Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Rullst Academy product programme

Status: proposed reference product, not a shipped framework capability. Academy must live in a separate repository and depend only on published Rullst packages. Its operation is evidence for the framework; its product content and deployment are not part of the rullst crate.

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. Omni shells may later add narrowly scoped native capabilities without becoming 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;
  • act as the first real upgrade, backup/restore and recovery consumer before a Rullst stable release is declared ready.

Focused first release

The first useful Academy release should complete one narrow journey well:

  1. A learner creates an account, joins the appropriate school and enrolls in a published course.
  2. The learner reads or watches an accessible lesson and resumes recorded progress.
  3. A server-authoritative quiz, matching or typed-recall activity records an idempotent result without accepting client-authored points.
  4. The review queue schedules a later activity and an achievement or certificate is derived from persisted rules.
  5. A practical project is submitted to a constrained runner and receives deterministic test feedback.
  6. 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:

TrackInitial lessonsPractical outcome
Rust foundationsownership and borrowing, structs/enums, pattern matching, errors, iterators, async and testsa tested command-line application that persists bounded data
Rullst web developmentproject creation, routes/SSR, forms, ORM/migrations, authentication/authorization, queues and deployment preparationa 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.

Local AI mascot

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

BoundaryCurrent reusable foundationAcademy must still prove
Learning domainGenerated curriculum, enrollment, progress, activities, quizzes, review, completion, certificates, leaderboard and automation foundationscoherent product UX, content quality, complete authorship and browser E2E
Identity and schoolsSession/RBAC helpers and persisted school-scoped LMS contractsaccount recovery, invitations, device/session policy and every cross-school negative
AI tutorguarded providers, Ollama fallback, bounded tenant-aware RAG and audit contractscurated corpus, pedagogy, model evaluation, capacity and user-facing failure behavior
Practical projectsqueues, outbox and bounded messaging foundationsisolated runner, immutable images, resource policy and escape testing
Mediabounded accessible lesson metadata, captions and transcriptsupload, storage, scanning, transcoding, caption quality and retention
Operationshealth/readiness, telemetry, deploy scaffolds and upgrade assistantproduction 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.0: close the framework independently through its coverage, CI/package/security, upgrade and release-candidate gates. Academy does not need to exist or run against the RC.
  • v12.0.x: maintenance only for confirmed framework defects and security fixes, without an Academy capability programme.
  • v13: the next feature line. Reusable improvements discovered by the future external Academy may be proposed with their own bounded contracts; research-heavy or breaking work remains explicitly governed by v13 criteria.

The 32 canonical milestones that are not fully closed belong to the long-term v13 horizon. They are not release blockers for v12.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, server-authoritative activities, durable spaced review, tenant-bound RAG, and the assisted upgrade workflow.