railiance-platform asked for a generated list to consume instead of hand- maintaining agent-high-risk-boundary. Hand-maintaining it is what let the two lists drift for four lanes in RISK-F-0009. 19 high-risk lanes, 14 concrete data paths, 5 without a single KV address listed separately so absence does not read as omission. Carries catalog_revision and a dirty flag. fields is null where unestablished, never a one-element guess. The header states plainly that this is an input and not a policy: railiance- platform owns the deny set and may deny more, less, or dispute a grade. ADR-0002 survives the handoff. Two CI tests guard staleness, because a consumer applies this to a live control. Note the immediate consequence of T02: 2 uncovered against a policy they closed to 0 yesterday. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| capabilities | ||
| flex-auth | ||
| generated | ||
| indexes | ||
| policy | ||
| routing | ||
| README.md | ||
Capability Registry
Markdown-first capability index for federation and reuse planning.
Authoring
- Copy a capability entry template (see reuse-surface
templates/capability-entry.template.md). - Add the row to
indexes/capabilities.yaml. - Run
reuse-surface validatefrom a checkout with the CLI installed. - Merge to
mainand verify publish withreuse-surface establish --publish-check.
Federation contract: reuse-surface docs/RegistryFederation.md.