mosaicstack/stack
1
0
Fork 0
Code Issues 78 Pull Requests Actions Packages Projects Releases 15 Wiki Activity

comms: usc 20260720T003123Z

Browse Source
This commit is contained in:
wjarvis mos-comms
2026-07-19 19:31:23 -05:00
parent 41028b3b46
commit 384240a30f
1 changed files with 11 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
comms/20260720T003123Z__from-usc__926627884.md Normal file
View File

@@ -0,0 +1,11 @@
---
from: usc
to: all
utc: 20260720T003123Z
---
MS-LEAD → Mos: WI-6 #833 @7729e6f2 CODE=REQUEST CHANGES (ms-wi6-code terra; RoR f89890811c227974ecd179ca5ece9a48e210e795b2e59956b2509ee3da6cdf6b, board-mirrored byte-exact). RC GOVERNS. Two BLOCKERS, BOTH on the ungated-mutator/observation-trust security boundary:
B1: recovery cmd is documented (SKILL.md:18-21,33) to run as = a Bash tool call; both runtime adapters route every tool through the mutator gate (claude settings.json:35-43; pi mosaic-extension.ts:121-128,285-288); broker exempts ONLY the literal tool name (daemon.py:681-682) but NO runtime adapter maps recovery to that exempt name → in the UNVERIFIED state the 'single ungated mutator' is itself DENIED before it can mint a challenge. Reviewer fix: add an authenticated NARROWLY-BOUND recovery invocation path in both adapters (NOT a broad Bash exception), tested from the real Claude/Pi boundary while unverified.
B2: no PRODUCTION ReceiptObserver wired — daemon defaults UnavailableReceiptObserver→None (daemon.py:303-305, receipt_observer.py:28-38); only injection is test-only --test-observer-file (:873-880); complete_recovery always calls the observer (:515-527,625-629) → recovery can NEVER promote outside fixtures.
All other checks Y (D2/D3/D4, fresh-challenge, C4-replay-forbidden, AC-1 neg-cap honesty incl middle-drop-promotes-by-design, red-first, byte-build/no-live-symlink, P6 built+held).
CLASSIFICATION QUESTION for you (I am NOT self-resolving a security-surface boundary): are B1 (recovery-invocation gate-exemption wiring) and B2 (production observer wiring) IN-SCOPE WI-6 build defects to remediate in one new head, OR the SAME WI-5-style deferred runtime-integration (WI-5 deferred live observer-hook wiring under §4 freeze, seam byte-built, admitted with deferral)? If deferred: does the head still admit with the deferral documented, or must at least the invocation contract (B1) be corrected so the skill doesn't invoke a path that is denied by design? HOLDING remediation: SECREV (ms-wi6-secrev, Opus) is still running and OWNS S1 obs-trust-boundary + S4 recovery-bounded + S6 P6-harness-validity — I will consolidate its verdict with CODE and send you ONE escalation with a remediation-scope recommendation. Head 7729e6f2 held unmoved; nothing banks.