Slice 17.5: Playable browser game (InteractiveActionSource + game content)

[Jamerrone]

What to build

Build the playable browser game on top of Slice 17. The player can place, sell, and upgrade Towers; drag rally points; override targeting strategies; and send waves manually. Player input is buffered into a new InteractiveActionSource that implements the same ActionSource interface Slice 17 introduces — so the loop, renderers, and engine are unchanged.

The game has its own content directory (e.g. demos/game/data/, one map is fine for this slice) with zero overlap with demos/shared-data/, which is consumed by tests and the CLI/replay demos. Gameplay tuning must not destabilise tests.

The game records the player's actions into a transcript that can be exported (JSON download). This closes the bug-report loop: a player encountering a bug can hit "export transcript", attach it to an issue, and the maintainer replays it deterministically via the transcript-replay browser demo from Slice 17, loaded with the game's content set.

UX decisions to pin in grilling:

• Tower picker pattern (sidebar palette vs click-to-cycle vs tile-context-menu)
• Upgrade tree visualization (DAG of prerequisites + exclusiveGroup labels)
• Rally-point drag affordance (per ADR-0010 / Guard plugin)
• Targeting / attack-selection strategy controls per Tower
• Wave-send button placement and feedback for WaveTrigger.kind === "manual" vs "hybrid"
• Placement preview UX (PlacementMode validation feedback before commit)
• Error feedback for failed PlayerAction dispatches per ADR-0014
• Entry flow: default route is the game; replay demo is a secondary route (/replay) used for bug-repro
• Project layout: one Vite project with two HTML entries (recommended) vs two Vite projects
• Script naming: consistent and clear about what each script produces (game / replay / CLI). Derived from the project-layout decision.

Acceptance criteria

• A grilling session (/grill-with-docs) is run on this issue before implementation to pin the UX decisions above. The decisions are posted as an Agent Brief comment, after which the issue moves from ready-for-human to ready-for-agent.
• An InteractiveActionSource class implements the ActionSource interface introduced in Slice 17. It buffers PlayerAction values produced from DOM input handlers and dispenses them on the next tick boundary via actionsForTick(tickIndex).
• The full built-in PlayerAction set is wired: placeTower, sellTower, purchaseUpgrade, moveRallyPoint, overrideTargeting, sendNextWave.
• No engine or BrowserDemoLoop changes are required — only new UI / renderer additions and the new ActionSource.
• The game ships its own content directory, separate from demos/shared-data/. Tests and the CLI demo continue to consume shared-data/ unchanged.
• package.json scripts are renamed so each script's name makes clear what artifact it produces (game vs replay browser demo vs CLI transcript demo). Specific names pinned in grilling alongside the project-layout decision.
• The playable game and the transcript replay demo coexist — either as routes within one Vite project, or as separate Vite projects. Pinned in grilling.
• Recorded player input can be exported as a transcript.json matching the shape used by the CLI demo and Slice 17.
• An exported transcript loaded into the replay demo produces the same outcome on replay (closes the bug-report loop end-to-end). Replay loads from whichever content directory the transcript was recorded against.
• All ADR-0014 ActionResult feedback (ok: true, effect / ok: false, code, message, hint) is surfaced to the player in the HUD.
• Headless test covers a minimal interactive flow (e.g., place one Tower via simulated click, dispatch one wave, assert state changes) — proves the input path works end-to-end without needing a human.
• No regressions on tests from earlier slices.

Blocked by

• Bug: Enemy with attacks array breaks the CLI demo #55 — the Enemy attacks bug must be fixed before interactive play.
• Slice 17: Browser reference demo + reference Renderer #18 — Slice 17 must ship the ActionSource interface, BrowserDemoLoop, the three Renderer classes, and the Vite build setup this slice extends.

[Jamerrone]

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Make the browser project playable — add InteractiveActionSource, a gameplay UI, and a separate game content set — while the Slice 17 transcript replay coexists at /replay.

Current behavior:
The browser Vite project ships a single HTML entry that auto-loads a transcript and replays it via TranscriptActionSource over BrowserDemoLoop. Three Renderer instances (Canvas 2D gameplay, DOM HUD, stub audio per ADR-0020) render the playback. The CLI demo produces transcripts. Tests, the CLI demo, and the replay all share demos/shared-data/ as their ConfigRegistry source — touching that content risks breaking tests.

Desired behavior:

The browser Vite project hosts two HTML entries: the playable game at / and the existing transcript replay debugger at /replay. Renderers, BrowserDemoLoop, and the ActionSource interface are shared. A new InteractiveActionSource implements the existing ActionSource contract by buffering PlayerAction values produced from DOM event handlers and dispensing them at the next tick boundary.

The game uses a content directory separate from shared-data/ (see ADR-0021). The Vite content plugin emits both bundles; the game fetches its own, the replay debugger fetches both so it can resolve any transcript's scenario id against either content set.

The game's Scenario uses WaveTrigger.kind === \"manual\" so the player has unmetered build-up time before each Wave.

