Unit Data Schema — Topic 06: Command-Post & Wonder-Slot Governance — Omega War

Stage 2 · per-topic review · topic 06 of 6 · cycle unit-data-schema · page created 2026-06-15 · approved 2026-06-15

alignment_status: review — topic 06 approved, read-only — Stage 2 of 3, final per-topic research review before synthesis.
This page reviews topic 06 only: command-post unlock governance, deck-level status rules, the strict one-wonder-slot constraint, and anti-rush prerequisite shapes. It compiles from research/unthinkable/_working/unit-data-schema/06-cp-and-wonder-slot.md.

Boundary (UD-A1): shape, not values. This topic assigns no command-post costs, build times, cooldowns, resource amounts, objective thresholds, damage values, warning durations, or balance magnitudes.

Topic-06 approval (read-only) — compiled YAML consumed 2026-06-15; missing_required: [], section_feedback: []. All four schema gates are approved, and the route approves topic 06 and proceeds to synthesis of research/unthinkable/unit-data-schema.md.

Gate	Answer
`command-post-governance`	`approve-command-post-governance`
`deck-governance`	`approve-deck-governance`
`wonder-slot-rule`	`approve-wonder-slot-rule`
`anti-rush-prereqs`	`approve-anti-rush-prereqs`
`route`	`proceed-synthesis` (approve topic 06; synthesize canonical schema)

Verbatim compiled YAML (frozen):

artifact: alignment/unit-data-schema-06-cp-and-wonder-slot-omega-war.html
cycle: unit-data-schema
topic: 06-cp-and-wonder-slot
stage: stage-2-topic-review
compiled_at: 2026-06-15T17:19:57.668Z
missing_required: []
gates:
  - qid: command-post-governance
    section: "CommandPost Governance"
    gate: "command-post-governance"
    answer: "approve-command-post-governance"
    notes: ""
  - qid: deck-governance
    section: "Deck Governance"
    gate: "deck-governance"
    answer: "approve-deck-governance"
    notes: ""
  - qid: wonder-slot-rule
    section: "Wonder Slot Rule"
    gate: "wonder-slot-rule"
    answer: "approve-wonder-slot-rule"
    notes: ""
  - qid: anti-rush-prereqs
    section: "Anti-Rush Prerequisites"
    gate: "anti-rush-prereqs"
    answer: "approve-anti-rush-prereqs"
    notes: ""
  - qid: route
    section: "Route & Open-Question Disposition"
    gate: "route"
    answer: "proceed-synthesis"
    notes: ""
section_feedback:
  []

Topic-05 hand-off (read-only) — topic 05 approved the Division, ToeProfile, and DivisionDeckMapping shape, then routed here with proceed-topic-06. Topic 06 governs playable-deck status, the single Band-C wonder slot, and the anti-rush surfaces that prevent wonder cards from becoming openers.

1. Purpose & scope of this topic

Section feedback notes

Author the final governance layer before synthesis. A playable deck must state its status, expose a command-post unlock structure, and carry exactly one late, named, documented wonder candidate with anti-rush prerequisites.

Object	Role
`DeckGovernance`	Deck status, zone policy, playable-deck invariant holder.
`CommandPost`	Band and scope unlock surface; no costs or timings.
`WonderSlotRule`	The strict single late slot for a playable deck.
`WonderPrerequisite`	Typed anti-rush gates and counterplay surfaces.

2. `CommandPost` governance

Section feedback notes

Field	Type	Req?	Notes
`id`	string	required	Stable key such as `advance_command_post`.
`display_name`	string	required	Player-facing facility name.
`unlocks_band`	enum `DeploymentBand`	required	The deck-side band this surface opens.
`unlock_scope`	enum `UnlockScope`	required	`infantry`, `armor`, `artillery`, `air`, `logistics`, `strategic`, `wonder`.
`prerequisite_surfaces`	ref `CommandPost`[]	optional	Shape-only dependency list; no build-order values.
`interruptible`	bool	optional	Counterplay eligibility; no disruption values.

Gate — command-post-governance required

Does the CommandPost governance shape correctly express unlock surfaces without adding economy values?

Approve the command-post governance shape Revise command-post governance (note fields or constraints) Hold — do not proceed yet Other / None of the above Need clarification

Additional notes (optional; required if Other)

3. `DeckGovernance` — status and invariants

Section feedback notes

Field	Type	Req?	Notes
`deck`	ref `Deck`	required	The governed topic-04 deck.
`status`	enum `DeckStatus`	required	`slice`, `base`, `conditional_base`, `expansion_backlog`, `attachment_only`, `flavor_only`, `reject`.
`requires_wonder_slot`	bool	required	True for playable decks.
`zone_policy`	enum `ZonePolicy`	required	How baseline/stretch/what-if cards may appear.
`framing_required`	bool	optional	Required for morally loaded premise rows.

Gate — deck-governance required

Does DeckGovernance capture deck status, zone policy, and playable-deck invariant ownership?

Approve the deck governance shape Revise deck governance (note fields or constraints) Hold — do not proceed yet Other / None of the above Need clarification

Additional notes (optional; required if Other)

4. `WonderSlotRule` — strict single late slot

Section feedback notes

Two late gates. Arsenal §4B says Phase-C only. In the synthesis model this means card.phase_band = C and CardRosterEntry.deployment_band = C, then anti-rush prerequisites still have to pass.

