Updated: 2026-09-29 · Status: ACTIVE CONSTRUCTION PLAN
The current teaching collection has one twenty-one-chapter map and four reader-facing assets: Teaching Book, Exercise Book, Solutions Book and Educator Guide. This plan records the work after reorganizing those assets. Sixteen manuscript drafts and their reference checkpoints have been retained. Chapter 4, the first missing foundation, is now a drafted chapter with a learner-owned store, checkpoint, experiment and two practical units. Chapter 8 is drafted too, with a learner-owned work queue on that store, checkpoint, experiment and two practical units. Chapters 6 and 14 are drafted too: embeddings and vector search, and a bounded MCP client built from the standard library, each with a checkpoint, an experiment and two practical units. Chapter 21 adds context engineering, measured and built the same way.
The quality benchmark is a self-contained professional technical textbook. “Manning level” describes teaching and editorial quality, not a publisher destination. No publisher submission belongs in this plan.
The five chapter additions
| Chapter | Why it needs dedicated space | Reader-owned output | Consumed next |
|---|---|---|---|
| 4: Durable state | Persistence and transaction foundations currently arrive through a supplied wrapper | Minimal store, explicit transactions, migrations, immutable event append | Memory in 5 and work in 8 |
| 6: Embeddings and vector search | Chapter 5 measures lexical retrieval missing paraphrases; dense vectors answer that failure, with costs of their own | Embedding use, cosine search, an index and its recall, retrieval metrics | Skills in 7 and every later memory lookup |
| 8: Durable work | Intake, completion and delivery have different failure states, crowded into messaging | Durable admission, basic claim, atomic terminal state/report creation | Telegram in 9 and scheduling in 10 |
| 14: MCP | Protocol connection and OS containment are different concepts and environments | Bounded stdio initialization, discovery and allowed invocation | Isolation in 15 |
| 21: Context engineering | No chapter owned the context window, though every chapter added to it | Layers stable first, a token budget, spilled tool results, two-step compaction and pinned records | The capstone coding agent |
Scroll horizontally to view columns.
Each addition follows the same build, fail and repair sequence, with exact ninety-minute Unit A and B plans and independently authored acceptance cases. Chapter 14 now teaches the MCP protocol, and Chapter 15 keeps only what isolation needs: connecting the store's own MCP server with the product's client.
One chapter map across four assets
Stable lesson identity is separate from display number. This map preserves the meaning of previously distributed material while giving new readers one sequence.
| Current chapter | Topic | Previous sixteen-chapter number |
|---|---|---|
| 1 | First model call | 1 |
| 2 | Typed shop tools and Pydantic | 2 |
| 3 | Owned model/tool loop | 3 |
| 4 | Durable SQLite state | New |
| 5 | Memory | 4 |
| 6 | Embeddings and vector search | New |
| 7 | Tested skills | 5 |
| 8 | Durable work and reports | New |
| 9 | Telegram | 6 |
| 10 | Schedules and stock events | 7 |
| 11 | Spending permissions | 8 |
| 12 | Ambiguous supplier outcomes | 9 |
| 13 | Worker recovery | 10 |
| 14 | MCP protocol | New standalone lesson |
| 15 | Isolation | 11 |
| 16 | Evaluation | 12 |
| 17 | Controlled improvement | 13 |
| 18 | Bounded delegation | 14 |
| 19 | Deployment and maintenance | 15 |
| 20 | Integrated day | 16 |
Scroll horizontally to view columns.
Older numbered releases retain their original meaning in historical records. Active manuscript links, checkpoint paths, companion numbers and classroom labels use the current map. Do not relabel an old binary archive and imply its contents were rebuilt.
Telegram and operating integrations
Telegram is implemented in the reference runtime and taught in Chapter 9. The actual path is authenticated intake → durable work/cursor transaction → claim → context and loop → terminal work/report transaction → delivery disposition. The outbox is created by the reference schema's terminal-state triggers. A source trace establishes this wiring; fixture tests and live observations establish different behavior.
| Integration | Current teaching/reference evidence | Remaining construction or acceptance |
|---|---|---|
| Telegram | Offline authenticated admission, duplicate/cursor behavior, work routing, report delivery and UNKNOWN handling | Connect the new learner inbox/outbox; complete a dedicated bot/handset exchange with sanitized identity/receipt evidence; handle structured retry delays in a bounded adapter |
| Schedules | Durable due slots and stock episodes enter the same work path; idle operation does not require a model | Consume Chapter 8's learner queue and demonstrate restart/coalescing; keep UTC interval scope explicit |
| Local skills | TOML versions, candidate evaluation, explicit activation and context selection | Introduce TOML/hashing before use and connect the cumulative learner store; skill text cannot grant tool authority |
| Permissions | Exact proposal, expiration/revocation and shared spend reservations | Break dense transactional methods into taught increments; independently test simultaneous reservation and stale consent |
| Supplier and receiving | Controlled independent ledger, lost-response reconciliation and receiving | Preserve UNKNOWN; reconcile physical stock, pending stock and actual expenditure separately |
| Worker recovery | Killed/stale-worker reference experiments and ownership generations | Extend the basic learner claim with tested takeover/fencing; never imply a local fence recalls a remotely accepted request |
| MCP | Chapter 14's learner client (ids, frame limit, shared deadline, allowlist, process-group cleanup) against a scripted server; optional pinned ZeoCore interoperability | Run the product's worker on the learner client; add Streamable HTTP only with its own authorization chapter; keep ZeoCore optional and separate |
| Container isolation | Configured Linux/container reference observations | Separate protocol permissions from filesystem/network/process enforcement; repeat measured boundaries on the final supported setup |
| Evaluation and improvement | Independent outcomes, strong baseline, explanation blind spot, versioned activation and rollback | Preserve failures and fresh-case discipline; measure learner comprehension and operator effort; a green trace is not prose acceptance |
| Delegation | Bounded child task, deadline/cancellation and shared budget; plain-function comparison | Explain first-use subprocess and budget concepts; retain evidence that delegation earns its added complexity |
| Linux operation | Explicit service, backup/restore and compatible-code maintenance reference receipts | Prove final-release operation on the supported host and recover against independent post-snapshot effects |
| Integrated day | Real controlled supplier and worker processes with fixture model/Telegram | Execute through the complete learner package and retain independent results; add field evidence without reclassifying fixtures as live |
Scroll horizontally to view columns.
Telegram's core lesson remains account-free. A separate field exercise requires a dedicated account, test-message consent and actual handset inspection. Record source revision, local work/report identities, sanitized API disposition and observed message. Cover restart after intake, restart before sending, duplicate requests and an uncertain send without automatic repetition. A simulated rate-limit response can test retry timing without forcing a live account to hit a service limit.
The optional ZeoCore appendix demonstrates one bounded protocol seam in a separate environment. It does not introduce a mandatory framework or promise a broad current integration catalog. No additional channel, marketplace, web gateway, general cron engine or autonomous real purchasing is needed to satisfy this edition's scope.
Teaching and companion deliverables
The completed sequence requires 38 ninety-minute learner units, two per chapter: 57 hours of dedicated core practice. Unit A constructs and connects; Unit B diagnoses, repairs and transfers. Each unit requires a student notebook and matching Markdown, a separate worked solution notebook/Markdown, progressive hints, independently authored outcomes and a saved learner artifact. That means 38 student notebooks, 38 solution notebooks, 76 matching Markdown files and 19 educator chapter guides.
At the reorganization, the existing sixteen-chapter course contributed 32 learner units and their worked counterparts. Their numerical migration is not proof that the new cumulative handoffs are built. All existing units must be reviewed against the new prerequisites and learner ownership; the three additional chapters add six new learner units plus six worked counterparts.
Each unit begins with observable goals and a prerequisite check. A new library or concept needs its smallest example, predicted output, explanation, deliberate failure, repair and eventual integration. Include retrieval questions and a changed-constraint task. Published additional cases become development material once they inform a repair; do not describe them as unseen tests forever.
Add three optional ninety-minute field worksheets for real Telegram, configured containment and Linux lifecycle/maintenance. These sit in the educator field material with explicit learner instructions and evidence forms, separate from the core units. Completing all three gives 61.5 planned practice hours. Unavailable credentials or host features must not strand the core course, while simulated alternatives must not certify real field acceptance.
Plan approximately 100,000–115,000 main-manuscript prose words to provide slower construction and explanation. The pre-expansion measurement was 65,401 words outside code fences. This is an allocation guide, not a padding requirement or a page-count promise. Typeset SQLite, Telegram and ambiguous-order samples before deriving a print extent. Human reader trials determine whether the material teaches well.
Implementation sequence and acceptance
| Order | Work | Required exit observation | Status on 2026-09-29 |
|---|---|---|---|
| 1 | Establish four assets and chapter identities | One visible map; preserved source content; active links and executable reference checks pass | Done |
| 2 | Finalize cumulative learner ownership and interface contracts | Every chapter's checkpoint runs only code the reader built, plus the standard library and locked course dependencies | In progress: 16 of 21 chapters (1–9, 11–14, 16, 18 and 21), enforced by the course gate; the ownership guide lists the rest |
| 3 | Author SQLite and its two units | Empty-root build works; rollback, conflicts and future-schema refusal fail correctly | Done: Chapter 4 |
| 4 | Author durable work and refocus Telegram/schedules | Both producers invoke the learner's actual admission/finish/outbox implementation | The queue is done (Chapter 8); Telegram and schedules still use the supplied runtime |
| 5 | Author MCP and refocus isolation | Independent protocol and host evidence; no unauthorized advertised tool invocation | Done: Chapters 14 and 15 |
| 6 | Expand dense existing chapters and all companion handoffs | 42 learner and 42 worked units execute independently with matching Markdown and guides | Units done and re-executed; chapter expansion continues |
| 7 | Author context engineering | Budget, compaction and pinned records built and measured | Done: Chapter 21 |
| 8 | Measure on a frontier model | Every experiment has a labeled Claude run beside its local run, with tokens and cost | In progress: Chapter 21 on Claude Haiku 4.5 and Sonnet 5.5, $8.46 USD at list price |
| 9 | Run final learner day and field observations | Independent supplier reconciliation plus separately labeled phone/container/Linux evidence | Open |
| 10 | Review the rendered book on the site | Unambiguous four-asset navigation, readable code and layout, and recorded learner timing | Ongoing |
Scroll horizontally to view columns.
Since 2026-09-28 the site is the book's only home, and the course lives in profrodai-resources, which runs its own notebooks and checkpoints. A merged pull request still does not establish what the website serves: only a deployed page does.
Completion works backward from the title: a Python-capable reader constructs the essential system, receives an authenticated phone request, retains appropriate memory, wakes without idle model calls, respects permissions, recovers from process and external-effect uncertainty and produces a report supported by independent records. See OWNERSHIP.md for the empty-workspace and deliberately broken-function checks. Reader comprehension, classroom pacing and print readability still require observed human review.
Keep building with Prof Rod
Found this material through a colleague, classroom or shared download? Get the complete book at profrod.ai/book and join the Prof Rod learner community. Bring one result, one question or one failure you learned from. Share this resource with another learner and keep its source links with it so they can find the full course and future updates.
