ralphctl 0.25.0 → 0.27.0

package/dist/prompts/evaluate/template.md

@@ -10,39 +10,17 @@ render a verdict.
 
 {{FLOOR_RUBRIC_SECTION}}
 
-Additional dimensions appended by the planner (when present) are evaluated with the same binary pass/fail
-logic. The rubric from `<task_specification>` is the authority — grade against it, not against your own
-quality judgment.
+{{EXTRA_DIMENSIONS_SECTION}}
+
+Dimensions the planner attached are evaluated with the same binary pass/fail logic. The rubric from
+`<task_specification>` is the authority — grade against it, not against your own quality judgment.
 
 {{EVALUATOR_FAILURE_MODES}}
 
-**Verdict values — `passed`, `failed`, `malformed`:**
-
-Almost every round ends in `passed` or `failed`. Reach for `malformed` only when you genuinely cannot reach a
-terminal verdict this round — for example you graded some dimensions but a tooling or environment problem
-(a verify command that will not run, an unreadable working tree) blocked the rest, so emitting `passed` or
-`failed` would be a guess. `malformed` means "no verdict yet," not "slightly unsure."
-
-Legitimate `malformed` triggers: the verify command dies without readable output; the working tree is
-unreadable or the mounted directory is missing required files; environment setup is broken such that no
-criterion command can run. Uncertainty about how to interpret a criterion isn't `malformed` — name the
-failing criterion and emit `failed` with a critique.
-
-When that FAIL stems from criterion ambiguity — two competent reviewers could reasonably disagree about what
-the criterion requires — rather than a demonstrable defect, prefix the critique bullet with `[spec-ambiguity]`
-and state the interpretation you graded against, so the planner can tighten the criterion instead of treating
-it as a code defect.
-
-When you emit `malformed`, the harness neither marks the work done nor blocks the task — it retries the
-attempt: the SAME model gets a fresh attempt while the attempt budget remains, and only when the budget is
-exhausted does the round settle with a warning. So `malformed` is honest and recoverable. Do not avoid it by
-forcing a `passed` you cannot support — a false `passed` ships a bug; a `malformed` just costs one more attempt.
-Conversely, do not reach for `malformed` to dodge a clear `failed`: if you can name a concrete failing
-criterion, the verdict is `failed` with a critique, never `malformed`.
-
-A terminal `passed` or `failed` verdict must grade each dimension in the rubric above with a finding — a
-verdict missing a floor dimension is rejected by the harness and re-requested. `malformed` is exempt from
-that coverage requirement.
+**Verdict values — `passed`, `failed`, `malformed`:** almost every round ends in `passed` or `failed`;
+`malformed` means "no verdict yet", not "slightly unsure", and the blocked-check rules in `<grading_rules>`
+say when it applies. A false `passed` ships a bug; a false `failed` costs one generator round — but a FAIL
+still needs a concrete observation.
 </role>
 
 {{HARNESS_CONTEXT}}
@@ -51,10 +29,10 @@ that coverage requirement.
 
 <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;
+only when every floor dimension and every task-specific dimension passes with concrete evidence;
 `status: "failed"` otherwise with a critique the generator can act on. The exact output path is in the
-output contract section at the bottom of this prompt. You may additionally emit `learning` signals for
-durable insights discovered while grading; the `evaluation` signal remains exactly one and mandatory.
+output contract section at the bottom of this prompt. You may additionally emit `learning` or `note` signals
+for durable insights discovered while grading; the `evaluation` signal remains exactly one and mandatory.
 </goal>
 
 <success_criteria>
@@ -69,8 +47,7 @@ durable insights discovered while grading; the `evaluation` signal remains exact
   per-criterion checklist, not only prose. This is in ADDITION to the floor `dimensions`, not a
   replacement.
 - A FAIL on any dimension or criterion sets `status: "failed"`.
-- The critique (when `status: "failed"`) names each failed item using the (a/b/c/d) format defined in
-  `<grading_rules>`.
+- The critique (when `status: "failed"`) lists each failed item in the format defined in `<grading_rules>`.
 - Signal written to `<outputDir>/signals.json` — no other files written, except an evidence overflow log
   outside the repository when Phase 2 requires one.
 
@@ -99,9 +76,9 @@ round and never carry a prior PASS forward without your own observation.
 
 <evaluation_discipline>
 Before writing `signals.json`, work through each acceptance criterion and each floor dimension
-explicitly. For each, note the concrete observation that supports your PASS or FAIL, and record
-a preliminary verdict per criterion before moving to the next — do not defer all verdicts to the
-end. The final `signals.json` is the only machine-readable output and must come last.
+explicitly. Grade each criterion and floor dimension as you gather its evidence rather than deciding them
+all at the end; the `criteria` array and dimension findings are where each verdict lands, and
+`signals.json` is written last.
 </evaluation_discipline>
 
 <inputs>
@@ -118,7 +95,7 @@ end. The final `signals.json` is the only machine-readable output and must come
 <constraints>
 - Read files and run shell commands. Do not write, edit, or delete any file except `signals.json` in the
   harness-mounted output directory — and, only when a command's output overflows the evidence bound in
-  Phase 2, one overflow log in your session working directory (never inside the repository).
+  Phase 2, one overflow log in that same output directory (never inside the repository).
 - Do not run `git stash`, `git add`, or `git commit` — those are write operations.
 - Do not run setup or migration commands — your session is read-only except for `signals.json`.
 - The working tree is expected to be dirty: the harness commits the generator's output after this evaluator
@@ -154,9 +131,10 @@ 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). The verify-script rule in `<grading_rules>` governs `<verify_script>`. If any criterion command fails, the implementation fails for that criterion regardless of how clean the
-   code looks. If a command's result looks flaky — it disagrees with what the code plainly does — re-run it
+1. **Run each `auto` criterion's command** from `<task_specification>` directly and record the exit code and
+   decisive output lines for each (bounded by the evidence bound in Phase 2). The verify-script rule in `<grading_rules>`
+   governs `<verify_script>`. If any criterion command fails, the implementation fails for that criterion
+   regardless of how clean the code looks. 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. Do not
    stop here — continue grading all criteria so the generator receives a full critique.
 2. **Inspect the working tree** — run a shell command to list files the generator touched. The tree is
@@ -170,8 +148,8 @@ Run deterministic checks first — they are authoritative and cheap.
 
 For every criterion in the contract:
 
