docs: correct stale key-cape blocker claim on the decisions origin
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:
parent
8d3e4a62b6
commit
eff457ef52
1 changed files with 18 additions and 5 deletions
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue