Answers & rationales

The loop branches on stop_reason: tool_use means “execute the call and continue the loop,” and the loop ends when Claude responds with stop_reason: "end_turn" — a normal completion carrying no tool call. max_tokens (truncation) and stop_sequence (a stop string was hit) are other ways a response can end, but neither is the “task finished” signal the loop waits for.

When a single response contains more than one tool_use block, the API requires every corresponding tool_result in the next user message — you collect all results and send them as one batch, each matched to its call by tool_use_id. Waiting for the slower query before sending is correct; (a) describes exactly that. (b) defers one result to a later turn, which the chapter rules out: you cannot answer one tool now and the other later. (c) collapses two results into one block, breaking the per-call tool_use_id join key that the next request needs. (d) drops one call’s result entirely and assumes the model will re-request it — but an unanswered tool_use block leaves the next request malformed, not merely incomplete.

A failed call still returns a tool_result — but flagged is_error: true, with actionable content (e.g. ConnectionError: weather API unavailable (HTTP 500)), so the next turn can reason about what to do. Omitting the result breaks the round-trip (every tool_use needs a matching tool_result); HTTP statuses are not how a handler signals the model; and tool_use blocks come from the model, not from your code.

This is the artifacts pattern: because results must cross a context boundary, large outputs are written to the filesystem or external storage and a lightweight reference is passed back — the high-fidelity output lives outside the coordinator’s window until it is actually needed. (b) defeats the whole reason the pattern exists: streaming everything back repollutes the lead’s window with the noise isolation was meant to keep out. (c) is worse still — the system prompt is the most expensive, always-resident slot. (d) is conversational compaction, not the multi-agent mechanism; it still spends tokens every turn, whereas a reference is read only on demand.

Decompose by context, not by role. The three vendors are independent research paths — a true context boundary — so the win is one isolated subagent per vendor, with the coordinator synthesizing once it holds all three (synthesis stays in one window because comparing needs every result at once). The researcher → analyst → writer → fact-checker split (b) is problem-centric: sequential phases of one tightly-coupled task that lose fidelity at every handoff — “the telephone game.” (c) nests that same anti-pattern inside the good split, multiplying handoff loss. (d) is wrong because there is a clean boundary to exploit — and parallelization to gain.

The verification subagent is the one multi-agent shape that succeeds across domains, and its characteristic failure is early victory — declaring success after one or two checks. The documented fix is an explicit completeness instruction: “You MUST run the complete test suite before marking as passed.” (b) destroys the property that makes a verifier reliable — its isolation; a blackbox verifier should get minimal context and hold no stake in how the work was produced. (c) adds cost and more failure points without addressing the premature-stop behavior. (d) misdiagnoses the cause: the verifier stops early by choice, not for want of budget.

Delegation is one level deep: subagents cannot spawn subagents. If a task seems to need a third layer, orchestrate that layer from the parent, not from inside a child. (b) is the documented anti-pattern — putting Agent in a child’s tools attempts a three-level hierarchy, but the depth-1 limit means the nested call produces no grandchild. (c) misdiagnoses the cause as a budget problem; maxTurns caps a subagent’s own turns and cannot create a missing level of delegation. (d) addresses the match gate, which is irrelevant here — even a perfect description cannot let a child invoke a grandchild past the structural limit.

A subagent starts in a fresh context window with no parent conversation, so “the bug we discussed” never crossed the boundary; the only inbound channel is the Agent tool’s prompt string. File paths, error messages, and prior decisions must be written into that prompt or they do not exist for the child. (b) is the exact misconception the chapter corrects — the parent conversation and tool results are among the things that do not cross. (c) misreads model: it only selects the engine and carries no conversation; even inherit transmits no prior turns. (d) confuses the run gate with a content channel — allowedTools decides whether the call is approved, not what context the child can see.

A subagent passes through two independent gates: the description is the match gate and allowedTools is the run gate — you need both. Here the description is already specific, so matching is fine; the listed allowedTools has no "Agent" entry, so the Agent-tool call is never auto-approved and falls through to canUseTool (or is denied in dontAsk). The fix is to add "Agent". (b) inverts the depth rule: you should not put Agent in a child’s tools — that array scopes what the child may use, not whether it can be invoked. (c) is wrong because model is optional and defaults; an unset model does not block invocation. (d) names the match gate, but the stem states the description is specific and keyword-rich, so matching is not the failing gate here.

The chapter’s Evaluate-level rule says to enforce programmatically when the workflow needs determinism, an audit trail, validation gates between steps, or a fixed and repeatable sequence — exactly this scenario, where the steps are known in advance and you want them to run the same way every time. (b) inverts the rule: prompt-based is the choice when the path is flexible and orchestration code would cost more than it saves, neither of which holds here. (c) invents a constraint the chapter denies — Anthropic notes the same workflow “translate[s] directly” between the CLI and the SDK, so translatability is not the deciding factor. (d) misstates when determinism matters: a fixed, known-in-advance sequence is precisely the case that wants deterministic enforcement, not the case that excuses it.

