feat(isac): link skill chips to abilities

docs/DESIGN_SYSTEM.md

@@ -2,14 +2,13 @@
 
 This document defines the visual language for SHD.build, the independent
 Division Resurgence community for builds, guides, game data, news, and
-discussion. New pages should feel like part of the same tactical intelligence
-network as the admin dashboard, while public pages may use more space and larger
-editorial typography.
+discussion. New pages use the same tactical intelligence network as the admin
+dashboard. Public pages may use more space and larger editorial typography.
 
 ## Design principles
 
-1. **Tactical, not military cosplay.** Use operational language, compact information density, restrained status indicators, and precise alignment. Avoid camouflage, distressed textures, or decorative weapon imagery in utility interfaces.
-2. **Data first.** Hierarchy comes from grouping, typography, borders, and spacing. Admin tools should resemble a dependable control surface rather than a collection of marketing cards.
+1. **Tactical.** Use operational language, compact information density, restrained status indicators, and precise alignment. Avoid camouflage, distressed textures, and decorative weapon imagery in utility interfaces.
+2. **Data first.** Grouping, typography, borders, and spacing establish hierarchy. Admin tools use a dependable control surface.
 3. **Orange means action.** SHD orange identifies primary actions, active navigation, focus, and important values. It should not cover large areas.
 4. **State is always visible.** Loading, disabled, active, archived, configured, error, and success states need both visual and textual indicators.
 5. **Square and engineered.** Panels and controls use square corners, fine borders, tight spacing, and deliberate grid alignment.
@@ -20,42 +19,41 @@ editorial typography.
 ### Routed error console
 
 Expected HTTP errors and unexpected server faults use one shared SHD exception
-console inside the normal application shell. The console always displays the
+console inside the application shell. The console displays the
 numeric status, an operational title, a safe explanation, request path, node,
 and context-appropriate recovery controls. Common statuses receive distinct
 language: authentication for 401, clearance for 403, lost location for 404,
 conflict for 409, saturation for 429, and service/fault language for 5xx.
 
 Orange identifies recoverable request errors and actions; red identifies server
-faults. Never display stack traces, database messages, credentials, request
-queries, or raw unexpected exceptions to users. Unexpected server faults receive
-a short reference ID from the global error handler for support correlation while
-the complete error remains server-side. If the root application shell itself
-cannot render, `src/error.html` provides a dependency-free SHD fallback surface.
+faults. Do not display stack traces, database messages, credentials, request
+queries, or raw unexpected exceptions. The global error handler gives each
+unexpected server fault a short support reference ID and keeps the full error
+server-side. If the root application shell cannot render, `src/error.html`
+provides a dependency-free SHD fallback surface.
 Error controls retain square geometry, focus-visible treatment, pressed motion,
 plain-language labels, and stacked mobile recovery actions.
 
 ### Contact relay and legal requests
 
-Public support uses the SHD Contact Relay surface: a broad transmission form
-paired with a compact destination guide. Two-to-six destinations use the shared
-segmented-choice pattern. Signed-in identity details may be prefilled, but the
-public form remains available to people who cannot sign in. Discord community
-access is a distinct provider-colored card; it supplements rather than replaces
-the durable contact channel.
+Public support uses the SHD Contact Relay: a broad transmission form and a
+compact destination guide. Two-to-six destinations use the shared
+segmented-choice pattern. Signed-in identity details may be prefilled; people
+who cannot sign in retain access to the public form. Discord community access
+uses a distinct provider-colored card alongside the durable contact channel.
 
-The Contact hero explicitly resets the global site-header height: semantic page
-`header` elements must use content-driven height and spacing rather than inherit
-the 76-pixel navigation-shell constraint. Its title, description, and Discord
+The Contact hero resets the global site-header height: semantic page `header`
+elements use content-driven height and spacing instead of the 76-pixel
+navigation-shell constraint. Its title, description, and Discord
 card align within a minimum 230-pixel desktop band before the form grid begins.
 The Contact page itself remains content-height-driven so high-resolution browser
 zoom does not multiply a viewport minimum into a large empty region above the
 footer.
 
