feat: refine ISAC design and prepare production deployment

PRODUCT.md

@@ -0,0 +1,151 @@
+# Product
+
+<!-- impeccable:product-schema 1 -->
+
+## Platform
+
+web
+
+## Users
+
+SHD.build primarily serves active *The Division Resurgence* players who want
+reliable game data, accurate loadout planning, build sharing, and community
+guides.
+
+Registered players can save and share builds, publish guides, participate in
+community interactions, and manage their identity and notifications. Anonymous
+players can explore public content and keep local builder drafts.
+
+Trusted contributors maintain structured game data through ISAC. Oversight
+reviewers validate proposed changes, moderators handle community safety, and
+administrators manage users, roles, system configuration, and operations.
+
+## Product Purpose
+
+SHD.build is an independent community intelligence platform for *The Division
+Resurgence*. It brings together a public game database, calculated loadout
+builder, shared builds, detailed guides, news, and community participation.
+
+Success means players can confidently understand game systems, create accurate
+loadouts, learn from other agents, and help keep information current as the game
+changes.
+
+## Positioning
+
+SHD.build uses one community-maintained, structured source of game data across
+its public database, builder calculations, builds, guides, and contribution
+workflow. ISAC lets non-technical contributors propose connected data changes
+while Oversight reviews them before they become authoritative.
+
+This makes SHD.build more than a loadout tool or static wiki: player-facing
+planning and reference experiences remain connected to the same moderated data.
+
+## Operating Context
+
+Players use the site while planning characters, comparing drops, reproducing
+in-game equipment, browsing community recommendations, and responding to game
+updates. The interface must work from mobile devices through high-resolution
+desktop displays.
+
+The principal public channels are News, Database, Builds, Guides, and Builder.
+Account management includes authentication methods, profile identity, avatars,
+notifications, created content, favorites, and privacy controls.
+
+ISAC is the operational console for game-data entry, contribution review, user
+and role management, moderation, audit history, automated messages, and system
+metrics. Registered agents begin with read-only access and may explicitly
+enable contributor mode after accepting the contributor guidelines. Proposed
+records may depend on other pending records so contributors can build connected
+data chains before approval.
+
+## Capabilities and Constraints
+
+- The application is built with SvelteKit and Svelte.
+- Persistent application data uses the embedded `@tursodatabase/database`
+  package rather than Turso Cloud.
+- Development, staging, and production use distinct databases. Embedded
+  database files and uploaded assets are persistent user data and must survive
+  deployments and additive schema migrations.
+- Authentication supports passkeys, emailed magic links, Discord OAuth, and
+  optional username/password credentials. An account must always retain at
+  least one usable sign-in method.
+- Anonymous builder drafts may use local storage. Database-backed sharing
+  requires an account.
+- Saved builds support private, unlisted, and public visibility.
+- User deletion is soft deletion so authored builds and guides can remain while
+  login identities and reusable usernames are released safely.
+- User-uploaded avatars are normalized for storage and enter an Oversight queue
+  without blocking immediate use.
+- ISAC mutations are permission-controlled, append-only audited, and use
+  moderation proposals when the operator lacks direct-write authority.
+- Game-data editors must preserve the standardized add/edit lifecycle described
+  in `AGENTS.md`.
+- Major data changes preserve contributor-entered data through verified backups
+  and additive migrations with minimal development-server downtime.
+- SHD.build is an independent fan site. Ubisoft and the relevant owners retain
+  rights to *Tom Clancy's The Division*, *The Division Resurgence*, and their
+  associated intellectual property and assets.
+
+## Brand Commitments
+
+The product name is `SHD.build`, with `SHD` always capitalized. The product is
+positioned as a complete *The Division Resurgence* community rather than only a
+loadout network.
+
+The established voice uses restrained in-universe operational language such as
+agent, ISAC, Oversight, intelligence, access, transmission, and registry when
+it improves comprehension. Theme must never obscure plain meaning or turn into
+military cosplay.
+
+The existing SHD logo, favicon, game-type icon library, quality colors, and
+provider branding are maintained assets. Discord, Google, Apple, and Steam
+identity controls must follow their respective provider requirements.
+
+## Evidence on Hand
+
+- `docs/DESIGN_SYSTEM.md` is the maintained authority for the incumbent visual
+  and interaction language.
+- `docs/architecture.md` documents the application architecture and staged
+  feature model.
+- `docs/STAT_LEVEL_SCALING.md` contains empirically derived equipment-scaling
+  rules used by builder calculations.
+- `docs/DEPLOYMENT.md` documents containerized staging and production
+  operations.
+- `src/routes` contains working public, account, builder, database, ISAC,
+  notification, contact, legal, and authentication surfaces.
+- `static` contains the SHD favicon, provider marks, equipment and weapon
+  category icons, attribute icons, specialization icons, and shared fallback
+  artwork.
+- The embedded development database contains contributor-entered game and user
+  data. It is evidence and persistent user data, not a disposable fixture.
+- No testimonials, player-count claims, official Ubisoft endorsement, or
+  performance benchmarks are established; future work must not fabricate them.
+
+## Product Principles
+
+1. **One source of operational truth.** Public reference data, builder
+   calculations, and contributed updates must remain connected rather than
+   becoming divergent copies.
+2. **Make deep systems understandable.** Dense game mechanics should be
+   explorable and precise without requiring users to understand the underlying
+   data model.
+3. **Contribution without technical gatekeeping.** Players should be able to
+   improve the database through clear forms, dependencies, review status, and
+   actionable Oversight feedback.
+4. **Trust through visible governance.** Permissions, moderation, audit
+   history, privacy, and system messages should make consequential states and
+   actions explicit.
+5. **Preserve the community's work.** User content, contributor-entered data,
+   and operational history must survive deployments, migrations, archival, and
+   account lifecycle changes whenever policy permits.
+
+## Accessibility & Inclusion
+
+SHD.build targets WCAG 2.2 AA. Interfaces must support keyboard navigation,
+clear focus-visible states, screen-reader semantics, sufficient contrast,
+reduced-motion preferences, and layouts that remain functional from mobile
+screens through 4K desktop displays.
+
+State and meaning must never depend on color, icons, hover, or motion alone.
+Controls need usable touch targets, and user identity must support non-ASCII
+display names and diverse avatar representation.