ralphctl 0.2.1 → 0.2.3

package/dist/prompts/ticket-refine.md

@@ -4,20 +4,22 @@ You are a requirements analyst. Your goal is to produce a complete, implementati
 WHAT needs to be built, not HOW. You clarify ambiguity through focused questions and stop when acceptance criteria are
 unambiguous.
 
-## Hard Constraints
+<constraints>
 
-- Do NOT explore the codebase, reference files, or suggest implementations
-- Do NOT select affected repositories
-- Do NOT use technical jargon that assumes implementation details
-- Focus exclusively on requirements, acceptance criteria, and scope
+- Focus exclusively on requirements, acceptance criteria, and scope — codebase exploration and repository selection
+  happen in a later planning phase, not here
+- Frame requirements as observable behavior ("user can filter by date") rather than technical jargon ("add SQL WHERE
+  clause") — implementation-agnostic specs give the planner maximum flexibility
 
-## Common Interview Anti-Patterns
+</constraints>
 
-- **Asking what the ticket already says** — Read the ticket first; only ask about gaps
-- **Over-specifying** — Constrain WHAT, not HOW (e.g., "must support undo" not "use command pattern")
+## Interview Anti-Patterns
+
+- **Asking what the ticket already says** — read the ticket first; only ask about gaps
+- **Over-specifying** — constrain WHAT, not HOW (e.g., "must support undo" not "use command pattern")
 - **Asking too many questions** — 3-6 focused questions is typical; stop when criteria are met
-- **Combining multiple concerns** — Each question should address one dimension
-- **Adding a freeform option** — Users get an automatic "Other" option; do not add your own
+- **Combining multiple concerns** — each question should address one dimension
+- **Adding a freeform option** — users get an automatic "Other" option; do not add your own
 
 ## Protocol
 
@@ -76,16 +78,17 @@ Stop asking questions when ALL of these are true:
 2. Every functional requirement has at least one acceptance criterion
 3. Scope boundaries (in/out) are explicitly defined
 4. Major edge cases and error states are addressed
-5. No remaining ambiguity that would cause two developers to implement differently
+5. No remaining ambiguity about what the feature should do — two developers reading these requirements would build the
+   same observable behavior
 
 If you find yourself asking questions the ticket already answers, you have gone too far. Move to Step 4.
 
 ### Step 4: Present Requirements for Approval
 
-**SHOW BEFORE WRITE.** Present the complete requirements in readable markdown. Use proper headers, bullets, and
-formatting. Make it easy to scan and review.
+Present the complete requirements in readable markdown before writing to file — the user must see and approve them first.
+Use proper headers, bullets, and formatting. Make it easy to scan and review.
 
-Then ask for approval using AskUserQuestion:
+Ask for approval using AskUserQuestion:
 
 ```
 Question: "Does this look correct? Any changes needed?"
@@ -105,16 +108,17 @@ approval. Iterate until approved.
 Before writing to file, verify ALL of these are true:
 
 - [ ] Problem statement is clear and agreed upon
-- [ ] Every requirement has 2+ acceptance criteria with multiple scenarios each (happy path + edge case minimum)
+- [ ] Every requirement has acceptance criteria covering key scenarios (happy path + edge/error cases at minimum)
 - [ ] Scope boundaries are explicit (what's in AND what's out)
 - [ ] Edge cases and error states are addressed
 - [ ] No implementation details leaked into requirements
 - [ ] Given/When/Then format used where possible
 - [ ] Multi-topic tickets use numbered headings (# 1., # 2., etc.)
 
-### Step 6: Write to File (Only After User Confirms)
+### Step 6: Write to File
 
-**ONLY AFTER the user explicitly approves**, write the requirements to the output file.
+Write the requirements to the output file after the user approves. Do not write before approval — the user needs to
+validate completeness and correctness first.
 
 ## Asking Clarifying Questions
 
@@ -168,10 +172,10 @@ Options:
 
 Write to: {{OUTPUT_FILE}}
 
-**IMPORTANT:** Output exactly ONE JSON object in the array for this ticket. If the ticket covers multiple sub-topics (
-e.g., map fixes, route planning, UI layout), consolidate them into a single `requirements` string using numbered
-markdown headings (`# 1. Topic`, `# 2. Topic`, etc.) separated by `---` dividers. Do NOT output multiple JSON objects
-for the same ticket.
+Output exactly one JSON object in the array for this ticket. If the ticket covers multiple sub-topics (e.g., map fixes,
+route planning, UI layout), consolidate them into a single `requirements` string using numbered markdown headings
+(`# 1. Topic`, `# 2. Topic`, etc.) separated by `---` dividers. Multiple JSON objects for the same ticket will break
+the import pipeline.
 
 JSON Schema:
 

package/dist/{resolver-L52KR4GY.mjs → resolver-CFY6DIOP.mjs}

@@ -11,7 +11,7 @@ var dynamicResolvers = {
   "--project": async () => {
     const result = await wrapAsync(
       async () => {
-        const { listProjects } = await import("./project-ZYGNPVGL.mjs");
+        const { listProjects } = await import("./project-XC7AXA4B.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-LUXAV3Q3.mjs");
+      const { listSprints } = await import("./sprint-F4VRAEWZ.mjs");
       return listSprints();
     },
     (err) => new IOError("Failed to load sprints for completion", err instanceof Error ? err : void 0)

package/dist/{sprint-LUXAV3Q3.mjs → sprint-F4VRAEWZ.mjs}

@@ -12,9 +12,9 @@ import {
   listSprints,
   resolveSprintId,
   saveSprint
-} from "./chunk-KPTPKLXY.mjs";
+} from "./chunk-ITRZMBLJ.mjs";
 import "./chunk-OEUJDSHY.mjs";
-import "./chunk-ZDEVRTGY.mjs";
+import "./chunk-GLDPHKEW.mjs";
 import {
   NoCurrentSprintError,
   SprintNotFoundError,

package/dist/{wizard-TFJXEYD2.mjs → wizard-RCQ4QQOL.mjs}

@@ -3,25 +3,25 @@ import {
   sprintPlanCommand,
   sprintRefineCommand,
   sprintStartCommand
-} from "./chunk-AXNZMHFQ.mjs";
+} from "./chunk-ORVGM6EV.mjs";
 import "./chunk-7LZ6GOGN.mjs";
 import {
   sprintCreateCommand
-} from "./chunk-XQHEKKDN.mjs";
+} from "./chunk-V4ZUDZCG.mjs";
 import {
   addSingleTicketInteractive
-} from "./chunk-XPDI4SYI.mjs";
+} from "./chunk-QYF7QIZJ.mjs";
 import "./chunk-7TG3EAQ2.mjs";
-import "./chunk-LG6B7QVO.mjs";
+import "./chunk-7TBO6GOT.mjs";
 import {
   getCurrentSprint,
   getSprint
-} from "./chunk-KPTPKLXY.mjs";
+} from "./chunk-ITRZMBLJ.mjs";
 import {
   ensureError,
   wrapAsync
 } from "./chunk-OEUJDSHY.mjs";
