reuse-surface/AGENTS.md

reuse-surface — Agent Instructions

Repo Identity

Purpose: Capability registry for planning and implementation reuse based on discovery and delivery maturity.

Domain: helix_forge Repo slug: reuse-surface Topic ID: f39fa2a3-c491-414c-a91b-b4c5fcc6139c Workplan prefix: REUSE-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.

Context	URL
Local workstation	http://127.0.0.1:8000
Remote via tunnel	http://127.0.0.1:18000

Orient at session start

# 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=f39fa2a3-c491-414c-a91b-b4c5fcc6139c&status=active" \
  | python3 -m json.tool

# Check inbox
curl -s "http://127.0.0.1:8000/messages/?to_agent=reuse-surface&unread_only=true" \
  | python3 -m json.tool

Mark a message read:

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)

curl -s -X POST http://127.0.0.1:8000/progress/ \
  -H "Content-Type: application/json" \
  -d '{
    "summary": "what was done",
    "event_type": "note",
    "author": "codex",
    "workstream_id": "<uuid>",
    "task_id": "<uuid>"
  }'

Omit workstream_id / task_id when not applicable.

Update task status

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

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"}'

---

Session Protocol

Start:

1. cat .custodian-brief.md — domain goal and open workstreams (offline-safe)
2. Check inbox: GET /messages/?to_agent=reuse-surface&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

During work:

• Update task statuses in workplan files as tasks progress
• Record significant decisions via POST /decisions/

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:

   make fix-consistency REPO=reuse-surface
   

   This syncs task status from files into the hub DB.

---

Local Developer Workflow

The repository is primarily documentation-first with a small Python CLI for registry validate, query, and export. There is no long-running service.

Install

python3 -m venv .venv
.venv/bin/pip install -e .

Build

No separate build step. Treat Markdown, YAML, and workplan edits as source artifacts.

Test / lint

# Registry validation (schema + index drift)
.venv/bin/reuse-surface validate

# Overlap, catalog, federation, and graph
.venv/bin/reuse-surface overlaps
.venv/bin/reuse-surface catalog
.venv/bin/reuse-surface federation compose
.venv/bin/reuse-surface graph --check

# Federation service (local)
# REUSE_SURFACE_TOKEN=dev-token reuse-surface serve

# Hub CLI (against deployed or local service)
# REUSE_SURFACE_URL=http://127.0.0.1:8000 reuse-surface hub status

# Automated tests
.venv/bin/pytest -q

# Repository hygiene
rg --files
git diff --check

When workplan files change, sync ADR-001 file state into State Hub:

curl -s -X POST "http://127.0.0.1:8000/repos/reuse-surface/sync?fix=true" \
  | python3 -m json.tool

If the HTTP sync endpoint is unavailable, run the consistency script from the State Hub checkout:

cd ~/state-hub
.venv/bin/python scripts/consistency_check.py --repo reuse-surface --fix
.venv/bin/python scripts/consistency_check.py --repo reuse-surface

The generated instruction in older workplans says make fix-consistency REPO=reuse-surface; that is still valid when uv is installed and on PATH. On this workstation, the .venv/bin/python fallback has been verified.

CI runs reuse-surface validate on push and pull requests via .gitea/workflows/ci.yml.

Run

There is no local service to run from this repository.

Documentation Review Checklist

• Keep INTENT.md, SCOPE.md, and specs/ aligned on the registry-first reuse boundary.
• Keep maturity definitions in specs/CapabilityMaturityStandard.md consistent with INTENT.md and specs/ProductRequirementsDocument.md.
• Keep registry entries, indexes, and schemas in registry/, schemas/, and templates/ current when capabilities change.
• Record implementation ideas in workplans, not as premature runtime code in this repository.

---

Capability Registry

Before building or documenting a new reusable behavior, query the registry to avoid duplication and to select the best existing capability for planning or implementation reuse.

Orient

# Fast discovery surface — read federated index when multi-repo
cat registry/indexes/federated.yaml
cat registry/indexes/capabilities.yaml

# CLI discovery and export
.venv/bin/reuse-surface query --discovery-min D4
.venv/bin/reuse-surface export --format yaml

# Authoring template and schema
cat templates/capability-entry.template.md
cat schemas/capability.schema.yaml

# Validation and search guidance
cat registry/README.md
cat tools/README.md

Query workflow

1. Run .venv/bin/reuse-surface query with filters, or read the index directly.
2. Filter by vector, tags, consumption_modes, domain, or summary.
3. Open only matching files under registry/capabilities/.
4. Compare candidates using discovery, external_evidence, availability, and relations from the entry front matter.
5. Prefer planning reuse when discovery is strong (D3+, especially D5+).
6. Prefer implementation reuse only when availability is consumable (A2+ code, A3+ CLI, A4+ API/SDK).

Add a new capability

1. Search the index for overlap (UC-RS-015) before creating a new entry.
2. Copy templates/capability-entry.template.md to registry/capabilities/capability.<domain>.<name>.md.
3. Start at D0 / A0 / C0 / R0 when evidence is minimal; keep gaps explicit.
4. Add the entry to registry/indexes/capabilities.yaml.
5. Run .venv/bin/reuse-surface validate.

Promote a capability

1. Attach evidence required by specs/CapabilityMaturityStandard.md for the target level.
2. Update maturity for discovery/availability and external_evidence for completeness/reliability separately.
3. Refresh the index vector and record rationale in the entry body.
4. Do not treat higher availability as proof of reliability or completeness.

MVP acceptance mapping

Acceptance criterion	Registry surface
Add D0/A0/C0/R0 with minimal friction	template + index + registry README
Promote through discovery levels	entry front matter + maturity standard
Identify current consumption mode	availability + index consumption_modes
Record expectations and broken expectations	external_evidence.completeness
Record reliability evidence	external_evidence.reliability
Search by maturity and availability	reuse-surface query or index filters
Compare candidates	entry vectors + relations + README guidance
Avoid duplicate capabilities	index search before add

---

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)

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=reuse-surface 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

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.

File location: workplans/REUSE-WP-NNNN-<slug>.md

Archived location: finished workplans may move to workplans/archived/YYMMDD-REUSE-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.

Frontmatter:

---
id: REUSE-WP-NNNN
type: workplan
title: "..."
domain: helix_forge
repo: reuse-surface
status: proposed | ready | active | blocked | backlog | finished | archived
owner: codex
topic_slug: ...
created: "YYYY-MM-DD"
updated: "YYYY-MM-DD"
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 (one per ## section):

## Task Title

` ` `task
id: REUSE-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.

Status progression: todo → progress → done; use wait for waiting/blocked work and cancel for stopped work.

To create a new workplan:

1. Write the file following the format above
2. Notify the custodian operator to run make fix-consistency REPO=reuse-surface (or send a message to the hub agent via POST /messages/)