immune-brain 3.6.5 → 3.6.7

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

@@ -23,7 +23,7 @@ Apply the gate when the task touches one or more of these surfaces:
 - **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.
-- **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. Every new or revised Spec records `**Diagram decision**: required|not_required` and a non-empty `**Diagram reason**:`. A `required` decision must include Mermaid; `not_required` explains why prose is sufficient.
+- **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`.
 - **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.

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

@@ -104,7 +104,7 @@ Parent workflow role 必须：
 4. 把 partial/error 标记为 `degraded`。
 5. 保留自身 baseline review，不把最终判断权交给 child。
 
-普通 advisory/discovery 的每次启动都消耗一个 candidate budget slot；失败、取消、timeout 或 result_untrusted 均丢弃该输出且不得自动重试。Parent 仅在剩余候选仍独立有用且 evidence budget 仍需要时继续，否则转 solo/fail-closed fallback，并记录 `dispatch_failed` 或 `child_timeout`。该规则不改变 Kernel authority Review 的显式恢复协议。Child 永远不获得实现、Plan write、workflow mutation 或 QA closure authority。
+普通 advisory/discovery 的每次启动都消耗一个 candidate budget slot；失败、取消、timeout 或 result_untrusted 均丢弃该输出且不得自动重试。Parent 仅在剩余候选仍独立有用且 evidence budget 仍需要时继续，否则转 solo/fail-closed fallback，并记录 `dispatch_failed` 或 `child_timeout`。Read-only eligibility 与 Pi 的 one-foreground-child 调度限制是两回事：只读调查可同时存在多个待派发候选，但实际执行仍逐个 foreground child 串行消费，不得把多个 foreground Agent 假定为并发 batch。该规则不改变 Kernel authority Review 的显式恢复协议。Child 永远不获得实现、Plan write、workflow mutation 或 QA closure authority。
 
 If Kernel Review dispatch fails, the Parent does not call `submit_review`; the existing Review reservation and immutable evidence remain available for a later foreground retry. A malformed verdict may be corrected and resubmitted. A stale snapshot, explicit release, successful settlement, or session shutdown removes the reservation and evidence. There is no retry counter, dispatch receipt state machine, or provider-specific recovery path.
 

package/plugins/immune-brain/dist/imm-agent-doc-maintain.md

@@ -1,6 +1,6 @@
 ---
 name: imm-agent-doc-maintain
-description: Use to minimize tracked AGENTS.md, CLAUDE.md, and GEMINI.md files to necessary non-discoverable context after an explicit, hash-bound, user-approved manifest; never installs or validates project contracts.
+description: Use when the user explicitly requests Immune-Brain minimization of tracked AGENTS.md, CLAUDE.md, or GEMINI.md.
 ---
 
 # Immune-Brain: Agent Doc Maintain
@@ -37,6 +37,8 @@ commit.
 
 ## Ordered Maintenance Protocol
 
+### Inventory and Manifest
+
 1. **Establish repository safety.** Mutation requires a Git worktree. Only
    tracked regular files named exactly `AGENTS.md`, `CLAUDE.md`, or `GEMINI.md`,
    at the repository root or in nested tracked directories, are candidates.
@@ -100,6 +102,8 @@ commit.
    repository scope or declared precedence are `BLOCKED`. Filename convention,
    nesting, or guessed host behavior alone may not resolve a conflict.
 
+### Manifest Approval and Recovery
+
 7. **Produce one exact manifest.** `audit` mode stops after the manifest.
    Mutation mode also stops until the literal user approves exact manifest
    entries (for example, "all recommendations except 4 and 7"). Broad approval
@@ -107,6 +111,8 @@ commit.
    no manifest is persisted. No fixed line, byte, percentage, or Token target
    authorizes removal.
 
+### Approved Mutation
+
 8. **Revalidate and mutate minimally.** Re-read candidate bytes, Git status,
    content hash, references, precedence evidence, and active scope immediately
    before each approved change. Drift blocks that item. Never execute commands
@@ -116,6 +122,8 @@ commit.
    basics, and explicit user requirements are never simplified away for
    brevity.
 
+### Verify and Report
+
 9. **Verify and report.** Re-scan modified instruction relationships, local
    pointer targets, duplicate retained meanings, unresolved conflicts,
    source/package public-surface parity, existing focused documentation

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

@@ -1,6 +1,6 @@
 ---
 name: imm-brainstorm
-description: Use when clarifying scope.
+description: Use when the user explicitly requests Immune-Brain requirement clarification.
 ---
 
 # Immune-Brain: Brainstormer
@@ -17,46 +17,47 @@ This skill adheres to the **[BASELINE.md](BASELINE.md)**.
 
 ## Invocation modes
 
-`imm-brainstorm` is the canonical exhaustive clarification owner. Its modes share
-one interaction protocol:
+`imm-brainstorm` owns proportionate clarification. Its modes share decision
+provenance and authority constraints:
 
-- `default`: traverse the full sourced design tree.
+- `default`: resolve facts and delegated choices; ask only material unresolved decisions.
 - `roundtable`: add bounded multi-role perspectives, visible agreement and
   disagreement, and decision criteria.
 - `adversarial`: add high-pressure security, migration, rollback, verification,
   audit, and cross-boundary analysis.
 
-All modes produce the same `brainstorm_framing` shape and use the same
-exhaustive frontier protocol. `roundtable` and `adversarial` are analysis lenses
+All modes produce the same `brainstorm_framing` shape. `roundtable` and `adversarial` are analysis lenses
 only when explicitly selected by the user; model task-type or risk
-classification never selects them. Failure, edge, rollback, compatibility,
-migration, and risk branches remain part of `default` traversal.
+classification never selects them. Exhaustive interviewing requires an explicit
+request for thorough interrogation; selecting a lens alone does not require it.
 
-## Default exhaustive decision tree
+## Default clarification
 
-Exhaustive means every sourced current-goal branch, not a fixed question count.
 Every branch must trace to the current user request, repository evidence, or a
-settled parent decision. Seed the fixed framing roots: goal, beneficiary and
-scenario, current state, desired behavior, scope and non-goals, constraints,
-failure and edge behavior, compatibility and migration, success and
-Verification, and deferred items. Expand them dynamically after every answer.
-Do not use materiality, task type, or risk classification to decide whether a
-sourced user decision is worth asking.
-
-Classify each unresolved node only as a repository fact or a user-owned decision.
-Resolve facts with bounded, on-demand read-only evidence. If evidence is
-unavailable, record a blocked fact and block only its dependent subtree; never
-turn the fact into a user preference. Place every sourced user decision on the
-current frontier.
+settled parent decision. For a clear request, use a zero-question fast path when
+no material decision or required fact remains unresolved. Do not seed or expand
+a complete tree by default. Failure, compatibility, rollback, and risk questions
+are relevant when evidence shows they can change the current outcome.
+
+Classify each unresolved node as a repository fact, a delegated technical
+choice, or a material user-owned decision. Resolve repository facts with
+bounded, on-demand read-only evidence. If evidence is unavailable, record a
+blocked fact and block only its dependent subtree; never turn the fact into a
+user preference. A delegated technical choice is verifiable through existing
+conventions, a reversible local probe, or an existing recorded decision when it
+does not change the goal, scope, observable behavior, compatibility, risk
+acceptance, or a protected effect; resolve it with evidence and record the
+chosen assumption instead of asking. When a technical choice does change one of
+those, it is material and belongs on the user frontier. Place every material
+user-owned decision on the current frontier.
 
 Ask every independent question on the complete currently unblocked frontier
 together. Hold downstream questions until their prerequisites are decided.
 Number every question, include grounded options and one recommended answer with
 a short reason, and accept bulk approval of all recommendations with explicit
-exceptions. Direct requirements and adopted recommendations settle only the
-current nodes; they never complete the Brainstorm session by themselves.
-Recompute the tree after every response and continue through newly unlocked
-downstream branches.
+exceptions. Direct requirements and adopted recommendations settle their
+decisions without another approval round. After an answer, ask again only for
+a newly evidenced material decision, not to manufacture further rounds.
 
 Minimally clarify an ambiguous answer while independent branches continue. If a
 later answer or new fact invalidates an earlier choice, reopen only that decision
@@ -64,13 +65,13 @@ delta and explain the new evidence. An explicit defer stops its subtree and is
 recorded as `BR-DEFER-*`; if the subtree still changes the current Result,
 interface, or compatibility, explain why it cannot be deferred.
 
-Brainstorm finishes only when the frontier is empty and no blocked fact prevents
-traversal. A zero-question fast path is valid only when the complete seeded and
-dynamically expanded tree contains no unresolved user decision. If the user
+Brainstorm finishes when the material decision frontier is empty and no blocked
+fact prevents the current handoff. Independent framing may continue while a
+dependent subtree is blocked. If the user
 stops early, record every open node as `BR-Q-*` and do not mark the framing
 planning-ready.
 
-When traversal completes, present a concise result-only summary as a
+When clarification completes, present a concise result-only summary as a
 non-blocking correction window. Do not ask the user to reconfirm decisions
 reflected without change. If the summary introduces or changes a
 decision, ask for explicit confirmation of only that decision delta
@@ -79,16 +80,29 @@ confirms a proposed direction or scope. Persist only final decisions: map them
 to `BR-REQ-*`, `BR-DEC-*`, `BR-OUT-*`, `BR-DEFER-*`, and resolved `BR-Q-*`
 manifest entries; do not copy the question transcript into repository artifacts.
 
+## Explicit exhaustive interrogation
+
+Read this section only when the user explicitly requests thorough or exhaustive
+interrogation. Exhaustive means every sourced current-goal branch, not a fixed
+question count. Seed the fixed framing roots: goal, beneficiary and scenario,
+current state, desired behavior, scope and non-goals, constraints, failure and
+edge behavior, compatibility and migration, success and Verification, and
+deferred items. Recompute the tree after every response and traverse newly
+unlocked downstream branches. Adoption closes current nodes, not unexplored
+branches. Resolve facts and delegated choices locally; ask material user-owned
+decisions. Stop when the sourced tree is traversed and its material frontier is
+empty, or report remaining blocked/open nodes if the user stops early.
+
 ## Workflow Rules
 
-- **Trigger Shape**: Use when product framing is still needed. Direct Planner entry remains available for a clear request, but once the user invokes Brainstorm, do not short-circuit its exhaustive traversal because an initial frame appears clear. Do not add a second confirmation for an unchanged final summary.
-- **Decision Provenance**: Traverse every sourced current-goal branch. A concrete scenario is a branch when the request, repository, or a settled parent decision makes it relevant; do not invent speculative future needs.
+- **Trigger Shape**: Explicit Brainstorm entry permits proportionate clarification, including a zero-question handoff for a clear request. Read the exhaustive protocol only on an explicit request for thorough interrogation. Do not add a second confirmation for an unchanged final summary.
+- **Decision Provenance**: Investigate evidenced current-goal uncertainty. A concrete scenario is relevant when the request, repository, or a settled parent decision makes it material; do not invent speculative future needs.
 - **Dependency-Aware Rounds**: Ask every independent question on the complete currently unblocked frontier together. Ask fewer questions only because dependencies keep downstream branches blocked, never because of an arbitrary question budget.
 - **Read-only by default**: Inspect context and summarize the problem. do not implement inside this skill.
 - **Handoff**: Write concise design notes under `docs/brainstorms/` only if explicitly requested.
 - **Handoff Manifest**: When framing is stable, user-confirmed, and routes to planner, include a compact `Brainstorm manifest` with stable IDs for every planner-relevant item: `BR-REQ-*` for confirmed requirements, `BR-DEC-*` for confirmed decisions, `BR-OUT-*` for non-goals, `BR-DEFER-*` for explicitly deferred items, and `BR-Q-*` for open questions. The manifest is the closed-world handoff; the planner must account for every ID instead of relying on prose memory.
-- **Default Next Route**: Route to `imm-planner` only when the full frontier is empty, no blocked fact prevents traversal, and every sourced user decision is settled by a direct requirement, explicit answer, or adopted recommendation. Those inputs close their nodes but never the session. An unchanged final summary is a correction window, not another gate. If Brainstorm introduces a new decision, ask for that delta and do not name `imm-planner` as the current next skill.
-- **Subagents**: Follow the Adaptive Cache-First Route in `docs/reference/subagent-dispatch-protocol.md`: classify the task, check cache-first discovery pointers, and carry subagent split pressure forward only when the Cost-Based Subagent Gate says parallel research is worth the coordination cost. User explicitly wants solo fallback when split is impossible.
+- **Default Next Route**: Route to `imm-planner` when the material frontier is empty, no required fact blocks the handoff, and every material user decision is settled by a direct requirement, explicit answer, or adopted recommendation. An unchanged final summary is a correction window, not another gate. If Brainstorm introduces a new decision, ask for that delta and do not name `imm-planner` as the current next skill.
+- **Subagents**: Only when optional research is needed, read Research Dispatch and its shared dispatch reference. Default to inline evidence gathering; do not load dispatch instructions merely because Brainstorm was invoked.
 - **Rejected Decision Evidence**: Use on-demand rejected-decision evidence instead of a global preflight. When a live branch resembles a rejected decision, resolve its recorded reason and optional `reconsider_if` conditions through code/docs inspection before asking the user. Treat each `reconsider_if` list item as an independently sufficient trigger (OR semantics): if available evidence satisfies none, keep the rejection as a current constraint or non-goal without re-litigation; if evidence satisfies one, reopen the decision and cite the condition plus changed evidence; if a condition cannot be resolved, ask only for that concrete missing fact. When `reconsider_if` is absent, preserve the backwards-compatible "what has changed?" fallback after inspection. When `rejection_reason` is absent, inspect an explicit rejection-reason section in the body; if no reason exists, report the metadata gap without inventing a reason or reconsideration condition.
 - **CONTEXT.md Awareness**: When the user uses vague or conflicting domain terms, check `CONTEXT.md` at the repo root. If a canonical term exists, surface the conflict: "CONTEXT.md defines X as Y, but you seem to mean Z — which is it?" If CONTEXT.md does not exist, note the gap and recommend the planner create it during planning. Use CONTEXT.md vocabulary in the output artifact when available.
 - **Discovery Protocol**: Before broad searching, read `CONTEXT.md` `## Architecture Map` and the active `.imm/memory/current_iteration.json` step `discovery_cache` when present. Use matching `docs/solutions/` `key_files` frontmatter as the pattern layer. If these pointers are missing or stale, note the discovery gap in the framing instead of compensating with unbounded search.
