Skip to main content

Failure Atlas

This atlas records recurring failure classes observed in agent-assisted game development. It is not limited to one engine.

Use the thematic index to enter from the observed symptom. Entries remain in their historical accumulation order below so existing links and decision provenance stay stable.

Thematic Index​

Diagnosis, Scope, And Authority​

Evidence And Claim Quality​

Visual Work And Review Surfaces​

Infrastructure And Capability Inflation​

Runtime, Tooling, And Operation Semantics​

Player Experience And Game Design​

Plausibility Patching​

Symptom: Several reasonable fixes change the behavior without explaining it.

Cause: The agent patches from a mental model instead of observed state.

Response: Preserve a reproduction, instrument the hidden state, rank hypotheses, and change one discriminating variable at a time.

Diagnosis Scope Creep​

Symptom: The owner asks for investigation without a fix, but the agent changes production behavior before establishing the cause.

Cause: Autonomy and momentum are mistaken for authority. A plausible patch is treated as diagnostic evidence even though it changes the condition being investigated and removes the owner's decision point.

Response: Treat diagnosis-only language as a hard scope boundary. Preserve the reproduction and inspect existing state. Add bounded reversible instrumentation only when the requested scope explicitly permits diagnostic edits. Report observations, ranked hypotheses, and the next discriminating step separately from proposed repairs. Do not tune, refactor, retain instrumentation, or checkpoint a behavior change until the owner authorizes implementation.

Observed correction: Circussy traversal work accumulated several plausible enemy-movement fixes before diagnostics isolated the real ramp-side behavior. Later requests explicitly separated diagnosis from repair so the reproduction and human decision survived long enough to identify the useful correction.

Compilation As Confidence​

Symptom: A change is declared fixed before the engine or composed runtime has been exercised.

Cause: Static success is mistaken for runtime, visual, or experiential success.

Response: Select evidence by claim and disclose missing verification.

Tests As Taste​

Symptom: Procedural terrain, UI, animation, or effects pass tests but look or feel wrong.

Cause: Invariants are used as substitutes for aesthetic judgment.

Response: Inspect the real production surface under representative conditions and require an identified human to judge the experiential claim.

Flattering-Angle Verification​

Symptom: An object, effect, or environment is declared visually correct from one hand-picked screenshot while defects remain behind, below, far away, or in another gameplay state.

Cause: Capture convenience substitutes for a declared coverage model.

Response: State the visual question, inspect purposeful fixed views and gameplay-relevant distances in the smallest truthful engine-native surface, and add bounded seeded exploration when procedural variation matters. Record a reproducible setup only when the review will recur. When exporting evidence, preserve every requested coordinate and failure instead of selecting only favorable output.

Random Screenshot Amnesia​

Symptom: A visual defect is found once but cannot be reproduced or compared after the next change.

Cause: Camera pose, state, time, quality, resolution, or procedural seed was not recorded as evidence coordinates.

Response: Record deterministic camera, state, time, quality, resolution, and seed coordinates in project-owned presentation data. Keep fixed regression coordinates and make exploratory randomness seeded and bounded. Persist the setup only when it recurs, and generate an export plan only when durable evidence is required.

Baseline Laundering​

Symptom: CI or an agent updates golden images until comparison passes, silently converting a regression into the new expected result.

Cause: Pixel storage is mistaken for product authority.

Response: Do not let automation replace approved reference images. Require an identified human owner to approve any reference update, and treat image comparison as diagnostic evidence rather than an acceptance decision.

Capture Adapter Authority Leak​

Symptom: The same engine tool stages a subject, renders it, declares it correct, and updates its baseline.

Cause: Evidence production, verification, analysis, and acceptance share one trust boundary.

Response: When a decision-bearing artifact consumer actually requires capture, let the capture tool emit media and provenance only. Keep integrity checks and analysis separate, keep agent review advisory, and grant acceptance only through the identified human owner.

Visual State Leakage​

Symptom: Later animation, VFX, UI, scene, or procedural captures depend on which shot ran before them.

Cause: The adapter batches work without restoring time, random state, pooled objects, scene state, animation graphs, particles, or UI selection.

Response: Define reset and teardown for the reviewed condition, replay the same state or motion twice, and treat unexplained presentation drift as a failed reproduction. Add byte comparison only when a named regression consumer actually needs stable captures.

Contact-Sheet Confidence​

Symptom: Tiny thumbnails look acceptable, but native captures contain clipping, seams, fallback particles, or unreadable text.

Cause: A navigation aid is used as the inspection surface.

Response: Return to native-resolution project or engine inspection for the decision. If a named external consumer already uses a contact sheet, treat it only as navigation and retain exact capture identities in findings.

Evidence-First Inversion​

Symptom: A visual workflow produces valid screenshots, videos, hashes, and contact sheets, but the reviewer cannot conveniently inspect, play, tune, or understand the real visual content. Placeholder subjects and low-value capture matrices survive because the export pipeline is easier to exercise than the game itself.

Cause: Portable evidence packaging was treated as the product before an engine-native review loop existed. The workflow rebuilt a weaker gallery outside the engine even though the engine already owned content resolution, animation, lighting, cameras, scenes, and runtime state.

Response: Return to the smallest truthful project-native surface first. Resolve real content, expose the presentation and motion needed by the question, and iterate in the engine or game. Add persistent custom UI only when it independently serves a recurring player, authoring, or development job. Export screenshots, videos, contact sheets, baselines, and receipts only for a concrete persistence, comparison, CI, or remote-review need.

