ADR 0052: Gate Player-Facing Expansion On Human Play

Status

Accepted; amended by ADR 0053.

Context

Lanternworks and Followspot were built as STAGE dogfoods. Both accumulated substantial mechanical evidence: deterministic rules, composed Unity paths, input rehearsals, lifecycle checks, documentation, and clean checkpoints. The owner then played both games and rejected them. They were difficult to understand, had poor UI and interaction design, and were not enjoyable even as prototypes.

The failure was not that the projects lacked enough architecture or polish. STAGE allowed engineering feasibility to create momentum before the player experience had earned expansion. Automated reachability showed that inputs could drive state. It did not show that the ordinary player surface explained the game, that its short loop was engaging, or that the owner wanted to continue.

The Circussy One followed a more productive pattern. The owner repeatedly played the real game, rejected visible or experiential failures, supplied screenshots and concrete observations, tuned exposed configuration, and returned failed experiments to known checkpoints. That loop was costly when diagnosis or scope control was weak, but human play materially redirected the product instead of merely approving an engineering result.

Decision

When work originates a game or materially expands a player-facing loop:

1. Use the human-led dialogue in ADR 0053 to obtain approval of a small experience hypothesis covering player fantasy, core verbs, intended experience, first-minute comprehension, the short loop, success, failure, and stop conditions.
2. Build the smallest complete loop through the real player surface, including the information and feedback needed to understand it.
3. Have the accountable human play that loop and record separate categorical findings for comprehension, usability, engagement, and desire to continue.
4. Treat the gate as accepted, blocked, or not tested.
5. While blocked or not tested, permit bounded diagnosis and iteration but block broad architecture, modes, content multiplication, polish programs, and transferability claims based on that loop.
6. Reopen the gate when a material design change invalidates the accepted basis.

This is recommended delivery guidance, not a universal Safety Kernel requirement. It does not apply to every bug fix, refactor, or content edit. Formal case studies use schema 0.4 when they need a durable structured record; ordinary game work does not require an artifact.

The solo owner is a valid human gatekeeper. ADR 0053 clarifies the preceding design-authority boundary: agents may research, model, critique, and, when explicitly delegated, draft hypotheses, but the intended experience requires human approval before broad implementation. Agents may not grant human product acceptance or infer it from open-ended permission to keep working.

Consequences

• Technically successful but experientially rejected prototypes stop before their assumptions spread through more systems and content.
• A thin complete loop must include comprehension and feedback, not only rules and architecture.
• Agents can continue productive diagnosis while the gate is blocked, but the allowed branch is intentionally narrow.
• Owner attention is required at a high-leverage boundary rather than after a large autonomous build.
• Acceptance remains project-local and may be revised; it does not establish objective fun, market fit, or method transferability.
• The method gains another conditional branch, so the installed guidance must keep it concise and avoid turning ordinary maintenance into ceremony.

Evidence Boundary

This decision is supported by direct owner rejection of two same-director Unity dogfoods and the contrasting correction history of one origin project. It is strong evidence that STAGE's previous dogfood control was insufficient for this owner's workflow. It is not an independent controlled comparison and does not prove that the four dimensions or this exact gate generalize to every designer, team, genre, or production phase.