@kudusov.takhir/ba-toolkit 1.2.0

package/skills/references/templates/principles-template.md

@@ -0,0 +1,118 @@
+# Project Principles: [PROJECT_NAME]
+
+**Version:** 1.0
+**Date:** [DATE]
+**Domain:** [DOMAIN]
+**Slug:** [SLUG]
+
+## 1. Artifact Language
+
+All artifacts are generated in: [LANGUAGE]
+
+## 2. ID Conventions
+
+| Artifact | Format | Example |
+|----------|--------|---------|
+| Functional Requirements | FR-NNN | FR-001 |
+| User Stories | US-NNN | US-001 |
+| Use Cases | UC-NNN | UC-001 |
+| Acceptance Criteria | AC-NNN-NN | AC-001-01 |
+| Non-functional Requirements | NFR-NNN | NFR-001 |
+| Architecture Decisions | ADR-NNN | ADR-001 |
+| Data Entities | PascalCase (English) | UserAccount |
+| API Endpoints | REST path | POST /users |
+| Wireframes | WF-NNN | WF-001 |
+| Validation Scenarios | SC-NNN | SC-001 |
+
+## 3. Traceability Requirements
+
+Mandatory links — violations flagged as **CRITICAL** by `/analyze` and `/trace`:
+
+- Every FR must have at least one linked US (after `/stories`).
+- Every Must-priority US must have at least one AC (after `/ac`).
+- Every NFR must have a measurable metric.
+- Every WF must link to at least one US.
+
+Recommended links — violations flagged as **HIGH**:
+
+- Must-priority US should have a linked UC (or documented exception).
+- Every Data Entity should link to at least one FR or US.
+- Every API endpoint should link to at least one FR or US.
+
+Optional links — violations flagged as **MEDIUM**:
+
+- Should-priority US may skip UC.
+- Could/Won't items may be undocumented in later artifacts.
+
+## 4. Definition of Ready
+
+An artifact is ready to `/done` when all of the following are true:
+
+### Functional Requirement (FR)
+- [ ] Description present and unambiguous.
+- [ ] Actor identified (not "the system" or "the user" without role).
+- [ ] Priority assigned (MoSCoW).
+- [ ] Input/Output specified.
+
+### User Story (US)
+- [ ] Role, Action, and Value filled.
+- [ ] Priority assigned.
+- [ ] Linked FR reference present.
+
+### Use Case (UC)
+- [ ] Actor, Preconditions, Main Flow, and at least one Exceptional Flow present.
+- [ ] Linked US reference present.
+
+### Acceptance Criterion (AC)
+- [ ] Given / When / Then all present and specific.
+- [ ] Type specified (positive / negative / boundary).
+- [ ] Linked US reference present.
+
+### NFR
+- [ ] Category specified.
+- [ ] Measurable metric present (numeric target, not adjective).
+- [ ] Verification method specified.
+
+### Data Entity
+- [ ] All attributes have types and constraints.
+- [ ] FK references point to existing entities.
+
+### API Endpoint
+- [ ] Request and Response schemas present.
+- [ ] At least one error code documented.
+- [ ] Linked FR/US present.
+
+### Wireframe (WF)
+- [ ] All four states present: default, loading, empty, error.
+- [ ] Navigation links (from / to) specified.
+- [ ] Linked US present.
+
+## 5. NFR Baseline
+
+The following NFR categories are required regardless of domain:
+
+- **Security:** authentication method, data encryption at rest and in transit.
+- **Availability:** uptime SLA with a numeric target.
+- **Compliance:** applicable laws and data retention policy.
+
+[ADDITIONAL_NFR_CATEGORIES]
+
+## 6. Quality Gates
+
+For `/analyze` findings:
+
+- **CRITICAL:** must be resolved. `/done` is blocked.
+- **HIGH:** [BLOCK_OR_WARN] — [PROJECT_DECISION].
+- **MEDIUM:** documented and may be deferred.
+- **LOW:** informational only.
+
+## 7. Output Folder Structure
+
+**Mode:** [flat | subfolder]
+
+- `flat` (default) — all artifacts saved directly in the output directory.
+- `subfolder` — all artifacts saved under `{output_dir}/[SLUG]/`.
+
+## 8. Project-Specific Notes
+
+[ADDITIONAL_CONVENTIONS]

package/skills/references/templates/research-template.md

