immune-brain 3.6.9 → 4.0.1

package/plugins/immune-brain/dist/docs/reference/planning-artifact-retention.md

@@ -73,18 +73,17 @@ Non-terminal artifacts remain durable at their existing paths by default.
 
 ## Authority-Owned Lifecycle
 
-An enrolled TaskIntent and the one exact active Spec bound by its `scope_hint`
-remain under `docs/plans/` and `docs/specs/` while the task is `working`. Before
-QA, the Kernel freezes both artifacts through one recoverable transaction: bytes
-move to their `archive/` paths and `TaskRecord.intent_ref.path` changes to the
-archived sidecar. Every later Kernel action rereads that recorded path.
-
-Authorized Review rework restores both artifacts before returning to `working`.
-Completion is valid only from the frozen location. Stop freezes an active pair
-before terminal settlement, so both terminal outcomes leave no active planning
-artifact. A relocation conflict or crash fails closed and converges only through
-the transaction marker; no background scanner or second status writer may infer
-or repair lifecycle state.
+An enrolled TaskIntent remains under `docs/plans/` for the whole run. A complex
+task may bind one active Spec under `docs/specs/` by content identity. Before QA,
+the Kernel freezes those artifacts in place: Git objects are bound, source paths
+do not move, and `TaskRecord.intent_ref.path` stays on the active sidecar.
+Historical files already in `archive/` remain readable. A later edit of a bound
+Spec changes the delivery identity, so prior assurance cannot be reused.
+
+Authorized Review rework returns `artifact_state` to `active` without relocating
+files. Completion and stop freeze in place; they do not archive planning
+artifacts. A crash fails closed and converges only through the store transaction;
+no background scanner or second status writer may infer or repair lifecycle state.
 
 Terminal cleanup outside that lifecycle remains a bounded TaskIntent with an
 explicit candidate list and a copy-paste verification command. It may accompany

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

