immune-brain 4.6.0 → 5.0.0

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

@@ -16,16 +16,16 @@ Apply the gate when the task touches one or more of these surfaces:
 
 - **contract surface**: name the files, skills, runtime modules, generated outputs, or docs whose behavior is part of the promised result.
 - **compatibility**: state whether existing plans, state files, Pi runtime contracts, or users need migration or backwards-compatible behavior.
-- **interruption recovery**: describe what should remain true if execution stops midway and how the next `imm-loop` run should continue.
+- **interruption recovery**: describe what should remain true if execution stops midway and how the next `imm-run` run should continue.
 - **rollback path**: name the smallest coherent set of files or state entries to revert if the step fails.
 - **verification strength**: prefer parser, contract-test, unit-test, or executable command evidence over simple file-existence checks.
 - **design-depth classification**: for a change with a Technical Design concern, record why it is Low, Medium, or High risk. Every new or revised Spec records `**Design risk**: Low|Medium|High` with an adjacent rationale. Medium/High risk requires a Technical Design baseline in the Spec; Low risk may remain concise only when it has no contract, ownership, security, persistence, compatibility, or multi-component concern.
 - **Technical Design baseline**: keep the Spec as the single design authority and make each Plan Step reference the applicable decision or invariant instead of duplicating design prose.
 - **design-view selection**: for Medium/High risk, select every materially relevant technical-design view from architecture layers, service/component interfaces, data flow, state transitions, and temporal sequence. Record selected views and why omitted views cannot affect the design. Low risk remains concise.
