Concepts — Browser & Framework Internals

1. What is it

A systems-construction track driven by browser-framework-internals.md (the specification), which lists 52 areas spanning Chromium/Blink internals, the rendering pipeline, and build-it-yourself framework runtimes. This module converts that flat list into an executable order: which areas gate which, what runs in parallel, where the local build actually matters, and what "done" means.

The unit of work is a numbered module directory (bi-NN-topic/) containing CONCEPTS.md, docs/ (execution, observation, verification, analysis), src/, and references.md — mirroring the fe-NN- convention used by the sibling track.

Root PROGRESS.md tracks this track. ../frontend-principal-journey/fe-00-roadmap/docs/progress.md tracks the other one.

2. Why it matters

Read in specification order, the 52 areas look sequential: build Chromium, then read Blink, then build frameworks. That reading produces three expensive failures.

• Blocking on the build. The specification puts "Build Chromium From Source" at §3, which reads as a prerequisite. It is not. Source navigation, spec↔implementation mapping, tracing and archaeology all work on a stock browser with zero build. Treating the build as a gate can stall the track indefinitely — as it did here, where the local toolchain turned out to be 15 months below trunk's floor. Everything through Phase 2 continued regardless.
• Copying Fiber instead of deriving it. §27 lists mini-React's stages in order, ending at scheduling and interruptible work. Attempted before browser scheduling (§16), those stages become transcription: the learner reproduces a data structure without having felt the frame budget that forced it. The specification's own §45 forbids this ("Do not begin with production source"), but its ordering invites it.
• Building the mini-browser as a monolith. §26 presents 15 milestones as one project. Built as a block after §6–§15, every "why is Blink like this?" question has already been answered by prose, and the comparison teaches nothing.

The ordering is the deliverable. Enumerating browser subsystems is easy; sequencing them so each build precedes the reading it motivates is what makes the track work.

3. How it works

SPECIFICATION (52 areas, flat)
  |
  v
TWO PARALLEL STRANDS + ONE SPINE
  |
  +-- BROWSER STRAND ------ parser -> DOM -> bindings -> CSS -> layout
  |                          -> paint -> compositor -> scheduling -> tests
  |        ^
  |        +-- SPINE: mini-browser milestones, interleaved 1:1
  |
  +-- FRAMEWORK STRAND ---- mini-redux -> mini-react I -> reactivity/signals
  |                          -> mini-react II -> compilers -> tooling
  |
  v
JOIN: cross-layer vertical traces
  v
CHROMIUM CONTRIBUTION  ->  CAPSTONE

3.1 The four structural decisions

The mini-browser is a spine, not a phase. Its 15 milestones map 1:1 onto the browser strand. Each is built immediately before the corresponding Blink reading, so the reading answers a question already felt. This is the specification's §45 loop applied at module granularity rather than track granularity.

mini-redux comes first, not last. It is the only production library in the track small enough to read end to end — the Level-1 rung of the §44 reading ladder. The capability it builds ("I have understood an entire real system") is a prerequisite for facing 30M lines of Chromium, not a reward afterwards.

Chromium C++ is just-in-time. Reading Blink structure — call graphs, ownership, layout — needs almost no C++. Reading Blink semantics needs specific idioms, learned the first time each one blocks a real read. A C++ course front-loaded before any browser reading is three weeks that teach nothing about browsers.

mini-React splits across two phases. Stages 1–7 (element model through effects) have no browser prerequisite. Stages 8–11 (batching, scheduling, interruptible work) require the real event loop, because the frame budget is the constraint that makes Fiber-shaped structures necessary rather than arbitrary.

3.2 Setup is two things, not one

Conflating these is the most common way this track stalls.

A checkout without a working compiler still delivers most of the read-only value: git grep over the full tree is faster than Code Search, and git log -S is the archaeology tool §25 depends on. Checkout and build are separable, and separating them buys months of runway.

3.3 Module sequence

4. What "done" means

Per the specification's §44, no source-reading exercise is complete until eight questions are answered in writing: why the code exists, what invariant it maintains, who calls it, what it calls, which process/thread runs it, what happens if removed, how it is tested, and what simpler design would fail.

Per §45, no abstraction is understood until it has been used, predicted, rebuilt in miniature, broken deliberately, debugged, compared against production source, and — where practical — modified in production.

A module is complete when its docs/verification.md checkpoints pass against measured or observed output, not when its prose has been read.

5. Known constraints on this machine

• Trunk does not compile here. macOS 15.0 / Xcode 16.2 vs trunk's floor of macOS 26.2 / Xcode 26.5 (requirement landed 2026-05-13). See bi-00-roadmap/docs/chromium-build-debug-trace.md §2.0 for the diagnosis and the ranked options. Phases 0–2 are unaffected.
• Disk. Checkout ~26 GB plus a ~24 GB git-cache mirror; ~90 GB free. One symbol-rich output directory fits; two do not.

6. Relationship to the sibling track

Shared, not duplicated: LEARNING-LOG.md §3 is the source-reading log for both tracks; decisions/ holds ADRs from either.

Cross-track sequencing that matters: