Developer Productivity & Operational Enablement

1. Claude Code, From an Architect's Seat

The exam does not ask whether you can drive the CLI. It asks whether you configured it so that twelve engineers get the same behavior, the same guardrails, and the same tool surface, without trusting each of them to remember. That is a configuration problem, and it has a small number of moving parts.

The CLAUDE.md hierarchy

Claude Code assembles its working context from a layered set of CLAUDE.md files, most-specific-wins. The one that matters for a team is the project file, checked into the repository. It is shared context; it is reviewed like code; it is the same for everyone who clones.

What belongs in the project file: the exact build and test commands, the architecture invariants an engineer would otherwise have to learn by breaking them, code conventions, and the short list of hard constraints. What does not belong: secrets (never), long prose, and anything that merely restates what the code already says. A CLAUDE.md that duplicates the codebase is a second thing to keep in sync and a place for drift to hide.

# Project: claims-triage

## Build & test
- Install: `uv sync`
- Test: `uv run pytest` (must pass before any commit)
- Lint: `uv run ruff check .`

## Architecture invariants
- The classification step is a single augmented-LLM call. Do NOT
  turn it into an agent loop.
- Every denial route requires a named human. Never auto-execute a denial.
- Structured output is the contract: keep the schema in `schemas/triage.py`.

## Conventions
- Type-hint everything; no bare `except`.
- New model calls go through `llm/client.py`, never `anthropic.Anthropic()`
  inline.

## Never
- Never commit secrets. Credentials come from the environment.
- Never edit files under `vendor/` or `migrations/` without asking.

Settings precedence and where team policy lives

Behavioral configuration (permissions, hooks, model defaults) lives in settings.json, and it layers the same way the context files do.

Permissions and hooks: the load-bearing distinction

Permissions are allow/deny rules for tools and commands. This is Lab 5's principle applied to the developer's own machine: if a capability is dangerous, remove it rather than writing a prompt that asks the model not to use it. A denied Bash(rm -rf:*) rule cannot be argued out of the way by a cleverly phrased task.

Hooks are deterministic code that runs on tool events: before a write, after an edit, on session start. A hook is the right home for a lint gate, a secret scan, or a hard block on a destructive command, because a hook executes. It is not a request the model can decline; it is a program that runs and can return non-zero.

{
  "permissions": {
    "allow": [
      "Bash(uv run pytest:*)",
      "Bash(uv run ruff:*)",
      "Read", "Edit", "Grep", "Glob"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./.claude/hooks/scan-secrets.sh" }
        ]
      }
    ]
  }
}

Reusable team assets and the CI path

Two more pieces round out a team configuration, and both live in the repo so the whole team inherits them:

• Subagents and custom slash commands — checked-in definitions that give everyone the same specialized helpers (a reviewer subagent, a /migrate command) instead of each engineer reinventing them.
• MCP servers configured at project scope — so every engineer's Claude Code sees the same tool surface (the internal docs server, the ticketing integration), rather than a surface that varies by whoever set up their laptop.

Finally, Claude Code runs headless: non-interactively, as a step in a pipeline. That is how AI-assisted work becomes a repeatable CI job rather than something that only happens when a human is at a keyboard.

# A CI step: run Claude Code non-interactively in print mode.
# The project CLAUDE.md and .claude/settings.json travel with the repo,
# so the pipeline inherits the same context, permissions, and hooks
# the whole team uses.

claude -p "Review the diff on this branch against our conventions in \
CLAUDE.md. List any violations. Do not edit files." \
  > review-output.txt

# Credentials come from the environment (see section 5), never from a flag.

2. Three Ways to Build an Agent, and the Trap

Once a team decides it wants an agent (open-ended, model-directed tool use; the four-part test from Lab 1 still applies), there are distinct products for building one, and the exam likes to test whether you can tell them apart. The confusion is real: two of them have similar names and do different things.

Separate them with two questions: who supplies the harness (the agent loop and context management) and who supplies the deployment (the infrastructure it runs on).

The mental model is the harness/deployment split. Tool Runner and the Agent SDK both give you a harness only; you still host and deploy. Managed Agents is the only one that supplies both. A manual while stop_reason == "tool_use" loop supplies neither; you own everything.

3. Where AI-Assisted Workflows Actually Pay Off

The objective is to "improve developer workflows," and the architect's job is to point the leverage at the tasks where it compounds, and to know each one's failure mode, because the exam rewards the candidate who names the risk, not the one who is merely enthusiastic.

