Autopilot · write-up

AI errors — Xenon 2 autopilot investigation

xenondoc/AUTOPILOT_AIERRORS.MD · 256 KB · updated 2026-10-06

A retrospective on the sessions spent building the Xenon 2 exploration protocol, recorder, world-model UI, Python autopilot, and resident C autopilot. Built from the actual conversation history, including the user's repeated run-by-run corrections. Roughly chronological. Kept so the same mistakes are not repeated when the controller is extended to later levels or moved into dependency-free C.

The renderer has its own, much shorter retrospective from one session: AI errors: the shop-screen session.

Where the lessons are

With over 200 entries, the conclusions are easy to miss. They are not at the end of the entries but in separate sections, written at different stages of the work:

• Updated high-level recommendations, at the very end: the current rule set, 65 rules drawn from the whole log. Most are about terrain, routes and getting a planned route executed, where the autopilot failed most often. Read this first.
• Patterns behind these and Recommendations: the first summary, written in August after the first 55 entries. The patterns (guessing what could be measured, mixed coordinate systems, diagnostics added too late, success reported too early) recur throughout the later entries; the 17 rules are the original version of the current set.
• Level-3 low-cost operating rules: eight rules for working on a new level cheaply (checkpoints, one change per experiment) without breaking the finished ones, written after Level 2 was completed.

Each entry below names the mistake, its root cause and the recommendation drawn from it. The entries are roughly chronological; later sessions are grouped into addenda.

Errors

1. Proposed too much architecture before proving the smallest useful loop

The first proposals included several layers, tools, and possible learning systems before the basic external loop—restore, inspect one canonical frame, inject input, and repeat—had been validated. The user correctly said it was too complicated. Root cause: designing for the eventual browser and AI-training system instead of first establishing the smallest deterministic experiment harness.

2. Initially treated restored object identities as disposable

The first snapshot plan reset renderer identities after restore, which would make two branches from the same snapshot impossible to compare object-for-object. The user identified the problem and suggested a sidecar file; only then was identity state made restorable, with reset as the fallback when the sidecar is absent. Root cause: treating identity as rendering metadata instead of part of the experimental state.

3. Captured identity too late and duplicated tracking ownership

The renderer/extrapolator and the new analysis path initially risked maintaining separate notions of object identity. That would make extrapolated draws disagree with canonical-frame tracks. The capture point had to be moved so both consumers share the same identity assignment. Root cause: the feature was first designed from the external protocol outward rather than from the existing identity lifecycle inward.

4. Designed step fire around debugger stepping, then described a command that did not exist

The first client made step fire leave emulation paused, surprising the user, and the explanation referred to a run-with command that had not been implemented. This was both an API-design error and a communication error: a joystick action should not acquire hidden pause semantics, and documentation must describe the executable interface rather than the intended one.

5. The first autoplay run was not anchored to the reproducible snapshot

The initial controller could start from whatever state Hatari happened to contain. The user had to point out that assets/xenonplay.sav should be loaded so runs can be compared. Root cause: treating snapshot restore as a convenience instead of the first step of every experiment and regression.

6. Misidentified $0CC6 from a stale comment

I stated that $0CC6 was a weapon meter. The user corrected this: it is the shield bar, decreases when the ship is hit, and costs a life at zero. Root cause: repeating an existing comment as fact without verifying it against observed damage behavior or fresh disassembly.

7. Failed to create output directories before opening trace files

An advertised autoplay command failed because xenon_tools\second-run.jsonl was opened before its parent path was created. This was a basic workflow regression in a tool meant to reduce manual work. Root cause: testing only with already-existing local directories and not executing the exact command given to the user from the repository root.

8. Encoded sprite address ranges without explaining or validating their semantics

Pickup families were initially represented as unexplained hard-coded ranges such as $02328C..$023BA0. The user had to ask whether they were animation sequences and request visualizations. Root cause: using atlas addresses as convenient classifiers before building the inspection tools that make the classification auditable; the later animation-table contact sheet should have preceded the policy.

9. Treated objectId and spriteId as if their relationship were simpler than animation permits

Some early reasoning implicitly expected one sprite per tracked object. The user explicitly reminded me that one stable identity can emit many sprite IDs while animating. Root cause: mixing visual-frame identity with game-object identity, exactly the distinction the fixed identity system was meant to preserve.

10. The first controller ignored important visible classes

Early runs missed horizontal wall projectiles, failed to destroy wall-mounted shooters, and let released pickups drift past the ship. Detection, target classification, hit telemetry, and collection behavior were added reactively after each visible failure. Root cause: beginning movement tuning before establishing a reviewed object taxonomy and explicit acceptance tests for every important class already present in the renderer stream.

11. Used screen-space motion in a world-space game model

Scrolling changes object screen Y even when its world position does not change. Several early predictions and velocities used rendered coordinates, which contaminated aim, projectile motion, formation paths, and navigation. The clearest later symptom was a wall projectile reported as velocity (6,1) even though its world Y velocity is zero. Root cause: adding world_y as another field without making world space an enforced boundary for all persistent state and prediction code.

12. Built a local obstacle reaction instead of a persistent world map

The first dead-end attempts reasoned mainly from currently visible wall tiles. This could not represent a corridor larger than the screen or remember the route back around an upside-down U. The user repeatedly asked why learned off-screen walls were absent. Root cause: treating the tile stream as a current collision mask rather than incrementally observed level geometry.

13. Repeatedly patched dead-end steering symptoms instead of fixing planner/controller ownership

Across many runs the ship hit the right wall, then the left wall, alternated left/right/up, failed to hold the corridor center, or stopped moving despite a sensible escape route. I repeatedly adjusted direction preferences and thresholds; the same defect returned in a different wall. Root cause: the planner produced a world path, but tactical scoring and one-frame steering could override it without a clear contract, latched phase, progress measure, or regression fixture.

14. Let combat and worm targeting override required retreat

The controller stayed in formation_hold while already in a dead end, targeted worms in other corridors, and sometimes aimed at a worm coming directly into the ship instead of dodging it. The user correctly emphasized that every segment causes damage and immediate survival must outrank shooting. Root cause: target priority and movement ownership were conflated; selecting an attractive target accidentally granted that target control over navigation.

15. Tried to destroy or aim at enemies without first proving reachability

Wall shooters were listed as targets while the ship did not move below them; worms separated by a wall were targeted with forward or rear weapons; followers that would not enter the firing lane soon were preferred over reachable enemies. Root cause: ranking semantic importance before checking a clear weapon lane, bullet travel time, wall occlusion, and near-future intersection.

16. Targeted formation followers instead of the path leader

Several runs selected an arbitrary follower even though all members replay the leader's path. The user had to restate that killing and then promoting the earliest surviving member lets one fixed lane hit the entire stream. Root cause: ranking individual rectangles by present proximity instead of modeling the formation as one ordered trajectory.

17. Added target seeking that made the ship oscillate left and right

The ship repeatedly “danced” between exact intercepts, pickups, and target centers. This was visible even when holding one X coordinate would eventually hit every follower. Root cause: recomputing a point target every frame, using narrow tolerances, and allowing immediate objective changes instead of latching a firing region with hysteresis.

18. Ignored projectile flight time in early aiming behavior

The controller initially aligned to current target X or chased moving carriers rather than solving where the target and bullet would meet. The user explicitly asked whether bullet travel time was being considered. Root cause: target selection and aiming were implemented as one-step geometry rather than a measured projectile-speed intercept in world coordinates.

19. Carrier interception chose “earliest possible,” not “least ship movement”

Even after adding a fixed carrier intercept, _carrier_intercept_lane selected the first legal lane. In the recorded early swarm failure this pulled the ship from x≈160 to x≈51 to meet a carrier near x≈25, leaving it badly positioned before the swarm. The corrected rule considers the carrier's near-term path and latches the crossing closest to the ship; root cause was optimizing time-to-first- shot while ignoring the strategic cost of abandoning the safe center lane.

20. Pickup collection had unconditional tactical priority until danger was already immediate

At frame 84366 of the failing run, the controller abandoned its swarm lane for an attachment moving in the opposite direction. The ten-frame emergency horizon took over nine frames later, when all actions already predicted collision. Root cause: a coarse priority list—“pickup unless imminent collision”—instead of checking whether the pickup command is compatible with preparation for a known approaching hazard. The eventual fix uses a longer conflict guard but still permits pickups whose collection region overlaps the safe lane.

21. Swarm prediction was initially too short and too unstable

The first circular swarm takes three to four seconds to loop into the firing lane, but early policy looked only a small number of canonical frames ahead. Last-frame velocity/acceleration estimates also made displayed paths change sharply between frames. Root cause: using a generic local extrapolator for a scripted motion system whose update procedure and command tables were available for exact analysis.

22. Confused long-range prediction with emergency escape

Extending swarm prediction initially risked entering swarm_escape several seconds too early and preempting safe pickups. Later, shortening the emergency horizon without a separate preparation horizon allowed pickups to ruin the lane before escape activated. Root cause: representing awareness, preparation, and emergency reaction with one boolean/horizon instead of three distinct concepts.

23. Did not make the controller obey the visualized lane

The UI could show a stable vertical swarm lane while the ship continued moving left and right. Scoring from other objectives and exact-point corrections still overrode the lane shown to the user. Root cause: visualization exposed an advisory value, not a controller invariant; diagnostic intent and applied movement were produced by different arbitration paths.

24. Introduced severe replay/autopilot slowness with repeated trajectory reconstruction

When swarms appeared, live play and replay spent most of their time “Reconstructing frame.” Scripted paths, follower chains, and candidate hazards were recalculated for many objects, horizons, and nine actions. Root cause: writing clear query-style prediction functions without accounting for their combinatorial call count; per-frame displacement series and follower anchors should have been cached from the start.

25. Implemented formation avoidance too late and too locally

The controller could predict a worm but still enter its chain, then suffer several segment hits. During retreat it either followed the route blindly or dodged without preferring a safe action that also made route progress. Root cause: one-frame scoring cannot reliably steer around an articulated multi-segment hazard; it needed bounded space-time search with survival lexicographically ahead of route proximity.

26. The first persistent-map UI did not actually display persistent history

The world pane initially drew grey cells only for the current screen even though the requested view was the whole discovered map. It took multiple corrections before off-screen learned rows remained visible. Root cause: the UI was still fed the current-frame wall list (and later invalidated cells at clipped edges) instead of rendering the mapper's monotonic world-cell store.

27. Added “go to frame” ambiguously and incompletely

The replay UI exposed both a large canonical game-frame number and a small recording index, and the first “go to frame” work either was missing from the visible layout or accepted the wrong numbering. The user had to explain which number their feedback referenced. Root cause: exposing two coordinate systems in time without distinct names, labels, and one explicit seek contract.

28. Corrected the wrong UI pane after a precise layout request

When asked to make the details pane taller and expandable instead of list_frame, I enlarged selection_details, the next pane, rather than the named one. Root cause: editing by approximate visual adjacency without tracing the widget hierarchy and confirming the exact variable requested.

29. Backward replay was slow because state reconstruction was treated as stateless seeking

Moving back one frame rebuilt tracking, prediction, controller, and map state from the start. The user had to request caching of recent reconstructed frames. Root cause: optimizing forward playback only and not modeling interactive debugging—where short backward steps are common—as a first-class workflow.

30. Terminated a recording abruptly instead of using the protocol's graceful shutdown

When asked to stop a run, I killed the process and lost/aborted output rather than pausing Hatari, stopping the event log, saving the checkpoint, releasing input, and then exiting. The user explicitly asked that future stops be graceful. Root cause: treating “stop now” as process control rather than a stateful recording transaction.

31. Misunderstood the requested recording wrapper and then caused a second-client timeout

The first record_run.py covered only one player workflow even though the user intended human and autopilot modes. The initial autopilot wrapper also launched/connected in a way that left the reactive client timing out during subscription. Root cause: composing command-line snippets without defining which process owns the socket, Hatari input claim, logging lifecycle, and shutdown order in each mode.

32. Reported a recorder fix as if it answered gameplay feedback

After the user supplied a detailed list of pickup, shooter, swarm, and dead-end failures, my response focused on fixing the recording script. The user had to ask whether the actual autoplay errors had been fixed. Root cause: losing the primary objective while addressing the most recent implementation failure, and not separating “tooling fixed” from “strategy analyzed” and “strategy verified.”

33. Used magic procedure addresses in C, ReVa notes, and Python

Values such as $E1E, $9AC0-family routines, and object offsets appeared as raw numbers in several layers. The user requested symbolic names and matching ReVa function/comments. Root cause: allowing reverse-engineering discoveries to remain local literals instead of maintaining one end-to-end vocabulary across disassembly, capture, decoder, classifier, diagnostics, and tests.

34. Modeled ship movement approximately for too long

Steering behavior, reversal delay, speed upgrades, edge clamps, and scrolling were initially inferred from observations. This contributed to lane oscillation and a controller that did not follow valid dead-end waypoints. Only much later did I disassemble $661C and mirror its $CDE steering and vertical movement arithmetic. Root cause: tuning a controller around an unknown actuator instead of recovering the small, deterministic movement function first.

35. Represented the route as quantized staircase waypoints and followed points already behind the ship

Early dead-end paths snapped to tile/grid coordinates, alternated horizontal and vertical segments, ran too close to walls, and sometimes placed the first waypoint above or beside the actual ship. The controller then steered back toward a consumed point. Root cause: using cell centers as the control trajectory without diagonal A*, line-of-sight smoothing, a real ship-anchor start, clearance reserve, segment projection, and monotonic waypoint consumption.

36. Chose collision geometry by convenience before verifying what the game uses

The first configuration-space discussion considered atlas alpha masks and a visually very wide 32-pixel ship footprint. The user correctly asked to verify the game's collision rectangles. Root cause: conflating renderer pixels, diagnostic rectangles, and gameplay collision fields; the game's $36..$3C rectangle should be primary, with renderer geometry only as a documented fallback.

37. The world-map visualization used a distorted aspect ratio

Sixteen-by-sixteen Atari wall tiles appeared twice as wide as high, making the yellow ship reserve look excessively wide and undermining confidence in navigation geometry. Root cause: independently fitting X and Y to the widget rather than using one pixels-per-world-pixel scale. A diagnostic view must preserve geometry before it can be used to judge clearance.

38. Dead-end detection triggered falsely and then latched indefinitely

One revision began in dead_end_retreat in open space and stayed there until the ship stopped. Other revisions detected a real dead end too early because the map did not yet contain enough forward space. Root cause: interpreting incomplete/unknown map extent as proof of blockage and re-evaluating retreat from unstable partial routes instead of requiring a discovered-space topological condition and latching a valid escape endpoint.

39. Persisted clipped wall draws into the wrong tile rows

One captured wall rectangle could become two solid world rows when its clipped edge was floored into neighboring cells. At frame 5882 this fabricated an occlusion that rejected otherwise reachable wall shooters. Root cause: rasterizing screen rectangles generically instead of recovering the original 16-pixel source-tile alignment and accounting for source_offset_y.

40. Diagnosed a player bullet as spawning behind a wall because stale collision words looked plausible

Projectile #3215 appeared remote in the diagnostic UI even though its current draw was directly above the ship. The object slot had been recycled and $36..$3C still contained the previous occupant's rectangle; I initially reasoned about pooling before proving which fields were active. Root cause: trusting generic object collision fields for a bullet procedure that does not refresh them. Current renderer bounds, lifecycle status, and stable identity had to be evaluated together.

41. Added fast-forward without compiling against the actual declaration surface

The Windows build failed because Configuration_ChangeFastForward was called without a visible prototype. I also repeatedly attempted the known-broken Visual Studio build directory before using build2, despite the user telling me it was available. Root cause: validating the concept and Python side without immediately compiling the exact C configuration the user uses, plus failing to retain a known environment-specific build instruction.

42. Assumed host fast-forward could not affect control quality before measuring it

The initial documentation claimed full-speed mode changed only wall-clock duration and left behavior unchanged. The user observed a negative autopilot effect and asked that it not be used. Even if Atari cycle timing is unchanged, socket scheduling, UI work, buffering, and decision delivery can still affect a host-coupled controller. Root cause: reasoning from emulator semantics while ignoring the external real-time control loop.

43. Forced DOWN during retreat without knowing the game's authoritative scroll limit

The controller kept pressing DOWN when backward scrolling no longer advanced, or released it based on an empirical plateau. Only after the user asked for ReVa analysis did disassembly show the exact gate: at the bottom action boundary the game requests backward scroll only while $CD0 != $CEA. Root cause: adding heuristics around an unknown game-state machine instead of exposing its small set of live boundary variables.

44. Declared dead-end fixes successful before replaying the reported failure state

For days, several changes were described as fixes, but the next recording showed the ship still alternating, touching walls, or ignoring the planned route. Root cause: testing helper functions and new synthetic cases without replaying the exact failing frame range and without a live end-to-end criterion such as “exit the U without shield loss.” This consumed time, tokens, and user trust.

45. Added regression tests only after many repeated failures

The user eventually asked whether there was an automatic test for previously reported bugs. There was not enough coverage tying recorded frames to tactical invariants, so old failures reappeared as new strategies were added. Root cause: treating recordings as material for manual inspection rather than a growing corpus of deterministic regression fixtures.

46. Let tactical targets choose the strategic corridor

Pickup collection, wall-shooter prepositioning, formation lanes, and swarm lanes could each steer the ship toward their local target even when the persistent map route had selected another branch. This was a major reason the ship entered known dead ends, chased unreachable enemies through walls, or alternated left and right as two goals took turns winning. Root cause: target priority, tactical aim, route selection, and immediate joystick ownership were represented by one score instead of separate decisions with explicit compatibility checks.

47. Recomputed swarm and formation intent without stable ownership

The controller could have a correct shared swarm lane and still dance around it because each frame reconsidered whether the lane, a newly promoted leader, or the navigation route owned horizontal movement. One attempted correction let the swarm lane override the route completely and immediately made survival worse. Root cause: treating arbitration as a fresh per-frame optimization rather than latching one owner for a maneuver and defining a precise release condition.

48. Allowed tactical dodges to discard the strategic route endpoint

A worm or swarm dodge could move the ship away from the current polyline. Replanning from that temporary position sometimes selected the same bad branch that the original route had rejected, or connected to an obsolete intermediate waypoint. Root cause: conflating “temporarily left the route” with “the mission changed.” Dynamic avoidance needed to reconnect to the retained suffix and fixed world-space endpoint rather than silently choose a new strategic destination.

49. Used one-frame hazard scoring for articulated worms

Individual worm segments were scored as nearby hazards, but a move safe against the closest segment could enter the path of the rest of the chain. One collision then commonly produced several hits. Root cause: greedy candidate scoring was structurally incapable of planning through moving, multi-segment geometry. The eventual bounded space-time search had to rank survival time first, segment exposure second, and progress along the retained retreat route only after both.

50. Kept a retreat label after the retreat mission was complete

Earlier routes remained active well after the ship had left a previous corridor, sometimes pointing far backward when only a short return to the junction was necessary. Hazard detours also caused the controller to re-enter formation or combat tactics before finishing the forward leg out of the U. Root cause: retreat was treated as a transient tactic name instead of a mission with a fixed turn, escape endpoint, scrolling phase, reconnection phase, and explicit world-Y completion condition.

51. Stored the wall-map revision but never used it to invalidate a route

The controller recorded navigation_map_revision, yet ordinary navigation did not compare it with the current persistent map. When newly rendered rows revealed a cap, the old polyline still pointed forward into what had now become a known dead end. The ship followed it until physical wall collision even though A* could already find the way back. Root cause: adding persistent mapping without making newly discovered geometry an input to route validity. Normal routes must replan on a map revision; an already-valid retreat mission must remain latched instead of restarting.

52. Mistook “all motion prediction uses world coordinates” for “screen position never matters”

Object trajectories, projectile velocity, aiming, and persistent paths correctly belong in world space, but the ship's vertical screen position controls its reaction time. The controller repeatedly stayed near the top, leaving almost no room to dodge a newly arriving swarm. Root cause: applying a correct coordinate-system rule beyond its domain. Screen Y is authoritative for a reaction-budget policy even though enemy motion remains world-space. The current policy actively returns toward a safe band, with more reserve when no rear cannon is installed; immediate survival may override it.

53. Let targetless combat and stale routes suppress progress

combat_hold could remain active for a wall shooter that was visible in the object stream but had no reachable firing lane. Separately, a route ending behind the player could remain selected after the ship had already advanced beyond the last discovered wall row. Both states produced apparently unmotivated neutral input. Root cause: checking whether an object or path existed, but not whether it still supplied a reachable, forward-relevant action. Targetless combat now becomes advance, and stale backward routes are discarded until new forward rows are observed.

54. Added long-horizon dynamic prediction without budgeting replay cost

Formation and swarm avoidance began reconstructing many future object rectangles for every one of nine actions. Live autoplay and especially replay spent most of their time in “Reconstructing frame.” Root cause: implementing the correct model as repeated query functions rather than one shared per-frame prediction product. Script displacement, follower anchors, swept rectangles, and configuration-space tests needed caching and early hazard culling before increasing the horizon.

55. Stopped the first successful validation before the requested end condition

After a run successfully left the first dead end with all lives, I stopped and reported the local improvement. When the user asked whether it had reached the shop, the answer was no. Root cause: substituting the most recently fixed milestone for the actual acceptance criterion. A navigation fix is not an end-to-end success until the normal-speed run reaches the shop, records damage/lives, saves the checkpoint, and releases input gracefully.

Current validation baseline (2026-08-20)

The current controller has now passed four consecutive normal-speed runs from assets/xenonplay.sav; the three explicitly repeated verification runs are autoplay-demo-0820-27.x2events, autoplay-demo-0820-28.x2events, and autoplay-demo-0820-29.x2events. Every run:

• reached the shop automatically;
• lost zero lives;
• took one hit for four shield points (39 -> 35), associated with horizontal projectile update procedure $004180;
• collected 15 pickups, including the rear cannon;
• scored 12,600 points; and
• detected, followed, and completed the first dead-end retreat without becoming stuck.

These identical results are useful evidence that snapshot restore, canonical-frame control, and normal-speed execution are deterministic. They are not evidence that later levels, different equipment states, alternate snapshots, or host fast-forward are solved; those need separate acceptance corpora.

Patterns behind these

• Plausible inference substituted for direct evidence. The $0CC6 label, approximate ship movement, scroll boundary, collision geometry, and projectile rectangle were all discoverable from behavior or disassembly but were initially guessed or inherited from stale comments.
• Coordinate systems were not enforced architecturally. Screen/world position, tile/configuration coordinates, widget pixels, game-frame numbers, and recording indices were repeatedly mixed. Merely naming both values is insufficient; APIs must make invalid combinations difficult.
• Objective selection, movement ownership, and safety were conflated. A pickup, carrier, formation, or retreat route could be the selected target and thereby unexpectedly control the joystick. The system needed explicit arbitration and compatibility checks, not a longer priority list.
• Local patches were applied to global navigation failures. Left/right constants and mode-specific exceptions could not repair a broken contract between persistent planning and exact ship control.
• Diagnostics were added after failures instead of before policy. Sprite-family visualization, world-map history, lane overlays, movement goals, lifecycle flags, and scroll bounds all became available only after opaque behavior had already consumed several iterations.
• Exact recordings were inspected manually but not immediately converted into tests. This allowed dead-end, pickup, swarm, and reachability regressions to recur.
• Completion was communicated too early or at the wrong layer. A helper passing, a recorder fix, or a plausible reconstructed action was sometimes reported as if the gameplay outcome had been fixed. The required distinction is analysis, implementation, offline replay, and live validation.
• State was captured without being made authoritative. navigation_map_revision, persistent endpoints, collision rectangles, and scroll bounds existed before all controller decisions were actually required to respect them. Exposing a value is not enough; its invalidation and ownership contract must be tested.
• World-space correctness was confused with eliminating every screen-space policy. Persistent geometry and motion belong in world coordinates, while reaction time, camera visibility, and shop transitions are inherently screen/camera concerns. The boundary must be explicit rather than forcing either coordinate system everywhere.

Recommendations

