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

```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=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:
```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)

```bash
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

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

---

## 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`:
   ```bash
   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

```bash
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

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

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

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

```bash
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:

```bash
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.

### 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

```bash
# Fast discovery surface — read this first
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 |

---

## 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:**

```yaml
---
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/`)