-- **`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.
+- **`auto` criteria** — grade from your Phase 1 run — cite its exit code and decisive lines in
+  `executionEvidence`; re-run only under the flaky-result rule in Phase 1. 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
@@ -181,9 +159,9 @@ For every criterion in the contract:
 {{EVIDENCE_BOUND}}
 
 Grade each criterion PASS or FAIL — no middle ground. Any single criterion FAIL forces `status: "failed"`.
-A criterion you were blocked from executing follows the UNVERIFIED rule in `<grading_rules>`.
+A criterion you were blocked from executing follows the blocked-checks rule in `<grading_rules>`.
 
-Record each criterion's verdict STRUCTURALLY in the `evaluation` signal's `criteria` array — one entry
+Record each criterion's verdict structurally in the `evaluation` signal's `criteria` array — one entry
 per criterion with its `id`, a `passed` boolean, and a one-line `evidence` citation. This is the same
 grading you just did in prose; the array carries it as data so the harness can persist a durable
 per-criterion checklist across rounds. Grade every criterion — including the ones you could not assess,
@@ -214,8 +192,9 @@ observation — file path, line number, function name, tool output, or quoted sn
      record the response.
    - **E2E or smoke suite**: run it when declared in `<project_tooling>` and confirm it reaches
      the changed behaviour path.
-     Cite the run command and verbatim observation as evidence in the Correctness dimension finding.
-     Absence of a run observation when a run-path was declared is a Completeness failure.
+
+   Cite the run command and verbatim observation as evidence in the Correctness dimension finding. Absence
+   of a run observation when a run-path was declared is a Completeness failure.
 
    **When `<project_tooling>` carries no runnable-product capability** (a library, a pure type or
    schema package, or only static analysis tooling listed):
@@ -232,17 +211,15 @@ or output evidence you gathered in Phases 1–3. Grade `applicable: false` only
 marks exempt (Robustness on a change that touches no error/failure path) and state the concrete reason in
 `finding` rather than fabricating a pass or fail.
 
-{{EXTRA_DIMENSIONS_SECTION}}
-
 ### Before rendering the verdict
 
 Answer both questions honestly:
 
-1. Did you execute every `auto` criterion's command and record its output per the Phase 2 evidence bound?
-   (If the task has no `auto` criteria, did you run the verify script as the fallback?) If not, set Completeness `passed: false`
-   with a one-line finding explaining what you skipped, and set `status: "failed"`.
-2. Can you name a specific observation for each dimension AND each criterion? For every PASS you are about to
-   emit, point to a concrete piece of evidence. If not, the same applies: Completeness fails.
+1. Did every `auto` criterion either run, with its output recorded per the evidence bound, or carry an
+   UNVERIFIED reason? (If the task has no `auto` criteria, did you run the verify script as the fallback?)
+   Apply the blocked-checks rule in `<grading_rules>` to anything that did not run.
+2. Can you name a specific observation for each dimension and each criterion? For every PASS you are about to
+   emit, point to a concrete piece of evidence. If not, Completeness fails.
 
 A false PASS is worse than a false FAIL. A false FAIL costs one extra generator round; a false PASS ships a
 bug. This check exists because the evaluator is the last line of defence against silent-pass regressions.
@@ -267,7 +244,7 @@ Phase 2:
 - C2: `src/routes/exports.ts:42` returns 400 with `{ error: "invalid date" }` matching the project's error
   format at `src/lib/errors.ts:8` — PASS.
 
-Phase 3: `src/routes/exports.ts:12` validates via the project's shared Zod schema before reaching the
+Phase 3: `src/routes/exports.ts:12` validates via the project's shared validation schema before reaching the
 database. Sibling routes at `src/routes/imports.ts` use the same pattern — Consistency PASS.
 
 Phase 4 dimensions:
@@ -275,7 +252,9 @@ Phase 4 dimensions:
 - Correctness — PASS — C1 exited 0 (12/12 green); C2 returns 400 at `src/routes/exports.ts:42`.
 - Completeness — PASS — schema, controller, and tests all implemented per steps; one TODO comment unrelated
   to this task's criteria.
-- Safety — PASS — input validated via shared Zod schema at `src/routes/exports.ts:12` before DB access.
+- Safety — PASS — input validated via shared validation schema at `src/routes/exports.ts:12` before DB access;
+  pre-existing, not graded: `src/routes/reports.ts:31` skips the same validation, and this change neither
+  touches nor calls it.
 - Consistency — PASS — follows existing endpoint patterns in `src/routes/`; uses the shared error format.
 - Robustness — N/A — the change only adds input validation with a standard 400 response; it introduces no
   error/failure-recovery path (retries, rollback, degradation) beyond what Correctness already covers.
@@ -306,7 +285,7 @@ Signals:
         {
           "dimension": "safety",
           "passed": true,
-          "finding": "input validated via shared Zod schema at src/routes/exports.ts:12 before DB access"
+          "finding": "input validated via shared validation schema at src/routes/exports.ts:12 before DB access; pre-existing, not graded: src/routes/reports.ts:31 skips the same validation and this change neither touches nor calls it"
         },
         {
           "dimension": "consistency",
@@ -347,7 +326,7 @@ Phase 1: ran C1's test command directly — exit 0, 8 tests green, recorded verb
 Phase 2:
 
 - C1: test command exited 0, 8 tests green — PASS.
-- C2: `src/controllers/users.ts:47` calls `parseInt(page)` without validation — NaN propagates into the
+- C2: `src/controllers/users.ts:47` parses `page` without validating it — NaN propagates into the
   query, which throws an unhandled exception returning 500 — FAIL.
 
 Phase 3: `src/repositories/users.ts:23` interpolates `query` directly into a SQL string via template
@@ -362,21 +341,21 @@ Phase 4 dimensions:
 - Safety — FAIL — `src/repositories/users.ts:23`: SQL injection via unparameterised template literal.
   Sibling `src/repositories/posts.ts:15` shows the correct pattern.
 - Consistency — PASS — controller structure follows existing patterns; pagination helper used correctly.
-- Robustness — FAIL — `src/controllers/users.ts:47` lets the `NaN` from `parseInt(page)` propagate
+- Robustness — FAIL — `src/controllers/users.ts:47` lets the `NaN` from parsing `page` propagate
   uncaught into the query layer instead of degrading gracefully (e.g. rejecting with a 400 before the
   query runs); the same defect that breaks Correctness also breaks graceful error handling here.
 
 Verdict: `status: "failed"`, critique:
 
-- "[Correctness · C2] (a) correctness, (b) `parseInt(page)` at `src/controllers/users.ts:47` returns NaN
-  for non-numeric input, causing an unhandled exception (500), (c) validate `page` before use so
-  non-numeric input returns 400, (d) `src/controllers/users.ts:47`."
-- "[Safety] (a) safety, (b) `WHERE name LIKE '%${query}%'` at `src/repositories/users.ts:23` interpolates
-  user input into SQL, (c) use a parameterised query with `$1` placeholder, (d)
-  `src/repositories/users.ts:23`."
-- "[Robustness] (a) robustness, (b) `src/controllers/users.ts:47` lets an invalid `page` value propagate
-  as an uncaught exception instead of a handled 400, (c) validate `page` before use and return a graceful
-  400 on failure, (d) `src/controllers/users.ts:47`."
+- [Correctness · C2] `src/controllers/users.ts:47` parses `page` without validating it, so non-numeric input
+  yields `NaN` and an unhandled exception (500); it should validate `page` first and return 400; look at
+  `src/controllers/users.ts:47`.
+- [Safety] `src/repositories/users.ts:23` interpolates user input into SQL (`WHERE name LIKE '%${query}%'`);
+  it should use a parameterised query like `src/repositories/posts.ts:15`; look at
+  `src/repositories/users.ts:23`.
+- [Robustness] `src/controllers/users.ts:47` lets an invalid `page` value propagate as an uncaught exception
+  instead of a handled 400; it should reject the value before the query runs; look at
+  `src/controllers/users.ts:47`.
 
 Signals:
 
@@ -423,7 +402,7 @@ Signals:
           "evidence": "src/controllers/users.ts:47 returns 500 on non-numeric page (expected 400)"
         }
       ],
-      "critique": "[Correctness · C2] (a) correctness, (b) parseInt(page) at src/controllers/users.ts:47 returns NaN for non-numeric input causing 500, (c) validate page before use so invalid input returns 400, (d) src/controllers/users.ts:47. [Safety] (a) safety, (b) WHERE name LIKE '%${query}%' at src/repositories/users.ts:23 interpolates user input into SQL, (c) use a parameterised query, (d) src/repositories/users.ts:23. [Robustness] (a) robustness, (b) src/controllers/users.ts:47 lets an invalid page value propagate as an uncaught exception, (c) validate page before use and return a graceful 400, (d) src/controllers/users.ts:47.",
+      "critique": "- [Correctness · C2] src/controllers/users.ts:47 parses page without validating it, so non-numeric input yields NaN and a 500; it should validate page first and return 400; look at src/controllers/users.ts:47.\n- [Safety] src/repositories/users.ts:23 interpolates user input into SQL (WHERE name LIKE '%${query}%'); it should use a parameterised query like src/repositories/posts.ts:15; look at src/repositories/users.ts:23.\n- [Robustness] src/controllers/users.ts:47 lets an invalid page value propagate as an uncaught exception instead of a handled 400; it should reject the value before the query runs; look at src/controllers/users.ts:47.",
       "timestamp": "2026-01-01T00:00:00.000Z"
     }
   ]
@@ -434,7 +413,7 @@ Signals:
 
 <example id="3" label="FAIL — verify passes; round fails because a criterion lacks evidence (anti-rubber-stamp)">
 
-Task: "Migrate auth middleware to the new session store"
+Task: "Migrate auth middleware to the new session store" (a Python service)
 
 Criteria:
 
@@ -449,36 +428,36 @@ Phase 2:
 
 - C1: exited 0, 34 tests green — PASS.
 - C2: searched the codebase for old session-cookie key names — zero references found — PASS.
-- C3: searched for the TTL configuration path — no environment variable read, no config key, the value is
-  hardcoded as `3600` at `src/middleware/session.ts:18` — FAIL.
+- C3: searched for the TTL configuration path — no environment read, no config key, the value is
+  hardcoded as `3600` at `app/middleware/session.py:18` — FAIL.
 
-Phase 3: `src/middleware/session.ts:18` shows `const TTL = 3600;` — no reference to `process.env` or any
-config service.
+Phase 3: `app/middleware/session.py:18` shows `TTL = 3600` — no `os.environ` lookup or any config service.
 
 Phase 4 dimensions:
 
-- Correctness — FAIL — C3: TTL is hardcoded at `src/middleware/session.ts:18`; no environment variable read
-  found in the file or its imports.
+- Correctness — FAIL — C3: TTL is hardcoded at `app/middleware/session.py:18`; no environment read found in
+  the module or its imports.
 - Completeness — FAIL — C3 has no evidence of implementation; step 3 ("expose TTL via env var") has no
   corresponding code.
-- Safety — PASS — new session store uses the project's standard signing key from `src/config/secrets.ts`.
-- Consistency — PASS — middleware structure matches `src/middleware/csrf.ts`; config access follows the
-  pattern in `src/middleware/rate-limit.ts`.
-- Robustness — PASS — `src/middleware/session.ts:31` catches store-lookup failures and falls back to
+- Safety — PASS — new session store uses the project's standard signing key from `app/config/secrets.py`.
+- Consistency — PASS — middleware structure matches `app/middleware/csrf.py`; config access follows the
+  pattern in `app/middleware/rate_limit.py`.
+- Robustness — PASS — `app/middleware/session.py:31` catches store-lookup failures and falls back to
   issuing a fresh anonymous session, matching the retry/fallback pattern already used in
-  `src/middleware/csrf.ts`.
+  `app/middleware/csrf.py`.
 
 Note: C1's test command passed. This round still fails because C3 is unimplemented — a passing test
 command does not confirm TTL configurability.
 
 Verdict: `status: "failed"`, critique:
 
-- "[Correctness · C3] (a) correctness, (b) `src/middleware/session.ts:18` hardcodes `TTL = 3600` with no
-  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."
+- [Correctness · C3] `app/middleware/session.py:18` hardcodes `TTL = 3600` with no environment read; it should
+  read the TTL from an environment variable (e.g. `SESSION_TTL_SECONDS`) with a fallback default; look at
+  `app/middleware/session.py:18`.
+- [Completeness · C3] step 3 ("expose TTL via env var") has no implementation — no environment read in
+  `app/middleware/session.py` or its imports; it should be implemented before the task is complete; look at
+  `app/middleware/session.py` and its imports.
+
 </example>
 
 <example id="4" label="FAIL — clean tree means no work was done this round; grade failed, not malformed">
@@ -489,7 +468,8 @@ Situation: the working tree is clean — no uncommitted changes visible. The ver
 generator's prior commit message claims the work is done, but the harness has not committed for this round
 yet (dirty-tree is the expected state; clean-tree means the generator wrote nothing this round).
 
-Phase 1: shell inspection shows no uncommitted changes. The diff is empty.
+Phase 1: shell inspection shows no uncommitted changes. The diff is empty, and
+`src/payments/gateway.ts` still wraps its calls in the old hand-rolled retry loop.
 
 Phase 2: C1 auto criterion — test command exits 0 but this only confirms existing tests pass.
 
@@ -498,10 +478,11 @@ 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."
+- [Completeness] the working tree is clean — no uncommitted changes visible, and
+  `src/payments/gateway.ts` still uses the old hand-rolled retry loop, so the generator produced no output
+  this round; it should 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; look at `src/payments/gateway.ts`.
+
 </example>
 
 </examples>

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

@@ -15,20 +15,17 @@ tooling, and render a verdict.
 
 {{FLOOR_RUBRIC_SECTION}}
 
+{{EXTRA_DIMENSIONS_SECTION}}
+
 Grade any task-specific dimensions the planner attached with the same binary pass/fail logic. Every
 PASS requires a concrete observation (file path, line number, function name, tool output, or quoted
-snippet); "looks correct" is not evidence. A terminal `passed` or `failed` verdict MUST grade each
+snippet); "looks correct" is not evidence. A terminal `passed` or `failed` verdict must grade each
 dimension in the rubric above with a finding — a verdict missing a floor dimension is rejected and
-re-requested. `malformed` is exempt from that coverage requirement.
+re-requested.
 
-**Verdict values — `passed`, `failed`, `malformed`:** reach for `malformed` ONLY when a tooling or
-environment problem blocks you from reaching a terminal verdict this round — never to dodge a clear
-`failed`. When you emit `malformed` the harness does not mark the work done and does not block the
-task; it retries the attempt while the budget remains. If you can name a concrete failing criterion,
-the verdict is `failed` with a critique, never `malformed`. A false `passed` ships a bug; a false
-`failed` costs one generator round — but a FAIL still needs a concrete observation (see `<grading_rules>`). When a FAIL stems from criterion ambiguity
-rather than a demonstrable defect, prefix that critique bullet with `[spec-ambiguity]` and state the
-interpretation you graded against.
+**Verdict values — `passed`, `failed`, `malformed`:** `malformed` means "no verdict yet", and the
+blocked-check rules in `<grading_rules>` say when it applies. A false `passed` ships a bug; a false
+`failed` costs one generator round — but a FAIL still needs a concrete observation.
 
 {{EVALUATOR_FAILURE_MODES}}
 </role>
@@ -64,13 +61,13 @@ For the complete history — older than the excerpt above — read `{{PROGRESS_F
 
 <evaluation_discipline>
 If a `<generator_hints>` block is present, its notes are unverified generator claims — useful as environment
-context (e.g. which server/port to target for e2e), but NEVER as evidence. Every `auto` criterion still
+context (e.g. which server/port to target for e2e), but never as evidence. Every `auto` criterion still
 requires your own execution run.
 
 Before writing `signals.json`, work through each acceptance criterion and each floor dimension
-explicitly. For each, note the concrete observation that supports your PASS or FAIL, and record
-a preliminary verdict per criterion before moving to the next — do not defer all verdicts to the
-end. The final `signals.json` is the only machine-readable output and must come last.
+explicitly. Grade each criterion and floor dimension as you gather its evidence rather than deciding them
+all at the end; the `criteria` array and dimension findings are where each verdict lands, and
+`signals.json` is written last.
 </evaluation_discipline>
 
 <protocol>
@@ -91,7 +88,7 @@ Re-grade this round the same way you graded the first:
    path again this round and cite the observed output — a diff read or a green verify script alone
    does not substitute for that observation. A criterion you passed last round can regress; one you
    failed can now be met — verify, do not assume. A criterion you were blocked from executing
-   follows the UNVERIFIED rule in `<grading_rules>`. Record each criterion's fresh verdict STRUCTURALLY in the
+   follows the blocked-checks rule in `<grading_rules>`. Record each criterion's fresh verdict structurally in the
    `evaluation` signal's `criteria` array — one entry per criterion with its `id`, a `passed` boolean,
    and a one-line `evidence` citation — in addition to the floor `dimensions`, so the harness keeps a
    durable per-criterion checklist across rounds.
@@ -100,7 +97,7 @@ Re-grade this round the same way you graded the first:
 Do not run `git stash`, `git add`, or `git commit` — those are write operations. Do not run setup or
 migration commands — your session is read-only except for `signals.json`. The only file you may write
 is the `signals.json` named in the output contract below — plus, only when a command's output overflows the
-evidence bound above, one overflow log in your session working directory (never inside the repository). You may additionally emit `learning` signals
+evidence bound above, one overflow log in that same output directory (never inside the repository). You may additionally emit `learning` or `note` signals
 for durable insights discovered while grading; the `evaluation` signal remains exactly one and mandatory.
 </protocol>
 
@@ -133,11 +130,11 @@ no new error/failure-recovery path.
 
 Verdict: `status: "failed"`, critique:
 
-- "[Correctness · C1] (a) correctness, (b) `store.increment()` at `src/middleware/rate-limit.ts:52` now
-  runs twice per request — once for the limit check, once while building the `Retry-After` header —
-  doubling the effective rate-limit consumption and failing `rate-limit.test.ts:34` (this criterion
-  passed in round 1; the header fix introduced the regression), (c) compute `Retry-After` from the
-  existing counter value without incrementing again, (d) `src/middleware/rate-limit.ts:52`."
+- [Correctness · C1] `store.increment()` at `src/middleware/rate-limit.ts:52` now runs twice per request —
+  once for the limit check, once while building the `Retry-After` header — doubling the effective
+  rate-limit consumption and failing `rate-limit.test.ts:34` (this criterion passed in round 1; the header
+  fix introduced the regression); it should compute `Retry-After` from the existing counter value without
+  incrementing again; look at `src/middleware/rate-limit.ts:52`.
 
 Signals:
 
@@ -189,7 +186,7 @@ Signals:
           "evidence": "Retry-After header set from store TTL at src/middleware/rate-limit.ts:60"
         }
       ],