1. Start every behavior change from one reproducible snapshot and one named failing frame range. Preserve identity sidecars, canonical inputs, compact RAM state, and expected outcome. Convert the failure into a regression before changing strategy.
2. Recover deterministic game mechanisms before tuning around them. Disassemble movement, scrolling, collision rectangles, object lifecycle, and scripted motion; expose the authoritative state in the canonical frame rather than polling it separately or inferring it from pixels.
3. Make world coordinates the type-level default for modeling. Keep screen coordinates only at capture/projection boundaries. Give map cells, world pixels, screen pixels, and UI pixels explicit conversion functions and names.
4. Separate four decisions: what matters, what is reachable, where to prepare, and what is safe now. Target priority must not directly own movement. A tactic should propose a world-space goal; safety and navigation should accept, defer, or route to it under explicit invariants.
5. Treat formations and swarms as trajectories, not bags of sprites. Target the earliest surviving member, latch a shared firing region, predict through the complete relevant period, and promote the next member without moving the lane.
6. Use regions and hysteresis, not exact points, for ship control. A firing lane, pickup envelope, corridor centerline, and waypoint tube should all tolerate at least one real ship step and account for the steering accumulator before reversing input.
7. Let persistent navigation own retreat until a precise terminal condition. Immediate survival may interrupt it, but safe alternatives should prefer route progress and then reconnect to the same escape endpoint. Never reinterpret unknown map space as a confirmed dead end.
8. Build diagnostic truth before adding another heuristic. The UI should show the exact collision rectangle, world path, movement goal, predicted hazard ribbon, selected target, rejected-target reason, applied input, and authoritative scroll bounds used by the controller.
9. Cache prediction by object, canonical frame, and horizon. Generate scripted displacement once, recursively derive follower positions once, and share those results across nine candidates and the UI. Profile whenever a new long-horizon model is introduced.
10. Validate at four levels and report them separately: unit invariant, exact-recording replay, normal-speed live run, and full-level outcome. Do not call a bug fixed when only the first level has passed.
11. Keep one symbolic vocabulary end-to-end. ReVa names, C constants, protocol fields, Python symbols, UI labels, and documentation should use the same names; raw addresses belong in the definition and evidence, not scattered through logic.
12. Design tools around the actual human investigation workflow. Commands must create output directories, stop gracefully, release input, distinguish game frame from record index, support quick backward stepping, and reproduce the exact command line on Windows and Linux before it is handed to the user.
13. Assume external scheduling can affect an emulator controller until measured otherwise. Keep normal-speed runs as the correctness baseline and treat fast-forward as a separately tested performance mode.
14. When user feedback disproves a design repeatedly, stop tuning it. Reconstruct the complete causal chain—from captured state through model, arbitration, planner, controller, and applied input—before making the next change.
15. Invalidate ordinary routes when persistent geometry changes. Replan against the complete discovered configuration map when its revision advances, but do not let that restart a retreat mission whose endpoint and phase are already valid.
16. Keep a deliberate vertical reaction-space band. Use screen Y only for this camera-relative safety policy; keep enemy/projectile prediction and navigation in world space. Permit predicted immediate survival to override the band temporarily, then actively return to it.
17. Define the live outcome before starting validation and run through it. For level 1 the current gate is: normal speed, shop detected, zero lives lost, no retreat stall, damage and pickup metrics recorded, checkpoint saved, and input released. Repeat deterministic runs, then add varied snapshots/equipment before claiming generality.

Level-2 completion addendum (2026-08-24)

The earlier postmortem correctly identified the unverified input/collision model, but completing the level exposed a second class of process errors after that model was repaired.

56. Used full playthroughs as the discovery loop

The Level-2 investigation accumulated 164 level2-*.x2events files and roughly 2.45 GB of event data. Many runs repeated already-solved sections merely to reach one new junction, spawn gate, or boss state. Root cause: checkpoints were created late and the experiment was specified as “try the level again” instead of “branch this one state through these bounded alternatives.” This consumed time, storage, and context while producing weak comparisons.

57. Added generic mechanisms for level-specific mission facts

Several dead ends and boss corridors were facts of the static level layout, but I tried to make generic A*, tactical arbitration, beam search, pressure relief, and route recovery infer them during play. Each extra mechanism added another movement owner and another opportunity to regress earlier areas. The final successful solution was much smaller: an explicit world-space Level-2 backbone, one fixed left-corridor choice, and a latched three-step boss entry. Root cause: treating a known mission route as an online intelligence problem.

58. Let a geometrically valid shortest route stand in for a playable route

The complete-map A found collision-free paths, but some hugged worm-bearing walls, required awkward four-pixel corners, or entered tactically lethal pockets. A shortest configuration-space path does not encode reaction space, spawn direction, weapon coverage, or the cost of later backtracking. Root cause: accepting “does not intersect a wall” as the whole navigation objective. The strategic route must use corridor centre lines, explicit junction choices, and retreat anchors with room to turn; live A is only a local connector back to that route.

59. Recomputed route meaning after temporary avoidance

Swarm, worm, pickup, and projectile maneuvers sometimes caused navigation to replan from the displaced ship position and choose a different branch. This turned a safe temporary detour into a changed mission and repeatedly re-entered known dead ends. Root cause: failure to distinguish the retained route suffix from the ship's current connection to it. Avoidance may replace the next few controls, but never the selected corridor or backtrack endpoint.

60. Disassembled scripted encounters too late

The final Level-2 boss controller at $50DE6 was present throughout the lower map, but remained a generic controller until the route had already reached its arena. Once its timer, health, world-Y anchor, velocity and collision rectangle were read from disassembly, the boss needed only a stable left-side weapon lane and camera regulation. Root cause: spending runs tuning symptoms before identifying the authoritative scripted state already available in the object.

61. Increased prediction/search cost before proving it changed the decision

Longer horizons, beam widths, formation reconstruction and repeated future-rectangle generation made both live control and replay slow. Several expensive additions did not affect the selected safe action, and some obscured the simpler route bug underneath. Root cause: no performance/effect gate. A new predictor must first change the result of one minimal failing fixture, reuse a per-frame cache, and stay outside the common path when its object family is absent.

62. Changed shared arbitration while validating a single new region

Some Level-2 fixes modified generic combat, retreat, swarm, or route scoring and then caused failures in Level 1 or an earlier Level-2 section. Root cause: a level-specific observation was allowed to change global policy without a cross-level regression gate. Known level geometry and scripted boss sequences belong in declarative level policy; shared code changes require a demonstrated shared model error and must pass the established Level-1 and Level-2 fixtures before a live run.

63. Reached the requested terminal state but still tolerated avoidable boss damage

The final acceptance run reached playable Level 3, yet the long final-boss engagement lost one life to four $4180 horizontal-projectile hits. This is honest completion evidence, not proof that boss combat is solved. Root cause: the side-cannon/camera lane was sufficient to kill the eye but did not reserve a separate vertical dodge lane for the boss's projectile rows. Later work must not weaken the validated route to address this; it needs one boss-local avoidance fixture.

Level-3 low-cost operating rules

1. Freeze generic navigation, combat arbitration, ship transition, and camera code at the Level-2 acceptance baseline. A Level-3 symptom may change those only after a minimal replay proves a cross-level model defect.
2. Start with the complete resident Level-3 tile map. Plot a world-space centre-line route, mark every junction, cul-de-sac, closed boss/shop door, and any segment that requires deliberate backtracking. Online A* connects the ship to the retained route; it does not select the mission branch.
3. Use the Atari map as geometry truth. Use external guides only to annotate attack direction, valuable pickups, recommended weapons, and encounter staging; the Master System map and economy are not assumed identical.
4. Create a checkpoint at each new scripted boundary. Explore it with short runs or snapshot branches, not a replay from the start of the level.
5. Before adding a new object-specific tactic, capture its update procedure, lifecycle/active fields, world position and collision/damage evidence. Prefer a table/constant and a small state machine to another scoring term or search dimension.
6. Add at most one level-policy change per experiment. It must pass a synthetic route invariant, the previous Level-1/Level-2 regression subset, and a replay from the nearest checkpoint before a live acceptance run.
7. Cache all route and prediction products by canonical frame. Do not extend the beam horizon or add a new search unless the minimal fixture has no safe solution under the exact current model.
8. Define the Level-3 acceptance condition before running: reach its end shop/next playable level at normal speed, preserve the retained route through required backtracking, record both AVIs and .x2events, save the final checkpoint, report all damage/lives, and release input gracefully.

64. Confused route ownership with permission to advance

The first Level-3 implementation correctly retained the offline corridor route, but its tactic was selected above pending-spawn pacing and pressure relief. Those phases still detected the approaching encounter and calculated a safe delay, yet never received control; the route kept pushing the camera until $4F244/$4F24E and $50690 formations spawned almost on top of the ship. Root cause: treating “this is the chosen corridor” as “move along it on every safe-looking frame.” A mission route owns branch choice and the suffix after avoidance. It must yield progress—without being discarded—to bounded encounter pacing, then resume from the same suffix.

65. Guessed installed weapons from projectile motion despite semantic inventory

The Level-3 checkpoint contained Side Shot in the captured attachment table, but WorldState persisted weapon directions inferred from two-frame projectile velocities and reported Rear Shot. Target reachability and reaction-space policy were consequently evaluated for a weapon the ship did not own. Root cause: retaining an observation heuristic after the authoritative attachment-to-shop mapping had already been added to the protocol. Captured semantic inventory is now authoritative; projectile inference is only useful before such inventory exists.

66. Treated every attachment pickup as an upgrade

At frame 37980 the ship crossed a Rear pickup while Side Shot was installed. Both use the wing mount, so this did not add a weapon: it silently discarded the Side Shot prescribed for Level 3. The pickup was not even the active target; the pacing route happened to intersect it. Root cause: pickup priority modeled permanence and cash value but not mount conflicts or the current level's preferred loadout. An incompatible replacement must be excluded from targeting and treated as an object to avoid, not as a universally beneficial collision.

67. Allowed encounter pacing to abandon the mission corridor

The correctly equipped run survived the opening encounters but drifted from the X160 Level-3 route to X258 at the bottom of a right-hand pocket. When danger cleared, the pocket opening was already beyond the game's 16-pixel backward-camera allowance. LEFT and UP then alternated through $42E wall replay indefinitely. Root cause: pending-spawn pacing was correctly allowed to pause route progress, but was exempt from the route tube altogether. Immediate survival may leave the route; once no collision is imminent, pacing must reconnect to the retained suffix before triggering more camera progress.

68. Added a second route for a job that needed only one axis

Level-3 spawn pacing generated its own configuration-space path to screen Y 172 even though the offline mission route already owned the corridor. At scroll 4112, the pacing path pulled the ship from Y 176 to Y 171; the pacing controller then pushed it back down. The two commands repeated without crossing the spawn boundary. Root cause: turning a bounded vertical delay into another navigation mission. Level 3 now uses safe DOWN only for the delay and retains the fixed route as the sole corridor owner.

69. Controlled an inertial ship from one-frame displacement

The first route-tube repair ranked candidates by their next predicted endpoint. Xenon's $661C horizontal steering accumulator means pressing LEFT can still move right for one frame. The controller interpreted that expected inertial displacement as evidence that LEFT was wrong, reversed the input, and oscillated forever between X 191 and X 200. Root cause: confusing the correct control intent with its delayed physical response. A route re-entry now commits to the input direction toward the centre line until momentum reverses; the exact movement model remains in collision prediction, where it belongs.

70. Mistook the installed attachment for the released pickup

The first review of run 13 claimed that the Rear Shot appeared under the ship at frame 38052 and was therefore unavoidable. That object was the newly installed attachment, not the released item. The actual released Rear Shot was identity 290885: it was already visible at frame 38011 and used updateProc=$4EA0, payload/status $44, and terminal-handler index 4. The controller spent more than forty frames moving toward its future drop lane before collecting it. Root cause: inspecting only the allocation at the end of the lifecycle, plus treating $4EA0 as generic linear motion.

Disassembly shows that $4EA0 is deterministic. Object words at +$28/+$2A hold a signed phase timer and direction. The item converges on screen (160,100), circles clockwise for 34 frames, then falls eight pixels per game frame at a fixed X. The fix captures those two existing object words, predicts the exact drop lane in world space, and rejects only inputs whose $661C braking coast crosses it. This preserves the retained Level-3 route and ordinary pickup collection. Run level3-rear-avoidance-0825-16.x2events kept Side Shot for all 800 captured frames; the Rear Shot fell off-screen at frame 38064 without collection.

71. Chased an articulated target instead of selecting an intercept lane

The first Level-3 composite tactic recomputed the vulnerable core's short bullet intercept every frame. Because the carrier reverses and crosses the screen, this made the ship follow it left from X201 to X169. The forward weapon lane moved continuously, the Laser missed useful crossings, and the ship entered the chain tail. Root cause: confusing target prediction with ship movement policy. For a scripted crossing target, predict a later useful crossing once, latch that world-space firing lane, and let the target cross the bullets.

72. Allowed survival arbitration to violate hard tactic configuration

The composite tactic correctly filtered immediate actions to its X/Y staging region. Generic survival arbitration later narrowed the candidate set to only DOWN; when the configuration filter found no valid intersection, it returned that invalid singleton as a fallback. The ship therefore left the staging band even though the diagnostic goal remained correct. Root cause: an ambiguous filter contract in which “no permitted candidate” meant “accept the caller's input.” Hard geometry filters now return an empty intersection, and the caller re-arbitrates over the complete configuration-valid set.

Level-3 navigation and survival addendum (2026-08-27)

73. Let Level-3 experiments grow for hours without bounded acceptance points

More than 4,500 lines accumulated while repeated full runs still entered the same labyrinth pockets, oscillated at walls, and lost lives. Small encounter rules were added faster than their assumptions could be disproved, so later failures were hard to attribute and previously passed regions regressed. Root cause: using the live playthrough as both model discovery and acceptance testing. Each new region needs a nearby checkpoint, one stated invariant, one model change, and a short deterministic replay before the full run resumes. Unverified staging, brace, and scoring rules should not remain merely because they helped one attempt.

74. Built the offline route on a wall model that treated destructible gates as permanent

The first Level-3 route and persistent-map analysis contained disconnected segments, including no credible connection between segments 1 and 2. Cells occupied by destructible gates or wall-mounted enemies were recorded as ordinary solid tiles even after destroying the object opened the corridor. The planner was therefore solving the wrong topology: it avoided required passages or declared them unreachable. Initial solidity, current solidity, destructibility, and observed-open state must be separate properties. Route connectivity must be evaluated on the expected post-destruction topology, while online collision continues to use the current topology.

75. Marked gates for destruction without planning a shot that could destroy them

The revised map could label a gate destroy, but the route sometimes passed neither through the gate nor through a front-cannon firing lane for it. Other destructible gates, such as the one at Level-3 tile (2,93), were omitted without a documented reason. A semantic marker is not an executable plan. Each required gate needs a reachable firing pose, weapon-direction and line-of-fire check, a hold/fire condition, positive evidence that the gate opened, and only then a traversable route suffix. Optional gates should be explicitly excluded rather than accidentally ignored.

76. Kept stale route and gate missions after the world topology changed

After a gate visibly opened, the ship still alternated forward and backward around the same location. The retained route, gate-attack state, local connector, and survival recovery could each own a different destination, and completion was not tied strongly enough to the observed open cell. Root cause: retaining controllers rather than retaining one mission state. Opening or destroying a gate must invalidate affected configuration-space paths, complete the attack subgoal, advance the route cursor monotonically, and prevent an older connector from reclaiming control.

77. Failed to model tile-embedded enemies as first-class interactable objects

At approximately frame 49334 of run 222, destroying a visually wall-like enemy opened a passage, yet the object was not classified or clickable like an ordinary enemy. Its spawned projectile was also given a misleading horizontal label. The renderer/object stream and tile map described different halves of the same mechanism. A tile-embedded gate launcher needs a stable semantic identity that links its object/update procedure, occupied map cells, spawned projectiles, destructible state, and the topology transition caused by its death.

78. Named a generic directional projectile from one observed direction

Objects updated by $4180, including #556275 through #556282, were classified as horizontal_projectile. Disassembly showed that $4140/$4160 are sixteen signed 2.14 direction vectors and that the reported volley used directions 0 through 7; #556277 travelled down-left, not horizontally. Root cause: promoting an encounter observation into a procedure-level semantic name. The generic type is now directional_projectile; horizontal, vertical, and diagonal movement are derived per object from its captured direction and exact world-space velocity. $50996 remains a separate reflecting/decorated variant rather than proof that $4180 is horizontal.

79. Displayed a useful long prediction while survival used a shorter one

The diagnostic overlay made the radial path look predictable, but the controller's ordinary horizon was eight frames and its special directional check reached only fourteen. #556277 struck about eighteen game frames after spawning, so the Level-3 route retained authority until avoidance was too late. Root cause: allowing visualization, target prediction, and collision arbitration to use different horizons without exposing the difference. Live directional projectiles now receive a 32-frame world-space hazard horizon; a visible predicted collision must enter the same survival model that selects controls.

80. Scored physically impossible escapes by moving the predicted ship through walls

The candidate scorer recorded the first static collision but continued advancing the simulated ship along the requested input. Xenon's ship update instead rejects/restores movement at a wall. This made a wall-bound command appear to move clear of a projectile even though the real ship remained pinned, which is exactly the dangerous state observed near frame 49081. Predicted ship motion must freeze at the last collision-free state (or reproduce the game's rollback precisely) and all later swept-hazard tests must use that constrained trajectory.

81. Found a complete escape, executed only its prefix, then replanned too late

In the first directional-projectile validation, the space-time beam found a complete safe 32-frame path. Only eight actions were retained. The discarded next leg was required around closest approach; when replanning resumed, every new first action already intersected the volley and the ship took four shield damage. Root cause: a mismatch between planning horizon and commitment horizon, not a failure to find a route. Complete directional-projectile escapes now retain sixteen actions through the critical phase, while revalidating them against new static and dynamic hazards on every frame. Other encounters keep the shorter commitment until separately proven to need more.

82. Let wall recovery restrict the survival search before proving the restriction was safe

When the ship was touching a wall, recovery logic narrowed the beam's first action to commands that looked useful for leaving the wall. That restriction could exclude the only action that avoided an incoming projectile. Root cause: allowing a navigation heuristic to constrain the safety envelope. Immediate projectile survival must search every physically valid first action; wall recovery and the retained mission route may rank otherwise-safe alternatives but cannot remove the only escape.

83. Reported the strategic tactic as though it were the applied controller

The UI continued to show analysis:level3_initial_route while a survival beam could actually override the joystick. Conversely, the same label made a genuine failure to yield look like a mere diagnostic problem. Root cause: one field was overloaded for mission ownership, tactical intent, and movement authority. Diagnostics now report the strategic tactic separately from control authority, such as survival:directional_projectile or survival:space_time_beam, so recordings can establish which layer selected the applied input.

84. Allowed navigation to win over a nearby high-value Zapper pickup

The ship passed close to the Y/Zapper smart-bomb pickup while the Level-3 route remained active. This was another instance of showing the right semantic opportunity without giving collection an executable, safety-checked intercept. Route progress is a preference, not a reason to discard a rare ship-related pickup. Valuable pickups need a reachable collection trajectory, sufficient disappearance margin, and a temporary route detour that preserves the retained suffix; they may still yield to an imminent collision.

85. Repeated a known build-environment failure instead of checking the process boundary

The documented Windows build wrapper was correct, but repeated sandboxed Ninja attempts stalled with no GCC child before a TTY run exposed MSYS2 cygpath/signal-pipe access failures. Running the same wrapper in its intended environment completed immediately. Root cause: treating an idle build as a compiler problem and retrying it instead of inspecting the process tree and the first failing runtime dependency. Use the documented build2 workflow once, distinguish sandbox/MSYS startup failure from C compilation failure, and do not spend iterations rediscovering the same environment constraint.

86. Treated a scoped validation as if it could establish global no-damage behavior

The final directional-volley replay survived the reported $4180 encounter, but the same recording still took an unrelated eight-point swarm hit earlier. That is evidence that the directional fix worked, not that the complete run was damage-free. Acceptance reports must name the checkpoint, encounter, frame range, shield delta, and any unrelated failures. A local model fix should first pass its focused fixture; global no-damage remains a separate regression goal.

87. Started after the useful firing station had already passed

The first Level-4 shooter experiment restored a checkpoint close to the reported frame. At that point the ship was already left of and nearly level with the wall target, so survival and wall recovery could not reproduce the earlier opportunity to sit below it. Root cause: choosing a checkpoint by frame proximity instead of by the lead time required by the tactic. Shooter staging must begin from a checkpoint before the target's world Y enters the engagement window; the focused validation now starts at level4-entry-inventory-0827-01.sav.

88. Modeled an installed Cannon as an unknown decoration

The attachment table already reported Cannon code $0034, but $4902 and its projectile $4e50 were classified as unknown objects. Combat therefore planned only the ship-centred ordinary bullet lane even though the live Cannon fired 26 pixels to the right. Root cause: equating installed-item knowledge with a complete weapon geometry model. Installed weapons must join shop semantics, live attachment objects, projectile update procedures, exact offsets, speed, and collision behavior.

89. Required a forward bullet to begin almost inside the target

The first Level-4 station test constrained the projectile's spawn Y to overlap the shooter within a few pixels. This rejected the user's valid station roughly half a screen below the target. Root cause: treating a firing pose as a one-frame collision instead of a clear future projectile path. Forward stations now allow bounded upward travel, and flight time is derived from the selected projectile's speed and spawn offset.

90. Invented wall occlusion that Xenon's projectile code does not implement

The attack planner rejected otherwise valid shots when the persistent tile map intersected a vertical ray. Disassembly shows ordinary $6086 bullets call point-vs-object helper $3950, while Cannon $4e50 uses the rectangle path at $3908; neither queries wall tiles. Root cause: importing conventional shooter physics instead of following the game's collision implementation. Walls still constrain the ship configuration space, but they must not block a projectile path unless the game code actually tests them.

91. Selected the first reachable weapon and later aimed with another one

The planner initially retained a zero-clearance centre-shot route at ship X about 258. Once the live Cannon lane became apparent, aiming switched to cannon-forward, but the old route continued pushing the ship into the right wall. Root cause: weapon choice and firing station were computed in different stages and were not one coherent decision. The planner now evaluates all installed forward lanes, chooses maximum wall clearance before shortest path, and latches weapon offset, projectile spawn offset, station, and route together.

92. Corrected a screen-script prediction after planning instead of preserving one world-space contract

The Level-4 escape planner initially found a path that the emulator could execute safely, then discarded it during queued-plan validation. The first attempted fix applied camera corrections in the validator itself. That duplicated a conversion already performed by the beam and violated the documented rule that planners consume world geometry. The game may store a script anchor relative to the screen, but that is an input-format detail: it must be converted at the prediction boundary, and every diagnostic, scoring, beam, and revalidation consumer must receive world rectangles.

93. Captured $E36 objects but omitted their semantic +$56 target link

Disassembly of $E36->$613E shows that it copies X/Y from the MyObject pointer at +$56. In the failing Level-4 swarm, each $E36 member pointed directly to an $E1E scripted leader. The raw bytes were already recorded, but Python interpreted the follower as an independent stationary object and did not inherit the leader's camera-dependent world trajectory. The model now exposes follow_target_object_id, resolves that object graph, and predicts the follower from its target in the same canonical frame. The global active-list link at +$12 is not a substitute for this field.

94. Turned an optional rear-cannon opportunity into a permanent combat mission

After passing the first Level-4 shooter, the controller found no safe below-shooter approach to the upper-right emplacement. It nevertheless latched a route across the live horizontal projectile lane so it could attack rearward, then rebuilt that route for hundreds of frames around scroll 3860. Root cause: static A* reachability was treated as proof that an optional combat mission was temporally executable. Proactive Level-4 shooter attacks now require a real forward/Cannon station below the target. Rear fire is opportunistic after normal navigation has already passed a shooter; it never owns a crossing. The known upper-right emplacement remains a full survival hazard but does not suspend route progress. In validation run 13 the ship advanced from scroll 3860 to 3647 without damage and destroyed the emplacement incidentally while progressing.

95. Treated a multi-part boss as one nearest-target loop

The first Level-4 boss controller passed all five weak points, then tried to repair missed targets by descending through the main pendulum. Even after the target order was corrected, the generic level route silently replaced the fixed-head firing-row goal, the moving fifth head was chased at its instantaneous Y, and an off-screen main head temporarily produced no goal at all. Finally, a geometrically safe right refuge was assumed to be an equally useful attack station, ignoring that the installed Cannon is mounted at player X+26. These were four manifestations of the same root cause: treating encounter geometry, target visibility, and weapon reach as independent scores instead of one ordered physical mission.