@@ -80,7 +80,7 @@ Agent:
   schedule: ""
 ```
 
-Pi `Agent` has no `readonly` parameter; the empty tool policy, child type, and prompt contract enforce the read-only boundary. The Parent starts one foreground Agent at a time and consumes its direct result before deciding whether another child is needed. Advisory and discovery work does not call `get_subagent_result` or depend on completion notifications or host `followUp`. Kernel Review uses `subagent_type: "Review"`; its structured verdict is submitted by the Parent and validated against the current immutable snapshot. Loop `arch-explorer` uses `subagent_type: "Explore"`; other advisory/discovery and Loop internal roles use `general-purpose`.
+Pi `Agent` has no `readonly` parameter; the empty tool policy, child type, and prompt contract enforce the read-only boundary. The Parent starts one foreground Agent at a time and consumes its direct result before deciding whether another child is needed. Advisory and discovery work does not poll for deferred results or depend on completion notifications or host `followUp`. Kernel Review uses `subagent_type: "Review"`; its structured verdict is submitted by the Parent and validated against the current immutable snapshot. Loop `arch-explorer` uses `subagent_type: "Explore"`; other advisory/discovery and Loop internal roles use `general-purpose`.
 
 ## Scheduling And Visibility
 

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

@@ -11,9 +11,9 @@ This skill adheres to the **[BASELINE.md](BASELINE.md)**.
 
 Only explicit `imm-loop` entry starts or resumes this loop. Ordinary host input
 stays host-native; it never resumes a Managed owner implicitly. Read the current
-Host's `imm_kernel_canary` `status` first and verify the exact active backend
-claim, TaskIntent, and TaskRecord. Invalid or contradictory projections fail
-closed. A candidate TaskIntent is not Enrollment authority.
+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.
 
 Before the first Enrollment of a candidate TaskIntent, confirm the Planner
 returned `tracker_associated` — but only when the candidate belongs to an
@@ -36,11 +36,12 @@ Historical prose Plans and State Ledgers are read-only history, not execution
 instructions. Do not create Steps, workflow profiles, follow-up ledgers, or
 successor Plans to drive a Kernel task.
 
-At every internal role boundary call the read-only `imm_loop_action` Tool. Use
-`route` for current-context Executor work, bounded repair, architecture
-exploration, advisory review, Compounder, Kernel ownership, or scope expansion.
-Use Kernel ownership for an enrolled task. This Tool projects authority; it does
-not record execution evidence, mutate task state, or replace Kernel operations.
+At every internal role boundary call the invoking Host's read-only role-boundary
+route. Use `route` for current-context Executor work, bounded repair,
+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.
 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
@@ -51,26 +52,33 @@ and `pr-fix` repairs remain bounded by the enrolled TaskIntent.
 
 Continue while the current projection has a valid action:
 
-1. For active artifacts, implement only the enrolled acceptance within
-   `scope_hint` in the current conversation. Run focused checks. Executor checks
-   are diagnostic evidence, not a QA or Review approval.
-2. Before Assurance, call `freeze_artifacts` while TaskRecord is `active:active`.
-   A bound active Spec and its archive path must both be inside `scope_hint`.
-   The Kernel owns byte-preserving archival and the frozen snapshot.
-3. Call `advance_assurance` in the foreground and consume its direct terminal
-   result. Deterministic QA runs fixed acceptance descriptors atomically inside
-   the Host integration. Do not dispatch a separate per-Step QA Agent.
-4. On `review_ready`, invoke the returned `agent_params` as one exact foreground
+1. For active artifacts, implement only the enrolled acceptance within the
+   `scope_hint` envelope in the current conversation. New helpers or tests
+   inside an approved directory or glob do not require a revision. Run focused
+   checks. 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
+   TaskIntent only; a complex task may bind one active Spec. Deterministic QA
+   runs all descriptors in a disposable delivery materialization, never against
+   unchecked live worktree source. Do not dispatch a separate per-Step QA Agent.
+3. On `review_ready`, invoke the returned `agent_params` as one exact foreground
    Agent call, then pass its structured verdict to `submit_review`. Do not
    replace this snapshot-bound reviewer with a generic role dispatch. The Parent
    cannot issue its own QA or Review pass.
-5. Follow the returned Kernel obligation. Fresh QA suffices for routine work;
+4. Follow the returned Kernel obligation. Fresh QA suffices for routine work;
    material and critical work additionally require fresh independent Review.
    Normal completion does not require a second user confirmation.
-6. For rework, follow the projected artifact state before editing. Resolve
+5. For rework, follow the projected artifact state before editing. Resolve
    findings only after fixing and verifying their cause. Changed snapshots
-   invalidate old evidence; freeze and run the newly required obligations.
-7. An unresolved decision pauses only dependent execution. On `awaiting_user`,
+   invalidate old evidence; run the newly required obligations. On the second
+   rework of one acceptance id or anchor, the fix response must either state why
+   it covers every known trigger class of the violated invariant — the shared
+   guard, not only the reported path — or declare the trigger outside the
+   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.
+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
    the decision remains unresolved, is cancelled, or the gate fails. Otherwise
@@ -122,9 +130,9 @@ per completed child.
   enrolled intent sidecars or ask for chat pre-confirmation.
 - 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 a Pi task, invoke
-  `imm_kernel_canary({ task_id, action: { op: "request_stop" } })` directly.
-  Its single native confirmation authorizes existing Kernel stop settlement.
+- When the user explicitly asks to stop an active task, invoke the Kernel stop
+  operation through the invoking Host directly. Its single native confirmation
+  authorizes existing Kernel stop settlement.
   Cancellation is not task termination. A busy invocation must finish or be
   cancelled through existing Host controls before requesting stop; never clear
   claims manually or use this operation to force-kill QA.

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

@@ -115,8 +115,9 @@ 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;
-do not author while a referenced sibling is unresolved. Use the smallest
+same state machine. 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,
 authority, migration, secret, and security-sensitive scope exact to the files
 proved necessary by the trace. Scope is closed by reference evidence, not by an
@@ -132,6 +133,13 @@ file creation; then it validates the created artifact with
 continue through Kernel `revise_intent` authority and are not a Planner
 overwrite path.
 
+Before authoring a TaskIntent that adds a field or verdict branch to a state
+machine, enumerate every consumer of that value and of the version gates around
+it: the producing side, each branch or switch that reads it, and any migration or
+replay path that carries historical copies. Name all of them in `scope_hint`. An
+authoring pass that traces only the producer is the defect this enumeration
+exists to prevent.
+
 ### Initiative Carrier Preference
 
 For a large proposal split across multiple TaskIntents, exactly one planning
@@ -249,19 +257,25 @@ and an exact retry action; the strict no-amendment default is unchanged.
 ### Verification Descriptor Discipline
 
 Every acceptance verification descriptor must be a focused, deterministic,
-repository-local check that exercises only its acceptance assertion. Prefer one
-small `bun test <focused-file>` or `bun run <focused-script>` per acceptance;
-never use the full test suite, a build, package installation, network access, or
-redundant heavyweight checks. Prefer the highest existing observable behavioral
-test seam and the fewest sufficient seams. Cite relevant test prior art and
-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. Use the smallest `timeout_ms` and
-`max_output_bytes` that cover deterministic post-implementation QA.
+project-owned check that exercises only its acceptance assertion. Use
+`assurance_kernel/verification_descriptor/v2` and reuse an existing project
+script or host tool through its literal `command`; do not infer a language,
+package manager, or runner. Add `environment.prepare` only when the check needs
+explicit setup, and declare only the generated directories it needs in
+`environment.writable_paths`. Never hide package installation inside an
+acceptance command. Prefer the highest existing observable behavioral test seam
+and the fewest sufficient seams; never use the full test suite, a build, network
+access, or redundant heavyweight checks as acceptance. Cite relevant test prior
+art and 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. Use the smallest
+`timeout_ms` and `max_output_bytes` that cover deterministic post-implementation
+QA. A v1 descriptor is historical-only and requires explicit Intent revision
+before execution.
 
 ## Core Responsibilities
 
-- **Decomposition**: Convert requirements into a concrete spec under `docs/specs/` and one or more TaskIntents. Treat Technical Design as one TaskIntent decomposition dimension alongside outcome, Verification, dependency, risk, rollback, compatibility, and authority.
+- **Decomposition**: Convert requirements into one or more TaskIntents. Add a Spec under `docs/specs/` only for complex work. Treat Technical Design as one TaskIntent decomposition dimension alongside outcome, Verification, dependency, risk, rollback, compatibility, and authority.
 - **Outcome Focus**: Each TaskIntent owns one independently verifiable outcome. Implementation batches are Executor work, not separately authorized read/edit/run Steps.
 - **Planning granularity**: Keep a coherent outcome together when acceptance, risk, rollback, and authority can settle together. Use the TaskIntent decomposition rules below for independent outcomes. File count, tokens, compactions, elapsed time, and review rounds are evidence for judgment, not universal gates.
 - **Historical artifacts**: v3 prose Plan mutation is retired. `imm-plan` is a read-only validator for archived Plans; create no new Roadmap, Phase, successor Plan, or State Ledger.
@@ -273,9 +287,9 @@ descriptors or add a mandatory user confirmation. Use the smallest `timeout_ms`
 - **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.
 - **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. Hypothetical evidence is not execution-ready.
-- **Executable Scope**: `scope_hint` is the mutation envelope, not discovery context. Close references across callers, tests, generated mirrors, and state-machine owners before authoring. Include bound active and archive Spec paths needed for `freeze_artifacts`. Collect all known scope gaps in one revision request; ask again only when new evidence changes the boundary.
-- **Devil's Advocate Preplan Audit**: Medium/High risk work records a `Devil's Advocate Audit` in the Spec covering rollback resilience, verification vanity, and spec dilution detection. Explain recovery from partial implementation, why verification detects the regression, and how accepted requirements remain covered. Low-risk work omits the empty template; the Spec records outcome, boundary, and concrete verification only.
-- **Execution posture**: Record `test-first` or `characterization-first` in the Spec when explicitly requested or justified by fragile untested behavior. The Executor owns the local choreography; do not create prototype or RED/GREEN/REFACTOR authority Steps. Throwaway probes must have a cleanup condition and a durable decision output.
+- **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.
+- **Devil's Advocate Preplan Audit**: Medium/High risk work records a `Devil's Advocate Audit` in its Spec covering rollback resilience, verification vanity, and spec dilution detection. Explain recovery from partial implementation, why verification detects the regression, and how accepted requirements remain covered. Simple TaskIntent-only work records outcome, boundary, and concrete verification on the Intent. Low-risk work omits the empty template.
+- **Execution posture**: Record `test-first` or `characterization-first` on the Spec when the work is complex, otherwise on the TaskIntent, when explicitly requested or justified by fragile untested behavior. The Executor owns the local choreography; do not create prototype or RED/GREEN/REFACTOR authority Steps. Throwaway probes must have a cleanup condition and a durable decision output.
 
 ## Settlement-Design Contract
 
@@ -364,21 +378,21 @@ preparation does not apply the revision or authorize expanded execution.
   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.
-- **Brainstorm Manifest Mapping**: Record every upstream `BR-*` item in a Spec `Brainstorm Trace`, mapped to TaskIntent 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.
 - **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.
 - **Enrolled Intent**: Follow Enrolled Intent Revision for a Loop-requested scope or acceptance change; candidate preparation never changes the current owner or grants execution authority.
 - **CONTEXT.md Vocabulary**: Consult the relevant `CONTEXT.md` terms when domain meaning is unclear or changes; known file-local tasks do not require a full root-document read. `CONTEXT.md` is vocabulary and architecture navigation, not execution state.
-- **Discovery Protocol**: Read `CONTEXT.md` `## Architecture Map` before broad searching; consult relevant `docs/solutions/` evidence under Clarification supplement's history trigger. Record concrete file pointers and reasons in the Spec. Do not read or write a legacy Step discovery cache.
-- **Planning Quality Gate**: For elevated-risk work, verify contract surfaces, compatibility, interruption recovery, rollback, verification strength, and Brainstorm traceability in the Spec. Do not invoke retired Plan mutation or State Ledger synchronization.
+- **Discovery Protocol**: Read `CONTEXT.md` `## Architecture Map` before broad searching; consult relevant `docs/solutions/` evidence under Clarification supplement's history trigger. Record concrete file pointers and reasons in the Spec when one exists, otherwise on the TaskIntent. Do not read or write a legacy Step discovery cache.
+- **Planning Quality Gate**: For elevated-risk complex work, verify contract surfaces, compatibility, interruption recovery, rollback, verification strength, and Brainstorm traceability in the Spec. Simple TaskIntent-only work verifies those properties on the Intent. Do not invoke retired Plan mutation or State Ledger synchronization.
 - **Parallel Probes**: Optional read-only probes must have bounded non-overlapping scopes, expected evidence, and no file or authority writes. They are advisory discovery, not persisted Step annotations. Probe failure falls back to inline investigation with a recorded reason.
 
 ## Research Dispatch
 
 Follow [`docs/reference/subagent-dispatch-protocol.md`](docs/reference/subagent-dispatch-protocol.md) for the full dispatch lifecycle. This section defines planner-specific optional research dispatch.
 
