immune-brain 2.8.2

package/plugins/immune-brain/skills/BASELINE.md

@@ -0,0 +1,138 @@
+# Immune-Brain Skill Baseline
+
+## Shared Guards
+
+- Load detailed workflow text from `dist/` only on invocation.
+- Ask only when missing information changes outcome or risk.
+- Keep edits inside the user-requested Direct scope or the active Managed step boundary.
+- Record reproducible evidence before reporting closure.
+- Use shallow discovery first.
+- Lead with conclusion, evidence, and Next Action.
+- Advisory roles do not implement; Managed execution roles do not close QA.
+- An explicit Managed Skill entry stops host-native mutation and routes scope changes to `imm-planner`; Managed execution remains inside its accepted boundary.
+
+## Workflow Activation
+
+Ordinary host input stays host-native and does not run natural-language Managed
+routing. A new Managed workflow starts only from explicit `imm-brainstorm`,
+`imm-planner`, or `imm-loop` Skill entry.
+
+1. **Continue an existing Managed owner explicitly**: an active Assurance
+   projection, TaskIntent, TaskRecord, reviewer `follow_up`, or other nonterminal
+   Managed owner remains authoritative; the user resumes it with `imm-loop`.
+2. **Start explicitly**: the selected Immune-Brain Skill owns its planning or
+   coordination work. It creates only requested artifacts and their required
+   parent directories; it does not install project-wide contract files.
+3. **Preserve authority**: Planner output is a candidate for later literal-user
+   Enrollment, and Fast-Track preserves TaskIntent scope, Enrollment, QA,
+   Review, authorization, and completion boundaries.
+
+Do not inspect or mutate Immune-Brain state merely because ordinary host input
+contains a mutation verb. File count, local verifier count, ordinary retries,
+read-only advisors, and unrelated dirty files do not change these boundaries.
+
+### Non-Mutating Host Path
+
+Read-only and explicit no-modification requests stay with the ordinary host
+agent. This path creates no Spec, Plan, TaskIntent, TaskRecord, State Ledger,
+acceptance evidence, QA job, mandatory Review job, HANDOFF update, or
+Compounder state. It may explain, inspect, or review without Enrollment.
+
+### Managed Execution And Completion
+
+The matching Managed owner drives execution, evidence, QA, Review, and
+completion without switching to a non-authoritative path. Scope expansion
+returns to `imm-planner`; an enrolled task resumes through `imm-loop` from the
+current Assurance projection. Do not create or mutate workflow state while
+classifying a non-mutating request.
+
+Stage only explicit task-owned paths. Never use `git add .` or `git add -A` in a dirty worktree.
+
+### Host Confirmation Boundary
+
+Require exact host confirmation only for privileged effects:
+
+- publish, release, deployment, or remote-system mutation;
+- destructive or irreversible operations and Git history rewrite;
+- credential, secret, permission, or access-control changes;
+- authority discard, task stop, breaking intent revision, or risk/policy
+  override; and
+- external writes whose target or impact cannot be safely reversed locally.
+
+Routine Managed enrollment uses one host confirmation bound to the TaskIntent content hash at the Planner's final `ctx.ui.custom` gate. Enrollment validates intent, Git ownership, scope, workspace claim, and final authority preconditions without executing acceptance descriptors; deterministic QA executes them after implementation. The routine task proceeds from that single confirmation through enrollment, execution, and QA without a second human stop. Do not request confirmation for local in-scope edits, local verification, ordinary Direct rework, scoped diff review, or completion reporting. Managed evidence, QA, Review, and completion authority remain governed by their Managed contracts; R2 does not weaken them.
+
+## Parallel Read-Only Dispatch
+
+State mutations, step activations, QA decisions, and plan switches remain
+strictly sequential. Read-only work — repo exploration, advisory review,
+host probing, planner research — may be dispatched in parallel.
+
+Parallel dispatch is restricted by capability, not by a closed Skill list. Every
+child delegation packet must enforce read-only advisory behavior: 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 such as
+Pi `Explore`. Executor, QA, Compounder, owning Planner, and test-fixer children
+always run sequentially.
+
+## Output Language Policy
+
+- Honor the configured language for user-facing replies and short summaries.
+- Persisted Immune-Brain documents default to English, including `HANDOFF.md`,
+  `docs/brainstorms/`, `docs/specs/`, `docs/plans/`, and `docs/solutions/`.
+- A reply-language instruction such as "use Chinese when replying" does not
+  change document language. Change persisted document language only when the
+  current user request, project instructions such as `AGENTS.md`, or host/user
+  preference contains an explicit document-language instruction.
+- Reply language precedence is: current user instruction, then project
+  instructions such as `AGENTS.md`, then host or user-level preference, then
+  the repo-wide default output contract. Document language precedence is:
+  current explicit document-language instruction, then project explicit
+  document-language instruction, then host or user-level explicit
+  document-language preference, then English.
+- Do not translate or rename machine contracts: schema fields, enum values,
+  CLI flags, JSON keys, file paths, tool names, API names,
+  and code identifiers stay literal.
+- Preserve `CONTEXT.md` canonical terms such as `Step`, `Plan`, `Spec`,
+  `Skill`, `Brainstorm`, `Executor`, `QA`, `Compounder`, `Learning`, and `ADR`;
+  add local-language explanations around them when helpful.
+
+## Success Criteria
+
+- Direct work closes only under the Direct completion contract above.
+- A Managed Step is ready to execute only when the target result, boundary, and
+  verification path are clear enough to avoid speculative edits.
+- A Managed Step is closable only when execution evidence proves the recorded
+  verification path and the active boundary still matches the Plan.
+- Managed scope changes, missing evidence, or structural mismatch return to
+  `imm-planner` instead of being hidden inside execution or QA.
+
+## Retirement Completion
+
+For retirement-class work, deletion of source and contract text is a completion condition. A retirement is not complete until the source and its contract text are deleted.
+
+An absence test is transitional scaffolding proving an in-progress deletion rather than a substitute for one. An absence test is transitional evidence of an in-progress deletion and may not stand in place of one. Distinguish an absence assertion that guards something already gone, which is durable and correct, from one that stands in for a deletion still owed, which is a promise recorded as if it were a result.
+
+## Collaboration Posture
+
+- When to ask: ask only when missing information would change the outcome,
+  authority boundary, or risk profile.
+- When to proceed: proceed on explicit, low-risk assumptions when the next
+  evidence path can validate or reject them.
+- Keep uncertainty visible in evidence, notes, or Next Action instead of
+  silently widening scope.
+
+## Hub skill anatomy
+
+The public Skills `imm-brainstorm`, `imm-planner`, and `imm-loop` carry the
+repo's user-facing workflow authority. Execution, QA, review, repair,
+exploration, and learning are internal runtime roles dispatched by Loop through
+packaged role prompts; they are not additional public Skills. Keep explicit
+`Rationalizations`, `Red Flags`, and Verification guidance grounded in
+Immune-Brain commands and `.imm` state.
+
+## Shallow Discovery
+
+Prefer shallow discovery before full-file reads. Start with file lists,
+`rg` hits, symbol/signature scans, and targeted line ranges; read whole files
+only when the narrower evidence path cannot answer the active Step question.