In the Writer/Reviewer pattern the absence of inheritance is the feature: a fresh context “won’t be biased toward code it just wrote” and “cannot rationalize choices it never made,” which is what makes the review independent. (b) invents a token-budget reason the chapter never gives — the point is bias, not context size. (c) describes early victory, a different failure mode from D1.2; here the issue is that an inheriting reviewer defends its own choices, not that it stops too soon. (d) is the biased case the pattern exists to avoid — handing the reviewer the writer’s transcript is exactly what reintroduces the bias the fresh context removes.

A schema check confirms the shape and nothing else — the chapter warns that a structurally perfect output can be semantically wrong (valid JSON, fabricated data), so the gate must pair the structural check with a semantic one wherever the content can be wrong, not just the form. A total that doesn’t add up is the chapter’s own example of a semantic failure. (b) cannot work: no amount of field or type strictness detects that correctly-typed numbers fail to sum — that is a content question, not a shape question. (c) is the silent-failure path the gate exists to prevent; on failure the gate should reject and retry, not wave the output through to publish. (d) over-corrects — the structural check is cheap and still catches malformed shapes; the chapter says to pair the two checks, not swap one for the other.

defer is the decision candidates miss: it ends the query so the host can resume it later from the persisted session — a pause-and-hand-back, not an allow — so the command does not run now. And updatedInput is ignored with defer; that field applies only to allow (or ask). To run a rewritten command the hook must return allow with updatedInput. (b) is the teammate’s mistaken model — defer neither permits nor applies the rewrite. (c) is closer but still wrong: defer hands the whole query back to the host rather than queuing the call for the next turn, and the rewrite is dropped either way. (d) confuses two distinct decisions — defer pauses and outranks ask, but a deny is what blocks a call outright, and deny outranks defer.

Stripping noise from a result is normalization, which happens on the side of tool execution after the tool runs. That is PostToolUse, and the field that does the work is updatedToolOutput, which replaces the output before Claude sees it. (b) names the gate side: PreToolUse with updatedInput rewrites the call’s input before the tool runs, but the noisy output does not exist yet at that point, so there is nothing to strip. (c) picks the right event but the wrong field: additionalContext appends to the result rather than replacing it, so the original ANSI-laden output still reaches the model. (d) blocks the call entirely, but the requirement is that the call still run — deny defeats the purpose.

All matching hooks run in parallel and the most restrictive result wins, following the fixed precedence deny > defer > ask > allow — so one hook returning deny blocks the call regardless of what the others return. (b) inverts the safety model: permitting requires every hook to agree, not a majority, so two non-deny votes cannot override a single deny. (c) gets the precedence backwards — deny outranks ask, not the other way around. (d) invokes execution order, but the outcome is decided by precedence, not by who finishes first; completion order is non-deterministic and a hook must never assume it.

The chapter attaches a price tag: an adaptive multi-agent flow “typically use[s] 3-10x more tokens than single-agent approaches for equivalent tasks,” and that spend buys thoroughness, not speed — parallel subagents explore a larger space, but coordination plus the slowest subagent often make the wall-clock slower. (b) keeps the right number but inverts the benefit: the chapter is explicit that parallelism does not buy speed. (c) is doubly wrong — it both denies the multiplier (adaptive work is not “the same tokens”) and claims a speed gain the chapter rules out. (d) borrows the language of the opposite structure: deterministic, auditable, bounded cost describe the sequential pipeline, which is precisely what an adaptive flow is not.

This is over-decomposition, the adaptive failure mode, and the chapter’s named guard is the effort-scaling heuristic: the orchestrator must be told how to size effort to complexity — “1 agent with 3-10 tool calls” for simple fact-finding, “2-4 subagents” for a comparison, “more than 10” for complex research. (b) throws away the adaptivity the open-ended task actually needs — forcing a fixed pipeline onto path-dependent work is the opposite failure mode (rigid pipelining). (c) misdiagnoses the cause: a budget cap may stop the bleeding but it doesn’t make the orchestrator size effort correctly — it just truncates, leaving the misjudgment intact. (d) is the wrong lever and inflates context: the fix is teaching the orchestrator to scale effort, not feeding every subagent the whole transcript.

The chapter’s deciding property is predictability, and this task fails it: the work is “inherently dynamic and path-dependent” — step N+1 depends on what step N discovered — so “you can’t hardcode a fixed path,” which is exactly what makes adaptive decomposition the right shape. (b) and (c) both reach for a pipeline, but a fixed sequence applied to path-dependent work is the rigid-pipelining failure: it is brittle and cannot branch on what it finds, and you cannot map findings to steps you couldn’t predict. (d) lands on adaptive for the wrong reason — “spawn many subagents up front” is over-decomposition; adaptive means the orchestrator sizes effort at runtime (the 1 / 2-4 / 10+ ladder), not that more agents is always better.

The chapter’s cross-host discipline is to lift the state you care about out of the conversation: capture the artifacts (analysis output, decisions, file diffs) as application state and pass them into a fresh session’s prompt — which the docs call “often more robust than shipping transcript files around.” (b) is the brittle option the chapter argues against: resuming by ID requires both restoring the transcript to the exact ~/.claude/projects/<encoded-cwd>/ path and reproducing the same cwd on every worker. (c) cannot help across hosts — forking still copies a transcript that lives under an encoded-cwd path tied to a directory, the very thing the fresh worker lacks. (d) restores files, not the conversation; checkpointing is a separate concern and does not carry the agent’s reasoning forward.