-The application frame is a full-viewport vertical flex stack. The shared footer
-uses automatic top margin, so it rests against the bottom edge on short routes
-and follows normal document flow after longer content. Individual pages must
-not add spacer heights solely to position the footer. The frame compensates for
+The application frame uses a full-viewport vertical flex stack. The shared
+footer uses automatic top margin. It rests against the bottom edge on short
+routes and follows document flow after longer content. Do not add spacer heights
+only to position the footer. The frame compensates for
 `--shd-display-scale` when calculating its viewport minimum so high-resolution
 browser zoom does not push a short-page footer below the visible edge.
 
@@ -73,8 +71,8 @@ color the complete product name orange.
 
 ### Community platform positioning
 
-SHD.build is a full Division Resurgence community, not solely a loadout tool.
-Primary product language and global navigation must represent five durable
+SHD.build is a Division Resurgence community. Primary product language and
+global navigation represent five durable
 channels: News, Database, Builds, Guides, and Builder. Loadout-specific terms
 remain appropriate inside build routes, but the global brand descriptor,
 homepage metadata, hero, sign-in introduction, and footer describe the broader
@@ -211,12 +209,10 @@ The canonical tokens live in `src/app.css` under `:root`.
 
 ### High-resolution display scaling
 
-The application uses restrained, stepped interface scaling when the effective
-CSS viewport is substantially wider than a conventional desktop. At 2200px the
-complete interface scales to 115%, at 2800px to 130%, and at 3400px to 150%.
-This preserves the established relationship between typography, controls,
-tables, spacing, hit targets, and fixed-position surfaces instead of enlarging
-text alone.
+The application uses restrained stepped interface scaling on wide CSS
+viewports. At 2200px, the interface scales to 115%; at 2800px, to 130%; and at
+3400px, to 150%. This maintains the established relationship among typography,
+controls, tables, spacing, hit targets, and fixed-position surfaces.
 
 Use the shared `--shd-display-scale` token and the root-level `zoom` treatment;
 do not add module-specific 4K font-size overrides. Responsive layouts below
@@ -233,7 +229,7 @@ Use the spacing tokens for new components. Prefer `8px`, `12px`, and `20px` gaps
 
 ## Typography
 
-SHD.build self-hosts two intentional type voices through Fontsource packages:
+SHD.build self-hosts two type voices through Fontsource packages:
 
 - **Barlow** is the operational family for display headings, navigation,
   controls, data, labels, metadata, and general interface copy. Use the shared
@@ -243,10 +239,9 @@ SHD.build self-hosts two intentional type voices through Fontsource packages:
   `--shd-font-editorial`; do not apply it to controls, tables, metrics, or
   telemetry labels.
 
-Only the used Barlow weights (400, 600, 700, 800, and 900) and Source Serif 4
-weights (400 and 600) are loaded. Both families are self-hosted, preserve
-fallback stacks, and render immediately without a third-party font request.
-The two-voice rule remains semantic: Barlow operates the system; Source Serif 4
+Load Barlow weights 400, 600, 700, 800, and 900, plus Source Serif 4 weights
+400 and 600. Both families are self-hosted, keep fallback stacks, and render
+without a third-party font request. Barlow operates the system; Source Serif 4
 explains it.
 
 - Page and module headings are uppercase, heavy, and tightly spaced.
@@ -265,7 +260,7 @@ explains it.
 ### Global mobile navigation
 
 At viewports up to 900px, replace the hidden desktop link rail and account
-controls with a clearly labeled square `MENU` control in the shared site
+controls with a labeled square `MENU` control in the shared site
 header. Activating it opens a right-side SHD navigation panel over a dismissible
 backdrop. The panel includes Home, Discover, Builder, Guides, Sign In or My
 Profile, and ISAC when authorized; authenticated agents also receive identity
@@ -289,7 +284,7 @@ squeezed beside long module headings on mobile.
 ### Public pages
 
 - Maximum content width: approximately 1400–1640px.
-- Larger headings and more generous vertical rhythm are appropriate.
+- Public pages may use larger headings and more generous vertical rhythm.
 - Preserve the grid background and orange accents.
 - Catalogue and editorial pages use `catalogue-hero` for an angular introductory
   panel and may pair it with a compact operational control bar.
@@ -377,7 +372,8 @@ squeezed beside long module headings on mobile.
   white Apple mark on black, Discord uses its unmodified white symbol on
   Blurple, and Steam uses its white linked-circle mark on Steam navy.
 - Providers that are not configured are disabled, desaturated, and marked