@@ -0,0 +1,99 @@
+# Technology Research & Architecture Decisions: [PROJECT_NAME]
+
+**Domain:** [DOMAIN]
+**Date:** [DATE]
+**Slug:** [SLUG]
+**References:** `02_srs_[SLUG].md`, `06_nfr_[SLUG].md`, `07_datadict_[SLUG].md`
+
+---
+
+## Architecture Decision Records (ADRs)
+
+### ADR-001: [Decision Title]
+
+**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-[NNN]
+**Date:** [DATE]
+
+**Context:**
+[What situation or requirement forces us to make this decision? Reference specific NFRs or FRs.]
+
+**Options Considered:**
+
+| Option | Pros | Cons |
+|--------|------|------|
+| [Option A] | [pros] | [cons] |
+| [Option B] | [pros] | [cons] |
+
+**Decision:** [Option A / B / other], because [rationale].
+
+**Consequences:**
+- [Positive consequence]
+- [Trade-off or risk]
+
+**References:** NFR-[NNN], FR-[NNN]
+
+---
+
+### ADR-002: [Decision Title]
+
+**Status:** Proposed | Accepted
+**Date:** [DATE]
+
+**Context:** [Context for this decision.]
+
+**Options Considered:**
+
+| Option | Pros | Cons |
+|--------|------|------|
+| [Option A] | [pros] | [cons] |
+| [Option B] | [pros] | [cons] |
+
+**Decision:** [Chosen option and rationale.]
+
+**Consequences:**
+- [Consequence]
+
+<!-- Repeat ADR block for each major architectural decision. -->
+
+---
+
+## Integration Map
+
+| Integration | Type | Protocol | Auth | Direction | Notes |
+|-------------|------|----------|------|-----------|-------|
+| [System name] | [REST / GraphQL / gRPC / Webhook / SDK] | [HTTPS / WSS] | [API key / OAuth / JWT] | Inbound / Outbound / Both | [notes] |
+
+---
+
+## Data Storage Decisions
+
+| Data Type | Storage Technology | Rationale |
+|-----------|-------------------|-----------|
+| [e.g. User profiles] | [e.g. PostgreSQL] | [why] |
+| [e.g. Session data] | [e.g. Redis] | [why] |
+| [e.g. Media files] | [e.g. S3-compatible] | [why] |
+
+---
+
+## Real-time Strategy
+
+**Requirement:** [What real-time feature needs this — e.g. live notifications, tracking]
+**Approach:** [WebSocket / Server-Sent Events / Long-polling / None]
+**Technology:** [e.g. Socket.io, native WebSocket, Pusher]
+**Rationale:** [Why this approach over alternatives]
+
+---
+
+## Regulatory & Compliance Notes
+
+| Requirement | Impact | Implementation Approach |
+|-------------|--------|------------------------|
+| [e.g. GDPR] | [what data is affected] | [how it will be addressed] |
+
+---
+
+## Open Questions
+
+| # | Question | Owner | Target Date |
+|---|---------|-------|-------------|
+| 1 | [Unresolved technical question] | [Role] | [Date] |

package/skills/references/templates/risk-template.md

