TwoMore Roadmap Implementation Plan
Status: Active Last reviewed: 2026-06-29
This document is the concrete build plan under the TwoMore Roadmap. The roadmap owns sequence and outcomes. This plan owns the implementation slices, source inputs, acceptance proof, and verification ladder for each roadmap track.
Use this with:
- Roadmap for track order, status, outcomes, and replanning rules.
- R1 Activation Source Pack for the accepted source-grounded onboarding, club discovery, invite, share, deep-link, and
club_growthinventory. - Product Spec Sheet for product scope and persona boundaries.
- App Functionality Map for the current tab, feature, and backend capability map.
- Sports Club Administration Opportunity Audit for the club-admin market thesis behind R2.
- Current Project State for generated repository facts.
- Current Documentation State for doc authority and hygiene.
- Change Routing Workflow for what to update when a slice changes code, docs, tests, or launch gates.
Implementation Plan Contract
Every executable slice must state:
| Field | Requirement |
|---|---|
| Slice ID | Stable ID shaped as R<track>-<number> |
| Status | Planned, Ready, Active, Blocked, Accepted, or Held |
| Primary artifact | The one thing the slice is expected to produce |
| Allowed surfaces | Docs, packages, routes, scripts, or external systems in scope |
| Blocked scope | Work that must not be pulled into the slice |
| Start condition | Evidence or prerequisite required before implementation starts |
| Acceptance proof | Concrete proof that the slice is done |
| Verification | Commands, tests, smoke paths, or external sign-off required |
| Stop condition | When the agent must stop instead of expanding scope |
| Deferral rule | Where useful but non-blocking findings are recorded |
| Handoff output | What a future agent or reviewer should be able to read afterward |
Do not start a slice unless its start condition is true. If implementation reveals a second primary artifact, split the slice before continuing.
Before editing, the agent must state the active slice, current blocker, allowed surfaces, blocked scope, acceptance proof, verification ladder, and stop condition. A broad instruction such as "keep going with the goal" is not enough to expand scope; adjacent findings are deferred unless they block the active acceptance proof.
Use Execute A Roadmap Slice when opening or resuming a build session.
Current Sequence Focus
| Position | Track | Focus slice | Default next action |
|---|---|---|---|
| Active | R1 Club Growth Loop | — | Closure-only: remove one current R1 blocker at a time, or prove it is owner/vendor/deployment-controlled |
| Active | R2 Organizer Operations | — | R2-0..R2-4 delivered; owner acceptance pending. R2-5 gated on that acceptance |
| Focus | R3 Product Polish & Optimization | R3-6 | R3-0/1/3/4/6 delivered (UX audit + Waves 1-5 + engineering soundness). Next: install 0.7.0 → advance OTA baseline, owner acceptance, then R3-2 perf + R3-5 RC packet |
| Final gate | R4 Launch Readiness Final Gate | — | Run only after R1-R3 evidence is accepted |
| Gated / held | R5-R9 | — | Keep as planning scaffolds until the tripwires in each track are met |
R1 Club Growth Loop - Active
Goal: a new or invited player can reach useful play quickly, and a club can grow through shareable flows.
| Slice | Status | Primary artifact | Start condition | Acceptance proof | Verification |
|---|---|---|---|---|---|
| R1-0 Activation source pack | Accepted | Source-grounded inventory of current onboarding, club discovery, invite, share, and club_growth paths | None | Exact route/surface list, current code owners, known gaps, and test entry points are recorded in the slice handoff | yarn docs:check |
| R1-1 Intent-aware onboarding routing | Accepted | Pure onboarding-intent resolver plus mobile root auth-gate handoff | R1-0 accepted | New player, club member, admin, pickup host, invitee, and safe next link intents resolve to non-dead-end destinations | yarn workspace @twomore/app test src/navigation/onboarding-intent.test.ts --runInBand; yarn check |
| R1-2 Club discovery and creation first-session loop | Accepted | Server-enforced zero-club path from discover/create to first club or session action | R1-0 accepted; R1-1 accepted | A zero-club user can find or create a club and reach a first club/session CTA in one coherent flow without bypassing join policy | Join RPC migration applied and smoke-tested; affected hook/adapter tests; seeded scenario smoke; preview OTA artifact for client changes; UI/device smoke; yarn check |
| R1-3 Share and deep-link activation | Active | Kakao/share/deep-link preview integration for club/session/profile share routes | Domain and Kakao-template constraints are known | Shared session, club, profile, and leaderboard links open useful web previews and app routes | Share route/card tests; web build/smoke for /s, /m, /p, /lb; yarn check:r1-kakao-share; Kakao-native smoke when credentials/build exist; app-link build proof when native config changes; yarn check:r1-release-readiness:eas; yarn check |
| R1-4 Club-growth hosted smoke | Planned | Consolidated hosted R1 evidence packet | R1-1 through R1-3 accepted or explicitly deferred | Hosted or device-level evidence proves discovery, join/apply, create-club first-session, and share/deep-link return paths | yarn check:r1-evidence-workflow; yarn check:r1-release-readiness:eas; cd apps/mobile && eas workflow:run .eas/workflows/maestro-r1-evidence-rerun.yml -F build_id=<id>; yarn check |
R1 Closure Mode
R1 is no longer an open-ended improvement track. R1 work is allowed only when it directly removes one blocker from yarn report:r1-release-readiness or proves that blocker is owner/vendor/deployment-controlled.
External credentials, live-domain deployment, and platform build/device proof are deferred to Production Readiness and R4 by owner decision on 2026-06-29. Keep yarn report:r1-release-readiness in the handoff loop so these gates stay visible, but do not spend R1 source-work cycles trying to close items that require Apple/Kakao credentials, DNS or hosting changes, EAS credential/build authority, iOS device access, Android/iOS app-link device smoke, or preview-native compatibility baseline advancement. Those gates remain real launch blockers; they are not solved and must not be described as accepted until the R4 production-readiness packet proves them.
yarn report:r1-release-readiness classifies these specific external gates as DEFERRED (R4), not BLOCKED, so R1 source readiness reads green while the gates stay listed with their owner/vendor/platform reason. This is a reclassification of development stage, not a resolution: the gates still appear in every report, still live in External Blockers Register and Pre-launch Checklist, and a failing source contract (anything not on the deferred list) still reports BLOCKED and exits non-zero.
Allowed R1 closure work:
- app-link credential proof;
- Kakao template/native proof;
- compatible Android/iOS preview builds;
- iOS/Android device or hosted smoke for share/deep-link return;
- consolidated R1 evidence packet;
- evidence docs that record one of the above.
Blocked R1 closure scope:
- docs reorganization;
- generic release-tool improvements;
- product polish;
- performance work;
- R2/R3 planning;
- opportunistic refactors.
Required start evidence:
yarn report:r1-release-readinessRequired close evidence:
yarn report:r1-release-readinessUse yarn check only after source changes or before pushing source changes. Do not run broad checks repeatedly while the active blocker is external.
Default R1 closure sessions stop after one blocker. If the user explicitly asks for unattended R1 closure while away, the agent may loop through R1 blockers without waiting for a new prompt, but each iteration must still select one blocker from yarn report:r1-release-readiness, state a session contract, run targeted verification, update release evidence when artifacts are created, and commit/push explicit paths before moving to the next blocker.
Unattended R1 closure must hard-stop when the remaining work requires owner credentials, vendor-console changes, MFA/login, device access, DNS/app-link hosting changes, App Store / Play Store action, production artifacts, destructive data changes, unrelated dirty work that cannot be safely preserved, or a blocker that fails three times for the same root cause.
Current R1-2 acceptance checkpoint, 2026-06-28: join policy now lives at the database/RPC boundary, the linked preview Supabase project is migrated through 00305, club_growth has deterministic invite/open/approval fixtures, preview OTA group 28950118-aeca-42a3-8de1-ec3e9df218e6 plus hosted rerun 019f0b37-4a40-7eff-8727-d31d22a43a43 prove the enabled invite/open/approval join suite, and preview OTA group ff478b2e-4058-49ce-8d0d-333b66eabaa9 plus hosted workflow 019f0bb1-2f5f-7845-bc8b-3d8ab65bbdfe prove the zero-club create-club -> first-session shortcut loop. R1-2 is accepted. R1 remains active because R1-3 share/deep-link activation and R1-4 club-growth evidence packet are still pending.
Current R1-3 checkpoint, 2026-06-28: source commit bf3c8746c18401e95378eca40ab3345a180ff890 made public share paths canonical in routes.public*Share, moved share-card URL generation onto those helpers, and changed club invite shares from the base web URL to /join-club?code=<invite>. Mobile and web join-club route shells now pass that query into the shared join screen as a prefilled invite code. Preview OTA group 3ea7b802-e498-4197-a081-0284f3f49c12 carries the client change on runtime 0.6.1. Source commit ce6a23185a322c51c2d31f301b0a82fc96f82bba adds a bounded get_public_share_preview RPC, moves public web receiver pages and OG images onto that RPC, exposes server-rendered twomore:// fallback links, extends club_growth with deterministic share IDs, and adds yarn smoke:r1-share-receivers. Preview Supabase migration 00306 was applied, seed-scenario was redeployed, seeded public receiver smoke passed locally, and the production web build passed with the existing expo-location warning. Source commit de703f539076523f7884c79189e966862c730330 adds scripts/prepare-r1-share-deep-link-flow.mjs, root yarn prepare:r1-share-deep-link-flow / yarn e2e:r1-share-deep-links, and targeted EAS workflow maestro-r1-share-deep-links-rerun.yml so custom-scheme device proof can be generated from live club_growth share IDs without hardcoding UUIDs. Source commit 111dbf77eb590b2ee6a49b0c70bffc3c2a5a342b adds mobile public-share receiver fallbacks for /s and /m, using the bounded public preview RPC when private member-only reads are blocked by RLS. Preview OTA group e01fc19c-19a8-4012-8ec8-1555edad14d6 carries that fallback on runtime 0.6.1. Source commit 55a901264df8c7a4780ee2953c385bc72609ee80 stabilizes the generated /lb assertion to the first-viewport public-club join CTA. Hosted workflow 019f0c32-1afc-70c5-82d8-185df88e8ad4 then passed the generated custom-scheme flow against Android preview build 6aa365f6-7814-4250-a708-a27843a919dc, proving installed-preview twomore://p, /s, /lb, and /m recipient return on hosted Android. Source commit c9d81257205f29cf71707eb730d762aab65876d5 extends the generated flow to open twomore://join-club?code=JOINR12, assert the join screen and prefilled code, then submit without typing. Hosted workflow 019f0c63-85bc-7f19-9d9b-d449ed548eb1 passed that updated flow against the same Android preview build, proving invite-code recipient return on hosted Android. Source commit a667567887143fbc85bb801ffad46e187dd6b222 then makes https://twomore.app the canonical share domain, wires ios.associatedDomains = ["applinks:twomore.app"], adds Android autoVerify intent filters for /s, /m, /p, /lb, and /join-club, serves credential-gated .well-known association handlers from the web app, and adds yarn check:r1-app-links to yarn check. The static app-link guard passes and reports the remaining external gates: TWOMORE_APPLE_TEAM_ID and TWOMORE_ANDROID_SHA256_CERT_FINGERPRINTS. Source commit e6f60c2850dbff3dfc6a58a6642e0f1e6c3b240c adds yarn check:r1-app-links:remote, which fetches the live .well-known association endpoints with redirects disabled and compares the credentialed Apple Team ID / Android SHA-256 fingerprint output when reachable. That remote gate currently fails because https://twomore.app/.well-known/apple-app-site-association returns HTTP 307 to https://www.twomore.app/.well-known/apple-app-site-association, and the www target is not the current TwoMore web app. Source commit ee49c9d75f59cc6033596d75c45f76b22b85d13f repairs the remote guard's Android fingerprint parser so that, once the live Apple/domain blocker is cleared, the same command can validate comma-separated Android SHA-256 fingerprints instead of crashing in the Android branch. Source commit 422037f28e815f17c179f54d2a033ac40bda3c60 adds the R1 Kakao custom-template manifest, attaches validated kakaoTemplate metadata to each session, club, match, tier, stat-card, and leaderboard share composer, and wires yarn check:r1-kakao-share into yarn check. The static Kakao template contract passes. Source commit fb2fd1bd76835a6921f1623b8c9600da2b3f6796 installs @react-native-kakao/core and @react-native-kakao/share, wires the Expo config plugin behind TWOMORE_KAKAO_NATIVE_APP_KEY, and updates the native share adapter to try Kakao custom-template sharing before falling back to the OS share sheet. The config now falls back to EXPO_PUBLIC_KAKAO_APP_KEY when that existing login variable carries the same Kakao Native App Key. Credential mode still reports missing TWOMORE_KAKAO_TEMPLATE_* IDs and a Kakao native app key unless either accepted app-key env is exported. R1-3 remains Active because KakaoTalk template rendering/return proof, correct live twomore.app association deployment, credentialed iOS/Android HTTP app-link preview-build proof, and device smoke are still pending. Source commit 64ea165c7651226f4f9a316b7de581d1cc353a92 adds yarn check:r1-release-readiness, yarn check:r1-release-readiness:eas, and yarn report:r1-release-readiness as the canonical aggregate gate for this state. The EAS report mode currently confirms that static source contracts pass while R1 acceptance is blocked by missing local/web app-link env, missing Kakao template IDs/native app key, the live .well-known redirect, preview OTA native incompatibility, missing EAS preview Kakao env, the Android preview build being behind native-sensitive source, and absent iOS preview build evidence.
Current deferral checkpoint, 2026-06-29: the remaining external credential/domain/build blockers above are intentionally carried by Production Readiness/R4 instead of the active R1 source loop. R1 agents should continue to surface the report output, but once a blocker is proven external, route it to docs/production-readiness.md, docs/external-blockers.md, and docs/pre-launch-checklist.md rather than widening R1 implementation scope.
Blocked scope: paid acquisition, ads, coach marketplace, direct venue booking, real payment capture, and multi-sport generalization.
Handoff output: update this plan with accepted/deferred status, update Roadmap if the track status changes, and attach evidence to the relevant launch or blocker doc if a gate moves.
R2 Organizer Operations - Next
Goal: club admins can understand and resolve weekly operational work without reconstructing it from memory, KakaoTalk, spreadsheets, or bank-transfer notes.
| Slice | Status | Primary artifact | Start condition | Acceptance proof | Verification |
|---|---|---|---|---|---|
| R2-0 Admin workflow teardown | Accepted | Admin workflow teardown — source-grounded inventory of current admin jobs, screens, queries, and missing links | R1-0 accepted | Admin jobs are mapped to existing routes and missing data inputs before UI work starts | yarn docs:check; source links in handoff |
| R2-1 Club operations read model | Accepted | Shared read model for Clubs admin cockpit and role-gated Home exceptions | R2-0 accepted | One query/model can answer upcoming sessions, unpaid holds, submitted transfers, overdue dues, attendance risks, join/guest applications, reports, and sessions needing closeout | Focused query/model tests; cache-key review; yarn check |
| R2-2 Clubs admin prominence | Active | Club list/card/detail admin attention surface | R2-1 accepted | Admin can see which club needs attention before opening every club; non-admin members see normal club identity and next-session context | Screen/component tests where available; role-based manual smoke; yarn check |
| R2-3 Home admin exceptions | Active | Role-gated Home exception cards that deep-link to Clubs admin work | R2-1 accepted | Admins see urgent actionable exceptions; non-admins do not see admin workload | Home route smoke for admin/non-admin fixtures; yarn check |
| R2-4 Session closeout workflow | Active | Post-session closeout path for attendance, payments, scores, and recap | R2-1 accepted | A completed session can be closed without relying on external notes | Money/trust mutation tests; session closeout smoke; yarn check |
| R2-5 Admin reminders and exports | Planned | Reminder and summary export actions for stable admin workflows | R2-2 through R2-4 accepted | Reminder/export actions are visible from admin context and do not bypass consent, i18n, or payment-trust constraints | Focused hook tests; copy/i18n check; yarn check |
Blocked scope: full accounting export, facility POS, open marketplace, generic team-chat replacement, and real payment capture.
Handoff output: update the opportunity audit if the admin thesis changes, update the app functionality map when surfaces move, and keep Home as an attention router rather than a full admin console.
R3 Product Polish & Optimization - Next
Goal: the proved club and admin loops become understandable, fast, resilient, and launchable for first public users.
| Slice | Status | Primary artifact | Start condition | Acceptance proof | Verification |
|---|---|---|---|---|---|
| R3-0 Product route audit | Active | Whole-app UX audit — all 69 screens (ux-residual-queue-2026-07-19.md + digest) | R1 and R2 source inventories exist | 111 findings adversarially verified vs live code; every finding logged with severity + disposition; 10 residual owner-decision items queued | yarn docs:check; the digest + residual queue |
| R3-1 Primary journey polish | Active | UI/copy/a11y fixes for new user, member, admin, and pickup host journeys | R3-0 accepted | Waves 1–5 shipped (~100 of 111 findings closed): privacy/host-lockout/dues/consent (W1), dead-surface + honest-stat cleanup (W2-3), touch targets + draws (W4), 51 canonical residuals (W5). Delivered, pending owner acceptance | Manual mobile smoke; focused component tests; yarn check (3,668 tests green) |
| R3-2 Performance budget pass | Planned | Measured fixes for high-frequency Home, Clubs, Activity, and Records surfaces | R3-0 accepted | Measurable render/network issues are fixed or explicitly deferred with reason | Perf log review; targeted tests; yarn check |
| R3-3 Offline and error resilience pass | Active | Stale/offline/error state polish + the offline-queue integrity invariants (engineering-soundness-masterfile.md §3.1-3.5) | R3-0 accepted | Offline-queue rejection classification, idempotent-replay recognition, forced-signout identity scrub, and empty/loading/error states shipped across primary journeys. Delivered, pending owner acceptance | QueryBoundary/offline smoke; yarn check |
| R3-4 Accessibility and Korean copy pass | Active | Accessibility labels, touch targets, and Korean product copy pass | R3-1 in progress or accepted | hitSlop/HeaderIconButton sweep, canonical Stepper/EmptyState adoption, a11y labels, terminology fixes (참가→가입, 대기열→대기 중) shipped in W4-5. Delivered, pending owner acceptance | ESLint i18n/a11y-sensitive checks; manual screen review; yarn check |
| R3-5 Release-candidate polish packet | Planned | R1-R3 evidence summary and residual-risk list | R3-1 through R3-4 accepted or explicitly deferred | Launch readiness can start with clear accepted work and known residual risk | yarn docs:check; yarn check |
| R3-6 Engineering soundness & OTA-safety | Active | 5-audit engineering-soundness campaign + the runtime-safety guard (engineering-soundness-masterfile.md) | R1/R2 code exists to audit | 12 + 7 confirmed findings fixed to prod (migrations 00434–00439, edge fn, OTA ae318003); 10 durable invariants each gate-enforced (§3); guard-ota-release.mjs blocks a native-dep OTA without a version bump. Current blocker: the 0.7.0 build (e56d3b16) must be installed + smoke-proven before the OTA baseline advances and everything since 03cc65e7 reaches devices (see R4). Delivered, pending owner acceptance | pgTAP 30 files/296 asserts; yarn check; guard-ota-release.mjs |
Blocked scope: new market categories, direct booking marketplace, real payment capture, multi-sport generalization, and speculative redesign.
Deferred out of R3 (owner-decision / gated — see ux-residual-queue-2026-07-19.md): 5 wireframe-first feature completions (dues-amount editing, overdue-dues view, inter-club challenge propose/decline, poll create+vote, format-scoped leaderboard), 2 external blockers (Kakao OAuth = EXT-11, CPO contact), 2 scoped data-layer tasks (venues→court_venues RPC, policy_versions JOIN). The surface-system build (club-surfaces-unification.md) is the next R3 design-led track, spec-approved but not started.
Handoff output: update roadmap status only when R1/R2/R3 evidence is accepted, not when a single check is green.
R4 Launch Readiness Final Gate
Goal: public launch is allowed, observable, and recoverable after R1-R3 are accepted.
| Slice | Status | Primary artifact | Start condition | Acceptance proof | Verification |
|---|---|---|---|---|---|
| R4-0 Gate inventory refresh | Planned | Fresh blocker register and pre-launch checklist review | R1-R3 accepted or explicitly signed off | Each blocker has owner, status, route, and launch impact | yarn docs:generate; yarn docs:check |
| R4-1 Legal and policy packet | Planned | Counsel-ready CPO contact, privacy, terms, location, consent, and marketing-push packet | Owner/counsel input available | Legal launch text is counsel-reviewed, linked, and reflected in blocker status | Counsel sign-off; docs check |
| R4-2 Production credentials and auth | Planned | Kakao, Apple, Supabase, EAS, and store credential proof | Owner/vendor credentials available | Production auth and build credentials are proven or gated with explicit launch impact | Production auth smoke; EAS credential/build checks |
| R4-3 Production build and OTA smoke | Planned | Installable production build and OTA evidence | R4-2 ready | Production build installs, opens, authenticates, and can receive an OTA update | Web build; mobile preflight; production build install; OTA smoke |
| R4-4 Non-dev guardrail smoke | Planned | Proof normal production users cannot access DevPanel, seed, or simulate paths | R4-3 ready | Non-dev account cannot reach privileged/dev-only surfaces | Non-dev account manual smoke; route checks; yarn check |
| R4-5 Release readiness packet | Planned | Final release packet | R4-0 through R4-4 accepted | Every launch blocker is closed, feature-gated, or explicitly signed off as non-blocking | yarn docs:check; yarn check; web build; mobile preflight; dependency audit; hosted club-growth smoke |
Blocked scope: new monetization surfaces, marketplace expansion, multi-sport work, and exploratory redesign.
Handoff output: update Production Readiness, External Blockers Register, and Pre-launch Checklist together.
R5 Real Payments & Subscriptions - Gated
Goal: money moves through production-grade rails without compromising trust or legal posture.
Start only after the R2 payment-trust workflow is usable and PortOne test-store prerequisites are available.
| Slice | Status | Primary artifact | Start condition | Acceptance proof | Verification |
|---|---|---|---|---|---|
| R5-0 Payment authority refresh | Held | Current PortOne, refund, support, and ledger requirements | R4 launch gate or explicit payment pilot approval | Payment/legal/support prerequisites are confirmed before code changes | Docs check; owner/vendor confirmation |
| R5-1 PortOne test rail | Held | Test store/channel/API/webhook configuration | R5-0 accepted | Card, transfer, webhook, and idempotency paths work in test mode | PortOne test checklist; edge-function smoke |
| R5-2 Native payment adapter | Held | Native PortOne adapter behind the existing payment service port | R5-1 accepted | Client starts payment through the port without per-PG SDK drift | Native runtime build; adapter tests; yarn check |
| R5-3 Server verification and webhook hardening | Held | Server-side confirmation and webhook reconciliation | R5-2 accepted | Client never marks payment paid without server verification | Edge-function tests; ledger tests; rollback test |
| R5-4 Pricing pilot | Held | Pilot pricing gate for participation fees, club subscription, or analytics | R5-3 accepted | Pilot club can pay with support/refund path documented | Pilot ledger; production smoke; launch-risk review |
Blocked scope: marketplace settlement, broad subscriptions, paid acquisition, and monetization before support/refund clarity.
R6 Venue & Court Platform - Discovery
Goal: make venue and court context operationally useful before direct booking.
| Slice | Status | Primary artifact | Start condition | Acceptance proof | Verification |
|---|---|---|---|---|---|
| R6-0 Venue data audit | Held | Current venue/court quality and schema gap report | R1-R3 accepted or pilot demand exists | Data issues that affect sessions are ranked by user impact | Docs check; source links |
| R6-1 Session venue attachment polish | Held | Reliable session-to-venue/court attachment path | R6-0 accepted | Sessions show useful venue/court context without marketplace claims | Session create/edit smoke; mapper tests |
| R6-2 Booking handoff pilot | Held | Low-friction contact/link handoff for selected venues | R6-1 accepted | Users can reach a venue booking channel without TwoMore owning inventory | Manual smoke; pilot feedback |
| R6-3 Direct booking tripwire review | Held | Decision on whether to build direct inventory | Repeated manual handoff demand | Direct booking is approved only with venue supply and operator workflow evidence | Pilot evidence review |
Blocked scope: facility POS, access control, operator SaaS, and direct inventory before supply validation.
R7 Leagues & Inter-Club Play - Held
Goal: turn retained clubs into structured competition only when pilot clubs ask for it.
| Slice | Status | Primary artifact | Start condition | Acceptance proof | Verification |
|---|---|---|---|---|---|
| R7-0 Pilot season source pack | Held | Pilot club format and standings requirements | Retained clubs request structured competition | Required format is specific enough to avoid generic league infrastructure | Docs check; pilot notes |
| R7-1 Minimal standings model | Held | Smallest data/model layer for the pilot format | R7-0 accepted | One pilot season can track schedule, scores, standings, and participants | Pure rules tests; migration/RLS tests |
| R7-2 Records and share integration | Held | Results flow into records and shareable outputs | R7-1 accepted | Season results produce useful profile/club records and share cards | Records/leaderboard smoke; yarn check |
Blocked scope: national federation integration, prize money, open tournament marketplace, and generic multi-format season engines.
R8 Coaching & Brand Marketplace - Held
Goal: monetize retained player intent without distracting from club operations.
| Slice | Status | Primary artifact | Start condition | Acceptance proof | Verification |
|---|---|---|---|---|---|
| R8-0 Marketplace thesis refresh | Held | Pilot thesis for coaches, lessons, sponsored challenges, or equipment | Retained club usage and payment trust exist | One marketplace experiment has a specific audience, offer, and trust boundary | Market/pilot review |
| R8-1 Coach or sponsor lead pilot | Held | Manual lead flow tied to player or club context | R8-0 accepted | Qualified leads can be captured without harming club workflows | Manual pilot ledger; abuse/report smoke |
| R8-2 Conversion and trust review | Held | Decision to continue, revise, or stop marketplace work | R8-1 data exists | Experiment has conversion evidence and support/trust risk review | Metrics review; docs check |
Blocked scope: open marketplace launch, broad ad inventory, affiliate automation, and paid placement before trust is proven.
R9 Expansion Platform - Held
Goal: preserve optionality without building speculative infrastructure.
| Slice | Status | Primary artifact | Start condition | Acceptance proof | Verification |
|---|---|---|---|---|---|
| R9-0 Expansion trigger audit | Held | Evidence that internationalization, multi-sport, white-label, or advanced analytics should reopen | Active revenue line and retained multi-club usage exist | Expansion work has a named customer or measurable pull | Docs check; business evidence |
| R9-1 Narrow capability spike | Held | One bounded spike for the approved expansion trigger | R9-0 accepted | Spike answers the specific customer or revenue question without broad platform rewrite | Targeted proof; rollback/defer decision |
Blocked scope: speculative platform abstractions, generic facility SaaS, broad multi-sport models, AI video, sensors, and white-label work without demand.
Implementation Conversation Template
Use this when opening a build conversation or assigning work to another agent:
We are implementing <slice id> from docs/architecture/implementation-plan.md.
Mode:
- <closure-only | implementation | investigation-only | docs-only>
Goal:
- <one-sentence outcome>
Read first:
- docs/architecture/implementation-plan.md#<track-anchor>
- docs/architecture/roadmap.md#<track-anchor>
- docs/workflows/change-routing.md
- docs/agent-prompts/slice-goal.md
- docs/specifications/app-functionality-map.md
- docs/specifications/product-spec-sheet.md
- any source paths named by the slice
Current blocker:
- <the one blocker this session should remove or prove external>
Allowed surfaces:
- <paths or systems>
Blocked scope:
- <explicit non-goals>
- Do not take adjacent improvements unless they block this acceptance proof.
Acceptance proof:
- <what must be true>
Verification:
- Start: <targeted report/check>
- Iteration: <targeted commands>
- Handoff: <final commands>
Stop rules:
- Stop after the named blocker is closed, proven external, or split.
- Record useful but non-blocking findings as follow-ups instead of implementing
them.
- If a second primary artifact is required, stop and propose a slice split.
Handoff:
- report files changed, checks run, blocker status, deferrals, and next exact
slice or owner action.Drift Control
- Keep current-state facts in generated docs. Do not hand-edit
docs/current-project-state.mdordocs/current-doc-state.md. - Keep sequence-level outcomes in Roadmap; keep concrete build slices here.
- Keep market rationale in research docs and link to it from slices only when it changes implementation priority.
- Update this plan in the same PR/session when a roadmap track changes status or a slice is accepted, blocked, split, or replaced.
- A green
yarn checkis necessary for code-affecting work but not sufficient to accept a product slice. The slice acceptance proof must also be satisfied.