immune-brain 5.1.0 → 5.1.2

package/plugins/immune-brain/dist/docs/reference/planning-quality-gate.md

@@ -25,7 +25,7 @@ Apply the gate when the task touches one or more of these surfaces:
 - **TaskIntent decomposition**: use Technical Design boundaries as one retain/split criterion with outcome, Verification, dependency, risk, rollback, compatibility, and authority. Split a successor TaskIntent only when a service, state-machine owner, migration, independently promotable layer, or sequence dependency needs independent verification, rollback, authorization, or settlement. A TaskIntent should normally change one primary trust-boundary invariant, but traversing several boundaries or updating both sides of one authority chain does not itself require a split. Split independently verifiable, reversible, authorizable, migratable, or settleable trust invariants. Keep multiple trust-boundary changes together only for one atomic security outcome whose split would create an unsafe or unusable intermediate state, and record that rationale in the Spec. Treat this as Planner judgment rather than a schema field or Enrollment counting rule. Do not split merely because the design names several layers, files, or services, and do not revive prose Plan authority. For a multi-TaskIntent Initiative only, require each Slice to state what is observable and verifiable when that Slice alone has landed, and no acceptance may require another unfinished Slice's work to pass; a Slice with no such statement is a horizontal layer slice and is re-cut. Record the exception for a wide mechanical refactor whose blast radius prevents any green vertical slice, with the rationale and a final integrate-and-verify Slice that the batches block.
 - **Mermaid intent**: use Mermaid only when it clarifies structure, sequence, data flow, or state transitions; it is not a universal gate or a second source of truth. Medium/High risk Specs record `**Diagram decision**: required|not_required` and a non-empty `**Diagram reason**:`. A `required` decision must include Mermaid; `not_required` explains why prose is sufficient. Low-risk Specs omit the empty ceremony and record neither field.
 - **Design Conformance**: before final closure, require Spec-to-implementation evidence. A local implementation mismatch routes to `rework`; a structural or intended design change routes to `replan` through Planner. QA cannot silently approve a design change.
-- **Brainstorm traceability**: ensure every `BR-*` item listed in `Brainstorm manifest` is mapped in `Brainstorm Trace`. Every Spec decision and every acceptance names exactly one source — an upstream `BR-*` ID, repository evidence, or a delegated technical choice — with or without an upstream manifest, and a user-owned decision that names no source is a defect the Planner removes or returns for clarification.
+- **Brainstorm traceability**: ensure every `BR-*` item listed in `Brainstorm manifest` is mapped in `Brainstorm Trace`. Every Spec decision and every acceptance names exactly one source — an upstream `BR-*` ID, repository evidence, or a delegated technical choice — with or without an upstream manifest, and a user-owned decision that names no source is a defect the Planner removes or returns for clarification. A Spec for work with a user-observable change has a `User scenarios` section; each scenario keeps its upstream `BR-SCN-<n>` ID, or on direct entry is confirmed in clarification and recorded as Spec-local `SCN-<n>`, is tagged `automated` with at least one acceptance ID or `manual` with the reason it cannot be automated, and the mapping is one-way. In a multi-TaskIntent Initiative a scenario belongs to exactly one Slice, the one that first makes it observable. `BR-SCN-*` items fall under the existing handoff completeness check, a scenario with no source is a defect, and `no user-visible change` requires a recorded reason.
 - **roadmap information preservation**: for large or multi-phase work, distinguish the Roadmap from the current executable slice, preserve deferred phase goals, open questions, promotion criteria, and candidate next Plans.
 - **executable-slice discipline**: the Plan promises only the current executable slice — one coherent set of Steps sharing acceptance, review, rollback, and authority boundaries. Future-phase logic, speculative architecture, and unvalidated assumptions belong in the Roadmap or as explicitly Deferred items, never as active Steps. Do not enforce a fixed Step count: multiple Steps inside one shared boundary are fine, and a single Step that smuggles in unvalidated future architecture is still over-planning.
 - **Plan boundary cohesion**: treat Plan granularity separately from Step and Roadmap Phase granularity. Confirm the current Plan contains one coherent executable slice and explain why its outcome, authority, risk, verification, review, and rollback boundaries belong together. Promote an independent boundary into a sequential Plan instead of hiding it inside a large Step. One Phase may therefore span multiple Plans.

package/plugins/immune-brain/dist/docs/reference/subagent-dispatch-protocol.md

@@ -118,9 +118,11 @@ Agent defaults to the current Pi session model. Only an explicit Parent requirem
 selects another Pi-configured model through host-native `Agent.model`. Kernel
 Review returns a complete foreground `Agent` envelope with empty `name`, `model`,
 `thinking`, `resume`, and `schedule` fields so Pi Host resolves the Review agent
-configuration. The Parent may use any compatible foreground Agent adapter and
-submits the resulting structured verdict directly; lifecycle event matching is
-not part of the local authority contract.
+configuration. A compatible foreground Agent adapter must expose the reserved
+dispatch and its paired result to the host's receipt observer. The Parent submits
+without a verdict to apply those observed bytes; a provided verdict must match
+the correlated receipt. Dispatch/result correlation is part of the local authority
+contract.
 
 ## Pi Agent Invocation
 
@@ -144,12 +146,12 @@ Pi `Agent` has no `readonly` parameter; the empty tool policy, child type, and p
 
 1. Planning、repository exploration、specialist advisory Review 和 work probe 必须 foreground 执行。Parent launches one child at a time，消费 direct terminal result，并在每个结果后 re-evaluates the remaining dispatch budget；不得把多个 foreground Agent 假定为并发 batch。
 2. 普通 interactive advisory 不建立 acknowledgement deadline、后台 progress UI、completion push 或 late-notification recovery。活跃 Agent 使用 Pi 原生 foreground Tool row、host cancellation 和 steer。Footer 保持严格为空；No defined-value `setStatus` call is allowed。