Field	Type	Req?	Notes
`deck`	ref `Deck`	required	The playable deck being checked.
`roster_entry`	ref `CardRosterEntry`	required	The one entry where `wonder_eligible = true`.
`required_phase_band`	enum `PhaseBand`	required	Always `C` for first synthesis.
`required_deployment_band`	enum `DeploymentBand`	required	Always `C` for first synthesis.
`required_zone`	enum `PlausibilityZone`	required	Baseline / stretch / what-if zone.
`named_documented_artifact`	bool	required	True for every wonder candidate.
`source_caveat`	string	required	Visible caveat for stretch, what-if, captured, or premise rows.

Gate — wonder-slot-rule required

Does the wonder-slot rule correctly encode exactly one named, documented, late slot per playable deck?

Approve the wonder-slot rule Revise the rule (note invariant or field changes) Hold — do not proceed yet Other / None of the above Need clarification

Additional notes (optional; required if Other)

5. `WonderPrerequisite` — anti-rush gate shape

Section feedback notes

Field	Type	Req?	Notes
`wonder_rule`	ref `WonderSlotRule`	required	The wonder slot rule being gated.
`kind`	enum `WonderPrerequisiteKind`	required	`command_post_infrastructure`, `resource_commitment`, `visible_warning`, `battlefield_control`, `campaign_progress`, `combat_performance`, `source_framing`, `one_use_or_cooldown`.
`target_ref`	string/ref	optional	Related surface, objective, campaign event, recon state, or source record.
`telegraph_required`	bool	optional	Whether visible warning is required.
`counterplay_channel`	enum `CounterplayChannel`	optional	Coarse counterplay surface; no strength values.

Gate — anti-rush-prereqs required

Does WonderPrerequisite capture anti-rush and counterplay shape without tuning values?

Approve anti-rush prerequisite shape Revise prerequisites (note fields or required gates) Hold — do not proceed yet Other / None of the above Need clarification

Additional notes (optional; required if Other)

6. Illustrative governance rows (shape demonstration only)

Section feedback notes

Deck	Wonder candidate shape	Required gates	Reading
`us_2nd_armored`	`super_pershing` as Band-C roster entry	Advance CP; resource commitment; visible warning; named artifact caveat	Clean identity option if rare and expensive later; no numbers here.
`uk_11th_armoured`	`centurion_trial_troop` or `tortoise_detachment`	Band C; stretch/source caveat; command-post infrastructure; counterplay telegraph	Stretch candidate must stay visibly flagged.
`soviet_2nd_guards_tank_army`	`is3_guards_shock_group`	Band C; campaign/era eligibility; visible warning; battlefield-control or campaign-progress gate	Legible late shock option, not an opener.
`rearmed_german_kampfgruppe`	`maus_recovery` or `v_weapon_strike`	What-if toggle; framing note; source caveat; explicit counterplay channel	Counterfactual and morally loaded rows require extra disclosure.

7. Open questions & route

Section feedback notes

open Storage placement — separate DeckGovernance table vs fields on Deck.
open Prerequisite encoding — polymorphic target_ref vs typed nullable refs.
open Automated invariant validation — whether synthesis should emit a machine-checkable exactly-one assertion.
open Conditional-base handling — which conditional statuses count as playable during a campaign branch.

Gate — route required

How should the cycle proceed? This also disposes the §7 open questions (they carry to synthesis unless you direct otherwise in notes).

Approve topic 06 and proceed to synthesis of research/unthinkable/unit-data-schema.md Revise topic 06 first (note what) Hold — do not proceed yet Other / None of the above Need clarification

Additional notes (optional; required if Other)

8. Deferred-values register (this topic)

Section feedback notes

Deferred	Why	Where it lands
Command-post costs, build times, numeric prerequisites	Economy/balance values	prototype balance / tactical vertical-slice spec
Wonder activation costs, cooldowns, damage, radius, duration	Combat/balance values	prototype balance pass
Exact objective-control, recon, veterancy, or campaign thresholds	Tuning and scenario design	campaign/economy pass
Final wonder identity per deck	Content selection	deck-content pass
Counterplay strength and warning duration	Balance and UX	playtest/balance pass

9. Source log (topic 06)

Section feedback notes

proposed-divisions-and-decks-roster §6.1 / §6.3 — Band C and wonder option menu with anti-rush examples.
proposed-divisions-and-decks-roster §7.1 / §7.2 — command-post naming and unlock mapping.
proposed-divisions-and-decks-roster §8 / RDQ6 — deck status, card-class zone, strict wonder slot, and framing-note rules.
arsenal-1945 §4B — adopted zone dial and Option C wonder-slot framework.
Topics 03, 04, and 05 — phase band, deployment band, roster entry, command post, and division mapping contracts.

10. Compile Responses

Answer the required gates above, add optional section feedback, then compile and copy the YAML into the next execution message. You may compile partial responses.

Unit Data Schema — Topic 06: Command-Post & Wonder-Slot Governance — Omega War

1. Purpose & scope of this topic

2. CommandPost governance

Gate — command-post-governance required

3. DeckGovernance — status and invariants

Gate — deck-governance required

4. WonderSlotRule — strict single late slot

Gate — wonder-slot-rule required

5. WonderPrerequisite — anti-rush gate shape

Gate — anti-rush-prereqs required

6. Illustrative governance rows (shape demonstration only)

7. Open questions & route

Gate — route required

8. Deferred-values register (this topic)

9. Source log (topic 06)

10. Compile Responses

2. `CommandPost` governance

3. `DeckGovernance` — status and invariants

4. `WonderSlotRule` — strict single late slot

5. `WonderPrerequisite` — anti-rush gate shape