forgejo_admin/westside-playground
1
0
Fork 0
Code Issues 4 Pull requests Projects Releases Packages Wiki Activity Actions

feat: Teams page with Kings/Queens toggle + profile gate (#93) #44

Merged
forgejo_admin merged 1 commit from 93-teams-page into main 2026-03-27 00:55:29 +00:00
Conversation 2 Commits 1 Files changed 10 +486
forgejo_admin commented 2026-03-27 00:49:39 +00:00
Owner
Copy link

Summary

  • Public-facing Teams page with Kings/Queens toggle, roster cards for all 5 Kings teams, "Profile Pending" placeholders demonstrating the profile completeness gate, and Queens "coming soon" section
  • Nav updated on all 8 public pages to include Teams link
  • Roster CSS scoped under [data-program-content] to avoid conflicts with coach.html grid

Changes

  • teams.html (new): Full teams page with KQ toggle, 5 Kings team sections (16U Elite, 17U Elite, 17U Select, 16U Local, 17U Local), roster cards with mock player data, profile-pending placeholders, Queens coming-soon block, CTA, footer
  • shared/style.css: Roster card styles, profile-pending state (dashed border, dimmed opacity), Queens coming-soon box, responsive grid (1col mobile, 2col tablet, 3col desktop)
  • index.html: Add Teams to nav
  • about.html: Add Teams to nav
  • staff.html: Add Teams to nav
  • tryouts.html: Add Teams to nav
  • sponsors.html: Add Teams to nav
  • schedule.html: Add Teams to nav
  • register.html: Add Teams to nav
  • success.html: Add Teams to nav

Test Plan

  • Toggle switches between Kings and Queens content
  • Kings shows 5 team sections with roster cards
  • Profile Pending cards visually distinct (dashed border, dimmed, italic)
  • Queens shows "Coming Soon" placeholder
  • Nav link appears on all 8 existing pages
  • All links resolve (no broken hrefs)
  • Visual check at 390px mobile
  • Toggle state persists via localStorage across pages
  • coach.html roster grid unaffected by new CSS

Review Checklist

  • Passed automated review-fix loop
  • No secrets committed
  • No unnecessary file changes
  • Commit messages are descriptive

Related Notes

## Summary - Public-facing Teams page with Kings/Queens toggle, roster cards for all 5 Kings teams, "Profile Pending" placeholders demonstrating the profile completeness gate, and Queens "coming soon" section - Nav updated on all 8 public pages to include Teams link - Roster CSS scoped under `[data-program-content]` to avoid conflicts with coach.html grid ## Changes - `teams.html` (new): Full teams page with KQ toggle, 5 Kings team sections (16U Elite, 17U Elite, 17U Select, 16U Local, 17U Local), roster cards with mock player data, profile-pending placeholders, Queens coming-soon block, CTA, footer - `shared/style.css`: Roster card styles, profile-pending state (dashed border, dimmed opacity), Queens coming-soon box, responsive grid (1col mobile, 2col tablet, 3col desktop) - `index.html`: Add Teams to nav - `about.html`: Add Teams to nav - `staff.html`: Add Teams to nav - `tryouts.html`: Add Teams to nav - `sponsors.html`: Add Teams to nav - `schedule.html`: Add Teams to nav - `register.html`: Add Teams to nav - `success.html`: Add Teams to nav ## Test Plan - [ ] Toggle switches between Kings and Queens content - [ ] Kings shows 5 team sections with roster cards - [ ] Profile Pending cards visually distinct (dashed border, dimmed, italic) - [ ] Queens shows "Coming Soon" placeholder - [ ] Nav link appears on all 8 existing pages - [ ] All links resolve (no broken hrefs) - [ ] Visual check at 390px mobile - [ ] Toggle state persists via localStorage across pages - [ ] coach.html roster grid unaffected by new CSS ## Review Checklist - [ ] Passed automated review-fix loop - [ ] No secrets committed - [ ] No unnecessary file changes - [ ] Commit messages are descriptive ## Related Notes - Closes forgejo_admin/westside-app#93 - `westside-playground-overhaul` — parent project
Add public teams.html with Kings/Queens toggle, roster cards for all 5
Kings teams, profile-pending placeholder cards demonstrating the
completeness gate, and Queens "coming soon" section. Add Teams to nav
on all 8 public pages.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
forgejo_admin commented 2026-03-27 00:50:19 +00:00
Author
Owner
Copy link

Review: PASS

Files reviewed: 10 (1 new, 9 modified)

Checks

  • Nav consistency: Teams link added between Staff and Tryouts on all 8 public pages. Matches teams.html nav order.
  • Toggle pattern: Exact same kq-toggle / data-program-content pattern as tryouts.html. initKQToggle() auto-wires on DOMContentLoaded.
  • 5 Kings teams: 16U Elite, 17U Elite, 17U Select, 16U Local, 17U Local -- all present with correct coaches.
  • Profile gate: Mix of visible roster cards and "Profile Pending" placeholders across all teams. 17U Local is all-pending to show a team still being built.
  • Queens placeholder: Coming-soon block with contact info. Correct data-program-content="queens" wrapper.
  • CSS scoping: [data-program-content] .roster-grid and [data-program-content] .roster-card prevent conflicts with the existing coach.html roster grid (which uses unscoped .roster-grid / .roster-card).
  • Responsive: 1-col mobile, 2-col tablet (640px), 3-col desktop (1024px) for roster grid.
  • No secrets, no stale files, no regressions.

Nits (non-blocking)

None found. Clean implementation.

Ready for Lucas phone review at 390px.

## Review: PASS **Files reviewed:** 10 (1 new, 9 modified) ### Checks - **Nav consistency:** Teams link added between Staff and Tryouts on all 8 public pages. Matches teams.html nav order. - **Toggle pattern:** Exact same `kq-toggle` / `data-program-content` pattern as tryouts.html. `initKQToggle()` auto-wires on DOMContentLoaded. - **5 Kings teams:** 16U Elite, 17U Elite, 17U Select, 16U Local, 17U Local -- all present with correct coaches. - **Profile gate:** Mix of visible roster cards and "Profile Pending" placeholders across all teams. 17U Local is all-pending to show a team still being built. - **Queens placeholder:** Coming-soon block with contact info. Correct `data-program-content="queens"` wrapper. - **CSS scoping:** `[data-program-content] .roster-grid` and `[data-program-content] .roster-card` prevent conflicts with the existing coach.html roster grid (which uses unscoped `.roster-grid` / `.roster-card`). - **Responsive:** 1-col mobile, 2-col tablet (640px), 3-col desktop (1024px) for roster grid. - **No secrets, no stale files, no regressions.** ### Nits (non-blocking) None found. Clean implementation. Ready for Lucas phone review at 390px.
forgejo_admin commented 2026-03-27 00:54:44 +00:00
Author
Owner
Copy link

PR #44 Review

DOMAIN REVIEW

Tech stack: Static HTML/CSS playground (vanilla JS via shared/app.js). No build step, no framework, no backend.

KQ Toggle reuse -- Correctly reuses the initKQToggle() function from shared/app.js (line 405). The function is auto-initialized on DOMContentLoaded (line 458), so teams.html needs zero inline JS. The data-program-content="kings" and data-program-content="queens" attributes match the selector pattern used by the toggle function. localStorage persistence of program state works across page navigations.

CSS scoping -- The PR description claims styles are "scoped under [data-program-content] to avoid conflicts with coach.html roster grid." Verified: coach.html uses .roster-grid and .roster-card (unscoped, lines 2349-2413 of shared/style.css), while the new teams page styles use [data-program-content] .roster-grid and [data-program-content] .roster-card with higher specificity. No collision. The display: grid declaration is correctly inherited from the unscoped .roster-grid rule via cascade.

Nav consistency -- Teams link inserted at the same position on all 8 public pages (after Staff, before Tryouts). Verified against main branch nav order. The tryouts.html page already had forward references to teams.html ("View Teams" links at lines 100 and 112) from a prior PR -- this PR fulfills those references.

Responsive grid -- Follows the existing breakpoint pattern: 1-column mobile (default), 2-column at tablet media query, 3-column at desktop media query. Both responsive overrides are present in the diff.

Accessibility -- aria-hidden="true" on decorative photo placeholders, aria-label on nav toggle, lang="en" on html element. Heading hierarchy is correct (h1 in hero, h2 per team section, h3 in Queens coming-soon).

HTML structure -- Clean semantic markup. Proper <section> usage, meta description, Open Graph tags. OG image URL matches all other pages.

BLOCKERS

None.

This is a static HTML/CSS playground page. No user input processing, no backend integration, no auth paths, no secrets. The BLOCKER criteria (unvalidated input, secrets, DRY auth violations, zero test coverage) do not apply to this domain -- there is no automated test infrastructure for static playground pages, and the test plan appropriately defines manual visual verification steps.

NITS

  1. DRY: .roster-photo-placeholder and .roster-photo-pending share 3 identical properties -- width: 56px, height: 56px, min-width: 56px, border-radius: 50%. Could extract a shared base class (e.g., .roster-photo) and extend with modifiers. Low impact but worth noting for when these patterns promote to SvelteKit components.

  2. Hardcoded font-size: 3rem on .queens-coming-soon-icon -- The stylesheet defines --font-size-4xl: 2.5rem and --font-size-5xl: 3.5rem but has no 3rem variable. This is the only 3rem value in the entire stylesheet. Could use one of the existing tokens or add a new one.

  3. Partial scoping -- The PR description says styles are scoped under [data-program-content], but only .roster-grid and .roster-card use the scope selector. The child classes (.roster-photo-placeholder, .roster-info, .roster-name, .roster-number, .roster-detail, .roster-note, and all pending/queens classes) are unscoped. These names are unique so there is no collision today, but the scoping strategy is inconsistent with the stated intent. When promoting to SvelteKit this becomes moot (component scoping takes over).

  4. Profile Pending card markup repeated 12 times -- Each pending card is an identical 7-line HTML block. In the playground this is fine (static mock data), but when promoting to SvelteKit, this should be a {#each} block or a component.

SOP COMPLIANCE

  • Branch named after issue (93-teams-page references issue #93)
  • PR body follows template (Summary, Changes, Test Plan, Review Checklist, Related)
  • Related references project context (westside-playground-overhaul). No plan slug -- consistent with user instruction that not all work needs plans.
  • Closes correct parent issue (forgejo_admin/westside-app#93)
  • No secrets committed
  • No unnecessary file changes (10 files: 1 new page + 1 CSS + 8 nav updates, all directly scoped to the issue)
  • Commit messages are descriptive

PROCESS OBSERVATIONS

Clean, well-scoped PR. The initKQToggle reuse pattern is working as intended -- zero new JS for new pages that use the toggle. The nav duplication across 8 HTML files is an inherent cost of the playground approach (no shared layout component), but it is mitigated by the fact that SvelteKit will have a single +layout.svelte. The profile-pending placeholder pattern is a strong visual design choice that clearly communicates the completeness gate concept for promotion to the real app.

VERDICT: APPROVED

## PR #44 Review ### DOMAIN REVIEW **Tech stack:** Static HTML/CSS playground (vanilla JS via shared/app.js). No build step, no framework, no backend. **KQ Toggle reuse** -- Correctly reuses the `initKQToggle()` function from `shared/app.js` (line 405). The function is auto-initialized on `DOMContentLoaded` (line 458), so `teams.html` needs zero inline JS. The `data-program-content="kings"` and `data-program-content="queens"` attributes match the selector pattern used by the toggle function. localStorage persistence of program state works across page navigations. **CSS scoping** -- The PR description claims styles are "scoped under `[data-program-content]` to avoid conflicts with coach.html roster grid." Verified: `coach.html` uses `.roster-grid` and `.roster-card` (unscoped, lines 2349-2413 of `shared/style.css`), while the new teams page styles use `[data-program-content] .roster-grid` and `[data-program-content] .roster-card` with higher specificity. No collision. The `display: grid` declaration is correctly inherited from the unscoped `.roster-grid` rule via cascade. **Nav consistency** -- Teams link inserted at the same position on all 8 public pages (after Staff, before Tryouts). Verified against `main` branch nav order. The `tryouts.html` page already had forward references to `teams.html` ("View Teams" links at lines 100 and 112) from a prior PR -- this PR fulfills those references. **Responsive grid** -- Follows the existing breakpoint pattern: 1-column mobile (default), 2-column at tablet media query, 3-column at desktop media query. Both responsive overrides are present in the diff. **Accessibility** -- `aria-hidden="true"` on decorative photo placeholders, `aria-label` on nav toggle, `lang="en"` on html element. Heading hierarchy is correct (h1 in hero, h2 per team section, h3 in Queens coming-soon). **HTML structure** -- Clean semantic markup. Proper `<section>` usage, meta description, Open Graph tags. OG image URL matches all other pages. ### BLOCKERS None. This is a static HTML/CSS playground page. No user input processing, no backend integration, no auth paths, no secrets. The BLOCKER criteria (unvalidated input, secrets, DRY auth violations, zero test coverage) do not apply to this domain -- there is no automated test infrastructure for static playground pages, and the test plan appropriately defines manual visual verification steps. ### NITS 1. **DRY: `.roster-photo-placeholder` and `.roster-photo-pending` share 3 identical properties** -- `width: 56px`, `height: 56px`, `min-width: 56px`, `border-radius: 50%`. Could extract a shared base class (e.g., `.roster-photo`) and extend with modifiers. Low impact but worth noting for when these patterns promote to SvelteKit components. 2. **Hardcoded `font-size: 3rem` on `.queens-coming-soon-icon`** -- The stylesheet defines `--font-size-4xl: 2.5rem` and `--font-size-5xl: 3.5rem` but has no `3rem` variable. This is the only `3rem` value in the entire stylesheet. Could use one of the existing tokens or add a new one. 3. **Partial scoping** -- The PR description says styles are scoped under `[data-program-content]`, but only `.roster-grid` and `.roster-card` use the scope selector. The child classes (`.roster-photo-placeholder`, `.roster-info`, `.roster-name`, `.roster-number`, `.roster-detail`, `.roster-note`, and all pending/queens classes) are unscoped. These names are unique so there is no collision today, but the scoping strategy is inconsistent with the stated intent. When promoting to SvelteKit this becomes moot (component scoping takes over). 4. **Profile Pending card markup repeated 12 times** -- Each pending card is an identical 7-line HTML block. In the playground this is fine (static mock data), but when promoting to SvelteKit, this should be a `{#each}` block or a component. ### SOP COMPLIANCE - [x] Branch named after issue (`93-teams-page` references issue #93) - [x] PR body follows template (Summary, Changes, Test Plan, Review Checklist, Related) - [x] Related references project context (`westside-playground-overhaul`). No plan slug -- consistent with user instruction that not all work needs plans. - [x] Closes correct parent issue (`forgejo_admin/westside-app#93`) - [x] No secrets committed - [x] No unnecessary file changes (10 files: 1 new page + 1 CSS + 8 nav updates, all directly scoped to the issue) - [x] Commit messages are descriptive ### PROCESS OBSERVATIONS Clean, well-scoped PR. The `initKQToggle` reuse pattern is working as intended -- zero new JS for new pages that use the toggle. The nav duplication across 8 HTML files is an inherent cost of the playground approach (no shared layout component), but it is mitigated by the fact that SvelteKit will have a single `+layout.svelte`. The profile-pending placeholder pattern is a strong visual design choice that clearly communicates the completeness gate concept for promotion to the real app. ### VERDICT: APPROVED
forgejo_admin deleted branch 93-teams-page 2026-03-27 00:55:29 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo_admin/westside-playground!44
No description provided.