BaseballHelm: stop non-showcase coaches from seeing showcase Organization routes

[njrini99-code]

Problem

Non-showcase BaseballHelm coaches can see an Organization hub because events is registered as visible to both roles/programs, and the sidebar shows the Organization hub when any of organization, teams, or events is visible. The destination routes are showcase/org-only and redirect ordinary coaches back to Command Center.

Evidence

• src/lib/baseball/nav-registry.ts: events is role both with no program/capability gate.
• src/components/layout/sidebar.tsx: buildCondensedBaseballNavigation() adds COACH_ORGANIZATION_HUB when any of organization, teams, or events is visible.
• src/app/baseball/(dashboard)/dashboard/events/page.tsx, organization/page.tsx, teams/page.tsx: org/showcase route guards are used.

Why it matters

This creates a polished-looking nav link that routes users into a guard bounce. It makes the shell feel broken and hides real route contract drift.

Acceptance criteria

• College, high-school, and JUCO coaches do not see showcase-only Organization routes in primary nav.
• Showcase/academy/club coaches still see the correct org routes.
• Shared Team Events are either split from Organization Events or explicitly gated by program type.
• Add a nav contract test for college, high-school, JUCO, showcase, and player contexts.
• Add a route/shell regression that ensures visible nav links do not redirect immediately to Command Center for authorized users.

[coderabbitai]

🔗 Related PRs

#281 - Men's/Women's Team Toggle — complete (backend, RLS, onboarding, UI) [merged]
#304 - feat: integration roundup — CoachHelm + stats + demo + a11y + nightly fixes + safe deps [merged]
#324 - fix(golf): player Roster renders its own page (no more Team Hub bounce) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[njrini99-code]

@coderabbitai plan

[coderabbitai]

Rate Limit Exceeded

@njrini99-code have exceeded the limit for the number of chat messages per hour. Please wait 50 minutes and 0 seconds before sending another message.

[coderabbitai]

Coding Plan

Summary

• Promote program-type gating to a first-class, optional field on nav registry entries and enforce it in isBaseballNavEntryVisible(), reusing the already-resolved programType in the nav context.
• Gate the organization, teams, and events entries to showcase/academy/club so the registry contract matches the existing requireShowcaseOrgRoute guard, which naturally removes the broken Organization hub for college/high-school/JUCO coaches.
• Keep the sidebar hub trigger keyed on the now-gated visible ids (with an explicit org program-type set for clarity), and add nav contract + route/shell mirror tests to lock the behavior and prevent future drift.

Design Choices

Design Choice 1: Should shared Team Events be split into a new surface, or should Organization Events be gated by program type?

Options Considered:

1. Gate the existing Organization Events entry by program type (showcase/academy/club) so it disappears for non-showcase coaches, who continue using the Calendar surface for team events.
2. Create a new, separate Team Events nav entry + route for non-showcase coaches, distinct from the showcase Organization Events surface.

Chosen Option: 1

Rationale: Option 1 — the destination route is already showcase-only and a separate team Calendar surface already exists, so gating avoids building a redundant new surface and directly removes the broken nav link.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Add Program-Type Gating to the Nav Registry

Introduce a first-class program-type gate on nav entries so registry visibility matches route-guard contracts, then apply it to the three Organization entries. This is the core fix that removes the broken hub for non-showcase coaches.

Task 1: Extend the nav entry contract with a program-type gate

Add an optional program-type allow-list to nav entries and enforce it in the visibility filter.

• Update src/lib/baseball/nav-registry.ts to add an optional allowedProgramTypes?: readonly BaseballProgramType[] | null field on BaseballNavEntry (import BaseballProgramType from src/lib/types/baseball-settings.ts).
• Extend isBaseballNavEntryVisible() so that when allowedProgramTypes is a non-empty list, the entry is visible only if ctx.programType is in that list; treat null/undefined as "all programs" to preserve current behavior for all other entries.
• Confirm getVisibleBaseballNav() / the nav context already supplies programType into the filter ctx; thread it through if the filter currently ignores it.

Task 2: Gate the Organization, Teams, and Organization Events entries

Apply the new gate to the three entries whose routes are showcase-only.

