ralphctl 0.4.3 → 0.4.5

package/dist/{project-JF47ZWMF.mjs → project-DQHF4ISP.mjs}

@@ -11,12 +11,12 @@ import {
   removeProjectRepo,
   resolveRepoPath,
   updateProject
-} from "./chunk-LDSG7G2T.mjs";
-import "./chunk-D2HWXEHH.mjs";
+} from "./chunk-BSB4EDGR.mjs";
+import "./chunk-WDMLPXOD.mjs";
 import {
   ProjectExistsError,
   ProjectNotFoundError
-} from "./chunk-57UWLHRH.mjs";
+} from "./chunk-VAZ3LJBI.mjs";
 export {
   ProjectExistsError,
   ProjectNotFoundError,

package/dist/prompts/sprint-feedback.md

@@ -49,6 +49,10 @@ interpretation and proceed.
 - **The feedback is the authoritative instruction** — implement it even if it seems unrelated to the completed tasks.
 - **Do the smallest change that fully satisfies the feedback** — no speculative refactors, no adjacent cleanup.
 - **Make the edits — don't just describe them** — the harness does not apply edits for you; you must write the files.
+- **Never reference sprint-local identifiers in code** — do not mention acceptance-criterion labels (`AC1`, `AC2`,
+  `AC1–AC6`), ticket numbers, task IDs, or sprint IDs in source files, comments, docstrings, test names, commit
+  messages, or any committed artefact. These identifiers are ephemeral sprint metadata and become stale. Describe
+  the underlying invariant or constraint directly instead.
 - **Must commit** — Create a git commit before signaling completion. Uncommitted changes leave the sprint branch dirty
   and block sprint close.
 

package/dist/prompts/task-evaluation.md

@@ -50,13 +50,19 @@ Computational results are ground truth. If the check script fails, stop early
 
 ### Phase 2: Inferential Investigation (reason about the changes)
 
-Now apply semantic judgment to what the computational checks cannot catch:
+Now apply semantic judgment to what the computational checks cannot catch. Every finding you emit
+must be traceable to a concrete observation from this phase — a file path, a line, a function name, a
+specific value, a tool output, or a quoted snippet. Generic approval language ("looks good", "appears
+correct", "seems fine", "looks clean", "should be OK") is **insufficient** and MUST be treated as a
+rubber stamp — flag it as a Completeness failure rather than emitting it yourself.
 
 1. **Diff the task's commit range** — derive the base from the branch's divergence point (`git merge-base HEAD main`
    or the closest equivalent) and run `git diff <base>..HEAD`. Tasks may produce multiple commits; do not assume
    a single commit.
-2. **Read the changed files carefully** — understand the full implementation, not just the diff.
+2. **Read the changed files carefully** — understand the full implementation, not just the diff. Note
+   specific constructs worth citing later (new functions, changed signatures, edge-case branches).
 3. **Read surrounding code** — check that the implementation follows existing patterns and conventions.
+   Cite a specific sibling file or function when the comparison matters.
 4. **Augment the Project Tooling section above** — the section lists detected subagents, skills, and MCP servers.
    Additionally skim repository config for the test/verification stack and any conventions the section didn't surface.
    Note which application type this is (backend API / CLI / frontend SPA / fullstack / library) — it determines which
@@ -84,6 +90,13 @@ Evaluate the implementation across the dimensions below. Each dimension is pass/
 dimension fails, the overall evaluation fails. The first four are the floor — every task is graded on them. The
 planner may have flagged additional task-specific dimensions; when present, they are graded on top of the floor.
 
+**Evidence rule — load-bearing:** Every dimension line, PASS or FAIL, MUST cite a concrete observation
+from Phase 1 or Phase 2. A PASS without evidence is not a PASS — it is a rubber stamp. Good evidence
+names something specific: a file path, a line number, a test count, a command output, a function
+name, a verification criterion that was graded, a pattern from a sibling file. Evidence that only
+restates the criterion in different words ("all tests pass", "implementation matches the spec", "no
+issues found") is still generic and does NOT satisfy this rule.
+
 <dimension name="Correctness" floor="true">
 Does the implementation do what the specification says? Check for:
 
@@ -137,6 +150,25 @@ Fail only on missed verification criteria, skipped steps, safety issues, or genu
 not style preferences, naming opinions, or improvements beyond the task scope. When verification criteria are provided,
 grade primarily against them — they are the contract.
 
+### Anti-Rubber-Stamp Guard
+
+Before you decide the verdict, answer both questions honestly:
+
+1. **Did you actually run the Phase 1 verification commands?** If the check script exists and you did
+   not execute it, or you did not run `git status` / `git log`, you lack the ground truth that
+   authoritatively settles Correctness and Completeness.
+2. **Can you name a specific observation for each dimension?** For every PASS and FAIL line you are
+   about to emit, point to a concrete piece of evidence — a file path, a line number, a test count,
+   a tool output, a function name, a verification criterion you graded. "Looks good" / "appears
+   correct" / "no issues found" are NOT specific observations.
+
+If the answer to either question is **no**, you MUST FAIL Completeness with a one-line finding
+explaining what you skipped, and emit `<evaluation-failed>` — even if everything else seems fine. A
+rubber-stamp PASS is worse than a real FAIL because it misleads the harness into marking work done
+when it was never audited. This guard exists because the evaluator is the last line of defense
+against silent-pass regressions; the cost of a false FAIL is one extra fix iteration, the cost of a
+false PASS is a shipped bug.
+
 ## Output
 
 Structure your output as a dimension assessment followed by a verdict signal.
@@ -144,8 +176,18 @@ Structure your output as a dimension assessment followed by a verdict signal.
 **Format rule:** Each dimension MUST be a single line: `**Dimension**: PASS/FAIL — one-line summary`. Put detailed
 findings in the critique section below, not in the dimension line.
 
+**Justification rule (enforced):** The `— one-line summary` after the verdict is required, not
+decorative. A bare `**Dimension**: PASS` with no em-dash and no finding is invalid — it parses as a
+rubber stamp and the harness will treat the evaluation as failed. Every dimension line needs an
+em-dash (or hyphen) followed by a non-empty, concrete finding.
+
 ### If the implementation passes all dimensions:
 
+Emit `<evaluation-passed>` ONLY when every dimension has a one-line justification that cites
+concrete evidence. A `<evaluation-passed>` signal after bare `PASS` lines or after generic approval
+phrasing is a contract violation — in that case, emit `<evaluation-failed>` instead with a
+Completeness finding that you could not justify the pass.
+
 ```
 ## Assessment
 

package/dist/prompts/task-execution.md

@@ -24,6 +24,11 @@ When finished, emit a signal from the `<signals>` block below.
   erases context that downstream tasks depend on.
 - **Leave {{CONTEXT_FILE}} and task definitions alone** — the context file is cleaned up by the harness (committing it
   pollutes the repo); the task name, description, steps, and other task files are immutable.
+- **Never reference sprint-local identifiers in code** — do not mention acceptance-criterion labels (`AC1`, `AC2`,
+  `AC1–AC6`), ticket numbers, task IDs, or sprint IDs in source files, comments, docstrings, test names, commit
+  messages, or any committed artefact. These identifiers are ephemeral sprint metadata and become stale as tickets
+  close. If a comment needs to explain WHY, state the underlying invariant or constraint directly (e.g. "exactly one
+  confirmation per destructive action") rather than citing the AC that mandates it.
 
 {{COMMIT_CONSTRAINT}}
 

package/dist/{resolver-PG2DZEBX.mjs → resolver-OVPYVW6Q.mjs}

@@ -4,14 +4,14 @@ import {
 } from "./chunk-IWXBJD2D.mjs";
 import {
   IOError
-} from "./chunk-57UWLHRH.mjs";
+} from "./chunk-VAZ3LJBI.mjs";
 
 // src/integration/cli/completion/resolver.ts
 var dynamicResolvers = {
   "--project": async () => {
     const result = await wrapAsync(
       async () => {
-        const { listProjects } = await import("./project-JF47ZWMF.mjs");
+        const { listProjects } = await import("./project-DQHF4ISP.mjs");
         return listProjects();
       },
       (err) => new IOError("Failed to load projects for completion", err instanceof Error ? err : void 0)
@@ -45,7 +45,7 @@ var configValueCompletions = {
 async function getSprintCompletions() {
   const result = await wrapAsync(
     async () => {
-      const { listSprints } = await import("./sprint-54DOSIJK.mjs");
+      const { listSprints } = await import("./sprint-4E26AB5F.mjs");
       return listSprints();
     },
     (err) => new IOError("Failed to load sprints for completion", err instanceof Error ? err : void 0)

package/dist/{sprint-54DOSIJK.mjs → sprint-4E26AB5F.mjs}

@@ -11,15 +11,15 @@ import {
   logSprintBaselines,
   resolveSprintId,
   saveSprint
-} from "./chunk-RQGD5WS6.mjs";
-import "./chunk-WZTY77GY.mjs";
+} from "./chunk-CBMFRQ4Y.mjs";
+import "./chunk-XN2UIHBY.mjs";
 import "./chunk-IWXBJD2D.mjs";
-import "./chunk-D2HWXEHH.mjs";
+import "./chunk-WDMLPXOD.mjs";
 import {
   NoCurrentSprintError,
   SprintNotFoundError,
   SprintStatusError
-} from "./chunk-57UWLHRH.mjs";
+} from "./chunk-VAZ3LJBI.mjs";
 export {
   NoCurrentSprintError,
   SprintNotFoundError,

package/dist/start-2WH4BTDB.mjs

@@ -0,0 +1,19 @@
+#!/usr/bin/env node
+import {
+  parseSprintStartArgs,
+  sprintStartCommand
+} from "./chunk-OFILN7QL.mjs";
+import "./chunk-ZLWSPLWI.mjs";
+import "./chunk-GQ2WFKBN.mjs";
+import "./chunk-CFUVE2BP.mjs";
+import "./chunk-747KW2RW.mjs";
+import "./chunk-BSB4EDGR.mjs";
+import "./chunk-CBMFRQ4Y.mjs";
+import "./chunk-XN2UIHBY.mjs";
+import "./chunk-IWXBJD2D.mjs";
+import "./chunk-WDMLPXOD.mjs";
+import "./chunk-VAZ3LJBI.mjs";
+export {
+  parseSprintStartArgs,
+  sprintStartCommand
+};

package/package.json

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

package/dist/create-PQK6KKRD.mjs

@@ -1,15 +0,0 @@
-#!/usr/bin/env node
-import {
-  sprintCreateCommand
-} from "./chunk-Q4AVHUZL.mjs";
-import "./chunk-CFUVE2BP.mjs";
-import "./chunk-747KW2RW.mjs";
-import "./chunk-LDSG7G2T.mjs";
-import "./chunk-RQGD5WS6.mjs";
-import "./chunk-WZTY77GY.mjs";
-import "./chunk-IWXBJD2D.mjs";
-import "./chunk-D2HWXEHH.mjs";
-import "./chunk-57UWLHRH.mjs";
-export {
-  sprintCreateCommand
-};

package/dist/start-2SZTBKGF.mjs

@@ -1,19 +0,0 @@
-#!/usr/bin/env node
-import {
-  parseSprintStartArgs,
-  sprintStartCommand
-} from "./chunk-LCY32RW4.mjs";
-import "./chunk-2FT37OZX.mjs";
-import "./chunk-EGUFQNRB.mjs";
-import "./chunk-CFUVE2BP.mjs";
-import "./chunk-747KW2RW.mjs";
-import "./chunk-LDSG7G2T.mjs";
-import "./chunk-RQGD5WS6.mjs";
-import "./chunk-WZTY77GY.mjs";
-import "./chunk-IWXBJD2D.mjs";
-import "./chunk-D2HWXEHH.mjs";
-import "./chunk-57UWLHRH.mjs";
-export {
-  parseSprintStartArgs,
-  sprintStartCommand
-};