Forking branches the conversation history, not the filesystem — both forks share one working directory, so a file edit (or deletion) in either is real and visible to the other. The chapter’s pitfall names this exactly: treating a fork as an isolated sandbox corrupts the shared directory. (b) misreads what the “copy” is: a fork copies the conversation history, never a snapshot of the disk. (c) attaches sandboxing to the new session ID, but the ID identifies a second conversation, not a second world; to branch the files too you need file checkpointing. (d) invents an open/closed rule the chapter never states — isolation does not turn on whether the original session is still open; the disk is shared regardless.

The #1 resume bug is a mismatched cwd: sessions are stored under ~/.claude/projects/<encoded-cwd>/*.jsonl, where the encoded-cwd is the absolute working directory with every non-alphanumeric character replaced by -. Resume from a different directory and the SDK derives a different path, finds nothing, and silently starts fresh — even with the correct ID. (b) is the opposite of what the chapter teaches: an error_max_turns session stops on a budget, not a wall, so its transcript is intact and resumable. (c) misfires because the stem says the specific ID was passed; and continue reopening the most-recent session would still return history, not an empty one. (d) invents session-ID expiry, a mechanism the chapter never mentions — the lookup is by encoded path, not a time-limited token.

The chapter uses this exact trio as its example of the documented default — consolidate related operations into a single tool with an action parameter, because “fewer, more capable tools reduce selection ambiguity” — so (a) is the documented redesign and rationale. (b) addresses name collisions, but these three names already differ; the problem is too many near-equivalent tools, which namespacing does not reduce. (c) shows argument shape per tool yet leaves three selectable tools in place, so the model can still misroute among them. (d) improves each response’s signal but again preserves the three-way choice the consolidation is meant to remove.

The chapter names the description as “by far the most important factor in tool performance” — the surface the model selects from — and prescribes saying what the tool does, when (and when not) to use it, and what each parameter means (3-4 sentences). Since the model chooses tools by description alone and never reads the implementation, an opaque description is a performance bug it cannot route around, so (a) is the highest-leverage fix. (b) helps disambiguate a growing library but does not tell the model what the tool does or its boundary. (c) compounds the gain by showing argument shape, yet the chapter frames examples as a complement to a good description, not a substitute for one. (d) improves the response half of the contract, which shapes the next call rather than fixing why the model misroutes to this tool.

The chapter’s one hard rule is that each example must validate against the tool’s input_schema, or the request returns a 400 — so a single example with an illegal enum value (the chapter’s own typo’d “kelvin” case) fails the whole request, making (a) correct. (b) invents a numeric ceiling the chapter never states; the cost of examples is a token cost paid deliberately, not a hard cap. (c) misreads the client/server distinction: input_examples are precisely for client (user-defined) tools, so they are permitted here. (d) describes a soundness concern but not a 400 — a description that disagrees with the examples is a quality problem, while the schema-validation failure is what actually returns the error.

The casing is the regime tell: is_error (snake_case) is the Claude Messages API’s single tool-failure signal, while isError (camelCase) is MCP’s flag — conflating the two spellings is the most common mistake here. The direct API has no in-band JSON-RPC channel (a protocol-level problem surfaces as an HTTP error such as 400), and error_code is not a tool_result field.

A past departure date is an input-validation / business-logic failure the model can self-correct, so per SEP-1303 it belongs in the isError: true channel — an execution error returned inside a successful result, addressed to the model so it can read the text and retry. The routing rule is who can act on the error, not how severe it feels. (b) and (c) both mis-route a recoverable failure to JSON-RPC: that channel is reserved for protocol errors the model cannot fix (unknown tool, malformed request), and sending a validation error there silently denies the model its chance to correct and retry. (c) adds the right-sounding rationale of “let the host decide,” but the host audience is exactly wrong here — the failure should be addressed to the model. (d) hides the failure behind a success result, leaving the model nothing to flag or recover against.

The documented guidance is to scope with allowedTools: a mcp__server__* wildcard “grants exactly the MCP server you want and nothing more,” leaving every other safety gate intact. (b) inverts the recommendation — bypassPermissions auto-approves the MCP tools but disables every other safety prompt across the whole agent, broader than necessary. (c) is the wrong axis: tool_choice steers which of the available tools fires on one request; it does not define which tools the agent has at all. (d) misuses disallowedTools, which removes a tool from the request entirely (the model never sees it) — the opposite of granting the server’s tools.

Only auto and none are compatible with extended (or adaptive) thinking; any and a forced tool return an error — the two requirements are mutually exclusive, so you cannot both force a tool and let the model reason with thinking on. (b) is the wrong resolution: the conflict surfaces as an error, not as a silent demotion of thinking. (c) misreads the prefill behavior — forcing prefills the assistant message and suppresses the natural-language preamble; it does not produce a schema-violating one, and with thinking on the request never gets that far. (d) confuses axes: parallel execution is governed by disable_parallel_tool_use, a separate knob from tool_choice, and it is not what breaks here.

The chapter’s most-confusing collision is the word local: a local-scoped MCP server is stored in ~/.claude.json (home directory, under a per-project key), whereas general local settings live in .claude/settings.local.json (the project directory). They are different files in different directories, so (a) is right — that is where the definition actually lives. (b) edits .claude/settings.local.json, the exact file the chapter calls a silent no-op for a local-scoped server. (c) is the Project scope’s committed file; local-scoped servers are never written there, and scopes are not all resolved through one file. (d) confuses Local with User scope — a local-scoped server is current-project-only and not shared across all projects.

