feat(isac): add OS protocol management

docs/DESIGN_SYSTEM.md

@@ -366,6 +366,67 @@ control at the data boundary instead of presenting cross-slot choices. Weapon
 talents are classified once as Talent 1 / Top or Talent 2 / Bottom in the
 talent registry; weapon editors only curate subsets from the matching slot.
 
+### Game-semantic iconography
+
+Canonical game icons are registered in `src/lib/game-icons.ts` and rendered
+through `GameIcon.svelte`; do not repeat asset paths in individual features.
+Use damage icons beside Blast, Pierce, and Shredding classifications, and core
+attribute icons beside Firepower, Toughness, and Engineering values. The same
+registry reserves the Bulwark, Combat Medic, Demolitionist, Tech Operator,
+Vanguard, Legendary, and SHD-ticket assets for controls or data that explicitly
+represent those concepts. Do not use semantic icons as unrelated decoration.
+
+Interactive icon choices retain a visible text label, square engineered cells,
+orange selected state, and hover, pressed, and focus-visible feedback. Icons
+that repeat an adjacent visible label are decorative with an empty alternative;
+standalone icons expose the registry's human-readable label. Preserve each
+asset's aspect ratio with `object-fit: contain` and scale through the shared
+`.game-icon` class rather than modifying source artwork.
+
+### Item quality
+
+Item quality is a global semantic scale: Standard uses
+`--quality-standard` green, Specialized uses `--quality-specialized` blue,
+Superior uses `--quality-superior` purple, and High-end uses
+`--quality-high-end` yellow. Apply the matching `.quality-*` utility wherever
+an item’s persisted quality is shown. Registry labels use `.quality-chip` so
+quality remains explicit in text and never depends on color alone. These colors
+identify item quality; orange remains reserved for actions and current
+selection.
+
+### OS Protocol editor
+
+OS Protocol definitions separate shared secondary profiles from item-owned
+progression. The twelve quality + attribute-type combinations are configured
+once in a compact matrix and inherited by every matching protocol. Each profile
+contains three fixed stat identities and editable values. Individual protocol
+editors show the inherited profile read-only and store one unique primary stat
+with a level-1 base value. That primary value scales linearly to exactly twice
+its base at level 50.
+
+Protocol identity forms stack the four-choice quality radio band above the
+three-choice secondary-profile type band, with the protocol name occupying the
+larger adjacent column. Quality choices use their global semantic color plus an
+explicit text label and selected underline; profile types retain their
+icon-backed labels. Both controls collapse below the name on narrow screens.
+
+The shared secondary-profile matrix is collapsed by default because it is
+configuration infrastructure rather than a frequent protocol-editing task. Its
+disclosure header always exposes the configured total, uses a textual title,
+and rotates the plus indicator when expanded. The full matrix remains keyboard
+operable and follows the shared hover, focus-visible, and pressed states.
+
+The dedicated unique-talent panel uses five interactive diamonds: no filled
+diamonds is the base definition, and each selected upgrade adds one fifth of
+the base until five upgrades show exactly twice the base effect.
+
+Diamonds are both a progression preview and an explicit numeric state; expose
+their upgrade number and `aria-pressed` state rather than relying on fill color.
+Protocol talents own their effects but reuse the global stat and trigger
+registries. Shared secondary values do not scale with the individual protocol’s
+level. Store only the unique primary and talent base values, and derive their
+progression consistently in calculation and display code.
+
 ### ISAC editor lifecycle
 
 Successful saves have a consistent outcome throughout data management:

docs/architecture.md

@@ -144,3 +144,22 @@ talent ID not already owned by the edited weapon and rejects any talent shared
 by another weapon. Converting a weapon back to standard clears the relationship
 and archives its now-unowned exotic talent. Exotic talent creation and editing
 are rejected by the shared Talent Registry so ownership cannot be bypassed.
+
+# OS Protocol progression
+
+OS Protocols use dedicated normalized tables because their talent progression
+has six calculated states (base plus five upgrades) rather than the shared
+two-tier talent model. Each protocol owns one `os_protocol_primary_effects`
+record and one `os_protocol_talents` record. Talent effects and reusable
+triggers live in their respective join tables.
+
+The three secondary attributes are normalized separately. One
+`os_protocol_secondary_profiles` record exists for each configured quality +
+attribute-type combination, with its three fixed stat/value pairs in
+`os_protocol_secondary_effects`. Every matching protocol inherits that profile;
+secondary values are not copied onto individual protocol records.
+
+The unique primary value uses `base × (1 + (level − 1) / 49)` for levels 1–50, while
+talent effects use `base × (1 + upgrades / 5)` for zero to five upgrades.
+Server actions validate all relationships and append the full owned graph to
+the existing `game_data` audit history.