ralphctl 0.16.0 → 0.17.1

package/dist/cli.mjs

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

package/dist/manifest.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
-  "packageVersion": "0.16.0",
-  "generatedAt": "2026-07-18T13:59:00.834Z",
+  "packageVersion": "0.17.1",
+  "generatedAt": "2026-07-28T04:40:58.689Z",
   "assets": [
     "agent-definitions/ralphctl-evaluator.md",
     "agent-definitions/ralphctl-generator.md",

package/dist/prompts/_partials/conventions-agents-md.md

@@ -47,14 +47,14 @@ break the shared lockfile.
 
 ## Architecture
 
-- Clean Architecture: `domain → business → integration → application`. No reverse imports.
-- No barrel files (`index.ts` re-exports) — every import names its symbol explicitly.
+- <your layering rule> — e.g. which modules may import which, and which direction is forbidden.
+- <your module-boundary rule> — e.g. no barrel re-export files; every import names its symbol explicitly.
 
 ## Conventions
 
-- Business operations return a `Result` type — do not throw for domain errors.
-- All file writes go through the atomic-write helper in `business/io/`; direct `fs.writeFile`
-  is banned from business code.
+- <your error-handling convention> — e.g. return a typed result instead of throwing for domain errors.
+- <your I/O convention> — e.g. all writes go through one shared helper; direct filesystem calls
+  are banned elsewhere.
 
 ## Security
 

package/dist/prompts/_partials/conventions-claude-md.md

@@ -10,7 +10,7 @@ invocation, not as a tutorial or README.
 - At most seven H2 sections (`## Build & Run`, `## Testing`, `## Architecture`, …). Fewer is better.
 - No H4 headings or deeper — three heading levels (`#`, `##`, `###`) is the practical maximum.
 - Prefer tight bullet lists over prose paragraphs; each bullet should be one verifiable claim.
-- Hard line cap: 200 lines. Instruction adherence measurably degrades on longer context files, so
+- Hard line cap: 200 lines. Instruction adherence degrades on longer context files, so
   brevity is load-bearing.
 
 **"Read on demand" pattern** — for sections that an agent rarely needs mid-task, list them under a
@@ -19,8 +19,8 @@ invocation, not as a tutorial or README.
 ```
 ## References
 
-- `.claude/docs/ARCHITECTURE.md` — module layout and layering rules
-- `.claude/docs/DESIGN-SYSTEM.md` — TUI tokens and component copy rules
+- `docs/architecture.md` — module layout and layering rules
+- `docs/style-guide.md` — UI style guide and component copy rules
 ```
 
 This keeps the primary file short while keeping the information reachable.
@@ -48,12 +48,11 @@ Node.js 20 + TypeScript. Run `<install command>` once, then `<dev command>` to s
 
 ## Architecture
 
-- Four-module Clean Architecture: `domain → business → integration → application`.
-- No barrel `index.ts` files under `src/` — name every import explicitly.
-- Business code must not import I/O-bearing `node:*` modules — pure `node:path` / `node:url` ok.
+- <your layering rule> — e.g. which modules may import which, and which direction is forbidden.
+- <your module-boundary rule> — e.g. no cross-module reach-arounds; go through the declared seam.
 
 ## Conventions
 
-- Return `Result<T, DomainError>` from every business operation — do not throw.
-- Em-dash (`—`) for explanatory clauses in comments and docs.
+- <your error-handling convention> — e.g. return a typed result instead of throwing.
+- <your formatting or naming convention> — state it as a checkable rule, not general advice.
 ```

package/dist/prompts/_partials/conventions-copilot-instructions.md

@@ -30,10 +30,9 @@ advice the model already follows by default.
 ```markdown
 ## Architecture
 
-- Four-module Clean Architecture: `domain → business → integration → application` — inner layers
-  must not import outer ones. ESLint enforces this; a lint failure means a layering violation.
-- No barrel `index.ts` files — every import names what it pulls in. This keeps dead-code analysis
-  accurate; barrel files silently re-export unused symbols.
+- <your layering rule> — e.g. inner layers must not import outer ones. State the enforcement
+  mechanism (linter, review checklist) so the model knows a violation is checkable.
+- <your module-boundary rule> — e.g. no barrel re-export files; every import names what it pulls in.
 
 ## Testing
 
@@ -42,9 +41,8 @@ advice the model already follows by default.
 
 ## Conventions
 
-- Every business operation returns `Result<T, DomainError>` — do not throw. Throws are reserved for
-  programmer errors (invariant violations inside leaf projections).
-- Em-dash (`—`) for explanatory clauses in comments and documentation — not a hyphen.
+- <your error-handling convention> — e.g. return a typed result instead of throwing; reserve throws
+  for programmer errors.
 
 ## Security
 

package/dist/prompts/_partials/decisions.md

@@ -15,6 +15,7 @@ in the sprint's decisions log.
   convention). Obvious changes do not need a decision entry.
 - **One sentence per decision** — lead with the choice, then the rationale: "Used X over Y because Z." Use
   two sentences only when the rationale genuinely cannot be compressed without losing the key tradeoff.