-  `PLANNED`; they must not navigate, submit, or visually imply availability.
+  `PLANNED`; they must not navigate, submit, or imply availability through
+  styling.
 - When each provider is implemented, replace its placeholder with the
   provider-rendered control or current pre-approved sign-in artwork where the
   provider requires it. In particular, use Google Identity Services or its
@@ -560,18 +556,17 @@ Do not communicate state by color alone; include a label, icon, or pattern.
 5. Use the shared tokens instead of introducing near-duplicate colors.
 6. Verify keyboard focus, pending behavior, empty states, mobile layout, and archived data behavior.
 
-If a new interface needs a genuinely new pattern, document it here when introducing it.
+Document a new interface pattern here when you introduce it.
 
 ## Design-system governance
 
-Significant visual and interaction changes must update this document and the
-shared implementation in the same change. A change is significant when it
-introduces or materially revises a reusable token, component pattern, layout,
-responsive rule, accessibility behavior, motion behavior, or state convention.
+Update this document and the shared implementation with each significant visual
+or interaction change. A change qualifies when it introduces or revises a
+reusable token, component pattern, layout, responsive rule, accessibility
+behavior, motion behavior, or state convention.
 
-Small alignment corrections and isolated visual bug fixes do not require a
-documentation change unless they establish a rule that other interfaces should
-follow.
+Small alignment corrections and isolated visual bug fixes need no documentation
+change unless they establish a reusable rule.
 
 Repository agents and contributors should follow the maintenance checklist in
 `AGENTS.md`.
@@ -753,7 +748,7 @@ numbers.
 
 When only one page exists, omit page navigation and row-count presets; retain
 only the useful result range and any registry search. Do not render disabled
-pagination controls simply to preserve the rail's shape.
+pagination controls to preserve the rail's shape.
 
 Registries with a meaningful name, title, or agent-identity column place the
 shared server-side search inside this pagination rail. Results update after a
@@ -787,13 +782,13 @@ bookmarkable, and expose the selected state with both orange emphasis and
 textually identifiable active states. Every card explicitly says `FILTER →`
 or `SELECTED`; do not rely on KPI-card styling alone to communicate that the
 metrics are controls. Counts describe the full search scope,
-not merely the visible page. Do not use aggregate facts that cannot filter the
-affected registry—replace them with actionable subsets.
+not merely the visible page. Replace aggregate facts that cannot filter the
+affected registry with actionable subsets.
 
 ### Registry row interaction
 
-Desktop registry rows are passive data containers unless the entire row
-actually opens a detail view. Do not apply a whole-row hover surface when only
+Desktop registry rows are passive data containers unless the entire row opens
+a detail view. Do not apply a whole-row hover surface when only
 the trailing Edit or View action is interactive. Render that action as a
 compact bordered control with hover, focus-visible, and pressed states so its
 interaction boundary is unmistakable.
@@ -812,7 +807,7 @@ and normalization checks remain authoritative.
 
 ### Moderated data states
 
-ISAC must clearly distinguish direct editing, contributor proposals, and read-only
+ISAC must distinguish direct editing, contributor proposals, and read-only
 access. Use a compact access banner above the module rather than changing the
 registry layout. Pending proposal counts appear as orange numeric indicators in
 data-navigation items. Proposal lifecycle states use text as well as color:
@@ -1077,7 +1072,7 @@ copy; do not apply the system-transmission frame to agent comments.
 
 Inbox entries expose two distinct actions. `VIEW DETAILS` opens the complete
 message when preview copy is truncated to two lines. A separate bordered orange
-response action navigates directly to the known workflow and uses specific
+response action opens the known workflow and uses specific
 language such as `UPLOAD NEW AVATAR`, `REVISE CONTRIBUTION`, or
 `VIEW BUILD & REPLY`; never substitute a generic destination label when the
 notification type is known. The same response label appears in the detail
@@ -1119,20 +1114,18 @@ unfocusable and unchanged.
 may omit visible text when a canonical, unambiguous game icon exists; they must
 retain an accessible label and hover title. Text-only segments may omit the
 default square indicator when the selected background, orange text, and lower
-rail already communicate state clearly. Do not remove both visible text and an
+rail communicate state. Do not remove both visible text and an
 icon from the same option.
 
 ### Skill Chip data console
 
