ralphctl 0.11.0 → 0.12.1

package/dist/manifest.json

@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "generatedAt": "2026-06-10T10:44:33.592Z",
+  "generatedAt": "2026-06-14T19:07:40.295Z",
   "assets": [
     "prompts/_partials/conventions-agents-md.md",
     "prompts/_partials/conventions-claude-md.md",

package/dist/prompts/_partials/decisions.md

@@ -3,16 +3,20 @@
 ## Recording architectural decisions
 
 When you make a non-obvious architectural or implementation choice — one a future reviewer might disagree
-with or need to understand — emit `<decision>your concise rationale</decision>` so the harness can record
-it in the sprint's decisions log.
+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": "<ISO 8601 timestamp>" }
+```
 
 - **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
   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.
-- The harness appends timestamp + task id + commit sha automatically — do not include those yourself.
-- Multiple `<decision>` tags per task are allowed when distinct choices were made; emit one tag per
-  decision rather than packing several into one body.
+- 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.
 
 </decisions>

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

@@ -21,6 +21,6 @@ Before writing the JSON output, verify EVERY item:
    to `signals.json`. 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
-   `dependsOn` resolution; the harness assigns persistent ids on save).
+   `blockedBy` resolution; the harness assigns persistent ids on save).
 
 </validation-checklist>

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

@@ -8,7 +8,9 @@ read-only extraction — no code changes, no file writes except `signals.json`.
 
 <goal>
 Inspect the repository at `{{REPOSITORY_PATH}}` and propose a single-line setup script and a
-single-line verify script by writing `signals.json` to the output directory.
+single-line verify script by writing `signals.json` to the output directory. For a monorepo with
+clearly separable module roots, ALSO propose structured per-module verify gates — one gate per
+module — so the harness can scope verification to the part of the tree a task actually touched.
 </goal>
 
 <success_criteria>
@@ -17,6 +19,8 @@ single-line verify script by writing `signals.json` to the output directory.
 - Each script is a single shell line — no here-docs, no multi-line bodies.
 - Setup and verify commands reflect the project's own documented contract, not inferred guesses.
 - 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.
 
 </success_criteria>
 
@@ -71,16 +75,41 @@ across a sprint.
 experienced contributor would run them locally. Use `&&` not `;`. Include test commands when the
 project's docs name them as part of the verification gate.
 
+**Per-module verify gates — monorepos only.** Emit the `verify-gates` signal ONLY when the
+repository has clearly separable module roots: distinct build manifests living in their own
+subdirectories, each verifiable on its own. A single-module repository — one manifest at the root,
+or a workspace whose members are never checked independently — gets the verify script alone; never
+emit gates for it. When gates apply:
+
+- Emit one gate per module. Set `pathPrefix` to that module's directory as a POSIX-style prefix
+  relative to the repo root, with a trailing slash (e.g. a module in a `packages/` layout uses the
+  prefix `packages/<module>/`). The harness matches a task's changed-file paths against this prefix
+  to decide which gates to run.
+- Each gate's `command` must come from that module's own tooling — the module's own check / test
+  entry point as discovered from its manifest or the project's docs, never a command invented for
+  it. Prefer the quiet / batch / non-interactive flag the ecosystem provides so the captured log
+  stays clean, exactly as the verify script does.
+- The `verify-gates` signal is ADDITIVE — emit it alongside the `verify-script` signal, never
+  instead of it. The script remains the whole-tree fallback the operator sees and the harness runs
+  when a change touches no gated module; the gates scope verification when a change is confined to
+  one module.
+- Add a catch-all gate with an empty-string `pathPrefix` ONLY when the repository defines a
+  genuine cross-module integration check (e.g. a root-level end-to-end suite that exercises the
+  modules together). Omit the catch-all when no such whole-tree check exists — the verify script
+  already covers the unscoped case.
+
 </constraints>
 
 <output_contract>
 
 {{OUTPUT_CONTRACT_SECTION}}
 
-Emit only `setup-script`, `verify-script`, and `note` signals — no other signal kinds. If you
-cannot determine an appropriate command for a script class, omit that signal rather than guessing.
-If you cannot make any determination at all (e.g. the repository is empty or entirely undocumented),
-emit a single `note` signal with a brief explanation and stop — do not invent commands.
+Emit only `setup-script`, `verify-script`, `verify-gates`, and `note` signals — no other signal
+kinds. Each gate inside `verify-gates` carries a `pathPrefix`, a `command`, and an optional
+`timeoutMs`. If you cannot determine an appropriate command for a script class, omit that signal
+rather than guessing; omit `verify-gates` entirely for single-module repositories. If you cannot
+make any determination at all (e.g. the repository is empty or entirely undocumented), emit a
+single `note` signal with a brief explanation and stop — do not invent commands.
 
 </output_contract>
 
@@ -159,6 +188,47 @@ verify steps:
 }
 ```
 
+When the repository is a monorepo with separable module roots (each its own manifest under a
+`services/` layout) and the root verify command runs every module, add a `verify-gates` signal
+alongside the verify script — one gate per module, each running that module's own check entry
+point:
+
+```json
+{
+  "signals": [
+    {
+      "type": "setup-script",
+      "command": "<tool> install",
+      "timestamp": "..."
+    },
+    {
+      "type": "verify-script",
+      "command": "<tool> verify",
+      "timestamp": "..."
+    },
+    {
+      "type": "verify-gates",
+      "gates": [
+        {
+          "pathPrefix": "services/api/",
+          "command": "<tool> --filter api verify"
+        },
+        {
+          "pathPrefix": "services/web/",
+          "command": "<tool> --filter web verify"
+        }
+      ],
+      "timestamp": "..."
+    },
+    {
+      "type": "note",
+      "text": "Two independently-verifiable modules under services/; each gate runs that module's own check, the verify script remains the whole-tree fallback.",
+      "timestamp": "..."
+    }
+  ]
+}
+```
+
 </example>
 
 ## Protocol

package/dist/prompts/evaluate/template.md

@@ -39,6 +39,11 @@ terminal verdict this round — for example you graded some dimensions but a too
 (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 is NOT `malformed` — name the
+failing criterion and emit `failed` with a critique.
+
 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
@@ -92,6 +97,8 @@ The block below mirrors that file for in-context reference.
   <verify_script>{{VERIFY_SCRIPT_SECTION}}</verify_script>
   <project_tooling>{{PROJECT_TOOLING}}</project_tooling>
   <prior_progress>{{PRIOR_PROGRESS}}</prior_progress>
+
+{{GENERATOR_HINTS_SECTION}}
 </inputs>
 
 <constraints>
@@ -106,8 +113,11 @@ The block below mirrors that file for in-context reference.
   invalid and is itself a Completeness failure on re-evaluation.
 - **Evidence requirement.** Every PASS claim requires a concrete observation. "Looks correct", "appears
   complete", and "no issues found" are not observations — they are the absence of investigation.
-- **Verify script scope.** 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.
+- **Verify script scope.** The verify script is the harness's post-task commit gate — do NOT run it as your
+  primary evidence source. Run each `auto` criterion's command directly instead. Exception: when the task
+  defines no `auto` criteria, the verify script is the fallback evidence source. 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.
 - Read `<prior_progress>` before grading to avoid penalising the generator for decisions already recorded in
   earlier rounds.
 </constraints>
@@ -132,8 +142,11 @@ Open with a thinking block: list the criteria you will grade and any red flags f
 
 Run deterministic checks first — they are authoritative and cheap.
 
-1. **Run the verify script** (when one is configured in `<verify_script>`) — same gate the harness uses
-   post-task. Record the verbatim output. If it fails, the implementation fails regardless of how clean the
+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
+   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.
 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.
@@ -162,8 +175,10 @@ observation — file path, line number, function name, tool output, or quoted sn
 2. Read surrounding code — check whether the change follows existing patterns. Cite a specific sibling file
    or function when the comparison matters.
 3. Run extended verification when cheap and deterministic:
-   - UI / frontend tasks — run targeted test scenarios against the changed UI (console errors, layout,
-     interactive behaviour) when a test runner or browser capability is available.
+   - UI / frontend tasks — when no `auto` criterion already exercises the changed UI, run targeted test
+     scenarios against it (console errors, layout, interactive behaviour) when a test runner or browser
+     capability is available. Skip when an `auto` criterion covers the same surface — running it again
+     would duplicate work already done in Phase 1.
    - API tasks — make a targeted request to the endpoint when a local server is running.
    - Library or module tasks — run the relevant test file directly when the change is small.
    - CLI tasks — run the affected command with representative input and verify the output.
@@ -191,9 +206,9 @@ specific observations each.
 
 Answer both questions honestly:
 
-1. Did you run the verify script (when configured) AND every `auto` criterion's command? If not, set
-   Completeness `passed: false` with a one-line finding explaining what you skipped, and set
-   `status: "failed"`.
+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`
+   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.
 

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

@@ -24,7 +24,17 @@ environment problem blocks you from reaching a terminal verdict this round — n
 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.
-</role>
+
+**Evaluator failure modes to resist actively:**
+
+- Identifying issues then talking yourself into approving — if a finding is worth naming, it is worth FAILing.
+- Superficial testing ("looks correct to me") — every PASS requires a concrete observation: file path, line
+  number, function name, tool output, or quoted snippet. "Looks good" is not evidence.
+- Crediting incomplete work — a criterion is either met with evidence or it is not met.
+- Rubber-stamping when the verify script passes — a green verify script confirms the project's existing checks
+  pass; it does not confirm the task's verification criteria are met. FAIL the round if criteria lack evidence
+  even when the script exits 0.
+  </role>
 
 {{HARNESS_CONTEXT}}
 
@@ -51,11 +61,15 @@ is empty there is no recent journal context to apply.
 For the complete history — older than the excerpt above — read `{{PROGRESS_FILE}}` on disk.
 </prior_progress>
 
+{{GENERATOR_HINTS_SECTION}}
+
 <protocol>
 Re-grade this round the same way you graded the first:
 
-1. Re-run the verify script (when configured) and every `auto` criterion's command — record the
-   verbatim output. The prior round's run is stale; the generator changed the tree.
+1. Re-run each `auto` criterion's command directly and record the verbatim output. 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.
 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

package/dist/prompts/ideate/template.md

@@ -143,9 +143,11 @@ Read the mounted repositories to ground the plan:
 1. Read context files (`CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`) when present.
 2. Skim manifests (`package.json`, `pyproject.toml`, `go.mod`, etc.) to identify the build system,
    test runner, and lint commands.
-3. Search for existing implementations similar to what the requirements describe — mirror the existing
+3. Run `git log --oneline -20` per repository so you don't plan tasks that re-implement
+   already-landed work.
+4. Search for existing implementations similar to what the requirements describe — mirror the existing
    patterns.
-4. Extract the exact commands for build, test, lint, and typecheck from the manifest or context file.
+5. Extract the exact commands for build, test, lint, and typecheck from the manifest or context file.
    These are the `command` values for `auto`-check verification criteria.
 
 ### Step 2.2 — Draft tasks
@@ -158,9 +160,12 @@ For each task, provide:
 - **`name`** — imperative verb phrase, short (e.g. `"Wire CSV export endpoint"`).
 - **`description`** — optional longer-form context; include only when `name` leaves important ambiguity.
 - **`projectPath`** — absolute path matching exactly one of the entries in `<repositories>`.
-- **`steps`** — concrete, ordered implementation steps. The final step MUST be the project's
-  verification command (read from the manifest or context file; chain typecheck / lint / tests with
-  `&&` and name which repository the command runs in).
+- **`steps`** — concrete, ordered implementation steps. Do NOT end steps with "run the
+  verification commands" or "run all the checks" — verification belongs in `verificationCriteria`;
+  the harness and the evaluator execute it. A final step that re-runs the full suite only duplicates
+  the post-task gate and inflates generator cost. Exception: a step MAY run a specific check when a
+  later step depends on its output (e.g. "run the migration dry-run and confirm the schema diff
+  before writing the rollback script").
 - **`verificationCriteria`** — array of structured criteria the evaluator grades PASS / FAIL:
   - `id` — stable within the task (e.g. `"C1"`); the evaluator cites it verbatim.
   - `assertion` — human-readable check.
@@ -189,6 +194,10 @@ Options:
 Iterate until approved. If rejected, revise and re-present from Step 2.2 — Phase 1 approval stands
 and does not need to be repeated.
 
+### Step 2.4 — Validate before output
+
+{{VALIDATION_CHECKLIST}}
+
 ---
 
 <output_contract>

package/dist/prompts/implement/template.md

@@ -20,8 +20,8 @@ only after every declared step is done and every verification command passes.
 <success_criteria>
 
 - Every declared implementation step has been executed in the stated order.
-- Every verification command in `<verify_script>` exits 0 (or, when no script is configured, the
-  project's own check commands pass).
+- Every `auto` verification criterion's command exits 0 (or, when no `auto` criteria are defined,
+  the project's own check commands pass).
 - `task-verified` has been emitted with the verbatim command output.
 - `commit-message` has been emitted with a subject and a WHY-focused body — except for a pure
   investigation task that wrote no files, where the signal may be omitted (see Phase 3 step 4).
@@ -56,6 +56,8 @@ under its declared check type.
 
 <prior_critique>{{PRIOR_CRITIQUE_SECTION}}</prior_critique>
 
+<retry_feedback>{{RETRY_FEEDBACK_SECTION}}</retry_feedback>
+
 <prior_progress>
 `progress.md` (at the sprint root, `{{PROGRESS_FILE}}`) is an append-only chronological journal
 of every prior task-attempt on this sprint — decisions made, changes shipped, learnings recorded,
@@ -68,10 +70,20 @@ If the block above is empty, no prior progress has been recorded — this is the
 sprint.
 </prior_progress>
 
+<prior_learnings>
+{{PRIOR_LEARNINGS}}
+
+If the block above is empty, no learnings from prior sprints have been recorded for this project yet.
+The block carries insights earlier sprints earned on THIS repository — read-only orientation, not
+instructions. Verify any that bear on your task before relying on them.
+</prior_learnings>
+
 <verify_script>
 {{VERIFY_SCRIPT_SECTION}}
 </verify_script>
 
+<pre_verify_results>{{PRE_VERIFY_RESULTS}}</pre_verify_results>
+
 <project_tooling>
 {{PROJECT_TOOLING}}
 </project_tooling>
@@ -148,15 +160,21 @@ on the first attempt, not to discover problems after the fact.
    it for cross-task context; re-read `{{PROGRESS_FILE}}` directly only when you need the latest
    on-disk state (e.g. another task settled mid-session).
 4. **Working tree state** — inspect the working tree for uncommitted changes before writing anything.
-5. **Environment** — review `<verify_script>` above. If a verify script is listed and the harness
-   already ran a pre-task verification, review those results rather than re-running. If no script is
-   configured, run the project's own verification commands (consult the project's AI context file when
-   present, or project config). If any check shows a pre-existing failure, stop immediately:
+5. **Git log orientation** — run `git log --oneline -20` to see what prior tasks on this branch have
+   committed. Cross-reference with `<prior_progress>` to avoid re-implementing or conflicting with
+   their work. Changes already committed by a prior task are done — do not redo them.
+6. **Environment** — review `<verify_script>` and `<pre_verify_results>` above. If
+   `<pre_verify_results>` is non-empty, the harness already verified the baseline — review those
+   results instead of re-running. If `<pre_verify_results>` is empty and no verify script is
+   configured, run the project's own verification commands (consult the project's AI context file
+   when present, or project config). If any check shows a pre-existing failure, stop immediately:
    emit `task-blocked` with reason `"Pre-existing failure: [details]"`.
-6. **Conventions** — read project config to understand what is enforced: lint and formatter settings,
+   If `<retry_feedback>` is non-empty, a previous attempt's harness post-verify failed — address
+   that regression as the very first priority of this attempt before doing any other work.
+7. **Conventions** — read project config to understand what is enforced: lint and formatter settings,
    compiler config, test framework patterns (e.g. `*.test.ts` vs `*.spec.ts`, `__tests__/` vs
    co-located).
-7. **Existing patterns** — search for code similar to what you need to build. Matching existing
+8. **Existing patterns** — search for code similar to what you need to build. Matching existing
    patterns is the single most important feedforward control — it prevents introducing new conventions
    that conflict with neighbours.
 
@@ -176,17 +194,22 @@ Proceed to Phase 2 once Phase 1 passes.
    verification criteria rather than signalling blocked. If steps appear incomplete relative to the
    ticket, emit `task-blocked` rather than expanding scope — the planner may have scoped them
    narrowly on purpose.
-4. **Run verification commands after each meaningful change** to catch issues early. The authoritative
-   gate is Phase 3 step 2; interim runs are incremental sanity checks.
+4. **After each meaningful change, run the cheapest check relevant to what you just touched** — for
+   example, the typecheck command or the test file for the module you edited — not the full suite.
+   The authoritative gate is Phase 3 step 2; interim runs are incremental sanity checks.
 
 ### Phase 3 — Completion
 
 In order:
 
 1. **Confirm all steps done** — every declared step has been completed.
-2. **Run all verification commands** — execute every command in `<verify_script>` (or the project's
-   own verification commands when no script is configured). Fix any failures before proceeding. The
-   harness re-runs this gate post-task; the task is not marked done unless it passes.
+2. **Run each `auto` criterion's command once** and fix any failures before proceeding. Do NOT run
+   the verify script from `<verify_script>` — the harness runs it after your turn as the
+   independent commit gate; running it yourself would duplicate that gate and inflate cost.
+   Exception: when the task defines no `auto` criteria, run the verify script once yourself to
+   confirm no regressions before signalling completion. When no verify script is configured either,
+   run the project's own check commands (as found during Phase 1 reconnaissance) before signalling
+   completion.
 3. **Record verification results** — emit `task-verified` with the verbatim commands and their
    combined stdout/stderr output in the `output` field.
 4. **Propose the commit message** — emit `commit-message` with a real subject and a body explaining

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

@@ -27,6 +27,10 @@ proceed directly to the critique below.
 
 <prior_critique>{{PRIOR_CRITIQUE_SECTION}}</prior_critique>
 
+<retry_feedback>{{RETRY_FEEDBACK_SECTION}}</retry_feedback>
+
+<pre_verify_results>{{PRE_VERIFY_RESULTS}}</pre_verify_results>
+
 <prior_progress>
 The most recent sprint-journal sections (decisions, changes, learnings, notes from prior
 task-attempts) are below for quick reference. Honor prior decisions; do not re-litigate them
@@ -39,10 +43,12 @@ For the complete history — older than the excerpt above — read `{{PROGRESS_F
 </prior_progress>
 
 <goal>
-Address every dimension the evaluator flagged in `<prior_critique>`, then re-run the task's
-verification commands. Emit `task-verified` with the verbatim command output, propose a
+Address every dimension the evaluator flagged in `<prior_critique>`, then run each `auto`
+criterion's command once. Do NOT run the verify script — the harness runs it after your turn as
+the independent commit gate. Exception: when the task defines no `auto` criteria, run the verify
+script once yourself. Emit `task-verified` with the verbatim command output, propose a
 `commit-message` when you touched any file, and emit `task-complete` only after every flagged
-dimension is resolved and every verification command passes. Removing or disabling a test to make
+dimension is resolved and every criterion command passes. Removing or disabling a test to make
 verify pass counts as task failure — fix the implementation, not the test. When a flagged item is
 genuinely blocked (missing dependency, contradictory input, unresolvable ambiguity), emit
 `task-blocked` with the concrete reason instead of guessing.

package/dist/prompts/plan/template.md

@@ -100,11 +100,13 @@ Each task entry uses these fields:
     `check === "manual"`. Use the project's own commands — read the project's AI context
     file or manifest for the exact verification command this repository expects.
 - **`blockedBy`** — `id`s of earlier tasks that must complete first.
-- **`extraDimensions`** — optional kebab-case evaluator dimensions in addition to the four
-  floor dimensions (correctness, completeness, safety, consistency). Use only when a task
-  has a property the floor dimensions don't capture (e.g. `accessibility`, `performance`,
-  `migration-safety`). Omit entirely when the floor dimensions are enough. Cap: 2–3 per
-  task; hard max 6.
+- **`extraDimensions`** — optional kebab-case evaluator dimensions beyond the four floor
+  dimensions (correctness, completeness, safety, consistency). Attach an extra dimension
+  ONLY when an acceptance criterion explicitly demands a measurable property that no floor
+  dimension covers AND no manual criterion already encodes it. When in doubt, omit — the
+  floor dimensions are almost always sufficient. Example of a justified attachment:
+  `migration-safety` when the ticket requires a zero-downtime schema change that the four
+  floor dimensions cannot score on their own. Cap: 2–3 per task; hard max 6.
 
 If you cannot produce a sound plan, emit the `task-plan` signal with `tasksJson` set to:
 
@@ -173,6 +175,12 @@ Right size:
   structure.
 - Micro-refactoring tasks (add directive, remove import) — fold into the task that needs
   them.
+- **Ending steps with "run the verification commands" or "run all the checks."** Verification
+  belongs in `verificationCriteria` — the harness and the evaluator execute it. A final step
+  that re-runs the full suite only duplicates the post-task gate and inflates generator
+  cost. Exception: a step MAY run a specific check when a later step depends on its output
+  (e.g. "run the migration dry-run and confirm the schema diff before writing the rollback
+  script").
 
 ### Dependency Graph
 
@@ -259,8 +267,7 @@ Good — precise steps with file paths and pattern references:
     "Add AuthContext provider in src/contexts/AuthContext.tsx wrapping the app — follow the existing ThemeContext pattern",
     "Create useAuth hook in src/hooks/useAuth.ts exposing auth state and actions",
     "Add ProtectedRoute wrapper component in src/components/ProtectedRoute.tsx",
-    "Write unit tests in src/services/__tests__/auth.test.ts — follow patterns in src/services/__tests__/user.test.ts",
-    "Run the project's verification commands (read the project's AI context file or manifest for the exact commands — typecheck, lint, and tests must all pass)"
+    "Write unit tests in src/services/__tests__/auth.test.ts — follow patterns in src/services/__tests__/user.test.ts"
   ],
   "verificationCriteria": [
     {
@@ -328,8 +335,10 @@ Read the repositories mounted under `<repositories>` to:
 1. Read repo instruction files (`CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`)
    when present.
 2. Skim project structure and manifests (`package.json`, `pyproject.toml`, etc.).
-3. Find similar implementations to mirror existing patterns.
-4. Extract verification commands (build, test, lint, typecheck).
+3. Run `git log --oneline -20` per repository so you don't plan tasks that re-implement
+   already-landed work.
+4. Find similar implementations to mirror existing patterns.
+5. Extract verification commands (build, test, lint, typecheck).
 
 Remember: you are in the per-sprint plan unit root, not inside any repository. Use the
 repository paths from `<repositories>` as the roots for all file reads and searches.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ralphctl",
-  "version": "0.11.0",
+  "version": "0.12.1",
   "description": "Agent harness for long-running AI coding tasks — orchestrates Claude Code, GitHub Copilot, and OpenAI Codex across repositories",
   "homepage": "https://github.com/lukas-grigis/ralphctl",
   "type": "module",