Appendix A. Bridges to Volume 1
The applied volume builds on the material from the first volume. This appendix collects all the bridges in one place: which parts of the first volume are considered prerequisites, how our SDD dialect relates to Spec Kit and Kiro, and how the production scenarios of the second volume grow out of the educational project AgentClinic.
If anything listed here is unfamiliar — first complete the corresponding part of the first volume, otherwise many chapters of the second volume will seem like a pile of terms.
Before Chapter 1, read Part 0. It translates the basic AgentClinic into an educational production model and fixes the minimal route: which artifacts are filled out manually, which examples are run locally, and which blocks belong only to the full implementation track.
Minimum without which the second volume is unreadable
| What you need to understand | Where it was introduced in the first volume |
|---|---|
Structure of mission.md, tech-stack.md, roadmap.md | Part 6. Creating a Constitution |
Format of requirements.md, plan.md, validation.md | Part 7. Feature Specification |
| Admission facts for merge, EARS, Given/When/Then | Part 9. Feature Validation: from Specifications to Facts |
| Replanning and roadmap updates | Part 10. Project Replanning |
| Legacy codebase support and spec archaeology | Part 13. Supporting an Existing Project |
| Agent replaceability, references to ACP/AGENTS.md | Part 15. Agent Replaceability |
| Team review and evidence package | Part 16. Teamwork and Code Review |
Qwen Code hooks, PreToolUse and PostToolUse | Part 17. Qwen Code Hooks |
| SDD anti-patterns | Part 20. SDD Anti-patterns |
| Practical exam as validation of the entire process | Part 22. Practical Exam |
SDD dialects: Spec Kit, Kiro, and the textbook's author dialect
The applied volume uses the same author dialect as the first volume. A detailed comparison with GitHub Spec Kit and AWS Kiro is given in Appendix A of the first volume: artifact correspondence table, recommendations for process migration, limitations of each format.
If your team already works in Spec Kit or Kiro, read the chapters of the second volume, mentally renaming requirements.md → /speckit.specify, plan.md → /speckit.plan + /speckit.tasks, validation.md → /speckit.analyze + checklists. The chapters are not rigidly tied to the format: their ideas transfer between dialects without loss of meaning.
AgentClinic domain map
The production scenarios of the second volume mentally unfold on the educational project AgentClinic from the first volume. The full description of domain entities — agent-patients, ailments, therapies, appointment bookings, reviews, feedback — is collected in Appendix B of the first volume.
The second volume does not require that the result of the first volume already works in real production infrastructure. All external systems in the chapters are educational sources of events and constraints. They are needed to show how the same SDD cycle behaves under the risk of rollback, escalation, metrics, and model budgets.
When production entities appear in the second volume (appointments-api, node_not_ready, appointment_latency, appointment_latency_spike, high_memory_usage, autoscale_200pct, cdn_error_budget_burn, rate_limit_breach), they are tied to AgentClinic as follows. For the exam route, use high_memory_usage as the main case; the other strings help understand local runnable examples and do not require a separate evidence package.
| Educational code from the first volume | Derived production scenario in the second volume |
|---|---|
Route GET / (Hello Hono, Part 7) | node_not_ready: replicas do not respond to health-check |
| Agents page on Hono JSX (Part 11) | appointment_latency / appointment_latency_spike: delay on the /agents route |
| SQLite + review migrations (Part 12) | high_memory_usage: read spike after deployment |
| Feedback form (Part 12) | rate_limit_breach: stream of identical POST requests |
| MVP phase (Part 12) | autoscale_200pct: sharp load growth |
| Agent journal (Part 11) | cdn_error_budget_burn: dashboard metric discrepancy |
| Clinic operator tone (Part 6) | shadow specifications from informal signals |
The README of the applied volume gives a short reading map and a link to this appendix. The full domain table lives here, so that when reading any chapter of the second volume, you can quickly recall which educational code corresponds to a production symptom.
What the second volume adds on top
| Layer | Where it is discussed in the second volume |
|---|---|
| AgentClinic-production lab frame and minimal route | Part 0. AgentClinic-production Lab |
| Recovering specifications from traces of a legacy system | Part 1. Recovering Specifications from Legacy |
| Controlled defects in specifications | Part 2. Specification Defect Diagnosis |
| Production constitution with immutable and mutable layers | Part 3. Project Constitution |
| Adversarial validation between roles | Part 4. LLM Duel |
| Mutation testing of specifications | Part 5. Specification Mutation Testing |
| Formalization of implicit heuristics | Part 6. Shadow Specification Selection |
| Specification gateway as a mandatory gate | Part 7. Specification CI |
| File arbitration of a disputed change | Part 8. File Arbitration of Disputed Change |
| Model routing and tiered budgets | Part 9. Tiered Budgets |
| Paired sentinel metrics anti-Goodhart | Part 10. Protecting Metrics from Goodhart |
| Integration with production API and auto-remediation | Part 11. Production API |
| Diagnostic map of applied cycle anti-patterns | Part 12. Production SDD Anti-patterns |
| Final production exam and evidence package | Part 13. Practical Exam |
The table above is the bridge that turns an abstract production scenario into a continuation of the educational project. In individual chapters of the second volume (for example, in Part 12 — production SDD anti-patterns), references to the first volume are also placed in the footer as a separate block; in other chapters they are woven into the text at the point of discussion.