Tactical Vertical-Slice Spec - Omega War
Stage 1 research-scope review · staged cycle: tactical-vertical-slice-spec · page created 2026-06-15
This page starts the tactical vertical-slice spec route recorded by the confirmed
unit-data-schema artifact. It proposes what the Stage-2 spec should decide
before implementation begins: the first playable battle contract, base-building and deck
unlock rules, combat model shape, prototype data needs, AI/save/performance gates, and
explicit deferrals. It does not implement the game, choose durable storage,
add auth/deployment/observability, or author final balance values.
1. Proposed Cycle Summary
Purpose: draft the design specification for Omega War's first playable tactical battle: one fixed tactical slice that proves cover/suppression/capture play, base-building × deck escalation, basic AI, browser performance, mid-battle save/pause, and data-schema usability.
Primary boundary: this is a spec cycle, not a production implementation. Stage 2 should produce decisions, diagrams, rules, prototype acceptance criteria, and fixture-level examples. It should not add final combat stats, production infrastructure, campaign systems, netcode, or a durable content pipeline.
Immediate downstream use: a confirmed spec becomes the build brief for a clickable/playable prototype and the Three.js performance spike.
1.1 Proposed slice promise
- Two fixed first-slice decks: UK/Commonwealth 11th Armoured Division vs Soviet 2nd Guards Tank Army, unless Stage 2 changes the pair.
- One tactical map and one skirmish scenario with capture points, cover, suppression, deployment, and victory conditions.
- Minimal Forward Command Post tree that gates deck bands A/B/C through build-order choices.
- Small fixture set drawn from
research/unthinkable/unit-data-schema.md, with values clearly marked provisional. - Prototype gates for baseline AI, mid-battle save/pause, and browser performance.
Gate - TVSQ1 Scope required
Approve this cycle scope as the Stage-2 tactical vertical-slice spec?
2. Spec Questions
These are the questions Stage 2 will answer. They are listed for scope agreement, not answered here.
| ID | Question | Expected Stage-2 output |
|---|---|---|
| TVS-a | What is the exact first playable battle contract? | Scenario brief, faction/deck pair, map requirements, victory and loss conditions, session length target. |
| TVS-b | How do cover, suppression, capture points, deployment, veterancy, and trait tags interact? | Combat-loop rules, state diagrams, UI-readable feedback requirements, provisional test values. |
| TVS-c | How does base building gate the deck? | Command-post tree, band A/B/C unlock contract, interruption/counterplay rules, resource-shape decision. |
| TVS-d | What data fixtures are required? | Fixture list mapped to Card, Deck, CardRosterEntry, CommandPost, and governance fields. |
| TVS-e | What baseline AI is sufficient for the slice? | AI behaviors, failure tests, and minimum competence criteria. |
| TVS-f | What save/pause and browser resilience is required? | Save-state contract, pause behavior, autosave/visibility-loss rules. |
| TVS-g | What proves browser feasibility? | Performance budget, unit ceiling targets, draw-call/pathfinding stress criteria, fallback decision point. |
| TVS-h | Which systems stay deferred? | Explicit out-of-scope register for campaign map, multiplayer, full balance, final art/audio, economy depth, and production infrastructure. |
Gate - TVSQ2 Deliverable Shape required
What should the Stage-2 packet produce?
3. Approved Inputs
| Source | Use in Stage 2 |
|---|---|
research/unthinkable/idea-brief.md | First vertical-slice premise, browser-first constraint, base building × deck integration, no netcode, basic audio/art constraints. |
research/unthinkable/game-genre-map.md | Must-have/prototype/defer convention split, anti-pattern register, browser scope controls, campaign deferrals. |
research/unthinkable/proposed-divisions-and-decks-roster.md | First deck pair, launch roster, deployment bands, command-post naming, wonder governance. |
research/unthinkable/unit-data-schema.md | Canonical data contract for cards, decks, roster entries, command posts, wonder rules, and deferred values. |
research/unthinkable/arsenal-1945.md | Equipment and plausibility inputs for slice fixtures and what-if caveats. |
research/unthinkable/divisions-1945.md | Formation/To&E guardrails for deck identity and class-weight rationale. |
Gate - TVSQ3 Input Coverage required
Approve these sources as the evidence base for the vertical-slice spec?
4. Slice Boundary and Deferrals
| In Stage 2 | Out of Stage 2 |
|---|---|
| Rules and acceptance criteria for a first playable tactical battle. | Full production implementation or durable content tooling. |
| Provisional fixture examples clearly marked as test values. | Final combat stats, prices, cooldowns, costs, card counts, or final balance. |
| Save/pause contract and browser-performance budget. | Campaign map, auto-resolve, strategic AI, persistence economy beyond hooks. |
| Minimal AI scope and failure criteria. | Multiplayer, netcode, matchmaking, accounts, payments, analytics, deployment. |
| Prototype route and validation checklist. | Final art/audio direction beyond stand-in requirements. |
Gate - TVSQ4 Boundaries required
Accept these in-scope and out-of-scope boundaries for the Stage-2 spec?
5. Outputs, Paths, and Route
| Stage | Path | Purpose |
|---|---|---|
| Stage 2 working packet | research/unthinkable/_working/tactical-vertical-slice-spec.md | Non-canonical vertical-slice spec draft for review. |
| Stage 2 review page | alignment/tactical-vertical-slice-spec-omega-war.html | This page advances in place with the Stage-2 artifact and approval gates. |
| Stage 3 canonical artifact | research/unthinkable/tactical-vertical-slice-spec.md | Approved tactical vertical-slice design spec. |
Gate - TVSQ5 Working Packet Path required
Approve the Stage-2 working packet path?
Gate - TVSQ6 Canonical Path required
Approve the proposed Stage-3 canonical path?
Gate - TVSQ7 Route After Approval required
After a confirmed vertical-slice spec, what should the next route be?
6. Compile Approval YAML
Answer all required gates above, add optional section feedback, then compile and copy the YAML into the next execution message.