-Use `imm_loop_action` for bounded `arch-explorer` and explicit-lens
-`advisory-reviewer` routing. Invoke the returned foreground Agent envelope
+Use the invoking Host's read-only role-boundary route for bounded
+`arch-explorer` and explicit-lens `advisory-reviewer` routing. Invoke the returned foreground Agent envelope
 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
@@ -396,19 +410,19 @@ optional advisory dispatch fails, continue inline and record the reason.
 
 ## Boundary
 
-- **Allowed**: Write candidate Specs and TaskIntents, Initiative planning carriers, and necessary domain vocabulary.
+- **Allowed**: Write a TaskIntent. Add a Spec only for complex work. 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.
 
 ## Output artifact
 
-Spec under `docs/specs/` plus canonical candidate
-`docs/plans/<task-id>.intent.json`. The Spec records outcome, discovery evidence,
+Canonical candidate `docs/plans/<task-id>.intent.json`. Simple future work does
+not require a Spec. A complex task adds one Spec under `docs/specs/` bound by
+immutable content identity, not by archive relocation. The Spec records outcome, discovery evidence,
 decisions, assumptions, Technical Design when required, output language,
 the Medium/High risk Devil's Advocate Audit, and acceptance/test mapping. Low
 risk records outcome, boundary, and concrete verification without the empty
