ralphctl 0.6.3 → 0.7.1

package/dist/chunk-S3PTDH57.mjs

@@ -1,78 +0,0 @@
-#!/usr/bin/env node
-import {
-  ValidationError
-} from "./chunk-WV4D2CPG.mjs";
-
-// src/domain/values/absolute-path.ts
-import { isAbsolute } from "path";
-import { Result } from "typescript-result";
-var ENV_VAR_REGEX = /\$\{[^}]*\}|\$[A-Za-z_][A-Za-z0-9_]*/;
-function validate(input) {
-  if (typeof input !== "string") {
-    return Result.error(
-      new ValidationError({
-        field: "absolute-path",
-        value: input,
-        message: "absolute path must be a string"
-      })
-    );
-  }
-  if (input.trim().length === 0) {
-    return Result.error(
-      new ValidationError({
-        field: "absolute-path",
-        value: input,
-        message: "absolute path must not be empty or whitespace-only"
-      })
-    );
-  }
-  if (input.includes("~")) {
-    return Result.error(
-      new ValidationError({
-        field: "absolute-path",
-        value: input,
-        message: 'absolute path must not contain "~"',
-        hint: "expand the home directory before constructing an AbsolutePath"
-      })
-    );
-  }
-  if (ENV_VAR_REGEX.test(input)) {
-    return Result.error(
-      new ValidationError({
-        field: "absolute-path",
-        value: input,
-        message: "absolute path must not contain environment variable references",
-        hint: "expand $VAR / ${VAR} via process.env before constructing an AbsolutePath"
-      })
-    );
-  }
-  if (!isAbsolute(input)) {
-    return Result.error(
-      new ValidationError({
-        field: "absolute-path",
-        value: input,
-        message: "path must be absolute",
-        hint: "use path.resolve() to convert a relative path before construction"
-      })
-    );
-  }
-  return Result.ok(input);
-}
-var AbsolutePath = {
-  parse(input) {
-    return validate(input);
-  },
-  /**
-   * Internal escape hatch for already-validated strings (e.g. paths read
-   * from persisted JSON that has already passed schema validation).
-   *
-   * **Do not call from business code; persistence layer only.**
-   */
-  trustString(s) {
-    return s;
-  }
-};
-
-export {
-  AbsolutePath
-};

package/dist/chunk-WV4D2CPG.mjs

@@ -1,26 +0,0 @@
-#!/usr/bin/env node
-
-// src/domain/values/validation-error.ts
-var ValidationError = class extends Error {
-  /** Discriminator. `as const` keeps it narrow at the type level. */
-  code = "invalid-value";
-  /** Logical field — usually the value-object name (e.g. "sprint-id"). */
-  field;
-  /** The raw input that failed validation. Kept untyped on purpose. */
-  value;
-  /** Optional human-readable repair hint. */
-  hint;
-  constructor(opts) {
-    super(opts.message);
-    this.name = "ValidationError";
-    this.field = opts.field;
-    this.value = opts.value;
-    if (opts.hint !== void 0) {
-      this.hint = opts.hint;
-    }
-  }
-};
-
-export {
-  ValidationError
-};

package/dist/prompt-adapter-JQICGVX7.mjs

@@ -1,7 +0,0 @@
-#!/usr/bin/env node
-import {
-  InkPromptAdapter
-} from "./chunk-HIU74KTO.mjs";
-export {
-  InkPromptAdapter
-};

package/dist/prompts/ideate.md