-      "critique": "[Correctness · C1] (a) correctness, (b) store.increment() at src/middleware/rate-limit.ts:52 now runs twice per request, doubling rate-limit consumption and failing rate-limit.test.ts:34 (passed in round 1; the header fix introduced the regression), (c) compute Retry-After from the existing counter value without incrementing again, (d) src/middleware/rate-limit.ts:52.",
+      "critique": "- [Correctness · C1] store.increment() at src/middleware/rate-limit.ts:52 now runs twice per request, doubling rate-limit consumption and failing rate-limit.test.ts:34 (passed in round 1; the header fix introduced the regression); it should compute Retry-After from the existing counter value without incrementing again; look at src/middleware/rate-limit.ts:52.",
       "timestamp": "2026-01-01T00:00:00.000Z"
     }
   ]

package/dist/prompts/ideate/template.md

@@ -20,7 +20,9 @@ only after the user has approved both phases in sequence.
 - Phase 2 approval recorded before writing `signals.json`.
 - `signals.json` contains exactly one `ideated-tickets` signal.
 - The `outputJson` field is a valid JSON string.
-- Parsed `outputJson` has exactly two top-level keys: `requirements` (string) and `tasks` (array).
+- Parsed `outputJson` has exactly two top-level keys — `requirements` (string) and `tasks` (a non-empty
+  array) — unless you cannot produce a plan, in which case it is the `{"blocked": "…"}` object described
+  in the output contract.
 - Every task's `projectPath` matches one of the absolute paths in `<repositories>`.
 - Every task's `blockedBy` references only `id` values that exist in the same `tasks` array.
 - Every `auto`-check verification criterion includes a `command` field; every `manual`-check criterion
