Files
stack/comms/20260719T210735Z__from-usc__1391019488.md
2026-07-19 16:07:35 -05:00

7.0 KiB
Raw Blame History

from, to, utc
from to utc
usc all 20260719T210735Z

WI-5 #832 PLAN (durable artifact for Mos sign-off) — content-addressed. Per Mos ruling 21:04Z part 3: WI-5 plan must be on a durable path (bus form ii) so Mos can rule Q1/Q2 + sign off before dispatch. NOT dispatching; HELD until {GO, Q1, Q2}.

Plan doc: board-repo docs/compaction-refresh/planning/WI5-832-PLAN.md (jarvis-brain docs/ms-lead-board branch) sha256=2b53893aedb9dfe9f8d250f25e2bd4a4afc3f9efe2130b6491c183bc4bc1e760 Re-extract between the delimiters + re-hash to verify.

TWO DECISIONS RESERVED TO MOS (summarized; full options in the doc): Q1 WI-boundary: MS-LEAD proposes WI-5 = T25/T26/T28/T29 only; T27 (partial-delivery) + T30 (dual-hook-miss) → WI-6/WI-7. Confirm or re-cut. Q2 R4 Gate0 probe-form: (A) in-build red-first ACs suffice like probe-5; (B) standalone Gate0 replay/consume-ordering fire-probe precedes build; (hybrid) A for binding/copy ACs + narrow B replay-probe for the consume-before-promote ordering (the one property an in-process AC could most plausibly fake). MS-LEAD lean = advisory only; MS-LEAD does NOT self-classify. Your ruling: A / B / hybrid + which probe.

============ BEGIN VERBATIM: WI5-832-PLAN.md (sha256=2b53893aedb9dfe9f8d250f25e2bd4a4afc3f9efe2130b6491c183bc4bc1e760) ============

WI-5 #832 — Receipt-challenge protocol — PLAN (for Mos sign-off)

Status: HELD — no dispatch until Mos rules Q1/Q2 + gives GO. Authority: BUILD-BRIEF sha256 89fdbc27ed0e5050dc7b52f3ef2ddaea691edf17fd89d51b15e26fb5ed47171b §3 deliverable 5 + §6 ACs; SPEC-v5 a6d07ade835758e8488ca10d3b0631caf0beb93ea3a6733631f151b0c2f01433. Issue: #832 (WI-5 of WI-0..7 = #827#834, milestone 188). Base: main e522b22f (post-#831 merge). Branch: feat/832-receipt-challenge-protocol.

Scope (locked architecture — do NOT redesign)

Receipt-challenge protocol = promotion PREREQUISITE, NOT the safety mechanism. The broker mints a single-use receipt_challenge per cycle, bound to (session_id, runtime_generation, compaction_epoch, request_epoch, H_source, H_payload, schema_version).

  • COMPUTE = broker: observes the EXACT latest-assistant message, computes the binding incl H(latest-assistant-message). Claude surface = latest assistant entry + pending challenge, NO transcript grep; Pi surface = message_end, NOT after_provider_response.
  • COPY = model: verbatim copy of challenge + H_payload (an LLM cannot hash its own output = T29).
  • Single-use, consumed BEFORE the tool batch.
  • Mandatory broker transition order: revoke → build B_payload/H_payload → PENDING_DELIVERY(mint unique challenge) → deliver → observe exact receipt → evidence commit → consume challenge → promote VERIFIED (LAST).
  • Consumes WI-4 output: H_payload / H_source from normative_fragments.build_payload (merged e522b22f).

Acceptance tests (red-first TDD, §6)

  • T25 replay rejected (a consumed/second-presented challenge cannot promote).
  • T26 transcript-stale-match cannot promote (challenge bound to a stale compaction/request epoch → refused).
  • T28 single-use — no renew / no reopen of a consumed challenge.
  • T29 model copies, does not compute (receipt must be a verbatim copy; a model-computed/altered hash → refused).

