games/fort-nash: collapse duplicate minigame-host arms

games/fort-nash: collapse duplicate minigame-host arms

#34 in Riparion/riparion-retro — merged 2026-06-12

Summary

Follow-up to #33. The generic minigame host (ui/screens/minigame.rs) matched (Mode, MinigameParams) with three byte-identical CrowdThreading arms (fog/flee/climb) and two identical TimingBar arms (splint/dose) that differed only in which resolve_* the result fed. This collapses each group into one arm that renders the shared component and picks the resolver by the live mode — removing ~60 lines of copy-paste so adding a prop to either component is now a single edit.

Safe by construction: every resolver guards on its own mode (resolve_fog returns unless mode == Fog, etc.), so a mis-routed result is a no-op that visibly fails to advance rather than silently applying the wrong toll.

Why a separate PR

This is pure UI dispatch with no golden-trace coverage (the oracle snapshots engine state, not rendered props or callback wiring), so I kept it out of the correctness-focused #33 and verified it live instead.

Test plan

  • cargo test -p fort-nash — 53 pass, golden trace unchanged; clippy clean; cargo check --target wasm32-unknown-unknown OK.

  • Playwright drive of all five modes (inject a save per mode → resume → complete the minigame → assert it advanced off the mode):

    Mode Rendered Advanced to
    Fog Interaction
    Flee Shoot (botched escape → gunfight)
    Climb Brigade (blizzard)
    Splint Interaction
    Dose Interaction

    The distinct destinations confirm each mode's own resolver fires — a single mis-wired resolver would make all three Crowd modes advance identically.

Version: fort-nash 0.1.6→0.1.7.

🤖 Generated with Claude Code

Last updated 2026-06-13