Implements the hub side of the shared reuse-event schema (already drafted in WP-0018-T01, schemas/reuse-event.schema.json): a SQLite reuse_events table, POST /v1/reuse-events (token-auth), GET /v1/reuse-events?capability_id= (read-only). reuse_surface/plan_check.py: refactored record_outcome around a new shared post_or_fallback_reuse_event() helper -- tries the hub first, falls back to the local JSONL only on failure/unreachability, never both. New record_manual_reuse_event() backs a new CLI command, reuse-surface record-reuse, for retroactive facts recorded outside plan-check. Privacy/scope (repo slugs and capability ids only, no code, no secrets) is enforced structurally via the schema's additionalProperties: false, not just by convention. 21 new pytest cases, 145 total pass. Live-verified against a real running hub instance: POST/GET /v1/reuse-events directly, record-reuse and plan-check --record-outcome both posting successfully to the hub, and -- after actually killing the hub process -- confirmed the fallback path writes correctly to the local JSONL instead of erroring. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
9.3 KiB
SCOPE
One-liner
Capability registry for planning and implementation reuse based on discovery and delivery maturity.
Core Idea
reuse-surface provides a registry-centric reuse layer for capabilities. It
makes capabilities visible, comparable, assessable, and reusable for planning,
implementation, and operation. A capability that is not registered is invisible
for reuse within this product boundary.
In Scope
- Maintain the capability maturity model, standards, schemas, registry formats, sample entries, indexes, validation guidance, CLI tooling, hub service, and agent instructions.
- Keep
INTENT.md,specs/, registry artifacts, and State Hub workplans aligned on the registry-first reuse boundary. - Support humans and agents as registry consumers through Markdown-first authoring and machine-readable metadata.
- Record decisions, progress, and workplan status through State Hub.
- Verify changes with
reuse-surface validate,git diff --check, and ADR-001 consistency checks.
Out of Scope
- Host or operate the registered capabilities themselves (except the federation hub coordinator, which stores repo metadata and index URLs only).
- Replace package registries, service catalogs, issue trackers, or project management systems.
- Judge internal code quality as capability maturity.
- Own unrelated adjacent systems or make irreversible operational decisions without human approval.
What Is Possible Now
The MVP registry foundation, CLI tooling (REUSE-WP-0003), federation stack (WP-0005/0010), and hosted hub (WP-0011) are in place. Humans and agents can:
- Discover capabilities via
registry/indexes/capabilities.yaml,reuse-surface query, orGET https://reuse.coulomb.social/v1/federated - Add a new capability at D0/A0/C0/R0 using
templates/capability-entry.template.md - Promote capabilities with evidence,
promotion_history, and index vector updates - Compare candidates using maturity vectors, scope, relations, and consumer guidance
- Record expectations through
external_evidence.completenessandexternal_evidence.reliability - Validate entries automatically with
reuse-surface validate - Export a machine-readable bundle with
reuse-surface export - Detect overlap candidates with
reuse-surface overlaps - Generate a human-readable catalog with
reuse-surface catalog - Browse a searchable catalog at
docs/catalog/search.html - Compose federated indexes with
reuse-surface federation compose(local paths and remote HTTP URLs with cache) - Register federation sources on the hosted hub with
reuse-surface hubagainsthttps://reuse.coulomb.social - Sync local federation manifest from hub with
reuse-surface hub sync - Export planning cohorts with
reuse-surface report cohorts - Report registry gaps with
reuse-surface report gaps(roster blockers, empty scaffolds, dedup stubs) - Bootstrap a sibling registry with
reuse-surface establish --scaffold - Verify index publish readiness with
reuse-surface establish --publish-check - View registry stats with
reuse-surface stats(per-repo or--roster registry/federation/local-repo-roster.yaml --federation-ready) - Draft or refresh entries with
reuse-surface establish --discoverandreuse-surface update(optional llm-connect backend) - Maintain registry interactively or automatically with
reuse-surface maintain(TTY prompts,--auto, optional llm-connect,--publishchain) - Run the hub locally or in a container with
reuse-surface serve - Generate relation graphs with
reuse-surface graph - Explore relations interactively at
docs/graph/index.html - Avoid duplicates by querying the index and checking overlaps before adding entries
- Check before building with
reuse-surface plan-check(REUSE-WP-0018) — match a draft workplan or free-text intent against the federated index and get a reuse/extend/new verdict;--file-requestbridges anewverdict to a State Hub capability request;report gaps --check-capability-requestssurfaces open requests with no matching capability - Get automatic hub refresh (REUSE-WP-0019-T02/T03) — a Forgejo push
webhook (
POST /v1/webhooks/forgejo, HMAC-signed) recomposes the hub's federated index when a registered repo'sregistry/indexes/changes, withcomposed_at/stalevisibility onGET /v1/federatedand a scheduled fallback recompose if a webhook delivery is ever missed - Record reuse telemetry (REUSE-WP-0019-T04) —
plan-check --record-outcomeandreuse-surface record-reusepost facts toPOST /v1/reuse-eventswhen the hub is reachable, falling back toregistry/telemetry/plan-check-events.jsonlotherwise (same schema either way);GET /v1/reuse-events?capability_id=aggregates them
Registry tooling availability is A4 (CLI plus hosted hub HTTP API). Registry authoring remains Markdown-first; consumption combines entries, the index, CLI automation, and the production hub.
What Is Not Possible Yet
- Multi-domain federation — all indexed capabilities remain
helix_forge - Planning analytics breadth —
report gapsshipped (REUSE-WP-0015-T03); no roadmap views or standardization tracker beyondoverlapsand compose collision warnings - Managed platform posture — hub runs as a container (A5 artifact) without implemented SLO, multi-replica, or Postgres backing (criteria documented)
- Formal consumer feedback loop for registry workflows (reliability evidence is mostly structural: CI/tests, not production telemetry)
See tools/README.md for command reference.
Current State
- Status: active registry with CLI, federation, production hub, and workstation-wide coverage campaign complete (REUSE-WP-0017 finished 2026-07-07).
- Capabilities (reuse-surface): 2 helix_forge meta-registry entries in
registry/capabilities/. - Workstation roster: 62 local git repos at
~/<slug>/tracked inregistry/federation/local-repo-roster.yaml— all established, 62/62 hub-registered (inter-hub registration disabled on hub), 62/62 publish-check pass, 62/62 capability coverage (hasor explicitnone). - Federation:
registry/federation/sources.yaml— 61 enabled sources;registry/indexes/federated.yaml— 61 composed capability rows (inter-hub excluded; core-hub included; 0 duplicate-ID warnings at last compose). - CLI / service:
reuse_surface/— validate, query, export, overlaps, catalog, federation, graph, hub client, establish/update/stats,serve(FastAPI hub). - Production hub:
https://reuse.coulomb.social— 61 enabled repo registrations;GET /v1/federatedserves 61 capabilities from published raw URLs (compose refreshed 2026-07-07). - Specs:
specs/FederationHubAPI.md,schemas/hub-registration.schema.yaml. - Docs:
docs/CapabilityRegistryConcept.md,docs/RegistryFederation.md,docs/IntentScopeGapAnalysis.md, deploy guidedocs/deploy/reuse-kubernetes.md. - CI:
.forgejo/workflows/ci.yml— validate, federation compose, catalog, graph, pytest, informationalreport cohorts,stats --roster,report gaps(migrated from Gitea 2026-07-07, REUSE-WP-0019-T03). Also.forgejo/workflows/image.yaml(container build/push) andrecompose-fallback.yaml(scheduled hub recompose, webhook backstop). - Relation graph:
docs/graph/capability-graph.mmd,docs/graph/index.html. - Searchable catalog:
docs/catalog/search.html. - Workplans: REUSE-WP-0001 through REUSE-WP-0015 finished (archived); REUSE-WP-0017 capability coverage campaign finished (2026-07-07); REUSE-WP-0018 plan-check consumption loop active next.
- Assessment history:
history/— intent/scope assessments, rollout milestone, dedup plan, per-repo follow-up. - Self-assessed vector:
D5 / A4 / C5 / R3(seedocs/IntentScopeGapAnalysis.md).
Repository Layout
reuse-surface/
├── INTENT.md
├── SCOPE.md
├── AGENTS.md
├── pyproject.toml
├── Dockerfile
├── reuse_surface/ # CLI, hub service, federation, graph, catalog
├── specs/
├── schemas/
├── templates/
├── registry/
│ ├── capabilities/ # per-entry Markdown
│ ├── indexes/ # capabilities.yaml, federated.yaml
│ └── federation/ # sources.yaml, local-repo-roster.yaml, cache/
├── docs/
├── tools/
└── workplans/
└── archived/
Getting Oriented
- Start with: INTENT.md
- Registry concept: docs/CapabilityRegistryConcept.md
- Intent vs scope gaps: docs/IntentScopeGapAnalysis.md
- Assessment snapshots: history/
- Product requirements: specs/ProductRequirementsDocument.md
- Use cases: specs/UseCaseCatalog.md
- Maturity standard: specs/CapabilityMaturityStandard.md
- Hub API: specs/FederationHubAPI.md
- Registry index: registry/indexes/capabilities.yaml
- Registry guidance: registry/README.md
- Federation guide: docs/RegistryFederation.md
- Hub deployment: docs/deploy/reuse-kubernetes.md
- Generated catalog: docs/CapabilityCatalog.md
- Searchable catalog: docs/catalog/search.html
- Relation graph: docs/graph/capability-graph.mmd
- Graph explorer: docs/graph/index.html
- CLI reference: tools/README.md
- Agent instructions: AGENTS.md
- Workplans: workplans/