feat: add catalog weapon throughput baseline

docs/DESIGN_SYSTEM.md

@@ -2595,10 +2595,33 @@ anchor scrolling and sticky-state transitions.
 #### Builder calculation modes
 
 The current Builder and shared Build pages do not expose calculation modes or
-combat assumptions. They show deterministic equipped-item totals and reserve
-conditional Talent outcomes, weapon and Skill DPS, encounter assumptions,
+combat assumptions. The Builder summary rail additionally contains one local
+experimental catalog baseline panel; shared Build pages do not render it. Keep
+the panel in the summary rail only, with two independent cards labeled `PRIMARY`
+and `SECONDARY`.
+
+Use the exact eyebrow `WEAPON OUTPUT / CATALOG BASELINE` and show the
+`EXPERIMENTAL` state. Each card displays the catalog weapon ID, selected damage,
+catalog RPM, magazine, reload, rated body-hit throughput, and magazine-cycle
+body-hit throughput. Include a visible formula and exclusions block with these
+exact formulas:
+
+- `selected damage × (RPM ÷ 60)` for rated body-hit throughput;
+- `(magazine × selected damage) ÷ ((magazine ÷ (RPM ÷ 60)) + reload seconds)`
+  for magazine-cycle body-hit throughput.
+
+The panel is evidence-only. It excludes inferred or substituted values, combat
+profiles, effects, Talents, Attribute totals, calculation profiles, accuracy,
+critical hits, headshots, enemy mitigation, target count, encounter uptime,
+rotations, and simulation. It must not present these values as actual, expected,
+or encounter DPS. When a required source value is unavailable or invalid, show
+`NOT AVAILABLE` and list the missing source fields under the metric; never
+display zero as a placeholder.
+
+The panel does not alter the planned calculation modes or full combat panels.
+Keep conditional Talent outcomes, weapon and Skill DPS, encounter assumptions,
 activation profiles, rotations, and simulation behind explicit `COMING SOON`
-panels.
+panels. Calculation modes remain planned and use these visible labels:
 
 Loadout schema version 6 retains `maximum`, `custom`, conditional state,
 encounter-assumption, and per-ability activation fields. Version 4 is obsolete

docs/DPS_SIMULATION_PROTOTYPE.md

@@ -0,0 +1,41 @@
+# Weapon baseline prototype
+
+## Scope
+
+`calculateWeaponBaseline` is a pure, client-safe Builder helper. It records
+weapon ID, name, and label, then reports three evidence-only metrics:
+
+- `selectedDamage`: the supplied positive finite damage value.
+- `ratedBodyHitThroughput`: `selectedDamage × rpm / 60`.
+- `magazineCycleBodyHitThroughput`:
+  `(selectedDamage × magazine) / (magazine / (rpm / 60) + reloadSeconds)`.
+
+Unknown, absent, non-positive, non-finite, or invalid source values make only
+the metrics that depend on them unavailable. The helper preserves decimal inputs
+and does not substitute values.
+
+These are not actual, expected, or encounter DPS. They contain no hit
+probability, critical or headshot outcomes, target state, or encounter timeline.
+The rated metric is nominal continuous body-hit throughput; the magazine-cycle
+metric includes the supplied reload interval.
+
+## Excluded inputs
+
+This helper does not read combat profiles, effects, talents, Attribute totals,
+calculation profiles, encounter assumptions, or any other build inputs. It does
+not call the simulation or combat engines.
+
+`selectedDamage` is already the equipped weapon damage used at this boundary. It
+is consumed exactly once; no additional level scaling or damage scaling is
+applied.
+
+## Missing data for a DPS model
+
+A valid DPS model still needs the authoritative damage calculation and its
+modifiers, hit and critical/headshot assumptions, firing and reload behavior,
+target and encounter assumptions, and the timing and contribution of talents,
+effects, Attributes, skills, and weapon swaps. Those data are outside this
+baseline.
+
+This is Builder-only, local prototype work. It does not define the player DPS
+simulation contract or change the existing calculation architecture.

docs/architecture.md

@@ -25,12 +25,16 @@ The team builds the project in vertical slices.
 Server code checks authorization for each mutation. UI visibility has no effect
 on server authorization.
 
-Builder and shared Build pages currently expose only deterministic totals from
-the equipped items, selected rolls, fixed bonuses, inherited profiles, augments,
-and active set bonuses. Conditional Talent outcomes, weapon and Skill DPS,
-encounter assumptions, activation profiles, rotations, and simulation remain
-planned. Explicit `COMING SOON` panels identify those player-facing
-capabilities.
+Builder and shared Build pages expose deterministic totals from the equipped
+items, selected rolls, fixed bonuses, inherited profiles, augments, and active
+set bonuses. Builder additionally shows an experimental catalog baseline for
+each selected weapon: body-hit throughput from selected weapon damage and
+catalog RPM, magazine, and reload values only. It is not expected or encounter
+DPS, does not infer or substitute missing values, reports blocked metrics with
+their source fields, and does not change shared Build behavior. Conditional
+Talent outcomes, full weapon and Skill DPS, encounter assumptions, activation
+profiles, rotations, and simulation remain planned. Explicit `COMING SOON`
+panels identify those player-facing capabilities.
 
 Weapon and gear range calculations must preserve decimal endpoints and follow
 the tested progression rules in