ralphctl 0.8.0 → 0.8.1

package/dist/manifest.json

@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "generatedAt": "2026-05-24T20:04:47.241Z",
+  "generatedAt": "2026-05-25T15:37:20.381Z",
   "assets": [
     "prompts/_partials/decisions.md",
     "prompts/_partials/harness-context.md",
@@ -18,6 +18,7 @@
     "prompts/refine/template.md",
     "skills/ralphctl-abstraction-first/SKILL.md",
     "skills/ralphctl-alignment/SKILL.md",
-    "skills/ralphctl-iterative-review/SKILL.md"
+    "skills/ralphctl-iterative-review/SKILL.md",
+    "skills/ralphctl-minimal-scaffolding/SKILL.md"
   ]
 }

package/dist/prompts/detect-scripts/template.md

@@ -30,6 +30,13 @@ lift it verbatim. Prefer this over any inference from manifest scripts.
 entries). **Monorepos**: inspect the root manifest and one or two representative sub-modules to
 confirm the stack, then propose root-level commands that build/verify the whole tree.
 
+**Non-interactive flags for JVM stacks.** The harness captures the script's combined stdout/stderr
+to a plain-text log file. Maven, Gradle, and sbt emit ANSI colour codes by default that render
+poorly there. When proposing a command for one of these tools, append the standard non-interactive
+flag — `mvn -B …`, `gradle --console=plain …`, `sbt -no-colors …` — unless the project's own docs
+prescribe a different invocation. Modern Node / Python / Rust tooling respects `NO_COLOR` which the
+harness sets automatically, so no per-tool flag is needed there.
+
 **Polyglot monorepos.** When sub-trees use different toolchains, chain each sub-tree's command so
 the harness prepares / verifies every half from the repo root. Use `&&` so the first failure stops
 the chain. Prefer each tool's own directory flag over `cd … &&` so the line stays portable; fall
@@ -74,6 +81,15 @@ When only a manifest exists with install + test scripts and no context file:
 <note>No context file found; commands inferred from package.json scripts.</note>
 ```
 
+When a JVM build descriptor (e.g. `pom.xml`) drives the project and `CLAUDE.md` names install +
+verify steps:
+
+```
+<setup-script>mvn -B -DskipTests install</setup-script>
+<verify-script>mvn -B verify</verify-script>
+<note>Commands lifted from CLAUDE.md; -B disables interactive prompts and ANSI colour for clean persisted logs.</note>
+```
+
 </example>
 
 ## Repository Context

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

@@ -0,0 +1,58 @@
+---
+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.
+---
+
+# 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."
+>
+> — Anthropic, _Harness Design for 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.
+
+## 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.
+
+## 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.
+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.
+- **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.

package/package.json

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