@@ -0,0 +1,188 @@
+# Risk Register: {PROJECT_NAME}
+
+**Domain:** {DOMAIN}
+**Date:** {DATE}
+**Slug:** {SLUG}
+**Sources:** {list of artifacts scanned}
+
+---
+
+## Summary
+
+| Priority | Count |
+|---------|-------|
+| 🔴 Critical | 1 |
+| 🟡 High | 2 |
+| 🟢 Medium | 3 |
+| ⚪ Low | 1 |
+| **Total** | **7** |
+
+---
+
+## Risk Register
+
+| ID | Title | Category | Probability | Impact | Score | Priority | Status |
+|----|-------|----------|:-----------:|:------:|:-----:|---------|--------|
+| RISK-01 | Payment provider SLA not guaranteed | External | 4 | 5 | 20 | 🔴 Critical | Open |
+| RISK-02 | Regulatory approval timeline unknown | Compliance | 3 | 4 | 12 | 🟡 High | Open |
+| RISK-03 | Real-time leaderboard at scale unproven | Technical | 3 | 3 | 9 | 🟡 High | Open |
+| RISK-04 | Scope creep from stakeholder wish list | Business | 3 | 2 | 6 | 🟢 Medium | Open |
+| RISK-05 | Telegram Mini App API breaking changes | External | 2 | 3 | 6 | 🟢 Medium | Open |
+| RISK-06 | Data model changes after /datadict | Technical | 2 | 3 | 6 | 🟢 Medium | Open |
+| RISK-07 | Development team unfamiliar with domain | Business | 2 | 1 | 2 | ⚪ Low | Open |
+
+---
+
+## Risk Details
+
+### RISK-01 — Payment provider SLA not guaranteed
+
+**Category:** External
+**Probability:** 4 / 5 — Likely
+**Impact:** 5 / 5 — Critical
+**Score:** 20 🔴 Critical
+**Status:** Open
+**Source:** `07a_research_{slug}.md`
+
+**Description:**
+The selected payment provider has not provided a written SLA. If the provider experiences downtime during peak traffic, transactions will fail and user funds may be delayed, directly impacting revenue and trust.
+
+**Mitigation:**
+Negotiate and sign an SLA before launch. Implement a fallback payment provider in the API contract. Add payment provider availability as a monitored NFR metric.
+
+**Contingency:**
+Enable the fallback provider automatically via feature flag if primary provider error rate exceeds 5% over a 5-minute window.
+
+**Owner:** Tech Lead
+
+---
+
+### RISK-02 — Regulatory approval timeline unknown
+
+**Category:** Compliance
+**Probability:** 3 / 5 — Possible
+**Impact:** 4 / 5 — Major
+**Score:** 12 🟡 High
+**Status:** Open
+**Source:** `01_brief_{slug}.md`
+
+**Description:**
+The product operates in a regulated iGaming jurisdiction. The licensing timeline was listed as an assumption in the Brief. If approval is delayed, the launch date will slip regardless of development readiness.
+
+**Mitigation:**
+Engage legal counsel early to track approval status. Decouple development milestones from the licensing timeline so that technical readiness does not block on regulatory process.
+
+**Contingency:**
+Prepare a soft launch in an unregulated market while the primary jurisdiction approval is pending.
+
+**Owner:** Product Manager
+
+---
+
+### RISK-03 — Real-time leaderboard at scale unproven
+
+**Category:** Technical
+**Probability:** 3 / 5 — Possible
+**Impact:** 3 / 5 — Moderate
+**Score:** 9 🟡 High
+**Status:** Open
+**Source:** `07a_research_{slug}.md`
+
+**Description:**
+The ADR for the leaderboard service chose Redis Sorted Sets as the primary data structure. This approach has not been load-tested for the projected 10,000 concurrent users. If throughput assumptions are wrong, real-time updates will lag and degrade UX.
+
+**Mitigation:**
+Conduct a load test spike in the first development sprint. Define a fallback to polling-based updates (every 5s) if WebSocket throughput targets are not met.
+
+**Contingency:**
+Switch to polling-based leaderboard refresh with a 10-second interval. Communicate the change as a phased rollout feature.
+
+**Owner:** Tech Lead
+
+---
+
+### RISK-04 — Scope creep from stakeholder wish list
+
+**Category:** Business
+**Probability:** 3 / 5 — Possible
+**Impact:** 2 / 5 — Minor
+**Score:** 6 🟢 Medium
+**Status:** Open
+**Source:** `01_brief_{slug}.md`
+
+**Description:**
+Several features were marked out of scope during the Brief interview but stakeholders indicated they "might be needed later." Without a change control process, these may be re-introduced mid-development, inflating the MVP scope.
+
+**Mitigation:**
+Establish a formal change request process referenced in the Handoff document. All scope additions must go through `/stories` and be re-estimated.
+
+**Contingency:**
+Freeze scope at the start of each sprint. Defer any mid-sprint scope additions to the next sprint backlog.
+
+**Owner:** Product Manager
+
+---
+
+### RISK-05 — Telegram Mini App API breaking changes
+
+**Category:** External
+**Probability:** 2 / 5 — Unlikely
+**Impact:** 3 / 5 — Moderate
+**Score:** 6 🟢 Medium
+**Status:** Open
+**Source:** `07a_research_{slug}.md`
+
+**Description:**
+The product is built as a Telegram Mini App. Telegram has released breaking changes to the Mini Apps API in previous versions. If the API changes after development, UI components and deep links may require rework.
+
+**Mitigation:**
+Pin the Telegram Web App SDK version used in development. Monitor the Telegram changelog and the `@twa-dev/sdk` release notes. Abstract SDK calls behind a thin adapter layer.
+
+**Contingency:**
+Allocate a 3-day buffer in the release plan for SDK compatibility fixes.
+
+**Owner:** Frontend Lead
+
+---
+
+### RISK-06 — Data model changes after /datadict
+
+**Category:** Technical
+**Probability:** 2 / 5 — Unlikely
+**Impact:** 3 / 5 — Moderate
+**Score:** 6 🟢 Medium
+**Status:** Open
+**Source:** `07_datadict_{slug}.md`
+
+**Description:**
+The Data Dictionary was finalised before the API Contract was fully detailed. Late-stage entity or field changes discovered during API design may require cascading updates across the SRS, Stories, and AC artifacts.
+
+**Mitigation:**
+Run `/trace` after `/apicontract` to detect any new cross-artifact inconsistencies. Address CRITICAL gaps before handoff.
+
+**Contingency:**
+Use `/revise` on affected artifacts to propagate changes. Document the delta in the Handoff open items list.
+
+**Owner:** Business Analyst
+
+---
+
+### RISK-07 — Development team unfamiliar with domain
+
+**Category:** Business
+**Probability:** 2 / 5 — Unlikely
+**Impact:** 1 / 5 — Negligible
+**Score:** 2 ⚪ Low
+**Status:** Open
+**Source:** `01_brief_{slug}.md`
+
+**Description:**
+The engineering team has limited prior experience with iGaming products. Domain-specific concepts (RTP, bonus wagering, KYC flows) may be misunderstood during implementation, leading to minor defects in edge cases.
+
+**Mitigation:**
+Include a domain onboarding session as part of sprint 0. Reference the iGaming domain glossary in the Handoff document.
+
+**Contingency:**
+Schedule a BA review checkpoint after the first feature is implemented end-to-end.
+
+**Owner:** Product Manager

