Story 4.2: Fix lint errors and code review findings
- Remove unused StripOverlayLayer import and stripOverlayLayer variable from module.js - Add comprehensive JSDoc annotations to FoundryAdapter.js methods (settings, socket, users, scenes, notifications, hooks) - Add /* global Dialog */ comment to PlayerPrivacyPanel.js for ESLint - Remove unused _force parameter from GMPlayerPrivacySelector.js render() method - Fix PlayerPrivacyPanelMenu.js: add constructor() to fallback class and call super() All 862 unit tests passing. All Story 4.2 acceptance criteria met. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
This commit is contained in:
@@ -0,0 +1,168 @@
|
||||
# PRD Template
|
||||
|
||||
## Essential Spine *(almost always present)*
|
||||
|
||||
```markdown
|
||||
---
|
||||
title: {Product Name}
|
||||
created: {YYYY-MM-DD}
|
||||
updated: {YYYY-MM-DD}
|
||||
---
|
||||
|
||||
# PRD: {Product Name}
|
||||
*Working title — confirm.*
|
||||
|
||||
## 0. Document Purpose
|
||||
[1 paragraph: who this PRD is for (PM, stakeholders, downstream workflow owners), how it's structured (Glossary-anchored vocabulary, features grouped with FRs nested, assumptions tagged inline and indexed). If UX work or other inputs already exist, name them here and reference where they live — this PRD builds on them, it does not duplicate.]
|
||||
|
||||
## 1. Vision
|
||||
[2-3 paragraphs: what this is, what it does for the user, why it matters. Compelling enough to stand alone.]
|
||||
|
||||
## 2. Target User
|
||||
|
||||
### 2.1 Primary Persona
|
||||
[Vivid but tight. Who they are, how this product fits their context.]
|
||||
|
||||
### 2.2 Jobs To Be Done
|
||||
[Bulleted. Emotional, social, functional, contextual — whichever apply. Even "this is for me as the builder" is a valid persona for a hobby project.]
|
||||
|
||||
### 2.3 Non-Users (v1) *(add when the audience boundary is non-obvious)*
|
||||
[Who this is explicitly not for in v1.]
|
||||
|
||||
### 2.4 Key User Journeys
|
||||
*Named-persona narratives the product enables. Numbered globally as UJ-1 through UJ-N. FRs reference journeys by ID inline ("realizes UJ-3"); SMs may also cross-reference. If a UX doc already exists, mirror its UJ IDs here and point to the source.*
|
||||
|
||||
**Default shape:** a named scene with entry state, path, climax, and resolution. Each beat forces specificity the team would otherwise leave implicit — auth assumptions, screen order, what tells the user value landed. Read together as a short narrative; the example below shows the form.
|
||||
|
||||
- **UJ-1. {One-line title — persona doing the thing.}**
|
||||
- **Persona + context:** one line, grounded enough to explain the *why*.
|
||||
- **Entry state:** authenticated? which surface? coming from where?
|
||||
- **Path:** 3-5 concrete beats — taps, screens, decisions.
|
||||
- **Climax:** the moment value is delivered and how the user knows.
|
||||
- **Resolution:** state they're left in, what's next.
|
||||
- **Edge case** *(optional)*: one real failure mode and what the user does next.
|
||||
|
||||
*Written out, that becomes:*
|
||||
> **UJ-3. Priya checks the trip damage before she's even home.**
|
||||
> Priya, budgeting on a single income with a new baby, finishes a grocery run and gets in the car. Already authenticated via biometric on a previous session. She opens the app, taps the FAB camera, and scans the receipt. The app OCRs the total and shows a single-screen overlay: this trip $84.20, weekly cap $250, $172.10 remaining, three days left in the week. She closes the app and drives home. **Edge case:** if she scanned a receipt earlier today, the app asks whether this replaces or adds to that trip before counting it against the cap.
|
||||
|
||||
- **UJ-2. ...**
|
||||
|
||||
**Scope dial:**
|
||||
- **Lighter** — hobby/solo, library/CLI, or when the UJ is essentially a JTBD restated: a single sentence works (`{Persona}, {context}, {what they do and why}.`).
|
||||
- **Heavier** — auth, multi-device handoff, complex navigation, or anything feeding downstream UX/architecture: add a numbered Flow, an Edge cases list, and a capability → FR mapping (`The system must {capability}. → FR-N`).
|
||||
|
||||
## 3. Glossary
|
||||
*Downstream workflows and readers must use these terms exactly. FRs, UJs, and SMs use Glossary terms verbatim; introducing a synonym anywhere in the PRD is a discipline violation. If §4 introduces a new domain noun, add it to the Glossary in the same pass.*
|
||||
|
||||
- **Term** — Definition. Relationships to other Glossary terms. Cardinality where relevant.
|
||||
- **Term** — ...
|
||||
|
||||
[Every domain noun the rest of the document uses. Defined once. No synonyms anywhere else in the PRD.]
|
||||
|
||||
## 4. Features
|
||||
*Each subsection is a coherent feature: behavioral description first, FRs nested under it, optional feature-specific NFRs and notes. FRs are numbered globally (FR-1 through FR-N) so downstream artifacts have stable references even if features get reorganized. Reference user journeys by ID inline ("realizes UJ-2") where the chain matters.*
|
||||
|
||||
### 4.1 {Feature Name}
|
||||
**Description:** [Behavioral narrative — how this feature works, who uses it, the user experience, edge cases. Realizes UJ-X, UJ-Y. Use Glossary terms exactly. Embed inline `[ASSUMPTION: ...]` tags where you inferred without confirmation.]
|
||||
|
||||
**Functional Requirements:**
|
||||
|
||||
#### FR-1: {Short capability name}
|
||||
|
||||
[Actor] can [capability] [under conditions]. Realizes UJ-X.
|
||||
|
||||
**Consequences (testable):**
|
||||
- {Specific testable condition, e.g. "System returns HTTP 429 when request rate exceeds 100/sec per merchant."}
|
||||
- {Another testable condition.}
|
||||
|
||||
**Out of Scope:** *(optional — what this FR explicitly does NOT cover)*
|
||||
- {bound}
|
||||
|
||||
#### FR-2: ...
|
||||
|
||||
**Feature-specific NFRs:** *(only if any apply uniquely to this feature)*
|
||||
- Performance / security / accessibility / etc. specific to this feature.
|
||||
|
||||
**Notes:** *(optional — open questions specific to this feature, `[NOTE FOR PM]` callouts)*
|
||||
|
||||
### 4.2 {Feature Name}
|
||||
...
|
||||
|
||||
## 5. Non-Goals (Explicit)
|
||||
[Bulleted. What this product is *not* and what it will *not* do in v1. Does outsized work for downstream readers and workflows — prevents the "let me also add this nearby thing" failure mode at every level (epic, ticket, code). Inline `[NON-GOAL for MVP]` callouts within §4 Features cover deferred items within features; this section captures the broader "we are not building X / we are not becoming Y" statements.]
|
||||
|
||||
## 6. MVP Scope
|
||||
|
||||
### 6.1 In Scope
|
||||
[Bulleted, crisp.]
|
||||
|
||||
### 6.2 Out of Scope for MVP
|
||||
[Bulleted. Each item with a one-line reason if the reason matters. Mark items deferred to v2/v3 explicitly. Add `[NOTE FOR PM]` callouts where a deferred item is emotionally load-bearing — flags it for revisit if timeline permits.]
|
||||
|
||||
## 7. Success Metrics
|
||||
|
||||
*Each SM cross-references the FR(s) it validates. Counter-metrics counterbalance specific primary or secondary metrics.*
|
||||
|
||||
**Primary**
|
||||
- **SM-1**: Metric — definition, target. Validates FR-X, FR-Y.
|
||||
|
||||
**Secondary**
|
||||
- **SM-2**: Metric — definition, target. Validates FR-Z.
|
||||
|
||||
**Counter-metrics (do not optimize)**
|
||||
- **SM-C1**: Metric — why this should *not* be optimized. Counterbalances SM-1.
|
||||
|
||||
[Length scales with stakes. Hobby/utility PRD: a single sentence may be enough ("Success: I use this weekly and don't abandon it after a month"). Public launch / enterprise: full quantitative breakdown with measurement methods. Counter-metrics are as load-bearing as primary metrics — they prevent the architect from optimizing the wrong thing and the dev from gaming the wrong target.]
|
||||
|
||||
## 8. Open Questions
|
||||
[Numbered. Things still unknown — they become future tickets or follow-up research, not silent gaps.]
|
||||
|
||||
## 9. Assumptions Index
|
||||
*Every `[ASSUMPTION]` from the document, surfaced for explicit confirmation:*
|
||||
- Inline assumption from §X.Y — short description.
|
||||
- ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Adapt-In Menu *(add the clusters the product calls for)*
|
||||
|
||||
### Cross-cutting quality and shape *(most non-trivial PRDs)*
|
||||
- **Cross-Cutting NFRs** — system-wide non-functional requirements not tied to a single feature (performance, security, reliability, observability). Add when system-wide quality attributes are meaningful.
|
||||
- **Constraints and Guardrails** — Safety, Privacy, Cost. Subsection per cluster. Add when any of these are real concerns.
|
||||
- **Why Now** — add when timing is load-bearing (a market shift, a technology enabler, a regulatory deadline). Drop when timing is incidental.
|
||||
|
||||
### Consumer / branded products
|
||||
- **Aesthetic and Tone** — visual references, anti-references, voice/tone for any product-generated text.
|
||||
- **Information Architecture** — top-level surfaces, navigation, screens.
|
||||
- **Monetization** — free vs. paid, pricing assumptions, ads policy.
|
||||
- **Platform** — web, mobile, PWA, native, v1 vs. v2+.
|
||||
|
||||
### Enterprise initiatives
|
||||
- **Stakeholders and Approvals** — who must sign off, at what stage.
|
||||
- **Risk and Mitigations** — operational, security, business, reputational risk register.
|
||||
- **ROI / Business Case** — quantified benefit, cost, payback period.
|
||||
- **Operational Requirements** — SLAs, RTO/RPO, support tier, on-call expectations.
|
||||
- **Integration and Dependencies** — SSO, existing enterprise systems, data sources, downstream consumers.
|
||||
- **Rollout and Change Management** — phased rollout plan, training, internal communication.
|
||||
- **Data Governance** — residency, sovereignty, classification, retention.
|
||||
- **Audit Trail / Decision Provenance** — formal documentation requirements for regulated environments.
|
||||
|
||||
### Regulated domains
|
||||
- **Compliance and Regulatory** — HIPAA, PCI-DSS, GDPR, SOX, SOC 2, Section 508 / WCAG 2.1 AA, FedRAMP, etc. — whichever apply. If any item needs depth, add a `[NOTE FOR PM]` callout to revisit or move to an addendum.
|
||||
|
||||
### Developer products (libraries, APIs, CLIs, SDKs)
|
||||
- **API Contracts / Public Surface** — endpoint shapes, breaking change policy.
|
||||
- **Versioning and Deprecation Policy**.
|
||||
- **Performance Budgets** — latency, throughput, resource use.
|
||||
- **Language / Runtime Targets and Dependency Policy**.
|
||||
|
||||
### Embedded / hardware
|
||||
- **Hardware Constraints** — memory, power, form factor.
|
||||
- **Deployment and Update Mechanism** — OTA, manual, image-based.
|
||||
- **Environmental and Reliability Requirements**.
|
||||
|
||||
### Small-scope all-inclusive *(use when scope is 1-2 stories' worth and the user wants a single captured artifact — chosen during the Right-skill check in Discovery)*
|
||||
- **Stories** — story-level specs listed inline at the end of the doc. Each story: *"As a [persona], I can [action] [under conditions]. Acceptance: [testable criteria]."* Numbered Story-1, Story-2, ... for reference. Pair with very lean §1 Vision, §2 Target User (often just JTBD + one UJ), §3 Glossary (handful of terms), §4 Features (often a single feature), §6 MVP Scope (in/out very tight). The whole doc fits on a page or two and captures intent + implementable stories in one place. If the user doesn't want the captured artifact at all, `bmad-quick-dev` is the better path — this cluster is only for "I want a doc *and* the stories."
|
||||
|
||||
Reference in New Issue
Block a user