Observed correction: The first Circussy rehearsal rendered a detached HTML contact sheet and substitute subjects even though Unity already owned the real models, materials, animation, lighting, and runtime composition. Moving the sequence into Unity made Enemy Arrival directly inspectable, but an isolated Test Lab was still a parallel product with little player value. The stronger correction is not another prescribed surface: bounded diagnosis stays on the smallest truthful native route. If a codex, gallery, world previewer, or inspect mode has independent player, author, or developer value, it is delivered as an ordinary project feature for that user. The isolated stage remains useful only for narrow diagnosis.

Parallel Visual Product​

Symptom: The project has a polished developer Test Lab or rehearsal scene, but ordinary players and developers rarely enter it, production presentation drifts, and every real asset or system needs parallel wiring before it can be inspected.

Cause: Moving review into the engine was mistaken for moving it into the product. The tool still duplicates the game's content resolution, stage, camera, lighting, animation, VFX, input, or lifecycle without earning an independent consumer.

Response: Return to the ordinary game or editor route that owns the work. If a codex, gallery, bestiary, model viewer, replay browser, world previewer, or inspect mode independently earns persistence, deliver it through the project's normal backlog for its actual user and reuse canonical production paths. It may be player-facing, author-facing, or developer-only; do not require combined player and developer modes. Keep isolated stages only for narrower questions whose omitted runtime context is explicit.

Infrastructure-First Inversion​

Symptom: A project gains a reusable tool, abstraction, dashboard, operation API, fixture catalog, or integration that is mechanically polished but has no recurring workflow using it. Maintaining and explaining the helper costs more attention than performing the original task directly.

Cause: Cheap agent implementation and measurable tool output were mistaken for demonstrated project need. The proposed reusable surface was allowed to define the workflow before the direct project-native path exposed what should actually be preserved.

Response: Return to the direct path and one bounded question. Use temporary instrumentation when state is invisible. Persist only the smallest helper that addresses an observed recurring cost, then dogfood one complete change through it. Add stable operation, durable evidence, or a shipping surface only for its own named consumer. Simplify or retire the helper when it does not reduce correction or oversight cost. See Earned Infrastructure.

Setup-Skill Capture​

Symptom: A fresh agent correctly identifies the primary change-delivery skill, then immediately invokes project mapping, creates STAGE.md and a manifest, proposes a custom review surface, and assembles an evidence package before touching the requested game fix.

Cause: Optional companion capabilities were presented as a maturity path or setup sequence. Written statements that artifacts were optional were too weak to overcome the agent's preference for visible framework outputs.

Response: Start ordinary work through stage-deliver-change in the current project. Mapping is a separate adoption, onboarding, or audit job. A custom review surface or durable evidence package must be earned by an observed recurring cost or named consumer. Existing project tests, editor views, game routes, logs, and human playtests are the default evidence surfaces.

Observed correction: A blank-directory Codex dogfood probe discovered the installed STAGE delivery skill but still treated stage-map-project as a companion setup skill and said a custom review surface and evidence package would be required before acceptance. The plugin prompt and skill routing were tightened, and this behavior became a packaging regression contract.

Judgment-Package Conflation​

Symptom: The owner asks to see or judge one visual fix in the running game, and the agent proposes an "engine-native review package," contact sheet, A/B capture set, or retained report before handing back the live result.

Cause: Human acceptance was mistaken for a remote-review or artifact consumer. The agent treated evidence-shaped output as more complete than the co-located engine view even though packaging added no truth and delayed the decision.

Response: Leave the smallest consumer-complete native surface ready for the owner and ask for the visual decision there. A direct screenshot or short clip may carry one conversational observation, but it is not a package. Add retained captures only for an explicitly named portability, revision-comparison, CI, milestone, audit, or remote-review need.

Observed correction: A fresh Unity animation task correctly rejected an external renderer and permanent gallery, but still promised a contact sheet and "review package" after the owner said "let me judge it." The visual-review contract was tightened so live human handoff and artifact retention are separate decisions. A follow-up probe rejected those packages but still called video the main judgment artifact, so live continuous motion was made the explicit default when the owner can watch Unity.

Artifact-Consumer Laundering​

Symptom: An agent correctly rejects a detached visual-review system, then proposes the same system as a "thin export adapter," fixed approval matrix, or standing capability because it will serve "human and AI review."

Cause: An audience or recurring activity is treated as a decision-bearing artifact consumer. The wording sounds specific while still omitting the decision, portability requirement, retention need, owner, and retirement condition that would justify persistent output.

Response: Require a concrete operation that cannot use the live native surface: remote review without engine access, stable revision comparison, objective CI, audit, release evidence, or retention of an accepted decision. Without one, decompose the broad request into bounded visual questions and hand back the native project route. Do not offer a contact sheet or export harness as an optional consolation prize.

Observed correction: A qualified dogfood probe loaded the installed STAGE 0.5.6 visual-review skill, rejected a universal capture matrix, and used an existing project Almanac. It then proposed an external contact-sheet generator and thin export harness for generic "human and AI review." This exposed that a named audience was still able to masquerade as a named artifact consumer.

Sunk-Cost Polishing After Route Utility Rejection​

Symptom: A human says that a workflow, evidence surface, or supporting system is not useful, but the agent treats the feedback as another quality pass. It keeps improving layouts, adding controls, narrowing scope, or repackaging the same route because substantial work already exists.