• In src/lib/baseball/nav-registry.ts, set allowedProgramTypes: ['showcase', 'academy', 'club'] on the organization, teams, and events entries so they match requireShowcaseOrgRoute's allowed program types.
• Optionally relabel the events entry to clarify it is the Organization Events surface (showcase-facing), keeping its href unchanged.
• Verify players are unaffected: the events entry's player visibility should follow the same program gate (showcase player contexts only) so player nav stays consistent with the route contract.

🤖 Prompt for AI agents

This phase introduces program-type gating as a first-class field on nav registry
entries and applies it to the three Organization-related entries in
`src/lib/baseball/nav-registry.ts`.

**Task 1: Extend the nav entry contract**
- In `src/lib/baseball/nav-registry.ts`, import `BaseballProgramType` from
`src/lib/types/baseball-settings.ts`.
- Add an optional field `allowedProgramTypes?: readonly BaseballProgramType[] |
null` to the `BaseballNavEntry` type/interface.
- Update `isBaseballNavEntryVisible()` to check this field: if
`allowedProgramTypes` is a non-empty array, the entry is only visible when
`ctx.programType` is included in that list. If `allowedProgramTypes` is `null`
or `undefined`, treat it as "all programs" (preserve existing behavior).
- Confirm that `getVisibleBaseballNav()` (or equivalent) passes `programType`
into the filter context (`ctx`); if it does not already do so, thread it
through.

**Task 2: Apply the gate to Organization, Teams, and Events entries**
- In the `BASEBALL_NAV_REGISTRY` definition in
`src/lib/baseball/nav-registry.ts`, set `allowedProgramTypes: ['showcase',
'academy', 'club']` on the `organization`, `teams`, and `events` entries —
matching the allowed program types enforced by `requireShowcaseOrgRoute()` in
`src/lib/baseball/server-route-guards.ts`.
- Optionally update the display label of the `events` entry to make clear it
represents the Organization Events surface (showcase-facing); do not change its
`href`.
- Ensure that the player-facing visibility of the `events` entry also respects
the same program gate, so player nav remains consistent with the route contract.

Phase 2: Align the Sidebar Organization Hub Trigger

Ensure the condensed sidebar no longer surfaces the Organization hub for non-showcase coaches and that the trigger logic is explicit and resistant to future drift.

Confirm and harden the Organization hub condition

Make the hub appear only when genuinely org-relevant entries are visible.

• In src/components/layout/sidebar.tsx, verify that with the registry now gating organization/teams/events, hasAnyVisible(ids, ['organization','teams','events']) evaluates false for college/high-school/JUCO contexts, removing COACH_ORGANIZATION_HUB.
• For defense-in-depth and readability, introduce an explicit ORG_PROGRAM_TYPES set (mirroring the existing RECRUITING_PROGRAM_TYPES pattern) and/or keep the hub trigger keyed on the now-gated visible ids, so the hub cannot reappear if an entry's gate changes.
• Ensure COACH_ORGANIZATION_HUB.hubPrefixes still resolve correctly for showcase/academy/club coaches.

🤖 Prompt for AI agents

This phase hardens the sidebar Organization hub trigger in
`src/components/layout/sidebar.tsx` so it cannot surface for non-showcase
coaches, even if the registry gate changes in the future.

- In `src/components/layout/sidebar.tsx`, locate
`buildCondensedBaseballNavigation()` and the `COACH_ORGANIZATION_HUB` display
logic.
- Verify that with the registry now gating `organization`, `teams`, and
`events`, the call `hasAnyVisible(ids, ['organization', 'teams', 'events'])`
evaluates to `false` for college/high-school/JUCO contexts — meaning
`COACH_ORGANIZATION_HUB` will not be shown for those coaches.
- For defense-in-depth and readability, introduce an explicit
`ORG_PROGRAM_TYPES` set (mirroring the existing `RECRUITING_PROGRAM_TYPES`
pattern) and/or keep the hub trigger keyed on the now-gated visible ids, so the
hub cannot reappear if an entry's gate is accidentally removed.
- Verify that `COACH_ORGANIZATION_HUB.hubPrefixes` still resolve correctly for
showcase/academy/club coaches after this change.

Phase 3: Tests — Nav Contract and Route/Shell Regression

Lock in the corrected behavior and prevent future drift between the registry and route guards.

