Close out RM-034: circle-vs-Rect detection generalizes to Core, wall/landing restitution policy does not (three games, three distinct answers)
Context
RM-034 tracked glemy's third reference game (a platformer) specifically to produce a real second data point on two Core API generalizations decision 0052 explicitly deferred pending exactly this evidence. With all four phases complete (0: Core promotion, decision 0058; 1: pure logic, decision 0059; 2: rendering/input, decision 0060; 3: tuning + website integration, this entry), RM-034's own resolution is the verdict decisions 0052/0058 said it should state plainly.
Decision
The verdict, with three real reference games' worth of evidence behind it: (1) Circle-vs-rectangle collision detection (Rect/nearest_point/overlaps/penetration_axis) genuinely generalizes and is now Core (physics/rect.gleam, decision 0058) -- Breakout and Platformer need byte-for-byte identical detection math, differing only in resolution (reflect vs. stop), the same detection/resolution split physics/collision.gleam already established. (2) No single wall/landing restitution policy belongs in Core, confirmed a third distinct way, not just reconfirmed once more: Tiers damps to ~10% (physics/bounds.bounce, decision 0029), Breakout reflects near-elastically (bounce_off_walls, decision 0052), Platformer stops dead at zero restitution (stop_at_walls/resolve_platform_hit, decision 0059) -- three genuinely different answers to 'what happens when an entity meets a boundary,' not three tunings of one shared idea. physics.update's own composition remains correctly not a drop-in generic physics step; every game with non-default wall behavior should keep composing entity.integrate/collision_sweep.resolve_all_collisions directly with its own bespoke resolution, as all three now do. A genuinely new finding this phase also produced, beyond RM-034's original two questions: a grounded-state-transition pattern (deriving a one-shot event from a state field's own before/after tick values, not from a single frame's transient physics derivative) is a real, reusable technique for detecting discrete events inside continuous simulation, caught while fixing a real bug in Platformer's own Landed event (decision 0059) before it shipped.
Verification
Backed by the full, independently verified phase history: decision 0058 (Core promotion, zero behavior change to Breakout, confirmed by every existing Breakout test passing unchanged plus a real browser-check re-run), decision 0059 (281 Erlang / 306 JavaScript tests, all pure logic), decision 0060 (a new browser-check passing on its first real run, confirming real keyboard-driven movement/jump via the captured-GPU-uniform technique), and this phase's own real fixes verified empirically -- a genuinely unwinnable level (15-unit platform steps exceeding the ~13.6-unit peak jump height, caught by direct calculation before any playtesting) corrected and re-confirmed via a real browser probe (one plausibly-timed jump lands exactly on the next platform's predicted resting height), and a full local glemy-website build producing a real, independently content-hashed platformer demo directory with genuine playable content. Final state: 281 Erlang / 308 JavaScript tests passing, 104/104 warnings baseline clean, all three browser-checks (Tiers/Breakout/Platformer) passing for real.
Consequences
glemy now has three complete, independently-launchable reference games, each contributing real evidence to the same running question this whole multi-month initiative has asked: what genuinely belongs in a genre-agnostic Core API, and what doesn't. The answer is no longer a hypothesis -- entity integration, pairwise collision sweep, and now circle-vs-rectangle detection are confirmed genre-agnostic across three real, structurally different games; wall/landing restitution policy is confirmed genre-specific across the same three. A fourth game's own tick function has a real, evidenced template to follow: compose the Core primitives directly, write bespoke resolution logic, and treat any detection math shared with an existing game (not this game's own resolution logic) as the actual Core-promotion candidate. RM-034 is closed; the next milestone is genuinely open -- no further Core-API-validation game is currently planned, and the physical package extraction trigger (RM-027, docs/technical-architecture.md §2.3) now has three consumers' worth of evidence behind it, more than the 'a second, genre-distinct game' condition it originally named.