Volleyball Elite Academy development update

Volleyball Elite Academy Coach Lifecycle Phase 4 — Coach Portal Cleanup & Stalled-Application Visibility Coach Lifecycle Phase 4 — Coach Portal Cleanup & Stalled-Application Visibility Volleyball Elite Academy — Development Update • May 27, 2026 --- title: Coach Portal cleanup & stale-application visibility --- --- title: Coach Portal cleanup & stale-application visibility --- Coach Lifecycle Phase 4 — Coach Portal Cleanup & Stalled-Application Visibility What & Why After Phases 1–3 shipped, the coach surface still has three rough edges that show up immediately when you click around the product: 1. is still a 5,419-line monolith with 8 tabs (Dashboard, My Assignments, Opportunities, My Profile, Payroll & Pay, Certifications, Video Reviews, My Athletes). It was deliberately left as-is by Phase 1, which only carved out onboarding. Day-to-day editing is now painful for the same reasons that motivated splitting in #1324. 2. Two coach landing pages still coexist. Phase 1 introduced and said it would "replace/redirect ", but is still registered in and still embeds onboarding queries/mutations alongside a link to . The duplicate routes create a real risk that a user starts onboarding in one place and finds none of it on the next visit. 3. The admin Coach Applications queue doesn't surface staleness. lists pending applications with completeness % and Tier 1 fields, but nothing tells an admin "this applicant has been sitting at step 5 for 30 days" or "this applicant has been Tier 1–ready and waiting for a decision for 14 days". Applicants quietly fall through the cracks. This is pure cleanup — no schema changes, no new product behavior — but it removes the most visible drag on iterating further on the coach lifecycle. Done looks like is decomposed along tab boundaries: each of the 8 tab contents lives in its own file under (or similar), and the top-level page is reduced to layout + tab routing + shared hooks. No behavior changes for an approved coach — same tabs, same data, same testids. There is exactly one coach-onboarding landing page reachable in the app. either redirects to (preferred) or is deleted from and any links pointing at it are updated. The portal's in-line onboarding queries/mutations are removed; the portal only shows a "Continue onboarding" CTA that links out to . On , each application row shows a clear "Last activity N days ago" indicator computed from (or the latest of step-completion timestamps), and applications that are Tier 1–ready but un-approved for more than a configurable threshold (default 14 days) are visually flagged as "Awaiting decision". A simple sort/filter ("show only stalled") is available. Admin Coach Applications queue has a separate "Stalled" section or filter pill that an admin can land on directly, so nobody has to scroll a long list to find the cases that need attention. No regression to the Phase 1 approve flow: clicking Approve on a stalled application still creates the and stamps step-7 fields exactly as before. Out of scope Splitting any other large file (the Session Operator workbench is covered by #1326–#1328). Adding new onboarding steps, certifications, or Tier 2 fields. Email nudges to stalled applicants — visibility for admins only in this phase. A future task can add proactive applicant nudges if desired. Any change to , training-cycle, or flows. Anything that requires a new database column or migration. Steps 1. Decompose by tab. Move each tab's body (Dashboard, My Assignments, Opportunities, My Profile, Payroll & Pay, Certifications, Video Reviews, My Athletes) into its own component file. Keep the top-level page responsible only for the role guard, the shell, and shared state/hooks. Preserve every exactly. 2. Remove in-portal onboarding code. Delete the query, the step-update mutation, and any onboarding UI that still lives in the portal. The portal should only know "is this user already an Academy Coach?" — if not, render a single CTA that links to . 3. Retire . Either redirect it to via a one-line wouter route or delete the page and update any incoming links. Pick redirect if there are external/email links pointing at it; pick deletion if there aren't. 4. Compute staleness on the admin applications endpoint. Return per-row (the most recent of or any ) and a enum (, , ). 5. Render staleness on . Add a "Last activity" column, a "Stalled / Awaiting decision" badge driven by , and a filter pill that narrows the list to non-NONE rows. Default the threshold to 14 days; surface the threshold as a constant so a SuperAdmin can tune it via PR without UI work. 6. Smoke-check the approve flow end to end. After the refactor, walk through: anonymous → become-a-coach → submit Tier 1 + step 5 artifacts → admin sees them in the queue with "Tier 1 ready" → admin approves with a level + pay band → user becomes and lands on the portal with no onboarding tab in sight. Architectural constraints No schema changes. Staleness must be derived from existing columns on (and joined tables if needed). Preserve all existing s on the portal; tests rely on them. Role promotion stays through the same Phase 1 path ( or its current equivalent). Do not reach into the assignment table directly. Keep the portal's existing query-key shapes so cached data survives the refactor (e.g. stays the same). Do not log or surface PII (uploaded artifact URLs, NCCP numbers) in any new logging added during the staleness work. Relevant files - - - - - - - - Volleyball Elite Academy Reply to this email — we read every reply. You received this because you have an account with Volleyball Elite Academy. elitevolleyball.training