docs/PHASE0-PLAN.md:
- Lab topology mirroring production 1:1 - two minimum-shape sites
(console + 2 cockpits) + hub, hub-and-spoke WireGuard over a
host-only "WAN" net with netem as the simulated internet.
- Lab IP conventions (strawman seat map; flagged for alignment with
real bay numbering before Phase 1).
- VM inventory: full 9-VM set and a 5-VM minimum-viable start.
- VM management recommendations: VMware Workstation Pro 17 (free
personal; host is Win11 Home so no Hyper-V) for the first pass,
Proxmox VE on a spare box as the persistent lab / future hub
staging; gold images + linked clones, snapshot-per-experiment
discipline, config-as-code under lab/, one-knob netem sweep script.
- Experiments E1-E9 with pass criteria mapped to the brainstorm's
open questions: routed fabric + console RPC over WAN, broadcast
locality, FS directed join + port matrix, latency cliff table,
WAN-drop behavior, MTU, BT411 cross-subnet egg push, hub host +
stream rehearsal, event-day dry run (SiteConfigMerge gate).
- Risks: MW4-in-VM rendering (physical-host fallback), vPOD fidelity
limits, firewall discipline.
Linked from BRAINSTORM Phase 0 and the README contents table.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Per operator: under the SiteLink IP plan there should never be
GUID/MAC/IP conflicts. Reframed the merge checks accordingly - they
are tripwires for plan drift (un-renumbered site) or stale inventory
(same pod recorded in two site files), not expected events. The merge
now exits 3 when any warning fired (master still written) so event-day
scripts can gate on a clean merge; 0 = clean, 1 = usage, 2 = hard
error. Verified: same-file-twice merge exits 3, clean merge exits 0.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
New: tools/SiteConfigMerge (net48 console app)
- dump: decode any .siteconfig (squads, pods, IPs, MACs, host types)
- merge: combine <siteName>.siteconfig inputs into master.siteconfig,
renaming squads "<siteName>-<original squad name>"
- Pod records pass through byte-for-byte; only squad records (the
rename) are re-serialized, under the TeslaConsole assembly identity
captured from the input. Stand-in types + SerializationBinder, so no
build dependency on TeslaSuite.
- Warns on duplicate pod GUID/MAC and cross-site IP overlap.
- Verified end-to-end: the real TeslaConsole.exe 4.11.4.1 loaded the
merged master via its own Site.LoadFromFile (reflection harness).
Doc updates from operator decisions:
- Operating model settled: sites voluntarily hand console authority to
the central console for the duration of a SiteLink event, by
contributing their siteconfig. Federation ruled out at current scale.
- Siteconfig "secrets" framing corrected: pod keys have no practical
value outside the air-gapped bay; files are exchanged per event and
never stored in this repo (tools only).
- Fleet scale recorded: 6 active pod bays, <120 cockpits in existence;
bay sizes range console+2 cockpits up to the full 20-node complement.
Open question 9 answered.
- Hub hosting direction: neutral Firestorm host at the WireGuard hub;
the FS server usually IS the Live Cam, so stream its output to all
sites and optionally to the public internet. Mission Review instance
runs at the hub too - one authoritative debrief streamed everywhere.
- Virtual PDF scoresheet printer at the hub: event debriefings print
centrally, retrievable from any site on the link.
- Voice (Mumble) backburnered - revisit only on event interest.
- .gitignore: build outputs; siteconfig exclusion rationale reworded.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- BOOTP was never actually implemented anywhere despite header
mentions: removed it as a design consideration (pod addressing is
static config); left a one-line "never implemented, don't design
against it" note so it doesn't creep back in.
- No cockpit title has an attract mode - the games were never deployed
as walk-up public arcade machines (Firestorm had unfinished plans
for one). Corrected the TeslaRel410 deployment-goal wording.
- PQS reclassified from core bay component to support tooling: it is
the operator's own event traffic-flow tool, not standard bay
infrastructure. Kept as the natural seed for future cross-site
queue/roster coordination (brainstorm shared-services table + open
question reworded accordingly).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Ecosystem doc: new section on the TeslaRel410 project — custom
DOSBox-X fork HLE-emulating the Division VPX board to run the
original, unmodified Tesla 4.10 BattleTech/Red Planet DOS binaries
on current Windows 10 pod hardware (RIO COM1 / plasma COM2
passthrough). Networking facts for SiteLink: WATTCP (real TCP/IP)
via NetNub over emulated NE2000 bridged by pcap -> routable in
principle; BOOTP is broadcast -> site-local provisioning.
- Clarified BT411 and RP411 as the two native Win32 Tesla 4.10
reconstructions (per operator), complementary to the emulation path.
- Brainstorm: new game-linking subsection for the emulated originals +
open question 11 (NetNub cross-subnet addressing, 30 Hz sim latency
tolerance).
- CTCL naming note: provenance question is out with VWE veterans.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Searched the firestorm tree for an authoritative expansion of "CTCL" and
found none. Replaced the guessed "cafe/Tesla control layer" wording with
the attested facts (Console 2 Launcher message comments, _ECTCL_Console/
_ECTCL_Launcher roles, Tesla-centric coin-op API) and flagged the reading
"Console-Tesla Control Layer" as inference. New facts from the dig: CTCL
is game-agnostic (_EAT_MW4/_EAT_RP) and has its own ports 1000/1001,
added to the port map.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5