Sensei implementation roadmap
The repo now uses one migration plan with v4 as the target architecture and the current SPA treated as the starting point, not the finish line.
Current
Cloudflare Pages-hosted Vite app + React Router + Worker API + Neon + Drizzle + database-backed session auth
Target
Cloudflare Pages + Worker API + Neon + Drizzle + Lucia-style session auth
Use v4 as the platform reference while keeping the current Vite shell production-ready and dependency-ordered.
Phases
7
Tasks
18
Completed
16
In Progress
0
Guiding principles
Keep the app working after every phase.
Replace duplicate contracts before adding backend complexity.
Move mock features to real persistence feature-by-feature.
Ship resilience as code, not as team discipline.
Next move
Finish phase 1 cleanly
The current pass is about reducing duplication, keeping progress visible, and preparing the repo for the platform shell migration.
Open platform mapPhase 1. Foundation Alignment
Turn the architecture drafts into one executable plan and reduce duplication inside the current frontend.
Done when
The repo has one canonical roadmap, the app can display it, and AppContext stops maintaining separate copies of shared seed data.
Create one canonical roadmap
CompletedConsolidate v1-v4 into a single execution document that reflects the current repo reality.
Surface the roadmap inside the app
CompletedAdd a route and typed roadmap data so progress can be tracked from inside the product shell.
Reuse shared seed/domain data in AppContext
CompletedStop duplicating notification, application, and community seed data inside the active context layer.
Normalize page consumption of richer state models
CompletedUpdate feature pages to use the shared application, notification, and community shapes consistently.
Phase 2. Platform Shell Migration
Prepare the repository for the Cloudflare platform structure without losing the current UI.
Done when
Package boundaries for app, api, and shared contracts exist and the web shell remains stable.
Introduce package boundaries
CompletedSplit responsibilities into app, api, shared schema, and config layers.
Keep the route shell production-ready
CompletedPreserve the current UI while mapping route ownership to the future platform boundary.
Phase 3. Backend Foundation
Stand up the API, database, auth, validation, logging, and rate limiting expected by v4.
Done when
Auth and migrations run end-to-end and protected API routes are stable.
Create the Worker API layer
CompletedAdd Hono-style route handling, middleware order, and error wrapping.
Connect Neon and Drizzle
CompletedIntroduce reproducible migrations and the real persistence layer.
Implement auth flows
CompletedSignup, login, verification, reset, and session revocation now run through database-backed Worker APIs.
Phase 4. Real Data Layer
Replace the frontend mock layer feature-by-feature with DB-backed APIs and search.
Done when
Core data pages are API-backed and critical user flows no longer depend on hardcoded primary storage.
Move universities, courses, and scholarships to real APIs
CompletedCatalog data is seeded into the backend and served through API routes that power the feature pages.
Persist dashboard and content flows
CompletedApplications, notifications, community, content, FAQ, and quiz results now sync through API-aware flows instead of in-memory handlers.
Phase 5. SEO, Performance, and Resilience
Add the operational pieces that v2-v4 spelled out: SEO, caching, retry safety, and circuit protection.
Done when
Performance gates are enforced and resilience behavior is structural.
Implement metadata and discovery files
CompletedMeta, canonical URLs, JSON-LD, sitemap, robots, and route-level metadata are now wired into the app shell.
Add outbox, rate-limit, timeout, and circuit protections
CompletedTelemetry intake, sliding-window rate limiting, outbox visibility, timeout wrappers, and circuit protection are structural in the API layer.
Enforce bundle budgets in CI
CompletedThe web app now ships with a build-time bundle budget check that can fail CI when major assets grow past agreed limits.
Phase 6. Feature Completion
Finish the end-to-end student and admin features on real workflows.
Done when
Community, resources, CMS, recommendations, admin moderation, FAQ, and audit workflows are functional end-to-end.
Deliver real community and moderation workflows
CompletedPosts, replies, reports, moderation queues, and admin resolution flows now run through shared API boundaries.
Wire the admin panel to real APIs
CompletedReplace static admin panels with authenticated moderation, CMS, resource, FAQ, telemetry, and audit workflows.
Phase 7. AI and Global Expansion
Add AI assistants and internationalization only after the core platform has real usage data.
Done when
The product is stable, measured, and ready to absorb the extra operational complexity.
Add MCP and agent workflows in sequence
DeferredMCP tools first, then richer agentic behavior after operational maturity.
Add Urdu and RTL support
DeferredGlobalization follows proven traction in the core Pakistan market.