immune-brain 3.5.0 → 3.6.0

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

@@ -6,162 +6,146 @@ description: Use to run an enrolled TaskIntent to completion through Kernel-gove
 # Immune-Brain: Loop
 
 This skill adheres to the **[BASELINE.md](BASELINE.md)**.
-At every runtime role boundary, call the read-only `imm_loop_action` Tool. Use
-`route` for active Steps, bounded repair, architecture exploration, advisory
-review, Compounder, Kernel ownership, or scope expansion. Use `dispatch_role`
-for `qa`, `code-review`, and `ui-review`, then invoke the returned foreground
-Agent envelope exactly. Brainstorm and Planner use the same Tool for bounded
-`arch-explorer` and explicit-lens `advisory-reviewer` dispatches. Loop may
-dispatch `compounder` only when a closed Step supplies structured evidence for
-a reusable Learning; routine work without that evidence returns `next: none`
-and creates no Learning. Do not discover or load a Pi Skill for these roles. The Managed Path public entries remain `imm-brainstorm`, `imm-planner`, and `imm-loop`; standalone `imm-pr-fix`, `imm-doc-prune`, and `imm-agent-doc-maintain` are host-native and are never dispatched as the Loop role.
-Dispatch authorization follows the [shared Subagent Dispatch
-Protocol](docs/reference/subagent-dispatch-protocol.md#authorization-authority).
-Same-boundary `follow_up` is not a Plan mutation; it repeats the current
-execution, QA, and originating review gate. All internal Agent dispatch
-envelopes use `run_in_background: false` and return a direct result to the Parent
-before any workflow mutation.
-
-## Workflow Profiles
-
-- `direct` has no Plan or Ledger and never invokes this skill.
-- `standard` keeps execution in the main context, closes a Plan Step when the runtime accepts passing evidence, and therefore does not dispatch the internal QA role per Step. It still dispatches every runtime-required final code/UI review gate. The last gate pass atomically performs internal terminal settlement when `compounder_requirement.required` is false.
-- `strict` preserves the full internal loop: each Step reaches isolated QA before final review, internal Compounder handoff, and terminal settlement. A missing profile is strict.
-- Reviewer `follow_up` targets always retain isolated QA. Standard Plans allow at
-  most two completed/open rounds; `review_budget_state.budget_stop` is a hard
-  stop. Never attempt a third Loop runtime action.
-- `workflow_profile`, `compounder_requirement`, and `review_budget_state` from
-  the live Kernel / Loop projection are authoritative. Do not infer or override
-  them in the host.
-
-## Core Responsibilities
-
-- **Main-context completion loop**: Drive the enrolled Kernel task in the current Host conversation until completion or a safe stop.
-- **Context-preserving execution**: Call `imm_loop_action` with `op: route`, then follow the returned `executor` context in the current Parent conversation. Implement only the active Step or pending same-boundary `follow_up`, then record structured execution evidence through the Loop runtime action. A bounded test failure uses the returned internal `test-fixer` dispatch with its explicit delegated test-file list; PR feedback or CI repair uses the returned internal `pr-fix` dispatch inside the current Plan boundary.
-- **Independent authority isolation**: Use the host `Agent` subagent primitive for `awaiting_qa_decision` and for the exact runtime-reported review gate. Standard Plan Steps close from accepted passing evidence before an internal QA boundary exists; Strict Steps and all follow-ups retain isolated QA. The parent records accepted child decisions through the Loop runtime action.
-- **Observable progress**: Update only at major phase changes: Step start, execution evidence recorded, QA/review result, or terminal stop. Always emit a terminal summary.
-- **Kernel projection authority**: Re-read `imm_kernel_canary` `status` after every persisted action. Conversation memory never overrides the Kernel projection.
-- **External tracker boundary**: The host may attach one opted-in GitHub Issue projection after terminal settlement. Only a fresh claimless `done`/`stopped` projection plus its exact terminal tombstone projects `completed`/`not planned`; Enrollment performs no GitHub projection. Report tracker failures separately, but never treat them as evidence, stop the Loop, repeat a Kernel mutation, or import Issue state.
-- **Scope boundary**: Scope expansion always returns to `imm-planner`; Executor, test repair, and PR/CI repair stop with the concrete missing scope and verification reason instead of widening execution.
-- **Action authority**: The loop always enters through `imm_loop_action`; its projected `next` authority is `executor`, `test-fixer`, `pr-fix`, `arch-explorer`, `advisory-reviewer`, `compounder`, `imm_kernel_canary`, `imm-planner`, or `none`.
-
-## Kernel Loop
-
-Repeat this sequence; do not silently stop while a valid action remains:
-
-1. Call `imm_loop_action` with `op: route` (or `dispatch_role` at a QA/review boundary) and follow the projected `next` authority.
-2. Emit one progress line: `[target][phase] result | next: action`.
-3. Execute exactly one allowed action:
-   - Kernel ownership: call `imm_kernel_canary` for that owned task. Freeze the completed artifacts, then call `advance_assurance`; when it returns `review_ready`, invoke the foreground reviewer and pass its structured verdict to `submit_review`. When the projection calls for `request_authorization` or `approve_breaking_intent_revision`, invoke the exact Tool operation directly without asking the user for chat pre-confirmation; the native host interaction is the single authority decision. Invoke `repair_authority_state` directly for a proven stale claim; Kernel revalidation removes only the redundant claim without user interaction.
-   - Active Step / `rework_needed`: follow the returned `executor` context in the current conversation, implement only the active Step or pending same-boundary `follow_up`, verify, record structured execution evidence through the Loop runtime action, and continue. A bounded test-only repair may request internal `test-fixer` with `focus_delta.specific_changes`; PR review or CI repair may request internal `pr-fix` with the current `plan_id`, changed-file boundary, and verification. Both return child evidence to the Parent and cannot widen scope.
-   - `awaiting_qa_decision`: call `imm_loop_action` with `op: dispatch_role`, role `qa`, the current projection, Plan verification, recorded evidence, and current target identity. Invoke the returned foreground Agent envelope exactly. A `rework` or `replan` must carry validated `notes`.
-   - `review_required`: map the exact `pending_review_gate` (`imm-code-review` or `imm-ui-review`) to the internal `code-review` or `ui-review` role and call `imm_loop_action` with `op: dispatch_role`, passing `pending_review_gate`, `review_changed_files`, and `review_changed_files_signature`. Invoke the returned foreground Agent envelope exactly. Record a validated pass, or open a same-boundary follow-up through the Loop runtime action.
-   - `awaiting_user_successor_decision`: stop immediately with `recommended_authority: user`, no next skill, and no runtime action. This boundary must not dispatch Planner, transition, Compounder, or a new Pi session/subagent. Only a literal user may supply a concrete validated successor Plan through the native authority gate; the internal runtime token is `--approve-successor`, never a public Skill or user-facing entry.
-4. After every accepted runtime write, discard the old snapshot and read a fresh Kernel / Loop projection. Emit a result line only when the write completes a major phase or a subagent round.
-
-Use Pi native `Agent` subagents. Do not spawn Pi child processes or invoke a separate `imm-loop` CLI.
-
-## Authority and Failure Guards
-
-- Implementation requires a validated Plan and active Step or accepted pending `follow_up`.
-- The parent may implement but must not issue its own QA or review pass.
-- QA and reviewer children must not edit files, write Plans, mutate Kernel state, or close decisions directly.
-- Missing `Agent` support, failed or malformed child output, stale child target, runtime write failure, invalid projection, missing credentials, unclear verification, repeated unchanged failure, or user cancellation stops fail-closed with an explicit reason and no decision write.
-- A Managed native authority failure reports its stable reason and exactly one same-Host recovery action. Never recommend another Host, worktree, Direct Path, unmanaged implementation, or automatic retry as a fallback.
-- `replan_needed` stops at `imm-planner`; do not widen scope or rewrite the active Plan. A replacement must use a new sequential Plan path after the current Plan reaches `completed`, or after a literal user explicitly marks it `cancelled` or `superseded`.
-- Plans never suspend, resume, queue, or execute in parallel. Do not insert a repair Plan ahead of the current Plan.
-- Same-boundary review `follow_up` repeats execution, independent QA, and the originating review gate.
-- Runtime `review_required` is the single review-gate authority. Do not invent hidden gates.
-- `imm-compounder` is an internal role and is never invoked as a public Skill. A `complete` projection carries an explicit internal Compounder handoff because the runtime determined it is required. A Standard Plan with optional Compounder is atomically finished by the last review gate and does not emit that handoff. Strict Plans preserve the successful order: current Steps and QA, required reviews, internal Compounder handoff, terminal settlement, then `awaiting_user_successor_decision` for a non-terminal Roadmap slice.
-- Successor approval is non-delegable. QA, review, Planner, Compounder, and the loop cannot approve or activate a successor, and the loop must not turn a command template into an executable successor invocation.
-
-## Stop Conditions
-
-Stop only for:
-
-- `complete` with an explicit internal Compounder handoff before terminal settlement
-- `terminal_plan_complete` after a contracted terminal Plan or a legacy Plan without successor metadata has passed internal Compounder handoff and terminal settlement; stop with no next skill, authority, or action
-- `awaiting_user_successor_decision` after finish, with literal user authority and no automatic action
-- `replan_needed`
-- blocker or required user input
-- runtime, tool, subagent, or output-contract failure
-- user cancellation (no decision write; Plan termination is a separate explicit user-confirmed runtime action)
-- repeated unchanged failure
-- explicit Step, rework, review, follow-up, or elapsed-time budget exhaustion
-
-Session-local budgets are advisory. Persisted Step, QA, review, and follow-up state controls recovery. After interruption, re-enter only by reading a fresh projection: a completed runtime write is honored once; an interrupted pre-write action is not claimed; cancellation performs no decision write; repeated unchanged failure stops unless the next attempt names a strategy change; explicit budgets stop before another action.
-
-## Observable Output Contract
-
-Do not narrate projection reads or routine runtime writes. Emit compact progress only for Step start, completed execution evidence, QA/review decisions, failures that change the plan, and terminal stop. Every subagent round still emits exactly one dispatch line and exactly one collection/result line:
 
-```text
-[Step 1/3][Executor] evidence recorded | next: QA
-[Step 1/3][QA] Agent dispatched
-[Step 1/3][QA] Agent collected: pass | next: imm-code-review
-```
-
-Do not emit a successful collection line for timeout, cancellation, malformed output, or stale identity; emit the explicit failure stop instead.
-
-Every exit, including failure, must include:
+## Kernel Canary Routing and Authority
+
+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.
+
+TaskIntent defines the goal, acceptance, and `scope_hint`; TaskRecord and the
+Kernel projection own lifecycle, artifact state, freshness, and next obligation.
+Conversation memory, GitHub Issues, and `CONTEXT.md` never override them.
+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.
+Follow 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`
+and `pr-fix` repairs remain bounded by the enrolled TaskIntent.
+
+## Execution Loop
+
+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
+   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;
+   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
+   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.
+
+Use the fresh projection returned by a successful operation when supplied. Read
+`status` after interruption, ambiguous mutation results, absent projections, or
+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.
+
+## 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.
+- 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.
+- On `awaiting_user`, invoke `request_authorization` directly. It is reserved
+  for a concrete unresolved decision or explicit stop, not risk tier alone.
+- Invoke `repair_authority_state` directly for a proven stale claim. Kernel
+  revalidation removes only the redundant claim without user interaction.
+- A Managed native authority failure stays fail-closed. Report its stable reason
+  and exactly one same-Host recovery action. Never recommend another Host,
+  worktree, Direct Path, unmanaged implementation, or automatic retry.
+- After interruption, read a fresh projection and run only the pending obligation.
+  A committed QA result is honored; an interrupted precommit QA run produces no
+  approval. Do not rerun fresh QA simply because Review was interrupted.
+- Malformed or stale reviewer output is not a verdict. Keep the existing
+  reservation only if the Host reports it valid; use its exact recovery action.
+  Do not fabricate a pass or blindly redispatch Review.
+- Missing tools, credentials, invalid projections, or repeated unchanged failures
+  stop with a concrete cause. Cancellation performs no decision write and is not
+  task termination. Explicit task stop uses its native authority gate.
+
+## Review and Learning
+
+Reviewers are read-only and bound to the frozen snapshot. They cannot edit files,
+write planning artifacts, mutate Kernel state, or settle decisions. Report all
+substantiated blockers in one round, tied to acceptance or a concrete regression;
+separate optional advice from blockers. Suggestions alone do not justify rework.
+Use the returned verdict schema exactly, including omission of unsupported fields.
+
+`dispatch_role` for `qa`, `code-review`, or `ui-review` is used only when an
+explicit runtime-supported role boundary requests it, followed by the returned
+foreground Agent envelope exactly. It is not an extra gate on Kernel Assurance.
+All internal Agent envelopes use `run_in_background: false`.
+
+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
+`completed`/`not planned`; Enrollment performs no GitHub projection. Report a
+tracker failure separately; never use it as evidence, a Loop blocker, or a reason to
+repeat a Kernel mutation.
+
+## Observable Output
+
+Emit progress at execution start, QA/Review phase changes, failures, and terminal
+stop. Every Agent round has one dispatch line and one result line; never claim a
+successful collection on timeout, cancellation, malformed output, or stale identity.
+Normal conversation and visible Tool calls are the observation surface. Do not
+narrate routine projection reads or add Footer status content.
+
+Every exit includes a concise summary:
 
 ```text
-Plan:
-Completed Steps:
+Task:
+Completed work:
 QA:
 Review:
 Stop reason:
 Next action:
 ```
 
-Normal conversation text and visible tool calls are the correctness-level observation surface. Extension widgets are optional decoration only.
-
-## Boundary
-
-- **Allowed**: Coordinate Kernel / Loop projections, current-conversation Executor work, isolated QA/review children, runtime decision recording, same-boundary follow-up, and terminal handoff reporting.
-- **Blocked**: Plan edits, parent-owned QA/review pass, hidden review gates, direct Kernel-store edits, child-owned state mutation, automatic Compounder execution, and external loop runners.
-- **Workflow guard**: Kernel and Loop projections choose the next authority; each authority keeps its existing Skill contract.
-
-## Output artifact
-
-A visible completion trace plus terminal summary containing Plan, completed Steps, QA state, review state, stop reason, and next action.
-
-## Next Action
-
-- If no validated Plan exists: stop and route to `imm-planner`.
-- If an allowed Loop action exists: continue the loop without another user command.
-- If work is fully closed but not finished: report the explicit internal Compounder handoff and wait for terminal settlement.
-- If the projection is `awaiting_user_successor_decision`: report the candidate and preconditions, ask for the user's decision, and stop without dispatch.
-
-## Output style
-
-Default user-facing shape: checkpoint progress lines, then `Conclusion -> Evidence -> Next action` at the terminal boundary.
-
-## Kernel Canary Routing
-
-When the Kernel projection reports an active/draining backend claim, keep
-`imm-loop` as the user-facing entry and call the current Host's Kernel integration
-for that owned task. Enrollment and Review authorization use the current Host's
-native gates. When the projection calls for `request_authorization` or
-`approve_breaking_intent_revision`, invoke the exact Tool operation directly
-without asking the user for chat pre-confirmation; the native Host interaction is
-the single authority decision. Invoke
-`repair_authority_state` directly for a proven stale claim; Kernel revalidation
-removes only the redundant claim without user interaction. Do not invoke the
-removed `imm-canary-work` Skill as
-a separate entry point. Invalid or contradictory projections fail closed. After
-implementation and focused verification, freeze the artifacts and call
-`advance_assurance`. If it returns `review_ready`, invoke the foreground
-reviewer and pass its structured verdict to `submit_review`;
-`request_authorization` is reserved for an unresolved user decision or an
-explicit stop. Critical work completes after fresh QA and Review without a
-second user confirmation.
-Every QA/Review operation stays foreground and returns its next projected
-obligation directly to the Parent. The host performs any opted-in GitHub Issue
-projection only after the corresponding authority mutation: only a fresh
-claimless `done`/`stopped` projection with its exact terminal tombstone projects
-terminal closure (`completed`/`not planned`); Enrollment performs no GitHub
-projection. Treat the attached tracker result as non-authoritative observation.
-Report its failure separately, but never use it as evidence, a stop condition,
-or a reason to repeat a Kernel mutation. A terminal tombstone alone never
-blocks unrelated v3 routing.
+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,
+with cancellation checks. Semantic authority errors and mutation failures are not
+retryable reads. For `review_preparation_failed`, repair the reported transport or
+environment cause before advancing; committed QA remains valid. For
+`verdict_invalid`, correct the existing payload once and resubmit without another
+reviewer dispatch. If correction fails, report the schema failure and stop the
+correction loop.
+
+For failures, name the cause, stages already committed, the safe retry boundary,
+and exactly one next action. Distinguish user approval from environment repair
+and runtime failure. Do not ask the user to manually switch internal roles.

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

@@ -38,7 +38,7 @@ Learnings. 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,
-scope, and delivery risk. Persist that design in the candidate Spec, Plan, or
+scope, and delivery risk. Persist that design in the candidate Spec and
 TaskIntent rather than copying the question transcript.
 
 Planner may ask only when concrete new evidence exposes an omission, repository
@@ -88,11 +88,10 @@ source. If its prose conflicts with those authority facts, report stale
 documentation, preserve projection-based routing, and do not automatically
 synchronize either representation.
 
-The routing projection selects the planning route; explicit
-`imm-plan <plan-path> --json` validation is a separate, read-only advisory check
-of that Plan artifact. A valid Plan never proves Managed authority. Under an
-active `kernel_task_intent` policy, authority still requires a Git-tracked
-TaskIntent whose `imm-kernel intent validate <path> --json` projection is
+Historical prose Plans are read-only artifacts. Their validation never proves
+Managed authority and is not a prerequisite for new TaskIntent planning. New
+execution requires a Git-tracked TaskIntent whose
+`imm-kernel intent validate <path> --json` projection is
 `valid: true` and `enrollment_ready: true`, followed by current-Host native
 Enrollment.
 
@@ -132,17 +131,21 @@ For a large proposal split across multiple TaskIntents, exactly one planning
 carrier is chosen per Initiative: a Local Markdown file at
 `docs/initiatives/<slug>.md` or one GitHub Parent Issue. This preference applies
 only to Initiatives; ordinary TaskIntents remain tracked by Kernel TaskRecords.
-Resolve the carrier in this order:
+Resolve the carrier in this order, reading each source directly rather than
+assuming the current Host injected it into context:
 
 1. a literal user instruction for the current request;
 2. `Initiative carrier default: local` or `Initiative carrier default: github`
-   in the repository root `AGENTS.md`;
-3. the same directive in `~/.pi/agent/AGENTS.md`; or
-4. ask the user when no valid directive exists.
-
-A repository directive overrides the global directive. Report an invalid value
-and ask instead of guessing. After resolving it, display one non-blocking line
-with the selected carrier and its source. A configured `github` default is
+   in the repository root agent instruction file, whichever this repository
+   tracks: `AGENTS.md` or `CLAUDE.md`;
+3. the same directive in the Host's user-level agent instruction file; or
+4. ask the user.
+
+A repository directive overrides the user-level directive. There is no silent
+carrier default: when no valid directive is found, ask and report which sources
+were checked. Report an invalid value and ask instead of guessing. Never resolve
+to `local` or `github` because a source was absent or unreadable. After resolving
+it, display one non-blocking line with the selected carrier and its source. A configured `github` default is
 standing opt-in for GitHub projection, but the literal user must still confirm
 the named Initiative, its immutable slug, and the complete Parent/Child
 decomposition before the first remote mutation. A prior bulk approval cannot
@@ -220,29 +223,20 @@ descriptors or add a mandatory user confirmation. Use the smallest `timeout_ms`
 ## 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.
-- **Outcome Focus**: Each step must have one user-verifiable result. Reject plans that split one outcome into action-micro steps.
-- **Planning granularity**: Treat each step as one **outcome unit** versus **implementation batches** inside that unit. An executor may ship multiple commits or touch many files within a step when the recorded verification still closes that single outcome. When framing is stable and verification paths are concrete, prefer **fewer outcome steps** that each stay independently closable instead of inventing extra steps for perceived incrementality. **Narrow product scope** (Simplicity) is about what you commit to deliver; it is never permission to carve one outcome into read/edit/run micro-steps.
-- **Plan Boundary Discipline**: Step granularity and Plan granularity are separate decisions. A Step remains one independently closable outcome; a Plan remains one coherent executable slice. Independent authority, risk, verification, promotion, review, or rollback boundaries normally become successor Plans instead of larger Steps in the current Plan. Infrastructure that establishes an invariant should normally close and pass review before broad consumer rollout. Record `Plan boundary`, `Boundary rationale`, and advisory `Scope pressure`; file count, domain count, tokens, compactions, elapsed time, and review rounds are evidence for Planner reasoning, never universal workflow gates.
-- **Roadmap / Executable Slice Separation (historical — read-only)**: v3 prose Plan mutation is retired; `imm-plan` is a read-only validator and no new Roadmap-backed prose Plan is created. Archived `roadmap-slice/v1` Plans remain readable via `plan_core.ts` for backward compatibility. Do not produce new Roadmap-backed Plans.
-- **Risk-Triggered Exploration**: Before freezing a Managed Plan, resolve only the unknowns that could change Scope, design, or Verification — CI environment, third-party APIs, database behavior, cross-module interfaces — using targeted read-only probes. The internal `arch-explorer` and explicit-lens `advisory-reviewer` roles are the Loop bridge for these bounded probes; both return evidence and decision criteria without writing the Spec, Plan, or workflow state. Read-only and Plan-only work stays host-native without Enrollment; explicit Immune-Brain Skill entry starts Managed planning. Independently owned domains and unresolved material risk remain Managed concerns. Stop probing once Result, Scope, and Verification are concrete.
-- **Supersede Observability**: Every new `superseded` termination must record the runtime flags `--reason-code` (`exploration_gap` | `scope_pivot` | `boundary_error` | `contract_change` | `execution_failure`), `--stage`, `--invalidated-assumption`, and `--avoidable yes|no`; `cancelled` terminations may record the same classification but do not require it. Legacy terminal records without observability remain readable. Planning-quality metrics count only `avoidable: yes` terminations; `scope_pivot` must use `--avoidable no` because it is an external requirement change, never planner failure; `execution_failure` normally routes to `rework`/`follow_up` instead of supersede.
+- **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.
+- **Risk-Triggered Exploration**: Before authoring a TaskIntent, resolve only unknowns that could change scope, design, or verification using targeted read-only probes. Internal `arch-explorer` and explicit-lens `advisory-reviewer` roles return evidence without writing the Spec, TaskIntent, or workflow state. Stop probing when outcome, scope, and verification are concrete. Do not use retired Plan termination flags to classify discovery failures.
 - **Simplicity**: Apply the BASELINE Workflow Activation gate first. Non-mutating host-native work creates no Planner artifact. Explicit Immune-Brain Skill entry starts this Planner phase; ordinary host input does not invoke it through natural-language routing. Create one coherent outcome instead of expanding ceremony.
 - **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.
 - **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.
-- **Verification**: Every step must name the result and verification path. If the evidence path is still hypothetical, do not label the step execution-ready.
-- **Executable Scope**: Every new code-changing Step must declare one or more bounded project-relative paths in `- Scope: \`path\`, \`directory/\`, ...`. Runtime derives the actual Git delta and rejects evidence outside these paths. Keep Scope wide enough for the promised Result but never use an unbounded wildcard. Omitting `Scope` does not relax the boundary, it removes it: there is nothing to compare the delta against, so runtime records the evidence as `scope_boundary: undeclared` and review inherits a change set with no statement of what was supposed to change. `Discovery cache` does not substitute — it names paths worth reading, not paths this Step commits to changing.
-- **Verification Type Annotation**: When planning a step, annotate an optional `Verification type` field: `automated` (test command or script produces pass/fail), `hitl` (human checks outcome in browser/app/device), or `manual` (spot-check with no reproducible signal). Omit the field when the type is obviously `automated`. Steps marked `manual` signal that the verification has no feedback loop and should be upgraded to `automated` in a follow-up. This is an advisory annotation read from raw plan text by executor and QA; it is not parsed into runtime state by `imm-plan.py`.
-- **Devil's Advocate Preplan Audit**: Before presenting a plan as execution-ready, run a hostile self-review and record a `Devil's Advocate Audit` in the plan. The audit must answer three questions: rollback resilience (what recovery or rollback path exists if a step fails midway), verification vanity (whether each `Verification` can actually fail on the intended regression instead of only proving text exists), and spec dilution detection (whether any accepted requirement was silently narrowed or omitted because execution looked expensive).
-- **Prototype Step**: When a step exists to answer a design question rather than produce production code, annotate it with `Prototype: true`. A prototype step produces a throwaway artifact whose durable output is a recorded decision (ADR or docs/solutions/ entry). The executor skips test-first discipline on prototype steps; the compounder captures the answer before the prototype is deleted. This is an advisory annotation read from raw plan text; it is not parsed by `imm-plan.py`.
-- **Execution Posture Detection**: When planning a step, detect whether a non-default execution posture applies. Write an `Execution note` field on the step when the signal is clear:
-  - Legal values: `test-first` | `characterization-first` (omit the field for default pragmatic execution)
-  - Trigger signals for `test-first`: user explicitly requests TDD; the step has clear input/output contract; new module with behavioral logic
-  - Trigger signals for `characterization-first`: modifying legacy code with no existing test coverage; refactoring fragile behavior
-  - Do not mark: pure spec/documentation writing, configuration wiring, styling, trivial renames
-  - Do not expand into literal RED/GREEN/REFACTOR substeps in the plan — the executor owns that choreography
+- **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.
+- **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
 
@@ -297,7 +291,7 @@ implementation-ready contract and routes it to normal planning or execution.
 
 ## Planning Rules
 
-- **Entry Contract**: Use when plan/spec work is actually needed. If a validated plan already exists and scope has not drifted, route forward to `imm-loop` rather than re-exposing planner as ceremony.
+- **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.
@@ -315,51 +309,52 @@ implementation-ready contract and routes it to normal planning or 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**: If the source origin is a review follow-up packet, map it explicitly: `origin_review` -> `Origin`, findings -> `Research`. Planner processes only packets that cross the current boundary. Planner does not process same-boundary follow-ups; a direct same-boundary `follow_up` handoff returns to `imm-loop` as an execution artifact instead of becoming a Plan mutation. A `direct_fix` handoff should usually mean a same-boundary follow-up candidate, not a planner-owned Plan mutation.
-- **Brainstorm Manifest Mapping**: If the source includes a `Brainstorm manifest`, treat it as a closed-world input. Copy the manifest IDs into the Plan and add a `Brainstorm Trace` row for every `BR-*` item. Legal statuses are `covered_by_step`, `partially_covered`, `captured_as_decision`, `out_of_scope`, `deferred`, and `resolved_as_assumption`. `partially_covered`, `out_of_scope`, and `deferred` rows require a reason. `BR-Q-*` rows must be resolved before the Plan is execution-ready. The planner may narrow scope only by recording an explicit mapping; it must not silently omit confirmed brainstorm items. `imm-plan <plan-path> --json` reports an `origin_coverage` summary with `declared_items`, `mapped_items`, `unmapped_items`, reason-required trace counts, and completeness.
-- **Roadmap-Backed Planning (historical — read-only)**: v3 prose Plan mutation is retired; no new `roadmap-slice/v1` Plans are created. `plan_core.ts` retains `roadmap-slice/v1` parsing for archived plans (8 declare `roadmap-slice/v1`, 13 carry `Successor candidate`, etc.) for backward compatibility. Do not add `Roadmap source`, `Current phase`, or successor fields to new work.
-- **Session Lifecycle Ownership**: The user decides whether progression continues in the current session or a new session. Planner must not turn Plan boundaries, tokens, compactions, tool calls, elapsed time, or review rounds into automatic session creation, closure, or forced-stop policy. Persisted Spec, Plan, State Ledger, and handoff artifacts must support either user choice.
+- **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.
-- **Immutable Active Plan**: Once a Step is activated, do not use `append_to_plan` and do not revise Result, Verification, Scope, contract, phase, or successor metadata in place. A cross-boundary replan produces a new Plan path. If the current Plan cannot finish, only a literal user may first mark it `cancelled` or `superseded`; the old Plan remains archived and cannot resume.
-- **CONTEXT.md Vocabulary**: When `CONTEXT.md` exists at the repo root, use its canonical terms in step Result lines, Verification paths, and scope descriptions. If a new domain concept emerges during planning that is not yet in CONTEXT.md, add it. Consistent vocabulary across plans reduces agent token overhead and improves cross-session navigability.
-- **Discovery Protocol**: Before decomposing steps, read `CONTEXT.md` `## Architecture Map`, active `.imm/memory/current_iteration.json` step `discovery_cache`, and relevant `docs/solutions/` `key_files` frontmatter. When planning reveals task-specific hot paths, write a `Discovery cache` field on the relevant step using `path (reason)` entries so `imm-plan` can sync them into runtime state.
-- **Planning Quality Gate**: For elevated-risk plans, consult `docs/reference/planning-quality-gate.md` before finalizing the Spec or Plan. Trigger signals include runtime state, State Ledger, migration or compatibility behavior, runtime/package-contract or compiled skill contract changes, reviewer or subagent contract changes, and rollback-sensitive workflow changes. The gate requires explicit treatment of contract surface, compatibility, interruption recovery, rollback path, verification strength, and Brainstorm traceability. This gate is not mandatory ceremony for every plan and does not replace `IMMUNE.md`, `imm-plan.py`, or the optional `imm-brainstorm` `adversarial` high-pressure gate.
-- **Deferred Phase Continuation (historical — read-only)**: Archived deferred phases remain readable via `plan_core.ts`; no new deferred roadmap continuation is produced. v3 prose Plan mutation is retired.
-- **Parallel Probes**: When decomposing a step, identify whether the step involves 3+ non-overlapping file areas where readonly investigation can run in parallel before the executor changes code. If so, define an optional `parallel_probes` annotation on the step describing each probe's `scope` (files/directories to investigate), `output` (expected evidence format), and `readonly: true` constraint. Plan parsing and runtime sync preserve `parallel_probes` on the normalized Step and State Ledger active Step. Probes are dispatched by `imm-work` before entering executor; the executor receives probe results as input context. Do not mark probes on small steps or steps where sub-tasks have causal dependencies. Probe failure falls back to sequential inline investigation by the executor with a recorded fallback reason.
+- **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.
+- **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.
 
 ## 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.
 
-Runtime helpers: `imm_core.planner_research`, `imm_core.buildPlannerEnsembleRequest`, and `imm_core.normalizePlannerEnsemblePacket`.
-
-### Planner Ensemble Advisory
-
-A planner ensemble is optional advisory input for elevated-risk planning, not a vote and not a child-owned Plan draft. The default roles are: fast candidate for divergent options and simpler alternatives, mid candidate for repo-grounded executable slice, and strong candidate for adversarial risk and verification strength review.
-
-All planner ensemble children are advisory-only with `tool_policy: no tools`; they do not edit code, write Specs, write Plans, mutate workflow state, or close QA. The parent `imm-planner` owns final Spec and Plan synthesis, Brainstorm Trace mapping, Step Results, and Verification paths. Pi launches one foreground Agent at a time, consumes its direct result, and re-evaluates the remaining dispatch budget before launching another candidate.
-
-Agreement becomes evidence. Disagreement becomes decision criteria. strong-model blockers become explicit risks or verification requirements in the planner-owned output. Small plans do not fan out by default; use solo planning unless the task has elevated planning risk or an explicit ensemble request.
-
-**Trigger condition:** Only dispatch when the task spans multiple domains (`multi_domain >= 2`) or the user explicitly requests parallel research during planning. Do not dispatch for single-domain tasks or small-scope plans.
-
-**Retrieval budget:** Stop dispatching as soon as existing evidence is sufficient to decompose steps with concrete verification paths. Do not dispatch additional agents to improve phrasing, add examples, or fill in non-essential details. Dispatch again only when a required interface contract, file dependency, or constraint is still missing and would block step decomposition.
-
-**Dispatch behavior:** Use Pi native `Explore` subagents (`subagent_type: "Explore"`). Parallel eligibility is capability-based rather than a closed Skill list: every child delegation prompt must enforce read-only advisory behavior with no file edits, Plan writes, workflow-state mutation, or QA closure. Eligible examples include Brainstorm and Planner research children, Domain Mappers and architecture explorers, advisory reviewers, and provider-native read-only explorers; executor, QA, Compounder, owning Planner, and test-fixer children always run sequentially. Each research subagent receives a bounded investigation scope (specific module, directory, or interface surface) and returns a structured summary with `constraints`, `risks`, `unknowns`, `file_pointers`, and `verification_implications`. The parent planner merges summaries into the Research section of the plan before step decomposition. Research subagents do not write specs, plans, or `.imm/` state.
+Use `imm_loop_action` 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
+constructing another Agent call. Do not invoke retired Planner runtime helpers
+or write child-owned planning artifacts.
 
-**Research consumer boundary:** Planner research output is evidence-only. It can supply candidate constraints, risks, unknowns, and file pointers, but the parent `imm-planner` owns final Spec and Plan writing, Brainstorm Trace mapping, step Results, and verification paths.
+An optional planner ensemble is advisory-only; the Parent owns the final Spec and TaskIntent.
+Agreement becomes evidence, not authority. Disagreement becomes decision criteria,
+not a new confirmation gate. Do not treat strong-model blockers as authority
+without concrete evidence for the requested outcome.
 
-**Failure handling:** If research dispatch is unavailable or fails, continue with solo inline investigation. Record the fallback reason per the shared protocol.
+Stop discovery once concrete interfaces, paths, constraints, and verification
+are known. Additional reviewers are not required to improve wording. If an
+optional advisory dispatch fails, continue inline and record the reason.
 
 ## Boundary
 
-- **Allowed**: Write specs, iteration plans, durable planning memory, and `CONTEXT.md` at the repo root.
-- **Blocked**: Implementation edits, active-step activation, and review decisions.
-- **Workflow guard**: after a validated plan, the default and only user-facing continuation is `imm-loop`. It must not skip into executor edits without the active-step driver. Planner owns scope/spec/step decomposition; it is not the default continue entry once that work is already closed.
+- **Allowed**: Write candidate Specs and TaskIntents, 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
 
-Iteration plan under `docs/plans/` and spec under `docs/specs/`. Includes: `Summary`, `Origin`, `Research`, `Decisions`, `Assumptions`, `Output Language`, `Devil's Advocate Audit`, `Step ID`, `Test scenarios`. The `Output Language` section sits immediately after `Task` and states the configured human-readable prose language plus preserved literals for both the Spec and Plan. The `Devil's Advocate Audit` records rollback resilience, verification vanity, and spec dilution detection before the plan is treated as execution-ready. When the origin supplies a `Brainstorm manifest`, also include `Brainstorm manifest` and `Brainstorm Trace` so `imm-plan` can prove every declared `BR-*` item is mapped. Historical `roadmap-slice/v1` Plans remain validated for archived artifacts via `plan_core.ts` and are not produced for new work; v3 prose Plan mutation is retired and `imm-plan` is a read-only validator. Optional traceability fields per step: `failure_behavior` (what happens if the step fails or is partially applied), `security_considerations` (privacy or security risks introduced). Use `imm-plan <plan-path> [--json]` to validate.
+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
+`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.
 
 ## Output style
 
@@ -369,33 +364,32 @@ Iteration plan under `docs/plans/` and spec under `docs/specs/`. Includes: `Summ
 
 | Excuse | Rebuttal |
 | -------- | ---------- |
-| Skip `imm-plan --json` | Validator catches multi-result steps and illegal deps; merge-ready plans must pass `imm-plan <plan> --json`. |
-| Split one outcome into read/edit/run micro-steps | Forbidden: one step owns one closable result; batch implementation inside that outcome unit instead. |
-| Append repair without append contract checks | Append only when runtime plan matches append legality; otherwise use `new_slice` after explicit routing. |
+| Skip TaskIntent validation | Author, stage, and validate the canonical candidate before native Enrollment. |
+| 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. |
 
 ## Red Flags
 
-- Step `Verification` names only hypothetical evidence (“should pass”) with no command or artifact path.
-- Plan text uses forbidden multi-result punctuation in `Result` lines that `imm-plan.py` rejects.
-- A Plan sourced from brainstorm declares `Brainstorm manifest` items but lacks a complete `Brainstorm Trace`.
-- A Plan reaches the user without a `Devil's Advocate Audit` covering rollback resilience, verification vanity, and spec dilution detection.
-- New human-readable Spec or Plan prose ignores an explicit document-language policy.
-- Spec/plan edits occur outside `docs/specs/` and `docs/plans/` ownership without acknowledging planner boundary.
+- 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.
+- New Spec prose ignores the document-language policy.
+- Candidate artifacts escape the approved planning scope.
 
 ## Verification
 
-- Every new or revised iteration plan is validated with `imm-plan <plan-path> --json` before treating it as merge-ready. Resolve every `spec_design_metadata_missing` warning for a new or revised referenced Spec; it is compatibility-only for untouched legacy Specs.
-- When a project explicitly expects Chinese document prose, `imm-plan <plan-path> --json` includes an `output_language` warning if target Plan or referenced Spec prose appears mostly English.
-- Spec references align with steps: each step’s `Verification` is copy-paste-checkable against repo commands or files.
-- For brainstorm-origin Plans with a manifest, `imm-plan <plan-path> --json` reports `origin_coverage` totals with no `unmapped_items` and no reason-required trace rows without reasons.
+- 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.
+- 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.
 
 ## Next Action
 
-- Gate: Reference closure and the clarification supplement are complete; every upstream `BR-*` item is represented; no unresolved user-owned decision remains; any Planner-introduced decision delta is confirmed; the Plan passes `imm-plan --json` validation; and no step has a hypothetical-only verification path.
+- 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 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.