ralphctl-minimal-scaffoldinglisted

# 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 evalu