Cross-Project Case-Study Synthesis

Scope

This synthesis compares STAGE's origin project, two same-director longitudinal dogfood projects, and four independent external projects:

Project	Shape	Runtime style	Study evidence
The Circussy One	Large, systems-heavy Unity game	Explicit composition, systems, authored definitions, Unity shell	Origin history, adoption, repeated runtime diagnosis and human correction
Lanternworks	Fresh systems-heavy Unity game	Deterministic simulation, ports and adapters, VContainer, authored Unity shell	Engineering operations passed; owner rejected comprehension, UI, design, and fun
Followspot	Small direct Unity game	Direct MonoBehaviours, pure show rules, authored scene and UI	Engineering operations passed; owner rejected comprehension, UI, design, and fun
Copperfall	Small custom browser game	JavaScript scene objects and canvas runtime	External map and operational browser smoke
Blopsqwash	Tiny project-owned Unity game inside a large imported tree	Two MonoBehaviours plus engine assets	External map and static binding audit
Godot Open RPG	Medium engine-native Godot project	Scenes, Nodes, Resources, signals, and autoloads	Exact-editor import and bounded runtime smoke
Fish Folk: Jumpy	Medium data-driven Rust game	Bones Sessions/worlds, schemas, scheduled systems, Bevy renderer	Format/metadata checks, pinned CI, hosted-web observation

The independent studies test whether STAGE can describe and operate materially different projects without turning The Circussy One's architecture into a universal template. Lanternworks tests whether the personal Solo Unity profile can survive repeated implementation, composition, and authoring work in a fresh project. Followspot tests whether ordinary project-native delivery remains proportional without a framework. Both same-director game dogfoods failed owner product review despite passing their bounded engineering checks. None of these studies demonstrates independent maintainer acceptance.

Findings Matrix

