Topic: Applied Part 0. AgentClinic-production Laboratory
Difficulty level: Medium
Estimated study time: 2–3 hours (theory + initial environment setup)
Prerequisites: Successful completion of the first volume of the course (creating the base AgentClinic application).
Understanding of working principles with TypeScript, the Hono framework, SQLite, and Vitest.
Basic knowledge of CI/CD concepts, code review, and writing specifications.
Python 3 installed to run the educational scripts from the second volume.
Learning objectives: Master the methodology of reading the second volume as a single laboratory branch that develops one production case.
Understand the difference between real infrastructure and educational roles (Kubernetes, Grafana) within the course.
Set up the working environment: create the capstone/ directory structure and successfully run the first smoke test.
Learn to distinguish between command types ([runnable], [project script], [conceptual interface]) and understand which artifacts count toward the grade.
Formulate rules for transferring verifiable principles from additional cases (for example, autoscale_200pct) to the base case (high_memory_usage).
Overview: This section is a methodological "zero" chapter that prepares the ground for a deep dive into operational scenarios (production environment) of the AgentClinic application. Unlike the first volume, where the focus was on developing features and routes, the second volume switches to reliability, incident management, and specification quality. Here the concept of an end-to-end educational case (high_memory_use) is laid down, which will run as a common thread through all subsequent lab assignments. You will learn to work with the evidence package (capstone/), without requiring the deployment of real heavy production systems, and instead using lightweight Python scripts to simulate checks.
Key concepts: Agentclinic-production: The educational production model of your application. Unlike a real production environment, terms like Kubernetes or Grafana are used here as abstractions (roles) for understanding where a signal came from and how to act.
End-to-end case (high memory usage): The main educational incident (in the appointments-api service) on which you will practice the entire cycle: from alert to normalization and review. Only one main case is allowed in capstone/.
Execution stack: The product stack (TypeScript, Hono, SQLite) remains unchanged. To simulate production checks in the second volume, a layer of Python (stdlib) scripts is added — this is a cheap way to run tests without infrastructure.
Evidence package (capstone/): The final directory with artifacts that you will collect as you progress through the volume. It includes the requirements genealogy, specifications, verdicts, and reviews. It should be readable without the chat history.
Transfer map: A rule by which conclusions from local incidents (node_not_ready, cdn_error_budget_burn, etc.) are converted into abstract principles (for example, the anti-Goodhart invariant) and transferred into the graded high_memory_usage.
Practice exercises: Name: Initializing the graded package
Problem: You need to prepare the directory structure for the future evidence package for the selected incident.
Solution: 1. Open a terminal in the project root. 2. Run the command mkdir -p capstone. 3. Leave the directory empty until you complete the following chapters, or create an empty README.md indicating the base incident (for example, high_memory_usage).
Complexity: beginner
Name: Running smoke testing of the educational environment
Problem: Before starting work with chapters 4–11, you need to make sure that all local runnable examples work correctly.
Solution: 1. Find the script book2/examples/smoke_all.sh. 2. Run it in the terminal with the command bash book2/examples/smoke_all.sh. 3. Make sure the script completed without errors and left no garbage in the working tree (temporary files are created in an isolated copy).
Complexity: intermediate
Name: Analyzing the incident transfer map
Problem: Determine which specific artifact (principle) you should extract from the analysis of the cdn_error_budget_burn case into your main graded package for high_memory_usage.
Solution: According to the transfer map, you do not need to transfer the new service itself from cdn_error_budget_burn. You need to extract a pair of KPI + guard metric (a protective rule against metric skew, anti-Goodhart). Write this principle down in a common notebook or draft.
Complexity: intermediate
Case studies: Name: Building the architecture of the educational Capstone package
Scenario: A student is going through the second part of the course and has reached chapter 3. Before this, they studied various incidents, including node_not_ready and appointment_latency, and are now trying to understand how to link them with the main case high_memory_usage for the final review.
Challenge: The temptation to mix all studied incidents in a single capstone/ package, which will lead to confusion and a violation of the "one project — one production environment" rule. There is also a risk of attempting to implement a full-fledged Kubernetes cluster instead of an educational simulation.
Solution: The student applies the "Short Transfer Map". They keep only high_memory_usage at the center of attention. All other cases are used only as sources of verifiable principles. For example, from node_not_ready they take only the rule "do not close an incident without proof of recovery" and adapt it for their main case, saving this in the genealogy.md file.
Result: The capstone/ directory remains clean and focused. The student saves time by not dispersing their efforts on setting up multiple domains, and forms a strong, coherent evidence package that is easy to read without context.
Lessons learned: The second volume is read as a single laboratory branch, not a collection of scattered recipes.
Production terms (Grafana, PagerDuty) are roles for scenario analysis, not a call to set up heavy infrastructure.
Additional incidents are just "small laboratory windows" for practicing specific mechanisms.
Related concepts: End-to-end case
Transfer map
Evidence package (capstone/)
Study tips: Do not get stuck on terminology: if you encounter a term in a chapter that is not in the minimum vocabulary (genealogy.md, validation.md, judgment.md, readiness.md), simply skip it on the first read. Return to it when you need it to fill in a file in capstone/.
Separate the stacks: write the main product in TS/Hono, and for simulating stress tests or budget checks, use ready-made Python scripts from examples/ without trying to integrate them into production.
Watch the command tags: run only what is marked as [runnable]. The [project script] and [conceptual interface] interfaces are needed only for understanding the future architecture.
After each chapter, ask yourself: "What one new verifiable conclusion should I add to capstone/?" If there is no answer, re-read the "Minimum Route".
Additional resources: Book2/examples/readme.md: Instructions and descriptions of runnable scripts for each specific chapter.
Examples/templates/capstone-dossier.md: A filled-in example of what the final answer should look like (artifacts after the first pass).
Examples/smoke all.sh: The main script for quickly checking the operability of all educational simulations on your machine.
Summary: The "AgentClinic-production Laboratory" section sets strict but liberating boundaries for studying production development without the pain of real infrastructure. The main takeaway: focus on one end-to-end incident (high_memory_usage), collect the artifact package gradually (one file per chapter), and use additional scenarios only as sources of invariants and rules. The main rule is that your final capstone/ should be understandable to a reviewer without the history of your chat with the AI.