Deep Dive Make Capstone Map¶
Page Maps¶
graph LR
family["Reproducible Research"]
program["Deep Dive Make"]
section["Capstone"]
page["Deep Dive Make Capstone Map"]
capstone["Capstone evidence"]
family --> program --> section --> page
page -.applies in.-> capstone
flowchart LR
orient["Orient on the page map"] --> read["Read the main claim and examples"]
read --> inspect["Inspect the related code, proof, or capstone surface"]
inspect --> verify["Run or review the verification path"]
verify --> apply["Apply the idea back to the module and capstone"]
Read the first diagram as a timing map: the capstone is a corroboration surface, not the first lesson. Read the second diagram as the route rule: choose one capstone route by module or question, inspect the matching surface, then stop when one honest proof route is visible.
Enter the capstone at the right time¶
Enter only when the module idea is already legible in the local exercise.
Return to the module first if:
- you cannot yet explain the concept on a smaller graph
- you do not know which command should prove the behavior
- the repository feels larger than the concept you are studying
Choose the route by question¶
| If the question is... | Start here | Escalate only if needed |
|---|---|---|
| what this repository promises | Capstone Guide | Capstone Walkthrough |
| which repository surface matches the current module | the table below | Command Guide |
| which command should prove the current claim | Command Guide | Capstone Proof Guide |
| which files own the behavior | Capstone File Guide | Capstone Review Worksheet |
| whether the whole repository holds together as a specimen | Capstone Review Worksheet | Capstone Extension Guide |
Choose the route by module arc¶
| Module arc | What should already be clear locally | First capstone route |
|---|---|---|
| Modules 01-02 | truthful edges, atomic publication, and one parallel race you can explain | Capstone Walkthrough |
| Modules 03-05 | selftests, public targets, portability boundaries, and one negative proof | Command Guide then Capstone Proof Guide |
| Modules 06-08 | generator boundaries, layered mk/ design, and release surfaces |
Capstone File Guide |
| Modules 09-10 | incident judgment, stewardship review, and migration boundaries | Capstone Review Worksheet |
Module-to-capstone map¶
| Module | Main question | Capstone surface | First command |
|---|---|---|---|
| 01 Foundations | what makes a graph truthful instead of lucky | Makefile, src/, include/ |
make walkthrough |
| 02 Scaling | what breaks under -j when the graph lies |
repro/, mk/objects.mk, tests/run.sh |
make selftest |
| 03 Production Practice | how a build proves convergence and equivalence | tests/run.sh, Capstone Proof Guide |
make verify-report |
| 04 Semantics Under Pressure | how precedence and rule choice stay legible | Makefile, mk/rules_eval.mk |
make inspect |
| 05 Hardening | where portability and hidden-input boundaries live | mk/contract.mk, mk/stamps.mk |
make contract-audit |
| 06 Generated Files | how generation enters the graph honestly | scripts/, mk/stamps.mk |
make proof |
| 07 Build Architecture | how layered includes become a public build surface | mk/*.mk, Capstone File Guide |
make inspect |
| 08 Release Engineering | how release artifacts stay reviewable | scripts/mkdist.py, build/attest.txt |
make proof |
| 09 Incident Response | how failures become inspectable instead of superstitious | repro/, Capstone Proof Guide |
make incident-audit |
| 10 Governance | whether another maintainer could extend or migrate the build safely | mk/, tests/, repro/ |
make confirm |
Good stopping point¶
Stop when you can name one capstone surface, one command, and one reason they are enough for the current module or question. If you still feel pulled toward the whole repository, step back to the smaller route.