FuncPipe Walkthrough Guide¶
Guide Maps¶
graph LR
family["Python Programming"]
program["Python Functional Programming"]
guide["Capstone docs"]
section["WALKTHROUGH_GUIDE"]
page["FuncPipe Walkthrough Guide"]
proof["Proof route"]
family --> program --> guide --> section --> page
page -.checks against.-> proof
flowchart LR
route["Run the walkthrough route"] --> bundle["Inspect the tour bundle"]
bundle --> guides["Return to package and test guides"]
guides --> code["Read the owning code and tests"]
code --> review["Decide whether the claim is justified"]
Use this guide when you want the shortest first pass through the capstone without turning the experience into random file browsing.
Recommended first route¶
- Run
make inspectif you need the fastest inventory before running the heavier proof routes. - Run
make tour. - Read
TOUR.mdfor the bundle purpose and reading order. - Read
pytest.txtfor the proof surface that currently passes. - Read
focus-areas.txtfor the package groups that matter most to the course. - Read
package-tree.txtandtest-tree.txtto place those focus areas inside the full repository. - Run
make verify-reportwhen you need the executed test record preserved as a review bundle. - Move into
PACKAGE_GUIDE.mdandTEST_GUIDE.mdwhen one part of the repository now matters more than the rest.
What this walkthrough should teach¶
- the capstone is reviewable as a human artifact, not just runnable code
- tests are the first proof surface, not an afterthought
- package groups and test groups line up with the course's module arc
- the tour bundle is a way to decide where to read next, not a substitute for code review
When to leave the walkthrough¶
- Leave for
PACKAGE_GUIDE.mdwhen the main question is package ownership. - Leave for
TEST_GUIDE.mdwhen the main question is proof depth. - Leave for
ARCHITECTURE.mdwhen the main question is purity and effect boundaries. - Leave for
PROOF_GUIDE.mdwhen the main question is which command or artifact proves the claim.