Developer productivity and operational enablement — study roadmap

This unit is CCARP-U7 · Developer Productivity & Operational Enablement, 7% of the blueprint and the smallest domain on the paper. It carries three official objectives in one topic, and almost every question in it is really the same question: who does this reach, and will it actually happen?

The six confusions this domain tests

1. Two configuration systems, opposite merge rules. Settings list keys combine across files. A tool server entry is taken whole from one scope, with no field merging. Reading one rule onto the other is how a half-configured server appears.
2. Environment variables are not a level. They are not in the precedence stack at all, and which one applies is decided per variable-and-key pair.
3. An instruction is asked for; a hook happens. Both memory systems are context rather than enforced configuration. A step that must run at a fixed point is a hook.
4. An unattended session loads more than you think. Without bare mode, a print-mode run executes the repository's committed hooks and connects its tool servers, in a folder nobody has ever trusted, with no trust dialog and no per-server approval.
5. A hook that exits 0 has told nobody anything. Its standard error reaches the debug log and never the transcript, and Claude never sees it. Exit 2 is the remedy — and it blocks only on events that can block, so on the post-tool event it shows Claude the failure after the tool has already run.
6. The local-file exemption does not explain a hook. An untracked project local file skips the workspace-trust step for its permission allow rules. Hooks are held back from every settings file, the author's own included.

Sequence

1. LO1 first, because its vocabulary carries the other two: the four settings files, the precedence stack, and the three tool-server scopes.
2. LO2 second. Its first half is one discrimination — instruction against hook — and its second half is what a non-interactive run still loads.
3. LO3 last, because it is mostly LO1 and LO2 read backwards. Every symptom in it resolves to a file that did not load, a level that took the key, or an exit code nobody saw.

This is the smallest unit on the paper at 20 seats, so depth per objective matters more than breadth. Expect the scenario stems to concentrate on the seam between a developer's machine and a teammate's.

What to carry into the exam

For each objective, be able to name the mechanism, its scope, and the reading that would settle a dispute about it. This domain rewards knowing where to look. Almost every wrong answer in it is a plausible guess offered in place of a command that would have answered the question.

Sources and their limits

Every factual claim is grounded in retained documentation, quoted verbatim with a recorded retrieval date and content hash. Three cautions:

• Behaviour here is versioned, and the documentation says so repeatedly. Several statements carry a minimum version, and a few describe what changed before one. The retained snapshots were current at their recorded retrieval date; check the current position before relying on a version-sensitive detail.
• This unit teaches configuration, not administration. What an organization should enforce is a policy question for that organization. What is here is where a setting lands, who it reaches, and how to prove which one applied.
• Paths and file names differ by platform. The documentation notes Windows and worktree variations for several files. Learn the scope each file carries, which is what the objective tests, rather than memorising one machine's paths.

Every command, exit code and file name used in an exercise is quoted from the documentation. Every threshold, team name and failure fixture is a house fixture, labelled where it appears.