plan

Purpose

The technical implementation plan (HOW) that build ships from — the bridge between the behavioral stories (WHAT) and shipped code. Stories say what the system should do; the plan decides how: the technical approach, which files change, the 2–5 min TDD tasks, and their dependencies/sequencing. Any agent can execute it with zero additional context.

This is not a re-listing of the stories. It adds the engineering layer they don't carry: architecture/approach, file-level changes, task ordering, and dependencies. Traceability runs PRD FR-N → story → task. Every acceptance criterion maps to at least one task; negative-path stories become explicit test tasks — not afterthoughts.

Correctness gate: a plan encodes technical assumptions (which files change, how a subsystem behaves, what an API accepts). Apply the /verify-claims protocol before finalizing tasks — prefer one cheap Read/grep over a guess, attach a grounded confidence % to claims you cannot cheaply verify, and HARD-BLOCK (operator approval interactive, HALT if autonomous) on any unconfirmed assumption that changes the technical approach or task breakdown.

Open with a short Technical Approach (a paragraph or few bullets: the design decisions, key modules/files, and sequencing) before the task list, so build has the shape of the work before the steps.

When the approach relies on a local implementation or test pattern, capture only the focused context an implementer needs: the relevant traits, why they fit this work, allowed variation, and search hints for finding comparable code or tests. This is semantic author guidance, not a new header or parser contract. An implementation task affected by that pattern repeats its relevant subset in its own steps, because isolated implementers do not receive the full plan. Do not anchor the guidance to line numbers or snapshots. If the local pattern does not fit, or a departure would change that task's approach, record the verified no-fit result or the authorized departure in that task before BUILD begins.

Keep this focused pattern context distinct from the exact-copy declaration: use the existing paired **Pattern-source:** and **Rename-map:** headers only when the plan replicates a source pattern, and preserve their existing separate semantics and grammar.

Read the Scope boundary: from .docs/track/<slug>.md as binding; preserve the confirmed narrow/comprehensive breadth outcome; do not permit a materially broader expansion beyond it unless the operator confirms before it enters the artifact.

Documentation boundary

Never create plan tasks, subtasks, requirements, verification items, or notes for writing or updating ordinary project documentation—even when it accompanies functional work. Documentation-only requests belong to /explore's direct delivery route. Plans cover only functional behavior and its implementation.

Amending a sealed plan

The first BUILD entry seals DECIDE artifacts. If an operator approves a plan or architecture amendment after that boundary, committing the amendment does not update the existing .pipeline/protected-artifact-seal.json; the old baseline is intentionally retained until the change is reviewed and audited.

Before clearing the resulting seal HALT or re-queueing the feature, review the exact protected artifact diff and rotate the seal with the engine-owned reseal procedure in the stalled-feature runbook. Record the approved paths and use an honest operator-review trigger. A pre-rebase seal refusal is not a git conflict: do not invoke the rebase resolver or run git rebase --continue.

Practices

1. Validate Preconditions

GATE: Refuse to produce a plan without these artifacts:

• [ ] Stories exist in .docs/stories/ for the feature being planned
• [ ] Every non-remediation task declares exactly one **Dependencies:** line: none when independent, or a comma-separated task reference list. Every cited id is declared and the dependency graph is acyclic. Land and the conduct plan gate enforce this rule for new plans
• [ ] Every story has both happy and negative paths
• [ ] Conflict-check has passed (check .docs/conflicts/ for recent clean pass, or no blocking conflicts)
• [ ] Before the plan declares a ## Slices section, the operator has explicitly accepted stacked delivery and .docs/complexity/<stem>.md carries Stacked-Delivery: approved (see Slice manifest). Land refuses a sliced plan without that line, after plan review has already run

If preconditions are not met, state which are missing and suggest the appropriate skill.

2. Read All Stories

Skip redundant exploration: If exploration was already performed in this session (e.g., during explore), use the existing exploration results. Do not re-explore the same scope — pass the summary to the Plan agent instead of dispatching new Explore agents.

Load every story for the feature from .docs/stories/. For each story, extract:

• All happy path acceptance criteria
• All negative path acceptance criteria
• Any dependencies between stories (shared entities, sequencing)

3. Generate Implementation Tasks

Break stories into tasks at 2-5 minute granularity. Each task follows the TDD cycle:

For every story criterion, answer: “Can a commit outside this feature's diff change whether this criterion is true?” Record diff-local only when the answer is no; outside-diff requires a documented coherence waiver rather than silently becoming a BUILD assertion.

Removal-shaped tasks follow /code-removal: specify the deletion, including what dies and which observable behavior survives. Do not specify a test whose subject is the removed code's absence, or mark a removal task Verify-only: merely to document that absence.

### Task [N]: [Descriptive title]
**Story:** [Reference to story and specific acceptance criterion]
**Type:** happy-path | negative-path | infrastructure | refactor

**Steps:**
1. Write failing test: [Specific test description with expected assertion]
2. Verify test fails (RED)
3. Implement: [Specific implementation description]
4. Verify test passes (GREEN)
5. Commit with message: "[descriptive message]"

**Done when:**
- [Falsifiable check naming the mechanism and observable assertion — see 3c and 3d.]
- [Second falsifiable check; use 2-5 checks, each on one physical line.]

**Files likely touched:**
- [file path] — [what changes]

Write file paths **repo-relative** (e.g. `src/engine/foo.ts`, not
`foo.ts`): the build evidence gate corroborates each task's commits against these
paths. Basename/suffix forms are tolerated (matched at `/` boundaries, #425), but
repo-relative paths corroborate precisely and never collide.

**Verify-only:** [yes, or omit — see 3b below]

**Dependencies:** [Task N that must complete first, or "none"]

The **Files:** line is authoritative for the build evidence gate: each task's commits are corroborated against exactly these paths (#424). Paths may be plain text or backticked, ;/, separated, on the line or as bullets under it. same inherits the previous task's set, same as Task N inherits task N's, and none means the task's commit trailer alone corroborates. Backticked file names elsewhere in the task (Steps prose) are only used when no Files line exists.

When a task is affected by local pattern context from Technical Approach, repeat the applicable traits, rationale, allowed variation, and search hints in that task's Steps prose. Do not add a new task header, parser grammar, line-number anchor, or snapshot reference for this context. Where the task cannot follow the pattern and that changes its approach, its Steps must state either the verified no-fit result or the authorized departure.

For test-owning tasks, map every covered acceptance criterion to a concrete, lowest-sufficient test disposition: name the test layer and the assertion or existing coverage that proves it. Several compatible criteria may be covered together by one focused test; do not prescribe a distinct test per criterion, or a production-file change merely to create one. The task must still make clear which criterion each disposition covers, including negative paths.

Sealed-artifact prohibition: A task MUST NOT name another feature's artifact under .docs/architecture/, .docs/decisions/, .docs/plans/, .docs/specs/, or .docs/stories/ in any reference that directs an amendment. DECIDE performs any required amendment before this plan is authored; BUILD must never receive that mutation as a task. A path naming this plan's own feature is not prohibited.

3a. No Terminal Catch-All Validation Task

A plan MUST NOT end with a catch-all validation task whose purpose is to prove, validate, confirm, or re-run the completed feature as a whole. Do not create a terminal "did everything work?", "end-to-end proof", "full-flow validation", or similar task after the behavior-owning implementation tasks. /writing-system-tests authors the story-level acceptance specs at BUILD entry, before implementation; the native test-suite gate, /manual-test, /prd-audit, and the as-built /architecture-review validate the completed feature afterward.

Keep scoped RED/GREEN tests inside the implementation task that owns the behavior or wiring. A behavior-specific integration task is valid only when it implements a named production integration point, not when it merely exercises the already-completed feature or promises to repair unspecified findings. Aggregate test-suite failures and /manual-test failures return directly to BUILD for scoped repair. Blockers from /prd-audit, as-built /architecture-review, and /finish route through /remediate to the appropriate SDLC step or the required human decision. Do not pre-create a speculative "fix anything uncovered" task.

3b. Verify-only: Marker

A task block MAY include a **Verify-only:** yes line to declare that the task is expected to prove existing behavior already satisfies its acceptance criteria, rather than land new code. The match is exact (case-insensitive) on the literal value yes; any other value, or the line's absence, means the task is NOT verify-only.

Use **Verify-only:** yes (or **Type:** verification) for a task that verifies or documents behavior that may already exist. prd_audit judges plan completion against its acceptance criteria, while build_review's non-blocking advisory work-happened floor recognizes this marker. Never mark a task that delivers new or changed behavior: over-marking widens the exemption and is forbidden.

Verify-only tasks preferably complete via an empty commit rather than a code commit: carry a Task: <id> trailer and an Evidence: skipped <reason> trailer (see skills/tdd/SKILL.md's "Commit-less Completions: Evidence Trailers" section for the exact commit form and the sibling Evidence: satisfied-by <sha> form). Do not force a throwaway code change onto a task just to produce a corroborating commit when the task's own acceptance criteria are already met.

Authoring note: build_review also runs a non-blocking, advisory per-task work-happened floor that flags any plan task with no Task:-trailered commit as a "gap" (warning only, never a HALT). If you're authoring a task you know will legitimately produce no commit of its own, mark it **Verify-only:** yes here so the floor recognizes it and doesn't flag it.

3b-i. Maintenance-change tasks

Use this guidance only when /explore has written an operator-confirmed Change class: marker in the track artifact. The marker, not an author inference, selects the maintenance class.

For a refactor or dependency upgrade task with no observable behavior change, declare **Verify-only:** yes; its Done when: checks require the existing suite and scoped existing tests to pass. A deletion task follows /code-removal, delivers the deletion diff and scoped tests proving survivor behavior, and is never Verify-only. Any task that changes observable behavior is not Verify-only and follows the ordinary test-first flow.

Only acceptance_specs may be inapplicable for a maintenance change. test_suite (including integrity), build_review, prd_audit, release disposition, and finish all run and block exactly as they do for a feature.

3c. Done when: — Falsifiable Completion Criteria (REQUIRED)

Every task carries a **Done when:** block of 2-5 enumerated checks. Together they are the task's complete definition of done: when every check passes, the task is finished — full stop.

Each check must be falsifiable: a zero-context reviewer evaluates it to a definite yes or no without appealing to an ideal. Name the test and what it asserts, the command and its expected output, or the concrete diff property. "The guard is robust" is not a check; "the guard rejects the three drift fixtures listed in Steps and exits non-zero" is.

Each check must be verifiable against a named mechanism — the function, file, gate, or state transition whose existence or behavior it asserts. State what that mechanism does to produce the mapped acceptance criterion's Then-clause; a paraphrase that names no mechanism does not establish delivery. For example: "the artifact admission gate returns a rejection for an unsigned artifact before persistence, as asserted by the unsigned-artifact test." A test name alone is insufficient: name the behavior it verifies. Existing mechanisms remain valid for Verify-only: tasks, and internal tasks retain the lower-layer scope allowed by §3d.

When a check requires a test as its close evidence, begin that check with the exact tag [test]. The tag is part of the authored check text and makes the task-close boundary require a committed test:<path>::<title> reference (or an explicit documented unverified reason).

Every Then outcome must be asserted. Split each mapped criterion's Then-clause on its conjunctions: every outcome it states — including absence and no-op outcomes such as "no dispatch is attempted", "nothing is published", or "the branch settles absent" — must be explicitly required by at least one check in a cited task, with the same precision the criterion uses ("byte-identical" is not satisfied by "deep-equal"). The independent coverage judgement (§7a) refuses the plan before it lands when any outcome is only implied. One check may carry several outcomes; when a task's criteria need more than five checks to cover, split the task rather than dropping outcomes.

Five drift shapes account for most coverage-judgement refusals; check each mapped criterion for them:

• Layer drift. The check asserts a lower mechanism than the criterion names — two render calls where the criterion says two dispatches, a store where it says the resolved candidate list. Assert at the criterion's layer, or name how that layer carries the lower result unchanged.
• Dropped sequence step. "Admitted and invoked", "written and published": each verb is its own outcome. A check that stops at the first verb leaves the rest unasserted.
• Inverted configuration. A criterion combining scopes or settings ("disallowed globally, permitted for one step") needs a fixture in exactly that combination, asserting both the override and the unaffected remainder. The mirror-image fixture does not cover it.
• Dropped identity. A criterion whose error or record names several things ("naming provider pi, capability selfHost, and the owning intake") needs a check that requires every name. A check that requires two of the three leaves the third unasserted.
• Dropped mechanism. A criterion that says how an outcome is reached ("completes through the real CLI") needs a check that requires that path. A check that asserts only that the step runs, or only its result, does not cover it.

For a preserved/default-mode behavior, make the relevant checks bound any new side effects on that path to their intended conditions. For a closed result/state/reason set, ensure the checks can represent each required scenario's actual outcome, including required absence or no-op cases. An existing value may cover several scenarios when its meaning fits; do not invent extra states or broaden the accepted criteria to fill a speculative case. Resolve any conflict with an approved decision during DECIDE rather than leaving BUILD to widen the set or choose which promise wins.

When a check uses normalized inputs or an enumerated subset, name the owning check that establishes how source data reaches that representation and how the enumeration covers the criterion's scope. An invalid-input fixture or a self-consistent subset alone does not prove that boundary. Reuse a sibling task's proof when it owns the boundary; do not add duplicate integration tasks.

Keep each Done when: bullet on one physical line. A wrapped continuation ends the parsed block, so later checks can disappear from the land-time count and quoted evidence can lose its grounding.

Unbounded quality words are banned unless immediately closed. An outcome stated as "fail-closed", "comprehensive", "robust", "hardened", "both directions", or any similar unbounded property MUST be followed in the same block by either the closed enumeration of cases it means, or the named mechanism that makes deeper failure impossible. An enforcement property is a mechanism decision, and the mechanism is decided HERE, in DECIDE — never left for the builder to pick or a reviewer to litigate. (Precedent: a task saying "extend the guard … both directions, fail-closed" with no mechanism let the builder choose textual source extraction; review then correctly found a deeper hole in it every lap until the cumulative cap halted the feature. The fix was a mechanism — execute the parser instead of reading it — that DECIDE could have named up front. See #1763.)

Review is bound by this block. A completion judgement measures the task against its Done when: checks. A genuine concern beyond them is new work: it is filed as intake, never raised as a finding that blocks this task. Criteria that turn out to be wrong are amended in DECIDE, not stretched in review.

Do not restate Steps or duplicate story acceptance criteria; the block states the observable end state, not the route there. For a Verify-only: task the block names what the verification must observe.

3d. Cross-Boundary Integration Ownership (REQUIRED WHEN APPLICABLE)

For each new or changed behavior that crosses a production boundary, assign exactly one task to own the integration proof. That task's Done when: must state the observable behavior through an appropriate project entry point: for example, a public API or route, CLI, job or worker, event consumer, framework hook, application-service boundary, or the project's equivalent. A direct unit test of a new helper proves the helper works; it does not prove the application reaches it.

This rule follows behavior, not file type. Do not force an entry-point test onto every task that touches non-test code: an internal helper, type-only edit, or refactor can remain unit-scoped when a sibling task owns the boundary integration. At Medium/Large tier, derive the owning tasks from the approved architecture's ## Wiring Surface; at Small tier, identify any changed production boundary directly from the scoped behavior. Name stable observable behavior, not a file:line or private caller that will drift under refactoring.

The Wiring Surface is a floor, not the full list. At SHIP, the as-built /architecture-review requires every primitive the diff adds or changes (an exported function, config key, emitted event, or hook) to be reachable from a production entry point at every tier. When a task changes a primitive whose behavior must reach production, some task's Done when: must state that behavior as observed through an entry point, even when no Wiring Surface entry names it. Wording the obligation as observed behavior, rather than as "call X from Y", lets /simplify move the call site without making the task undeliverable or its evidence stale.

4. Task Ordering Rules

1. Infrastructure first — Database migrations, model definitions, route setup
2. Happy paths before negative paths — Build the working flow, then test failure modes
3. Negative paths are explicit tasks — Each negative path scenario gets its own task, not a "clean up error handling" catch-all
4. Integration points identified — Mark tasks where components connect for the first time
5. Dependencies declared — If Task 5 requires Task 3's model, say so. Declare only genuine dependencies. List in **Files likely touched:** every file the task must change, including the call sites, exhaustive unions or switches, and registries its change forces, and nothing more: BUILD schedules by ready frontier and fans out independent tasks concurrently, so a dependency that is merely narrative order, or a file set padded beyond the task's real reach, serializes work that could have been delivered in parallel

5. Plan Format

Slice manifest

For a Large feature, propose delivery slices only when the resolved project configuration enables stacked_prs.enabled. Slice a Medium feature only when the operator asks for it. Ask the operator to choose stacked or single-PR delivery before writing the section; never add it unasked. On operator acceptance, declare one optional ## Slices section before the first task heading and write Stacked-Delivery: approved into .docs/complexity/<stem>.md. If the operator declines, author no manifest and no sign-off line.

The manifest table header is exactly Slice, Title, Tasks. A slice lists its member task ids in the Tasks cell; every plan task belongs to exactly one slice, and a slice cannot be empty. Keep each story's tasks in one slice, and make every **Story:** line cite exactly one id. The grammar bound is 9 slices; stacking remains bounded by stacked_prs.max_slices.

Dependencies remain task-local. Every cited task heading must carry exactly one **Dependencies:** line: write none when it has no prerequisite, or a comma-separated list of Task N/Tasks N, M references when it does. A task may depend on a task in its own or an earlier slice, never a later slice.

# Implementation Plan: sliced example

## Slices

| Slice | Title | Tasks |
| --- | --- | --- |
| 1 | Foundation | 1, 2 |
| 2 | Follow-up | 3 |

### Task 1: Establish the foundation
**Story:** 1
**Dependencies:** none

### Task 2: Add the companion behavior
**Story:** 1
**Dependencies:** none

### Task 3: Connect the follow-up
**Story:** 2
**Dependencies:** Tasks 1, 2

For an accepted stacked-delivery proposal, record the sign-off in the complexity artifact:

Tier: L
Stacked-Delivery: approved

**Stories:** Reference Forms

The **Stories:** line identifies the one stories artifact the plan covers. Use one of these forms, each optionally followed by a human-readable trailing annotation:

**Stories:** .docs/stories/<feature>.md
**Stories:** `.docs/stories/<feature>.md` (accepted stories)
**Stories:** [accepted stories](../stories/<feature>.md) — reviewed

The plain and inline-code forms name a repo-relative path. A Markdown link resolves its target from the plan file; its target must resolve to the selected .docs/stories/ artifact. Do not use absolute paths, traversal outside the repository, a prose-only value, or a link to a different stories file. Land and backlog discovery use the same resolution rule, so an invalid or unrelated reference is refused before it can become a blocked merged spec.

**Pattern-source:** and **Rename-map:** Header Forms

The **Pattern-source:** and **Rename-map:** lines together declare that this plan replicates an existing source pattern. Use both lines or neither: a plan with only one line is malformed. The Pattern-source accepts the same plain, inline-code, and Markdown link reference forms as **Stories:**; the Rename-map accepts one or more ordered, comma-separated source -> target pairs:

**Pattern-source:** src/engine/source-pattern.ts
**Pattern-source:** `src/engine/source-pattern.ts` (source pattern)
**Pattern-source:** [source pattern](../../src/engine/source-pattern.ts) — reviewed

**Rename-map:** source-pattern -> plan-pattern-source
**Rename-map:** source-pattern -> plan-pattern-source, SourcePattern -> PlanPatternSource

The Pattern-source value must name a repo-relative path. The plain and inline-code forms use that path directly; for a Markdown link, the link target is the path. Do not use an absolute path, traversal outside the repository, an empty reference, or a prose-only value. Each Rename-map pair must have a non-empty source and target around exactly one ->; declaration order and case are preserved. A malformed declaration fails closed rather than being treated as an absent pattern.

# Implementation Plan: [Feature Name]

**Date:** YYYY-MM-DD
**Design:** [link to .docs/specs/ file]
**Stories:** [link to .docs/stories/ file]
**Conflict check:** Clean as of YYYY-MM-DD

## Summary
[1-2 sentences: what this plan builds and how many tasks]

## Technical Approach
[The HOW, before the steps: key design decisions, the modules/files involved, data shapes,
and the sequencing rationale. A paragraph or a few bullets — enough that `build` understands
the shape of the work before reading individual tasks.]

## Prerequisites
- [Any setup, migrations, or dependencies that must exist before task 1]

## Tasks

### Task 1: [Title]
...

### Task 2: [Title]
...

## Optional Task Dependency Graph
[Optional simple text diagram showing which tasks block which, alongside the per-task lines]

## Integration Points
- After Task [N]: [What can be tested end-to-end at this point]

## Architecture Obligation Coverage
[Required only when the current spec change set contains a non-deleted land-accepted ADR (`APPROVED`
or `SUPERSEDED`) with citable
decisions. Use the exact table contract from Section 7.]

## Verification
- [ ] All happy path criteria covered by at least one task
- [ ] All negative path criteria covered by at least one task
- [ ] No task exceeds 5 minutes of work
- [ ] Every task has a `Done when:` block of falsifiable checks; no unbounded quality word is left
      without its closed enumeration or named mechanism (3c)
- [ ] Dependencies are explicit and acyclic
- [ ] Tasks do not invalidate each other's fixtures or assertions; plan review sweeps this
      at Medium and Large tier, and Small tier gains no required step for it

5b. Task Header Format and ID Grammar

Task ID Grammar: Task ids can be:

• Numeric: 1, 18, 100 (legacy, still supported)
• Dotted: 1.2, 2.1.3 (for subtask notation)
• Alphanumeric with separators: task_1, rem-adr-001, task-name-02
• Characters allowed: [A-Za-z0-9._-] (letters, digits, dots, underscores, hyphens)

Examples:

### Task 1: Basic feature
### Task 1.2: Subtask of task 1
### Task rem-adr-001: Remediation for ADR-001
### Task task_setup_1: Project setup

Trailer matching: Commit trailers use the same id grammar for consistency:

Task: 1.2
Task: rem-adr-001

The parser and trailer matcher use identical grammar to ensure deterministic round-trip: parse plan → extract ids → emit trailers → re-parse → identical ids.

6. Scope Sanity Check

After generating tasks, check the total count:

Task Count	Action
1-20	Normal — proceed
21-29	Warning — surface to user: "This plan has N tasks (~X hours). Consider splitting into multiple features."
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.

Reaching this table with 30+ tasks usually means the split was missed upstream. /architecture-review §3a owns the split decision before stories are written, and its rules for ordering, flagging, and reachability apply here too.

The only exception for a plan with 30 or more tasks is exactly one **Scope-exception:** <non-empty rationale> declaration on one physical line in the plan. A missing, empty, or duplicate declaration is rejected when the spec is landed; a valid rationale is the recorded authorization for the oversized plan.

7. Coverage Check

GATE: Every story acceptance criterion (happy AND negative) must map to at least one task.

After generating the plan, cross-reference:

• For each acceptance criterion in .docs/stories/, find the task(s) that cover it
• If any criterion is uncovered, add a task
• For each row, list the criterion's Then outcomes and confirm the cited task's checks explicitly require every one (§3c); widen a check or add one for any outcome that is only implied
• Contradiction pass (mandatory at Small tier): check every task's Done-when bullets and required behavior against every criterion, not only those it cites — negative paths and "only"/"never"/"no" constraints first. If satisfying a task would violate a criterion, or the task's design cannot represent state a criterion depends on, fix the plan before landing or surface it to the operator. Example: Story 6 negative "the only assertion changes are the added credential option" vs a task whose Done-when requires new endpoint assertions — covered, yet contradictory. The pass is run by an independent judge, never the plan's author (§7b).
• Run the independent coverage judgement (§7a) at every tier. At Medium and Large tier, plan review owns the independent contradiction judgement; at Small tier, run §7b. Resolve every refusal and conflict before landing.
• Present the coverage mapping to the user

Record the mapping in a ## Coverage Check table. At every tier, use one four-cell criterion row per extracted criterion; Tier S is required to carry this table because it has no coherence artifact carrier. The Criterion cell is the exact extracted text (Story <id> happy|negative: Given …, when …, then …), not a paraphrase. The quote must be taken from one cited task's Done when block, and the disposition is diff-local unless a waiver is required.

Criterion	Task id(s)	Done when quote	Disposition
Story 2 happy: Given …, when …, then …	4	"the required completion check"	diff-local

7a. Independent Coverage Judgement

GATE: before the plan lands, a fresh subagent judges every criterion row. The plan's author never judges its own checks. This is the only coverage judgement: no engine step re-judges coverage before BUILD.

1. Build one claim per criterion row: the exact criterion text and every Done when bullet of each cited task, verbatim. Include nothing else — no plan prose, stories, files, or rationale — so the subagent sees only the claim and its checks. Number the claims.
2. Dispatch one subagent with fresh context through the selected host's available subagent facility. Instruct it to apply skills/coverage-binding/SKILL.md exactly — its judgement policy and its result contract, using the claim numbers as claim ids — and to read nothing beyond the supplied claims. If the host has no subagent facility, stop and tell the operator; do not judge in the authoring context.
3. For each does-not-assert, change the cited task's checks so they require the stated missing assertion (§3c), and update the row's quote if the quoted bullet changed. Then re-judge only the revised claims, in a new subagent.
4. Stop after three rounds. A claim still refused is a blocking assumption under the correctness gate: interactive runs present it to the operator and wait; autonomous runs HALT naming the refused criteria. Never land it.
5. Never overrule a refusal by argument, and never edit a criterion to fit a check. Criteria change only through the stories step.

7b. Independent Contradiction Judgement

GATE: before the plan lands, only at tier S, a fresh subagent checks the whole plan against every criterion and every approved ADR decision the plan is subject to. The plan's author never judges its own plan for contradictions. The author wrote the tasks to fit the criteria it read; a pass in the same context re-reads them the same way. A contradiction that reaches BUILD costs a full build and its review laps before it surfaces, and then an amendment and an operator reseal.

1. Supply the subagent with the stories file, every plan task (id, title, Steps, and Done when bullets, verbatim), and the ## Decision section of each approved ADR the plan is subject to: every ADR in the current spec change set, plus every ADR whose filename stem the plan text cites. Include nothing else: no coverage table, rationale, or author commentary.
2. Dispatch it with fresh context through the selected host's available subagent facility. Instruct it to check every task against every criterion and every decision, cited or not, negative paths and "only"/"never"/"no" constraints first. It records a conflict only when satisfying the task would necessarily violate the criterion or decision, or when the task's design cannot represent state the criterion depends on. A criterion that is merely uncovered, or covered by a different task, is not a conflict. Each conflict names the task, the criterion text or <adr-stem>#D<n>, and quotes both opposing passages verbatim. If the host has no subagent facility, stop and tell the operator; do not judge in the authoring context.
3. Resolve each conflict in DECIDE: change the plan, or route a wrong criterion or decision through the stories step or an ADR amendment. Then re-judge in a new subagent.
4. Stop after three rounds. A conflict still standing is a blocking assumption under the correctness gate: interactive runs present it to the operator and wait; autonomous runs HALT naming the task and the criterion or decision. Never land it.
5. Never overrule a conflict by argument. If you believe the judge misread, show the operator both passages and let them decide.

GATE: Every citable decision in each non-deleted land-accepted ADR (APPROVED or SUPERSEDED) in the current spec change set must have exactly one row in ## Architecture Obligation Coverage. Use this table:

| Decision | Disposition | Task(s) | Evidence |
| --- | --- | --- | --- |
| adr-<stem>#D<n> | task | task-<id>[, task-<id>] | <exact fragment from a cited task's Done-when block> |
| adr-<stem>#D<n> | existing | none | <specific existing implementation evidence> |
| adr-<stem>#D<n> | no-change | none | <why this decision imposes no implementation change> |

task is for implementation work and must cite real task ids plus an exact Done-when fragment. existing is for a decision already satisfied by the codebase. no-change is for a constraint or recorded choice that requires no implementation change in this feature. The latter two cite no task and require concrete evidence; they are not escape hatches for undecided work.

The land-time coherence machinery enumerates the ADR decisions and rejects missing, duplicate, or invented rows, invalid dispositions, nonexistent task ids, and task evidence absent from the cited Done-when block. /coherence-check independently judges whether the cited task or existing/no-change evidence actually satisfies the decision; deterministic validation establishes bookkeeping, not semantic truth.

8. Save and Suggest

Save the plan to .docs/plans/YYYY-MM-DD-<feature>.md

8a. Advisory Overlap Scan

Before the plan is committed, run ai-conductor overlap-scan --files <comma-separated Files set> over the union of every task's **Files:** paths (add --source-ref <issue ref> when the feature's originating issue/intake ref is known). Surface the rendered report to the author as-is.

This check is advisory only — it never blocks plan authoring. Unmerged overlap is a heads-up for sequencing/coordination, not a precondition; proceed to save the plan regardless of what the scan reports.

8a2. Blocking Protected-Target Scan

Before committing the plan, run:

ai-conductor plan-protected-targets .docs/plans/<feature>.md

This check is blocking. It must report no task/path violations before the plan is saved or committed. If it reports another feature's sealed artifact, perform the needed amendment in DECIDE and rewrite the task; a **Files:** line does not resolve the violation. Do not waive the result or defer the mutation to BUILD.

8b. Update Architecture Diagrams

After saving the plan, run /architecture-diagram in plan-update mode to update existing diagrams in place with the planned changes. Diagrams are mutated directly — no separate proposed-state files are created.

8c. Suggest Next Step

/architecture-review — the plan must pass architecture review before any code is written. The full flow from here is:

/plan (you are here)
  → /architecture-diagram (generate/update current-state diagrams)
  → /architecture-review (feasibility, alignment, risks — consumes diagrams, may BLOCK)
  → /writing-system-tests (failing acceptance specs from stories)
  → /pipeline or /tdd (implement and verify affected tests; `test_suite` owns configured suite verification)

Verification

• [ ] Preconditions validated (stories exist, both paths, conflict-check clean)
• [ ] A ## Slices section exists only with the operator's stacked-delivery acceptance recorded as Stacked-Delivery: approved in .docs/complexity/<stem>.md
• [ ] Every acceptance criterion maps to at least one task
• [ ] Every citable decision in each non-deleted land-accepted ADR in the current change set has one mechanically valid Architecture Obligation Coverage row
• [ ] Every changed cross-boundary behavior has exactly one integration-owning task whose Done when: states observable behavior through an appropriate project entry point
• [ ] Negative paths are explicit tasks (not grouped into catch-alls)
• [ ] The plan has no terminal catch-all task that re-validates the completed feature
• [ ] Tasks are 2-5 minute granularity
• [ ] Each task has specific test and implementation descriptions
• [ ] Every Done when: check names a mechanism and its observable assertion, rather than merely restating the mapped criterion; each bullet occupies one physical line
• [ ] At Small tier, a fresh subagent found no contradiction between any task and any criterion or subject ADR decision (§7b); at Medium and Large tier, plan review owns that contradiction check
• [ ] Every outcome in each mapped criterion's Then-clause, including absence/no-op outcomes, is explicitly required by a cited task's Done when: check at the criterion's precision (§3c)
• [ ] Dependencies are declared and acyclic
• [ ] Tasks do not invalidate each other's fixtures or assertions; plan review sweeps this at Medium and Large tier, and Small tier gains no required step for it
• [ ] ai-conductor plan-protected-targets .docs/plans/<feature>.md passes with no task/path violations; no task targets another feature's sealed artifact
• [ ] Plan saved to .docs/plans/
• [ ] Coverage mapping presented to user