diff --git a/.planning/REQUIREMENTS.md b/.planning/REQUIREMENTS.md index 97ce2b6..a242f48 100644 --- a/.planning/REQUIREMENTS.md +++ b/.planning/REQUIREMENTS.md @@ -271,13 +271,161 @@ Which phases cover which requirements. Updated during roadmap creation. | Requirement | Phase | Status | |-------------|-------|--------| -| (Populated during roadmap creation) | | | +| ARCH-01 | Phase 1 | Pending | +| ARCH-02 | Phase 1 | Pending | +| ARCH-03 | Phase 1 | Pending | +| ARCH-04 | Phase 1 | Pending | +| ARCH-05 | Phase 1 | Pending | +| ARCH-06 | Phase 1 | Pending | +| ARCH-07 | Phase 1 | Pending | +| ARCH-08 | Phase 1 | Pending | +| AUTH-01 | Phase 1 | Pending | +| AUTH-02 | Phase 1 | Pending | +| AUTH-03 | Phase 1 | Pending | +| AUTH-04 | Phase 1 | Pending | +| AUTH-05 | Phase 1 | Pending | +| AUTH-06 | Phase 1 | Pending | +| AUTH-07 | Phase 1 | Pending | +| AUTH-08 | Phase 1 | Pending | +| AUTH-09 | Phase 1 | Pending | +| NET-01 | Phase 1 | Pending | +| NET-02 | Phase 1 | Pending | +| NET-03 | Phase 1 | Pending | +| NET-04 | Phase 1 | Pending | +| NET-05 | Phase 1 | Pending | +| NET-06 | Phase 1 | Pending | +| NET-07 | Phase 1 | Pending | +| PLAT-01 | Phase 2 | Pending | +| PLAT-02 | Phase 2 | Pending | +| PLAT-03 | Phase 2 | Pending | +| PLAT-04 | Phase 2 | Pending | +| PLAT-05 | Phase 2 | Pending | +| PLAT-06 | Phase 2 | Pending | +| SYNC-01 | Phase 2 | Pending | +| SYNC-02 | Phase 2 | Pending | +| SYNC-03 | Phase 2 | Pending | +| SYNC-04 | Phase 2 | Pending | +| EXPORT-01 | Phase 2 | Pending | +| EXPORT-02 | Phase 2 | Pending | +| EXPORT-03 | Phase 2 | Pending | +| EXPORT-04 | Phase 2 | Pending | +| CLOCK-01 | Phase 3 | Pending | +| CLOCK-02 | Phase 3 | Pending | +| CLOCK-03 | Phase 3 | Pending | +| CLOCK-04 | Phase 3 | Pending | +| CLOCK-05 | Phase 3 | Pending | +| CLOCK-06 | Phase 3 | Pending | +| CLOCK-07 | Phase 3 | Pending | +| CLOCK-08 | Phase 3 | Pending | +| CLOCK-09 | Phase 3 | Pending | +| BLIND-01 | Phase 3 | Pending | +| BLIND-02 | Phase 3 | Pending | +| BLIND-03 | Phase 3 | Pending | +| BLIND-04 | Phase 3 | Pending | +| BLIND-05 | Phase 3 | Pending | +| BLIND-06 | Phase 3 | Pending | +| CHIP-01 | Phase 3 | Pending | +| CHIP-02 | Phase 3 | Pending | +| CHIP-03 | Phase 3 | Pending | +| CHIP-04 | Phase 3 | Pending | +| MULTI-01 | Phase 3 | Pending | +| MULTI-02 | Phase 3 | Pending | +| FIN-01 | Phase 4 | Pending | +| FIN-02 | Phase 4 | Pending | +| FIN-03 | Phase 4 | Pending | +| FIN-04 | Phase 4 | Pending | +| FIN-05 | Phase 4 | Pending | +| FIN-06 | Phase 4 | Pending | +| FIN-07 | Phase 4 | Pending | +| FIN-08 | Phase 4 | Pending | +| FIN-09 | Phase 4 | Pending | +| FIN-10 | Phase 4 | Pending | +| FIN-11 | Phase 4 | Pending | +| FIN-12 | Phase 4 | Pending | +| FIN-13 | Phase 4 | Pending | +| FIN-14 | Phase 4 | Pending | +| PLYR-01 | Phase 5 | Pending | +| PLYR-02 | Phase 5 | Pending | +| PLYR-03 | Phase 5 | Pending | +| PLYR-04 | Phase 5 | Pending | +| PLYR-05 | Phase 5 | Pending | +| PLYR-06 | Phase 5 | Pending | +| PLYR-07 | Phase 5 | Pending | +| SEAT-01 | Phase 5 | Pending | +| SEAT-02 | Phase 5 | Pending | +| SEAT-03 | Phase 5 | Pending | +| SEAT-04 | Phase 5 | Pending | +| SEAT-05 | Phase 5 | Pending | +| SEAT-06 | Phase 5 | Pending | +| SEAT-07 | Phase 5 | Pending | +| SEAT-08 | Phase 5 | Pending | +| SEAT-09 | Phase 5 | Pending | +| UI-01 | Phase 6 | Pending | +| UI-02 | Phase 6 | Pending | +| UI-03 | Phase 6 | Pending | +| UI-04 | Phase 6 | Pending | +| UI-05 | Phase 6 | Pending | +| UI-06 | Phase 6 | Pending | +| UI-07 | Phase 6 | Pending | +| UI-08 | Phase 6 | Pending | +| DISP-01 | Phase 7 | Pending | +| DISP-02 | Phase 7 | Pending | +| DISP-03 | Phase 7 | Pending | +| DISP-04 | Phase 7 | Pending | +| DISP-05 | Phase 7 | Pending | +| DISP-06 | Phase 7 | Pending | +| DISP-07 | Phase 7 | Pending | +| DISP-08 | Phase 7 | Pending | +| DISP-09 | Phase 7 | Pending | +| DISP-10 | Phase 7 | Pending | +| PWA-01 | Phase 8 | Pending | +| PWA-02 | Phase 8 | Pending | +| PWA-03 | Phase 8 | Pending | +| PWA-04 | Phase 8 | Pending | +| PWA-05 | Phase 8 | Pending | +| PWA-06 | Phase 8 | Pending | +| PWA-07 | Phase 8 | Pending | +| PWA-08 | Phase 8 | Pending | +| PWA-09 | Phase 8 | Pending | +| PWA-10 | Phase 8 | Pending | +| SIGN-01 | Phase 9 | Pending | +| SIGN-02 | Phase 9 | Pending | +| SIGN-03 | Phase 9 | Pending | +| SIGN-04 | Phase 9 | Pending | +| SIGN-05 | Phase 9 | Pending | +| SIGN-06 | Phase 9 | Pending | +| SIGN-07 | Phase 9 | Pending | +| SIGN-08 | Phase 9 | Pending | +| SIGN-09 | Phase 9 | Pending | +| SIGN-10 | Phase 9 | Pending | +| EVENT-01 | Phase 9 | Pending | +| EVENT-02 | Phase 9 | Pending | +| EVENT-03 | Phase 9 | Pending | +| EVENT-04 | Phase 9 | Pending | +| LEAGUE-01 | Phase 10 | Pending | +| LEAGUE-02 | Phase 10 | Pending | +| LEAGUE-03 | Phase 10 | Pending | +| LEAGUE-04 | Phase 10 | Pending | +| LEAGUE-05 | Phase 10 | Pending | +| LEAGUE-06 | Phase 10 | Pending | +| REGION-01 | Phase 10 | Pending | +| REGION-02 | Phase 10 | Pending | +| REGION-03 | Phase 10 | Pending | +| REGION-04 | Phase 10 | Pending | +| REGION-05 | Phase 10 | Pending | +| TDD-01 | Phase 11 | Pending | +| TDD-02 | Phase 11 | Pending | +| TDD-03 | Phase 11 | Pending | +| TDD-04 | Phase 11 | Pending | +| TDD-05 | Phase 11 | Pending | +| TDD-06 | Phase 11 | Pending | +| TDD-07 | Phase 11 | Pending | **Coverage:** - v1 requirements: 126 total -- Mapped to phases: 0 -- Unmapped: 126 +- Mapped to phases: 126 +- Unmapped: 0 --- *Requirements defined: 2026-02-28* -*Last updated: 2026-02-28 after initial definition* +*Last updated: 2026-02-28 — traceability populated after roadmap creation* diff --git a/.planning/ROADMAP.md b/.planning/ROADMAP.md new file mode 100644 index 0000000..65e776a --- /dev/null +++ b/.planning/ROADMAP.md @@ -0,0 +1,178 @@ +# Roadmap: Felt + +## Overview + +Felt is built in 11 phases, all scoped to Development Phase 1 (Live Tournament Management). The build order is constraint-driven: infrastructure and data model correctness must be established before any domain logic, domain logic before frontend, frontend before displays, and the TDD migration weapon last — delivered just before launch when there is a complete system to migrate into. Each phase delivers one coherent, independently verifiable capability. + +## Phases + +**Phase Numbering:** +- Integer phases (1, 2, 3): Planned milestone work +- Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED) + +Decimal phases appear between their surrounding integers in numeric order. + +- [ ] **Phase 1: Foundation** - Go monorepo, Leaf binary, embedded NATS + LibSQL, Netbird mesh, Authentik OIDC, CI with ARM64 cross-compilation +- [ ] **Phase 2: Platform Identity & Sync** - Platform-level player profiles, NATS Leaf-to-Core sync, Core PostgreSQL with RLS, export formats +- [ ] **Phase 3: Tournament Engine** - Clock, blind structures, chip management, multi-tournament support +- [ ] **Phase 4: Financial Engine** - Buy-ins, rebuys, add-ons, bounties, prize pool, payouts, chop/deal, receipts +- [ ] **Phase 5: Player & Table Management** - Player database, registration flows, bust-out, seating, auto-balancing, hand-for-hand +- [ ] **Phase 6: Operator UI** - Mobile-first SvelteKit interface, dark theme, FAB, data tables, toast notifications +- [ ] **Phase 7: Display System** - Wireless display node registry, view assignment, tournament views, theming, screen cycling +- [ ] **Phase 8: Player Mobile PWA** - QR code access, live clock, rankings, personal stats, WebSocket real-time, add-to-home +- [ ] **Phase 9: Digital Signage & Events Engine** - Content editor, AI assist, scheduling, event rules, automation triggers +- [ ] **Phase 10: League, Season & Regional Tournaments** - Point formulas, standings, cross-venue tournaments, finals management +- [ ] **Phase 11: TDD Migration** - Full TDD XML import, player database migration, tournament history, wizard, zero data loss + +## Phase Details + +### Phase 1: Foundation +**Goal**: The Leaf binary runs on ARM64, passes CI, and provides the infrastructure skeleton every subsequent phase builds on +**Depends on**: Nothing (first phase) +**Requirements**: ARCH-01, ARCH-02, ARCH-03, ARCH-04, ARCH-05, ARCH-06, ARCH-07, ARCH-08, AUTH-01, AUTH-02, AUTH-03, AUTH-04, AUTH-05, AUTH-06, AUTH-07, AUTH-08, AUTH-09, NET-01, NET-02, NET-03, NET-04, NET-05, NET-06, NET-07 +**Success Criteria** (what must be TRUE): + 1. A single Go binary (`cmd/leaf`) builds for ARM64 via CI with CGO enabled and LibSQL linked, with zero manual steps + 2. The Leaf binary starts on an Orange Pi 5 Plus, serves HTTP, connects embedded NATS JetStream and LibSQL, and survives a simulated power failure without data loss (NATS sync_interval: always verified) + 3. An operator can log in with a PIN (offline) or OIDC via Authentik (online) and receive a JWT with their role (Admin/Floor/Viewer) + 4. A display node and a player browser can reach the Leaf from outside the local network via HTTPS through the Netbird reverse proxy + 5. Every state-changing action writes an append-only audit trail entry readable from the database +**Plans**: TBD + +### Phase 2: Platform Identity & Sync +**Goal**: Players are platform-level Felt entities with cross-venue portable profiles, and tournament events flow from Leaf to Core with guaranteed delivery +**Depends on**: Phase 1 +**Requirements**: PLAT-01, PLAT-02, PLAT-03, PLAT-04, PLAT-05, PLAT-06, SYNC-01, SYNC-02, SYNC-03, SYNC-04, EXPORT-01, EXPORT-02, EXPORT-03, EXPORT-04 +**Success Criteria** (what must be TRUE): + 1. A player created on one Leaf appears on Core with the same UUID and profile data after reconnect, with no duplicates + 2. Tournament events published on Leaf while offline queue in NATS JetStream and replay to Core in order when connectivity is restored + 3. Core never overwrites Leaf data for a tournament that is currently running + 4. A player can request and download a JSON export of all their personal data (GDPR portability) + 5. A completed tournament exports to CSV, JSON, and HTML with correct data and venue branding applied +**Plans**: TBD + +### Phase 3: Tournament Engine +**Goal**: A complete tournament clock and blind structure runs from start to finish with all operational controls an operator needs +**Depends on**: Phase 1 +**Requirements**: CLOCK-01, CLOCK-02, CLOCK-03, CLOCK-04, CLOCK-05, CLOCK-06, CLOCK-07, CLOCK-08, CLOCK-09, BLIND-01, BLIND-02, BLIND-03, BLIND-04, BLIND-05, BLIND-06, CHIP-01, CHIP-02, CHIP-03, CHIP-04, MULTI-01, MULTI-02 +**Success Criteria** (what must be TRUE): + 1. The clock counts down each level with second-granularity display, transitions automatically to the next level or break, and emits warning alerts at configurable thresholds + 2. An operator can pause, resume, jump to any level, and advance forward or backward; all connected clients reflect the change within 100ms + 3. A blind structure with mixed-game rotation, big-blind antes, and chip-up breaks can be saved as a template and loaded into any new tournament + 4. The structure wizard produces a playable blind structure from player count, duration, starting chips, and denomination inputs + 5. Two tournaments run simultaneously on the same Leaf with independent clocks, financials, and player tracking +**Plans**: TBD + +### Phase 4: Financial Engine +**Goal**: All tournament money flows are tracked with integer-only arithmetic, full receipts, and a complete payout calculation from first buy-in to final chop +**Depends on**: Phase 3 +**Requirements**: FIN-01, FIN-02, FIN-03, FIN-04, FIN-05, FIN-06, FIN-07, FIN-08, FIN-09, FIN-10, FIN-11, FIN-12, FIN-13, FIN-14 +**Success Criteria** (what must be TRUE): + 1. A CI gate test verifies that the sum of individual payouts always equals the prize pool total — zero floating-point deviation possible + 2. A complete buy-in, rebuy, add-on, and bounty flow produces a transaction log where every event is a receipt with operator, timestamp, and previous/new state + 3. Prize pool auto-calculates correctly from all financial inputs including guaranteed pot shortfall and end-of-season withholding + 4. The ICM calculator, chip-chop, and custom deal-making flows produce payout splits that sum exactly to the prize pool + 5. An operator can edit a financial transaction with a reason; the audit trail shows both the original and corrected entries +**Plans**: TBD + +### Phase 5: Player & Table Management +**Goal**: Operators can register, seat, track, and bust players through a complete tournament with automatic balancing and full action history +**Depends on**: Phase 4 +**Requirements**: PLYR-01, PLYR-02, PLYR-03, PLYR-04, PLYR-05, PLYR-06, PLYR-07, SEAT-01, SEAT-02, SEAT-03, SEAT-04, SEAT-05, SEAT-06, SEAT-07, SEAT-08, SEAT-09 +**Success Criteria** (what must be TRUE): + 1. An operator can search by name with typeahead, select a player, process a buy-in, and have the player auto-seated — all within a single touch flow + 2. Busting a player triggers hitman selection, bounty transfer, auto-ranking, and a rebalancing proposal; the operator confirms before any seats move + 3. The auto-balancing algorithm never produces invalid seating (validated against TDA Rules 25-28 edge cases: last 2-player table, button position, blinds position, locked players) + 4. Any bust-out, rebuy, or buy-in can be undone with full re-ranking and table state restoration + 5. A QR code per player enables self-check-in; scanning it opens the player's registration flow +**Plans**: TBD + +### Phase 6: Operator UI +**Goal**: The complete operator experience is a mobile-first, dark-room-ready SvelteKit interface that surfaces all engine capabilities with TDD-depth and modern UX +**Depends on**: Phase 5 +**Requirements**: UI-01, UI-02, UI-03, UI-04, UI-05, UI-06, UI-07, UI-08 +**Success Criteria** (what must be TRUE): + 1. An operator running a tournament on a phone can access every runtime action (bust, buy-in, rebuy, add-on, pause/resume) without navigating away from the current screen, using the FAB + 2. The persistent header shows current clock, level, blinds, and player count at all times across all tabs + 3. All touch targets are at least 48px; the interface is usable in a dark room without eye strain (Catppuccin Mocha) + 4. On a laptop or desktop, the sidebar navigation is visible and the content area is wider — same codebase, responsive layout + 5. Data tables support sort, sticky headers, and search/filter; swipe actions work on mobile +**Plans**: TBD + +### Phase 7: Display System +**Goal**: Wireless display nodes connect, receive view assignments, and show tournament data readable from 10+ feet — without HDMI cables +**Depends on**: Phase 6 +**Requirements**: DISP-01, DISP-02, DISP-03, DISP-04, DISP-05, DISP-06, DISP-07, DISP-08, DISP-09, DISP-10 +**Success Criteria** (what must be TRUE): + 1. A Pi Zero 2W display node connects to the Leaf via WebSocket, appears in the node registry with name, status, and current view, and the operator can reassign its view without touching the device + 2. All tournament views (Clock, Rankings, Seating, Blind Schedule, Final Table, Prize Pool, Lobby) render correctly and are readable from 10+ feet at common TV resolutions + 3. Display nodes auto-scale font size to resolution; no overflow or truncation on any supported resolution + 4. Screen cycling with configurable rotation runs automatically; the operator can override or lock any screen to a specific view + 5. A Pi Zero 2W running all display views stays within 450MB memory for 8+ hours without crash or restart (validated on actual hardware) +**Plans**: TBD + +### Phase 8: Player Mobile PWA +**Goal**: Any player with a phone can scan a QR code and get live tournament data — clock, rankings, blinds, prize pool — with no app install and no login +**Depends on**: Phase 7 +**Requirements**: PWA-01, PWA-02, PWA-03, PWA-04, PWA-05, PWA-06, PWA-07, PWA-08, PWA-09, PWA-10 +**Success Criteria** (what must be TRUE): + 1. A player scans a QR code at the venue entrance and sees live clock, current blinds, and next level within 3 seconds — no account required + 2. The PWA stays live during a tournament: WebSocket updates arrive within 100ms; if disconnected, the PWA auto-reconnects and falls back to polling + 3. A player can claim personal status (their seat, points) by entering a 6-digit PIN — no email or app account needed + 4. The PWA prompts "Add to Home Screen" on both iOS and Android; launching from home screen works offline for the last-known state + 5. Players can view league standings and upcoming tournaments without any authentication +**Plans**: TBD + +### Phase 9: Digital Signage & Events Engine +**Goal**: Venue screens show scheduled content between tournaments and the events engine automates visual and audio responses to tournament moments +**Depends on**: Phase 7 +**Requirements**: SIGN-01, SIGN-02, SIGN-03, SIGN-04, SIGN-05, SIGN-06, SIGN-07, SIGN-08, SIGN-09, SIGN-10, EVENT-01, EVENT-02, EVENT-03, EVENT-04 +**Success Criteria** (what must be TRUE): + 1. An operator creates a promo card with the WYSIWYG editor, uses AI text generation to produce content, schedules it to run on specific screens at specific times, and it appears without any manual intervention + 2. Screens automatically switch to tournament clock view when a tournament starts and revert to the signage playlist when it ends — without operator action + 3. An event rule triggers a sound and a display message when the final table is reached; the operator created the rule via the visual builder without writing code + 4. Different screens show different content simultaneously (e.g., screen 1 shows sponsor ad, screen 2 shows league table) + 5. All signage content bundles are stored on Leaf as static HTML/CSS/JS and render in Chromium kiosk without internet +**Plans**: TBD + +### Phase 10: League, Season & Regional Tournaments +**Goal**: Venues can run structured leagues with configurable point formulas and season standings, and anyone can create cross-venue tournaments using the free-tier regional organizer +**Depends on**: Phase 8 +**Requirements**: LEAGUE-01, LEAGUE-02, LEAGUE-03, LEAGUE-04, LEAGUE-05, LEAGUE-06, REGION-01, REGION-02, REGION-03, REGION-04, REGION-05 +**Success Criteria** (what must be TRUE): + 1. An operator configures a league with a custom point formula, tests it against sample placements with the formula tester, and sees the distribution graph before saving + 2. Season standings update automatically after each tournament result; the operator can configure best-N-of-M counting and minimum attendance requirements + 3. League standings display on a dedicated display node view, updating live as tournament results arrive + 4. A regional organizer (free-tier user) creates a cross-venue tournament, adds qualifying events at participating venues, and the unified leaderboard updates automatically from each venue's results + 5. A finals event is managed through the platform with aggregated qualifying results feeding directly into the finals seeding +**Plans**: TBD + +### Phase 11: TDD Migration +**Goal**: Any venue running The Tournament Director can import their complete history — blind structures, players, results, leagues — and start using Felt on day one with zero data loss +**Depends on**: Phase 10 +**Requirements**: TDD-01, TDD-02, TDD-03, TDD-04, TDD-05, TDD-06, TDD-07 +**Success Criteria** (what must be TRUE): + 1. An operator drops a TDD XML export file into the import wizard and sees a preview of all detected blind structures, players, tournaments, and leagues before committing + 2. All blind structures and payout tables import with exact value preservation — no rounding, no data loss + 3. The player database imports with name matching that detects likely duplicates and prompts the operator to confirm merges before writing + 4. Complete tournament history (results, payouts, bust-out order) appears in Felt as if it were run there — full search, export, and league calculation work on imported data + 5. A venue that has used TDD for 5 years can import their full history and see complete league standings with accurate historical point calculations on day one +**Plans**: TBD + +## Progress + +**Execution Order:** +Phases execute in numeric order: 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9 → 10 → 11 + +| Phase | Plans Complete | Status | Completed | +|-------|----------------|--------|-----------| +| 1. Foundation | 0/TBD | Not started | - | +| 2. Platform Identity & Sync | 0/TBD | Not started | - | +| 3. Tournament Engine | 0/TBD | Not started | - | +| 4. Financial Engine | 0/TBD | Not started | - | +| 5. Player & Table Management | 0/TBD | Not started | - | +| 6. Operator UI | 0/TBD | Not started | - | +| 7. Display System | 0/TBD | Not started | - | +| 8. Player Mobile PWA | 0/TBD | Not started | - | +| 9. Digital Signage & Events Engine | 0/TBD | Not started | - | +| 10. League, Season & Regional Tournaments | 0/TBD | Not started | - | +| 11. TDD Migration | 0/TBD | Not started | - | diff --git a/.planning/STATE.md b/.planning/STATE.md new file mode 100644 index 0000000..7671695 --- /dev/null +++ b/.planning/STATE.md @@ -0,0 +1,66 @@ +# Project State + +## Project Reference + +See: .planning/PROJECT.md (updated 2026-02-28) + +**Core value:** A venue can run a complete tournament offline on a €100 device with wireless displays and player mobile access — and it just works, on any network, with zero IT involvement. +**Current focus:** Phase 1 — Foundation + +## Current Position + +Phase: 1 of 11 (Foundation) +Plan: 0 of TBD in current phase +Status: Ready to plan +Last activity: 2026-02-28 — Roadmap created (11 phases, 126 v1 requirements mapped) + +Progress: [░░░░░░░░░░] 0% + +## Performance Metrics + +**Velocity:** +- Total plans completed: 0 +- Average duration: - +- Total execution time: 0 hours + +**By Phase:** + +| Phase | Plans | Total | Avg/Plan | +|-------|-------|-------|----------| +| - | - | - | - | + +**Recent Trend:** +- Last 5 plans: none yet +- Trend: - + +*Updated after each plan completion* + +## Accumulated Context + +### Decisions + +Decisions are logged in PROJECT.md Key Decisions table. +Recent decisions affecting current work: + +- [Init]: Go monorepo, shared `internal/`, `cmd/leaf` and `cmd/core` are the only divergence points +- [Init]: NATS sync_interval: always required before first deploy (December 2025 Jepsen finding) +- [Init]: All monetary values int64 cents — never float64 (CI gate test required) +- [Init]: go-libsql has no tagged releases — pin to commit hash in go.mod +- [Init]: Netbird reverse proxy is beta — validate player PWA access in Phase 1 before depending on it in Phase 8 + +### Pending Todos + +None yet. + +### Blockers/Concerns + +- [Phase 1]: go-libsql CGO ARM64 cross-compilation must be validated in CI before any downstream features depend on it +- [Phase 1]: Netbird reverse proxy beta status — test the full QR code → HTTPS → WireGuard → Leaf flow early +- [Phase 3]: NATS JetStream cross-domain stream mirroring (Leaf → Core) needs integration test before Phase 2 depends on it +- [Phase 7]: Pi Zero 2W memory must be profiled on actual hardware with all display views before scaling signage + +## Session Continuity + +Last session: 2026-02-28 +Stopped at: Roadmap created, STATE.md initialized — ready to begin Phase 1 planning +Resume file: None