Improve ISAC libraries, roles, and public profiles

docs/DESIGN_SYSTEM.md

@@ -449,8 +449,11 @@ direct URL. Do not present authentication as a way around a disabled section.
 - On small screens, the split frame becomes a single column and account controls
   move before archival content.
 - Public display names and private login usernames are distinct. Display names
-  support normalized Unicode and relaxed visible characters; login usernames
-  remain unique, ASCII-only credentials and must never appear on public-facing
+  support normalized Unicode and relaxed visible characters. They are unique
+  under the product's normalized identity key and generate readable,
+  collision-safe public-profile slugs. New accounts receive the next available
+  `Agent N` placeholder until the owner chooses a name. Login usernames remain
+  unique, ASCII-only credentials and must never appear on public-facing
   community surfaces. Authorized ISAC user operations may show both.
 
 ### Public Agent profiles
@@ -458,11 +461,17 @@ direct URL. Do not present authentication as a way around a disabled section.
 Public Agent profiles are community dossiers, not account-control screens. Lead
 with the shared `AgentIdentityLink` in its large state: circular portrait,
 display name, explicit `SHD.BUILD AGENT PROFILE` context, and a directional
-link cue. The profile owner may receive an `EDIT MY PROFILE` action in the
-header. Keep public content totals in a compact telemetry strip below the
-identity header, then place the field bio, public builds, published guides, and
-recent discussion in the primary column. Profile messages occupy the narrower
-communications column and may remain sticky where the viewport has room.
+link cue. Place assigned site-role badges beneath the identity as a labeled
+semantic list. Show role names only, in alphabetical order, and omit the list
+when the Agent has no assigned roles. Badges use the shared raised surface,
+explicit role text, and a small orange diamond; they wrap without truncating
+long or multiple role names. Never expose role descriptions, permissions,
+direct grants, or access scopes on public profiles. The profile owner may
+receive an `EDIT MY PROFILE` action in the header. Keep public content totals
+in a compact telemetry strip below the identity header, then place the field
+bio, public builds, published guides, and recent discussion in the primary
+column. Profile messages occupy the narrower communications column and may
+remain sticky where the viewport has room.
 
 Use `AgentIdentityLink` for author attribution on builds, guides, comments, and
 other community records. Its compact and default states combine the circular
@@ -471,6 +480,11 @@ cue. Hover and focus-visible states may turn the name and cue orange. The
 portrait remains circular at every size; selectors may use square tactical
 thumbnails only where the avatar rules explicitly allow them.
 
+Public-profile links use the stored readable slug, URL-encoded as one path
+segment. A display-name change updates the canonical slug. Legacy UUID routes
+remain valid and redirect to the canonical address; UUIDs remain the internal
+identity for mutations, relationships, and audit evidence.
+
 Public biographies and community comments use the shared `MarkdownEditor` and
 `MarkdownContent` pair. The editor supplies a small formatting toolbar,
 remaining-character count, concise help, a readable editorial typeface, and a
@@ -663,10 +677,18 @@ error, or danger indicators.
 - Roles is a separate User Operations registry. Role definitions
   compose discrete capabilities through a dense permission catalogue with an
   explicit selected count and textual `GRANTED` / `NOT GRANTED` states. The
-  built-in Admin role is visible but system-protected. Delegated access managers
-  must never be able to grant `system.admin`; both option visibility and
-  server-side validation enforce this boundary. Role mutations are recorded in
-  the audit log with their previous and resulting permission sets.
+  core Admin role is deletion-protected because it provides the system's
+  unrestricted access mechanism. Full administrators may edit every role and
+  delete seeded operational roles; deletion records a persistent tombstone so
+  migrations do not recreate the role. Delegated access managers may edit
+  seeded operational roles but may delete only custom roles. Every deletion
+  requires an exact-name confirmation that states how many agents will
+  immediately lose the role. Keep Delete separated from Edit and use the danger
+  treatment only inside this confirmed path.
+  Delegated access managers must never be able to grant `system.admin`; both
+  option visibility and server-side validation enforce this boundary. Role
+  mutations are recorded in the audit log with their previous and resulting
+  permission and assignment evidence.
 - Audit History belongs to a separate `SYSTEM OVERSIGHT` navigation domain.
   Audit records are append-only operational evidence and show the operator,
   categorical action, target identifier, timestamp, and expandable before/after