Cause: Rejection of the route's utility was collapsed into rejection of the current implementation. Mechanical success and sunk cost were allowed to outweigh human authority over what is worth building.

Response: Terminate optimization of the rejected route. Preserve state, salvage only the parts the human explicitly accepts, and retire, revert, or materially reframe the remainder through a different project-native route. Do not offer a smaller or optional version of the same route unless the human explicitly reauthorizes it. If the feedback could genuinely be a tuning request, ask one concise discriminating question first.

Observed correction: The Circussy visual-rehearsal experiment produced a technically functional detached contact sheet, yet the useful experience was the native enemy-arrival motion preview and the real need was better served by the game or editor itself. Continued refinement of the detached surface added cost without adding product truth. The route was rejected; its native-first lesson was retained.

Analogical Recovery After Route Rejection​

Symptom: An agent stops the explicitly rejected route, then performs a broad repository inspection to find something "close enough" to an accepted fragment. It maps a missing named behavior onto an unrelated feature and presents that substitution as the next authorized action.

Cause: "Carry forward the accepted part" was interpreted as an implementation mandate instead of a preservation constraint. A generic instruction to keep working supplied momentum but no replacement outcome, so the agent used semantic similarity to manufacture scope.

Response: Run rejection preflight before project orientation. Preservation is not authorization: retain the accepted fragment where it actually exists, but do not extend, port, recreate, or analogize it. Do not inspect broadly for a replacement. Continue only from a concrete materially different human outcome; otherwise ask one concise outcome question and end the branch.

If no cleanup or state-protection action was authorized, do not even run a status check or targeted search. Those operations cannot answer the missing product question and can restart the rejected route through newly discovered similarities. Respond directly from the correction instead.

Observed correction: A read-only 0.5.8 probe correctly refused further work on a detached contact-sheet exporter, but consumed a broad Lanternworks inspection and mapped the prompt's accepted Enemy Arrival fragment onto the unrelated Route Flow Motion scenario because the named fragment did not exist there. The target remained unchanged, but the reasoning still exceeded the authorized scope. This motivated rejection-before-orientation and explicit preservation-without-inference semantics.

An initial 0.5.9 candidate added those semantics but still ran git status and three target searches before asking the correct outcome question. This exposed the remaining gap between bounded inspection and the required zero-inspection response when no cleanup action exists.

Unbounded Visual Inventory​

Symptom: A request to inspect every visual object causes the agent to map the whole presentation layer, enumerate missing coverage, and propose scenario families, coverage profiles, or Almanac expansion before identifying one visual decision.

Cause: Orientation and inventory happened before scope. Once a coverage catalog exists, its empty cells look like required work even when no player, author, developer, or release decision needs them.

Response: Stop before repository-wide inspection. Require one bounded question with a subject, state or beat, context, and failure condition. Inspect only the production paths needed to answer it. An existing gallery or Almanac is a possible route, not a completion checklist.

Observed correction: A 0.5.7 candidate probe correctly refused detached exports but spent a broad source audit turning "every visual object" into an Almanac expansion plan. The skill had placed project protection and inventory before question framing. The gate now runs first.

Maturity-Ladder Completionism​

Symptom: Optional maps, diagnostics, operations, galleries, receipts, or automation become a numbered backlog. The agent keeps implementing the next slice after the original value hypothesis has failed because an unfinished level looks like incomplete adoption.

Cause: A maturity ladder or preplanned sequence encodes progress as artifact accumulation. Agents are especially likely to optimize for checklist completion instead of re-evaluating whether the next capability still has a consumer.

Response: Keep project-native delivery as the baseline and present every persistent capability as an independent, need-triggered option. Name its observed trigger, owner, consumer, stop condition, and retirement condition. There is no terminal STAGE level and no reward for retaining unused machinery.

Observed correction: STAGE's adoption guide still labeled optional capabilities Level 0 through Level 5 after Earned Infrastructure became normative. The detached visual-rehearsal work showed why that framing was dangerous: planned slices continued to produce artifacts even after direct engine review was clearly more useful. The guide was converted to a non-linear capability menu.

Visual Surface Collapse​

Symptom: One feature is expected to be an artist-facing inspector, an agent API, a screenshot-regression suite, a shipping bestiary, and a portable review report. Improving one audience's workflow makes another audience's lifecycle, performance, failure visibility, or interface worse.

Cause: Shared content resolution and staging code were mistaken for a shared product contract. Interactive inspection, agent operation, visual regression, player content browsing, and capture/export were treated as interchangeable.

Response: Share canonical identity and production presentation where useful. Keep the consumer contracts separate. Build only those with a real consumer and do not infer visual acceptance, agent operability, regression stability, or shipping readiness from another surface's existence.

Native Shell Substitution​

Symptom: A project has an engine editor window that loads real assets, yet the review still misses defects in gameplay camera framing, animation, VFX, post-processing, UI composition, generated environments, input, pause, or runtime lifecycle.

Cause: engine-native was treated as a sufficient truth claim. The host lived inside the engine but bypassed the production paths needed by the visual claim.

Response: Choose the least artificial engine or game route that contains the production consumer needed by the question. Prefer a development runtime screen, runtime scene, or composed player route for player-visible behavior. Keep editor previews for genuinely asset-local questions, and state what the selected route does not contain.

Consumer Omission​

