A course that teaches AI engineering from zero, plus a tutor that watches how the user learns and gets better at helping them. This page shows every part: what is finished and proven, what is being built, what is planned, and what cannot move until the owner acts. Status as of 14 Oct 2026, 23:30 IST, taken from the git history and test runs — not from memory.
Each block from the diagram above, with its internal flow drawn the same way. “In” = what feeds it, “Out” = what it feeds.
The person studying. Everything on the page starts with their action.
What it does. Reads a lesson, watches the animation, types and runs Python, answers the quiz, asks the tutor. Each of these is recorded as an event.
In: — Out: Browser · Android app · iOS app
The study site opened in any modern browser. No install.
What it does. Loads the page, the lesson engine (engine.js) and the catalog; restores progress from this browser; draws the shared header and the lesson; keeps syncing in the background.
In: User Out: 160 lessons · Dashboard · Every action → event
The same site inside a native frame, so it works offline and matches the web 1:1.
What it does. A tiny local server serves the bundled site to a WebView. A native bridge adds what a browser cannot: offline Python files, the on-device brain, a native progress store, Google Drive sync and reminders.
In: User Out: Python in the page · Google Drive · On-device brain
Same shell as Android, using the system web view on iPhone/iPad.
What it does. Identical flow: bundled site, local server, WKWebView, native bridge. Verified on the simulator; a real device needs an Apple Developer account.
In: User Out: Dashboard · Google Drive · On-device brain
The course content: one HTML page plus one JSON data file per lesson.
What it does. Each page has Why this matters → Big idea → Watch it happen → Try it → Common mistakes → Words you learned → Quiz. Reading is always allowed; progress needs the previous lesson passed.
In: Browser Out: Animations · Python in the page · Quizzes & gates · Every action → event
308 step-by-step players that show how a decision is made, not just the result.
What it does. Each step is data (what changed, why). The engine morphs the picture from one step to the next (keyed morph), writes the narration, and lets you play at 0.25–3× or step by hand. On phones it zooms ≤2× and follows the action.
In: 160 lessons Out: Every action → event
Real Python running in the browser, so there is nothing to install.
What it does. Code boxes send code to a Web Worker running Pyodide (Python compiled for browsers). Output and errors come back into the page. In the app the Pyodide files are bundled, so it works offline.
In: 160 lessons · Android app Out: Every action → event · Code checker (optional)
The end-of-lesson check that unlocks the next lesson.
What it does. Questions come from the lesson's JSON. 80 % passes. A pass marks the lesson done locally and as an event; the next lesson's gate opens. You can still read ahead.
In: 160 lessons Out: Every action → event · Progress & events
The home page: where you are and what to do today.
What it does. Builds a summary from catalog + progress (ring, stats), shows today's plan (from the server when signed in, otherwise from local progress), the 'your next step' idea map, sign-in / create account, and the Google Drive card in the app.
In: Browser · iOS app · Plan & review Out: 160 lessons · Accounts · Every action → event
A chat drawer on every lesson that knows the lesson you are on.
What it does. The lesson text is cached as a prompt prefix, so the first word arrives in 0.4–0.85 s. Replies are streamed. Hint rules stop it from handing over the full answer; the server version uses the same rules.
In: 160 lessons Out: Local brain · On-device brain · Every action → event
The diary: one small record per thing you do.
What it does. Each event has a type (answer, run, help…), fields and a time. Events are queued locally first, then flushed to the server in batches with retry; in the app they also go to the native store and Drive.
In: Lessons · Animations · Python · Quizzes · Dashboard · Tutor panel Out: Accounts · Progress & events · Mastery · Code checker · Plan & review · Learning loop
Who you are on the tutor server.
What it does. Register with email + password (hashed), sign in to get a token, sign out, reset a password with an admin script. Optional Google sign-in in the app.
In: Dashboard · Events Out: Progress & events
The teacher's logbook on the server.
What it does. Receives event batches, stores them, computes progress per lesson, and merges 'best of' with the copy the browser sends — so nothing is lost whichever side is newer.
In: Events · Accounts Out: Is the server reachable? · Mastery
A running estimate, per idea, of whether you really know it.
What it does. Every answer updates a Bayesian Knowledge Tracing value for the concepts it touches. Low values become weak spots. Readiness = 0.60 × core + 0.25 × beyond-course + 0.15 × interview.
In: Events · Progress & events Out: Plan & review · Learning loop
Runs submitted Python on the server, safely, and explains mistakes.
What it does. Off unless ZTM_CODERUN=on. Code runs inside a macOS sandbox with time and memory limits; the result goes through a rule-based mistake explainer (a plug-in point for the user's own model later).
In: Events · Python in the page Out: Mastery · Learning loop
Builds today's plan and asks old ideas again at the right moment.
What it does. A spaced-repetition scheduler (SM-2) keeps an interval per item; due items plus weak spots become today's plan; review results stretch or shrink the intervals.
In: Events · Mastery Out: Dashboard
The part that learns how to help this particular user.
What it does. When help is offered (hint, example, re-explain…), the outcome updates a bandit, which then favours the kinds of help that work. Also serves beyond-course and interview drills and feeds chats to training.
In: Events · Mastery · Code checker Out: User's own tutor model
The fork that makes the system work with or without a server.
What it does. A quick health check plus 'is there a token?'. Yes → push the queue and pull progress. No → keep working locally; the queue is flushed later with retry/backoff.
In: Progress & events Out: This browser / phone · Postgres
The user's own copy of everything, always present.
What it does. Progress and the event queue live in browser storage (and the native store in the app). Merging is best-of, so a later sync never loses work.
In: Is the server reachable? Out: Dashboard · Lessons
The server's database.
What it does. Nine migrations: users, events, progress, reviews, mastery, code runs, learning loop, beyond/interview, model registry.
In: Is the server reachable? Out: Google Drive (optional backup)
A backup copy in the user's own Drive, from the app.
What it does. Google sign-in → a private app folder → progress is written as small event-log segments → merged by event id on every device. Built and unit-tested; needs real API keys.
In: Android app · iOS app · Postgres Out: This browser / phone
An open AI model running on the user's own computer.
What it does. llama.cpp serves a 7B instruct model. The tutor panel sends the cached lesson prefix plus the question; tokens stream back. Nothing leaves the machine.
In: Tutor panel Out: Tutor panel
The same idea inside the phone app.
What it does. The app offers to download a small model, runs it with llama.cpp through FFI in a worker isolate, and streams tokens to the panel. CPU-only on simulators.
In: Tutor panel Out: Tutor panel
The tutor learning from its own sessions with this user.
What it does. Chats are collected, filtered (anything that hands over an answer is dropped), fine-tuned with LoRA on the laptop GPU (5 GB peak), evaluated, and exported as a candidate.
In: Learning loop · Safety rails Out: Promotion gate
The exam a new candidate must pass before it replaces the current model.
What it does. Candidate and base answer the same eval set; leaks and rubric scores are compared; promote only if strictly better. Admin-only rollback. First run: 6/17 leaks vs 4/17 → rejected.
In: User's own tutor model Out: Tutor panel (via server)
The locks and limits across the whole system.
What it does. Code sandbox (17 escape tricks blocked), per-user rate limits on AI / code / help calls, a training-data guard against poisoning and answer leaks, admin-only model rollback. Open: Android release signing key.
In: — Out: Code checker · Learning loop · User's own tutor model
The diagram above shows blocks. This one opens them up: every wire starts at one step inside a block and ends at one step inside another. Hover (or tap) a wire to read why that link exists, how it is made (a click, a JavaScript call, browser storage, an HTTPS request, SQL, a native bridge, FFI, a stream) and what travels along it. Short vertical links inside a block are its internal steps, in order; every step has at least one link. Hover a step to read what it does and see all of its connections.
Like a textbook with a lab bench built into every page.
Today: 160 lessons in 8 stages; every lesson has a big idea, an animation that shows each decision, Python you run in the page, common mistakes, a glossary, a quiz. Dark by default; home and lesson pages share one header.
Left: 8 lessons whose quiz choices contain text like <class 'str'> lose that text on screen; one animation glitch in s2-17 (dark). Found tonight, not yet fixed.
The same book, in your pocket — not a copy, the very same pages.
Today: a native frame that shows the bundled site offline, with Python bundled, the phone brain, reminders, Google Drive card. Pixel difference vs the website: 0.01–0.4 %. Android release build is as smooth as the browser on the same phone (home 0 % janky frames).
Left: re-measure the latest build on a real Android phone; real iOS device test; it is not yet "never a frame over 16.7 ms" while Python warms up.
The teacher's logbook: who you are, what you did, what you know.
Today: accounts, progress, mastery estimate per idea, daily plan, spaced review, code checker, learning loop, interview drills. Build/vet/test clean; the end-to-end "learner journey" test passes all 15 features.
Left: nothing known. Daily spend caps are a design idea, not a gap.
An assistant tutor that lives on your own machine.
Today: a 7-billion-parameter open model runs on the user's own computer; the tutor panel answers in under a second. Phones can download a small model and run it on the device.
Left: nothing known.
The assistant studies how it helped you and tries to get better — but only gets the job if it passes an exam.
Today: training pipeline (LoRA = a cheap way to teach an existing model new habits) fits in 5 GB; seed chats cleaned; a filter now drops any example that hands over the answer; tests + docs done.
Left: the second train + eval run was still going when work was paused; the first candidate failed the gate honestly.
Optional: keep a copy of your progress in your own Google Drive.
Today: fully built and unit-tested (194 tests) with stand-in keys.
Left: the owner creates the real Google keys (docs/tutor/GOOGLE-SETUP.md); then one real sign-in test.
The keys to the front door.
Left: an Android release keystore (release currently signs with the debug key); an Apple Developer account for real iOS devices and iCloud; decide whether to rewrite git history to remove the company team ID; decide when the repo goes public.
Next in order: fix the 9 lessons → full 160-lesson check → push all 36 commits → real-phone re-measure → promotion decision for the trained model → iCloud sync after an Apple account.
And the real goal: the user studies it, lesson by lesson, with the tutor beside them.
| Box | Evidence |
|---|---|
| 160 lessons, 8 stages | 2bd6694, 21f21be, 5fb8c2c … Stage 7 1c46fcc; catalog validates 160 JSON ↔ 160 HTML |
| Animations show each decision; readable on phones | c9d81e3, b1c8ecd, e1c02f7; b05a7f1 (160/160 phone sweep, max zoom 1.89×, min label 12 px) |
| Python in the page | e1c02f7 (worker; first run <0.2 s), 5841127 |
| Dashboard, dark default, shared header | 26ccfd6…1dec9dc, 9435a76, 11459ae; home + lesson checked at 412/1440 px, light+dark, no errors |
| Tutor panel speed | 4d1a7a8 (first token 0.4–0.85 s measured) |
| Accounts, progress, mastery, plan, review, learning loop | 25440a7, d920081, 8509511, 37bbec8; go test ./... green; e2e journey 15/15 green ×2 (7e95400) |
| Code sandbox + rate limits | 8509511 (17 escapes blocked, 736/736 tests) |
| Local brain / on-device brain | 399b186, bc9eca1; app brain tests in b3b5eae |
| App = the website | 744e6ef, aa37013, b3b5eae, 5d43171: analyze clean, 106/106 unit tests, shell tests green on desktop, iOS simulator, Android emulator; Android release 0 % jank on home |
| Google Drive sync (code) | fce1926, 194 tests — real keys pending |
| Training guard | f349768, 52d76c3, 134b79d, 541a483 |
| Docs match reality | f91f909, a1248d9, 3924341; sweep found no TODO/stub/mock in real code |
Honesty notes. "Verified" means a test or a check ran and passed on 14 Oct — on a desktop computer, the Android emulator, the iOS simulator, or a real Android phone. Nothing has run on a real iOS device. The 36 newest commits are on the laptop only, not yet pushed to GitHub. The second training run's result is unknown.