The advisory on coder-mos1 is retracted and the hold released; the token was valid all along and the
403 was a scope refusal on /user, not an authentication rejection.
coder-mos1 contributed the piece neither Mos nor I had. My differential proves capability but cannot
tell a BROKEN credential from a NARROW one, and that distinction is exactly what a credential advisory
turns on. Its addition: a genuinely invalid token returns 401, while a scope refusal returns 403 with a
required-scope body. So body-aware classification plus an invalid-token 401 control settles credential
validity without needing read:user at all.
A status code read as a bare number cannot distinguish "wrong key" from "right key, narrow door", and
reading it as a bare number nearly cost an escalation on f10-coder and an indefinite silent hold on
coder-mos1 on the same day. A held seat is externally indistinguishable from an idle one, which is what
makes that false negative expensive.
Also banked: capability and identity are separate conditions with different evidence and neither
substitutes for the other. coder-mos1 held that line in its own release criterion after I had corrected
only the capability half, and refused to widen its own token scope to make a check pass — which would
have been D-45, an audited party relaxing its own audit.
read:user is an enhancement for mechanical self-checking, not a repair. The classification belongs in
the seat-provisioning checklist rather than only in this ledger.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