The encounter now has monotonic phases and world-space invariants. It clears the two fixed Side Shot rows on the ascent, holds a fixed crossing lane for the upper chained head, retains the main head as a target while off-screen, moves horizontally into the left exterior refuge before descending, and attacks from the only refuge whose Cannon lane intersects the swing. Generic route and short-horizon preferences cannot move the ship inward when a collision-free exterior option exists. Runs 22 through 27 validate all phases without head or chain contact and destroy the boss without losing a life.

A later experiment exposed an important qualification to "exterior refuge." Run 28 followed the main head's Y at X=20 and lost 16 shield at frame 67166. $50782 itself remained separated, but its distinct $507F6 damaging face reached X=30 while the ship's live interaction rectangle ended at X=31. Therefore X separation alone is not a safety proof for a multi-object boss; the validated main-head station is safe because it combines the exterior X with fixed vertical separation below the swing anchor. Strategies and diagnostics must evaluate every damaging child object, not just the selected target's rectangle.

96. Treated a safe refuge and a visible firing lane as a complete boss model

The first post-shop Level-4 head strategy either remained outside without damaging the centre or left too late and met the returning tongue. It also aimed the Cannon as if FIRE created a projectile immediately. Live health stayed at 100 despite apparently aligned shots. Root cause: the model mixed three different times--current ship position, attachment animation time, and future projectile spawn--and used an absolute chain position instead of the geometry that identifies a completed retraction.

The corrected encounter measures the complete 16-link chain span: 16 pixels is fully hidden and any larger span is exposed. It budgets only the first 11 frames of the measured 22--25-frame collapsed interval for the outward leg, then commits back to world X 24..36. Disassembly of $4902 established that Cannon allocation occurs two canonical updates after FIRE and uses the attachment's current X, so the trigger window is X=102..108 for the X=124 firing station. The two active eyes are handled first with right Side Shot because $D84 gates $4FE74; the centre uses Cannon because spent eyes block horizontal fire. Runs 82 and 83 complete all phases with no shield loss. Future boss tactics must model input-to-projectile latency and phase gates explicitly rather than infer success from a rendered alignment.

97. Treated a captured collision rectangle and a homing missile as timeless geometry

The Level-5 controller translated the protocol's global player AABB to every candidate endpoint and projected $4FA1E from its last observed velocity. Both operations were temporally wrong. The global AABB had already participated in the current $5D86 collision pass before ship movement, while each homing missile retargets toward the future ship every eight updates. A candidate could therefore appear to evade a collision it could not affect, and a route could appear safe only because the missile was incorrectly kept on its old line.

The corrected model keeps the prior global hull and live header offsets as two separate phases, applies the one-frame joystick latch, and carries a complete world-space missile state through every beam node. Announced cannon launches are also materialized during retained-plan validation. The first real replay removed all curved-missile hits from the previously fatal interval.

A related tactical mistake was to equate visible with immediately attackable. However, the subsequent conclusion that these particular launchers were isolated across an impassable wall was also wrong. Atari RAM already showed that the laser tiles were cleared, and the retained reserve-zero route crossed the resulting 32-pixel opening. The controller nevertheless replaced that route with changing launcher firing-station paths below the gate.

98. Mistook safety reserve and tactical arbitration for level topology

The Level-5 route was correct, but two downstream policies contradicted it. First, launcher prepositioning outranked the short crossing and alternated between animated/moving cannon targets. Second, the homing-missile beam required ordinary wall manoeuvre reserve before considering route progress. No ship state inside a 32-pixel opening can satisfy that reserve, so every valid crossing history was pruned in favor of orbiting below the gate while more missiles spawned. At the lip, the one-frame animation-mask probe also marked UP hard-blocked even when the full configuration replay planned and the game accepted the same edge.

The correction identifies only verified-open destructible gates on the retained world-space route. A bounded destructible_gate_egress phase aligns with the crossing and owns progress until the whole hull clears it. Physical wall/missile collisions remain hard constraints, but surplus wall clearance is not requested inside the aperture, and the consistent full-route replay wins the one-pixel immediate-probe disagreement. Run 102 crosses the opening and reaches/destroys a cannon; its later death from an already dense missile population is not evidence that the topology is still disconnected.

99. Modeled only one Level-5 destructible family and then contradicted the corrected map

The persistent map knew about five $50DAE horizontal lasers but not the status $00F4 barriers driven by $5131E/$514AA. After one of those barriers cleared its 2x2 resident tile block, the live renderer correctly omitted all four tiles while the navigation map kept them permanently solid. This was not a clearance or scoring problem. The offline asset discovery had encoded only one of two authored mechanisms. Disassembly and the Level-5 backward spawn table now identify all twelve type-3/type-9 barrier records, their exact four cells, and their absolute object world coordinates.

Correcting the cells exposed a second contract error. A 12/8-pixel comfort route could legitimately terminate at a short frontier below the 32-pixel opening, while a narrower collision-checked route continued through it. The planner took the first non-backtracking route and therefore mistook "some forward progress" for the best reachable topology. Even after selecting the crossing route, the egress tactic required the reserve to equal exactly zero and later arbitration projected each alignment/UP pulse as a constant input beyond the next bend. The ship consequently alternated DOWN/NONE below a passage that A* and the game both accepted.

The fix makes verified-open gates an explicit topology exception: evaluate lower reserves until a route actually crosses the tagged opening, use that route rather than a short conservative frontier, and give the bounded egress phase one-frame movement commitments. The route is still collision-checked, the game wall replay remains authoritative, and dynamic hazards retain survival veto. Run 116 crosses the newly modeled barrier in 17 frames with no damage. The general lesson is to compare routes by the semantic boundary they reach, not merely by whether they are nonempty, and never add a numeric reserve equality after the route itself has already proved traversability.

100. Treated a progression barrier as an ordinary target and left one destruction family out of the map

At the paired Level-5 barriers near world Y 3152/3120, diagnostics selected a wall shooter but movement either followed the unrelated exploration route or stopped. The generic firing-lane query used tile centres rather than the ship's collision hull, returned tile coordinates, and remained subject to the global route-tube arbitration. Generic weapon choice could also prefer Side Shot even though solid corridor walls prevented the ship from reaching the side-firing row. This was an ownership/model error, not insufficient target score.

The spawn-table audit also found five omitted record-type-4 controllers. Disassembly of $51000/$5119C proves that each clears a 2x2 resident tile block: clr.l (A2) removes two columns and clr.l $28(A2) removes the same columns on the next 20-word row. Adding these groups merges the first three disconnected offline Level-5 route segments. The remaining full-width separation is a scripted arena/shop transition and must be modeled as such rather than opened by guessing additional destructible cells.

The correction gives both verified 2x2 families a semantic level5_barrier_clearance mission. It searches full world-coordinate 4-pixel configuration space for a forward-gun/Cannon station below the target, retains the resulting route through survival detours, and forbids side-weapon substitution. Future progression obstacles must be recovered from the complete spawn dispatch and exact tile writes before controller changes are attempted.

101. Planned through camera-inaccessible space and let survival erase a time-bounded barrier mission

The first barrier fix still failed in runs 118--124. A* correctly found a route around the sealed bend, but it considered every resident world cell reachable. Xenon permits only a sixteen-pixel backward camera window, so a station at world Y=3284 could remain geometrically connected after the maximum reachable ship anchor had contracted to Y=3195. The controller then held DOWN at screen Y=176. A retained segment could also survive within the polyline's eight-pixel tolerance after the camera limit moved past it.

The strategy hierarchy caused the opportunity to be lost even earlier. An imminent swarm replaced the complete barrier mission with swarm_escape; pressure relief and pickup collection then continued advancing the camera. When control returned, the only below-wall route was already physically unreachable. This was not a target score problem: the objective had a deadline in camera state, but the model represented only static connectivity.

Every barrier route now bounds both its endpoint and all intermediate waypoints by scrollBackwardLimit + 176. Open-gate egress owns the critical crossing first; then a still-reachable progression barrier owns strategy until destroyed. Dynamic swarm/projectile prediction still vetoes unsafe inputs, but it no longer deletes the route deadline. Validation must start from a checkpoint at which that deadline has not already expired; run 125 consequently removes seven barriers and continues through their opened passages, whereas replaying the later run-116 checkpoint is correctly recognized as too late.

102. Evaluated one-frame route pulses as indefinitely held joystick input

Run 119 selected the correct forward-gun route but stayed at one position. The route follower requested a single RIGHT/diagonal actuator pulse and would replan on the next canonical frame. Survival instead projected that input as constant; a periodic barrier projectile intersected the fictitious held-RIGHT path three frames later, so infinite neutral survival won forever. The same mismatch appeared at smoothed diagonals because Xenon's horizontal and vertical ship speeds differ.

World-coordinate configuration paths now have a one-frame commitment horizon. Dynamic and static contacts after that pulse do not invalidate the pulse; the existing space-time planner and next-frame revalidation own the continuation. Contacts during the committed transition still have absolute veto. Regression coverage explicitly checks that a frame-three constant-RIGHT collision cannot cancel a safe frame-one barrier-route pulse.

103. Predicted Level-5 barrier bullets only after they had been allocated

Run 125 took three projectile contacts while the route and barrier targets were otherwise correct. The generic hazard model could see $4180 objects only after allocation. At frame 90163, however, the live $5131E barrier already had +$5E = $FE; its next update necessarily carried and linked a speed-8 aimed projectile. Later $510A2 tile-pair controllers carried the same timer and emitted simultaneous speed-10 radial volleys. Waiting for a projectile identity left too little room for any of the nine first inputs to escape.

The correction derives allocation time from the captured byte accumulator and the disassembled $12 increment. It exposes $5131E +$2A/+$5E and $510A2 +$5E as semantic object fields and inserts the future shots into survival before their object slots exist. The eight radial members remain separate sweeps; joining them into a bounding rectangle would invent collisions between rays. Synthetic tests cover both the one-frame aimed carry and the eight-way carry. Run 126 destroyed eleven barriers and took no hit from either barrier projectile family; its remaining damage is from speed-6 scripted/swarm shots and direct swarm contact and must not be misreported as a failure of this model.

The performance audit also found that pointwise escape-distance queries were materializing complete level-wide configuration grids for anchors which were already free. An exact shifted-mask fast path avoids that work without replacing the conservative route grid. Do not optimize survival by substituting a different collision model merely because it benchmarks faster; the rejected version changed the established live-pixel refinement contract and immediately failed its regression test.

104. Let an already-open gate outrank a predicted leader/follower crossing

Run 126 modeled the Level-5 $E1E swarm and its periodic speed-6 $4180 shots correctly, yet still took 28 shield damage. The controller kept destructible_gate_egress as the displayed tactic and supplied the open-gate waypoint as the beam destination. At frame 90176 the only surviving beam path ended at step 45 of the 48-frame horizon; later partial paths became shorter and one committed a 25-frame neutral prefix. The ship was consequently pulled into the aimed shot line and the following member even though both future tracks were known. This was not missing emulator data or inaccurate $9A40 prediction; it was the wrong high-level owner.

An opened passage is persistent, unlike a live barrier whose firing station can fall outside the camera backtrack window. The corrected policy preserves live barrier suppression, but after all reachable barriers are gone it lets a 48-frame predicted swarm crossing temporarily own movement. The egress route is retained and resumes after the normal clear latch. Keep this distinction narrow: an initial attempt to broaden beam width/re-rank clearance changed the earlier barrier fight and reintroduced speed-8 hits, while a generic partial-plan commitment change did the same. Both were rejected. Run 133 has no post-barrier swarm or speed-6 contact in the validated interval, although earlier barrier contacts mean it is not a full no-damage acceptance run.

105. Freeze an aimed barrier at the current ship position, then discard the safer fallback

The Level-5 pre-allocation model initially treated $5131E like a stationary aimed emitter: it advanced the captured +$2A direction toward the ship position from the current frame. That is not the state transition the game executes. $5131E turns one octant toward the live ship on every update before the +$5E carry. Two ship paths which end at the same position can therefore leave different barrier directions and different straight projectile rays. The beam deduplicated those histories as if the shot were path-independent, so it did not preserve the useful bait-and-dodge history.

Run 134 exposed a separate arbitration failure after the path model was corrected. At frame 90156 the beam safely reached frame 14, while repeated DOWN-LEFT was known to survive 17 frames. Rejecting the shorter beam was correct. The controller then returned to route-local survival, where only a one-frame route pulse counted, and selected RIGHT even though its predicted projectile contact was at +3. The speed-8 shot hit at frame 90159. A component had made a correct local decision, but the owner handoff discarded the evidence on which that decision depended.

The correction makes the barrier rollout path-dependent in world coordinates and retains its evolved direction in the beam's Markov state. If a beam declines an incomplete path, fallback now uses the legal constant input with the longest full dynamic/static survival and commits it for only the next replanned frame. Synthetic tests cover opposite bait paths, the separate eight-ray $510A2 volley, and the route-pulse versus full-horizon fallback. Runs 135 through 137 retain all 35 shield points across the former failure interval; run 137 uses the final code and includes both AVI streams.

High-level recommendation: whenever a planner rejects its own result in favour of another model, make the fallback choice in that same model's ordering. Do not hand control back to a weaker tactical comparator and assume that the rejected planner's safety evidence will remain implicit. Any emitter that reads the player repeatedly before allocation is path-dependent state, not a future rectangle fixed at the current player anchor.

106. Confused a hostile destructible controller with the barrier that owned the route

In level5-corridor-ownership-diagnostic-0831-14.x2events, the retained route already continued from the lower pocket to world Y 2704 through the left/centre corridor. A $510A2 controller at world (288,2832) sat on the remote right wall. The controller nevertheless entered level5_barrier_clearance, selected that object, and kept the forward cannon as its weapon while navigation followed a different polyline. The resulting left/right motion was not an actuator or A* failure: combat and navigation had been assigned incompatible objectives.

The model used only update-procedure identity, approximate world Y, and whether the route had made sufficient forward progress. That was insufficient because Xenon uses the same destructible 2x2 controller both for corridor seals and for hostile wall emplacements. A first corridor-width check against the open gate was also too coarse: the target was 80 pixels from the gate crossing, but the route was already more than 68 pixels from its own wall footprint at that row.

Route-barrier ownership now includes local lateral topology. The retained world-space path is intersected with the controller's vertical band, including diagonal segments, and the controller owns navigation only when the horizontal gap is at most 32 pixels. The resident pre-allocation query and live-object query use the same rule. Objects outside that tube remain in shooter/projectile hazard prediction and may still be attacked from a currently valid Side Shot ray; they cannot request an unrelated forward-cannon staging route.

level5-route-role-validation-0831-15.x2events validates the reported interval. After frame 90429 the right-wall controller is never selected, the ship stays in the open-gate route, and advances from world Y 3012 to 2739. The extended run then encounters a different radial controller at (144,2752) and takes damage from its already allocated eight-way volley. That later survival encounter must not be misreported as recurrence of the remote-target ownership bug.

High-level recommendation: semantic object type answers what an object can do; it does not answer which strategic mission it owns. Derive navigation ownership from topology and weapon feasibility, while retaining every hostile instance in survival prediction. Never let a target remain selected when its attack plan and the active navigation route require different corridors.

107. Passed a naked A* polyline between systems and discarded the reserve which made it valid

In level5-diagonal-validated-connector-0831-42.x2events, target identity #942724 remained stable and the firing-station search produced a sensible route to world X 119--129 near Y 2948. The ship nevertheless moved around the route and eventually appeared to oscillate at the diagonal wall. This was initially treated as another target-selection or path-following problem. The actual contradiction was lower in the model: the attack planner tried reserves 8, 4, and 0, returned a naked polyline, and discarded which reserve succeeded. Static candidate prediction then evaluated that polyline with the generic navigation reserve (normally 12/8), while emergency survival used its own zero-reserve mask. Each component was locally reasonable, but they were solving different configuration spaces.

The Python UI made this harder to diagnose because its blue route was the global recovery path, not necessarily the firing path controlling the ship, and its yellow footprint always displayed navigation_reserve. Thus the visible explanation did not match the action being executed. More target scoring or another encounter flag could not repair this inconsistency.

The first implementation of the contract still left one legacy owner active. Run 44 showed the orange barrier_attack plan ending at X=76, the correct Cannon anchor for target bounds X=100--124, but later generic strategic arbitration changed movement_goal to the cyan/global navigation_route. The survival beam then reported mission_goal_changed and repeatedly moved left. This was not a bad A* station or insufficient prediction horizon; the migration had published one route object without actually removing the subsequent second-owner pass.

Level 5 now uses a Level5RoutePlan contract containing purpose, target/group, weapon, world polyline, monotonic cursor, exact $387C hull, selected reserve, and map revision. The same reserve drives the follower, static prediction, and survival lookahead. A map change revalidates the retained suffix and live rejoin edge in the same pixel-mask model; an unchanged map does not pay that cost every frame. The UI draws the global route in cyan and the actual owning plan in orange, including its clearance corridor, exact hull/reserve, waypoint, invalidation event, and movement authority.

Run 45 repeats the same pre-diagonal checkpoint after removing that second owner. Every barrier-plan frame retains level5_route:barrier_attack; three wall shooters are destroyed in 180 frames with no shield damage or life loss. This is the required acceptance evidence, whereas run 44's no-damage-but-no-kill result was correctly treated as failure.

High-level recommendation: a path is not just a list of points. Its collision hull, clearance reserve, coordinate space, map revision, objective, and progress cursor are part of its type and must travel with it. Diagnostic overlays must visualize the contract that actually controls movement, not a nearby path from another layer.

108. HIGH PRIORITY: let the current scene and persistent navigation map disagree about an open gate

The checkpoint used by level5-unified-route-0831-45.x2events begins after level5-tile-pair-r179-c02 has already been destroyed. The upper scene correctly contains a hole because it renders the current canonical tile draws. Replay's lower map nevertheless showed the old barrier because PersistentWorldMap seeded the resident Level-5 map and required that reconstruction first witness a live solid tile before later absence could clear it. A recording which starts after destruction can never satisfy that condition. Offline re-analysis consequently supplied A* with geometry contradicted by the same frame's renderer stream.

This repeats the central architectural mistake behind several earlier failures: two representations of the same fact were allowed to evolve independently, and the less current representation owned control. The upper scene is an instantaneous draw view and the lower map is necessarily accumulated world state, but this difference does not permit contradictory occupancy for a fully observed destructible cell. Treating the lower pane as merely a display bug is especially dangerous because it is the PersistentWorldMap four-pixel configuration grid—not the upper scene—that feeds navigation and replay re-analysis.

Live autoplay already has an additional authoritative startup path: on the first frame of each level it reads Atari RAM and synchronizes every known destructible tile-map word. Run 45's live trace therefore reported r179-c02 as its open egress on the first frame. Native .x2events replay has no corresponding initial RAM image, which exposed the split. The correction retains RAM synchronization and also lets two consecutive fully visible absences clear an offline-tagged destructible cell, even if the recording never observed its closed state. The two-frame/full-row guard continues to reject the one-frame clipped-edge gaps that originally required static wall monotonicity. Reconstructing run 45 now marks r179-c02 and r179-c04 free, matching its rendered scene, and invalidates the configuration-grid caches.

The lower map is now clickable. Its yellow crosshair reports a copyable level/tile, world-cell origin, exact world point, four-pixel navigation point, solid/free state, and destructible-group ID. This makes any future scene/map contradiction an explicit coordinate-level bug report rather than a visual guess.

level5-unified-map-validation-0831-46.x2events is the live acceptance run from the same mid-level checkpoint. Live RAM synchronization recognizes the old opening on its first frame and immediately selects destructible_gate_egress. Reconstructing the native recording without RAM marks both r179-c02 and r179-c04 open on record 2 and keeps them open thereafter, matching the scene stream. The run retains all 35 shield and destroys three shooters. Two X=192 shooters remain because target selection rejects them as outside a clear near-term weapon lane; that is a separate mission/weapon-feasibility limitation and must not be claimed as a recurrence of the stale-map error—or hidden by declaring the complete encounter solved.

High-level recommendation: there may be multiple views of world state, but there must be one occupancy truth at the planner boundary. At controller startup, restore dynamic terrain from authoritative RAM when it is available. In recordings or other contexts without RAM, reconcile accumulated terrain against repeated complete renderer observations before it can own a route. Add regression coverage for checkpoints that begin after each kind of persistent state transition; tests that start before destruction cannot expose this class of stale-world bug.

109. Let a later route waypoint position the ship before an imminent authored encounter

Run 46's cyan A8 continuation was geometrically valid, but generic spawn pacing used that route while the row-164 aimed barriers were still dormant. The ship descended at X=54 toward the later upper-left continuation even though the pending resident record already identified two controllers at trigger 2656 and the selected left controller's installed-Cannon lane was X=72..80. Once the objects allocated, their projectile field made that small realignment expensive. Both left controllers eventually died, but the 51 pixels of automatic camera progress during the fight put the central return dogleg beyond $CEA.

The root cause was mission sequencing, not A geometry or an inaccurate camera constant. A pending scroll-spawn record is useful encounter state before any live object or overlay tile exists. The controller ignored it for firing-position planning and allowed a valid later* navigation goal to own the pre-allocation interval. The live protocol reported $CEE=$0010 on every relevant frame, and $7B5A proves this is a rolling leash: ordinary forward progress moves $CEA forward too. Delaying the decision until visibility therefore destroys route feasibility even if every later component behaves correctly.

The corrected Level-5 pacing policy matches the unconsumed RAM trigger to resident directional-barrier records, selects one stable barrier column, derives the firing X interval from installed weapon offsets, and configuration-space-routes there while descending to the bottom pacing band. The global A8 route remains diagnostic context until the pending row allocates and clears. Synthetic tests cover exact-trigger classification and the resulting pre-allocation firing station.

High-level recommendation: route validity is not route urgency. Before following a later waypoint, inspect authoritative pending-event data for encounters that will allocate first. Use quiet pre-allocation time to establish the required combat pose; do not spend a finite camera/reaction resource and then ask survival to reconstruct that pose under fire.

110. Treated a reachable firing station as authority to abandon the selected suppression column

The first live test of the pre-allocation lane still became stuck, for two distinct reasons. Run 47 let an off-route $510A2 radial tile-pair at world X=288 acquire a forward-cannon route merely because A* found a station. That route replaced the already valid central/left egress and held DOWN at the camera limit. Run 48 rejected that radial detour, but after destroying the lower left $5131E controller it made the same conceptual mistake with the lower right peer: the resident mission remained latched to collision-centre X=112, yet generic target selection acquired the X=208 peer's forward station. Survival then moved away from that contradictory route, the next controller row allocated, and overlapping projectile paths drove the ship into the left wall pocket at X=14.

The root error was equating three different facts: a hostile object must remain in survival prediction; a weapon can geometrically reach it from some configuration; and the object is allowed to own movement now. Only the first two were proved. A forward Level-5 barrier mission now additionally requires either retained-route topological necessity or admission by the explicit pre-egress suppression mission. That mission enforces its selected resident column. Same-row peers remain dangerous and are still eligible for an immediately valid Side Shot, but an unrelated forward station cannot replace the route contract.

Run level5-prespawn-firing-lane-validation-0831-49.x2events repeats the exact run-40 checkpoint for 300 canonical frames. The ship never enters the X=14 pocket, destroys three wall sources (including both selected left-column controllers), advances from world Y=2921 to Y=2546 through the opening, and keeps shield 35 with no hit or life loss. Both synchronized AVI streams and the JSONL decision trace accompany it.

High-level recommendation: path existence is feasibility, not policy. Every movement-owning attack path needs an explicit mission-admission predicate derived from topology and retained encounter state. Target ranking must not be able to manufacture mission authority from A* success alone.

111. Inferred a map-state reversal without evidence and missed the proven route-erasure event

While diagnosing the remaining row-162 right shooter, I claimed that opened left cells had later become solid. The Python UI showed those cells remained open, and the recording contained no authoritative evidence of a reversal. That conclusion came from an offline reconstruction which did not reproduce the live controller's map state and should not have been presented as fact.

The trace did contain direct evidence of the real failure: at frame 91520 the retained r162-c12 path was [(98,2671), (96,2672), (172,2688)]; at frame 91521 the group remained selected but a transient failed A* refresh replaced the path with [], releasing advance while the shooter was still live. Empty replans now mean “no replacement,” the exact central crossing ends the obsolete pre-egress weapon restriction, and a live post-entry source remains a Side Shot objective until it disappears.

High-level recommendation: distinguish observed facts from hypotheses and state which tool produced each one. Never mutate a shared model from an unverified offline reconstruction. For retained missions, lack of a fresh path is not proof of completion; require an explicit world-state completion event.

