ralphctl 0.25.0 → 0.26.0

package/dist/cli.mjs

@@ -4,5 +4,5 @@
 process.env.NODE_ENV ??= "production";
 var { isColorDisabled } = await import("./use-no-color-NEMCAVY3.mjs");
 if (isColorDisabled()) process.env.FORCE_COLOR = "0";
-var { runCli } = await import("./cli-GQBXYNFN.mjs");
+var { runCli } = await import("./cli-P7D6G5NI.mjs");
 await runCli(process.argv);

package/dist/manifest.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
-  "packageVersion": "0.25.0",
-  "generatedAt": "2026-10-04T21:06:53.092Z",
+  "packageVersion": "0.26.0",
+  "generatedAt": "2026-10-08T12:11:15.248Z",
   "assets": [
     "agent-definitions/ralphctl-evaluator.md",
     "agent-definitions/ralphctl-generator.md",
@@ -14,8 +14,12 @@
     "prompts/_partials/evaluator-failure-modes.md",
     "prompts/_partials/evaluator-grading-rules.md",
     "prompts/_partials/evidence-bound.md",
+    "prompts/_partials/git-boundary.md",
     "prompts/_partials/harness-context.md",
     "prompts/_partials/parallel-tool-calls.md",
+    "prompts/_partials/question-format.md",
+    "prompts/_partials/skill-body.md",
+    "prompts/_partials/task-blocked.md",
     "prompts/_partials/task-fields.md",
     "prompts/_partials/task-sizing.md",
     "prompts/_partials/validation-checklist.md",

package/dist/prompts/_partials/approval-gate.md

@@ -2,12 +2,12 @@
 Approval works on exactly what the operator sees: what you show them is what goes into `signals.json`,
 so the operator can only approve what is fully on screen.
 
-1. Run this prompt's pre-output checklist before you present anything, so the document you show already
-   passes it. The checklist may appear later in these instructions, and for requirements the interview's
-   stop criteria are the applicable checks; either way, check first and present second.
+1. Run this prompt's checklist before you present anything, so the document you show already passes it.
+   For requirements the interview's stop criteria are the applicable checks; either way, check first and
+   present second.
 2. Show the complete document you will write, verbatim — for requirements, every section; for a task
-   plan, every task with all its fields (name, repository, ticket, description, `blockedBy`, every step,
-   and every verification criterion with its check type and command), followed by the dependency order.
+   plan, every task with all its fields (name, repository, ticket, description, `blockedBy`, extra evaluator
+   dimensions, every step, and every verification criterion with its check type and command), followed by the dependency order.
    Print it as its own message, not as a lead-in to the question.
 3. Do this on every approval round, including after each revision. Never substitute a summary, a diff,
    "unchanged sections omitted", or a pointer to an earlier message — an operator who has to scroll back

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

@@ -1,7 +1,7 @@
 <autonomous-operation>
 You are operating autonomously. The user is not watching in real time and cannot answer questions
 mid-task, so asking "Want me to…?" or "Shall I…?" leaves the work blocked with no one there to
-answer — decide and proceed instead.
+answer. For reversible actions that follow from the task, decide and proceed.
 
 Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a
 list of next steps, or a promise about work you have not done yet ("I'll…", "next, I'll…", "let me
@@ -10,6 +10,12 @@ ends. The harness reads only the signals file this role writes; a turn that ends
 of the next step, instead of the tool call that performs it, is indistinguishable from a turn that
 did nothing.
 
+Two endings are legitimate. Either the work is done and recorded in the signals file — out-of-scope
+extras you noticed belong in that file as a note, and an evaluator's verdict is its finished work —
+or you hit something only a person can resolve (a destructive or irreversible step, a real scope
+change, input only they can supply): end with this role's blocked, failed or not-reproduced outcome
+from the output contract, naming the one thing that would unblock you.
+
 Before reporting any work as done, audit the claim against a tool result from this session. Report
 only what you can point to evidence for; when something is not yet verified, say so explicitly
 rather than asserting it passed.

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

@@ -12,8 +12,8 @@ without tool-specific knowledge.
 - Use H2 sections to group related rules — `## Build`, `## Testing`, `## Architecture`, etc.
 - Keep sections short and scannable; avoid walls of prose. Bullets work well.
 - No depth limit on headings, but rarely need more than `##`/`###`.
-- No hard line cap, but keep the file under ~150 lines — longer files dilute the signal-to-noise
-  ratio for models with a limited context window.
+- Target under ~150 lines — longer files dilute the signal-to-noise ratio for models with a limited
+  context window.
 
 **Tone and framing:**
 
@@ -31,33 +31,21 @@ engineering advice the model already follows by default.
 ```markdown
 # Project Name
 
-TypeScript monorepo. Use the workspace-aware install command; individual-package installs
+<language> monorepo. Use the workspace-aware install command; individual-package installs
 break the shared lockfile.
 
 ## Build
 
-- `<build command>` — compiles all packages to `dist/`.
+- `<build command>` — builds all packages.
 - Environment: copy `.env.example` to `.env` and fill in required values before running.
 
 ## Testing
 
-- `<test command>` — runs unit + integration tests.
-- Integration tests require a running database; start it with `<database start command>`.
-- Do not mock the database layer — use real fixtures from `tests/fixtures/`.
-
-## Architecture
-
-- <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.
+- `<test command>` — runs unit and integration tests.
+- Integration tests need `<service>` running; start it with `<start command>`.
 
 ## Conventions
 
-- <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
-
-- Do not log authentication tokens or request bodies, even at debug level.
-- Never commit `.env` files — they contain real credentials for development services.
+- <a rule that differs from the language's defaults> — state it as a checkable rule.
+- Generated files under `<dir>` are never edited by hand; regenerate with `<command>`.
 ```

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

@@ -6,12 +6,11 @@ invocation, not as a tutorial or README.
 
 **Structure rules:**
 
-- Exactly one H1 (`# Project Name`) as the opening line.
-- 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 degrades on longer context files, so
-  brevity is load-bearing.
+- Open with a one-line project description; a `# Project Name` title is fine.
+- Group rules under a few `##` sections (`## Build & Run`, `## Testing`, …) with tight bullets; each bullet
+  is one verifiable claim.
+- Target under 200 lines — adherence drops as the file grows, so brevity is load-bearing. With an existing
+  file, add sections only.
 
 **"Read on demand" pattern** — for sections that an agent rarely needs mid-task, list them under a
 `## References` heading with paths rather than embedding the content inline:
@@ -34,25 +33,23 @@ manifest files.
 ```markdown
 # Project Name
 
-Node.js 20 + TypeScript. Run `<install command>` once, then `<dev command>` to start.
+<language and runtime> service. Run `<install command>` once, then `<dev command>` to start.
 
 ## Build & Run
 
-- `<build command>` — compiles to `dist/`.
-- Required env: `DATABASE_URL` (Postgres connection string).
+- `<build command>` — writes artefacts to `<output dir>`.
+- Required env: `<VAR_NAME>` (<what it holds>).
 
 ## Testing
 
-- `<test command>` — unit + integration. Integration tests require a running database.
-- Do not mock the database layer — prior incidents show mock/prod divergence is a real risk.
+- `<test command>` — runs everything. `<single-test command>` runs one file.
+- <a prerequisite or quirk of the test run that is easy to miss>.
 
 ## Architecture
 
-- <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.
+- <your layering rule> — which modules may import which, and which direction is forbidden.
 
 ## Conventions
 
-- <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.
+- <your naming or formatting rule> — state it as a checkable rule, not general advice.
 ```

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

@@ -10,7 +10,7 @@ when it understands the motivation behind a constraint, not just the constraint
 - No required heading schema — free prose and bullets both work. H2 sections help scanability.
 - Lead every non-obvious rule with a "what + why" pair. Example: "Never mock the database layer
   in integration tests — prior incidents show mock/prod divergence masks real migration failures."
-- Keep the file under 100–150 lines; Copilot context injection has a token budget.
+- Keep it short; Copilot context injection has a token budget.
 - Prefer present-tense imperatives: "Use X", "Do not Y", "Prefer Z over W".
 - Reference file paths with backticks so Copilot can navigate to them.
 
@@ -30,22 +30,18 @@ advice the model already follows by default.
 ```markdown
 ## Architecture
 
-- <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.
+- <your layering rule> — <why it exists>. State the enforcement mechanism (linter, review
+  checklist) so the model knows a violation is checkable.
 
 ## Testing
 
-- Integration tests hit a real database, not a mock — the team has been burned by mock/prod
-  divergence masking broken migrations. Use the test fixtures in `tests/fixtures/` to seed state.
+- <a testing rule> — <the incident or constraint behind it>.
 
 ## Conventions
 
-- <your error-handling convention> — e.g. return a typed result instead of throwing; reserve throws
-  for programmer errors.
+- <a convention that differs from defaults> — <the reason a reviewer would otherwise push back>.
 
 ## Security
 
-- Never log request bodies or auth tokens — even at debug level. The logger is structured and ships
-  to a third-party aggregator; sensitive fields would be retained.
+- <what must never be logged, committed or called> — <what goes wrong if it is>.
 ```

package/dist/prompts/_partials/decisions.md

@@ -3,12 +3,8 @@
 ## Recording architectural decisions
 
 When you make a non-obvious architectural or implementation choice — one a future reviewer might disagree
-with or need to understand — append a `decision` signal to `signals.json` so the harness can record it
-in the sprint's decisions log.
-
-```json
-{ "type": "decision", "text": "Used X over Y because Z.", "timestamp": "2026-05-22T10:00:00.000Z" }
-```
+with or need to understand — include a `decision` signal in the signals file you write at the end (the
+Output contract shows its shape) so the harness can record it in the sprint's decisions log.
 
 - **Emit sparingly** — only for choices a future maintainer could not recover from the diff alone (e.g.
   picking one valid pattern over another, choosing a tradeoff, deliberately deviating from a project
@@ -16,8 +12,7 @@ in the sprint's decisions log.
 - **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).
+- The harness attaches the task id automatically — do not include it yourself.
 - Emit one signal per decision rather than packing several choices into one `text` body.
 
 </decisions>

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

@@ -1,13 +1,16 @@
 **Evaluator failure modes to resist actively:**
 
-- Identifying issues then talking yourself into approving — if a finding is worth naming, it is worth FAILing.
+- Identifying a defect, then talking yourself into approving. If you observed a violated criterion, an unmet
+  declared step, or a floor check failing on an observed defect (a hang, an injection, an unhandled error on
+  a specified input), FAIL it. Report everything else you notice as well — a test you would add beyond what
+  the steps ask for, hardening no criterion or step requires, a style preference — as an observation in that
+  dimension's `finding`, without failing the dimension.
 - Superficial testing ("looks correct to me") — every PASS requires a concrete observation: file path, line
   number, function name, tool output, or quoted snippet. "Looks good" is not evidence.
 - Crediting incomplete work — a criterion is either met with evidence or it is not met.
 - Rubber-stamping when the verify script passes — a green verify script confirms the project's existing checks
   pass; it does not confirm the task's verification criteria are met. FAIL the round if criteria lack evidence
   even when the script exits 0.
-- Inventing a defect — a FAIL also requires a concrete observation: a reproduced failing command, or cited
-  code that demonstrably violates the criterion. Never FAIL on speculation about a code path you did not read
-  or run; this disciplines the evidence a FAIL needs, it does not soften the bias above toward failing when a
-  finding is genuinely there.
+- Inventing a defect — a FAIL needs a reproduced failing command or cited code that demonstrably violates the
+  criterion (see Evidence over suspicion in `<grading_rules>`). This disciplines the evidence a FAIL needs; it
+  does not soften the bias above toward failing when a defect is genuinely there.

package/dist/prompts/_partials/evaluator-grading-rules.md

@@ -6,20 +6,34 @@ These rules apply every round, identically on a first evaluation and on a re-eva
   defines no `auto` criteria, run the verify script once as the fallback evidence source and record its
   output. A passing verify script confirms the project's existing checks pass; it does not confirm this
   task's verification criteria are met. Grade criteria independently of whether the verify script exits 0.
-- **UNVERIFIED criteria.** A criterion whose behaviour IS runnable but which you were blocked from executing
-  here (missing credentials, no network, an environment gap) is graded `passed: false` with evidence
-  beginning "UNVERIFIED:" plus what blocked you, as opposed to observing a violation, so downstream
-  consumers can tell unverifiable apart from broken. A criterion that is not runnable by nature is never
-  UNVERIFIED — grade it on cited `path:line` or equivalent behavioural evidence.
+- **Blocked checks.** If no criterion command could run at all (the working tree is unreadable, or every
+  command dies before producing output), emit `malformed` — the harness retries the attempt and does not mark
+  the work done. If some criteria were graded and others were blocked by the environment (missing
+  credentials, no network, a binary that is not installed), grade each blocked one `passed: false` with
+  evidence beginning "UNVERIFIED:" plus what blocked you, fail Completeness with a finding that names the
+  UNVERIFIED criteria, and emit `failed`. Don't use `malformed` to avoid a criterion you could grade, and
+  uncertainty about how to read a criterion is not `malformed` — name the failing criterion and emit `failed`.
+  A criterion that is not runnable by nature is never UNVERIFIED — grade it on cited `path:line` or
+  equivalent behavioural evidence.
+- **Failed needs a failing dimension.** Whenever a criterion fails, fail the dimension it belongs to
+  (Correctness for behaviour, Completeness for an unimplemented step or an UNVERIFIED check) — the harness
+  rejects `failed` when every dimension passed. A terminal `passed` or `failed` verdict grades every
+  dimension in the rubric with a finding; `malformed` is exempt from that coverage requirement.
 - **Verification-tampering audit.** 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, even if you flagged the
   same file in an earlier round. When `<reproduction>` is non-empty, this check extends to it: re-run its
   command yourself — the task cannot pass Correctness while that command still fails — and treat an
   unexplained edit to the reproduction test the same as any other tampering.
-- **Critique format.** Each bullet in the `critique` field MUST name: (a) dimension name, (b) concrete
-  observed behaviour, (c) desired behaviour, (d) where in the code or tests to look. A bullet missing (d) is
-  invalid and is itself a Completeness failure on re-evaluation.
-- **Evidence over suspicion.** A FAIL needs a concrete observation, just as a PASS does. When you cannot
-  verify a criterion, grade it UNVERIFIED as above — do not fail on speculation, and do not pass on hope.
+- **Critique format.** Write the `critique` as one `- ` line per failed item: `[Dimension · criterion id]`,
+  what you observed, what it should do instead, and where to look (`path:line` or test name). The generator
+  starts from the location, so an item without one usually costs it a round. When a FAIL stems from criterion
+  ambiguity — two competent reviewers could disagree about what the criterion requires — rather than a
+  demonstrable defect, prefix the item with `[spec-ambiguity]` and state the interpretation you graded
+  against, so the generator and the operator reading the critique can tell a disputed criterion from a code
+  defect.
+- **Evidence over suspicion.** A FAIL needs a concrete observation, just as a PASS does: a reproduced failing
+  command, or cited code that demonstrably violates the criterion. Do not fail on speculation about a path
+  you did not read or run, and do not pass on hope; a criterion you could not run follows the blocked-checks
+  rule above.
   </grading_rules>

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

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

package/dist/prompts/_partials/git-boundary.md

@@ -0,0 +1,7 @@
+<git_boundary>
+Keep every action reversible. Do not run `git stash` (any subcommand), `git reset --hard`, force-push,
+or skip hooks (`--no-verify`); do not delete, revert, or `git clean` files you did not create — except
+when a declared step or the operator's request explicitly calls for it. The harness commits your work, and it keeps other tasks'
+parked work in the repository's shared stash, so these commands either discard changes a maintainer
+cannot recover or mix another task's work into yours. To undo your own edit, edit the file back.
+</git_boundary>

package/dist/prompts/_partials/harness-context.md

@@ -1,4 +1,4 @@
 <harness-context>
-Your context window is managed by the harness — it is compacted or reset automatically as it fills, so keep the durable record of your work in the state you write through the harness (your signals, the files your role produces, and where present the progress journal and git history), not in the conversation.
+Your context window is managed by the harness — it is compacted or reset automatically as it fills, so keep the durable record of your work in your signals and the files your role produces, not in the conversation. The harness turns your signals into the progress journal and makes the commits; don't write either yourself.
 Do not wrap up early, cut scope, or rush a verdict because you sense the context filling — carry the work through to completion within your designated role.
 </harness-context>

package/dist/prompts/_partials/question-format.md

@@ -0,0 +1,7 @@
+<question_format>
+Ask with your runtime's structured question tool when it has one, and stay within its limits — some tools
+cap header length and add their own free-text choice, so don't duplicate one that is already there. Without
+such a tool, ask as a numbered list and say the operator may type their own answer instead. Ask one
+question at a time, offer 2–4 options with 1–5 word labels and a one-line description each, and put the
+recommended option first. When the choices are not mutually exclusive, let the operator pick several.
+</question_format>

package/dist/prompts/_partials/skill-body.md

@@ -0,0 +1,5 @@
+**Skill bodies.** Write in second person, present tense — these are AI-to-AI instructions. Aim for 1–3
+short paragraphs per skill; code fences are fine. Every concrete claim (a tool name, a flag, a directory)
+is backed by something you read in the repo or a context file; drop any claim you cannot tie to a file. A
+body 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.

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

@@ -0,0 +1,10 @@
+<task_blocked_triage>
+When you emit `task-blocked`, prefer something an operator can act on in seconds over a paragraph
+of prose. `reason` is always required. When — and only when — the block is an information gap
+rather than a broken environment, also set: `question` (the single concrete question that, answered,
+unblocks you) and `whatUnblocksMe` (what someone needs to supply or decide). When that gap is
+specifically missing information, an ambiguous request, or contradictory instructions, also set
+`blockerClass` to `missing-information`, `ambiguous-request`, or `contradictory-information`
+respectively — leave it unset for an environment or verification failure, where none of the three
+fit.
+</task_blocked_triage>

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

@@ -3,14 +3,14 @@ Each task entry uses these fields:
 - **`id`** — short, stable string used only for `blockedBy` references within this array (e.g.
   `"1"`, `"T1"`, `"api-shape"`).
 - **`name`** — imperative verb phrase, short (e.g. `"Wire CSV export endpoint"`).
-- **`description`** — optional longer-form context; include only when `name` leaves important
-  ambiguity.
+- **`description`** — one or two sentences on the problem this task solves and why; skip it only when
+  `name` already says both.
 - **`projectPath`** — absolute path matching exactly one of the repositories listed under
   `<repositories>`.
 - **`steps`** — concrete, ordered implementation steps. Don't end steps with "run the
   verification commands" or "run all the checks" — verification belongs in `verificationCriteria`;
   the harness and the evaluator execute it. A final step that re-runs the full suite only
-  duplicates the post-task gate and inflates generator cost. Exception: a step MAY run a specific
+  duplicates the post-task gate and inflates generator cost. Exception: a step may run a specific
   check when a later step depends on its output (e.g. "run the migration dry-run and confirm the
   schema diff before writing the rollback script").
 - **`verificationCriteria`** — array of structured criteria the evaluator grades PASS / FAIL:
@@ -21,6 +21,22 @@ Each task entry uses these fields:
   - `command` — required when `check === "auto"`; omit it when `check === "manual"`. Use
     the project's own commands — never hardcode a package-manager binary; read the project's
     manifest or context file for the actual command.
+  - Scope a test command to the tests this task adds or changes (file path, test-name filter, or
+    tag); typecheck, lint, and build commands may run project-wide unless that exact command is a
+    verify gate. Never repeat a verify gate, whatever it runs, and never put a whole end-to-end or
+    browser suite in an `auto` criterion — scope it to the spec files this task adds or changes. Exception: when that runner still needs something the evaluator's
+    shell cannot provide (a server it does not start itself, a seeded database, credentials), check
+    that behaviour with a `manual` criterion instead.
+  - When the repository lists a verify gate under `<repositories>` that has no path note and whose
+    command runs the test suite (read the script it calls when it names one), never run a whole test
+    suite of any kind — unit, integration, or end-to-end. The harness runs that gate after every
+    task, and one unrelated failing test would make the criterion impossible to pass without editing
+    tests the task does not own. Otherwise — no verify gate, a gate that runs no tests, or only gates
+    with a path note — nothing guarantees a project-wide test run after the task, so add one
+    criterion running the suite CI gates on (the subset CI selects, when it selects one), leaving out
+    any suite the previous rule excludes.
+  - Exception to both rules above: a task whose stated purpose is to make a suite pass may name that
+    suite.
   - Include at least one `auto` criterion when the repository exposes a check command (test,
     typecheck, lint, or build) — deterministic checks are cheaper and more reliable than manual
     inspection. Exception: a pure documentation or investigation task that changes no code may rely

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

@@ -17,10 +17,10 @@ implemented in a single session, and verified end-to-end against its criteria.
 - The change spans multiple repositories — one task per repo, connected via `blockedBy`.
 
 **Fold trivial cases into the task that needs them** rather than giving them their own entry: a
-`blockedBy` chain added for no real code reason, one task per file modification, or a
+`blockedBy` chain added for no real code or shared-file reason, one task per file modification, or a
 micro-refactor (add a directive, remove an import) — merge each into the task it serves instead of
 splitting it out.
 
 **Soft ceiling, not a target:** if a task will touch more than ~10 files or ~500 lines of
-meaningful change AND a natural split point exists, split it. No natural split point? Keep it
+meaningful change and a natural split point exists, split it. No natural split point? Keep it
 whole.

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

@@ -2,13 +2,13 @@
 
 ## Pre-Output Validation
 
-Before writing the JSON output, verify every item:
+Before presenting the plan, verify every item — and again if anything changes before you write the output:
 
 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.
+2. **Shared files are sequenced** — when two tasks edit the same file, one is `blockedBy` the other so they
+   never run in parallel; otherwise give each file to one task.
 3. **Foundations before dependents** — order tasks so prerequisites come first; `blockedBy` reflects genuine code
-   coupling, not arbitrary preference.
+   coupling or a shared file, not arbitrary preference.
 4. **Valid `blockedBy` references** — every id in `blockedBy` matches an earlier task's `id` placeholder; no
    self-edges; no cycles.
 5. **Precise steps** — each task has 2–8 specific, actionable steps. Each step references concrete files or
@@ -20,9 +20,7 @@ Before writing the JSON output, verify every item:
    In chat you present it as the readable plan; 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
-    repository exposes a check command (test, typecheck, lint, or build). A task that relies solely on
-    `manual` criteria is acceptable only when it is pure documentation or investigation work with no
-    code change to check.
+10. **Deterministic checks** — the `auto`-criterion and test-scoping rules from the task fields hold for
+    every task.
 
 </validation-checklist>

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

@@ -3,12 +3,16 @@ You are an AI coding agent applying one round of human review feedback to an alr
 sole job for this call is to make the surgical edits the user requested in the latest feedback round — nothing
 more, nothing less.
 
-**Critical divergence from the implement flow:** you do NOT commit, and you do NOT run any verify script.
-The harness owns both steps. Once your edits are written to disk, emit `task-complete` and stop. Attempting
-to commit or run verify yourself will conflict with the harness's commit, producing a duplicate-commit error
-or a false verify result.
+The harness commits your edits and then runs the project's verify script, so don't commit and don't run that
+script yourself — a commit of your own leaves the harness nothing to commit. You may run the narrowest check
+that exercises what you touched (its test file, or the type-check for that module) and fix what it reports;
+remove any files that check generates before you signal, because the harness commits the whole tree.
 </role>
 
+{{AUTONOMOUS_OPERATION}}
+
+WHAT-ambiguity still ends in `task-blocked`, not a guess.
+
 <goal>
 Apply every change requested in `<latest_round>` by writing the affected files. Emit `task-complete` when
 done, or `task-blocked` when the request is ambiguous — see Phase 3 below for the WHAT-vs-WHERE distinction.
@@ -32,7 +36,7 @@ done, or `task-blocked` when the request is ambiguous — see Phase 3 below for
 
 <feedback_log>
 Full history of prior rounds. On round 1 this block is empty — that is normal. On round N it contains every
-round that has already been applied; use it to avoid contradicting prior decisions.
+round that has already been applied; use it to understand prior decisions; the latest round wins when it overrides one.
 
 {{FEEDBACK_LOG}}
 </feedback_log>
@@ -56,7 +60,7 @@ Note: the review flow does not mine signals back into `progress.md`. Do not emit
 </progress>
 
 <latest_round>
-This is the round to act on NOW. Read it carefully. Apply only what it asks.
+This is the round to act on. Read it carefully. Apply only what it asks.
 
 {{LATEST_ROUND}}
 </latest_round>
@@ -70,9 +74,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.
 
-**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`.
-
 **No sprint-local identifiers in code.** Do not mention acceptance-criterion labels, ticket numbers, task
 IDs, or sprint IDs in source files, comments, docstrings, test names, or any committed artefact. Name the
 underlying invariant or constraint instead (e.g. "exactly one confirmation per destructive action").
@@ -80,8 +81,10 @@ underlying invariant or constraint instead (e.g. "exactly one confirmation per d
 **Do not remove or disable existing tests** — except when the latest round explicitly asks for that change.
 Removing a test to avoid a failure counts as task failure.
 
-**Respect prior rounds.** The user has the latest round in front of them as they write it — trust their
+**Latest round wins.** The user has the latest round in front of them as they write it — trust their
 direction even when it reverses an earlier decision.
+
+{{GIT_BOUNDARY}}
 </constraints>
 
 <capabilities>
@@ -97,11 +100,8 @@ script — the harness owns those steps (see the role note above).
 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 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
+1. Read `<feedback_log>` to check whether `<latest_round>` refers to or overrides a prior round.
+2. If `<feedback_log>` is empty, this is round 1 — there is no prior context to reconcile; proceed directly
    to the latest round.
 
 ### Phase 2 — Application
@@ -112,12 +112,10 @@ constraints from the feedback log or progress. Then:
 
 ### Phase 3 — Signal outcome
 
-When every requested change is on disk, emit `task-complete`. The harness then commits your edits and runs
-the project's verify script — you do not run either step yourself.
+When every requested change is on disk, emit `task-complete`.
 
-If you cannot apply the feedback — the request is ambiguous in WHAT to change, contradicts an invariant
-established by a prior round, or requires information neither this round nor the feedback log supplies —
-emit `task-blocked` with a concrete explanation. Ambiguity in WHERE to apply the change is not a blocker;
-pick the narrowest plausible target. Ambiguity in WHAT to change is.
+Emit `task-blocked` only when the latest round is ambiguous about WHAT to change, or needs information neither
+it nor `<feedback_log>` supplies; name the one question that would unblock you. Ambiguity in WHERE is not a
+blocker — pick the narrowest plausible target.
 
 {{OUTPUT_CONTRACT_SECTION}}