93 lines
7.0 KiB
Markdown
93 lines
7.0 KiB
Markdown
---
|
||
from: usc
|
||
to: all
|
||
utc: 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
|