LMS Implementation Execution Plan
Wave-based parallel execution strategy for Training App LMS features implementation
Overview
This document describes the wave-based execution strategy used to implement the Training App LMS features. The implementation was structured into 5 waves with parallel task execution where possible.
Implementation Summary:
- Total Waves: 5
- Total Tasks: 10
- Parallel Efficiency: 60% (6/10 tasks parallelizable)
- Status: ✅ All waves complete
Wave Structure
Wave 1: Foundation (Parallel)
Dependencies: None (foundational wave)
| Task | Description | Status |
|---|---|---|
| 1a | Authentication setup (simple - no org switching) | ✅ |
| 1b | UI Components (LessonContainer, Callout, CodeBlock, etc.) | ✅ |
Key Simplification: Training app uses simple auth model without organization switching layer.
Wave 2: Content
Dependencies: Wave 1 (needs UI components)
| Task | Description | Status |
|---|---|---|
| 2a | Content system + example course | ✅ |
Created course registry, types, and example "Platform Basics" course with 3 lessons + 1 quiz.
Wave 3: Data Access (Parallel, Simplified)
Dependencies: Wave 1 + Wave 2
| Task | Description | Status |
|---|---|---|
| 3a | Progress tracking hooks (direct Supabase) | ✅ |
| 3b | Assessments hooks (direct Supabase) | ✅ |
Key Simplification: Used direct Supabase client via useSupabase() instead of API routes. KISS principle applied.
Wave 4: Integration
Dependencies: Wave 3
| Task | Description | Status |
|---|---|---|
| 4a | Certifications system (auto-award logic) | ✅ |
Wave 5: Verification
Dependencies: All previous waves
| Task | Description | Status |
|---|---|---|
| TypeScript | pnpm --filter training check-types | ✅ |
| Build | pnpm --filter training build | ✅ |
Critical Path
Wave 1 (Foundation) → Wave 2 (Content) → Wave 3 (Data) → Wave 4 (Certs) → Wave 5 (Verify)
↓ ↓ ↓
[Auth + UI] [Content] [Progress + Assessments]
(parallel) (parallel)Simplifications Applied
1. Direct Supabase Client (No API Layer)
Original Plan: Create API routes in apps/api/src/training/
Simplified To: Direct Supabase access via useSupabase() hook
Rationale:
- Training data is user-scoped only
- No complex business logic requiring server-side processing
- Supabase RLS can enforce access control
- Fewer moving parts = fewer bugs
2. Simple Authentication
Original Plan: Copy full command-center auth setup
Simplified To: Use @repo/ui shared modules without org switching
What's Used:
AuthKitProvider+useAuth()from @workos-inc/authkit-reactuseRefocusSessionCheck()from @repo/ui/authuseUserProfile()from @repo/ui/profileuseSupabase()from @repo/ui/supabase
What's Skipped:
- Organization initialization layer
- Complex 3-layer init process
- Org switching capabilities
Deferred Items (YAGNI)
Items not implemented per YAGNI principle:
- PDF certificate generation
- Admin course management UI
- SSE real-time updates
- Course analytics dashboard
These can be added when requirements emerge.
Related Documentation
- Training App Overview - App infrastructure
- LMS Features - Full feature architecture
- Course Subshell - Navigation implementation
Last Updated: 2026-01-10