Files
state-hub/scripts/project_claude_md.template
tegwick ba89ebfa67 feat(canon): add inter-repo communication standard with todo taxonomy
Establishes the repo boundary rule and a formal vocabulary for classifying
work items by scope:

- Task: neutral state hub data entity
- Todo: a task scoped to the current session's repo/domain
  - Internal todo: addressed within this repo by this agent
  - Ecosystem todo: work for another registered repo → state hub task [repo:<slug>]
  - Third-party todo: work for an upstream repo → contribution artifact (BR/FR/EP/UPR)

New dashboard doc: /docs/inter-repo-communication — defines the boundary rule,
the full terminology, ecosystem and third-party todo workflows, and a decision
table for classifying any piece of work found during a session.

Also:
- sbom.md: replace verbose inter-repo section with a 3-line summary + link
- observablehq.config.js: add "Inter-Repo Communication" to Reference nav
- project_claude_md.template: add "### Repo Boundary Rule" section; fix
  Workplan Convention section (removing incorrect claim that the custodian
  writes workplan files in other repos — that is the target repo's job)

Cross-repo: created state hub task [repo:railiance-bootstrap] for that repo's
agent to apply the boundary rule and workplan convention fix to its own CLAUDE.md
(task 78d43cb0, workstream 59155efb).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-01 20:52:07 +01:00

174 lines
6.4 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# {PROJECT_NAME} — Claude Code Instructions
## Custodian State Hub Integration
This project is tracked as the **{DOMAIN}** domain in the Custodian State Hub.
Hub topic ID: `{TOPIC_ID}`
The State Hub runs locally at http://127.0.0.1:8000. The MCP server (`state-hub`)
exposes tools for reading and writing state without touching the API directly.
---
### Session Protocol
**On receiving your first message — before writing any response text — execute
this orientation sequence. Do not greet, do not ask what to do first.**
**Step 1 — Call the State Hub**
```
get_state_summary() # orientation: workstreams, decisions, recent progress
get_next_steps() # contextual suggestions from resolved decisions
```
If the call fails, the API is offline: `cd ~/the-custodian/state-hub && make api`
**Step 2 — Scan local workplans**
Read every `.md` file under `workplans/`. Use `Glob(pattern="**/*.md", path="workplans/")`
or Bash `ls workplans/` to discover them. For each file with `status: active`,
extract and note:
- The workplan title and ID
- All tasks whose `status` is `todo` or `in_progress`
**Step 3 — Present orientation to the user**
Output a concise brief covering:
1. **Active workstreams** (from state hub) for the `{DOMAIN}` domain — title,
task counts, any blocking decisions
2. **Pending tasks for this repo** — from local `workplans/` files (Step 2)
plus any state hub tasks with `[repo:{REPO_SLUG}]` in their title
3. **Suggested next action** — the highest-priority open item across both sources
4. **SBOM status** — is `last_sbom_at` set for this repo? If not, note it as a gap
If there are no workstreams at all: follow the First Session Protocol below.
**During work:**
- Use `record_decision()` for any decision that affects direction or dependencies.
- Use `add_progress_event()` for notable events (milestones, blockers, insights).
- Use `resolve_decision()` to close a decision once the choice is made.
> **Design boundary:** The State Hub is a *read model*. Two write operations are
> permanently sanctioned: **Resolving Decisions** and **Suggesting Next Steps**.
> The bootstrap tools (`create_workstream`, `create_task`, `update_task_status`)
> are only for First Session Protocol. Formal work structure — workplans, tasks —
> belongs in the domain repo as files (ADR-001), not managed through the hub alone.
**At the end of every session:**
- Call `add_progress_event()` with a summary of what was accomplished or decided.
Include `topic_id: {TOPIC_ID}` and the relevant `workstream_id`.
---
### Repo Boundary Rule
This agent is responsible for files **in this repo only**.
- **Do not** write files or make commits in any other repository
- **Do not** create workplan files in other repos on their behalf
- When you identify work for another registered repo (**ecosystem todo**):
create a state hub task with `[repo:<slug>]` in the title — the other repo's
agent will see it at session start and create its own workplan
- When you identify work for an upstream repo (**third-party todo**):
create a contribution artifact in `contrib/` and register it
Terminology and workflows: `http://localhost:3000/docs/inter-repo-communication`
---
### First Session Protocol
Triggered when `get_state_summary()` shows **no workstreams** for the `{DOMAIN}`
topic. The project is registered but work has not yet been structured.
**Step 1 — Understand the project (read, don't write)**
- `~/the-custodian/canon/projects/{DOMAIN}/project_charter_v0.1.md` — purpose, scope
- `~/the-custodian/canon/projects/{DOMAIN}/roadmap_v0.1.md` — planned phases
- Scan the repo root: README, directory structure, existing code or docs
**Step 2 — Survey in-progress work**
- Look for TODOs, open branches, half-finished files, notes
- Note what is already done vs. what is clearly started but incomplete
**Step 3 — Propose workstreams to Bernd**
Propose 13 workstreams — each a coherent strand of work lasting weeks to months,
named clearly, anchored to a roadmap phase. **Wait for approval before creating.**
**Step 4 — Create workplan file first, then DB record**
Per ADR-001, work items originate as files in the repo:
```
workplans/<DOMAIN>-WP-NNNN-<slug>.md ← write this first
```
Then register in the hub:
```
create_workstream(topic_id="{TOPIC_ID}", title="...", owner="...", description="...")
create_task(workstream_id="<id>", title="...", priority="high|medium|low")
```
**Step 5 — Record the setup**
```
add_progress_event(
summary="First session: structured {DOMAIN} work into N workstreams, M tasks",
event_type="milestone",
topic_id="{TOPIC_ID}",
detail={"workstreams": [...], "tasks_created": M}
)
```
---
### Workplan Convention (ADR-001)
Work items MUST originate as files in this repo before being registered in the hub.
**File location:** `workplans/<ID>-<slug>.md`
**Frontmatter required:** `id`, `type: workplan`, `domain`, `repo`, `status`,
`state_hub_workstream_id`, `state_hub_task_id` (per task)
When another domain's agent identifies work for this repo, it creates a state hub
task with `[repo:{REPO_SLUG}]` in the title (an **ecosystem todo**). You will
see it at session start via `get_state_summary()`. When you pick it up, create
the corresponding workplan file in `workplans/` (ADR-001) and begin work.
---
### Contribution Tracking
Track upstream contributions in `contrib/` — bug reports (BR), feature requests
(FR), extension-point proposals (EP), upstream PRs (UPR).
```
contrib/
bug-reports/ # br-YYYY-MM-DD--org--repo--slug.md
feature-requests/ # fr-YYYY-MM-DD--org--repo--slug.md
extension-points/ # EP-{DOMAIN}-NNN--org--repo--slug.md
upstream-prs/ # upr-YYYY-MM-DD--org--repo--slug.md
```
Templates: `~/the-custodian/canon/standards/contrib-templates/`
Convention: `~/the-custodian/canon/standards/contribution-convention_v0.1.md`
```
register_contribution(type="br|fr|ep|upr", title="...", target_org="...",
target_repo="...", body_path="contrib/...", related_workstream_id="<uuid>")
update_contribution_status(contribution_id="<uuid>", status="submitted")
```
---
### SBOM
After updating dependencies, re-ingest the SBOM:
```bash
cd ~/the-custodian/state-hub
make ingest-sbom REPO={REPO_SLUG} SCAN=1 REPO_PATH=$(pwd)
```
Check compliance: `http://localhost:3000/repos`
Standard: `~/the-custodian/canon/standards/sbom-convention_v0.1.md`
---
### Quick Reference
`~/the-custodian/state-hub/mcp_server/TOOLS.md` — compact MCP tool reference