Your athlete front door, powered by SlidraOS.
athlete-fd is the athlete experience powered by SlidraOS. It gives athletes a warmer, focused place to see today's priorities, progress, feedback, and training plans while SlidraOS owns identity, permissions, workflows, canonical records, intelligence, reporting, and audit history.
Train with a clear next step.
SlidraOS owns the system. athlete-fd owns the experience.
This first-party product surface is intentionally wired around the consolidation rule: no duplicate identity, permission, athlete profile, workflow, reporting, or intelligence system inside athlete-fd.
Identity and authentication
SlidraOS session, credential, password-reset, and login-rate-limit services. A duplicate athlete-fd login system would create inconsistent sessions and weaker security controls.
Authorization and field visibility
SlidraOS role permissions and server-side visibility helpers. Client-only role checks could expose minor athlete data or coach-private notes.
Canonical athlete profile
SlidraOS player, family, roster, team, and player-development records. A second athlete profile table would create stale or conflicting athlete history.
Workflow state and history
SlidraOS workflow/event/audit history patterns and product operating-system services. Local intake or readiness states would break auditability and staff handoff.
Readiness and intelligence outputs
SlidraOS rankings, matchup, player-development, and intelligence services. Independent athlete-fd scoring would create ungoverned recommendations without provenance.
The athlete-facing experience stays clear, mobile-first, and trustworthy.
Technical consolidation should improve the athlete journey, not make it feel like an admin console with a new label.
Athlete-facing journey design
Own mobile-first onboarding, dashboard, task presentation, progress views, and UX copy. Preserve loading, empty, error, unauthorized, partial-data, and retry states in each athlete flow.
Athlete actions should feel immediate
athlete-fd can compose low-latency views, but durable reads and writes still resolve through SlidraOS-owned services.
Sensitive athlete data stays permissioned
Server-side SlidraOS authorization decides field visibility before athlete-fd renders profile, development, guardian, or staff data.
Every state has a consumer-grade fallback
Loading, empty, error, unauthorized, partial-data, retry, and session-expiration states are part of the product surface.
Current SlidraOS checkout has the operating layer, not a separate athlete-fd app.
The repo already contains SlidraOS-owned auth, permissions, canonical players, teams, development records, video evidence, rankings, and matchup intelligence. A standalone athlete-fd codebase was not present in this checkout during the first inventory pass.
Safe next engineering move
Import or point Codex at the existing athlete-fd source repository, then classify each table, endpoint, permission check, workflow state, report, and recommendation against the boundary map before any durable migration runs.
External athlete-fd source repository: Locate and import/audit the existing athlete-fd repository before migrating durable data paths.
Give athletes the front door without splitting the system.
Use athlete-fd for the journey and SlidraOS for the durable source of truth. That keeps the experience consumer-grade and the operating layer governable.