-- **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.
+- **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`.
+- **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.
 - **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

@@ -1,6 +1,35 @@
 # Pi Subagent Dispatch Protocol
 
-本文档定义 Immune-Brain workflow role 在 Pi 中调度 advisory child 的唯一可执行协议。公共 `imm-brainstorm`、`imm-planner`、`imm-loop` 和 runtime 内部 roles 引用本协议，不内联另一套宿主分支。
+本文档定义 Immune-Brain workflow role 在 Pi 中调度 advisory child 的唯一可执行协议。公共 `imm-brainstorm`、`imm-planner`、`imm-run` 和 runtime 内部 roles 引用本协议，不内联另一套宿主分支。Claude Host 的 read-only role 派发见 [Claude Host Read-Only Agent Dispatch](#claude-host-read-only-agent-dispatch)；Pi 的调度规则不因该节改变。
+
+## Claude Host Read-Only Agent Dispatch
+
+On the Claude Host a read-only internal role is dispatched through the `Agent`
+tool by its plugin agent type, not by prompt text alone:
+
+| Internal role | Claude agent type | Tool allowlist |
+|---|---|---|
+| `qa` | `immune-brain:immune-brain-qa` | `Read, Grep, Glob` |
+| `ui-review` | `immune-brain:immune-brain-ui-review` | `Read, Grep, Glob` |
+| `advisory-reviewer` | `immune-brain:immune-brain-advisory-reviewer` | `Read, Grep, Glob` |
+| `arch-explorer` | the Host's `Explore` agent | whatever the Host grants |
+
+Each shipped definition is generated from the matching `runtime/prompts/` source
+by the plugin build, so its body states the same role contract a Pi child
+receives. The agent definition, not prompt text, bounds the role's tools: a
+write, shell or dispatch tool absent from the allowlist is unavailable to the
+child whatever its prompt asks for. `arch-explorer` ships no definition because
+architecture exploration uses the Host's own read-only research agent, and a
+second definition would fork a boundary the Host owns.
+
+`code-review` is not in this table: the authoritative Review authority ships
+`immune-brain:immune-brain-reviewer`, whose allowlist adds `Bash` because it must
+run read-only Git commands against the immutable revision.
+
+On Pi the agent configuration belongs to the Pi user, and the read-only boundary
+remains prompt text plus the `tool_policy` the delegation packet declares; Pi's
+`Agent` has no `readonly` parameter. The Pi invocation and scheduling rules below
+are unchanged.
 
 ## Eligibility
 

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

@@ -158,7 +158,7 @@ Agreement becomes framing evidence. Disagreement becomes decision criteria or an
 
 - **Allowed**: Clarify framing, inspect read-only context, ask narrowing questions, perform inline gap analysis.
 - **Blocked**: Implementation edits, test changes, plan writes, and runtime state updates. Do not edit implementation files, tests, specs, plans, or `.imm/memory/`.
-- **Workflow guard**: implementation continuations must go through `imm-planner` or `imm-loop`. `imm-brainstorm` frames the problem; it is not the default post-framing stage once the task is already stable enough to route forward. The `adversarial` mode remains available as an opt-in high-pressure gate for high-risk scenarios but is not a default route target.
+- **Workflow guard**: implementation continuations must go through `imm-planner` or `imm-run`. `imm-brainstorm` frames the problem; it is not the default post-framing stage once the task is already stable enough to route forward. The `adversarial` mode remains available as an opt-in high-pressure gate for high-risk scenarios but is not a default route target.
 
 ## Output artifact
 

package/plugins/immune-brain/dist/imm-doc-prune.md

@@ -9,14 +9,14 @@ Prune stale current documentation from one Git repository through explicit
 invocation, comprehensive inventory, evidence-based candidate narrowing,
 one exact user-approved manifest, and bounded current-only mutation. This is
 a standalone host-native maintenance entry, not a Managed Path continuation
-and not an `imm-loop` internal-role dispatch.
+and not an `imm-run` internal-role dispatch.
 
 ## Authority Boundary
 
 This Skill prunes documentation
 without creating or mutating
 TaskIntent, TaskRecord, Kernel, Spec, or Plan authority. An already active
-Managed task remains owned by `imm-loop`. Read-only inventory and manifest
+Managed task remains owned by `imm-run`. Read-only inventory and manifest
 production remain available. Classify each candidate overlapping the active
 TaskIntent `scope_hint` as `BLOCKED_ACTIVE_SCOPE` and continue auditing
 unaffected candidates. If the routing owner or scope cannot be read reliably,

package/plugins/immune-brain/dist/{imm-agent-doc-maintain.md → imm-doc-slim.md}

@@ -1,20 +1,20 @@
 ---
-name: imm-agent-doc-maintain
+name: imm-doc-slim
 description: Use when the user explicitly requests Immune-Brain minimization of tracked AGENTS.md, CLAUDE.md, or GEMINI.md.
 ---
 
-# Immune-Brain: Agent Doc Maintain
+# Immune-Brain: Doc Slim
 
 Minimize tracked agent instruction files in one Git repository to the smallest
 set of persistent rules that are non-obvious, repeatable, stable, and costly to
 violate. This is a standalone host-native maintenance entry, not a Managed Path
-continuation and not an `imm-loop` internal-role dispatch.
+continuation and not an `imm-run` internal-role dispatch.
 
 ## Authority Boundary
 
 This Skill maintains agent instruction files without creating or mutating
 TaskIntent, TaskRecord, Kernel, Spec, or Plan authority. An already active
-Managed task remains owned by `imm-loop`. Read-only inventory and manifest
+Managed task remains owned by `imm-run`. Read-only inventory and manifest
 production remain available. Classify each candidate overlapping the active
 TaskIntent `scope_hint` as `BLOCKED_ACTIVE_SCOPE` and continue auditing
 unaffected candidates. If the routing owner or scope cannot be read reliably,
@@ -23,12 +23,12 @@ deletion of evidence-proven content remains that Skill's separate job.
 
 ## Invocation
 
-Requires explicit invocation: `imm-agent-doc-maintain` or
-`/imm-agent-doc-maintain`. Ordinary "is this AGENTS.md too long?" questions stay
+Requires explicit invocation: `imm-doc-slim` or
+`/imm-doc-slim`. Ordinary "is this AGENTS.md too long?" questions stay
 host-native and do not enter this Skill.
 
-- `imm-agent-doc-maintain audit`: read-only. Produce the manifest and stop.
-- `imm-agent-doc-maintain`: produce the manifest, then wait for exact manifest
+- `imm-doc-slim audit`: read-only. Produce the manifest and stop.
+- `imm-doc-slim`: produce the manifest, then wait for exact manifest
   approval before any mutation.
 
 No automatic invocation. No daemon, no telemetry, no automatic learning, no
@@ -52,7 +52,7 @@ commit.
 
 2. **Resolve Managed ownership.** Read the existing routing projection without
    creating authority. An already active Managed task remains owned by
-   `imm-loop`. A candidate overlapping its `scope_hint` is
+   `imm-run`. A candidate overlapping its `scope_hint` is
    `BLOCKED_ACTIVE_SCOPE`; continue auditing unaffected candidates. If the
    routing owner or scope cannot be read reliably, fail closed for mutation.
 

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

@@ -12,7 +12,7 @@ This skill adheres to the **[BASELINE.md](BASELINE.md)**.
 `imm-planner` is entered explicitly by the user for a clear repository mutation.
 Ordinary host input does not invoke this Skill through natural-language routing.
 An active Assurance projection remains authoritative and is resumed only through
-an explicit `imm-loop` entry; explicit Planner entry owns planning and the later
+an explicit `imm-run` entry; explicit Planner entry owns planning and the later
 native Enrollment gate.
 
 Plan-only output remains non-authoritative. Planner creates or validates a
@@ -91,7 +91,7 @@ resolved wrapper and use the resolved `imm-kernel` wrapper for every Kernel
 command below. Do not assume either bare command is available on shell `PATH`.
 Then route deterministically:
 
-- an active Kernel claim remains with `imm-loop` for foreground Kernel Tool
+- an active Kernel claim remains with `imm-run` for foreground Kernel Tool
   coordination, except a Loop-requested revision follows Enrolled Intent Revision
   below to prepare a non-authoritative proposal for that same owner;
 - an active or otherwise nonterminal v3 Plan remains on its existing v3 route;
@@ -409,7 +409,7 @@ it, and structural Enrollment readiness is not proof that a descriptor executed.
 - **Design-Depth Classification**: Classify change design risk with the smallest sufficient tier: **Low risk** (copy, configuration, trivial rename, or contained local fix) may omit a separate Technical Design; **Medium risk** (non-trivial single-module behavior or internal contract) records affected components, decisions, invariants, failure behavior, and verification implications; **High risk** (cross-module/API/data-flow/state-machine, security, migration, concurrency, architecture ownership, cross-runtime/package-contract, or persisted-state work) records boundaries, interfaces or flow, alternatives, invariants, rollback/compatibility, and verification implications. Medium and High risk require Technical Design in the Spec. Do not classify a change as Low risk when it has a contract, ownership, security, persistence, compatibility, or multi-component concern. Every new or revised Spec records `**Design risk**: Low|Medium|High` with an adjacent rationale.
 - **Design-view selection**: For Medium and High risk, select every materially relevant technical-design view from architecture layers, service/component interfaces, data flow, state transitions, and temporal sequence. Record a short `Design views` statement naming the selected views and why any omitted view cannot affect the design. Do not write empty architecture, interface, data-flow, state, or sequence sections. Low risk remains concise and may omit Technical Design. When a selected view is recorded, also record its required decision content: architecture layers need layer responsibilities, dependency direction, ownership, and prohibited coupling; service/component interfaces need inputs, outputs, errors, compatibility/versioning, and caller/callee ownership; data flow needs source, transformations, validation, destination, and failure handling; state transitions need states, legal transitions, trigger, invariant, terminal ownership, and recovery; temporal sequence needs ordered interactions, authority at each point, interruption behavior, and idempotency.
 - **Technical Design Authority**: The Spec is the single Technical Design baseline. TaskIntent acceptance and scope reference the applicable design decisions or invariants without copying Technical Design prose. If discovery invalidates the baseline, stop execution and return to Planner to update the Spec and decide whether `replan` is required. TaskIntent and Initiative text do not duplicate Technical Design prose or become a prose Plan substitute.
-- **TaskIntent decomposition**: Use the selected design boundaries as one retain/split criterion for TaskIntent slices. Keep work in one TaskIntent when the selected views describe one coherent executable slice with shared acceptance, risk treatment, rollback, and authority. Split a successor TaskIntent when a service boundary, state-machine owner, migration/compatibility boundary, independently promotable layer, or sequence dependency needs independent verification, rollback, authorization, or settlement. Do not split merely because the design names several layers, files, or services. Treat trust-boundary changes as the same kind of decomposition evidence: a TaskIntent should normally change one primary trust-boundary invariant, while merely traversing several boundaries or updating both sides of one end-to-end authority chain does not require a split. Split separate trust invariants when they can be independently verified, rolled back, authorized, migrated, or settled. Keep multiple trust-boundary changes together only when they form one atomic security outcome and splitting would create an unsafe or unusable intermediate state; record that reason in the Spec. This is Planner judgment, not a TaskIntent schema field or an Enrollment counting rule. This does not revive prose Plan, Roadmap, or Phase authority.
+- **TaskIntent decomposition**: Use the selected design boundaries as one retain/split criterion for TaskIntent slices. Keep work in one TaskIntent when the selected views describe one coherent executable slice with shared acceptance, risk treatment, rollback, and authority. Split a successor TaskIntent when a service boundary, state-machine owner, migration/compatibility boundary, independently promotable layer, or sequence dependency needs independent verification, rollback, authorization, or settlement. Do not split merely because the design names several layers, files, or services. Treat trust-boundary changes as the same kind of decomposition evidence: a TaskIntent should normally change one primary trust-boundary invariant, while merely traversing several boundaries or updating both sides of one end-to-end authority chain does not require a split. Split separate trust invariants when they can be independently verified, rolled back, authorized, migrated, or settled. Keep multiple trust-boundary changes together only when they form one atomic security outcome and splitting would create an unsafe or unusable intermediate state; record that reason in the Spec. This is Planner judgment, not a TaskIntent schema field or an Enrollment counting rule. This does not revive prose Plan, Roadmap, or Phase authority. For a multi-TaskIntent Initiative only, each Slice also states what is observable and verifiable when that Slice alone has landed, and no acceptance may require another unfinished Slice's work to pass; the Initiative review table's existing `result` column carries that statement. A Slice with no such result is a horizontal layer slice and is re-cut. Exception: a wide mechanical refactor whose blast radius prevents any green vertical slice may be batched, with the rationale recorded and the batches blocking one final integrate-and-verify Slice.
 - **Mermaid Use**: Mermaid is required only when a medium/high-risk design contains structure, sequence, data flow, or state transition relationships that a diagram materially clarifies. Mermaid is not a universal gate; a diagram supplements adjacent prose and never becomes a second design authority. Medium/High risk Specs record `**Diagram decision**: required|not_required` and a non-empty `**Diagram reason**:`. A `required` decision must have a Mermaid block; `not_required` explains why prose is sufficient. Low-risk Specs omit the empty ceremony and record neither field.
 - **Verification**: Every acceptance assertion has a concrete focused descriptor that can fail on the intended regression, and every named invariant has positive, negative, and bound controls at an observable seam. Hypothetical evidence is not execution-ready; a check that matches zero tests, is skipped, or lacks its prerequisite is a failure rather than a pass.
 - **Executable Scope**: `scope_hint` is the mutation envelope, not discovery context. Close references across callers, tests, generated mirrors, and state-machine owners before authoring. Simple tasks are TaskIntent-only. A complex task binds at most one active Spec by content identity; do not add archive paths for freeze, and do not relocate artifacts. Collect all known scope gaps in one revision request; ask again only when new evidence changes the boundary.
@@ -484,7 +484,7 @@ preparation does not apply the revision or authorize expanded execution.
 
 ## 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-loop`; a validated candidate still needs native Enrollment.
+- **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.
 - **Output Language Gate**: Before writing or revising any Spec or Plan, read the project output language policy from `AGENTS.md`, `IMMUNE.md`, or Immune-Brain plugin config. Default Spec and Plan prose to English unless the current user request, project instructions, or host/user preference contains an explicit document-language instruction. A reply-language instruction does not change document language. Keep schema fields, CLI commands, file paths, code identifiers, enum values, JSON keys, and canonical terms such as `Step`, `Plan`, `Spec`, `Verification`, `Discovery cache`, and `Devil's Advocate Audit` literal.
 - **Clarification Supplement**: If an upstream `imm-brainstorm` manifest exists, verify that every `BR-Q-*` item is resolved and every confirmed framing decision is represented; must not repeat, reopen, or rewrite confirmed decisions. Ask only a focused omission, repository-conflict, or invalidated-assumption delta tied to concrete evidence. Resolve a local delta here; return to `imm-brainstorm` when it reopens multiple product branches or changes the overall goal or Scope. Finalization requires no unresolved supplement and no unconfirmed decision introduced by Planner.
 - **Planning Bootstrap**: When no upstream `imm-brainstorm` manifest exists, preserve Direct Planner entry by resolving repository facts and deriving ordinary technical choices. An already-clear request takes the zero-question fast path to a non-blocking correction summary. Discovery of an unresolved user-owned goal, user, scope, behavior, compatibility preference, risk acceptance, or success criterion returns to `imm-brainstorm`; Planner does not convert product uncertainty into a silent assumption or duplicate Brainstorm's interview.
@@ -502,7 +502,16 @@ preparation does not apply the revision or authorize expanded execution.
   explain how the selected seam catches the intended regression. This is a
   planning heuristic: it must not weaken acceptance-specific focused
   verification descriptors or add a mandatory user confirmation.
-- **Review Mapping**: In-scope rework stays with the enrolled TaskIntent and explicit `imm-loop` entry. Cross-scope findings become a Planner decision delta with concrete missing paths and verification evidence; do not create a successor prose Plan.
+  **Agreed seam recording.** Record, for each acceptance, the agreed seam: the
+  existing or new test file and the observable boundary it exercises. Complex
+  work records it in the Spec's verification and acceptance mapping; simple work
+  names it in the acceptance assertion. Because the seam is part of the
+  candidate, present it in the native Enrollment gate, and the Initiative review
+  table when one exists, without any added confirmation. Tests the Executor adds
+  exercise the agreed seams, and replacing a seam is an acceptance change and
+  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.
 - **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.
@@ -535,7 +544,12 @@ Use the invoking Host's read-only role-boundary route for bounded
 exactly. The Parent owns Spec/TaskIntent synthesis, Brainstorm traceability,
 acceptance, and scope; children return evidence only. On Pi the `arch-explorer` envelope
 uses `subagent_type: "Explore"`; invoke the returned envelope rather than
