docs: correct stale key-cape blocker claim on the decisions origin
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 12s

An earlier version said the origin unblocks KEY-WP-0013-T02, 'blocked since
2026-09-08'. Both halves are wrong. T02 is done, and so is T05 -- the task that
actually held the human registration. key-cape published the contract shape from
its side and closed a follow-up informed-decision prompted (KEY-WP-0030).
Nothing there waits on this host.

The error came from repeating informed-decision's workplan prose of 2026-09-09
without checking the source repo. The origin work stands on its own: T07's
acceptance requires a real origin regardless of who else is waiting.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJbh7o7UWF4tQ5jxygnNGu

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2072522@bnt-lap001
Assistant-Session: 46173adf-7302-4ede-99d6-963b61359928
This commit is contained in:
tegwick 2026-09-11 00:53:08 +02:00
parent 8d3e4a62b6
commit eff457ef52

View file

@ -7,9 +7,21 @@ Last reviewed: 2026-09-10
## Why this host exists before the app does
`informed-decision` owns the browser-facing approver UI that `approval-engine`
deliberately does not contain. Its workplan task `INFD-WP-0001-T07` must publish
two strings to `key-cape` — an OIDC `client_id` and a full callback URI — and
close `KEY-WP-0013-T02`, which has been blocked on them since 2026-09-08.
deliberately does not contain. Its workplan task `INFD-WP-0001-T07` must publish two strings to `key-cape` — an
OIDC `client_id` and a full callback URI — and cannot do so against a host that
does not answer.
**Correction, 2026-09-11.** An earlier version of this document said the origin
unblocks `key-cape`'s `KEY-WP-0013-T02`, "blocked since 2026-09-08". That is
wrong twice over, and the error came from repeating `informed-decision`'s
workplan prose of 2026-09-09 without checking the source repo. `KEY-WP-0013-T02`
is `done`; so is `T05`, the task that actually carried the human registration.
`key-cape` published the contract shape from its side — including the
`approval:read` scope `informed-decision` asked for and a fix to the `assurance`
object's `at` field — and closed a follow-up (`KEY-WP-0030`) that
`informed-decision` prompted. **Nothing in `key-cape` is waiting on this host.**
What remains is `informed-decision`'s own `T07`, whose acceptance requires the
real origin regardless.
Both strings are now fixed except for the host:
@ -86,8 +98,9 @@ fallback. That is the correct behaviour for now: the origin answers, which is
what the registration needs. The real surface will handle the path when
`INFD-WP-0001-T08` ships.
**`informed-decision` is unblocked to submit `docs/keycape-client-registration.md`
to `key-cape` and close `KEY-WP-0013-T02`.**
**`informed-decision` can now submit `docs/keycape-client-registration.md` to
`key-cape`.** That closes its own `INFD-WP-0001-T07`, not a `key-cape` task —
see the correction above.
## Redeploy / recovery