7.1 — Team Tooling Configuration: Guidance Versus Enforcement

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