-
Notifications
You must be signed in to change notification settings - Fork 1
Roadmap
Items 1–14 are complete. Items 19 is complete. This file tracks the remaining work.
Status: Complete (PRs #93, #94)
Core smoke tests covering the offline teacher workflow are live. playwright.config.ts and e2e/ are in the repository.
Status: Complete (PR #104)
Tier: Testing & Quality
Magic-link sign-in via the admin generate_link API (no email/inbucket required), cloud persistence, offline-queue-and-flush, and pending-queue checks are all covered in a dedicated supabase Playwright project (e2e/specs/14-supabase-sync.spec.ts).
What was built:
-
e2e/fixtures/supabase.fixture.ts— creates a fresh test user + school per test, signs in via magic link, tears down after -
npm run e2e:supabase— runs the Supabase suite (--project=supabase --workers=1) against a local stack - CI job
E2E — Supabase Integrationruns after the standard offline suite; spins upsupabase start, exports credentials, uploads separate artifacts - Five test scenarios: magic-link auth, cloud persistence after localStorage wipe, deletion sync, offline-queue flush on reconnect, queue empty while online
What to keep building (see CLAUDE.md):
- Shared rubric flow — teacher A shares, teacher B sees it (not yet covered)
- Grading-while-offline → sync on reconnect
- Student portal sign-in via share code
- Broader coverage of the reconnect-hydration path and multi-device data merging
Status: Planned
Tier: Architecture
Effort: 8–12 days
Currently localStorage is the source of truth and Supabase is a write-through cache. This causes Supabase data to lag behind, making cross-device access unreliable. Flipping the model — Supabase primary, localStorage offline cache — makes cloud sync reliable and opens the door to real-time collaboration between colleagues.
Scope:
- Audit the read path in
src/store/storage.tsandsrc/context/AppContext.tsx - AppContext hydrates from Supabase on load (when configured); localStorage is populated as a cache
- Offline detection via
navigator.onLine+ reconnect events; queue writes and flush on reconnect - Conflict resolution: last-write-wins on
updated_attimestamp (simplest safe default) - Auth-gated: the Supabase-first path only activates when
VITE_SUPABASE_URLis set; full offline-only mode is unchanged for users without Supabase
Architecture impact: High — core data layer (storage.ts, AppContext, StorageSync). Requires a migration path for existing localStorage-only users and thorough E2E coverage before ship (see item 14).
Status: Planned
Tier: Reach & Localisation
Effort: 1 day (technical) + translation review per language
EN and NL are complete. FR and DE are ~93% complete — both are missing the admin and onboarding namespace keys. Spanish opens a large new teacher market.
What to build:
- Complete the two missing namespace keys in
src/locales/fr.jsonandsrc/locales/de.json - Add
src/locales/es.json(copy ofen.jsonwith values translated to Spanish) - Register
esinsrc/i18n.ts - Add Spanish to the language selector in
src/pages/SettingsPage.tsx - Update
Internationalisation.md(wiki) to list ES as supported - Update
CLAUDE.mdto note all five locale files must be updated together: en, nl, fr, de, es
Architecture impact: Minimal — locale files + i18n registration only.
Status: Planned
Tier: Content & Templates
Effort: 1–2 days
IB is used in 5,000+ schools globally. MYP Language Acquisition has 4 criteria × 8 performance levels (0–8), a clean fit for the existing rubric model. DP Language A Literature and Language B criteria can also be pre-built.
What to build:
- IB MYP Language Acquisition criteria as a built-in rubric template (JSON in
src/data/) - IB DP Language A: Literature criteria
- IB DP Language B criteria
- Surface these in the template picker in the rubric builder
Architecture impact: Minimal — static data files + template picker extension.
Research: IB criteria are publicly documented; no API needed.
Status: Planned
Tier: EFL Core
Effort: 2–3 days (static) or 5–7 days (live API)
Cambridge levels (KET/PET/FCE/CAE/CPE mapping to A2–C2) are the dominant assessment framework for EFL teachers. A Cambridge API key field already exists in AdminPage settings but is not yet wired to any functionality.
What to build:
- Investigate Cambridge Assessment API availability and terms; if accessible, integrate via a new
src/services/cambridgeApi.tsmodelled onsrc/services/standardsApi.ts - If a live API requires a partnership agreement, ship as static CEFR-mapped Cambridge descriptor data (aligned to the existing CEFR infrastructure)
- Surface Cambridge exam labels (e.g., "B2 First") alongside CEFR levels in the grading and analytics views
Architecture impact: Medium — new service module; CEFR level mapping already exists.
Status: Complete
Tier: UX
Print buttons added to StudentProfilePage, StatisticsPage, and ComparativeGrading. Centralized @media print block in src/index.css hides nav, sidebar, and interactive controls; forces white background; handles view-specific classes (.statistics-controls, .comparative-actions).
Status: Planned
Tier: UX / Personalisation
Effort: 2–3 days
The app UI is visually tied to a single accent color and the Inter font. Full theme support lets schools and individual teachers express their identity and makes the app more accessible for neurodiverse students who prefer certain typefaces.
Phase 1 (in progress): Foundation already shipped:
-
AppSettings.uiFontFamilyfield + AppContext applies it as--fontCSS variable with dynamic Google Fonts loading - 8 named accent-color preset swatches in Settings → General (Ocean, Forest, Indigo, Sunset, Rose, Slate, Teal, Gold)
- UI font picker in Settings → General (Inter, Nunito, Source Sans 3, Lato, Roboto)
Phase 2 (planned): Full theme bundles:
- Define 4–6 named themes (e.g. "Academy", "Nature", "Midnight", "Warm") — each theme sets
accentColor,uiFontFamily,defaultFormat.fontFamily,defaultFormat.headerColor - Add a
colorPreset?: stringfield toAppSettingsto track the active preset name - Implement tonal accent-color scales (50–900 steps via
color-mix()or LCH interpolation) so--accent-50through--accent-900are available for richer component styling in charts and rubric exports - Export font library for rubric DOCX/PDF: include decorative options:
Playfair Display(elegant serif headings),Oswald(condensed bold),Bebas Neue(display caps),Special Elite(distressed typewriter),Courier Prime(clean terminal) - Rubric title "ASCII / terminal art" styling: monospace fonts + optional border decorations around rubric headings in DOCX export
What to build:
- Theme definition file:
src/data/themes.ts— array of{ id, label, accent, font, headerColor, exportFont }objects - Theme picker in Settings → General (visual card swatches with preview)
- Update
src/context/AppContext.tsxto apply theme bundles atomically (singleupdateSettingscall) - Extend
src/utils/docxExport.tsandsrc/utils/pdfExport.tsto readsettings.defaultFormat.fontFamilyfor decorative heading fonts - CSS custom properties audit: ensure
--accent-{50..900}scale is wired consistently to charts, badges, and rubric cell highlights
Architecture impact: Low-medium — theme data file + Settings UI + CSS variable additions. No data model migration needed.
Status: Planned
Tier: UX / Features
Effort: 3–4 days
All underlying data exists (grades, CEFR sessions, essays, feedback history) but is spread across separate pages. A portfolio view aggregates a student's full year into a single scrollable report — useful for parent-teacher conferences, student self-reflection, and end-of-year reporting.
What to build:
- New route
/students/:id/portfolio(or a tab onStudentProfilePage) - Chronological timeline: rubric grades → essays submitted → CEFR assessments → speaking sessions
- Print/export to PDF from the portfolio view
- No new data fetching; purely a UI aggregation of existing AppContext state
Architecture impact: Low — new page on existing data model.
Status: Planned
Tier: Compliance
Effort: 3–5 days
WCAG 2.1 AA compliance is required by EU law (EN 301 549) for software used in schools. The app is currently untested for accessibility. Key risk areas: icon-only buttons without aria labels, keyboard navigation in the grading interface, color contrast of CSS custom properties in light and dark mode.
What to build:
- Run axe-core or Lighthouse accessibility audit; document the top 10 violations
- Fix: add aria labels to all icon-only buttons (lucide-react icons)
- Fix: ensure the rubric level selector in GradeStudent is keyboard-navigable (arrow keys, Enter)
- Fix: verify color contrast ratios for
--accent,--text,--bg-elevatedin both themes - Add axe-core to the Vitest/Playwright suite so regressions are caught automatically
Architecture impact: Low — HTML attributes and CSS only.
Status: Planned (Community Contribution)
Tier: Integrations
Effort: 4–6 days per platform
Magister and SOMtoday are the dominant student information systems (SIS) in Dutch schools. Auto-importing class rosters would eliminate the largest manual onboarding step for NL teachers. Full integration documentation is in /docs/MAGISTER_INTEGRATION.md.
What to build:
-
src/services/magisterApi.ts— Magister REST + OAuth flow -
src/services/somtodayApi.ts— SOMtoday OpenID Connect flow - OAuth token exchange must go through a Supabase edge function (client secret cannot be exposed in the SPA)
- Student data model already exists; the import maps to existing types
Architecture impact: Medium — new service files; edge function for token exchange.
Note: This item is open for community contribution. Core team will review and merge a well-tested PR.