pal-e-docs

Review: Parent dashboard: player's team schedule via player_teams FK

review-809-2026-04-04 Review

review approved
Project

Verdict: APPROVED

Re-review after refinements. All previous NEEDS_REFINEMENT findings resolved. Backend dependency merged, data flow documented, scope is pure frontend.

Template Completeness

  • [x] Type — Feature
  • [x] User Story — story:WS-S28, clear parent persona
  • [x] Lineage — story, arch, blockers all documented
  • [x] Repo — forgejo_admin/westside-landing
  • [x] Context — thorough: DB relationship chain, data flow (4-step), edge cases (Sandra Apaisa multi-team)
  • [x] File Targets — 1 frontend file specified
  • [x] Acceptance Criteria — 6 testable conditions
  • [x] Test Expectations — svelte-check, visual validation
  • [x] Constraints — pure CSS, no Tailwind, no new API endpoints
  • [x] Checklist — 7 items, comprehensive
  • [x] Related — 3 references (basketball-api#333/PR#334, sibling #213, schedule fix PR#216)
All required Feature template sections present and complete.

Traceability

  • [x] story:WS-S28 — "As a parent, I want to see my child's team practice schedule so I know when and where to take them"
  • [x] story note verified — found in project-westside-basketball user-stories section under Parent heading
  • [x] arch:landing-site — references the westside-landing SvelteKit app
  • [ ] arch note MISSING — [SCOPE] Create architecture note arch-landing-site for the westside-landing frontend component (non-blocking, tracked)
  • [x] Forgejo issue — forgejo_admin/westside-landing#214, open

File Targets

  • [x] src/routes/(app)/my-players/+page.svelte — verified: file exists at ~/westside-app/src/routes/(app)/my-players/+page.svelte. Placeholder text at line 126: "Schedule data will appear here once practice times are confirmed." Confirmed match.

Backend Dependency (Resolved)

  • [x] basketball-api PR #334 merged to main (commit 2853efd, 2026-04-04)
  • [x] AccountPlayerResponse now includes team_ids: list[int] (line 32) and team_id: int | None (line 31)
  • [x] Populated from [t.id for t in player.teams] (line 102)
  • [x] /public/schedule endpoint returns CombinedScheduleResponse with PracticeScheduleResponse.team_id and EventResponse.team_id
  • [x] Data flow documented in issue body: fetch /account/players → get team_ids → fetch /public/schedule → filter client-side

Repo Placement

Correct. Issue filed on westside-landing, all work is pure frontend in westside-landing. Backend dependency (basketball-api#333/PR#334) already merged — no cross-repo work remaining.

Dependencies

  • [x] basketball-api#333/PR#334 (add team_ids to AccountPlayerResponse) — merged, verified on origin/main
  • [x] #808 (Coach dashboard schedule, westside-landing#213) — sibling ticket, same pattern. Not a blocker.
  • [x] #810 (Admin: Marcus verifies schedule data) — in needs_approval. Not a blocker; practice_schedules data already seeded.
  • [x] /public/schedule endpoint (basketball-api#241) — done, returns practices with team_id and events with team_id.
  • [x] westside-landing#209/PR#216 (public schedule grouping fix) — merged.
No unresolved dependencies. All blockers cleared.

Acceptance Criteria

6 criteria, all testable via visual validation + svelte-check. Well-specified:
  • Practice schedule with day name, 12-hour time, venue — verifiable
  • Grouped by player name, then team — verifiable
  • Placeholder removed — verifiable
  • Events/tournaments filtered by team_id + division fallback — verifiable
  • Multi-player parents see all relevant schedules — verifiable (Sandra Apaisa test case)
  • No backend changes — guardrail, verifiable via diff

Blast Radius

  • Only /my-players page is modified. No other pages consume /account/players.
  • /public/schedule is also consumed by the public schedule page, but this ticket only reads it — no changes to the endpoint or its other consumer.
  • Adding team_ids to the API response was additive (new field). No breaking changes.
  • Coach dashboard sibling (#808) uses a different auth chain (/coaches/me) — no shared blast radius.
  • Rollback is straightforward — revert the Svelte component to the placeholder.

Decomposition

1 file target, 1 repo, 6 acceptance criteria (slightly over threshold but all within one file and one conceptual change — schedule display). Estimated agent time: under 5 minutes. No decomposition needed.

Recommendation

  • [SCOPE] Create architecture note arch-landing-site for the westside-landing frontend component. Non-blocking — tracked as discovered scope from previous review.
No other action needed. Ticket is ready for dispatch.

Previous Review Resolution

Prior review (2026-04-04) returned NEEDS_REFINEMENT with 5 recommendations. Status:
  • [BODY] Backend file target — RESOLVED: basketball-api#333/PR#334 merged. Issue body updated to state "No backend changes" and documents the merged PR.
  • [BODY] Data flow — RESOLVED: 4-step data flow explicitly documented in Context section.
  • [BODY] Backend AC — RESOLVED: replaced with AC6 "No backend changes" since backend is done.
  • [LABEL] Cross-repo split — RESOLVED: backend issue created (basketball-api#333), PR merged (#334). No cross-repo work remains.
  • [SCOPE] arch-landing-site note — Still missing. Carried forward as non-blocking [SCOPE] recommendation.