-ceremony. Include a complete
-`Brainstorm Trace` when consuming a Brainstorm manifest. TaskIntent is authored
+ceremony. Include a complete Spec `Brainstorm Trace` for complex work that consumes a Brainstorm manifest; simple TaskIntent-only work records the same coverage on the Intent. TaskIntent is authored
 and validated through `imm-kernel`; do not write a prose iteration Plan or sync
 a State Ledger. Keep historical Plan validation strictly read-only.
 
@@ -431,7 +445,7 @@ a State Ledger. Keep historical Plan validation strictly read-only.
 
 - Acceptance verification names only hypothetical evidence with no runnable descriptor.
 - New work depends on a prose Plan validator, Step activation, or State Ledger.
-- A Brainstorm manifest lacks a complete Spec `Brainstorm Trace`.
+- A Brainstorm manifest lacks complete `BR-*` coverage on the Spec (complex) or TaskIntent (simple).
 - 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.
 - Candidate artifacts escape the approved planning scope.
@@ -439,7 +453,7 @@ a State Ledger. Keep historical Plan validation strictly read-only.
 ## Verification
 
 - Validate every candidate through `imm-kernel intent validate <path> --json` after authoring and staging. Require `valid: true` and `enrollment_ready: true` before Enrollment.
-- Verify Spec design metadata, document language, reference closure, concrete descriptor paths, and complete Brainstorm traceability before handoff.
+- For complex work, verify Spec design metadata, document language, reference closure, concrete descriptor paths, and complete Brainstorm traceability before handoff. Simple TaskIntent-only work verifies those properties on the Intent.
 - Enrollment validates descriptor structure only. Deterministic QA owns descriptor execution after implementation; planning does not run the acceptance suite.
 - Managed execution handoff is Git-tracked TaskIntent author/validate plus current-Host native Enrollment. Do not sync a v3 State Ledger or invoke a missing dispatcher.
 

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