-constructing another Agent call. Do not invoke retired Planner runtime helpers
+constructing another Agent call. On the Claude Host a read-only role is dispatched
+through the `Agent` tool by its plugin agent type —
+`immune-brain:immune-brain-advisory-reviewer` — and architecture exploration uses
+the Host's own `Explore` agent; the agent definition, not prompt text, bounds
+that role's tools. On Pi the agent configuration belongs to the Pi user and the
+read-only boundary remains prompt text. Do not invoke retired Planner runtime helpers
 or write child-owned planning artifacts.
 
 An optional planner ensemble is advisory-only; the Parent owns the final Spec and TaskIntent.
@@ -551,7 +565,7 @@ optional advisory dispatch fails, continue inline and record the reason.
 
 - **Allowed**: Write a TaskIntent. Add a Spec only for complex work. Activate an absent routing policy under Kernel TaskIntent Routing. Initiative planning carriers and necessary domain vocabulary.
 - **Blocked**: Implementation edits, direct Kernel-store writes, enrolled intent overwrites, and QA/Review decisions.
-- **Workflow guard**: Execution continues through native Enrollment and explicit `imm-loop`. Planner owns design and decomposition, not execution authority.
+- **Workflow guard**: Execution continues through native Enrollment and explicit `imm-run`. Planner owns design and decomposition, not execution authority.
 
 ## Output artifact
 
@@ -588,6 +602,7 @@ a State Ledger. Keep historical Plan validation strictly read-only.
 - A required check matches zero tests or is skipped and the run is reported as passing.
 - New work depends on a prose Plan validator, Step activation, or State Ledger.
 - A Brainstorm manifest lacks complete `BR-*` coverage on the Spec (complex) or TaskIntent (simple).
+- A user-owned Spec decision or acceptance names no source, or names one nobody made.
 - The handoff completeness check passed while a required phase or upstream item is unmapped, or while the plan delivers only part of the confirmed outcome.
 - A Medium/High risk Spec lacks a `Devil's Advocate Audit` covering rollback resilience, verification vanity, and spec dilution detection.
 - New Spec prose ignores the document-language policy.
@@ -603,6 +618,6 @@ a State Ledger. Keep historical Plan validation strictly read-only.
 ## Next Action
 
 - Gate: Reference closure and clarification are complete; every upstream `BR-*` item is represented; no unresolved user decision remains; Planner-introduced decision deltas are confirmed; the candidate is Git-tracked and validates with `valid: true` and `enrollment_ready: true`; each acceptance has concrete focused verification. Plan-only requests stop here.
-- If gates pass: for Kernel-managed work, invoke the current Host's native Enrollment Tool directly without chat pre-confirmation. Its single literal-user gate binds the TaskIntent revision, content hash, and preparation digest, validates Enrollment preconditions without executing acceptance descriptors, and enrolls the task to continue through `imm-loop`.
+- If gates pass: for Kernel-managed work, invoke the current Host's native Enrollment Tool directly without chat pre-confirmation. Its single literal-user gate binds the TaskIntent revision, content hash, and preparation digest, validates Enrollment preconditions without executing acceptance descriptors, and enrolls the task to continue through `imm-run`.
 - If the native gate fails: preserve candidate artifacts and report the stable reason plus exactly one same-Host recovery action. Do not suggest another Host, worktree, Direct Path, unmanaged implementation, or automatic retry.
 - If gates are not met: state which validation failures, unresolved verification paths, or material decision deltas remain; do not name a next skill.

package/plugins/immune-brain/dist/imm-pr-fix.md

@@ -9,7 +9,7 @@ description: Use when the user explicitly requests Immune-Brain repair of GitHub
 
 Repair blockers on one GitHub pull request without creating or mutating
 TaskIntent, TaskRecord, Kernel, Spec, or Plan authority. An already active
-Managed task remains owned by `imm-loop`; stop and direct the user there when
+Managed task remains owned by `imm-run`; stop and direct the user there when
 the target PR is part of that task.
 
 ## Workflow

package/plugins/immune-brain/dist/{imm-review-retro.md → imm-retro.md}

@@ -1,14 +1,14 @@
 ---
-name: imm-review-retro
+name: imm-retro
 description: Use when the user explicitly requests Immune-Brain ranking of models by cross-model review load or a project usage retro.
 ---
 
-# Immune-Brain: Review Retro
+# Immune-Brain: Retro
 
 Rank models by how much code review their own edits triggered, and report
 basic project usage over a look-back window the user supplies in days. This
 is a standalone host-native analysis entry, not a Managed Path continuation
-and not an `imm-loop` internal-role dispatch. It reviews no diff — a diff
+and not an `imm-run` internal-role dispatch. It reviews no diff — a diff
 review is `code-review`.
 
 ## Boundary
