coulomb/core-hub
Archived
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Set up Core Hub framework planning

Browse Source
This commit is contained in:
Bernd Worsch
2026-06-27 11:00:12 +02:00
parent 8ed13623e5
commit a69df288b7
33 changed files with 1058 additions and 274 deletions
Download Patch File Download Diff File Expand all files Collapse all files

155
AGENTS.md
View File

@@ -1,20 +1,19 @@
# Repo Seed — Agent Instructions
# Core Hub - Agent Instructions
## Repo Identity
**Purpose:** Git repository template to bootstrap coulomb projects.
**Purpose:** 3rd-generation production interaction framework for Coulomb / Helixforge. Reimagines and replaces the 2nd-generation Inter-Hub framework goals on a practical contract-first Python/FastAPI/Postgres platform.
**Domain:** infotech
**Repo slug:** repo-seed
**Repo slug:** core-hub
**Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a`
**Workplan prefix:** `REPO-WP-`
**Workplan prefix:** `CORE-WP-`
---
## State Hub Integration
The Custodian State Hub tracks work across all domains. Interact via HTTP REST —
there is no MCP server for Codex agents.
The Custodian State Hub tracks work across all domains. Interact via HTTP REST - there is no MCP server for Codex agents.
| Context | URL |
|---------|-----|
@@ -24,25 +23,19 @@ there is no MCP server for Codex agents.
### Orient at session start
```bash
# Offline brief — works without hub connection
cat .custodian-brief.md
# Active workstreams for this domain
curl -s "http://127.0.0.1:8000/workstreams/?topic_id=cee7bedf-2b48-46ef-8601-006474f2ad7a&status=active" \
| python3 -m json.tool
# Check inbox
curl -s "http://127.0.0.1:8000/messages/?to_agent=repo-seed&unread_only=true" \
| python3 -m json.tool
curl -s "http://127.0.0.1:8000/workstreams/?topic_id=cee7bedf-2b48-46ef-8601-006474f2ad7a&status=active" | python3 -m json.tool
curl -s "http://127.0.0.1:8000/messages/?to_agent=core-hub&unread_only=true" | python3 -m json.tool
```
Mark a message read:
```bash
curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
-H "Content-Type: application/json" -d '{}'
```
### Log progress (required at session close)
### Log progress at session close
```bash
curl -s -X POST http://127.0.0.1:8000/progress/ \
@@ -64,156 +57,86 @@ Omit `workstream_id` / `task_id` when not applicable.
curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
-H "Content-Type: application/json" \
-d '{"status": "progress"}'
# values: wait | todo | progress | done | cancel
```
### Flag a task for human review
```bash
curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
-H "Content-Type: application/json" \
-d '{"needs_human": true, "intervention_note": "reason"}'
```
Status values: `wait | todo | progress | done | cancel`.
---
## Session Protocol
**Start:**
1. `cat .custodian-brief.md` — domain goal and open workstreams (offline-safe)
2. Check inbox: `GET /messages/?to_agent=repo-seed&unread_only=true`; mark read
3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks
4. Check human-needed tasks: `GET /tasks/?needs_human=true`
1. `cat .custodian-brief.md` - domain goal and open workstreams.
2. Check inbox: `GET /messages/?to_agent=core-hub&unread_only=true`; mark read when acted on.
3. Scan workplans: `ls workplans/` and inspect `ready`, `active`, or `blocked` files.
4. Check human-needed tasks: `GET /tasks/?needs_human=true` when the work may touch operational gates.
**During work:**
- Update task statuses in workplan files as tasks progress
- Record significant decisions via `POST /decisions/`
- Update workplan files first; State Hub is the read/cache/index layer.
- Record significant decisions via `POST /decisions/` when available.
- Keep secrets out of Git, State Hub, workplans, logs, and chat.
**Close:**
1. Update workplan file task statuses to reflect progress
2. Log: `POST /progress/` with a summary of what changed
3. Note for the custodian operator: after workplan file changes, run from
`~/state-hub`:
```bash
make fix-consistency REPO=repo-seed
```
This syncs task status from files into the hub DB.
1. Update workplan statuses.
2. From `~/state-hub`, run `make fix-consistency REPO=core-hub` after workplan changes.
3. Log progress with `POST /progress/`.
---
## Credential and access routing
## Credential and Access Routing
**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
for inference. Run this check **before** requesting secrets, API keys, SSH access,
login tokens, or database passwords — in any repo, not only `ops-warden`.
ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
other credential need belongs to another subsystem. **Do not** message
`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
### Lookup (do this first)
Before requesting secrets, API keys, SSH access, login tokens, or database passwords, route the need through ops-warden/OpenBao/key-cape ownership.
```bash
warden route find "<describe your need>" --json
warden route show <catalog-id> --json
```
Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
| Agent runtime | How to orient |
| --- | --- |
| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=repo-seed` is for coordination, not secret vending |
| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
### Quick routing table
| I need… | Owner | ops-warden executes? |
| --- | --- | --- |
| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
| Authorization decision | flex-auth | No — route only |
| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
### Anti-patterns (do not do these)
- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
- Pasting secrets into Git, State Hub, workplans, logs, or chat
### Other capabilities (reuse-surface)
Non-credential capabilities are usually discovered through **reuse-surface** federation
(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
every repo's agent instructions because it is high-frequency, high-risk, and easy to
get wrong.
**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`
<!-- REPO-AGENTS-EXTENSIONS -->
<!-- Append repo-specific agent instructions below this marker.
The state-hub template sync preserves content after this line. -->
ops-warden issues SSH certificates only. API keys, DB passwords, provider tokens, login/OIDC/MFA, authorization decisions, and OpenBao leases belong to their owning subsystems. Do not paste secrets into Git, State Hub, workplans, logs, or chat.
---
## Workplan Convention (ADR-001)
Work items originate as files in this repo — not in the hub. The hub is a
read/cache/index layer that rebuilds from files.
Work items originate as files in this repo, not in the hub. The hub rebuilds from files.
**File location:** `workplans/REPO-WP-NNNN-<slug>.md`
**File location:** `workplans/CORE-WP-NNNN-<slug>.md`
**Archived location:** finished workplans may move to
`workplans/archived/YYMMDD-REPO-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is
the completion/archive date; the frontmatter `id` does not change.
**Archived location:** finished workplans may move to `workplans/archived/YYMMDD-CORE-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is the completion/archive date; the frontmatter `id` does not change.
**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use
`workplans/ADHOC-YYYY-MM-DD.md` with task ids `ADHOC-YYYY-MM-DD-T01`, etc. Use
this only for low-risk work completed directly; create a normal workplan for
anything needing analysis, design, approval, dependencies, or multiple phases.
**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use `workplans/ADHOC-YYYY-MM-DD.md` with task ids `ADHOC-YYYY-MM-DD-T01`, etc. Use this only for low-risk work completed directly.
**Frontmatter:**
```yaml
---
id: REPO-WP-NNNN
id: CORE-WP-NNNN
type: workplan
title: "..."
domain: infotech
repo: repo-seed
repo: core-hub
status: proposed | ready | active | blocked | backlog | finished | archived
owner: codex
topic_slug: ...
topic_slug: custodian
created: "YYYY-MM-DD"
updated: "YYYY-MM-DD"
state_hub_workstream_id: "<uuid>" # written by fix-consistency — do not edit
state_hub_workstream_id: "<uuid>" # written by fix-consistency - do not edit
---
```
Use `proposed` for a new draft, `ready` after review against current repo
state, and `finished` after implementation. `stalled` and `needs_review` are
derived health labels, not frontmatter statuses.
Task block format:
**Task block format** (one per `##` section):
```
````markdown
## Task Title
` ` `task
id: REPO-WP-NNNN-T01
```task
id: CORE-WP-NNNN-T01
status: wait | todo | progress | done | cancel
priority: high | medium | low
state_hub_task_id: "<uuid>" # written by fix-consistency — do not edit
` ` `
Task description text.
state_hub_task_id: "<uuid>" # written by fix-consistency - do not edit
```
Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.
Task description text.
````
To create a new workplan:
1. Write the file following the format above
2. Notify the custodian operator to run `make fix-consistency REPO=repo-seed`
(or send a message to the hub agent via `POST /messages/`)
Status progression: `todo` -> `progress` -> `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.