bi-01 — Broader Ideas
Where this generalises
The techniques here are not Chromium-specific. They are how you enter any codebase too large to read.
| Technique | Generalisation |
|---|---|
| Spec-phrase search | any implementation of a written standard: TCP stacks, PDF renderers, compilers, SQL engines |
| Path ⇒ layer ⇒ process | any layered system with enforced dependency direction |
| Generated-code detection | Protobuf, GraphQL codegen, ORM models, OpenAPI clients — the same "grep finds nothing" failure |
git log -S | the fastest way to date any behaviour in any repository |
| Tests as enumerated fears | universal |
The habit worth exporting to your team
Record the query, not the path. A team wiki full of file paths is stale within two release cycles and actively misleads. A wiki that says "to find how X is enforced, search for the spec phrase Y, then follow xrefs from symbol Z" stays true across refactors.
This is a concrete thing to change in your organisation's onboarding docs on Monday.
Next steps in this track
bi-02gives you the process/thread map that makes "which layer?" answerable rather than guessed.bi-12adds tracing as rung 3 — the instrument that tells you where to look when you have no hypothesis at all.bi-14is where navigation becomes falsifiable: you cannot land a CL in code you cannot find.
An exercise beyond the module
Take a codebase you own. Write the six-step cold-read procedure for it: what is the README, where is the layering declared, what is generated, where are the tests, what are the naming conventions. If you cannot write it, new hires are reverse-engineering it individually — which is a cost you are paying without measuring.