@@ -135,6 +149,6 @@ Default user-facing shape: `Conclusion -> Scope -> Next Action`. For the normal
 
 ## Next Action
 
-- Gate: The exhaustive frontier is empty; no blocked fact prevents traversal; every sourced user decision is settled by a direct requirement, explicit answer, or adopted recommendation; and the result-only summary introduces no unconfirmed decision delta. **If any requested clarification remains unanswered, you MUST NOT proceed to planning or suggest the next skill.** **If a decision delta is still unconfirmed, you MUST NOT proceed to planning, must not name a next skill, and should ask the user to confirm only that delta.**
+- Gate: The material frontier is empty; no required fact blocks the handoff; every material user decision is settled by a direct requirement, explicit answer, or adopted recommendation; and the result-only summary introduces no unconfirmed decision delta. **If any required clarification remains unanswered, you MUST NOT proceed to planning or suggest the next skill.** **If a decision delta is still unconfirmed, you MUST NOT proceed to planning, must not name a next skill, and should ask the user to confirm only that delta.**
 - If gates pass: suggest `imm-planner` with a one-line reason.
 - If gates are not met: state which questions or decision deltas remain open; do not name a next skill and wait for the user's answer.

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

@@ -1,6 +1,6 @@
 ---
 name: imm-doc-prune