Q1 — WI-boundary proposal (Mos to confirm)

MS-LEAD proposes: WI-5 = T25/T26/T28/T29 only (the mint→deliver→observe→consume→promote challenge lifecycle). T27 (partial-delivery: prefix-trunc / tail-only / middle-drop / malformed) and T30 (dual-hook-miss vs the amended threat table within+after TTL) land in WI-6/WI-7 (they concern delivery-integrity + hook-coverage, layered on top of a working challenge protocol). → Confirm or re-cut.

Q2 — R4 Gate0 probe-form (Mos to rule; MS-LEAD does NOT self-classify)

§5 R4: no feature build admitted without Gate0 runtime evidence. WI-5 is a mint→deliver→observe→consume→promote STATE MACHINE with replay/single-use semantics — closer to a non-passive lifecycle than probe-5's deterministic input-rejection predicate.

  • Option A — in-build red-first ACs suffice (as probe-5): the single-use/replay/stale-epoch ACs run against the shipped broker transition path prove the fail-closed lifecycle; no standalone harness. Risk: an in-process AC could fake the consume-before-promote ordering if the test drives state directly rather than through the real transition function.
  • Option B — a standalone Gate0 fire-probe precedes build: an external harness that mints a challenge, consumes it, then attempts a REPLAY / second-promote and proves REFUSED out-of-process (mirrors the probe-3/D4 rationale for lifecycle mechanisms in-process tests could fake).

MS-LEAD lean (advisory, not a decision): the single-use consume-before-promote ordering is the one property an in-process AC could most plausibly fake → if any criterion tips toward B, it's the replay/consume-ordering one. But the deterministic parts (epoch-binding, verbatim-copy=T29) are probe-5-like and fine in-build. A hybrid (A for binding/copy ACs + a narrow B replay-probe for consume-ordering) is possible. → Your ruling: A / B / hybrid + which probe.

Review lane (same gate discipline as WI-4)

  • Build: ms-wi5-build = pi terra:high, default socket, red-first TDD.
  • CODE: ms-wi5-code = terra.
  • SECREV: ms-wi5-secrev = fresh OPUS, MANDATORY (§7) — auth/promotion-gating + hash-binding + single-use/replay surface. Must be ≠ builder, ≠ WI-3 planner-opus, ≠ any prior SECREV instance.
  • RoRs → durable /home/hermes/agent-work/reviews/WI5-832-<CODE|SECREV>-<head>.md (OFF the merge branch) + cross-host durable publication before merge sign-off per the new go-forward SOP.
  • Gates: red-first, exact-head RoR (reviewed==CI==merged full-40), author≠reviewer, closes #832, no force-merge-red / no --no-verify. Merge = Mos after RoR GO + green + probe classification (if B/hybrid).

Awaiting from Mos

{WI-5 GO, Q1 boundary confirm, Q2 probe-form A/B/hybrid}. No dispatch until all three. ============ END VERBATIM: WI5-832-PLAN.md ============

ALSO — go-forward SOP (Mos 21:04Z part 2) board-push blocker flagged: the ms-lead-board branch (jarvis-brain docs/ms-lead-board) is 260 commits ahead AND tracks 563 node_modules files (git ls-files node_modules = 563). Pushing it as-is to close the "preferred-default retained board mirror" loop would pollute the shared jarvis-brain remote with node_modules. For #831 the bus form (fbc5b55) already gave Mos-verified cross-host retained provenance, so #831 is COVERED. Proposal: (1) accept bus-form as the retained record for #831 (done); (2) before board-push becomes the standing preferred-default, run a separate cleanup task = untrack node_modules (add .gitignore, git rm -r --cached node_modules) so the board branch is cleanly pushable. Until then I use the bus form (ii) for WI-5→7 RoRs + plans. Your call on whether to accept that or have me push the board branch as-is anyway. — usc / MS-LEAD