112. Modeled a global fire trigger as one exclusive weapon and confused renderer visibility with projectile reach

Run 56 repeatedly labeled the right-side barrier as a forward-Cannon target. A* proved a short station to the right, but the live projectile field made survival reject that traverse. The controller retained the same geometric answer, then briefly dropped the target when it left the renderer band. It neither represented the simultaneous Laser/Cannon/Side Shot streams nor tried a different firing region, so “reachable” became a left/right oscillation rather than an executable attack.

Disassembly established separate collision limits: ordinary $6086 projectiles must remain in unsigned 312x192 before $3950; $4E50 Cannon has 13 pixels of top-edge sprite reach; $4848 Laser clamps a beam which crosses the top edge but cannot hit an entirely off-screen rectangle. The controller now derives live Laser and Cannon mount offsets, enumerates every installed forward and horizontal firing region, and records all streams contributing at one station. If survival blocks progress toward a station for twelve attack observations, it quarantines that approach—not the hostile shooter—and replans through an alternate weapon region. One-frame target/navigation alternation no longer erases the evidence.

level5-multilane-alternate-validation-0901-60.x2events validates the change from the exact run-40 checkpoint. It destroys two wall shooters, takes no shield hit, loses no life, and leaves the previously repeated Cannon traverse instead of remaining pinned against the left wall. Both AVI streams and the JSONL trace are stored beside the recording.

High-level recommendation: distinguish visibility, collision reach, geometric station reachability, and dynamic executability. Represent FIRE as a set of simultaneous weapon lanes. When a retained route fails under survival, preserve the target as a threat but invalidate the dominated approach class so replanning can change the method rather than merely recompute the same path.

113. Applied generic barrier navigation inside an unrecognized composite boss

At the first Level-5 tank arena, I interpreted two $5131E side emplacements as another optional route-aligned barrier pocket. That model encouraged reaching a Side Shot row and continuing the level route. In reality the tank had already allocated a controller plus four mounted cannons, armor pieces, and a central core. Generic target feasibility could not express the required order or the safe camera pose, so it advanced the ship while the side sources filled the arena with projectiles.

The initial reverse-engineering check also queried a stale earlier-level memory image at the same addresses. Level loading overwrites this code. Repeating the analysis in the Level-5 snapshot exposed the $50538 descriptor table and exact update/hit callbacks: $508E0 controller, $507DA/$50870 mounted cannons, $5078C non-damageable armor, and $506DE/$50722 core. The controller now uses those semantic identities and a monotonic side-emplacement -> cannon -> core mission. It reveals only one collision-actionable row and then holds DOWN in the lower action band rather than following the global route into the boss.

The first semantic implementation still chose the nearer side emplacement. Validation run 65 destroyed the left source, but the accumulated projectile field then made the full-width transfer to the right source non-executable; the ship lost 35 shield and a life. The level script already supplied an exact pre-allocation record (path_index=110) while the arena was empty. The corrected contract orders right before left, so the later transfer moves toward the safer cleared side instead of crossing into a live remote source. A subsequent attempt to force a configuration-space route to the right before allocation was also wrong: although the route was wall-valid, it climbed into the upper attack band and lost a life sooner. The retained rule is lower-band camera pacing; rightward pre-staging is only a preference when immediately reachable without climbing.

Run 68 exposed a second, more fundamental omission. A status-$0110 object with updateProc $50B38 appeared above the viewport as unknown, grew into a tall column, and caused six shield damage. Since unknown was outside WorldState.hazards, every survival trajectory treated the collision as absent. Level-5 disassembly showed this is the tank controller's central projectile: +$28 grows 16 -> 32 -> 48 while camera compensation keeps world Y stationary; after that signed +$2A (normally 16) advances screen Y and $5D86/$65A4 applies six damage. It now has a semantic hazard-only class and an exact world-space grow/fall predictor, with candidate camera correction during the falling phase.

Run 69 then showed why merely preferring the right source did not make it reachable. The path-110 preparation signal was accepted only within 96 scroll pixels of its trigger. By then the arena's horizontal wall had entered the lower ship band, separating player X=104 from the required X=272 lane. The controller retained the correct target for hundreds of frames, but no survival action could cross the wall; five directional-projectile and two homing-missile hits eventually consumed the life. Recorded geometry places the last clear, low crossing at scroll 2540, 140 pixels before the 2400 trigger. Preparation now begins at delta 144 so it crosses while the arena is empty, rather than trying to solve a topology change after it occurs.

Run 70 crossed during that interval and retained the right source without losing a life, but exposed another systematic weapon-model error. The boss code built its aim from tank_weapon_specs[0], always the main forward gun. It therefore kept demanding ship X=272 even though the wall limited the ship near X=244. The installed Cannon already fires 26 pixels to the right. Its complete valid ship interval is X=234..258 for the target's X=260..284 rectangle; X=234 is the nearest safe station when approaching from the left. Continuing toward 272 triggered wall_escape, displaced the ship, delayed destruction, and allowed four hits. Tank targeting and pre-staging now evaluate all simultaneous forward-going Forward/Laser/Cannon offsets and choose the nearest point in a valid interval, rather than another weapon's center line.

Run 73 proved that this fixes the first source and that the ordered encounter correctly advances to the mounted-cannon phase after both side sources vanish. It also exposed a remaining execution error: crossing the full arena after the right source died took long enough for the left source to inflict seven more projectile hits, consuming the life just as the cannon phase began.

The first attempted fix incorrectly assumed that an installed left Side Shot could hit the remaining source by holding X and waiting for camera scroll. Run 74 disproved that model: at handoff the source was at world Y=2416 while the player was near world Y=2545. Automatic scroll moved both the source on screen and the player's world position, so their roughly 120-pixel world separation did not close. The controller labelled side-left for more than 200 frames and the source died only after survival had accidentally driven the ship to the same row and nearly the same X; the result was again 35 damage and a lost life.

Side fire is now selected only when the current world-space firing row actually intersects the target. Otherwise the remaining source keeps a forward-going weapon station and a monotonic lower-band transfer: while a LEFT/DOWN or LEFT prefix has more than eight collision-free frames, a finite-horizon RIGHT escape cannot erase progress toward the only action that stops new projectiles. If no non-right prefix is locally safe, unrestricted survival retains authority. Tests cover both the already-row-aligned Side Shot and the unaligned forward transfer.

Run 75 validated that correction: both side sources were gone by frame 91689 with shield still 35, about 180 frames earlier than run 74. The cannon phase then revealed two further perception/weapon-model errors. $507DA is included in the general wall-shooter set, but unlike fixed wall objects its child anchor is kept in screen coordinates; diagnostics reported cannon world Y values around 11 instead of roughly 2370. Its interaction rectangle happened to be translated separately, masking the inconsistency in some aim code while leaving velocity and future reasoning wrong. $507DA is now an explicit screen-anchor exception.

The first attempted cannon optimization made another unsupported inference: it mistook four $70CC objects one pixel from the ship for Laser streams and assumed Forward plus Laser could overlap one inner cannon. Run 76 was bit-for-bit unchanged because the real Laser attachment is $47A8 at ship X-26; the four near-centre objects are not Laser lanes. Level-5 disassembly shows $70CC copies the player anchor and applies offsets from the $70B0 auxiliary-formation table. It is now named PlayerAuxiliaryFormation_Update_70CC and documented in ReVa.

The actual simultaneous opportunity is across targets, not on one target. With Laser at X-26 and Cannon at X+26, ship X around 144 lets Laser hit the left outer mount while Cannon hits the right inner mount; a station near 160 covers the other pair. A 40-health mount survived for roughly 240 frames when arbitration minimized distance to it alone. Cannon-phase planning now optimizes one FIRE station over the complete live mount set, maximizing the number of distinct mounts and firing directions before travel distance. This is a set-level weapon geometry correction, not another target score adjustment.

Runs 77 and 78 exposed two forms of objective jitter in that set-level plan. The first version filtered mount intervals by their transient vertical viewport membership, so the same four horizontal mounts produced X=114, X=139.5, and X=160 stations on adjacent animation frames. Removing that filter was necessary but insufficient: several stations still hit two mounts, and using the ship's current X as the last tie-breaker let a survival dodge choose a new objective. The corrected controller latches the station plus its original target-key set until every surviving member of that set is gone. A synthetic four-mount test now displaces the ship across the arena and verifies that the objective remains unchanged.

Run 79 then kept X=114 correctly but revealed a misleading split between the UI and the actual survival search. movement_goal displayed the firing station and lower hold band, but the space-time beam never received that goal; it optimized collision survival with no encounter destination, wandered across X=14..147, advanced too close to the tank, and destroyed only one cannon before losing the life. The tank cannon/core phases now feed that same world-space goal into the beam. This is not a weaker survival priority: collision-free paths remain first, but equally safe endpoints recover the attack geometry.

Run 81 validated the connection without changing the proven side-source handoff. Both side emplacements vanished by frame 91689 with shield 35, and two mounted cannons were gone by frame 91869 while shield was still 35. The remaining pair then required a large transfer through an already saturated field and the ship still died. Run 82 tested planning the complete two-station cover in advance by starting near X=150.5 so the second station would be only about nine pixels away. That longer initial crossing caused early damage and was therefore rejected and reverted. A globally shorter station tour is not useful if its first edge is not dynamically executable at encounter entry.

High-level recommendation: when several unknown objects allocate together at an arena boundary, stop applying generic navigation/target policy. Inspect the descriptor graph in the memory snapshot for the active level, identify which children are actually damageable, and encode one ordered encounter contract with an explicit safe region and completion predicate. Treat every unknown object which coincides with unexplained damage as a perception/model defect to reverse engineer before changing navigation or target scoring.

For multi-phase bosses, additionally verify that the strategic goal used by the diagnostic UI is the same goal consumed by survival planning. Latch a selected firing objective across temporary dodges, but validate every proposed phase-to- phase transfer live; optimizing a static sequence of weapon stations without the time-dependent projectile field can make the first transition worse.

114. Let three valid movement policies alternate at the tank entrance

Run 97 displayed a correct open-gate route at frame 91441 but alternated UP and DOWN, then let pending tank preparation move to the farther corridor. The first diagnosis changed target order, but the trace showed a deeper ownership problem. The unified Level-5 route branch executed before an older egress-specific branch, so the proposed continuous-UP code was unreachable. After moving the rule into the actual route owner, the global screen-Y reaction-room policy still replaced UP with DOWN whenever the ship reached Y=116; DOWN returned it to Y=121, where the route selected UP again. Both policies were locally valid and their composition was wrong.

The entrance is also two sequential open barrier rows. Crossing r164-c06 caused the active group to become r162-c06; initially recognizing only the first row re-enabled the same veto halfway through. These names are stable resident-map coordinates, not runtime object IDs. The bounded tank-entry egress now covers both rows on either side, holds the proven route's asymmetric ship-anchor lane rather than the tile-center coordinate, and temporarily exempts that crossing from generic reaction-room recovery. Dynamic/static collision prediction remains authoritative.

Run 104 crossed quickly but then recomputed “nearest emplacement” from the ship's survival-displaced X every frame, flipping a left entry into right-first staging. Run 105 latched the entry side but exposed a second composition error: when the requested DOWN+LEFT diagonal was blocked, the fallback discarded LEFT as well and minimized ordinary score over every non-forward input. The controller now retains a safe horizontal component, holds the entry-side objective until that emplacement disappears, and only then transfers to the survivor. Run 106 holds UP through frames 91441--91455, removes the first source by 91565 and the second by 91625, with shield unchanged at 35.

High-level recommendation: a critical traversal must be implemented in the branch that actually owns the route, and every later global policy must state whether it may override that traversal. Represent multi-row connectors as one semantic encounter boundary. After choosing a side from stable world topology, latch it across survival displacement; if a diagonal is unavailable, preserve each independently safe goal-directed axis before falling back to unrelated inputs.

115. Treat a time-bounded pickup as a score and let camera arbitration cancel it

Run 107 correctly recognized the tank's Homing Missile pickup, but collection was only a target priority and approximate movement goal. The survival beam had no terminal meaning for “collected before $4EA0 unlinks it at screen Y 200,” and a later camera-hold rule replaced its output with DOWN. The ship moved away during the last reachable frames. Pickup motion is now rolled out exactly from its timer and direction; collision-rectangle overlap is a beam terminal, and that verified prefix cannot be replaced by the generic camera command.

The same run damaged two of four mounted cannons but then drifted from the latched station to X=301 and died. The first attempted correction was also wrong: it put projectile clearance, horizontal reserve, station distance, and camera band into one lexicographic beam rank, then reduced cannon plans to one action so they would replan frequently. Runs 109/110 showed the result clearly. Receding-horizon replanning alternated endpoints near X=194 and X=301, the ship barely reduced one cannon from 31 to 24 health, and died while four sources continued firing. A stable route goal is not a commitment when it remains only a late tie-break.

The replacement is an explicit mounted-weapon state machine. attack owns one latched firing station; an imminent predicted contact enters evade and commits a bounded prefix through closest approach; return then reacquires that exact station before attack can resume. The beam is now only an evasive geometry solver. The failed one-action special case and 32-pixel tank endpoint rank were removed instead of being left as competing mechanisms.

Run 109 also proved that collecting the Homing Missile replaced Side Shot. That removed both lateral streams which could intercept approaching tank missiles, so the supposedly high-priority pickup reduced survival. Pickup arbitration now compares the incoming attachment with installed equipment and rejects Homing Missile while Side Shot is installed. Exact pickup rollout remains useful for pickups which do not displace required equipment.

I also inferred damage only from object disappearance even though the canonical capture already contained the cannon/core health word at +$32. This hid useful closed-loop evidence: run 107 had reduced two counters from 40 to 28 and 25/7. Health is now a named semantic field in traces and the UI. It finishes the weakest visible member of an otherwise equal multi-stream volley, without promoting an off-screen damaged member into a false cannon_reveal objective.

High-level recommendation: separate a persistent encounter mission from a bounded collision solver. Safety may temporarily preempt the mission, but it must return control through an explicit state transition rather than optimize mission return as a weak endpoint preference. Equipment pickups require replacement-cost arbitration, not a monotonic “attachment is valuable” rule. Expose available game-state feedback such as health early; do not wait for disappearance when the controller needs proof that an attack is making progress.

116. Protect the hidden tank while it attacks, then let global reaction policy reverse the fix

Run 112 cleared both side emplacements but retained their lower-screen camera hold while the mounted tank cannons were outside the projectile collision viewport. The tank could still create missiles, so this produced a one-sided encounter. The first correction released the camera hold and requested UP until the cannon became actionable, but two unrelated global mechanisms silently reversed it. The generic reaction-room rule selected DOWN at screen Y 112, and Level-5 corridor arbitration evaluated neutral as if it would be repeated forever through the persistent map. The result was an UP/DOWN reveal oscillation, not aggressive engagement.

The tank arena now owns its own vertical contract: climb to Y 112, wait there only until a weak point is collision-reachable, then attack from the lower band. Generic screen-Y recovery does not participate, and corridor-style indefinite input rollout is not used to rank arena station commands. Immediate static blocks still veto a move and the space-time projectile solver still preempts an imminent collision.

Run 112 also spent 247 of 350 active frames in evade and 103 in return, with zero attack frames. The 32-frame general hazard horizon will always see another future projectile when the boss continuously replenishes them; demanding an empty horizon makes offense impossible and ultimately increases danger. Tank combat now uses a 12-frame entry gate for its bounded six-frame evade, leaving time for sustained damage while retaining two committed prefixes before contact.

Finally, ordinary $6086 player bullets restored far from the player were misclassified as hostile because the shared $3950 renderer relied on a birth-near-player heuristic. Their updater is now the primary semantic identity; the heuristic is reserved for genuinely ambiguous shared-renderer objects.

High-level recommendation: define encounter ownership at every policy boundary, not only at target selection. A boss state machine must explicitly exclude global camera and corridor policies which describe a different environment. For continuously generated hazards, survival needs a near-contact commitment window rather than a requirement that the entire long horizon become empty. Prefer stable semantic code identity over spatial birth heuristics whenever the game exposes it.

Run 117 then exposed two more phase-boundary errors. A cannon was declared actionable with only six pixels of its rectangle inside the collision viewport; the ensuing DOWN command immediately hid it again. At the same time, level5_tank_minimal_reveal still published the old lower-screen firing band as its movement goal, so survival had no representation of the requested approach. The corrected entry requires 24 pixels of viewport depth and publishes the screen-Y 112 reveal band as the actual world-space goal.

The X=197 volley station had also been selected while the tank was off-screen. By the time reveal completed, survival had displaced the ship to X=113, where real bullets were already damaging the left mounts, but the controller continued returning toward the obsolete right station. The station is now provisional during reveal and is latched only on the reveal-to-combat boundary. Run 120 validated the result: cannon health 160 -> 130, shield 35 -> 23, no life lost.

I then kept extending a partially successful change without a new model. A continuous vertical-bob hysteresis reduced damage, and an alleged “velocity-aware” correction reused _follow_movement_goal, which is actually a position-sign helper. Replacing it with a one-step endpoint rank made reveal faster but offense worse: run 123 inflicted no cannon damage and lost the life. Both experiments were removed. The retained implementation is the best validated run-120 configuration, not the newest attempted code.

High-level recommendation: define separately when a firing pose may be planned, when it becomes valid, and when it becomes durable. Never latch a station from off-screen geometry across a long survival displacement. A helper's name is not evidence of its model—inspect its implementation and validate the complete closed-loop result. Revert failed experiments promptly instead of layering a new policy over them.

117. Model a destroyable projectile only in scoring, then let another controller abandon the attack lane

The first Side Shot implementation correctly identified $4FA1E curved tank missiles as damageable, but only the constant-candidate predictor knew that a side bullet could remove one. The multi-frame escape beam still treated every missile as immortal. A second error then hid the partial correction: when the direct centerward tank command had a collision within eight frames, tactical arbitration discarded every mission-aligned command and passed an unrelated edgeward fallback into survival planning. Finally, a generic vertical-projectile lane hint could replace the retained X=197 firing station with X=125 and then X=239. Runs 131--135 consequently displayed the correct station while control repeatedly moved to an edge and cannon damage stalled.

The beam now carries exact curved-missile health and Side Shot bullet states. Only missiles with the real damage callback can be removed; one bullet cannot be credited twice, and straight/central tank shots remain obstacles. Tank planning is triggered from the threatened mission-aligned command, while generic lateral escape hints cannot redefine the tank goal. Intermediate beam pruning preserves detours, but final equal-horizon selection returns toward the firing station before optimizing turn count. Run 136 reduced total cannon health by 85, recorded six planned side interceptions, and survived the validation interval.

High-level recommendation: a physical capability must live in the shared rollout used by final control, not just in a diagnostic or one-step scorer. Preserve the semantic command that became unsafe so the joint planner knows what mission it must resume. Temporary hazard hints may constrain a path, but must never replace a boss-phase firing objective already represented in that same path search.

118. Declare an escape committed while cleanup silently deletes it

Run 200 found a concrete sequence error: a safe DOWN-LEFT prefix selected at 92580 was discarded at 92581, replaced by LEFT, and followed by an unavoidable contact. Cleanup checked generic homing missiles but omitted Level-5 homing presence, so the retained plan did not survive a frame. The explicit Level-5 condition and a synthetic retention test fixed this; run 201 retained queued actions but still did not solve normal tank survival.

High-level recommendation: verify a commitment end to end through selection, cleanup, next-frame restoration and application. A planned path in the UI is not evidence the next input will use it. Keep the residual failure separate from the invariant actually repaired.

119. Insert telemetry into a positional constructor and silently disable level detection

The new projectile-damage-bonus field was inserted before shop in GameMemoryState. Existing positional callers placed their ShopState in that integer field and left shop=None. The full handoff suite exposed fifteen failures/errors across levels, while focused tank tests and keyword-based live decoding remained green. Appending the field restored the constructor contract; all 549 autoplay tests now pass, with a regression for the positional shop slot.

High-level recommendation: prefer named construction for large state records, and do not reorder an established constructor silently when adding telemetry. Run the complete inexpensive suite, not only the new encounter's tests, before claiming no cross-level regressions.

120. Preserve an attachment in pickups but discard it in the next shop

Tank collection rejected Homing Missile when it replaced Side Shot, but the unconfigured Level-5 shop still used generic priorities and planned that same replacement. Run 203 exposed the inconsistency. An explicit conservative post-tank recipe now preserves equipment, permits one affordable Power Up and critical repair, and performs no equipment sales; run 204 retained Side Shot and entered the next area without damage.

High-level recommendation: equipment replacement constraints must apply at every acquisition path, not only pickup scoring. A new unexplored shop should not silently undo a loadout whose tactical value was just established. Label this as a conservative exploration policy, not an optimal future-level recipe.

121. Turn a conservative loadout recipe into a cap on all purchases

Run204 stopped after one Power Up with5100 credits and two auxiliary mounts still empty. Preserving Side Shot did not require leaving money unused. The planner conflated finite recipe goals with the entire purchase budget; a generic Rear preference could also veto a compatible installed Side Shot upgrade. Four auxiliary slots were already represented, but the policy underused them.

High-level recommendation: separate required loadout, compatibility and remaining budget. Complete the recipe, then buy useful compatible upgrades from live RAM until none is affordable. Verify economy assumptions from disassembly: cash can survive a mid-level shop but level initialization clears it. Do not promise every credit can be spent without buying excluded or useless items.

122. Treat a one-time renderer hook as restorable gameplay state

Restoring shop checkpoint202 after leaving the shop cleared the renderer cache and its shop-active flag. The entry hook had already executed before the save, so run205 sat in the menu without a working shop controller. Earlier restores inside an already-active shop masked this host-state dependency. Shop-only grid draws now recover active state from fresh execution, while gameplay/level-loading hooks retain their existing invalidation behavior.

High-level recommendation: a restored checkpoint must not depend on the phase of the previous host session. Derive phase from current execution or persist the necessary state; do not substitute stale RAM labels or controller tactics for an authoritative phase. Test restores both from within and outside the saved phase.

123. Budget only the visible shop page and assume a menu press was consumed

The initial MORE implementation visited page2 only after first-page spending, so Protection could lose its budget before being considered. Reserving across both pages corrected that model. The first live test then bought Protection but waited indefinitely after one Fire edge on MORE: cursor arrival in RAM was not proof that the selector had consumed Fire during redraw. Page navigation now retries unacknowledged edges with releases, stops firing on page-base change, and waits for the new grid before selecting another item.

High-level recommendation: distinguish the complete merchandise catalog from its current UI page, and distinguish issuing input from acknowledgement. Use authoritative state to finish an operation; retry only before acknowledgement, with a bounded timeout. Preserve explicit budgets and physical mount capacity.

124. Mistake an uncaptured script cursor for a jump to its beginning

Level-5 trains reused the known motion interpreter, but their320-byte loops exceeded the128-byte observation window. The predictor reset an out-of-window cursor to zero, inventing a path restart; run213 had187 one-frame mismatches. Train-only512-byte capture and removal of that reset produced zero errors through 64-frame comparisons in run214. The original live objects and the script bytes were correct; the observation boundary and fallback were wrong.

High-level recommendation: verify the data extent as well as the interpreter. Missing bytes mean unknown continuation, never implicit restart. Preserve replay decoding of older envelopes, distinguish pre-update bytes from script bytes, and compare multi-frame world trajectories before relying on a newly recognized mover.

125. Conflate route obstruction with combat suppression value

The right post-shop cannon was repeatedly rejected as outside a near-term weapon lane. An earlier anti-detour rule allowed forward preposition only for route seals or pre-egress objectives, so it denied this otherwise reachable threat source. The two entry cannons now have an explicit bounded suppression objective using their verified world anchors; weapon reachability and survival still gate movement. Both were destroyed in run214 without opening the rule to arbitrary remote shooters.

High-level recommendation: a source need not obstruct movement to justify its destruction. Separate strategic permission to suppress it from the geometry of a firing station. Retain an achievable attack objective, not just a nominal target, and report why preposition was denied instead of calling every rejection unreachable.

126. Add exact motion but leave encounter ownership generic

The post-shop train predictor matched observed world positions, but generic enemy targeting had no persistent encounter mission. Between immediate firing opportunities it returned no target, and the route advanced into the circular path. This was a policy omission, not inaccurate movement or insufficient score. Keep a productive world-space firing lane for the remaining looping members; navigation resumes after the encounter, while imminent collision avoidance can still interrupt the hold. Test the actual final owner with no current intercept, not just whether the predicted path looks correct.

127. Recognize the collision box but misinterpret the aiming anchor

