ralphctl 0.27.0 → 0.28.0

package/dist/manifest.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
-  "packageVersion": "0.27.0",
-  "generatedAt": "2026-10-25T09:18:02.901Z",
+  "packageVersion": "0.28.0",
+  "generatedAt": "2026-11-11T08:06:25.094Z",
   "assets": [
     "agent-definitions/ralphctl-evaluator.md",
     "agent-definitions/ralphctl-generator.md",

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

@@ -11,6 +11,8 @@ invocation, not as a tutorial or README.
   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.
+- An existing file that is only an `@AGENTS.md` line imports the repository's `AGENTS.md`: keep that line first
+  and add only Claude-specific sections below it — the imported rules already load.
 
 **"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:

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

@@ -28,10 +28,13 @@ These rules apply every round, identically on a first evaluation and on a re-eva
 - **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 defect is one instance of
-  a pattern, name the pattern and list the other locations you saw, so one round fixes every instance. 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
+  a pattern, name the pattern and list the other locations you saw, so one round fixes every instance. When a
+  FAIL rests on a project convention rather than a criterion, cite the context file and line that states it,
+  since the generator's tool may not load that file, or the sibling code at `path:line` that shows it; do not
+  fail on a convention nothing in the repository states or shows.
+  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

package/dist/prompts/implement/template.md

@@ -118,7 +118,10 @@ sessions and may be stale.
   created before finishing — they would otherwise be committed with the task.
 - **Stay in scope.** Change what the steps request or clearly require. Do not add unrequested
   abstractions, docstrings, documentation, supporting files, or compatibility shims; when you spot a
-  worthwhile extra, list it in a `note` signal rather than doing it. Add tests only where the steps or
+  worthwhile extra, list it in a `note` signal rather than doing it. Don't add error handling, fallbacks or
+  validation for states the surrounding code already rules out — validate only at system boundaries — and
+  don't add comments or type annotations to code you didn't change; a smaller diff is cheaper to review and
+  verify. Add tests only where the steps or
   criteria call for them or the project already keeps tests for this kind of change — sized like the
   neighbouring test files, roughly one focused test per stated behaviour — and don't turn scratch
   checks into permanent test files.
@@ -190,7 +193,8 @@ on the first attempt, not to discover problems after the fact.
 4. **Working tree state** — inspect the working tree for uncommitted changes before writing anything.
    Two kinds are expected: the reproduction test named in `<reproduction>`, and earlier work on this
    task (signalled by a non-empty `<prior_critique>`, `<retry_feedback>`, `<prior_attempts>` or
-   `<restored_work>`). Build on those. Any other uncommitted change is unknown state — emit
+   `<restored_work>` — except that a `<retry_feedback>` saying its changes were set aside means the
+   tree holds none of them until you apply the saved patch). Build on those. Any other uncommitted change is unknown state — emit
    `task-blocked` naming the files rather than building on it.
 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

package/dist/prompts/readiness/template.md

@@ -42,6 +42,7 @@ bottom of this prompt.
 <target_file_conventions>
 {{TARGET_FILE_CONVENTIONS}}
 </target_file_conventions>
+<target_cli_loads>{{TARGET_CLI_LOADS}}</target_cli_loads>
 </inputs>
 
 <constraints>
@@ -50,9 +51,11 @@ bottom of this prompt.
 `Cargo.toml`, `go.mod`, `Makefile`, `mise.toml`, `.tool-versions`, `.github/workflows/*.yml`, `README.md`,
 top-level `scripts/` entries, `flake.nix`. Also read other tools' context files and onboarding docs when
 present — `AGENTS.md`, `CLAUDE.md`, `.github/copilot-instructions.md`, `.cursor/rules/`, `.grok/rules/`,
-`.claude/rules/`, `CONTRIBUTING.md` — and do not restate or contradict them; when they disagree with a
-manifest, mention it in a `note`. Do not read source trees, test directories, vendored or generated
-directories. Do not write any file other than `signals.json` in `<outputDir>`.
+`.claude/rules/`, `CONTRIBUTING.md`. `<target_cli_loads>` names the ones the `{{CURRENT_TOOL}}` CLI loads by
+itself: do not restate or contradict those; from a context file it does not load, carry over the rules that
+still apply, since its sessions never see that file. When they disagree with a manifest, mention it in a
+`note`. Do not read source trees, test directories, vendored or generated directories. Do not write any file
+other than `signals.json` in `<outputDir>`.
 
 **Evidence requirement.** For each tech-stack claim in the context file body, quote the file that
 establishes it (e.g. `"build": "tsup src/index.ts"` from `package.json` → `## Build & Run` bullet).

package/dist/prompts/reproduce/template.md

@@ -103,6 +103,13 @@ Choose the smallest test that demonstrates the defect exactly as reported — no
 narrower one. Add it to an existing relevant test file when one fits naturally; otherwise create a new
 test file following the project's own conventions.
 
+Assert the behaviour the report or done criteria state — the expected value, exception, or output — not
+only that the result differs from today's wrong value: a test that only rejects the current output also
+accepts a wrong fix. Do not assert what the report does not require (formatting or ordering it never
+mentions, a particular helper or call sequence) — that rejects a correct fix written another way. If the
+defect is a hang, bound it with a timeout inside the test so it fails instead of hanging — a run the
+harness has to kill (timeout or runaway output) is not accepted as a reproduction.
+
 ### Phase 3 — Run it and capture the failure
 
 Run the new test in isolation using the project's own test runner. Confirm it fails, and confirm the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ralphctl",
-  "version": "0.27.0",
+  "version": "0.28.0",
   "description": "A ralph harness for long-running AI coding tasks — a generator-evaluator loop that drives Claude Code, GitHub Copilot CLI, OpenAI Codex CLI, OpenCode or Grok Build CLI across one or more repositories",
   "homepage": "https://github.com/lukas-grigis/ralphctl",
   "type": "module",