Record JWT adoption gap and independent verifier counterexamples

docs/evidence/2026-10-10-security-consolidation/key39-root-source-counterexamples.json

@@ -0,0 +1,9 @@
+{
+  "scope": "offline synthetic counterexamples; no HTTP/Kubernetes/credentials",
+  "manifest_sha256": "870d8faf5588311c8955f45ddc1c2d28ed4f43e5d00c5f54e2bdb405eaa71646",
+  "future_role_observation_accepted": true,
+  "unrelated_https_bao_origin_accepted": true,
+  "urllib_default_opener_inherits_proxy": true,
+  "review_disposition": "request_changes",
+  "native_execution_performed": false
+}

docs/security-collaboration-review-2026-10-10.md

@@ -553,7 +553,7 @@ audit. Its effort ranges are planning judgments, not measured calendar promises.
 
 | Bundle | Next acceptance | Conditional effort and closures |
 | --- | --- | --- |
-| Service JWT | Attended KEY39 negative claims and real expiry/cleanup; Mason operator/ESO capability and nonmember refusal; platform denial; actual Secrets Engine adoption |2–4focused sessions. KEY39, MASON9 and SECRETS8 are the strongest next whole-plan closures. RPF35T02 can finish; RPF35 retains six other unfinished tasks. |
+| Service JWT | Attended KEY39 negative claims and real expiry/cleanup; Mason operator/ESO capability and nonmember refusal; platform denial; separately scoped Secrets Engine backend execution entitlement and adoption |2–4focused sessions remains a conditional estimate for KEY39 and MASON9. SECRETS8 needs an owner-reviewed execution contract and implementation before a closure estimate is credible. RPF35T02 can finish; RPF35 retains six other unfinished tasks. |
 | Human identity and membership | Actual signed-in readback, tegwick U05–U08, precise changed fact/owner for scoped mutation/revocation, Fluid salt create-once evidence; ordinary management restoration |1–2attended sessions plus1–2implementation/verification sessions. MASON5 can finish afterT05/T06. USER27 also needs matrix/invitation/mail and real VERGABE-WP-0019 acceptance; catalogue bootstrap is not that proof. |
 | First reusable Forgejo SecurityCase | Implement acknowledged type1.2, authenticate six-object provenance, native closed adapters/receipts, separately authorized mint/delivery, login/denial/cleanup/created-only rollback |4–7focused sessions including attendance. First session closes NK48T06/MASON10T03/WARDEN44T03; their remaining reuse tasks still prevent whole-plan closure. A service-JWT target cannot reuse a browser type by relabeling. |
 | Audit and independent monitoring | Six-pin sender/custody, compatible commit/acceptance-time windows, persistent native rollout, actual retry/heartbeat/silence and Qonto receiver/collector evidence |4–7focused sessions across independent Access and Qonto tracks. KG5 can close after observer acceptance; AUDIT13 needs both senders. Quiet-stream evidence also needs its real observation interval/grace, including a24h Qonto cadence. |
@@ -582,3 +582,55 @@ mentions unresolved factor custody, while its later narrative and USER28's
 concrete evidence identify an available handoff and tegwick's attended run as
 the next act. Verify and refresh that owner qualifier before scheduling; do not
 revive an obsolete secret request from historical prose.
+
+### JWT preparation checkpoint and corrected adoption forecast
+
+Three parallel workers returned immutable source preparations. Root verified all
+staged file hashes and original checkout pins: KeyCape/NetKingdom manifest
+`870d8faf…`, Mason manifest `e5d4781c…`, and Secrets Engine revised manifest
+`c4668709…`. Reported offline checks are 20 lifecycle plus 17 existing runner
+tests, 19 capability-verifier tests, and 37 service-boundary tests respectively.
+These are preparations, not owner acceptance or native proof; no checkout
+application, credential session or runtime mutation occurred in this wave.
+
+Secrets Engine has a material functional adoption gap: its deployed service JWT
+permits login and self-management, while the protected backend operations use
+that same token after approval consumption. No task-scoped execution entitlement
+is wired. Switching the default would consume an approval and then fail at the
+backend. Login-only proof cannot close SECRETS8. A concrete Platform/Secrets
+owner design must bind action, target, TTL, uses, revocation and backend-enforced
+scope, followed by implementation and actual permitted/refused-operation proof.
+The prepared acceptance checklist preserves that gate and does not widen policy.
+
+The Secrets verifier's first prepared transport was rejected during root review.
+The new immutable version fixes origin, refuses redirects, disables environment
+proxies, bounds JSON and suppresses unsafe error/evidence output. Original bytes
+are retained. KeyCape also corrected the removed-client cleanup contract to the
+actual `401 invalid_profile_usage` with `feature=client_id`; the changed proposal
+needs fresh source acknowledgment. Mason uses the existing survey authority for
+capability queries because reader tokens lack `sys/capabilities-self`, without
+widening their policies. All three still require exact source review and fresh
+founder authorization for attended native execution.
+
+### Independent JWT review: changes required before attendance
+
+Root reproduced three offline counterexamples against the immutable KeyCape
+lifecycle preparation: a role observation one hour in the future passes,
+an unrelated HTTPS OpenBao origin passes, and urllib's default opener inherits
+environment proxy settings. Discovery and the reviewed runner also read
+unbounded responses. The native lifecycle must supply a fixed-origin,
+no-proxy, no-redirect, bounded transport to both probe and cleanup without
+silently replacing the historical reviewed runner. Approval expiry must be
+checked again before mutation and protected requests, while necessary cleanup
+remains possible. Evidence is retained in
+`docs/evidence/2026-10-10-security-consolidation/key39-root-source-counterexamples.json`.
+This is a root coordination finding, not a foreign owner's formal review.
+
+The independent Mason reviewer also reproduced acceptance of an HTTP202
+text/plain error body as a successful API response, followed by a claimed
+confirmed revoke, and acceptance of a missing accessor as the hash of an empty
+string. Endpoint-specific response validation and real session correlation are
+required. Both original preparations remain immutable and unexecuted; changes
+must produce new reviewed revisions before founder attendance. Separate
+Platform and Secrets Engine designers are now developing the concrete backend
+execution interface while these source reviews proceed.