-3. Kernel Assurance runs in the foreground Tool call. `advance_assurance` awaits deterministic QA, emits bounded native updates, and returns `review_ready` with foreground `Agent` parameters. The Parent invokes a reviewer, reads its direct result, and passes the structured verdict to `submit_review`. `request_authorization` is the only literal-user confirmation path. AbortSignal cancellation before authority commit and snapshot/CAS revalidation remain mandatory.
+3. Kernel Assurance runs in the foreground Tool call. `advance_assurance` awaits deterministic QA, emits bounded native updates, and returns `review_ready` with foreground `Agent` parameters. The Parent invokes a reviewer, then calls `submit_review`: omitting the verdict applies the host-observed reviewer receipt, or the Parent may relay the reviewer's structured verdict for fingerprint comparison. `request_authorization` is the only literal-user confirmation path. AbortSignal cancellation before authority commit and snapshot/CAS revalidation remain mandatory.
 4. Kernel Assurance chat uses native Tool rendering only. It does not publish completion messages or wake a later parent turn; the direct Tool result is the continuation boundary. `awaiting_user` remains valid until the host-built authorization operation is confirmed and the immutable snapshot is revalidated.
 5. Child 不得再次派发 child，nested delegation 一律禁止。Parent 保留综合与最终判断责任。
 6. Kernel authority Review 对每个 immutable snapshot 恰好一个 primary reviewer，turn 预算按 workload 缩放（Quick 12 / Standard 16 / Heavy 24），并使用该 snapshot 对应的 Quick/Standard/Heavy 执行档位；不存在从 initial dispatch 起算的单一端到端总预算。Reviewer 必须先验证 immutable v5 manifest 的 `base_head`、`review_commit`、单一 parent、`review_tree` 与 `manifest_digest`，再用只读 Git 命令从 synthetic revision 获取源码；manifest 只有 metadata，不复制 source bytes，也不枚举 neighborhood files。审查只围绕 acceptance assertions 与 `changed_paths`，未变更路径只有在 acceptance、changed caller 或同一 state machine 直接需要时按需读取并注明理由；Reviewer 不探索无关 repository paths。对 settlement-class change，Reviewer 必须先枚举 immutable revision 内每条 terminal、cancellation、timeout 与 race path，再对全部路径给出判断；finding summary 必须以受影响路径开头。每个 acceptance 的执行结果已由 deterministic QA 在 review 前验证并内嵌于 manifest 的 `outcomes` 字段（acceptance_id -> {status, summary}）；Reviewer 不得重跑 descriptor，也不得把本地没有测试运行当作 finding——Review 只审 revision provenance、代码正确性、回归、安全与缺失测试。除该 reviewer 外，同一触发点最多两个相互独立的 advisory/discovery children；它们只能并行读，不能写 workflow state、关闭 QA 或产生 authority。
 7. Foreground assurance never sleeps, polls, or schedules a completion callback. One Tool call owns QA; one Parent turn obtains and submits the reviewer verdict. User authorization is reserved for unresolved decisions, explicit stop, and breaking Intent revisions; no risk tier adds a generic final confirmation.
-8. `submit_review` validates the verdict contract, task identity, immutable snapshot digest, and fresh record/Intent/workspace/diff revisions before applying Review authority. Malformed verdicts are retryable without rebuilding evidence. Stale verdicts leave the TaskRecord unchanged and release the stale reservation. Local execution trusts the Parent to relay the reviewer verdict and does not require Agent lifecycle receipts.
+8. `submit_review` validates the verdict contract, task identity, immutable snapshot digest, and fresh record/Intent/workspace/diff revisions before applying Review authority. An omitted verdict applies the host-observed reviewer receipt bytes (ADR 0017); a relayed verdict must fingerprint-match the observed receipt. Malformed verdicts are retryable without rebuilding evidence. Stale verdicts leave the TaskRecord unchanged and release the stale reservation. Each host adapter observes its own reviewer receipt edge — the Claude host via the dispatch hook log, the Pi host via the generic `Agent` tool events correlated by the reserved prompt digest — and a submission with no recorded receipt fails closed.
 9. The assurance Tool checks the immutable snapshot before each phase and returns a terminal structured state directly: `cancelled`, `rework`, `review_ready`, `awaiting_user`, `blocked`, or `settlement_unknown`. The commit boundary is non-cancellable. No silent task, status timer, completion notification, or result retrieval path is permitted.
 
 ## Result Synthesis
@@ -165,6 +167,6 @@ Parent workflow role 必须：
 
 普通 advisory/discovery 的每次启动都消耗一个 candidate budget slot；失败、取消、timeout 或 result_untrusted 均丢弃该输出且不得自动重试。Parent 仅在剩余候选仍独立有用且 evidence budget 仍需要时继续，否则转 solo/fail-closed fallback，并记录 `dispatch_failed` 或 `child_timeout`。Read-only eligibility 与 Pi 的 one-foreground-child 调度限制是两回事：只读调查可同时存在多个待派发候选，但实际执行仍逐个 foreground child 串行消费，不得把多个 foreground Agent 假定为并发 batch。该规则不改变 Kernel authority Review 的显式恢复协议。Child 永远不获得实现、Plan write、workflow mutation 或 QA closure authority。
 
-If Kernel Review dispatch fails, the Parent does not call `submit_review`; the existing Review reservation and immutable evidence remain available for a later foreground retry. A malformed verdict may be corrected and resubmitted. A stale snapshot, explicit release, successful settlement, or session shutdown removes the reservation and evidence. There is no retry counter, dispatch receipt state machine, or provider-specific recovery path.
+If Kernel Review dispatch fails, the Parent does not call `submit_review`; the existing Review reservation and immutable evidence remain available for a later foreground retry. A malformed verdict may be corrected and resubmitted. A stale snapshot, explicit release, successful settlement, or session shutdown removes the reservation and evidence. There is no retry counter or provider-specific recovery path; the only dispatch record is the receipt a host adapter binds to the reservation for receipt-bound submission.
 
 This protocol is provider- and host-adapter-agnostic for local execution.

package/plugins/immune-brain/dist/imm-brainstorm.md

@@ -95,8 +95,8 @@ reflected without change. If the summary introduces or changes a
 decision, ask for explicit confirmation of only that decision delta
 and block Planner handoff until it is answered. Agent judgment alone never
 confirms a proposed direction or scope. Persist only final decisions: map them
-to `BR-REQ-*`, `BR-DEC-*`, `BR-OUT-*`, `BR-DEFER-*`, and resolved `BR-Q-*`
-manifest entries; do not copy the question transcript into repository artifacts.
+to `BR-REQ-*`, `BR-DEC-*`, `BR-OUT-*`, `BR-DEFER-*`, resolved `BR-Q-*`,
+and `BR-SCN-*` manifest entries; do not copy the question transcript into repository artifacts.
 
 ## Explicit exhaustive interrogation
 
@@ -119,7 +119,7 @@ empty, or report remaining blocked/open nodes if the user stops early.
 - **Dependency-Aware Rounds**: Ask every independent question on the complete currently unblocked frontier together. Ask fewer questions only because dependencies keep downstream branches blocked, never because of an arbitrary question budget.
 - **Read-only by default**: Inspect context and summarize the problem. do not implement inside this skill.
 - **Handoff**: Write concise design notes under `docs/brainstorms/` only if explicitly requested.