Task 1: Add a program-type nav contract test for the Organization routes

Assert Organization route visibility per program type and role.

• Add a test (extend program-type-nav-variants.test.ts or create a new file in src/lib/baseball/__tests__/) that builds coach nav contexts for college, high-school, JUCO, showcase, and a player context.
• Assert organization, teams, and events are NOT visible for college/high-school/JUCO coaches, ARE visible for showcase (and academy/club) coaches, and that the player context matches the intended contract.
• Assert the sidebar's COACH_ORGANIZATION_HUB is absent for non-org coaches and present for org coaches (drive buildCondensedBaseballNavigation() with the same contexts).

Task 2: Add a route/shell regression mirror guard

Guarantee that every visible nav link routes to a page the user is authorized for (no immediate redirect bounce).

• Add a test (in src/lib/baseball/__tests__/, following the existing "middleware-registry mirror guard" pattern) that maps the program-gated registry entries to their server route guards in server-route-guards.ts.
• For each program-type context, assert that every visible nav entry whose href is covered by a route guard has that context's program type within the guard's allowed program types — i.e., no visible link would trigger a Command Center redirect for an authorized user.
• Include the Organization Events / Organization / Teams routes (requireShowcaseOrgRoute) explicitly, asserting their registry allowedProgramTypes equals the guard's allowed program types to prevent contract drift.

🤖 Prompt for AI agents

This phase adds tests to lock in the corrected nav behavior and prevent future
drift between the nav registry and route guards. All test files should live in
`src/lib/baseball/__tests__/` and follow existing patterns from
`nav-capability-gating.test.ts` and `program-type-nav-variants.test.ts`.

**Task 1: Program-type nav contract test**
- Extend `program-type-nav-variants.test.ts` or create a new test file in
`src/lib/baseball/__tests__/`.
- Build coach nav contexts for each of the following program types: college,
high-school, JUCO, showcase, academy, club, and a player context.
- Assert that the `organization`, `teams`, and `events` nav entries are **NOT**
visible for college/high-school/JUCO coaches.
- Assert that those same entries **ARE** visible for showcase/academy/club
coaches.
- Assert that the player context matches the intended contract for these
entries.
- Drive `buildCondensedBaseballNavigation()` with each context and assert that
`COACH_ORGANIZATION_HUB` is **absent** for non-org program types and **present**
for org program types (showcase/academy/club).

**Task 2: Route/shell regression mirror guard test**
- Add a new test file in `src/lib/baseball/__tests__/` following the existing
"middleware-registry mirror guard" pattern.
- Map the program-gated registry entries to their corresponding server route
guards in `src/lib/baseball/server-route-guards.ts`.
- For each program-type context, assert that every visible nav entry whose
`href` is covered by a route guard has that context's program type within the
guard's allowed program types (i.e., no visible link would trigger a Command
Center redirect for an authorized user).
- Explicitly cover the Organization Events, Organization, and Teams routes
(`requireShowcaseOrgRoute`), asserting that the registry's `allowedProgramTypes`
for those entries exactly equals the guard's allowed program types to prevent
contract drift.

Research

Baseball navigation is driven by a single master list in src/lib/baseball/nav-registry.ts (BASEBALL_NAV_REGISTRY) whose entries are filtered by isBaseballNavEntryVisible() using role and requiredCapability. The resolved nav context (getBaseballNavContext()) already carries programType, which today is only consumed for ordering and for the sidebar's RECRUITING_PROGRAM_TYPES hub gate. The sidebar (src/components/layout/sidebar.tsx) groups entries into hubs via buildCondensedBaseballNavigation(), showing COACH_ORGANIZATION_HUB when any of organization, teams, or events is visible. The destination pages (events, organization, teams) are server-guarded by requireShowcaseOrgRoute() in src/lib/baseball/server-route-guards.ts, which permits only showcase coach types and showcase/academy/club program types. Existing tests in src/lib/baseball/__tests__/ (nav-capability-gating.test.ts, program-type-nav-variants.test.ts) establish patterns for contract and mirror-guard testing.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase introduces program-type gating as a first-class field on nav registry
entries and applies it to the three Organization-related entries in
`src/lib/baseball/nav-registry.ts`.