Pressure	Cross-project finding	Method consequence
Architecture	Each project exposes a different real ownership boundary: scene, MonoBehaviour, Node/Resource, or Session/world.	Project-native concepts are authoritative. Reference architectures are optional question sets.
Scale	A two-script game and a multi-domain game cannot justify equal artifact depth.	Maps use compact, standard, or extended profiles selected by risk and coordination cost.
Lifecycle	Repeated-scene callbacks, Godot runtime copies, Jumpy Session restarts, and Circussy run resets all fail differently.	Every map identifies persistent/transient state, reset/teardown, and authored-to-runtime copy boundaries.
Activation readiness	Lanternworks resolved its dependency graph before UI Toolkit runtime content was ready.	Dependency presence, construction, scene activation, and runtime readiness are distinct states.
Operations	A command can be documented yet unavailable, available yet unexecuted, executed with partial scope, run in a mode that removes a required capability, or exit zero without producing its requested result.	Operation definitions, capabilities, project preconditions, process completion, and operation completion are distinct. A pass requires a fresh declared completion signal from the current invocation. Outcomes include passed, failed, inconclusive, unavailable, and not attempted.
Toolchains	Declared versions did not always match effective executables; editor readiness and dependency acquisition changed outcomes.	Evidence records declared and effective tools, readiness, dependency availability, and actual exit state.
Evidence	Local, CI, hosted, editor, browser, native, web, and multiplayer claims are not interchangeable.	Evidence is located by class, provenance, scope, outcome, revision, and toolchain.
Consumer completeness	Circussy repeatedly passed a nearby layer while the real route still failed: mouse versus controller focus, Wwise authoring versus runtime playback and handoff, async stages versus visible frame continuity, and imported assets versus runtime factory resolution. Lanternworks repeated the pattern when a native world Almanac omitted the production HUD.	Name the production consumer and intended environment for each material claim. Use the smallest route containing every material boundary; retain narrower tests as support without inflating their scope.
Ownership	Imported Unity assets, Godot caches, Wwise outputs, Jumpy legacy assets, and runtime-only objects need different authority.	Ownership uses explicit authority categories; unresolved authority blocks destructive automation.
Runtime resources	Lanternworks generated meshes and materials safely only after giving each resource family an explicit owner and teardown path.	Runtime-created engine resources require named creation, ownership, and release contracts.
Derived explanations	Lanternworks duplicated Resource-path traversal when separate views explained the same topology, then removed the drift risk with one read-only analyzer.	Shared domain explanations use pure deterministic analysis results; adapters retain player wording and claims stay narrower than the analysis can prove.
Read-only research	Editors and compilers create caches even when source code is not edited.	Formal source snapshots and disposable rehearsal copies are separate when tools can mutate the tree.
Automation	A shell pipeline once reported the status of tee, not the failing Cargo process.	Repeated operations fail closed, preserve the real exit status, and report what actually ran.
Ubiquitous language	Familiar engine labels repeatedly obscured the project's own model.	Canonical project language is mapped before architecture is classified.
Coordinates	A local-versus-world presentation assumption passed isolated tests and failed in the composed Lanternworks scene.	Coordinate spaces are named at engine boundaries and verified in composed runtime evidence.
Visual capture modes	Lanternworks graphical batch mode supported explicit render targets but did not resume an interactive end-of-frame screenshot recipe.	Visual operations name required capabilities and frame surfaces; deterministic offscreen composition is not promoted into an exact Game-view or human-acceptance claim.
Virtual input timing	Lanternworks Input System helpers queued Gamepad state, while immediate adapter polling expected synchronous publication.	Scripted input operations name and control their event-processing boundary before reading edge state.
Composed deterministic baselines	Lanternworks advanced Simulation Ticks during scene load before the rehearsal gained control.	Deterministic composed rehearsals pause and establish a named baseline before input; real-time pacing remains a separate claim.
Interaction evidence	A virtual Gamepad completed Lanternworks' First Light loop but could not judge understandability or feel.	Mechanical input rehearsal and human interaction acceptance remain separate evidence entries.
Affordance presentation	The same First Light rehearsal passed while the ordinary HUD exposed no build, Route, Remove, Save, or Load controls and mouse input could only select Cells.	Separate executable reachability, affordance presentation on the ordinary production surface, and human comprehension. Inspect the real player surface before building review infrastructure.
Product experience	Lanternworks and Followspot accumulated mechanically complete slices, tests, native inspection, and supporting features before the owner rejected both as incomprehensible, poorly explained, weakly designed, and not fun. The agent also originated and expanded their gameplay premises without sufficient prior design dialogue with the owner.	Begin new gameplay with a human-led design dialogue and approved hypothesis, then require an early owner-played experience gate. Mechanical health cannot promote a failed or unapproved product premise.
Player-system loop	The rejected prototypes implemented system nouns and reachable routes without first proving one repeated, perceivable, consequential decision through UI, feedback, learning, and adaptation. More systems and information did not repair the missing player loop.	For systems-heavy work, trace perceive -> decide -> act -> read consequence -> learn -> adapt, build the smallest complete decision, and match automated evidence to mechanical claims while direct play remains the experiential gate.
Human correction	Circussy's accepted work repeatedly came from the director discussing intent, playing or inspecting the real Unity consumer, narrowing the next question, retaining diagnostics for hidden state, and accepting, tuning, rejecting, or rolling back a bounded change. The same loop also consumed substantial time when hypotheses stayed broad, design intent stayed implicit, or patches stacked.	Treat human design and judgment as implementation inputs, not final ceremony. Discuss intent before breadth, rehearse early, instrument before broad repair, checkpoint known-good states, and use the Player Experience Gate to limit correction cost.
Player-build evidence	Lanternworks produced a valid macOS app bundle, but the build operation did not launch it.	Project-owned build intent, STAGE artifact verification, player launch, and human release acceptance remain separate operations and claims.
Player-launch evidence	Lanternworks' built player reached project-defined scene readiness and exited cleanly, while input, visuals, performance, and acceptance remained unobserved.	The project owns readiness semantics; STAGE owns generic process, provenance, nonce, log, and artifact-integrity checks.
Visual workflow ownership	The Circussy export-first trial produced valid but mostly low-value portable evidence; only one coherent Enemy Arrival sequence proved useful. Moving inspection into Unity restored production assets and motion, but an isolated Test Lab still omitted player context and became a parallel product. Lanternworks independently kept a player-facing Almanac, which was legitimate because it served content discovery, yet its developer surface still missed a HUD defect that ordinary Game-view inspection exposed. Both projects also caught state-only checks that passed while the rendered result was wrong.	Start with the smallest consumer-complete game or editor route. Persistent UI must earn its place from an actual player, author, or recurring developer job; visual review alone does not justify it. Reuse canonical content and production presentation when a project feature already exists, but do not infer a reusable gallery architecture. Verify visible effects rather than only state mutation, and leave taste with the human.

