feat: defer advanced build calculations

docs/architecture.md

@@ -25,6 +25,13 @@ 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.
+
 Weapon and gear range calculations must preserve decimal endpoints and follow
 the tested progression rules in
 [`STAT_LEVEL_SCALING.md`](STAT_LEVEL_SCALING.md). Leveling is linear rather than
@@ -174,9 +181,11 @@ stores only its domain-separated hash. Repeated anonymous activity requires a
 Turnstile result. Guide reports reference the exact published revision so a
 report against an older revision cannot hide newer work.
 
-The Builder stores loadout data only. It has no summary or Guide body. An owned
-Build page links to `/guides/new?build=<id>`, where the server verifies
-ownership and initializes a removable Build block in a new private Guide.
+The Builder stores loadout data and displays deterministic equipped-item totals.
+It has no Guide body. Shared Build pages use the same player-facing calculation
+boundary. An owned Build page links to `/guides/new?build=<id>`, where the
+server verifies ownership and initializes a removable Build block in a new
+private Guide.
 
 ## Public data corrections and discussion
 
@@ -490,10 +499,11 @@ Talent, OS Protocol Talent, Skill Chip Talent, or Specialization tree rank. The
 `source_type` and `source_id` pair identifies that owner. No standalone Trigger
 record or shared Trigger relationship participates in execution.
 
-The builder supplies normalized timeline events to each equipped mechanic.
-`movement_snapshot.values.state` is `immobile`, `moving`, or `sprinting`; the
-mechanic's moving and sprinting scenario controls select that state, with
-sprinting taking precedence. Enabled Skill activation profiles emit
+The mechanic runtime accepts normalized timeline events for each equipped
+mechanic. Current player pages do not construct this timeline or invoke the
+runtime. `movement_snapshot.values.state` is `immobile`, `moving`, or
+`sprinting`; the mechanic's moving and sprinting scenario controls select that
+state, with sprinting taking precedence. Enabled Skill activation profiles emit
 `skill_deployed` events on the same cadence as Skill calculations and identify
 the deployed ability. An `on_event` Skill modifier applies to that activation
 until the ability's next deployment or the encounter ends.
@@ -502,7 +512,7 @@ Each source supplies a fixed value-variant contract:
 
 - Standard Talents require Tier I and Tier II values. Exotic Talents require
   Tier I and may omit Tier II until contributors document its game values.
-  Builder calculations use Tier I while an equipped exotic Talent has no Tier II
+  Runtime calculations use Tier I while an equipped exotic Talent has no Tier II
   mechanic variant.
 - OS Protocol Talents store a base value. An outcome may use an expression that
   reads `equipment.protocolTalentUpgrades`, from zero through five, so selected
@@ -622,10 +632,11 @@ uses `requires_assumptions`, identifies the missing input, and stays out of the
 calculation until an operator or builder scenario supplies it.
 
 The runtime derives a read-only pseudo-language listing from the typed program.
-ISAC and the builder use that listing to explain events, predicates, reducers,
-state changes, phases, and formulas. No route accepts the generated text as
-input, and no server process executes it. Operators edit structured fields; the
-formatter regenerates the listing after each change.
+ISAC uses that listing to explain events, predicates, reducers, state changes,
+phases, and formulas. Planned player calculations can reuse it when those pages
+consume mechanic outcomes. No route accepts the generated text as input, and no
+server process executes it. Operators edit structured fields; the formatter
+regenerates the listing after each change.
 
 ## AI-assisted mechanic drafting
 
@@ -732,7 +743,8 @@ clarification requests. It does not grant revision mutation or publication.
 Applying a result changes the open revision form in the client. The operator
 must review and save that draft through the existing revision action. The
 separate `calculation.publish` permission and activation confirmation remain
-mandatory before the saved draft affects loadout results.
+mandatory before the saved draft becomes the active authored model. Current
+player pages do not consume that model.
 
 Successful calculation-generation requests append sanitized events under
 `ai_assistance`. These events use calculation-specific actions, identify the
@@ -741,23 +753,23 @@ token-usage, result, and secret-exclusion rules as mechanic-assistance events.
 Applying a draft creates no server event. Existing `calculation_configuration`
 events remain the evidence for revision saves and activation.
 