+- Keep `text` under roughly 500 characters.
 - The harness appends task id automatically — do not include it yourself, but DO include the `timestamp`
   field (ISO 8601).
 - Emit one signal per decision rather than packing several choices into one `text` body.

package/dist/prompts/_partials/validation-checklist.md

@@ -4,7 +4,7 @@
 
 Before writing the JSON output, verify EVERY item:
 
-1. **Requirements understood** — every approved ticket is reflected in at least one task; nothing in scope is dropped.
+1. **Requirements understood** — every requirement in scope is reflected in at least one task; nothing in scope is dropped.
 2. **Exclusive file ownership** — each file is owned by exactly one task. When two tasks must edit the same file,
    make the relationship explicit via `blockedBy` so they run in sequence, not in parallel.
 3. **Foundations before dependents** — order tasks so prerequisites come first; `blockedBy` reflects genuine code
@@ -15,11 +15,10 @@ Before writing the JSON output, verify EVERY item:
    functions; "implement the feature" is not a step.
 6. **Verification criteria** — each task has 2–4 `verificationCriteria` that are testable and unambiguous.
    "Tests pass" alone is too vague — name the behaviour or invariant that proves the task is done.
-7. **Repository assignment** — every task's `projectPath` matches one of the absolute paths listed under
-   "Selected repositories" above.
-8. **Signal output only** — the task array goes into the `tasksJson` field of the `task-plan` signal written
-   to `signals.json`. Do not emit the JSON array as prose or inside markdown fences — only the signal file
-   is read by the harness.
+7. **Repository assignment** — every task's `projectPath` matches one of the repository paths provided above.
+8. **Signal output only** — the task array goes into the output signal named in your output contract below.
+   Do not emit the JSON array as prose or inside markdown fences — only the signal file is read by the
+   harness.
 9. **Unique placeholder ids** — each task's `id` is a unique string within this array (used only for
    `blockedBy` resolution; the harness assigns persistent ids on save).
 10. **Deterministic checks preferred** — each task includes at least one `auto` criterion when the

package/dist/prompts/apply-feedback/template.md

@@ -13,8 +13,7 @@ or a false verify result.
 
 <goal>
 Apply every change requested in `<latest_round>` by writing the affected files. Emit `task-complete` when
-done. Emit `task-blocked` if the request is ambiguous in WHAT to change (not WHERE — pick the narrowest
-plausible target when the location is unclear).
+done, or `task-blocked` when the request is ambiguous — see Phase 3 below for the WHAT-vs-WHERE distinction.
 </goal>
 
 <success_criteria>
@@ -74,10 +73,6 @@ direction.
 **Write the files — don't describe the edits.** The harness does not apply changes for you. A written-out
 description without actual file writes is not feedback applied.
 
-**Do not commit. Do not run verify scripts.** The harness commits your changes with the message
-`feedback(round-N): <body-snippet>` and then runs the project's verify script. Emit `task-complete` once
-your edits are on disk and let the harness drive the gate.
-
 **Pre-existing uncommitted changes are a protocol violation.** If `git status` shows a dirty tree before you
 start editing, stop and emit `task-blocked` with reason `dirty-tree`.
 
@@ -95,8 +90,8 @@ referencing the change), not in a signal.
 
 <capabilities>
 You can read and write files under every repository path listed in `<repositories>`. You can run shell