-Skill Chip editing follows the dense ISAC staged-definition pattern: identity
-and icon first, the 2-piece numeric bonus second, mutually exclusive primary
-and secondary roll pools next, and the 3-piece talent last. Superior blue and
-High-end yellow communicate the only supported qualities; orange remains
-reserved for actions and current interactive state. A four-step segmented
-preview exposes the linear zero-to-three High-end interpolation without storing
-duplicate values. At narrow widths the roll pools and talent columns stack,
-preview segments become a two-by-two grid, and interactive targets remain at
-least 44 pixels tall.
+Skill Chip editing uses the dense ISAC staged-definition pattern: identity and
+icon, 2-piece numeric bonus, mutually exclusive primary and secondary roll
+pools, then 3-piece talent. Superior blue and High-end yellow identify the
+supported qualities; reserve orange for actions and the current interactive
+state. A four-step segmented preview shows the linear zero-to-three High-end
+interpolation without duplicate values. At narrow widths, stack roll-pool and
+talent columns, use a two-by-two preview grid, and retain 44-pixel targets.
 
 ### ISAC record identity controls
 
@@ -1145,12 +1138,12 @@ drop-zone to fill spare identity-row space.
 Icon-enabled consecutive-entry editors pass a successful-add result token into
 the shared upload control. Advancing that token clears the native file input,
 temporary preview URL, filename, drag/paste feedback, and validation state.
-This reset occurs only after a validated add succeeds; failed saves preserve
-the selected image, and successful edits close the editor normally.
+Reset only after a validated add succeeds. Failed saves preserve the selected
+image; successful edits close the editor.
 
-The primary `name` field in every ISAC data editor is a header-level input:
-46 pixels tall with larger, heavier text. This creates a consistent first
-reading point for long registries while keeping secondary metadata compact.
+The primary `name` field in each ISAC data editor is a 46-pixel header-level
+input with larger, heavier text. It gives long registries a consistent first
+reading point while keeping secondary metadata compact.
 
 `SearchableAssignment` is the standard relationship picker for long attribute,
 talent, trigger, and compatibility lists. Multiple mode manages additive sets;
@@ -1621,9 +1614,9 @@ second. Use a compact angular command band rather than a cinematic display
 hero: keep the archive identity, state how many registries are online, state the
 record total, and present contribution as a bordered secondary action.
 
-Place one discovery bar directly below the command band. Its label presents
-browsing and global search as equal paths—select a registry or search all
-data—and its search field searches across all public registry names and useful
+Place one discovery bar below the command band. Its label gives users two equal
+paths: select a registry or search all data. Its search field searches across
+all public registry names and useful
 descriptive data such as Talent text, Damage Types, item slots, qualities, and
 Brand bonus Attributes. Do not stack a separate registry-heading bar above or
 below it. Results name both the matching record and its registry, then link into
@@ -1640,12 +1633,11 @@ 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.
+Use the Specialization workbench pattern for ordered game systems that depend
+on hierarchy and spatial placement. Keep the registry, selected parent identity,
+child navigation, readiness telemetry, and visual tree in one operational
+surface. Editors open above the registry and follow the standard ISAC lifecycle.
+Use the workbench for navigation and context.
 
 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;
@@ -1662,20 +1654,19 @@ 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.
+Show allocation scope as first-class telemetry. A specialization unlocks once;
+each focus receives its own full point allocation. Show the point total and
+scope near the tree. A focus becomes builder-ready after it has three distinct
+active abilities, each ability has exactly three active Skill Chip definitions,
+tree rows are contiguous, at least one paid node exists, and the tree uses 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.
+Compose focus identity from uploaded specialization artwork and the canonical
+Firepower, Toughness, or Engineering icon. Keep the specialization art primary
+and place the attribute mark in a smaller corner badge. Mirror ability slots 1
+and 3 as free tree nodes. Label slot 2 Combat Skills-only and exclude it from
+the upgrade tree. Universal grenade and medical-kit actions are outside the
+specialization ability set.
 
 Use `StructuredEffectEditor` whenever an ISAC record needs an ordered set of
 calculation-ready effects. It provides Attribute, Ability when applicable, and
@@ -1686,6 +1677,15 @@ 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.
 
+Exclusive child-record relationships use a searchable assignment block directly
+after the record identity. The header names the parent type, states the
+relationship and capacity in plain language, and shows current usage as `N / N`.
+The registry repeats the assigned parent beside each child so exclusivity can be
+audited without opening the editor. Legacy records may remain visibly
+`UNASSIGNED`, but creation, restoration, and successful edits require a valid
+active parent. Capacity rules are enforced on the server and never communicated
+by color alone.
+
 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