-- **Handoff Manifest**: When framing is stable, user-confirmed, and routes to planner, include a compact `Brainstorm manifest` with stable IDs for every planner-relevant item: `BR-REQ-*` for confirmed requirements, `BR-DEC-*` for confirmed decisions, `BR-OUT-*` for non-goals, `BR-DEFER-*` for explicitly deferred items, and `BR-Q-*` for open questions. The manifest is the closed-world handoff; the planner must account for every ID instead of relying on prose memory.
+- **Handoff Manifest**: When framing is stable, user-confirmed, and routes to planner, include a compact `Brainstorm manifest` with stable IDs for every planner-relevant item: `BR-REQ-*` for confirmed requirements, `BR-DEC-*` for confirmed decisions, `BR-OUT-*` for non-goals, `BR-DEFER-*` for explicitly deferred items, `BR-Q-*` for open questions, and `BR-SCN-*` for a confirmed user scenario. A `BR-SCN-*` item has exactly `Actor`, `Given`, `When`, `Then`, written in English. `Then` states a result the actor observes directly — command output, a file, an Issue or UI state — and never an internal state or a test file name. Record a scenario only for framing that changes user-observable behavior: framing without a user-observable change gets no invented scenario. The manifest is the closed-world handoff; the planner must account for every ID instead of relying on prose memory.
 - **Default Next Route**: Route to `imm-planner` when the material frontier is empty, no required fact blocks the handoff, and every material user decision is settled by a direct requirement, explicit answer, or adopted recommendation. An unchanged final summary is a correction window, not another gate. If Brainstorm introduces a new decision, ask for that delta and do not name `imm-planner` as the current next skill.
 - **Subagents**: Only when optional research is needed, read Research Dispatch and its shared dispatch reference. Default to inline evidence gathering; do not load dispatch instructions merely because Brainstorm was invoked.
 - **Rejected Decision Evidence**: Use on-demand rejected-decision evidence instead of a global preflight. When a live branch resembles a rejected decision, resolve its recorded reason and optional `reconsider_if` conditions through code/docs inspection before asking the user. Treat each `reconsider_if` list item as an independently sufficient trigger (OR semantics): if available evidence satisfies none, keep the rejection as a current constraint or non-goal without re-litigation; if evidence satisfies one, reopen the decision and cite the condition plus changed evidence; if a condition cannot be resolved, ask only for that concrete missing fact. When `reconsider_if` is absent, preserve the backwards-compatible "what has changed?" fallback after inspection. When `rejection_reason` is absent, inspect an explicit rejection-reason section in the body; if no reason exists, report the metadata gap without inventing a reason or reconsideration condition.
@@ -150,7 +150,7 @@ Agreement becomes framing evidence. Disagreement becomes decision criteria or an
 
 **Dispatch behavior:** Use Pi native `Explore` subagents (`subagent_type: "Explore"`). Each prompt must state a bounded read-only scope and returns a structured summary (affected files, conventions found, risks). The parent brainstorm agent merges summaries before producing the output artifact. Research subagents do not write files, specs, plans, or `.imm/` state.
 
-**Manifest mapping:** Repo-local runtimes use `imm_core.brainstorm_research` to keep research probes host-bound and manifest-oriented. Every child summary that affects planning must map to a Brainstorm manifest ID: `BR-REQ-*`, `BR-DEC-*`, `BR-OUT-*`, `BR-DEFER-*`, or `BR-Q-*`. Any unmapped or unresolved research question becomes a `BR-Q-*`; open `BR-Q-*` items block planner handoff.
+**Manifest mapping:** Repo-local runtimes use `imm_core.brainstorm_research` to keep research probes host-bound and manifest-oriented. Every child summary that affects planning must map to a Brainstorm manifest ID: `BR-REQ-*`, `BR-DEC-*`, `BR-OUT-*`, `BR-DEFER-*`, `BR-Q-*`, or `BR-SCN-*`. Any unmapped or unresolved research question becomes a `BR-Q-*`; open `BR-Q-*` items block planner handoff.
 
 **Failure handling:** If research dispatch is unavailable or fails, continue with solo inline investigation. Record the fallback reason per the shared protocol.
 

package/plugins/immune-brain/dist/imm-planner.md

@@ -175,7 +175,10 @@ and clarification. It does not apply to Enrolled Intent Revision.
 Before authoring a TaskIntent, trace each expected behavior from its public or
 runtime entry point through existing imports and callers to the highest focused
 behavioral tests. Include generated or packaged mirrors and every owner of the
-same state machine. Record the concrete paths in the Spec's discovery evidence when the work is
+same state machine. For configuration changes, follow deployment copies and
+integration assertions; for runtime changes, include the generated Claude bundle
+when it inlines that runtime and the required release changeset. Resolve these
+paths from the build and test references before Enrollment. Record the concrete paths in the Spec's discovery evidence when the work is
 complex; simple TaskIntent-only work records them in `scope_hint`.
 Do not author while a referenced sibling is unresolved. Use the smallest
 coherent module directory for ordinary implementation scope. Keep Kernel,
@@ -234,14 +237,21 @@ confirm a name, slug, Child, or dependency that had not yet been shown.
 
 Once decomposition is complete, present one review table containing the Parent
 result and every Child's stable Slice ID, result, scope boundary, risk, blockers,
-and proposed execution order. Ask one focused question: whether the coverage,
+each Slice's scenario IDs or its exemption with the reason, and proposed execution order. Ask one focused question: whether the coverage,
 granularity, and dependencies are correct. Recommend the complete current
 frontier so the user can approve it in one response. Before that approval,
 perform zero GitHub mutations. A partial or progressively disclosed issue set is
 not eligible for publication.
 
 After approval, author, stage, and validate every TaskIntent in the decomposition
