devflow-kit 2.4.0 → 2.5.0

package/src/assets/commands/dynamic-build.mds

@@ -4,11 +4,13 @@ argument-hint: "[ticket | issue-url | plan-doc]"
 output-dir: dist/commands
 ---
 @import { authoring_preamble } from "./_partials/_preamble.mds"
-@import { compliance_gate } from "./_partials/_compliance.mds"
+@import { evidence_policy } from "./_partials/_evidence_policy.mds"
 @import { agent_roster, agent_caveats } from "./_partials/_roster.mds"
 @import { gate1_postcode, gate2_acceptance, evaluator_panel, implement_bundle, review_pass, concurrency_doctrine, build_execution_doctrine, engine_output_schema, engine_invariants } from "./_partials/_engine.mds"
 @import { wave_loop, branch_merge_model, merge_doctrine, escalation_model } from "./_partials/_wave.mds"
 @import { acceptance_criteria_contract } from "./_partials/_plan_contract.mds"
+@import { issue_ref_grammar, issue_capture_contract } from "./_partials/_tracker.mds"
+@import "./_partials/_publication.mds" as pub
 
 {authoring_preamble()}
 
@@ -35,8 +37,8 @@ Before authoring, verify:
 
 1. **Workflow tool available:** if the `Workflow` tool is not in your available tools, STOP and tell the user: "The Workflow tool is not available in this session. dynamic-build requires Claude Code's dynamic workflow runtime."
 2. **`agentType` support:** confirmed available (spike F5, 2026-06-11). If spawned agents return no results, check that devflow is installed (`devflow init` has been run).
-3. **GitHub paths:** if the input is a GitHub issue URL, `gh` CLI must be authenticated. If not authenticated, note it and fall back to the issue text the user provided.
-4. **No-remote path:** if the repo has no remote, skip GitHub-dependent steps (issue reading, PR creation) and proceed with local branch operations only.
+3. **Tracker paths:** an issue reference or URL in the input is read through the Git agent, which resolves the configured tracker and its access itself and reports `TRACEABILITY: DEGRADED (\{reason\})` when it cannot read one — then note it and fall back to the issue text the user provided. No tracker CLI is checked here.
+4. **No-remote path:** if the repo has no remote, skip the remote-dependent steps (the wave PR and its evidence) and proceed with local branch operations only; the Git agent reports DEGRADED for any tracker step it cannot reach.
 
 ---
 
@@ -44,12 +46,13 @@ Before authoring, verify:
 
 Before you write the workflow script:
 
-**0. Resolve compliance context**
+**0. Resolve the evidence policy**
 
-{compliance_gate()}
-Reuse this result for every ticket in the wave.
+**Produces:** EVIDENCE_POLICY, ISSUE_REQUIRED, APPLY_CONVENTIONS, REQUIRE_NON_AUTHOR_APPROVAL
 
-When authoring the workflow script, include the resolved value as a constant: `COMPLIANCE = COMPLIANCE_SKILL_INSTALLED ? "enabled" : "(none)"`. Pass `COMPLIANCE: \{COMPLIANCE\}` to Git agent spawns (setup-task and branch-creation). When compliance-gated (`COMPLIANCE_SKILL_INSTALLED === true`), branch names follow the `.devflow/conventions.md` Branch Naming convention if that file exists; degrade gracefully if absent.
+{evidence_policy()}
+
+Author the resolved `ISSUE_REQUIRED` and `APPLY_CONVENTIONS` into the workflow script as constants — pass them as `issueRequired` and `applyConventions` when invoking the workflow — and pass both to the Git `setup-task` spawn.
 
 **1. Apply decisions context**
 
@@ -62,7 +65,8 @@ Note the `budget` value from the Workflow tool context (or default to "medium" i
 **3. Detect mode: SINGLE or WAVE**
 
 - **SINGLE mode:** input is one ticket, one issue, one task description, or one plan document
-- **WAVE mode:** input is a set of GitHub issues (wave labels, milestone, issue list), or the user says "wave" / "all tickets in wave N"
+- **WAVE mode:** input is a set of tracker issues (wave labels, milestone, issue list), or the user says "wave" / "all tickets in wave N"
+- **A `/devflow:dynamic-tickets` ticket directory** (`.devflow/docs/tickets/\{slug\}/\{ts\}/`) is WAVE input: in each ticket file (every `.md` there but `tracking-issue.md`), the `**Issue:**` line directly after `**Depends on:**` is one raw `ISSUE_REFS` token, forwarded to the wave's pre-fetch verbatim — never rendered, normalised or re-derived. A ticket file with no `**Issue:**` line, or more than one, contributes no token; name it in the run summary as `not filed`.
 
 When ambiguous, ask the user before authoring: "Is this a single ticket or a wave of tickets?"
 
@@ -70,24 +74,41 @@ When ambiguous, ask the user before authoring: "Is this a single ticket or a wav
 
 Check for (in priority order):
 - A plan document passed as input (path or inline)
-- A GitHub issue body (fetch via `gh issue view <number>`)
+- An issue body (fetched via the Git agent using `OPERATION: fetch-issue`)
 - The current working context (recent `/devflow:dynamic-plan` output)
 - An in-context task description
 
+{issue_capture_contract()}
+
 Extract or note:
 - Implementation plan (for Code agent prompt and Evaluate agent)
-- Acceptance criteria and test plan (for Gate 2)
+- Acceptance criteria (for Gate 2) — pass them as `criteria` when invoking the workflow
+- The test plan (for Gate 2) — a plan's TP lines, passed only once they pass this check. Copy the plan's `## Test Plan` section byte for byte into a fresh `mktemp` file with the Write tool, never through an interpolated shell string, and run:
+
+```bash
+node "${DEVFLOW_DIR:-$HOME/.devflow}/scripts/verify-evidence.cjs" check tp <that file>; echo "exit=$?"
+```
+
+  Only `exit=0` passes it: pass the section's TP lines, as one string, as `testPlan` when invoking the workflow — a test plan alone still runs the Test agent. Any other result, or a plan with no `## Test Plan` section: omit `testPlan` and note `Test plan: missing or malformed` in the run summary. Nothing is repaired, and a test plan in any other shape — an older JSON one included — is never passed.
+
+In WAVE mode, run this step once per ticket and author the results as `plans`, keyed by the ticket's reference: each ticket gets its own `plan`, `criteria` and checked `testPlan` — never one test plan for the whole wave. Keep each ticket's checked TP lines: step 3 after the workflow builds the wave test plan from them.
 
 If none found: build proceeds Gate-1-only (Gate 2 skipped with a note). Never refuse to build; never fabricate criteria.
 
 **5. Resolve tracking-issue number (optional)**
 
 Check, in priority order:
-- An explicit issue number or GitHub issue URL in the user's input (e.g., `#42`, `42`, or `https://github.com/…/issues/42`)
-- The tracking-issue reference in the ticket set's `tracking-issue.md` (written by `/devflow:dynamic-tickets` at `.devflow/docs/tickets/\{slug\}/\{ts\}/tracking-issue.md`)
+- An explicit candidate issue reference or issue URL in the user's input (e.g. `#42`, `42`, or `https://github.com/…/issues/42`)
+- The `**Issue:**` line directly after the H1 of the ticket set's `tracking-issue.md` (written by `/devflow:dynamic-tickets`' filing step; the file is at `.devflow/docs/tickets/\{slug\}/\{ts\}/tracking-issue.md`), as a raw token — only when the file holds exactly one `**Issue:**` line
 - Otherwise: none
 
