ralphctl 0.4.2 → 0.4.4

package/dist/{project-2IE7VWDB.mjs → project-DQHF4ISP.mjs}

@@ -11,12 +11,12 @@ import {
   removeProjectRepo,
   resolveRepoPath,
   updateProject
-} from "./chunk-NUYQK5MN.mjs";
-import "./chunk-CTP2A436.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/check-script-discover.md

@@ -0,0 +1,69 @@
+# Check-Script Discovery Protocol
+
+You are a build-system analyst. Inspect the repository at the path below and propose a single shell command that the
+harness can run after every AI task to verify the working tree still passes the project's own quality gates (typecheck
+/ lint / tests / build — whatever the project considers "green"). Static ecosystem detection has already returned
+nothing useful, which usually means the project is polyglot, custom, or uses an uncommon build tool.
+
+<harness-context>
+This invocation is read-only — do not modify the working tree, do not create files, do not run network calls, do not
+execute the candidate command. The harness owns execution; your only job is to read configuration files and produce a
+recommendation. The user will see your suggestion as an editable default and can accept, modify, or discard it.
+</harness-context>
+
+<context>
+
+**Repository path:** `{{REPO_PATH}}`
+
+</context>
+
+<constraints>
+
+- Inspect only the files explicitly listed below — do not crawl the entire tree, do not open source files, do not read
+  vendored or generated directories
+- Prefer commands that exit non-zero on failure and zero on success — that is the contract the harness relies on to
+  decide whether a task passes the post-task gate
+- Combine multiple gates with `&&` so the first failure aborts the chain — example shape: `<install> && <typecheck> &&
+<lint> && <test>` (substitute the project's actual tools)
+- If you find a single canonical entry point — a `Makefile` target like `make check`, a `mise` task, or a top-level
+  script in `scripts/` — prefer that over reconstructing the chain by hand
+- Never embed credentials, environment-specific paths, or commands that touch remote services
+- Output exactly one `<check-script>` block, on its own line, containing the bare command (no markdown fences, no
+  surrounding prose)
+- If the repo contains nothing actionable, emit `<check-script></check-script>` with empty content — the harness will
+  treat that as "no check script" and fall through to manual entry
+
+</constraints>
+
+<examples>
+
+- Polyglot Node + Python:
+  `<check-script>pnpm install && pnpm typecheck && pnpm test && uv run pytest</check-script>`
+- Makefile-driven:
+  `<check-script>make check</check-script>`
+- mise tasks:
+  `<check-script>mise run ci</check-script>`
+- Bare scripts directory:
+  `<check-script>./scripts/verify.sh</check-script>`
+
+</examples>
+
+## Files to Inspect
+
+Read whichever of these exist; ignore the rest:
+
+- `package.json` — `scripts` block (look for `test`, `typecheck`, `lint`, `check`, `ci`, `verify`)
+- `pyproject.toml` — `[tool.poetry.scripts]`, `[tool.uv]`, `[tool.hatch]`, `[project.scripts]`
+- `Makefile` — top-level targets (`check`, `test`, `ci`, `verify`, `all`)
+- `mise.toml` / `.mise.toml` — `[tasks]` block
+- `.tool-versions` — runtime hints only; combine with the above
+- `.github/workflows/*.yml` — CI definitions are the most authoritative source of "what passes"
+- `README.md` — explicit "running tests" / "development" sections, if present
+- `flake.nix` — `apps`, `checks`, `devShells.default.shellHook`
+- `WORKSPACE` / `BUILD` — Bazel target conventions (`bazel test //...`)
+- `scripts/` — top-level entries only (do not recurse); look for `check`, `verify`, `ci`, `test`
+
+## Output Contract
+
+After your inspection, emit a single `<check-script>…</check-script>` element on its own line. Nothing else — no
+preamble, no explanation, no markdown. The harness parses the first match with a strict regex.

package/dist/prompts/repo-onboard.md

@@ -0,0 +1,111 @@
+# Repository Onboarding Protocol
+
+You are a senior engineer preparing a repository for agentic work. Your job is to produce a minimal, high-signal
+project context file, written to `{{FILE_NAME}}` at the repo root, that captures the _non-inferable_ facts an
+autonomous coding agent needs — custom tooling, non-standard commands, security constraints, and performance
+boundaries — and to suggest a single shell check command the harness can run as a post-task gate. Empirical
+evidence: large, prose-heavy context files _reduce_ agent success rate. Keep it small and surgical.
+
+<harness-context>
+This invocation is read-only — do not modify the working tree, do not create files, do not run network calls, do not
+execute the candidate command. The harness owns execution. The user reviews your proposal before anything is written.
+</harness-context>
+
+<context>
+
+**Repository path:** `{{REPO_PATH}}`
+**Target file:** `{{FILE_NAME}}` — the harness will write the body you emit to this path.
+**Mode:** `{{MODE}}` — one of `bootstrap` (no prior project context file), `adopt` (authored project context file
+exists, do not clobber), `update` (prior harness-managed project context file exists; propose a prune + augment).
+**Project type hint:** `{{PROJECT_TYPE}}`
+**Static check-script suggestion (may be empty):** `{{CHECK_SCRIPT_SUGGESTION}}`
+
+{{EXISTING_AGENTS_MD}}
+
+</context>
+
+<constraints>
+
+- Inspect only configuration and metadata files — `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `Makefile`,
+  `mise.toml`, `.tool-versions`, `.github/workflows/*.yml`, `README.md`, top-level `scripts/` entries, `flake.nix`.
+  Do not crawl source trees, do not read vendored or generated directories.
+- The proposed project context file MUST have exactly these H2 sections, in this order — omit none:
+  1. `## Project Overview` — one-paragraph description of what the repo is and who uses it.
+  2. `## Build & Run` — exact commands to install dependencies and run the project locally.
+  3. `## Testing` — exact commands to run unit / integration / end-to-end tests.
+  4. `## Architecture` — three to six bullets naming the top-level modules or layers, with a one-line role each.
+  5. `## Implementation Style` — conventions that can't be inferred from a file listing (naming, error handling,
+     logging, imports).
+  6. `## Security & Safety` — secrets / auth / network boundaries the agent must respect.
+  7. `## Performance Constraints` — hot paths, latency budgets, or memory limits the agent must honour.
+- Security & Safety and Performance Constraints are mandatory — when the repo offers no clues, prefix the body with
+  `LOW-CONFIDENCE:` and state what _is_ known (e.g. "LOW-CONFIDENCE: no explicit budgets; default to O(n) on request
+  hot paths"). Never drop these sections.
+- Implementation Style entries must reflect conventions demonstrably present in at least two files of the repository —
+  when you cannot cite at least two occurrences (mentally, not in the output), prefix the bullet with
+  `LOW-CONFIDENCE:`. Do not invent conventions.
+- Do not embed tool-specific slash commands, hooks, subagent definitions, MCP server configurations, or IDE settings
+  in this file. Those belong in tool-specific directories (e.g. `.claude/`, `.cursor/`). This file is facts about the
+  repository only.
+- Hard caps: exactly one H1, at most 7 H2 sections, no H4 or deeper headings, under 300 lines total. Prefer bullets
+  and short sentences — target a Flesch reading ease above 40.
+- Use the em-dash `—` (not `-`) for explanatory clauses in prose. Ordinary hyphens in identifiers and compound words
+  are fine.
+- Never embed credentials, user-specific paths, or commands that touch remote services.
+- Do not hardcode package-manager commands outside the tooling context — every command you cite must actually resolve
+  in this repository (e.g. only write `pnpm lint` when `package.json` has a `lint` script).
+- In `adopt` mode: treat the existing body as authoritative. Emit only the _additions_ you propose as new sections;
+  never rewrite or reorder the user's prose.
+- In `update` mode: emit the full replacement body AND a short `<changes>` block listing the non-obvious
+  prunes/augments (`- removed stale command "npm run foo"`, `- added missing Security section`).
+
+</constraints>
+
+<examples>
+
+- Minimal Node.js API:
+
+  ```
+  # Acme API
+
+  ## Project Overview
+  Internal REST service for order ingestion — consumed by the dashboard and the worker fleet.
+
+  ## Build & Run
+  - `pnpm install` then `pnpm dev` for local hot-reload on port 3000.
+
+  ## Testing
+  - `pnpm test` — unit + integration (Vitest).
+
+  ## Architecture
+  - `src/routes/` — HTTP surface, thin controllers.
+  - `src/services/` — business logic, pure where possible.
+  - `src/db/` — Drizzle schema and query builders.
+
+  ## Implementation Style
+  - Result<T, Err> at service boundaries, never throw for expected failures.
+  - Zod-validated request bodies, no untyped inputs.
+
+  ## Security & Safety
+  - All inbound requests are authenticated by upstream gateway; never trust the `X-User-Id` header directly.
+  - Do not log PII — scrub emails and phone numbers from error payloads.
+
+  ## Performance Constraints
+  - LOW-CONFIDENCE: no explicit budgets documented; default to p95 under 100 ms for read endpoints.
+  ```
+
+</examples>
+
+## Output Contract
+
+After your inspection, emit exactly two elements on their own lines — nothing else (no preamble, no summary):
+
+1. `<agents-md>…full project context file body…</agents-md>` — the proposed file, obeying every constraint above.
+2. `<check-script>…single shell command…</check-script>` — one command the harness can run as a post-task gate.
+   Empty content (`<check-script></check-script>`) is allowed when no gate can be inferred.
+
+In `update` mode, also emit a third element describing the delta:
+
+3. `<changes>…bullet list…</changes>` — one bullet per non-obvious prune or addition.
+
+No markdown fences around the elements. No commentary between them.

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-EOE5WUMV.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-2IE7VWDB.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-OGOFEJJH.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)
@@ -133,7 +133,7 @@ async function resolveCompletions(program, ctx) {
 function getCommandPath(cmd) {
   const parts = [];
   let current = cmd;
-  while (current?.parent) {
+  while (current.parent) {
     parts.unshift(current.name());
     current = current.parent;
   }

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

@@ -11,15 +11,15 @@ import {
   logSprintBaselines,
   resolveSprintId,
   saveSprint
-} from "./chunk-YCDUVPRT.mjs";
-import "./chunk-FKMKOWLA.mjs";
+} from "./chunk-CBMFRQ4Y.mjs";
+import "./chunk-XN2UIHBY.mjs";
 import "./chunk-IWXBJD2D.mjs";
-import "./chunk-CTP2A436.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.2",
+  "version": "0.4.4",
   "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",
@@ -53,8 +53,8 @@
     "@types/node": "^25.6.0",
     "@types/react": "^19.2.14",
     "@types/tabtab": "^3.0.4",
-    "@vitest/coverage-v8": "^4.1.4",
-    "eslint": "^10.2.0",
+    "@vitest/coverage-v8": "^4.1.5",
+    "eslint": "^10.2.1",
     "eslint-config-prettier": "^10.1.8",
     "globals": "^17.5.0",
     "husky": "^9.1.7",
@@ -64,11 +64,11 @@
     "tsup": "^8.5.1",
     "tsx": "^4.21.0",
     "typescript": "^5.9.3",
-    "typescript-eslint": "^8.58.2",
-    "vitest": "^4.1.4"
+    "typescript-eslint": "^8.59.0",
+    "vitest": "^4.1.5"
   },
   "lint-staged": {
-    "*.ts": [
+    "*.{ts,tsx}": [
       "eslint --cache --fix",
       "prettier --write"
     ],

package/dist/create-7WFSCMP4.mjs

@@ -1,15 +0,0 @@
-#!/usr/bin/env node
-import {
-  sprintCreateCommand
-} from "./chunk-3QBEBKMZ.mjs";
-import "./chunk-NUYQK5MN.mjs";
-import "./chunk-CFUVE2BP.mjs";
-import "./chunk-747KW2RW.mjs";
-import "./chunk-YCDUVPRT.mjs";
-import "./chunk-FKMKOWLA.mjs";
-import "./chunk-IWXBJD2D.mjs";
-import "./chunk-CTP2A436.mjs";
-import "./chunk-57UWLHRH.mjs";
-export {
-  sprintCreateCommand
-};

package/dist/start-76JKJQIH.mjs

@@ -1,17 +0,0 @@
-#!/usr/bin/env node
-import {
-  parseSprintStartArgs,
-  sprintStartCommand
-} from "./chunk-TKPTT2UG.mjs";
-import "./chunk-JOQO4HMM.mjs";
-import "./chunk-CFUVE2BP.mjs";
-import "./chunk-747KW2RW.mjs";
-import "./chunk-YCDUVPRT.mjs";
-import "./chunk-FKMKOWLA.mjs";
-import "./chunk-IWXBJD2D.mjs";
-import "./chunk-CTP2A436.mjs";
-import "./chunk-57UWLHRH.mjs";
-export {
-  parseSprintStartArgs,
-  sprintStartCommand
-};