A project-scoped MCP server is declared in .mcp.json at the repository root, which is committed to version control so every collaborator inherits it. ~/.claude.json is user-global — it applies across all of your projects but is not shared through the repo. .claude/settings.local.json holds personal, git-ignored overrides. There is no mcpServers field in package.json.

When the same server name appears in more than one scope, Claude Code connects once, using the highest-precedence source, and the order is Local -> Project -> User -> plugin -> claude.ai connectors (the first three match duplicates by name). Local outranks Project, so the teammate’s ~/.claude.json definition wins on their machine, making (a) correct. (b) inverts the order — the shared Project config does not override a personal Local one; this is the intended path for letting personal credentials take over a team default. (c) is wrong: there is no field-by-field merge — only one definition connects. (d) is wrong: a name appearing in two scopes is resolved by precedence, not flagged as a conflict that blocks both.

A wired server that never connected is this chapter’s silent failure: the agent just runs without the tools. The documented fix is to read the system:init message — each server’s status is connected | failed | needs-auth | pending | disabled — and gate the run on it, so (a) is right. (b) assumes an exception is raised, but the chapter’s whole point is that no error is thrown; the failure surfaces only in the status field. (c) misreads the 60-second timeout: shortening it does not reveal the problem and would make slow-but-healthy servers fail — the chapter says pre-warm or use a lighter package instead. (d) strictMcpConfig controls which servers are considered (clean-room config), not whether a configured server actually connected.

The SDK checks permissions in a fixed order: Hooks, then Deny rules, then Permission mode, then Allow rules, then canUseTool. Because deny rules (step 2) sit above the permission mode (step 3), the Bash(rm -rf *) rule matches and denies the call before the mode is ever consulted — so the deletion is blocked even though the mode is bypassPermissions. (b) inverts the order: bypassPermissions is step 3, below deny rules, so it cannot approve first. (c) confuses the two instruments — allowed_tools only pre-approves and lives at step 4 (below the mode), so under bypassPermissions it is ignored entirely; the allowlist would not block anything. (d) invents a restriction: deny rules apply in every mode, which is exactly why they are the tool for forbidding.

The roster splits on whether a tool is read-only or state-modifying: read-only tools — Read, Glob, Grep — may run concurrently because they cannot conflict, while state-modifying tools (Edit, Write, Bash) run sequentially to avoid clobbering each other. So the two Grep calls and the Glob can fan out together; the Write must run on its own. (b) overgeneralizes: the runtime does not parallelize every call — state-modifying tools are held sequential. (c) misidentifies the property as “file-system tool” rather than read-versus-write — Write is a state-modifying file tool and is excluded, while Grep/Glob qualify by being read-only. (d) confuses this with a request-level cap: parallelism here is a property of the tool’s nature, not a switch the developer flips per request.

Unlike the five-level settings precedence (where the highest scope wins), discovered CLAUDE.md files concatenate root-down without overriding — both contradictory lines load into context at once (a smell to fix at the source, not something proximity resolves). The rule of thumb: settings override; instructions accumulate. Reasoning about CLAUDE.md the way you reason about settings.json predicts the wrong behavior every time.

The first time a session encounters an @import, Claude Code shows an approval dialog, and declining it disables imports permanently — the dialog does not reappear, so the referenced file silently will not expand until the choice is reset. (b) contradicts the documented behavior: the consequence is permanent, not re-prompted each session. (c) treats the decline as a one-time skip, but the chapter is explicit that the dialog does not come back. (d) confuses a declined approval with a hard failure — declining suppresses imports, it does not block the session from starting, and the chapter notes the overflow behavior past depth 5 (silent truncation versus error) is itself undocumented.

Settings resolve by a strict five-level precedence where the highest scope wins: Managed → CLI arguments → Local → Project → User. The --model haiku flag is a CLI argument (level 2), which beats both the project opus (level 4) and the user sonnet (level 5), so haiku runs. (b) inverts the ladder — being committed gives Project no power over a CLI argument, which sits a full two levels higher. (c) imports the CLAUDE.md mental model (broadest-first concatenation) onto settings; for settings the broadest scope, User, is the lowest, not the winner. (d) reaches the right model but by the wrong mechanism: settings override to a single value, and only permission allow/ask/deny rules are the merge exception — model is not.

Custom commands have merged into skills: the chapter states that .claude/commands/deploy.md and .claude/skills/deploy/SKILL.md both create /deploy and work the same way, so (a) is right. (b) repeats the colleague’s misconception — the flat file is not the sole way; it is the legacy shape. (c) inverts the truth: existing .claude/commands/ files keep working, so the skill form is not the only one that runs. (d) confuses built-in commands (behavior coded into the CLI) with the user-authored prompt mechanism that both files use; a custom /deploy need not be built-in.

disable-model-invocation: true keeps the skill’s description out of context entirely — it loads only when the user types /name — so the model is never told the skill exists and cannot auto-invoke; (a) matches the chapter exactly. (b) is the wrong mechanism: the chapter does not gate a seen description, it removes the description so there is nothing to match. (c) invents a load-on-first-use rule the chapter never states. (d) describes the separate budget-overflow path, where least-invoked descriptions drop first; that is a different cause from this flag, which always withholds the description.

