Decklist Rules Alignment - Omega War

must Model army organizations before decks

Agents must not treat a deck as the full faction or division card pool. The larger historical force is an army organization; a deck is a player-usable subset built from that organization; a decklist is a specific user-created or provided deck configuration.

• Organization display nouns may be division, army, brigade, regiment, or another nationality-appropriate formation term.
• Deck display nouns should usually be smaller tactical formations, such as battalion, or the nationality-appropriate equivalent.
• Fixed scenario deck fixtures are allowed, but they should still be framed as subsets of the larger organization.
• Future campaign prototypes may use many created decks, prebuilt fixed decks, or one persistent deck.

must Preserve a later deck-builder path

The deployment-plan-first prototype can remain a fixed scenario deck, but it must not block a later deck-builder experience.

• The deck-builder screen should mirror the deployment prototype roster as a full-width screen.
• A later build-order creation screen should mirror the deployment prototype build-order panel as its own full-width screen.
• Decks are built from units available in an army organization. Build orders are authored from a selected deck.
• Computer-controlled allied forces may use their own battalions operating along the front.

must Use clear unit terminology

A card represents one deployable unit instance in the tactical battle, not a deck by itself.

• A unit can be an infantry section, tank, aircraft, vehicle, gun team, artillery piece, logistics vehicle, utility vehicle, structure, or wonder candidate.
• unit type means the rendering and rules class that drives stats and selection rows, such as infantry, vehicle, tank, gun-team, aircraft, or structure.
• type of unit means the selected loadout, transport, passenger, or other configuration for a unit.
• CardRosterEntry is not approved player-facing language. Treat it as an implementation/schema name that may need a clearer production name.

must Use Phase A/B/C in deck building and deployment planning

Stored values may remain A, B, and C, but deck-building and deployment-plan UI should label them as Phase A, Phase B, and Phase C.

Only labels should be player-facing. Explanations of why labels raise tension belong in documentation.

must Use dynamic tactical late-phase labels

In the tactical battle, Phase C should display as battle-state language rather than a static "Commitment" label.

• Use [Nationality] Breakthrough when one side has a severe advantage.
• Use [Nationality] Commitment when one side has a narrow or moderate advantage.
• Use Stalemate when both sides are tied.
• The labels should create pressure to push an advantage, break a stalemate, or reverse fortune without visible explanatory text.

must Gate unit availability through facilities

Availability is gated through command-post and facility surfaces, not through a deck object by itself.

• A motor pool or tank park supports vehicle and tank deployment.
• An air liaison plus an airfield supports aircraft deployment.
• Artillery batteries, fire direction centers, supply dumps, workshops, and command posts support their corresponding unit families.
• A locked unit must name or derive the facility surface that unlocks it. The facility unlocks unit availability; it does not imply deck editing.

must Support selectable veterancy

Deck building must support selected veterancy in the WARNO / Steel Division style.

• Use the current labels green, trained, and experienced.
• Veterancy raises unit quality in exchange for increased cost.
• Phase availability may constrain veterancy; Phase B and Phase C cards may have better veterancy access than equivalent earlier cards.
• Phase A can still offer experienced units with a battle-weary trait that suppresses some veterancy benefit until later phases.

must Allow zero or one active wonder candidate

Wonder cards are Phase C units. A playable deck may have no wonder if the player chooses not to include one, but it may have no more than one active wonder candidate.

• Fixture audits should distinguish active wonder candidates from locked future/stretch candidates.
• Any active wonder candidate must be Phase C.
• Wonder candidates remain gated by late command-post, facility, resource, and battlefield-state requirements.
• What-if, captured, rare, or premise-loaded wonder candidates need explicit framing and should not become default content by accident.

must Use one primary category per unit

A unit must not appear in multiple category tabs. Category is the primary roster tab, such as INF, REC, VEH, ARMOR, AT, ARTY, AA, AIR, SUPP, BLDG, or WONDER.