@@ -20,12 +20,12 @@ Blocked: code, test, Spec, Plan, or `.imm/` edits; session-log writes;
 Kernel, TaskIntent, or TaskRecord mutation; Compounder or scheduled runs;
 `.imm/audit/` lifecycle statistics.
 
-An already active Managed task remains owned by `imm-loop`. This Skill does
+An already active Managed task remains owned by `imm-run`. This Skill does
 not create or resume Managed authority.
 
 ## Invocation
 
-Requires explicit invocation: `imm-review-retro` or `/imm-review-retro`.
+Requires explicit invocation: `imm-retro` or `/imm-retro`.
 Ordinary questions such as "which model is worse" stay host-native and do
 not enter this Skill.
 
@@ -42,23 +42,36 @@ No daemon, no cron, no CI, no automatic commit.
 These rules keep numbers comparable across runs. Read the analyzer header
 aloud in the report so the 口径 stays visible.
 
-- `review` = an `Agent` tool call with `subagent_type` equal to `Review`.
-- Attribution = the model behind the most recent `edit`, `write`, or
-  `multiedit` in that session. If none, the row is `no-edit (review-only)`.
+- `review` = an `Agent` tool call with `subagent_type` equal to `Review`,
+  compared case-insensitively.
+- Attribution = the model behind the most recent `edit`, `write`,
+  `multiedit`, or `apply_patch` in that session. If none, the row is
+  `no-edit (review-only)`. Edits made through `bash` or `codemode` are not
+  attributed.
 - `uniq` counts distinct (session, description+prompt prefix) pairs. A wide
   gap versus `reviews` is the same review re-run on the same code.
 - `rev/100ed` is `100 * reviews / devEdits`. Rank on both absolute `reviews`
   and this intensity. A model can lead one axis and sit mid-pack on the
   other.
-- `avgSc` / `pass%` parse `[SCORE: …]` and `[VERDICT: …]` tags from the
-  matching Review `toolResult`. Untagged reviews show `-`.
+- `avgSc` parses the `[SCORE: …]` tag from the matching Review `toolResult`.
+  The `assurance_verdict` contract carries no score, so untagged reviews show
+  `-` and are left out of the average.
+- `pass%` is PASS over judged reviews. A review is judged by the `decision`
+  of the `assurance_kernel/assurance_verdict` contract in its `toolResult`
+  (`pass` counts as PASS); without a contract, by the `[VERDICT: …]` tag. A
+  review with neither is unjudged and left out of the denominator.
+- The quality table (`PASS` / `REVISE` / `REJECT` / `highRisk`) covers tagged
+  reviews only, so its `PASS` count can differ from `pass%`.
 - `registr` counts the Kernel `submit_review` registration in the session log.
   It is the registration of the same review and is never added into `reviews`.
 - `rounds/task` is registrations per distinct `(cwd, task_id)`. High values
   can be canary/QA harness re-registration, not human-visible rework.
-- Findings are `record_finding` calls, deduped per session. Summaries that
-  match `recorded cleanly`, `receipt recorded`, `round recorded`, or
-  `no finding(s)` are `bookkeep` / `noisy`, excluded from `block`/`advis`.
+- Findings are the `verdict.findings` entries of `submit_review` calls plus
+  legacy `record_finding` calls, deduped per session by summary, so a finding
+  re-submitted across rounds counts once. The Review `toolResult` copy of the
+  same verdict is not counted. Summaries that match `recorded cleanly`,
+  `receipt recorded`, `round recorded`, or `no finding(s)` are `bookkeep` /
+  `noisy`, excluded from `block`/`advis`.
 
 Usage counters on the same pass: sessions with activity, assistant turns,
 edit counts, a tool-call name histogram, and the project × author table.

package/plugins/immune-brain/dist/{imm-loop.md → imm-run.md}

@@ -1,5 +1,5 @@
 ---
-name: imm-loop
+name: imm-run
 description: Use when the user explicitly requests execution or resumption of an Immune-Brain task.
 ---
 
@@ -9,7 +9,7 @@ This skill adheres to the **[BASELINE.md](BASELINE.md)**.
 
 ## Kernel Canary Routing and Authority
 
-Only explicit `imm-loop` entry starts or resumes this loop. Ordinary host input
+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
 Host's `status` projection first and verify the exact active backend claim,
 TaskIntent, and TaskRecord. Invalid or contradictory projections fail closed. A
@@ -25,7 +25,7 @@ assume either way. For a GitHub-carried Initiative, `tracker_projection_failed`
 `awaiting_user_initiative_confirmation` blocks that Enrollment until the same
 complete carrier batch succeeds; report the stable carrier reason and its exact
 retry action instead of enrolling. A carrier command the Host refused, cancelled,
