evidence-binder/workplans/EBIND-WP-0002-capability-index-repair.md
tegwick 0c962ff508
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 2s
Align capability index domain
2026-08-21 11:59:37 +02:00

89 lines
3.6 KiB
Markdown

---
id: EBIND-WP-0002
type: workplan
title: "Repair capability registry federation metadata"
domain: infotech
repo: evidence-binder
status: active
owner: codex
topic_slug: capability_registry_federation
created: "2026-08-21"
updated: "2026-08-21"
---
# EBIND-WP-0002 — Repair capability registry federation metadata
Restore `evidence-binder` to the reuse-surface federation after its capability
index was found to contain `SCOPE.md` advertisement blocks instead of validated
registry rows. Preserve the valid SCOPE advertisements, add resolvable registry
entries, and assess maturity from current repository evidence.
## Repair and document the capability entries
```task
id: EBIND-WP-0002-T01
status: done
priority: high
```
Translate both index rows to the federation contract and add their backing
Markdown entries. Use repository evidence, current consumer integration, and
the reuse-surface maturity standard to choose defensible D/A/C/R vectors.
Acceptance:
- both rows expose all required federation fields and stable capability IDs
- both `path` values resolve to schema-valid Markdown entries
- maturity rationale distinguishes source availability from completeness and
reliability evidence
## Validate, synchronize, and request federation re-enable
```task
id: EBIND-WP-0002-T02
status: wait
priority: high
blocking_reason: awaiting repo-manager production registrar indexing
```
Run the reuse-surface validator and the repository quality checks, synchronize
the workplan with State Hub, and send non-secret completion evidence to the
reuse-surface owner so its federation source can be re-enabled.
Acceptance:
- registry validation passes without index-drift warnings
- tests, typecheck, lint, and repository diff checks pass
- State Hub records the completed work and reuse-surface receives the repair
summary and maturity vectors
Local implementation completed 2026-08-21. The checked-out reuse-surface
validator accepted both entries with warnings treated as failures. Repository
verification passed 43 tests plus typecheck, lint, and `git diff --check`. The
quality pass also found and removed a stale `AttributeValueType` import that had
been failing both typecheck and lint.
Published to Forgejo `main` as commit `e462775` on 2026-08-21; the remote head
was verified with `git ls-remote`. Reuse-surface was asked to re-enable and
refresh the source in State Hub message `9c857277-f0e9-4f29-9def-896bdba1fcc3`.
Closeout is waiting on two external-state confirmations: the capabilities
appearing in the federated API, and production-registrar assignment of State Hub
identifiers for this new workplan and its tasks.
Rechecked 2026-08-21: the hosted registration still reports `enabled: false`
and the federated API omits both capability IDs. The approved
`reuse-surface-hub-write-token` route was attempted without exposing or
persisting the credential, but OpenBao denied the proxy caller on the owning
runtime lane. The enable-and-compose action is escalated to the lane owner in
State Hub message `ad3221d0-ccd5-4f90-89b3-8bfec24a1f49`. The unread registrar
request was also rerouted to `repo-manager` in message
`5c74f09d-6ee6-4bac-b02f-18e6ab9ad173`.
Federation confirmed 2026-08-21 in reuse-surface message
`5dff19b9-fed6-4acf-b14e-2859620afcf9`: the source is enabled, the public compose
is fresh, and both capabilities appear with the assessed vectors. REUSE-WP-0020
T03 and T04 are closed. The same review identified a non-blocking metadata
inconsistency, so the index header is aligned from the scaffold default
`helix_forge` to this repository's and both rows' actual domain, `infotech`.
Only production-registrar identifier assignment remains before T02 can close.