Symptom: Nearby evidence passes, but normal project use still fails. A world gallery hides the production HUD; mouse clicks work while controller focus or modal submit fails; a Wwise event previews while runtime media or music handoff does not; loading stages complete while the visible frame loop freezes; or an asset imports while the production factory still composes a placeholder.

Cause: Local success or engine ownership was treated as sufficient evidence. The selected route does not include the production consumer or another integration or environmental dependency material to the claim.

Response: Name the production consumer and intended environment before selecting evidence. Use the smallest consumer-complete verification route, or narrow the claim to what the current route actually contains. Keep focused tests and previews for diagnosis; do not promote them across omitted input, composition, middleware, frame-loop, runtime-resolution, or platform boundaries. Do not build a new harness when the ordinary project route already supplies the missing context.

Observed correction: Lanternworks' First Light Almanac truthfully staged the generated borough progression but intentionally hid the ordinary HUD. It could inspect the world-state sequence, not a new HUD completion banner. That feedback had to be reviewed through the playable game route.

The Circussy One exposed the same pattern across modalities: modal submit had to be checked through controller input rather than mouse behavior; Wwise music required the complete menu/loading/gameplay handoff rather than authoring preview; loading responsiveness required frame-gap diagnostics under real work rather than an async signature; and runtime content required composed factory resolution rather than successful asset import.

Launch-Path Drift​

Symptom: A native review setup shows authored content when opened through one editor tool, but direct scene Play, a development player, or an agent launch shows capsules, stale presentation, the wrong subject, or an unready state.

Cause: Required identity or setup is injected by one orchestrator and is not owned by the runtime host or carried in an explicit launch request. Correctness depends on hidden prior-session state even though several entry points are described as equivalent.

Response: Verify every available entry point from a fresh session. Resolve canonical subject and presentation identity during native host initialization or from explicit launch parameters. Compare subject, state, truth mode, temporal mode, presentation, and readiness across routes. Fail visibly on fallback content, and mark non-equivalent routes partial or deferred.

Capability Theatre​

Symptom: A project is described as agent-operable because it has an editor menu, window, or MCP-visible button, but an agent cannot reliably select a subject, wait for readiness, reset it, or release the resulting state.

Cause: Human discoverability is confused with a stable operation surface. Interactive UI automation is treated as a contract even though control names, focus, selection, and timing remain implicit.

Response: Declare human and agent native-review entry points separately. Keep agent status deferred until a project operation supports subject selection, staging, readiness, reset, and teardown with explicit failures.

Receipt-Only Inspection​

Symptom: An agent launches a native review route and receives a ready log or machine-readable state receipt, then reports the visual as correct without ever seeing the engine frame. Alternatively, it sees a frame but cannot identify the subject, truth mode, beat, seed, camera, or lighting that produced it.

Cause: Native control, state provenance, and visual observation are treated as one implied capability. A successful command or receipt is inflated into a pixel claim, or an unlabelled image is inflated into reproducible evidence.

Response: Validate the three channels independently. Use a stable native control operation, read back the actual project state, and observe the engine's real frame or motion through a named surface. Preserve human authority for visual acceptance. Export evidence only when persistence or portability has a real consumer.

Catalog Shadowing​

Symptom: The engine and a STAGE artifact each maintain lists of performers, enemies, weapons, scenes, animations, or props, and visual review silently uses stale, placeholder, or differently ordered entries.

Cause: A capability map expanded into a parallel content database because external tooling wanted convenient subject enumeration.

Response: Keep content identity in canonical engine-owned catalogs, registries, scenes, or assets. The normal project map and operating docs may point to discovery sources and placeholder policy, but they must not copy the entries themselves. A project does not need an additional visual capability artifact merely because it performs visual review.

Parallel Capability Manifest​

Symptom: A project already documents a native tool in its ordinary project map, operating guide, and source, yet a second versioned manifest repeats the same entry points, modes, settings, lifecycle, evidence, and limitations. Most maintenance work changes the descriptions rather than the tool.

Cause: Machine-readable completeness was treated as an independent product without naming a consumer. Compatibility machinery was added before two tools or repositories actually needed to exchange the data.

Response: Keep one project map and the native feature's operating docs. Introduce a separate interchange format only after naming multiple real consumers, the fields they cannot obtain from the project map, and the compatibility promise they require.

Scenario Inflation​

Symptom: A native gallery treats every player content entry as a nominal developer review case, each with a generic camera or authored-default state, but reviewers still have to invent the useful question and staging every time.

Cause: Catalog completeness is mistaken for review usefulness. Generated scenario records mirror content inventory without expressing a distinct visual judgment.

Response: Keep subject discovery in the canonical project catalog. Preserve a small set of reproducible setups around recurring questions and human-owned presentation choices. Add another setup only when it shortens a real review loop. A player-facing browser may still derive one entry per canonical subject; reuse its resolver and renderer without making catalog cardinality the review plan.

Observed correction: Lanternworks initially exposed real canonical content through a native browser and still produced weak review value. Separating its per-Subject player entries from two explicit developer questions produced one useful Structure guide, one five-Structure readability lineup, and one five-beat First Light progression without duplicating the renderer. Native location alone did not solve Scenario Inflation; distinct catalog purposes did.

Symptom: A project has a polished native gallery, codex, or Almanac, but it is evaluated by feature count and presentation rather than by whether it finds and helps correct defects in the real game.

Cause: Building the inspection surface became the destination. The project never preserved a question and native coordinate across an authorized production change, so the gallery's engineering value remained hypothetical.

