FuncPipe Capstone Tour¶
Guide Maps¶
graph LR
family["Python Programming"]
program["Python Functional Programming"]
guide["Capstone docs"]
section["TOUR"]
page["FuncPipe Capstone Tour"]
proof["Proof route"]
family --> program --> guide --> section --> page
page -.checks against.-> proof
flowchart LR
orient["Read the guide boundary"] --> inspect["Inspect the named files, targets, or artifacts"]
inspect --> run["Run the confirm, demo, selftest, or proof command"]
run --> compare["Compare output with the stated contract"]
compare --> review["Return to the course claim with evidence"]
This tour is the learner-facing entrypoint for the FuncPipe capstone. It builds a proof bundle that captures the code and evidence surfaces the course keeps referring to: package layout, test proof, and the main areas where purity, effects, and async coordination live.
Use WALKTHROUGH_GUIDE.md when you want a stable first-pass route
through the bundle instead of deciding the reading order yourself.
The tour is not just a convenience export. It is the shortest path from course prose to
inspectable evidence when you want a human-readable review route.
Use make inspect first when you need a smaller inventory bundle, and use
make verify-report when you need to preserve the executed test result alongside the tour.
What the tour produces¶
pytest.txt: the current test run for the capstoneARCHITECTURE.md: the package map for the capstonepackage-tree.txt: the package layout undersrc/funcpipe_ragtest-tree.txt: the test layout undertestsfocus-areas.txt: the packages most relevant to course milestonesREADME.md: the repository guide for the capstonepyproject.toml: the executable project contractmanifest.json: the stable inventory of the generated bundle
How to run it¶
From the capstone directory:
From the repository root:
Neighbor routes:
make inspectfor the fastest inspection bundlemake verify-reportfor the saved verification bundlemake confirmfor the strictest combined route
What to inspect first¶
ARCHITECTURE.mdpytest.txtfocus-areas.txtpackage-tree.txttest-tree.txtREADME.md
That order mirrors the course: map first, proof second, then architectural hotspots, and finally the wider codebase shape.
Questions to carry through the tour¶
- Which packages stay descriptive instead of effectful?
- Which focus areas correspond to the module you just studied?
- Which test surfaces prove the current abstraction instead of only exercising it?