package/skills/references/templates/scenarios-template.md

@@ -0,0 +1,93 @@
+# Validation Scenarios: [PROJECT_NAME]
+
+**Domain:** [DOMAIN]
+**Date:** [DATE]
+**Slug:** [SLUG]
+**References:** `03_stories_[SLUG].md`, `05_ac_[SLUG].md`, `09_wireframes_[SLUG].md`, `08_apicontract_[SLUG].md`
+
+---
+
+## Scenario Index
+
+| ID | Title | Persona | Priority | Type |
+|----|-------|---------|---------|------|
+| SC-001 | [Title] | [Persona] | P1 | Happy path |
+| SC-002 | [Title] | [Persona] | P2 | Negative |
+| SC-003 | [Title] | [Persona] | P1 | Edge case |
+
+---
+
+## SC-001: [Scenario Title]
+
+**Persona:** [Name and role — e.g. "Alex, a returning customer"]
+**Type:** Happy path | Negative | Edge case | Performance | Security
+**Priority:** P1 (critical) | P2 (important) | P3 (nice to have)
+**Entry point:** [Where the scenario starts — e.g. "Home screen, not logged in"]
+**Platform:** Web | iOS | Android | API
+**Linked Stories:** US-[NNN], US-[NNN]
+**Linked AC:** US-[NNN] Scenario [N]
+
+### Steps
+
+| # | Actor | Action | Expected Result | Ref |
+|---|-------|--------|----------------|-----|
+| 1 | [Persona] | [Does something] | [What happens] | WF-[NNN] |
+| 2 | System | [Responds] | [State changes] | API: `POST /[endpoint]` |
+| 3 | [Persona] | [Continues] | [UI updates] | AC: US-[NNN] S[N] |
+
+### Expected Outcome
+
+[What the final state is when the scenario completes successfully.]
+
+### Failure Conditions
+
+| Condition | Expected Behaviour |
+|-----------|-------------------|
+| [What could go wrong] | [How the system should handle it] |
+
+---
+
+## SC-002: [Scenario Title]
+
+**Persona:** [Persona]
+**Type:** Negative | Happy path | Edge case
+**Priority:** P1 | P2 | P3
+**Entry point:** [Start state]
+**Platform:** [Platform]
+**Linked Stories:** US-[NNN]
+**Linked AC:** US-[NNN] Scenario [N]
+
+### Steps
+
+| # | Actor | Action | Expected Result | Ref |
+|---|-------|--------|----------------|-----|
+| 1 | [Persona] | [Action] | [Result] | WF-[NNN] |
+| 2 | System | [Response] | [State] | |
+
+### Expected Outcome
+
+[Final state after scenario.]
+
+### Failure Conditions
+
+| Condition | Expected Behaviour |
+|-----------|-------------------|
+| [Condition] | [Behaviour] |
+
+<!-- Repeat SC block for each scenario. Numbering: SC-001, SC-002, ... -->
+
+---
+
+## Coverage Summary
+
+| Artifact | Covered | Not Covered |
+|---------|---------|------------|
+| User Stories | [N] / [Total] | US-[NNN], … |
+| Acceptance Criteria Scenarios | [N] / [Total] | |
+| API Endpoints | [N] / [Total] | `[endpoint]`, … |
+| Wireframe screens | [N] / [Total] | WF-[NNN], … |
+
+**Happy path scenarios:** [N]
+**Negative scenarios:** [N]
+**Edge case scenarios:** [N]
+**Total scenarios:** [N]

