The render-hooks resolver and capability-state resolver headers (and their CONTEXT.md glossary entries) still claimed "no workflow calls this yet" / "consumed by nothing yet (phase-6 wiring is out of scope)". Both are now false: loop.render-hooks is consumed live by plan-phase.md/autonomous.md (plan:pre ui-phase, verify:post ui-review), and capability-state is the `gsd-tools capability state` CLI diagnostic.
Comment/prose only — no behavior change. Surfaced by the ADR-857 phase 1-5 completeness audit.
Closes#1125
Refs #857
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Add the loop.render-hooks resolver: the first registry-consuming query.
`gsd-tools loop render-hooks <point>` validates the point against the
authoritative canonical 12, reads the registry's materialized byLoopPoint
hooks, filters them by activation, and emits a JSON envelope {point,
activeHooks, rendered} with ordered markdown.
Activation resolves each hook's `when` key by precedence: loadConfig value
(post-cutover federated) -> raw config.json workstream/root single-key lookup
(pre-cutover central override) -> registry configSchema default (so a
default:true capability hook is active out-of-the-box) -> inactive. Guarded
single-value reads only (no merged object built from untrusted keys).
Registry-only: no workflow calls the resolver yet (wiring is the phase-6
cutover). Completes the phase-3 trio.
Closes#918
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