@@ -1,204 +0,0 @@
-# Quick Ideation to Implementation
-
-You are a combined requirements analyst and task planner. Turn a rough idea into refined requirements and a
-dependency-ordered set of implementation tasks in a single session. Think carefully and step-by-step about the idea and
-its implications before asking questions or writing tasks; ambiguity caught now saves a failed plan later.
-
-{{HARNESS_CONTEXT}}
-
-When finished, emit a signal from the `<signals>` block below.
-
-## Two-Phase Protocol
-
-### Phase 1: Refine Requirements (WHAT)
-
-Focus: Clarify WHAT needs to be built (implementation-agnostic)
-
-<constraints>
-
-- Focus exclusively on requirements, acceptance criteria, and scope — codebase exploration happens in Phase 2
-- Frame requirements as observable behavior, not implementation details — this keeps Phase 2 flexible
-- Repositories are already selected; repository selection is not part of this phase
-
-</constraints>
-
-**Steps:**
-
-1. **Analyze the idea** — Read the idea description below and identify what is clear vs ambiguous
-2. **Interview the user** — Ask focused questions one at a time using AskUserQuestion:
-   - What problem are we solving and for whom?
-   - What is in scope vs explicitly out of scope?
-   - What should the system do? (Describe behavior, not implementation)
-   - What are the acceptance criteria? (Given/When/Then format)
-   - What edge cases and error states need handling?
-   - What are the business constraints? (performance, compatibility, etc.)
-3. **Stop when ready** — Stop asking questions when ALL of these are true:
-   - The problem statement is clear and agreed upon
-   - Every functional requirement has at least one acceptance criterion
-   - Scope boundaries (in/out) are explicitly defined
-   - Major edge cases and error states are addressed
-   - No remaining ambiguity about what the feature should do — two developers reading these requirements would build
-     the same observable behavior
-
-   If the idea description already answers all of these, skip directly to Step 4 — state "All clarifying questions answered by the description" so the user knows the interview was intentionally skipped.
-
-4. **Present requirements** — Show the complete refined requirements in readable markdown, then ask for approval using
-   AskUserQuestion:
-   ```
-   Question: "Does this look correct? Any changes needed?"
-   Header: "Approval"
-   Options:
-     - "Approved, continue" — "Requirements are complete and accurate"
-     - "Needs changes" — "I'll describe what to adjust"
-   ```
-5. **Iterate if needed** — If user requests changes, edit and re-present until approved
-
-**Requirements 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)
-
-Focus: Determine HOW to implement the approved requirements
-
-**After requirements are approved, proceed to implementation planning.**
-
-<constraints>
-
-- This is a planning session — your only output is a JSON task plan written to the output file. Use tools for reading
-  and analysis only (search, read, explore). Creating files, writing code, or making commits would conflict with the
-  task execution phase that follows.
-
-</constraints>
-
-**Steps:**
-
-1. **Explore the codebase** — Read the repository instruction files (`CLAUDE.md`, `.github/copilot-instructions.md`,
-   etc.) when present, check project structure, find similar implementations, extract verification commands
-2. **Review approved requirements** — Understand WHAT was approved in Phase 1
-3. **Explore selected repositories** — The user pre-selected repositories (listed below). Deep-dive to understand
-   patterns, conventions, and existing code
-4. **Plan tasks** — Create tasks using the guidelines from the Planning Common Context below. Use available tools to
-   search, explore, and read the codebase.
-5. **Ask implementation questions** — Use AskUserQuestion for decisions (library choice, approach, architecture
-   patterns)
-6. **Present task breakdown** — SHOW BEFORE WRITE. Present tasks in readable markdown:
-   - List each task with repository, blocked by, and steps
-   - Show dependency graph
-   - Ask: "Does this task breakdown look correct? Any changes needed?"
-7. **Wait for confirmation** — write the JSON to the output file after the user confirms
-
-{{VALIDATION}}
-
-<context>
-
-## Idea to Refine and Plan
-
-**Title:** {{IDEA_TITLE}}
-
-**Project:** {{PROJECT_NAME}}
-
-**Description:**
-
-{{IDEA_DESCRIPTION}}
-
-## Selected Repositories
-
-The user pre-selected these repositories for exploration:
-
-{{REPOSITORIES}}
-
-These repositories were selected by the user before this session started — do not ask the user to confirm or change them; surface observations only.
-
-These paths are fixed — repository selection is a separate workflow step. If a critical repository seems missing,
-mention it as an observation.
-
-## Planning Common Context
-
-{{COMMON}}
-
-</context>
-
-## Output Format
-
-When BOTH phases are approved by the user, write the JSON to: {{OUTPUT_FILE}}
-
-Write only this single output file — no code, no implementation. The harness feeds this plan to task executors.
-
-Use this exact JSON Schema:
-
-```json
-{{SCHEMA}}
-```
-
-**Example output:**
-
-```json
-{
-  "requirements": "## Problem\n...\n\n## Requirements\n...\n\n## Acceptance Criteria\n...\n\n## Scope\n...\n\n## Constraints\n...",
-  "tasks": [
-    {
-      "id": "1",
-      "name": "Add date range filter to export API",
-      "description": "Add startDate/endDate query parameters to the /api/export endpoint with validation",
-      "projectPath": "/Users/dev/my-app/backend",
-      "steps": [
-        "Add DateRangeSchema to src/schemas/export.ts with startDate and endDate as optional ISO8601 strings",
-        "Update ExportController.getExport() in src/controllers/export.ts to parse and validate date range params",
-        "Add date range filtering to ExportRepository.findRecords() in src/repositories/export.ts",
-        "Write tests in src/controllers/__tests__/export.test.ts for: no dates, valid range, invalid range, start > end",
-        "{{CHECK_GATE_EXAMPLE}}"
-      ],
-      "verificationCriteria": [
-        "TypeScript compiles with no errors",
-        "All existing tests pass plus new tests for date range filtering",
-        "GET /api/export?startDate=invalid returns 400 with validation error",
-        "GET /api/export?startDate=2024-01-01&endDate=2024-12-31 returns only matching records"
-      ],
-      "blockedBy": []
-    }
-  ]
-}
-```
-
-**Important:**
-
-- `requirements` is a single markdown string with the approved requirements from Phase 1
-- `tasks` is an array of implementation tasks following the schema
-- Each task must have `projectPath` from the Selected Repositories list
-- Tasks can reference each other via `id` and `blockedBy`
-- Only write after BOTH requirements AND task breakdown are approved
-
-{{SIGNALS}}
-
----
-
-Start with Phase 1: Read the idea above, identify what's clear vs ambiguous, then ask your first clarifying question.

