immune-brain 4.6.0 → 5.1.0

package/plugins/immune-brain/dist/docs/reference/immune-brain-config.md

@@ -53,6 +53,33 @@ with a batch retry action and does not invalidate the authored planning files,
 but it blocks Enrollment and execution handoff for that Initiative until the same
 complete batch succeeds. It never silently switches carrier.
 
+## Lane Preferences
+
+Four optional directives hold standing lane-mode choices. The Parent resolves
+them before the first `start_unattended_batch` call for an Initiative; the batch
+runner reads none of them. None has a built-in default.
+
+```md
+## Immune-Brain Preferences
+
+- Lane max parallel: 4
+- Lane Executor Host: claude-code
+- Lane Executor model: <model id>
+- Lane Executor effort: high
+```
+
+- `Lane max parallel` is passed as `max_parallel` and turns lane mode on.
+  Without it a batch stays serial unless you ask for lanes in that request. A
+  resumed batch keeps the value it recorded.
+- `Lane Executor Host` is `claude-code` or `pi`. Every Lane uses it, with no
+  fallback to the other Host. Without it the Parent prefers its own Host type.
+- `Lane Executor model` and `Lane Executor effort` apply only when
+  `Lane Executor Host` is set, because a model ID belongs to one Host. Without
+  them each Executor Host uses its own default.
+
+Lane-mode agents only create: they close no tab, stop no session and remove no
+Lane. The full contract is `plugins/immune-brain/dist/imm-run.md#lane-preferences`.
+
 ## Other Preferences
 
 - Set reply-language preferences as ordinary `AGENTS.md` communication

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.