feat: link PR #394 case study to actual GitHub PR

The canonical case study is referenced 10+ times across ch01, ch08,
ch12, ch13 but was never hyperlinked. First mention in each chapter
now links to microsoft/apm#394

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: danielmeppiel

handbook/ch01-the-agentic-sdlc-thesis.qmd

@@ -68,7 +68,7 @@ The five constraints, and the failure modes each addresses:
 
 Each constraint is necessary to address its failure mode. Together, they form a minimal sufficient set.
 
-These constraints sound abstract. Later in this book, we trace a single pull request — 70 files changed, 2,874 tests passing, 3 human interventions, roughly 90 minutes of wall-clock time — that demonstrates what they produce in practice. That case study shows both what worked and what required human escalation. It is evidence, not a sales pitch.
+These constraints sound abstract. Later in this book, we trace a single pull request — [70 files changed, 2,874 tests passing, 3 human interventions, roughly 90 minutes of wall-clock time](https://github.com/microsoft/apm/pull/394) — that demonstrates what they produce in practice. That case study shows both what worked and what required human escalation. It is evidence, not a sales pitch.
 
 **The REST parallel is specific, not decorative.** REST's statelessness constraint meant servers didn't maintain session state between requests — which seemed limiting, but induced scalability. PROSE's Reduced Scope constraint means complex work is decomposed into tasks sized to fit available context — which seems slower, but induces consistent quality. REST's uniform interface meant all resources were accessed the same way — which seemed rigid, but induced independent evolution. PROSE's Explicit Hierarchy means instructions form a global-to-local tree — which seems bureaucratic, but induces domain adaptation without context pollution.
 

handbook/ch08-the-practitioners-mindset.qmd

@@ -70,7 +70,7 @@ Your job as escalation handler is to be available for these moments and to resol
 
 The ratio between these roles shifts as you gain experience. Early on, you spend most of your time reviewing — checking agent output carefully, catching failures, building intuition for what agents get wrong. As you develop better specifications and better instincts for decomposition, the review burden decreases and the architect role dominates. The escalation handler role remains roughly constant — some decisions always require a human.
 
-**These three roles are not theoretical categories.** Chapter 13 traces a real pull request — PR #394, 70 files changed, 90 minutes, 3 human interventions — and each intervention maps directly to one of these roles. The first intervention was a scope decision during planning: the practitioner assessed audit findings and decided to include all severity levels rather than deferring moderate issues. That was the Architect. The second was an agent recovery: an agent stalled mid-migration, and the practitioner diagnosed the failure mode, decided to split the remaining work across two replacement agents, and re-dispatched. That was the Escalation Handler. The third was test triage: a test failed after wave completion, and the practitioner traced the cause to an ordering issue in the migration and directed a targeted fix. That was the Reviewer. Three interventions, three roles, no overlap. The framework is not a taxonomy for its own sake — it describes the actual pattern of human judgment in agentic execution.
+**These three roles are not theoretical categories.** Chapter 13 traces a real pull request — [PR #394](https://github.com/microsoft/apm/pull/394), 70 files changed, 90 minutes, 3 human interventions — and each intervention maps directly to one of these roles. The first intervention was a scope decision during planning: the practitioner assessed audit findings and decided to include all severity levels rather than deferring moderate issues. That was the Architect. The second was an agent recovery: an agent stalled mid-migration, and the practitioner diagnosed the failure mode, decided to split the remaining work across two replacement agents, and re-dispatched. That was the Escalation Handler. The third was test triage: a test failed after wave completion, and the practitioner traced the cause to an ordering issue in the migration and directed a targeted fix. That was the Reviewer. Three interventions, three roles, no overlap. The framework is not a taxonomy for its own sake — it describes the actual pattern of human judgment in agentic execution.
 
 ---
 

handbook/ch12-multi-agent-orchestration.qmd

@@ -93,7 +93,7 @@ For cross-cutting changes, organize agents by area of expertise rather than by w
 └─────────────────────────┘  └─────────────────────────┘
 ```
 
-In the reference case study (PR #394, detailed in Chapter 13), this two-team structure — architecture team led by an architect agent, domain team led by a logging expert agent — handled a 70-file change across five concerns. The architecture team carried type definitions and structural patterns. The domain team carried output conventions and migration examples. Neither team needed the other's context, and both produced output consistent with their specialization.
+In the reference case study ([PR #394](https://github.com/microsoft/apm/pull/394), detailed in Chapter 13), this two-team structure — architecture team led by an architect agent, domain team led by a logging expert agent — handled a 70-file change across five concerns. The architecture team carried type definitions and structural patterns. The domain team carried output conventions and migration examples. Neither team needed the other's context, and both produced output consistent with their specialization.
 
 This pattern scales by adding teams. A security concern adds a security team. A documentation concern adds a documentation team. Each team brings its own specialized context, its own instruction files, and its own validation criteria. The coordination cost is between teams, not within them.
 

handbook/ch13-the-execution-meta-process.qmd

@@ -172,7 +172,7 @@ Tasks that fail the self-sufficiency test are the primary source of mid-wave esc
 
 ---
 
-## PR #394: The Worked Example
+## [PR #394](https://github.com/microsoft/apm/pull/394): The Worked Example
 
 The meta-process is abstract until you see it execute. This section walks through a specific PR — an auth and logging architecture overhaul on a real codebase — with exact numbers.