shd.build/PRODUCT.md

Product

Platform

web

Users

SHD.build serves active The Division Resurgence players who need 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, while administrators manage users, roles, system configuration, and operations.

Product Purpose

SHD.build is an independent community intelligence platform for The Division Resurgence. It includes a public game database, calculated loadout builder, shared builds, guides, news, and community participation.

Players should 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 game-data source for its public database, builder calculations, builds, guides, and contribution workflow. ISAC lets non-technical contributors propose connected data changes. Oversight reviews proposals before they become authoritative.

Player-facing planning and reference experiences use the same moderated data.

Operating Context

Players use the site to plan characters, compare drops, reproduce in-game equipment, browse community recommendations, and respond 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 can enable contributor mode after accepting the contributor guidelines. Contributors can connect proposed records to pending records before approval.

Capabilities and Constraints

• The application is built with SvelteKit and Svelte.
• Persistent application data uses the embedded @tursodatabase/database package. Turso Cloud is not required.
• 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 the system releases login identities and reusable usernames safely.
• The application normalizes user-uploaded avatars for storage and sends them to 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 capitalized. The product serves the full The Division Resurgence community, including loadout planning.

Use restrained in-universe operational language such as agent, ISAC, Oversight, intelligence, access, transmission, and registry when it improves comprehension. Do not let the theme 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 defines the current 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. Treat it as evidence and persistent user data rather than 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. Keep public reference data, builder calculations, and contributed updates connected.
2. Make deep systems understandable. Present dense game mechanics with precision without requiring users to understand the underlying data model.
3. Contribution without technical gatekeeping. Let players improve the database through clear forms, dependencies, review status, and actionable Oversight feedback.
4. Trust through visible governance. Use permissions, moderation, audit history, privacy, and system messages to make consequential states and actions explicit.
5. Preserve the community's work. Keep user content, contributor-entered data, and operational history through deployments, migrations, archival, and account lifecycle changes when 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 work from mobile screens through 4K desktop displays.

State and meaning cannot depend on color, icons, hover, or motion alone. Controls need usable touch targets. User identity must support non-ASCII display names and diverse avatar representation.