152 lines
7.1 KiB
Markdown
152 lines
7.1 KiB
Markdown
# 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.
|