pal-e-docs

Review: Spike: Player self-service jersey ordering from profile

review-690-2026-03-29 Doc

review ready
Project

Verdict: APPROVED

Re-review after conversion from Feature to Spike. Issue body completely rewritten with spike template. All spike-specific sections present and well-scoped. The spike is investigation-only with sub-tickets as the deliverable, not code. Previous NEEDS_REFINEMENT issues (vague file targets, decomposition needed, story mismatch) are resolved by the type conversion — spikes don't have file targets, the spike IS the decomposition step, and the investigation will determine if WS-S18 needs extending.

Template Completeness

Evaluated against template-issue-spike:
  • [x] Type — "Spike"
  • [x] Lineage — Standalone, references first review and jersey email session 2026-03-29
  • [x] Repo — Both repos identified (westside-landing + basketball-api)
  • [x] Question — Clear, specific: "What backend and frontend changes are needed to let a logged-in parent order a jersey from their profile, without requiring the email token link?"
  • [x] Context — Describes current token-only flow accurately (email to /jersey?token={token}, no session auth path, both jersey.py and checkout.py token-only)
  • [x] Investigation Scope — Four concrete areas: (1) backend dual-auth, (2) frontend entry point, (3) player resolution for multi-player parents, (4) blast radius
  • [x] Deliverable — "A decomposed set of sub-tickets (backend + frontend) with concrete file targets, ready for review"
  • [x] Time Box — "1 hour investigation, output is tickets not code"
  • [x] Acceptance Criteria — 4 success criteria, all investigation-appropriate
  • [x] Related — Links project-westside-basketball and basketball-api#243 (closed)
No missing sections. Full compliance with spike template.

Traceability

  • [x] story:WS-S18 label — "As a parent, I want to receive a branded email with jersey ordering link so that I can order without bringing cash"
  • [x] story note verified — WS-S18 found in project-westside-basketball user-stories section under Parent stories
  • [x] arch:westside-app label present
  • [ ] arch note MISSING — [SCOPE] No arch-westside-app note found in pal-e-docs. Create architecture note for westside-app component.
  • [x] arch:basketball-api label present
  • [ ] arch note MISSING — [SCOPE] No arch-basketball-api note found in pal-e-docs. Create architecture note for basketball-api component.
  • [x] Forgejo issue — forgejo_admin/westside-landing#196, state: open
Note: The first review flagged story:WS-S18 as a mismatch (email-centric wording vs. self-service scope). For the spike, this is acceptable — one of the spike's investigation outputs may be a recommendation to extend WS-S18 or create a new story. The spike itself is correctly linked to the jersey ordering domain.

File Targets

Spike template has no File Targets section (correct per template-issue-spike). The issue body references files as investigation context, not implementation targets. All referenced paths verified against the filesystem:
  • [x] routes/jersey.py — verified at src/basketball_api/routes/jersey.py. Token auth confirmed at lines 118, 231 via Parent.registration_token
  • [x] routes/checkout.py — verified at src/basketball_api/routes/checkout.py. Token auth confirmed at line 119 via Parent.registration_token
  • [x] players/[id]/+page.svelte — verified at src/routes/(app)/players/[id]/+page.svelte in westside-app. Also has billing/+page.svelte sub-page.
  • [x] Existing jersey frontend route at src/routes/(app)/jersey/+page.svelte (with cancel/success sub-routes)
  • [x] Existing checkout frontend route at src/routes/(app)/checkout/+page.svelte

Repo Placement

OK. Issue filed on forgejo_admin/westside-landing (the Forgejo repo for westside-app issues). Investigation scope correctly identifies both westside-landing (frontend) and basketball-api (backend). Board item labels match: arch:westside-app, arch:basketball-api. Spike output (sub-tickets) will be filed on both repos as needed — the issue explicitly acknowledges cross-repo scope and names the deliverable as sub-tickets.

Dependencies

  • [x] basketball-api#243 (jersey email with division filter) — closed/complete. No blocker.
  • [x] Phase 11 (Girls Tryout, board #128) — in_progress on board, but all 12 jersey/checkout/payment items within it are done. No conflict.
  • [x] Phase 14 (Billing Tiers, board #556) — in_progress. Touches billing but not jersey flow. No conflict.
  • [x] Phase 15 (SPA Rebuild, board #545) — in_progress. Structural app work. Investigation-only spike won't conflict.
  • [x] No blocking items found in next_up column.
  • [x] 12 completed jersey/checkout/payment items on board provide rich prior art for investigation.
Note: The first review flagged board item #666 (in_progress, sharing WS-S18) as a potential conflict. Since this is now a spike producing tickets (not code), there is no merge conflict risk during investigation. The spike agent should note #666's status when creating sub-tickets.

Acceptance Criteria

4 success criteria, all appropriate for a spike:
  • [x] "Backend changes documented with specific file targets and approach" — verifiable: agent produces file target list with specific paths
  • [x] "Frontend entry point decided with mockup or description" — verifiable: agent produces concrete description
  • [x] "Multi-player parent edge case addressed" — verifiable: documented decision with reasoning
  • [x] "Sub-tickets created on Forgejo and added to board" — verifiable: Forgejo issues exist, board items created
All criteria are investigation outputs, not code changes. Each is concrete, verifiable, and scoped to the spike's purpose.

Blast Radius

The issue correctly identifies blast radius as investigation area #4. Confirmed via codebase grep: registration_token auth pattern is used across 4 route files — jersey.py (2 refs), checkout.py (1 ref), register.py (2 refs), tryouts.py (3 refs) — totaling 13 references. The spike should investigate whether modifying jersey/checkout auth affects assumptions in register.py and tryouts.py. This is already captured in the investigation scope, not a blocker. No code changes during the spike — blast radius is zero for the spike itself.

Decomposition Assessment

No decomposition needed for the spike itself. This spike IS the decomposition step — its deliverable is sub-tickets with concrete file targets. Assessment:
  • 0 code changes (investigation only, output is tickets)
  • 4 acceptance criteria (under the 5 threshold)
  • 1-hour time box (appropriate for investigation scope)
  • Single agent can investigate both repos and produce tickets
  • No independent subtasks to parallelize — investigation is sequential
The first review's [DECOMPOSE] recommendation was "convert to spike then decompose." That conversion happened. The spike will produce the decomposed sub-tickets as its primary deliverable.

Recommendation

  • [LABEL] Change board item label from type:feature to type:spike to match the issue type conversion.
  • [SCOPE] Create architecture note arch-westside-app for the westside-app component (project-wide gap, not spike-specific).
  • [SCOPE] Create architecture note arch-basketball-api for the basketball-api component (project-wide gap, not spike-specific).
The label fix is cosmetic and should not block advancement. The arch notes are discovered scope — they apply to the entire westside-basketball project, not just this ticket. Verdict is APPROVED because the spike itself is well-scoped, all template sections are complete, investigation areas are concrete, and the deliverable (sub-tickets) is clearly defined.