-with `valid: true` and `enrollment_ready: true`. Resolve `../bin/imm-tracker` from this packaged contract; do not assume a bare command is on `PATH`. Submit the entire approved set once through
+with `valid: true` and `enrollment_ready: true`. Before handoff, compare the
+scopes by machine: run `imm-kernel intent overlap <path> <path>... --json` over
+every TaskIntent of the Initiative, with one `--blocked-by <task-id>=<task-id>,...`
+per dependency, and report its `overlaps` (each shared entry pair) and
+`parallel_groups`. Parallel recommendations follow that output, which uses the
+same projection as the Batch Plan. Never write "disjoint" or "verified" for
+scopes by hand; when the output shows an overlap the Slices run serially unless
+a revised `scope_hint` removes it. Resolve `../bin/imm-tracker` from this packaged contract; do not assume a bare command is on `PATH`. Submit the entire approved set once through
 `imm-tracker publish-initiative --stdin --json`. Its input contains the confirmed
 Initiative slug and goal, Parent projection, and every Child's `slice_id`,
 canonical TaskIntent path, bounded public `acceptance` summaries, and public
@@ -260,7 +270,27 @@ published Child; future checklist-only Slices are not allowed in the batch.
 Each Child must provide public `acceptance` entries with `id` and a 1-500
 character `summary`. Their IDs must match every canonical TaskIntent acceptance
 ID exactly once. Canonical assertion prose is authority evidence and must never
-be copied into public GitHub projection. Each Child projection requires
+be copied into public GitHub projection. Each Child may also provide an optional
+`scenarios` array. Omitting it, or giving an empty array, renders no
+`## User scenarios` section for that Child and contributes nothing to the Parent;
+when no Task supplies scenarios the Parent and every Child body are unchanged.
+A scenario is public projection of one user-observable result: `id`
+(`BR-SCN-<n>` or `SCN-<n>`), `actor`, `given`, `when`, `then`, and `mode`.
+`automated` maps to one or more of that Task's canonical acceptance IDs and
+renders as a plain bullet; `manual` requires `manual_reason`, may name no
+acceptance ID, and renders as an unchecked task-list item that also shows the
+reason. The Parent derives one plain bullet per scenario (its ID, owning Slice
+ID, mode, When, and Then) and never a checkbox. Scenarios never widen TaskIntent
+scope or authority. The tracker rejects the whole batch before any remote write
+when a scenario lacks a field, has an id matching neither form, repeats an id
+within the Initiative, is automated with no acceptance ID, names an acceptance ID
+its TaskIntent lacks, or is manual without `manual_reason`. Every scenario list
+item starts at the beginning of its line, so no metadata comment precedes the
+marker. Each Child's ownership marker block also carries one
+`<!-- immune-brain:scenarios=<percent-encoded JSON> -->` per Task holding all of
+its scenarios verbatim; an amendment reads historical scenarios only from that
+marker, never parses the visible section, and treats a Child without it as
+having no scenarios. Each Child projection requires
 `title` (1-60 characters), the short Slice display title, and may contain
 `result`, `current_behavior`,
 `desired_behavior`, `key_interfaces`, `verification`, `blocked_by` Task IDs,
@@ -482,6 +512,12 @@ when breaking, `approve_breaking_intent_revision` with the complete next intent.
 The native gate is the single user decision for a breaking revision; candidate
 preparation does not apply the revision or authorize expanded execution.
 
+A revision is warranted only when the goal, the `scope_hint`, or a user-visible
+commitment changes. A finding whose defect lies inside the current goal and scope
+is ordinary rework for the Loop, not a revision request: decline to prepare one
+that only appends a single input case to an acceptance assertion. Acceptance
+states principles; enumeration of cases belongs in tests.
+
 ## Planning Rules
 
 - **Entry Contract**: Use when Spec/TaskIntent planning is needed. An already enrolled owner remains on its current Kernel authority and resumes only through explicit `imm-run`; a validated candidate still needs native Enrollment.
@@ -512,7 +548,7 @@ preparation does not apply the revision or authorize expanded execution.
   follows Enrolled Intent Revision.
 - **Review Mapping**: In-scope rework stays with the enrolled TaskIntent and explicit `imm-run` entry. Cross-scope findings become a Planner decision delta with concrete missing paths and verification evidence; do not create a successor prose Plan.
 - **Decision Provenance**: Every Spec decision and every acceptance names exactly one source: an upstream `BR-*` ID, repository evidence with a concrete path, or a delegated technical choice as defined by Clarification supplement. The rule applies with or without an upstream Brainstorm manifest, and the source does not have to be a `BR-DEC` item: Direct Planner entry and delegated technical choices stay legitimate sources. A user-owned decision — goal, user, scope, observable behavior, compatibility preference, risk acceptance, or success criterion — that names no source is a defect the Planner removes or returns for clarification under the existing Clarification supplement routes. Simple TaskIntent-only work satisfies the rule when each acceptance traces to the request text and adds no table.
-- **Brainstorm Manifest Mapping**: Record every upstream `BR-*` item in a Spec `Brainstorm Trace` when the work is complex, otherwise on the TaskIntent, mapped to acceptance, a captured decision, or an explicit reason for deferral or exclusion. Resolve every `BR-Q-*` item before handoff. Do not silently narrow confirmed framing.
+- **Brainstorm Manifest Mapping**: Record every upstream `BR-*` item in a Spec `Brainstorm Trace` when the work is complex, otherwise on the TaskIntent, mapped to acceptance, a captured decision, or an explicit reason for deferral or exclusion. Resolve every `BR-Q-*` item before handoff. Do not silently narrow confirmed framing. A Spec for work with a user-observable change has a `User scenarios` section. Each scenario keeps its upstream `BR-SCN-<n>` ID; on direct entry each scenario is confirmed in clarification and recorded as Spec-local `SCN-<n>` sourced to that confirmation, and a scenario with no source is a defect the Planner removes or returns for clarification. Each scenario is tagged `automated` with at least one acceptance ID, or `manual` with the reason it cannot be automated; a `manual` scenario may name no acceptance, and the mapping is one-way — an acceptance need not serve a scenario. In a multi-TaskIntent Initiative a scenario belongs to exactly one Slice, the one that first makes it observable, and an `automated` scenario maps only to that Slice's acceptance. `BR-SCN-*` items fall under the existing handoff completeness check like every other `BR-*` item. When the work has no user-observable change, record `no user-visible change` with a one-line reason — in the Spec for complex work, on the TaskIntent goal for simple work — write no scenario section, and `no user-visible change` requires a recorded reason.
 - **Handoff Completeness Check**: Before reporting a candidate as handoff-ready, confirm every upstream item and required phase is mapped exactly once, that required phases are delivered rather than excused by a reason, and that no confirmed outcome was conserved as a smaller deliverable. Reject a narrowed deliverable as a completeness failure; ask again only for a new material delta, never to reconfirm an unchanged clear request or an already-confirmed decision.
 - **Session Lifecycle Ownership**: The user chooses the current or a new session. Tokens, compactions, tool counts, elapsed time, and review rounds never trigger automatic session creation or termination. Recovery uses TaskRecord and the fresh Kernel projection.
 - **Subagents**: Only when optional research is needed, read Research Dispatch and its shared dispatch reference. Default to inline evidence gathering. Plan conditional reviewers such as `security-reviewer` only if their trigger surfaces are explicit; do not manufacture them.

