# CS2.WTF Rewrite TODO

## Phase 0 – Kickoff & Research
- [ ] Create and push the `cs2-port` branch from the current default branch.
- [ ] Capture the legacy stack (Vue 3 SPA + Go backend) and existing route map (`/`, `/matches`, `/player/[id]`, `/match/[id]/{economy|details|flashes|damage|chat}`) for reference.
- [ ] Host workshops with stakeholders, shoutcasters, and data consumers to gather CS2-specific requirements (new stats, volumetric smokes, MR12 changes).
- [ ] Audit the `csgowtfd` backend APIs and data models; decide whether to extend or replace services for CS2 telemetry.
- [ ] Document CS2 demo parsing pipeline expectations, storage strategy, and data freshness SLAs.

## Phase 1 – Technical Foundations
- [ ] Standardize on Node.js ≥ 18 (add `.nvmrc` / `.tool-versions`) and npm or yarn (lock the choice in documentation).
- [ ] Scaffold a new SvelteKit project with TypeScript in strict mode and commit the baseline to `cs2-port`.
- [ ] Integrate Tailwind CSS with DaisyUI; configure theme tokens, base styles, and dark/light mode support.
- [ ] Add project tooling: ESLint (with Svelte + TypeScript rules), Prettier, `svelte-check`, Stylelint (for Tailwind), and git hooks via Husky + lint-staged.
- [ ] Configure Vitest for unit/component tests and Playwright for E2E smoke tests (headless + CI modes).
- [ ] Set up Vite aliases, environment variable handling, and TypeScript path mappings for domain-driven organization.
- [ ] Update Woodpecker (or preferred CI) pipelines to run install, lint, type-check, test, and build jobs on every push.

## Phase 2 – Design System & UX Direction
- [ ] Produce a Figma (or Penpot) design system: typography scale, spacing, color ramps, iconography inspired by modern Counter-Strike 2 visuals.
- [ ] Define DaisyUI themes aligned with CS2 branding, including semantic color tokens for teams, utility types, and economy states.
- [ ] Establish responsive layout grids (mobile-first up to ultrawide) and interaction patterns (hover, focus, press states).
- [ ] Design core components: global navigation, search, tabs, data tables, filters, cards, charts, modals, toasts, and timeline elements.
- [ ] Create motion guidelines (micro-interactions, transitions) that reinforce hierarchy without compromising performance.
- [ ] Run accessibility review on mockups (contrast, color blindness variants, keyboard flows).

## Phase 3 – Domain Modeling & Data Layer
- [ ] Define TypeScript interfaces and Zod schemas for CS2 entities: matches, rounds, players, utility events, economy states, chat logs, and metadata.
- [ ] Decide on data access strategy (REST, GraphQL, WebSocket) and outline API contracts with backend engineers.
- [ ] Build a typed API client module with error boundaries, retry/backoff, caching, and cancellation support.
- [ ] Prepare mocked fixtures and MSW handlers for offline development and automated tests.
- [ ] Explore real-time update requirements (live match polling or push) and capture API changes needed on the backend.

## Phase 4 – Application Architecture & Routing
- [ ] Plan a route hierarchy using SvelteKit layouts (`src/routes/+layout.svelte`, `routes/matches/+page.svelte`, nested `routes/match/[id]/+page.svelte`, etc.).
- [ ] Implement the global shell: header, footer, persistent search, language switcher, theme toggle, and notification area.
- [ ] Configure `load` functions, universal load guards, and error/skeleton states per route for resilient UX.
- [ ] Introduce cross-route state management (Svelte stores) for filters, user preferences, and shared data caches.
- [ ] Establish analytics and consent handling architecture compatible with SSR.