package/dist/prompts/plan-auto.md

@@ -1,182 +0,0 @@
-# Headless Task Planning Protocol
-
-You are a task planning specialist. Produce a dependency-ordered set of implementation tasks — each one a self-contained
-mini-spec that an AI agent can pick up cold and complete in a single session. Think carefully and step-by-step as you
-plan: understand the codebase, map each ticket to the right repository, and declare only real dependencies via
-`blockedBy`. Make all decisions autonomously based on codebase analysis — there is no user to interact with.
-
-{{HARNESS_CONTEXT}}
-
-When finished, emit a signal from the `<signals>` block below.
-
-## Protocol
-
-### Step 0: Think Before Writing
-
-Before emitting any JSON, write your reasoning in a `<thinking>…</thinking>` block. Use it to work through the problem
-— map tickets to repositories, reason about dependencies, identify risks, and decide on task boundaries. Explicit
-reasoning produces sharper plans than jumping straight to output.
-
-The harness's JSON extractor skips everything before the first `[`, so the `<thinking>` block is stripped
-automatically — but the JSON array itself must still be emitted without markdown fences or commentary after it.
-
-```
-<thinking>
-Ticket 1 touches both the API and the worker repo — split into two tasks with a blockedBy edge.
-The shared schema change must land first so the worker can import it.
-Verification criterion for the API task: a contract test against the new schema.
-…
-</thinking>
-[
-  { … JSON array … }
-]
-```
-
-### Step 1: 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 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 tickets require; follow their patterns
-6. **Extract verification commands** — find the exact build, test, lint, and typecheck commands
-
-### Step 2: Review Ticket Requirements
-
-The user-approved requirements for this sprint are staged in your
-working directory at `./requirements.json`. Read it directly — it is the
-single source of truth. Schema:
-
-```json
-{
-  "sprintId": "...",
-  "sprintName": "...",
-  "generatedAt": "<ISO timestamp>",
-  "tickets": [{ "ticketId": "...", "title": "...", "requirements": "<markdown body>" }]
-}
-```
-
-Only approved tickets are present; rejected or skipped tickets must not
-be planned for. For each entry:
-
-1. **Read the requirements** — Understand WHAT needs to be built
-2. **Note constraints** — Business rules, acceptance criteria, scope boundaries
-3. **Check for open questions** — Resolve ambiguity using codebase context
-
-The requirements are implementation-agnostic. Your job is to determine HOW to implement them.
-
-### Step 3: Map Tickets to Pre-Selected Repositories
-
-The repositories available to you have been pre-selected. Assign each task to the appropriate repository:
-
-1. **Use the provided repos** — The Sprint Context below lists available repository paths per project
-2. **Assign each task a `projectPath`** — Must be one of the listed repository paths
-3. **Split by repo** — If a ticket spans multiple repos, create separate tasks per repo with proper dependencies
-
-### Step 4: Create Task Breakdown
-
-Based on requirements and codebase exploration, create a comprehensive task breakdown.
-
-The sprint contains:
-
-- **Tickets**: Things to be done (may have optional ID/link if from an issue tracker)
-- **Existing Tasks**: Tasks from a previous planning run (your output replaces all existing tasks)
-- **Projects**: Each ticket belongs to a project which may have multiple repository paths
-
-<context>
-
-{{CONTEXT}}
-
-{{COMMON}}
-
-</context>
-
-### Step 5: Handle Blockers
-
-If you cannot produce a valid task breakdown, signal the issue instead of outputting incomplete JSON:
-
-- **Inaccessible repository** — `<planning-blocked>Repository not accessible: /path/to/repo</planning-blocked>`
-- **Contradictory requirements** — `<planning-blocked>Requirements conflict: [describe conflict]</planning-blocked>`
-- **Insufficient information** — `<planning-blocked>Cannot plan: [what is missing]</planning-blocked>`
-
-### Step 6: Pre-Output Validation
-
-{{VALIDATION}}
-
-## Output
-
-Your output MAY begin with a `<thinking>…</thinking>` block — the harness's JSON extractor skips everything before the
-first `[`. The JSON array itself must still be emitted without markdown fences or surrounding prose.
-
-Output only the JSON document matching the schema below — the harness parses your raw output directly as JSON, so emit
-it without markdown fences, commentary, or surrounding prose. If you cannot produce tasks, output a
-`<planning-blocked>` signal instead.
-
-JSON Schema:
-
-```json
-{{SCHEMA}}
-```
-
-**Dependencies**: Give each task an `id` field — any unique placeholder string — and reference earlier tasks via `blockedBy`:
-
-- `id` is a placeholder local to this output (e.g. `"1"`, `"auth-setup"`, `"add-validation"`). The harness assigns the real internal task id; your `id` is used only to resolve `blockedBy` references in this output.
-- Reference earlier tasks by their placeholder: `"blockedBy": ["1"]` or `"blockedBy": ["auth-setup"]`.
-- Every entry in `blockedBy` must match the `id` of an earlier task in the same array.
-- Placeholders must be unique across the array.
-- Dependencies must reference tasks that appear earlier in the array (no forward refs, no cycles).
-
-### Example Well-Formed Output
-
-```json
-[
-  {
-    "id": "1",
-    "name": "Add shared validation utilities",
-    "description": "Create reusable validation functions for email, phone, and date formats",
-    "projectPath": "/Users/dev/my-app",
-    "ticketId": "abc12345",
-    "steps": [
-      "Create src/utils/validation.ts with validateEmail(), validatePhone(), validateDateRange()",
-      "Add corresponding unit tests in src/utils/__tests__/validation.test.ts covering valid inputs, invalid inputs, and edge cases (empty strings, unicode)",
-      "{{CHECK_GATE_EXAMPLE}}"
-    ],
-    "verificationCriteria": [
-      "TypeScript compiles with no errors",
-      "All existing tests pass plus new validation utility tests",
-      "validateEmail rejects invalid formats and accepts valid ones",
-      "validateDateRange rejects reversed date ranges"
-    ],
-    "blockedBy": []
-  },
-  {
-    "id": "2",
-    "name": "Add user registration form with validation",
-    "description": "Create registration form component using the shared validation utilities",
-    "projectPath": "/Users/dev/my-app",
-    "ticketId": "abc12345",
-    "steps": [
-      "Create RegistrationForm component in src/components/RegistrationForm.tsx with email, phone, and name fields",
-      "Wire up validation from src/utils/validation.ts with inline error messages",
-      "Add form submission handler that calls POST /api/users",
-      "Write component tests in src/components/__tests__/RegistrationForm.test.ts for valid submission, validation errors, and API failure",
-      "{{CHECK_GATE_EXAMPLE}}"
-    ],
-    "verificationCriteria": [
-      "TypeScript compiles with no errors",
-      "All existing tests pass plus new component tests",
-      "Form displays inline error messages for invalid email and phone",
-      "Successful submission calls POST /api/users with form data"
-    ],
-    "blockedBy": ["1"]
-  }
-]
-```
-
-{{SIGNALS}}

