feat: model specialization combat effects

docs/DESIGN_SYSTEM.md

@@ -196,8 +196,10 @@ The canonical tokens live in `src/app.css` under `:root`.
 | Page background | `--shd-bg` | `#0a0c0d` |
 | Base surface | `--shd-surface` | `#111415` |
 | Raised surface | `--shd-surface-raised` | `#141718` |
+| Modeled-data surface | `--shd-model-surface` | `#0d1213` |
 | Subordinate border | `--shd-border-soft` | `#272c2d` |
 | Primary border | `--shd-border` | `#303536` |
+| Modeled-data border | `--shd-model-border` | `#3b4648` |
 | Interactive boundary | `--shd-border-strong` | `#424849` |
 | Main text | `--shd-text` | `#ecebe5` |
 | Muted text | `--shd-text-muted` | `#858b8d` |
@@ -206,6 +208,7 @@ The canonical tokens live in `src/app.css` under `:root`.
 | Supporting copy floor | `--shd-type-supporting` | `14px` |
 | Ordinary body floor | `--shd-type-body` | `16px` |
 | Adaptive display scale | `--shd-display-scale` | `1` by default; stepped on high-resolution desktops |
+| Monospaced data | `--shd-font-mono` | Cascadia Mono with system monospace fallbacks |
 
 ### High-resolution display scaling
 
@@ -1605,7 +1608,9 @@ Pair the short state label with a complete consequence sentence. Contributors
 must not have to infer this behavior from their role name, data-mode color, or a
 success message shown after saving. Read-only operators do not see a mutation
 statement because their mutation controls are absent. At narrow widths the
-  message becomes its own compact row above the module toolbar.
+message becomes its own compact row above the module toolbar. A toolbar with
+multiple actions must reserve the complete action group width in the inline
+desktop strip so the consequence sentence never runs beneath a button.
 
 ### Public database index
 
@@ -1692,3 +1697,71 @@ components use the shared blue quality treatment and may be combined in any
 positive whole-number quantities for Rank 2. Rank 3 uses the yellow High-end
 Omega treatment and exactly one component. Color is supporting hierarchy;
 quality names and quantities always remain visible.
+
+### Conditional combat modeling
+
+ISAC authors define a combat effect once per Specialization and attach it to
+one or more tree-node ranks. Each rank attachment owns its hit trigger, stack
+duration, stack limit, and Attribute modifiers. Keep the lifecycle rules in a
+compact fact rail: trigger counters reset after a proc, each stack gain refreshes
+the timer, and expiry clears the complete stack. The shared definition provides
+one effect name and description to every attached rank.
+
+Use `--shd-model-surface` and `--shd-model-border` for conditional mechanics,
+calculation revisions, and field calibration. The blue information rail marks
+modeled behavior. Orange remains reserved for selection and activation. Every
+effect card names its trigger, duration, maximum stacks, and value per stack in
+text so the mechanic remains clear without color.
+
+The loadout builder gives each unlocked conditional effect three calculation
+modes:
+
+- `OFF` excludes the effect.
+- `PEAK` applies its configured maximum stacks.
+- `ENCOUNTER` models stack buildup and expiry from weapon RPM, magazine size,
+  reload time, hit rate, firing activity, and encounter duration.
+
+Users may override encounter assumptions on one effect without changing the
+global combat profile. The effect card shows the applied stack state beside the
+mode. On mobile, assumption fields and effect controls stack into full-width
+44-pixel targets.
+
+Combat result panels show normal, critical, headshot, and critical-headshot
+values with burst, sustained, and encounter DPS. Conditional stack telemetry
+lists the mode, average and peak stacks, ending stacks, buildup time, and
+maintained state that produced the result. A result with missing equipment,
+Attribute bindings, rules, or assumptions displays `INSUFFICIENT DATA` and a
+concrete remediation list. The interface withholds combat numbers until it has
+the required inputs.
+
+### Specialization loadout composer
+
+The builder places Specialization focus selection after equipment
+configuration. The focus identity combines Specialization artwork and the
+primary Attribute mark, followed by three ability panels. Each ability panel
+contains three fixed Skill Chip positions. A chip picker shows definitions
+assigned to that ability and excludes definitions assigned elsewhere.
+
+The focus tree groups nodes by row and uses segmented rank controls. Disabled
+ranks remain visible with their lock state. The builder permits a row after the
+user buys every available Rank 1 and Rank 2 in preceding rows and enforces the
+49-point limit. Cost telemetry lists Credits and components beside each rank.
+
+Saved loadouts store focus, node ranks, nine Skill Chips, effect modes, and
+combat assumptions. Version 1 loadouts keep their three legacy chips in an
+unassigned recovery list until the user places them under compatible abilities.
+
+### Calculation revision controls
+
+Combat rules use immutable active and retired revisions. ISAC editors may
+change draft revisions, ordered stages, and Attribute profiles. Activation
+requires `calculation.publish`, an explicit review state, and a confirmation
+that saved builds will recalculate. Successful activation closes the
+confirmation surface and records the revision in the audit history.
+
+Calibration cases pair a loadout snapshot with measured hit and timing values.
+Ready cases require the four hit values, magazine time, and reload time.
+Assisted suggestions create a draft revision for review and leave activation
+to an authorized operator. Use monospaced text for raw loadout and prediction
+snapshots; labels, findings, and errors stay in the standard operational
+typeface.