Follow

Book VII Product implementation and production

Public edition ·

The Bible states intended game behaviour. Source inspection, historical test reports, current verification and release evidence describe different things. A decision is not implementation; source is not proof of a passing build; a local render is not a deployed release.

Product and platforms

The browser game is the main development line. The Windows desktop edition packages the shared browser game for offline use and local playtesting. Native mobile work has separate source and validation; web parity must not be assumed. Earlier “mobile is a non-goal” statements belong to the original concept, while current mobile scope remains governed by its own implementation and release evidence.

Single-player tactical and operational play is the foundation. Standalone and campaign multiplayer rules are design work; their presence in the Bible does not establish shipped networking. Wider theatres and later-era equipment remain roadmap scope.

Implementation observations at consolidation

SystemObserved source or reportCurrent interpretation
Helmstedt boardsrc/data/campaigns/operational.ts13×9 schematic board, eight half-day turns; Brunswick is off-board.
Operational outcomesrc/campaign/rules.tsFinal landmark-VP comparison still exists; the new objective/result contract is not fully implemented here.
Finite establishmentssrc/data/campaigns/helmstedtForces.ts and helmstedtForcesV2.tsv3 establishment and preserved legacy stock; no free migration top-up.
Deckssrc/data/decks.ts45 AP and current category validation exist; values are tuning.
Refitsrc/campaign/refit.tsPolitical Points and finite survivor/refit rules exist; not a campaign victory score.
Movementsrc/campaign/movement.tsAP, supply, hostile control and route checks exist; enlarged-map scale needs validation.
Tactical systemsTransport, towing, urban, fieldwork, doctrine and intelligence reportsHistorical implementation evidence; no new full-game regression run in this consolidation.
CinematicsConcurrent campaignIntros, narration, assets and film/map UI workWorking-tree production is preserved; it must reconcile against current Bible canon and result guards.
Ending prototypeArchived campaign-continuity reviewSeven fixtures passed in that review; it is not runtime linked-campaign implementation.
Other campaign dossiersReviewed map and roster proposalsPlanned content, not proof that all five strategic campaigns are playable.

Concurrent runtime/UI changes were left untouched during consolidation. Exact source paths and hashes in the evidence inventory describe the inspected state, not a commit or release claim.

Feature production contract

Each unit or feature needs its rule, data, model/animation, crew behaviour, weapon/ammunition, sound, interface, persistence and relevant tests to agree. Initial card integration does not complete an equipment family. Missing cards and national-release gates should reject materialisation rather than silently substituting another unit.

Use tests appropriate to the change. The repository’s quick suite is not the full release gate; full seeded battles and campaign continuation are required before shipping the relevant game changes. Platform-specific checks, hardware performance and visual/audio acceptance remain separate. Do not repeat unrelated tests merely to inflate a validation claim.

Maintain source attribution and licences. Keep state changes atomic. A failed save cannot consume a purchase or corrupt the current world. Preserve unrelated work and inspect changes before committing; the repository’s Git conventions still apply.

Source of truth and exports

Edit docs/game-bible/ for game vision, lore, campaigns, rules, feature intent, presentation and roadmap decisions. Its books and structured registers form one framework. The private website is generated from these files; it is not a second editable canon.

The reading-view exporter is build-bible.py in the existing omega-campaign-storyboards-20261029 Site project. It reads this Bible directly, generates book/register pages and preserves the frozen archive. check-bible.cjs verifies navigation, search, archive access and responsive layout. Exported bible-export.json records source hashes.

Runtime data remains the executable configuration. When implementing a Bible decision, update the relevant source and tests, then amend the implementation observation/status. When source and intended design disagree, retain the discrepancy here until resolved rather than silently redefining the design from code.

Operational manuals for building, publishing, testing, recording and platform validation remain live technical companions. They do not decide game canon. Historical review packets, test results, citations and deployment receipts remain archival evidence.

Maintenance workflow

  1. Read the affected book and register before making a change.
  2. Amend the existing rule or passage in place. Identify owner-approved direction, proposal, historical fact or implementation observation precisely.
  3. Update dependent books, roster identities, scripts and open items together; remove superseded active wording.
  4. Record a concise entry in the single change history, linking the affected sections and evidence.
  5. Export the private reading view and production inputs from the Bible; validate links and affected behaviour.
  6. Keep receipts and research evidence in the archive/evidence layer. Do not create another accumulating “decisions revision” outside the Bible.

A user request authorises its ordinary reversible updates; this process does not add a new approval ritual. Proposals remain proposals until adopted. The archive cannot override a later owner decision or a corrected current passage.

Current delivery

The Bible replaces the scattered review pages as the private reading entry point. Earlier pages and packets are retained with archive status and stable compatibility links. Consolidation changes documentation and its reading view only; it does not deploy the game or certify concurrent cinematic work.