The later Level-5 cannon at $515DC writes a correct screen collision rectangle but retains its anchor in world pixels. Without a semantic classification, the generic normalization added scroll to that anchor again. Thus one object had internally inconsistent geometry: contact looked plausible while firing-station selection rejected it. Disassembly confirmed fixed-world coordinates and a damageable tile-restoring wall source, now named in ReVa and Python. For every new object family, validate anchor, collision, motion and classification together across camera reversals; correct rendering alone is not a perception test.

The subsequent integration test also exposed an incomplete use of the existing single-owner route contract: the generic station path was still being replaced by navigation. Reusing the exact multi-mount planner fixed that representation boundary, but run219 still cannot execute its last edge because static collision prediction disagrees with the accepted station. Record this as an unresolved failure, not a solved cannon tactic. A synthetic ownership test is necessary but does not prove live physical reachability. Do not keep adding scoring exceptions or disable the safety check to force the path.

128. Reuse a station planner without checking which ship hull it uses

The post-train cannon integration reused Level4's station planner, which passed the animated enemy-hit rectangle to A*. The Level5 movement executor used the fixed $387C wall shape. At run219's failure these were17x20 versus29x24 pixels. Consequently the advertised firing pocket below the diagonal wall was not physically executable. Ownership and endpoint-tolerance corrections could not repair that geometric contradiction. The user's gate-first observation led to the actual boundary error: the new cannon's station search now uses the same wall hull as execution and rejects the below-wall shortcut. Test the planner's shape argument, not just its returned path or target label. Reusing a mature function is safe only when its coordinate, geometry and timing contracts match.

129. Keep optimizing the destination while ignoring its prerequisite

The user repeatedly explained that the left gate must be crossed before reaching the post-train right cannon. Correcting the firing-station hull alone did not implement that ordering: run220 chose another station below the camera's maximum reachable row. A free point in the world map is not necessarily reachable under the game's finite scrolling limits. The gate's valid navigation route existed, but combat kept replacing it. The fix bounds station paths by camera reach and uses the existing egress contract to complete the left connector before target acquisition resumes. Run221 crossed it and destroyed both subsequent cannons with no shield loss. Treat a user's explicit traversal prerequisite as a mission ordering constraint; do not substitute more local endpoint repairs for it. Verify the actual crossing from the failed checkpoint, not merely a plausible blue line.

130. Three-eye ordering existed but its activation condition excluded the approach (2026-09-02)

full-game-02 spent 1,562 frames in worm-hole clearance during the three-eye mission. The ordered-eye policy waited for an upper eye to enter the screen, but the lower invulnerable eye appears 320 world pixels earlier. Both side-eye objects were already captured; missing telemetry or target scores were not the cause. Existing ordering tests began inside the upper arena and never exercised this approach or a cold restore below it. Activation now includes the lower eye, while the existing side-before-center order remains authoritative.

Recommendation: test encounter entry and checkpoint reconstruction, not only phase selection after activation. A correctly implemented strategy is useless if its entry predicate cannot become true along the actual approach. Validate target ordering and survival separately; the first live check fixed the ordering but still lost a life to worm formation contact during the cross-arena route.

131. Discard a safe worm escape before its critical interval ends (2026-09-02)

The Level-2 boss route found a complete 32-frame escape at frame 19005, but only retained eight actions. At 19013 the suffix was discarded; new searches chose four-, three-, then two-frame partial paths and the worm hit at 19018. Forecast positions matched the recorded world positions exactly. Blaming the prediction model would have missed the execution-contract failure. This encounter now keeps the whole complete suffix, with live revalidation; incomplete paths and other encounters retain their existing rules.

Recommendation: compare the accepted plan with the inputs actually executed, including truncation and invalidation reasons. Test retention as well as path quality. A passing target-order test is not a survival regression test.

132. Mistake destroyed boss terrain for permanent walls during loot collection (2026-09-02)

The eye death handler clears 460 resident tile words (rows 162..184), but the offline map did not tag them as destructible. Its monotonic-solid rule overrode the empty live scene. The ship alternated left/right while the cash passed by. ReVa disassembly and checkpoint RAM both proved the clear; the existing dynamic terrain pipeline now handles it. Separate pickup errors compounded this: a frozen shower centroid survived a large camera transition, and a historical movement envelope was treated as collectible overlap. Pickup contact actually uses only the core ship, never side attachments.

Recommendation: inspect authoritative RAM and compare current scene, persistent map, goal geometry and command trace before changing pursuit scores. Terrain destruction is not limited to known narrow gates. Require regression coverage for both witnessed destruction and a cold restore after destruction, preserving ordinary walls outside the verified cleared range.

133. Classify a blocking shell correctly but never give its attack control (2026-09-02)

In full-game-03, shell #11697 was classified and ranked correctly, yet generic weapon reachability rejected it while navigation continued. The only existing test checked classification and priority, not the movement or destruction contract. Disassembly confirms fixed-X vertical oscillation and an X-independent proximity burst: this requires front fire from below before passing, not a lateral avoidance score adjustment. Its already-recorded step/phase/travel fields now drive prediction; zero step identifies a spent, undamageable shell.

The first validation also exposed an overbroad acquisition rule: a shell across a wall is not an immediately reachable front lane. A direct sideways-motion check was insufficient too; the reachable firing row can be farther DOWN. Reusing the existing configuration-space station planner fixes that distinction. Finally, the broad tolerance appropriate for following a waypoint must not be used as proof that a narrow projectile lane overlaps the target.

Recommendation: test the complete perception-to-action contract, including the final firing interval and safe approach, rather than merely the label/priority. Keep random proximity releases separate from deterministic movement prediction. Use a short recorded replay from the original checkpoint to verify actual destruction before the trigger, then check continued movement and damage. Do not infer success from target selection, sprite disappearance, or passing unit tests alone.

Level-5 full-run addendum (2026-09-30–2026-10-01)

This session investigated the repeated Level-5 gate and train-passage stalls and validated the complete level with resident C control. Evidence and rejected attempts are preserved in the full validation report. Recording stems below resolve to E:\xenon_runs\<stem>.validation\<stem>.x2events, with paired original/sprite AVIs and 150-frame checkpoints. Frame numbers identify evidence only; they must not become tactical conditions.

134. Treat a predicted collision as a prediction failure before examining action selection

Mistake and evidence: In level5-full-current-r102, the ship held still before the eight-point hit at 73145, then climbed into the fatal gate cluster 73602–73624. The resident trace already reported imminent contact and verified=0; the hazards were not simply missing from the scene.

Root cause: Ordinary candidates tried a short dodge followed by the original route. An unsafe later continuation could discard useful near-term movement; holding position or continuing the route was still selected when no complete candidate passed. Exact prediction alone cannot repair this candidate set.

Correction and recommendation: The early corridor now has a bounded multi-turn fallback using the existing transition budget. A safer checked partial path remains explicitly unverified. For every hit, compare collision-time telemetry, predicted contact, accepted plan and applied input before blaming a trajectory. Separate prediction error, missing escape options, arbitration and physical execution. The tank hits at 76439 and 76465 in the final r125 run were also predicted unsafe; their remaining root cause is not yet established.

135. Use incompatible or changing ship geometry to define a traversal contract

Mistake and evidence: Legacy corridor trials represented the idle ship as 21×30 instead of its original 21×20 collision header, rejecting legitimate gaps. Later, the diagonal gate's exit boundary moved between Y=2728 and Y=2744 in level5-diagonal-full-regression-r115 / level5-diagonal-repeat-r117, allowing phase changes without a real crossing.

Root cause: Different consumers used padded legacy hulls, captured collision bounds from the preceding collision pass, and terrain geometry as if they had the same meaning. A dormant target's 32×16 damage rectangle was also unsuitable as the gate's 32×32 terrain footprint.

Correction and recommendation: Use the original sprite collision headers for body trials, the game's wall hull for wall traversal, and the authored tile footprint for gate topology. The stable diagonal exit at (160,2732) derives from the maximum bottom extent of all five original ship poses plus the documented reserve. Share the pose table instead of copying it. Test geometry at the planning/execution boundary, including turns and retreat; do not add guessed thresholds to compensate for inconsistent shapes.

136. Repair a waypoint after scrolling has already removed its recovery route

Mistake and evidence: level5-whole-current-r120 stalled from about 79586 at world (130,1568). Camera Y=1392 and backward limit 1397 allowed a maximum ship anchor Y=1573, while crossing around the right shoulder required Y=1584. The earlier diagonal stall in level5-full-corridor-fixed-r112 had the same irreversible-camera problem. Both relevant openings were correctly represented in the native map.

Root cause: A world-map destination was treated as reachable independently of current camera limits. Generic goal projection selected a disconnected upper pocket; failed connectors then held the current X. By the stalled frame, changing the destination could not restore the lost lower crossing.

Correction and recommendation: Claim the local transfer before the camera passes its recovery row. Retain the reachable shelf/staging row, use an exact exit region, and include camera reach in the feasibility check. On connector failure, preserve the real crossing mission rather than projecting into another component. Inspect live occupancy, physical connectivity and scroll limits before assuming another missing map update. Restart before the loss of reachability when validating prevention, not only after the ship is trapped.

137. Permanently latch crossing completion even when a dodge reverses it

Mistake and evidence: In level5-full-corridor-fixed-r112, reaching (155,2734) at 76061 permanently set diagonal_crossed. Combat immediately selected DOWN; the ship returned to Y=2778 by 76072, but the flag stayed true. It eventually sat outside the chamber under its left diagonal wall, targeting a cannon through terrain. Previous endpoint and horizon adjustments did not repair this state transition.

Root cause: One anchor crossing was treated as irrevocable completion. Retreat, whole-ship clearance, disconnected pockets and route-failure fallthrough were absent from the completion contract.

Correction and recommendation: Recompute chamber membership from current position and physical connection to the exit; restore crossing priority if a dodge leaves that component. A failed crossing connector must retain the gate mission. Test crossing, retreat, recovery and release together. Keep permanent facts such as observed gate destruction separate from reversible facts such as being safely inside a chamber. Do not claim that a target can be shot through the diagonal wings: this session corrected that earlier comment.

138. Add a new passage owner without retiring the old train hold

Mistake and evidence: level5-train-passage-r121 reached the right exit, but at 79162 the old train hold replaced its route with a backward goal at Y=1561..1569. Alternating retreat and crossing led to two shield damage at 79248.

Root cause: The new exit route and old combat hold could both claim the same boundary. Surviving train members behind the ship kept the old mission active. Implementing the new route did not define when the previous consumer released control.

Correction and recommendation: choose_train_passage() owns this chamber before generic progression and the old hold. choose_train() releases at the exit, world Y<=1424. Audit all existing consumers when introducing a local mission, and test the first frame after release with surviving enemies behind the player. Log proposed, planned and applied actions separately; a displayed route is not proof that it controls movement.

139. Commit to a narrow exit before the scroll-triggered final wave is revealed

Mistake and evidence: Immediate crossing completed checkpoint run level5-train-passage-r122, but full-start level5-whole-fixed-r123 suffered 16 damage at 79240–79245 in the narrow right lane and lost its life at 80973. The trace predicted danger from 79218. Another train appeared as the camera passed approximately Y=1448; an earlier empty scene was not a cleared chamber. A 16-frame gate trial in level5-gate-local-r103 similarly passed one cluster but climbed into the following missiles.

Root cause: Local path clearance and present hazard absence were treated as sufficient readiness. The controller entered a choke before revealing the next authored wave, removing lateral dodge room. Shortening the evaluation horizon hid consequences instead of making the traversal safer.

Correction and recommendation: Stage at world (240,1588), preserving the wide lower area while the camera reaches the bottom-edge position Y=1412. Wait for the revealed train, hostile shots and damaging wrecks to retire, then commit to the exact right exit with the normal prediction horizon. Use camera geometry and observed encounter state, not a frame-number check or guessed wait duration. Test an initially empty scene before activation and a surviving projectile after train destruction. This correction passed both focused r124 and full-start r125 without chamber damage or stall.

140. Let checkpoint success stand in for the complete acceptance test

Mistake and evidence: Focused level5-gate-safe-prefix-r107 avoided its original cluster, but full-entry r108 failed. The immediate train route passed r122 and failed r123. Final-boss cash was 20/20 in r122 and r124, but only 17/20 in r125. Checkpoint runs r113 and r116 stalled at the preceding seal, so they did not exercise the intended diagonal correction at all.

Root cause: Restoring a checkpoint resets native mission history and can change camera, wave, weapon and spawn timing. A passing fixture or one focused run covers only its starting conditions, not the uninterrupted level. A test that never reaches its target is inconclusive, not a pass or a failure of that target.

Recommendation: Use a short failing checkpoint to establish the mechanism, then validate from before encounter activation and finally from the level start. Verify RAM-derived entry state and inspect that the intended encounter actually occurred. Report completion, survival, pickups and boss cash as separate results. The final r125 run completed at 82438 with one life and 23 shield, but still had four hits, a missed missile and three missed coins; it is not a clean run. Thirty-seven Level-5 mission tests passed, not every test in the wider suite.

141. Give boss loot priority without proving actual collection alignment

Mistake and evidence: In level5-whole-staged-r125, final-boss coins

626049, #626051 and #626061 expired at 82375, 82403 and 82416. The ship

alternated around X=161 and 170 while those large coins fell around X=147–148. The result was 1200/1500 cash, despite active collection priority. Tank cash was 10/10, worth 750.

Root-cause status: The collector retained control; this was not a proven terrain blockage or generic advancement override. Its collect_cash() code uses default X=162 and switches to an individual coin only within a three-frame arrival estimate. Switching between that default and short-lived intercepts is a plausible source of the oscillation, but the recorded C track velocities and pickup-contact timing have not yet confirmed it. Do not present this hypothesis as a finished diagnosis or another tested fix.

Recommendation: Trace the selected coin, velocity, arrival estimate, core pickup-contact rectangle, movement authority and applied movement until actual collection or expiry. Retain a feasible interception region and sufficient movement lead time rather than repeatedly changing an exact point. Audit every boss reward identity through retirement, distinguish collection from bottom-edge expiry, and verify reward value as well as count. Validate across several shower timings and an uninterrupted run before claiming all cash is collected.

142. Treat near contact and a redundant pickup audit as adequate equipment coverage

Mistake and evidence: r125 missed unequipped Homing Missile #603341, code $48, at 76425. It appeared at 76334; even its closest approach at 76413 left a ten-pixel gap. The same miss appeared in r120. Other expired Side Shots were already installed at maximum power two and were therefore redundant.

Root-cause status: The failure is a missed useful interception, not evidence that the item was already equipped or collected. The precise arbitration, reachability or danger restriction responsible for the missile miss has not been established; proximity alone does not prove a safe detour was available.

Recommendation: Compare semantic pickup identity and current loadout, then record the collection region, safe detour and any override reason. Make a small safe detour when reachable, while preserving survival priority. Verify actual inventory change or a collection event. Report useful, redundant and forbidden replacement pickups separately; do not turn every disappearance or carrier handler change into a successful equipment pickup.

143. Repeat a documented sandbox build failure before checking the process boundary

Mistake and evidence: An un-escalated official build stalled with Ninja but no compiler child, although HATARI_BUILD_RUN.MD already describes this sandbox failure. The exact stalled build processes were stopped, then the same official wrapper completed with scoped escalation. No build-script rewrite was needed.

Root cause: Tool execution permissions were treated as a build-system defect before checking the existing environment instructions and process tree.

Recommendation: Use xenon_tools/hatari_dev.ps1 for both Hatari and the native DLL, and use the documented escalation when the no-compiler-child symptom occurs. Do not start competing Ninja processes or kill unrelated instances. Wait for successful completion of both outputs before live or DLL replay tests. Keep the source/binary identity in the manifest; finalize AVIs gracefully and verify their indexes and end frames before presenting them as evidence.

144. Generalize a successful replay instead of the navigation invariant

Mistake and evidence: The earlier Level 2 lip repair remained in the merged sources, but r173 stalled at a different anchor in the same passage and r174 stalled after the shop. Its world-Y exemption and first-waypoint threshold did not recognize a tiny projected anchor followed by a real retreat.

Root cause: Lane/pacing preferences could replace the retained terrain connector, and occupied-start recovery required the hull to become clear in one step. A passing replay was incorrectly treated as a general repair.

Recommendation: Inspect the retained connector, preserve necessary retreat legs, use consistent ship/camera phases, and admit only physically safe escape trajectories. Test occupied and clear starting anchors, projected starts and different corridors, then an uninterrupted level. Never infer that a fix was lost in a merge without comparing the actual sources.

145. Let route recovery erase a valid survival decision

Mistake and evidence: Provisional r184 cleared the known wall traps but lost a life at 9932. Its recovery could replace a clear forward planner dodge whenever the route proposed another first input. This version was rejected.

Root cause: Terrain reachability was treated as sufficient authority to replace a checked maneuver. Running an emergency hazard pass afterwards does not establish that every overwritten maneuver was safely replaced.

Recommendation: Preserve ordinary forward dodges. Certify corrections against terrain and hazards before applying them. Keep route completion and shield/life acceptance separate, and report failed whole-level runs even if focused probes passed.

146. Confuse projected anchors with actual retreat rows

Mistake and evidence: Provisional r181 passed the early corridor without shield damage but stalled near (211,3243). Permissive skipping of an occupied start discarded the real (212,3252) retreat row along with projected points.

Root cause: A small quantization correction and a geometrically necessary backward leg were given the same waypoint-arrival rule.

Recommendation: Limit projection skips to genuinely small offsets and retain real corner rows. Validate the actual next physical segment, not only a rounded anchor. Add a fixture where skipping the retreat would cross terrain.

147. Apply an axis-ordering rule through a scrolling lateral crossing

Mistake and evidence: Provisional r187 stalled near (284,1102) and (261,1163). Physical start alignment alone still left r188's second maze replay stalled. The new horizontal-first rule suppressed vertical corrections until the whole lateral goal was reached.

Root cause: World-space Y drifts while the camera scrolls. An axis-ordering hint that is valid for the first corner does not maintain a crossing row.

Recommendation: Use vertical-first until a required retreat reaches its row, then allow both-axis world feedback on lateral legs. Test the public C forecast through a full crossing with active camera scroll, not just the mission's flag or its first proposed action.

148. Report a route pass despite a monitor stall

Mistake and evidence: The first corridor checkpoint helper emitted route_passed=true for r187 despite a stalled incident. It checked several specific stall names but omitted the monitor's actual stationary-stall name.

Root cause: Partial forward progress and an incomplete incident-kind list were used as route acceptance.

Recommendation: Reject every stall kind and life loss, optionally require an explicit exit world row, and inspect the completed incident report. Verify checkpoint locations from their own captures; the same frame range can describe different map sections in different recordings. The old r187 pass flags are invalid; see LEVEL2_ROUTE_ARBITRATION_20261002.MD.

149. Treat a grid-free refuge as a usable ship stopping pose

Mistake and evidence: October 3 Level 3 R226/R231 escaped a swarm into a left pocket but could not resume progress. In R231, (108,3472) was accepted as a station while the ship at (115,3470) stepped left into occupied terrain. The exit existed from the actual anchor.

Root cause: The onward check accepted a valid query with zero route points. Grid reachability also ignored the coarse horizontal stopping step.

Recommendation: Require actual route points, prove the exit under the future camera clamp, and certify the stopping neighborhood. Keep the transit graph undilated: narrow corridors and narrow stopping poses are different.

150. Review existing encounter evidence only after repeated experiments

Mistake and evidence: Level 3 notes were reread only after the user's reminder. Recent upper-refuge experiments lost lives while the C notes already described the lower-right escape. One passing checkpoint in R234 did not generalize to R235's earlier continuous run.

Root cause: Historical Python evidence, later C evidence and the current loadout were not compared before changing tactics. Converting a controller into goals also changed movement authority. The Y190 joystick hint became an unreachable waypoint, and an already completed right crossing could restart the left refuge during a new launch.

Recommendation: Read encounter documentation first, verify its source and loadout assumptions, and compare final applied inputs. Preserve the forward attack below the boss, make every goal physically reachable, and make return phases respect the ship's current side and their completion state. Require an earlier continuous run as well as focused checkpoint branches.

Full-campaign addendum (2026-10-02–2026-10-05)

These entries come from the native campaigns run from the start of the game, from the first three attempts, which all stalled in Level 4, to the four uninterrupted runs that finished it. Entries 225–227 were collected afterwards from the run reports.

151. Accepting route lookahead as a live navigation fix before it passed

Mistake: In R245 the carrier was defeated cleanly, but the post-shop G1 approach lost its later retreat row and stalled. Extending the search through G1 (R246) removed the hit without removing the stall. Forecasting successive route bends (R247) passed a component test but still took damage and stalled. Those changes were rejected rather than retained as completed fixes.

Root cause: Static map connectivity and a passing turn/retreat fixture do not establish that live survival choices preserve a camera-reachable route. The ship delayed in the right passage while the C camera model made the required world-Y2304 crossing appear unreachable. The historical investigation below establishes that the original Level 3 hook restores backward camera reach every frame; the crossing was not permanently sealed in the actual game. Route lookahead alone did not correct that missing rule.

Recommendation: Track reachability of the whole remaining route under future camera limits during detours. Preserve working boss attacks and validate the exit into the next area. Do not broaden claims from a clean boss fight to a clean level, or keep a failed feature because its unit test passed. Full recording paths and incident frames are in CAMPAIGN_FIXES_20261003.MD.

152. Treating a captured camera limit as a permanent Level 3 restriction

Mistake: Repeated G1 pacing and route changes assumed that the camera had irreversibly removed the maze's retreat bends. This contradicted the older Python runs that cleared all nine gates. The September native run was also mistaken for a successful baseline, although actual RAM shows G3's cap intact.

Root cause: The C migration bounded topology searches by the captured post-camera limit and refreshed routes every 64 frames. Original Level 3 code at $4F460..$4F468 restores $CEA to at least 2608 before the next camera pass. That rule was omitted from native player preparation and forecasting. In R245 at 23210, the same native physical graph returns no G1 route under the captured maximum Y2212, but a complete route via Y2304 with the actual restored allowance. The old and new snapshots contain identical original camera code.

Recommendation: Compare historical captured sources, applied inputs and checkpoint RAM before adding encounter rules. Model level camera restoration before declaring a route physically unreachable. Validate every gate through its actual cell state; a later-level filename or an after-gates resume proves neither all-gate progression nor port equivalence. Do not blindly restore an old forced-input override: the saved September experiment still stalled.

153. Reporting the previous gate after a failed route selection

Mistake: R258's later stall was described as G2, while RAM and C map state agree that G2 was open and G3's eight cap cells remained solid.

Root cause: choose_gate writes state->level3.gate only after successful route construction. Selecting G3 and returning a route-failure hold leaves the last successful G2 identifier in diagnostic state. The trace looked authoritative but reported stale mission selection.

Recommendation: Publish selected gate and route outcome separately and update selection even when route construction fails. Verify target labels against original tile words before diagnosing wrong topology. The detailed history, recording paths, code comparison and reproducible probes are in LEVEL3_GATE_REGRESSION_ANALYSIS_20261003.MD.

154. Checking a waiting destination without checking its connector bounds

Mistake: A visible Level 3 swarm bay was treated as reachable without backscroll, although its route dipped below the screen to world Y2496. R270 stalled at 23126 while the hold kept replacing the gate route.

Root cause: Only the station rectangle used the viewport bound. The span connector retained the newly restored whole-maze camera allowance.

Recommendation: Bound the entire route according to its purpose. A scroll-triggered waiting tactic and a deliberate maze retreat have different camera requirements. Validate intermediate bends, not just the destination. See LEVEL3_GATE_REGRESSION_ANALYSIS_20261003.MD for the recording and reproduction data.

155. Extending a maze escape rule into an already validated swarm passage

Mistake: Blocked-route progress search was enabled by the Level 3 camera rule and absence of a posture band, which also matched formation holds. The next full-entry run took earlier swarm hits despite focused maze success.

Root cause: Physical camera semantics were used as a proxy for tactical scope. The carrier-only result was also insufficient coverage of the passage.

Recommendation: Pass explicit search intent from the owning mission. The progress search now belongs to gate travel; early swarms retain contact escape. Verify the whole entry in addition to the focused failed checkpoint.

156. Mistaking coarse escape actions for an absence of safe maneuvering room

Mistake: The Level 3 G2-to-G3 shaft alternated retreat and Up/neutral, eventually stalling in R271 at 24560. An initial camera mismatch explanation was incorrect: original $661C and next-frame telemetry agreed with C.

