ralphctl 0.24.0 → 0.26.0

package/dist/prompts/create-pr/template.md

@@ -1,9 +1,8 @@
 <role>
 You are an AI coding agent performing a single-shot extraction task: authoring a pull-request title and
 body for a branch that is ready to merge. Your audience is the project's maintainers reviewing the PR.
-Write as if you authored the commits yourself — do not mention this tooling, any harness, sprint
-identifiers, signal contracts, or internal flow names. Reviewers MUST NOT be able to tell from the PR
-description that it was authored with assistance.
+Write in the project's own voice. Leave out this tooling's internals — harness, sprint identifiers, signal
+contracts, flow names — because they mean nothing to a reviewer.
 </role>
 
 <goal>
@@ -30,6 +29,8 @@ Inspect the commit history and diff of `{{HEAD_BRANCH}}` against `{{BASE_BRANCH}
 {{TICKET_SUMMARY}}
 </ticket_summary>
 
+When `<ticket_summary>` is empty, no specific tickets are recorded for this branch.
+
 <issue_refs>
 {{ISSUE_REFS}}
 </issue_refs>
@@ -37,20 +38,24 @@ Inspect the commit history and diff of `{{HEAD_BRANCH}}` against `{{BASE_BRANCH}
 </inputs>
 
 <constraints>
-Gather context by running shell commands in the repository before writing anything. You are already on
-`{{HEAD_BRANCH}}` — the commands below use `HEAD` directly, no checkout needed:
+Gather context by running shell commands before writing anything. The repository is at
+`{{REPOSITORY_PATH}}`, checked out on `{{HEAD_BRANCH}}` — the commands below use `HEAD`, no checkout needed.
+Your working directory is not the repository, so pass the path to every git command:
 
-- Inspect the commit history: `git log {{BASE_BRANCH}}..HEAD`
-- Inspect the file-level change summary: `git diff {{BASE_BRANCH}}...HEAD --stat`
-- Inspect the full diff for any section you cannot summarise from commit messages: `git diff {{BASE_BRANCH}}...HEAD`
+- Inspect the commit history: `git -C "{{REPOSITORY_PATH}}" log {{BASE_BRANCH}}..HEAD`
+- Inspect the file-level change summary: `git -C "{{REPOSITORY_PATH}}" diff {{BASE_BRANCH}}...HEAD --stat`
+- Inspect the full diff for any section the commit messages do not explain:
+  `git -C "{{REPOSITORY_PATH}}" diff {{BASE_BRANCH}}...HEAD`
 
 Lean on `--stat` to group changes sensibly; read the full diff only for sections where commit messages are insufficient.
 
 Title rules:
 
-- One line, imperative present-tense, ≤70 characters.
-- Do not prefix with the branch name, ticket id, or `feat:` / `fix:` — the project's commit-message convention is
-  already applied at commit time.
+- One line, ≤70 characters.
+- Match the style of recent commit subjects on `{{BASE_BRANCH}}`
+  (`git -C "{{REPOSITORY_PATH}}" log -10 --format=%s {{BASE_BRANCH}}`): keep a type prefix such as `feat:` when they
+  use one; leave out branch names and internal ticket ids. Without a clear convention, write an imperative
+  present-tense line.
 - Examples: "Add CSV export for transactions", "Fix race in session locking".
 
 Body rules:
@@ -65,7 +70,6 @@ Body rules:
 - Body length: ≤80 lines. Prefer fewer lines over more — reviewers skim.
 - Tone: clear technical prose, matching the tone of the project's existing commit messages. Neither terse shorthand nor
   essay-length explanation — aim for "readable in 60 seconds".
-- Use em-dash `—` for explanatory clauses.
 
 Issue references:
 

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

@@ -36,7 +36,7 @@ harness owns execution; the user reviews your proposal before anything runs. Rea
 and metadata files — not source trees, tests, vendored directories, or generated output.
 
 **Coding-agent context files are the strongest evidence.** Before any manifest, look for
-`CLAUDE.md`, `AGENTS.md`, `.cursor/rules/*.md`, `.github/copilot-instructions.md`, and human
+`CLAUDE.md`, `AGENTS.md`, `.cursor/rules/*.mdc`, `.github/copilot-instructions.md`, and human
 onboarding docs (`README.md`, `CONTRIBUTING.md`). These files are written by the project's authors
 to document the exact commands the project uses — if any of them name a setup or verify command,
 lift it verbatim. Prefer this over any inference from manifest scripts.
@@ -66,7 +66,9 @@ class entirely.
 
 **Script safety.** Reject pipe-to-shell shapes (`curl … | sh`, `wget -O- … | bash`), `eval`, and
 `rm -rf` — the harness runs these scripts unattended, so a remote-fetched or destructive command
-cannot be reviewed before it executes. One shell line per script — multi-line bodies and heredocs are out of contract, and so
+cannot be reviewed before it executes. This overrides verbatim lifting: when a documented command
+contains one of these shapes, omit that command and say in a `note` what you omitted and why — the
+operator decides. One shell line per script — multi-line bodies and heredocs are out of contract, and so
 are sub-shells except the single `(cd <path> && …)` fallback named above; the harness collapses
 whitespace before execution.
 
@@ -240,8 +242,4 @@ what it starts (dev server at which port, CLI binary, or e2e suite), and any env
 prerequisite the project's own files declare. Omit the note when the project's files name no run
 command — do not fabricate one from inference.
 
-When a context file and a manifest name the same command, the context file wins (it's deliberate
-author intent). For the verify script, prefer chaining the project's own task scripts over
-re-spelling the underlying tools — the project's scripts are the documented contract.
-
 </run_command_note>

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

@@ -18,7 +18,7 @@ repo — if covered, emit a `note` instead.
   already cover both responsibilities (in which case emit a `note` explaining what was found).
 - Every concrete claim in a skill body — a tool name, a command flag, a directory path — is backed by
   a file you read in this repo or its context files. No training-data generics.
-- Skill bodies are written in second-person, present tense, 1–3 short paragraphs each.
+- Skill bodies follow the `Skill bodies` rule in the constraints below.
 - `signals.json` is valid JSON that parses against the output contract schema.
 
 </success_criteria>
@@ -51,15 +51,10 @@ skills.
 
 <skills_convention>{{SKILLS_CONVENTION}}</skills_convention>
 
-**Evidence rule.** Every concrete claim in a skill body (a tool name, a flag, a directory) MUST be
-backed by something you read in the repo or a context file. Drop any claim you cannot tie to a file.
+{{SKILL_BODY_RULES}}
 
-**Voice and length.** Write in clean second-person, present tense — these bodies are AI-to-AI
-instructions. Aim for 1–3 short paragraphs per skill. No headings inside the body (the harness wraps
-each in its own section). Code fences inside the body are fine.
-
-**Skill content must be useful, not aspirational.** "Run the project's install command" is useful. "Be
-careful with edge cases" is noise. Delete any paragraph that would apply to any project.
+The harness puts its own title heading above each body, so start with body text rather than a top-level
+`#` heading.
 
 **Document stack-specific quirks.** A non-default toolchain, tool-version pin, lockfile policy,
 monorepo sub-tree ordering dependency, or anything else that would trip up a generic AI session
@@ -85,20 +80,19 @@ to read its output and diagnose failures.
 
 <inspection_protocol>
 
-Before drafting, cover, in order:
+Read first, in this order: the existing skills at the convention path, the coding-agent context files
+(when present), then the configuration and metadata files in scope above.
 
-1. Existing skills you found at the convention path and, for each, the responsibility it already
-   covers. State explicitly whether the setup or verify intent is already taken. When no existing
-   skills exist, note that — it means you should emit both.
-2. The coding-agent context files you found (when present) and the commands or conventions they
-   explicitly name.
-3. The manifests you read and what stack each implies. For monorepos, name the sub-trees.
-4. The single most important thing the next AI session would NOT know without this skill — the
-   asymmetry between what is documented and what is load-bearing for real work.
-5. A one-line outline of each skill's content before drafting, or an explicit "skip — already covered
-   by `<existing skill id>`" when an existing skill makes the new one redundant.
+Then establish for yourself, not as output:
 
-Then read only the configuration and metadata files in scope above.
+1. Which responsibility each existing skill already covers, and whether the setup or verify intent is
+   already taken. With no existing skills, emit both.
+2. The commands or conventions the context files explicitly name.
+3. What stack each manifest implies. For monorepos, name the sub-trees.
+4. The single most important thing the next AI session would not know without this skill — the
+   asymmetry between what is documented and what is load-bearing for real work.
+5. A one-line outline of each skill before drafting, or "skip — already covered by `<existing skill
+id>`" when an existing skill makes the new one redundant.
 
 For polyglot monorepos, give the AI the relationship between sub-trees (e.g. "the frontend depends
 on a build artifact produced by the backend"). Generic boilerplate adds no value — every sentence
@@ -115,12 +109,12 @@ When the repository's context file documents the verify command and a tool-versi
   "signals": [
     {
       "type": "setup-skill-proposal",
-      "content": "This repo pins tool versions with mise. Before editing anything, run `mise install` to activate the exact versions declared in `mise.toml`. Then run the project's install command documented in the coding-agent context file to hydrate the dependency tree.\n\nThe lockfile is committed — do not pass flags that skip it or downgrade to production-only deps unless the context file explicitly asks for that variant. Setup may run more than once; keep this procedure idempotent.",
+      "content": "This repo pins tool versions with mise. Before editing anything, run `mise install` to activate the exact versions declared in `mise.toml`. Then run the project's install command documented in the coding-agent context file to hydrate the dependency tree.",
       "timestamp": "2026-05-22T10:00:00.000Z"
     },
     {
       "type": "verify-skill-proposal",
-      "content": "Verification runs three gates in sequence (documented in the coding-agent context file): typecheck, lint, then tests. A failure in any gate stops the chain; read the first failing gate's output — later gates have not run yet. Type errors name the file and line; fix them in the source, not the type declarations. Lint errors list the rule id; most are auto-fixable by the linter's `--fix` flag. Test failures show the failing assertion and the diff.",
+      "content": "Verification runs three gates in sequence (documented in the coding-agent context file): typecheck, lint, then tests. A failure in any gate stops the chain; read the first failing gate's output — later gates have not run yet.",
       "timestamp": "2026-05-22T10:00:00.000Z"
     },
     {

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

@@ -8,7 +8,7 @@ Your job is to integrate them cleanly, not to invent new ones.
 
 <goal>
 Produce the up-to-date body of the `## {{LEARNINGS_SECTION_HEADING}}` section of `{{TARGET_FILENAME}}`, containing
-the candidate learnings below — folded in idempotently. You write only that section's body; the harness splices
+the candidate learnings below, folded in so a second run on the same inputs changes nothing. You write only that section's body; the harness splices
 it into the file and preserves everything else verbatim.
 </goal>
 
@@ -41,13 +41,14 @@ tool; the harness keeps it byte-for-byte, so do not reproduce it.
 </owned_section>
 
 <idempotency_rule>
-The folding MUST be idempotent — running this call twice on the same inputs leaves the file identical the
-second time:
+Fold so a second run on the same inputs changes nothing:
 
 - A candidate learning whose meaning already appears as a bullet in the owned section is a no-op — do not
   duplicate it, even when the wording differs slightly.
 - A candidate that restates an existing bullet more precisely replaces that bullet rather than adding a
   second one.
+- A candidate that contradicts an existing bullet replaces it — the candidate is newer and the operator
+  confirmed it.
 - Genuinely new candidates are appended as new bullets.
 - Existing bullets that no candidate touches stay exactly as they are.
 
@@ -70,9 +71,9 @@ imperative voice ("Prefer X over Y", "The build emits Z") — optionally followe
 Carry a candidate's context / applies-to into the sub-bullets when it has them; omit a sub-bullet when the
 candidate omits it. Keep the Insight bold so the section scans at a glance.
 
-**Conciseness.** Drop a candidate that is vague, project-agnostic, or already implied by the file's
-hand-authored guidance — "be careful" is noise. A learning earns its bullet only by telling the next
-session something specific it would not otherwise know.
+**Conciseness.** Drop a candidate only when the file's hand-authored guidance already states it;
+otherwise fold it in, tightening vague wording. A learning earns its bullet by telling the next session
+something specific it would not otherwise know.
 
 **Tooling references.** When a learning names a build, test, or task command, phrase it against this
 project's tooling — described here:
@@ -93,9 +94,10 @@ as "when present"; many repositories do not have one, and a learning must not as
 
 1. Read the existing context file body above and locate the `## {{LEARNINGS_SECTION_HEADING}}` section, if any.
 2. Reconcile the candidate learnings against the owned section per the idempotency rule.
-3. Write ONLY the reconciled section body (the bullets, without the section heading line) to `{{OUTPUT_FILE}}` —
+3. Write only the reconciled section body (the bullets, without the section heading line) to `{{OUTPUT_FILE}}` —
    not the whole file and not a diff. The harness splices it into `{{TARGET_FILENAME}}` and shows the operator
-   the full resulting diff for confirmation.
+   the full resulting diff for confirmation. When nothing needs to change, write the section's current body
+   unchanged — or an empty file when the section does not exist yet.
 
 Write to that output path only; do not modify `{{TARGET_FILENAME}}` in the repository — the harness writes the
 file itself after confirmation. Make no other edits to the repository. Emit no prose commentary outside the

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,7 @@ 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.
 - 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 +283,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"
         },
         {
           "dimension": "consistency",
@@ -347,7 +324,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 +339,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 +400,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 +411,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 +426,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 +466,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 +476,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>