package/plugins/immune-brain/skills/imm-brainstorm/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: imm-brainstorm
+description: Use to frame and clarify an ambiguous problem and its open questions before planning; framing only, no implementation or plan writing.
+---
+
+# Immune-Brain: Brainstorm
+
+Load [`../../dist/imm-brainstorm.md`](../../dist/imm-brainstorm.md), then frame the
+task before planning. Do not edit project files. Return goal, constraints,
+unknowns, readiness, and Next Action.
+
+## Default exhaustive decision tree
+
+Exhaustive clarification traverses every current-goal branch grounded in the
+user request, repository evidence, or a settled parent decision. Do not use a
+materiality or task-type judgment to decide whether a sourced user decision is
+worth asking. 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; then expand branches from each answer.
+
+Classify each unresolved node only as a repository fact or a user-owned decision.
+Resolve repository facts with bounded, on-demand read-only evidence. A blocked
+fact blocks only its dependent subtree and remains explicit; never convert it
+into a user preference. Place every sourced user decision on the complete
+currently unblocked frontier. Hold dependent questions until their parents are
+settled, but ask all independent questions together. Number each question,
+include grounded options and a 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.
+Minimally clarify an ambiguous answer. If later evidence invalidates a settled
+choice, reopen only that decision delta. An explicit defer stops its subtree and
+becomes `BR-DEFER-*`, unless it still changes the current Result, interface, or
+compatibility and therefore cannot be deferred.
+
+Brainstorm is complete 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 stops early, emit every open node as `BR-Q-*` and do not mark the frame
+planning-ready. Otherwise present a result-only summary as a non-blocking
+correction window and retain final decisions in the `BR-*` manifest rather than
+copying the question transcript. 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 and block Planner handoff
+until it is answered. Agent judgment alone never confirms a proposed direction
+or scope.
+
+Brainstorm supports `default`, `roundtable`, and `adversarial` modes. All use the
+same exhaustive frontier protocol; `roundtable` and `adversarial` add analysis
+lenses only when explicitly selected by the user. Required failure, rollback,
+compatibility, migration, and risk branches remain part of default traversal.
+Consult ADRs and on-demand rejected-decision evidence only when a live branch
+reaches that topic.
+Architecture mapping is a bounded, read-only `arch-explorer` role selected
+through the internal Loop bridge; it cannot write a Spec, Plan, or workflow
+state. Pi's adapter may consume `brainstorm_ensemble` dispatch JSON to prepare
+advisory Pi subagent envelopes, but envelope construction is not child execution
+and does not transfer framing authority. Pi itself may launch those subagents,
+collect completed child outputs, and feed them to
+`normalizePiBrainstormAgentResults`; runtime does not call any agent, poll
+background work, mutate state, or own final Spec/Plan authority.
+Agreement becomes framing evidence, Disagreement becomes decision criteria or
+`BR-Q-*`, and strong-model blockers become risks or verification requirements.

