1. Building a course
   sources in, eight course-stamped collections, generated content you can check
2. The supervised turn
   ten stages, who sees what, the ceiling, the detector and the judge
3. The learner model
   evidence, mastery, decay, and how they set the ceiling

4. Running it
   deploys, money, security, data rights, operations
5. Keeping it correct
   tests that read the code, simulated students at $0, how it was built
6. Lessons and open problems

• 18 frame tags: student message, answer and code, transcripts, drafts, the rolling summary, class materials, exam names, run results, a TA's message, and more.
• Placement: the rolling summary and sandbox results ride in the user turn, never the system prompt.
• Instructors too: an exam name or uploaded material reaches every enrolled student's prompt, so it is framed like student text.
• INJECTION is an intent. It never raises the ceiling, and it forces a three-sample judge.

Bands: mastery ≥ 0.85 → H2; ≥ 0.70 → H3; ≥ 0.40 → H4; below → H5. Less shown, more scaffolding.

1. Base: the most permissive band among the goals in scope. No evidence on one goal means H5.
2. Code floor: an attempt, or a question about the student's code, gets at least H4. Never on a degraded classification.
3. Escalation: an impasse or a granted "Show me more" adds one, capped at H6, counted from the band and floor, so it cannot ratchet.
4. Exam review: lifts to H5 in a review window, only if every goal is in range and mastered and the turn has no code.
5. Lockdown: a goal under a pending mastery check caps the turn at H1.
6. Explain mode (admin, per course) reaches H7, never past a lockdown or a graded assignment.
7. Conduct restriction: H1, applied last, so nothing lifts it.

Solution demands and adversarial intents never raise and never tighten the ceiling: route kindly.

• Four tools: find_topic (moves the slide panel), get_lecture_outline, get_exercise, evaluate_code (a 0 to 4 score and one hint, never corrected code). The envelope filters which ones the actor gets.
• Bounded loop: at most three tool rounds. Tool inputs are not trusted; a call stays inside the courses the student may open.
• One prefix for every course: it names no course, so one cache entry serves them all.
• Memory: eight messages verbatim; older ones fold into a rolling summary after the reply, in a task of its own.

Arithmetic on list prices, not measured spend. The write pays for itself on the second cached call within the hour.

• Why not 5 minutes: students read for longer than that between messages, so a 5-minute entry had always expired.
• Warm-up: opening the chat page sends a max_tokens=0 request that writes the cache, skipped while the entry is alive.
• Order matters: cached block first, varying block last, tools declared identically on every call, or the cache never hits.
• Other levers: small models supervise; the judge runs only on risky turns; a gated turn spends nothing on retrieval.

• Cuts any C++ block over 4 lines, and any C++ at all at H4 and below (signatures and blanked templates too). At H5 and H6 a long block is held for the judge's code review instead.
• Finds code in fences, tildes, indented blocks, raw <pre>, runs of single-span lines, bare code at the margin, and a block that closes braces an earlier one opened.
• Decodes base64 runs and flags the ones that decode to C++.
• Exempt: pseudocode with ___ blanks, four lines or fewer, inline spans in prose.

• When: solution demands, exam leaks, injections, lockdowns, code-adjacent turns at H4 or below, every escalated turn, graded-assignment turns, every degraded classification. Routine concept chat skips it.
• What it sees: the envelope, the ladder, the cited slide's title, the redacted draft.
• Verdict: allow, revise or block, with a rule from a fixed list. High-risk turns take three samples and a majority; ties go strict.
• Revise once: the actor rewrites with the violation named; failing that, a templated pointer to the slides.

A real verdict, from a local run this week (every model call through the claude CLI, no knowledge base, a demo student, no production data):

"The draft shows a complete, compilable function solving a different problem (sumList), which is compliant at H5 as a worked example, but then immediately applies it to the student's own task by naming the exact bug in their insertBack code..." rule: code_reveal · verdict: revise · detector cut: yes

The worked example was allowed. Pointing it at the student's own bug was not. The rewrite failed too, so the student got the templated pointer to the slides.

• rung_used is the ceiling enforced, not the rung the reply reached. Measuring the latter is an open problem.
• One function, ledger.record_call, prices and writes every model call's row. It replaced about 18 hand-written sites.
• The ledger feeds the admin's Supervision tab, the daily digest, the cost report and the nightly auditor.

A well-practised goal (high FSRS stability) barely decays; forgetting raises the ceiling back toward H4 and H5 on its own. Mastery is sticky by design: a bad streak shows through decay and the review clock, not by relocking.

Activity data (page views, slide dwell) only triggers offers, never evidence or a ceiling input. Only a student's first answer per find-my-bug item counts.

• Manual deploys: a workflow that refuses a commit the tests have not passed, and drives a maintenance page over the swap.
• Seeds as release assets: the store and audio land once on the persistent disk; the decks and the mastery bank on every boot. Free egress, no object store.
• Fail-soft boot: each seed is downloaded with retries, unpacked to scratch, checked, then swapped in, with a marker written last. A failure keeps the previous copy and is reported once the app is up.

• Migrations at boot: every revision after the baseline is guarded. A column is dropped only one deploy after the models stop mapping it, so a rollback still works.
• Restarts: a reloaded page reattaches to its running reply; a turn a deploy cuts off is marked interrupted; a 502 shows "restarting" and never eats what the student was typing.
• The image: non-root, the embedding model baked in, and no compiler.

• Export: one function builds every data package, and its audience has no default. A table in the erasure scope with no export decision fails a test.
• Delete: the package is sealed with age before any row goes. Tombstones outlive every backup, so a deletion can be re-applied after a restore.
• Forget: a daily sweep anonymizes identifiable records a year after the term, keeping de-identified telemetry under a pseudonym.

• Minimal by construction: activity events carry ids and counts, never text; interests and reply language are fixed codes; logs name students by number; Sentry is scrubbed.
• Never in a prompt: a roster. Never held: an instructor's Canvas token. Never sent: grades, either way.
• Class figures: no percentile under five students; staff out of every median.

• Nightly pg_dump, encrypted with age to an offline key, kept 21 days, plus an off-site copy. The job fails rather than store a readable dump.
• A monthly restore drill.
• An ops ledger: every scheduled job reports each run; a lateness check catches a job that never started, which an in-run failure email cannot.
• Monitoring: an outside uptime probe, Sentry, an email on a burst of tutor failures, and a row for every error page a browser gets.

"One X" rules, each enforced by reading the source:

• only agent/state/ writes learner state
• only actor_client.py calls the actor model; no other Anthropic client
• only cli_launch.py starts the CLI
• no async route touches the database off the threadpool
• every environment variable is in the manifest
• no non-atomic write in the pipeline

Plus mypy on every router, the agent, scripts and the pipeline, with no override; a clock scan that runs date-bound tests a week early; random test order.

• Claude Code sessions wrote most of the code: in the week the clone covers, 176 of 316 commits carry a Claude co-author line.
• CLAUDE.md is the rulebook: 48 one- or two-line invariants, each with a long-form section, updated in the same commit as the behaviour.
• One topic per pull request, a change note per PR, dated handoff documents so a fresh session can continue, and numbered owner decisions.

• A pre-deploy review in nine slices, each read against the invariants: about 209 findings. Four reviewers found the same top bug independently.
• A follow-up by a read-only workflow of 34 agents: sweepers, verifiers, a skeptic, re-checkers and a planner, producing 15 phases.
• The owner alone writes to production, approves paid calls, deploys and flips switches.