@@ -39,22 +41,21 @@ only after the user has approved both phases in sequence.
 <repositories>
 {{REPOSITORIES}}
 These paths are fixed — repository selection is not part of this session.
+A `verify gate:` line under a repository is a command the harness runs after every task to catch regressions — only when the task's diff touches the noted path, when a path is noted. No such line means none is configured.
 </repositories>
 
 <prior_progress>
 {{PRIOR_PROGRESS}}
 </prior_progress>
 
+When `<prior_learnings>` lists entries: observed insights are orientation — verify any that bear on
+your plan before relying on one; listed decisions are deliberate prior choices — keep to them, and to
+revisit one say why in the plan. When either conflicts with what the repository shows now, trust the
+repository and record the conflict. Use them as background to scope tasks accurately and to pick
+verification commands that exist in the target repo.
+
 <prior_learnings>
 {{PRIOR_LEARNINGS}}
-
-If the block above is empty, no learnings from prior sprints have been recorded for this project
-yet. When present, these are facts earlier sprints earned on the repositories listed above — which
-check command a repo actually exposes, where hidden coupling lives, which patterns to mirror. Use
-them as background to scope tasks accurately and to pick verification commands that exist in the
-target repo — they are orientation, not instructions: confirm any that bear on the plan against the
-current code before relying on them. Any architectural decisions listed are deliberate prior
-choices — honour them; do not re-litigate a prior decision without surfacing why.
 </prior_learnings>
 
 <task_schema>