/ opens in a menu state showing a Scenario picker; clicking a card transitions to playing state. Win/Loss banners offer Play again and Back to menu.

Interaction state machine (canvas + HUD):

Three modes — Idle, Build (palette entry armed), Inspect (placed Tower selected).

• Clicking a placed Tower always transitions to Inspect on that Tower. Overrides Build, replaces any prior selection, interrupts rally placement on a Guard Tower.
• Clicking a palette entry enters Build with that archetype.
• ESC returns to Idle.
• Clicking an empty (non-Tower) tile dispatches contextually:
  • In Build → attempts placeTower; the player remains armed after a successful place for rapid placement.
  • In Inspect on a non-Guard Tower → deselects.
  • In Inspect on a Guard Tower → attempts moveRallyPoint; the player remains in Inspect on the same Tower.

Guards and Enemies are not selectable. Hovering them reveals range circles but does not select.

Tower palette (Build picker):

DOM sidebar in the HUD column listing every placeable Tower archetype with meta.symbol / meta.name + cost. Disabled style when gold < cost. Clicking arms; the canvas cursor renders a translucent ghost.

Inspect details panel:

DOM panel in the HUD column, replacing the palette while a Tower is selected. Contains:

• Tower name + canvas position
• Attack summary (range, cooldown per Attack)
• sellTower button, labelled with the refund amount derived from the sell-value RewardKind
• TargetingStrategy dropdown with all five built-in strategies (closest-to-base, closest, lowest-hp, highest-hp, tag-priority). For tag-priority, a sub-picker provides an ordered list of tag names with drag-to-reorder + add (against tags discovered in the registry's Enemies) + remove. Selection dispatches overrideTargeting with either the canonical string shorthand (parameterless strategies) or a full TargetingStrategyConfig object (tag-priority requires priority: string[]).
• UpgradeTree as tiered cards grouped by Upgrade.tier. Each card: name (meta.name), cost, one-line ops summary, status badge — ○ available, ✓ purchased, 🔒 locked. Locked tooltip cites the unmet prerequisite Upgrade id or the conflicting exclusiveGroup label. Clicking an available card dispatches purchaseUpgrade.
• No explicit rally button — the canvas state machine handles moveRallyPoint directly when a Guard Tower is selected.

HUD chrome (top-to-bottom):

• Gold (live, via goldChanged)
• Base HP (live, via baseDamaged)
• Wave N of M
• Palette or details panel (mutex)
• Send-wave button (bottom): Send wave N between waves; disabled Wave N spawning… while active; hidden after the last wave. Dispatches sendNextWave.
• Persistent Export-transcript button: serialises the recorded (tickIndex, PlayerAction) pairs into the existing TranscriptFile shape and triggers a browser download.
• Transient failure toast (~3s) above the Send button rendering ActionResult.code + message + hint. New toasts replace the current.

Rendering specifications (GameplayRenderer, Canvas 2D per ADR-0020):

Tile tinting:

• Build → at minimum, the cursor tile is tinted green or red per the active Map's PlacementMode validate function (looked up from the placementModes registry entry by the Map's PlacementMode kind).
• Rally placement (Guard Tower in Inspect) → all tiles within summon.rallyPointRange that pass the ADR-0011 Rally Point eligibility rule (not Base / BlockedRegion / tower-occupied; on a placeable tile or a Path tile) are tinted green; ineligible tiles inside the range are tinted red.

Range circles — one per Attack, multi-Attack entities render every circle:

• Build → for each of the armed Tower's Attacks, centred on the cursor.
• Inspect → for each of the selected Tower's Attacks.
• Hover on a placed Tower → for its Attacks.
• Hover on an Enemy → for its attacks (anti-Guard).
• Hover on a Guard → for the Guard's Attacks.

Guard-specific overlays (only while the parent Guard Tower is in Inspect):

• Rally-point placement radius — circle of radius summon.rallyPointRange centred on the Tower.
• Each active Guard's Engagement zone — circle of radius summon.engagementRange centred on the Guard's Rally Point (per ADR-0010).
• The Rally Point marker.

/replay (transcript debugger):

Existing Slice 17 semantics plus a source selector with two modes — the default Slice 17 transcript or a user-supplied .json loaded via <input type=\"file\">. Both content bundles fetched at load time; the transcript's scenario id resolves against whichever bundle has it. No new playback controls (play / pause / scrub) in scope — only the file picker is added.

Scripts:

package.json scripts flatten to dev / build / preview operating on the Vite project, plus demo:cli for the CLI transcript producer. The previous *:browser namespacing is removed; the top-level dev/build/preview aggregators are removed (single child each). test:e2e replaces the prior test:browser; test:unit and test:types are unchanged.

Key interfaces:

• ActionSource (existing) — actionsForTick(tickIndex): readonly PlayerAction[]. InteractiveActionSource implements it by maintaining a tick-keyed buffer; DOM handlers push, the loop drains before each engine.tick.
• PlayerAction (existing) — all six built-in kinds wired: placeTower, sellTower, purchaseUpgrade, moveRallyPoint, overrideTargeting, sendNextWave. Each dispatched via engine.dispatch(action) per ADR-0014.
• ActionResult (existing) — every { ok: false, code, message, hint? } shape surfaces in the HUD failure toast.
• TargetingStrategyConfig (existing) — overrideTargeting.strategy accepts either a string shorthand or the full discriminator-object form; tag-priority requires priority: string[].
• TranscriptFile (existing CLI demo shape) — exported transcripts conform exactly so they replay through /replay byte-identically.
• BrowserDemoLoop (existing) — unchanged. Already iterates actionsForTick(tickIndex) before each tick.
• Vite content plugin (existing sharedDataPlugin) — extended to walk a second content directory and emit a second JSON asset alongside the existing one. Both served by the dev middleware and the production build.

Acceptance criteria:

• InteractiveActionSource implements ActionSource and feeds engine.dispatch via the existing BrowserDemoLoop. No BrowserDemoLoop, engine, or PlayerAction interface changes.
• All six built-in PlayerAction kinds dispatchable from the UI: placeTower, sellTower, purchaseUpgrade, moveRallyPoint, overrideTargeting, sendNextWave.
• The Vite project hosts two HTML entries — game at /, replay at /replay — built and served by one Vite config.
• A second content directory exists alongside demos/shared-data/, seeded as a verbatim copy of shared-data/ at ship time, with the Scenario's waveTrigger overridden to { \"kind\": \"manual\" }. Tests, the CLI demo, and the default /replay source still consume shared-data/ unchanged.
• The Vite content plugin emits two JSON content bundles to both the dev server and the production build. The game entry fetches its own; /replay fetches both.
• package.json scripts are flattened to dev / build / preview (Vite) and demo:cli (CLI producer). *:browser namespacing removed.
• / opens in a menu state listing Scenarios from the game's content set; selecting a card transitions to active gameplay; Win/Loss banners offer Play again and Back to menu.
• The interaction state machine matches the rules above. Clicking a placed Tower always selects it. ESC returns to Idle. Empty-tile clicks dispatch contextually. Guards and Enemies are not selectable.
• The Build palette lists every Tower with cost; disabled when gold < cost. Clicking arms; the canvas renders a translucent ghost of the armed Tower at the cursor.
• The Inspect details panel shows the selected Tower's name, attack summary, sell button (with refund), TargetingStrategy dropdown with all five built-ins and a tag-priority sub-picker, and a tiered UpgradeTree card list with status badges and locked-state tooltips.
• Selecting a TargetingStrategy dispatches overrideTargeting with the canonical shape; tag-priority includes priority: string[] from the picker.
• Purchasing an Upgrade card dispatches purchaseUpgrade; locked states correctly reflect prerequisite and exclusiveGroup constraints.
• Clicking eligible tinted tiles while in Inspect on a Guard Tower dispatches moveRallyPoint.
• During Build, the cursor tile is tinted green or red per the active PlacementMode. During rally placement, tiles within rallyPointRange are tinted per the ADR-0011 Rally Point eligibility rule.
• The GameplayRenderer draws range circles per Attack for: the armed Tower (Build), the selected Tower (Inspect), and any hovered Tower / Enemy / Guard. While a Guard Tower is in Inspect, the rally-point placement radius, each active Guard's Engagement zone, and the Rally Point marker are also drawn.
• The Send-wave button shows Send wave N between waves, Wave N spawning… (disabled) while active, and is hidden after the last wave.
• The Export-transcript button serialises recorded actions into a TranscriptFile matching the existing shape and triggers a browser download.
• Failed ActionResults surface as transient (~3s) toasts above the Send button.
• /replay accepts the default Slice 17 transcript or a user-supplied transcript via file picker. Both content bundles fetched on load; the transcript's scenario resolves against whichever bundle has it. An exported game transcript loaded back into /replay reproduces the recorded play byte-identically per ADR-0017.
• A headless test drives InteractiveActionSource end-to-end: places one Tower via simulated input, dispatches one Wave, asserts on resulting world state. No human interaction required.
• CONTEXT.md's TargetingStrategy entry lists all five built-in strategies (corrected during grilling — closest was previously undocumented).
• ADR-0021 documents the game-data / shared-data separation and the two-bundle emission.
• No regressions on tests from earlier slices.

Out of scope:

• Engine API changes (no new PlayerAction kinds, no read-only "can place" predicates — the UI calls the PlacementMode registry entry's validate function directly for preview).
• BrowserDemoLoop changes.
• AttackSelectionStrategy player overrides (no built-in PlayerAction supports it; would require a new engine surface).
• New /replay playback controls (play / pause / scrub). The file picker is the only addition.
• Audio backend. The Slice 17 stub AudioRenderer is kept as-is.
• Responsive / mobile layout. The existing fixed-canvas + HUD column is kept.
• Authoring new game content beyond seeding the copy and overriding the Scenario's WaveTrigger.