• The same unit may appear in multiple phases.
• Each phase's entry may have a different loadout, transport, passenger, or other configuration.
• Transport does not move an infantry or gun unit into the VEH tab.
• Deployable logistics and utility vehicles remain ordinary cards in their own primary category.
• Logistics cards are support/vehicle cards, not infantry or gun transport choices. A v1 logistics card carries one resource kind (munitions or fuel) plus cargo charges.

must Preserve transport and organic-crew boundaries

• Transport is a configuration or companion relationship.
• Organic-crew vehicles are units, not transports.
• Tanks, vehicles, aircraft, self-propelled anti-air, self-propelled artillery, support vehicles, and utility vehicles belong in their own primary category when they are deployed as units.
• Non-self-propelled artillery and guns that require towing must have a tow configuration.
• If there is no plausible non-towed version, the required tow is effectively part of the unit's baseline deployment cost.
• Vehicle, tank, aircraft, and support-transport display stats should be sourced real-world facts. Use cost, count, phase placement, facility gates, unlocks, and availability to balance vehicle cards instead of changing historical speed, armor, range/Fuel, health, or ammo.

should Add requisition points for deck building

Deck building should introduce a requisition-points system analogous to activation-points systems in WARNO, Steel Division 2, and Wargame.

• Category slots in a deck count against a total requisition-points budget.
• Exact slot costs are balance values.
• Requisition points are a tuning lever alongside unit cost, count, phase, veterancy, and facility gating.

must Keep card faces terse and structured

Roster tiles and decklist cards must show only compact, scannable metadata.

• Allowed on card face: cost, category/type chips, count, name, one short keyword, and compact structured hints.
• Terse logistics hints such as Resource: Fuel or Resource: Munitions are allowed when drawn from structured fields.
• Forbidden on card face: prose summaries, usage advice, flavor paragraphs, multi-clause explanations, and long transport details.
• Logistics cargo counts and restoration rules belong in detail surfaces, not card faces.
• Longer prose belongs in reference/documentation surfaces such as a future Omegapedia-style unit details page, or in internal documentation.
• Enemy deck cards follow the same card-face convention as player cards.

should Treat traits as mechanical tokens

Traits are mechanical tokens, not restatements of visible weapons or unit labels.

• Avoid traits such as Bren group when the weapon row already shows a Bren.
• Use general mechanical language such as shock, anti-tank specialization, or combined arms.
• Trait examples should describe effects such as close-range damage, reduced suppression, improved anti-armor performance, target tracking, or artillery/air accuracy.
• Exact magnitudes remain balance values.

must Keep enemy deck inspection read-only

Enemy deck inspection may use the same category, phase, card-face, and popover conventions as the player roster, but it must remain read-only unless a future feature explicitly changes that.

• No add mode.
• No deck editing.
• No build-order queue controls.
• No save/export actions.

should Use single-source fixture data and derived roster views

Fixture data should be authored once and rendered into derived views for the UI. The prototype's "roster maps" are derived roster views: category to phase to unit cards.

• Use the phrase "derived roster views" in future docs unless referring to a specific implementation type.
• Do not hand-edit derived roster views when a source unit table owns the data.
• Current prototype source tables are GAME_DATA.units for the player fixture and ENEMY_UNITS for the enemy fixture.
• Companion-only transport/passenger rows are not roster cards and should be excluded from roster derivation.

must Attach build orders to decks

A build order is attached to a deck. Import/export must encode deck identity because a build order can become invalid when applied to a different deck.

• Build-order validation must reject incompatible formats, scenarios, deck identifiers, units, transport values, passenger values, loadout values, configuration values, and malformed phase data.
• Configuration values must be rejected on units that do not support them.
• If card names change, provide explicit aliases or migration notes.

defer Do not invent final balance during rule alignment

This ruleset governs structure and audit quality. It does not approve final balance.

• Deferred unless a task explicitly asks for tuning: final card counts, exact costs, requisition point budgets, slot prices, command-post build times, resource thresholds, damage, cooldowns, trait magnitudes, phase timings, era unlock cadence, and final wonder effects.
• Prototype values may exist for testing, but agents must mark them as provisional and keep them separate from canonical schema rules.