**Task 1: Extend the nav entry contract**
- In `src/lib/baseball/nav-registry.ts`, import `BaseballProgramType` from
`src/lib/types/baseball-settings.ts`.
- Add an optional field `allowedProgramTypes?: readonly BaseballProgramType[] |
null` to the `BaseballNavEntry` type/interface.
- Update `isBaseballNavEntryVisible()` to check this field: if
`allowedProgramTypes` is a non-empty array, the entry is only visible when
`ctx.programType` is included in that list. If `allowedProgramTypes` is `null`
or `undefined`, treat it as "all programs" (preserve existing behavior).
- Confirm that `getVisibleBaseballNav()` (or equivalent) passes `programType`
into the filter context (`ctx`); if it does not already do so, thread it
through.

**Task 2: Apply the gate to Organization, Teams, and Events entries**
- In the `BASEBALL_NAV_REGISTRY` definition in
`src/lib/baseball/nav-registry.ts`, set `allowedProgramTypes: ['showcase',
'academy', 'club']` on the `organization`, `teams`, and `events` entries —
matching the allowed program types enforced by `requireShowcaseOrgRoute()` in
`src/lib/baseball/server-route-guards.ts`.
- Optionally update the display label of the `events` entry to make clear it
represents the Organization Events surface (showcase-facing); do not change its
`href`.
- Ensure that the player-facing visibility of the `events` entry also respects
the same program gate, so player nav remains consistent with the route contract.
===============================================================================

Task: 2

This phase hardens the sidebar Organization hub trigger in
`src/components/layout/sidebar.tsx` so it cannot surface for non-showcase
coaches, even if the registry gate changes in the future.

- In `src/components/layout/sidebar.tsx`, locate
`buildCondensedBaseballNavigation()` and the `COACH_ORGANIZATION_HUB` display
logic.
- Verify that with the registry now gating `organization`, `teams`, and
`events`, the call `hasAnyVisible(ids, ['organization', 'teams', 'events'])`
evaluates to `false` for college/high-school/JUCO contexts — meaning
`COACH_ORGANIZATION_HUB` will not be shown for those coaches.
- For defense-in-depth and readability, introduce an explicit
`ORG_PROGRAM_TYPES` set (mirroring the existing `RECRUITING_PROGRAM_TYPES`
pattern) and/or keep the hub trigger keyed on the now-gated visible ids, so the
hub cannot reappear if an entry's gate is accidentally removed.
- Verify that `COACH_ORGANIZATION_HUB.hubPrefixes` still resolve correctly for
showcase/academy/club coaches after this change.
===============================================================================

Task: 3

This phase adds tests to lock in the corrected nav behavior and prevent future
drift between the nav registry and route guards. All test files should live in
`src/lib/baseball/__tests__/` and follow existing patterns from
`nav-capability-gating.test.ts` and `program-type-nav-variants.test.ts`.

**Task 1: Program-type nav contract test**
- Extend `program-type-nav-variants.test.ts` or create a new test file in
`src/lib/baseball/__tests__/`.
- Build coach nav contexts for each of the following program types: college,
high-school, JUCO, showcase, academy, club, and a player context.
- Assert that the `organization`, `teams`, and `events` nav entries are **NOT**
visible for college/high-school/JUCO coaches.
- Assert that those same entries **ARE** visible for showcase/academy/club
coaches.
- Assert that the player context matches the intended contract for these
entries.
- Drive `buildCondensedBaseballNavigation()` with each context and assert that
`COACH_ORGANIZATION_HUB` is **absent** for non-org program types and **present**
for org program types (showcase/academy/club).

**Task 2: Route/shell regression mirror guard test**
- Add a new test file in `src/lib/baseball/__tests__/` following the existing
"middleware-registry mirror guard" pattern.
- Map the program-gated registry entries to their corresponding server route
guards in `src/lib/baseball/server-route-guards.ts`.
- For each program-type context, assert that every visible nav entry whose
`href` is covered by a route guard has that context's program type within the
guard's allowed program types (i.e., no visible link would trigger a Command
Center redirect for an authorized user).
- Explicitly cover the Organization Events, Organization, and Teams routes
(`requireShowcaseOrgRoute`), asserting that the registry's `allowedProgramTypes`
for those entries exactly equals the guard's allowed program types to prevent
contract drift.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!