-description: Use to prune stale current documentation from a Git repository after an explicit, hash-bound, user-approved manifest; never deletes Managed authority artifacts.
+description: Use when the user explicitly requests Immune-Brain pruning of stale current documentation.
 ---
 
 # Immune-Brain: Doc Prune
@@ -36,6 +36,8 @@ no persistent report, and no automatic commit.
 
 ## Ordered Pruning Protocol
 
+### Inventory and Manifest
+
 1. **Establish repository safety.** Mutation requires a Git worktree. A
    non-Git repository or an untracked candidate is audit-only. Record the
    candidate path, blob/content hash, tracked status, and candidate-local
@@ -91,6 +93,8 @@ no persistent report, and no automatic commit.
    "clean stale docs" is insufficient. Interruption starts a fresh scan; no
    manifest is persisted.
 
+### Approved Mutation
+
 9. **Revalidate and mutate minimally.** Re-read candidate bytes, Git status,
    inbound references, generated ownership, and active scope immediately
    before each approved change. Drift blocks that item. Delete a whole file
@@ -99,6 +103,8 @@ no persistent report, and no automatic commit.
    owner before deleting the obsolete source. Never renumber ADRs and never
    create a new ADR or Solution merely to complete pruning.
 
+### Verify and Report
+
 10. **Verify and report.** Re-scan residual names and paths, current local
     links on current documentation, source/generated parity, existing documentation contract tests,
     and `git diff --check`. This Skill does not execute arbitrary documented

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

