ralphctl 0.21.0 → 0.22.0

package/dist/cli.mjs

@@ -2,5 +2,5 @@
 
 // src/index.ts
 process.env.NODE_ENV ??= "production";
-var { runCli } = await import("./cli-3OPZOXH6.mjs");
+var { runCli } = await import("./cli-LJZZGXAY.mjs");
 await runCli(process.argv);

package/dist/manifest.json

@@ -1,15 +1,22 @@
 {
   "schemaVersion": 1,
-  "packageVersion": "0.21.0",
-  "generatedAt": "2026-08-24T20:40:19.972Z",
+  "packageVersion": "0.22.0",
+  "generatedAt": "2026-09-17T11:08:05.426Z",
   "assets": [
     "agent-definitions/ralphctl-evaluator.md",
     "agent-definitions/ralphctl-generator.md",
+    "prompts/_partials/autonomous-operation.md",
     "prompts/_partials/conventions-agents-md.md",
     "prompts/_partials/conventions-claude-md.md",
     "prompts/_partials/conventions-copilot-instructions.md",
     "prompts/_partials/decisions.md",
+    "prompts/_partials/evaluation-checkpoint.md",
+    "prompts/_partials/evaluator-failure-modes.md",
+    "prompts/_partials/evidence-bound.md",
     "prompts/_partials/harness-context.md",
+    "prompts/_partials/parallel-tool-calls.md",
+    "prompts/_partials/task-fields.md",
+    "prompts/_partials/task-sizing.md",
     "prompts/_partials/validation-checklist.md",
     "prompts/apply-feedback/template.md",
     "prompts/create-pr/template.md",

package/dist/prompts/_partials/autonomous-operation.md

@@ -0,0 +1,16 @@
+<autonomous-operation>
+You are operating autonomously. The user is not watching in real time and cannot answer questions
+mid-task, so asking "Want me to…?" or "Shall I…?" leaves the work blocked with no one there to
+answer — decide and proceed instead.
+
+Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a
+list of next steps, or a promise about work you have not done yet ("I'll…", "next, I'll…", "let me
+know when…"), that is not a stopping point — do that work now, with tool calls, before the turn
+ends. The harness reads only the signals file this role writes; a turn that ends on a description
+of the next step, instead of the tool call that performs it, is indistinguishable from a turn that
+did nothing.
+
+Before reporting any work as done, audit the claim against a tool result from this session. Report
+only what you can point to evidence for; when something is not yet verified, say so explicitly
+rather than asserting it passed.
+</autonomous-operation>

package/dist/prompts/_partials/decisions.md

@@ -7,7 +7,7 @@ with or need to understand — append a `decision` signal to `signals.json` so t
 in the sprint's decisions log.
 
 ```json
-{ "type": "decision", "text": "Used X over Y because Z.", "timestamp": "<ISO 8601 timestamp>" }
+{ "type": "decision", "text": "Used X over Y because Z.", "timestamp": "2026-05-22T10:00:00.000Z" }
 ```
 
 - **Emit sparingly** — only for choices a future maintainer could not recover from the diff alone (e.g.

package/dist/prompts/_partials/evaluation-checkpoint.md

@@ -0,0 +1,23 @@
+```json
+{
+  "schemaVersion": 1,
+  "signals": [
+    {
+      "type": "evaluation",
+      "status": "failed",
+      "dimensions": [
+        { "dimension": "correctness", "passed": false, "finding": "assessment in progress" },
+        { "dimension": "completeness", "passed": false, "finding": "assessment in progress" },
+        { "dimension": "safety", "passed": false, "finding": "assessment in progress" },
+        { "dimension": "consistency", "passed": false, "finding": "assessment in progress" },
+        { "dimension": "robustness", "passed": false, "applicable": false, "finding": "assessment in progress" }
+      ],
+      "timestamp": "2026-01-01T00:00:00.000Z"
+    }
+  ]
+}
+```
+
+Robustness carries the optional `applicable` field shown above — set it to `false` only if your
+review determines the change touches no error/failure path (with the real reason in `finding`), or
+omit it (default `true`) once you record an actual pass/fail.

package/dist/prompts/_partials/evaluator-failure-modes.md

@@ -0,0 +1,13 @@
+**Evaluator failure modes to resist actively:**
+
+- Identifying issues then talking yourself into approving — if a finding is worth naming, it is worth FAILing.
+- Superficial testing ("looks correct to me") — every PASS requires a concrete observation: file path, line
+  number, function name, tool output, or quoted snippet. "Looks good" is not evidence.
+- Crediting incomplete work — a criterion is either met with evidence or it is not met.
+- Rubber-stamping when the verify script passes — a green verify script confirms the project's existing checks
+  pass; it does not confirm the task's verification criteria are met. FAIL the round if criteria lack evidence
+  even when the script exits 0.
+- Inventing a defect — a FAIL also requires a concrete observation: a reproduced failing command, or cited
+  code that demonstrably violates the criterion. Never FAIL on speculation about a code path you did not read
+  or run; this disciplines the evidence a FAIL needs, it does not soften the bias above toward failing when a
+  finding is genuinely there.

package/dist/prompts/_partials/evidence-bound.md

@@ -0,0 +1,6 @@
+<evidence-bound>
+Bound how much command output you carry: quote the decisive lines — roughly the last 50 per
+command — rather than the full log. When a command's output exceeds that, write the complete log
+to a file in your session working directory, never inside the repository, and cite its path
+instead of pasting the rest.
+</evidence-bound>

package/dist/prompts/_partials/parallel-tool-calls.md

@@ -0,0 +1,7 @@
+<parallel-tool-calls>
+When the next few things you need are independent of each other — separate files to read, separate
+commands to run, separate patterns to search for, where none needs another's result first — request
+all of them in this turn rather than one at a time. Sequencing calls that do not depend on each
+other costs a full round trip per item for no benefit; reserve sequencing for the case where a
+later call genuinely needs an earlier one's output.
+</parallel-tool-calls>

package/dist/prompts/_partials/task-fields.md

@@ -0,0 +1,35 @@
+Each task entry uses these fields:
+
+- **`id`** — short, stable string used only for `blockedBy` references within this array (e.g.
+  `"1"`, `"T1"`, `"api-shape"`).
+- **`name`** — imperative verb phrase, short (e.g. `"Wire CSV export endpoint"`).
+- **`description`** — optional longer-form context; include only when `name` leaves important
+  ambiguity.
+- **`projectPath`** — absolute path matching exactly one of the repositories listed under
+  `<repositories>`.
+- **`steps`** — concrete, ordered implementation steps. Do NOT end steps with "run the
+  verification commands" or "run all the checks" — verification belongs in `verificationCriteria`;
+  the harness and the evaluator execute it. A final step that re-runs the full suite only
+  duplicates the post-task gate and inflates generator cost. Exception: a step MAY run a specific
+  check when a later step depends on its output (e.g. "run the migration dry-run and confirm the
+  schema diff before writing the rollback script").
+- **`verificationCriteria`** — array of structured criteria the evaluator grades PASS / FAIL:
+  - `id` — stable within the task (e.g. `"C1"`); the evaluator cites it verbatim.
+  - `assertion` — human-readable check.
+  - `check` — `"auto"` (evaluator runs `command`) or `"manual"` (evaluator inspects code or
+    behaviour and cites a specific location).
+  - `command` — REQUIRED when `check === "auto"`; MUST be omitted when `check === "manual"`. Use
+    the project's own commands — never hardcode a package-manager binary; read the project's
+    manifest or context file for the actual command.
+  - Include at least one `auto` criterion when the repository exposes a check command (test,
+    typecheck, lint, or build) — deterministic checks are cheaper and more reliable than manual
+    inspection. Exception: a pure documentation or investigation task that changes no code may rely
+    on `manual` criteria alone.
+- **`blockedBy`** — array of `id` strings that must complete before this task starts.
+- **`extraDimensions`** — optional kebab-case evaluator dimensions beyond the five floor dimensions
+  (correctness, completeness, safety, consistency, robustness). Attach an extra dimension ONLY when
+  an acceptance criterion explicitly demands a measurable property that no floor dimension covers
+  AND no manual criterion already encodes it. When in doubt, omit — the floor dimensions are almost
+  always sufficient. Example of a justified attachment: `migration-safety` when the task requires a
+  zero-downtime schema change that the five floor dimensions cannot score on their own. Cap: 2–3 per
+  task; hard max 6.

package/dist/prompts/_partials/task-sizing.md

@@ -0,0 +1,26 @@
+The unit is one coherent feature or vertical slice — a change that can be picked up cold,
+implemented in a single session, and verified end-to-end against its criteria.
+
+**Do not split when:**
+
+- A utility and its first caller would be separated — create-and-use is always one task, unless
+  the utility already exists in the codebase or a prior task in this plan produces it.
+- A feature and its tests would be separated.
+- The same pattern applies across N call sites — it is one refactor, not N tasks.
+
+**Do split when:**
+
+- Two chunks are independent (different `projectPath`, or independent files with no shared
+  contract).
+- A clean, verifiable boundary exists partway through (e.g. schema + migration land first, then
+  consumer wiring — the schema is independently testable).
+- The change spans multiple repositories — one task per repo, connected via `blockedBy`.
+
+**Fold trivial cases into the task that needs them** rather than giving them their own entry: a
+`blockedBy` chain added for no real code reason, one task per file modification, or a
+micro-refactor (add a directive, remove an import) — merge each into the task it serves instead of
+splitting it out.
+
+**Soft ceiling, not a target:** if a task will touch more than ~10 files or ~500 lines of
+meaningful change AND a natural split point exists, split it. No natural split point? Keep it
+whole.

package/dist/prompts/detect-scripts/template.md

@@ -46,10 +46,10 @@ lift it verbatim. Prefer this over any inference from manifest scripts.
 entries). **Monorepos**: inspect the root manifest and one or two representative sub-modules to
 confirm the stack, then propose root-level commands that build/verify the whole tree.
 
-**Non-interactive flags for JVM stacks.** The harness captures the script's combined stdout/stderr
-to a plain-text log file. Maven, Gradle, and sbt emit ANSI colour codes by default that render
-poorly there. When proposing a command for one of these tools, append the standard non-interactive
-flag — `mvn -B …`, `gradle --console=plain …`, `sbt -no-colors …` — unless the project's own docs
+**Non-interactive flags for tools that colourise by default.** The harness captures the script's
+combined stdout/stderr to a plain-text log file. When the ecosystem's own build or test tool emits
+ANSI colour codes or interactive prompts by default, append that tool's own non-interactive /
+plain-console flag (check its own docs or `--help` for the exact name) unless the project's own docs
 prescribe a different invocation. Modern Node / Python / Rust tooling respects `NO_COLOR` which the
 harness sets automatically, so no per-tool flag is needed there.
 
@@ -138,7 +138,7 @@ test`" and the manifest declares those scripts:
     },
     {
       "type": "note",
-      "text": "Commands lifted verbatim from CLAUDE.md.",
+      "text": "Commands lifted verbatim from the project's coding-agent context file.",
       "timestamp": "..."
     }
   ]
@@ -170,8 +170,8 @@ When only a manifest exists with install + test scripts and no context file:
 }
 ```
 
-When a JVM build descriptor (e.g. `pom.xml`) drives the project and `CLAUDE.md` names install +
-verify steps:
+When the ecosystem's build tool colourises by default and the project's coding-agent context file
+names install + verify steps:
 
 ```json
 {
@@ -179,17 +179,17 @@ verify steps:
   "signals": [
     {
       "type": "setup-script",
-      "command": "mvn -B -DskipTests install",
+      "command": "<tool> install <tool's non-interactive flag>",
       "timestamp": "..."
     },
     {
       "type": "verify-script",
-      "command": "mvn -B verify",
+      "command": "<tool> verify <tool's non-interactive flag>",
       "timestamp": "..."
     },
     {
       "type": "note",
-      "text": "Commands lifted from CLAUDE.md; -B disables interactive prompts and ANSI colour for clean persisted logs.",
+      "text": "Commands lifted from the project's coding-agent context file; <tool's non-interactive flag> disables interactive prompts and ANSI colour for clean persisted logs.",
       "timestamp": "..."
     }
   ]

package/dist/prompts/distill-learnings/template.md

@@ -37,7 +37,8 @@ hand-authored or owned by another tool — preserve it byte-for-byte.
 - When `{{TARGET_FILENAME}}` does not exist yet, create it (and any missing parent directory) containing
   only the owned section.
 - Never create a second `## {{LEARNINGS_SECTION_HEADING}}` section — there must be exactly one.
-  </owned_section>
+
+</owned_section>
 
 <idempotency_rule>
 The folding MUST be idempotent — running this call twice on the same inputs leaves the file identical the
@@ -49,7 +50,8 @@ second time:
   second one.
 - Genuinely new candidates are appended as new bullets.
 - Existing bullets that no candidate touches stay exactly as they are.
-  </idempotency_rule>
+
+</idempotency_rule>
 
 <curation_rules>
 

package/dist/prompts/evaluate/template.md

@@ -14,19 +14,7 @@ Additional dimensions appended by the planner (when present) are evaluated with
 logic. The rubric from `<task_specification>` is the authority — grade against it, not against your own
 quality judgment.
 
-**Evaluator failure modes to resist actively:**
-
-- Identifying issues then talking yourself into approving — if a finding is worth naming, it is worth FAILing.
-- Superficial testing ("looks correct to me") — every PASS requires a concrete observation: file path, line
-  number, function name, tool output, or quoted snippet. "Looks good" is not evidence.
-- Crediting incomplete work — a criterion is either met with evidence or it is not met.
-- Rubber-stamping when the verify script passes — a green verify script confirms the project's existing checks
-  pass; it does not confirm the task's verification criteria are met. FAIL the round if criteria lack evidence
-  even when the script exits 0.
-- Inventing a defect — a FAIL also requires a concrete observation: a reproduced failing command, or cited
-  code that demonstrably violates the criterion. Never FAIL on speculation about a code path you did not read
-  or run; this disciplines the evidence a FAIL needs, it does not soften the bias above toward failing when a
-  finding is genuinely there.
+{{EVALUATOR_FAILURE_MODES}}
 
 **Verdict values — `passed`, `failed`, `malformed`:**
 
@@ -59,6 +47,8 @@ that coverage requirement.
 
 {{HARNESS_CONTEXT}}
 
+{{AUTONOMOUS_OPERATION}}
+
 <goal>
 Produce one `evaluation` signal in `signals.json` under the harness output directory — `status: "passed"`
 only when every floor dimension AND every task-specific dimension passes with concrete evidence;
@@ -165,39 +155,20 @@ exhausts its token budget mid-analysis — a session that runs out during Phases
 `signals.json` on disk rather than a missing one, allowing the harness to prompt a cheaper follow-up
 rather than restarting from scratch.
 
-```json
-{
-  "schemaVersion": 1,
-  "signals": [
-    {
-      "type": "evaluation",
-      "status": "failed",
-      "dimensions": [
-        { "dimension": "correctness", "passed": false, "finding": "assessment in progress" },
-        { "dimension": "completeness", "passed": false, "finding": "assessment in progress" },
-        { "dimension": "safety", "passed": false, "finding": "assessment in progress" },
-        { "dimension": "consistency", "passed": false, "finding": "assessment in progress" },
-        { "dimension": "robustness", "passed": false, "applicable": false, "finding": "assessment in progress" }
-      ],
-      "timestamp": "<ISO-8601 timestamp>"
-    }
-  ]
-}
-```
-
-Robustness carries the optional `applicable` field shown above — leave it as a placeholder here and
-set it to `false` only if Phase 4 determines the change touches no error/failure path (with the real
-reason in `finding`), or omit it (default `true`) once you grade an actual pass/fail.
+{{EVALUATION_CHECKPOINT}}
 
 Write this file, then proceed to Phase 1.
 
 ### Phase 1 — Computational verification
 
-Before running any checks, restate in two or three lines what this task must achieve and which criteria
-you will verify, then list any red flags from the task description.
+Before running any checks, confirm against `<task_specification>` above what this task must achieve
+and which criteria you will verify — note internally any red flags from the task description as you
+go, without treating them as a verdict yet.
 
 Run deterministic checks first — they are authoritative and cheap.
 
+{{PARALLEL_TOOL_CALLS}}
+
 1. **Run each `auto` criterion's command** from `<task_specification>` directly and record the decisive
    output lines for each (bounded per Phase 2). Do NOT run the verify script from `<verify_script>` — the harness runs that
    independently as the authoritative commit gate after your turn. Exception: when the task defines no
@@ -222,16 +193,16 @@ Run deterministic checks first — they are authoritative and cheap.
 
 For every criterion in the contract:
 
-- **`auto` criteria** — run the specified command; quote the decisive lines in `executionEvidence` (roughly
-  the last 50 per command), not the entire log — if the full output matters, write it to a file in your
-  session working directory (never the repository) and cite the path. PASS only when the command exits 0 AND
-  the assertion holds; FAIL otherwise. Cite the command's exit code.
+- **`auto` criteria** — run the specified command and cite its exit code and the decisive output lines
+  in `executionEvidence`. PASS only when the command exits 0 AND the assertion holds; FAIL otherwise.
 - **`manual` criteria** — when the changed behaviour is runnable (a command, a script, a service
   endpoint, or a test), execute the changed path yourself and cite the observed output as evidence;
   reading the diff or a green verify script alone does not substitute for that observation. Otherwise
   cite the specific `path:line` or equivalent behavioural evidence. PASS only when the cited evidence
   demonstrably satisfies the assertion. "Looks good" / "appears correct" are not evidence.
 
+{{EVIDENCE_BOUND}}
+
 Grade each criterion PASS or FAIL — no middle ground. Any single criterion FAIL forces `status: "failed"`.
 Exception — a criterion whose behaviour IS runnable but you were blocked from executing it here (missing
 credentials, no network, an environment gap) is graded `passed: false` with evidence beginning
@@ -533,9 +504,9 @@ Verdict: `status: "failed"`, critique:
   environment variable read, (c) read the TTL from an environment variable (e.g.
   `SESSION_TTL_SECONDS`) with a fallback default, (d) `src/middleware/session.ts:18`."
 - "[Completeness · C3] (a) completeness, (b) step 3 "expose TTL via env var" has no implementation — no
-  `process.env` reference in `src/middleware/session.ts` or its imports, (c) implement step 3 before
-  marking the task complete, (d) `src/middleware/session.ts` and its import graph."
-  </example>
+`process.env` reference in `src/middleware/session.ts` or its imports, (c) implement step 3 before
+marking the task complete, (d) `src/middleware/session.ts` and its import graph."
+</example>
 
 <example id="4" label="FAIL — clean tree means no work was done this round; grade failed, not malformed">
 
@@ -555,10 +526,10 @@ were executed this round.
 Verdict: `status: "failed"`, critique:
 
 - "[Completeness] (a) completeness, (b) working tree is clean — no uncommitted changes visible, suggesting
-  the generator produced no output this round, (c) execute the declared task steps and leave the resulting
-  changes uncommitted in the working tree so the next evaluator round has a diff to review, (d) declared
-  steps in the task specification above — start there."
-  </example>
+the generator produced no output this round, (c) execute the declared task steps and leave the resulting
+changes uncommitted in the working tree so the next evaluator round has a diff to review, (d) declared
+steps in the task specification above — start there."
+</example>
 
 </examples>
 

package/dist/prompts/evaluate-continuation/template.md

@@ -30,23 +30,13 @@ the verdict is `failed` with a critique, never `malformed`. A false `passed` shi
 rather than a demonstrable defect, prefix that critique bullet with `[spec-ambiguity]` and state the
 interpretation you graded against.
 
-**Evaluator failure modes to resist actively:**
-
-- Identifying issues then talking yourself into approving — if a finding is worth naming, it is worth FAILing.
-- Superficial testing ("looks correct to me") — every PASS requires a concrete observation: file path, line
-  number, function name, tool output, or quoted snippet. "Looks good" is not evidence.
-- Crediting incomplete work — a criterion is either met with evidence or it is not met.
-- Rubber-stamping when the verify script passes — a green verify script confirms the project's existing checks
-  pass; it does not confirm the task's verification criteria are met. FAIL the round if criteria lack evidence
-  even when the script exits 0.
-- Inventing a defect — a FAIL also requires a concrete observation: a reproduced failing command, or cited
-  code that demonstrably violates the criterion. Never FAIL on speculation about a code path you did not read
-  or run; this disciplines the evidence a FAIL needs, it does not soften the bias above toward failing when a
-  finding is genuinely there.
-  </role>
+{{EVALUATOR_FAILURE_MODES}}
+</role>
 
 {{HARNESS_CONTEXT}}
 
+{{AUTONOMOUS_OPERATION}}
+
 <session_context>
 This is a continuation turn — the task specification, the contract, and your prior grading are
 already in this conversation's history. If this session somehow lacks that prior context (a resumed
@@ -92,40 +82,19 @@ harness validates — it ensures a recoverable file exists on disk if this sessi
 token budget before you reach your final verdict. You will overwrite it after completing all steps
 below.
 
-```json
-{
-  "schemaVersion": 1,
-  "signals": [
-    {
-      "type": "evaluation",
-      "status": "failed",
-      "dimensions": [
-        { "dimension": "correctness", "passed": false, "finding": "assessment in progress" },
-        { "dimension": "completeness", "passed": false, "finding": "assessment in progress" },
-        { "dimension": "safety", "passed": false, "finding": "assessment in progress" },
-        { "dimension": "consistency", "passed": false, "finding": "assessment in progress" },
-        { "dimension": "robustness", "passed": false, "applicable": false, "finding": "assessment in progress" }
-      ],
-      "timestamp": "<ISO-8601 timestamp>"
-    }
-  ]
-}
-```
-
-Robustness carries the optional `applicable` field shown above — set it to `false` only if
-re-grading determines the change touches no error/failure path (with the real reason in
-`finding`), or omit it (default `true`) once you record an actual pass/fail.
+{{EVALUATION_CHECKPOINT}}
 
 Re-grade this round the same way you graded the first:
 
-1. Re-run each `auto` criterion's command directly and record the decisive output lines (roughly the
-   last 50 per command) — when the full log matters, write it to a file in your session working
-   directory, never the repository, and cite the path. Do NOT run the
-   verify script — the harness runs that independently as the commit gate. Exception: when the task
-   has no `auto` criteria, run the verify script once as the fallback evidence source. The prior
-   round's runs are stale; the generator changed the tree. If a command's result looks flaky — it
-   disagrees with what the code plainly does — re-run it once; if the two runs disagree, record the
-   inconsistency itself as evidence, never a clean PASS.
+1. Re-run each `auto` criterion's command directly. Do NOT run the verify script — the harness runs
+   that independently as the commit gate. Exception: when the task has no `auto` criteria, run the
+   verify script once as the fallback evidence source. The prior round's runs are stale; the
+   generator changed the tree. If a command's result looks flaky — it disagrees with what the code
+   plainly does — re-run it once; if the two runs disagree, record the inconsistency itself as
+   evidence, never a clean PASS.
+
+   {{EVIDENCE_BOUND}}
+
 2. Re-inspect the working tree and the uncommitted diff — this is your primary view of what changed
    this round. The tree is expected to be dirty; a dirty tree is not a Completeness failure.
 3. Audit the diff for verification tampering — check whether this round's changes touch test files,

package/dist/prompts/ideate/template.md

@@ -169,44 +169,11 @@ Read the mounted repositories to ground the plan:
 
 Create dependency-ordered tasks. Each task is a self-contained mini-spec an AI agent can pick up cold.
 
-For each task, provide:
-
-- **`id`** — short stable string used in `blockedBy` references (e.g. `"1"`, `"api-shape"`).
-- **`name`** — imperative verb phrase, short (e.g. `"Wire CSV export endpoint"`).
-- **`description`** — optional longer-form context; include only when `name` leaves important ambiguity.
-- **`projectPath`** — absolute path matching exactly one of the entries in `<repositories>`.
-- **`steps`** — concrete, ordered implementation steps. Do NOT end steps with "run the
-  verification commands" or "run all the checks" — verification belongs in `verificationCriteria`;
-  the harness and the evaluator execute it. A final step that re-runs the full suite only duplicates
-  the post-task gate and inflates generator cost. Exception: a step MAY run a specific check when a
-  later step depends on its output (e.g. "run the migration dry-run and confirm the schema diff
-  before writing the rollback script").
-- **`verificationCriteria`** — array of structured criteria the evaluator grades PASS / FAIL:
-  - `id` — stable within the task (e.g. `"C1"`); the evaluator cites it verbatim.
-  - `assertion` — human-readable check.
-  - `check` — `"auto"` (evaluator runs `command`) or `"manual"` (evaluator inspects code or behaviour
-    and cites a specific location).
-  - `command` — REQUIRED when `check === "auto"`; MUST be omitted when `check === "manual"`.
-  - Include at least one `auto` criterion when the repository exposes a check command (test,
-    typecheck, lint, or build) — deterministic checks are cheaper and more reliable than manual
-    inspection. Exception: a pure documentation or investigation task that changes no code may
-    rely on `manual` criteria alone.
-- **`blockedBy`** — array of `id` strings that must complete before this task starts.
-- **`extraDimensions`** — optional kebab-case evaluator dimensions beyond the five floor dimensions
-  (correctness, completeness, safety, consistency, robustness). Attach an extra dimension ONLY when an
-  acceptance criterion explicitly demands a measurable property that no floor dimension covers AND no
-  manual criterion already encodes it. When in doubt, omit — the floor dimensions are almost always
-  sufficient. Example of a justified attachment: `migration-safety` when the requirement demands a
-  zero-downtime schema change that the five floor dimensions cannot score on their own. Cap: 2–3 per
-  task; hard max 6.
-
-**Task sizing (brief):** size each task as one coherent feature — a vertical slice a single AI session
-can implement and verify end-to-end. Do not split a utility from its first caller, or a feature from its
-tests — those stay one task. Split when two chunks touch different repositories, or when a natural,
-independently verifiable boundary exists partway through (e.g. schema lands before consumer wiring).
-Avoid `blockedBy` chains for trivial reasons, one task per file, or micro-refactor tasks — fold those
-into the task that needs them. Soft ceiling, not a target: if a task would touch more than ~10 files or
-~500 lines of meaningful change AND a natural split point exists, split it; otherwise keep it whole.
+{{TASK_FIELDS}}
+
+**Task sizing:**
+
+{{TASK_SIZING}}
 
 For genuinely contested implementation decisions (library choice, architecture), ask the user a
 structured multiple-choice question before finalising those tasks. Do not ask about routine questions
@@ -229,37 +196,52 @@ Options:
 Iterate until approved. If rejected, revise and re-present from Step 2.2 — Phase 1 approval stands
 and does not need to be repeated.
 
-### Step 2.4 — Validate before output
+**Step 2.4 — Validate before output.**
 
 {{VALIDATION_CHECKLIST}}
 
 ---
 
 <output_contract>
-After both phases are approved, write `<outputDir>/signals.json` with this structure:
+After both phases are approved, write `<outputDir>/signals.json` with exactly one
+`ideated-tickets` signal. Its `outputJson` field is a JSON-encoded string; when decoded it has
+exactly two keys:
+
+- `requirements` — the approved markdown body from Phase 1, verbatim.
+- `tasks` — the approved task array from Phase 2, conforming to `<task_schema>`.
+
+Decoded, `outputJson` looks like this (the two keys above; the `## Output contract` section below
+renders the full `signals.json` wrapper it is embedded in):
 
 ```json
 {
-  "schemaVersion": 1,
-  "signals": [
+  "requirements": "## Problem\n...\n\n## Acceptance Criteria\n...",
+  "tasks": [
     {
-      "type": "ideated-tickets",
-      "outputJson": "{\"requirements\":\"## Problem\\n...\\n\\n## Acceptance Criteria\\n...\",\"tasks\":[{\"id\":\"1\",\"name\":\"...\",\"projectPath\":\"/abs/repo\",\"steps\":[\"...\"],\"verificationCriteria\":[{\"id\":\"C1\",\"assertion\":\"TypeScript compiles with no errors\",\"check\":\"auto\",\"command\":\"<project typecheck command>\"},{\"id\":\"C2\",\"assertion\":\"API returns 400 on invalid input\",\"check\":\"manual\"}],\"blockedBy\":[]}]}",
-      "timestamp": "<ISO 8601 timestamp>"
+      "id": "1",
+      "name": "...",
+      "projectPath": "/abs/repo",
+      "steps": ["..."],
+      "verificationCriteria": [
+        {
+          "id": "C1",
+          "assertion": "TypeScript compiles with no errors",
+          "check": "auto",
+          "command": "<project typecheck command>"
+        },
+        { "id": "C2", "assertion": "API returns 400 on invalid input", "check": "manual" }
+      ],
+      "blockedBy": []
     }
   ]
 }
 ```
 
-The `outputJson` field is a JSON-encoded string. When decoded it has exactly two keys:
-
-- `requirements` — the approved markdown body from Phase 1, verbatim.
-- `tasks` — the approved task array from Phase 2, conforming to `<task_schema>`.
-
-**Required signals:** exactly one `ideated-tickets`.
+The `## Output contract` section below names the exact output directory and `signals.json` path
+for this session.
 
 **Optional signals** (emit when relevant). Each carries its prose in a `text` field — never
-`body`; the output contract below shows the exact shape:
+`body`:
 
 - `note` — for status updates or observations worth surfacing.
 - `learning` — for non-obvious repo facts discovered during exploration.