-commands (e.g. `git status`, `git log`) to orient yourself. You cannot commit or push — the harness owns
-those steps. You cannot run the verify script — the harness runs it after your signal.
+commands (e.g. `git status`, `git log`) to orient yourself. You cannot commit, push, or run the verify
+script — the harness owns those steps (see the role note above).
 </capabilities>
 
 ## Protocol
@@ -106,8 +101,8 @@ those steps. You cannot run the verify script — the harness runs it after your
 Before editing, work through what the latest round is asking, which files you expect to touch, and any
 constraints from the feedback log or progress. Then:
 
-1. Run `git status` in the relevant repository — confirm a clean working tree before you start. If the tree
-   is dirty, emit `task-blocked` with reason `dirty-tree` and stop.
+1. Run `git status` in each repository you will touch — confirm a clean working tree before you start. If
+   the tree is dirty, emit `task-blocked` with reason `dirty-tree` and stop.
 2. Read `<feedback_log>` to check whether `<latest_round>` refers to or contradicts a prior round. Trust the
    latest round's direction even when it reverses an earlier decision.
 3. If `<feedback_log>` is empty, this is round 1 — there is no prior context to reconcile; proceed directly
@@ -118,7 +113,6 @@ constraints from the feedback log or progress. Then:
 1. Apply only what `<latest_round>` asks. No opportunistic refactors, no unsolicited tests.
 2. Be surgical — small, targeted edits to the files the round names, or the nearest obvious files when the
    round is symptom-described rather than file-described.
-3. Do not commit. Do not run verify.
 
 ### Phase 3 — Signal outcome
 

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

@@ -15,10 +15,7 @@ Inspect the commit history and diff of `{{HEAD_BRANCH}}` against `{{BASE_BRANCH}
 
 <success_criteria>
 
-- The signal carries a `title` of ≤70 characters, imperative present-tense (e.g. "Add CSV export for transactions").
-- The `body` has three sections in order: a 1–3 sentence summary, a `## Changes` bullet list, and a `## Test plan`
-  markdown checklist.
-- The `body` is ≤80 lines — concise summaries are a feature, not a limitation.
+- The `title` and `body` follow the format and length rules in the Constraints section below.
 - Every claim in `body` is supported by the actual diff or commit messages — nothing is invented.
 - Issue references, when present, appear verbatim at the end of `body`.
 
@@ -42,7 +39,8 @@ 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:
+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:
 
 - Inspect the commit history: `git log {{BASE_BRANCH}}..HEAD`
 - Inspect the file-level change summary: `git diff {{BASE_BRANCH}}...HEAD --stat`
@@ -69,7 +67,7 @@ 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, matching the project's house style.
+- Use em-dash `—` for explanatory clauses.
 
 Issue references:
 
@@ -86,8 +84,8 @@ Hard constraints:
 - Emit ONLY the `pr-content` signal. Do not emit narrative signals (`note`, `learning`, `decision`, `change`) — they are
   not consumed by this flow and represent wasted tokens.
 - If you cannot produce a meaningful title and body (e.g. the repository is inaccessible, the diff is empty, or there is
-  nothing to summarise), write `signals.json` as an empty array `[]` and stop. Do not invent PR content. The harness
-  falls back to a template-derived description in that case.
+  nothing to summarise), write `signals.json` as `{"schemaVersion": 1, "signals": []}` and stop. Do not invent PR
+  content. The harness falls back to a template-derived description in that case.
 
 </constraints>
 

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

@@ -21,10 +21,8 @@ module — so the harness can scope verification to the part of the tree a task
 - If no evidence exists for a script class, that signal is absent rather than fabricated.
 - Per-module verify gates appear only when the repository has distinct module roots — a
   single-module repository proposes the verify script alone and no gates.
-- When the project's documented contract names a command for starting the product in a running
-  state (a dev-server start script, application entry point, or end-to-end / smoke suite), a
-  `note` signal describes it: the exact invocation, what it starts, and any declared port or
-  environment prerequisite.
+- When the project's documented contract names a run command, a `note` signal describes it — see
+  the Protocol's Phase 1 step 5 and Phase 2 below for what counts and what the note must contain.
 
 </success_criteria>
 
@@ -67,8 +65,9 @@ what the project documented. Omit a signal only when the project's own files are
 class entirely.
 
 **Script safety.** Reject pipe-to-shell shapes (`curl … | sh`, `wget -O- … | bash`), `eval`, and