@@ -1,6 +1,6 @@
 ---
 name: imm-loop
-description: Use to run an enrolled TaskIntent to completion through Kernel-governed execution, QA, and Review.
+description: Use when the user explicitly requests execution or resumption of an Immune-Brain task.
 ---
 
 # Immune-Brain: Loop
@@ -16,7 +16,12 @@ 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` for its Initiative. `tracker_projection_failed` or
+returned `tracker_associated` — but only when the candidate belongs to an
+identified GitHub-carried Initiative. Standalone TaskIntents and Local
+Initiatives carry no tracker prerequisite: their Enrollment needs only the
+validated candidate. When membership is uncertain, resolve it against the
+Planner's carrier decision before treating the candidate as exempt; do not
+assume either way. For a GitHub-carried Initiative, `tracker_projection_failed` or
 `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,
@@ -36,7 +41,7 @@ At every internal role boundary call the read-only `imm_loop_action` Tool. Use
 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.
-Follow the [Subagent Dispatch Protocol](docs/reference/subagent-dispatch-protocol.md#authorization-authority).
+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
 maintenance entries, never dispatched as the Loop role. Internal `test-fixer`
@@ -65,8 +70,12 @@ Continue while the current projection has a valid action:
 6. 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. Stop on terminal `done` or `stopped`, unresolved user decisions, explicit
-   cancellation, or a failure without a safe projected action.
+7. 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
+   continue from the returned projection. Stop on terminal `done` or `stopped`,
+   explicit cancellation, or a failure without a safe projected action.
 
 Use the fresh projection returned by a successful operation when supplied. Read
 `status` after interruption, ambiguous mutation results, absent projections, or
@@ -74,12 +83,37 @@ suspected external changes. Never repeat a mutation merely to obtain its result.
 Kernel CAS and freshness checks remain mandatory; reducing Parent reads does
 not bypass them. Do not poll or create detached jobs.
 
+## Unattended Batch Opt-In
+
+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,
+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.
+
+Invoking it authorizes only a user-confirmed batch of already-planned child
+TaskIntents. The Host projects the batch plan from the Initiative's published
+children, excludes every `critical` child, renders the ordered child list, budget,
+and plan digest through its native confirmation, and issues one Kernel Batch
+Authorization for that exact plan. The extension mints no capability and owns no
+batch state transition: the shared `startBatch` driver in
+`runtime/unattended/` owns every batch transition, and each child is still
+enrolled, assured, and settled by the Kernel under an ordinary TaskRecord.
+
+Batch execution never pushes a ref, opens or updates a pull request, resolves a
+user decision, or creates, switches, or deletes a Git worktree. Its sole Git
+effect is the batch branch `imm/<initiative-slug>` plus one scope-bounded commit
+per completed child.
+
 ## Decisions and Recovery
 
-- Scope expansion always returns to `imm-planner`. Collect all currently known missing
-  paths, caller/test/generated mirrors, and verification reasons in one request.
-  Do not edit outside scope while waiting or widen it piecemeal without new
-  evidence. Bounded test or PR repair stays inside the same TaskIntent.
+- Scope expansion returns to Planner's Enrolled Intent Revision route. Planner
+  prepares the complete proposed revision without replacing the active owner;
+  the current Loop submits it through Kernel revision authority. Collect all
+  currently known missing paths, caller/test/generated mirrors, and verification
+  reasons in one request. Do not edit outside scope while waiting or widen it
+  piecemeal without new evidence. Bounded test or PR repair stays inside the same
+  TaskIntent.
 - Invoke `approve_breaking_intent_revision` with the complete next intent
   directly; the native Host gate is the single user decision. Do not overwrite
   enrolled intent sidecars or ask for chat pre-confirmation.
@@ -123,8 +157,6 @@ The internal Compounder is optional: only closed work with structured evidence
 of a reusable Learning may route to it. Routine completion creates no Learning.
 It cannot approve successors or delay terminal settlement. A projection with
 `recommended_authority: user` must not dispatch successor work automatically.
-Do not create, switch,
-or delete Git worktrees; operate only in the Host launch directory.
 
 The Host may attach an opted-in GitHub projection after settlement. Only a fresh claimless
 `done`/`stopped` projection plus its exact terminal tombstone projects
@@ -151,6 +183,8 @@ Stop reason:
 Next action:
 ```
 
+## Failure Output
+
 For `settlement_unknown`, call `advance_assurance` once to reconcile the Kernel
 projection before resuming; never replay the uncertain write directly. The runtime
 retries only explicit `EINTR`/`EAGAIN` failures of its initial projection read, once,

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

@@ -1,6 +1,6 @@
 ---
 name: imm-planner
-description: Use to create or revise a spec and TaskIntent from requirements; owns scope and decomposition, not implementation or Enrollment.
+description: Use when the user explicitly requests Immune-Brain Spec and TaskIntent planning.
 ---
 
 # Immune-Brain: Planner
@@ -16,8 +16,8 @@ an explicit `imm-loop` entry; explicit Planner entry owns planning and the later
 native Enrollment gate.
 
 Plan-only output remains non-authoritative. Planner creates or validates a
-candidate Spec/TaskIntent, but it never enrolls a task or enrolls generated
-artifacts unconditionally. Explicit Plan-only requests stop after returning the
+candidate Spec/TaskIntent. Planner may request the native Enrollment gate;
+only that gate grants execution authority. Explicit Plan-only requests stop after returning the
 planning artifacts. A later literal-user request to start Enrollment is a
 non-authoritative execution trigger: invoke the native Enrollment gate directly,
 without asking for chat pre-confirmation. For a clear mutation request that
@@ -32,9 +32,10 @@ cannot bypass that boundary, QA, Review, authorization, or completion.
 ## Clarification supplement
 
 Planner consumes an upstream Brainstorm manifest as closed-world framing and
-must not repeat, reopen, or rewrite confirmed decisions. Direct Planner entry
-and Medium/High Design Risk work must inspect relevant ADRs and rejected
-Learnings. It resolves repository facts, performs reference closure, and owns
+must not repeat, reopen, or rewrite confirmed decisions. Consult relevant ADRs
+and rejected Learnings only when an architectural decision, known historical
+constraint, or conflict with the existing design makes them relevant. Reuse
+upstream evidence; absent relevant history is not a planning blocker. It resolves repository facts, performs reference closure, and owns
 ordinary technical choices:
 component boundaries, internal interfaces, failure behavior, compatibility,
 migration, recovery and rollback, Verification, execution slices, dependencies,
@@ -71,15 +72,16 @@ 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 routes to `imm-loop` for foreground Kernel Tool
-  coordination, not new planning;
+- an active Kernel claim remains with `imm-loop` 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;
 - no routing policy preserves the legacy v3 Planner behavior;
 - a valid `kernel_task_intent` retirement policy produces one TaskIntent draft
   through the current Host's explicit `imm-planner`;
 - an invalid, unreadable, untracked, or tracked-deleted policy rejects new
   planning authority with `routing_policy_invalid`;
-- no Planner path enrolls a task or falls back to v3 after retirement.
+- no Planner path grants execution authority or falls back to v3 after retirement.
 
 Current owner, phase, completion, and authority facts are authoritative only
 when read from the Assurance projection and TaskRecord. `CONTEXT.md` is
@@ -105,6 +107,11 @@ workspace claim, and final authority preconditions without executing acceptance
 descriptors. A routine task proceeds from that single confirmation through
 enrollment, execution and QA without a second human stop.
 
+## Candidate Authoring
+
+Read this section before creating new candidate artifacts, after request routing
+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
@@ -212,6 +219,19 @@ TaskIntent or TaskRecord. Existing Issue markers grant permission only for
 idempotent retry of that same approved Initiative; they never grant execution
 authority.
 
+For amending an already-published Initiative, the same
+`imm-tracker publish-initiative --stdin --json` operation accepts an optional
+`amendment` input after the literal user approves the changed pending frontier.
+Provide the complete approved pending Tasks plus the complete read-only
+historical Child list, each binding the observed `issue_number`, title, body,
+and state at approval. The tracker verifies every bound Issue against that
+baseline before any write, updates only approved pending briefs, converges the
+exact approved pending `blocked_by` set, creates newly added pending Children,
+and preserves historical Children byte-for-byte with their native Sub-issue
+links and dependency relations. Omitted membership, baseline drift, or a
+stopped historical prerequisite fails closed with zero or bounded mutations
+and an exact retry action; the strict no-amendment default is unchanged.
+
 ### Verification Descriptor Discipline
 
 Every acceptance verification descriptor must be a focused, deterministic,
@@ -237,10 +257,10 @@ descriptors or add a mandatory user confirmation. Use the smallest `timeout_ms`
 - **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.
-- **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. Every new or revised Spec records `**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.
+- **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**: Record 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.
+- **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.
 
 ## Settlement-Design Contract
@@ -294,21 +314,36 @@ state coverage, and verification cues for desktop and mobile. Use `Standard` or
 The mode produces an
 implementation-ready contract and routes it to normal planning or execution.
 
+## Enrolled Intent Revision
+
+Use this route instead of new-task planning when the current Loop requests a
+scope or acceptance revision. Planner prepares the complete proposed revision
+from the requested delta and concrete evidence without replacing the active
+owner. Keep unaffected decisions; include all known scope, Spec, and acceptance
+changes in the proposal. Preserve the prior on-disk sidecars until Kernel applies
+the revision; do not overwrite the enrolled TaskIntent, invoke the new-intent
+author command, or request a second Enrollment.
+
+Return the proposal to the current Loop owner for Kernel `revise_intent` or,
+when breaking, `approve_breaking_intent_revision` with the complete next intent.
+The native gate is the single user decision for a breaking revision; candidate
+preparation does not apply the revision or authorize expanded execution.
+
 ## 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.
 - **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.
-- **Small-scope budget discipline**: For small or fixture-sized planning tasks,
-  read the named files and root orientation files first (`README.md`,
-  `CONTEXT.md`, `IMMUNE.md`, `HANDOFF.md`, active tests/docs). Avoid broad
-  `rg --files`, plugin `skills/`, plugin `dist/`, generated logs, and
-  unrelated directories until a specific missing fact blocks plan validation.
-- **Decision History Discovery**: Direct Planner entry and Medium/High Design
-  Risk work must inspect relevant ADRs and rejected Learnings. Reuse constraints
-  already covered by an upstream Brainstorm manifest instead of repeating that
-  discovery.
+- **Small-scope budget discipline**: Read the named files first for small or
+  fixture-sized planning tasks. Read relevant orientation documents and follow
+  caller, test, or generated-reference links when a concrete missing fact requires
+  them; root documents are not a fixed preflight checklist. Before broad searching,
+  consult `CONTEXT.md`'s Architecture Map. Avoid repository-wide listings and
+  unrelated directories when targeted evidence resolves the task. Required
+  authority, security, and shared-contract reference closure still applies.
+- **Decision History Discovery**: Apply Clarification supplement's conditional
+  history lookup; reuse upstream evidence rather than repeating discovery.
 - **Testing Seam Selection**: 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
@@ -317,10 +352,10 @@ implementation-ready contract and routes it to normal planning or execution.
 - **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.
 - **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**: Follow the Adaptive Cache-First Route in `docs/reference/subagent-dispatch-protocol.md`: classify the task, use cache-first discovery evidence, and add subagent participation only when the Cost-Based Subagent Gate says the slice is multi-domain, high-risk, explicitly requested, or has concrete `parallel_probes`. Plan conditional reviewers such as `security-reviewer` only if their trigger surfaces are explicit; do not manufacture them.
-- **Enrolled Intent**: Planner never overwrites an enrolled TaskIntent. Scope or acceptance changes use Kernel revision authority; breaking revisions invoke the native gate directly with the complete next intent. Preserve the prior on-disk sidecars until Kernel applies the revision.
-- **CONTEXT.md Vocabulary**: Read `CONTEXT.md` at the repo root. Use canonical terms in Spec, acceptance, and scope descriptions. `CONTEXT.md` is vocabulary and architecture navigation, not execution state.
-- **Discovery Protocol**: Read `CONTEXT.md` `## Architecture Map` before broad searching and relevant `docs/solutions/` evidence. Record concrete file pointers and reasons in the Spec. Do not read or write a legacy Step discovery cache.
+- **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.
 - **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.
 
@@ -356,7 +391,9 @@ optional advisory dispatch fails, continue inline and record the reason.
 Spec under `docs/specs/` plus canonical candidate
 `docs/plans/<task-id>.intent.json`. The Spec records outcome, discovery evidence,
 decisions, assumptions, Technical Design when required, output language,
-`Devil's Advocate Audit`, and acceptance/test mapping. Include a complete
+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
 and validated through `imm-kernel`; do not write a prose iteration Plan or sync
 a State Ledger. Keep historical Plan validation strictly read-only.
@@ -373,15 +410,15 @@ a State Ledger. Keep historical Plan validation strictly read-only.
 | Split one outcome into read/edit/run micro-steps | One TaskIntent owns one closable outcome; Executor owns implementation batches. |
 | Append repair outside scope | Return the complete known scope delta for Kernel revision; do not widen execution. |
 | Drop a brainstorm-confirmed item as "out of scope" without saying so | Closed-world handoff: every `BR-*` ID must be covered, decisioned, deferred, scoped out with reason, or resolved as an assumption. |
-| Start planning while brainstorm questions are open | **Clarification Barrier**: Planning is blocked until all `BR-Q-*` items are answered; do not speculate on missing product info. |
-| Skip adversarial self-review because the plan is small | **Devil's Advocate** audit still checks rollback resilience, verification vanity, and spec dilution before the plan is treated as execution-ready. |
+| Finalize dependent planning while brainstorm questions are open | **Clarification Barrier**: Finalization and dependent commitments are blocked until required `BR-Q-*` items are answered. Independent investigation and explicitly unapproved alternative drafts may continue; silence is not consent. |
+| Skip adversarial self-review on Medium/High risk because the plan is small | **Devil's Advocate** audit still checks rollback resilience, verification vanity, and spec dilution before the plan is treated as execution-ready. |
 
 ## Red Flags
 
 - 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 Spec lacks a `Devil's Advocate Audit` covering rollback resilience, verification vanity, and spec dilution detection.
+- 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.
 

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

@@ -1,10 +1,12 @@
 ---
 name: imm-pr-fix
-description: Use to repair GitHub PR review feedback, merge conflicts, or failing CI checks within the current PR scope.
+description: Use when the user explicitly requests Immune-Brain repair of GitHub PR review feedback, merge conflicts, or failing checks.
 ---
 
 # Immune-Brain: PR Fix
 
+## Authority Boundary
+
 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
@@ -66,7 +68,9 @@ not repair blockers.
 
 ### 4. Verify and close out
 
-Run the smallest checks that reproduce each blocker, then any repository check
+Before any push or feedback mutation, apply the BASELINE Host Confirmation
+Boundary to the exact remote effect; the repair request alone does not grant
+unrequested publication authority. Run the smallest checks that reproduce each blocker, then any repository check
 required by the changed surface. Re-read remote PR status, verify local HEAD is
 the expected PR head, inspect the final diff, and push only the repair branch.
 Reply to or resolve handled feedback when GitHub permissions and thread state

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

@@ -30,6 +30,14 @@ 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`,
 `summary`), for `rework` include `findings` (`id`, `kind`, `acceptance_id`,
-`summary`). Do not invent fields. A passing review has no findings. If the
+`summary`, `evidence`). Every rework finding's `evidence` must carry
+`trigger` (the concrete inputs or state that reach the defect), a non-empty
+`caller_chain` (ordered repository paths or symbols), and `violated`
+(`kind`: `acceptance` or `security_boundary`, `ref`: the acceptance id or
+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
 checkpoint is `awaiting_user_successor_decision`, stop without dispatch; only
 a literal user may invoke `--approve-successor`.