Root cause: Escape search held each move for four frames. Lateral trials hit the walls after two or three frames, so legal single-input sidesteps were never explored. A safe hold preserved the ship but did not finish the retreat.

Recommendation: Inspect rejected trials and actual applied inputs before changing physics. Retry wall-rejected lateral moves with short taps only in the constrained navigation search, retaining collision checks and a bounded budget. Include a narrow raster-corner regression test, and do not accept a focused completion as proof of a damage-free full level.

157. Accepting gate clearance without testing ceiling exposure and the exit

Mistake: R273 opened every Level 3 gate but lost 20 shield in three frames at G6 (23714–23716), then repeatedly revisited the maze after G9. Gate clearance alone did not establish a successful level.

Root cause: Gate travel had dropped reaction pacing even on a forward approach, placing the ship at screen Y16 when new enemies appeared. The ordinary exit controller then restored screen pacing during a required retreat and replaced its destination every 64 frames, undoing progress through the detour.

Recommendation: Keep reaction room on forward legs, give retreat legs camera ownership, and retain a valid connector through its whole detour. Apply these rules to the maze exit as well as gate attacks. Verify entry, all gates and the actual level transition; record focused success separately from full completion and from damage-free completion.

Recording: E:/xenon_runs/level3-maze-repaired-full-20261003-r273.validation/level3-maze-repaired-full-20261003-r273.x2events.

158. Treating a projected navigation destination as forward progress

Mistake: After clearing every gate in R274, Level 3 advancement repeatedly requested a center point inside terrain. Navigation projected it to (164,544) in the same pocket, and the controller accepted a successful connector as progress. Retaining that connector alone could not solve the stall.

Root cause: The destination was chosen geometrically (160, player_y-128) without a forward-progress requirement. Projection guarantees legal space, not that the point is beyond the obstacle or useful for finishing the level.

Recommendation: Search a reachable region ahead and permit either side of the obstacle. Test a blocked center with open side exits, then validate through the real level transition. Keep the selected route until reached or invalidated. The implemented change is limited to Level 3 ordinary advancement.

Recording: E:/xenon_runs/level3-gate-reaction-exit-20261003-r274.validation/level3-gate-reaction-exit-20261003-r274.x2events.

159. Losing usable escape space when the mission changes at the end of the maze

Mistake: R275 left the Level 3 maze but died in the final radial-worm waves: 8 shield at 26896, the remaining 31 at 26897, and a life at 26914. All nine gates were already open. Resolving gate traversal did not resolve the encounter that followed it.

Root cause: Gate travel used real sprite hulls and a small wall reserve, but the final formation_hold reverted to padded wall checks without the contact escape search. Near the right edge, every immediate move was rejected as wall contact, although the real ship was still outside terrain. The incoming leader and its radial volley then overlapped the ship. This was a planning-space and mission-transition failure, not proof of a wrong projectile direction.

Recommendation: Audit which footprint, reserve, search mode and camera rule remain active when mission ownership changes. Keep wall safety and desired clearance distinct; do not label padding as actual collision. Use checked escapes with the physical hull in constrained encounters, without broadening progress-search scope into unrelated formation tactics. Validate through the next encounter and actual level transition.

Recording: E:/xenon_runs/level3-forward-region-exit-20261003-r275.validation/level3-forward-region-exit-20261003-r275.x2events.

160. Treating accurate paths or a safe forecast as complete collision validation

Mistake and evidence: Directional-path audits agreed with recorded motion to within one pixel, but full-entry R277 still took hits at 23211, 24162 and 28262. At 28262 the recomputed C plan reported 1.414px clearance while the recorded player and projectile rectangles touched. It would be incorrect to declare collision prediction solved, or to assume another projectile-direction error without investigating that discrepancy.

Root cause: Motion error, collision geometry, tick ordering, applied-input alignment and planning quality are different measurements. Accurate surviving object anchors do not validate all contacts or newly allocated shots. The exact geometry/timing cause of R277's third hit remains unresolved; the first two contact-frame forecasts found no immediate verified escape, which does not prove that their earlier approaches were optimal.

Recommendation: For each hit, compare the original captured contact with the forecast made before it and the input actually consumed. Verify inclusive edges, sprite/rectangle assumptions, camera origin and allocation/update order. Distinguish a model mismatch from an accurate but late safety decision. Keep unresolved causes explicitly unresolved; do not hide them behind a successful level transition or a motion-only audit.

Recording: E:/xenon_runs/level3-full-repaired-20261003-r277.validation/level3-full-repaired-20261003-r277.x2events. Inspection evidence and exact captured sources are in LEVEL3_GATE_REGRESSION_ANALYSIS_20261003.MD.

Session acceptance, 3 October 2026

R277 reached Level 4 at 30214, with all nine gates open, no lost life and no recorded stall. It took 12 shield damage across the three incidents above. The early swarm passage and carrier were damage-free. The pickup audit infers collection of all 10 carrier and 20 final-encounter cash drops from retirement beside the ship; it does not contain explicit collection events. Health Power pickups and Zapper were still missed, as were 46 ordinary cash items. These limitations must survive summaries of the successful navigation repair.

Both native targets were rebuilt, 74 targeted tests passed, and both finalized AVIs passed their structure/index audits. This is evidence for level completion and removal of the observed navigation stalls, not optimal or damage-free play.

161. Counting boss cash solely from observed pickup lifetimes

Audit limitation: Level 4 R278's pickup audit acquired only 19 of the final boss's 20 cash drops. Reporting this as a missed drop would have been incorrect. Drop #132197 was allocated and collected in the same update at 38104: its first captured state already uses retirement procedure $107C, and cash rises 6450→6550. The other 19 drops retired beside the ship before the shop opened.

Root cause: A lifetime observer only acquires objects while their pickup procedure is active. Allocation, collision and retirement can all occur between captures, leaving no captured active-pickup frame.

Recommendation: Reconcile boss payout totals with retired object states and cash changes before declaring a collection failure. Keep observed lifetimes, inferred collection and same-update credit evidence separate; do not treat an automatic shop payout as proof that the ship physically collected a drop.

Recording: E:/xenon_runs/level4-full-after-level3-20261003-r278.validation/level4-full-after-level3-20261003-r278.x2events. The completed result and remaining damage/pickup limitations are in LEVEL4_VALIDATION_20261003.MD.

162. Equating object observation, sprite visibility and click geometry

The Level 4 report at R278 frame 37337 exposed two different capture gaps: the tongue's conditional draw wrapper was rejected by an address whitelist, and Drone bullets bypass the object list entirely through a resident point pool. The Drone body was already pixel-identical in the AVIs, but unused interaction fields put its replay selection box off screen. Treating all three as missing sprites would have repaired the wrong mechanism.

Capture actual common blitter executions instead of guessing visibility from the installed draw procedure or stale sprite field. Capture direct framebuffer writers separately without fabricating canonical objects. Use render bounds for scene selection and keep collision bounds available as distinct evidence. Validate the exact logical coordinates after AVI scaling and display latency, including negative cases: R280 retained all 1,360 hidden-tongue observations without drawing them, and all visible tongue/Drone regions matched the original across 600 aligned frames. See rendering evidence.

163. Treating a selected weapon name as proof of effective firing alignment

R278's right eye eventually settles at screen hitbox Y=56..76, while the upper station Y=51..53 sends Side Shot at Y=48..50. All attachments fire together, so occasional Drone damage concealed the horizontal weapon's miss. The remaining head already uses a forward mount; this does not prove that every equipment combination is ranked by actual DPS.

Verify the live hitbox, shot origin, obstruction and observed health change before calling a station a firing lane. Preserve the safe approach separately from the final firing position: moving the entire left refuge/crossing down into the eye row increased exposure and was rejected. The right-eye adjustment applies only after entering its own pocket. R287 finishes that continuation without damage, but its eye dies during transit at the same frame as R280; do not present this as a measured DPS win.

An earlier restart also exposed a left-eye stall. Rebuilding the original tactic and using the identical checkpoint reproduced the candidate's hit sequence and life loss at 37815 (R286 vs R285), rather than proving a new right-eye regression. Keep that remaining restart failure explicit. See recordings and audit details.

164. Diagnosing a gate stall from its late stationary frame

R289's monitor reported the Level 5 stall long after the damaging decision. The ship starts entering the wrong pocket at 41857, just after destroying the right mount. At 41868 the center route correctly requires retreat, but its first leg is rejected by the clearance reserve. By 42009 the route is empty and the required lower turn has become unreachable. Inspecting only that last state suggested a direct-goal failure and missed the earlier mission/camera transition.

Root cause: Treating a recomputed route overlay as movement authority and starting analysis at the stall detector's frame. The original report also did not compare the earlier successful run's captured source and approach.

Recommendation: Trace destruction, selected mission, route suffix, trial rejection and applied input from before the first divergence. Compare the same physical phase across recordings, not frame numbers. R123's diagonal mission and map data had not changed; its central approach with the left mounts already absent did not cover R289's right-pocket arrival.

See gate evidence and final recordings.

165. Reducing clearance before removing the cause of a crowded retreat

An exploratory Level 5 candidate lowered the retreat reserve and changed progress search. It passed the wall but exposed the ship to projectiles from the surviving left mount. R293 took crossing damage at 41948, 41949 and 42007, then lost a life in the tank fight at 42399. This was not a successful gate fix. Those driver changes were removed.

Root cause: Solving the final trapped posture rather than planning the source suppression and lateral transition while the lower platform remained reachable. The same experiment exposed two competing mission owners: moving DOWN crossed the entrance acquisition boundary and abandoned the route; later the tank camera trigger stole control with an upper chamber seal still intact.

Recommendation: Keep acquisition distinct from release. Give a bounded encounter ownership through its necessary detours, and order its completion before a later encounter's camera trigger. Clear local projectile sources before reducing ordinary avoidance margins. Test that all-open and unavailable graph states release the old mission rather than routing back into it.

Final R299, R300 and R301 pass the chamber with the original reserve. Their earlier four-point hits remain explicit; an unchanged-mission control reproduces R301's 76047 hit. This proves the local transition, not damage-free full-level play. Recordings and source comparison are in the linked gate report.

166. Auditing object draw wrappers while missing a direct countdown draw

The Nashwan probe's missing gray shape was the timed-power digit, not another attachment. Its original routine selects a prepared sprite at $6B94 and branches directly to the blitter at $6BA4, bypassing both object dispatch and the captured prepared-sprite wrappers. No unknown-object-draw record could identify that path.

Root cause: Assuming that auditing installed object procedures covered every framebuffer writer, and comparing the full scene before locating the specific residual component.

Recommendation: Trace direct callers as well as object wrappers. Capture the game's actual selected sprite and anchor at the call site, then compare the complete aligned component region. The hook now covers both original Dive and Nashwan callers. Nashwan's ten digits match 168/168 regions; manual Dive activation is still untested live and residual weapon-edge differences remain. See countdown evidence.

167. Running emulator probes with overlapping process ownership

One countdown probe was interrupted while another probe finalized: the older harness cleanup stops every Hatari PID created since its initial process snapshot. Concurrent probes therefore appear to own each other's emulator. The countdown was repeated sequentially and completed normally.

Recommendation: Run live probes sequentially while cleanup uses a global before/after PID set. A future concurrent harness must retain and terminate only its own launched process. Interrupted recording is not a validation pass; audit finalized AVI indexes before publishing comparison results.

168. Nearest-pickup switching loses the first upgrade's interception window

In Level 5 R299, the pilot abandoned POWERUP #132972 for the nearer #133137 at 39899. It collected the second at 39915, but returning to the first's current position missed its fast downward exit at 39946. Both were valuable; being within 13 pixels earlier was not proof of collection.

Root cause: Independent nearest-target selection and pursuit of the current position, rather than a retained collection job with a reachable orbit/drop intercept. The ordinary cruising band also competes with a short detour.

Recommendation: Retain one live high-value pickup through its interception window, let collision avoidance temporarily override movement, and release only on observed retirement. Predict the existing scripted motion instead of chasing an old anchor. Scope the correction to the affected area until broader coverage is justified. R302/R303 confirm both collections by actual weapon power changes; see validation report.

169. A retired boss emplacement preempts the post-shop route

R302 stalled after the Level 5 shop while targeting an authored emplacement behind the ship. The actor had been retired by the shop transition, but its terrain/group evidence was enough for the mission to keep requesting attack.

Root cause: Treating a persistent authored group as a live target after the encounter's actor lifetime ended. This does not prove the remaining terrain is empty and must not be repaired by fabricating an opening.

Recommendation: Keep target presence and terrain occupancy separate. Skip an absent directional emplacement behind the ship while retaining real map cells. Give boss rewards their own completion phase before ordinary progress; R303 then collected all ten tank coins and passed the transition.

170. Plausible tank priority/search changes worsen live survival

Adding contact search and zero clearance reserve to tank side-emplacement attacks increased damage in R303. A follow-up rule that delayed emplacement priority until reaching a flank passed its synthetic fixture but lost a life in R304 at 42903. Both experiments were removed before final validation.

Root cause: Changing one priority boundary without validating the coupled cannon pulses, homing missiles and suppression timing. Correctness of a synthetic mission label does not imply lower exposure in gameplay.

Recommendation: Compare live survival from the same pre-encounter state, reject worsened candidates, and distinguish a diagnosed mechanism from a validated repair. Keep successful pickup, loot and transition changes separate from unresolved tank avoidance. Do not call a completed campaign damage-free.

171. Repeated pocket fixes without a navigation execution contract

The r306 campaigns all stalled at the Level 4 post-shop bend. A preferred point was projected into the current pocket, optional cash could preempt the required connector, and independent recovery rules rewrote the planner's movement. At a late stalled state the world map still connected the passages, but the connector was already below the camera's available backward reach. Another left-input patch could not recover that state.

Root cause: Treating map connectivity, current camera reach, and executable ship steering as the same property. Timer-based route replacement discarded legal retreats; diagonal 9px/5px steering did not follow a straight graph edge. Pacing could cancel the last few pixels of a required backward leg.

Recommendation: Require semantic progress from advance connectors, validate all remaining legs against camera reach, retain legal mandatory retreats, and carry explicit axis/world-row execution intent into the candidate forecast. Give one route ownership of the bend before optional jobs. Remove competing post-evaluation input rewrites instead of stacking another unsticking rule. Full r349 reached Level 5 without damage or stalls; earlier short-probe successes that worsened full-level survival were rejected. See sequential evidence.

172. Changing tactical cache admission while fixing moving pickups

A moving pickup needed its current goal to invalidate a retained escape. Applying that comparison to every direct-goal flag change also invalidated ordinary tactical suffixes and changed subsequent encounter timing. Full Level 2 probes then lost lives despite focused interception probes passing.

Root cause: Giving a boolean direct-goal hint the semantics of a moving target, without distinguishing tactical waypoint admission from reactive interception. Coupled tests were run too late.

Recommendation: Encode that distinction explicitly. Invalidate changed reactive goals; retain and recheck normal tactical suffixes through ordinary admission changes. Test both cache contracts, then run from before the encounter transition. Report rejected runs and keep cold-start diagnostics separate from resident uninterrupted validation.

173. Stopping cash validation before the next level exposed a transition hit

Focused Level 1 probes collected all eighteen boss coins without damage. A later full start showed damage on Level 2's first active tick, involving an eye's stale collision fields before its first update. Collecting the last coin opens the shop immediately, leaving no extra gameplay tick to reposition.

Recommendation: Include the shop and next level's first active ticks in a reward-phase regression check. Keep observed object origins separate from live collision fields. A successful last-coin counter is not sufficient evidence that the resulting transition pose is safe. The Level 1-only higher collection row passed r350; final campaign coverage is still required.

174. Replanning a safe delayed retreat restarted its delay forever

A complete candidate could wait briefly and then escape, but the next decision discarded that suffix and selected another candidate with the same wait at its start. The ship therefore never executed the retreat. R377 passed the captured failure after preserving a rechecked progressing suffix through its horizon; stationary suffixes are not admitted as navigation progress.

Recommendation: Verify progress over executed inputs, not only a horizon's endpoint. Test several consecutive decisions and distinguish safe waiting from repeatedly postponing a required leg.

175. Preserving destroyed spider web as static terrain

At r392 f14137, RAM and authentic pixels showed an opening, but native spans still contained the old web. The map permitted destruction only for authored groups; the spider's 44 rebuildable tiles had no group. R393 reached the shop but took 16 damage and collected no reward cash. Smaller movement adjustments could not repair the falsely disconnected map.

The correct Level 2 overlay shows four web tables at $5151C, $5157E, $515E0 and $51632. $511E6 can restore individual cells after they were shot away. RAM restoration and complete live observations now reconcile those exact cells, including repeated destruction and rebuilding. R394 took no damage and collected 20/20 cash; r396's four pre-boss checkpoints all defeated the spider without damage, though some still missed cash.

Recommendation: Compare RAM, rendering, persistent cells and span topology at the same failed frame before changing steering. Rebuildable terrain must not be modeled as a gate which can only open once.

176. Rejecting an ordered route because its diagonal shortcut was blocked

In r397 the Level 3 ship alternated at world (250..259,3421..3422), with stall reported at f17717. Camera drift put it just above its saved horizontal leg at Y=3424. Retention tested a direct line to the next point, rejected that shortcut and restarted the previous bend, although down-then-left was clear. The new retention check accepts clear ordered axis legs and axis selection verifies the chosen first leg. R398 passed this corner without damage; full-level validation is separate.

Recommendation: Route generation, retention and execution must agree on permitted motion. Test both axis orders, blocked alternatives, camera drift and camera-unreachable destinations; do not use a valid diagonal as the only proof that an orthogonal connector remains reachable.

177. Using a different build directory for a checkpoint matrix

The focused runner rebuilt out/build/codex-validate, while the existing boss matrix selected the stale out/build/mingw-release executable. R395 failed before recording started. Rebuilding the selected directory and DLL made r396 valid. An earlier reverse-engineering inspection also found a supposedly Level 2 dump containing a different level's overlay at the same addresses.

Recommendation: Record the selected executable and hashes in every test, carry build-directory selection into reusable runners, and verify overlay bytes before interpreting same-address routines. A level-specific filename alone is not evidence of the loaded code.

178. Point progress and polyline proximity are insufficient in a maze

Mistake: repeated waypoint tolerance changes treated a safe stationary choice as progress. An experimental nearest-polyline score then skipped a required retreat because a later route leg lay nearby, losing two lives in level3-connector-progress-20261004-r400-1.

Root cause: geometric distance through terrain is not remaining travel distance, and proximity to a future leg does not establish route order.

Correction: retain the ordered connector and use terrain distance to its destination for Level 3 travel. Keep actual trajectory collision validation and reaction posture independent. Test a folded route and an obstacle requiring initial motion away from the target, then run the entire maze.

179. Cash interception was defeated by its own descent predicate

Mistake: a new coin interception rule produced identical live misses in r409 even though its isolated fixture selected the desired X.

Root cause: camera drift moved the ship just outside a stricter descent threshold than the accepted collection row. Descent then suppressed X changes; the fixture tested a perfectly aligned station and missed that transition.

Correction: verify the recorded phase/goal/action at the miss, and test interception while Y drifts within the legal station. Keep the below-web prerequisite separate from normal Y corrections. Boss defeat and reward collection need independent acceptance conditions.

180. Unvalidated prediction expansion contaminated navigation comparisons

Mistake: a wider Level 3 chain forecast remained in builds used to validate unrelated maze repairs and introduced a carrier regression.

Root cause: accumulating unaccepted experiments prevented attribution of new failures. A filename or intended scope was taken as sufficient evidence.

Correction: withdraw unvalidated independent changes, compare exact saved source and build identities, and validate one changed mechanism at a time. Verify checkpoint filenames before starting a run; an approximate filename is not a usable checkpoint. r406 is the zero-damage carrier rollback control.

181. A destruction consumer searched a population which had already removed the object

Mistake: Level 4 map clearance looked for the main head's unlink handler among live tracks. R421 head #87252 dies at f34331, but explicit destruction filtering removes it before the map sees those tracks. Its offscreen wall remains solid and the reward tactic is never acquired.

Root cause: the consumer required an object lifecycle state the upstream producer deliberately excluded. Prior tests covered RAM restoration and stale draws, but not the destruction event passing through the real observation filter.

Correction: query the existing captured destruction event by retained identity; test both an unrelated death and the filtered boss death with its wall offscreen. R423 validates zero damage and 10/10 reward collection. Do not infer a kill from draw visibility or disappearance alone.

182. A focused boss pass did not cover an uninterrupted pickup approach

Mistake: treating R417's focused success as sufficient would have hidden R418's missed Side Shot and three lost lives. Retention initially omitted the screen-Y range check, and an orbit-crossing experiment still chased the wrong part of the pickup's lifecycle.

Root cause: acquisition thresholds were also release thresholds; checkpoint restart changed movement timing, and a full sprite gap was mistaken for enough evidence of actual pickup collection. Different checkpoint/loadout outcomes were not interchangeable controls.

Correction: retain the admitted object until retirement, use the already implemented Level 4 final-drop/short-contact routine, and audit equipment changes and full-level outcomes separately. R421 and R422 collect Side Shot; R422 still has entry/final-boss damage, so it is not a clean campaign result.

183. A checked approach repeated its waiting prefix instead of executing its turn

Mistake: a Level 5 launcher approach remained in ordinary contact-escape refresh, even though it owned a concrete route to a firing station. Its safe forecast waited, then travelled; repeated refresh restarted the wait.

Root cause: route intent was assigned by an incomplete tactic list rather than the job's travel phase. A valid route overlay concealed a scheduling failure.

Correction: give that approach the existing progress/retained-suffix contract and score distance through reachable terrain. Preserve actual contact checks and test the entire approach, not only the first selected input. R424 clears the former stall but has later damage, requiring further combat validation.

184. A screen posture erased an interception's required world retreat

Mistake: R426's Side Shot interception targeted the bottom screen band while already there. Neutral input satisfied that posture and let the camera advance; the ship never reached the pickup's required world-space station.

Root cause: screen pacing and world movement were treated as interchangeable. A finite station became an unbounded world-Y goal during wrapper assembly.

Correction: preserve the finite world retreat and reserve the predictable missing-weapon drop before boss bypass. Reuse its prepared interception once. R428 collects Side Shot with zero damage and all ten boss coins; full R429 collects both useful items with no life loss, but retains a final projectile hit.

185. A late raw input override invalidated a checked route

Mistake: Level 4 entry changed the planner's checked UP to DOWN/LEFT. The entry mission also released when the ship crossed its acquisition X edge, allowing a wall-gun job to cancel the unfinished retreat.

Root cause: input authority and mission ownership had contradictory contracts.

Correction: remove the post-planner steering helper, retain a checked corridor connector until completion, and test the applied input against the actual native winning trajectory. Full R429 eliminates the entry damage.

186. Repeated a previously rejected tank experiment

Mistake: the R431/R432 tank experiments repeated physical-hull and pulse priority changes similar to failures already documented for R303/R304. They again lost lives and were withdrawn.

Root cause: encounter notes were read after implementing a plausible tweak. Synthetic mission selection was mistaken for evidence about coupled projectile avoidance, cannon suppression and return to the firing station.

Correction: consult the accepted run and rejected-experiment ledger before implementation; compare saved sources and identical checkpoints. Keep rejected changes out of unrelated navigation builds. Active tank safety is unresolved.

187. Relied on full viewport observations for a gate destroyed outside them

Mistake: R434 destroys Level 5 gate 10 at f44962, but the map still treats its clipped lower row as solid and continues attacking it indefinitely.

Root cause: the two-full-observation opening rule cannot observe every mutable tile after camera movement. The map ignored controller retirement.

Correction: retain terrain-controller identities and borrow actual tile RAM on unlink/death, recording the same import for replay. Do not open a gate from death alone: $510A2 also culls intact controllers at $51152, while its hit handler clears tiles at $511F8/$511FA. Verify the correct Level 5 RAM image; the currently open ReVa program had different overlay bytes. The fixture covers both clear words and culling with nonzero words; live acceptance is pending.

188. Restricted progress to one tactic without repairing routed execution

Mistake: after a broad progress-search run failed combat acceptance, restricting it to launchers reproduced the retreat-prefix stall at a gate in R436. That gate also attempted diagonal steering through a wing despite a clear down-then-sideways approach.

Root cause: the job's execution contract was incomplete: its route, steering order and retained safe prefix disagreed. Changing a tactic list alone did not repair the whole contract.