Response: Select one recurring question, preserve its known starting state and reproducible setup, observe the canonical renderer, change the smallest production-owned path, and replay the same setup. Automate only objective invariants and keep human visual acceptance explicit.

Observed correction: Lanternworks' Structure Readability Scenario exposed two duplicated cylinder profiles and three weak box variants in the real BoroughWorldView. A bounded production-renderer change, structural PlayMode guardrail, fresh player build, and same-coordinate replay demonstrated the correction loop while leaving final visual acceptance pending.

Preview Truth Inflation​

Symptom: A smoothly encoded preview video is reported as proof of gameplay animation, physics, particles, or runtime integration even though each frame was reconstructed by editor state seeking.

Cause: Presentation format is mistaken for execution semantics.

Response: Label authored state seek, deterministic simulation, composed runtime, and live runtime separately. A video inherits the truth mode that produced its frames.

Timed Stills Masquerading As Motion​

Symptom: A native gallery has Previous, Play, and Next controls, or exports an MP4, but each frame merely hard-cuts to another complete static state. The workflow is described as animation, continuous playback, or motion evidence.

Cause: Temporal controls and transport format are mistaken for temporal semantics. Named states are treated as proof that meaningful in-between frames exist. Sometimes preview-only interpolation is added to make the evidence look stronger even though the production game has no corresponding motion.

Response: Distinguish a still, a sequence of discrete states, and continuous motion. Reserve motion claims for meaningful frame-to-frame change produced by the project's real presentation path. Label timed or manual hard cuts as a state sequence, state how the frames were produced, and let videos inherit rather than upgrade those execution semantics.

Observed correction: Lanternworks' five-beat First Light Progression was a useful deterministic State Sequence, but its toolbar said MOTION, its declaration claimed still and motion support, and its docs called playback continuous. Source inspection and a built-player rehearsal showed that no production animation existed. The correction renamed and typed the sequence, strengthened its contracts and receipt, and deliberately did not invent review-only animation.

Async By Declaration​

Symptom: Loading code uses coroutines, tasks, or async methods but still freezes presentation.

Cause: Main-thread integration or synchronous work remains unmeasured.

Response: Measure frame gaps and named stages; move only thread-safe work; yield engine integration intentionally.

Generated Ownership Violation​

Symptom: A scene, prefab, UI document, or tuned asset is regenerated over human changes.

Cause: Automation lacks ownership boundaries.

Response: Mark manual and generated roots, make rebuild operations explicit, and prefer additive generation. When generation only seeds an asset that then becomes human-authored, record the handoff and delete, disable, or narrow the generator before manual work begins.

Abstraction Inflation​

Symptom: Every feature gains interfaces, services, systems, rules, factories, and registries.

Cause: The agent imitates repository vocabulary rather than responding to complexity.

Response: Require real duplication, substitution, ownership, or test pressure before adding a role.

Runtime DI Surprise​

Symptom: Compilation succeeds but the container fails during startup.

Cause: Constructor selection or collection registration is validated only at runtime.

Response: Use explicit injection points and a composed graph smoke test.

External Tool Drift​

Symptom: Unity and an audio, animation, or content tool disagree about generated state.

Cause: Only one side of a multi-editor pipeline was verified.

Response: Treat authoring source, generated artifact, import state, and runtime event as one pipeline.

Documentation Multiplication​

Symptom: Agents read a plausible but stale plan instead of current implementation truth.

Cause: New documents are added without canonical ownership or retirement.

Response: Maintain an index, one current project map, versioned decisions, and explicit historical case studies.

Tool Impatience​

Symptom: A temporarily compiling or importing editor is treated as unavailable or broken.

Cause: Readiness is inferred from response latency.

Response: Expose and wait for a settled-state signal before verification.

Hidden Scaling​

Symptom: Displayed values do not explain observed gameplay.

Cause: Legacy multipliers, fallback data, or implicit progression modify behavior outside authoring surfaces.

Response: Make scaling explicit, traceable, and visible in previews or diagnostics.

Broad Recovery Damage​

Symptom: Reverting an experiment also removes unrelated human work.

Cause: The checkpoint or rollback boundary was not established.

Response: Inspect the dirty tree, checkpoint intentionally, and revert only owned changes.

Reference-Shape Projection​

Symptom: An agent invents services, systems, or layers because a familiar architecture profile contains them.

Cause: The reference architecture is treated as the project instead of an inspection aid.

Response: Map canonical vocabulary and native lifecycle first. Add an abstraction only when real ownership, duplication, substitution, or evidence pressure justifies it.

Documented Operation As Evidence​

Symptom: A project is called tested or operable because a command appears in documentation.

Cause: Operation definition, availability, execution, and result collapse into one status.

Response: Record exact operation state and preserve unavailable or inconclusive outcomes.

Evidence Scope Collapse​

Symptom: Native CI success is used to claim web, multiplayer, editor, or hosted runtime correctness.

Cause: Evidence class is recorded without provenance and scope.

Response: Record class, provenance, scope, revision, effective toolchain, outcome, and limitation for material claims.

Toolchain Shadowing​

Symptom: A repository declares one version but another executable actually runs.

Cause: PATH order, editor selection, middleware state, or dependency resolution is assumed rather than observed.

Response: Capture the effective executable and version in the operation receipt.

Read-Only Cache Mutation​