@@ -1532,10 +1554,12 @@ Public Gear cards use the same rail for compatible Brand Sets and available
 Talents so players can identify actual options instead of reading a count.
 Each icon retains its accessible name and hover title, and missing artwork uses
 the shared placeholder without suppressing the relationship. Relationship
-icons are buttons: activating one opens a modal quick view using the same card
-facts as that record's public database category. The overlay closes through
-its explicit close action, backdrop, or Escape key. Do not render an empty
-Talent rail on item types that cannot equip Talents.
+icons are buttons: activating one opens a modal quick view with the shared
+database card component and the same facts, tier hierarchy, mechanic rows, and
+actions shown in that record's public registry. The overlay traps keyboard
+focus, returns focus to its trigger when closed, and closes through its explicit
+close action, backdrop, or Escape key. Do not render an empty Talent rail on
+item types that cannot equip Talents.
 
 ### Public game-database registries
 
@@ -1740,16 +1764,26 @@ them below a reliably readable width.
 
 Talent registry cards treat the two tier descriptions as their primary
 content; never replace them with configured/missing summary facts. Render Tier
-I and Tier II as distinct structured data blocks, then place optional cooldown
-metadata below both descriptions. Do not use the serif, quote-like prose
-treatment for tier effects. Use compact fixed tier labels, sans-serif effect
-text, and engineered borders. Tier I is the neutral baseline; Tier II uses the
-orange rail, label, and subtly elevated surface to communicate that it is the
-improved version. Duration and stack limits may remain compact badges. The
-top-right header status uses the applicable Backpack or Body Armor icon for
-gear talents and the SMG icon as the generic Weapon Talent symbol. Weapon
-Talent headers pair that icon with an explicit `1 · TOP` or `2 · BOTTOM`
-status badge; never rely on the slot number alone.
+I and Tier II as distinct structured data blocks, then place mechanics metadata
+below both descriptions. Use 16px semibold sans-serif text for tier effects so
+players can scan them before supporting facts. Do not use the serif,
+quote-like prose treatment. Use compact fixed tier labels and engineered
+borders. Tier I is the neutral baseline; Tier II uses the orange rail, label,
+and subtly elevated surface to communicate that it is the improved version.
+Render duration and stack limits as detail rows with activation and cooldown
+data. Keep calculation effects out of public Talent cards because the tier
+descriptions already state the player-facing values. Omit a stack limit of one
+because a single active instance is the default. The top-right header status
+uses the applicable Backpack or Body Armor icon for gear talents and the SMG
+icon as the generic Weapon Talent symbol. Weapon Talent headers pair that icon
+with an explicit `1 · TOP` or `2 · BOTTOM` status badge; never rely on the slot
+number alone.
+
+End each Talent card with a compatibility action. Gear Talent actions navigate
+to the Gear registry with the Talent filter selected. Weapon Talent actions
+navigate to the Weapons registry with the Talent Pool filter selected. Keep
+this action in shared cards and relationship quick views so both contexts use
+the same destination and label.
 
 When a public registry needs only one small bounded filter vocabulary, use the
 compact facet-panel form: one full-width group with all options visible in a
@@ -2265,4 +2299,8 @@ such as quality, focus, ability, or Talent category.
 Operators may rename, recategorize, and add tags to the library record. Replacing
 the icon from its game-data editor keeps that metadata and refreshes the context
 tags and file facts. Removing the source icon removes its linked library record.
-General library uploads retain the `ICON` or `IMAGE` state.
+Each library card offers `DOWNLOAD`, `EDIT`, and `DELETE` in a connected action
+rail. `DELETE` opens a focused confirmation that names the 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.