Correction: check axis order for pre-tank routed approaches and preserve the lower world row during lateral crossing. R437 passes the previously stuck gate, but exposes a later empty-tank approach stall and is not a level pass.

189. Occupancy-only revisions left a different collision image cached

Mistake: R447's Level 5 gate stall was initially probed from a cold checkpoint, where a fresh environment selected a clear route. That alone could suggest mission retention or another waypoint tweak. The uninterrupted run retained a different wall raster despite having received the tile import.

Root cause: Map revisions counted known/solid state but omitted a solid cell's sprite and source-row offset. RAM import skipped nonzero-to-different- nonzero tile words. Complete-history C replay reproduced 4586/4586 live decisions, then showed that cached and fresh rasters from the same canonical map disagreed across world rows 3360..3391.

Repair: Include collision-image changes in geometry revisions and import actual replacement tile words. Keep solid totals distinct. Regression fixtures cover image changes, unchanged observations, cache refresh and immutable old snapshots. Record every live topology import and consume it at its exact frame in the authoritative replay decoder.

Recommendation: Before editing a stalled route, compare current RAM, native cells, cached raster and a fresh raster of those same cells. Reproduce retained history through all lifecycle and terrain messages; a cold checkpoint probe is diagnostic evidence, not an equivalent replay of the live controller state.

190. Replaced a static connector on animation and confused transit with refuge

Mistake: R449's gate approach moved from a valid lower crossing station to ever-higher stations, then froze outside the opening. Removing its hard refuge constraint in R450 prevented damage but did not establish progress.

Root cause: Blind revision/timer invalidation discarded a still-clear route to a static gate whenever the gate animated. World-row compensation was also conditional on screen posture. The transit exit was erroneously a containing refuge, excluding retreats around the obstacle.

Repair: Retain authored gate connectors while every leg is clear and within camera reach; compensate mandatory lateral world rows independently of screen Y. Keep gate priority without imposing refuge containment. R451 crosses and defeats the tank with zero damage; full R452 completes but retains separate combat/reward failures. Fixtures include animation/timer churn, new obstruction and loss of backscroll allowance.

191. Correct cash priority lacked navigation out of a firing pocket

Mistake: R452 correctly selected tank cash but missed all ten coins while staying at X276. Priority labels were mistaken for evidence of executable input.

Root cause: Direct coin steering crossed a right-hand wall lip. It had no connector owning the necessary DOWN-then-LEFT approach to the central lane.

Repair: Route the tank's reward approach in C before direct falling-coin interception. Preserve its world row during the crossing. R453 replays the failing run's pre-death checkpoint with zero new damage and 10/10 coins.

Recommendation: Navigation is required for rewards and combat repositioning as well as forward travel. A movement target does not imply a direct path; separate the checked approach from the moving interception phase.

192. Terrain distance rewarded the destination before a required route bend

Mistake: R455 kept changing camera Y near (200,1140) instead of reaching the active maze bend (176,1140). Valid topology and an accurate route overlay were mistaken for proof of executable progress.

Root cause: The candidate terrain flood targeted the final destination, allowing a local improvement which abandoned the ordered connector.

Repair: Price the active waypoint; the mission advances it only after reaching the bend and validating the next leg. The folded-return fixture requires the retreat first. R456 passes the maze, but full R457 exposes a carrier life loss: the focused run alone does not certify the full repair.

Recommendation: Progress metrics must agree with route ownership. Test both the original stalled state and uninterrupted arrival at later encounters.

193. A selected carrier refuge was not safe for the time needed to leave

Mistake: R457's goal kept pulling the ship to the low-left refuge until the moving carrier trapped it and killed it at f17724.

Root cause: Refuge selection used launch side and a short threat check at the firing lane, not the refuge's safety over its escape time. The shared planner could postpone contact but could not repair that persistent goal.

Repair: Check the low refuge for the time required to reach the upper route; begin the existing upper crossing when that interval is threatened. R458 defeats the carrier with zero damage and all ten coins. Full-level acceptance remains separate from this focused success.

Recommendation: A refuge requires a predicted safe interval and an exit, not merely a safe current point. Preserve the encounter-local route while letting the shared collision evaluator validate its actual inputs.

194. Refreshed a timed escape before its initial wait could finish

Mistake: R463 repeatedly restarted a 22-frame safe waiting prefix at the eight-frame refresh. The ship never performed the escape predicted by its own planner, although the recorded worm motion agreed with the prediction.

Root cause: Finite route commitment applied to progress-producing travel, but not a CONTACT dodge which returns to its preferred region.

Repair: Retain a finite, moving CONTACT suffix while reevaluating it against every new scene. R465 passes the first wave but fails the next; do not confuse one corrected control defect with full encounter acceptance.

Recommendation: Validate executed prefixes against the promised trajectory. A forecast containing a later escape is worthless if refresh repeatedly resets the time before that escape.

195. Greedy frontier pruning mistook a future trap for lack of escape space

Mistake: R465 forecasts contact 34 frames ahead but keeps safe prefixes near the same corner, pruning the early retreats needed to avoid enclosure.

Root cause: Preferred posture and accumulated clearance rank the bounded frontier before the distant threat reaches those nearby branches.

Repair: Preserve safe spatial extremes alongside the best CONTACT branch without increasing frontier size. R466 clears the waves with no damage and all 20 coins. The independent wall-tap retry loop also required a larger local array than its held-action-only allocation.

Recommendation: Inspect discarded safe branches before increasing budgets or claiming there is no room. Keep exploration diversity distinct from final trajectory ranking and size buffers for all actual loop attempts.

196. A carrier refuge check omitted the parts that actually hit the ship

Mistake: Full R467 loses a life at f18599 after emitter/main-body hits at f18580..18582, despite a clean focused final-wave test.

Root cause: Encounter threat admission checked tails, attachments and live cores, but omitted the main body, emitters and spent cores. Its 8..12-frame firing-lane check was shorter than the time needed to retreat and climb.

Repair: Include all live carrier collision parts and check through a speed-derived sequential retreat/climb interval. Focused R468 and full R469/R479 pass the carrier without damage; R479 also collects all ten carrier coins.

Recommendation: Reconcile high-level threat sets with the bodies consumed by collision evaluation and the exact recorded damage sources. A selected station must remain safe long enough to reach its exit, across arrival phases.

197. Truncating admission evidence and assigning no progress owner to its route

Mistake: R469's G1 staging oscillates with gate selection. The focused R474 test passes, but full R475 circles before the carrier without advancing.

Root cause: Pending-wave paths were prepared after selection using a horizon capped to imminent birth. Moving preparation earlier fixes that truncated evidence, but reveals that a routed FORMATION_HOLD still uses contact-only search. Its safe retreat can be retained without advancing its actual connector.

Repair: Prepare the shared paths once before admission; a routed waiting-bay approach uses ordered progress. Bound its arrival by spawn/activation facts. Full R479 has no stalls/lost lives and collects all 30 boss coins, but takes one 8-point hit. It is not evidence that every combat decision is clean.

Recommendation: Distinguish a waiting station from the route to that station. Prepare enough evidence before acquisition, and test the same build over the uninterrupted entry as well as a cold checkpoint at the failed gate.

198. Confusing a goal bound with a connector bound

Mistake: A newly required lower bay returns no route, so travel resumes the unsafe approach despite a legal retreat into the bay.

Root cause: The station's minimum Y was also passed as the span connector's minimum Y. That search excludes a ship which begins above its goal. A retained station also bypassed newly observed dormant-row admission constraints.

Repair: Use camera bounds for the connector, station bounds for its endpoint, and recheck the station's dynamic admission predicate before retaining its route. A synthetic newly observed controller reproduces both failures; the affected 38 native route/decision/planner/driver tests pass after correction.

Recommendation: Keep goal eligibility, connector reachability and timed collision validation as separate conditions. A correctly drawn endpoint does not establish a reachable or safely executable route.

199. Describing screen motion as a world-space prediction error

Mistake: During R476 investigation I initially said an expanding member's changing screen Y proved the C model incorrectly held Y fixed.

Root cause: I compared screen anchors before reconciling the camera. Verified Level 3 bytes at $50690..$50816 add camera compensation to Y and change only horizontal spacing. ReVa decompilation returned a cached Level 4 overlay despite the requested Level 3 path; raw project bytes match the captured Level 3 RAM.

Recommendation: Compare anchors in the same frame origin and verify binary bytes before using cached overlay labels. A conservative dependent envelope is also not the same thing as the single-point path rendered for inspection.

200. Pruning the retreat needed to execute a graph bend

Mistake: Treating a connected graph route and a complete safe forecast as proof of forward progress. R480 stalled at (237,2065) while selecting repeated Up/Down cycles. Right moved nine pixels into terrain; the following route leg could not safely replace the active bend.

Root cause: The PROGRESS search retained only nearby low-cost parents. It discarded safe retreat branches before they could turn through the bend. There were no pending spawns at the inspected f23200 decision, the horizon was 56 frames, and the cached/fresh raster matched. Blaming the earlier allocation horizon correction would have misidentified the failing mechanism.

Correction: A broad PROGRESS diversity change clears the focused stall in R481 but causes a carrier life loss in full R482; reject that policy. Preserve distinct safe endpoint extremes only for an arrived route bend whose onward line is blocked from the actual hull, then rank completed paths by the ordered progress objective. R483 clears the former stall without forcing a direction or skipping a waypoint, but its three later projectile hits mean it is not a damage-free level. Full and cross-level regressions remain required.

Recommendation: Diagnose graph connectivity, actuator reachability, frontier admission and executed progress separately. An escape may initially increase distance. Require focused and uninterrupted live regressions before accepting a generic search-policy change.

201. A close waypoint, a scored arrival and a usable departure were different predicates

Mistake: Accepting full R484's lack of stalls as proof that the original trapped pose was repaired. Recomputing that pose still selects a vertical cycle. A multi-pose fixture also finds forecast tails which promise departure but are discarded or land outside the mission's actual advancement interval.

Root cause: Scoring measures distance to a nominal bend while the mission requires a clear onward line from the actual hull. Interpolation can score a neighboring legal anchor which the mission's rounded position does not occupy. Nearby-parent grouping can erase a real transition boundary. Four held vertical inputs can overshoot the required row at another ship speed.

Correction: At blocked bends, seed the field from valid departure anchors, score the same rounded anchor/arrival interval as mission advancement, retain admitted and unadmitted parents separately and retry short vertical taps. Cache the admission predicate once per decision. A twelve-pose closed-loop fixture executes C mission, planner, movement and retained-plan updates until the route cursor advances. Its pass is an algorithm regression check, not live acceptance.

Recommendation: Test the failed state directly as well as an earlier checkpoint. Use executed-prefix closed-loop tests when refresh or mission transitions are involved; a safe forecast tail and a changed arrival time are not proof that the old trap can be escaped.

202. Reporting a partial incident count as a finalized validation result

R488 was described as a full Level 3 clear with one four-point hit before its audit had finished. The finalized recording instead contains 78 shield damage and two lost lives, at f26074 and f27162. The earlier statement was corrected immediately, but it should never have been made from a partial log.

Root cause: progress output and a partially written audit were mistaken for the completed acceptance report. A process returning successfully also does not certify gameplay; the wrapper can finish after a failed campaign.

Recommendation: wait for graceful recording finalization and audit completion, then read every damage/life/stall entry and the terminal result before claiming success. Report focused tests separately from uninterrupted level/campaign tests.

203. Discarding the only collision-free retained escape for missing reserve

In R488 f26025, retained trial 0 passes all 56 collision-check frames with 3.1px clearance. Because the preferred reserve is 4px, search does not accept it immediately. It also omits that trial from its fallback candidates, leaving only worse new routes. A shorter fallback returns right into the radial worm. The actual worm paths agree with the C forecast throughout the checked window.

Root cause: retained-plan early acceptance was incorrectly also its admission to the final comparison. Missing preferred clearance was treated as reason to erase a valid route, whereas actual collision and incomplete evaluation are the reasons to reject it.

Repair: keep a completely evaluated, non-contacting retained suffix as a fallback while still searching for greater clearance. Ordinary safety ranking then prefers it to colliding routes. Three native contract cases verify this fallback, selection of a safer new route, and rejection of a contacting suffix. R490's focused live replay reaches Level 4 with zero additional damage/lives/ stalls. Full R491 rejects the global policy because it regresses earlier encounters (67 damage, one lost life). The retained fallback is now an explicit search mode selected only for the failing Level 3 final waves. Full R492 has no lost lives/stalls or final-wave damage, with the earlier four-point projectile hit still open. Campaign validation remains necessary.

R535/R536 repeat an overly broad fallback for progressing navigation escapes. The focused run still takes four damage and the full Level 3 regresses to 16; the additional mode selection is removed. The wall bullet also changes its collision header with animation, so a fully evaluated suffix against a frozen short rectangle is not proof of physical safety. Do not expand the scope again without checking the model's contact geometry and full encounter regressions.

204. Updating a moving pickup goal without invalidating its retained station

R489 misses Cannon despite acquiring its mission. At f5079 the goal is a short orbit intercept, but the accepted old forecast still starts DOWN and waits at the prior drop station. The mission clears its cruise band without propagating the direct/reactive property, so the decision layer cannot distinguish the new job from its old stationary suffix.

Repair: pass the existing reactive-goal contract for this direct Level 1 Cannon intercept. The weapon model is unchanged. R494 collects Cannon at f5071 and reaches the shop without damage, lost lives or stalls, but uninterrupted R496 and R497 still miss it. The reactive flag reaches the planner; a safe retained path without pickup contact is still accepted, and orbit chasing competes with the approaching swarm. R498 instead meets the predicted drop on the ship's current reaction row and uses an explicit collection completion contract. Cannon is installed at f5109; uninterrupted Level 1 reports zero damage/lives/ stalls. Nearby equipment still permits a short immediate detour when no future crossing exists. R499 checks the resulting equipment through all of Level 2.

Recommendation: verify acquisition, updated endpoint, retained-plan invalidation and executed first input as one contract. A correct target label alone is not proof that its new interception actually controls the ship.

205. Letting homing staging preempt the missing Side Shot intercept

R489's falling Level 2 Side Shot is missed while its fixed central reaction row pulls the ship upward and homing staging repeatedly takes priority back. The missing attachment then changes spider entry and available weapons.

Repair: in the lower Level 2 homing passage, meet the item near the current reaction row and give missing Side Shot priority over homing staging, retaining collision checks. R493 collects it at f12885. Its three spider projectile hits and poor boss cash collection remain separate failures.

Recommendation: compare actual equipment and phase-entry state before treating a downstream failure as a regression in an encounter previously tested with a different loadout. Test reward retirement against installed equipment changes.

206. Treating phase retention alone as a usable spider attack

R493 falls back from front fire when the spider timer becomes negative. The original $50DE6 controller uses that timer during live movement as well as dormancy. R495 tries retaining the front phase unconditionally, but keeps backscrolling until the head is outside the viewport. It requests world Y 468..476 despite a maximum of 464 and stalls at f19868. The experiment is removed.

Recommendation: admit target visibility, camera reachability, actual installed weapon contact and phase lifetime together. Fixing one state predicate must not preserve an impossible station. Revalidate with the intended collected equipment before redesigning the fallback for a checkpoint with missing upgrades.

207. Collision-checked control was replaced by a second encounter scorer

R499 predicts the three-eye worm contact yet a later Level 2 input rewrite restores crossing after checking only an eight-frame prefix. R501 then exposes the same competing ownership during worm clearing. The repair gives checked transfer and clearing candidates final movement authority; R502/R503 pass five earlier checkpoints without damage. Root cause: calling a proposed route safe without verifying the mask actually consumed by the game and the entire crossing. Recommendation: trace proposed, evaluated, applied and consumed input, then remove redundant arbitration instead of tuning its distance thresholds.

208. Unlinking a hostile was mistaken for immediately removing contact

R499 f12347 is a homing-body collision on its unlink update. The original collision check precedes object retirement. R504 keeps exactly that first retirement observation contact-bearing, with a shared semantic predicate and tests for both Level 2 and Level 5. Root cause: independent contact-kind lists and lifecycle classification dropped still-effective geometry. Recommendation: derive contact membership once and test update order through retirement.

209. Used a hypothetical weapon instead of the recorded loadout

R511 prefers a laser in a synthetic spider fixture but the live checkpoint has no laser. The real loadout includes Double Shot and a Cannon; using the nominal primary center misses the head's narrow shot bounds. R512 aligns the captured Cannon mount and passes five earlier starts with zero damage and all 20 coins. Root cause: generalizing from an invented loadout and sprite geometry without checking installed attachments and observed boss health. Recommendation: report what the live run actually exercised, use captured shot bounds, and retain the deferred weapon-physics scope rather than claiming an unmeasured DPS gain.

210. Treated replacement route indices as semantic progress

R492 f23470 has a checked escape, but a reconnect at f23471 renumbers route_index 2 to 1 and changes mission identity without changing target or destination. The gate retainer also tests a straight diagonal even when execution permits a clear ordered dogleg. New tests reproduce both contract failures and distinguish actual reached-bend advancement from reconnect numbering. Root cause: topology, route representation and high-level job lifetime shared one invalidation rule. Recommendation: keep separate contracts and validate safety against each new observation. Do not declare the repair accepted from tests alone: the first focused combined repair R513 completes without stalls but takes 28 damage. Component isolation and full-level regression remain required.

211. Predicted a long boss wait using only already allocated worms

R516 f8918 collects POWERUP but loses a life at f9721 after contacts f9700..9704. The last old left member disappears at f9688, and a new train appears at f9690. At f9680 the retained forecast is clear for 56 frames, but contains only the old train. Shots destroy its surviving members sooner than their script termination; the planner's retreat to the left edge intersects the replacement train. ReVa's verified Level 2 overlay confirms $50218 allocates a replacement whenever $DA3 is clear, using the arena table at $501B8 and path $5174A. Eye destruction does not close the wormhole. R519's replacement envelope passes this one start, but R520 produces a stall and damage; the narrower R521 also regresses. Both experiments are removed. R522 instead pauses fire after the incoming right leader is cleared, preserving the outgoing left script until launch is safe. Two starts pass, but another loses a life during the later middle-eye descent. That phase still replaces a checked escape with its raw Down proposal. R523 gives it checked steering authority and passes the failed start; the other starts and uninterrupted level remain required before acceptance.

R525 reacquires replacement incoming right leaders. R526 still exposes a stall from a stale departure rectangle; R527/R528 replace that condition with live train/delay evidence plus full-route checking. All five earlier starts then clear without shield damage/lost lives/stalls. Two cash misses remain separate acceptance failures. Uninterrupted whole-level coverage is still required.

212. Cash lifetime heuristics omitted allocation-update collections

R519's first boss-reward capture contains nine active coins worth 700, although the recorded cash balance increases by 750 over their lifetime. An additional 50 is credited on the allocation frame, before that coin has a captured active lifetime. Conversely R516's older run credits only 650 and genuinely expires one 100-value coin. Report object lifetimes and scalar credit together, preserve unknown identities, and exclude shop transactions from collection credits.

213. Camera reset discarded an unfinished reward job

R523 kills the three-eye boss at f10854, then the camera reanchors from 2880 to 2543 at f10855. Session reset clears boss_active together with retained movement. Generic pickup targeting climbs after orbiting coins and misses small cash #24044 at f10923. R528 repeats the miss from two other starts. This is loss of semantic ownership, not a coin-path or terrain error. Preserve the completed encounter's reward job while discarding camera-dependent routes, retained decisions and wall recovery. Keep full resets on life loss, new level and restored run. Tests must include that ownership transition and actual cash credit, not just damage-free boss completion. R529 tests this repair separately.

214. A departed train was required to remain in its departure rectangle

R526 f8423 waits at (100,2704) from f9769 until the stall report at f10668. The launch predicate requires a left-origin survivor at X<80 and screen Y>=120. Those survivors have already followed their script outside that rectangle; the complete route forecast never gets to decide whether departure is safe. Current C replay matches all recorded statuses through f10685, and the new trace identifies no_departing_left_member, not blocked terrain or body contact. Replace the stale positional requirement with live train/delay evidence and the complete route forecast. R527/R528 clear all five starts with zero damage, lost lives and stalls. Test delayed tails, already departed survivors, replacement incoming leaders and real route contacts separately. Avoid fixed waiting times or an unconditional forced movement as substitutes for usable transition evidence.

215. Treated pre-boundary formation waiting as ordinary padded-hull cruise

R531 clears the last Level 3 gate but takes 12 damage during formation waiting before scroll Y208. The actual job already has no gate route; a coordinate-only scope excludes the real-hull contact search and rejects useful dodges. R532 includes that semantic post-gate waiting job. The original contact is gone; a separate four-point projectile hit remains and is reported separately.

Use job state to identify an encounter's ownership transition. Clearing the navigation stall is not a full acceptance test for its subsequent combat.

216. Froze an animated radial bullet's current collision rectangle

At R532 f25056 the forecast approves a dodge which the real game hits. Level 3 radial bullets cycle four sprites at two ticks each ($4F69E). Their collision boxes shift with draw origin even though their widths appear identical. ReVa confirms $4180 advances animation before refreshing the contacting bounds. R533 adds the extracted sequence to generated C envelopes and clears the focused passage without damage. Full-level R534 still has a four-point hit from a wall bullet whose direction is predicted correctly but whose header also animates. The user accepts that level result (zero lives/stalls, complete boss cash) under the four-shield-per-level budget. The further geometry work is deferred; it must not be conflated with acceptance of a broader retention rule.

Verify active collision headers across animation, rather than infer a constant box from sprite appearance or the correctness of the anchor trajectory.

217. Reserved every possible aimed shot instead of predicting the candidate's shot

Level 4's final eye allocates an aimed projectile on a known byte-timer carry. The original scene omitted that future allocation, causing R537's two final-eye hits. R538 anticipated all four legal directions as simultaneous hazards. That diverted the ship into the actual tongue/projectile, costing 35 shield and a life. Root cause: replacing an omitted candidate-dependent interaction with an overly broad independent danger fan. R539 uses the original compass mapping, muzzle bias and alternating collision headers for the candidate's predicted ship position at allocation. Its focused run is clean; full R540 has eight damage, all restored by a paid shop repair, no lives/stalls and complete boss cash.

Recovery accounting must distinguish an observed shield increase from a pickup that merely disappeared. R537's early health pickup did not restore the later 12 damage. R540's restoration occurs in the shop (31 to 39), not gameplay. The passive audit now includes shop restoration while excluding respawns and level resets. Use this evidence when applying the user's net-damage budget.

218. Mistook a consistent station for an executable temporal approach

Mistake: Diagnosed Level 5's final-side stall as an X-lane mismatch, then expected a fixed world station to resolve it. R544/R545 still stalled beside cannon #151197 at Y249 instead of reaching Y263..265.

Root cause: A lane is a scoring preference, not a hard constraint. The side planner discarded its safe retained approach unless it predicted mounted damage and immediately moved (or was already at the firing row). Replanning repeatedly restarted a wait/dodge before the required descent. Captured camera/input/ship telemetry passed 431 checked R545 updates; terrain cache agreed with a fresh raster. Neither camera exhaustion nor stale wall occupancy explained this stall.

Repair and evidence: R546 retains a fully rechecked suffix which either damages mounted parts or ends closer to the firing row, including a finite wait. A non-progressing wait remains ineligible. The same start now completes without damage/lives/stalls and collects all 1500 final cash. R547 also clears from before the last gate, but its eight immediate post-load damage points remain a separate incident; do not silently call that earlier-start run clean.

219. Extended a retiring missile's collision lifetime in the wrong phase

Mistake: R549 kept a frozen Level 5 missile box hazardous after age 80 and tested it against the ship's new position on that same update. The synthetic test agreed with the implementation, but the full run lost a life at f40419.

Root cause: The original player scans stored boxes before moving. Missile expiry installs the unlink thunk without movement, camera compensation or its normal post-movement contact check. A retiring box can hurt the ship on its next pre-unlink scan; it does not perform another active missile contact. The prior passive validator omitted the expiry transitions which would expose this error.

Repair and evidence: R550 follows the two contact phases and expiry camera origin separately. ReVa /level5dump establishes the branch and call order; 4282 observed original updates, including 20 expiry transitions, match motion and bounds. Full R550 still fails a different train approach, so model accuracy is not described as full-level acceptance. Recordings use E:/xenon_runs/level5-full-missile-unlink-20261005-r549-1.validation/level5-full-missile-unlink-20261005-r549-1.x2events and E:/xenon_runs/level5-full-missile-order-20261005-r550-1.validation/level5-full-missile-order-20261005-r550-1.x2events.

