77 lines
2.8 KiB
Markdown
77 lines
2.8 KiB
Markdown
|
---
|
||
|
|
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"
|
||
|
|
---
|
||
|
|
|
||
|
|
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
|
||
|
|
|
||
|
|
```task
|
||
|
|
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
|
||
|
|
|
||
|
|
```task
|
||
|
|
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
|
||
|
|
|
||
|
|
```task
|
||
|
|
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.
|