feat(isac): add specialization data management

docs/DESIGN_SYSTEM.md

@@ -447,6 +447,10 @@ squeezed beside long module headings on mobile.
   so changing one history page does not reset the others.
 - Each module starts with `module-toolbar`, followed by `module-kpis`.
 - Editors use `dashboard-editor` and appear before the affected table.
+- Optional record descriptions use a full-width narrative field beneath the
+  identity controls. Preserve the same full-width placement in Oversight
+  before/after previews so reviewers can compare meaning without reading raw
+  proposal data.
 - Data collections use `dashboard-table`, `dashboard-row`, and `table-heading`.
 - Keep tables dense and horizontally scrollable rather than wrapping columns unpredictably.
 - User dossiers pair access controls and moderation in a two-column console,
@@ -1460,6 +1464,9 @@ proposing a canonical item. Upload fields must state that an icon may be
 contributed later and show the shared `/missing-item-icon.svg` artwork when no
 upload exists. Registries, relationship rails, and builder selection controls
 use the same placeholder instead of initials, empty boxes, or ad hoc glyphs.
+Application code references that asset through the shared
+`MISSING_ITEM_ICON_URL` constant and renders it through `ItemIcon`; do not
+duplicate its path or introduce module-specific missing-icon artwork.
 
 Treat the placeholder as an explicit incomplete-data state: keep its subdued
 SHD styling and useful alternative text where the surrounding item name is not
@@ -1630,3 +1637,58 @@ four-by-two matrix; the grid reduces to two columns and then one as available
 space narrows. Registry cards lead with complete category names. Counts and
 availability remain quiet footer metadata, and internal abbreviations or
 workflow-centric states are not exposed as primary public labels.
+
+### ISAC progression-tree composer
+
+Use the Specialization workbench pattern for ordered game systems whose
+meaning depends on both hierarchy and spatial placement. Keep the registry,
+selected parent identity, child navigation, readiness telemetry, and visual
+tree in one operational surface. Editors still open above the registry and
+follow the standard ISAC lifecycle; the workbench is navigation and context,
+not a replacement modal.
+
+The tree uses a stable 12-column track per row. Row and column are explicit
+numeric fields so placement is keyboard operable, auditable, and portable;
+never make drag-and-drop the only authoring method. On narrow screens, retain
+the geometry in a horizontally scrollable canvas instead of squeezing nodes
+until their names and state are unreadable. Controls outside the canvas stack
+and maintain at least a 44-pixel touch target.
+
+Each row header states its derived gate in plain language. Specialization gates
+count all available Rank 1 and Rank 2 unlocks in preceding rows, including the
+two immediately available ability nodes displayed in the first row. Do not
+store or manually edit a second gate value that could diverge. Free nodes use
+the orange identity rail plus the explicit `1 / 1 · FREE` state; pending,
+archived, incomplete, and builder-ready states must remain textual as well as
+colored.
+
+Treat allocation scope as first-class telemetry. Specialization progression is
+unlocked once for a specialization, but every focus receives the full point
+allocation independently. Show both the point total and that scope near the
+tree; do not imply that focuses draw from one shared spend pool. A focus is
+builder-ready only after it has three distinct active abilities, contiguous
+tree rows, at least one paid node, and exactly the configured available point
+total.
+
+Compose focus identity from the uploaded specialization artwork and the
+canonical Firepower, Toughness, or Engineering icon. Keep the specialization
+art primary and the attribute mark as a smaller corner badge. Ability slots 1
+and 3 are mirrored as free tree nodes; slot 2 is labeled Combat Skills-only and
+must not appear in the upgrade tree. Universal grenade and medical-kit actions
+are not specialization abilities.
+
+Use `StructuredEffectEditor` whenever an ISAC record needs an ordered set of
+calculation-ready effects. It provides Attribute, Ability when applicable, and
+Custom targets; a numeric value; and the shared bounded unit vocabulary. Keep
+the target searchable, show all bounded type and unit choices with segmented
+controls, and preserve explicit custom labels for mechanics that calculations
+do not yet support. Oversight previews must render effect and rank summaries as
+structured cards. Serialized JSON belongs only in the expandable raw-evidence
+panel.
+
+Rank cards present the complete rank description, structured effects, point
+cost, Credits, and material cost together. Specialized Alpha, Beta, and Gamma
+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.