Shared Weapon-Catalog Drift Audit & Architecture Recommendation

The fire-timing display arc (rngMin → rof → TOT) is complete, so we now hand-author per-weapon firing values (rof, layTime, rngMin). The tactical-battle prototype ships as two deliberately separate copies that role-swap the player:

• deployment-plan-first — UK 11th Armoured is the player (data.js); Soviet 2nd Guards is the enemy (enemy-data.js).
• deployment-plan-soviet — Soviet is the player (data.js); UK is the enemy (enemy-data.js).

Inside each copy, data.js declares const weaponSpecificStats = {…} (plus weaponAmmo, weaponShortNames) and enemy-data.js appends the opposing nation's weapons by Object.assign(weaponSpecificStats, {…}) onto that same shared object (top-level consts share lexical scope across classic <script> tags). The net effect: every weapon ends up authored twice — once per copy — and weapons shared by both nations (e.g. Lend-Lease .50 cal/.30 cal, the Bombs air strike, mines, and all command/logistics "weapons") are authored in both player files. Two hand-edited homes for one logical value is a drift risk. This audit measures whether that risk has already materialized.

1. For each of the four files, locate the three table blocks by opener — const NAME = { or Object.assign(NAME, { — and walk to the matching close brace with a string/comment/brace-aware scanner.
2. Tokenize every top-level "key": value pair inside each block. This is required because the enemy-data weaponShortNames blocks pack several pairs per physical line (e.g. soviet/enemy-data.js:184); a naïve line parser under-counts and reports false drift. Each pair records the line its key sits on.
3. Normalize each value by eval → key-sorted canonical string (a value-hash), so key-order differences are not mistaken for drift.
4. Build name → [{file, line, hash}] per table. Classify each name: authored-once (1 file), duplicated-identical (N files, 1 distinct hash), drifted (N files, ≥2 distinct hashes). Cite file:line for every drift.
5. Faction overlay: tag files UK = {first/data, soviet/enemy}, SOV = {first/enemy, soviet/data}. A name in both a UK and a SOV file is cross-nation. Cross-check the two mirror pairs (same faction, opposite copy) for value diffs and coverage gaps.

Value drift is essentially nil. Of 385 shared (multi-file) definitions across the three tables, exactly one disagrees — and it is a cosmetic display label, not a mechanical stat. (397 distinct names total = 385 shared + 12 authored-once.)

Entry counts per file (authoring volume that feeds the duplication burden): weaponSpecificStats — first/data 93, first/enemy 40, soviet/data 62, soviet/enemy 72 (267 authorings for 135 distinct ≈ 2× duplication). The duplication is real and large; the disagreement is not.

"Bombs" is the generic air-strike munition shared by both nations' aircraft. Its firing profile (weaponSpecificStats) is byte-identical across copies; only the cosmetic caliber display string in weaponAmmo disagrees:

Is it a bug? Borderline. The two labels read as deliberate national flavour — British "500 pounds" vs Soviet FAB (фугасная авиабомба). But because "Bombs" is one generic weapon name shared by both decks, the label a player sees depends on which copy they open rather than on the firing unit's nation — the air-strike on a UK enemy aircraft in the Soviet copy would read "FAB". This is exactly the inconsistency a catalog removes. Resolution at extraction (Step 2): either (a) pick one canonical caliber for the shared "Bombs" entry, or (b) if per-nation flavour is wanted, split into nation-specific weapon names ("Typhoon bombs" already exists at first/data:573 with "500 pounds"; a Soviet "FAB bombs" could carry "FAB") and let the generic "Bombs" resolve to one default.

These weapon names appear in both a UK and a SOV table — the true shared surface a catalog would author once. All are duplicated-identical except "Bombs" (§4). 20 cross-nation weaponSpecificStats entries:

Where they live (the asymmetry): all 20 cross-nation entries are authored in the two player files (first/data.js and soviet/data.js) and in neither enemy overlay. That is by design — within a copy, the enemy units reference these generics from the host data.js object that already declared them. So the duplication for generics is "once per copy" (2×), and the "Bombs" drift is the consequence of those two independent hands. weaponShortNames has 22 cross-nation entries (adds Tow gear, Tow hitch, Troop benches, Troop compartment); weaponAmmo has 5 (.30 cal MG, AP/AT mines, Bombs, Quad .50 cal AA).

The two mirror pairs are perfectly value-consistent. Comparing the same faction across copies — UK: first/data vs soviet/enemy; SOV: first/enemy vs soviet/data — yields value-diff = 0 in all three tables for both pairs. Whatever weapon a faction has in one copy, it has with the same values in the other. Good discipline; it also means the byte-shareable surface is essentially the whole table.

Coverage gaps (secondary finding — not value drift). The 12 "authored-once" names are weapons present in only one of the four files. Most are benign (the referencing unit simply does not exist in the mirror copy). Three are minor coverage gaps where a unit references a weapon the file's tables do not define, so the engine falls back to a generic profile/label:

Benign authored-once (referenced only where defined): Mosin-Nagant M91/30 PU and PTRD-41 (both soviet/data.js only; the SOV enemy detachment in the first copy doesn't field them). These three gaps are also dissolved by a shared catalog — a single union table makes "referenced but undefined" impossible. They are flagged here so Step 2 can confirm/clean them; this pass makes no edits.

The data says: drift risk is real structurally (2× hand-authoring) but has produced only one cosmetic disagreement so far. So the choice is between eliminating the duplication (a catalog) and guarding it (a verifier). Three candidates, all offline file://-safe constraints respected (plain <script>, no import/fetch/build step — see memory/prototype-fileurl-constraint.md).

Option A — Shared js/weapon-catalog.js (extract authored-once union) recommended for Step 2

Option B — Keep the Object.assign overlay + add a drift verifier

Option C — Hybrid: extract only the cross-nation set, verifier for the rest