What is missing on purpose, and what is next — How this is built

Where the plan lives

The plan is docs/ROADMAP.md, with a visual copy in docs/roadmap.html. It was last measured on 15 September, and the code has moved since. This chapter checks its engineering list against the repository as it is today.

It then adds what writing these chapters turned up, and ends with what is left out on purpose. The effort figures are the roadmap's own, for one person who knows the codebase. They are not measurements.

The roadmap's list, checked

#	Item	Roadmap's effort	State today
1	Take the WebAssembly out of every deploy	0.5–1 day	Shipped Pyodide and sql.js load from jsDelivr at pinned versions, and `public/wasm/` went from 18 MB to 1.4 MB. The same pattern now serves Ruby, PHP, Lua and Clang.
2	A schema for chapter bodies	0.5 day	Not started Chapters are still HTML strings in TypeScript, guarded by the integrity tests. No schema library is installed.
3	Server-render the Git guide	0.5–1 day	Shipped `app/git/page.tsx` renders the whole body on the server. Only the contents list and copy buttons are client code.
4	A real error tracker	0.5–1 day	Wired Sentry is in, loaded only by dynamic import, and inactive until `NEXT_PUBLIC_SENTRY_DSN` is set.
5	New exercise formats	2–3 days	Partly The mock interview's design round has a whiteboard that stays with the answer. Machine coding and read-and-fix exercises do not exist yet.
6	Offline reading	2–3 days	Not started `app/manifest.ts` exists; no service worker does.
7	Accounts and progress sync	5–8 days	Not started Everything a reader earns is still in one browser.

Meanwhile, a lot shipped that the list never named:

the whiteboard
the mock interview and its readiness dashboard
a step-through debugger
running C, C++, Ruby, PHP and Lua in the browser
a playground with files, tabs, share links and run history
a redesigned problems page

That is not a complaint about the plan. The list was for engineering that removes risk, and most of what shipped is product.

The middle column is new. Each item in it came from measuring for these chapters, and none appears in the roadmap file yet.

What this rewrite added to the list

Patch Next. The installed 16.3.0 falls inside the range of a critical advisory, and 16.3.6 exists. The last attempt failed on a single slow Lighthouse sample, not a real regression. With three runs, it deserves another go before anything else here.
Budget the heavy pages. Add /practice and one problem page to the Lighthouse URL list. They ship 422 KB of gzipped script, and no budget watches them.
Move SQL into a worker. It is the one runtime without isolation or a timeout.
Reconcile the cleanup defaults, and have lib/wasmAssets.ts read versions from one place, so a Pyodide bump stops needing a hand edit.

None of these adds anything a reader would see. Each removes a way for the site to break quietly.

Why accounts are still last

Not because they are hard. Because they are the only item that adds ongoing work rather than removing it: a database to keep alive, sign-in email that actually has to arrive, and an account-deletion path that has to work. Every other item is finished when it ships.

The code is ready for it. Every progress-aware component reads through one storage module, which exposes subscribe(). A synced version could sit behind that module without touching a component. The roadmap's plan keeps reading open to signed-out readers and moves existing local progress up once at first sign-in, rather than starting accounts from zero.

Offline, and the part that is fiddly

The content is static and already cached hard, so most of the work is a cache strategy. The awkward detail is that the App Router fetches RSC payloads as well as HTML. The rules have to cover both, or a full page load works offline while clicking a link does not. The playground's runtimes come from jsDelivr, and a service worker should not precache them by default. Either the playground stays online-only, or downloading it for offline use becomes an explicit button.

The larger plan is content

The roadmap is clear that the pressure is on the writing, not the system. Seven of 32 topics are written, counting Git's standalone guide. The engineering above runs alongside the writing rather than ahead of it. Section 0.2 of the roadmap orders the rest by what the job market asks for:

P0: TypeScript, Next.js, Node.js, and a new topic on AI engineering for JavaScript developers.
P1: SQL and databases, Testing, Docker with CI/CD, and frontend and GenAI tracks for System Design.
P3: Kubernetes and GraphQL, both shrinking: GraphQL folds into an API-design unit inside Node.

A chapter template, written down once, is meant to come before the first of those.

Missing on purpose

Some absences are not on any list, because adding them would make the site a different kind of system:

A database, until accounts. The repository is the content store, and it has no downtime.
A CMS. Publishing through a deploy is slower, but it means every chapter passes the type checker, the integrity tests and the claims test before a reader sees it.
Server-side code execution. Running readers' code on a server would turn the playground into the biggest security problem on the site.
Product analytics. Page views cannot say which chapter people leave from or which searches return nothing. The roadmap names the five events it would send, search_no_results most valuable among them. None is sent yet.
Payments. The interview book is the obvious thing to charge for, but a gate needs accounts first.

What is not on the list

A rewrite. Nothing in this architecture is the wrong shape for what the site is. The debt is specific and small: a stale framework patch, a few oversized files, one runtime on the main thread, and documents that drift. Each has a line in the tables above.