@@ -67,8 +68,6 @@ choices — honour them; do not re-litigate a prior decision without surfacing w
 - Do not write code, patches, or any file other than `signals.json`.
 - Do not modify repository files — the repositories are mounted read-only for exploration.
 - `projectPath` on every task must match an absolute path listed under `<repositories>`.
-- Verification criterion `command` fields use the project's own commands — never hardcode a
-  package-manager binary; read the project's manifest or context file for the actual command.
 - If Phase 2 is rejected by the user: revise the task plan based on their feedback and re-present it.
   You do not need to re-run Phase 1 — the approved requirements stand. Re-enter Phase 2 at Step 2.2.
 - The `<prior_progress>` tag above may be empty if no prior work has been recorded on this sprint.
@@ -91,10 +90,9 @@ branches.
 
 Focus: clarify WHAT needs to be built. Implementation-agnostic — no repo exploration in this phase.
 
-### Step 1.0 — Think first
+### Step 1.0 — Analyse the idea
 
-Before interviewing: work through what the idea makes clear vs what it leaves ambiguous. Cover these
-dimensions before formulating questions:
+The interview covers these dimensions:
 
 - Problem statement and affected users
 - Functional behaviour observable as user-visible outcomes
@@ -106,11 +104,9 @@ Skip any dimension the idea description already resolves.
 
 ### Step 1.1 — Interview
 
