0019: Require Earned Infrastructure

Status: Accepted

The ordered "escalation ladder" wording below is superseded by ADR 0034. Its trigger, ownership, consumer, and retirement rules remain accepted; the responses are non-linear capabilities rather than maturity steps.

Context

Agentic development makes infrastructure unusually cheap to propose and build. That changes the failure mode: a project can acquire a polished browser, generator, abstraction, operation wrapper, evidence pipeline, or dashboard before anyone has shown that it improves a real recurring decision.

The first STAGE visual workflow demonstrated this directly. Its detached capture and contact-sheet pipeline was deterministic, validated, and broad, but it was less useful than inspecting the real content in Unity. The tooling optimized what was easy for the agent to produce instead of what was useful for the human to judge. Moving the recurring Enemy Arrival question into the game made the loop shorter, more truthful, and easier to tune.

The same risk exists outside visual work. A diagnostic console can precede an observable failure, an authoring tool can precede repeated authoring pain, a generic abstraction can precede duplication, and an agent operation can precede a stable human workflow. Testability and polish do not by themselves justify the maintenance surface.

Decision

STAGE uses Earned Infrastructure: reusable infrastructure is introduced only after a direct project-native workflow exposes recurring decision cost, risk, or inconsistency that the infrastructure is expected to reduce.

Use this escalation ladder:

1. Direct path - use the canonical engine, project, or product surface for the concrete task.
2. Local aid - use temporary instrumentation or a disposable helper to make one bounded question observable.
3. Persistent project tool - retain a scenario, diagnostic, authoring tool, abstraction, or fixture only when the workflow recurs, setup is expensive, or repeated inconsistency has been observed.
4. Stable operation - expose callable human or agent operation only after ownership, readiness, failure, reset, and teardown semantics are understood.
5. Durable evidence or integration - add export, CI, baseline, middleware, or cross-project packaging only for a named consumer and retention need.
6. Product surface - ship a gallery, codex, editor, or other player-facing form only when it has product value independent of development convenience.

Before moving up the ladder, record:

• the recurring question or workflow;
• the observed cost, failure, or inconsistency;
• the owner and canonical source the infrastructure will preserve;
• the narrower direct path that was tried first;
• the claim that will show the new surface reduced correction or oversight cost; and
• how the surface can be simplified or retired if it does not.

An agent may identify a likely recurring need and propose the next level. It must not promote the proposal into an observed requirement merely because it can implement or validate it. A human may deliberately invest ahead of demand, but that is an explicit product or workflow decision rather than inferred method conformance.

This decision does not prohibit foundations, tests, or proactive design. It requires their scope to match demonstrated pressure and keeps speculative reuse separate from current necessity.

Consequences

• STAGE evaluates tools by reduced decision and correction cost, not artifact count or implementation sophistication.
• Direct engine and product surfaces remain first-class even when a custom tool would be easy to generate.
• Persistent helpers begin with one real recurring workflow and expand only after dogfooding.
• Agent APIs follow stable human workflows instead of inventing parallel lifecycles for automation.
• Optional infrastructure may remain absent without lowering project maturity or STAGE conformance.
• Failed infrastructure experiments become reusable lessons and can be retired without discarding the production knowledge they revealed.