Quick Reference: Domain 7 — Developer Productivity & Operational Enablement

The most important idea in the domain, and the substitution the exam puts into wrong options. Written instructions are context. They influence Claude and are right for conventions and architectural decisions, but they do not enforce a limit. Permission rules and lifecycle hooks are enforced by the client, whatever the model decides. The documentation says so four times:

• Memory doc: "Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead."
• Memory doc, on organisation-wide deployment: "Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer."
• Permissions doc: "Permission rules are enforced by Claude Code, not by the model. Instructions in your prompt or CLAUDE.md shape what Claude tries to do, but they don't change what Claude Code allows."
• Configuration-debugging doc: "Use CLAUDE.md for 'we do it this way here.' Use permissions or hooks for security boundaries and anything that must never happen, where you need a guarantee instead of guidance."

As of mid-2026 — re-verify before quoting. The names of the mechanisms below are parts of the product and change when the product changes. The judgement above them, about guidance versus enforcement, does not change.

The right answer and the tempting wrong answer name the same rule. Only one names a mechanism.

Learn how the scopes relate. You do not need to memorise the paths. Each layer exists because of who must not override it. Organisation-managed is for policy nobody may switch off. Project-committed is for the standard inherited on clone. Personal is for preference. Local-uncommitted is for machine values that never enter shared history.

As of mid-2026 — re-verify before quoting. Settings live at ~/.claude/settings.json (user), .claude/settings.json (project, committed), .claude/settings.local.json (local, gitignored), and managed policy delivered server-side or at /Library/Application Support/ClaudeCode/, /etc/claude-code/ or C:\Program Files\ClaudeCode\. Precedence, verbatim: managed (highest, cannot be overridden by anything) → command-line arguments → local → project → user (lowest).

Command-line arguments sit above a committed team standard and below managed policy: a control the organisation depends on belongs at the top and nowhere else. The exam's questions about a setting placed at the wrong layer follow from that ordering.

As of mid-2026 — re-verify before quoting. Three permission keys: allow, ask, deny, evaluated "in order: deny, then ask, then allow". additionalDirectories extends the file-access boundary, defaultMode the starting permission mode. Managed-only lock keys include allowManagedPermissionRulesOnly, allowManagedHooksOnly, allowManagedMcpServersOnly and strictPluginOnlyCustomization.

The durable property is that restrictive rules add together rather than override each other, which makes the managed layer a minimum that other layers cannot lower, not a default that they can replace:

• Settings doc: a list key such as permissions.allow can appear in more than one file. In that case, "Claude Code combines the lists instead of picking one, so each file can add entries without removing another file's".
• Permissions doc: "If a tool is denied at any level, no other level can allow it." A user-level denial blocks a project-level permission just as the reverse does.
• Administrator guide: array settings "merge entries from all sources, so developers can extend managed lists but not remove from them".

The tempting wrong option assumes a permission granted in one place allows what another place forbids. It never does.