package/skills/references/templates/sprint-template.md

@@ -0,0 +1,158 @@
+# Sprint Plan: Dragon Fortune
+
+**Domain:** iGaming
+**Date:** 2026-04-08
+**Slug:** dragon-fortune
+**Sprint length:** 2 weeks
+**Team velocity:** 35 SP per sprint
+**Sources:** `00_estimate_dragon-fortune.md`, `03_stories_dragon-fortune.md`, `00_risks_dragon-fortune.md`, `02_srs_dragon-fortune.md`
+
+---
+
+## Summary
+
+| Sprint | Goal | Stories | Points | Capacity |
+|--------|------|:-------:|:------:|:--------:|
+| SP-00 | Setup: environment, CI/CD, Telegram Mini App scaffold | — | — | — |
+| SP-01 | Players can register via Telegram and spin a slot for the first time | 6 | 34 SP | 97% |
+| SP-02 | Players can deposit, withdraw, and view wallet balance | 5 | 32 SP | 91% |
+| SP-03 | Referral programme and bonus mechanics are live | 5 | 30 SP | 86% |
+| SP-04 | Admin panel: player management, game configuration, reporting | 4 | 28 SP | 80% |
+| **Total** | | **20** | **124 SP** | |
+
+**Planned:** 20 stories / 124 SP across 4 sprints (8 weeks)
+**Unplanned backlog:** 4 stories / 18 SP (scope exceeds MVP capacity or marked Could/Won't)
+
+---
+
+## Sprint Details
+
+### SP-00 — Setup and environment
+
+**Duration:** Week 0 (pre-sprint)
+**Capacity:** Setup only — no story points assigned
+
+**Tasks:**
+- Configure CI/CD pipeline (GitHub Actions).
+- Provision staging environment on cloud infrastructure.
+- Scaffold Telegram Mini App project with base authentication stub.
+- Establish database schema baseline from `/datadict`.
+- Team domain onboarding session (iGaming concepts, RTP, KYC flow).
+
+**Definition of Done for SP-00:**
+- [ ] All developers can run the project locally.
+- [ ] Staging environment is accessible via Telegram.
+- [ ] Base CI pipeline runs lint + unit tests on every push.
+
+---
+
+### SP-01 — Players can register via Telegram and spin a slot for the first time
+
+**Duration:** Weeks 1–2
+**Capacity:** 35 SP
+
+| US | Title | Epic | Priority | Risk | Estimate |
+|----|-------|------|---------|------|---------|
+| US-001 | Register via Telegram | E-01 Auth | Must | RISK-02 ↑ | 5 SP |
+| US-002 | Launch slot game from Mini App | E-02 Gameplay | Must | — | 3 SP |
+| US-003 | Execute a spin and see result | E-02 Gameplay | Must | RISK-03 ↑ | 13 SP |
+| US-004 | View current wallet balance | E-03 Wallet | Must | — | 3 SP |
+| US-005 | See responsible gambling session limit warning | E-05 Compliance | Must | — | 5 SP |
+| US-006 | View game history (last 20 spins) | E-02 Gameplay | Should | — | 5 SP |
+
+**Sprint total:** 34 SP / 35 SP capacity (97%)
+
+**Definition of Done for SP-01:**
+- [ ] All stories pass their Acceptance Criteria.
+- [ ] Telegram login tested on iOS and Android Telegram clients.
+- [ ] RNG certified spin result returned in under 200 ms at p95.
+- [ ] No 🔴 Critical open items in `/analyze` for completed stories.
+
+---
+
+### SP-02 — Players can deposit, withdraw, and view wallet balance
+
+**Duration:** Weeks 3–4
+**Capacity:** 35 SP
+
+| US | Title | Epic | Priority | Risk | Estimate |
+|----|-------|------|---------|------|---------|
+| US-007 | Deposit via cryptocurrency | E-03 Wallet | Must | RISK-01 ↑ | 8 SP |
+| US-008 | Deposit via local payment system | E-03 Wallet | Must | RISK-01 ↑ | 8 SP |
+| US-009 | Request withdrawal | E-03 Wallet | Must | — | 8 SP |
+| US-010 | View full transaction history | E-03 Wallet | Should | — | 5 SP |
+| US-011 | Complete KYC identity verification | E-04 Compliance | Must | — | 3 SP |
+
+**Sprint total:** 32 SP / 35 SP capacity (91%)
+
+**Definition of Done for SP-02:**
+- [ ] All stories pass their Acceptance Criteria.
+- [ ] Payment provider sandbox integration verified end-to-end.
+- [ ] KYC flow tested with test credentials from the provider.
+- [ ] Withdrawal processed within 24 h in staging environment.
+
+---
+
+### SP-03 — Referral programme and bonus mechanics are live
+
+**Duration:** Weeks 5–6
+**Capacity:** 35 SP
+
+| US | Title | Epic | Priority | Risk | Estimate |
+|----|-------|------|---------|------|---------|
+| US-012 | Share referral link and earn bonus | E-06 Referrals | Must | RISK-04 ↑ | 8 SP |
+| US-013 | Claim welcome bonus on first deposit | E-06 Referrals | Must | — | 5 SP |
+| US-014 | View active bonuses and wagering progress | E-06 Referrals | Should | — | 5 SP |
+| US-015 | Set self-exclusion period | E-05 Compliance | Must | — | 5 SP |
+| US-016 | Configure deposit limits | E-05 Compliance | Should | — | 7 SP |
+
+**Sprint total:** 30 SP / 35 SP capacity (86%)
+
+**Definition of Done for SP-03:**
+- [ ] All stories pass their Acceptance Criteria.
+- [ ] Fraud scoring on referral payouts is active and logged.
+- [ ] Self-exclusion blocks all game access within 5 minutes of activation.
+
+---
+
+### SP-04 — Admin panel: player management, game configuration, reporting
+
+**Duration:** Weeks 7–8
+**Capacity:** 35 SP
+
+| US | Title | Epic | Priority | Risk | Estimate |
+|----|-------|------|---------|------|---------|
+| US-017 | Admin views player list and profile | E-07 Admin | Must | — | 5 SP |
+| US-018 | Admin adjusts RTP and payline configuration | E-07 Admin | Must | — | 8 SP |
+| US-019 | Admin views revenue and activity report | E-07 Admin | Should | — | 8 SP |
+| US-020 | Admin flags a player account for review | E-07 Admin | Should | — | 7 SP |
+
+**Sprint total:** 28 SP / 35 SP capacity (80%)
+
+**Definition of Done for SP-04:**
+- [ ] All stories pass their Acceptance Criteria.
+- [ ] RTP configuration change takes effect within 1 spin cycle.
+- [ ] Revenue report matches transaction ledger to within 0.01%.
+
+---
+
+## Unplanned Backlog
+
+Stories not assigned to any sprint — below MVP capacity or marked Could/Won't:
+
+| US | Title | Epic | Priority | Estimate | Reason |
+|----|-------|------|---------|---------|--------|
+| US-021 | Export transaction history as PDF | E-03 Wallet | Could | 5 SP | Capacity exceeded — defer to v1.1 |
+| US-022 | Multi-language support (EN / RU / KZ) | E-01 Auth | Could | 8 SP | Deferred — requires i18n infrastructure |
+| US-023 | Live chat support widget | E-08 Support | Could | 3 SP | Deferred — third-party integration |
+| US-024 | Affiliate dashboard | E-06 Referrals | Won't | 2 SP | Out of MVP scope |
+
+---
+
+## Assumptions
+
+- Sprint velocity: 35 SP based on a team of 4 full-stack developers (2 sprints of historical data from similar projects).
+- SP-00 is a pre-sprint setup week; its effort is not tracked in Story Points.
+- Frontend and backend are developed in parallel within each sprint.
+- No hard release deadline was specified; the plan targets an 8-week MVP delivery window.
+- Risk-elevated stories (RISK-01, RISK-02, RISK-03, RISK-04) were pulled into earlier sprints to validate mitigations sooner.