|
| 1 | +# ADR-003: RAID Sandbox is a desktop game — the mobile flow is removed |
| 2 | + |
| 3 | +**Date**: 2026-09-05 |
| 4 | +**Status**: Accepted |
| 5 | +**Impact**: medium |
| 6 | +**Summary**: Below the desktop breakpoint the game is no longer offered. A phone or a narrow window gets a short page that says what RAID Sandbox is, that it needs a desktop browser, and points to the knowledge base — which stays readable on mobile. The touch shim, the mobile layout and the accordion palette go; the inline picker stays, as click-to-build on desktop. No mobile version is promised. |
| 7 | + |
| 8 | +## Context |
| 9 | + |
| 10 | +The game was built for a wide canvas: drag disks, group them, set the two axes, watch |
| 11 | +the layout animate. Mobile support was added afterwards, in three steps: |
| 12 | + |
| 13 | +- **June 2026** — a responsive pass: the palette wraps and collapses into an accordion |
| 14 | + under 900px, the physical layer folds away, the results panel flows below the canvases. |
| 15 | +- **June 2026** — `touch-dnd.js`, a shim that fakes the HTML5 drag-and-drop events on |
| 16 | + touch (press-and-hold 180 ms, then drag), so the controllers work unchanged. |
| 17 | +- **July 2026** — the mobile flow inverted (PR #1): tapping an empty zone opens an inline |
| 18 | + picker of what fits there, because drag and scroll compete for the same gesture. It |
| 19 | + was validated in the browser by the author and a designer, and shipped. |
| 20 | + |
| 21 | +Two things were never finished. The **physical layer** got no picker: on touch it is |
| 22 | +still the shim, the worst experience in the game |
| 23 | +(`tech-debt/physical-layer-canvas-has-no-touch-picker.md`). And the shim itself was |
| 24 | +flagged the day tap-to-build landed as *"largely redundant, possibly dead code — to |
| 25 | +re-scope"*, and stayed that way for six weeks because nobody could say what to keep. |
| 26 | + |
| 27 | +Meanwhile every change to the interface is designed twice. The two boxes of the |
| 28 | +degenerate-levels work (2026-09-05) were laid out for the wide panel *and* for the |
| 29 | +single-column flow; the information icons and the knowledge-base rework ahead would be |
| 30 | +too. That is the real cost: not the code that exists, but the second target every future |
| 31 | +change has to hit. |
| 32 | + |
| 33 | +The site has no audience yet — it has not been announced anywhere. There is nothing to |
| 34 | +lose by deciding now, and Search Console will say later how many phones ever arrive. |
| 35 | + |
| 36 | +One more thing depends on this. `.claude/rules/overview.md` justifies the vanilla stack |
| 37 | +with *"the bottleneck is interaction (touch gestures), not rendering"*. Without touch, |
| 38 | +that sentence no longer carries the argument, and the stack has to be defended on the |
| 39 | +grounds that were always there too. |
| 40 | + |
| 41 | +## Decision |
| 42 | + |
| 43 | +**RAID Sandbox is a desktop game.** Below the desktop breakpoint (900px, the line the |
| 44 | +layout already used) `index.html` does not offer the canvases. It shows a short page: |
| 45 | + |
| 46 | +- what the game is, in a few lines; |
| 47 | +- that it needs a desktop browser — stated plainly, with no "coming soon" and no |
| 48 | + mention of a mobile version, because none is planned and the project does not print |
| 49 | + promises it cannot keep; |
| 50 | +- a link to the knowledge base. |
| 51 | + |
| 52 | +A shared `#build=` link opened on a phone lands on that page too, not on a broken |
| 53 | +canvas. |
| 54 | + |
| 55 | +**The knowledge base stays readable on mobile.** It is the one page a phone visitor gets, |
| 56 | +and its rework (roadmap item 3) designs for that. |
| 57 | + |
| 58 | +**What goes**: `touch-dnd.js`; `sidebar-accordion.js`; the mobile layout in |
| 59 | +`sandbox.css` (the ≤ 900px flow, the `pointer: coarse` sizing); the physical-layer |
| 60 | +fold-away where it exists only for narrow screens; the `pointer: coarse` and |
| 61 | +`(max-width: 900px)` branches in the controllers. |
| 62 | + |
| 63 | +**What stays**: the inline picker. It was written *touch-first*, but it opens on click, |
| 64 | +and on desktop it is a second way to build — an empty zone offers what fits — next to |
| 65 | +drag-and-drop. It is not mobile code; it is the game's own answer to "what can go here", |
| 66 | +and the information icons will lean on the same idea. |
| 67 | + |
| 68 | +## Rationale |
| 69 | + |
| 70 | +- **One target.** Every interface change from here on is designed once, for the wide |
| 71 | + layout. That halves the cost of the roadmap's next three items. |
| 72 | +- **The mobile game was never whole.** Half of it (the physical layer) ran on a |
| 73 | + press-and-hold shim that fought the scroll. Finishing it meant a second picker and a |
| 74 | + second round of validation for a surface nobody has visited. |
| 75 | +- **Honesty over reach.** A page that says "this needs a desktop" is true. A half-working |
| 76 | + game on a phone teaches the wrong things about RAID and about the project. |
| 77 | +- **Reversible.** The removed code stays in the history (PR #1 and the June commits); |
| 78 | + the notice page is an afternoon. If Search Console ever shows a mobile audience worth |
| 79 | + serving, the decision is one revert and one conversation away. |
| 80 | + |
| 81 | +## Consequences |
| 82 | + |
| 83 | +- **One tech-debt closes by deletion, one is re-scoped.** The `touch-dnd.js` re-scope |
| 84 | + (roadmap item 5) is answered: the shim is gone. `physical-layer-canvas-has-no-touch-picker` |
| 85 | + loses its touch half but not its point — the data layer keeps a click-to-build picker |
| 86 | + and the physical layer has only drag, an asymmetry that matters for the accessibility |
| 87 | + work (item 9); it stays open at low priority under a truer title. |
| 88 | +- **Smaller surface**: two JavaScript files and the mobile section of the stylesheet go; |
| 89 | + the headless suites are untouched (none of this was ever loaded under Node). |
| 90 | +- **A phone visitor loses the game** and gets the knowledge base. Until the site is |
| 91 | + announced, that visitor is the author. |
| 92 | +- **The stack argument is restated** in `overview.md`: no build step and no framework |
| 93 | + because the whole game must travel as one link with zero runtime dependencies, be |
| 94 | + readable as source, and be type-checked without a toolchain — not because of touch. |
| 95 | +- **Accessibility (roadmap item 9) is unaffected**: keyboard and screen-reader paths are |
| 96 | + a desktop concern, and the click-to-build picker is a better base for them than drag. |
| 97 | +- **The knowledge base becomes the mobile front door**, which sets a requirement for its |
| 98 | + rework: readable on a phone, linked from the notice page. |
| 99 | + |
| 100 | +## See also |
| 101 | + |
| 102 | +- `.claude/rules/overview.md` — the stack decision, restated by this ADR. |
| 103 | +- `tech-debt/physical-layer-canvas-has-no-touch-picker.md` — re-scoped by this decision: |
| 104 | + no longer about touch, still about the physical layer having one build path. |
| 105 | +- `.memory-bank/2026-07-24-2135-mobile-tap-to-build-ci-branch-protection.md` (local) — |
| 106 | + the day tap-to-build shipped and the shim was first questioned. |
| 107 | +- [ADR-001](001-engine-identity-not-position.md), [ADR-002](002-the-engine-holds-no-domain-facts.md) — |
| 108 | + unaffected: this decision is about the surface, not the engine. |
0 commit comments