package/plugins/immune-brain/dist/imm-run.md

@@ -10,7 +10,12 @@ This skill adheres to the **[BASELINE.md](BASELINE.md)**.
 ## Kernel Canary Routing and Authority
 
 Only explicit `imm-run` entry starts or resumes this loop. Ordinary host input
-stays host-native; it never resumes a Managed owner implicitly. Read the current
+stays host-native; it never resumes a Managed owner implicitly. While a
+non-terminal TaskRecord holds the workspace, both Hosts add a read-only notice
+to ordinary input (Pi `before_agent_start`, Claude Code `UserPromptSubmit`)
+naming the task, its next obligation and its scope: before committing or
+modifying files inside that scope, read `status` and tell the user the task is
+active and what it waits for. The notice resumes nothing. Read the current
 Host's `status` projection first and verify the exact active backend claim,
 TaskIntent, and TaskRecord. Invalid or contradictory projections fail closed. A
 candidate TaskIntent is not Enrollment authority.
@@ -100,6 +105,12 @@ Continue while the current projection has a valid action:
    accepted contract and answer with `refute_finding` bound to fresh QA evidence
    for that acceptance. Escalating a local heuristic a third time instead of
    choosing one of those two responses is the loop this step exists to break.
+   A finding whose defect lies inside the TaskIntent goal and `scope_hint` is
+   ordinary rework even when no acceptance names its exact case: fix the code,
+   add the test that pins the case, and dispose the finding. It is never a
+   reason to revise the Intent. Acceptance text states principles; enumeration
+   of specific inputs belongs in tests, so never append a single input case to
+   an acceptance assertion in order to close a finding.
 6. An unresolved decision pauses only dependent execution. On `awaiting_user`,
    invoke `request_authorization` directly before ending the turn; use the
    Decisions and Recovery route for its native-gate handling. End the turn if
@@ -197,7 +208,46 @@ Only children whose scopes are provably disjoint run together; a child whose sco
 overlaps an in-flight Lane waits until that Lane is integrated. Settled children
 integrate serially, and a parked child ends only itself and its dependents while a
 disjoint sibling keeps moving. A lost Lane parks as `batch_lane_lost`, and