As of mid-2026 — re-verify before quoting. Instruction-file scopes match the settings scopes: managed policy CLAUDE.md at the managed paths (cannot be excluded by individual settings), user at ~/.claude/CLAUDE.md, project at ./CLAUDE.md or ./.claude/CLAUDE.md, local at ./CLAUDE.local.md. A claudeMd key in managed settings carries the same content inline; claudeMdExcludes skips ancestor files in a monorepo. Path-scoped rules live in .claude/rules/*.md with a YAML paths field taking glob patterns, and personal rules at ~/.claude/rules/.

Root and ancestor instruction files load in full at launch, so they use context on every request whether relevant or not. Path-scoped rules and instruction files in subdirectories are the exception: they load only when Claude works on matching files, which is what makes scoping worth doing:

• Keep them short. The docs target under 200 lines per instruction file, because "Longer files consume more context and reduce adherence".
• Keep them consistent: "if two rules contradict each other, Claude may pick one arbitrarily".
• Scope narrow instructions to the code they govern rather than loading everything for everyone.
• A section that grows "into a procedure rather than a fact" becomes a packaged workflow: a skill.

The durable point is the reuse unit, the form in which work is shared. A procedure becomes a shared artefact. A recurring specialist task becomes a defined role with restricted tools. A recurring need for context becomes shared project context.

As of mid-2026 — re-verify before quoting.

Skill frontmatter includes name, description, allowed-tools and disable-model-invocation; subagent frontmatter includes name, description, tools (an allowlist), disallowedTools (a denylist) and model. Plugins bundle skills, hooks, subagents and tool connections into one installable unit. A skill's body "loads only when it's used, so long reference material costs almost nothing until you need it", which is why packaging material as a skill is better than pasting it where it always loads.

As of mid-2026 — re-verify before quoting. Hooks are configured under a hooks key inside a settings file, not a standalone file of their own for project or user configuration. The reference lists roughly thirty events, including SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PermissionRequest, PermissionDenied, Stop, SubagentStart, SubagentStop, InstructionsLoaded, ConfigChange, PreCompact, PostCompact and SessionEnd.

Memorise what the mechanism gives you, not the list. Hooks run at fixed points in the lifecycle, "which gives you deterministic control: certain actions always happen rather than relying on the LLM to choose to run them". So a check that must run before a turn can end is a hook, not a request in a prompt. The hook inherits the scope of the settings file that holds it. It merges with hooks from other scopes rather than overriding them.

Nothing secret goes into a shared layer: anything committed is visible to everyone with repository access and stays in history after deletion. Deleting it does not remove it from history; rotating it makes the exposed value useless. Machine-specific values belong in the local uncommitted layer.

Better still, automation that needs authenticated access should not hold the credential at all. Anthropic's secure-deployment guidance places a proxy outside the agent's boundary. The proxy injects credentials into outgoing requests, so the agent "never sees the credential itself". The proxy also enforces an endpoint allowlist, and every request is logged in one place. The same page names what leaks when a workspace is mounted carelessly: environment files, git credentials, cloud credential files, registry tokens and private keys. Its security principles are security boundaries, least privilege and defence in depth.

As of mid-2026 — re-verify before quoting. These answer "what actually loaded", the first question in both configuration debugging and incident response.

The same reasoning applies to any stack. When something configured is not taking effect, "the cause is usually that the file didn't load, it loaded from a different location than you expected, or another file overrode it" — three hypotheses, each answered by reading state.

Outcome measures are properties of the work and each can be measured beforehand: cycle time from ticket to merged change, defect escape rate (the share of defects that reach production), review latency (how long a change waits for review), the time new joiners take to become productive, incident time-to-resolution. Name the measure and its baseline before the quarter starts; a baseline reconstructed afterwards is an argument, not evidence. A same-period comparison shows whether the numbers moved, not why.

As of mid-2026 — re-verify before quoting. The analytics dashboard reports PRs with CC, Lines of code with CC, PRs with Claude Code (%), Suggestion accept rate and Lines of code accepted, plus daily active users and sessions. Attribution uses a window running from 21 days before to 2 days after the PR merge date. It excludes lock files, generated code and build directories. The docs call this deliberately conservative and an underestimate.

The docs present it as a usage measure to read beside an outcome measure: use it "alongside DORA metrics, sprint velocity, or other engineering KPIs to understand changes from adopting Claude Code". An accept rate (the share of suggestions that developers accept) is the tempting wrong answer because it is the number teams actually have.

As of mid-2026 — re-verify before quoting. The quoted lines and the levels of check enforcement below are documentation wording; the question that sorts the tasks does not change.

When a question describes a task, ask what checks its output cheaply. That one question decides which tasks to automate.

The best-practices page says it directly: "Give Claude something it can run that comes back pass or fail." Without one, "looks done" is all Claude has to go on, and "that makes you the test suite".

The docs rank how strongly a check controls the work. The weakest level is a request in the prompt. The next is a session-level goal condition that is re-evaluated every turn. The strongest is a hook that blocks the turn from ending until the check passes. The last is enforcement rather than instruction. This is the 7.1 idea of enforcement versus guidance, used inside a workflow.

Whatever produced a change is the worst reviewer available for it. It still holds the assumptions it used to write the change, and it fluently agrees with its own reasoning. The fix is in how the review is organised. A reviewer in a fresh context sees the diff and the criteria, not the conversation. So it "isn't swayed by the reasoning that produced the code".

Humans keep merge authority: the managed review "never approves or blocks the pull request", and its check run "doesn't conclude as a failure". The reviewer's own failure mode is named too: "A reviewer that's asked to find problems will always find something." Scope it to correctness and stated requirements, not personal style preferences.

As of mid-2026 — re-verify before quoting. The bundled /code-review skill runs in a background subagent with its own context window and takes --fix and --comment. The managed pull-request Code Review service is in research preview on Team and Enterprise plans. It posts findings at Important / Nit / Pre-existing severities. On average, a review takes roughly twenty minutes and costs 15 to 25 US dollars. The service reads a repository REVIEW.md.

The right level of autonomy depends on how cheaply an action can be undone, not how much the team trusts the tooling. Bound what automation may execute, gate irreversible actions behind an approval, protect the branches that matter, and make continuous integration a required check that no confident report from the agent can bypass. Broad, long-lived credentials that are granted because scoping slows people down do remove the delay. They do it by removing the control.

As of mid-2026 — re-verify before quoting. The controls that shape an unattended run: --allowedTools and --disallowedTools; --permission-mode, with values default, acceptEdits, plan, auto, dontAsk and bypassPermissions; --settings and --setting-sources; -p or --print for non-interactive runs, with --max-turns and --max-budget-usd as limits on length and spend; and --safe-mode to start with all customisations disabled.

The docs give the rule: before a run goes unattended, make sure it "can only touch what it should". Note which controls enforce and which only limit amounts. A turn cap limits loops that do not stop. The permission rules are what prevent actions.

The answer that is most reliably right in the domain: read what actually happened first — inputs, retrieved context, tool calls and their results, outputs, and the versions in use. A fix applied before the failure is understood usually changes something, occasionally fixes something, and always destroys the evidence.

Containment answers a different question from diagnosis, and blast radius decides which comes first:

Containment is not a diagnosis: a reverted system no longer shows the failure, and the failure is not understood. Containment that reverts everything at once also loses attribution, since when changes are reverted together, nobody learns which one was responsible.

Most incidents are caused by something that changed, so the fastest narrowing question is what changed and when the symptom started. Version and timestamp every kind of change: prompt and instruction versions, model versions, corpus refreshes, configuration changes, dependency and connector updates. Correlating onset against that timeline eliminates most of the possible causes without touching the system. When two changes land in the same window, test them one at a time — Domain 4's one-variable rule in an incident, and a small-scale use of the documented isolation technique: remove variables until the behaviour changes, then reintroduce them one by one.

As of mid-2026 — re-verify before quoting. claude --safe-mode starts with all customisations disabled while managed policy still applies; pointing the configuration-directory environment variable at an empty directory bypasses user configuration entirely. Session-level undo gives a basic level of recovery. /rewind, or a double Escape, restores conversation, code, or both. Snapshots are kept for the 100 most recent checkpoints. By default, they are deleted about 30 days after the session last saved one. Files changed only by Bash commands, most subagent edits and external changes are not tracked. Symlinked or hard-linked files are skipped on restore. The docs describe checkpoints as "designed for quick, session-level recovery" and leave "permanent version history and collaboration" to version control such as Git.

The team's ability to investigate is a deployment decision made in advance. Telemetry export is configured centrally through managed settings for that reason: "Environment variables defined in the managed settings file have high precedence and can't be overridden by users."

As of mid-2026 — re-verify before quoting. Telemetry is enabled with CLAUDE_CODE_ENABLE_TELEMETRY=1.

• Metrics: claude_code.session.count, claude_code.lines_of_code.count, claude_code.pull_request.count, claude_code.commit.count, claude_code.cost.usage, claude_code.token.usage, claude_code.code_edit_tool.decision, claude_code.active_time.total.
• Events: claude_code.user_prompt, claude_code.assistant_response, claude_code.tool_result, claude_code.api_request, claude_code.api_error, claude_code.tool_decision, claude_code.permission_mode_changed, claude_code.mcp_server_connection.
• Correlation: events carry a prompt identifier, so you can "trace all activity triggered by a single prompt"; tool results carry tool_use_id, tool_name, success, duration_ms and error_type.

Questions test what correlation makes possible, not the exact metric and event names: correlation is what lets an agent reconstruct a timeline from large volumes of data.

An agent is good at investigating but is not a reliable judge of the cause. It reads large volumes of traces, reconstructs a timeline, correlates a symptom against a deployment, reproduces a case and proposes hypotheses fast. Its account of its own behaviour is a hypothesis. It is generated from the same context that produced the behaviour. It has no privileged access to the cause, and it is persuasive because it is fluent. A human confirms it against the trace. One clean re-run clears nothing, and one failing run proves nothing. So confirmation means a pattern across collected cases.

The closing checklist, and the trap for candidates who nearly pass is stopping after the first line:

• A fix at the failing layer, verified against the case that actually failed.
• A regression case added to the suite Domain 4 owns.
• A runbook update, written while the gap is recent.
• Any access gap the incident exposed either closed or recorded.

An investigation plan assuming access the on-call engineer does not have cannot be carried out, and when an incident is closed with no artefact, the team pays its cost twice.