Symptom: An external audit dirties the source through imports, caches, lock updates, or generated metadata despite making no intentional edit.

Cause: “Read-only” describes intent rather than measured repository state.

Response: Snapshot formal source before and after; run mutation-prone tools in a disposable rehearsal copy.

Exit-Status Masking​

Symptom: A logged operation appears successful although an upstream command failed.

Cause: A pipe or wrapper reports the logger, formatter, or final command's status.

Response: Use fail-fast execution and pipe-failure propagation; capture the actual command status before reporting evidence.

Successful Exit Without Completion​

Symptom: A command exits zero, but the requested test report, generated artifact, readiness state, or other declared result is absent. An older file at the expected path can make the invocation appear successful.

Cause: Process termination is treated as proof that the project operation completed. The wrapper checks an exit code or reads a stale artifact without binding it to the current invocation.

Response: Define the operation's completion signal before running it. Use a fresh result path, remove an owned old result safely, or verify invocation identity and freshness. Report zero exit without the declared result as inconclusive. Lanternworks exposed this when Unity accepted -quit, imported and compiled, exited zero, and produced no current Test Runner XML.

Capability-Blind Operation​

Symptom: A valid-looking evidence command crashes, hangs, or produces an empty artifact only in headless, offline, background, or disconnected mode.

Cause: The operation records project preconditions but not the execution capabilities it needs. A fallback mode silently removes graphics, editor interactivity, credentials, network access, or middleware connectivity.

Response: Declare operation capabilities explicitly. Mark the operation unavailable when a capability is absent, or define a narrower fallback whose claim and evidence scope honestly match what that mode can observe.

Batch End-Of-Frame Assumption​

Symptom: A Unity batch PlayMode test never finishes after requesting a screen capture, even though ordinary tests and explicit camera rendering work.

Cause: An interactive recipe relies on WaitForEndOfFrame or the Game-view backbuffer, but the batch execution mode does not advance that callback surface. The operation has a graphics device yet still lacks the interactive frame phase the recipe assumes.

Response: Do not add arbitrary waits. Render required layers into explicit, owned targets, assert each layer independently, compose them deterministically, and disclose that the result is not the exact interactive backbuffer. Retain human Game-view inspection for legibility, timing, and visual-quality claims.

Queued Virtual Input Assumption​

Symptom: A composed input rehearsal presses a virtual button, but the real input adapter observes no press or observes it one frame later.

Cause: The test helper queued an Input System state event for the player loop, while the rehearsal polled the adapter immediately in the same test step. The helper call looked synchronous, but device-state publication was not.

Response: Name the event-processing boundary. Process queued virtual-device updates deliberately before polling, then release and process again so edge state cannot leak into the next action. Verify through the real project input adapter, not by calling the gameplay action directly.

Scene-Load Clock Contamination​

Symptom: A deterministic composed-scene rehearsal reaches the correct game state at different Simulation Ticks across otherwise identical runs.

Cause: The scene's real-time scheduler advanced authoritative state during load and startup before the test gained control. Wall-clock startup latency became an undeclared input to the assertion.

Response: Pause the composed runtime, restore or establish a named authored baseline, and assert that baseline before scripted input begins. Advance exact Simulation Ticks for deterministic mechanics. Keep a separate real-time or human rehearsal when cadence and pacing are the actual claim.

Automated Input As Player Acceptance​

Symptom: A virtual controller completes a loop, so the feature is described as understandable, comfortable, or fun.

Cause: Mechanical reachability and human interaction quality collapse into one interactive result.

Response: Record two claims. Automated input may prove mapping, focus, adapter wiring, and outcome reachability. Physical-device behavior, control feel, accessibility, comprehension, pacing, and enjoyment remain human evidence unless the claim is narrowed explicitly.

Mechanically Successful Game Failure​

Symptom: A prototype has deterministic rules, passing engine tests, supported input routes, native visual inspection, clean lifecycle behavior, and multiple implemented feature slices, yet a human player cannot understand it and does not enjoy it.

Cause: Experiential uncertainty is documented as a disclaimer instead of used as a sequencing gate. Mechanical completion keeps authorizing expansion while comprehension, usability, engagement, and desire to continue remain untested.

Response: Before broad player-facing expansion, discuss the player fantasy, core verbs, intended first-minute understanding, short loop, success and failure, and explicit stop conditions with the accountable human designer. Obtain approval of the smallest complete hypothesis, build it, and require direct human play. A failed material experience dimension blocks further architecture, content, supporting modes, polish, and transferability claims until the hypothesis is changed and replayed. Automated evidence can support diagnosis but cannot lift the gate.

Observed correction: Lanternworks and Followspot both retained valid mechanical and Unity-integration evidence, but their owner rejected the games as incomprehensible, poorly explained, weakly designed, and not fun. STAGE now records those projects as failed experiential dogfoods rather than operational game successes.

System Completeness Without A Player Decision​

Symptom: Rules, resources, agents, progression, and failure states exist, but the player cannot name the recurring decision or explain why one available action should be preferred over another now.

Cause: The implementation is organized around system nouns and state transitions rather than the player's repeated perceive -> decide -> act -> read consequence -> learn -> adapt loop. Mechanical breadth is mistaken for a playable product.

Response: Trace one complete decision through the production surface. Require perceivable alternatives, a context-dependent tradeoff, a real input, causally legible consequences, recovery, and a changed next situation. Enumerate and simulate options as mechanical evidence, then observe a human choosing without coaching. Block breadth while the decision remains unperceived, inconsequential, solved, or unexplained.