Claim Review

Orientation

Supported as a mapping claim. All four independent projects could be described through direction, vocabulary, domains, lifecycle, authoring, operations, ownership, evidence, risks, and decision rights. This does not yet show that a maintainer would orient faster with the map.

Control

Supported as a safety design. Repository snapshots detected target mutation, and ownership analysis exposed paths where a guessed regeneration policy would be unsafe. One same-director Lanternworks controlled change preserved a clean baseline, production ownership, and bounded diff, but no independent controlled change has measured whether STAGE reduces unintended edits in practice.

Trust

Strongly supported as a failure-prevention rule. The studies produced several cases where one evidence surface could have created a false claim: successful formatting without tests, a created canvas without a loaded game, an editor import with runtime warnings, and static Unity bindings without the exact editor. Evidence dimensions should therefore be normative.

Continuity

Supported for same-director resumption, but not independently measured. Lanternworks preserved revision-bound operations, failed assumptions, authored decisions, and evidence through 66 source-control checkpoints. A longitudinal handoff or independent maintainer study is still required for the broader claim.

Proportionality

Supported at the artifact-design level. Blopsqwash demonstrates that a useful map can remain compact and should not manufacture services, domains, or tools. Controlled adoption is still needed to measure maintenance cost.

Player Experience

Not supported by either same-director dogfood. Lanternworks and Followspot both show that STAGE can help produce mechanically healthy software while still failing at the central job of a game. The method stated that fun and comprehension were human-owned, but treated their absence as a deferred claim rather than a stop condition. That sequencing allowed architecture, content, tooling, and supporting features to expand before the owner tested the core experience.

The rejected reviews are negative evidence about STAGE itself. The agent also originated their premises without enough prior gameplay-design discussion with the owner. Future player-facing dogfoods must begin from a human-approved, explicit experience hypothesis and test the smallest complete form with the owner before longitudinal expansion. Passing automated checks cannot establish design approval or lift the experience gate.

For a systems-heavy premise, that smallest form is now defined more precisely as one complete player decision: the player can perceive relevant state and alternatives, choose through production controls, read the consequence, form a useful mental model, and adapt in a changed situation. UI, feedback, onboarding, pacing, progression, balance, and accessibility are evaluated as parts of that loop rather than as later feature categories. This is a revised practitioner hypothesis. Neither failed dogfood was rerun under it, so STAGE has no positive product evidence for the sequence yet.

The origin project provides a useful but narrower counterpoint. The Circussy correction-loop retrospective records repeated owner play, real-consumer observation, diagnostics, bounded repair, rollback, tuning, and accepted checkpoints. It supports the value of active human product authority during implementation. It does not prove product quality, efficiency, a STAGE treatment effect, or transferability. Its high correction cost strengthens rather than weakens the need for an early experience gate.

Decisions For STAGE 0.3

1. Make project-native architecture a core rule and demote the existing runtime architecture to an optional profile.
2. Add compact, standard, and extended map profiles.
3. Define operation state and multidimensional evidence coordinates.
4. Expand ownership authority, including an explicit unresolved state.
5. Require source/rehearsal separation for mutation-prone external audits.
6. Version schemas and preserve validation for 0.1 manifests.
7. Add deterministic semantic artifact hashing for refresh comparisons.
8. Keep transferability claims bounded: no independent maintainer has reviewed or adopted STAGE, and no independent controlled change or longitudinal study exists. Do not encode that evidence gap in the release version.

Personal Solo Unity Evidence

Lanternworks is not independent evidence. It is a direct dogfood study for the owner's personal profile. It supports these non-normative Unity practices:

The historical Almanac implementation is not a profile requirement. The list below records portable lessons from the work, not a recipe for reproducing its UI, modes, catalogs, scenarios, or capture paths.

