Locked Case Map (v1)
HungerSync Case Series — Locked Case Map (v1)
Section titled “HungerSync Case Series — Locked Case Map (v1)”Supersedes §3 of coverage-matrix.md. Decisions applied: C8 split into two
(config vs CI/review) and tighter target → four thematic merges to land at
10 cases. Coverage re-verified: all 27 Claude task statements and all 20 AWS
tasks still covered (see §3 below). The full per-task mapping and watchlist remain
in coverage-matrix.md.
Merges applied: C1+C2 → CS2 · C3+C4 → CS3 · C5+C6 → CS4 · C7+C12 → CS10 · C10+C11 → CS9. C8 → CS7 + CS8.
1. The ten cases
Section titled “1. The ten cases”| # | Title | Tag | System | Incident hook |
|---|---|---|---|---|
| CS1 | Designing HungerSync | AWS | S-all | The pitch is funded; now architect it under the Well-Architected GenAI Lens before the Peachtree contract clock starts. |
| CS2 | The ordering agent you can trust | Joint | S1 | The agent applies a voucher to the wrong passenger and confuses get_flight with lookup_booking. |
| CS3 | The storm breaks the pipeline | Joint | S2+S3 | A ground stop hits: the forecast forgets Concourse F and the FAA feed times out mid-surge. |
| CS4 | Discovery you can trust | Joint | S4+S5 | The app recommends a vendor that’s already 86’d, and the taste index keeps surfacing the wrong cuisine. |
| CS5 | The four-hour delay conversation | Joint | S1 | One passenger’s chat runs four hours; the agent forgets her nut allergy stated in hour one. |
| CS6 | Building with Claude Code: config & workflows | Claude | S8 | The team’s dispatch-engine refactor needs conventions that don’t drift across the monorepo. |
| CS7 | Claude in the pipeline: review & CI | Claude | S8 | Settlement code must be reviewed automatically in CI without false-positive noise or self-review blind spots. |
| CS8 | Trust & Safety: guardrails, privacy, governance | AWS | S9 | A passenger games the system for free vouchers; an allergen slips through; auditors ask who saw whose data. |
| CS9 | The ops center | Joint | S7+S10 | Token spend spikes during the storm, a hallucination reaches a passenger, and the nightly forecast must not block the live floor. |
Note: that’s nine rows because the C8 split already produced CS6+CS7; the tenth is below. Renumbered clean list follows so IDs are stable.
1b. Clean numbered list (stable IDs)
Section titled “1b. Clean numbered list (stable IDs)”| # | Title | Tag | System | Claude tasks | AWS tasks | Exhibit |
|---|---|---|---|---|---|---|
| CS1 | Designing HungerSync | AWS | S-all | (arch. judgment) | 1.1, 2.2, 2.3 | BMC, value-chain, ecosystem |
| CS2 | The ordering agent you can trust | Joint | S1 | 1.1, 1.4, 1.5, 2.1, 2.3, 4.2 | 2.1, 2.3, 2.4 | ecosystem, revenue-flow |
| CS3 | The storm breaks the pipeline | Joint | S2+S3 | 1.2, 1.3, 1.6, 2.2, 5.3, 5.6 | 1.2, 1.3, 2.1, 2.4, 2.5 | value-stream |
| CS4 | Discovery you can trust | Joint | S4+S5 | 2.4, 4.1, 4.2, 4.3, 4.4 | 1.2.4, 1.3, 1.4, 1.5, 4.2, 5.1, 5.2 | journey, capability-map |
| CS5 | The four-hour delay conversation | Joint | S1 | 1.7, 5.1, 5.2 | 1.6, 4.1, 5.2 | journey |
| CS6 | Building with Claude Code: config & workflows | Claude | S8 | 2.5, 3.1, 3.2, 3.3, 3.4, 3.5, 5.4 | — | (code) |
| CS7 | Claude in the pipeline: review & CI | Claude | S8 | 3.6, 4.6 | 2.3.5, 2.5.4, 2.5.6 | (code) |
| CS8 | Trust & Safety: guardrails, privacy, governance | AWS | S9 | 4.1, 5.2 | 3.1, 3.2, 3.3, 3.4, 2.3.3 | capability-map, journey |
| CS9 | The ops center | Joint | S7+S10 | 4.5, 4.6, 5.5 | 2.2, 4.1, 4.2, 4.3, 5.1 | swot, value-stream |
| CS10 | (reserve / overflow) | — | — | — | — | — |
We’re at nine load-bearing cases. The four merges saved more than expected, so CS10 is a held slot. Two clean uses for it: (a) un-merge CS4 back into a dedicated RAG case if it proves too dense (RAG + structured output is the heaviest pairing), or (b) a capstone end-to-end ground-stop case that re-runs the whole platform and exercises integration across all systems. Recommendation: hold CS10 as the capstone.
2. Tag distribution
Section titled “2. Tag distribution”AWS-primary: CS1, CS8 · Claude-primary: CS6, CS7 · Joint: CS2, CS3, CS4, CS5, CS9. Balanced, with the joint cases as the spine and two clean single-cert anchors per exam.
3. Coverage re-confirmation (post-merge)
Section titled “3. Coverage re-confirmation (post-merge)”Claude — all 27: 1.1 CS2 · 1.2 CS3 · 1.3 CS3 · 1.4 CS2 · 1.5 CS2 · 1.6 CS3 · 1.7 CS5 · 2.1 CS2 · 2.2 CS3 · 2.3 CS2 · 2.4 CS4/CS6 · 2.5 CS6 · 3.1–3.5 CS6 · 3.6 CS7 · 4.1 CS4/CS8 · 4.2 CS2/CS4 · 4.3 CS4 · 4.4 CS4 · 4.5 CS9 · 4.6 CS7/CS9 · 5.1 CS5 · 5.2 CS5/CS8 · 5.3 CS3 · 5.4 CS6 · 5.5 CS9 · 5.6 CS3. ✓
AWS — all 20: 1.1 CS1 · 1.2 CS3/CS1/CS4 · 1.3 CS3/CS4 · 1.4 CS4 · 1.5 CS4 · 1.6 CS5/CS8/CS4 · 2.1 CS2/CS3 · 2.2 CS9/CS1 · 2.3 CS1/CS8/CS7 · 2.4 CS2/CS3/CS9 · 2.5 CS7/CS3/CS9 · 3.1 CS8/CS4 · 3.2 CS8 · 3.3 CS8 · 3.4 CS8 · 4.1 CS9 · 4.2 CS9/CS4 · 4.3 CS9 · 5.1 CS9/CS4 · 5.2 CS5/CS4/CS9. ✓
Density flag (cost of “tighter”): CS3, CS4, and CS9 each carry a lot. Mitigation — each gets two assignments instead of one, splitting the load while keeping one narrative situation.
4. Still-open decisions
Section titled “4. Still-open decisions”- W1 — fine-tuned taste FM? I’ve provisionally placed AWS 1.2.4 (FM customization / Model Registry) in CS4 by giving the taste classifier a small fine-tuned FM. Confirm, or drop 1.2.4 to light coverage.
- CS10 use — hold as end-to-end capstone (recommended) vs split CS4’s RAG out.
- Novel ordering (later, doesn’t affect cases) — chronological ground-stop arc vs difficulty ramp.
5. Recommended build order
Section titled “5. Recommended build order”- Case template — the three-layer skeleton (Case / Assignment / Teaching Note) so every case is fast to produce and consistent.
- CS1 fully worked through all three layers as the reference implementation — it’s AWS-primary, opens the series, and reuses the business-architecture diagrams directly as exhibits.
- Then CS2 (the agent-reliability spine) and outward.