Observed correction: Lanternworks and Followspot contained functioning systems and completable routes, but owner review found no compelling, self-explaining activity. The retained lesson is not to add more mechanics; it is to prove the first complete decision before multiplying systems.

Information Inventory Instead Of Decision UI​

Symptom: The screen exposes resources, stats, controls, panels, and help, yet the player still cannot decide what matters, compare alternatives, predict an outcome, or recover from a blocked action.

Cause: UI is evaluated by information presence rather than by the decision it must support. Internal state is surfaced without hierarchy, deltas, causal relationships, constraints, or contextual timing.

Response: For each decision, name what the player must perceive, compare, predict, act on, explain, and recover from. Put relevant state and deltas beside the choice, explain blocked actions, preserve stable semantics and input parity, and reveal detail when its decision becomes relevant. Check layout and focus mechanically; test comprehension and cognitive load through uncoached play.

Observed correction: Both rejected dogfoods had functioning UI and documented controls, but the owner still described the games as incomprehensible and poorly explained. UI existence did not establish decision support.

Feedback Volume Without Priority​

Symptom: More animation, sound, particles, camera response, numbers, and notifications are added, but important consequences remain unclear or the presentation becomes exhausting.

Cause: Feedback is treated as a quantity or polish pass. Input acknowledgment, immediate outcome, causal explanation, strategic consequence, emotional emphasis, and persistent history are not assigned different jobs or priorities.

Response: Map each material consequence to the feedback layer that explains it. Verify timing, lifecycle, channel agreement, aggregation, and priority. Match intensity to consequence and preserve sensory alternatives. Human play judges impact, comfort, emotional fit, and whether the hierarchy remains readable in motion. Do not infer quality from effect count.

Progression As Numbers Only​

Symptom: Values, unlock counters, levels, or reward frequency increase, but the repeated activity does not create new questions and becomes solved or repetitive.

Cause: Progression is modeled only as power or accumulation rather than as a change to the player's decision space.

Response: State what each progression step changes: a verb, constraint, synergy, tension, role, timing, risk, or application of learned skill. Inspect curves and unlock graphs mechanically. Ask in play whether the player notices new possibilities, revises a plan, and wants to test another approach. Increasing a number is allowed when that is the intended reward, but it is not automatic evidence of motivation.

One-Policy Balance Proof​

Symptom: A bot completes the game, choices have similar aggregate rates, or one modeled policy looks healthy, so the system is called balanced and strategically rich.

Cause: The encoded objective, observations, action space, skill assumptions, and contexts are hidden inside one result. Actual power is collapsed with perceived power, identity, appeal, execution difficulty, availability, cost, risk, and counterplay.

Response: Declare the balance goal and policy assumptions. Search multiple policies and contexts, test sensitivity, and preserve counterexamples. Telemetry and simulation expose mechanical risks; human play judges fairness, strategy identity, discoverability, adaptation, and enjoyment. Equal rates are not a universal target.

Telemetry As Enjoyment​

Symptom: Session duration, retention, return rate, action count, or reward collection rises and is reported as increased fun, satisfaction, or player welfare.

Cause: Observable behavior is treated as its own interpretation. Incentive pressure, confusion, obligation, friction, novelty, and genuine enjoyment can produce similar metrics.

Response: Keep behavioral telemetry, observed play, player report, and team interpretation separate. Use metrics to locate events and compare declared hypotheses. Require direct human evidence for lived experience and representative participants for audience claims. Review fear of missing out, obscured odds or costs, exit friction, punitive absence, and coercive reward schedules as design risks rather than engagement wins.

Silent Agent Gameplay Authorship​

Symptom: The agent creates a gameplay premise, core loop, controls, and supporting systems from a broad request, then asks the human to evaluate the result only after substantial implementation.

Cause: Implementation delegation is mistaken for authority to choose the intended player experience. Game-design frameworks and automated play are treated as substitutes for discussing fantasy, audience, verbs, tradeoffs, and desired feeling with the accountable human designer.

Response: Before substantial implementation of a new or materially changed premise, recover existing intent and discuss the highest-leverage open design decisions with the human. Present alternatives, theory, cost, assumptions, and what remains unknowable without play. Obtain a human-approved gameplay hypothesis, then build the thin complete loop and use the Player Experience Gate. When invention is explicitly delegated, the agent may draft the hypothesis but does not silently approve it. Synthetic play supports mechanical claims; direct human play supports lived experience, and representative players are required for broader audience claims.

Observed correction: The owner identified that Lanternworks and Followspot were not merely tested too late; their gameplay was designed too independently by the agent. The corrected STAGE sequence moves human design authority before implementation breadth.

Reachable But Unpresented​

Symptom: Automated input completes the intended action or gameplay loop, but the ordinary player surface does not visibly expose the action, current tool, or way to continue. The feature is reachable only through undocumented input, external instructions, a developer-only surface, or prior knowledge.

Cause: Mechanical reachability was mistaken for affordance presentation. The production action path is complete, but its intended player-facing consumer is absent or was never included in the evidence route.

Response: Record mechanical reachability, affordance presentation, and human acceptance as separate claims. Inspect the ordinary production surface before adding a custom rehearsal or gallery. Expose the action through the project's intended controls, prompt, tutorial, convention, or diegetic cue and bind that presentation to the same production input path. If the action is deliberately hidden, state that policy and narrow the operability claim. Human comprehension and feel still require human review.