1. Treat package presence, compilation, composition, scene activation, and interactive readiness as separate claims.
2. Open or create a destination scene before loading native Unity asset handles that will be assigned into it.
3. Select runtime shaders from the active render pipeline rather than from installed package presence.
4. Name local-space and world-space APIs explicitly at presentation boundaries.
5. Give every runtime-generated Unity resource family an explicit owner and teardown check.
6. Preserve authored scenes, UXML, and USS as canonical source; prefer targeted authoring operations over retained wholesale regeneration.
7. Discuss gameplay intent with the owner before substantial implementation, record a human-approved smallest complete player hypothesis, and stop architectural and product expansion at that boundary. Require direct owner play, record comprehension, usability, engagement, and desire to continue, and do not resume broad work while any material dimension remains failed or untested.
8. Prefer explicit world and UI render targets for deterministic batch capture; keep exact Game-view and human visual judgment as separate evidence.
9. Process queued virtual-device state explicitly before polling a project input adapter in deterministic tests.
10. Anchor composed simulations to a named baseline before exact-Tick input rehearsal, then retain a separate human smoke for feel and understanding.
11. Keep project-owned player-build policy separate from generic clean-revision, scene, log, freshness, and artifact-integrity verification; do not infer launch or release acceptance from build success.
12. Establish a truthful native review route from canonical engine content before creating portable visual evidence. Use existing previews or direct game routes by default. Persist custom review UI only when it independently serves a recurring player, author, or developer job, and keep agent control, state readback, and actual engine observation separately visible.
13. Preserve one reproducible native coordinate across a visual correction, change the production renderer rather than a review-only copy, and automate only objective invariants while human visual acceptance remains explicit.
14. Keep project-owned player-launch readiness checks separate from generic process, nonce, receipt, log, and artifact-mutation verification; do not infer input, visual, performance, or human acceptance from startup success.
15. When multiple views explain the same domain relationship, centralize a pure derived result rather than duplicating traversal in adapters. Keep player wording in the Unity shell and distinguish topology evidence from throughput, future-state, and comprehension claims.
16. Treat each retained native review entry point as an independent launch contract. Exercise editor, direct scene Play, and player routes from fresh sessions so hidden launcher state cannot substitute placeholders for production subjects.
17. Share canonical subject identity, staging, and presentation where useful, but keep interactive inspection, agent operation, regression capture, player-facing content browsing, and evidence export as separate contracts with separate consumers and claims.
18. Select a review surface by production consumer, not by whether the surface happens to run in-engine. Reuse existing deterministic input and composed capture seams when they exercise the real consumer; do not expand a review surface to imitate omitted HUD, camera, lighting, or lifecycle context.
19. Apply the same consumer-complete rule beyond visuals. Controller, Wwise, loading, runtime asset resolution, lifecycle, and platform claims require their material production path; focused tests remain supporting evidence, not substitutes for omitted consumers.
20. Require persistent visual UI to serve a real player, author, or recurring developer job. Reuse canonical identity and production presentation where useful, without requiring a gallery or paired player/developer modes.
21. Verify controls through their visible presentation effect. Lanternworks' orthographic camera changed transform distance without changing apparent scale, so state-only assertions gave false confidence until the lens and rendered framing were checked.

The structured record is in trials/stage-lanternworks-dogfood/study.yaml.

Remaining Evidence

To strengthen transferability claims, perform controlled, authorized changes in materially different projects and record correction cost, rejected work, and maintenance overhead. Independent maintainer review and longitudinal adoption would support broader claims if those opportunities arise, but they are not on the current solo-owner critical path. The personal Solo Unity track now has two owner-rejected game dogfoods. Mechanically passed operations remain useful engineering evidence, but neither project supports a claim that STAGE can originate a comprehensible or enjoyable game. A future product trial must begin from a human-approved player-experience hypothesis and pass early owner play before it contributes positive product evidence. Agent-created mechanics, theory reviews, or synthetic play cannot substitute for either decision. Release 1.0 is separately gated by a stable public contract, migration policy, critical defect review, and explicit owner acceptance.