-Source authors define the builder controls required by their mechanic as typed
-toggle, slider, or numeric scenario inputs. Each input records its label,
-guidance, bounds when applicable, default value, and best-case value. These
-controls appear only in advanced scenario configuration. Maximum mode supplies
-best-case values. Custom mode uses the values saved with the loadout. A mechanic
-with an undefined required assumption remains excluded and reports
-`REQUIRES_ASSUMPTIONS`.
+Source authors define planned player scenario controls as typed toggle, slider,
+or numeric inputs. Each input records its label, guidance, bounds when
+applicable, default value, and best-case value. ISAC retains these definitions
+for continued mechanic authoring. Current Builder and shared Build pages do not
+render or evaluate them. Their calculation panels display `COMING SOON` instead.
 
 Loadout schema version 4 stores one focus, selected tree ranks, nine Skill
 Chips, a unified conditional-effect state map, encounter assumptions,
 per-ability activation controls, and `calculationMode`. Runtime readers accept
-the exact version 4 structure. A backed-up prototype migration removes drafts,
-saved builds, and calibration snapshots that use incompatible payloads.
+the exact version 4 structure. The schema retains its simulation fields for
+compatibility, but the current player UI ignores them. A backed-up prototype
+migration removes drafts, saved builds, and calibration snapshots that use
+incompatible payloads.
 
-## Calculation modes
+## Planned player calculation modes
 
-The builder offers `maximum` and `custom` modes.
+Loadout v4 defines `maximum` and `custom` modes for the planned simulation UI:
 
 - Maximum mode supplies each scenario input's best-case value, selects peak
   conditional-effect state, and runs selected abilities on cooldown against
@@ -767,9 +779,10 @@ The builder offers `maximum` and `custom` modes.
   rates, target counts, and other supported assumptions. A missing required
   input produces `REQUIRES_ASSUMPTIONS` rather than a fabricated value.
 
-Saved and shared loadouts preserve the selected mode. Calculation results label
-the mode so readers can distinguish a best-case ceiling from a scenario-based
-estimate.
+Saved and shared loadouts preserve the selected mode as compatibility data. The
+current Builder and shared Build UI does not expose a mode selector, read
+encounter assumptions, or execute either mode. Explicit `COMING SOON` panels
+reserve the player-facing space for these calculations.
 
 ## Specialization ability attacks
 
@@ -795,6 +808,12 @@ holds the first position, and the firing-cycle stage holds the last.
 `attribute_calculation_profiles` maps an Attribute to a weapon stage with its
 weight, optional caps, curve, and weapon-category scope.
 
+ISAC keeps combat revision editing, publication, calibration, assisted
+suggestions, and the calculation AI assistant available so operators can
+continue authoring the model. Builder and shared Build pages do not load the
+active revision or consume revision, calibration, assistant, mechanic-runtime,
+or combat-engine output at the current player-facing boundary.
+
 The shared combat engine consumes weapon facts, accumulated Attributes,
 calculation profiles, and mechanic outcomes. It produces four hit values, burst
 DPS, reload-aware sustained DPS, encounter DPS, and stack telemetry. Custom mode
@@ -803,11 +822,11 @@ configured burst size, pauses between bursts, and encounter duration. It
 resolves the active Attribute state at each landed shot before calculating that
 shot's expected damage.
 
-The builder scales a weapon definition's level-1 damage range to the equipped
-item level, then the agent selects one damage value inside that valid range.
-Combat receives `equipped_weapon.damage` as its base damage and consumes that
-number once. The combat pipeline has no `level_scaled_damage` value and must not
-apply item-level scaling a second time.
+The deterministic equipment path scales a weapon definition's level-1 damage
+range to the equipped item level, then the agent selects one damage value inside
+that valid range. A combat invocation receives `equipped_weapon.damage` as its
+base damage and consumes that number once. The combat pipeline has no
+`level_scaled_damage` value and must not apply item-level scaling a second time.
 
 The generated calculation listing names each typed pipeline stage and its bound
 Attributes. The listing explains the active revision with statements such as
@@ -829,8 +848,8 @@ the builder supports a combined weapon-rotation model.
 
 The engine returns `INSUFFICIENT_DATA` with missing requirement keys when a
 calculation lacks required inputs or an Attribute binding. Callers must render
-that state instead of a partial result. Saved and shared builds load the current
-active revision for each request.
+that state instead of a partial result. Current player routes do not call the
+engine; their planned calculation surfaces display `COMING SOON`.
 
 `calculation_calibration_cases` stores a versioned loadout snapshot, observed
 hit values, timing values, optional encounter DPS, and the model prediction.