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

---
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

```task
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

```task
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

```task
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.