The documented order is that “user-level rules are loaded before project rules, giving project rules higher priority” — rules concatenate, but the more-specific scope is read last and dominates, the same recency model as the CLAUDE.md hierarchy. So the project rule (“spaces”) wins. (b) inverts the order: a user-level preference is a default that a project rule can override by being read after it, not the other way around. (c) imports a priority mechanism that does not exist — paths controls whether a rule is present, not its precedence once loaded, and here neither rule is scoped anyway. (d) invents a cancellation behavior the chapter never describes; the conflict is resolved by load order, not by mutual nullification.

Path-scoped rules “trigger when Claude reads files matching the pattern, not on every tool use” — so a rule scoped to src/api/** has no effect during work that never touches src/api/, which is exactly the value of scoping: file-specific guidance that costs nothing on unrelated turns. (b) describes an unconditional rule (no paths), which loads at launch at the same priority as .claude/CLAUDE.md; the whole point of paths is that it does not load that way. (c) confuses any-tool-use with file-read: the chapter is explicit that the trigger is reading a matching file, “not on every tool use.” (d) invents a one-shot launch check the chapter never describes — the rule is dormant, not disabled, and would activate the moment Claude does read a matching API file.

Approving a plan exits plan mode and switches the session to the write mode the chosen approve option names — here “accept edits” lands the session in acceptEdits, where edits auto-approve and Claude starts editing. To plan again you must re-enter plan mode (cycle with Shift+Tab or prefix /plan); approval is one-way. (b) misses the whole point: the approval ends the read-only guarantee rather than staying in plan mode. (c) invents a second confirmation step — approval itself is the decision point, with no further gate. (d) confuses approving a plan with skipping permission checks; the approve options choose a write mode, not bypassPermissions.

The automatic 1M-context upgrade applies to the opus alias only, not opusplan — its Opus plan phase runs with the standard 200K window. So a ~400K planning context is out of reach under opusplan; you would pin a 1M model such as opus[1m] for that phase instead. (b) is the trap the chapter says to memorize against: 1M is opus-only. (c) invents a size-triggered window that does not exist; the cap is fixed at 200K for this alias. (d) misattributes context to the model switch — Sonnet runs execution, not planning, and switching models does not grant the planning step a larger window.

Plan mode is a no-edit mode, not a prompt-free one: Claude can read files, run shell commands to explore, and write a plan, but it does not edit your source — and “permission prompts still apply the same as default mode.” So the prompts behave exactly as in default; only the edits to source are withheld. (b) is the precise misconception the chapter corrects — read-only is the guarantee, silence is not. (c) invents a selective-suppression rule the chapter never states; prompts apply uniformly, as in default. (d) misreads writing the plan as a state that quiets prompts, but plan mode still gates the actions it allows throughout.

The chapter sets a hard threshold: corrected more than twice on the same issue in one session, “the context is cluttered with failed approaches. Run /clear and start fresh with a more specific prompt that incorporates what you learned” — a clean session with a better prompt “almost always outperforms a long session with accumulated corrections.” (b) is the move the chapter explicitly warns against: past the second correction each nudge fights a context polluted with the very approaches you are steering away from. (c) keeps the polluted context in place and still ends in another correction, so it does not reset the loop. (d) misdiagnoses the problem — the failed approaches in the window are pulling the model back, so giving them more room makes the drift worse, not better; the fix is to clear them, not accommodate them.

The chapter is explicit that a fresh session implements from the written spec: the interview session is “full of question-answer thrashing,” while the implementation session should “start with clean context whose only input is the written spec.” So the correct move is to open a new session (or /clear) and prompt it to implement per SPEC.md. (b) is the exact mistake the split exists to prevent — the interview context is full of half-formed options and back-and-forth, and the implementation session should not inherit that noise. (c) re-injects precisely the thrash the fresh session is meant to escape, defeating the purpose; the spec file is the clean hand-off, so the transcript is not needed. (d) discards the reviewable artifact that serves as both review gate and context bootstrap, and leans on a cluttered session’s memory instead of the corrected spec.

In headless mode the process exit code is the CI success contract — 0 passes the step, non-zero fails it. Hitting --max-turns “limits agentic turns and exits with error when reached,” i.e. a non-zero exit; but the trailing || true swallows that status, so the shell reports success and the next step consumes the truncated output as if it were real — exactly the pitfall the chapter warns against (“don’t mask the status”). (b) is wrong: --output-format json decides what the run prints, not its exit code; the two are independent. (c) inverts the documented behavior — --max-turns exits with error, it does not exit 0 with a warning. (d) is false: claude -p hands its real exit code straight to the runner (0 on success, non-zero on failure); total_cost_usd is a spend field, not a failure signal.

claude -p "<prompt>" (alias --print) is headless / print mode: it runs the prompt, writes the final result to stdout, and exits without opening the interactive REPL — the basis for CI/CD use. Pair it with --output-format json (or stream-json) for machine-parseable output. The other three flags are not real Claude Code modes.

The chapter is explicit on both points: --json-schema is “documented as print-mode-only — it works under -p, not in an interactive session,” and when used correctly with --output-format json “the schema-conforming result then arrives in structured_output.” So the engineer’s error is reaching for a print-mode flag in a terminal session; the fix is to run it under -p. (b) inverts the cause — the flag itself is print-mode-only, not merely the field it populates, so the chapter does not describe an interactive run that validates-but-hides the result. (c) misnames the required format: structured output uses --output-format json with --json-schema, not stream-json (which carries newline-delimited events, not a schema-validated payload). (d) invents a per-turn enforcement mechanism the chapter never states; --json-schema produces “validated JSON output matching a JSON Schema after agent completes its workflow,” not a per-turn check, and the reason it fails interactively is simply that it is print-mode-only.

The chapter is explicit that a positive instruction outperforms a prohibition when steering format or tone: “Respond in smoothly flowing prose” points straight at the destination, while a prohibition only names a forbidden region without locating the target inside the still-vast permitted one. (b) is the negative form the chapter contrasts against — banning lists rules out one failure but leaves a thousand other acceptable-but-unwanted shapes. (c) is still negative and adds a second vague term (“too structured”) with no defined target. (d) treats firmness as the fix, but absoluteness does not address the real defect: a prohibition shrinks the output space without aiming within it, so even an emphatic “never” fails to specify the paragraph form you meant.

The chapter’s discipline is to “stop at the rung the stakes require”: most fields never leave Rung 1 (explicit instruction), and only the crash-on-violation field earns Rung 3 (structured outputs / strict tools), which makes a non-conforming value unrepresentable rather than merely discouraged. (b) over-climbs — promoting every field to the strongest rung just buys setup cost and latency the lower-stakes fields don’t need. (c) under-climbs: the premise is that a fourth value crashes the pipeline, and instruction-plus-retries only makes the shape likely-correct, not unviolatable. (d) escalates to the wrong rung — few-shot (Rung 2) disambiguates ambiguous judgments but still cannot prevent an out-of-set label from being emitted.

The ambiguous case — an input with no order number — is exactly what an example should demonstrate: place one in the set whose output shows the field as null, in the middle, and the model generalizes from that treatment. (b) is the D4.1 instinct and it helps, but the chapter is explicit that a prose rule beside the examples teaches the case less reliably than a demonstration on it — the model generalizes from the example treatment, not the written rule next to it. (c) adds volume without diversity: more clean inputs never show the missing-field case, so the model still has nothing to copy. (d) is a band-aid that hard-codes one symptom — the model may emit "none" or "n/a" next, leaving you maintaining a translation table instead of fixing the prompt at its root.

With one example the model cannot separate the pattern from incidental traits, so it copies first-field-quoting as if it were required — the documented failure of 1-2 examples. The fix is diversity-via-count: move into the 3-5 range with examples that vary the incidental traits while holding the intended pattern constant, so the quirk no longer appears in every example and stops reading as the rule. (b) is the D4.1 instinct (write a rule), but the chapter’s point is that a prose rule beside the examples is weaker than letting contrasting demonstrations break the spurious pattern. (c) removes the demonstration entirely; zero examples breaks on exactly the kind of case the teammate is trying to pin. (d) misdiagnoses the cause — the model isn’t short on budget, it’s short on contrast.

You rent the typed tool-call slot as an output channel: the forced call’s input object is your shaped JSON, and the “tool” never does anything — you discard its result. Parsing JSON out of a free-text block with a regex is the brittle approach this pattern replaces, and output_config.format is the modern grammar-constrained feature — a different generation, not the classic pattern.

strict: true (grammar-constrained sampling) is honored only on the native Claude API. Calling through the OpenAI-SDK compatibility layer silently drops it — the request still succeeds, so a type mismatch you thought impossible can reappear. The native SDK honors it; batching is orthogonal; and combining strict: true with tool_choice: {type: "any"} is the documented “call one of N tools and validate its inputs” pattern, not a conflict.

This is truncation, not a grammar failure: max_tokens is a hard cap on output, and generation hit it partway through writing the object. The grammar did its job — every emitted token was schema-valid — but it cannot guarantee the structure finishes within the budget, so the JSON is cut off before its closing braces. The fix is to enlarge the room: raise max_tokens (or shrink the schema). (b) re-runs against the same budget and truncates at the same place — the chapter is explicit that a plain retry is not the fix. (c) addresses a different failure: a missing additionalProperties: false is the top schema-compilation 400, not a mid-write cutoff. (d) misreads the cause — the grammar was working per-token; abandoning it forfeits the type guarantee without giving the generation any more room.

A wrong-but-well-typed total is a semantic error — valid JSON, incorrect data — that no schema or type guarantee can touch. The chapter’s fix is to make the model show enough work for a mechanical test: emit both the document’s stated_total and its own re-summed calculated_total, then let application code compare them and route any mismatch to human review. (b) bounds magnitude, not internal consistency, and the chapter notes minimum is unsupported by the structured-outputs subset anyway. (c) only guarantees the total is present and a number — which it already was; a guaranteed type does nothing about a number being wrong. (d) addresses arithmetic effort, not the verification gap; the catch exists only because the verification field pair was added to the schema.

Exhaustion is a result you inspect, not an exception that throws, so the caller must branch on subtype: success carries the typed payload in message.structured_output, while error_max_structured_output_retries means the budget ran out and you fall back (simpler schema, simpler prompt, or human review). (b) assumes a throw — but the SDK returns a result on exhaustion, so a try/catch never fires and the failure path is still unhandled. (c) reads the payload before discriminating; on the error path message.structured_output is undefined, which is exactly how garbage reaches downstream code. (d) relies on a retry count the chapter says is undocumented, so it must never be hard-coded.

A cut-off response on the longest inputs is truncation, confirmed by stop_reason: "max_tokens" — the one failure retries cannot fix on their own, because re-prompting on the same output budget truncates at the same place and silently burns the whole retry allowance. The fix is to detect that stop reason and raise the cap (or shrink the schema). (b) adds attempts against the same budget, so every one truncates identically — more retries make it worse, not better. (c) loosening the checks lets a partial object pass and ships incomplete data; it treats truncation as a validation problem, which it is not. (d) mutating the schema between attempts invalidates the grammar cache and re-pays compilation — the opposite of the chapter’s advice to keep the schema fixed and vary only the feedback message.

The chapter states plainly that “streaming is not supported for batch requests,” and the exercise solution rejects the live-updating dashboard for exactly that reason — so the proposal cannot be built as described. (b) is the distractor’s trap: custom_id is the mandatory join key for unordered results pulled after the batch ends, but it does nothing to enable live per-ticket streaming, which the batch surface does not offer at all. (c) misattributes the limit — the output-300k-2026-03-24 beta raises the max_tokens cap, not anything about streaming. (d) invents a false size constraint: a single batch is limited to 100,000 requests, so 80,000 fits comfortably; the real blocker is the streaming feature, not the count.

The four result types (succeeded, errored, canceled, expired) are batch-level outcomes — they say the request ran, not that its answer is good. A succeeded result carries a message with its own stop_reason, and two values still bite: a refusal (stop_reason: "refusal") returns a 200, is billed, and may not match your schema; a truncation ("max_tokens") is incomplete output. So handling must inspect each succeeded message’s stop_reason, not stop at the result type. (b) inverts the chapter’s central warning: unusable refusals and truncations arrive precisely as succeeded, not as errored. (c) misreads the lifecycle — re-polling cannot reclassify a finished result, and stop_reason lives on the message, not the batch status. (d) is backwards on billing and content: succeeded is the type that includes the message result, while canceled/expired are the unbilled failures.

The failure mode is false-positive amplification: parallel reviewers each flag plausible-but-wrong issues, and with no filter those candidates accumulate, so more reviewers means more noise, not just more signal. The fix is the verification step, which re-checks each candidate against actual code behavior to filter out false positives before anything is posted — it is what makes fan-out a net gain rather than a faster false-positive generator. (b) discards the fan-out itself, which the chapter calls the direct architectural answer to attention dilution; shrinking to one reviewer surrenders the benefit instead of fixing the noise. (c) collapses the specialists’ single-class mandates back into one over-loaded checklist, reintroducing the dilution the fleet was built to avoid, and overlapping wrong findings still survive unverified. (d) misdiagnoses the cause as a budget shortfall; the problem is the absent behavioral filter, not how much room each reviewer has to second-guess itself.

Code Review’s check run “always completes with a neutral conclusion so it never blocks merging through branch protection rules” — it advises, it does not gate. The documented way to enforce its signal is to read the severity breakdown from the check-run output in your own CI and fail the step yourself, exiting non-zero when the Important count is positive so your own required check goes red. (b) misunderstands the neutral conclusion: branch protection can require the check, but a neutral result never counts as a failing status, so the merge is never blocked. (c) confuses trigger mode with gating — after-every-push only controls when reviews run; every run still completes neutral and blocks nothing. (d) treats the symptom as a finding-volume problem; more reviewers produce more findings (and more false positives without the verification pass), but none of them can flip a check that is neutral by design.

This is accumulation pressure: nothing is degraded — the budget is simply spent — so the fix is to reduce what accumulates (tighter tool outputs, or /clear and restart with a focused prompt). (b) is the lost-in-the-middle remedy, but here no buried fact has been misremembered; nothing is degraded to re-surface. (c) addresses post-compaction loss of an early rule, which hasn’t happened — the session has not compacted and no instruction has been dropped. (d) misreads spent budget as a quality bug; the chapter’s discipline is to name the mode first, and accumulation is not a degradation to instruct away.

Under the limit with no compaction, the failure is lost-in-the-middle: a model attends least reliably to material buried in the middle of a long window, so the fix is to re-surface the fact near the end of the context where it is attended to most reliably. (b) targets post-compaction loss, but the scenario never compacted — re-injection solves a problem that isn’t present. (c) is the bigger-window instinct, which does nothing for this mode: a larger context still loses its middle. (d) governs output length, not which earlier material the model attends to, so it is unrelated to the failure.

Subagents cannot call AskUserQuestion, so a subagent that hits an ambiguous requirement can only guess or fail — the exact failure escalation exists to prevent. The fix is to restructure the decomposition so the part that needs a human stays with the agent that can reach one: the coordinator resolves the open questions first, then delegates a fully-specified task. (b) assumes the limit is a missing callback, but the constraint is on the subagent’s side — it cannot raise AskUserQuestion at all, so wiring a callback gives it nothing to surface. (c) is exactly the guess-on-intent the chapter warns against; a recorded assumption is still a coin flip on a decision the model cannot make. (d) misdiagnoses the cause: the subagent is blocked by an absent escalation channel, not by a shortage of reasoning budget.

Suggest-alternative is a deny whose message carries guidance; Claude reads the guidance and adjusts its next step, so the command is blocked and the agent is steered toward the safe path in one move. (b) approve-with-changes would run the call after silently editing updatedInput — but the goal is to block this command and let Claude re-derive the safe approach itself, not to execute a rewritten version. (c) a plain reject blocks the command but supplies no guidance, so Claude is stopped without being redirected. (d) approve-and-remember allows the call and suppresses future prompts — the opposite of blocking a pipe-to-shell you consider unsafe.

The chapter states a compounding failure “is invisible to component tests precisely because it lives between components” — each part passes its own eval and the degradation appears only in the interaction, on traffic slices no single test exercises. The postmortem’s remedy is integration-level: “per-model evaluations on every prompt change, ablation testing, and soak periods before rollout — exercising the system as it actually runs.” (b) misses the point: the failure is not inside any one component, so more exhaustive component suites still can’t see a between-components effect. (c) is a real defense the chapter lists for error propagation across boundaries, but structured error context routes faults that surface — it is not the detection method the postmortem concluded was needed for a degradation no eval reproduced. (d) repeats the weakest-link fallacy the chapter rejects: the degradation lived in the interaction, not in a single least-reliable component, so swapping one agent does not address it.

The chapter’s propagation mechanism is specific: a mid-pipeline agent “usually has no one to ask, so it resolves the ambiguity — and a quietly-wrong resolution is handed downstream as if it were settled fact,” and “the next agent has no signal that the input it received was a guess.” That is why the reviewer rates plausible code fine: it never sees that a guess was made. (b) is wrong because the chapter’s failure is not forwarding unclear wording — the coder commits to one interpretation and emits clean code, so the reviewer sees a confident artifact, not ambiguity. (c) inverts the chapter: the whole point is that a mid-pipeline agent cannot escalate the way D5.2’s interactive agent can — it has no one to ask, so it does not wait on a human reply. (d) invents a retry-until-clear loop the chapter never describes; the coder does not re-query the planner, it silently picks an interpretation and moves on.

The decision rule is continuity. /compact condenses the conversation in place, so you keep going on the same task with a shorter (lossy) history; /clear starts a fresh conversation — the previous one still reachable via /resume — for switching to an unrelated task. Both free context, and neither changes the model.

Compaction summarizes the window and /clear wipes the window — neither touches the filesystem. State written to a file lives on disk, so the agent re-reads PLAN.md after a compaction, or in a freshly-cleared session, exactly as it left it. The durable layer of a long task doesn’t live in the conversation at all; /clear does not delete files.

Review is a funnel, not a gate: cheap auto-checks, then an isolated judge, then the human, with each tier escalating only what it cannot resolve. The judge catches wrong-but-plausible errors precisely because a fresh, independent context has no authorship bias toward the output it is checking — it can judge correctness where a regex or equality test cannot. (b) retries with the same model, but a confidently-wrong extraction reproduces on the second run, so agreement is not evidence of correctness. (c) trusts self-reported confidence, which a confidently-wrong output also reports as “high” — a claim, not a measurement. (d) is safe but uncalibrated: it spends the most expensive reviewer on every record and does not scale.

A confidence signal earns its routing role by measurement, not by its name: you measure, over real labeled data, the accuracy at each stated-confidence level and set the bar where the signal reliably predicts correctness. (b) trusts the word “high” as if it meant “certain” — but a measured “high” can be 94%, not ~100%, so roughly six in a hundred high-confidence extractions are wrong, an unacceptable residual on a high-stakes clinical field. (c) discards a signal the measurement shows is informative (accuracy falls monotonically high to low) and routes on frequency, which carries no information about correctness. (d) ignores the chapter’s warning that calibration is not permanent — you re-measure when the model, prompt, or input distribution changes.

The chapter is explicit that “Citations cannot be used together with Structured Outputs … the API will return a 400 error,” because cited text must interleave with the response prose, which a strict JSON schema forbids. You cannot get span-bound attribution and a grammar-constrained JSON shape in the same call; the fallback is the provenance triple. (b) describes a real limitation — scanned images without extractable text are not citable — but a scan failure is not what produces this 400; the conflict is structural, not a document-quality problem. (c) names the all-or-none enablement rule, a separate constraint that governs mixing cited and uncited documents, not the Citations-plus-schema collision. (d) misreads the cost model: cited_text “does not count towards output tokens,” so it cannot overflow the output budget.

The chapter states the reliable knowledge cutoff is earlier than (or equal to) the training-data cutoff because data near the training cutoff is sparse, so the model’s reliable knowledge stops before its training does — Sonnet 4.6 trained through January 2026 but is reliable only to August 2025, and the earlier date bounds trust. (b) picks the training cutoff, the exact trap the chapter warns against: training reach is not reliability, so January 2026 overstates what the model dependably knows. (c) denies the gap the chapter builds the whole section on — the two dates are distinct, not the same boundary. (d) is true only after a dated source is supplied; the question is precisely whether memory is trustworthy first, which the reliable cutoff decides.