-or never ran is not a completed batch, and a later `imm-loop` entry does not
+or never ran is not a completed batch, and a later `imm-run` entry does not
 clear it. This pre-Enrollment gate is distinct from the post-settlement tracker
 projection below, which never blocks the Loop.
 
@@ -42,9 +42,18 @@ architecture exploration, advisory review, Compounder, Kernel ownership, or
 scope expansion. Use Kernel ownership for an enrolled task. This route projects
 authority; it does not record execution evidence, mutate task state, or replace
 Kernel operations.
+
+On the Claude Host a read-only internal role is dispatched through the `Agent`
+tool by its plugin agent type — `immune-brain:immune-brain-qa`,
+`immune-brain:immune-brain-ui-review`,
+`immune-brain:immune-brain-advisory-reviewer` — and architecture exploration uses
+the Host's own `Explore` agent. The agent definition, not prompt text, bounds
+that role's tools. On Pi the agent configuration belongs to the Pi user and the
+read-only boundary remains prompt text; the Pi dispatch rules are unchanged.
+
 Before a child dispatch, read the [Subagent Dispatch Protocol](docs/reference/subagent-dispatch-protocol.md#authorization-authority).
 Never load an internal role as a public Skill or spawn another loop process.
-The standalone `imm-pr-fix`, `imm-doc-prune`, and `imm-agent-doc-maintain` are host-native
+The standalone `imm-pr-fix`, `imm-doc-prune`, and `imm-doc-slim` are host-native
 maintenance entries, never dispatched as the Loop role. Internal `test-fixer`
 and `pr-fix` repairs remain bounded by the enrolled TaskIntent.
 
@@ -60,7 +69,9 @@ Continue while the current projection has a valid action:
    to the user. If a file mixes pre-existing user changes with task changes and
    the task-owned hunks cannot be isolated reliably, stop with that ownership
    conflict instead of staging the whole file. Staging grants no commit or push
-   authority. Executor checks are diagnostic evidence, not a QA or Review approval.
+   authority. Complete the [Executor Delivery Evidence](role-prompts/executor.md#delivery-evidence)
+   table before the first Assurance attempt and update affected rows after repair.
+   Executor checks are diagnostic evidence, not a QA or Review approval.
 2. Call `advance_assurance` in the foreground and consume its direct terminal
    result. The Kernel freezes the artifacts itself before QA: it binds Git
    content identity in place without relocating source paths. A simple task has
@@ -104,7 +115,7 @@ not bypass them. Do not poll or create detached jobs.
 
 The only unattended batch entry is the privileged Host tool `start_unattended_batch`
 with its `initiative_slug` parameter. That parameter is the opt-in: absent the call,
-`imm-loop` behavior is byte-identical to per-task Enrollment, and no batch state,
+`imm-run` behavior is byte-identical to per-task Enrollment, and no batch state,
 branch, or Batch Authorization exists. The Standalone Hosts expose the same tool
 name and the same single parameter; it is never a batch of tasks the Host chose.
 When an Initiative is referenced by its tracker Issue (e.g. `github #<number>`),
@@ -236,11 +247,26 @@ write planning artifacts, mutate Kernel state, or settle decisions. Report all
 substantiated blockers in one round, tied to acceptance or a concrete regression;
 separate optional advice from blockers. Suggestions alone do not justify rework.
 Use the returned verdict schema exactly, including omission of unsupported fields.
+A Review pass verdict's approval must carry `inspected_paths`: an array of
+unique repository-relative path strings listing every path of the reviewed
+change set, deleted paths included; an empty change set is listed as an empty
+array. A path may be listed only after its diff was read. A pass that omits any
+changed path, lists a path outside the change set, or duplicates a path is
+rejected as a correctable invalid verdict.
 
 `dispatch_role` for `qa`, `code-review`, or `ui-review` is used only when an
 explicit runtime-supported role boundary requests it, followed by the returned
 foreground Agent envelope exactly. It is not an extra gate on Kernel Assurance.
-All internal Agent envelopes use `run_in_background: false`.
+Pass the returned Agent envelope through unchanged. On the Claude Host an Agent
+call always returns an asynchronous launch receipt, which is normal and never a
+configuration fault; the Parent waits for the reviewer to finish before
+`submit_review`. A dispatched reviewer is never continued or re-prompted,
+including through SendMessage. The reserved prompt is dispatched verbatim. Any
+edit to it forfeits the reservation: the Host binds a reviewer start only to a
+byte-identical prompt, so appending context, truncating or rewriting the body
+leaves the reservation unobserved and `submit_review` blocked. Dispatch the same
+envelope unchanged. A blocked `submit_review` is recovered only through its
+returned `recovery_action`.
 
 Role dispatches follow the user's interaction language: include
 `"interaction_language"` in the `dispatch_role` or routed role context with

package/plugins/immune-brain/dist/registry.yaml

@@ -18,10 +18,10 @@ skills:
     role_class: authority
     canonical: true
     output_artifacts: [validated_plan]
-    next_actions: [imm-loop]
+    next_actions: [imm-run]
     boundary: Owns plan creation and revision; no executor edits.
-  - name: imm-loop
-    path: skills/imm-loop/SKILL.md
+  - name: imm-run
+    path: skills/imm-run/SKILL.md
     role: coordinate
     title: Run
     role_class: coordinator
@@ -47,19 +47,19 @@ skills:
     output_artifacts: [prune_report]
     next_actions: []
     boundary: Prune stale current documentation after explicit manifest approval; no Managed authority mutation or authority-artifact deletion.
-  - name: imm-agent-doc-maintain
-    path: skills/imm-agent-doc-maintain/SKILL.md
+  - name: imm-doc-slim
+    path: skills/imm-doc-slim/SKILL.md
     role: execute
-    title: Agent Doc Maintain
+    title: Doc Slim
     role_class: repair
     canonical: true
     output_artifacts: [maintain_report]
     next_actions: []
     boundary: Minimize tracked agent-instruction context after explicit manifest approval; no Managed authority mutation, contract installation, or reference-document creation.
-  - name: imm-review-retro
-    path: skills/imm-review-retro/SKILL.md
+  - name: imm-retro
+    path: skills/imm-retro/SKILL.md
     role: execute
-    title: Review Retro
+    title: Retro
     role_class: discovery
     canonical: true
     output_artifacts: [retro_report]

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

@@ -46,6 +46,13 @@ covers the whole lifecycle including cleanup, ranking tolerates missing
 embeddings, the budget covers the complete serialized request, and each success,
 failure, and timeout outcome carries its own duration evidence.
 
+When an acceptance assertion, or the Spec it references, names an agreed seam,
+check that the delivered tests exercise that acceptance at that seam. A missing
+seam, or a seam silently replaced by a different one, is a finding carrying
+`violated.kind` of `acceptance` with `ref` the acceptance id. When no seam is
+named, its absence is not a finding: candidates written before this rule carries
+no defect for lacking one.
+
 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

@@ -12,8 +12,9 @@ scoped implementation, staging and focused diagnostics. Enrollment itself does
 not start QA; the Parent owns the subsequent Kernel Assurance and foreground
 Review handoff under the same still-valid batch authorization.
 
-Before handoff, run the permitted diagnostic checks and return commands and
-outcomes to the Parent as structured diagnostic evidence. The read-only Loop
+Before handoff, run the permitted diagnostic checks, complete the Delivery
+Evidence check below and return its table to the Parent as structured diagnostic
+evidence. The read-only Loop
 runtime action only constructs the dispatch envelope; it does not store
 evidence or change task state. Preserve failed and blocked attempts. Do not
 perform QA,
@@ -21,6 +22,38 @@ review, plan mutation, successor approval, Compounder work, or authority
 writes. If the requested change needs scope expansion, stop and return an
 `imm-planner` route with the concrete missing scope and verification reason.
 
+## Delivery Evidence
+
+Reuse the TaskIntent and any bound Spec's agreed seams and controls. Before the
+first Assurance attempt, return one compact row per acceptance; update affected
+rows after repair. This is handoff evidence, not a new artifact or approval gate.
+
+| Acceptance / invariant | Entry and consumers | Positive / negative / boundary controls | Command, outcome and input | Finding coverage |
+|---|---|---|---|---|
+
+For changed shared behavior, trace the real entry through its state owner,
+write, serialization, reload and downstream consumer as applicable. Include
+both affected hosts and recovery/replay branches. An async, return-type or
+exception-contract change requires checking every affected caller's await,
+cancellation and error propagation.
+
+Use the real producer for the success control where available. Derive rejection
+controls from a successful state, change only the target condition, and assert
+the intended rejection reason and required side effects. A control must fail
+when its target protection is removed. For byte-preservation claims compare the
+relevant raw files, index and refs; for observed behavior link each required
+criterion to its concrete observation.
+
+Name whether each check consumed worktree or delivery bytes. Before Assurance,
+verify task-owned changes are staged within scope, generated mirrors match,
+and applicable type/build checks pass. On QA failure, reproduce the reported
+failure under its delivery conditions before another attempt. For rework, name
+the violated invariant, all known trigger classes and their controls in Finding
+coverage; account for affected callers sharing that invariant within scope.
+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.
+
 ## Code Quality Guard
 
 Before handoff, check the implementation for real implementation rather than