-`rm -rf`. One shell line per script — multi-line bodies, sub-shells, and heredocs are out of
-contract; the harness collapses whitespace before execution.
+`rm -rf`. 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.
 
 **Idempotence.** Prefer commands that are safe to re-run (e.g. the plain install invocation for
 the project's package manager rather than a frozen-lockfile / production-only variant, unless the
@@ -106,6 +105,8 @@ emit gates for it. When gates apply:
 
 <output_contract>
 
+Only `signals.json` is read by the harness; all other session output is forensic and not persisted as data.
+
 {{OUTPUT_CONTRACT_SECTION}}
 
 Emit only `setup-script`, `verify-script`, `verify-gates`, and `note` signals — no other signal
@@ -123,6 +124,7 @@ test`" and the manifest declares those scripts:
 
 ```json
 {
+  "schemaVersion": 1,
   "signals": [
     {
       "type": "setup-script",
@@ -147,6 +149,7 @@ When only a manifest exists with install + test scripts and no context file:
 
 ```json
 {
+  "schemaVersion": 1,
   "signals": [
     {
       "type": "setup-script",
@@ -172,6 +175,7 @@ verify steps:
 
 ```json
 {
+  "schemaVersion": 1,
   "signals": [
     {
       "type": "setup-script",
@@ -199,6 +203,7 @@ point:
 
 ```json
 {
+  "schemaVersion": 1,
   "signals": [
     {
       "type": "setup-script",
@@ -255,8 +260,6 @@ Before writing any output, cover, in order:
    the live product so it can be exercised as a real user would. List the command and the file
    that documents it.
 
-Only `signals.json` is read by the harness; all other session output is forensic and not persisted as data.
-
 Then read only the configuration and metadata files in scope above. Do NOT read source trees,
 tests, vendored directories, or generated output.
 

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

@@ -25,15 +25,16 @@ covers that responsibility for this repo.
 
 <inputs>
 <repository_path>{{REPOSITORY_PATH}}</repository_path>
-<skills_convention>See the full skills convention in the constraints section below.</skills_convention>
+<skills_convention_pointer>See the full skills convention in the constraints section below.</skills_convention_pointer>
 </inputs>
 
 {{HARNESS_CONTEXT}}
 
 <capabilities>
 You can read files anywhere in the repository at `{{REPOSITORY_PATH}}`. You cannot run shell commands,
-modify files, or create files — this invocation is read-only. The harness owns execution; your output
-is a proposal the operator reviews before anything lands.
+modify files, or create files — this invocation is read-only — except the single `signals.json` write
+the output contract names. The harness owns execution; your output is a proposal the operator reviews
+before anything lands.
 </capabilities>
 
 <constraints>
@@ -81,8 +82,8 @@ what it needs to know up front.
 **Verify skill** (`verify-skill-proposal`) — teaches a future AI session how to interpret verification
 results in this repo: which commands gate correctness, where the signal lives (test output, type
 errors, lint reports), and how to interpret common failure modes for this stack. The reader will run
-the verify script (a single shell command defined elsewhere on the repository entity) and needs to
-know how to read its output and diagnose failures.
+the verify script (a single shell command configured separately in the harness) and needs to know how
+to read its output and diagnose failures.
 </skill_shapes>
 
 <inspection_protocol>
@@ -119,7 +120,7 @@ signals.json
   "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. The harness may re-run setup across a sprint; the install command is 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.\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.",
       "timestamp": "2026-05-22T10:00:00.000Z"
     },
     {

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

@@ -34,6 +34,8 @@ hand-authored or owned by another tool — preserve it byte-for-byte.
   prior state and reconcile the candidates against them (see the idempotency rule below).
 - When the file has no such section yet, append one at the end of the file — after the last existing
   section, separated by a single blank line.
+- 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>
 

package/dist/prompts/evaluate/template.md

@@ -23,6 +23,10 @@ quality judgment.
 - 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.
 
 **Verdict values — `passed`, `failed`, `malformed`:**
 
@@ -36,6 +40,11 @@ unreadable or the mounted directory is missing required files; environment setup
 criterion command can run. Uncertainty about how to interpret a criterion is NOT `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 does NOT mark the work done and does NOT block 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
@@ -43,9 +52,9 @@ forcing a `passed` you cannot support — a false `passed` ships a bug; a `malfo
 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 all five floor dimensions (correctness, completeness,
-safety, consistency, robustness), each with a finding — a verdict missing a floor dimension is rejected by the
-harness and re-requested. `malformed` is exempt from that coverage requirement.
+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.
 </role>
 
 {{HARNESS_CONTEXT}}
@@ -54,15 +63,16 @@ harness and re-requested. `malformed` is exempt from that coverage requirement.
 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;
 `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.
+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.
 </goal>
 
 <success_criteria>
 
 - Every floor dimension graded with at least one concrete observation (file path, line, function, tool output,
   or quoted snippet) — not "looks correct" or "appears complete".
-- Every `auto` criterion in `<task_specification>` run via shell command; verbatim output in
-  `executionEvidence` field of the matching dimension.
+- Every `auto` criterion in `<task_specification>` run via shell command; the bounded evidence excerpt
+  specified in Phase 2 in the `executionEvidence` field of the matching dimension.
 - Every `manual` criterion graded with a `path:line` citation or equivalent behavioural evidence.
 - Every criterion recorded in the structured `criteria` array of the `evaluation` signal — its `id`,
   a `passed` boolean, and a one-line `evidence` citation — so the harness persists a durable
@@ -181,39 +191,50 @@ Write this file, then proceed to Phase 1.
 
 ### Phase 1 — Computational verification
 
-Before running any checks, list the criteria you will grade and any red flags from the task description.
+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.
 
 Run deterministic checks first — they are authoritative and cheap.
 
-1. **Run each `auto` criterion's command** from `<task_specification>` directly and record the verbatim
-   output for each. Do NOT run the verify script from `<verify_script>` — the harness runs that
+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
    `auto` criteria at all, run the verify script once as the fallback evidence source and record its output.
    If any criterion command fails, the implementation fails for that criterion regardless of how clean the
-   code looks. Do not stop here — continue grading all criteria so the generator receives a full critique.
+   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
    expected to be dirty at this point; a dirty tree is not a failure.
 3. **Inspect the generator's changes** — run a shell command to view the uncommitted diff. This is your
    primary view of what was implemented. The history will not show this task's work because no commit exists
    yet.
+4. **Audit the diff for verification tampering** — check whether the changes touch test files, fixtures, or
+   verification tooling themselves. A criterion satisfied by weakening or deleting a test, adding a skip, or
+   hardcoding an expected value is a Correctness FAIL, not a PASS — cite the specific diff hunk showing it.
 
 ### Phase 2 — Per-criterion assessment
 
 For every criterion in the contract:
 
-- **`auto` criteria** — run the specified command; record verbatim output (a trimmed tail for large outputs)
-  in `executionEvidence`. 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; 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.
 - **`manual` criteria** — cite the specific `path:line` or behavioural evidence. PASS only when the cited
   evidence demonstrably satisfies the assertion. "Looks good" / "appears correct" are not evidence.
 
 Grade each criterion PASS or FAIL — no middle ground. Any single criterion FAIL forces `status: "failed"`.
+When you could not verify a criterion — as opposed to observing a violation — grade `passed: false` and begin
+its evidence with "UNVERIFIED:" plus what blocked you, so downstream consumers can tell unverifiable apart
+from broken.
 
 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 you can; omit one only when you genuinely
-could not assess it this round.
+per-criterion checklist across rounds. Grade every criterion — including the ones you could not assess,
+which carry `passed: false` and the "UNVERIFIED:" evidence prefix above. Never omit a criterion from the
+array.
 
 ### Phase 3 — Inferential investigation
 
@@ -251,24 +272,11 @@ observation — file path, line number, function name, tool output, or quoted sn
 
 ### Phase 4 — Dimension assessment
 
-Evaluate across the five floor dimensions rendered in the grading rubric pinned at the top of this
-prompt. Write per-dimension
-findings as one PASS/FAIL verdict (or `applicable: false` for robustness, when justified) and 1–3 specific
-observations each, anchored to the acceptance criteria and check/verify output you gathered in Phases 1–3.
-
-1. **Correctness** — does the implementation do what the specification says, across every verification
-   criterion? Cite the criterion and the code that satisfies (or fails to satisfy) it.
-2. **Completeness** — are all declared steps present, all criteria addressed, all edge cases listed in the
-   requirements actually handled? Note any criterion you cannot find evidence for.
-3. **Safety** — are there error paths that crash, swallow, or silently corrupt? Inputs not validated at
-   trust boundaries? Resources that leak (file handles, subscriptions, locks)?
-4. **Consistency** — does the change follow the project's existing patterns and conventions (naming, file
-   organisation, error handling, test structure, import style)? Cite a specific sibling file or function
-   when the comparison matters.
-5. **Robustness** — does the change handle error and failure paths gracefully — unhandled exceptions,
-   missing error propagation, ungraceful degradation, recovery from transient faults? When the change
-   touches no error/failure path, grade this dimension `applicable: false` and state the concrete reason in
-   `finding` rather than fabricating a pass or fail.
+Grade each dimension per the rubric pinned at the top of this prompt. Write per-dimension findings as one
+PASS/FAIL verdict and 1–3 specific observations each, citing the criterion and the concrete file, line,
+or output evidence you gathered in Phases 1–3. Grade `applicable: false` only for a dimension the rubric
+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}}
 
@@ -276,8 +284,8 @@ observations each, anchored to the acceptance criteria and check/verify output y
 
 Answer both questions honestly:
 
-1. Did you execute every `auto` criterion's command and record its verbatim output? (If the task has no
-   `auto` criteria, did you run the verify script as the fallback?) If not, set Completeness `passed: false`
+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.
@@ -519,7 +527,7 @@ Verdict: `status: "failed"`, critique:
   marking the task complete, (d) `src/middleware/session.ts` and its import graph."
   </example>
 
-<example id="4" label="FAIL — cannot investigate; evaluator must not invent a verdict">
+<example id="4" label="FAIL — clean tree means no work was done this round; grade failed, not malformed">
 
 Task: "Refactor the payment module to use the new retry library"
 

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

@@ -17,16 +17,18 @@ tooling, and render a verdict.
 
 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 all
-five floor dimensions, each with a finding — a verdict missing a floor dimension is rejected and
-re-requested.
+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.
 
 **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 — when in doubt, fail.
+`failed` costs one generator round — when in doubt, fail. 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.
 
 **Evaluator failure modes to resist actively:**
 
@@ -37,6 +39,10 @@ the verdict is `failed` with a critique, never `malformed`. A false `passed` shi
 - 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>
 
 {{HARNESS_CONTEXT}}
@@ -110,23 +116,35 @@ re-grading determines the change touches no error/failure path (with the real re
 
 Re-grade this round the same way you graded the first:
 
-1. Re-run each `auto` criterion's command directly and record the verbatim output. Do NOT run the
+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.
+   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.
 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. Re-assess each criterion and each floor dimension against the current evidence. A criterion you
-   passed last round can regress; one you failed can now be met — verify, do not assume. 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.
-4. When `status: "failed"`, write a critique whose every bullet names (a) the dimension, (b) the
+3. Audit the diff for verification tampering — check whether this round's changes touch test files,
+   fixtures, or verification tooling themselves. A criterion satisfied by weakening or deleting a test,
+   adding a skip, or hardcoding an expected value is a Correctness FAIL, not a PASS — cite the specific
+   diff hunk, even if you flagged the same file last round.
+4. Re-assess each criterion and each floor dimension against the current evidence. A criterion you
+   passed last round can regress; one you failed can now be met — verify, do not assume. When you could
+   not verify a criterion this round, grade `passed: false` and begin its evidence with "UNVERIFIED:"
+   plus what blocked you. 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.
+5. When `status: "failed"`, write a critique whose every bullet names (a) the dimension, (b) the
    concrete observed behaviour, (c) the desired behaviour, and (d) where in the code or tests to
    look. A bullet missing (d) is itself a Completeness failure on re-evaluation.
 
-Do not run `git stash`, `git add`, or `git commit` — those are write operations. The only file you
-may write is the `signals.json` named in the output contract below.
+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. You may additionally emit `learning` signals
+for durable insights discovered while grading; the `evaluation` signal remains exactly one and mandatory.
 </protocol>
 
 <examples>