Curriculum Map, Dependency Graph & Phase Plan

Derived from frontend-principal-engineering.md (source of truth) and browser-framework-internals.md (depth track). This file is navigation, not specification. If it conflicts with the spec files, the spec files win.

1. The map: 46 spec areas → 8 clusters

The spec lists 46 numbered areas plus failure case studies, capstones, heuristics and AI rules. Studied in spec order they look like 46 independent subjects. They are not. They collapse into 8 clusters with very different dependency behaviour.

The three things that are not clusters

• Failure case studies (12 listed incidents) — these are assessments, not content. Each one is scheduled against the phase that gives you the tools to solve it. See §5.
• Capstones (6 levels) — one per phase boundary. They are the promotion gate.
• Heuristics (10 listed) — the spec says "for every heuristic include counterexamples and limitations." That is a running exercise, tracked in learning-log.md, not a module.

2. Dependency graph

The real edges. A → B means "A must be solid before B is honest."

graph TD
  subgraph SUB["A · Platform substrate"]
    JS["§1 JS runtime<br/>event loop · closures · GC · object shapes"]
    BR["§2 Browser architecture<br/>processes · rendering pipeline · scheduling"]
    HTML["§3 HTML platform<br/>semantics · forms · web components"]
    CSS["§4 CSS architecture<br/>cascade · layout · containment"]
    NET["§10 Networking<br/>HTTP/2·3 · caching · CDN"]
    TS["§1b TypeScript<br/>structural typing · contracts"]
  end

  subgraph FW["B · Framework mechanics"]
    REACT["§5 React deep dive<br/>fiber · render/commit · hooks"]
    ALT["§6 Vue/Svelte/Solid/WC"]
    ALGO["§40 UI algorithms<br/>diff · LRU · virtualization"]
  end

  subgraph ARCH["C · Architecture & data"]
    APP["§7 App architecture"]
    STATE["§8 State management"]
    API["§9 API integration"]
    EDGE["§19 Unhappy path"]
    SSR["§31 SSR/SSG/ISR/islands"]
  end

  subgraph QA["D · Quality attributes"]
    PERF["§11 Performance"]
    A11Y["§12 Accessibility"]
    SEC["§13 Security"]
    I18N["§36 i18n"]
    MOB["§37 Mobile web"]
    WORK["§38 Workers"]
    WASM["§39 WASM"]
    BIGUI["§41 Large-scale UI"]
  end

  subgraph TEST["E · Quality engineering"]
    TSTRAT["§14 Test strategy"]
    UIT["§15 UI testing"]
    E2E["§16 E2E"]
    INT["§17 Integration"]
    VIS["§18 Visual regression"]
    QEP["§25 Org quality policy"]
  end

  subgraph PLAT["G · Platform & delivery"]
    DS["§26 Design systems"]
    FPE["§27 Platform engineering"]
    BUILD["§28 Build tooling"]
    MONO["§29 Monorepos"]
    MFE["§30 Microfrontends"]
    OBS["§32 Observability"]
    REL["§33 Reliability"]
    CICD["§34 CI/CD"]
    RELE["§35 Release engineering"]
  end

  subgraph PRIN["H · Principal judgment"]
    ADR["§42 ADRs"]
    DEC["§43 Decision making"]
    DEBT["§44 Technical debt"]
    MIG["§45 Migrations"]
    PSK["§46 Principal skills"]
  end

  JS --> BR
  JS --> REACT
  JS --> ALGO
  JS --> WORK
  BR --> REACT
  BR --> PERF
  BR --> A11Y
  HTML --> A11Y
  HTML --> CSS
  HTML --> REACT
  CSS --> PERF
  CSS --> DS
  NET --> API
  NET --> PERF
  NET --> SSR
  NET --> SEC
  TS --> API
  TS --> APP

  REACT --> APP
  REACT --> STATE
  REACT --> SSR
  ALGO --> BIGUI
  ALT --> APP

  APP --> STATE
  STATE --> API
  API --> EDGE
  STATE --> EDGE
  SSR --> PERF
  REACT --> SSR

  PERF --> OBS
  PERF --> BIGUI
  WORK --> BIGUI
  WORK --> WASM
  A11Y --> DS
  MOB --> PERF

  EDGE --> TSTRAT
  APP --> TSTRAT
  TSTRAT --> UIT
  TSTRAT --> E2E
  TSTRAT --> INT
  TSTRAT --> VIS
  UIT --> QEP
  E2E --> QEP
  INT --> QEP
  VIS --> QEP

  CSS --> BUILD
  BUILD --> MONO
  MONO --> MFE
  DS --> MFE
  DS --> FPE
  MONO --> FPE
  QEP --> CICD
  CICD --> RELE
  OBS --> REL
  RELE --> REL
  FPE --> MFE

  MFE --> ADR
  REL --> ADR
  FPE --> ADR
  ADR --> DEC
  DEC --> MIG
  DEBT --> MIG
  MIG --> PSK
  DEC --> PSK

The five load-bearing chains

Everything else is decoration around these. If you only get five things right:

1. Scheduling chain — event loop → task/microtask semantics → long tasks → INP → concurrent rendering → Suspense/transitions → streaming SSR → hydration cost. Rendering the heuristic "performance problems are often scheduling problems" legible.

2. Async-correctness chain — promises/cancellation → request lifecycle → server-state cache → race conditions → optimistic update + rollback → offline/conflict. This is where "stale response overwrites newer data" lives.

3. Cache-coherence chain — HTTP cache semantics → ETag/Cache-Control → CDN → SSR/ISR revalidation → query-cache invalidation → stale-while-revalidate UX. One concept, four layers, four different invalidation vocabularies.

4. Semantics chain — DOM → semantic HTML → accessibility tree → accessible name computation → focus management → a11y as a design-system contract → a11y CI gate. "Accessibility is architecture, not polish" is only true if you can walk this chain.

5. Org-topology chain — package boundaries → build graph → monorepo → independent deployability → microfrontends → governance → standardisation vs autonomy. "Frontend architecture frequently reflects organizational architecture."

Cross-track hooks into browser-framework-internals.md

Only cross when the frontend topic genuinely stalls without it:

3. Phases

Seven phases plus a continuous spine. Each phase ends in a capstone-shaped deliverable and a promotion gate. Depth target rises per phase; tutorial density falls per phase, per the spec's closing instruction.

Spine (continuous, from Phase 1 onward)

F · AI-assisted engineering (§20–24) + §46 writing practice Not a phase. Every module carries an AI-assisted exercise. The rule from the spec holds throughout: AI increases leverage, never replaces understanding. You may not use an agent to produce an artifact whose failure modes you cannot enumerate yourself.

Phase 1 — Platform Substrate

Spec areas: 1, 2, 3, 4, 10 · Level: Foundation → Senior Thesis: Before any abstraction, know what the abstraction is hiding.

Capstone 1 (Foundation): production-quality accessible responsive application, built with deliberately minimal framework surface. Budget-constrained.

Phase 2 — Framework Mechanics

Spec areas: 5, 6, 40 · Level: Senior Thesis: A framework is a scheduling and diffing policy with ergonomics attached. Prereq: fe-01, fe-02, fe-04, fe-05.

Deliverable: a written architectural comparison of three reactivity models with a measured micro-benchmark and an explicit statement of what the benchmark does not prove.

Phase 3 — Architecture & Data

Spec areas: 7, 8, 9, 19, 31 · Level: Senior → Staff Thesis: A frontend is a distributed system with a rendering engine attached. Prereq: Phase 2 + fe-07.

Capstone 2 (Intermediate): complex application with API integration, state management, full testing — built against an intentionally unreliable API.

Phase 4 — Quality Attributes

Spec areas: 11, 12, 13, 36, 37, 38, 39, 41 · Level: Staff Thesis: These are not features. They are properties of the architecture, and they are measurable. Prereq: Phase 3. fe-22 is the anchor; the rest parallelise heavily.

Capstone 3 (Senior): high-performance application with SSR, caching, observability, defended with numbers against a stated budget.

Phase 5 — Quality Engineering

Spec areas: 14, 15, 16, 17, 18, 25 · Level: Staff Thesis: Quality is an architecture problem. Thousands of tests can still produce low confidence. Prereq: Phase 3 (need a system worth testing) + fe-20 (need to know what to test for).

Deliverable: an organization-wide testing policy document with explicit confidence claims and explicit un-covered risk.

Phase 6 — Platform & Delivery

Spec areas: 26, 27, 28, 29, 30, 32, 33, 34, 35 · Level: Staff → Principal Thesis: You stop building applications and start building the conditions under which others build them. Prereq: Phases 4 and 5.

Capstone 4 (Staff): shared design system + frontend platform used by multiple applications.

Phase 7 — Principal Judgment

Spec areas: 42, 43, 44, 45, 46 + failure case studies + heuristics · Level: Principal → Distinguished Thesis: The work is now decisions, influence, and time horizons — and being right about reversibility. Prereq: Phase 6.

Capstone 5 (Principal): frontend architecture for dozens of teams — RFC, diagrams, budgets, testing strategy, observability, security model, a11y policy, migration strategy, CI/CD, DX, operational model.

Capstone 6 (Distinguished/SME): multi-year frontend platform strategy — standardisation, technology radar, migration roadmap, platform APIs, governance, org topology, adoption, build-vs-buy, measurable outcomes.

4. Parallelisation

Safe to study concurrently

Hard prerequisites — do not parallelise

Explicitly deferred (common temptation to start early)

• Microfrontends (§30) — the most requested, least ready topic. Deferred to Phase 6 on purpose.
• Design systems (§26) — feels like a Phase 1 topic. It isn't; it needs a11y, CSS architecture, versioning and governance to be real.
• State machines / DDD / clean architecture (§7) — Phase 3, and taught with its overengineering critique attached.

5. Failure case-study schedule

The 12 incidents from the spec, assigned to the earliest phase that gives you the tools to solve them honestly. Each runs under the spec's 7-question protocol.

Phase 7 re-runs all twelve, cold, in fe-51.

6. Promotion gates

You do not advance a phase by finishing modules. You advance by clearing the gate.