feat: expand ISAC content modeling

docs/DESIGN_SYSTEM.md

@@ -1572,13 +1572,42 @@ an icon in every option.
 
 ### Skill Chip data console
 
-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.
+Place two shared configuration cards above the Skill Chip definition registry.
+The `SHARED PRIMARY PROFILE` card contains the fixed Skill Duration, Skill
+Radius, Skill Cooldown Recovery, and Skill Intensity rows, with direct minimum
+and maximum fields for Standard, Specialized, Superior, and High-end. Its
+summary shows the configured count for each quality and the `NOT YET DEFINED`
+calculation state. The `SHARED SECONDARY POOL` card contains repeatable
+searchable Attribute rows with direct minimum and maximum fields for
+Specialized, Superior, and High-end. Its summary shows each quality's fixed
+capacity and the shared option count. Each card opens its own editor and closes
+that editor after a successful save. Validation keeps the affected editor open
+with its values intact. Successful saves append
+`game_data/skill_chip_primary_profile.updated` or
+`game_data/skill_chip_secondary_pool.updated`.
+
+State the fixed secondary capacities in the pool card and editor: Standard zero,
+Specialized one, Superior two, and High-end two. Skill Chip fields never show an
+item-level control or level-based preview. Quality labels use the global green,
+blue, purple, and yellow treatments; orange remains reserved for actions and
+selection. On narrow screens, profile summaries stack, endpoint matrices scroll
+inside their cards, and actions retain 44-pixel targets.
+
+Definition editors follow the dense staged pattern: ability assignment, identity
+and icon, one per-set 2-piece bonus, then the optional 3-piece Talent. Place the
+Talent assignment control before one disclosure that contains the entire Talent
+workspace: identity, description, quality-mix preview, and
+`MechanicProgramEditor`. The disclosure summary shows the configured Talent name
+or `TALENT WORKSPACE`, the quality-scaled outcome count, and an explicit
+`EXPAND` or `COLLAPSE` action. Existing Talents start collapsed when an operator
+opens a definition. Assigning a Talent or receiving a Talent validation error
+opens the workspace. Native disclosure semantics expose the expanded state, keep
+draft state mounted while collapsed, and provide a 44-pixel mobile target.
+
+Every equipped chip quality counts toward the two-piece threshold. The set-bonus
+preview uses four steps for zero through three equipped High-end chips and the
+formula `minimum + (maximum − minimum) × h / 3`; only High-end chips increase
+`h`. Do not duplicate calculated values as editable fields.
 
 ### ISAC record identity controls
 
@@ -1808,6 +1837,15 @@ same `weaponBaseRange` curve as the builder; never label the configured base
 endpoints as level-50 values. Weapon Talent 1 and Talent 2 pools use separate
 clickable icon rails and the standard Talent quick view.
 
+Show each weapon's named Mod slots and slot pictograms between its performance
+facts and Talent pools. Native T0 weapons display the complete T1/T2 slot set.
+Mark the slot that is absent at T0 with the blue information state and an
+explicit `T1+` label so the unlock does not rely on color alone. Other slots use
+the neutral telemetry treatment. If ISAC has no slot data, show
+`MOD SLOT DATA NOT CONFIGURED`. Do not show the weapon-category bonus count as
+`BASE BONUSES`; that identical count does not help players compare weapon
+definitions.
+
 Record cards may end with contextual actions that connect related public
 registries. Actions use the compact orange tactical-button treatment and encode
 their destination filter in the URL. Brand cards provide a “find Gear” action
@@ -1970,18 +2008,26 @@ mode with weapon icons and retained accessible names. Show configured versus
 required slot counts in text. Disabled tiers remain visibly unavailable and must
 not submit slot assignments.
 
-Quality-scaled registry editors use a compact matrix when the same numeric shape
-repeats across all four quality levels. Apply global quality colors only to the
-quality labels, retain textual quality names, and keep numeric fields neutral.
-On narrow screens the matrix may scroll horizontally while its surrounding
-editor and previews stack.
+Regular Weapon Mod definitions use a compact Level 1 and Level 20 primary-range
+matrix for Standard, Specialized, Superior, and High-end quality. Apply global
+quality colors only to the quality labels, retain textual quality names, and
+keep numeric fields neutral. On narrow screens the matrix may scroll
+horizontally while its surrounding editor and previews stack. Primary core type
+remains builder-selected and appears as the three always-available core icons
+rather than a persisted ISAC choice. Individual regular Weapon Mod editors also
+retain triggerless Mod Effects with one or two Attribute references and fixed
+per-quality values.
 
-When two item slots draw from the same canonical option pool, edit that pool
-once rather than rendering two duplicated selectors. Weapon Mods use a
-repeatable secondary-attribute row: one searchable attribute reference plus four
-quality range pairs. Show that the builder selects two distinct options from the
-pool. Primary core type is likewise builder-selected and is displayed as the
-three always-available core icons rather than a persisted ISAC choice.
+Configure one global secondary Attribute pool above the Weapon Mod registry.
+Each repeatable row contains one searchable Attribute reference and Level 1 and
+Level 20 minimum and maximum fields for Specialized, Superior, and High-end.
+Values between those endpoints use linear interpolation. Do not render Standard
+range fields because Standard has no secondary slot. State the fixed capacity in
+the pool editor and builder: Standard zero, Specialized one, Superior two, and
+High-end two. The builder requires distinct selections. Individual Weapon Mod
+editors must not repeat or submit pool data. A successful pool save uses the
+standard shared-profile lifecycle and creates the dedicated
+`game_data/weapon_mod_secondary_pool.updated` audit event.
 
 Exotic Weapon Mod status is a separate single-icon toggle using the exotic icon
 and the standard pressed, focus-visible, and selected states. Selecting it must
