FuncPipe Walkthrough Guide¶
Guide Maps¶
graph LR
family["Python Programming"]
program["Python Functional Programming"]
guide["Capstone docs"]
section["Docs"]
page["FuncPipe Walkthrough Guide"]
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"]
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.