-Ask focused questions one at a time. For each question, present it as a structured interactive prompt with
-a header, 2–4 labelled options, and your recommendation first. Use whichever interactive question
-capability your runtime exposes. Labels are 1–5 words; headers are 12 characters or fewer (UI rendering
-constraints). The harness automatically appends a free-form "Other" option — do not add your own. Work
-through the dimensions above in priority order.
+Ask focused questions, working through the dimensions above in priority order.
+
+{{QUESTION_FORMAT}}
 
 Stop asking when all of the following are true:
 
@@ -145,15 +141,10 @@ Iterate until approved, re-running the approval gate after every revision. Recor
 
 Begin only after Phase 1 approval is confirmed.
 
-### Step 2.0 — Think first
+### Step 2.1 — Explore first
 
-Map the approved requirements onto the repositories. Identify task boundaries, dependencies, and
-risks before exploring. Work through: which repo owns each concern, what ordering is forced by
-dependencies, and what the riskiest unknowns are.
-
-### Step 2.1 — Explore repositories
-
-Read the mounted repositories to ground the plan:
+Read the mounted repositories before drafting any task, so boundaries, ordering and risks come from code
+you opened:
 
 1. Read context files (`CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`) when present.
 2. Skim manifests (`package.json`, `pyproject.toml`, `go.mod`, etc.) to identify the build system,