The thread running through every failure mode is the same: generated code is reviewed like any other code. That is the governance stance an architect owns. It has three parts: a review requirement (a human approves before merge, exactly as for hand-written code), provenance (you can tell what was AI-assisted, so a regression can be traced), and the flat rule that AI authorship changes nothing about the bar the change must clear. "The model wrote it" is never a reason to skip review; if anything it is a reason not to.

4. Debugging and Operational Enablement

This objective overlaps Lab 7's diagnosis-and-optimization material, so keep it short and cross-reference: the how of isolating a fault (the ablation ladder, distinguishing a retrieval regression from a prompt regression) lives there. The half that belongs to Domain 7 is enablement: the architect's job is to make the on-call engineer's first ten minutes deterministic rather than heroic.

You do that by shipping the pieces before the incident, not during it:

• A runbook (Lab 9) so the responder follows a path instead of inventing one at 3 a.m.
• Structured traces keyed by request_id (Lab 5) so any failure can be pulled up by its identifier and reported to Anthropic without guesswork.
• A reproducible failing case (the input, the trace, the observed output), because a bug you can replay is a bug you can fix.
• The ablation ladder (Lab 7) so the responder localizes the regression instead of changing four things at once.

None of this is about the model being clever in the moment. It is about the architect having made the moment boring in advance.

5. Environment Configuration for Teams

Secrets are the part of team configuration where a mistake is expensive, and the rule is absolute: secrets never live in CLAUDE.md, never in prompts, and never in the repository. They come from environment variables or a secret manager. A key committed to a context file is a key leaked to everyone who clones and everyone in the model's context.

The subtle exam point is credential resolution order. The SDK resolves credentials in a fixed sequence, first match wins:

6. Design Exercise

Objective: onboard a twelve-engineer team onto Claude Code in a regulated codebase, and produce the configuration a new hire inherits on their first clone. About 40 minutes; this domain does not warrant more.

Scenario. A fintech team of twelve is adopting Claude Code across a Python monorepo under regulatory scope. Denials of a customer action must be attributable to a named human. The codebase has a migrations/ directory that must never be edited without review, a mandatory linter, and a hard rule that no secret ever reaches a commit. You are the architect setting the team up.

1. Write the project CLAUDE.md outline. List the sections and one line each: build/test commands, the architecture invariants (including the named-human-on-denial rule), conventions, and the "never" list. State explicitly what you are keeping out, and why secrets and long prose are not in it.
2. Sort the controls: hook or prompt? For each of (run the linter before commit, block edits to migrations/, scan for secrets before any write, prefer small functions), decide whether it is a hook / deny rule (must always hold) or an instruction in CLAUDE.md (guidance). Justify each with one sentence. The regulator's rule is the tell for at least one of them.
3. Split committed vs. local settings. What goes in .claude/settings.json (shared, in git) versus .claude/settings.local.json (personal, gitignored)? Put the allow/deny list and the hooks in the right place, and name one thing that belongs only in an individual's local file.
4. Define the code-review policy for AI-assisted changes. Write the rule in one or two sentences. It must cover the review requirement, provenance, and the principle that generated code clears the same bar as any other change. Do not let "the model wrote it" appear anywhere as an exemption.
5. Specify the CI step. Describe the headless Claude Code invocation that runs in the pipeline, what it checks, where its credentials come from, and why running it in CI (rather than trusting each engineer to run it locally) is the enforcement point.
6. State the one control the regulator makes non-optional, and show where it is enforced. If your answer is "an instruction in CLAUDE.md," revise it: a regulated constraint is a hook, a deny rule, or an egress gate, not a request.

Step 2 is the one the exam tests. Step 6 is the one an auditor tests.

Key Takeaways

• Domain 7 is the smallest domain: 7%, about four questions. Learn the distinctions, answer the scenarios, and spend your saved hours on the heavier domains.
• The project CLAUDE.md and .claude/settings.json are the team's shared context and policy, committed to version control. Personal preferences and settings.local.json are not.
• Secrets belong in CLAUDE.md, prompts, and the repo never: only in environment variables or a secret manager.
• Hooks enforce; prompts request. A control that must always hold is a hook or a deny rule, never an instruction in a context file.
• Permissions apply Lab 5's principle to the developer's machine: remove the capability rather than trusting a prompt not to use it.
• Tool Runner (in the anthropic SDK) loops over your own tools, harness-only, self-hosted. The Claude Agent SDK is a separate package: Claude Code as a library with built-in tools, harness-only, self-hosted. Managed Agents supplies the harness and the hosted sandbox. Don't confuse the first two.
• Generated code is reviewed like any other code: review requirement, provenance, same bar. "The model wrote it" is never an exemption.
• An unset ANTHROPIC_API_KEY does not mean no credentials: the SDK falls through API key → auth token → OAuth profile → Workload Identity Federation, first match wins.