bi-15 — Analysis
The capability being built
Given any operation a web developer can perform, trace it downward until you run out of mechanism — and know where you ran out.
The second clause carries the weight. A trace that stops at "and then Blink handles it" is not a failure; a trace that stops there without noticing is. The gap is the next study target.
Required invariants of a completed trace
- Every layer is resolved with evidence, or explicitly recorded unresolved.
- Process and thread are named at every resolved step.
- Deferred vs immediate is stated at every step — most of the pipeline is deferred, and saying so is most of the insight.
- A variant is constructed that changes which layers are involved. This is what proves mechanism rather than memorised path.
- Evidence type is recorded per layer: source, trace, or debugger.
Why the evidence type matters
Source tells you what can happen; a trace tells you what did. A trace resolved entirely by reading is weaker than one where a trace event confirmed the code ran — and noticing that difference is itself part of the exercise. In a codebase with feature flags and generated code, "the source says so" is a hypothesis.
The table this is all teaching
The deliverable is not eight documents. It is the ability to say, for any change, which pipeline stages are skipped and why. Anyone can learn that layout is expensive; knowing precisely which changes avoid it — and being able to derive that rather than recall it — is the Principal-level skill, because the list changes and the mechanism does not.
Cross-check every row against css_properties.json5's invalidate: data. Where your trace
disagrees with the declaration, one of the two is telling you something interesting.
Working without a debugger
The local build is blocked on the reference machine, which removes rung 5 and not rungs 1–3.
All eight traces are largely doable with Perfetto on stock Chrome, git grep/git log -S on the
checkout, and the declarative files. Record which instrument produced each conclusion.