220. Moved a complete firing station to an unadmitted camera-relative point

Mistake: To avoid rushing to screen Y17 during the Level 5 train approach, R551 replaced the authored firing station with a lower camera-relative point. That point lay behind terrain and the replacement stalled.

Root cause: A desired reaction band is not evidence of a connected endpoint. Changing the destination discarded the useful ordered connector and allowed a failed route to fall back toward an unreachable direct goal.

Repair and evidence: R552 keeps the authored destination and route cursor. Only a physically clear active upward leg may be clipped to screen Y140..144, and its input proposal is recomputed. The same earlier checkpoint now crosses the train chamber without damage. Full R553 has no lives lost/reported stalls, collects all 750/1500 boss rewards and finishes at 37 shield after a real twelve-point shop repair. This accepts the user's recovery budget without claiming a zero-damage level. Recordings: E:/xenon_runs/level5-train-visible-stage-20261005-r551-1.validation/level5-train-visible-stage-20261005-r551-1.x2events and E:/xenon_runs/level5-full-train-recovery-20261005-r553-1.validation/level5-full-train-recovery-20261005-r553-1.x2events.

221. Called a gradual escape through occupied terrain wall-free

Mistake: Focused level validations passed, but three full R554 campaigns stall at the same Level 2 connector near (181,2965). At f9520 the native planner labels five initial predicted updates clear even though its own anchor query reports all five inside terrain. It expects to reach clear space on update six.

Root cause: Wall-motion admission permits non-increasing approximate escape distance from an occupied starting point, including occupied endpoints. Original collision replay prevents those individual movements from executing. Driver recovery accumulates all four blocked directions while retaining the same route. An additional shared geometry error uses the animated player sprite rather than the original fixed $3515C wall footprint. Raster-cache equality and native/live parity cannot prove that either physics assumption matches the original game.

Recommendation: Validate every executed update under the game's actual collision/replay rules; keep overlap, preferred clearance and approximate escape distance as distinct facts. Regenerate the fixed footprint from canonical RAM and repair a connector after execution disproves it. Test the full prefix and its acquired loadout: these campaigns also miss the Level 1 Cannon which the earlier focused validation collected. Original failing recording: E:/xenon_runs/campaign-final-recovery-20261005-r554-1.validation/campaign-final-recovery-20261005-r554-1.x2events; the corresponding -2 and -3 recordings reproduce the same failure.

Confirmed repair (2026-10-05): The generator now extracts the original 25-row wall footprint from assets/stram.bin and verifies its 16 shifted copies. Wall-motion admission checks each game update's actual endpoint; a decreasing escape distance cannot admit an occupied endpoint. Ending actual wall replay invalidates the disproved connector once while preserving its mission target. Recovery no longer permanently blacklists all four directions. A single retained environment replaces the animated-footprint cache and separate raster ownership; ordinary frames do not add a graph search or escape-distance ring search.

The R555 checkpoint passes the original lip without damage. The three fresh R564 campaigns and R565 HD/high-FPS campaign complete all five levels without detected stalls or lost lives. These results confirm navigation execution in the tested campaigns, not pickup completeness or damage-free play. The Cannon miss remains unresolved. Full filenames and incidents are in the uninterrupted validation report.

222. Confused a replay label and retained route storage with an active travel job

The full-prefix eye approach uses C tactic BOSS_EYE (6), although the UI calls it boss_refuge. An initial steering-ownership fix used the wrong eligibility condition and therefore did not repair the fresh-prefix stall. A subsequent extension to every nonzero eye phase treated a formation hold as travel merely because route storage remained populated. R560 then lost two lives to worm segments at f10425/f11036. The first commentary also prematurely named an eye as the attacker; the captured hit sources identify worm followers. That attribution is corrected in the run report.

Root cause: diagnostic names and stored geometry were substituted for the controller's actual semantic output. Focused success from a different pose failed to exercise the erroneous predicate.

Recommendation: test the real C phase, tactic and executed input together. An old connector can remain stored during a waiting job; route count alone does not grant travel authority. Keep validated combat/waiting behavior when repairing an approach and confirm a fresh prefix before accepting it.

The rejected run is E:/xenon_runs/level2-route-owner-20261005-r560-1.validation/level2-route-owner-20261005-r560-1.x2events. The corrected R561 reaches Level 3 without stalls or lives lost, but still misses Cannon and spider cash. Those omissions remain distinct acceptance failures; do not erase them because the navigation problem is improved.

The accepted predicate requires Level 2, an actual BOSS_EYE or BOSS_REFUGE route output, and APPROACH_LEFT or DASH_RIGHT_REFUGE. It preserves the existing guards in formation holds and other waiting/combat phases. All four subsequent uninterrupted campaigns pass the eye encounter without losing a life; the broader Level 2 damage and missed spider reward remain reported separately.

223. Used a firing deadzone to decide whether a route bend was reached

Mistake: Even with the correct wall model and a connected route, the eye approach could stop three pixels before the retreat's required turning row. The displayed route therefore looked usable while repeated decisions failed to execute its first leg.

Root cause: Ordered waypoint feedback reused the firing-station deadzone and compared a world-Y requirement against the wrong camera origin. Being close enough to aim is not the same as reaching the row from which the next route leg can execute. A camera step changes that world-space arrival test even when the screen-space pose looks unchanged.

Repair and evidence: Feedback now uses the next camera origin and the connector's actual finite world-Y interval. It retains route order instead of silently accepting a nearby firing pose. The existing bounded planner performs the approach; its search budget is unchanged. Fifty targeted environment, wall, maneuver, driver and session checks pass, and the four uninterrupted R564/R565 campaigns have no detected stalls. See the navigation review for the rejected intermediate runs and the separate steering-ownership repair.

Recommendation: Give waypoint arrival, firing alignment and preferred screen posture separate predicates. Test neighboring poses, discrete ship steps and camera changes through repeated applied decisions, not only a forecast from an exact waypoint center.

224. Focused and split validation missed the fresh campaign's loadout and transitions

Mistake: Successful gate and boss checkpoint tests left repeated full-prefix stalls undiscovered. Later R561 (start through Level 3) plus R562 (restart through the end) covered the level sequence, but did not satisfy the requested uninterrupted campaign test. A saved checkpoint also supplied equipment which fresh gameplay could miss, including the Level 1 Cannon.

Root cause: Restarting reconstructs controller state from RAM; it does not exercise the same retained jobs, acquired weapons, camera transitions or damage history as continuous play. Completion, survival, damage recovery, useful pickups and boss rewards were different acceptance conditions and needed separate evidence.

Repair and evidence: The reusable repeat launcher now starts three fresh campaigns from the same initial snapshot and records both AVIs through spaceship destruction and final completion. A fourth uses HIGH FPS and HD sprites. All four reach completion at f49987 with three lives, 33 shield and no detected stalls. Their 49986 active gameplay frames have identical recorded controls, player/shop state and raw object state. Launch arguments, visible-window inspection and AVI exports confirm that the fourth actually uses the different renderer options. Different final capture frames reflect observer stop latency, not different gameplay; comparisons end at the first completion event.

The remaining failures are explicit: Cannon #9655 is missed at f5011–5067, the Level 2 spider reward is 0/1500 at f14936, and Level 5 ends with six unrecovered shield damage. Earlier damage clusters and other pickup misses are listed in the full report. Surviving all four runs does not resolve those failures or prove every possible starting state safe.

Recommendation: Use focused tests to diagnose a repair, then accept it against the actual requested campaign and renderer configuration. Compare canonical active game frames, verify actual collected/installed equipment and cash credits, and publish every remaining criterion independently. Do not use a later health repair to hide a dangerous early damage cluster or count a respawn as recovery.

225. Validated and timed on a Debug emulator without checking the build type

Mistake: Validation runs, including the timed full Level 5 runs, used out/build/mingw-debug. The emulator core, tracing, GPU view and AVI recorder were compiled -g -O0; only the C autopilot linked into Hatari was optimized. Naming an output directory mingw-release would not have helped: the official wrapper configured the Debug preset for any directory. The build type was only read from the compile commands during the fast-forward investigation.

Root cause: The configuration being measured was assumed, not checked. Wall-clock comparisons are meaningless without the actual flags and executable.

Repair and evidence: A Release preset and -BuildType Release were added, and campaign validation records the build type and the executable's hash. With immediate GPU presentation and automatic memory tracing as well, the same full Level 5 run took 202 s instead of 832 s, 4.12 times faster than the old fast-forward setup. See the fast-forward investigation.

Recommendation: Before timing or comparing runs, record the build type, the effective optimization flags and the executable hash, and measure the configuration that will actually be used.

226. Explained an enemy's motion from its handler's name

Mistake: The three-campaign baseline found that fitted straight-line motion missed the turns of the Level 2 lower-maze diver $50346. It then blamed the missing motion-script capture, because the code already called the handler LEVEL2_SCRIPTED_SINE_SWARM. Disassembly of saved Level 2 RAM showed a ship-aligned diver instead: it climbs to the top of the screen, tracks the ship's X, dives, and resets near the bottom, with a small wobble driven by the game timer. Capturing it as a motion script would have been wrong.

Root cause: A symbol name was taken as evidence of behaviour. The measurement was right; the explanation came from the label, not the code.

Repair and evidence: C now captures the dive flag and simulates the climb, chase and dive phases, and recordings carry the game timer for the wobble (trailer $5842). Resumed at the same point, R194 took no diver damage where the baseline took three 8-point diver hits. See the campaign fixes and the baseline report.

Recommendation: Describe a handler's behaviour only from its disassembly, checked against RAM from the same level. Treat existing symbol names as hypotheses.

227. Trusted a checker's assumed record layout

Mistake: In the audit of the three campaigns of 2026-10-04, validate_game_model.py reported 24 homing-prediction failures over frames 12000–13000, failures that could have justified changing the homing model. They were invalid. The checker assumed that any captured object record of at least 196 bytes ends with a 98-byte pre-update snapshot, but a new object's first capture is 98 bytes of object data plus 128 bytes of script payload, without pre-update state.

Root cause: The checker decoded a layout that had never been checked against the capture code, and its failures were read as findings about the game.

Repair and evidence: The audit set those failures aside and relied on the independent damage and movement evidence. The checker now uses the actual capture layout (2026-10-05). See the three-campaign report.

Recommendation: Derive record layouts from the code that writes them, not from sizes, and check a validator against known-good records before acting on its failures.

228. Reported a final-message flag as a fully recorded ending (2026-10-05)

Mistake: The full AVI/MP4 campaigns stopped when $1178C first became nonzero, before recording the final shop dialogue. The report called that final completion. The C session also treated the byte as a permanent stop, preventing the later GET READY fire acknowledgement and continued Level 1 gameplay.

Root cause: A message-selection flag was mistaken for a completed lifecycle event. The flag remains set after Level 1 loads. The old test asserted zero input after that flag without checking the shop, loading, prompt or next playable frame.

Repair and evidence: ReVa confirms the shop's three timed messages skip buying/selling, followed by level wrap and a GET READY fire wait. C acknowledges the prompt and can resume gameplay despite the sticky flag. The monitor now requires Level 5 ending evidence followed by playable Level 1. Visible continuation E:/xenon_runs/ffmpeg-final-shop-20261005-r582.validation/ffmpeg-final-shop-20261005-r582.x2events records the shop at f49983, Fire at f51328, and playable Level 1 at f51352, with no damage, lost lives or stalls. Both MP4s finalized and passed video/audio audits. This continuation does not retroactively turn the earlier runs into uninterrupted recordings of the entire ending. See FINAL_SHOP_VALIDATION_20261005.MD.

Recommendation: Define campaign completion from the observable end-to-end sequence, not a variable name. Inspect the actual final scenes, include prompt acknowledgements in lifecycle tests, and distinguish ending selection, ending completion and campaign restart in reports. Keep bounded stall detection during timed scenes without treating an automatically advancing dialogue as a menu stall.

Updated high-level recommendations

For the recent navigation failures, start with the execution chain: original collision rules, authoritative terrain, ordered connector, active mission owner, and final applied input. Repair the first disproved contract before adding another waypoint exception or expanding search. Keep working encounter behavior intact and finish with a fresh campaign using its real acquired loadout.

1. Require one planner-facing occupancy truth. Restore dynamic terrain from RAM at live startup and reconcile it with repeated complete renderer observations; a stale persistent cell must never overrule an authoritative visible opening.
2. Keep exactly one retained mission route and one monotonic route cursor. Combat, pickup collection, pacing, and survival may temporarily control the ship, but they return to that suffix rather than create competing navigation missions.
3. Represent destructible topology explicitly: closed cell, controlling object, required firing pose, observed destruction, open cell, and path invalidation. Never infer permanent geometry from one frame of a dynamic gate.
4. Derive semantics from update procedures and object fields before naming behavior. Direction is an instance property unless disassembly proves that the procedure itself is direction-specific.
5. Use one world-space prediction product for diagnostics and control. Collision-constrain the ship with the game's real rollback behavior, resolve semantic object links before predicting, convert game-internal screen anchors only at the boundary, predict threats through closest approach, and retain enough of a proven escape to cross its critical interval.
6. Give survival absolute authority over route and wall recovery. Among safe choices, prefer the one that preserves corridor clearance and advances the retained route; do not sacrifice a life to obey a wall or route heuristic.
7. Make UI labels auditable: strategic mission, movement authority, active target, prediction horizon, committed plan length, and invalidation reason must be separate values.
8. Explore from the nearest checkpoint with one acceptance condition and one model change. Preserve verified cross-level mechanisms, remove unproven encounter rules, and run the relevant synthetic fixture before another long recorded playthrough.
9. Model scripted bosses as monotonic encounter missions. Each phase should own its target set, weapon lane, safe configuration-space region, and completion predicate; draw visibility and the global route must not erase an active phase.
10. Include delayed weapon state in attack timing. FIRE time, projectile allocation time, attachment position, and collision time are distinct events and must not be collapsed into one visual lane.
11. Plan irreversible camera transitions before the lower crossing becomes unreachable. A free world cell, an open gate and a complete map route do not establish reachability under current scroll limits. First include per-level restoration rules: a post-camera capture alone does not establish irreversibility.
12. Define mission acquisition and release together. Retain traversal ownership through a dodge, recheck reversible crossing facts, and prevent an old hold from reclaiming a completed passage.
13. Reveal scroll-triggered encounter hazards before committing to a choke. Preserve maneuvering room while clearing the wave; an empty current scene is not proof that the encounter is over.
14. Separate acceptance results and diagnosis confidence. Full completion does not imply no damage, all useful pickups or all boss cash. State confirmed causes, plausible explanations and unresolved causes explicitly, with recording filenames and frames for each failure.
15. Give route success a semantic progress contract. Require a nonempty connector to a reachable forward region; projecting a preferred point out of terrain must not silently turn it into the same pocket. Retain a valid detour until reached or invalidated, rather than moving its endpoint during a backward leg merely because a refresh interval elapsed.
16. Bound the whole connector by its purpose. Waiting for a scroll-triggered wave requires a visible station and visible intermediate bends; intentional maze backtracking requires the original level's restored camera allowance. Screen pacing must not reverse either mission's required leg.
17. Pass explicit search intent from the mission. Camera rules and absence of a posture band are not encounter identifiers. Keep contact escapes distinct from progress search, and retain reaction room on forward approaches while allowing checked retreat and lateral world-row corrections.
18. Match search resolution to the actuator and passage. Inspect rejected trials before concluding that no room exists; a four-frame lateral action can hit a wall while one input is legal. Retry only the relevant rejected actions with short checked taps, within the same bounded work budget.
19. Audit collision truth separately from desired clearance and motion accuracy. Actual hull contact, padded-wall rejection, safe-forecast/live-contact mismatch and lack of an early enough dodge require different repairs. Verify the forecast's frame origin and consumed input before tuning.
20. Test ownership transitions as well as steady phases: carrier to cash, gate to egress, last gate to maze exit, maze exit to final waves, and level to shop. Restart tests must reconstruct needed encounter state from RAM and be compared against uninterrupted runs; prior success from one checkpoint is not sufficient coverage of a different starting phase or loadout.
21. Reconcile pickup lifetimes with scalar credit and retirement state. A drop collected on its allocation update may have no captured active frame; distinguish this from a miss and from automatic shop credit before evaluating boss-cash tactics.
22. Keep observed objects, executed draws and interaction geometry distinct. Conditional draws, point pools and unused equipment collision fields need different capture/inspection rules; verify both visible and deliberately hidden cases against aligned original pixels.
23. Verify effective weapon contact separately from mission labels. Use live hitboxes, actual spawn offsets and observed health changes; preserve safe approach stages when aligning a stronger weapon. Compare old and new tactics from identical checkpoints before assigning causality, and never claim a DPS improvement from a run that did not exercise the new station.
24. Diagnose the first failed transition before the eventual stall. An initially correct map route may be rejected, abandoned on a retreat leg or preempted by a later camera-triggered mission. Clear local sources while the connector is still reachable; do not reduce global clearance to force a passage whose safe approach was already lost.
25. Audit direct rendering paths independently from object draw procedures. Compare the affected component at aligned logical coordinates, preserve residual differences, and distinguish shared-hook coverage from an actual live test of each activating power.
26. Make navigation's execution contract explicit: semantic progress region, complete camera-reachable connector, retained suffix, realizable axis order, and final movement authority. A correct route overlay cannot certify an input which another controller later replaced.
27. Treat cache admission and interception intent as separate concepts. Restrict goal-change invalidation to moving jobs and verify that ordinary tactical retention remains equivalent before long validation.
28. Reconcile known mutable cells throughout their lifetime, including destruction followed by rebuilding. Verify topology against actual tile words before interpreting a failed connector as a steering problem.
29. Retain routes under the same axis-order semantics used to execute them. A blocked shortcut does not invalidate a clear dogleg; a clear alternative does not authorize taking its blocked first leg.
30. Separate encounter clearance, damage, stalls and reward collection in acceptance reports. Four damage-free boss clears do not prove that all four collected their reward cash.
31. Score progress through reachable terrain and preserve mandatory route order. Never use proximity to a future polyline segment as permission to skip an obstacle's retreat or crossing.
32. Test every phase predicate across the whole accepted station interval, including camera drift. A fixture at the exact station center can miss a transition which suppresses the desired action.
33. Test topology events through the actual observation filter. Consumers of destruction must read destruction evidence even when the affected object is correctly absent from live hazards.
34. Assign navigation intent to the travel job, including approach to a firing station. A checked wait-and-turn must advance through time; repeated refresh must not restart its wait indefinitely.
35. Keep finite world-space requirements through every wrapper. A screen posture which is already satisfied cannot replace a required retreat, even if both goals mention the bottom of the viewport.
36. Review saved accepted sources and rejected encounter experiments before implementing another plausible variation. Passing synthetic selection is not proof that coupled combat is safer.
37. Treat controller retirement as a reason to reconcile authoritative topology, not proof that its tiles were cleared. Preserve replay parity by recording the same import before the affected frame.
38. Invalidate geometry for collision-image changes as well as occupancy. Diagnose retained caches against fresh geometry from the same canonical cells before modifying mission or steering rules; reproduce all recorded lifecycle and terrain messages when comparing live and replay decisions.
39. Static stations need route-validity retention, not moving-target refresh rules. Preserve required world rows regardless of screen posture; a transit exit is not a containing refuge. Route reward approaches through terrain before handing control to direct pickup interception.
40. Price the active route bend before its final destination. A shorter terrain distance to a later leg is not progress if it abandons an ordered retreat or crossing.
41. Validate refuges over their escape time. A short currently safe hold can become an inescapable body collision while the same high-level goal keeps pulling the ship back.
42. Preserve full admission evidence independently of the immediate control horizon. Reobserve at known allocation boundaries before committing beyond missing target/damage state.
43. A route to a refuge needs travel ownership; waiting begins only after arrival. Keep endpoint eligibility separate from the camera domain which includes the route's actual starting point.
44. Preserve bounded search diversity for necessary detours. A low-cost prefix is not evidence that its continuation can execute a graph bend with the ship's discrete movement steps.
45. Give scoring, parent equivalence and mission advancement the same transition predicate. Verify it across neighboring poses and actuator speeds, then execute repeated decisions; forecast-only tests can miss a delay which is continually restarted.
46. Keep collision freedom and preferred clearance separate throughout search admission. A route missing reserve must remain eligible against routes with actual contact; recheck its suffix and prefer greater clearance when both routes are complete and safe.
47. Publish acceptance only from finalized recordings and completed audits. A progress log, checkpoint success, wrapper exit code or partial incident count cannot certify a full run.
48. Define success for the job, not just its geometry. A safe retained route is not a completed moving-pickup interception. Price actual collection, admit feasible timed crossings and verify the installed attachment in an uninterrupted run before accepting a checkpoint-only result.
49. Separate job identity from connector numbering. A reconnect toward the same destination is not a reached bend; preserve checked escapes through representation changes while rechecking terrain, threats and camera limits. Test actual advancement and route loss separately.
50. Give one validated candidate final movement authority in each encounter phase. A second scorer of constant inputs can discard the safe wait/turn which the first evaluator proved.
51. Verify actual mounted equipment and interaction geometry before choosing a firing lane. A primary center, sprite center and narrow damage hitbox are different quantities; synthetic weapon fixtures cannot substitute for the live checkpoint's captured loadout.
52. Include imminent allocations in long-horizon safety. Destruction can accelerate a repeating source's next birth; a correct path for existing bodies does not certify an empty future scene. Use exact captured scripts and conservative timing where weapon outcomes remain uncertain.
53. Reconcile reward lifetimes with recorded cash credits. A missing active object can have been collected during allocation; neither disappearance nor a nearby sprite alone proves collection.
54. Separate semantic task lifetime from geometry lifetime. Camera reanchoring invalidates movement, but does not itself complete a reward job; death and level/run changes are different events.
55. Check whether a wait predicate can become permanently false after its intended event has already happened. Use captured state and the actual route forecast rather than requiring an old event's visual footprint to remain present.
56. Re-evaluating a whole route does not establish safety when the interaction model is incomplete. Check animation-dependent hulls as well as trajectory direction before expanding retention policy; use the user's accepted damage budget to avoid destabilizing working encounters for marginal gains.
57. Model an aimed allocation against the candidate's future player state when its firing edge is known. Reserving mutually exclusive directions together can produce worse dodges. Report total damage and actual restoration separately; do not count respawn/level resets as health recovery.
58. Compare executed inputs and captured movement with the forecast before blaming a station or camera limit. A consistent mission can still stall if its safe finite approach is rejected at each update; test repeated decisions, including waits and pre-attack travel with zero predicted weapon damage.
59. Validate retirement through the actual collision order. A frozen box may remain scannable before unlinking without performing another post-movement contact. Include expiry transitions in model comparisons; omitting them can let a passing test encode the wrong lifetime semantics.
60. Preserve an admitted destination while managing approach posture. Clip only an active leg with a physically clear connector, recompute its proposal and retain the ordered route. A desired screen band does not justify replacing the mission endpoint with an unreachable point.
61. Distinguish an admitted escape from executable collision-free game updates. An approximate distance which decreases does not authorize occupied endpoints when the original game rolls them back. Validate the original fixed wall footprint, repair disproved connectors, and verify complete approach/loadout prefixes instead of treating checkpoint success as campaign proof.
62. Define route ownership from the active semantic job, not UI labels or retained route storage. Exercise the exact C tactic/phase predicate and final applied input in regression checks; preserve a waiting or combat phase when fixing its approach. Attribute live damage only after checking captured hit sources.
63. Keep route arrival distinct from firing tolerance and screen posture. Use the correct camera phase and the connector's finite world-space interval; a nearby station is not evidence that the next bend can execute. Verify repeated controls from neighboring poses and ship speeds.
64. Remove duplicate preparation only after identifying the original game's geometry contract. Share one immutable environment per relevant geometry revision and invalidate disproved routes at the execution event. Do not compensate for a wrong model with larger search budgets, repeated full-map rebuilds or additional per-frame fallback searches.
65. Accept campaign and renderer claims against canonical active gameplay, with actual startup flags and rendered evidence. Split checkpoint coverage is not an uninterrupted campaign; observer stop latency is not gameplay variation. Report survival, restoration, useful pickups and boss cash separately, including unresolved misses after a stall-free completion.
66. Validate the full terminal sequence, including ending dialogue and its required acknowledgements. A sticky message-selection flag is not a finished scene. Confirm the next playable state and retain separate milestone frames so a report cannot silently equate entry with completion.