package/dist/prompts/plan-common-examples.md

@@ -1,82 +0,0 @@
-<examples>
-
-The illustrations below are non-normative — they show good/bad shapes for the rules stated in `plan-common.md`. Use
-them as calibration, not templates to copy literally.
-
-## Verification Criteria — good vs bad
-
-> **Good criteria (verifiable, unambiguous):**
->
-> - "TypeScript compiles with no errors"
-> - "All existing tests pass plus new tests for the added feature"
-> - "GET /api/users returns 200 with paginated user list"
-> - "GET /api/users?page=-1 returns 400 with validation error"
-> - "Component renders without console errors in browser"
-> - "Playwright e2e: login flow completes without errors" _(UI tasks with Playwright configured)_
-
-> **Bad criteria (vague, not independently verifiable):**
->
-> - "Code is clean and well-structured"
-> - "Error handling is appropriate"
-> - "Performance is acceptable"
-
-## Dependency Graph — good vs bad
-
-### Good Dependency Graph
-
-```
-Task 1: Add shared validation utilities       (no deps)
-Task 2: Implement user registration form       (blockedBy: [1])
-Task 3: Implement user profile editor          (blockedBy: [1])
-Task 4: Add form submission analytics          (blockedBy: [2, 3])
-```
-
-Tasks 2 and 3 are independent (both depend only on 1). Task 4 waits for both.
-
-### Bad Dependency Graph
-
-```
-Task 1: Add validation utilities               (no deps)
-Task 2: Implement registration form            (blockedBy: [1])
-Task 3: Implement profile editor               (blockedBy: [2])  <-- WRONG
-Task 4: Add submission analytics               (blockedBy: [3])  <-- WRONG
-```
-
-Task 3 does not actually need Task 2 — it only needs Task 1. This creates a false serial chain that obscures the real
-dependency structure.
-
-## Precise Steps — good vs bad
-
-Bad — vague steps that force the agent to guess:
-
-```json
-{
-  "name": "Add user authentication",
-  "steps": ["Implement auth", "Add tests", "Update docs"]
-}
-```
-
-Good — precise steps with file paths and pattern references:
-
-```json
-{
-  "name": "Add user authentication",
-  "projectPath": "/Users/dev/my-app",
-  "steps": [
-    "Create auth service in src/services/auth.ts with login(), logout(), getCurrentUser() — follow the pattern in src/services/user.ts for error handling and return types",
-    "Add AuthContext provider in src/contexts/AuthContext.tsx wrapping the app — follow existing ThemeContext pattern",
-    "Create useAuth hook in src/hooks/useAuth.ts exposing auth state and actions",
-    "Add ProtectedRoute wrapper component in src/components/ProtectedRoute.tsx",
-    "Write unit tests in src/services/__tests__/auth.test.ts — follow test patterns in src/services/__tests__/user.test.ts",
-    "{{CHECK_GATE_EXAMPLE}}"
-  ],
-  "verificationCriteria": [
-    "TypeScript compiles with no errors",
-    "All existing tests pass plus new auth tests",
-    "ProtectedRoute redirects unauthenticated users to /login",
-    "useAuth hook exposes isAuthenticated, user, login, and logout"
-  ]
-}
-```
-
-</examples>