key-cape/workplans/KEY-WP-0029-scope-reassessment.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id	state_hub_workstream_id
KEY-WP-0029	workplan	Reassess SCOPE against the current revision	infotech	key-cape	finished	claude	scope-reassessment	2026-09-09	2026-09-09	cebe226b-5418-5559-bc48-379e843bca78	cebe226b-5418-5559-bc48-379e843bca78

---

id: KEY-WP-0029 type: workplan title: "Reassess SCOPE against the current revision" domain: infotech repo: key-cape status: finished owner: claude topic_slug: scope-reassessment created: "2026-09-09" updated: "2026-09-09" state_hub_workstream_id: "cebe226b-5418-5559-bc48-379e843bca78" state_hub_workstream_id: "cebe226b-5418-5559-bc48-379e843bca78"

SCOPE.md declared itself reviewed against b989de4, 63 commits behind. Its limits section had been kept current by appending to bullets, which works until the header asserts a review date that no longer describes what was reviewed.

Recheck every claim against source

id: KEY-WP-0029-T01
status: done
priority: medium
state_hub_task_id: "b12dfe7d-f4b6-5c44-89c6-9d3c02435d4c"

Routes read from the mux registrations, subcommands from the dispatch in main.go and internal/authclient/cli.go, flags from the flag sets, claim behaviour from token.go and userinfo.go. Where the existing prose and the code disagreed, the code won.

Three claims were false and are corrected: caller commands omitted verify-client; the container was described as packaging only keycape, untrue since KEY-WP-0026; and the issuer API row omitted /readyz. Capabilities that had only reached SCOPE piecemeal — the authorization-code bindings, upstream token verification, readiness and drain, the human tenant rules, authentication-time assurance, the shared verifier — are now stated in the capability table rather than only in the limits prose.

Separate source behaviour from deployed behaviour

id: KEY-WP-0029-T02
status: done
priority: medium
state_hub_task_id: "28ae58c0-9bb9-573f-9cf3-51230d053e3c"

The document now says plainly that it describes source, and that the two are different claims with different evidence: the test suite and harness runs for one, committed receipts in docs/evidence/ for the other.

What is proven live is narrower and is stated exactly — the issuer pin, whose pre-pin state did not match, so that risk was real rather than hypothetical; and the two approval clients verified in an attended owner process. Both receipts decline real predecessor rotation and observed wall-clock expiry, and SCOPE declines them too. The deployed image predates this revision, so several behaviours SCOPE describes are running nowhere yet, two of them fail-closed at startup.

This is the correction that matters. Four times in two days a statement about current state was written from a workplan paragraph, a partial git status, or an inference about what was admitted, without reading the authoritative artifact. A SCOPE that does not distinguish "the code does this" from "this is running" invites exactly that error from the next reader.

Record the reassessment

id: KEY-WP-0029-T03
status: done
priority: low
state_hub_task_id: "7ef92d4f-eb56-5208-8b85-ed7bb2656c46"

history/2026-09-09-scope-reassessment.md records the method, what changed since 2026-09-05, the corrections, and what remains. It supersedes rather than replaces the 2026-09-05 assessment, which stays as the record of the ten-gap backlog and its closures; both are linked from SCOPE.