-If a number is found, record it as the command-level `ISSUE_NUMBER` and pass it as `issueNumber: <number>` when invoking the workflow (the Code agent threads it through as `ISSUE_NUMBER`). If none is found, pass nothing — `ISSUE_NUMBER` defaults to `"(none)"` in the workflow script.
+{issue_ref_grammar()}
+
+If a number is found, record it as the command-level `ISSUE_NUMBER`:
+- **SINGLE mode:** it is the ticket's own reference. Pass it as `issueNumber: <number>` when invoking the workflow; the engine hands it to setup-task as `ISSUE_INPUT`. If none is found, pass nothing.
+- **WAVE mode:** it is the tracking issue. Only steps 2 and 3 after the workflow use it: step 2 for the wave report, step 3 for the wave block's tracking line. It never reaches a ticket: each ticket's engine gets that ticket's own reference as `issueInput`.
+
+Never pass `ISSUE_PR_LINK` into the workflow. The engine binds each ticket's `ISSUE_NUMBER` and `ISSUE_PR_LINK` from that ticket's own setup-task Output (`### Handoff Values`), never from the token it passed in, and hands both to that ticket's Code agents. No `- **PR link line**:` captured ⇒ `ISSUE_PR_LINK` is `"(none)"` and the Code agent emits the `## Related Issues` heading with no reference.
 
 ---
 
