ralphctl 0.5.0 → 0.6.0

package/dist/project-DQHF4ISP.mjs

@@ -1,34 +0,0 @@
-#!/usr/bin/env node
-import {
-  addProjectRepo,
-  createProject,
-  getProject,
-  getProjectById,
-  getRepoById,
-  listProjects,
-  projectExists,
-  removeProject,
-  removeProjectRepo,
-  resolveRepoPath,
-  updateProject
-} from "./chunk-BSB4EDGR.mjs";
-import "./chunk-WDMLPXOD.mjs";
-import {
-  ProjectExistsError,
-  ProjectNotFoundError
-} from "./chunk-VAZ3LJBI.mjs";
-export {
-  ProjectExistsError,
-  ProjectNotFoundError,
-  addProjectRepo,
-  createProject,
-  getProject,
-  getProjectById,
-  getRepoById,
-  listProjects,
-  projectExists,
-  removeProject,
-  removeProjectRepo,
-  resolveRepoPath,
-  updateProject
-};

package/dist/prompts/check-script-discover.md

@@ -1,69 +0,0 @@
-# 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/ideate-auto.md

@@ -1,195 +0,0 @@
-# Autonomous Ideation to Implementation
-
-You are a combined requirements analyst and task planner working autonomously. Turn a rough idea into refined
-requirements and a dependency-ordered set of implementation tasks. Think carefully and step-by-step: resolve ambiguity
-from the idea description and the codebase before writing tasks — there is no user to interact with, so your own
-analysis is the only source of clarity.
-
-{{HARNESS_CONTEXT}}
-
-When finished, emit a signal from the `<signals>` block below.
-
-## Two-Phase Protocol
-
-### Phase 0: Think Before Writing
-
-Before emitting any JSON, write your reasoning in a `<thinking>…</thinking>` block. Use it to interrogate the idea —
-surface hidden assumptions, identify the real user problem, sketch requirements, and reason about which repositories
-and dependencies the work touches. Explicit reasoning produces sharper output than jumping straight to JSON.
-
-The harness's JSON extractor skips everything before the first `{`, so the `<thinking>` block is stripped
-automatically — but the JSON object itself must still be emitted without markdown fences or commentary after it.
-
-```
-<thinking>
-The idea says "webhook notifications" but doesn't say which events. Reviewing the API, the natural candidates are
-task-status transitions. Scope = status-change webhooks only; other event types are out of scope.
-Acceptance: POST to configured URL with JSON payload on task status change; retries on 5xx.
-…
-</thinking>
-{
-  … JSON object …
-}
-```
-
-### Phase 1: Refine Requirements (WHAT)
-
-Analyze the idea and produce complete, implementation-agnostic requirements:
-
-- **Problem statement** — What problem are we solving and for whom?
-- **Functional requirements** — What should the system do? (behavior, not implementation)
-- **Acceptance criteria** — Testable conditions (Given/When/Then format preferred)
-- **Scope boundaries** — What's in vs out of scope
-- **Constraints** — Performance, compatibility, business rules if applicable
-
-**Output format:**
-
-```markdown
-## Problem
-
-[Clear problem statement]
-
-## Requirements
-
-- [Functional requirement 1]
-- [Functional requirement 2]
-
-## Acceptance Criteria
-
-- Given [precondition], When [action], Then [expected result]
-- [Additional criteria...]
-
-## Scope
-
-**In scope:**
-
-- [What's included]
-
-**Out of scope:**
-
-- [What's explicitly excluded or deferred]
-
-## Constraints
-
-- [Business/technical constraints if any]
-```
-
-### Phase 2: Plan Implementation (HOW)
-
-Phase 2 begins with reconnaissance — orient yourself in the codebase before generating tasks. Skip exploration and your
-plan will be guesswork.
-
-#### Step 0: Explore the Project
-
-Scope exploration to what will change the plan — read instruction files first, then only the specific files you need
-for patterns and verification commands:
-
-1. **Read project instructions first** — start with `CLAUDE.md` (or `AGENTS.md`) if it exists, then check
-   `.github/copilot-instructions.md` when present. Follow any links to other documentation. See the "Project Resources"
-   section in the Planning Common Context below for the full list of resources under `.claude/` and at the repo root.
-2. **Read manifest files** — `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `pom.xml`, etc. for dependencies
-   and scripts
-3. **Read README** — project overview, setup, and architecture
-4. **Scan directory structure** — understand the layout before diving into files
-5. **Find similar implementations** — look for existing features similar to what the requirements call for; follow
-   their patterns
-6. **Extract verification commands** — find the exact build, test, lint, and typecheck commands from the repository
-   instruction files or project config
-
-#### Step 1: Generate the Plan
-
-1. **Map requirements to implementation** — Determine which parts of the approved requirements map to which repository
-2. **Create tasks** — Following the Planning Common Context guidelines below
-3. **Validate** — Ensure tasks are non-overlapping, properly ordered, and completable
-
-### Blocker Handling
-
-If you cannot produce a valid plan, signal the issue instead of outputting incomplete JSON:
-
-- `<planning-blocked>reason</planning-blocked>`
-
-<context>
-
-## Idea to Implement
-
-**Title:** {{IDEA_TITLE}}
-
-**Project:** {{PROJECT_NAME}}
-
-**Description:**
-
-{{IDEA_DESCRIPTION}}
-
-## Selected Repositories
-
-You have access to these repositories:
-
-{{REPOSITORIES}}
-
-## Planning Common Context
-
-{{COMMON}}
-
-</context>
-
-{{VALIDATION}}
-
-## Output Format
-
-Output a single JSON object with both requirements and tasks.
-If you cannot produce a valid plan, output `<planning-blocked>reason</planning-blocked>` instead of JSON.
-
-```json
-{{SCHEMA}}
-```
-
-**Requirements:**
-
-- Complete markdown string with the structure shown in Phase 1
-- Implementation-agnostic (WHAT, not HOW)
-- Clear acceptance criteria
-
-**Tasks:**
-
-- Each task has `id`, `name`, `projectPath`, `steps`, and optional `blockedBy`
-- `projectPath` must be one of the Selected Repositories paths
-- Steps reference actual files discovered during exploration
-- Verification steps use commands from the repository instruction files if available
-- Tasks properly ordered by dependencies
-
-**Example:**
-
-```json
-{
-  "requirements": "## Problem\n\nUsers cannot filter exports by date range...\n\n## Requirements\n\n- Support optional start/end date query parameters...\n\n## Acceptance Criteria\n\n- Given valid ISO dates, When GET /exports?startDate=...&endDate=..., Then only matching exports returned\n\n## Scope\n\n**In scope:** Date filtering on export endpoint\n**Out of scope:** Date filtering on other endpoints\n\n## Constraints\n\n- Must use ISO8601 date format",
-  "tasks": [
-    {
-      "id": "1",
-      "name": "Add date range validation schema and export filter",
-      "projectPath": "/Users/dev/my-app",
-      "steps": [
-        "Create src/schemas/date-range.ts with DateRangeSchema using Zod — validate ISO8601 format, ensure startDate <= endDate",
-        "Modify src/controllers/export.ts to accept optional startDate/endDate query params using DateRangeSchema",
-        "Update src/repositories/export.ts findExports() to add WHERE clause for date filtering",
-        "Add unit tests in src/schemas/__tests__/date-range.test.ts covering valid ranges, invalid formats, and reversed dates",
-        "Add integration test in src/controllers/__tests__/export.test.ts for filtered and unfiltered queries",
-        "{{CHECK_GATE_EXAMPLE}}"
-      ],
-      "verificationCriteria": [
-        "TypeScript compiles with no errors",
-        "All existing tests pass plus new tests for date range filtering",
-        "GET /exports?startDate=invalid returns 400 with validation error",
-        "Filtered query returns only records within the specified date range"
-      ],
-      "blockedBy": []
-    }
-  ]
-}
-```
-
-{{SIGNALS}}
-
----
-
-Proceed autonomously: refine the idea into clear requirements, explore the codebase, then generate tasks. Output only
-the final JSON when complete.

package/dist/prompts/task-evaluation-resume.md

@@ -1,41 +0,0 @@
-# Evaluator Feedback — Fix and Re-verify
-
-You are a task implementer responding to a code review. The independent reviewer's findings are authoritative. For each
-issue, think through what is broken and what the minimal safe fix is — then apply, re-verify, and signal completion.
-
-{{HARNESS_CONTEXT}}
-
-When finished, emit a signal from the `<signals>` block below.
-
-<constraints>
-
-- **Stay within scope** — fix only what the critique flags; keep edits local to the files and lines the critique
-  calls out. Do not expand the task or refactor neighboring code.
-- **Default to minimal fix** — make targeted changes; preserve the existing implementation structure where possible.
-- **Pivot when the critique is structural, not local** — if the findings point at a fundamentally wrong approach
-  (wrong abstraction, wrong data flow, wrong contract) rather than localized bugs, a patch over the existing
-  implementation will likely fail re-evaluation on related grounds. In that case, replace the affected section
-  with a correct approach instead of repeatedly patching it. Use this judgement sparingly — most critiques are
-  genuinely local.
-- **Treat reviewer findings as authoritative** — apply the fix they describe rather than rewriting the approach. If a
-  finding is genuinely wrong, signal `<task-blocked>` so a human can decide; do not silently ignore it.
-
-</constraints>
-
-## Critique
-
-{{CRITIQUE}}
-
-## Fix Protocol
-
-1. **Address each issue** — Reference the file:line locations the reviewer cited. If a citation is
-   wrong, find the actually-affected location and fix that.
-2. **Re-run verification** — Run the project's check script (or the equivalent verification
-   commands) and confirm they pass.{{COMMIT_INSTRUCTION}}
-3. **Output verification results** — Wrap output in `<task-verified>...</task-verified>`.
-4. **Signal completion** — Output `<task-complete>` ONLY after all steps above pass.
-
-If an issue is unfixable (contradicts the spec, or requires changes outside your scope), signal
-`<task-blocked>reason</task-blocked>` instead of completing.
-
-{{SIGNALS}}

package/dist/resolver-OVPYVW6Q.mjs

@@ -1,163 +0,0 @@
-#!/usr/bin/env node
-import {
-  wrapAsync
-} from "./chunk-IWXBJD2D.mjs";
-import {
-  IOError
-} from "./chunk-VAZ3LJBI.mjs";
-
-// src/integration/cli/completion/resolver.ts
-var dynamicResolvers = {
-  "--project": async () => {
-    const result = await wrapAsync(
-      async () => {
-        const { listProjects } = await import("./project-DQHF4ISP.mjs");
-        return listProjects();
-      },
-      (err) => new IOError("Failed to load projects for completion", err instanceof Error ? err : void 0)
-    );
-    if (!result.ok) return [];
-    return result.value.map((p) => ({ name: p.name, description: p.displayName }));
-  },
-  "--status": () => {
-    return Promise.resolve([
-      { name: "draft", description: "Draft sprints" },
-      { name: "active", description: "Active sprints" },
-      { name: "closed", description: "Closed sprints" },
-      { name: "todo", description: "Todo tasks" },
-      { name: "in_progress", description: "In-progress tasks" },
-      { name: "done", description: "Done tasks" },
-      { name: "pending", description: "Pending requirements" },
-      { name: "approved", description: "Approved requirements" }
-    ]);
-  }
-};
-var configKeyCompletions = [
-  { name: "provider", description: "AI provider (claude or copilot)" },
-  { name: "editor", description: "External editor for multiline input" }
-];
-var configValueCompletions = {
-  provider: [
-    { name: "claude", description: "Claude Code CLI" },
-    { name: "copilot", description: "GitHub Copilot CLI" }
-  ]
-};
-async function getSprintCompletions() {
-  const result = await wrapAsync(
-    async () => {
-      const { listSprints } = await import("./sprint-4E26AB5F.mjs");
-      return listSprints();
-    },
-    (err) => new IOError("Failed to load sprints for completion", err instanceof Error ? err : void 0)
-  );
-  if (!result.ok) return [];
-  return result.value.map((s) => ({
-    name: s.id,
-    description: `${s.name} (${s.status})`
-  }));
-}
-function getSubcommands(cmd) {
-  return cmd.commands.map((sub) => ({
-    name: sub.name(),
-    description: sub.description()
-  }));
-}
-function getOptions(cmd) {
-  const items = [];
-  for (const opt of cmd.options) {
-    const flag = opt.long ?? opt.short;
-    if (flag) {
-      items.push({ name: flag, description: opt.description });
-    }
-  }
-  return items;
-}
-function findSubcommand(cmd, name) {
-  return cmd.commands.find((sub) => sub.name() === name);
-}
-function optionExpectsValue(cmd, flag) {
-  const opt = cmd.options.find((o) => o.long === flag || o.short === flag);
-  if (!opt) return false;
-  return opt.required || opt.optional;
-}
-function parseWords(line) {
-  return line.trim().split(/\s+/).slice(1);
-}
-async function resolveCompletions(program, ctx) {
-  const words = parseWords(ctx.line);
-  let currentCmd = program;
-  let wordIndex = 0;
-  while (wordIndex < words.length) {
-    const word = words[wordIndex];
-    if (!word) break;
-    if (word.startsWith("-")) {
-      wordIndex++;
-      if (optionExpectsValue(currentCmd, word) && wordIndex < words.length) {
-        wordIndex++;
-      }
-      continue;
-    }
-    const sub = findSubcommand(currentCmd, word);
-    if (sub) {
-      currentCmd = sub;
-      wordIndex++;
-    } else {
-      break;
-    }
-  }
-  const cmdPath = getCommandPath(currentCmd);
-  if (cmdPath === "config set") {
-    return resolveConfigSetCompletions(words, ctx);
-  }
-  if (ctx.prev.startsWith("-")) {
-    const resolver = dynamicResolvers[ctx.prev];
-    if (resolver) {
-      return resolver();
-    }
-    if (optionExpectsValue(currentCmd, ctx.prev)) {
-      return [];
-    }
-  }
-  if (ctx.last.startsWith("-")) {
-    return getOptions(currentCmd);
-  }
-  const subs = getSubcommands(currentCmd);
-  if (subs.length > 0) {
-    return subs;
-  }
-  if (cmdPath.startsWith("sprint ") && acceptsPositionalArg(currentCmd)) {
-    return getSprintCompletions();
-  }
-  return [];
-}
-function getCommandPath(cmd) {
-  const parts = [];
-  let current = cmd;
-  while (current.parent) {
-    parts.unshift(current.name());
-    current = current.parent;
-  }
-  return parts.join(" ");
-}
-function acceptsPositionalArg(cmd) {
-  return cmd.registeredArguments.length > 0;
-}
-function resolveConfigSetCompletions(words, ctx) {
-  const setIndex = words.indexOf("set");
-  if (setIndex === -1) {
-    return Promise.resolve(configKeyCompletions);
-  }
-  const argsAfterSet = words.slice(setIndex + 1).filter((w) => !w.startsWith("-"));
-  if (argsAfterSet.length === 0) {
-    return Promise.resolve(configKeyCompletions);
-  }
-  if (argsAfterSet.length === 1 && ctx.last !== "") {
-    return Promise.resolve(configKeyCompletions);
-  }
-  const key = argsAfterSet[0];
-  const values = key ? configValueCompletions[key] : void 0;
-  return Promise.resolve(values ?? []);
-}
-export {
-  resolveCompletions
-};

package/dist/sprint-4E26AB5F.mjs

@@ -1,38 +0,0 @@
-#!/usr/bin/env node
-import {
-  activateSprint,
-  assertSprintStatus,
-  closeSprint,
-  createSprint,
-  deleteSprint,
-  getCurrentSprintOrThrow,
-  getSprint,
-  listSprints,
-  logSprintBaselines,
-  resolveSprintId,
-  saveSprint
-} from "./chunk-CBMFRQ4Y.mjs";
-import "./chunk-XN2UIHBY.mjs";
-import "./chunk-IWXBJD2D.mjs";
-import "./chunk-WDMLPXOD.mjs";
-import {
-  NoCurrentSprintError,
-  SprintNotFoundError,
-  SprintStatusError
-} from "./chunk-VAZ3LJBI.mjs";
-export {
-  NoCurrentSprintError,
-  SprintNotFoundError,
-  SprintStatusError,
-  activateSprint,
-  assertSprintStatus,
-  closeSprint,
-  createSprint,
-  deleteSprint,
-  getCurrentSprintOrThrow,
-  getSprint,
-  listSprints,
-  logSprintBaselines,
-  resolveSprintId,
-  saveSprint
-};

package/dist/start-T34NI3LF.mjs

@@ -1,19 +0,0 @@
-#!/usr/bin/env node
-import {
-  parseSprintStartArgs,
-  sprintStartCommand
-} from "./chunk-D6QZNEYN.mjs";
-import "./chunk-62HYDA7L.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
-};