## Phase 5 – Feature Delivery (Parity + Enhancements)
- [ ] Home/Dashboard: featured matches, live queue, top performers, and quick filters with real-time indicators.
- [ ] Matches Index: searchable, filterable list with virtualized tables, map/side filters, rank tiers, and date range pickers.
- [ ] Player Profile (`/player/[id]`): career summary, map win rates, weapon performance, clutch stats, and timeline cards.
- [ ] Match Overview (`/match/[id]`): scoreboard, round-by-round timeline, win probability graph, and MR12 adjustments.
- [ ] Economy View: spend/equipment charts, save rounds, utility purchases, and loss-bonus visualization.
- [ ] Utility/Flashes View: breakdown of utility effectiveness, pop flash timings, volumetric smoke coverage (heatmap/webgl overlays).
- [ ] Damage View: per-round damage charts, headshot percentages, spatial heatmaps using Canvas/WebGL.
- [ ] Chat View: chronological chat feed with role badges, highlight detection, and translation toggle.
- [ ] Introduce CS2-exclusive insights (sky smoke bloom, loadout value changes, new grenade types) and align labels accordingly.
- [ ] Add sharing/export features (downloadable stats, social cards) respecting privacy constraints.

## Phase 6 – Localization & Personalization
- [ ] Integrate `sveltekit-i18n` (or equivalent) for multi-language support, starting with English plus priority locales.
- [ ] Externalize all copy into translation files, including validation messages and chart labels.
- [ ] Persist language preference (cookie/localStorage) and sync with SSR.
- [ ] Localize formatting (dates, currency, ranks) using `Intl` APIs and server-aware utilities.
- [ ] Provide user preference storage for theme, metric units, and favorite players/teams.

## Phase 7 – Performance, Accessibility & Observability
- [ ] Define and enforce performance budgets (LCP ≤ 2.5s, CLS ≤ 0.1, TTI ≤ 4s) with automated Lighthouse checks.
- [ ] Optimize assets: code splitting, prefetching strategies, image/CDN pipeline, and font loading.
- [ ] Implement progressive enhancement for charts/tables and graceful degradation when JS is disabled.
- [ ] Add runtime error monitoring (e.g., Sentry), structured logging, and privacy-aware analytics.
- [ ] Conduct comprehensive accessibility audits with axe, manual keyboard testing, and screen reader passes.

## Phase 8 – Testing & Quality Assurance
- [ ] Write unit tests for components, stores, and utilities (Vitest + Testing Library).
- [ ] Develop integration/E2E scenarios (Playwright) covering match search, player view, and match detail tabs.
- [ ] Set up visual regression snapshots for critical pages via Playwright or Loki.
- [ ] Build load-testing scripts for APIs powering live dashboards (k6 or artillery).
- [ ] Coordinate QA playbook: test matrices, release checklists, and bug triage workflow.

## Phase 9 – Deployment & Release Strategy
- [ ] Choose hosting strategy (Node SSR on Fly.io/Vercel/Render or self-hosted) and provision staging/production environments.
- [ ] Configure CI/CD deployment pipelines with environment promotion gates and feature flag toggles.
- [ ] Establish secrets management (e.g., Doppler, Vault, SSM) for API keys and telemetry tokens.
- [ ] Plan data migration/backfill from CS:GO to CS2, including schema evolution and archive policies.
- [ ] Organize beta program, feedback channels, and phased rollout (legacy vs CS2 opt-in).

## Phase 10 – Documentation & Handover
- [ ] Update `README.md` with setup, development, testing, and deployment instructions for CS2.WTF.
- [ ] Create architecture decision records (ADRs) for key choices (SvelteKit adoption, data strategy, hosting).
- [ ] Document API contracts, rate limits, and error semantics in an accessible format (OpenAPI + human-readable docs).
- [ ] Prepare contributor guidelines, coding standards, and project board workflow.
- [ ] Schedule knowledge transfer sessions and record walkthrough videos for onboarding.

## Stretch Goals
- [ ] Add authenticated user features: saved searches, match alerts, personalized dashboards.
- [ ] Offer real-time live match viewer with timeline scrubbing and auto-updating stats.
- [ ] Deliver PWA enhancements (offline read-only cache, push notifications when favorites go live).
- [ ] Explore integrations with tournament APIs (Valve, HLTV, FACEIT) to enrich match context.