ralphctl 0.3.0 → 0.4.0

package/dist/prompts/plan-common.md

@@ -29,10 +29,28 @@ verification criteria and the codebase?" If not, the task needs work.
 
 ### Task Sizing
 
-Completable in a single AI session: 1-3 primary files (up to 5-7 total with tests), ~50-200 lines of meaningful
-changes, one logical change per task. Split if too large, merge if too small.
+The unit is **one coherent feature or vertical slice** — a change that can be picked up cold, implemented in a single
+session, and verified end-to-end against its criteria. Size is driven by coherence, not line count. Modern agents are
+capable; artificial fragmentation creates serial chains, duplicate context reloads, and merge conflicts that cost far
+more than they save.
 
-Too granular (three tasks that should be one):
+**Do not split when:**
+
+- A utility and its first caller would be separated — create-and-use is always one task
+- A feature and its tests would be separated
+- The same pattern applies across N call sites — it is one refactor, not N tasks
+
+**Do split when:**
+
+- Two chunks can run in parallel (different `projectPath`, or independent files with no shared contract)
+- A clean, verifiable boundary exists partway through (e.g. schema + migration land first, then consumer wiring — the
+  schema is independently testable and unblocks parallel consumers)
+- The change spans multiple repositories — one task per repo, connected via `blockedBy`
+
+**Soft ceiling, not a target:** if a task looks like it will touch more than ~10 files or ~500 lines of meaningful
+change AND a natural split point exists, split it. No natural split point? Keep it whole.
+
+Too granular (one task, not three):
 
 - "Create date formatting utility"
 - "Refactor experience module to use date utility"
@@ -91,7 +109,8 @@ the evaluator will attempt visual verification using Playwright or browser tools
 
 1. **Outcome-oriented** — Each task delivers a testable result
 2. **Merge create+use** — Never separate "create X" from "use X" — that is one task
-3. **Target 5-15 tasks** per scope, not 20-30 micro-tasks
+3. **Let scope drive task count** — do not aim for a specific number. Fewer, larger coherent tasks beat many
+   micro-tasks; split only when parallelism or a clean boundary justifies it
 4. **Merge serial chains** — If tasks only make sense when run in sequence, fold them into one task
 
 ### Anti-Patterns

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

@@ -11,7 +11,12 @@ When finished, emit a signal from the `<signals>` block below.
 
 - **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.
-- **Fix, don't rewrite** — make minimal targeted changes; preserve the existing implementation structure where possible.
+- **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.
 

package/dist/prompts/validation-checklist.md

@@ -7,7 +7,7 @@ Before writing the JSON output, verify EVERY item:
 3. **Foundations before dependents** — tasks are ordered so prerequisites come first
 4. **Valid dependencies** — every `blockedBy` reference points to an earlier task with a real code dependency
 5. **Maximized parallelism** — independent tasks run in parallel; use `blockedBy` only when there is a genuine code dependency
-6. **Precise steps** — every task has 3+ specific, actionable steps with file references
+6. **Precise steps** — every task has specific, actionable steps with file references — as many as the scope needs (a small task may have 2 steps, a larger coherent one may have 8+)
 7. **Verification steps** — every task ends with project-appropriate verification commands
 8. **`projectPath` assigned** — every task uses a path from the available repositories
 9. **Verification criteria** — every task has 2-4 `verificationCriteria` that are testable and unambiguous

package/dist/{start-MMWC7QLI.mjs → start-D35SOXMM.mjs}

@@ -2,8 +2,8 @@
 import {
   parseSprintStartArgs,
   sprintStartCommand
-} from "./chunk-CDOPLXFK.mjs";
-import "./chunk-HL4ZMHCQ.mjs";
+} from "./chunk-JYCGQA2D.mjs";
+import "./chunk-JOQO4HMM.mjs";
 import "./chunk-CFUVE2BP.mjs";
 import "./chunk-747KW2RW.mjs";
 import "./chunk-YCDUVPRT.mjs";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ralphctl",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "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",