-`qa_failure_limit` counts each child separately. A resume with a different
+`qa_failure_limit` counts each child separately. A completed settlement inside a
+Lane changes Kernel state only and writes nothing to the tracker: the coordinator
+closes the child's Issue after it integrates that child's commit, exactly once,
+and reports the attempt in `tracker_observations`. A parked or lost child is
+never integrated, so its Issue stays open; an explicit stop inside a Lane still
+projects `not planned` at once.
+
+The lane batch confirmation offers one opt-in choice, off by default: delegate
+to the coordinator the approval of each Lane child's breaking Intent revisions
+that stay inside that child's TaskIntent as authorized for the batch (ADR 0018).
+The answer is recorded on the batch record as `revision_delegation`; a batch
+confirmed without it behaves exactly as before, and the grant ends with that
+batch — a terminal, retired or later batch never uses it. When an integrated
+child's TaskIntent equals the last revision applied under that grant, the runner
+reseals `plan_digest` and records both digests in `reseals`, so later children
+continue without retiring the batch. Any other Intent change still fails closed
+as `plan_changed` and takes the ADR 0016 retirement path.
+
+Before a new lane batch provisions any Lane, the runner compares the Kernel
+contract identifiers (TaskRecord, tombstone, projection, store schema) of the
+coordinator's runtime with those of the runtime a Lane Executor loads — never the
+plugin version number — and refuses with `batch_runtime_contract_mismatch`,
+naming both sources, when they differ; a match adds no confirmation. A Lane whose
+state exists but whose contract the coordinator refuses to read parks as
+`batch_lane_contract_mismatch` with the original parse error, distinct from a
+missing Lane's `batch_lane_lost`.
+
+Inside a Lane, the Pi extension and the Claude Code `PreToolUse` hook refuse an
+`edit`/`write` (Claude: `Edit`, `Write`, `MultiEdit`, `NotebookEdit`) whose
+resolved target lies outside the Lane, naming the Lane path. A shell command is
+not intercepted; this is no bash sandbox. When a lane batch is re-entered with a
+dirty coordinator checkout, each dirty path is restored to HEAD only if every one
+of them is an unstaged modification or untracked file that a Lane of this batch
+changed (its bytes differ from that Lane's base) and whose bytes equal the Lane's,
+in its worktree or a Lane-branch commit. The read-only preflight only attributes;
+the runner restores after the batch is authorized. The bytes are
+backed up first under `.imm/state/batches/restores/`, and the backup is recorded
+in the batch record and report as `restores`. If any change has another origin,
+or is staged or deleted, no file is touched and the refusal names it; never
+stage such changes to get past the refusal. A resume with a different
 `max_parallel` is refused with `batch_parallel_mismatch`. A Lane holds no batch
 state and its Host session never re-enters the batch.
 
@@ -220,6 +270,7 @@ source directly rather than assuming the Host injected it into context:
 | `Lane Executor Host: <host>` | `claude-code` or `pi` | Every Lane's Executor Host is that Host. When the `lane-steward` did not report it available in a Lane, that Lane has no Executor Host; the Parent does not fall back to the other one. | The Parent's own Host type, else the other allowlisted Host |
 | `Lane Executor model: <model>` | a model identifier of the configured Executor Host | Passed to the Executor Host as `--model <model>` | The Executor Host's own default |
 | `Lane Executor effort: <level>` | a level the configured Executor Host accepts | Passed as `--effort <level>` to `claude-code` and as `--thinking <level>` to `pi` | The Executor Host's own default |
+| `Batch final verification: <command>; <command>` | plain commands without shell syntax or quoting, at most 8 | Passed as `final_verification` when a new lane batch starts and shown in its native confirmation; the runner runs them on the batch branch once every child is integrated and writes each command's exit status and timing into the completion report as `final_verification`. A failing command reports the batch as not passed; integrated commits are never rolled back | The commands the repository instruction file names for its full test suite and type check, else none and the completion report says nothing was run |
 
 A model identifier and an effort level mean something only to one Host, so
 `Lane Executor model` and `Lane Executor effort` apply only together with
@@ -231,6 +282,11 @@ a resume the recorded `max_parallel` stands and the directive is not passed
 again. The directives configure how the Parent starts sessions; the runner reads
 none of them, and they grant no permission or trust option.
 
+A repository that names its full test and type-check commands in prose (for
+example "uses `bun test`; type checking is `bun run typecheck`") supplies them as
+the final verification without a directive; the Parent never invents a command
+the repository does not name.
+
 #### Lane Executor Supervision
 
 The Parent launches and supervises every Lane's Executor Host; no other role
@@ -300,7 +356,8 @@ a live tab:
    `herdr agent start <name> --kind <kind> --pane <pane_id> -- <host arguments>`.
    Host arguments are only those that load the Parent's plugin and those that
    [Lane Preferences](#lane-preferences) resolved for model and effort.
-4. Submit the entry and nothing else, and confirm the turn began:
+4. Submit the entry and nothing else (later text follows only the instruction
+   rule below), and confirm the turn began:
    `herdr agent prompt <pane_id> "<imm-run entry> <task_id>" --wait --until working --until blocked --timeout 30000`.
    The entry is the Executor Host's own `imm-run` invocation as that Host names
    it: a Claude Code Host that loaded the plugin from a directory names it
@@ -312,13 +369,52 @@ a live tab:
 
 `agent_not_ready` from step 3, or a `blocked` state at any time, means the tab
 shows a dialog only the user may answer: workspace trust, sign-in, a permission
-request or a question. The Parent sends that tab no keys and no prompt. It
-tells the user which tab and `task_id` is waiting, leaves the tab open, and
-continues the other Lanes; once the user has answered, step 3's tab is resumed
+request, a question, or a native confirmation such as an Intent revision gate.
+The Parent sends that tab no keys and no prompt, and never answers such a dialog
+for the user. As soon as the wait returns `blocked` it tells the user which tab
+and `task_id` is waiting and what the dialog asks, without waiting to be asked,
+leaves the tab open, and continues the other Lanes; once the user has answered, step 3's tab is resumed
 from step 4 if the entry was never submitted, otherwise from step 5. `idle` or
 `done` is a session end for the rules below, although the tab stays open: the
 Parent calls `start_unattended_batch`, and a relaunch submits the entry again in
-the same tab instead of creating another. A failed or timed-out `herdr` command
+the same tab instead of creating another. When that report shows the child
+neither settled nor waiting on a user decision, the Parent tells the user which
+tab and `task_id` went idle and what the Kernel projection still requires.
+
+The Parent may send one text instruction to a Lane session, and only while it is
+`idle` and its child is still running in the Lane: a correction to the
+Executor's approach, never an answer to a dialog. It first calls
+`start_unattended_batch` with `lane_instruction` (`task_id`, `text`, `kind`
+`instruction` or `correction`, and the `session_state` it just observed with
+`herdr agent get`). The runner records the text in the batch record and report
+as `interventions` and answers `lane_instruction.accepted`; only when accepted
+does the Parent submit it with `herdr agent prompt <pane_id> "<text>" --wait
+--until working --until blocked --timeout 30000` and re-arm step 5. A `blocked`
+or `working` session is refused and receives nothing. Every instruction the
+coordinator sent is therefore in the report, so Executor-initiated behavior and
+coordinator intervention can be told apart afterwards. This never applies to a
+Review agent: a dispatched reviewer is still never continued or re-prompted.
+
+When a Lane child exhausts its rework budget (the per-child `qa_failure_limit`)
+it does not park for the user at once: the report carries a
+`{ role: "coordinator", action: "correct" }` handoff and the runner makes no
+further attempt for that child. The Parent reads the findings of every round
+from that Lane's Kernel state, decides whether they point at one root cause, and
+writes one design-level correction — the invariant to hold and the shared seam to
+fix — never a patch of its own. It starts a new Executor session in the Lane
+(the old context is not reused; the new session resumes from the Kernel
+projection and the Lane workspace alone) and sends the correction as
+`lane_instruction` kind `correction`; the runner counts it. At most two
+corrections are spent per child: the third exhaustion parks the child as
+`batch_correction_limit_reached`, its dependents are skipped, siblings that do not
+depend on it keep executing and integrating, and the batch reports it at the end.
+Single tasks outside a batch keep their existing budget behavior, and Review
+independence is unchanged. A Review rework budget that the Kernel turns into a
+`replan_required` decision still needs the user's own native decision.
+
+Every live Lane session keeps exactly one `herdr agent wait` armed, so `blocked`
+and idle-without-settlement wake the Parent on their own; a Parent that has
+nothing else to do still ends its turn with those waits armed. A failed or timed-out `herdr` command
 proves nothing about delivery; inspect the session's state before repeating it.
 
 The Parent only creates: it closes no tab, including the tabs it created, and
@@ -393,9 +489,23 @@ is recorded as a separate follow-up rather than resolved here.
   no new provider or data effect.
 - Text instructions are contracts, not a hard bash sandbox. They guide and are
   reviewed; the Kernel authority gates remain the real boundary.
+- In a Lane whose batch confirmation delegated in-envelope revisions
+  (ADR 0018), the Executor does not open the gate for a revision that only
+  changes acceptance or narrows `scope_hint`: it stops and returns the complete
+  next intent to the Parent, which submits it as `lane_revision` on
+  `start_unattended_batch`. The runner applies it as a delegated approval
+  (actor `batch-coordinator`, confirmation `delegated-batch:<batch_id>@<time>`)
+  or refuses it with `batch_delegation_refused` and a `fallback`; on refusal the
+  Executor uses its own native gate below. Widening scope, changing risk, goal
+  or the bound Spec is never delegated, and nobody answers a dialog in a tab.
 - Invoke `approve_breaking_intent_revision` with the complete next intent
   directly; the native Host gate is the single user decision. Do not overwrite
-  enrolled intent sidecars or ask for chat pre-confirmation.
+  enrolled intent sidecars or ask for chat pre-confirmation. A breaking revision
+  is used only when the goal, the `scope_hint`, or a user-visible commitment
+  changes. A defect inside the existing goal and scope is rework under the
+  Execution Loop, not a revision, and the acceptance length limit is never
+  worked around by shortening words: when an assertion grows toward it, the
+  assertion is enumerating cases that belong in tests.
 - On `awaiting_user`, invoke `request_authorization` directly for a concrete
   unresolved decision or rework authorization, not risk tier alone.
 - When the user explicitly asks to stop an active task, invoke the Kernel stop
@@ -505,7 +615,11 @@ Every line reports authority evidence, not prose inference: name the exact
 task/run identity and the observed lifecycle, artifact, obligation, and claim
 facts that decided the exit. If a summary claimed more than the projection
 proves — for example a later Slice as enrolled or the task as completed — report
-the projection instead and correct the prose.
+the projection instead and correct the prose. When the bound Spec lists `manual`
+scenarios owned by the settled Task's Slice, add one line naming those scenario
+IDs as pending manual walkthrough; the line is informational and changes no
+stop reason, obligation, or completion fact, and is absent when that Slice owns
+no manual scenario.
 
 ## Failure Output
 

package/plugins/immune-brain/dist/role-prompts/code-review.md

@@ -34,6 +34,13 @@ about the fix's scope, not a new bug. A trigger the accepted contract explicitly
 excludes is reported as an advisory note against that boundary, never as blocking
 rework.
 
+A defect that lies inside the TaskIntent goal and `scope_hint` is a blocking
+finding even when no acceptance assertion names its exact case word for word:
+cite the acceptance whose principle it violates as `acceptance_id` and
+`violated.ref`. Ask for the fix and a test that pins the case, never for the case
+to be written into the acceptance text; a missing literal clause is not itself a
+finding and does not call for an Intent revision.
+
 ## Invariant and Evidence Coverage
 
 Judge whether the change actually closes the invariant its acceptance names,
@@ -53,6 +60,24 @@ seam, or a seam silently replaced by a different one, is a finding carrying
 named, its absence is not a finding: candidates written before this rule carries
 no defect for lacking one.
 
+When the Spec referenced by an acceptance maps an `automated` user scenario to
+it, check that the delivered tests at that acceptance's agreed seam assert the
+scenario's `Then`: a scenario whose observable result is asserted nowhere is a
+finding carrying `violated.kind` of `acceptance` with `ref` the acceptance id.
+A `manual` scenario, and an acceptance with no mapped scenario, produce no such
+finding. This adds no finding kind and no verdict branch: it is the same
+`acceptance` finding the seam rule above already defines.
+
+Before pass, enumerate the immutable change set and read each complete per-file
+diff, including deletions. Page bounded reads until every hunk is visible; a
+truncated aggregate output or summary is incomplete coverage. Trace changed
+high-risk behavior through its callers and state owner, and inspect a concrete
+negative case against the embedded acceptance. If immutable evidence remains
+unavailable or incomplete, report the concrete acceptance coverage gap in a
+rework finding with required evidence. `inspected_paths` declares coverage; it
+does not itself prove tool reading. Judge quality by evidence, not elapsed time
+or tool-call count.
+
 A required check that is skipped, that matches zero tests, or whose prerequisite
 is absent does not prove the acceptance; do not accept it as evidence. Full
 suite coverage reported at a coarse pass count is not per-invariant evidence.

package/plugins/immune-brain/dist/role-prompts/executor.md

@@ -54,6 +54,13 @@ Record missing evidence as blocked and repair it before handoff. The Loop owns
 verdict submission, finding disposition and the second-rework generalize-or-refute
 rule.
 
+A finding whose defect lies inside the TaskIntent goal and `scope_hint` is
+ordinary rework even when no acceptance names its exact case: fix the code and
+add the test that pins the case. Do not propose an Intent revision for it, and
+never append a single input case to an acceptance assertion to close a finding;
+acceptance states principles, tests enumerate cases. Route to `imm-planner` only
+when the goal, the scope, or a user-visible commitment must change.
+
 ## Code Quality Guard
 
 Before handoff, check the implementation for real implementation rather than

package/plugins/immune-brain/hooks/hooks.json

@@ -1,6 +1,27 @@
 {
-  "description": "Observe Claude Code Review and session lifecycle for Immune-Brain. Hooks never mint authority.",
+  "description": "Observe Claude Code Review and session lifecycle for Immune-Brain, keep a batch Lane's file edits inside its Lane, and announce an active Managed task without resuming it. Hooks never mint authority.",
   "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Edit|Write|MultiEdit|NotebookEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node \"${CLAUDE_PLUGIN_ROOT}/dist/claude/mcp-server.mjs\" --hook"
+          }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node \"${CLAUDE_PLUGIN_ROOT}/dist/claude/mcp-server.mjs\" --hook"
+          }
+        ]
+      }
+    ],
     "SubagentStart": [
       {
         "hooks": [

package/plugins/immune-brain/runtime/assurance/active_task_notice.ts

@@ -0,0 +1,42 @@
+// A read-only Host notice for ordinary input while a Managed task is active in
+// the workspace. It tells the model, and through it the user, that the task
+// exists and what it is waiting for, so a fresh session does not commit or edit
+// inside that task's scope blind. It never resumes the task: ordinary input
+// stays host-native, and only an explicit `imm-run` entry continues it.
+import { readTaskRecordRaw } from "../kernel/storage";
+import { readActiveClaimTaskId } from "../unattended/batch_preflight";
+
+const MAX_SCOPE_ENTRIES = 12;
+
+export async function activeTaskNotice(root: string): Promise<string | null> {
+	let taskId: string | null;
+	try {
+		taskId = readActiveClaimTaskId(root);
+	} catch {
+		return null;
+	}
+	if (!taskId) return null;
+	// One TaskRecord read, no workspace diff: this runs on every prompt, and the
+	// exact next obligation is what the model reads from `status` afterwards.
+	let lifecycle = "unknown";
+	let artifactState = "unknown";
+	let scope: string[] = [];
+	try {
+		const record = readTaskRecordRaw(root, taskId).record;
+		if (record) {
+			lifecycle = record.lifecycle;
+			artifactState = record.artifact_state;
+			scope = [...record.intent_snapshot.scope_hint];
+		}
+	} catch {
+		// The notice is advisory; an unreadable projection still names the task.
+	}
+	if (lifecycle === "done" || lifecycle === "stopped") return null;
+	const shown = scope.slice(0, MAX_SCOPE_ENTRIES).join(", ") + (scope.length > MAX_SCOPE_ENTRIES ? ", ..." : "");
+	return [
+		`Immune-Brain: Managed task ${taskId} is active in this workspace (lifecycle ${lifecycle}, artifacts ${artifactState}).`,
+		"Ordinary input does not resume it, and another session may be running its assurance right now.",
+		`Before committing or modifying files inside its scope${shown ? ` (${shown})` : ""}, read its status and tell the user that this task is active and which obligation it is waiting on.`,
+		"Only an explicit imm-run entry continues it.",
+	].join(" ");
+}

package/plugins/immune-brain/runtime/assurance/coordinator.ts

@@ -23,6 +23,7 @@ import type { AssuranceProjectionResult } from "../kernel/assurance_projection";
 import type { TaskIntentIdentityToken } from "../kernel/intent_token_registry";
 import type { AssuranceHostPort, HostReviewReservation } from "./host_port";
 import type { GithubTrackerResult as GithubTrackerProjectionResult } from "../github_issue_tracker";
+import { isLaneWorkspaceForTask } from "../unattended/lane_workspace";
 
 
 export type AssuranceRole = "qa" | "review";
@@ -87,6 +88,10 @@ export function deriveGithubTerminalProjectionInput(
  * null otherwise), a tracker failure is reported as a retryable failure rather
  * than evidence or a blocker, and a failure never repeats the settling Kernel
  * mutation.
+ *
+ * A completed settlement inside a batch Lane writes nothing to the tracker: the
+ * Lane's delivery is not on the batch branch yet, so the coordinator closes the
+ * Child only after it integrates that child's commit.
  */
 export async function projectTerminalTrackerState(input: {
 	root: string;
@@ -94,10 +99,14 @@ export async function projectTerminalTrackerState(input: {
 	projection: AssuranceProjectionResult;
 	tombstone: TaskTombstone | null;
 	markTerminal: (root: string, projection: GithubTerminalProjectionInput) => Promise<GithubTrackerProjectionResult>;
+	isLaneWorkspace?: (root: string, taskId: string) => boolean;
 }): Promise<GithubTrackerProjectionResult | undefined> {
 	if (input.projection.error) return undefined;
 	const terminal = deriveGithubTerminalProjectionInput(input.task_id, input.projection, input.tombstone);
 	if (!terminal) return undefined;
+	// Only a completed delivery waits for integration; an explicit stop inside a
+	// Lane is never integrated and still projects `not planned` here.
+	if (terminal.phase === "done" && (input.isLaneWorkspace ?? isLaneWorkspaceForTask)(input.root, input.task_id)) return undefined;
 	try {
 		return await input.markTerminal(input.root, terminal);
 	} catch {
@@ -350,6 +359,18 @@ export type AssuranceSubmitReviewResult = AssuranceRecoveryFields & (
 	| { state: "settlement_unknown"; operation: "qa" | "review"; operation_id: string; reason: string }
 	| { state: "blocked"; reason: string; code?: "verdict_invalid"; recovery_action?: string });
 
+/**
+ * ADR 0017: optional metadata a host adapter supplies alongside the verdict
+ * input. The coordinator threads it opaquely; it never resolves verdict sources.
+ */
+export interface ReviewSubmissionOptions {
+	/** sha256 over the reviewer's own result bytes, bound into the review attestation. */
+	reviewer_verdict_sha256?: string;
+	/** Synchronous host check immediately before the reservation is consumed. */
+	validateReceipt?: () => string | null;
+	receiptRecoveryAction?: string;
+}
+
 export type ActiveAssuranceState =
 	| { state: "running"; operation: "qa"; operation_id: string; deadline_seconds: number }
 	| { state: "review_ready"; operation: "review"; operation_id: string }
@@ -559,7 +580,10 @@ function parseVerdictEvidence(value: unknown, index: number): FindingEvidence {
 export function parseAssuranceVerdict(input: unknown, snapshot: SnapshotDescriptor): AssuranceVerdict {
 	let raw: Record<string, unknown>;
 	if (typeof input === "string") {
-		const cleaned = input.split("\n").map((line) => line.trim()).filter((line) => line.startsWith("{") && line.endsWith("}")).join("");
+		// Agent transport prefixes a status line to the strict JSON verdict.
+		const first = input.indexOf("{");
+		const last = input.lastIndexOf("}");
+		const cleaned = first >= 0 && last >= first ? input.slice(first, last + 1) : "";
 		if (!cleaned) throw new Error("reviewer returned no strict JSON verdict");
 		try { raw = JSON.parse(cleaned) as Record<string, unknown>; } catch { throw new Error("reviewer verdict is not valid JSON"); }
 	} else if (typeof input === "object" && input !== null && !Array.isArray(input)) {
@@ -1192,11 +1216,11 @@ export class AssuranceCoordinator {
 		}
 	}
 
-	async submitReview(taskId: string, ctx: HostContext, verdictInput: unknown): Promise<AssuranceSubmitReviewResult> {
-		return this.withRecovery(taskId, ctx, await this.submitReviewOnce(taskId, ctx, verdictInput));
+	async submitReview(taskId: string, ctx: HostContext, verdictInput: unknown, options?: ReviewSubmissionOptions): Promise<AssuranceSubmitReviewResult> {
+		return this.withRecovery(taskId, ctx, await this.submitReviewOnce(taskId, ctx, verdictInput, options));
 	}
 
-	private async submitReviewOnce(taskId: string, ctx: HostContext, verdictInput: unknown): Promise<AssuranceSubmitReviewResult> {
+	private async submitReviewOnce(taskId: string, ctx: HostContext, verdictInput: unknown, options?: ReviewSubmissionOptions): Promise<AssuranceSubmitReviewResult> {
 		const unknown = this.unknownOperations.get(taskId);
 		if (unknown) return { state: "settlement_unknown", operation: unknown.operation, operation_id: unknown.operationId, reason: unknown.reason };
 		const rejected = this.rejectedReviewOperations.get(taskId);
@@ -1233,6 +1257,8 @@ export class AssuranceCoordinator {
 			reservation.verdictCorrectionRequired = true;
 			return { state: "blocked", code: "verdict_invalid", reason: boundedAssuranceError(error) };
 		}
+		const receiptError = options?.validateReceipt?.();
+		if (receiptError) return { state: "blocked", reason: receiptError, ...(options?.receiptRecoveryAction ? { recovery_action: options.receiptRecoveryAction } : {}) };
 		const invocation = this.openInvocation(taskId);
 		this.releaseReviewReservation(taskId, reservation);
 		try {
@@ -1242,6 +1268,7 @@ export class AssuranceCoordinator {
 				verdict,
 				invocation,
 				actorId: "parent-mediated-review",
+				...(options?.reviewer_verdict_sha256 ? { reviewer_verdict_sha256: options.reviewer_verdict_sha256 } : {}),
 			});
 		} catch (error) {
 			const reason = boundedAssuranceError(error);