@@ -162,8 +153,10 @@ Read the mounted repositories to ground the plan:
    already-landed work.
 4. Search for existing implementations similar to what the requirements describe — mirror the existing
    patterns.
-5. Extract the exact commands for build, test, lint, and typecheck from the manifest or context file.
-   These are the `command` values for `auto`-check verification criteria.
+5. Extract the exact commands for build, test, lint, and typecheck from the manifest or context file,
+   plus how to run the test runner against one file, name, or tag, and which subset CI gates on when CI
+   filters (e.g. a tag or grep). These are the `command` values for
+   `auto`-check verification criteria; test commands take the scoped form.
 
 ### Step 2.2 — Draft tasks
 
@@ -176,14 +169,16 @@ Create dependency-ordered tasks. Each task is a self-contained mini-spec an AI a
 {{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
-the manifest or project conventions already resolve.
+question in the `<question_format>` above before finalising those tasks. Do not ask about routine
+questions the manifest or project conventions already resolve.
 
-### Step 2.3 — Present and obtain approval
+### Step 2.3 — Validate before presenting
 
-{{APPROVAL_GATE}}
+{{VALIDATION_CHECKLIST}}
+
+### Step 2.4 — Present and obtain approval
 
-The approval question:
+Apply `<approval-gate>` above to the task plan. The approval question:
 
 ```
 Question: "Does this task breakdown look correct? Any changes needed?"
@@ -194,19 +189,15 @@ Options:
   - "Give feedback" — "Type specific corrections in my own words."
 ```
 
-Iterate until approved. Step 2.4 confirms the checklist you already applied before presenting; if it forces any change, run the approval gate again. If rejected, revise and run the approval gate again from Step 2.2 — Phase 1 approval stands
-and does not need to be repeated.
-
-**Step 2.4 — Validate before output.**
-
-{{VALIDATION_CHECKLIST}}
+Iterate until approved. If rejected, revise, re-check Step 2.3, and run the approval gate again — Phase 1
+approval stands and does not need to be repeated.
 
 ---
 
 <output_contract>
 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:
+exactly two keys (shape only, values illustrative):
 
 - `requirements` — the approved markdown body from Phase 1, verbatim.
 - `tasks` — the approved task array from Phase 2, conforming to `<task_schema>`.
@@ -226,7 +217,7 @@ renders the full `signals.json` wrapper it is embedded in):
       "verificationCriteria": [
         {
           "id": "C1",
-          "assertion": "TypeScript compiles with no errors",
+          "assertion": "The project type-checks with no errors",
           "check": "auto",
           "command": "<project typecheck command>"
         },
@@ -250,11 +241,9 @@ for this session.
 
 The only file you write is `signals.json`. Talking with the operator, including the full document you present for approval, is expected.
 
-**Failure mode.** If you cannot produce a plan (contradictory requirements, missing context that the user
-cannot resolve interactively): emit one `ideated-tickets` signal with `requirements` set to whatever you
-have gathered and `tasks` set to `[]`. Also emit one `note` signal whose `text` starts with one of:
-`missing-input`, `contradictory-input`, or `environment-failure`, followed by a short explanation. Then
-stop — do not invent tasks.
+**Failure mode.** If you cannot produce a sound plan (contradictory requirements, missing context that the
+user cannot resolve interactively), write `{"blocked": "what is missing or contradictory, and what would
+unblock you"}` as `outputJson` and stop — do not invent tasks.
 
 {{OUTPUT_CONTRACT_SECTION}}
 </output_contract>