UX Variations — Tactical Battle
Five UX progression branches for the first playable tactical battle, Breakthrough at Helmstedt. Alignment date: 2026-06-15. Status: review. Product path: unthinkable.
Review Status
This page renders the full UX-variations plan and interview log for review. It proposes progression branches only — no prototype, UI spec, or implementation is created here. No live concept-selection interview occurred this turn, so the page is amendable: answer the gates or send section feedback before any branch routes to $ui-interview.
prototype tierproduct-designfile:// safeno external dependenciesprogression-path mode (not layout-mode)
Rendered deliverables: design/unthinkable/ux-variations-tactical-battle.md, design/unthinkable/ux-variations-tactical-battle-interview.md, and design/unthinkable/flow-tree-tactical-battle.yaml.
Table of Contents
Scope
This packet expands the tactical vertical-slice flow into five alternate UX progression branches. The goal is to compare how a player enters, understands, advances through, recovers within, and completes the first playable battle before a single branch moves to $ui-interview.
No prototype, UI spec, implementation plan, production art, campaign map, deck builder, multiplayer, analytics backend, or final combat balance is created by this packet.
Source Evidence
| Source | Use in this packet |
|---|---|
research/.progress.yaml | Product-path mode; unthinkable is active and scoped to research/unthinkable/. |
research/unthinkable/tactical-vertical-slice-spec.md | Parent battle contract, tactical loop, command-post surfaces, tactical UI contract, deferrals, and acceptance checklist. |
research/unthinkable/proposed-divisions-and-decks-roster.md | UK 11th Armoured vs Soviet 2nd Guards Tank Army slice pairing, deck band vocabulary, wonder-slot menu, and command-post framing. |
research/unthinkable/game-prototype-test.md | Prototype task sequence, playtest script, observation checklist, and validation questions. |
research/unthinkable/game-audience.md | Primary campaign-wargamer segment, secondary deck/division tactician segment, onboarding risks, browser wedge risk, SP-first AI/save expectations. |
research/unthinkable/game-fantasy.md | Theater-commander fantasy, deck-as-identity promise, Central Germany first-front commitment, and no-voiced-narrator presentation constraint. |
Confirmed Assumptions Manifest
These assumptions are confirmed for this evidence-synthesis pass by the current implementation request and the approved upstream artifacts.
| Area | Assumption | Evidence tag |
|---|---|---|
| Product context | The product path is unthinkable; all new design outputs belong under design/unthinkable/. | [from spec] |
| Parent flow | The selected user flow is the first playable tactical battle for Breakthrough at Helmstedt. | [from spec] |
| Player role | The player commands UK/Commonwealth 11th Armoured Division against Soviet 2nd Guards Tank Army AI. | [from spec] |
| Primary job | The player must deploy Band A, scout/capture, build command-post surfaces, unlock Band B/C, and resolve the battle. | [from spec] |
| Activation event | The first "aha" is understanding that the deck is authored before battle, while command-post build order decides when that identity arrives. | [from research] |
| Repeat-use workflow | Replay desire should come from trying a different build order, preserving units better, or countering the AI differently. | [from research] |
| Progression variables | Entry, tutorial pressure, information density, deck visibility, command-post sequencing, recovery, save drills, AI pressure, and completion framing may vary. | [inferred] |
| Fixed constraints | Scenario, factions, one fixed map, five capture points, Band A/B/C vocabulary, command-post band unlocks, one wonder per side, save/pause/restart requirements, and prototype scope are fixed. | [from spec] |
| Open decisions | How much guidance vs operator density vs map-first play vs deck doctrine vs resilience practice the first battle should emphasize remains open. | [inferred] |
| Evaluation method | Compare branches by task-based prototype review and UAT; product-testing is not enabled, so install it before $uat --variant-evaluation. | [from codebase] |
Required Gate: Assumptions
Are these confirmed assumptions correct for the variation work?
Parent Flow
The parent flow remains bounded to one browser-first tactical skirmish:
- Open the fixed scenario.
- Read the objective and starting deck identity.
- Deploy Band A Vanguard units from a Forward Command Post.
- Scout cover lanes, resource points, and the central command point.
- Capture territory while reading cover, suppression, and AI pressure.
- Choose and build command-post surfaces that open Band B Frontline/Main Body support.
- Preserve units, contest the center, and respond to AI escalation.
- Complete the Advance Command Post to open Band C Breakthrough/Commitment options.
- Trigger or counter one telegraphed wonder event.
- Win, lose, restart, or save/reload through interruption.
Fixed vs Variable Scope
Fixed
- Tactical battle title: Breakthrough at Helmstedt.
- UK 11th Armoured playable side and Soviet 2nd Guards Tank Army AI side.
- Five capture points: two player-side, two AI-side, one central command point.
- Band labels: Recon/Vanguard, Frontline/Main Body, Breakthrough/Commitment.
- Command-post surfaces and Advance Command Post gating.
- Cover, suppression, capture, wonder, AI, save/pause, and browser feasibility contracts.
- Canonical first prototype remains small, fixture-backed, and single-player.
Variable
- Entry framing and first five minutes.
- Amount and timing of tutorial guidance.
- Whether the deck, map, command-post chain, or recovery loop is the dominant first-screen mental model.
- Step granularity and automation.
- How the player sees prerequisites, objectives, AI pressure, and abandoned/recovery states.
- Spatial density, navigation, copy tone, and branch-specific visual hierarchy for later
$ui-interview.
Required Gate: Fixed vs Variable Scope
Is this fixed-versus-variable boundary correct for branching the flow?
Variation Concepts
| ID | Label | Thesis | Archetype | Best fit | Main tradeoff | Complexity |
|---|---|---|---|---|---|---|
guided-battle-drill | Guided Battle Drill | Teach the fused loop as a battle drill: each phase introduces one mechanic only when the battlefield needs it. | Guided step-by-step flow | New RTS/wargame players and first-time browser trial users | Strong clarity but risks feeling scripted or less replayable. | Medium |
commanders-tactical-console | Commander's Tactical Console | Treat the battle as an operator console where capture, deck availability, command-post state, and AI pressure are always visible. | Data-dense operator console | WARNO/SD2 power users and deck/division tacticians | High agency but risks overwhelming onboarding. | High |
map-first-operational-battle | Map-First Operational Battle | Make the map and objectives lead the experience; deck and command posts appear as battlefield consequences. | Visual canvas / objective-first workflow | Campaign wargamers who care about spatial command | Strong theater feel but risks hiding the deck × command-post claim. | Medium |
deck-doctrine-first | Deck Doctrine First | Put the 11th Armoured deck identity up front and make command-post construction feel like executing doctrine. | Onboarding-first activation path | Deck tacticians and players evaluating the hybrid's novelty | Directly tests the riskiest deck × base-building claim but may feel abstract before combat pressure. | Medium |
resilient-skirmish-loop | Resilient Skirmish Loop | Frame the battle as a recoverable tactical exercise: save, pause, fallback, rebuild, and counter-escalate are first-class progression beats. | Recovery/status-driven workflow | SP campaign players who punish brittle sessions and dumb AI | Validates trust and browser resilience but may under-sell spectacle. | Medium |
Required Gate: Concept Selection
How should I adjust these UX variants before they move toward UI work? (Pre-build narrowing is discouraged — all five are kept unless you direct otherwise.)
Variation Specs
1. Guided Battle Drill
Design thesis: The first battle should behave like a competent field instructor: reveal only the next tactical job, then remove scaffolding as the player proves comprehension.
Target user fit: Players new to the deck/base hybrid, browser trial users, and campaign players who need confidence before systems depth.
Parent-flow relationship: Same battle contract, but progression is segmented into drill cards: deploy, scout, capture, build, counter, commit, finish.
Flow changes
- Scenario opens on a concise operation order with three visible goals: secure near points, establish the command chain, break the Soviet push.
- Band A deployment is constrained to a small first set until the player issues the first scout/capture orders.
- Cover and suppression prompts appear only when a relevant unit is threatened.
- First command-post surface is recommended, not forced.
- Band B unlock produces a short deck-arrival moment naming what changed.
- Save/reload drill appears as an optional checkpoint after first escalation.
- Band C and wonder prerequisites unlock as a final battle drill.
Onboarding and activation model: Activation happens when the player builds a surface and sees the deck roster change immediately, with a short "Main Body now available" confirmation.
Typical workflow sequence: Read drill objective, act on map, receive focused feedback, unlock the next phase, repeat until the late commitment.
Sharing, collaboration, permissions: None in-slice; shareable output is a post-battle summary showing completed drills and the decisive moment.
Return-use and notification model: Restart offers "try without drill prompts" after one completion.
Failure recovery: If a player loses a command post or gets pinned, the drill switches to a recovery task: retreat, rebuild, counterattack.
Navigation model: Linear drill rail plus map hot spots.
Screen-by-screen layout direction: Operation order panel, contextual drill card, tactical map, compact deck tray, command-post progress strip, post-battle drill report.
Key components and controls: Next objective card, minimize guidance, replay hint, recommended build marker, save checkpoint button, restart scenario.
Button and link behavior: Primary button focuses the next drill target; secondary button dismisses guidance for the current phase; restart returns to scenario start.
Density and hierarchy: Low-to-medium density; map remains primary, guidance is prominent but collapsible.
Responsive behavior: Desktop-first; on narrower screens, drill cards collapse into a bottom sheet and the deck tray becomes segmented tabs.
Visual tone: Training-map clarity, annotated but not playful.
Strengths: Fastest route to first comprehension, strong onboarding, good for browser trial.
Risks: Can make the tactical battle feel solved; power users may resent staged reveals.
Implementation complexity: Medium, mostly stateful tutorial triggers and contextual copy.
Prototype first: First seven minutes through Band B unlock with three drill prompts and one recovery prompt.
Ready-for-ui signal: User can explain cover, capture, and command-post unlock without saying the game played itself.
2. Commander's Tactical Console
Design thesis: The first battle should trust the player as an operator and surface every important system: resources, command posts, deck bands, capture pressure, AI tempo, and save state.
Target user fit: Deck/division tacticians, WARNO/Steel Division veterans, and players who prefer dense tactical feedback.
Parent-flow relationship: Same flow, but the player can freely choose sequence from the start. The UX adds observability rather than guidance.
Flow changes
- Scenario opens directly into a command dashboard over the map.
- Deck roster shows all bands with locked prerequisites visible.
- Command-post queue, damage, unlocks, and resource deltas remain persistent.
- AI pressure appears as contact reports and objective pressure, not hidden AI state.
- Save/pause status is always visible in the system strip.
- Post-battle report emphasizes build timings, capture control, and unit preservation.
Onboarding and activation model: Activation occurs when the player sees the complete deck plan and intentionally chooses an escalation path.
Typical workflow sequence: Scan dashboard, issue map orders, inspect deck locks, choose build surface, monitor AI pressure, time late commitment.
Sharing, collaboration, permissions: No collaboration; exportable battle log or screenshot-friendly after-action table.
Return-use and notification model: Return loop is "beat your timing": restart with prior build-order metrics visible.
Failure recovery: Alerts escalate from watch to warning to critical for pinned units, damaged command posts, and command-score drain.
Navigation model: Persistent tactical console with tabs for Deck, Command, Objectives, Log.
Screen-by-screen layout direction: Full map center, left deck/command rail, top resource/status bar, right objective/intel rail, bottom selected-unit inspector.
Key components and controls: Sortable deck list, prerequisite checklist, build queue, alert log, pause/save/reload controls, filters.
Button and link behavior: Command buttons issue orders or focus map entities; locked items open prerequisite detail; log items pan camera to source.
Density and hierarchy: High density; compact typography, tables, icon-backed status chips.
Responsive behavior: Desktop-only for evaluation; tablet collapses one rail; mobile is out of scope except read-only after-action review.
Visual tone: Military operations room, utilitarian and restrained.
Strengths: Best branch for expert agency and system legibility.
Risks: Highest onboarding cliff; may validate power-user desire while failing broader first-session clarity.
Implementation complexity: High because it needs synchronized status surfaces.
Prototype first: Opening through first Band B build with persistent deck prerequisites and command-post state.
Ready-for-ui signal: User praises control and can act faster without losing tactical cause/effect.
3. Map-First Operational Battle
Design thesis: The battlefield should teach the system. Objectives, terrain, and enemy movement lead; deck and command-post UI appears when the map creates the need.
Target user fit: Campaign wargamers and tactical players who need spatial stakes before abstract deck logic.
Parent-flow relationship: Same battle, but entry begins with the map situation rather than deck doctrine.
Flow changes
- Scenario opens on the Helmstedt map with front-line annotations and objective clusters.
- The player receives a map-based opening task: secure the road junction and recon both flanks.
- Deck tray stays compact until the player selects a command-post or deploy zone.
- Command-post build sites are visible terrain objects with construction radius and vulnerability.
- AI escalation is communicated through map reports: dust columns, artillery markers, recon sightings.
- Band C late commitment is presented as a battlefield breakthrough, not a menu milestone.
Onboarding and activation model: Activation happens when the player sees that building a command post at a contested location changes the map and roster at once.
Typical workflow sequence: Read terrain, choose lane, capture, build where the map permits, react to spotted AI pressure, commit late support.
Sharing, collaboration, permissions: Shareable artifact is a post-battle map snapshot with capture swings and breakthrough route.
Return-use and notification model: Restart focuses alternate lane plans: center rush, flank economy, conservative build.
Failure recovery: Lost territory triggers fallback lines and rebuild site suggestions rather than abstract alerts.
Navigation model: Map-first, with contextual overlays and minimal permanent chrome.
Screen-by-screen layout direction: Large tactical map; overlays for capture ownership, cover, line of fire, build radii; collapsible lower deck tray; right-side situational messages.
Key components and controls: Overlay toggles, map objective cards, build-site markers, recon/contact pings, after-action heat map.
Button and link behavior: Overlay toggles persist per session; objective cards pan to map; build markers open command-post choices.
Density and hierarchy: Medium density; terrain, objectives, and unit positions dominate.
Responsive behavior: Desktop uses overlay controls; tablet moves overlays into a bottom drawer; mobile only for future spectator/review.
Visual tone: Living operational diorama with restrained military cartography.
Strengths: Best at selling the war-map fantasy inside a battle.
Risks: Deck × command-post novelty can become secondary or under-explained.
Implementation complexity: Medium, weighted toward map overlays and battlefield markers.
Prototype first: First five minutes with objective overlays, capture clusters, and contextual build-site reveal.
Ready-for-ui signal: User talks about terrain and command-post placement as strategic choices, while still noticing deck unlocks.
4. Deck Doctrine First recommended next $ui-interview
Design thesis: The first battle should make the player understand "my deck is my doctrine" before the first shot, then let command-post construction execute that doctrine under pressure.
Target user fit: Deck/division tacticians, theorycrafters, and players judging whether the deck × command-post hybrid is actually distinctive.
Parent-flow relationship: Same battle, but the pre-battle and opening frame centers on UK 11th Armoured doctrine, visible locked bands, and chosen escalation intent.
Flow changes
- Scenario opens with a doctrine card for 11th Armoured: recon screens, Comet timing, artillery observers, RAF cab-rank finish.
- The deck is displayed as three bands with clear command-post gates.
- The player chooses an opening doctrine emphasis: Recon Screen, Early Assembly, or Fast Motor Pool.
- The map starts immediately after the choice, with the chosen emphasis reflected in suggested first objectives.
- Command-post completion animates a doctrine step rather than a generic tech unlock.
- Late wonder checklist is visible from the start but clearly unreachable until the Advance Command Post and battlefield control.
Onboarding and activation model: Activation happens before battle when the player can predict how command-post choices will make Comets, observers, and air support arrive.
Typical workflow sequence: Inspect doctrine, select opening emphasis, fight for prerequisites, unlock bands, execute the planned late commitment or adapt.
Sharing, collaboration, permissions: Shareable artifact is an after-action doctrine comparison: intended path vs actual battle path.
Return-use and notification model: Restart prompts "try the other doctrine opening" with prior timings.
Failure recovery: If the player falls behind, the doctrine panel offers adaptation paths: stabilize with Assembly Area, contest center with artillery, or rebuild command chain.
Navigation model: Deck/doctrine hub into tactical map; in-battle doctrine panel remains accessible.
Screen-by-screen layout direction: Pre-battle doctrine overview, band ladder, command-post dependency diagram, tactical map with doctrine progress side panel, after-action path comparison.
Key components and controls: Doctrine cards, band ladder, prerequisite checklist, opening-emphasis selector, command-post dependency diagram, after-action timeline.
Button and link behavior: Opening selector starts the battle with different hints only, not different final content; locked cards reveal prerequisite surfaces; doctrine timeline jumps to battle events.
Density and hierarchy: Medium density; deck identity gets the first read, map takes over after start.
Responsive behavior: Desktop uses a side-by-side doctrine and map transition; tablet stacks; mobile defers the pre-battle doctrine review to a full-screen step.
Visual tone: Staff briefing plus armored-division identity; precise, confident, and readable.
Strengths: Directly tests the riskiest product claim: deck identity authored before battle, executed through command posts in battle.
Risks: If too abstract, first-time players may feel they are reading a build guide instead of entering a fight.
Implementation complexity: Medium; requires pre-battle state, dependency diagrams, and after-action path logging.
Prototype first: Doctrine overview into first command-post choice and Band B unlock.
Ready-for-ui signal: User can name the 11th Armoured plan, explain why a command post changed the deck, and wants to replay with another doctrine opening.
5. Resilient Skirmish Loop
Design thesis: The first battle should prove that a browser tactical session can be trusted: pause, save, reload, fallback, rebuild, and recover are part of the combat loop rather than utility afterthoughts.
Target user fit: SP campaign wargamers who punish missing saves, brittle sessions, and unfair AI; browser skeptics.
Parent-flow relationship: Same battle, with explicit recovery and interruption beats inserted into progression.
Flow changes
- Scenario opens with a compact readiness panel: objective, save status, pause availability, restart path.
- First combat phase introduces retreat, pinning recovery, and fallback lines.
- First command-post build includes visible vulnerability and repair/rebuild affordances.
- Mid-battle asks the player to perform a save/reload confidence drill.
- AI pressure is tuned to create one recoverable setback before Band C.
- Post-battle report includes resilience outcomes: reload success, command-post recovery, units saved, comeback path.
Onboarding and activation model: Activation happens when the player survives a setback and sees state restore/recovery work reliably.
Typical workflow sequence: Fight, get pressured, pause/save/reload or retreat, rebuild command chain, counter-escalate, finish.
Sharing, collaboration, permissions: Shareable artifact is a comeback/recovery after-action log.
Return-use and notification model: Resume battle is a primary entry next to restart; autosave status is explicit.
Failure recovery: This branch makes recovery the centerpiece: pinned units, damaged posts, lost points, and bad saves all have visible routes.
Navigation model: Tactical map with persistent resilience/status strip and recovery prompts.
Screen-by-screen layout direction: Readiness panel, tactical map, save/pause strip, recovery objective cards, reload confirmation, after-action resilience report.
Key components and controls: Pause, manual save, autosave indicator, reload, restart, fallback objective, repair/rebuild command, recovery warnings.
Button and link behavior: Save writes current state; reload confirms state timestamp; restart requires confirmation; recovery prompts pan to fallback or repair target.
Density and hierarchy: Medium-low density; status trust and recovery states are highly visible.
Responsive behavior: Desktop and tablet supported; mobile remains a future spectator/resume review only.
Visual tone: Calm command reliability under pressure.
Strengths: Best branch for validating browser-first trust, SP-first expectations, and interruption resilience.
Risks: May feel procedural if the setback is too artificial or if recovery interrupts tactical momentum.
Implementation complexity: Medium; depends on save-state fidelity and recovery-state instrumentation.
Prototype first: Opening through first setback, manual save, reload, and command-post recovery.
Ready-for-ui signal: User trusts the session enough to experiment and says recovery made the battle more replayable, not more tedious.
Decision Criteria
| Criterion | Why it matters | Strong signal | Non-acceptance signal |
|---|---|---|---|
| Deck × command-post legibility | Core product claim. | Player can explain how build choices unlock deck identity. | Player calls bands a hidden timer or base clutter. |
| Tactical readability | First battle must stand alone. | Player reads cover, suppression, capture, and unit roles. | Player sees visual noise or cannot explain outcomes. |
| Agency without overwhelm | Must serve both campaign wargamers and deck tacticians. | Player makes intentional build/order choices. | Player either follows prompts passively or freezes under density. |
| Replay desire | Campaign context is deferred; battle must carry itself. | Player wants another build order, lane, or recovery attempt. | Player says scenario is solved or only interesting with rewards. |
| Browser trust | Browser-first is a wedge and risk. | Player trusts save, pause, reload, and performance. | Player doubts session durability or loses state confidence. |
| UI branch viability | Next step is $ui-interview. | Branch has clear screens, controls, state model, and evaluation task. | Branch cannot be mocked without inventing missing product scope. |
Experiment Plan & UAT Handoff
Cheapest useful validation is one lightweight clickable or static-plus-interactive prototype per variation, then task-based comparison. Since .agents/project.json does not enable product-testing, install it before running $uat --variant-evaluation:
npx skillpacks install product-testing
Variant Tasks
| Variation | Target task | Evidence to capture |
|---|---|---|
| Guided Battle Drill | Complete opening deployment, capture, first command-post build, and Band B unlock using drill prompts. | Time to comprehension, prompt dismissals, confusion notes, whether player feels guided or constrained. |
| Commander's Tactical Console | Choose a build path and respond to AI pressure using persistent status surfaces. | Scan behavior, misread alerts, useful/ignored panels, perceived control. |
| Map-First Operational Battle | Secure an objective lane and place/build a command post from map context. | Map readability, terrain/objective decisions, whether deck unlocks remain noticed. |
| Deck Doctrine First | Inspect doctrine, choose opening emphasis, then execute the first unlock. | Recall of deck identity, predicted vs actual command-post effect, replay interest. |
| Resilient Skirmish Loop | Recover from a setback, save/reload, rebuild or repair, then counter-escalate. | Trust in browser session, recovery clarity, interruption confidence. |
Side-by-Side Questions
- Which branch made you understand the deck × command-post relationship fastest?
- Which branch made the battlefield feel most alive?
- Which branch made you feel most in command?
- Which branch would you replay first?
- Which branch would make you stop playing?
- Which branch is clearest enough to move into
$ui-interview?
Readiness Criteria for Consolidation
- Every built branch has screenshots or a recorded walkthrough.
- Each branch has at least one completed task note set.
- Non-acceptance signals are recorded, not smoothed over.
- A winning direction is selected only after review evidence or explicit user judgment.
$consolidate-variationswaits until UAT evidence exists or the user explicitly confirms they have reviewed the variants and is ready to converge.
Required Gate: Evaluation Method
Is build-each-variant then $uat --variant-evaluation (after installing product-testing) the right comparison method?
Branch Routing
Parent user-flow branch: tactical-battle.
| Branch ID | Label | Status | Routing note |
|---|---|---|---|
guided-battle-drill | Guided Battle Drill | planned | Good first mockup if onboarding clarity is the immediate concern. |
commanders-tactical-console | Commander's Tactical Console | planned | Good first mockup if expert control and dense system observability are the concern. |
map-first-operational-battle | Map-First Operational Battle | planned | Good first mockup if battlefield fantasy and terrain-led progression are the concern. |
deck-doctrine-first | Deck Doctrine First | planned | Recommended next $ui-interview branch because it most directly tests the slice's riskiest deck × command-post legibility claim. |
resilient-skirmish-loop | Resilient Skirmish Loop | planned | Good first mockup if browser trust and save/recovery are the concern. |
Recommended next branch for $ui-interview: deck-doctrine-first.
Do not route directly to implementation from this packet. The selected branch still needs a $ui-interview HTML visual mockup, alignment review, and explicit branch decision.
Required Gate: Post-Approval Route
After this variation packet is accepted, which branch should route to $ui-interview first?
Coverage Checkpoint
- Parent tactical flow: covered.
- Five contrasting progression branches: covered.
- Fixed-vs-variable scope: covered.
- Deck, command-post, capture, AI, save/pause, and wonder implications: covered.
- Decision criteria: covered.
- UAT handoff and product-testing install note: covered.
- Scoped flow-tree manifest destination:
design/unthinkable/flow-tree-tactical-battle.yaml. - Alignment review page destination:
alignment/ux-variations-tactical-battle.html. - Open risk: no live concept-selection interview occurred in this turn; the alignment page must be treated as review-state and amendable before downstream branch work.
Required Gate: Coverage Checkpoint
Are any decision criteria, risks, validation steps, or constraints missing before this is treated as the variation baseline?
Interactive Flow Preview
Ephemeral preview only. This is a review aid for the shared parent battle flow that every branch reshapes, not production code.
Interview Log
Full render of design/unthinkable/ux-variations-tactical-battle-interview.md.
1. Product-Path Selection
Selected product path: unthinkable. Basis:
research/.progress.yamllistsunthinkableas an active path.- The provided plan explicitly targets
research/unthinkable/. - The parent tactical vertical-slice artifact is
research/unthinkable/tactical-vertical-slice-spec.md.
Design outputs are therefore scoped to design/unthinkable/.
2. Source Files Read
| File | Reason |
|---|---|
.codex/skills/ux-variations/SKILL.md | Skill process, deliverable contract, flow-tree requirement, alignment-page requirement. |
.codex/skills/ux-variations/ALIGNMENT-PAGE.md | Review-state HTML gates, feedback controls, response YAML compiler, index update, TTS script, dark styling. |
.codex/skills/ui-interview/SKILL.md | Downstream branch-review route and guardrails. |
.agents/project.json | Enabled packs; confirmed product-testing is not installed. |
research/.progress.yaml | Product-path resolution. |
research/unthinkable/tactical-vertical-slice-spec.md | Parent tactical battle contract and UI requirements. |
research/unthinkable/proposed-divisions-and-decks-roster.md | Deck/band/wonder/command-post terminology. |
research/unthinkable/game-prototype-test.md | Prototype validation tasks and observation criteria. |
research/unthinkable/game-audience.md | Player segments and risk register. |
research/unthinkable/game-fantasy.md | Player fantasy and Central Germany positioning. |
alignment/index.html | Central alignment-index structure and existing category organization. |
3. Assumptions Confirmation
The current user task explicitly asked to implement a previous agent's plan in a fresh context. No new live interview questions were asked. The assumptions below were treated as confirmed for a review-state evidence-synthesis deliverable:
- Topic slug:
tactical-battle. - Product path:
unthinkable. - Parent flow: first playable tactical battle from the tactical vertical-slice spec.
- Scenario: Breakthrough at Helmstedt.
- Variation mode: default progression-path UX variations, not layout-mode.
- Output count: five variations.
- Required branch labels: Guided Battle Drill, Commander's Tactical Console, Map-First Operational Battle, Deck Doctrine First, Resilient Skirmish Loop.
- Recommended
$ui-interviewbranch:deck-doctrine-first. - No web research needed.
- No prototype or UI spec created in this step.
design/flow-tree.schema.jsondoes not exist, so create only the scoped flow-tree YAML using the skill contract.product-testingis not enabled, so UAT routing should mention installing it before$uat --variant-evaluation.
4. Concept Set Confirmation
The concept set was retained exactly from the plan. Rationale:
| Concept | Retained because |
|---|---|
| Guided Battle Drill | Tests first-session clarity and guided progression. |
| Commander's Tactical Console | Tests expert agency and dense status surfaces. |
| Map-First Operational Battle | Tests map-led operational fantasy and terrain-first progression. |
| Deck Doctrine First | Tests the riskiest deck × command-post legibility claim directly. |
| Resilient Skirmish Loop | Tests browser trust, save/reload, recovery, and SP-first expectations. |
No concept was removed or merged because the UX-variation skill discourages pre-build narrowing.
5. Coverage Checkpoint
Covered
- Parent battle flow.
- Fixed-vs-variable scope.
- Five branch concepts and buildable branch specs.
- Evaluation criteria.
- UAT handoff checklist.
- Branch routing and recommended next
$ui-interviewbranch. - Scoped flow-tree manifest.
- Review-state alignment page and index entry.
Not covered
- Live concept-selection Q&A.
- HTML visual mockups for individual branches.
- UI branch approval/rejection.
- Prototype implementation or UAT evidence.
6. Final Retained Decisions
| Decision | Result |
|---|---|
| Product path | unthinkable |
| Parent flow ID | tactical-battle |
| Variation branch count | Five |
| Branch states | planned |
Recommended branch for $ui-interview | deck-doctrine-first |
| Canonical design packet | design/unthinkable/ux-variations-tactical-battle.md |
| Interview log | design/unthinkable/ux-variations-tactical-battle-interview.md |
| Flow tree | design/unthinkable/flow-tree-tactical-battle.yaml |
| Alignment page | alignment/ux-variations-tactical-battle.html |
7. Next Review Action
Review the alignment page and provide either section-feedback YAML or bottom compiled response YAML. Downstream branch work should wait until the review-state variation packet is accepted or revised.
Output & Route Gates
The variation plan, interview log, and flow-tree manifest already exist on disk in review state. These gates approve their destinations and the downstream mutation scope.
Required Gate: Artifact Destination
Approve the design-packet, interview-log, flow-tree, and alignment-page destinations?
Required Gate: Proposed File Changes
Approve the allowed file set: the three design/unthinkable/ deliverables, this alignment page, and the alignment/index.html entry — and nothing else?
Compile Responses
Answer any gate or select section feedback, then compile YAML. Partial responses are allowed and remain revision requests until every required gate is answered with no unresolved negative feedback.