ralphctl 0.15.0 → 0.16.0

package/dist/cli.mjs

@@ -2,5 +2,5 @@
 
 // src/index.ts
 process.env.NODE_ENV ??= "production";
-var { runCli } = await import("./cli-CKPJ5SY4.mjs");
+var { runCli } = await import("./cli-KZ4IYDKB.mjs");
 await runCli(process.argv);

package/dist/manifest.json

@@ -1,7 +1,10 @@
 {
-  "version": 1,
-  "generatedAt": "2026-07-03T20:19:33.217Z",
+  "schemaVersion": 1,
+  "packageVersion": "0.16.0",
+  "generatedAt": "2026-07-18T13:59:00.834Z",
   "assets": [
+    "agent-definitions/ralphctl-evaluator.md",
+    "agent-definitions/ralphctl-generator.md",
     "prompts/_partials/conventions-agents-md.md",
     "prompts/_partials/conventions-claude-md.md",
     "prompts/_partials/conventions-copilot-instructions.md",

package/dist/prompts/evaluate/template.md

@@ -75,6 +75,8 @@ output contract section at the bottom of this prompt.
 
 </success_criteria>
 
+{{AGENT_DEFINITION_SECTION}}
+
 <task_specification>
 
 **Task:** {{TASK_NAME}}

package/dist/prompts/implement/template.md

@@ -35,6 +35,8 @@ only after every declared step is done and every verification command passes.
 
 </success_criteria>
 
+{{AGENT_DEFINITION_SECTION}}
+
 <inputs>
 
 ## Task

package/dist/skills/ralphctl-minimal-scaffolding/SKILL.md

@@ -1,58 +1,59 @@
 ---
 name: ralphctl-minimal-scaffolding
-description: Cross-phase skill — question every harness component on every model bump; remove non-load-bearing pieces one at a time with measurement. Complexity drifts upward by default; subtraction requires discipline. Governs the surrounding harness's own scaffolding, not the task's application code — for code-level minimalism defer to the ralphctl-ponytail, ralphctl-surgical-simplicity, and ralphctl-karpathy-guidelines skills when installed in this session.
+description: Cross-phase skill — question every piece of AI-workflow scaffolding on every model upgrade; remove non-load-bearing pieces one at a time with measurement. Complexity drifts upward by default; subtraction requires discipline. Governs scaffolding built around AI usage (prompts, wrapper scripts, guardrails, validation steps), not the task's application code — for code-level minimalism defer to the ralphctl-ponytail, ralphctl-surgical-simplicity, and ralphctl-karpathy-guidelines skills when installed in this session.
 ---
 
 # Minimal Scaffolding
 
 > "Find the simplest solution possible, and only increase complexity when needed. Every component encodes
 > assumptions about model limitations. Stress-test assumptions; they can go stale quickly as models improve.
-> Remove one component at a time when simplifying. Re-examine entire harness when new model releases; strip
-> non-load-bearing pieces."
+> Remove one component at a time when simplifying. Re-examine the whole system when a new model releases;
+> strip non-load-bearing pieces."
 >
 > — Anthropic, [_Harness Design for Long-Running Application Development_](https://www.anthropic.com/engineering/harness-design-long-running-apps)
 
-Harness complexity drifts upward. Each component that solves a real problem at the time of its addition
-becomes a permanent fixture — even after the model capability that made it necessary has improved past the
-threshold. Without an active counter-pressure, the harness grows into a weight that slows iteration and
-obscures the actual design signal. Minimal scaffolding is not a one-time decision at design time; it is a
-discipline applied on every model release and on every proposed addition.
+Scaffolding built around AI usage — prompts, wrapper scripts, extra validation steps, guardrails — drifts
+upward in complexity by default. Each piece that solves a real problem at the time of its addition becomes a
+permanent fixture, even after the model capability that made it necessary has improved past the threshold.
+Without an active counter-pressure, the scaffolding grows into a weight that slows iteration and obscures the
+actual design signal. Minimal scaffolding is not a one-time decision at design time; it is a discipline
+applied on every model upgrade and on every proposed addition.
 
 ## When this applies
 
-- **Refine** — before proposing that the refine phase needs a new guard, new evaluator, or new validation
-  step, ask whether the model would produce the right output without it given a well-scoped prompt.
-- **Plan** — before adding a new planning sub-agent or splitting a flow into more phases, ask whether the
-  additional structure would improve output quality measurably, or whether it is defensive scaffolding
-  against a past model's limitations.
-- **Execute** — before wiring a new chain primitive, a new leaf, or a new wrapper around the evaluator, ask
-  which assumption about current model capability the addition encodes, and whether that assumption is still
-  valid.
+- **Refine** — before proposing that the requirements need an extra review gate, an extra validation pass,
+  or an approval step to compensate for the model, ask whether the model would produce the right output
+  without it given a well-scoped prompt.
+- **Plan** — before adding an extra AI-assisted review step or splitting the work into more stages, ask
+  whether the additional structure would improve output quality measurably, or whether it is defensive
+  scaffolding against a past model's limitations.
+- **Execute** — before wiring a new wrapper, guard clause, or retry layer around an existing AI-assisted
+  check, ask which assumption about current model capability the addition encodes, and whether that
+  assumption is still valid.
 
 ## What to do
 
 1. **Start with the simplest viable shape.** Draft the simplest version that could work given today's model
    capability. Only add components when the simple version demonstrably fails.
-2. **Question every component on every model bump.** When a new model version ships, re-read
-   `HARNESS-PRINCIPLES.md` § 14 and § 18 in the project's `.claude/docs/` directory. For each `applied` row,
-   ask: "Would removing this component degrade output quality on the new model?" If the answer is uncertain,
-   run the test.
-3. **Remove one component at a time, measure.** Never refactor two components simultaneously — you cannot
-   isolate the regression. Remove one; run the project's check gate; observe output quality; decide.
+2. **Question every component on every model upgrade.** When a new model version ships, re-read the
+   project's own notes on why each piece of AI-workflow scaffolding exists, if the project keeps them. For
+   each one, ask: "Would removing this component degrade output quality on the new model?" If the answer is
+   uncertain, run the test.
+3. **Remove one component at a time, measure.** Never remove two pieces of scaffolding simultaneously — you
+   cannot isolate the regression. Remove one; run the project's check gate; observe output quality; decide.
 4. **Default toward subtraction over addition.** When in doubt, omit. Adding a component later when its
    need is proven is cheaper than carrying a component whose need was assumed.
 
 ## Anti-patterns
 
-- **Stacking primitives "just in case".** Adding a `guard` around the evaluator, a `loop` around the guard,
-  and a retry decorator around the loop — each layer may have been justified at the time, but the stack
-  encodes four separate assumptions, each of which needs re-validation on every model bump.
-- **Treating scaffolding as load-bearing without measurement.** "We've always had the idle watchdog" is not
-  a reason to keep it — it is a reason to measure whether it still fires in practice. If it never fires on
-  the current model, it may be removable.
-- **Mass refactors that change more than one component at a time.** Removing the plateau detector and the
-  idle watchdog in the same PR makes it impossible to attribute a quality change to either. One component
-  at a time.
+- **Stacking guardrails "just in case".** Adding a validation wrapper around a check, a retry loop around
+  the wrapper, and a review gate around the retry loop — each layer may have been justified at the time, but
+  the stack encodes several separate assumptions, each of which needs re-validation on every model upgrade.
+- **Treating scaffolding as load-bearing without measurement.** "We've always had this check" is not a
+  reason to keep it — it is a reason to measure whether it still fires in practice. If it never fires on the
+  current model, it may be removable.
+- **Mass refactors that change more than one piece of scaffolding at a time.** Removing two guardrails in
+  the same change makes it impossible to attribute a quality change to either. One piece at a time.
 - **Never re-auditing existing scaffolding when models get better.** Capability improvements accrue quietly.
   A component that was essential for an older model may be transparently handled by a newer one. Without an
-  explicit re-audit cadence, the harness ossifies around old assumptions.
+  explicit re-audit cadence, AI-workflow scaffolding ossifies around old assumptions.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ralphctl",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "description": "Agent harness for long-running AI coding tasks — orchestrates Claude Code, GitHub Copilot, and OpenAI Codex across repositories",
   "homepage": "https://github.com/lukas-grigis/ralphctl",
   "type": "module",
@@ -45,34 +45,34 @@
   "dependencies": {
     "commander": "^15.0.0",
     "cross-spawn": "^7.0.6",
-    "ink": "^7.0.3",
+    "ink": "^7.1.1",
     "proper-lockfile": "^4.1.2",
-    "react": "^19.2.6",
+    "react": "^19.2.7",
     "typescript-result": "^3.5.2",
     "zod": "^4.4.3"
   },
   "devDependencies": {
     "@eslint/js": "^10.0.1",
     "@types/cross-spawn": "^6.0.6",
-    "@types/node": "^26.0.0",
+    "@types/node": "^26.1.1",
     "@types/proper-lockfile": "^4.1.4",
-    "@types/react": "^19.2.14",
-    "@vitest/coverage-v8": "^4.1.6",
+    "@types/react": "^19.2.17",
+    "@vitest/coverage-v8": "^4.1.10",
     "eslint": "^10.4.0",
     "eslint-plugin-react-hooks": "^7.1.1",
     "eslint-plugin-sonarjs": "^4.0.3",
-    "globals": "^17.6.0",
+    "globals": "^17.7.0",
     "husky": "^9.1.7",
     "ink-testing-library": "^4.0.0",
     "jiti": "^2.7.0",
-    "knip": "^6.14.1",
-    "lint-staged": "^17.0.5",
-    "prettier": "^3.8.3",
+    "knip": "^6.27.0",
+    "lint-staged": "^17.0.8",
+    "prettier": "^3.9.5",
     "tsup": "^8.5.1",
-    "tsx": "^4.22.1",
+    "tsx": "^4.23.1",
     "typescript": "^6.0.3",
     "typescript-eslint": "^8.59.3",
-    "vitest": "^4.1.6"
+    "vitest": "^4.1.10"
   },
   "lint-staged": {
     "*.{ts,tsx}": [