Execution — Chromium Navigation Drills

Module bi-01. Phase 0. No local build required. Tools: Code Search + stock Chrome.

The deliverable is the query log, not the answers. Every drill is scored on the search you ran, how many attempts it took to converge, and what you learned when it didn't. Record everything in docs/observation.md, including failed queries — the failures are the data.

Time-box each drill to 10 minutes. Blowing the box is a result, not a failure: write down where your model was wrong and move on. Total ~90 minutes.

Scoring

For each drill record:

A drill where you predicted the wrong subsystem and found out in 90 seconds is a better outcome than one you got right by luck. The point is calibrating the prediction.

Drill 1 — Spec-phrase search (Technique 1)

Find Blink's implementation of the CSS cascade's "specificity" comparison.

Then: find where the spec's phrase for the algorithm that orders declarations of equal specificity is quoted in a comment. Which file? What does the comment say the tie-break is?

Check your model: did you predict core/css/? If you predicted core/style/, note why — the split between those two is a recurring confusion and bi-07 depends on it.

Drill 2 — Symbol + cross-reference (Technique 2)

Find Document::UpdateStyleAndLayout (or whatever the current name is — finding out that a name has changed is part of the drill).

Answer from the xref panel only, without reading bodies:

• How many callers does it have, roughly?
• Name three callers from different subsystems.
• What does the caller count tell you about changing its signature?

Drill 3 — Naming grammar (Technique 3)

Without using the word "compositor" in your query, find the class in //cc that owns the compositor's main-thread state, and its impl-thread counterpart. Use the naming grammar.

Then: find one *Client and one *Delegate in Blink and state, for each, which direction the dependency was inverted and why that was necessary.

Drill 4 — Generated code (Technique 4)

document.querySelector — find:

1. the .idl declaration
2. the Blink C++ method the binding calls
3. the name-mangling rule that connects them

Then pick a CSS property added in the last three years and, from css_properties.json5 alone, state whether it is inherited, whether it is animatable, and whether it uses custom parsing.

Finally: search for RuntimeEnabledFeatures:: and find one feature that is declared but not enabled by default. Where is "enabled by default" recorded?

Drill 5 — History (Technique 5)

Take the <input type=hidden> special case you found in the parsing lab. Find the CL or spec change that justifies it. Quote the reasoning.

Then find any line in the parser directory that has survived unchanged for more than ten years, and one that changed in the last six months. What does the contrast tell you about where the risk is in this subsystem?

Drill 6 — Tests (Technique 6)

For HTMLConstructionSite:

• find its unit test
• find one Blink web test covering foster parenting
• find the WPT covering the same behaviour
• find where Chromium records that a WPT is expected to fail, and find one currently- failing WPT in the HTML parsing area

That last item is a candidate for §24 rung 3. Write down the test name; you may come back to it in Phase 6.

Drill 7 — Invariants (Technique 7)

Find three DCHECKs in core/dom/ and, for each, write the invariant in one English sentence. Then find one CHECK (not DCHECK) in the renderer and explain why the author classified that failure as unrecoverable rather than merely a bug.

Drill 8 — Layering (Technique 8)

Read third_party/blink/renderer/DEPS and one core/*/DEPS.

• Name one include rule you would not have predicted.
• Find an include_rules exception with a comment justifying it. What compromise is documented there?
• From OWNERS files alone, identify a boundary between two teams inside Blink.

Cross-check drill — the ladder (bi-01 §"tool ladder")

Determine whether smooth scrollIntoView is main-thread or compositor-driven.

Do it twice: once by source reading only, once by tracing only (DevTools Performance or chrome://tracing). Record time-to-answer and your confidence for each. Then answer:

Why is tracing rung 3 and source reading rung 1, if tracing gave the faster answer here?

Getting this reconciliation right is the whole point of the ladder.

Done when

• All 8 drills logged with queries, including failures
• Prediction accuracy tallied (how many subsystems did you predict correctly?)
• Cross-check drill answered, including the reconciliation question
• One candidate failing-WPT recorded for Phase 6
• The three techniques that worked best for you noted in PROGRESS.md
• Source readings logged in LEARNING-LOG.md §3