# Trainer’s Guide — Advanced Level, Session 9
# “Certification scenarios”

**Program:** Applied AI — Yann Isola
**Audience:** Solutions architects preparing for certification *Claude Certified Architect*
**Duration:** 2 hours (+ 10 minutes recommended break halfway through)
**Prerequisites:** Sessions 1 to 8 of the advanced level (API Claude, tool use, MCP, Claude Code, advanced prompt engineering, context & reliability). This session **does not present any new concepts**: it brings together everything that has been seen, from the exact angle of the exam.
**Materials:** interactive session web page (`webpage/index.html` — scenario analyzer, domain coverage tracker, timed exam simulator), projector, score sheet per participant.

---

## Educational objectives

At the end of the session, each participant knows:

1. **Describe** the format of the exam: 60 questions, 90 minutes ⚠, MCQ (MCQ = Multiple Choice Questionnaire) and questions based on scenarios, success threshold 72% ⚠ (i.e. 720 on a scale of 100 to 1000), 4 scenarios drawn from 8, no penalty for a wrong answer.
2. **Map** the 5 areas of the exam and their weighting: Architecture & agent orchestration (27%), Tool design & MCP integration (18%), Configuration & workflows Claude Code (20%), Prompt engineering & structured output (20%), Context management & reliability (15%).
3. **Analyze** each of the 8 exam scenarios: identify expected architectural decisions, recurring pitfalls and areas called for.
4. **Apply** the “root cause → least effort → guarantee required” reading grid to eliminate distractors from a certification MCQ.
5. **Self-assess** your coverage of the 5 areas and build a revision plan prioritized by weighting.
6. **Manage** exam time: 90 seconds per question on average ⚠, marking and second pass strategy.

> ⚠ **Session agreement:** all figures marked ⚠ (exam format, number of questions, duration, threshold, weightings) are **volatile**. They reflect the exam guide at the time of writing. Absolute reflex: check the official Anthropic certification page before booking the exam.

---

## Timed plan

| Block | Duration | Content |
|------|-------|---------|
| 0. Opening | 5 mins | Exam format, rules of the game, session method |
| 1. The MCQ reading grid | 10 mins | Anatomy of a certification question, method of elimination |
| 2. Scenarios 1 & 8 — Customer support & agentic tools | 20 mins | Routing, Escalation, Preconditions, Tool Selection and Chaining |
| 3. Scenarios 3 & 7 — Multi-agents & conversational AI | 20 mins | Coordinator/subagents, consensus, stateful sessions, memory |
| **Pause** | 10 mins | |
| 4. Scenarios 2, 4 & 5 — Claude Code (dev, productivity, CI/CD) | 25 mins | CLAUDE.md, slash commands, plan mode, headless, PR review |
| 5. Scenario 6 — Structured Data Extraction | 15 mins | JSON schemas, validation, edge cases, trust calibration |
| 6. Exam Simulator | 20 mins | Timed mini-exam (web page), collective correction |
| 7. Review plan & closure | 5 mins | Domain Tracker, Prioritization, Review Logistics |

---

## Block 0 — Opening (5 min)

**Catch message:** “You have eight sessions of material in your head.The exam won't ask you to recite it: it will put you in the shoes of an architect facing a dysfunctional system, with four plausible fixes — three of which are well-constructed traps. Today, we learn to think like the author of the question. »

### The format, black on white

Project and comment on this table (volatile figures ⚠):

| Parameter | Value ⚠ |
|---|---|
| Number of questions | 60 |
| Duration | 90 minutes (i.e. 90 seconds/question on average) |
| Type | MCQ, 1 correct answer out of 4 + questions based on scenarios |
| Rating | Scale 100–1000, threshold **720** (≈ 72%) |
| Penalty for error | **None** — answer all questions, always |
| Scenarios | 4 drawn randomly from 8 |

**Three practical consequences to hammer home:**

1. **No penalty** → we never leave a question blank. Even at random, it's a 25% chance of winning.
2. **4 scenarios out of 8** → we can't get away with it. Each scenario must be mastered, because we don't know which ones will fall.
3. **72% threshold** → we are allowed ~16 errors out of 60. This is comfortable if the 3 heaviest areas (27 + 20 + 20 = 67% of the exam) are solid.

### The 5 domains and their weight

| Domain | Weighting | ≈ Questions out of 60 ⚠ |
|---|---|---|
| 1. Agent architecture & orchestration | 27% | ~16 |
| 2. Tool design & MCP integration | 18% | ~11 |
| 3. Configuration & workflows Claude Code | 20% | ~12 |
| 4. Prompt engineering & structured output | 20% | ~12 |
| 5. Context management & reliability | 15% | ~9 |

**Strategy point:** Domain 1 weighs almost twice as much as Domain 5. An hour of review on agent orchestration statistically “pays off” more than an hour on context management — but be careful, the domains intersect in the scenarios: a “customer support” question can evaluate Domain 5 (escalation).

---

## Block 1 — The MCQ reading grid (10 min)

### 1.1 Anatomy of a certification question

Each question follows the same skeleton:

1. **Situation** — a system in production with a measured symptom (“in 12% of cases, the agent jumps `get_customer`…”);
2. **Question** — almost always some variation of “which change is **most effective**?” » or “what is the **first** step?” » ;
3. **Four options** — one correct, three distractors constructed according to identifiable recipes.

**Insist on the trap words in the statement:** “the most effective”, “the first step”, “with the least effort”, “the best”. These are not ornaments: they mean that **several options may be technically valid**, and that we decide between the cost/impact ratio or the logical order of intervention.

### 1.2 The four families of distractors

Have the room build this table (she saw enough questions in previous sessions to fill it):| Distractor Family | Signature | Typical example |
|---|---|---|
| **The magic prompt** | Solve by prompt which requires a deterministic guarantee | “Improve the prompt system” in the face of a critical business rule |
| **Over-engineering** | A heavy component (ML classifier, routing layer) for a simple problem | “Train a separate classifier” when explicit criteria are enough |
| **The invented feature** | A flag, variable or file that does not exist | `CLAUDE_HEADLESS=true`, `--batch`, `.claude/config.json` |
| **The symptom, not the cause** | A plausible fix that addresses another problem | “Sentiment Analysis” for an escalation calibration problem |

### 1.3 The reading grid in three questions

To be applied systematically, in order:

1. **What is the root cause?** (not the symptom — reread the situation, the numerical data points to the cause)
2. **Does the rule require a deterministic guarantee or is probabilistic compliance sufficient?** (deterministic → programmatic hooks/preconditions; probabilistic → prompt/few-shot)
3. **Among the options that address the cause, which has the best effort/impact ratio?** (certification rewards the simplest correction that resolves the problem)

**Board demo** with Question 1 of the exam guide (preconditions blocking `process_refund`): unfold the grid step by step. Response A (programmatic precondition) comes out in 30 seconds, because the situation says “incorrect reimbursements” = critical business rule = deterministic guarantee required = prompt options (B, C) fall automatically.

---

## Block 2 — Scenarios 1 & 8: Customer support & agentic tools (20 min)

### 2.1 Scenario 1 — Customer Support Agent

**Guide Statement:** agent built with the Claude Agent SDK (SDK = Software Development Kit) to handle returns, billing disputes, and account issues. MCP Tools (MCP = Model Context Protocol): `get_customer`, `lookup_order`, `process_refund`, `escalate_to_human`. Goal: First contact resolution > 80% with appropriate escalation.

**Domains called:** 1 (orchestration, preconditions), 2 (tool descriptions, structured errors), 5 (escalation, ambiguity).

**Expected architectural decisions — to be displayed on the board:**| Problem in the scenario | Architect response expected | Why not the alternatives |
|---|---|---|
| Agent skips ID verification before refund | **Programmatic precondition** (hook) that blocks `process_refund` until `get_customer` returns a verified ID | The prompt = probabilistic conformity; money requires determinism |
| Bad routing between `get_customer` and `lookup_order` | **Enrich tool descriptions**: input formats, examples, limitations, when to use one vs the other | Descriptions are the #1 selection mechanism; the few-shot comes after |
| Poorly calibrated escalation (escalates simple cases, keeps complex cases) | **Explicit escalation criteria + few-shot examples** in system prompt | Self-perceived confidence is unreliable; the feeling ≠ complexity |
| Multiple customer matches for one name | **Request additional credentials** from the user | Never make heuristic assumptions about identity |
| Explicit request to speak to a human | **Immediate escalation**, without prior investigation | Delaying an explicit request degrades satisfaction and violates the escalation contract |

**Sentiment point of attention:** the scenario mentions sentiment analysis. On examination, it almost always appears as a **distractor**: the feeling (anger, frustration) is a tone signal, not a reliable indicator of the complexity of the case nor a criterion for escalation in itself. An irate customer may have a trivial problem; a calm client, an inextricable political exception. Good practice: sentiment can modulate the **tone** of the response, but escalation is decided on **explicit policy criteria**.

**Handoff protocol:** during escalation, produce a structured summary — client ID, reason, actions already attempted, recommended action. A classic exam question opposes “transferring the raw conversation” (bad: the human must reread everything) to “structured summary” (good).

### 2.2 Scenario 8 — Agentic AI tools

**Honest context to give:** this scenario is reported by candidates but less documented in community guides ⚠. It covers three transversal skills: **tool selection, chaining, error recovery**. Good news: everything is already covered by Domains 1 and 2 — it's a recombination.

**Tool selection — the rules to know by heart:**

- Too many tools per agent **reduces** the reliability of the selection (the canonical example: 18 tools instead of 4-5). The exam answer: Narrow the toolset to the scope of the role.
- Ambiguous or overlapping descriptions → bad routing. First fix: rewrite/rename (`analyze_content` → `extract_web_results`).
- `tool_choice`: `"auto"` (model can respond in text), `"any"` (must call a tool, any tool), `{"type": "tool", "name": "..."}` (forced tool). Typical question: “ensure structured output when multiple schemas exist” → `"any"`; “guarantee a precise tool first” → forced selection.

**Chaining — two patterns:**

- **Chaining imposed by the software** (preconditions, hooks) when the order is a business rule;
- **Prompt-guided chaining** when order is a preference. The exam tests the ability to choose the right one.

**Error recovery — the taxonomy to recite:**| Error category | Example | Retryable? | Good answer from the tool |
|---|---|---|---|
| Transient | timeout, service unavailable | Yes | `errorCategory: "transient"`, `isRetryable: true` |
| Validation | invalid input format | Yes, after correcting the entry | Message specifying the expected format |
| Profession | reimbursement above policy threshold | **No** | `retryable: false` + readable explanation |
| Permission | access denied | No (climb) | Distinguish from a valid empty result |

**The golden trap of Domain 2:** distinguish "access failure" (you have to decide whether to retry or escalate) from "valid empty result" (the search worked, there are just no matches). A tool that returns an empty set on timeout **masks a failure as a success** — definite anti-pattern under consideration.

---

## Block 3 — Scenarios 3 & 7: Multi-agents & conversational AI (20 min)

### 3.1 Scenario 3 — Multi-agent search system

**The wording of the guide:** coordinator who delegates to specialized sub-agents (web research, document analysis, synthesis, generation of reports). Output: full reports **with citations**.

**Domains called:** 1 (heavily — this is the heart of the 27%), 2 (tool allocation), 5 (error propagation, provenance).

**Hub-and-spoke architecture — the invariants:**

1. **The coordinator owns all inter-agent communication**: decomposition, delegation, aggregation, error management. The subagents do not speak directly to each other (observability).
2. **Subagents have an isolated context**: they do not inherit the coordinator's history. Any necessary context should be **explicitly included in their prompt**. Recurring review question: a subagent produces an off-topic result → probable cause: the context of the previous phases was not transmitted to it.
3. **Parallelism**: several `Task` calls in a single round of the coordinator generate parallel subagents. The coordinator's `allowedTools` must include `"Task"`.
4. **Prompts of the coordinator in objectives and quality criteria**, not in step-by-step instructions (otherwise we lose the adaptivity which justifies multi-agents).

**The three classic failures of scenario 3 — and their diagnosis:**

| Symptom | Root cause | Correction |
|---|---|---|
| The report covers only part of the subject | **Too narrow breakdown by the coordinator** (he divided “creative industries” into 3 visual sub-themes) | Review the coordinator's decomposition prompt — the subagents did what they were asked to do |
| Timeout of a subagent → entire workflow fails or generic status | Poorly designed error propagation | **Structured error context**: type of failure, query attempted, partial results, alternatives — coordinator decides |
| Latency +40% due to back and forth verification | The summary goes back through the coordinator for each simple check | **Least graduated privilege**: give the synthesis a tool `verify_fact` limited for the 85% of simple cases, keep the coordinator path for the complex |

**Consensus and contradictions - the expected pattern:** two credible sources give contradictory figures (40% vs 12%). The correct exam response is **never** to choose heuristically, nor to escalate by blocking everything, nor to transmit without marking the conflict.This is: **keep the two values, explicitly annotate the conflict with attribution of sources, and let the coordinator reconcile**. Add publication dates (a “contradiction” is often a temporal difference).

**Citations and provenance:** attribution is lost in the summary if we do not preserve the “affirmation → source” correspondences. Require structured output from subagents: assertion, URL/document name, citation, date. Refer to session 8 for full chain of provenance.

### 3.2 Scenario 7 — Conversational AI architecture patterns

**The guide's statement:** Multi-turn conversational systems — context window management, persistence of instructions across turns, memory strategies, design of tools for safe execution, ambiguous or contradictory inputs.

**Summoned Domains:** 5 (heavy), 1, 4.

**Structuring reminder #1 (the most tested):** the API is **stateless**. Each query must return all necessary history. There is no "server-side session" in the Core Messages API. Stateful sessions are an **application responsibility** (or a feature of the SDK/Claude Code: `--resume`, `fork_session`).

**Memory strategies — the decision board:**

| Strategy | Principle | When | Risk |
|---|---|---|---|
| Complete history | Return everything at every turn | Short conversations | Saturation + quadratic cost |
| Sliding window | Keep only the last N rounds | Sessions where the distant past doesn't matter | Loss of commitments made early |
| Progressive summary | Summarizing ancient tricks | Long sessions | **Numerical values, dates, amounts** are diluted into vague summaries |
| Hybrid (summary + recent verbatim + block of facts) | Old summary + N verbatim rounds + **persistent “case facts”** excluding summary | Serious production | Implementation complexity |

**The “case facts” pattern is the reflex response:** extract the transactional facts (order number, amounts, decisions taken, commitments) in a persistent block **never summarized**, injected at each turn. This is the #1 risk avoidance of the progressive summary.

**Persistence of instructions:** the instructions of the system prompt are diluted in very long conversations (“lost in the middle” effect: the model handles the beginning and the end well, less the middle). Parades: reinject critical constraints near the end of the context, structure with XML tags (XML = eXtensible Markup Language) separating system / data / instructions.

**Ambiguous or contradictory entries:** request clarification when the ambiguity relates to an irreversible action; for multi-aspect requests, explicitly break it down into separate elements and handle them one by one.

---

## Block 4 — Scenarios 2, 4 & 5: Claude Code (25 min)

This is the densest block: three scenarios for Domain 3 (20%) plus part of Domain 1. Announce the structure: configuration (S2) → productivity (S4) → CI/CD (S5).

### 4.1 Scenario 2 — Code generation with Claude Code

**The four configuration mechanisms — hierarchy to know by heart:**| Mechanism | Location | Scope | Shared via VCS (VCS = Version Control System)? |
|---|---|---|---|
| CLAUDE.md user | `~/.claude/CLAUDE.md` | All sessions of **this user** | **No** |
| CLAUDE.md project | `CLAUDE.md` root or `.claude/CLAUDE.md` | The whole team on this repository | **Yes** |
| CLAUDE.md directory | project subdirectory | Files in this subtree | Yes |
| Targeted rules | `.claude/rules/*.md` with frontmatter `paths:` (glob patterns) | Loaded **only** by editing corresponding files | Yes |

**The classic review diagnosis:** “a new team member doesn't have the conventions” → they are at the **** user level instead of the **project** level. Variant: "test conventions must apply to `**/*.test.tsx` files scattered everywhere" → `.claude/rules/` with glob pattern, **not** one CLAUDE.md per directory (the files concerned are in too many directories), **not** everything in the root CLAUDE.md (constantly loading the context).

**Modularization:** `@path` (`@./standards/coding-style.md`) syntax to include external files; `.claude/rules/` themes (testing.md, api-conventions.md) rather than a monolithic CLAUDE.md.

**Slash Commands and Skills:**

- **Project** commands: `.claude/commands/` (versioned, whole team); **personal** orders: `~/.claude/commands/`.
- Skills: `.claude/skills/` with frontmatter `SKILL.md` — `context: fork` (execution in an isolated context, does not pollute the main session — reflex response for verbose skills), `allowed-tools` (tool restriction), `argument-hint` (parameter guidance).

**Planning mode vs. direct execution — the decision rule:**

- **Plan mode**: significant changes, several viable approaches, architectural decisions (restructuring a monolith, migration affecting dozens of files). Allows safe exploration before modification.
- **Direct execution**: simple and well understood change (a validation to add, a bug with clear stack trace in a single file).
- The **Explore** subagent isolates the verbose discovery output (context protection).
- The answer “start live and switch to plan when things get stuck” is a distraction: it’s reactive, we’re already paying for the recovery.

### 4.2 Scenario 4 — Developer productivity tools

**Built-in tools — who does what (almost guaranteed exam question):**

| Tool | Usage | Not to be confused with |
|---|---|---|
| **Grep** | Search in the **contents** of files (function names, error messages, imports) | Glob (filenames) |
| **Glob** | Find files by **name/extension patterns** | Grep (content) |
| **Read / Write** | Read/write entire file | Edit (targeted modification) |
| **Edit** | Precise change by **unique** text match; if not unique → fail → fallback Read + Write | |
| **Bash** | Shell commands (tests, build, git) | |

**The pattern for exploring an unknown code base:** Grep entry points → Read to trace flows → build the understanding **incrementally**. On exam: “the agent must understand how function X is used through wrapper modules” → Grep on the name, then Read call sites.

**MCP in Claude Code:**- **project** scope: `.mcp.json` (shared, for the team); **user** scope: `~/.claude.json` (personal experiences).
- Secrets: substitution of environment variables in `.mcp.json` (`${GITHUB_TOKEN}`) — **never** clear token in a versioned file.
- **MCP resources** serve as “content catalogs” (database schemas, summaries) to avoid repeated exploratory tool calls.
- Prefer MCP **community** servers to in-house servers for standard integrations (GitHub, databases).

### 4.3 Scenario 5 — Claude Code for continuous integration

**Headless mode (headless = headless, non-interactive) — the exact flags:**```bash
# Le pipeline reste bloqué ? Il manque -p (--print) :
claude -p "Analyse cette pull request pour les problèmes de sécurité"

# Sortie structurée exploitable par le pipeline :
claude -p "Revue de sécurité de ce diff" \
  --output-format json \
  --json-schema review_schema.json
```Recurring distractors: `CLAUDE_HEADLESS=true`, `--batch`, stdin redirect — **non-existent features or workarounds**. The documented response is `-p` / `--print` ⚠.

**Architecture of an automated PR review (PR = Pull Request, merge request):**

1. **Independent body for review**: the session which generated the code is less effective in revising it (it keeps its reasoning context and does not question its own decisions). Revise = new instance without generation context.
2. **CLAUDE.md as CI context**: testing standards, review criteria, available fixtures — this is what makes the review relevant to THIS project.
3. **Minimize false positives**: **explicit and categorical** criteria (“report: bugs, security; ignore: minor style”) rather than “be more conservative” (ineffective generic guidance). High false positive rates in one category undermine confidence in all others → temporarily disable noisy categories.
4. **Re-execution after new commits**: include previous review results to only report new/unfixed.
5. **Large PR**: passes per file + inter-file integration pass (dilution of attention in single pass — see session 8). The distractor: “take a model with a larger context window” — a larger window does not correct the quality of attention.

**Batch vs real time in CI:** **blocking** verification before merging → synchronous API (developers wait); **nightly** report (technical debt, weekly audit) → Message Batches API (−50% ⚠, processing window up to 24 hours ⚠, no latency SLA — SLA = Service Level Agreement, service level commitment). The Batch API does not support multi-turn tool calls in a query ⚠; correlation by `custom_id`; in case of partial failure, resubmit only the failed elements.

---

## Block 5 — Scenario 6: Structured data extraction (15 min)

**The guide's statement:** extract information from unstructured documents (invoices, contracts, semi-structured documents), validate by JSON schemas (JSON = JavaScript Object Notation, JavaScript object notation), maintain high precision, manage edge cases.

**Summoned domains:** 4 (heavily), 5 (trust calibration, human supervision).

### 5.1 The reliable mining stack — from bottom to top

1. **`tool_use` + JSON schema** = the most reliable way to ensure schema-compliant output. Eliminates JSON **syntax** errors. With `tool_choice: "any"` or forced, the model cannot respond with free text.
2. **But the schema does not prevent semantic errors**: totals that do not reconcile, value in the wrong field. Certain point of review: “we have a strict schema, why are there still errors?” » → the diagram validates the **form**, not the **meaning**.
3. **Design of the schema against hallucination:** fields **optional/nullable** when the source may not contain the information (a required field forces the model to invent); enums with `"other"`/`"unclear"` + detail field for extensibility.
4. **Semantic self-check:** extract both `calculated_total` (row sum) and `stated_total` (displayed total) to detect discrepancies by programmatic comparison.
5.**Retry with error feedback:** resend the original document + incorrect extraction + **precise validation errors**. Absolute limit: retry is **ineffective if the information is absent from the source** (it is in an external document) — detect it and route for human review, not loop.
6. **Few-shot for ambiguous cases:** 2-4 examples showing correct extraction on documents of **different structures** — the few-shot reduces extraction hallucinations.

### 5.2 Calibration and human supervision (Domain 5 in scenario 6)

**The pitfall of aggregated metrics:** “97% overall accuracy” can hide 60% on a minority document type or on a specific field. Exam Answers:

- **stratified random sampling** of high-confidence extractions (detect new error patterns);
- **Precision by document type and field** before automating anything;
- **Field-level confidence scores**, calibrated on a labeled validation set;
- **Human review routing** of low confidence or ambiguous source extractions.

**Expected production release sequence:** sample → prompt iteration on the sample → stratified validation → calibrated confidence thresholds → automation with continuous sampling. Any exam option that automates 100% from “overall accuracy is good” is a distractor.

---

## Block 6 — Exam simulator (20 min)

**Unfolded:**

1. Open the session web page, **Exam simulator** tab. 12 questions, 18 timed minutes (real pace: 90 seconds/question).
2. Each participant works alone, under examination conditions (no documentation).
3. At the end: individual score + collective correction of the 3 most failed questions (the page displays the room statistics if the trainer records the scores by show of hands).

**During the correction, hammer home the method, not the answer:** for each missed question, verbalize: “Which family of distracters got me? » (magic prompt / over-engineering / invented feature / symptom). The goal is for everyone to leave with awareness of **their** dominant bias.

**Time strategy to transmit:**

- First pass: respond to everything that comes out in < 60 s, **mark** the rest;
- Second passage: the marked questions, with the remaining time;
- Last minute: **no empty questions** (no penalty);
- Scenario-based questions take longer to read: read the **question** before the situation to know what to look for.

---

## Block 7 — Revision plan & closure (5 min)

1. **Domain tracker** (web page, dedicated tab): each participant self-evaluates on the skills of the 5 domains with a level of confidence (🟢 mastered / 🟡 to review / 🔴 gap). The page calculates a preparation score **weighted by exam weights**.
2. **Prioritization rule:** first review the 🔴 of heavy domains (D1 27%, D3 20%, D4 20%), then the 🟡. A 🔴 in D1 statistically costs ~4 questions; a 🔴 in D5, ~1.5.
3. **Logistics:** check the official Anthropic page ⚠ for up-to-date terms and conditions (registration, monitoring, language, ironing policy). Remember that **all figures in this session are volatile**.
4. **Exit ticket:** each participant notes their weakest scenario and their revision window.Announce the exercises (S1 architecture design, S3 comparison of approaches, S6 evaluation grid) and session 10.

---

## Certification pitfalls — trainer’s cheat sheet

To distribute or project at the end of the session. The most profitable “quirks”:

1. **Deterministic vs probabilistic**: critical business rule (money, identity, compliance) → hooks/preconditions, never the prompt alone.
2. **Tool descriptions** = #1 selection mechanism. First correction in case of bad routing, before few-shot or routing layer.
3. **Subagents = isolated context.** Nothing is inherited; everything happens explicitly in the prompt.
4. **Decomposition too narrow**: when the coverage of a report is partial, suspect the coordinator, not the subagents.
5. **Structured error > generic status**; access failure ≠ valid empty result; never mask failure as success.
6. **`-p` / `--print`** for headless; `--output-format json` + `--json-schema` for the IC. `CLAUDE_HEADLESS`, `--batch`: do not exist ⚠.
7. **`.claude/commands/`** = team (versioned); **`~/.claude/commands/`** = personal. Same logic for `.mcp.json` (project) vs `~/.claude.json` (user).
8. **`.claude/rules/` + glob patterns** when conventions apply per file type across the entire codebase.
9. **JSON schema = syntax guaranteed, semantics not guaranteed.** Nullable fields against hallucination; useless retry if the information is missing from the source.
10. **Batch**: −50% ⚠, ≤ 24 h ⚠, no SLA → never for blocking; `custom_id` to correlate; resubmit only failures.
11. **Weak self-review**: independent body to review; passes per file + integration pass for large PRs; “larger context window” does not repair attention.
12. **Feeling ≠ complexity; self-assessed confidence ≠ reliable.** Escalation based on explicit criteria; explicit human request = immediate escalation.
13. **Progressive summary dilutes the figures** → “case facts” block persisting outside the summary.
14. **Aggregated metrics lie** → stratify by document type and field; confidence at field level.
15. **No exam penalty** → answer everything, always.

---

## Appendix — Correspondence scenarios × domains

| Scenario | D1 (27%) | D2 (18%) | D3 (20%) | D4 (20%) | D5 (15%) |
|---|---|---|---|---|---|
| S1 Customer Support | ●● | ●● | | ● | ●● |
| S2 Code generation | ● | | ●●● | ● | |
| S3 Multi-agent search | ●●● | ● | | | ●● |
| S4 Dev Productivity | ● | ●● | ●● | | ● |
| S5 Claude CI/CD code | | | ●●● | ●● | ● |
| S6 Structured extraction | | ● | | ●●● | ●● |
| S7 Conversational AI | ●● | ● | | ● | ●●● |
| S8 Agentic Tools | ●● | ●●● | | ● | ● |

(●●● = dominant domain, ●● = strongly present, ● = present)

**Strategic reading:** D1 and D3 are everywhere — impossible to be weak there. D2 focuses on S1/S4/S8. D4 is mainly played on S5/S6. D5 is diffuse but peaks on S7.