144 lines
6.7 KiB
Markdown
144 lines
6.7 KiB
Markdown
# Product
|
|
|
|
<!-- impeccable:product-schema 1 -->
|
|
|
|
## 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.
|