package/plugins/immune-brain/skills/imm-doc-prune/SKILL.md

@@ -0,0 +1,11 @@
+---
+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.
+---
+
+# Immune-Brain: Doc Prune
+
+Load [`../../dist/imm-doc-prune.md`](../../dist/imm-doc-prune.md), then prune
+stale current documentation from the target Git repository. This is a
+standalone host-native maintenance entry, not a Managed Path continuation
+and not an `imm-loop` internal-role dispatch.

package/plugins/immune-brain/skills/imm-loop/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: imm-loop
+description: Use to run a validated Plan to completion in the current conversation through checkpoints and isolated QA/review authorities.
+---
+
+# Immune-Brain: Loop
+
+Load [`../../dist/imm-loop.md`](../../dist/imm-loop.md), then run the checkpoint loop in the current Pi conversation. Keep active Step implementation in this conversation; use Pi native `Agent` subagents only when the runtime reports `awaiting_qa_decision` or a required review gate. Standard Plan Steps close from passing evidence without per-Step QA; Strict Plan Steps retain isolated QA. Return visible checkpoint progress and a final stop summary.
+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` and `imm-doc-prune` are host-native and are never dispatched as the Loop role.
+Subagent Dispatch Protocol](../../dist/docs/reference/subagent-dispatch-protocol.md#authorization-authority).
+All internal Agent dispatch envelopes use `run_in_background: false` and
+return `tool_call`, `tool_result`, and `tool_execution_end` evidence to the
+Parent before any workflow mutation.
+
+At `terminal_plan_complete`, stop with no next skill, authority, or action. At `awaiting_user_successor_decision`, stop with `recommended_authority: user`. This boundary follows the explicit internal Compounder handoff and runtime terminal settlement; it must not dispatch Planner, Compounder, transition, or a new Pi session/subagent. Only a literal user may approve a successor through the native authority gate; the internal runtime token is `--approve-successor`, never a public Skill or user-facing entry.
+
+Scope expansion always returns to `imm-planner`; Executor and repair roles must stop with the concrete missing scope and verification reason instead of widening execution.
+
+The loop always enters through `imm_loop_action`: the projected action's `next`
+authority is `executor`, `test-fixer`, `pr-fix`, `arch-explorer`,
+`advisory-reviewer`, `compounder`, `imm_kernel_canary`, `imm-planner`, or
+`none`.
+
+When the Kernel projection reports an active/draining backend claim, keep
+`imm-loop` as the user-facing entry and call the `imm_kernel_canary` Tool for
+that owned task. Enrollment uses the `imm_canary_enrollment` Tool and Review
+authorization remains a native TUI gate. When the projection calls for
+`request_authorization`, `approve_breaking_intent_revision`, or
+`repair_authority_state`, invoke the exact Tool operation directly without
+asking the user for chat pre-confirmation; the native host interaction is the
+single authority decision. 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 exact reserved
+foreground Agent and call `submit_review`; `request_authorization` remains the
+critical-risk user authorization boundary. 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.

package/plugins/immune-brain/skills/imm-planner/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: imm-planner
+description: Use to create or revise a spec and iteration plan from requirements; owns scope and plan decomposition, not implementation or step activation.
+---
+
+# Immune-Brain: Planner
+
+Load [`../../dist/imm-planner.md`](../../dist/imm-planner.md), then create or revise
+the executable plan. `mode: page_design` is the canonical pre-implementation
+design-contract mode formerly exposed as `imm-page-design`. Keep scope
+explicit, including the Devil's Advocate preplan audit and `Devil's Advocate Audit` output. Return plan path, decisions,
+first step, verification approach, and Next Action.
+
+## Clarification supplement
+
+Planner consumes an upstream Brainstorm manifest as a closed-world input 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 and owns ordinary technical choices: design and component boundaries, failure behavior, compatibility, migration, recovery and
+rollback, Verification, execution slices, dependencies, scope, and delivery
+risk. It then authors the candidate Spec, Plan, or TaskIntent.
+
+Planner may ask only when concrete new evidence exposes an omission, repository
+conflict, or invalidated assumption. Ask the focused decision delta, cite the
+upstream `BR-*` item and new evidence when available, and preserve every
+unaffected decision. Resolve a local delta here; if its answer reopens multiple
+product branches or changes the overall goal or Scope, stop and return to
+`imm-brainstorm`.
+
+Direct Planner entry remains valid for clear requests. Resolve facts and derive
+technical design without a Brainstorm pass; if an unresolved user-owned product
+decision appears, return to `imm-brainstorm` instead of silently choosing it or
+starting a second exhaustive interview. A zero-question fast path is valid when
+no supplement is required. Present an unchanged result summary as a
+non-blocking correction window and do not ask the user to reconfirm existing
+decisions. If the summary itself introduces or changes a user decision, confirm
+only that decision delta before finalizing.
+
+Settlement-class intents (terminal settlement, cancellation, timeout, race, or
+authority-lifecycle semantics) must embed the `Settlement-Design Contract`
+enumeration required by the loaded contract before they are execution-ready.
+
+## Technical Design Views And Decomposition
+
+For Medium and High Design 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. The Spec is the single Technical Design baseline. Persist those decisions there; do not copy them into a TaskIntent or revive prose Plan authority. Low risk remains concise and is not forced to produce empty architecture, interface, data-flow, state, or sequence sections.
+
+Use the selected design boundaries as one TaskIntent decomposition dimension alongside outcome, Verification, dependency, risk, rollback, compatibility, and authority. Keep one TaskIntent when the selected views describe one coherent executable slice with shared acceptance, risk treatment, rollback, 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. Do not split merely because the design names several layers, files, or services.
+
+## Reference Closure Preflight
+
+Before authoring a TaskIntent, trace each expected behavior from its public or
+runtime entry point through existing imports and callers to the highest focused
+behavioral tests. Include generated or packaged mirrors and every owner of the
+same state machine. Record the concrete paths in the Spec's discovery evidence;
+do not author while a referenced sibling is unresolved. Use the smallest
+coherent module directory for ordinary implementation scope. Keep Kernel,
+authority, migration, secret, and security-sensitive scope exact to the files
+proved necessary by the trace. Scope is closed by reference evidence, not by an
+exhaustive filename guess.
+
+## Managed Request Routing
+
+`imm-planner` is entered explicitly by the user for a clear repository mutation.
+Ordinary host input does not invoke this Skill through natural-language routing.
+An active Assurance projection remains authoritative and is resumed only through an explicit `imm-loop` entry; explicit Planner entry owns planning and the later native Enrollment gate:
+- an active Assurance projection remains on its current owner until the user explicitly enters `imm-loop`;
+- read-only, explanation, review-only, Plan-only, and explicit no-modification
+  requests do not enroll;
+- materially ambiguous mutations go to `imm-brainstorm` before planning; and
+- clear new mutations reach this Planner phase.
+
+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
+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 already includes
+execution, invoke that gate as soon as the candidate is validated and Git-tracked.
+Literal-user confirmation in the native gate remains the authority boundary.
+Fast-Track may compress the same phases but cannot bypass that boundary, QA,
+Review, authorization, or completion.
+
+## Kernel TaskIntent Routing
+
+Before producing a new managed planning artifact, resolve the canonical wrappers
+from the declared Skill location: `../../bin/imm-plan` and
+`../../bin/imm-kernel`. Invoke `imm-plan --routing-status --json` through that
+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 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 Pi `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.
+
+Current owner, phase, completion, and authority facts are authoritative only
+when read from the Assurance projection and TaskRecord. `CONTEXT.md` is
+non-authoritative vocabulary and architecture navigation, not a workflow-status
+source. If its prose conflicts with those authority facts, report stale
+documentation, preserve projection-based routing, and do not automatically
+synchronize either representation.
+
+Pi host identity is implicit and never a planning input. The production boundary
+that turns a Git-tracked TaskIntent draft into managed execution authority is the
+native host TUI: the Planner's final `ctx.ui.custom` gate (via the
+`imm_canary_enrollment` foreground Tool) provides one literal-user confirmation
+bound to the TaskIntent content hash. Invoke the Tool directly when the route is
+ready; do not ask for a chat pre-confirmation. Enrollment validates the intent,
+Git ownership, scope, 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.
+
+The Planner never writes the `docs/plans/<task-id>.intent.json` artifact
+directly and never overwrites an existing TaskIntent. Under an active
+`kernel_task_intent` policy it supplies one complete candidate to the canonical
+`imm-kernel intent author <path> --stdin --json` command, which owns strict
+parsing, verification-descriptor canonicalization, path binding, and exclusive
+file creation; then it validates the created artifact with
+`imm-kernel intent validate <path> --json`. Revisions of an enrolled intent
+continue through Kernel `revise_intent` authority and are not a Planner
+overwrite path.
+
+### Initiative Carrier Preference
+
+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:
+
+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
+standing opt-in for GitHub projection, but the literal user must still confirm
+the named Initiative and its immutable slug before the first remote mutation.
+Surface that name, slug, and the proposed Parent/Child creation together as soon
+as decomposition establishes multiple TaskIntents. Recommend one answer so the
+user may adopt the complete current decision frontier in bulk. A prior bulk
+approval cannot confirm a name or slug that had not yet been shown.
+Resolve `../../bin/imm-tracker` from this Skill location; do not assume a bare
+command is on `PATH`. After the first TaskIntent has been authored, staged, and
+validated with `valid: true` and `enrollment_ready: true`, and both the named
+Initiative and its immutable slug are confirmed, attempt the GitHub projection
+before returning the final Planner result or invoking Enrollment: call
+`imm-tracker create-initiative --stdin --json` once with the confirmed goal,
+stable Slice summaries, and the public Parent projection fields. `create-initiative`
+receives the stable Initiative goal and Slice summaries plus the
+public Parent projection fields `problem`, `result`, `decisions`,
+`testing_strategy`, and `out_of_scope`. It creates a result-oriented Parent title
+`[<initiative>] <result>` and never rewrites an existing Parent.
+
+Then call
+`imm-tracker upsert-task --initiative-id <slug> --slice-id <id> --intent <path> --projection-json <json> --json`
+to create one neutral open Child Issue and attach it to the Parent as a native
+Sub-issue. The projection JSON is public planning context only and may contain
+`result`, `current_behavior`, `desired_behavior`, `key_interfaces`,
+`verification`, `blocked_by` Task IDs, `out_of_scope`, and `agent_handoff`.
+The tracker rereads the canonical TaskIntent for identity, risk, and acceptance;
+projection fields never widen TaskIntent scope or authority. The Child title is
+`[<initiative>/<slice>] <result>` with no `IB:` prefix or Task ID. Its body is an
+Agent Brief with Parent, What to build, Current behavior, Desired behavior, Key
+interfaces, Acceptance criteria, Verification, Blocked by, Out of scope, Agent
+handoff, and Authority boundary sections. Native `blocked_by` relations are
+created only for exact marker-owned Task Issues and are idempotently observed.
+Internal role prompts, tool policies, review gates, model reservations, and
+prompt digests never belong in this external handoff.
+If `docs/initiatives/<slug>.md` exists, the tracker fails with a
+carrier conflict; Local mode performs zero GitHub operations. A future Slice remains a parent checklist entry until its own TaskIntent is
+canonically authored and validated.
+
+Tracker output is observation, never authority. Before the Planner returns, its
+GitHub carrier outcome must be exactly one of: `tracker_associated` after both
+operations return `created`, `updated`, or `already_current`;
+`awaiting_user_initiative_confirmation` with the single pending Initiative
+name-and-slug decision; or `tracker_projection_failed` with the returned failure
+and exact retry action.
+A candidate Initiative name or slug recorded only in the Spec or final summary
+is neither user confirmation nor a completed carrier outcome. Report `retryable_failure`,
+`permanent_failure`, or `ambiguous_remote_state` and the exact retry action, but
+do not block planning, Enrollment, execution, QA, Review, settlement, or another
+association. Do not infer opt-in from tracker output or Issue state,
+auto-close the parent, import Issue state, create a TaskIntent from an Issue, or store Issue identity in TaskIntent or
+TaskRecord. Existing Issue markers grant permission only for later one-way
+projection updates to that same Initiative; they never grant execution authority.
+
+### Verification Descriptor Discipline
+
+Every acceptance verification descriptor must be a focused, deterministic,
+repository-local check that exercises only its acceptance assertion. Prefer one
+small `bun test <focused-file>` or `bun run <focused-script>` per acceptance;
+never use the full test suite, a build, package installation, network access, or
+redundant heavyweight checks. Prefer the highest existing observable behavioral
+test seam and the fewest sufficient seams. Cite relevant test prior art and
+explain how the selected seam catches the intended regression. This is a
+planning heuristic: it must not weaken acceptance-specific focused verification
+descriptors or add a mandatory user confirmation. Use the smallest `timeout_ms` and
+`max_output_bytes` that cover deterministic post-implementation QA.
+
+## Retirement Completion Contract
+
+For retirement-class work, deletion of source and contract text is a completion condition. A retirement that routes the command to a retirement wall, pins the absence with test assertions, and leaves the source in the tree is not complete. A retirement is not complete until the source and its contract text are deleted.
+
+An absence test is transitional scaffolding proving an in-progress deletion rather than a substitute for one. An absence test is transitional evidence of an in-progress deletion and may not stand in place of one. It proves a deletion in progress, not a completed result. Distinguish an absence assertion that guards something already gone, which is durable and correct, from one that stands in for a deletion still owed, which is a promise recorded as if it were a result.
+Architecture exploration and advisory review use the internal Loop bridge's
+read-only `arch-explorer` and `advisory-reviewer` roles. They can supply
+candidates, evidence, and decision criteria, but cannot write this Spec/Plan or
+activate execution.
+Agreement becomes evidence, Disagreement becomes decision criteria, and
+strong-model blockers become risks or verification requirements.

package/plugins/immune-brain/skills/imm-pr-fix/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: imm-pr-fix
+description: Use to repair GitHub PR review feedback, merge conflicts, or failing CI checks within the current PR scope.
+---
+
+# Immune-Brain: PR Fix
+
+Load [`../../dist/imm-pr-fix.md`](../../dist/imm-pr-fix.md) and repair the
+target PR directly. This is a standalone host-native repair entry, not a
+Managed Path continuation and not an `imm-loop` internal-role dispatch.

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

@@ -0,0 +1,49 @@
+version: 1
+source_glob: skills/*/SKILL.md
+skills:
+  - name: imm-brainstorm
+    path: skills/imm-brainstorm/SKILL.md
+    role: brainstorm
+    title: Brainstormer
+    role_class: framing
+    canonical: true
+    modes: [default, roundtable, adversarial]
+    output_artifacts: [brainstorm_framing]
+    next_actions: [imm-planner]
+    boundary: Problem framing only; no implementation or QA closure.
+  - name: imm-planner
+    path: skills/imm-planner/SKILL.md
+    role: plan
+    title: Planner
+    role_class: authority
+    canonical: true
+    output_artifacts: [validated_plan]
+    next_actions: [imm-loop]
+    boundary: Owns plan creation and revision; no executor edits.
+  - name: imm-loop
+    path: skills/imm-loop/SKILL.md
+    role: coordinate
+    title: Run
+    role_class: coordinator
+    canonical: true
+    output_artifacts: [run_status]
+    next_actions: [imm-planner]
+    boundary: Coordinate the validated plan through execution, review, and settlement; no planning bypass.
+  - name: imm-pr-fix
+    path: skills/imm-pr-fix/SKILL.md
+    role: execute
+    title: PR Fix
+    role_class: repair
+    canonical: true
+    output_artifacts: [repair_report]
+    next_actions: []
+    boundary: Repair one GitHub PR directly; no Managed authority mutation or scope expansion.
+  - name: imm-doc-prune
+    path: skills/imm-doc-prune/SKILL.md
+    role: execute
+    title: Doc Prune
+    role_class: repair
+    canonical: true
+    output_artifacts: [prune_report]
+    next_actions: []
+    boundary: Prune stale current documentation after explicit manifest approval; no Managed authority mutation or authority-artifact deletion.