Review: New page: Tryouts (history + Kings/Queens toggle)

review-407-2026-03-25 Review

review needs-refinement

Project

Template Completeness

[x] Lineage — present ("Part of public site evolution. Parent note: westside-playground-overhaul")
[x] Repo — present (forgejo_admin/westside-playground) — BUT see Repo Placement below
[x] User Story — present and well-written
[x] Context — present, good detail on Kings/Queens toggle and FOMO angle
[x] File Targets — present (tryouts.html)
[x] Acceptance Criteria — present, 6 items
[x] Test Expectations — present, 3 items
[x] Constraints — present (app.js, style.css, component doc, mobile-first)
[x] Checklist — present
[x] Related — present

File Targets

[x] tryouts.html — does NOT exist yet in westside-playground (confirmed via Glob). Correctly identified as a new file to create.
[x] shared/app.js — verified exists at ~/westside-playground/shared/app.js. Contains initTabs() function that could power the Kings/Queens toggle. However, the ticket says "light JS in shared/app.js (show/hide sections)" — no specific function name or implementation guidance. The existing initTabs pattern (lines 35-51) uses data-tab attributes and panel prefixes, which is a natural fit.
[x] shared/style.css — verified exists at ~/westside-playground/shared/style.css.
[ ] Nav update on ALL pages — ticket says "Nav updated on ALL pages to include Tryouts" but does NOT list which pages need nav updates. Current nav across playground pages is: Home, About, Staff, Sponsors, Schedule. Agent needs to know exactly which HTML files to modify. There are 24 HTML files in the playground; only public pages have the site nav. This should enumerate the files or say "all pages with .site-nav".

Repo Placement

ISSUE: Repo mismatch. The issue body says Repo: forgejo_admin/westside-playground but the Forgejo issue is filed on forgejo_admin/westside-app (issue #92). The work clearly targets the playground (creating tryouts.html, using shared/app.js), so the issue should be filed on forgejo_admin/westside-playground instead. This is a filing error, not a scope error — the issue body is correct about where the work lives.

Note: The existing westside-app/src/routes/tryouts/+page.svelte is a stale girls-only tryout page from Phase 11. This playground page will eventually replace it in Stage 3 (playground to Svelte promotion), but that is future scope.

Dependencies

#410 (Update Schedule: Kings/Queens toggle) — in todo column. Same Kings/Queens toggle pattern. These two tickets share the toggle UX and JS mechanism. The toggle implementation in app.js should be built once and reused. Neither ticket documents this shared dependency. Recommendation: whichever ticket lands first should implement the reusable toggle in app.js; the second ticket should reference it.
#408 (New page: Teams — Kings/Queens toggle + profile gate) — in todo column. Also uses Kings/Queens toggle. Same shared dependency as above.
#381, #382, #383, #384 (Playground overhaul 1-4) — all in done. These are the foundation this ticket builds on. CSS/JS unification is complete. No blocker.
#405 (Landing page: restore original energy) — in next_up. Not a blocker but may change the nav structure that this ticket also modifies. Sequencing risk if both modify nav simultaneously.
#356 (Public site: travel schedule page) — in next_up. Also adds to nav. Same sequencing concern.

Acceptance Criteria

[x] "tryouts.html exists with Kings/Queens toggle" — testable by file existence + DOM check
[x] "Past tryouts show real data" — testable, and real data IS provided in the ticket (Kings: March 13, Queens: March 24)
[x] "No upcoming tryouts shown when none active" — testable but ambiguous: is the "no upcoming" state the DEFAULT for this ticket? The ticket context implies yes (historical page), but the acceptance criterion reads like a conditional. Agent may be confused about which state to build.
[x] "Links to Teams page from tryout results" — testable, but Teams page may not exist yet (depends on #408). Should link to team.html which DOES exist in the playground as a single-team view, not a public roster page. The link target is ambiguous.
[x] "Nav updated on ALL pages" — testable but see File Targets note above about missing file list
[x] "Toggle is a prominent two-button switch" — testable visually but no CSS class or design reference provided. Agent will need to invent the toggle design.

Blast Radius

Nav changes across all pages: This ticket modifies nav on every public page. Board items #405 (landing page energy), #356 (travel schedule page), #406 (About page), #409 (Gear page), and #408 (Teams page) all also add or modify nav. If these land in any order, there will be merge conflicts on every page's nav block. Consider a single "add all new nav items" pass or explicit sequencing.
Kings/Queens toggle pattern: Three tickets (#407, #408, #410) all need the same toggle. The toggle JS + CSS should be a shared component defined once. The ticket's constraint says "light JS in shared/app.js" but does not specify whether this is a new function or reuse of initTabs. Risk of three different toggle implementations if tickets land independently.

Recommendation

Three items to fix before this ticket is READY:

Move Forgejo issue to correct repo. Close #92 on westside-app and re-file on forgejo_admin/westside-playground. Or if the convention is to keep all issues on westside-app, document that explicitly in the Repo field.
Enumerate nav files. Add a "Files to modify" list under File Targets naming every HTML file whose nav needs the Tryouts link (or specify a selector pattern like "all files with .site-nav").
Clarify toggle reuse. Specify whether the Kings/Queens toggle should reuse initTabs() from app.js or create a new function. Document that #408 and #410 share this pattern so the first ticket to land builds the reusable version.

Optional improvements:

Clarify that "No upcoming tryouts" is the default state for this ticket (no active tryouts exist now).
Clarify the "Links to Teams page" target — is it team.html (existing single-team view) or the future public roster from #408?