tegwick
d6ecb2b7aa
SCOPE.md declared itself reviewed against b989de4, 63 commits behind, with its
limits kept current by appending to bullets. That works until the header asserts
a review date that no longer describes what was reviewed -- the drift this file
exists to prevent, in the document whose only job is to be accurate.
Every claim was rechecked against source rather than carried forward: routes from
the mux registrations, subcommands from the dispatch, flags from the flag sets,
claim behaviour from token.go and userinfo.go. Three were false. Caller commands
omitted verify-client, the container was said to package only keycape (untrue
since KEY-WP-0026), and the issuer API row omitted /readyz. Capabilities that had
reached SCOPE only piecemeal are now in the capability table: the
authorization-code bindings, upstream token verification, readiness and drain, the
human tenant rules, authentication-time assurance, the shared verifier.
The substantive addition is a distinction SCOPE did not draw: source behaviour
and deployed behaviour 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 now stated exactly, including that the
issuer pin's pre-pin state did not match, so that risk was real rather than
hypothetical, and that the deployed image predates this revision so several
described behaviours are running nowhere yet.
That distinction is the fix for a repeated error: four times in two days a claim
about current state was written from a workplan paragraph or a partial view
instead of the authoritative artifact. A SCOPE that does not separate "the code
does this" from "this is running" invites the same mistake from the next reader.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6
2.8 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated |
|---|---|---|---|---|---|---|---|---|---|
| KEY-WP-0029 | workplan | Reassess SCOPE against the current revision | infotech | key-cape | finished | claude | scope-reassessment | 2026-09-09 | 2026-09-09 |
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
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
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
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.