ralphctl 0.13.1 → 0.14.0

package/dist/manifest.json

@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "generatedAt": "2026-06-23T21:08:54.874Z",
+  "generatedAt": "2026-07-01T05:14:06.220Z",
   "assets": [
     "prompts/_partials/conventions-agents-md.md",
     "prompts/_partials/conventions-claude-md.md",

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

@@ -1,5 +1,11 @@
 <harness-context>
-Your context window is managed by the harness — when it approaches its limit the session is
-compacted automatically so you can keep working on the task at hand without worrying about the
-token budget. Focus on doing the work correctly within your designated role.
+Your context window is managed by the harness — as it approaches its limit the session is
+compacted or reset automatically. Treat the durable record of your work as the state you write
+through the harness — your signals and the files your role produces, and (where present) the
+progress journal and git history — not the conversation in your context window, which may be
+compacted away. Keep that external state current and accurate as you go, so a fresh session can
+resume from it cleanly.
+
+Do not wrap up early, cut scope, or rush a verdict because you sense the context filling — the
+harness handles compaction; carry the work through to completion within your designated role.
 </harness-context>

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

@@ -99,17 +99,12 @@ commands (e.g. `git status`, `git log`) to orient yourself. You cannot commit or
 those steps. You cannot run the verify script — the harness runs it after your signal.
 </capabilities>
 
-<reasoning>
-Before editing, outline your plan in a `<thinking>` block: restate what the latest round is asking in one or
-two sentences, identify which files you expect to touch, and note any constraints from the feedback log or
-progress that should shape how you apply it. Explicit reasoning produces sharper, more surgical edits.
-</reasoning>
-
 ## Protocol
 
 ### Phase 1 — Reconnaissance
 
-Open with a `<thinking>` block as described in `<reasoning>`. Then:
+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.

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

@@ -21,6 +21,10 @@ 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.
 
 </success_criteria>
 
@@ -235,7 +239,7 @@ point:
 
 ### Phase 1 — Inspection
 
-Open with a `<thinking>...</thinking>` block. Cover, in order:
+Before writing any output, cover, in order:
 
 1. The coding-agent context files you found and the commands they explicitly name. These are your
    primary evidence source — list them before anything else.
@@ -244,8 +248,14 @@ Open with a `<thinking>...</thinking>` block. Cover, in order:
 3. The shape of the repo: single-stack, single-language monorepo, or polyglot monorepo. For
    polyglot layouts, name each sub-tree's path and toolchain.
 4. The candidate setup / verify commands, each with the file that documents it.
+5. The candidate run command — the command that starts the product in a running state for
+   interactive or end-to-end use (for example, a dev-server start script, an application
+   entry point, or an integration / smoke test runner). A run command is distinct from the
+   verify script: the verify script confirms correctness after a change; a run command starts
+   the live product so it can be exercised as a real user would. List the command and the file
+   that documents it.
 
-The harness strips thinking blocks before persisting; explicit reasoning produces sharper proposals.
+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.
@@ -257,6 +267,11 @@ both name the same command, the context file wins (it's deliberate author intent
 script, prefer chaining the project's own task scripts over re-spelling the underlying tools — the
 project's scripts are the documented contract.
 
+When a run command was found in Phase 1 step 5, document it in a `note` signal: include the exact
+invocation, what it starts (dev server at which port, CLI binary, or e2e suite), and any
+environment prerequisite the project's own files declare. Omit the note when the project's files
+name no run command — do not fabricate one from inference.
+
 ### Phase 3 — Output
 
 Write `signals.json` to the output directory as described in `<output_contract>` above.

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

@@ -25,7 +25,7 @@ covers that responsibility for this repo.
 
 <inputs>
 <repository_path>{{REPOSITORY_PATH}}</repository_path>
-<skills_convention>{{SKILLS_CONVENTION}}</skills_convention>
+<skills_convention>See the full skills convention in the constraints section below.</skills_convention>
 </inputs>
 
 {{HARNESS_CONTEXT}}
@@ -87,7 +87,7 @@ know how to read its output and diagnose failures.
 
 <inspection_protocol>
 
-Open with a `<thinking>` block. Cover, in order:
+Before drafting, cover, in order:
 
 1. Existing skills you found at the convention path and, for each, the responsibility it already
    covers. State explicitly whether the setup or verify intent is already taken. When no existing

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

@@ -7,7 +7,7 @@ Your job is to integrate them cleanly, not to invent new ones.
 </role>
 
 <goal>
-Update `{{TARGET_FILENAME}}` so that it carries an up-to-date `## Learnings (ralphctl)` section containing
+Update `{{TARGET_FILENAME}}` so that it carries an up-to-date `## {{LEARNINGS_SECTION_HEADING}}` section containing
 the candidate learnings below — folded in idempotently, preserving everything else in the file verbatim.
 </goal>
 
@@ -26,15 +26,15 @@ the candidate learnings below — folded in idempotently, preserving everything
 {{HARNESS_CONTEXT}}
 
 <owned_section>
-You own exactly one section of `{{TARGET_FILENAME}}` — the one headed `## Learnings (ralphctl)`. This is
+You own exactly one section of `{{TARGET_FILENAME}}` — the one headed `## {{LEARNINGS_SECTION_HEADING}}`. This is
 the only part of the file you may add, reorder, or rewrite. Everything outside that section is
 hand-authored or owned by another tool — preserve it byte-for-byte.
 
-- When the file already contains a `## Learnings (ralphctl)` section, treat its current bullets as the
+- When the file already contains a `## {{LEARNINGS_SECTION_HEADING}}` section, treat its current bullets as the
   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.
-- Never create a second `## Learnings (ralphctl)` section — there must be exactly one.
+- Never create a second `## {{LEARNINGS_SECTION_HEADING}}` section — there must be exactly one.
   </owned_section>
 
 <idempotency_rule>
@@ -87,7 +87,7 @@ as "when present"; many repositories do not have one, and a learning must not as
 
 <output_contract>
 
-1. Read the existing context file body above and locate the `## Learnings (ralphctl)` section, if any.
+1. Read the existing context file body above and locate the `## {{LEARNINGS_SECTION_HEADING}}` section, if any.
 2. Reconcile the candidate learnings against the owned section per the idempotency rule.
 3. Write the COMPLETE, updated `{{TARGET_FILENAME}}` back to disk at its original path — the full file, not
    a diff and not only the section. Everything outside the owned section must be unchanged.

package/dist/prompts/evaluate/template.md

@@ -72,6 +72,10 @@ output contract section at the bottom of this prompt.
 - Every `auto` criterion in `<task_specification>` run via shell command; verbatim output in
   `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
+  per-criterion checklist, not only prose. This is in ADDITION to the floor `dimensions`, not a
+  replacement.
 - A FAIL on any dimension or criterion sets `status: "failed"`.
 - The critique (when `status: "failed"`) names each failed item using the (a/b/c/d) format defined in
   `<constraints>`.
@@ -92,6 +96,13 @@ The block below mirrors that file for in-context reference.
 
 </task_specification>
 
+<evaluation_discipline>
+Before writing `signals.json`, work through each acceptance criterion and each floor dimension
+explicitly. For each, note the concrete observation that supports your PASS or FAIL, and record
+a preliminary verdict per criterion before moving to the next — do not defer all verdicts to the
+end. The final `signals.json` is the only machine-readable output and must come last.
+</evaluation_discipline>
+
 <inputs>
   <project_path>{{PROJECT_PATH}}</project_path>
   <verify_script>{{VERIFY_SCRIPT_SECTION}}</verify_script>
@@ -128,12 +139,6 @@ commands (to execute the verify script, run test files, check git status, inspec
 may write is `signals.json` under the harness output directory.
 </capabilities>
 
-<reasoning>
-Use a thinking block when weighing multiple criteria or dimensions simultaneously. Skip it for straightforward
-single-criterion checks. Structure your thinking as: (1) list the criteria you will grade, (2) note red flags
-from the task description, (3) plan which shell commands to run first.
-</reasoning>
-
 ## Review protocol
 
 ### Phase 0 — Checkpoint write (do this first, before any verification)
@@ -171,7 +176,7 @@ Write this file, then proceed to Phase 1.
 
 ### Phase 1 — Computational verification
 
-Open with a thinking block: list the criteria you will grade and any red flags from the task description.
+Before running any checks, list the criteria you will grade and any red flags from the task description.
 
 Run deterministic checks first — they are authoritative and cheap.
 
@@ -199,6 +204,12 @@ For every criterion in the contract:
 
 Grade each criterion PASS or FAIL — no middle ground. Any single criterion FAIL forces `status: "failed"`.
 
+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.
+
 ### Phase 3 — Inferential investigation
 
 Apply semantic judgment to what the computational checks cannot catch. Every finding MUST trace to a concrete
@@ -207,16 +218,31 @@ observation — file path, line number, function name, tool output, or quoted sn
 1. Read the changed files in full — understand the implementation, not just the diff.
 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 — 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.
+3. Run end-to-end verification against the running product when a capability is declared. Check
+   `<project_tooling>` for a run-path — a dev-server start command, application entry point, CLI
+   invocation, or end-to-end / smoke suite. Note that `<project_tooling>` and any generator-provided
+   hints give you CONTEXT about where to look — they are never a substitute for your own direct
+   observation; the information they carry is unverified until you exercise the path yourself.
+
+   **When a run-path is declared in `<project_tooling>`**, you MUST exercise the changed behaviour
+   directly before settling your verdict:
+   - **Web app or UI**: start the server, navigate to the changed path, and record what you
+     observed. Skip when an `auto` criterion in Phase 1 already covered the same path.
+   - **CLI tool**: invoke the affected command with representative input and record the exact
+     output.
+   - **Service or API**: call the affected endpoint when a local server is running; inspect and
+     record the response.
+   - **E2E or smoke suite**: run it when declared in `<project_tooling>` and confirm it reaches
+     the changed behaviour path.
+     Cite the run command and verbatim observation as evidence in the Correctness dimension finding.
+     Absence of a run observation when a run-path was declared is a Completeness failure.
+
+   **When `<project_tooling>` carries no runnable-product capability** (a library, a pure type or
+   schema package, or only static analysis tooling listed):
    - 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.
-   - Skip only when the project has no runnable verification tooling or the task is purely structural (types,
-     schemas, config).
+   - Structural tasks (types, schemas, config only) — skip; Phase 1 and Phase 2 checks are
+     sufficient evidence.
 
 ### Phase 4 — Dimension assessment
 
@@ -312,6 +338,10 @@ Signals:
           "finding": "follows existing endpoint patterns in src/routes/; uses the shared error format from src/lib/errors.ts"
         }
       ],
+      "criteria": [
+        { "id": "C1", "passed": true, "evidence": "test command exited 0 — 12/12 green" },
+        { "id": "C2", "passed": true, "evidence": "returns 400 at src/routes/exports.ts:42" }
+      ],
       "timestamp": "2026-01-01T00:00:00.000Z"
     }
   ]
@@ -391,6 +421,14 @@ Signals:
           "finding": "controller structure follows existing patterns; pagination helper used correctly"
         }
       ],
+      "criteria": [
+        { "id": "C1", "passed": true, "evidence": "test command exited 0 — 8/8 green" },
+        {
+          "id": "C2",
+          "passed": false,
+          "evidence": "src/controllers/users.ts:47 returns 500 on non-numeric page (expected 400)"
+        }
+      ],
       "critique": "[Correctness · C2] (a) correctness, (b) parseInt(page) at src/controllers/users.ts:47 returns NaN for non-numeric input causing 500, (c) validate page before use so invalid input returns 400, (d) src/controllers/users.ts:47. [Safety] (a) safety, (b) WHERE name LIKE '%${query}%' at src/repositories/users.ts:23 interpolates user input into SQL, (c) use a parameterised query, (d) src/repositories/users.ts:23.",
       "timestamp": "2026-01-01T00:00:00.000Z"
     }

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

@@ -63,17 +63,43 @@ For the complete history — older than the excerpt above — read `{{PROGRESS_F
 
 {{GENERATOR_HINTS_SECTION}}
 
+<evaluation_discipline>
+Before writing `signals.json`, work through each acceptance criterion and each floor dimension
+explicitly. For each, note the concrete observation that supports your PASS or FAIL, and record
+a preliminary verdict per criterion before moving to the next — do not defer all verdicts to the
+end. The final `signals.json` is the only machine-readable output and must come last.
+</evaluation_discipline>
+
 <protocol>
 **Checkpoint write — do this first, before re-grading**
 
-If you have not already written a checkpoint `signals.json` for this round, write one now before
-continuing. Use `status: "failed"`, all four floor dimensions present, each set to
-`passed: false` with `finding: "assessment in progress"`. Use the path named in the output
+If you have not already written a checkpoint `signals.json` for this round, write an `evaluation`
+signal now before continuing. Use `status: "failed"`, all four floor dimensions present, each set
+to `passed: false` with `finding: "assessment in progress"`. Use the path named in the output
 contract section at the bottom of this prompt. This placeholder is valid against the schema the
 harness validates — it ensures a recoverable file exists on disk if this session exhausts its
 token budget before you reach your final verdict. You will overwrite it after completing all steps
 below.
 
+```json
+{
+  "schemaVersion": 1,
+  "signals": [
+    {
+      "type": "evaluation",
+      "status": "failed",
+      "dimensions": [
+        { "dimension": "correctness", "passed": false, "finding": "assessment in progress" },
+        { "dimension": "completeness", "passed": false, "finding": "assessment in progress" },
+        { "dimension": "safety", "passed": false, "finding": "assessment in progress" },
+        { "dimension": "consistency", "passed": false, "finding": "assessment in progress" }
+      ],
+      "timestamp": "<ISO-8601 timestamp>"
+    }
+  ]
+}
+```
+
 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
@@ -83,7 +109,10 @@ Re-grade this round the same way you graded the first:
 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.
+   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
    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.

package/dist/prompts/ideate/template.md

@@ -83,8 +83,8 @@ Focus: clarify WHAT needs to be built. Implementation-agnostic — no repo explo
 
 ### Step 1.0 — Think first
 
-Before interviewing: write a `<thinking>` block surfacing what the idea makes clear vs what it leaves
-ambiguous. Work through these dimensions before formulating questions:
+Before interviewing: work through what the idea makes clear vs what it leaves ambiguous. Cover these
+dimensions before formulating questions:
 
 - Problem statement and affected users
 - Functional behaviour observable as user-visible outcomes
@@ -132,9 +132,9 @@ Begin only after Phase 1 approval is confirmed.
 
 ### Step 2.0 — Think first
 
-Write a `<thinking>` block. Map the approved requirements onto the repositories. Identify task
-boundaries, dependencies, and risks before exploring. Think about: which repo owns each concern,
-what ordering is forced by dependencies, and what the riskiest unknowns are.
+Map the approved requirements onto the repositories. Identify task boundaries, dependencies, and
+risks before exploring. Work through: which repo owns each concern, what ordering is forced by
+dependencies, and what the riskiest unknowns are.
 
 ### Step 2.1 — Explore repositories
 

package/dist/prompts/implement/template.md

@@ -11,6 +11,8 @@ lifecycle and context compaction.
 
 {{HARNESS_CONTEXT}}
 
+{{PRIOR_EPISODES}}
+
 <goal>
 Complete every declared implementation step for the task defined below. Write `signals.json` to the
 path specified in the Output contract section at the bottom of this prompt. Emit `task-complete`
@@ -22,9 +24,10 @@ only after every declared step is done and every verification command passes.
 - Every declared implementation step has been executed in the stated order.
 - 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.
+- `task-verified` has been emitted with the verbatim command output and, when a run-path was
+  exercised in step 3, the direct end-to-end observation.
 - `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).
+  investigation task that wrote no files, where the signal may be omitted (see Phase 3 step 5).
 - `task-complete` has been emitted.
 - No test has been removed or disabled to achieve a passing verify run.
 - No file outside the declared implementation steps has been modified — except for the project's
@@ -74,8 +77,11 @@ sprint.
 {{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.
+The block carries two kinds of content earned on THIS repository. Observed insights are read-only
+orientation — not instructions; verify any that bear on your task before relying on them.
+Architectural decisions are deliberate choices made in prior sprints; honor them and do not
+re-litigate them without emitting a `decision` signal that explains why the prior choice is being
+revisited.
 </prior_learnings>
 
 <verify_script>
@@ -133,29 +139,23 @@ create files under the project path. Write `signals.json` to the output director
 `<output_contract>`.
 </capabilities>
 
-<reasoning>
-Use a `<thinking>` block when: opening Phase 1 (walk declared steps + risks); deciding between
-competing implementation approaches; or weighing whether a pre-existing failure is your fault.
-Respond directly for routine file edits and command runs — do not pad short actions with thinking.
-</reasoning>
-
 ## Protocol
 
 ### Phase 1 — Reconnaissance
 
-Open with a `<thinking>` block: walk through the prior critique (if any), the declared steps, the
+Before starting Phase 1, work through the prior critique (if any), the declared steps, the
 verification criteria, and risks you can already see (file conflicts, ambiguous scope, edges the
 steps do not cover). Addressing the prior critique's dimensions comes before any new implementation
-work.
+work. Proceed directly for routine file edits and command runs.
 
 Then perform these checks before writing any code. The goal is to steer the implementation correctly
 on the first attempt, not to discover problems after the fact.
 
 1. **Confirm your working directory** — verify you are in the expected project path (`{{PROJECT_PATH}}`).
-2. **Prior critique first (rounds 2+)** — if `<prior_critique>` above is non-empty, list each
-   failed dimension in your `<thinking>` block and plan how you will address it before starting new
-   work. If this task was escalated to a stronger model, the prior critique identifies exactly what
-   the previous model missed — address those dimensions specifically.
+2. **Prior critique first (rounds 2+)** — if `<prior_critique>` above is non-empty, work through
+   each failed dimension and plan how you will address it before starting new work. If this task
+   was escalated to a stronger model, the prior critique identifies exactly what the previous model
+   missed — address those dimensions specifically.
 3. **Prior progress** — the `<prior_progress>` block above carries the journal body in-context. Read
    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).
@@ -210,14 +210,39 @@ In order:
    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
+3. **End-to-end exercise — required when a run-path exists.** Before recording verification
+   results, check `<project_tooling>` for a way to start or invoke the product: a dev-server
+   start command, application entry point, CLI invocation, or end-to-end / smoke suite. Consult
+   the project's AI context files (when present) for additional run instructions. When a run-path is
+   present, start the product and exercise the changed behaviour AS A USER:
+
+   - **Web app or UI**: start the dev server, navigate to the changed path, and confirm the
+     behaviour from the user's perspective.
+   - **CLI tool**: invoke the affected command with representative input and observe the output
+     directly.
+   - **Service or API**: call the affected endpoint and inspect the response.
+   - **E2E or smoke suite**: run it and confirm it reaches and passes the changed behaviour path.
+
+   Record the invocation command(s) and your direct observation — what you actually saw, not what
+   you expected — in the `output` field of your `task-verified` signal alongside the step 2 output.
+
+   When `<project_tooling>` carries no runnable-product capability — a library, a pure type or
+   schema package, or only static analysis tooling listed — skip this step and state the reason in
+   one sentence in `task-verified` so the evaluator does not treat the absence as an oversight.
+
+   If starting the product fails due to an environment failure (missing dependency, port
+   unavailable, runtime not found), emit `task-blocked` with the failure details — do not skip
+   silently. A deliberate skip (no run-path declared) does not warrant `task-blocked`.
+
+4. **Record verification results** — emit `task-verified` with the verbatim commands and their
+   combined stdout/stderr output from step 2, plus the end-to-end observation from step 3 when
+   it ran, all in the `output` field.
+5. **Propose the commit message** — emit `commit-message` with a real subject and a body explaining
    WHY the change exists, what alternatives you weighed, and any follow-ups a reviewer should know.
    The harness commits after this turn using your wording verbatim. The fallback when you omit the
    signal is just the task name and description paragraph — thin context. Emit it on every task that
    touched any file. Omit only when the task was a pure investigation that wrote nothing.
-5. **Signal completion** — emit `task-complete` ONLY after all the above steps pass.
+6. **Signal completion** — emit `task-complete` ONLY after all the above steps pass.
 
 ## Failure modes
 

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

@@ -42,6 +42,8 @@ context to apply.
 For the complete history — older than the excerpt above — read `{{PROGRESS_FILE}}` on disk.
 </prior_progress>
 
+{{DECISIONS_GUIDANCE}}
+
 <goal>
 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
@@ -51,7 +53,8 @@ script once yourself. Emit `task-verified` with the verbatim command output, pro
 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.
+`task-blocked` with the concrete reason instead of guessing. Emit `change`, `learning`, and
+`note` signals as applicable — the harness records them in the sprint journal.
 </goal>
 
 {{OUTPUT_CONTRACT_SECTION}}

package/dist/prompts/plan/template.md

@@ -140,7 +140,7 @@ implemented in a single session, and verified end-to-end against its criteria.
 
 **Do not split when:**
 
-- A utility and its first caller would be separated — create-and-use is always one task.
+- A utility and its first caller would be separated — create-and-use is always one task, unless the utility already exists in the codebase or a prior task in this plan produces it.
 - A feature and its tests would be separated.
 - The same pattern applies across N call sites — it is one refactor, not N tasks.
 
@@ -319,15 +319,11 @@ If `<prior_progress>` is empty, no prior progress has been recorded on this spri
 
 </inputs>
 
-<reasoning>
-Use a thinking block before producing any output. Map each ticket onto repositories,
-identify natural task boundaries, and sequence dependencies. Explicit reasoning produces
-sharper plans than jumping straight to JSON. The harness strips thinking blocks before
-persisting.
-</reasoning>
-
 ## Protocol
 
+Before producing any output, map each ticket onto repositories, identify natural task boundaries,
+and sequence dependencies.
+
 ### Step 1 — Explore the repositories
 
 Read the repositories mounted under `<repositories>` to:
@@ -351,7 +347,7 @@ For each approved ticket, decide:
 - Where the natural task boundaries are.
 - Which tasks must complete before others (`blockedBy`).
 
-Build the plan in a thinking block first — do not write JSON yet.
+Draft the plan first, before writing JSON.
 
 ### Step 3 — Interview the user
 

package/dist/prompts/readiness/template.md

@@ -33,9 +33,10 @@ warranted. Write all signals to the `signals.json` path described in `<output_co
 <target_file_conventions>
 {{TARGET_FILE_CONVENTIONS}}
 </target_file_conventions>
-{{HARNESS_CONTEXT}}
 </inputs>
 
+{{HARNESS_CONTEXT}}
+
 <constraints>
 
 **Read-only scope.** Read configuration and metadata files only — `package.json`, `pyproject.toml`,
@@ -117,7 +118,7 @@ A short, accurate file beats a long, padded one.
 
 ### Phase 1 — Inspection
 
-Outline your plan in a thinking block: list which artefacts from `<detected_artefacts>` you will actually
+Before reading files, outline your plan: list which artefacts from `<detected_artefacts>` you will actually
 read, the project's apparent shape (language, package manager, monorepo vs single repo), and the candidate
 sections you would consider including.
 

package/dist/prompts/refine/template.md

@@ -57,9 +57,8 @@ If `<issue_context>` is empty, no upstream issue body was available.
 
 ### Step 1 — Analyse the ticket
 
-Before producing any output, reason in a `<thinking>...</thinking>` block. Surface what is clear,
-what is ambiguous, and what edge cases the ticket omits. The harness discards `<thinking>` blocks
-before persisting; reasoning here produces sharper requirements than jumping straight to output.
+Before producing any output, work through what is clear, what is ambiguous, and what edge cases the
+ticket omits. Only `signals.json` is read by the harness.
 
 Then identify, in order:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ralphctl",
-  "version": "0.13.1",
+  "version": "0.14.0",
   "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",
@@ -16,8 +16,12 @@
   "keywords": [
     "cli",
     "agent-harness",
+    "ralph",
+    "ralph-harness",
+    "ralph-loop",
     "claude-code",
     "github-copilot",
+    "codex",
     "ai-coding",
     "task-orchestration",
     "anthropic",
@@ -93,7 +97,7 @@
     "coverage:unused": "tsx scripts/find-unused.ts",
     "deadcode": "knip",
     "skills:update": "tsx scripts/sync-skills.ts",
-    "lint": "eslint .",
+    "lint": "eslint . --max-warnings 254",
     "lint:fix": "eslint . --fix",
     "format": "prettier --write .",
     "format:check": "prettier --check ."