Deep Dive Make Capstone Map¶
Guide Fit¶
flowchart TD
family["Reproducible Research"] --> program["Deep Dive Make"]
program --> pressure["A concrete learner or reviewer question"]
pressure --> guide["Deep Dive Make Capstone Map"]
guide --> next["Modules, capstone, and reference surfaces"]
flowchart TD
question["Name the current module or question"] --> choose["Choose one capstone route"]
choose --> inspect["Inspect the matching guide, file, or command"]
inspect --> next_move["Stop when the claim has one honest proof surface"]
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 Checklist |
| 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 Checklist |
| 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 learner 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 Checklist |
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/, Repro Catalog |
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.