@@ -105,22 +126,43 @@ export const meta = {
 // SINGLE mode: one ticket, one branch, full engine
 
 const TICKET = args.ticket || args[0] || "see task description";
-const BRANCH = args.branch || `ticket/${TICKET.replace(/[^a-z0-9]/gi, '-').toLowerCase()}`;
 const PLAN = args.plan || null;
 const CRITERIA = args.criteria || null;
+const TEST_PLAN = args.testPlan || null;  // the plan's checked TP lines, one string (Pre-authoring step 4)
 const DECISIONS_CONTEXT = args.decisionsContext || "";  // injected before authoring
-const ISSUE_NUMBER = args.issueNumber || "(none)";  // resolved in Pre-authoring step 5
-const COMPLIANCE = args.compliance || "(none)";  // "enabled" when COMPLIANCE_SKILL_INSTALLED, else "(none)"
+const ISSUE_INPUT = args.issueInput || args.issueNumber || "(none)";  // this ticket's OWN raw reference (Pre-authoring step 5; a wave passes issueInput) — setup-task's input, never a Code agent's
+const ISSUE_REQUIRED = String(args.issueRequired) === "false" ? "false" : "true";  // Pre-authoring step 0; only an explicit false turns it off — absent or unrecognised fails closed, like the resolver
+const APPLY_CONVENTIONS = String(args.applyConventions) === "false" ? "false" : "true";
 
-// Phase 1: Git setup — declare the operation; the agent owns the process
-await phase("setup", () =>
+// Phase 1: Git setup — declare the operation; the agent owns the process, the branch name included
+const setup = await phase("setup", () =>
   agent(`OPERATION: setup-task
 BASE_BRANCH: ${args.baseBranch || "HEAD"}
 TASK_DESCRIPTION: ${TICKET}
-COMPLIANCE: ${COMPLIANCE}
-${ISSUE_NUMBER && ISSUE_NUMBER !== "(none)" ? "ISSUE_INPUT: " + ISSUE_NUMBER : ""}`.trim(), { agentType: "Git" })
+ISSUE_REQUIRED: ${ISSUE_REQUIRED}
+APPLY_CONVENTIONS: ${APPLY_CONVENTIONS}
+${ISSUE_INPUT !== "(none)" ? "ISSUE_INPUT: " + ISSUE_INPUT : ""}
+Return: {"branch": "<the - **Branch name**: value under your ### Branch, or (none)>", "issueId": "<the - **Issue ID**: value under your ### Handoff Values, or (none)>", "prLinkLine": "<the - **PR link line**: value, or (none)>"}`, { agentType: "Git" })
 );
 
+// The ticket's own Handoff Values, read from setup-task's Output — never derived from ISSUE_INPUT.
+// An Issue ID is a bare number or a KEY-number, per the provider; any other value — "none", blank, prose — is no capture, so the stop fails closed.
+const ISSUE_ID_SHAPE = /^(?:[1-9][0-9]{0,8}|[A-Z][A-Z0-9_]{0,9}-[1-9][0-9]{0,8})$/;
+const ISSUE_NUMBER = ISSUE_ID_SHAPE.test(String(setup?.issueId ?? "")) ? setup.issueId : "(none)";  // the captured Issue ID; "(none)" ⇒ none was captured
+const ISSUE_PR_LINK = setup?.prLinkLine || "(none)";  // "(none)" ⇒ Code emits the heading with no reference
+// The branch setup-task created, as it reported it: every later phase and the merge use it. The engine never names one.
+const BRANCH = typeof setup?.branch === "string" && setup.branch.trim() !== "" && setup.branch.trim() !== "(none)" ? setup.branch : "(none)";
+
+// Ticket-link stop, before implement. The workflow cannot ask, so it never records an exception: it stops.
+if (ISSUE_REQUIRED === "true" && ISSUE_NUMBER === "(none)") {
+  return { ticket: TICKET, branch: BRANCH, verdict: "ESCALATED", issueId: "(none)", issuePrLink: ISSUE_PR_LINK, escalations: [{ type: "ticket-link-missing", description: "setup-task captured no Issue ID while issues are required — link or create this ticket's issue, then re-run" }] };
+}
+
+// Branch stop, before implement: with no branch there is nothing to build on or merge — a correctness stop, not a shape gate.
+if (BRANCH === "(none)") {
+  return { ticket: TICKET, branch: BRANCH, verdict: "ESCALATED", issueId: ISSUE_NUMBER, issuePrLink: ISSUE_PR_LINK, escalations: [{ type: "branch-missing", description: "setup-task reported no branch name — check its Output, then re-run" }] };
+}
+
 // Phase 2: Implement
 await phase("implement", () =>
   agent(`Implement the following ticket on branch ${BRANCH}:
@@ -133,6 +175,7 @@ Relevant architectural decisions (apply devflow:apply-decisions algorithm):
 ${DECISIONS_CONTEXT}
 
 ISSUE_NUMBER: ${ISSUE_NUMBER}
+ISSUE_PR_LINK: ${ISSUE_PR_LINK}
 
 When you build or run tests to verify your work, use your "Long-running commands" discipline (background-Bash + Monitor poll) for anything that may run silent >120s, and prefer package-scoped commands.
 
@@ -155,6 +198,7 @@ Report: PASS or FAIL with details.`, { agentType: "Validate" });
       await agent(`Fix the validation failures on branch ${BRANCH}:
 ${validation.details}
 ISSUE_NUMBER: ${ISSUE_NUMBER}
+ISSUE_PR_LINK: ${ISSUE_PR_LINK}
 Commit fixes with conventional-commit message.`, { agentType: "Code" });
       const recheck = await agent(`Re-run build, typecheck, lint, tests on branch ${BRANCH}. Report: PASS or FAIL.`, { agentType: "Validate" });
       if (recheck.verdict === "PASS") break;
@@ -175,8 +219,8 @@ Commit fixes with conventional-commit message.`, { agentType: "Code" });
 
 // Phase 4: Gate 2 — acceptance gate (once, before review pass)
 const gate2 = await phase("gate2", async () => {
-  if (!PLAN && !CRITERIA) {
-    return { evaluateVerdict: "SKIPPED", testVerdict: "SKIPPED", skipReasons: ["No plan and no criteria provided"] };
+  if (!PLAN && !CRITERIA && !TEST_PLAN) {
+    return { evaluateVerdict: "SKIPPED", testVerdict: "SKIPPED", skipReasons: ["No plan, no criteria and no test plan provided"] };
   }
 
   let evalVerdict = "SKIPPED";
@@ -197,23 +241,26 @@ Report: PASS or FAIL with rationale.`, { agentType: "Evaluate" }),
       await agent(`Fix the alignment issues identified by the Evaluate agent panel on branch ${BRANCH}:
 ${panel.filter(p => p.verdict === "FAIL").map(p => p.rationale).join("\n")}
 ISSUE_NUMBER: ${ISSUE_NUMBER}
+ISSUE_PR_LINK: ${ISSUE_PR_LINK}
 Self-verify your fix compiles (background-Bash + Monitor for any build >120s — see your "Long-running commands" discipline). Commit fixes.`, { agentType: "Code" });
       evalVerdict = "FAIL-FIXED";  // issues found, fixes applied, not re-evaluated by design
     }
   }
 
   let testVerdict = "SKIPPED";
-  if (CRITERIA) {
+  if (CRITERIA || TEST_PLAN) {
     const testResult = await agent(`Run scenario-based acceptance tests on branch ${BRANCH} against these criteria:
-${CRITERIA}
+${CRITERIA || "(none)"}
+TEST_PLAN: ${TEST_PLAN || "(none)"}
 For any test/build command that may run silent >120s, use the background-Bash + Monitor poll procedure (your "Long-running commands" discipline) so you never trip the 180s watchdog.
-Cover: functionality, API contracts, performance. Report: PASS or FAIL per scenario.`, { agentType: "Test" });
+Cover: functionality, API contracts, performance, and cover every TEST_PLAN scenario. Report: PASS or FAIL per scenario.`, { agentType: "Test" });
     testVerdict = testResult.verdict;
     if (testVerdict === "FAIL") {
       // fix-and-continue — no re-test, no inline Gate 1.
       await agent(`Fix the failing acceptance test scenarios on branch ${BRANCH}:
 ${testResult.failures}
 ISSUE_NUMBER: ${ISSUE_NUMBER}
+ISSUE_PR_LINK: ${ISSUE_PR_LINK}
 Self-verify your fix compiles and the scenarios pass (background-Bash + Monitor for any build/test >120s). Commit fixes.`, { agentType: "Code" });
       testVerdict = "FAIL-FIXED";  // issues found, fixes applied, not re-evaluated by design
     }
@@ -326,6 +373,7 @@ ${JSON.stringify(allFindings.map((f, i) => ({ index: i, description: f.descripti
 ${chunk.map(f => `- ${f.description} (${f.severity})`).join("\n")}
 
 ISSUE_NUMBER: ${ISSUE_NUMBER}
+ISSUE_PR_LINK: ${ISSUE_PR_LINK}
 Fix all findings in this batch. Self-verify your fix compiles (background-Bash + Monitor for any build >120s — see your "Long-running commands" discipline). Commit with conventional-commit message.
 Return: {"status": "fixed"|"blocked", "commitShas": ["<sha>"], "unresolved": ["<description of any finding that could not be fixed>"]}`, { agentType: "Code" });
       chunkResults.push({ chunk, result: r });
@@ -375,6 +423,7 @@ Report: PASS or FAIL with details.`, { agentType: "Validate" });
       await agent(`Fix the final validation failures on branch ${BRANCH}:
 ${failureDetails}
 ISSUE_NUMBER: ${ISSUE_NUMBER}
+ISSUE_PR_LINK: ${ISSUE_PR_LINK}
 Self-verify your fix compiles. Commit fixes with conventional-commit message.`, { agentType: "Code" });
       const recheck = await agent(`Re-run build, typecheck, lint, tests on branch ${BRANCH} (background+Monitor for long commands). Report: PASS or FAIL.`, { agentType: "Validate" });
       if (recheck.verdict === "PASS") break;
@@ -395,15 +444,17 @@ Self-verify your fix compiles. Commit fixes with conventional-commit message.`,
 });
 
 // PASS requires survivingFindings.length === 0 && coverageGaps.length === 0 && gate1Final.verdict !== "ESCALATED"
+// and no FAIL-FIXED Gate 2 verdict: fixes applied but never re-run report UNVERIFIED, never PASS
 const coverageGaps = reviewResult.coverageGaps || [];
-const overallVerdict = (reviewResult.survivingFindings?.length || 0) === 0 && coverageGaps.length === 0 && gate1Final.verdict !== "ESCALATED" ? "PASS" : "PARTIAL";
+const gate2Unverified = [gate2.evaluateVerdict, gate2.testVerdict].includes("FAIL-FIXED");
+const overallVerdict = (reviewResult.survivingFindings?.length || 0) === 0 && coverageGaps.length === 0 && gate1Final.verdict !== "ESCALATED" ? (gate2Unverified ? "UNVERIFIED" : "PASS") : "PARTIAL";
 
-// Phase 6: Report
-return phase("report", () =>
-  agent(`Synthesize the build run for ticket ${TICKET} on branch ${BRANCH}:
+// Phase 6: Report — the phase returns the engine result (engine_output_schema); its verdict is overallVerdict
+return phase("report", async () => {
+  const report = await agent(`Synthesize the build run for ticket ${TICKET} on branch ${BRANCH}:
 - Implementation summary
 - Gate 1 (#1 post-implementation) result
-- Gate 2 result: ${JSON.stringify(gate2)}
+- Gate 2 result: ${JSON.stringify(gate2)} (render FAIL-FIXED as "UNVERIFIED (fixes applied, not re-run)", never PASS)
 - Review: single pass (full branch diff)
 - Final Gate 1 (#2 post-fix): ${JSON.stringify(gate1Final)}
 - Findings disposition:
@@ -411,8 +462,18 @@ return phase("report", () =>
   - SURVIVING: ${reviewResult.survivingFindings?.length || 0} findings not addressed (fix Code agent failed or deferred): ${JSON.stringify(reviewResult.survivingFindings)}
 - Overall verdict: ${overallVerdict}
 
-Write a concise report. Present only surviving findings as outstanding — never present FIXED findings as outstanding. The branch is ready for user review — do NOT merge to main.`, { agentType: "Synthesize" })
-);
+Write a concise report. Present only surviving findings as outstanding — never present FIXED findings as outstanding. The branch is ready for user review — do NOT merge to main.`, { agentType: "Synthesize" });
+  return {
+    ticket: TICKET, branch: BRANCH, verdict: overallVerdict, issueId: ISSUE_NUMBER, issuePrLink: ISSUE_PR_LINK,
+    survivingFindings: reviewResult.survivingFindings || [], fixedFindings: reviewResult.fixedFindings || [],
+    reviewCoverage: { failedFocuses: coverageGaps, complete: coverageGaps.length === 0 },
+    escalations: [
+      ...(gate1Final.verdict === "ESCALATED" ? [{ type: "validation-exhausted", description: gate1Final.reason || "final Gate 1 escalated" }] : []),
+      ...coverageGaps.map(focus => ({ type: "review-coverage-incomplete", description: `review coverage incomplete: ${focus}` })),
+    ],
+    gate2, report,
+  };
+});
 ```
 
 {concurrency_doctrine()}
@@ -451,12 +512,18 @@ When WAVE mode is detected, author a workflow that wraps the single-ticket engin
 
 **Wave workflow structure (author after the SINGLE engine blocks above):**
 
-The wave workflow uses the same phases as SINGLE but wraps them in a wave loop. The integration branch is `wave/<initiative>` — the initiative slug, referenced below as `\{slug\}` — (or the user's current branch). Per-ticket branches are `ticket/<slug>`. The Git agent manages worktrees for parallel-eligible tickets. After every merge: Validate agent (build + test). Escalations accumulate in a list; the final report lists all of them.
+The wave workflow uses the same phases as SINGLE but wraps them in a wave loop. The integration branch is `wave/<initiative>` — the initiative slug, referenced below as `\{slug\}` — (or the user's current branch). Each ticket works on the branch setup-task created. The Git agent manages worktrees for parallel-eligible tickets. After every merge: Validate agent (build + test). Escalations accumulate in a list; the final report lists all of them.
 
 Wave skeleton — compact reference (see `wave_loop()` doctrine for full semantics):
 
 ```js
 // Wave round loop: Design agent reader → per-ticket try/catch → cascade quarantine via next reader
+// runSingleTicketEngine(args) is the SINGLE skeleton above as a function of its OWN args: the wave's
+// args.issueNumber (the tracking issue, Pre-authoring step 5) is never in its scope.
+const WAVE_TICKETS = [...remainingTickets];  // the pre-fetch's refs, in input order — the wave block's row order
+const results = {};  // ticketId → its row of the workflow's return; a ticket with no entry never ran
+// A row from an engine result: the fields step 3 after the workflow renders
+const rowOf = (ticketId, r, merged) => ({ ticket: ticketId, ran: true, verdict: r?.verdict || r?.overallVerdict || null, merged, issuePrLink: r?.issuePrLink || "(none)", evaluateVerdict: r?.gate2?.evaluateVerdict, testVerdict: r?.gate2?.testVerdict, surviving: r?.survivingFindings?.length, coverageComplete: r?.reviewCoverage?.complete });
 const MAX_ROUNDS = Math.max(10, remainingTickets.length * 2 + 5);  // heuristic; always finite
 const waveState = { quarantined: [], round: 0 };
 let reAskedThisDeadlock = false;  // re-ask guard: re-ask once on empty ready-set, then escalate
@@ -477,7 +544,7 @@ Return: {"ready": [...ticket-ids], "blocked": [{"ticket": "id", "namedBlocker":
     { agentType: "Design" }
   );
 
-  const ready = waveRead?.ready || [];
+  const ready = (waveRead?.ready || []).filter(t => remainingTickets.includes(t));  // only the pre-fetch's own refs: a ready ID the reader invents never reaches an engine
   if (ready.length === 0) {
     if (reAskedThisDeadlock) break;  // second empty read → declare deadlock with named blockers, break
     reAskedThisDeadlock = true;      // re-ask once with vacuous-truth rule quoted verbatim
@@ -487,20 +554,31 @@ Return: {"ready": [...ticket-ids], "blocked": [{"ticket": "id", "namedBlocker":
 
   for (const ticketId of ready) {
     try {
-      const engineResult = await runSingleTicketEngine({ ticketId, integrationBranch: INTEGRATION_BRANCH, plans, decisionsContext: DECISIONS_CONTEXT, issueNumber: ISSUE_NUMBER });
-      // Check both verdict (engine_output_schema) and overallVerdict (SINGLE skeleton alias)
-      if ((engineResult.verdict || engineResult.overallVerdict) === "PASS") {
-        await agent(`Merge ticket/${ticketId} to ${INTEGRATION_BRANCH}. Include ticket ID ${ticketId} in the merge commit message. Run Validate agent (build + test) after merge.`, { agentType: "Git" });
+      // ticketId is the ISSUE_REF the pre-fetch heading printed — this ticket's OWN reference: the engine's `ticket` (its TICKET)
+      // and its setup-task ISSUE_INPUT; the engine returns the branch that setup-task created, merged below; plans[ticketId] is its own plan, criteria and checked testPlan (Pre-authoring step 4)
+      const engineResult = await runSingleTicketEngine({ ticket: ticketId, baseBranch: INTEGRATION_BRANCH, ...(plans[ticketId] || {}), decisionsContext: DECISIONS_CONTEXT, issueRequired: ISSUE_REQUIRED, applyConventions: APPLY_CONVENTIONS, issueInput: ticketId });
+      // Check both verdict (engine_output_schema) and overallVerdict (SINGLE skeleton alias).
+      // PASS and UNVERIFIED merge; PARTIAL, FAIL, ESCALATED (the ticket-link and branch stops included) or no verdict quarantine.
+      if (["PASS", "UNVERIFIED"].includes(engineResult.verdict || engineResult.overallVerdict)) {
+        const merge = await agent(`Merge ${engineResult.branch} to ${INTEGRATION_BRANCH}. Include ticket ID ${ticketId} in the merge commit message. Run Validate agent (build + test) after merge.
+Return: {"merged": true} — or {"merged": false, "reason": "<why>"} when the merge or the post-merge build failed and the merge was not kept.`, { agentType: "Git" });
+        results[ticketId] = rowOf(ticketId, engineResult, merge?.merged === true);
+        if (merge?.merged !== true) waveState.quarantined.push({ ticket: ticketId, reason: merge?.reason || "merge or post-merge build failed" });
       } else {
+        results[ticketId] = rowOf(ticketId, engineResult, false);
         waveState.quarantined.push({ ticket: ticketId, reason: engineResult.escalations?.[0]?.description || "engine fail/escalated" });
       }
     } catch (err) {
       // One ticket's crash/stall never kills the wave — quarantine it; cascade propagates to dependents via the next reader round
+      results[ticketId] = rowOf(ticketId, null, false);
       waveState.quarantined.push({ ticket: ticketId, reason: `engine crash: ${String(err)}` });
     }
     remainingTickets = remainingTickets.filter(t => t !== ticketId);
   }
 }
+
+// After the wave report is written: one row per wave ticket, in input order. No entry ⇒ never ran (cascade, deadlock, MAX_ROUNDS).
+return { tickets: WAVE_TICKETS.map(t => results[t] || { ticket: t, ran: false, verdict: null, merged: false, issuePrLink: "(none)" }), quarantined: waveState.quarantined };
 ```
 
 ---
@@ -519,14 +597,122 @@ A workflow cannot pause mid-run. After the build/wave workflow returns, you (the
    WAVE_ID: \{WAVE_ID\}
    WORKTREE_PATH: \{integration worktree root, when the wave ran in a linked worktree; omit if cwd\}"
    ```
-   The Git agent deduplicates via marker `<!-- devflow:wave-report wave:\{WAVE_ID\} -->` — skips if already present. On API failure it degrades gracefully (`TRACEABILITY: DEGRADED (\{reason\})`) and continues — never blocks the post-wave step. This comment is the evidence surface for the PR-less integration-branch path; no other PR machinery is invented.
+   The Git agent deduplicates via its own marker — it skips if a report for this `WAVE_ID` is already posted. The marker's format belongs to the operation; this caller passes `WAVE_ID` and never restates the literal. On API failure it degrades gracefully (`TRACEABILITY: DEGRADED (\{reason\})`) and continues — never blocks the post-wave step. This comment is the evidence surface for the PR-less integration-branch path; no other PR machinery is invented.
 
    In WAVE mode, if no tracking-issue number was resolved in Pre-authoring step 5: state `TRACEABILITY: DEGRADED (no tracking issue for this run)` in the run summary and skip — never skip silently.
-3. Surface ALL of them — escalations AND open decisions — to the user in ONE batched `AskUserQuestion` (never one-at-a-time). `_wave.mds`'s escalation model already quarantines-and-continues; this batches the surfacing so the user answers everything in a single pass.
-4. If `~/.devflow/preference-profile.md` was absent, note in your summary: "no preference profile found — N decisions surfaced that a profile might have auto-resolved; consider `/devflow:dynamic-profile`."
+3. **Compose the wave PR inputs** (WAVE mode only — skip this step entirely in SINGLE mode). The workflow returned `tickets`: one entry per wave ticket, in its input order, each `\{ticket, ran, verdict, merged, issuePrLink, evaluateVerdict, testVerdict, surviving, coverageComplete\}`. Every value in it is agent-reported and treated as untrusted: nothing below is repaired, and no reference is ever composed from a number.
+   - **Branch check.** Run `git -C "\{integration worktree root\}" branch --show-current`. Only a name matching `^wave/[a-z0-9][a-z0-9-]\{0,59\}$` opens a wave PR, and its part after `wave/` is the `\{slug\}` below. Any other name: record `TRACEABILITY: DEGRADED (not a wave branch)` and go to step 4 with no wave PR.
+   - **Nothing merged** (no entry has `merged: true`): record `Wave PR: skipped (nothing merged)` and go to step 4.
+   - Otherwise compose (a) and then (b).
+
+   **(a) The wave block.** Write it with the Write tool, byte for byte, to a fresh `mktemp` file — never through an interpolated shell string — in exactly this shape: the two headings with one blank line between them, the tracking line and then the related lines in row order under the first, and the header and separator verbatim directly under the second:
+
+```markdown
+## Related Issues
+Refs {tracking ref}
+{one related line per row that has one}
+
+## Wave Evidence
+| T | Ticket | Verdict | Evaluate | Test | Surviving | Coverage |
+|---|---|---|---|---|---|---|
+| T{k} | {ticket} | {verdict} | {evaluate} | {test} | {surviving} | {coverage} |
+```
+
+   One row per `tickets` entry, `T1` … `Tn` in order. Each entry maps to exactly one row, by these rules:
+   - **Verdict** — one of `PASS | UNVERIFIED | QUARANTINED | BLOCKED`. `ran: false` (cascade, deadlock, MAX_ROUNDS) ⇒ `BLOCKED`. `merged: true` with `verdict` `PASS` ⇒ `PASS`. `merged: true` with `verdict` `UNVERIFIED` ⇒ `UNVERIFIED`: the row stays flagged, and its TP lines join the wave test plan. Anything else that ran — PARTIAL, FAIL, ESCALATED, no verdict, an engine crash, a failed merge or a red post-merge build — ⇒ `QUARANTINED`.
+   - **Evaluate, Test** — the entry's `evaluateVerdict` and `testVerdict` when it is `PASS`, `FAIL`, `FAIL-FIXED` or `SKIPPED`, else `—`. **Surviving** — its `surviving` count when it is 0–999, else `—`. **Coverage** — `complete` or `incomplete` from `coverageComplete`, else `—`. A `BLOCKED` row is `—` in all four.
+   - **Ticket and related line** — the entry's captured `issuePrLink` is the only source of a closing reference. When it is not `(none)`: a `PASS` or `UNVERIFIED` row's related line is `issuePrLink` verbatim; a `QUARANTINED` row's is `issuePrLink` with a leading `Closes ` replaced by `Refs `; and the Ticket cell is the reference that line names (its text after `Closes ` or `Refs `). When it is `(none)`: no related line, and the Ticket cell is `(none)` on a `PASS` or `UNVERIFIED` row; on any other row it is the entry's `ticket` when that is a `#N` or `KEY-N` reference, else `(none)`.
+
+   **Tracking line** — only when Pre-authoring step 5 resolved a tracking issue whose token is, as a whole, a `#N` or `KEY-N` reference: `Refs ` and that token, verbatim, as the first line under `## Related Issues`. Never `Closes` — the tracking issue outlives the wave. Any other token (a bare number, a URL), or none ⇒ no tracking line: nothing is composed from a number.
+
+   Then check it:
+
+```bash
+node "${DEVFLOW_DIR:-$HOME/.devflow}/scripts/verify-evidence.cjs" check wave <that file>; echo "exit=$?"
+```
+
+   Only `exit=0` admits the file's text, verbatim, as `PR_WAVE_BLOCK`. Any other result: no wave PR — record `Wave PR: not opened (wave block refused: <the code on stderr>)` and go to step 4.
+
+   **Required link** — only when `EVIDENCE_POLICY` is `required`: a `PASS` or `UNVERIFIED` row whose Ticket is `(none)` — a merged ticket whose setup-task captured an Issue ID but no link line, so the wave PR would close nothing for it — ⇒ `Wave PR: BLOCKED (no ticket link for T<k>, …)`, with no wave PR question and the remedy "link or create those tickets' issues, then re-run"; there is no exception. Under `standard` such a row stays as the Ticket rule above renders it.
+
+   **(b) The wave test plan.** Take the checked TP lines each merged row's ticket was given in Pre-authoring step 4, in row order; renumber them `TP-1`, `TP-2`, … and prefix each scenario with its row's `T<k>: `. A line is never shortened or reworded: one whose prefixed scenario would pass 200 characters leaves its ticket with no usable test plan. Write `## Test Plan` and those lines, and nothing else, to `"\{integration worktree root\}/.devflow/docs/evidence-wave-\{slug\}.md"` with the Write tool, then run (the path double-quoted; one rewrite from the same lines after a refusal, never a second):
+
+```bash
+node "${DEVFLOW_DIR:-$HOME/.devflow}/scripts/verify-evidence.cjs" check tp "{integration worktree root}/.devflow/docs/evidence-wave-{slug}.md"; echo "exit=$?"
+node "${DEVFLOW_DIR:-$HOME/.devflow}/scripts/verify-evidence.cjs" render --plan "{integration worktree root}/.devflow/docs/evidence-wave-{slug}.md"; echo "exit=$?"
+```
+
+   Only when both exit 0 is `PR_TEST_PLAN_BLOCK` the render's stdout, byte for byte without its `exit=` line; in every other case it is `(none)`.
+
+   **Required plan** — only when `EVIDENCE_POLICY` is `required`: a merged ticket with no usable test plan ⇒ `Wave PR: BLOCKED (no test plan for T<k>, …)`, more than 200 lines in all ⇒ `Wave PR: BLOCKED (test plan over 200 lines)`, and a plan that did not check and render ⇒ `Wave PR: BLOCKED (test plan malformed)` — each with no wave PR question and the remedy "run `/devflow:dynamic-plan` for those tickets and re-run, or ship them through `/implement`"; no exception is offered here. Otherwise the block is optional: a ticket with no usable test plan is left out of it and named in the summary, and `(none)` is passed when no line remains.
+4. Surface ALL of them — escalations AND open decisions — to the user in ONE batched `AskUserQuestion` (never one-at-a-time). `_wave.mds`'s escalation model already quarantines-and-continues; this batches the surfacing so the user answers everything in a single pass.
+   - **The wave PR question.** Only when step 3 composed `PR_WAVE_BLOCK`, the batch gains exactly one question: "Open the wave PR from wave/\{slug\}? It links \{n\} merged tickets (\{u\} UNVERIFIED) and references \{q\} quarantined." It has exactly two options: open it, or don't. The counts come from the checked block's rows: `\{n\}` PASS and UNVERIFIED, `\{u\}` UNVERIFIED, `\{q\}` QUARANTINED.
+   - A `ticket-link-missing` escalation carries its remedy: link or create that ticket's issue, then re-run. There is no per-ticket exception.
+   - **Headless** — `AskUserQuestion` is unavailable, or no answer comes — is a decline: nothing is created and nothing is pushed.
+5. If `~/.devflow/preference-profile.md` was absent, note in your summary: "no preference profile found — N decisions surfaced that a profile might have auto-resolved; consider `/devflow:dynamic-profile`."
+6. **Wave PR** — only after an explicit "open" in step 4. Spawn:
+   ```
+   Agent(subagent_type="Git"):
+   "OPERATION: ensure-pr-ready
+   WORKTREE_PATH: \{integration worktree root\}
+   PR_DESCRIPTION_GUIDANCE: \{counts only — the wave slug and the merged, quarantined and blocked counts; never an issue title or body\}
+   APPLY_CONVENTIONS: \{APPLY_CONVENTIONS\}
+   PR_WAVE_BLOCK: \{PR_WAVE_BLOCK verbatim\}
+   PR_TEST_PLAN_BLOCK: \{PR_TEST_PLAN_BLOCK verbatim, or (none)\}"
+   ```
+   The Git agent pastes each block only behind its own check. Report its `**PR**` line and any `TRACEABILITY: DEGRADED (\{reason\})` lines. The wave PR is opened here and nowhere else; it is never merged, and main is never touched — the user merges.
 
 Do NOT ask questions mid-workflow — that is impossible (F4). The workflow only WRITES the report; you read it and ask.
 
+7. **Wave PR evidence** — only when step 6 reported the wave PR, after it; it never blocks, and every outcome below goes into the run summary. Take `\{n\}` from step 6's `- **PR**: #\{n\}` line when `\{n\}` matches `^[1-9][0-9]\{0,9\}$` as a whole; no such line ⇒ record `TRACEABILITY: DEGRADED (wave PR number not captured)` and skip this step. `PR_TEST_PLAN_BLOCK` `(none)` ⇒ record `Wave evidence: skipped (no wave test plan)` and skip it.
+
+   **(a) Test the wave.** Spawn one Test agent on the integration worktree with the wave test plan — the TP lines of the `## Test Plan` section step 3(b) wrote to `.devflow/docs/evidence-wave-\{slug\}.md`:
+
+```
+Agent(subagent_type="Test"):
+"ORIGINAL_REQUEST: the merged tickets of wave/{slug}, as the wave test plan names them
+FILES_CHANGED: {the files wave/{slug} changes against the - **Base**: branch step 6 reported}
+TEST_PLAN: {the TP lines of the wave evidence file's ## Test Plan section}
+WORKTREE_PATH: {integration worktree root}
+Cover every TEST_PLAN line on the integration branch as it stands. Report PASS or FAIL with evidence."
+```
+
+   Nothing is fixed here, PASS or FAIL: the wave is done and its PR is open. Report the Test agent's Status.
+
+   **(b) Claims.** Append its TP claims, PASS or FAIL alike, to the `## Claims` section of `"\{integration worktree root\}/.devflow/docs/evidence-wave-\{slug\}.md"` — the file's last section, created when absent. Append only: never edit or remove a claim. Each line is `/implement`'s TP claim, keyed to the 40-hex `HEAD:` the Test agent's report shows:
+
+```
+- TP-<n> <PASS|FAIL|SKIP> sha:<head> by:test exit:<0-255>
+```
+
+   One line per `### Test Plan Evidence` row whose TP is in the wave test plan, with the row's outcome; the line ends at `by:test` when the row's Exit is not a number from 0 to 255. A report whose `HEAD:` is not a single 40-hex SHA — a reported before/after change included — gets no claim: record `Wave evidence: no claims (HEAD not one SHA)`.
+
+   **(c) Push** the integration branch once — never force, no retry — so every claim's SHA is in the PR:
+
+```bash
+git -C "{integration worktree root}" push origin HEAD; echo "exit=$?"
+```
+
+   Any result but `exit=0`, a rejected non-fast-forward push included ⇒ record `TRACEABILITY: DEGRADED (evidence push failed)` and refresh anyway.
+
+   **(d) Refresh.** Resolve the publication value for the integration worktree:
+
+{pub.publication_gate()}
+
+   Then spawn:
+
+```
+Agent(subagent_type="Git"):
+"OPERATION: update-pr-evidence
+PR_NUMBER: {n}
+EVIDENCE_FILE: .devflow/docs/evidence-wave-{slug}.md
+REVIEW_PUBLICATION: {REVIEW_PUBLICATION resolved above, or auto}
+WORKTREE_PATH: {integration worktree root}
+Update the wave PR's test-plan block and post its evidence comment."
+```
+
+   `update-pr-evidence` decides what each publication value means for the evidence comment. Report its `## PR Evidence` block — its `EVIDENCE` line and its `**Body**:` / `**Comment**:` line — or its `TRACEABILITY: DEGRADED (\{reason\})` line; a spawn that returns neither ⇒ `TRACEABILITY: DEGRADED (evidence refresh failed)`. Whatever it returns, the run ends here.
+
 ---
 
 ### Maintenance note

package/src/assets/commands/dynamic-plan.mds

@@ -6,6 +6,7 @@ output-dir: dist/commands
 @import { authoring_preamble } from "./_partials/_preamble.mds"
 @import { agent_roster, agent_caveats } from "./_partials/_roster.mds"
 @import { acceptance_criteria_contract } from "./_partials/_plan_contract.mds"
+@import { issue_ref_grammar, issue_capture_contract } from "./_partials/_tracker.mds"
 
 {authoring_preamble()}
 
@@ -21,7 +22,7 @@ This command instructs you to construct and run a Claude Code dynamic Workflow t
 
 ---
 
-**Requires:** ticket files directory or GitHub issue list; optional `~/.devflow/preference-profile.md`
+**Requires:** ticket files directory or tracker issue list; optional `~/.devflow/preference-profile.md`
 **Produces:** per-ticket plan files + `DECISIONS-NEEDED.md` at `.devflow/docs/design/\{slug\}/\{ts\}/`
 
 ---
@@ -32,8 +33,8 @@ Before authoring, verify:
 
 1. **Workflow tool available:** if the `Workflow` tool is not in your available tools, STOP and tell the user: "The Workflow tool is not available in this session. dynamic-plan requires Claude Code's dynamic workflow runtime."
 2. **`agentType` support:** confirmed available (spike F5, 2026-06-11).
-3. **GitHub paths:** if the input is a list of GitHub issue URLs or numbers, `gh` CLI must be authenticated to read issue bodies. If not authenticated, fall back to reading ticket `.md` files from a local path.
-4. **No-remote path:** if the repo has no remote, skip GitHub-dependent steps and read ticket files from the provided local path.
+3. **Tracker paths:** a list of issue references or URLs is read through the Git agent, which resolves the configured tracker and its access itself and reports `TRACEABILITY: DEGRADED (\{reason\})` when it cannot read an issue — then fall back to reading ticket `.md` files from a local path. No tracker CLI is checked here.
+4. **No-remote path:** if the repo has no remote, read ticket files from the provided local path; the Git agent reports DEGRADED for any issue it cannot reach.
 
 ---
 
@@ -56,11 +57,15 @@ If present, note its contents as `PREFERENCE_PROFILE`. This will be used to auto
 
 Determine the ticket source (in priority order):
 - A directory of ticket `.md` files (from `/devflow:dynamic-tickets` output)
-- A list of GitHub issue numbers/URLs
+- A list of candidate issue references or issue URLs
 - Inline ticket descriptions passed as args
 
+{issue_ref_grammar()}
+
 Read or note the tickets. The agents will read them in full; you need the list and any key constraints.
 
+{issue_capture_contract()}
+
 ---
 
 ### CRITICAL (F4) — AskUserQuestion at the command boundary, NOT inside the workflow
@@ -68,9 +73,16 @@ Read or note the tickets. The agents will read them in full; you need the list a
 A workflow cannot pause mid-run. Open design decisions collected in `DECISIONS-NEEDED.md` are surfaced to the user via **AskUserQuestion AFTER the workflow returns** — at the command boundary. The workflow only WRITES the file; the command (you, the main model) reads it and asks.
 
 After the workflow completes:
-1. Read the `decisionsNeededPath` returned by the workflow (e.g. `.devflow/docs/design/<slug>/<ts>/DECISIONS-NEEDED.md`). Always use the OUTDIR-scoped path the workflow wrote — never the flat `.devflow/docs/design/DECISIONS-NEEDED.md`.
-2. First surface the **Auto-Resolved Decisions** section (decision → resolution → source) for audit, then surface ALL open **Decisions Needed** to the user in ONE batched `AskUserQuestion` (never one-at-a-time).
-3. The user's answers feed into their own plan edits or a follow-up `/devflow:dynamic-plan` run.
+1. **Check each plan's test plan.** For every path in `planPaths`, copy that plan's `## Test Plan` section — the heading and its TP lines, up to the next `## ` heading — byte for byte into a fresh `mktemp` file with the Write tool, never through an interpolated shell string, and run:
+
+```bash
+node "${DEVFLOW_DIR:-$HOME/.devflow}/scripts/verify-evidence.cjs" check tp <that file>; echo "exit=$?"
+```
+
+   Check the section, never the whole plan file: the plan's other `## ` headings are not evidence-file sections, so the script would parse the whole document as the plan. `exit=0` passes. Any other result names that plan `test plan malformed (<code>)` in your summary, `<code>` being the code the script printed on stderr; a plan with no `## Test Plan` section copies as an empty file, which the script refuses. Nothing is repaired: `/devflow:dynamic-build` passes no test plan from that plan.
+2. Read the `decisionsNeededPath` returned by the workflow (e.g. `.devflow/docs/design/<slug>/<ts>/DECISIONS-NEEDED.md`). Always use the OUTDIR-scoped path the workflow wrote — never the flat `.devflow/docs/design/DECISIONS-NEEDED.md`.
+3. First surface the **Auto-Resolved Decisions** section (decision → resolution → source) for audit, then surface ALL open **Decisions Needed** to the user in ONE batched `AskUserQuestion` (never one-at-a-time).
+4. The user's answers feed into their own plan edits or a follow-up `/devflow:dynamic-plan` run.
 
 State this explicitly in the workflow script as a comment: `// AskUserQuestion happens at the command boundary after this workflow returns — NOT here.`
 
@@ -92,6 +104,7 @@ export const meta = {
 const ticketSource = args.ticketSource || args[0] || "see task description";
 const DECISIONS_CONTEXT = args.decisionsContext || "";   // injected before authoring
 const PREFERENCE_PROFILE = args.preferenceProfile || "";  // injected before authoring
+const TP_CONTRACT = args.tpContract || "";  // the "Test-plan line (TP)" contract below — its paragraph and four bullets — passed verbatim as tpContract when invoking the workflow, never pasted into this script (it holds backticks)
 const slug = args.slug || "wave";
 const ts = new Date().toISOString().slice(0,16).replace(/[-:T]/g, (c) => c === 'T' ? '_' : c === ':' ? '' : c);
 const OUTDIR = `.devflow/docs/design/${slug}/${ts}`;
@@ -100,7 +113,7 @@ const OUTDIR = `.devflow/docs/design/${slug}/${ts}`;
 const tickets = await phase("read-tickets", () =>
   agent(`Read all tickets from: ${ticketSource}
 For each ticket, extract: title, summary, wave, dependsOn, scope (in/out), acceptance criteria, open questions, and any existing implementation hints.
-If the source is a directory, read all .md files. If the source is GitHub issues, use gh issue view for each.
+If the source is a directory, read all .md files. If the source is tracker issues, use the Git agent's fetch-issue or fetch-issues-batch operation.
 Return: array of ticket objects with all fields.`, { agentType: "Git" })
 );
 
@@ -130,15 +143,23 @@ Decisions context: ${DECISIONS_CONTEXT}
 Produce:
 1. List of improvements / gaps / edge cases / side-effects identified.
 2. Well-structured acceptance criteria (numbered, positive + negative, at least one negative per ticket). See the acceptance criteria contract below.
-3. A test plan for the Test agent: for each criterion, scenario + setup + expected outcome + verification method.
+3. The test plan for the Test agent as TP lines, numbered from TP-1, at least one per criterion, each in exactly the shape of the test-plan line contract below. Map each scenario onto its line:
+   - the scenario, in plain words, is the line's scenario text — never a path, a reference, a mention or markup;
+   - the number of the criterion it covers is its (AC-m);
+   - its verification method is its method: a test committed to the suite is ci; a command run and read (a load test, a script) is local; a step performed and observed is manual;
+   - the paths it exercises, from the plan's affected files, are its files: globs.
+   Setup and expected outcome never go in a line: give them per TP in testScenarios.
 4. A list of genuine design decisions that require user input (not settled by the plan, the preference profile, or existing ADRs).
 
+Test-plan line contract:
+${TP_CONTRACT}
+
 Acceptance criteria quality bar (apply strictly):
 - Vague criteria ("the feature should work correctly") are NOT acceptable — reject and rewrite.
 - Implementation-coupled criteria ("the function must call X") are NOT acceptable — test behavior, not implementation.
 - Untestable criteria are NOT acceptable.
 
-Return: { ticketTitle, improvements (array), acceptanceCriteria (array of numbered strings), testPlan (array of {scenario, setup, expectedOutcome, verificationMethod}), openDecisions (array) }.`, { agentType: "Evaluate" })
+Return: { ticketTitle, improvements (array), acceptanceCriteria (array of numbered strings), testPlan (array of TP-line strings, TP-1 first), testScenarios (array of {tp, setup, outcome}), openDecisions (array) }.`, { agentType: "Evaluate" })
   ))
 );
 
@@ -190,7 +211,8 @@ For each ticket, write ${OUTDIR}/{ticket-slug}-plan.md containing:
 - ## Implementation Plan
 - The plan body (incorporate cross-plan amendments)
 - ## Acceptance Criteria (numbered, positive + negative)
-- ## Test Plan (per-criterion scenarios)
+- ## Test Plan — the challenger's testPlan lines, verbatim, one per line, and nothing else: no prose, no blank line between them, no setup or outcome
+- ## Test Scenarios — one line per TP, in TP order: TP-n: its setup, then its expected outcome, from testScenarios
 - ## Auto-Resolved Decisions (if any — list each as: decision → resolution → source)
 
 Then write ${OUTDIR}/DECISIONS-NEEDED.md:
@@ -228,14 +250,14 @@ The workflow returns:
 
 ```json
 {
-  "planPaths": ["string — path to each per-ticket plan file"],
+  "planPaths": ["string — path to each per-ticket plan file; its ## Test Plan holds TP lines only, its ## Test Scenarios their setup and outcome"],
   "decisionsNeededPath": "string — path to DECISIONS-NEEDED.md",
   "decisionsNeededCount": "number — how many decisions need user input",
   "autoResolvedCount": "number — decisions auto-resolved by preference profile"
 }
 ```
 
-After the workflow returns: read `DECISIONS-NEEDED.md`. First briefly surface the **Auto-Resolved Decisions** section (decision → resolution → source) so silently-settled calls are visible and reversible, then surface ALL open **Decisions Needed** in ONE batched `AskUserQuestion` (never one-at-a-time). Do not ask questions mid-workflow — this is F4. If no preference profile was found, note in your summary: "no preference profile found — N decisions were surfaced that a profile might have auto-resolved; consider `/devflow:dynamic-profile`."
+After the workflow returns: check each plan's test plan (step 1 of the F4 list above), then read `DECISIONS-NEEDED.md`. First briefly surface the **Auto-Resolved Decisions** section (decision → resolution → source) so silently-settled calls are visible and reversible, then surface ALL open **Decisions Needed** in ONE batched `AskUserQuestion` (never one-at-a-time). Do not ask questions mid-workflow — this is F4. If no preference profile was found, note in your summary: "no preference profile found — N decisions were surfaced that a profile might have auto-resolved; consider `/devflow:dynamic-profile`."
 
 ---