@@ -1993,12 +2039,20 @@ state panel visible so the change in data semantics is unmistakable.
 
 ### Gear Mod registry
 
-Gear Mods reuse the compact quality matrix, level preview, and pooled
-secondary-attribute rows established by Weapon Mods. Do not render exotic,
+Gear Mods reuse the compact Level 1 and Level 20 primary-range matrix and level
+preview established by regular Weapon Mods. Do not render exotic,
 weapon-category, slot-type, or Mod Effect controls in this simpler editor.
 Present the five primary options as an always-visible informational band because
-the actual primary is selected on the build instance, not persisted on the
-canonical definition.
+the build instance selects the primary; the canonical definition does not store
+that selection.
+
+Configure the Gear Mod family’s global secondary Attribute pool above the
+registry, separate from individual Gear Mod editors. Use the same three-quality
+endpoint rows, linear interpolation, and distinct-selection rule as the Weapon
+Mod pool. Capacity is zero for Standard, one for Specialized, and two each for
+Superior and High-end. Individual Gear Mod edits must not repeat or submit this
+pool. A successful pool save creates the dedicated
+`game_data/gear_mod_secondary_pool.updated` audit event.
 
 Use explicit textual tier capacity wherever Gear tier is summarized:
 `1 MOD SLOT` for T0 and `2 MOD SLOTS` for T1/T2. On narrow screens the identity
@@ -2325,6 +2379,16 @@ applied to the stored value. Restoration outcomes also expose an `INSTANT` or
 field and describes the configured value as the total delivered across that
 duration; switching back to instant clears the duration.
 
+Target-scoped direct-damage outcomes offer `HIT-TARGET EXPLOSION` in the Area
+Targeting control. Selecting it creates an event-target-centered enemy area with
+a five-meter starting radius, reveals the required radius field, and shows a
+text readout for the center, valid-target policy, inclusive boundary, and
+runtime evidence requirement. Only `ON EVENT` and `AFTER EVENT` remain available
+for this mode; selecting it from another phase moves the outcome to
+`AFTER EVENT`. Changing the outcome kind or target scope clears an incompatible
+area definition. Keep `ENEMIES IN RADIUS · LEGACY` visible for saved descriptive
+radius metadata, but do not present that mode as calculated explosion fan-out.
+
 Action Family recipes are optional authoring starters. Present the recipe
 catalog as a searchable assignment with only the parameters required by the
 selected family. `ADD RECIPE BRANCH` copies typed branches into the current
@@ -2511,10 +2575,11 @@ conditional Talent outcomes, weapon and Skill DPS, encounter assumptions,
 activation profiles, rotations, and simulation behind explicit `COMING SOON`
 panels.
 
-Loadout schema version 4 retains `maximum`, `custom`, conditional state,
-encounter-assumption, and per-ability activation fields for compatibility. The
-current player UI ignores those fields. When player simulation ships, one
-required two-option `SegmentedChoice` will use these visible labels:
+Loadout schema version 5 retains `maximum`, `custom`, conditional state,
+encounter-assumption, and per-ability activation fields. Version 4 is obsolete
+prototype data rather than a compatibility format. The current player UI ignores
+the simulation fields. When player simulation ships, one required two-option
+`SegmentedChoice` will use these visible labels:
 
 - `MAXIMUM POTENTIAL` calculates a configured ceiling. It applies conditional
   effects at peak state and treats selected abilities as firing on cooldown
@@ -2566,7 +2631,11 @@ Focus sets the primary Attribute, progression tree, and three ordered abilities.
 Its identity combines Specialization artwork and the primary Attribute mark.
 Each ability panel contains three fixed Skill Chip positions. A chip picker
 shows definitions assigned to that ability and excludes definitions assigned
-elsewhere.
+elsewhere. Skill Chips have no item-level control. The editor uses the shared
+quality profiles for direct rolls. It labels the four ability-scoped primary
+values `NOT YET DEFINED` and excludes them from current Agent and combat totals.
+Secondary capacity is Standard zero, Specialized one, Superior two, and High-end
+two; each equipped chip uses distinct selections from the shared pool.
 
 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
@@ -2581,11 +2650,11 @@ enabled ability. Future Skill result cards will show activation count,
 single-target DPS, total-target DPS, and a combined summary. They will state
 that Skills can critically hit and multi-shot but cannot headshot.
 
-Saved loadouts store focus, node ranks, nine Skill Chips, conditional modes,
+Version 5 loadouts store focus, node ranks, nine Skill Chips, conditional modes,
 encounter assumptions, and per-ability activation profiles. The builder accepts
-only the current complete structure for compatibility. Current player pages
-ignore the simulation fields. Invalid local drafts are discarded; invalid server
-records are removed through a backed-up database migration.
+only the current complete structure. Current player pages ignore the simulation
+fields. The builder discards version 4 local drafts; a backed-up database
+migration removes version 4 server records.
 
 ### Calculation revision controls
 
@@ -2650,3 +2719,13 @@ asset and states that the change is permanent. For assigned icons, the
 confirmation names the owning entity type. ISAC clears that source icon
 assignment before it removes the shared file. General library uploads retain the
 `ICON` or `IMAGE` state.
+
+In the Weapon Mod registry, operators manage shared artwork for all eight
+code-defined slots. The compact panel labels each slot `ICON REGISTERED` or
+`ICON REQUIRED`. Selecting a slot opens the standard icon upload control. Keep
+the slot name visible in ISAC after an operator uploads artwork.
+
+On public weapon cards, a configured slot chip shows only its uploaded icon.
+Keep the slot name in screen-reader and hover text. Retain the visible `T1+`
+marker and blue information treatment for slots unlocked at Tier 1. When artwork
+is missing, show the slot name instead of an invented glyph.