Observed correction: Lanternworks' deterministic virtual Gamepad rehearsal completed First Light through its real input adapter, but the playable HUD exposed only the Almanac and mouse input could only select Cells. Direct inspection of the ordinary Game view found the omission. The resulting Command Deck exposed build, exact-resource Route, Remove, Apply, Cancel, Pause, Save, Load, and Almanac actions through the existing BoroughInputDriver; the full Unity suites then passed at 221/221 EditMode and 20/20 PlayMode. Whether the controls are understandable and comfortable remains a human playtest claim.

Player Build As Runtime Proof​

Symptom: A successful engine build is described as a working or releasable game even though the produced player was never launched.

Cause: Build integration, artifact identity, startup, representative runtime behavior, platform distribution, and human release acceptance collapse into one binary success state.

Response: Let the project own target, scene, backend, signing, and output policy. Bind the raw receipt, settled log, enabled scenes, exact clean revision, and complete artifact hash independently. Record launch and release acceptance as later operations with their own capabilities and evidence.

Authority Guessing​

Symptom: Legacy, imported, or unfamiliar assets are deleted or regenerated because their folder name looked disposable.

Cause: The ownership model has no explicit unresolved state.

Response: Mark authority unresolved, name the decision owner, and prohibit destructive or broad mutation until clarified.

Artifact-Level Authority Collapse​

Symptom: An exact source-backed field repair is refused because some other part of the file has uncertain provenance, or authority for that repair is used to regenerate the whole file.

Cause: Provenance of the containing artifact and authority for the proposed operation are collapsed into one binary ownership label. Blanket inaction then looks safer than least-authority repair, while narrow permission can also be misread as whole-artifact permission.

Response: Evaluate the actual mutation. Permit an explicitly authorized, canonical-source-backed repair only when it preserves unresolved adjacent state. Do not widen that authority into replacement, normalization, or regeneration. Broad work needs both explicit handling authority and a complete canonical source for every state it can overwrite.

Observed correction: The first safety-boundary evaluator incorrectly rejected every mutation to a mixed-provenance prefab. A preregistered follow-up separated narrow repair from broad regeneration across character, UI, and audio fixtures. All eighteen runs repaired narrowly and stopped broadly, confirming the operation boundary but showing no correctness advantage for a STAGE treatment over the explicit project contract.

Declared Stop Without Termination​

Symptom: An agent says a request is unbounded, unsafe, ambiguous, or unsupported, then continues by inventorying the same surface, proposing a smaller version of the same system, or implementing around the missing decision.

Cause: The stop condition was treated as explanatory prose instead of a control-flow branch. Continued activity still feels productive, so the agent launders prohibited work through a narrower label.

Response: End the blocked branch. Preserve state and allow at most one bounded operation that directly distinguishes the blocker. If no such operation remains, state the trigger and evidence, ask for one missing decision or state change, and end. Do not substitute more inventory, a speculative plan, or a parallel harness for the unavailable authority or evidence.

Observed correction: A dedicated visual-review probe correctly announced that an exhaustive request was unbounded, but then proposed Almanac subjects, scenario families, sweeps, agent controls, and exports. The corrected branch asks one bounded visual question and terminates before project inventory.

Corroboration After The Decision​

Symptom: An investigation reaches a defensible owner, diagnosis, smallest plan, and next runtime check, then keeps reading adjacent files and collecting equivalent evidence without changing any of them.

Cause: Correct orientation has no stopping rule. More context feels safer, so corroboration is mistaken for reduced uncertainty even after the remaining unknowns cannot change the next engineering decision.

Response: Drive inspection from the unresolved decision. After each material step, ask whether another read or tool action can plausibly change ownership, implementation, verification, authority, diagnosis, or material risk. If not, stop orientation and perform the next discriminating check. Do not impose a universal action quota. Broaden again when evidence conflicts, verification fails, authority or blast radius remains unresolved, a required consumer is missing, or broad coverage is the requested outcome.

For a bounded named question, search the subject before reading general maps and architecture guides. Once the owner, diagnosis, and next check are supported, write a sufficiency checkpoint and require a named missing material fact before another inspection batch. An unavailable live or human check is a limitation to report, not permission to keep mining source for equivalent evidence.

Observed correction: The 0.5.12 Lanternworks probe found the correct Route Flow production path and plausible readability risk, but used 72 action calls before ending at one live Game-view check. A later same-revision search exposed the decisive documentation, controller, projection, catalog, world-view, and test paths immediately. The comparison motivates a sufficiency rule; it does not establish how many individual actions were unnecessary.

The first 0.5.13 candidate probe reduced the count only to 57 actions and used more aggregate input tokens. It announced that only live judgment remained, then continued reading source and checking editor-lock state. The final answer was sound, but the run remained operationally disproportionate.

The second candidate reduced the trace to 52 actions and roughly half the aggregate input, but still read the project map first, checked process state, omitted its sufficiency checkpoint, and continued after naming live observation as the remaining discriminator. The correction was structural: bounded named diagnosis became an early terminal branch instead of falling through the full delivery loop.

The third candidate followed the early branch, searched the exact subject first, skipped process-state inspection, and stopped at the native Game-view check in 29 actions. It still communicated sufficiency informally and gathered more composition detail than the final claim clearly required. That partial result is retained as a warning against optimizing a prompt until one trace matches its wording exactly.

Last updated on