Domain 7 – Developer Productivity & Operational Enablement (7%)

• Configure Claude tools and environments for teams (Claude Code, shared skills, settings)
• Improve developer workflows with AI-assisted tooling
• Support debugging and operational issue resolution

CCAR-P Domain 7 · Task 7.1

What You Need to Know

One question sorts everything: does an element shape output the team collectively owns? If yes → shared and version-controlled. If no → personal.

Four Layers

1. Organisation-managed — policy individuals must not override (top of precedence)
2. Project-committed — team’s shared standard, reviewed in PRs, inherited on clone
3. Personal — preference that follows one developer
4. Local and uncommitted — machine-specific values that must never enter shared history

Restrictive rules compose: a denial at any layer cannot be undone elsewhere. A managed control is a floor, not a default.

Guidance Is Not Enforcement

• Instructions (CLAUDE.md etc.) shape behaviour but are not a hard enforcement layer
• Settings rules and lifecycle handlers (hooks) are enforced by the client regardless of what Claude decides
• If it must never happen → enforcement, not instruction

What Never Goes in a Shared Layer

• Secrets (committed = distributed to whole organisation and stays in history)
• Machine paths and sandbox endpoints
• Bloat — keep instruction files short and free of contradictions; package procedures as reusable workflows

Key Concept: Onboarding is the acceptance test. Whatever a new engineer inherits by cloning, untold, is the standard.

Exam Traps

• Writing a prohibition into the shared instruction file and treating the operation as prevented
• Offering an onboarding page/wiki/training as the answer to divergent setups
• Restricting the tooling to senior engineers, or requiring a human to retype every generated change
• Assuming a permission granted at one scope widens what another scope forbids

Practice Scenario

Four engineers form a new team in a payments monorepo. Two other teams already use AI-assisted tooling daily. They inherited nothing: each wrote a private description of the codebase and no two agree; one can publish to the internal registry with no review. What should the architect put in place?

Build Exercise: Write the Configuration Map for One Team (40 min)

CCAR-P Domain 7 · Task 7.2

What You Need to Know

Measure the Work, Not the Tooling

Outcome measures (properties of the work): cycle time, defect escape rate, review latency, time for a new joiner to make a safe change, incident time-to-resolution.

Adoption figures (how much the tooling was used): sessions per week, accept rate, share of merged changes containing assisted code.

Read adoption alongside engineering measures, never in place of them. Name the outcome measure and its baseline before the quarter starts.

Verifiability Decides What to Automate

Before automating, ask what checks the output cheaply (test suite, build, linter, fixture comparison). Without a check the agent can run, you become the verification loop. Work whose correctness only an experienced human can judge slowly is the worst candidate for automation — volume arrives faster than judgement absorbs it.

Packaging Turns a Habit Into a Capability

• Repeatable procedure → shared, version-controlled workflow anyone can invoke by name
• Recurring specialist task → defined role with its own instructions and restricted tools
• Recurring context need → shared project context

Outcome quality stops depending on who ran it; the gain survives a resignation.

Review Stays Independent; Humans Keep Merge Authority

Whatever produced a change still holds the assumptions it was written under. Review in a fresh context. Machine review adds a signal; a named human keeps merge authority. Scope independent review to correctness and stated requirements, not taste.

Autonomy Follows Reversibility

Bound what automation may execute; gate irreversible actions behind approval; protect important branches; let CI be the objective gate.

Exam Traps

• Reporting an adoption percentage / accept rate / satisfaction survey as the ROI
• Letting whatever produced a change review it, then recording the change as reviewed
• Pointing automation first at the work that hurts most when nothing checks its output cheaply
• Measuring the improvement honestly but leaving the procedures that produced it in individuals’ heads

Practice Scenario

Platform team is a quarter into AI-assisted tooling. Director asks whether it worked. Only figure held: 70% of merged changes contained assisted code. Two engineers have procedures that clearly help (migration tests; triaging production logs); neither has been written down. What should the architect do?

Build Exercise: Build the Workflow Inventory and Its Outcome Measure (35 min)

CCAR-P Domain 7 · Task 7.3

What You Need to Know

Read the Evidence First

When a production agent behaves unexpectedly, the first move is to read what happened: inputs, retrieved context, tool calls and results, outputs, versions in play.

Editing the agent’s instructions first is wrong for three stacked reasons: nothing yet implicates the instructions; the edit changes the system under investigation; the failing runs become unreproducible.

Containment ≠ Diagnosis

• Blast radius decides containment. Ongoing external effect (money moving, messages sent, records altered outside the team) → contain first, diagnose second.
• Internal and reversible degradation → the failing cases are the asset; a rollback spends them.
• Containment is not a diagnosis. A reverted system is quiet, not understood. Blanket containment also costs attribution.

Change History Narrows the Search

Most incidents are caused by a change. Correlate symptom onset against instruction versions, model versions, corpus refreshes, configuration changes, dependency/connector updates. When two changes land in the same window, test them one at a time (Domain 4’s one-variable rule).

The Agent Investigates; It Does Not Adjudicate

AI tooling shortens root-cause work (logs at volume, timeline reconstruction, correlation, reproduction, hypothesis generation). Its account of its own behaviour is a hypothesis — fluent, from the same context that produced the behaviour, with no privileged access to the cause. Confirm against the trace. One clean re-run does not clear a hypothesis under non-determinism.

Enablement Is Built Before the Incident

Traces that exist and are readable; pager-holder who can open them at 2am; rollback available to more than one person; runbook naming the first three moves; shared investigation tooling.

What the Incident Must Leave Behind

A fix at the failing layer, verified against the real case; a regression case; a runbook update; any access gap closed or recorded.

Exam Traps

• Rewriting the prompt/shared instructions as the first move
• Reverting several recent changes at once as a precaution, with no ongoing harm
• Accepting the agent’s account of its own behaviour as the root cause, or clearing a hypothesis on one clean re-run
• Closing the incident with a fix and nothing else, or planning an investigation that assumes access nobody has granted

Practice Scenario

Internal reporting agent has started skipping its source-verification step on a minority of nightly runs. Effect is internal; every affected report regenerated without loss. Two things landed this week: a model version bump and a rewrite of the shared project instructions. Nobody has opened a trace; asked about a failed run the agent gives a fluent account of why it judged the step unnecessary. Team wants to know today which of this week’s two updates caused the skip, before altering anything. What should the team do first?

Build Exercise: Write the Incident Page for One System (45 min)