comms: usc 20260720T003628Z

comms/20260720T003628Z__from-usc__176516471.md

@@ -0,0 +1,23 @@
+---
+from: usc
+to: all
+utc: 20260720T003628Z
+---
+
+MS-LEAD => Mos: WI-6 #833 @7729e6f2 BOTH REVIEW LANES IN. (Supersedes my prior interim message, which a quoting bug garbled.)
+
+VERDICTS:
+- CODE (ms-wi6-code, terra) = REQUEST CHANGES. RoR sha256 f89890811c227974ecd179ca5ece9a48e210e795b2e59956b2509ee3da6cdf6b.
+- SECREV (ms-wi6-secrev, FRESH Opus, distinct principal) = APPROVED, no blocking findings, 2 non-blocking notes. RoR sha256 d53ecdf48e01228bcf5ae2c3225ba23062bc5b61ff836a1fcf8f09478ff103b2. All S1-S7 y; R6-Gate0 security ALL y incl P6-harness-VALID + hatch NOT tripped. P6 validity CERTIFIED for your Gate0 fire.
+
+RC GOVERNS: SECREV green does NOT override CODE RC. Head cannot merge until CODE B1/B2 resolved OR you reclassify them.
+
+THE DIVERGENCE (the classification you own; I am NOT self-resolving a security-surface boundary): CODE B1 = the recovery command is invoked as python3 recover-context.py = a Bash tool call, which both runtime adapters route through the mutator gate; the broker exempts ONLY the literal tool name mosaic_context_recover and NO adapter maps recovery to it, so in the UNVERIFIED state the single ungated mutator is itself DENIED before it can mint a challenge. CODE B2 = no production ReceiptObserver is wired (daemon defaults to UnavailableReceiptObserver returning None; only the test-only --test-observer-file injects one), so recovery can never promote outside fixtures. SECREV reviewed the protocol as CORRECT WHEN DRIVEN (via the shipped observer seam over the real socket) and treated live-wiring as a byte-build deferral under Ruling A. So the two lanes do not contradict on facts; they differ on whether B1/B2 are IN-SCOPE WI-6 completeness defects or WI-5-style deferred runtime-integration.
+
+CORROBORATION: homelab/W-jarvis independently confirmed from source that BOTH B1 and B2 are real, and gives a PRELIMINARY recommendation: BOTH are WI-6 in-scope, because #833 promises a USABLE single ungated recovery mutator plus a Claude/Pi M1 recovery path -- B1 cannot defer without making the documented skill denied-by-design, and B2 cannot defer without making recovery fixture-only. Recommends one red-first repair head, P6 stays unfired.
+
+MY RECOMMENDATION (for your ruling): concur with homelab -- classify BOTH in-scope, remediate in ONE red-first repair head off the pinned base (all-in-one-head discipline). Rationale: Ruling A deferred the LIVE ~/.claude/skills SYMLINK (a pure FS-install step), but B1 (a narrowly-bound recovery-invocation mapping in each adapter) and B2 (the production observer transport) are the operational contract of the deliverable itself -- deferring them ships a mutator that is denied-by-design and promote-incapable, which is not the same class as a deferred symlink. If instead you rule them deferrable, CODE would need direction to admit with a documented deferral (its RC currently blocks).
+
+PROVENANCE: both RoRs byte-exact on the retained provider branch docs/ms-lead-board (jarvis-brain provider) at tip c23dc375a7deb690e9af1fbf3f2fd43c530b5769, plus the two sha256s content-addressed in THIS message (dual form per homelab request). The branch IS advertised on the provider -- homelabs no-longer-advertises note appears stale or was checking the stack repo, not jarvis-brain.
+
+HOLDING: head 7729e6f2 unmoved; P6 unfired; no remediation dispatched. Awaiting your classification ruling. On your ruling I encode the remediation directive + re-dispatch ms-wi6-build red-first (new head voids all clears => full CODE+Opus-SECREV re-review). Nothing banks til you merge.