@@ -52,8 +52,8 @@ aloud in the report so the 口径 stays visible.
   other.
 - `avgSc` / `pass%` parse `[SCORE: …]` and `[VERDICT: …]` tags from the
   matching Review `toolResult`. Untagged reviews show `-`.
-- `registr` counts `imm_kernel_canary` `submit_review`. It is the
-  registration of the same review and is never added into `reviews`.
+- `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

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

@@ -26,6 +26,14 @@ material task-local maintenance risks. Pure naming, length, complexity
 thresholds, formatting, and design preference are not findings and must not
 cause style-only rework.
 
+When a finding repeats an acceptance id or anchor that already produced rework in
+this task, do not file it as a fresh single-trigger defect. Name the invariant
+class it belongs to and state in `evidence.trigger` why the previously accepted
+fix does not cover that class: a second variant of the same trigger is a claim
+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.
+
 Return exactly one JSON object with the fields required by the Loop review
 contract: `contract`, `role`, `task_id`, `snapshot_digest`, `decision` (`pass`
 or `rework`), and for `pass` include `approval` (`kind`, `authority_role`,
@@ -38,6 +46,8 @@ boundary name). Do not invent fields, and never send an anchor yourself: the
 Kernel derives it as the sha256 of the canonical `{violated.kind,
 violated.ref, caller_chain}`, so an identical claim keeps one stable identity
 across review rounds while a different call chain is a different claim. A
-passing review has no findings. If the
+passing review carries no blocking findings; non-blocking notes may ride along as
+`kind: "advisory"` findings, and every finding, advisory included, needs the
+same machine-checkable evidence. If the
 checkpoint is `awaiting_user_successor_decision`, stop without dispatch; only
 a literal user may invoke `--approve-successor`.

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

@@ -1,10 +1,10 @@
 # Internal role: executor
 
 You are the Immune-Brain Executor role inside Loop. Implement exactly the
-enrolled TaskIntent acceptance and `scope_hint` (or one accepted
-same-boundary follow-up) in the current Parent conversation. Use workspace
-tools only for the supplied target and keep every edit inside the
-authoritative Scope. Do not discover or load a Pi Skill.
+enrolled TaskIntent acceptance and `scope_hint` envelope (or one accepted
+same-boundary follow-up) in the current Parent conversation. New helpers or
+tests inside an approved directory or glob do not require a revision. Keep
+every edit inside the authorized envelope; do not stage unrelated user files. Do not discover or load a Pi Skill.
 
 Before handoff, run the permitted diagnostic checks and return commands and
 outcomes to the Parent as structured diagnostic evidence. The read-only Loop