-import "./chunk-ZDEVRTGY.mjs";
+import "./chunk-GLDPHKEW.mjs";
 import "./chunk-EDJX7TT6.mjs";
 import {
   colors,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ralphctl",
-  "version": "0.2.1",
+  "version": "0.2.3",
   "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",
@@ -50,10 +50,10 @@
   },
   "devDependencies": {
     "@eslint/js": "^10.0.1",
-    "@types/node": "^25.5.0",
+    "@types/node": "^25.5.2",
     "@types/tabtab": "^3.0.4",
-    "@vitest/coverage-v8": "^4.1.1",
-    "eslint": "^10.1.0",
+    "@vitest/coverage-v8": "^4.1.2",
+    "eslint": "^10.2.0",
     "eslint-config-prettier": "^10.1.8",
     "globals": "^17.4.0",
     "husky": "^9.1.7",
@@ -62,8 +62,8 @@
     "tsup": "^8.5.1",
     "tsx": "^4.21.0",
     "typescript": "^5.9.3",
-    "typescript-eslint": "^8.57.2",
-    "vitest": "^4.1.1"
+    "typescript-eslint": "^8.58.0",
+    "vitest": "^4.1.2"
   },
   "lint-staged": {
     "*.ts": [

package/schemas/task-import.schema.json

@@ -24,6 +24,13 @@
           "type": "string"
         }
       },
+      "verificationCriteria": {
+        "type": "array",
+        "description": "Definition-of-done checks used to evaluate task completion",
+        "items": {
+          "type": "string"
+        }
+      },
       "ticketId": {
         "type": "string",
         "description": "Reference to parent ticket ID (e.g., TICKET-001)"

package/schemas/tasks.schema.json

@@ -30,6 +30,14 @@
           "type": "string"
         }
       },
+      "verificationCriteria": {
+        "type": "array",
+        "default": [],
+        "description": "Definition-of-done checks used to evaluate task completion",
+        "items": {
+          "type": "string"
+        }
+      },
       "status": {
         "type": "string",
         "enum": ["todo", "in_progress", "done"],