[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K3CTBV5QR6CCHJP1SN75GD":3,"skill-same:01M6K3CTBV5QR6CCHJP1SN75GD":69},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M6K3CTBV5QR6CCHJP1SN75GD","plan",null,"Use only within active engineer\u002Fconduct DECIDE after accepted stories and a clean conflict-check, when a committed `.docs\u002Fplans` implementation artifact is required. Do not invoke for conversational planning, implementation checklists, or direct coding requests.","jstoup111\u002Fai-conductor","jstoup111","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1585332?v=4","01M6K374Y0VEFPVCT2KPBAN4HC","James Stoup","01M6K3751X0GFKNBD0198F50XN",7,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fplan\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"paths","when","gating","invoke","planning","conflict","do","conduct","coding","direct","active","artifact","claims","conflicts","false","only","clean","engineer","decide","2026-11-10 10:12:30",false,"---\nname: plan\nimplicit_invocation: required\ndescription: \"Use only within active engineer\u002Fconduct DECIDE after accepted stories and a clean conflict-check, when a committed `.docs\u002Fplans` implementation artifact is required. Do not invoke for conversational planning, implementation checklists, or direct coding requests.\"\nenforcement: gating\nphase: decide\nstandalone: false\nrequires: [\".docs\u002Fstories\u002F with both paths\", \".docs\u002Fconflicts\u002F clean pass or no blocking conflicts\", verify-claims]\n---\n\n## Purpose\n\nThe **technical implementation plan** (`HOW`) that `build` ships from — the bridge between the\nbehavioral stories (`WHAT`) and shipped code. Stories say *what* the system should do; the plan\ndecides *how*: the technical approach, which files change, the 2–5 min TDD tasks, and their\ndependencies\u002Fsequencing. Any agent can execute it with zero additional context.\n\nThis is **not** a re-listing of the stories. It adds the engineering layer they don't carry:\narchitecture\u002Fapproach, file-level changes, task ordering, and dependencies. Traceability runs\nPRD `FR-N` → story → task. Every acceptance criterion maps to at least one task; negative-path\nstories become explicit test tasks — not afterthoughts.\n\n**Correctness gate:** a plan encodes technical assumptions (which files change, how a subsystem\nbehaves, what an API accepts). Apply the `\u002Fverify-claims` protocol before finalizing tasks —\nprefer one cheap `Read`\u002F`grep` over a guess, attach a grounded confidence % to claims you cannot\ncheaply verify, and HARD-BLOCK (operator approval interactive, HALT if autonomous) on any\nunconfirmed assumption that changes the technical approach or task breakdown.\n\nOpen with a short **Technical Approach** (a paragraph or few bullets: the design decisions,\nkey modules\u002Ffiles, and sequencing) before the task list, so `build` has the shape of the work\nbefore the steps.\n\nWhen the approach relies on a local implementation or test pattern, capture only the focused\ncontext an implementer needs: the relevant traits, why they fit this work, allowed variation, and\nsearch hints for finding comparable code or tests. This is semantic author guidance, not a new\nheader or parser contract. An implementation task affected by that pattern repeats its relevant\nsubset in its own steps, because isolated implementers do not receive the full plan. Do not anchor\nthe guidance to line numbers or snapshots. If the local pattern does not fit, or a departure would\nchange that task's approach, record the verified no-fit result or the authorized departure in that\ntask before BUILD begins.\n\nKeep this focused pattern context distinct from the exact-copy declaration: use the existing paired\n`**Pattern-source:**` and `**Rename-map:**` headers only when the plan replicates a source pattern,\nand preserve their existing separate semantics and grammar.\n\nRead the `Scope boundary:` from `.docs\u002Ftrack\u002F\u003Cslug>.md` as binding; preserve the confirmed narrow\u002Fcomprehensive breadth outcome; do not permit a materially broader expansion beyond it unless the operator confirms before it enters the artifact.\n\n### Documentation boundary\n\nNever create plan tasks, subtasks, requirements, verification items, or notes for writing or\nupdating ordinary project documentation—even when it accompanies functional work. Documentation-only\nrequests belong to `\u002Fexplore`'s direct delivery route. Plans cover only functional behavior and its\nimplementation.\n\n### Amending a sealed plan\n\nThe first BUILD entry seals DECIDE artifacts. If an operator approves a plan or architecture\namendment after that boundary, committing the amendment does not update the existing\n`.pipeline\u002Fprotected-artifact-seal.json`; the old baseline is intentionally retained until the\nchange is reviewed and audited.\n\nBefore clearing the resulting seal HALT or re-queueing the feature, review the exact protected\nartifact diff and rotate the seal with the engine-owned reseal procedure in the stalled-feature\nrunbook. Record the approved paths and use an honest operator-review trigger. A pre-rebase seal\nrefusal is not a git conflict: do not invoke the rebase resolver or run `git rebase --continue`.\n\n## Practices\n\n### 1. Validate Preconditions\n\n**GATE: Refuse to produce a plan without these artifacts:**\n\n- [ ] Stories exist in `.docs\u002Fstories\u002F` for the feature being planned\n- [ ] Every non-remediation task declares exactly one `**Dependencies:**` line: `none` when\n      independent, or a comma-separated task reference list. Every cited id is declared and the\n      dependency graph is acyclic. Land and the conduct `plan` gate enforce this rule for new plans\n- [ ] Every story has both happy and negative paths\n- [ ] Conflict-check has passed (check `.docs\u002Fconflicts\u002F` for recent clean pass, or no blocking conflicts)\n- [ ] Before the plan declares a `## Slices` section, the operator has explicitly accepted stacked\n      delivery and `.docs\u002Fcomplexity\u002F\u003Cstem>.md` carries `Stacked-Delivery: approved` (see Slice\n      manifest). Land refuses a sliced plan without that line, after plan review has already run\n\nIf preconditions are not met, state which are missing and suggest the appropriate skill.\n\n### 2. Read All Stories\n\n**Skip redundant exploration:** If exploration was already performed in this session (e.g.,\nduring explore), use the existing exploration results. Do not re-explore the same scope —\npass the summary to the Plan agent instead of dispatching new Explore agents.\n\nLoad every story for the feature from `.docs\u002Fstories\u002F`. For each story, extract:\n- All happy path acceptance criteria\n- All negative path acceptance criteria\n- Any dependencies between stories (shared entities, sequencing)\n\n### 3. Generate Implementation Tasks\n\nBreak stories into tasks at **2-5 minute granularity**. Each task follows the TDD cycle:\n\nFor every story criterion, answer: “Can a commit outside this feature's diff\nchange whether this criterion is true?” Record `diff-local` only when the\nanswer is no; `outside-diff` requires a documented coherence waiver rather\nthan silently becoming a BUILD assertion.\n\nRemoval-shaped tasks follow `\u002Fcode-removal`: specify the deletion, including what dies and which\nobservable behavior survives. Do not specify a test whose subject is the removed code's absence, or\nmark a removal task `Verify-only:` merely to document that absence.\n\n```markdown\n### Task [N]: [Descriptive title]\n**Story:** [Reference to story and specific acceptance criterion]\n**Type:** happy-path | negative-path | infrastructure | refactor\n\n**Steps:**\n1. Write failing test: [Specific test description with expected assertion]\n2. Verify test fails (RED)\n3. Implement: [Specific implementation description]\n4. Verify test passes (GREEN)\n5. Commit with message: \"[descriptive message]\"\n\n**Done when:**\n- [Falsifiable check naming the mechanism and observable assertion — see 3c and 3d.]\n- [Second falsifiable check; use 2-5 checks, each on one physical line.]\n\n**Files likely touched:**\n- [file path] — [what changes]\n\nWrite file paths **repo-relative** (e.g. `src\u002Fengine\u002Ffoo.ts`, not\n`foo.ts`): the build evidence gate corroborates each task's commits against these\npaths. Basename\u002Fsuffix forms are tolerated (matched at `\u002F` boundaries, #425), but\nrepo-relative paths corroborate precisely and never collide.\n\n**Verify-only:** [yes, or omit — see 3b below]\n\n**Dependencies:** [Task N that must complete first, or \"none\"]\n```\n\nThe `**Files:**` line is authoritative for the build evidence gate: each task's\ncommits are corroborated against exactly these paths (#424). Paths may be\nplain text or backticked, `;`\u002F`,` separated, on the line or as bullets under\nit. `same` inherits the previous task's set, `same as Task N` inherits task\nN's, and `none` means the task's commit trailer alone corroborates. Backticked\nfile names elsewhere in the task (Steps prose) are only used when no Files\nline exists.\n\nWhen a task is affected by local pattern context from Technical Approach, repeat the applicable\ntraits, rationale, allowed variation, and search hints in that task's Steps prose. Do not add a\nnew task header, parser grammar, line-number anchor, or snapshot reference for this context. Where\nthe task cannot follow the pattern and that changes its approach, its Steps must state either the\nverified no-fit result or the authorized departure.\n\nFor test-owning tasks, map every covered acceptance criterion to a concrete, lowest-sufficient test\ndisposition: name the test layer and the assertion or existing coverage that proves it. Several\ncompatible criteria may be covered together by one focused test; do not prescribe a distinct test\nper criterion, or a production-file change merely to create one. The task must still make clear\nwhich criterion each disposition covers, including negative paths.\n\n**Sealed-artifact prohibition:** A task MUST NOT name another feature's artifact under\n`.docs\u002Farchitecture\u002F`, `.docs\u002Fdecisions\u002F`, `.docs\u002Fplans\u002F`, `.docs\u002Fspecs\u002F`, or `.docs\u002Fstories\u002F` in\nany reference that directs an amendment. DECIDE performs any required amendment before this plan is\nauthored; BUILD must never receive that mutation as a task. A path naming this plan's own feature is\nnot prohibited.\n\n### 3a. No Terminal Catch-All Validation Task\n\nA plan MUST NOT end with a catch-all validation task whose purpose is to prove, validate, confirm,\nor re-run the completed feature as a whole. Do not create a terminal \"did everything work?\",\n\"end-to-end proof\", \"full-flow validation\", or similar task after the behavior-owning implementation\ntasks. `\u002Fwriting-system-tests` authors the story-level acceptance specs at BUILD entry, before\nimplementation; the native\n`test-suite` gate, `\u002Fmanual-test`, `\u002Fprd-audit`, and the as-built `\u002Farchitecture-review` validate the\ncompleted feature afterward.\n\nKeep scoped RED\u002FGREEN tests inside the implementation task that owns the behavior or wiring. A\nbehavior-specific integration task is valid only when it implements a named production integration\npoint, not when it merely exercises the already-completed feature or promises to repair unspecified\nfindings. Aggregate `test-suite` failures and `\u002Fmanual-test` failures return directly to BUILD for\nscoped repair. Blockers from `\u002Fprd-audit`, as-built `\u002Farchitecture-review`, and `\u002Ffinish` route\nthrough `\u002Fremediate` to the appropriate SDLC step or the required human decision. Do not pre-create\na speculative \"fix anything uncovered\" task.\n\n### 3b. `Verify-only:` Marker\n\nA task block MAY include a `**Verify-only:** yes` line to declare that the task is\nexpected to prove existing behavior already satisfies its acceptance criteria, rather\nthan land new code. The match is exact (case-insensitive) on the literal value `yes`;\nany other value, or the line's absence, means the task is NOT verify-only.\n\nUse `**Verify-only:** yes` (or `**Type:** verification`) for a task that verifies or\ndocuments behavior that may already exist. `prd_audit` judges plan completion against its\nacceptance criteria, while `build_review`'s non-blocking advisory\nwork-happened floor recognizes this marker. Never mark a task that delivers new or changed\nbehavior: over-marking widens the exemption and is forbidden.\n\nVerify-only tasks preferably complete via an empty commit rather than a code commit:\ncarry a `Task: \u003Cid>` trailer and an `Evidence: skipped \u003Creason>` trailer (see\n`skills\u002Ftdd\u002FSKILL.md`'s \"Commit-less Completions: Evidence Trailers\" section for the\nexact commit form and the sibling `Evidence: satisfied-by \u003Csha>` form). Do not force a\nthrowaway code change onto a task just to produce a corroborating commit when the task's\nown acceptance criteria are already met.\n\n**Authoring note:** `build_review` also runs a non-blocking, advisory per-task\nwork-happened floor that flags any plan task with no `Task:`-trailered commit as a \"gap\"\n(warning only, never a HALT). If you're authoring a task you know will legitimately produce\nno commit of its own, mark it `**Verify-only:** yes` here so the floor recognizes it and\ndoesn't flag it.\n\n### 3b-i. Maintenance-change tasks\n\nUse this guidance only when `\u002Fexplore` has written an operator-confirmed\n`Change class:` marker in the track artifact. The marker, not an author inference, selects the\nmaintenance class.\n\nFor a `refactor` or `dependency upgrade` task with no observable behavior change, declare\n`**Verify-only:** yes`; its `Done when:` checks require the existing suite and scoped existing\ntests to pass. A `deletion` task follows `\u002Fcode-removal`, delivers the deletion diff and scoped\ntests proving survivor behavior, and is never Verify-only. Any task that changes observable\nbehavior is not Verify-only and follows the ordinary test-first flow.\n\nOnly `acceptance_specs` may be inapplicable for a maintenance change. `test_suite` (including\nintegrity), `build_review`, `prd_audit`, release disposition, and `finish` all run and block\nexactly as they do for a feature.\n\n### 3c. `Done when:` — Falsifiable Completion Criteria (REQUIRED)\n\nEvery task carries a `**Done when:**` block of 2-5 enumerated checks. Together they are the task's\ncomplete definition of done: when every check passes, the task is finished — full stop.\n\nEach check must be **falsifiable**: a zero-context reviewer evaluates it to a definite yes or no\nwithout appealing to an ideal. Name the test and what it asserts, the command and its expected\noutput, or the concrete diff property. \"The guard is robust\" is not a check; \"the guard rejects the\nthree drift fixtures listed in Steps and exits non-zero\" is.\n\nEach check must be verifiable against a **named mechanism** — the function, file, gate, or state\ntransition whose existence or behavior it asserts. State what that mechanism does to produce the\nmapped acceptance criterion's Then-clause; a paraphrase that names no mechanism does not establish\ndelivery. For example: \"the artifact admission gate returns a rejection for an unsigned artifact\nbefore persistence, as asserted by the unsigned-artifact test.\" A test name alone is insufficient:\nname the behavior it verifies. Existing mechanisms remain valid for `Verify-only:` tasks, and internal\ntasks retain the lower-layer scope allowed by §3d.\n\nWhen a check requires a test as its close evidence, begin that check with the exact tag `[test]`.\nThe tag is part of the authored check text and makes the task-close boundary require a committed\n`test:\u003Cpath>::\u003Ctitle>` reference (or an explicit documented unverified reason).\n\n**Every Then outcome must be asserted.** Split each mapped criterion's Then-clause on its\nconjunctions: every outcome it states — including absence and no-op outcomes such as \"no dispatch\nis attempted\", \"nothing is published\", or \"the branch settles `absent`\" — must be explicitly\nrequired by at least one check in a cited task, with the same precision the criterion uses\n(\"byte-identical\" is not satisfied by \"deep-equal\"). The independent coverage judgement (§7a) refuses\nthe plan before it lands when any outcome is only implied. One check may carry several outcomes; when a task's\ncriteria need more than five checks to cover, split the task rather than dropping outcomes.\n\nFive drift shapes account for most coverage-judgement refusals; check each mapped criterion for them:\n\n- **Layer drift.** The check asserts a lower mechanism than the criterion names — two render calls\n  where the criterion says two dispatches, a store where it says the resolved candidate list. Assert\n  at the criterion's layer, or name how that layer carries the lower result unchanged.\n- **Dropped sequence step.** \"Admitted and invoked\", \"written and published\": each verb is its own\n  outcome. A check that stops at the first verb leaves the rest unasserted.\n- **Inverted configuration.** A criterion combining scopes or settings (\"disallowed globally,\n  permitted for one step\") needs a fixture in exactly that combination, asserting both the\n  override and the unaffected remainder. The mirror-image fixture does not cover it.\n- **Dropped identity.** A criterion whose error or record names several things (\"naming provider\n  pi, capability selfHost, and the owning intake\") needs a check that requires every name. A check\n  that requires two of the three leaves the third unasserted.\n- **Dropped mechanism.** A criterion that says how an outcome is reached (\"completes through the real\n  CLI\") needs a check that requires that path. A check that asserts only that the step runs, or only\n  its result, does not cover it.\n\nFor a preserved\u002Fdefault-mode behavior, make the relevant checks bound any new side effects on that\npath to their intended conditions. For a closed result\u002Fstate\u002Freason set, ensure the checks can\nrepresent each required scenario's actual outcome, including required absence or no-op cases. An\nexisting value may cover several scenarios when its meaning fits; do not invent extra states or\nbroaden the accepted criteria to fill a speculative case. Resolve any conflict with an approved\ndecision during DECIDE rather than leaving BUILD to widen the set or choose which promise wins.\n\nWhen a check uses normalized inputs or an enumerated subset, name the owning check that establishes\nhow source data reaches that representation and how the enumeration covers the criterion's scope.\nAn invalid-input fixture or a self-consistent subset alone does not prove that boundary. Reuse a\nsibling task's proof when it owns the boundary; do not add duplicate integration tasks.\n\nKeep each `Done when:` bullet on one physical line. A wrapped continuation ends the parsed block,\nso later checks can disappear from the land-time count and quoted evidence can lose its grounding.\n\n**Unbounded quality words are banned unless immediately closed.** An outcome stated as\n\"fail-closed\", \"comprehensive\", \"robust\", \"hardened\", \"both directions\", or any similar unbounded\nproperty MUST be followed in the same block by either the closed enumeration of cases it means, or\nthe named mechanism that makes deeper failure impossible. An enforcement property is a mechanism\ndecision, and the mechanism is decided HERE, in DECIDE — never left for the builder to pick or a\nreviewer to litigate. (Precedent: a task saying \"extend the guard … both directions, fail-closed\"\nwith no mechanism let the builder choose textual source extraction; review then correctly found a\ndeeper hole in it every lap until the cumulative cap halted the feature. The fix was a mechanism —\nexecute the parser instead of reading it — that DECIDE could have named up front. See #1763.)\n\n**Review is bound by this block.** A completion judgement measures the task against its `Done\nwhen:` checks. A genuine concern beyond them is new work: it is filed as intake, never raised as a\nfinding that blocks this task. Criteria that turn out to be wrong are amended in DECIDE, not\nstretched in review.\n\nDo not restate Steps or duplicate story acceptance criteria; the block states the observable end\nstate, not the route there. For a `Verify-only:` task the block names what the verification must\nobserve.\n\n### 3d. Cross-Boundary Integration Ownership (REQUIRED WHEN APPLICABLE)\n\nFor each new or changed behavior that crosses a production boundary, assign exactly one task to own\nthe integration proof. That task's `Done when:` must state the observable behavior through an\nappropriate project entry point: for example, a public API or route, CLI, job or worker, event\nconsumer, framework hook, application-service boundary, or the project's equivalent. A direct unit\ntest of a new helper proves the helper works; it does not prove the application reaches it.\n\nThis rule follows behavior, not file type. Do not force an entry-point test onto every task that\ntouches non-test code: an internal helper, type-only edit, or refactor can remain unit-scoped when a\nsibling task owns the boundary integration. At Medium\u002FLarge tier, derive the owning tasks from the\napproved architecture's `## Wiring Surface`; at Small tier, identify any changed production boundary\ndirectly from the scoped behavior. Name stable observable behavior, not a `file:line` or private\ncaller that will drift under refactoring.\n\nThe Wiring Surface is a floor, not the full list. At SHIP, the as-built `\u002Farchitecture-review`\nrequires every primitive the diff adds or changes (an exported function, config key, emitted event,\nor hook) to be reachable from a production entry point at every tier. When a task changes a\nprimitive whose behavior must reach production, some task's `Done when:` must state that behavior\nas observed through an entry point, even when no Wiring Surface entry names it. Wording the\nobligation as observed behavior, rather than as \"call X from Y\", lets `\u002Fsimplify` move the call site\nwithout making the task undeliverable or its evidence stale.\n\n### 4. Task Ordering Rules\n\n1. **Infrastructure first** — Database migrations, model definitions, route setup\n2. **Happy paths before negative paths** — Build the working flow, then test failure modes\n3. **Negative paths are explicit tasks** — Each negative path scenario gets its own task, not a \"clean up error handling\" catch-all\n4. **Integration points identified** — Mark tasks where components connect for the first time\n5. **Dependencies declared** — If Task 5 requires Task 3's model, say so. Declare only genuine\n   dependencies. List in `**Files likely touched:**` every file the task must change, including\n   the call sites, exhaustive unions or switches, and registries its change forces, and nothing more:\n   BUILD schedules by ready frontier and fans out independent tasks concurrently, so a dependency\n   that is merely narrative order, or a file set padded beyond the task's real reach, serializes\n   work that could have been delivered in parallel\n\n### 5. Plan Format\n\n## Slice manifest\n\nFor a Large feature, propose delivery slices only when the resolved project configuration enables\n`stacked_prs.enabled`. Slice a Medium feature only when the operator asks for it. Ask the operator\nto choose stacked or single-PR delivery before writing the section; never add it unasked. On operator\nacceptance, declare one optional `## Slices` section before the first task heading and write\n`Stacked-Delivery: approved` into `.docs\u002Fcomplexity\u002F\u003Cstem>.md`. If the operator declines, author\nno manifest and no sign-off line.\n\nThe manifest table header is exactly `Slice`, `Title`, `Tasks`. A slice lists its member task ids in\nthe `Tasks` cell; every plan task belongs to exactly one slice, and a slice cannot be empty. Keep\neach story's tasks in one slice, and make every `**Story:**` line cite exactly one id. The grammar\nbound is 9 slices; stacking remains bounded by `stacked_prs.max_slices`.\n\nDependencies remain task-local. Every cited task heading must carry exactly one\n`**Dependencies:**` line: write `none` when it has no prerequisite, or a comma-separated list of\n`Task N`\u002F`Tasks N, M` references when it does. A task may depend on a task in its own or an earlier\nslice, never a later slice.\n\n```markdown\n# Implementation Plan: sliced example\n\n## Slices\n\n| Slice | Title | Tasks |\n| --- | --- | --- |\n| 1 | Foundation | 1, 2 |\n| 2 | Follow-up | 3 |\n\n### Task 1: Establish the foundation\n**Story:** 1\n**Dependencies:** none\n\n### Task 2: Add the companion behavior\n**Story:** 1\n**Dependencies:** none\n\n### Task 3: Connect the follow-up\n**Story:** 2\n**Dependencies:** Tasks 1, 2\n```\n\nFor an accepted stacked-delivery proposal, record the sign-off in the complexity artifact:\n\n```markdown\nTier: L\nStacked-Delivery: approved\n```\n\n### `**Stories:**` Reference Forms\n\nThe `**Stories:**` line identifies the one stories artifact the plan covers. Use one of\nthese forms, each optionally followed by a human-readable trailing annotation:\n\n```markdown\n**Stories:** .docs\u002Fstories\u002F\u003Cfeature>.md\n**Stories:** `.docs\u002Fstories\u002F\u003Cfeature>.md` (accepted stories)\n**Stories:** [accepted stories](..\u002Fstories\u002F\u003Cfeature>.md) — reviewed\n```\n\nThe plain and inline-code forms name a repo-relative path. A Markdown link resolves its target\nfrom the plan file; its target must resolve to the selected `.docs\u002Fstories\u002F` artifact. Do not use\nabsolute paths, traversal outside the repository, a prose-only value, or a link to a different\nstories file. Land and backlog discovery use the same resolution rule, so an invalid or unrelated\nreference is refused before it can become a blocked merged spec.\n\n### `**Pattern-source:**` and `**Rename-map:**` Header Forms\n\nThe `**Pattern-source:**` and `**Rename-map:**` lines together declare that this plan replicates\nan existing source pattern. Use both lines or neither: a plan with only one line is malformed.\nThe Pattern-source accepts the same plain, inline-code, and Markdown link reference forms as\n`**Stories:**`; the Rename-map accepts one or more ordered, comma-separated `source -> target`\npairs:\n\n```markdown\n**Pattern-source:** src\u002Fengine\u002Fsource-pattern.ts\n**Pattern-source:** `src\u002Fengine\u002Fsource-pattern.ts` (source pattern)\n**Pattern-source:** [source pattern](..\u002F..\u002Fsrc\u002Fengine\u002Fsource-pattern.ts) — reviewed\n\n**Rename-map:** source-pattern -> plan-pattern-source\n**Rename-map:** source-pattern -> plan-pattern-source, SourcePattern -> PlanPatternSource\n```\n\nThe Pattern-source value must name a repo-relative path. The plain and inline-code forms use that\npath directly; for a Markdown link, the link target is the path. Do not use an absolute path,\ntraversal outside the repository, an empty reference, or a prose-only value. Each Rename-map pair\nmust have a non-empty source and target around exactly one `->`; declaration order and case are\npreserved. A malformed declaration fails closed rather than being treated as an absent pattern.\n\n```markdown\n# Implementation Plan: [Feature Name]\n\n**Date:** YYYY-MM-DD\n**Design:** [link to .docs\u002Fspecs\u002F file]\n**Stories:** [link to .docs\u002Fstories\u002F file]\n**Conflict check:** Clean as of YYYY-MM-DD\n\n## Summary\n[1-2 sentences: what this plan builds and how many tasks]\n\n## Technical Approach\n[The HOW, before the steps: key design decisions, the modules\u002Ffiles involved, data shapes,\nand the sequencing rationale. A paragraph or a few bullets — enough that `build` understands\nthe shape of the work before reading individual tasks.]\n\n## Prerequisites\n- [Any setup, migrations, or dependencies that must exist before task 1]\n\n## Tasks\n\n### Task 1: [Title]\n...\n\n### Task 2: [Title]\n...\n\n## Optional Task Dependency Graph\n[Optional simple text diagram showing which tasks block which, alongside the per-task lines]\n\n## Integration Points\n- After Task [N]: [What can be tested end-to-end at this point]\n\n## Architecture Obligation Coverage\n[Required only when the current spec change set contains a non-deleted land-accepted ADR (`APPROVED`\nor `SUPERSEDED`) with citable\ndecisions. Use the exact table contract from Section 7.]\n\n## Verification\n- [ ] All happy path criteria covered by at least one task\n- [ ] All negative path criteria covered by at least one task\n- [ ] No task exceeds 5 minutes of work\n- [ ] Every task has a `Done when:` block of falsifiable checks; no unbounded quality word is left\n      without its closed enumeration or named mechanism (3c)\n- [ ] Dependencies are explicit and acyclic\n- [ ] Tasks do not invalidate each other's fixtures or assertions; plan review sweeps this\n      at Medium and Large tier, and Small tier gains no required step for it\n```\n\n### 5b. Task Header Format and ID Grammar\n\n**Task ID Grammar:** Task ids can be:\n- **Numeric:** `1`, `18`, `100` (legacy, still supported)\n- **Dotted:** `1.2`, `2.1.3` (for subtask notation)\n- **Alphanumeric with separators:** `task_1`, `rem-adr-001`, `task-name-02`\n- **Characters allowed:** `[A-Za-z0-9._-]` (letters, digits, dots, underscores, hyphens)\n\nExamples:\n```markdown\n### Task 1: Basic feature\n### Task 1.2: Subtask of task 1\n### Task rem-adr-001: Remediation for ADR-001\n### Task task_setup_1: Project setup\n```\n\n**Trailer matching:** Commit trailers use the same id grammar for consistency:\n```\nTask: 1.2\nTask: rem-adr-001\n```\n\nThe parser and trailer matcher use identical grammar to ensure deterministic round-trip:\nparse plan → extract ids → emit trailers → re-parse → identical ids.\n\n### 6. Scope Sanity Check\n\nAfter generating tasks, check the total count:\n\n| Task Count | Action |\n|---|---|\n| 1-20 | Normal — proceed |\n| 21-29 | Warning — surface to user: \"This plan has N tasks (~X hours). Consider splitting into multiple features.\" |\n| 30+ | Hard stop — refused when the spec is landed unless the plan carries an authorized scope exception. Break into separately plannable features and run the stories and plan steps for each. |\n\nReaching this table with 30+ tasks usually means the split was missed upstream. `\u002Farchitecture-review`\n§3a owns the split decision before stories are written, and its rules for ordering, flagging, and\nreachability apply here too.\n\nThe only exception for a plan with 30 or more tasks is exactly one\n`**Scope-exception:** \u003Cnon-empty rationale>` declaration on one physical line in the plan. A\nmissing, empty, or duplicate declaration is rejected when the spec is landed; a valid rationale is\nthe recorded authorization for the oversized plan.\n\n### 7. Coverage Check\n\n**GATE: Every story acceptance criterion (happy AND negative) must map to at least one task.**\n\nAfter generating the plan, cross-reference:\n- For each acceptance criterion in `.docs\u002Fstories\u002F`, find the task(s) that cover it\n- If any criterion is uncovered, add a task\n- For each row, list the criterion's Then outcomes and confirm the cited task's checks explicitly\n  require every one (§3c); widen a check or add one for any outcome that is only implied\n- **Contradiction pass (mandatory at Small tier):** check every task's Done-when bullets and required behavior\n  against *every* criterion, not only those it cites — negative paths and \"only\"\u002F\"never\"\u002F\"no\"\n  constraints first. If satisfying a task would violate a criterion, or the task's design cannot\n  represent state a criterion depends on, fix the plan before landing or surface it to the operator.\n  Example: Story 6 negative \"the only assertion changes are the added credential option\" vs a task\n  whose Done-when requires new endpoint assertions — covered, yet contradictory. The pass is run by\n  an independent judge, never the plan's author (§7b).\n- Run the independent coverage judgement (§7a) at every tier. At Medium and Large tier, plan review\n  owns the independent contradiction judgement; at Small tier, run §7b. Resolve every refusal and\n  conflict before landing.\n- Present the coverage mapping to the user\n\nRecord the mapping in a `## Coverage Check` table. At every tier, use one four-cell\ncriterion row per extracted criterion; Tier S is required to carry this table because\nit has no coherence artifact carrier. The Criterion cell is the exact extracted text\n(`Story \u003Cid> happy|negative: Given …, when …, then …`), not a paraphrase. The quote\nmust be taken from one cited task's `Done when` block, and the disposition is\n`diff-local` unless a waiver is required.\n\n| Criterion | Task id(s) | Done when quote | Disposition |\n| --- | --- | --- | --- |\n| Story 2 happy: Given …, when …, then … | 4 | \"the required completion check\" | diff-local |\n\n#### 7a. Independent Coverage Judgement\n\n**GATE: before the plan lands, a fresh subagent judges every criterion row. The plan's author never\njudges its own checks.** This is the only coverage judgement: no engine step re-judges coverage\nbefore BUILD.\n\n1. Build one claim per criterion row: the exact criterion text and every `Done when` bullet of each\n   cited task, verbatim. Include nothing else — no plan prose, stories, files, or rationale — so the\n   subagent sees only the claim and its checks. Number the claims.\n2. Dispatch one subagent with fresh context through the selected host's available subagent facility.\n   Instruct it to apply `skills\u002Fcoverage-binding\u002FSKILL.md` exactly — its judgement policy and its\n   result contract, using the claim numbers as claim ids — and to read nothing beyond the supplied\n   claims. If the host has no subagent facility, stop and tell the operator; do not judge in the\n   authoring context.\n3. For each `does-not-assert`, change the cited task's checks so they require the stated missing\n   assertion (§3c), and update the row's quote if the quoted bullet changed. Then re-judge only the\n   revised claims, in a new subagent.\n4. Stop after three rounds. A claim still refused is a blocking assumption under the correctness\n   gate: interactive runs present it to the operator and wait; autonomous runs HALT naming the\n   refused criteria. Never land it.\n5. Never overrule a refusal by argument, and never edit a criterion to fit a check. Criteria change\n   only through the stories step.\n\n#### 7b. Independent Contradiction Judgement\n\n**GATE: before the plan lands, only at tier S, a fresh subagent checks the whole plan against every\ncriterion and every approved ADR decision the plan is subject to. The plan's author never judges its\nown plan for contradictions.** The author wrote the tasks to fit the criteria it read; a pass in the\nsame context re-reads them the same way. A contradiction that reaches BUILD costs a full build and\nits review laps before it surfaces, and then an amendment and an operator reseal.\n\n1. Supply the subagent with the stories file, every plan task (id, title, Steps, and `Done when`\n   bullets, verbatim), and the `## Decision` section of each approved ADR the plan is subject to:\n   every ADR in the current spec change set, plus every ADR whose filename stem the plan text cites.\n   Include nothing else: no coverage table, rationale, or author commentary.\n2. Dispatch it with fresh context through the selected host's available subagent facility. Instruct\n   it to check every task against every criterion and every decision, cited or not, negative paths\n   and \"only\"\u002F\"never\"\u002F\"no\" constraints first. It records a conflict only when satisfying the task\n   would necessarily violate the criterion or decision, or when the task's design cannot represent\n   state the criterion depends on. A criterion that is merely uncovered, or covered by a different\n   task, is not a conflict. Each conflict names the task, the criterion text or `\u003Cadr-stem>#D\u003Cn>`,\n   and quotes both opposing passages verbatim. If the host has no subagent facility, stop and tell\n   the operator; do not judge in the authoring context.\n3. Resolve each conflict in DECIDE: change the plan, or route a wrong criterion or decision through\n   the stories step or an ADR amendment. Then re-judge in a new subagent.\n4. Stop after three rounds. A conflict still standing is a blocking assumption under the correctness\n   gate: interactive runs present it to the operator and wait; autonomous runs HALT naming the task\n   and the criterion or decision. Never land it.\n5. Never overrule a conflict by argument. If you believe the judge misread, show the operator both\n   passages and let them decide.\n\n**GATE: Every citable decision in each non-deleted land-accepted ADR (`APPROVED` or `SUPERSEDED`) in\nthe current spec change set must have exactly one row in `## Architecture Obligation Coverage`.** Use\nthis table:\n\n```markdown\n| Decision | Disposition | Task(s) | Evidence |\n| --- | --- | --- | --- |\n| adr-\u003Cstem>#D\u003Cn> | task | task-\u003Cid>[, task-\u003Cid>] | \u003Cexact fragment from a cited task's Done-when block> |\n| adr-\u003Cstem>#D\u003Cn> | existing | none | \u003Cspecific existing implementation evidence> |\n| adr-\u003Cstem>#D\u003Cn> | no-change | none | \u003Cwhy this decision imposes no implementation change> |\n```\n\n`task` is for implementation work and must cite real task ids plus an exact Done-when fragment.\n`existing` is for a decision already satisfied by the codebase. `no-change` is for a constraint or\nrecorded choice that requires no implementation change in this feature. The latter two cite no task\nand require concrete evidence; they are not escape hatches for undecided work.\n\nThe land-time coherence machinery enumerates the ADR decisions and rejects missing, duplicate, or\ninvented rows, invalid dispositions, nonexistent task ids, and task evidence absent from the cited\nDone-when block. `\u002Fcoherence-check` independently judges whether the cited task or existing\u002Fno-change\nevidence actually satisfies the decision; deterministic validation establishes bookkeeping, not\nsemantic truth.\n\n### 8. Save and Suggest\n\nSave the plan to `.docs\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature>.md`\n\n### 8a. Advisory Overlap Scan\n\nBefore the plan is committed, run `ai-conductor overlap-scan --files \u003Ccomma-separated Files set>` over\nthe union of every task's `**Files:**` paths (add `--source-ref\n\u003Cissue ref>` when the feature's originating issue\u002Fintake ref is known). Surface the\nrendered report to the author as-is.\n\nThis check is **advisory only — it never blocks plan authoring.** Unmerged overlap\nis a heads-up for sequencing\u002Fcoordination, not a precondition; proceed to save the\nplan regardless of what the scan reports.\n\n### 8a2. Blocking Protected-Target Scan\n\nBefore committing the plan, run:\n\n```bash\nai-conductor plan-protected-targets .docs\u002Fplans\u002F\u003Cfeature>.md\n```\n\nThis check is **blocking**. It must report no task\u002Fpath violations before the plan is saved or\ncommitted. If it reports another feature's sealed artifact, perform the needed amendment in DECIDE\nand rewrite the task; a `**Files:**` line does not resolve the violation. Do not waive the result or\ndefer the mutation to BUILD.\n\n### 8b. Update Architecture Diagrams\n\nAfter saving the plan, run `\u002Farchitecture-diagram` in plan-update mode to update existing\ndiagrams in place with the planned changes. Diagrams are mutated directly — no separate\nproposed-state files are created.\n\n### 8c. Suggest Next Step\n\n`\u002Farchitecture-review` — the plan must pass architecture review before\nany code is written. The full flow from here is:\n\n```\n\u002Fplan (you are here)\n  → \u002Farchitecture-diagram (generate\u002Fupdate current-state diagrams)\n  → \u002Farchitecture-review (feasibility, alignment, risks — consumes diagrams, may BLOCK)\n  → \u002Fwriting-system-tests (failing acceptance specs from stories)\n  → \u002Fpipeline or \u002Ftdd (implement and verify affected tests; `test_suite` owns configured suite verification)\n```\n\n## Verification\n\n- [ ] Preconditions validated (stories exist, both paths, conflict-check clean)\n- [ ] A `## Slices` section exists only with the operator's stacked-delivery acceptance recorded as\n      `Stacked-Delivery: approved` in `.docs\u002Fcomplexity\u002F\u003Cstem>.md`\n- [ ] Every acceptance criterion maps to at least one task\n- [ ] Every citable decision in each non-deleted land-accepted ADR in the current change set has one\n      mechanically valid Architecture Obligation Coverage row\n- [ ] Every changed cross-boundary behavior has exactly one integration-owning task whose `Done\n      when:` states observable behavior through an appropriate project entry point\n- [ ] Negative paths are explicit tasks (not grouped into catch-alls)\n- [ ] The plan has no terminal catch-all task that re-validates the completed feature\n- [ ] Tasks are 2-5 minute granularity\n- [ ] Each task has specific test and implementation descriptions\n- [ ] Every `Done when:` check names a mechanism and its observable assertion, rather than merely\n      restating the mapped criterion; each bullet occupies one physical line\n- [ ] At Small tier, a fresh subagent found no contradiction between any task and any criterion or\n      subject ADR decision (§7b); at Medium and Large tier, plan review owns that contradiction check\n- [ ] Every outcome in each mapped criterion's Then-clause, including absence\u002Fno-op outcomes, is\n      explicitly required by a cited task's `Done when:` check at the criterion's precision (§3c)\n- [ ] Dependencies are declared and acyclic\n- [ ] Tasks do not invalidate each other's fixtures or assertions; plan review sweeps this\n      at Medium and Large tier, and Small tier gains no required step for it\n- [ ] `ai-conductor plan-protected-targets .docs\u002Fplans\u002F\u003Cfeature>.md` passes with no task\u002Fpath\n      violations; no task targets another feature's sealed artifact\n- [ ] Plan saved to `.docs\u002Fplans\u002F`\n- [ ] Coverage mapping presented to user\n","## Purpose\n\nThe **technical implementation plan** (`HOW`) that `build` ships from — the bridge between the\nbehavioral stories (`WHAT`) and shipped code. Stories say *what* the system should do; the plan\ndecides *how*: the technical approach, which files change, the 2–5 min TDD tasks, and their\ndependencies\u002Fsequencing. Any agent can execute it with zero additional context.\n\nThis is **not** a re-listing of the stories. It adds the engineering layer they don't carry:\narchitecture\u002Fapproach, file-level changes, task ordering, and dependencies. Traceability runs\nPRD `FR-N` → story → task. Every acceptance criterion maps to at least one task; negative-path\nstories become explicit test tasks — not afterthoughts.\n\n**Correctness gate:** a plan encodes technical assumptions (which files change, how a subsystem\nbehaves, what an API accepts). Apply the `\u002Fverify-claims` protocol before finalizing tasks —\nprefer one cheap `Read`\u002F`grep` over a guess, attach a grounded confidence % to claims you cannot\ncheaply verify, and HARD-BLOCK (operator approval interactive, HALT if autonomous) on any\nunconfirmed assumption that changes the technical approach or task breakdown.\n\nOpen with a short **Technical Approach** (a paragraph or few bullets: the design decisions,\nkey modules\u002Ffiles, and sequencing) before the task list, so `build` has the shape of the work\nbefore the steps.\n\nWhen the approach relies on a local implementation or test pattern, capture only the focused\ncontext an implementer needs: the relevant traits, why they fit this work, allowed variation, and\nsearch hints for finding comparable code or tests. This is semantic author guidance, not a new\nheader or parser contract. An implementation task affected by that pattern repeats its relevant\nsubset in its own steps, because isolated implementers do not receive the full plan. Do not anchor\nthe guidance to line numbers or snapshots. If the local pattern does not fit, or a departure would\nchange that task's approach, record the verified no-fit result or the authorized departure in that\ntask before BUILD begins.\n\nKeep this focused pattern context distinct from the exact-copy declaration: use the existing paired\n`**Pattern-source:**` and `**Rename-map:**` headers only when the plan replicates a source pattern,\nand preserve their existing separate semantics and grammar.\n\nRead the `Scope boundary:` from `.docs\u002Ftrack\u002F\u003Cslug>.md` as binding; preserve the confirmed narrow\u002Fcomprehensive breadth outcome; do not permit a materially broader expansion beyond it unless the operator confirms before it enters the artifact.\n\n### Documentation boundary\n\nNever create plan tasks, subtasks, requirements, verification items, or notes for writing or\nupdating ordinary project documentation—even when it accompanies functional work. Documentation-only\nrequests belong to `\u002Fexplore`'s direct delivery route. Plans cover only functional behavior and its\nimplementation.\n\n### Amending a sealed plan\n\nThe first BUILD entry seals DECIDE artifacts. If an operator approves a plan or architecture\namendment after that boundary, committing the amendment does not update the existing\n`.pipeline\u002Fprotected-artifact-seal.json`; the old baseline is intentionally retained until the\nchange is reviewed and audited.\n\nBefore clearing the resulting seal HALT or re-queueing the feature, review the exact protected\nartifact diff and rotate the seal with the engine-owned reseal procedure in the stalled-feature\nrunbook. Record the approved paths and use an honest operator-review trigger. A pre-rebase seal\nrefusal is not a git conflict: do not invoke the rebase resolver or run `git rebase --continue`.\n\n## Practices\n\n### 1. Validate Preconditions\n\n**GATE: Refuse to produce a plan without these artifacts:**\n\n- [ ] Stories exist in `.docs\u002Fstories\u002F` for the feature being planned\n- [ ] Every non-remediation task declares exactly one `**Dependencies:**` line: `none` when\n      independent, or a comma-separated task reference list. Every cited id is declared and the\n      dependency graph is acyclic. Land and the conduct `plan` gate enforce this rule for new plans\n- [ ] Every story has both happy and negative paths\n- [ ] Conflict-check has passed (check `.docs\u002Fconflicts\u002F` for recent clean pass, or no blocking conflicts)\n- [ ] Before the plan declares a `## Slices` section, the operator has explicitly accepted stacked\n      delivery and `.docs\u002Fcomplexity\u002F\u003Cstem>.md` carries `Stacked-Delivery: approved` (see Slice\n      manifest). Land refuses a sliced plan without that line, after plan review has already run\n\nIf preconditions are not met, state which are missing and suggest the appropriate skill.\n\n### 2. Read All Stories\n\n**Skip redundant exploration:** If exploration was already performed in this session (e.g.,\nduring explore), use the existing exploration results. Do not re-explore the same scope —\npass the summary to the Plan agent instead of dispatching new Explore agents.\n\nLoad every story for the feature from `.docs\u002Fstories\u002F`. For each story, extract:\n- All happy path acceptance criteria\n- All negative path acceptance criteria\n- Any dependencies between stories (shared entities, sequencing)\n\n### 3. Generate Implementation Tasks\n\nBreak stories into tasks at **2-5 minute granularity**. Each task follows the TDD cycle:\n\nFor every story criterion, answer: “Can a commit outside this feature's diff\nchange whether this criterion is true?” Record `diff-local` only when the\nanswer is no; `outside-diff` requires a documented coherence waiver rather\nthan silently becoming a BUILD assertion.\n\nRemoval-shaped tasks follow `\u002Fcode-removal`: specify the deletion, including what dies and which\nobservable behavior survives. Do not specify a test whose subject is the removed code's absence, or\nmark a removal task `Verify-only:` merely to document that absence.\n\n```markdown\n### Task [N]: [Descriptive title]\n**Story:** [Reference to story and specific acceptance criterion]\n**Type:** happy-path | negative-path | infrastructure | refactor\n\n**Steps:**\n1. Write failing test: [Specific test description with expected assertion]\n2. Verify test fails (RED)\n3. Implement: [Specific implementation description]\n4. Verify test passes (GREEN)\n5. Commit with message: \"[descriptive message]\"\n\n**Done when:**\n- [Falsifiable check naming the mechanism and observable assertion — see 3c and 3d.]\n- [Second falsifiable check; use 2-5 checks, each on one physical line.]\n\n**Files likely touched:**\n- [file path] — [what changes]\n\nWrite file paths **repo-relative** (e.g. `src\u002Fengine\u002Ffoo.ts`, not\n`foo.ts`): the build evidence gate corroborates each task's commits against these\npaths. Basename\u002Fsuffix forms are tolerated (matched at `\u002F` boundaries, #425), but\nrepo-relative paths corroborate precisely and never collide.\n\n**Verify-only:** [yes, or omit — see 3b below]\n\n**Dependencies:** [Task N that must complete first, or \"none\"]\n```\n\nThe `**Files:**` line is authoritative for the build evidence gate: each task's\ncommits are corroborated against exactly these paths (#424). Paths may be\nplain text or backticked, `;`\u002F`,` separated, on the line or as bullets under\nit. `same` inherits the previous task's set, `same as Task N` inherits task\nN's, and `none` means the task's commit trailer alone corroborates. Backticked\nfile names elsewhere in the task (Steps prose) are only used when no Files\nline exists.\n\nWhen a task is affected by local pattern context from Technical Approach, repeat the applicable\ntraits, rationale, allowed variation, and search hints in that task's Steps prose. Do not add a\nnew task header, parser grammar, line-number anchor, or snapshot reference for this context. Where\nthe task cannot follow the pattern and that changes its approach, its Steps must state either the\nverified no-fit result or the authorized departure.\n\nFor test-owning tasks, map every covered acceptance criterion to a concrete, lowest-sufficient test\ndisposition: name the test layer and the assertion or existing coverage that proves it. Several\ncompatible criteria may be covered together by one focused test; do not prescribe a distinct test\nper criterion, or a production-file change merely to create one. The task must still make clear\nwhich criterion each disposition covers, including negative paths.\n\n**Sealed-artifact prohibition:** A task MUST NOT name another feature's artifact under\n`.docs\u002Farchitecture\u002F`, `.docs\u002Fdecisions\u002F`, `.docs\u002Fplans\u002F`, `.docs\u002Fspecs\u002F`, or `.docs\u002Fstories\u002F` in\nany reference that directs an amendment. DECIDE performs any required amendment before this plan is\nauthored; BUILD must never receive that mutation as a task. A path naming this plan's own feature is\nnot prohibited.\n\n### 3a. No Terminal Catch-All Validation Task\n\nA plan MUST NOT end with a catch-all validation task whose purpose is to prove, validate, confirm,\nor re-run the completed feature as a whole. Do not create a terminal \"did everything work?\",\n\"end-to-end proof\", \"full-flow validation\", or similar task after the behavior-owning implementation\ntasks. `\u002Fwriting-system-tests` authors the story-level acceptance specs at BUILD entry, before\nimplementation; the native\n`test-suite` gate, `\u002Fmanual-test`, `\u002Fprd-audit`, and the as-built `\u002Farchitecture-review` validate the\ncompleted feature afterward.\n\nKeep scoped RED\u002FGREEN tests inside the implementation task that owns the behavior or wiring. A\nbehavior-specific integration task is valid only when it implements a named production integration\npoint, not when it merely exercises the already-completed feature or promises to repair unspecified\nfindings. Aggregate `test-suite` failures and `\u002Fmanual-test` failures return directly to BUILD for\nscoped repair. Blockers from `\u002Fprd-audit`, as-built `\u002Farchitecture-review`, and `\u002Ffinish` route\nthrough `\u002Fremediate` to the appropriate SDLC step or the required human decision. Do not pre-create\na speculative \"fix anything uncovered\" task.\n\n### 3b. `Verify-only:` Marker\n\nA task block MAY include a `**Verify-only:** yes` line to declare that the task is\nexpected to prove existing behavior already satisfies its acceptance criteria, rather\nthan land new code. The match is exact (case-insensitive) on the literal value `yes`;\nany other value, or the line's absence, means the task is NOT verify-only.\n\nUse `**Verify-only:** yes` (or `**Type:** verification`) for a task that verifies or\ndocuments behavior that may already exist. `prd_audit` judges plan completion against its\nacceptance criteria, while `build_review`'s non-blocking advisory\nwork-happened floor recognizes this marker. Never mark a task that delivers new or changed\nbehavior: over-marking widens the exemption and is forbidden.\n\nVerify-only tasks preferably complete via an empty commit rather than a code commit:\ncarry a `Task: \u003Cid>` trailer and an `Evidence: skipped \u003Creason>` trailer (see\n`skills\u002Ftdd\u002FSKILL.md`'s \"Commit-less Completions: Evidence Trailers\" section for the\nexact commit form and the sibling `Evidence: satisfied-by \u003Csha>` form). Do not force a\nthrowaway code change onto a task just to produce a corroborating commit when the task's\nown acceptance criteria are already met.\n\n**Authoring note:** `build_review` also runs a non-blocking, advisory per-task\nwork-happened floor that flags any plan task with no `Task:`-trailered commit as a \"gap\"\n(warning only, never a HALT). If you're authoring a task you know will legitimately produce\nno commit of its own, mark it `**Verify-only:** yes` here so the floor recognizes it and\ndoesn't flag it.\n\n### 3b-i. Maintenance-change tasks\n\nUse this guidance only when `\u002Fexplore` has written an operator-confirmed\n`Change class:` marker in the track artifact. The marker, not an author inference, selects the\nmaintenance class.\n\nFor a `refactor` or `dependency upgrade` task with no observable behavior change, declare\n`**Verify-only:** yes`; its `Done when:` checks require the existing suite and scoped existing\ntests to pass. A `deletion` task follows `\u002Fcode-removal`, delivers the deletion diff and scoped\ntests proving survivor behavior, and is never Verify-only. Any task that changes observable\nbehavior is not Verify-only and follows the ordinary test-first flow.\n\nOnly `acceptance_specs` may be inapplicable for a maintenance change. `test_suite` (including\nintegrity), `build_review`, `prd_audit`, release disposition, and `finish` all run and block\nexactly as they do for a feature.\n\n### 3c. `Done when:` — Falsifiable Completion Criteria (REQUIRED)\n\nEvery task carries a `**Done when:**` block of 2-5 enumerated checks. Together they are the task's\ncomplete definition of done: when every check passes, the task is finished — full stop.\n\nEach check must be **falsifiable**: a zero-context reviewer evaluates it to a definite yes or no\nwithout appealing to an ideal. Name the test and what it asserts, the command and its expected\noutput, or the concrete diff property. \"The guard is robust\" is not a check; \"the guard rejects the\nthree drift fixtures listed in Steps and exits non-zero\" is.\n\nEach check must be verifiable against a **named mechanism** — the function, file, gate, or state\ntransition whose existence or behavior it asserts. State what that mechanism does to produce the\nmapped acceptance criterion's Then-clause; a paraphrase that names no mechanism does not establish\ndelivery. For example: \"the artifact admission gate returns a rejection for an unsigned artifact\nbefore persistence, as asserted by the unsigned-artifact test.\" A test name alone is insufficient:\nname the behavior it verifies. Existing mechanisms remain valid for `Verify-only:` tasks, and internal\ntasks retain the lower-layer scope allowed by §3d.\n\nWhen a check requires a test as its close evidence, begin that check with the exact tag `[test]`.\nThe tag is part of the authored check text and makes the task-close boundary require a committed\n`test:\u003Cpath>::\u003Ctitle>` reference (or an explicit documented unverified reason).\n\n**Every Then outcome must be asserted.** Split each mapped criterion's Then-clause on its\nconjunctions: every outcome it states — including absence and no-op outcomes such as \"no dispatch\nis attempted\", \"nothing is published\", or \"the branch settles `absent`\" — must be explicitly\nrequired by at least one check in a cited task, with the same precision the criterion uses\n(\"byte-identical\" is not satisfied by \"deep-equal\"). The independent coverage judgement (§7a) refuses\nthe plan before it lands when any outcome is only implied. One check may carry several outcomes; when a task's\ncriteria need more than five checks to cover, split the task rather than dropping outcomes.\n\nFive drift shapes account for most coverage-judgement refusals; check each mapped criterion for them:\n\n- **Layer drift.** The check asserts a lower mechanism than the criterion names — two render calls\n  where the criterion says two dispatches, a store where it says the resolved candidate list. Assert\n  at the criterion's layer, or name how that layer carries the lower result unchanged.\n- **Dropped sequence step.** \"Admitted and invoked\", \"written and published\": each verb is its own\n  outcome. A check that stops at the first verb leaves the rest unasserted.\n- **Inverted configuration.** A criterion combining scopes or settings (\"disallowed globally,\n  permitted for one step\") needs a fixture in exactly that combination, asserting both the\n  override and the unaffected remainder. The mirror-image fixture does not cover it.\n- **Dropped identity.** A criterion whose error or record names several things (\"naming provider\n  pi, capability selfHost, and the owning intake\") needs a check that requires every name. A check\n  that requires two of the three leaves the third unasserted.\n- **Dropped mechanism.** A criterion that says how an outcome is reached (\"completes through the real\n  CLI\") needs a check that requires that path. A check that asserts only that the step runs, or only\n  its result, does not cover it.\n\nFor a preserved\u002Fdefault-mode behavior, make the relevant checks bound any new side effects on that\npath to their intended conditions. For a closed result\u002Fstate\u002Freason set, ensure the checks can\nrepresent each required scenario's actual outcome, including required absence or no-op cases. An\nexisting value may cover several scenarios when its meaning fits; do not invent extra states or\nbroaden the accepted criteria to fill a speculative case. Resolve any conflict with an approved\ndecision during DECIDE rather than leaving BUILD to widen the set or choose which promise wins.\n\nWhen a check uses normalized inputs or an enumerated subset, name the owning check that establishes\nhow source data reaches that representation and how the enumeration covers the criterion's scope.\nAn invalid-input fixture or a self-consistent subset alone does not prove that boundary. Reuse a\nsibling task's proof when it owns the boundary; do not add duplicate integration tasks.\n\nKeep each `Done when:` bullet on one physical line. A wrapped continuation ends the parsed block,\nso later checks can disappear from the land-time count and quoted evidence can lose its grounding.\n\n**Unbounded quality words are banned unless immediately closed.** An outcome stated as\n\"fail-closed\", \"comprehensive\", \"robust\", \"hardened\", \"both directions\", or any similar unbounded\nproperty MUST be followed in the same block by either the closed enumeration of cases it means, or\nthe named mechanism that makes deeper failure impossible. An enforcement property is a mechanism\ndecision, and the mechanism is decided HERE, in DECIDE — never left for the builder to pick or a\nreviewer to litigate. (Precedent: a task saying \"extend the guard … both directions, fail-closed\"\nwith no mechanism let the builder choose textual source extraction; review then correctly found a\ndeeper hole in it every lap until the cumulative cap halted the feature. The fix was a mechanism —\nexecute the parser instead of reading it — that DECIDE could have named up front. See #1763.)\n\n**Review is bound by this block.** A completion judgement measures the task against its `Done\nwhen:` checks. A genuine concern beyond them is new work: it is filed as intake, never raised as a\nfinding that blocks this task. Criteria that turn out to be wrong are amended in DECIDE, not\nstretched in review.\n\nDo not restate Steps or duplicate story acceptance criteria; the block states the observable end\nstate, not the route there. For a `Verify-only:` task the block names what the verification must\nobserve.\n\n### 3d. Cross-Boundary Integration Ownership (REQUIRED WHEN APPLICABLE)\n\nFor each new or changed behavior that crosses a production boundary, assign exactly one task to own\nthe integration proof. That task's `Done when:` must state the observable behavior through an\nappropriate project entry point: for example, a public API or route, CLI, job or worker, event\nconsumer, framework hook, application-service boundary, or the project's equivalent. A direct unit\ntest of a new helper proves the helper works; it does not prove the application reaches it.\n\nThis rule follows behavior, not file type. Do not force an entry-point test onto every task that\ntouches non-test code: an internal helper, type-only edit, or refactor can remain unit-scoped when a\nsibling task owns the boundary integration. At Medium\u002FLarge tier, derive the owning tasks from the\napproved architecture's `## Wiring Surface`; at Small tier, identify any changed production boundary\ndirectly from the scoped behavior. Name stable observable behavior, not a `file:line` or private\ncaller that will drift under refactoring.\n\nThe Wiring Surface is a floor, not the full list. At SHIP, the as-built `\u002Farchitecture-review`\nrequires every primitive the diff adds or changes (an exported function, config key, emitted event,\nor hook) to be reachable from a production entry point at every tier. When a task changes a\nprimitive whose behavior must reach production, some task's `Done when:` must state that behavior\nas observed through an entry point, even when no Wiring Surface entry names it. Wording the\nobligation as observed behavior, rather than as \"call X from Y\", lets `\u002Fsimplify` move the call site\nwithout making the task undeliverable or its evidence stale.\n\n### 4. Task Ordering Rules\n\n1. **Infrastructure first** — Database migrations, model definitions, route setup\n2. **Happy paths before negative paths** — Build the working flow, then test failure modes\n3. **Negative paths are explicit tasks** — Each negative path scenario gets its own task, not a \"clean up error handling\" catch-all\n4. **Integration points identified** — Mark tasks where components connect for the first time\n5. **Dependencies declared** — If Task 5 requires Task 3's model, say so. Declare only genuine\n   dependencies. List in `**Files likely touched:**` every file the task must change, including\n   the call sites, exhaustive unions or switches, and registries its change forces, and nothing more:\n   BUILD schedules by ready frontier and fans out independent tasks concurrently, so a dependency\n   that is merely narrative order, or a file set padded beyond the task's real reach, serializes\n   work that could have been delivered in parallel\n\n### 5. Plan Format\n\n## Slice manifest\n\nFor a Large feature, propose delivery slices only when the resolved project configuration enables\n`stacked_prs.enabled`. Slice a Medium feature only when the operator asks for it. Ask the operator\nto choose stacked or single-PR delivery before writing the section; never add it unasked. On operator\nacceptance, declare one optional `## Slices` section before the first task heading and write\n`Stacked-Delivery: approved` into `.docs\u002Fcomplexity\u002F\u003Cstem>.md`. If the operator declines, author\nno manifest and no sign-off line.\n\nThe manifest table header is exactly `Slice`, `Title`, `Tasks`. A slice lists its member task ids in\nthe `Tasks` cell; every plan task belongs to exactly one slice, and a slice cannot be empty. Keep\neach story's tasks in one slice, and make every `**Story:**` line cite exactly one id. The grammar\nbound is 9 slices; stacking remains bounded by `stacked_prs.max_slices`.\n\nDependencies remain task-local. Every cited task heading must carry exactly one\n`**Dependencies:**` line: write `none` when it has no prerequisite, or a comma-separated list of\n`Task N`\u002F`Tasks N, M` references when it does. A task may depend on a task in its own or an earlier\nslice, never a later slice.\n\n```markdown\n# Implementation Plan: sliced example\n\n## Slices\n\n| Slice | Title | Tasks |\n| --- | --- | --- |\n| 1 | Foundation | 1, 2 |\n| 2 | Follow-up | 3 |\n\n### Task 1: Establish the foundation\n**Story:** 1\n**Dependencies:** none\n\n### Task 2: Add the companion behavior\n**Story:** 1\n**Dependencies:** none\n\n### Task 3: Connect the follow-up\n**Story:** 2\n**Dependencies:** Tasks 1, 2\n```\n\nFor an accepted stacked-delivery proposal, record the sign-off in the complexity artifact:\n\n```markdown\nTier: L\nStacked-Delivery: approved\n```\n\n### `**Stories:**` Reference Forms\n\nThe `**Stories:**` line identifies the one stories artifact the plan covers. Use one of\nthese forms, each optionally followed by a human-readable trailing annotation:\n\n```markdown\n**Stories:** .docs\u002Fstories\u002F\u003Cfeature>.md\n**Stories:** `.docs\u002Fstories\u002F\u003Cfeature>.md` (accepted stories)\n**Stories:** [accepted stories](..\u002Fstories\u002F\u003Cfeature>.md) — reviewed\n```\n\nThe plain and inline-code forms name a repo-relative path. A Markdown link resolves its target\nfrom the plan file; its target must resolve to the selected `.docs\u002Fstories\u002F` artifact. Do not use\nabsolute paths, traversal outside the repository, a prose-only value, or a link to a different\nstories file. Land and backlog discovery use the same resolution rule, so an invalid or unrelated\nreference is refused before it can become a blocked merged spec.\n\n### `**Pattern-source:**` and `**Rename-map:**` Header Forms\n\nThe `**Pattern-source:**` and `**Rename-map:**` lines together declare that this plan replicates\nan existing source pattern. Use both lines or neither: a plan with only one line is malformed.\nThe Pattern-source accepts the same plain, inline-code, and Markdown link reference forms as\n`**Stories:**`; the Rename-map accepts one or more ordered, comma-separated `source -> target`\npairs:\n\n```markdown\n**Pattern-source:** src\u002Fengine\u002Fsource-pattern.ts\n**Pattern-source:** `src\u002Fengine\u002Fsource-pattern.ts` (source pattern)\n**Pattern-source:** [source pattern](..\u002F..\u002Fsrc\u002Fengine\u002Fsource-pattern.ts) — reviewed\n\n**Rename-map:** source-pattern -> plan-pattern-source\n**Rename-map:** source-pattern -> plan-pattern-source, SourcePattern -> PlanPatternSource\n```\n\nThe Pattern-source value must name a repo-relative path. The plain and inline-code forms use that\npath directly; for a Markdown link, the link target is the path. Do not use an absolute path,\ntraversal outside the repository, an empty reference, or a prose-only value. Each Rename-map pair\nmust have a non-empty source and target around exactly one `->`; declaration order and case are\npreserved. A malformed declaration fails closed rather than being treated as an absent pattern.\n\n```markdown\n# Implementation Plan: [Feature Name]\n\n**Date:** YYYY-MM-DD\n**Design:** [link to .docs\u002Fspecs\u002F file]\n**Stories:** [link to .docs\u002Fstories\u002F file]\n**Conflict check:** Clean as of YYYY-MM-DD\n\n## Summary\n[1-2 sentences: what this plan builds and how many tasks]\n\n## Technical Approach\n[The HOW, before the steps: key design decisions, the modules\u002Ffiles involved, data shapes,\nand the sequencing rationale. A paragraph or a few bullets — enough that `build` understands\nthe shape of the work before reading individual tasks.]\n\n## Prerequisites\n- [Any setup, migrations, or dependencies that must exist before task 1]\n\n## Tasks\n\n### Task 1: [Title]\n...\n\n### Task 2: [Title]\n...\n\n## Optional Task Dependency Graph\n[Optional simple text diagram showing which tasks block which, alongside the per-task lines]\n\n## Integration Points\n- After Task [N]: [What can be tested end-to-end at this point]\n\n## Architecture Obligation Coverage\n[Required only when the current spec change set contains a non-deleted land-accepted ADR (`APPROVED`\nor `SUPERSEDED`) with citable\ndecisions. Use the exact table contract from Section 7.]\n\n## Verification\n- [ ] All happy path criteria covered by at least one task\n- [ ] All negative path criteria covered by at least one task\n- [ ] No task exceeds 5 minutes of work\n- [ ] Every task has a `Done when:` block of falsifiable checks; no unbounded quality word is left\n      without its closed enumeration or named mechanism (3c)\n- [ ] Dependencies are explicit and acyclic\n- [ ] Tasks do not invalidate each other's fixtures or assertions; plan review sweeps this\n      at Medium and Large tier, and Small tier gains no required step for it\n```\n\n### 5b. Task Header Format and ID Grammar\n\n**Task ID Grammar:** Task ids can be:\n- **Numeric:** `1`, `18`, `100` (legacy, still supported)\n- **Dotted:** `1.2`, `2.1.3` (for subtask notation)\n- **Alphanumeric with separators:** `task_1`, `rem-adr-001`, `task-name-02`\n- **Characters allowed:** `[A-Za-z0-9._-]` (letters, digits, dots, underscores, hyphens)\n\nExamples:\n```markdown\n### Task 1: Basic feature\n### Task 1.2: Subtask of task 1\n### Task rem-adr-001: Remediation for ADR-001\n### Task task_setup_1: Project setup\n```\n\n**Trailer matching:** Commit trailers use the same id grammar for consistency:\n```\nTask: 1.2\nTask: rem-adr-001\n```\n\nThe parser and trailer matcher use identical grammar to ensure deterministic round-trip:\nparse plan → extract ids → emit trailers → re-parse → identical ids.\n\n### 6. Scope Sanity Check\n\nAfter generating tasks, check the total count:\n\n| Task Count | Action |\n|---|---|\n| 1-20 | Normal — proceed |\n| 21-29 | Warning — surface to user: \"This plan has N tasks (~X hours). Consider splitting into multiple features.\" |\n| 30+ | Hard stop — refused when the spec is landed unless the plan carries an authorized scope exception. Break into separately plannable features and run the stories and plan steps for each. |\n\nReaching this table with 30+ tasks usually means the split was missed upstream. `\u002Farchitecture-review`\n§3a owns the split decision before stories are written, and its rules for ordering, flagging, and\nreachability apply here too.\n\nThe only exception for a plan with 30 or more tasks is exactly one\n`**Scope-exception:** \u003Cnon-empty rationale>` declaration on one physical line in the plan. A\nmissing, empty, or duplicate declaration is rejected when the spec is landed; a valid rationale is\nthe recorded authorization for the oversized plan.\n\n### 7. Coverage Check\n\n**GATE: Every story acceptance criterion (happy AND negative) must map to at least one task.**\n\nAfter generating the plan, cross-reference:\n- For each acceptance criterion in `.docs\u002Fstories\u002F`, find the task(s) that cover it\n- If any criterion is uncovered, add a task\n- For each row, list the criterion's Then outcomes and confirm the cited task's checks explicitly\n  require every one (§3c); widen a check or add one for any outcome that is only implied\n- **Contradiction pass (mandatory at Small tier):** check every task's Done-when bullets and required behavior\n  against *every* criterion, not only those it cites — negative paths and \"only\"\u002F\"never\"\u002F\"no\"\n  constraints first. If satisfying a task would violate a criterion, or the task's design cannot\n  represent state a criterion depends on, fix the plan before landing or surface it to the operator.\n  Example: Story 6 negative \"the only assertion changes are the added credential option\" vs a task\n  whose Done-when requires new endpoint assertions — covered, yet contradictory. The pass is run by\n  an independent judge, never the plan's author (§7b).\n- Run the independent coverage judgement (§7a) at every tier. At Medium and Large tier, plan review\n  owns the independent contradiction judgement; at Small tier, run §7b. Resolve every refusal and\n  conflict before landing.\n- Present the coverage mapping to the user\n\nRecord the mapping in a `## Coverage Check` table. At every tier, use one four-cell\ncriterion row per extracted criterion; Tier S is required to carry this table because\nit has no coherence artifact carrier. The Criterion cell is the exact extracted text\n(`Story \u003Cid> happy|negative: Given …, when …, then …`), not a paraphrase. The quote\nmust be taken from one cited task's `Done when` block, and the disposition is\n`diff-local` unless a waiver is required.\n\n| Criterion | Task id(s) | Done when quote | Disposition |\n| --- | --- | --- | --- |\n| Story 2 happy: Given …, when …, then … | 4 | \"the required completion check\" | diff-local |\n\n#### 7a. Independent Coverage Judgement\n\n**GATE: before the plan lands, a fresh subagent judges every criterion row. The plan's author never\njudges its own checks.** This is the only coverage judgement: no engine step re-judges coverage\nbefore BUILD.\n\n1. Build one claim per criterion row: the exact criterion text and every `Done when` bullet of each\n   cited task, verbatim. Include nothing else — no plan prose, stories, files, or rationale — so the\n   subagent sees only the claim and its checks. Number the claims.\n2. Dispatch one subagent with fresh context through the selected host's available subagent facility.\n   Instruct it to apply `skills\u002Fcoverage-binding\u002FSKILL.md` exactly — its judgement policy and its\n   result contract, using the claim numbers as claim ids — and to read nothing beyond the supplied\n   claims. If the host has no subagent facility, stop and tell the operator; do not judge in the\n   authoring context.\n3. For each `does-not-assert`, change the cited task's checks so they require the stated missing\n   assertion (§3c), and update the row's quote if the quoted bullet changed. Then re-judge only the\n   revised claims, in a new subagent.\n4. Stop after three rounds. A claim still refused is a blocking assumption under the correctness\n   gate: interactive runs present it to the operator and wait; autonomous runs HALT naming the\n   refused criteria. Never land it.\n5. Never overrule a refusal by argument, and never edit a criterion to fit a check. Criteria change\n   only through the stories step.\n\n#### 7b. Independent Contradiction Judgement\n\n**GATE: before the plan lands, only at tier S, a fresh subagent checks the whole plan against every\ncriterion and every approved ADR decision the plan is subject to. The plan's author never judges its\nown plan for contradictions.** The author wrote the tasks to fit the criteria it read; a pass in the\nsame context re-reads them the same way. A contradiction that reaches BUILD costs a full build and\nits review laps before it surfaces, and then an amendment and an operator reseal.\n\n1. Supply the subagent with the stories file, every plan task (id, title, Steps, and `Done when`\n   bullets, verbatim), and the `## Decision` section of each approved ADR the plan is subject to:\n   every ADR in the current spec change set, plus every ADR whose filename stem the plan text cites.\n   Include nothing else: no coverage table, rationale, or author commentary.\n2. Dispatch it with fresh context through the selected host's available subagent facility. Instruct\n   it to check every task against every criterion and every decision, cited or not, negative paths\n   and \"only\"\u002F\"never\"\u002F\"no\" constraints first. It records a conflict only when satisfying the task\n   would necessarily violate the criterion or decision, or when the task's design cannot represent\n   state the criterion depends on. A criterion that is merely uncovered, or covered by a different\n   task, is not a conflict. Each conflict names the task, the criterion text or `\u003Cadr-stem>#D\u003Cn>`,\n   and quotes both opposing passages verbatim. If the host has no subagent facility, stop and tell\n   the operator; do not judge in the authoring context.\n3. Resolve each conflict in DECIDE: change the plan, or route a wrong criterion or decision through\n   the stories step or an ADR amendment. Then re-judge in a new subagent.\n4. Stop after three rounds. A conflict still standing is a blocking assumption under the correctness\n   gate: interactive runs present it to the operator and wait; autonomous runs HALT naming the task\n   and the criterion or decision. Never land it.\n5. Never overrule a conflict by argument. If you believe the judge misread, show the operator both\n   passages and let them decide.\n\n**GATE: Every citable decision in each non-deleted land-accepted ADR (`APPROVED` or `SUPERSEDED`) in\nthe current spec change set must have exactly one row in `## Architecture Obligation Coverage`.** Use\nthis table:\n\n```markdown\n| Decision | Disposition | Task(s) | Evidence |\n| --- | --- | --- | --- |\n| adr-\u003Cstem>#D\u003Cn> | task | task-\u003Cid>[, task-\u003Cid>] | \u003Cexact fragment from a cited task's Done-when block> |\n| adr-\u003Cstem>#D\u003Cn> | existing | none | \u003Cspecific existing implementation evidence> |\n| adr-\u003Cstem>#D\u003Cn> | no-change | none | \u003Cwhy this decision imposes no implementation change> |\n```\n\n`task` is for implementation work and must cite real task ids plus an exact Done-when fragment.\n`existing` is for a decision already satisfied by the codebase. `no-change` is for a constraint or\nrecorded choice that requires no implementation change in this feature. The latter two cite no task\nand require concrete evidence; they are not escape hatches for undecided work.\n\nThe land-time coherence machinery enumerates the ADR decisions and rejects missing, duplicate, or\ninvented rows, invalid dispositions, nonexistent task ids, and task evidence absent from the cited\nDone-when block. `\u002Fcoherence-check` independently judges whether the cited task or existing\u002Fno-change\nevidence actually satisfies the decision; deterministic validation establishes bookkeeping, not\nsemantic truth.\n\n### 8. Save and Suggest\n\nSave the plan to `.docs\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature>.md`\n\n### 8a. Advisory Overlap Scan\n\nBefore the plan is committed, run `ai-conductor overlap-scan --files \u003Ccomma-separated Files set>` over\nthe union of every task's `**Files:**` paths (add `--source-ref\n\u003Cissue ref>` when the feature's originating issue\u002Fintake ref is known). Surface the\nrendered report to the author as-is.\n\nThis check is **advisory only — it never blocks plan authoring.** Unmerged overlap\nis a heads-up for sequencing\u002Fcoordination, not a precondition; proceed to save the\nplan regardless of what the scan reports.\n\n### 8a2. Blocking Protected-Target Scan\n\nBefore committing the plan, run:\n\n```bash\nai-conductor plan-protected-targets .docs\u002Fplans\u002F\u003Cfeature>.md\n```\n\nThis check is **blocking**. It must report no task\u002Fpath violations before the plan is saved or\ncommitted. If it reports another feature's sealed artifact, perform the needed amendment in DECIDE\nand rewrite the task; a `**Files:**` line does not resolve the violation. Do not waive the result or\ndefer the mutation to BUILD.\n\n### 8b. Update Architecture Diagrams\n\nAfter saving the plan, run `\u002Farchitecture-diagram` in plan-update mode to update existing\ndiagrams in place with the planned changes. Diagrams are mutated directly — no separate\nproposed-state files are created.\n\n### 8c. Suggest Next Step\n\n`\u002Farchitecture-review` — the plan must pass architecture review before\nany code is written. The full flow from here is:\n\n```\n\u002Fplan (you are here)\n  → \u002Farchitecture-diagram (generate\u002Fupdate current-state diagrams)\n  → \u002Farchitecture-review (feasibility, alignment, risks — consumes diagrams, may BLOCK)\n  → \u002Fwriting-system-tests (failing acceptance specs from stories)\n  → \u002Fpipeline or \u002Ftdd (implement and verify affected tests; `test_suite` owns configured suite verification)\n```\n\n## Verification\n\n- [ ] Preconditions validated (stories exist, both paths, conflict-check clean)\n- [ ] A `## Slices` section exists only with the operator's stacked-delivery acceptance recorded as\n      `Stacked-Delivery: approved` in `.docs\u002Fcomplexity\u002F\u003Cstem>.md`\n- [ ] Every acceptance criterion maps to at least one task\n- [ ] Every citable decision in each non-deleted land-accepted ADR in the current change set has one\n      mechanically valid Architecture Obligation Coverage row\n- [ ] Every changed cross-boundary behavior has exactly one integration-owning task whose `Done\n      when:` states observable behavior through an appropriate project entry point\n- [ ] Negative paths are explicit tasks (not grouped into catch-alls)\n- [ ] The plan has no terminal catch-all task that re-validates the completed feature\n- [ ] Tasks are 2-5 minute granularity\n- [ ] Each task has specific test and implementation descriptions\n- [ ] Every `Done when:` check names a mechanism and its observable assertion, rather than merely\n      restating the mapped criterion; each bullet occupies one physical line\n- [ ] At Small tier, a fresh subagent found no contradiction between any task and any criterion or\n      subject ADR decision (§7b); at Medium and Large tier, plan review owns that contradiction check\n- [ ] Every outcome in each mapped criterion's Then-clause, including absence\u002Fno-op outcomes, is\n      explicitly required by a cited task's `Done when:` check at the criterion's precision (§3c)\n- [ ] Dependencies are declared and acyclic\n- [ ] Tasks do not invalidate each other's fixtures or assertions; plan review sweeps this\n      at Medium and Large tier, and Small tier gains no required step for it\n- [ ] `ai-conductor plan-protected-targets .docs\u002Fplans\u002F\u003Cfeature>.md` passes with no task\u002Fpath\n      violations; no task targets another feature's sealed artifact\n- [ ] Plan saved to `.docs\u002Fplans\u002F`\n- [ ] Coverage mapping presented to user\n",{"name":5,"phase":37,"requires":43,"standalone":39,"description":7,"enforcement":21,"implicit_invocation":47},[44,45,46],".docs\u002Fstories\u002F with both paths",".docs\u002Fconflicts\u002F clean pass or no blocking conflicts","verify-claims","required","main","60310a111655e2d63b87223befba464932465487","skills\u002Fplan",2,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor","https:\u002F\u002Fgithub.com\u002Fjstoup111","2026-11-11 22:26:29",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add jstoup111\u002Fai-conductor --skill plan",{"tool":61,"command":62},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill plan",{"tool":64,"command":65},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fplan\u002FSKILL.md",true,[],[70,89,127,147,166,179],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":38},"01M70YKSA2H7Q9WSRD1ECEGY20","build-review-dependency-hygiene","Judge whether a feature diff adds unnecessary, insufficiently pinned, or license-incompatible dependencies.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-review-dependency-hygiene\u002FSKILL.md",[],[77,78,79,80,81,82,83,84,85,86,87,88,21],"build","dependency hygiene","dependency","hygiene","build review dependency hygiene","review","feature","diff","dependencies","license","true","judge",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":108,"publishedAt":38},"01M6K3EQQ6ADH3G2RMYK6XE26E","writing-system-tests","Use BEFORE implementing any feature that has stories in .docs\u002Fstories\u002F — generates failing acceptance specs from acceptance criteria as the RED phase of TDD. Generates HTTP\u002Frequest-level acceptance tests for headless\u002FAPI projects, end-to-end UI tests for projects with a frontend, using the project's own test framework and directory conventions.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-system-tests\u002FSKILL.md",[95,100,103],{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":101,"categoryName":102,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[109,110,111,112,113,114,115,116,117,118,119,120,31,121,122,123,124,21,125,126],"writing","system","tests","writing system tests","projects","headless","project","end","implementing","frontend","acceptance","api","directory","ui","framework","failing","phase","request",{"skillNo":128,"name":46,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":38},"01M6K3EHR0QQ1QY1S9RC6D1WTD","Use only when an active workflow is about to rely on a nontrivial factual claim or assumption for a spec, plan, ADR, finding, or code decision. Do not invoke for casual questions, status reports, restatements, or trivially verifiable mechanics.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fverify-claims\u002FSKILL.md",[],[133,31,134,25,135,136,137,138,87,139,34,140,141,142,143,5,29,144,145,146,22,21,20],"verify claims","verify","adr","for","decision","claim","mechanics","use","workflow","code","reports","questions","about","spec",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":38},"01M6K3ED4NF5DJA2Y35MH2JCRC","tdd","Use when implementing any feature or bugfix. Five-step cycle: RED → DOMAIN → GREEN → DOMAIN → COMMIT. Enforces test-first development with domain integrity review at every phase boundary.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[],[149,154,155,156,117,157,82,158,159,160,161,83,162,87,140,163,164,165,20,125],"green","cycle","structural","commit","at","bugfix","integrity","domain","development","with","test","test-first",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":38},"01M6K3E6PEXBXYY2K8TSRTN1JT","stories","Use only within active engineer\u002Fconduct DECIDE after architecture approval, when a committed `.docs\u002Fstories` acceptance artifact is required. Do not invoke for general user-story examples, requirements discussion, or direct implementation requests.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstories\u002FSKILL.md",[],[168,26,25,136,37,36,173,87,34,140,119,174,175,176,31,30,134,177,29,178,22,21,20],"general","requirements","architecture","examples","requests","implementation",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":38},"01M6K3E1HE7267YKFJQ3YFCGW5","stack-land","Use when an operator needs to land reviewed manual changes on the correct closed child of a stacked feature. Operator-invoked only: inspect ownership, propose the safe child with evidence, and require confirmation before opening the landing.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstack-land\u002FSKILL.md",[],[186,187,188,163,31,189,190,191,134,83,192,193,194,195,196,87,197,34,140,198,20,199],"stack","land","stack land","evidence","child","changes","inspect","manual","correct","landing","safe","operator","confirmation","advisory"]