Rullst Academy product programme
Status: Rullst Academy runs at academy.rullst.win as a separate application; it is not a shipped framework capability. This page records its boundary with the framework and the evidence needed before its operation counts as framework release evidence. Academy must live in a separate repository and depend only on published Rullst packages; its product content and deployment are not part of the
rullstcrate.
Rullst Academy is a web-first platform for learning Rust and Rullst through short explanations, authoritative interactive exercises, review sessions and small practical projects. The target is an enjoyable learning product, not a claim that a framework can automatically produce good pedagogy or a universally better alternative to an existing course.
Product boundary
The browser-accessible web application is canonical. Server-side code owns
identity, school scope, authorization, course versions, grading, progress,
achievements and audit. Installing the application as a Progressive Web App
(cargo rullst make:pwa) does not create a second security or business model.
The Academy repository must:
- pin one exact Rullst RC or stable release and contain no monorepo path dependencies;
- use public CLI scaffolds and escape hatches instead of private framework modules;
- keep curriculum, content, product UI, deployment and learner support in the application;
- contribute only proven, reusable abstractions back to optional framework crates;
- provide application-level upgrade, backup/restore and recovery feedback for future releases; Academy is not a prerequisite for any Rullst release.
Focused first release
The first useful Academy release should complete one narrow journey well:
- A learner creates an account, joins the appropriate school and enrolls in a published course.
- The learner reads or watches an accessible lesson and resumes recorded progress.
- A server-authoritative quiz, matching or typed-recall activity records an idempotent result without accepting client-authored points.
- The review queue schedules a later activity and an achievement or certificate is derived from persisted rules.
- A practical project is submitted to a constrained runner and receives deterministic test feedback.
- An instructor drafts, reviews and publishes content; an administrator can audit the resulting events without crossing school boundaries.
Polish should concentrate on this journey: responsive SSR, keyboard operation, visible focus, reduced motion, clear errors, fast navigation and useful empty states. Payment, social features, advanced gamification, native-store releases, offline synchronization and a large course catalogue are not prerequisites for the first release.
Initial curriculum and projects
Two short tracks are enough to validate the product:
| Track | Initial lessons | Practical outcome |
|---|---|---|
| Rust foundations | ownership and borrowing, structs/enums, pattern matching, errors, iterators, async and tests | a tested command-line application that persists bounded data |
| Rullst web development | project creation, routes/SSR, forms, ORM/migrations, authentication/authorization, queues and deployment preparation | a secure small web application with owner-only CRUD and background work |
Every exercise must have a versioned ruleset, bounded input/output and retained test identity. Curriculum authors, not an LLM, define the expected concepts, tests, hints and completion conditions.
Safe practical-code runner
Learner code is hostile input. It must never execute inside the Academy web process or through a mounted host Docker socket. The application-owned runner must use a disposable rootless container or stronger microVM boundary with:
- no network by default and no cloud/application credentials;
- read-only base images and a fresh writable workspace per attempt;
- explicit CPU, memory, process, file, disk, output and wall-clock limits;
- a reviewed Rust toolchain/dependency policy and immutable image digest;
- bounded compile/test logs with control-character handling and secret redaction;
- an idempotent submission identity, queued execution, cancellation and terminal retry/dead-letter policy;
- cleanup after success, failure, timeout and worker restart;
- adversarial escape, fork-bomb, filesystem, network and output-amplification tests before public use.
The runner returns structured test evidence. It does not grant points directly;
the Academy service binds that evidence to the authenticated learner, project
version and server-owned scoring policy. Rullst does not ship this runner; with
rullst-labs, it implements the Labs controller contract.
Local AI mascot
Privacy and proportional age assurance are v13 P0 dependencies for the applicable learner journeys; follow the shared privacy programme. Academy must decide its audience and processing purposes, validate any guardian relationship, and implement actual export/deletion adapters. The v12 Academy scaffold’s age bands and consent records, retired in v13, are not independent age or guardianship verification. Reading lessons must not acquire a camera requirement without a justified policy.
The mascot can be a friendly tutor backed by the existing Ollama path in
rullst-ai, with a deterministic offline fallback for tests. It should use a
bounded RAG corpus containing version-pinned official Rust material, Rullst
documentation and Academy-authored hints.
The mascot may explain an error, ask a guiding question, retrieve a relevant lesson or suggest the next exercise. It must not:
- authoritatively grade code, invent completion or change persisted points;
- execute arbitrary tools or learner code outside the sandbox boundary;
- retrieve another learner’s conversation, submission or school data;
- receive secrets, raw session values or unnecessary personal data;
- present an uncited generated statement as official Rust or Rullst behavior.
Responses should carry source references and a visible “local AI tutor” label. Provider/model unavailability must leave the curriculum and deterministic grader usable. Prompt-injection regressions, context limits, tenant binding, PII masking and secret-minimized audit remain mandatory.
What exists and what remains application work
| Boundary | Current reusable foundation | Academy must still prove |
|---|---|---|
| Learning domain | The LMS example’s (examples/lms, the former v13 LMS starter) catalog, modules, lessons, accessible player, enrollment and owner-bound progress; the v12 Academy scaffold’s activities, quizzes, review, completion, certificates, leaderboard and automation were retired | those learning features, coherent product UX, content quality, complete authorship and browser E2E |
| Identity and schools | Session/RBAC helpers; the LMS example has no schools (the v12 school-scoped contracts were retired) | schools and memberships, account recovery, invitations, device/session policy and every cross-school negative |
| AI tutor | guarded providers, Ollama fallback, bounded tenant-aware RAG and audit contracts | curated corpus, pedagogy, model evaluation, capacity and user-facing failure behavior |
| Practical projects | queues, outbox and bounded messaging foundations; the rullst-labs job and grading contracts (published since 13.0.0-alpha.1) | isolated runner, immutable images, resource policy and escape testing |
| Media | bounded accessible lesson metadata, captions and transcripts; the opt-in rullst-media Bunny Stream candidate (published since 13.0.0-alpha.1) | upload, storage, scanning, transcoding, caption quality and retention |
| Operations | health/readiness, telemetry, deploy scaffolds and upgrade assistant | production topology, TLS/proxy identity, backup/restore, rollback, alerts and incident response |
Repository and release boundary
Academy will be developed in a separate repository and conversation. This document records only the intended boundary and the reusable framework foundation that already exists; it does not authorize further Academy work in the Rullst repository and it is not a framework release gate.
- v12: closed through its own gates without Academy; the line reached end of life on 16 October 2026.
- 13.0: 13.0.0-alpha.4 is the feature freeze, 13.0.0-rc.1 takes fixes and documentation only, and Academy does not need to exist or run against either.
- After 13.0: reusable improvements discovered by the external Academy may be proposed with their own bounded contracts; research-heavy or breaking work remains governed by the maintenance scope.
The open canonical milestones in the current roadmap belong to the long-term v13 horizon. They do not block 13.0.0, and Academy itself is not part of that milestone denominator.
Acceptance evidence
Before Academy can be treated as release evidence, record all of the following against immutable application and framework SHAs:
- the complete learner/instructor/admin journey on PostgreSQL, with SQLite kept as a local profile only when its declared limits are acceptable;
- anonymous, cross-user, cross-role and cross-school denial tests;
- browser accessibility and responsive-layout checks for the primary journey;
- sandbox abuse tests and bounded compile/test output;
- backup restoration, forward migration, rollback and framework-upgrade drills;
- dependency-only installation from crates.io with no Rullst path overrides;
- load and failure tests with unavailable AI, mail, cache and worker services;
- a documented human GO/NO-GO decision and remaining product risks.
Related reusable guides include accessible Academy media, tenant-bound RAG, and the assisted upgrade workflow.