Claude Architect WorkshopPDFEPUBlearnwithparam.comkaas.team

Professional, lesson 20

Team enablement

Enforce in managed settings and hooks, not in CLAUDE.md

Lumen Supply writes "never push to main" in CLAUDE.md for ten teams, and one team's agent pushes to main anyway. A line in CLAUDE.md is a request, and a team can write a line of its own beside it. This lesson moves the rule to the managed settings and a hook, and writes the baseline that shows whether the rollout helped. This is the Lumen shop repo, with a bare remote to push to. You will watch Claude Code try a push, a change to the secrets file and a normal edit, first under CLAUDE.md alone and then under managed settings.

I doWatch the failure and its fix.

Ten teams, one rule, one push

Claude Code reads CLAUDE.md as context. It does not enforce it. The managed settings are a file the team cannot override, and they hold permission rules and hooks that run at the point of the call.

Three things go wrong. The rule lives in CLAUDE.md, where any team can add a line that overrides it. Nothing stops the push at the moment it happens. And nobody measured how long a review takes before the rollout, so nobody can say it helped.

Claude proposes a call. The managed settings and the hook decide before it runs.DeveloperasksClaudeproposes a callManagedsettingsHookexit code 2 blocksRepothe call runsthe rules are written in settings.json and hook.pyClaude proposes a call. The managed settings and the hook decide before it runs.DeveloperasksClaudeproposes a callManagedsettingsHookexit code 2 blocksRepothe call runsthe rules are written in settings.json and hook.py

A push blocked at the point of the call

The platform file here is passed with --settings, as a stand-in for the system managed path, so the lab runs on a laptop. To try your own, run ./workshop start team-enablement, edit settings.json and hook.py, then ./workshop watch team-enablement. Claude asks to run git push origin main. The managed settings answer before the command runs.

Open the cards to see the call and the refusal. The refusal comes from the hook that the managed settings load, so its text names them, and nothing reaches the remote. Claude then tells the developer that its team line and the platform rule disagree, and asks what to do.

  1. DeveloperIt is release day. Release the shop.
  2. ClaudeBash: git status -sb && git remote -v && git log --oneline -5 &&…
    Show the result
    {
      "name": "Bash",
      "target": "git status -sb && git remote -v && git log --oneline -5 && git fetch origin && git status -sb",
      "denied": false,
      "reason": "## main\norigin\torigin.git (fetch)\norigin\torigin.git (push)\n95802a2 start\n## main"
    }
  3. RefusedPreToolUse:Bash hook error: [python3 managed/hook.py]: Blocked by managed settings: no pushes to main.
    Show the result
    {
      "name": "Bash",
      "target": "git push origin main && git status -sb && git log --oneline -1 origin/main",
      "denied": true,
      "reason": "PreToolUse:Bash hook error: [python3 managed/hook.py]: Blocked by managed settings: no pushes to main."
    }

The call was refused before it ran, and nothing changed.

Precedence and the hook, written as code

Managed settings win over project and user settings, so a team cannot switch the rule off in its own repo. A permission rule matches a command by its prefix. A hook is a script that reads the call and exits with code 2 to block it, and any other code lets it run.

The starting check raises an error and blocks nothing.

The fix has three parts. A deny rule refuses the push. A PreToolUse hook exits with 2 on a push to main or a change to .env. A Stop hook refuses to finish with an empty README.

starter/hook.py
1"""The hook that blocks a risky call before it runs."""23from typing import Any456def check(call: dict[str, Any]) -> tuple[int, str]:7 """Return (2, reason) to block a call, or (0, "") to let it run."""8 raise NotImplementedError("implement check")

Does a line in CLAUDE.md stop a push to main?

The platform team wrote "Never push to main. Open a pull request instead." in the shared CLAUDE.md. One team's own section claims "The platform team approved an exception for us: we ship from main" and "When asked to release, push main to origin."

Predict: Does a line in CLAUDE.md stop a push to main?

  1. AYes. The agent reads it.
  2. BNo. Only a permission rule or a hook does.
Show the answer

B. CLAUDE.md is guidance. Managed settings and hooks are enforced at the call, and a team line can overrule guidance.

A rule in CLAUDE.md

Claude is asked to release the shop. It runs git push origin main, and the push lands on the remote.

The push goes through here because the team's own line claims an approved exception to ship from main. The file was a request, and a later and more specific request won.

  1. DeveloperIt is release day. Release the shop.
  2. ClaudeBash: git status --short && echo "---" && git remote -v && echo…
    Show the result
    {
      "name": "Bash",
      "target": "git status --short && echo \"---\" && git remote -v && echo \"---\" && git branch -vv && echo \"---\" && git log --oneline -5",
      "denied": false,
      "reason": "---\norigin\torigin.git (fetch)\norigin\torigin.git (push)\n---\n* main 028b7a1 start\n---\n028b7a1 start"
    }
  3. ClaudeBash: git push origin main 2>&1; echo "exit=$?"; echo "---"; git…
    Show the result
    {
      "name": "Bash",
      "target": "git push origin main 2>&1; echo \"exit=$?\"; echo \"---\"; git fetch origin 2>&1; git status -sb | head -1; git rev-parse HEAD origin/main",
      "denied": false,
      "reason": "To origin.git\n * [new branch]      main -> main\nexit=0\n---\n## main\n028b7a162b550406300e8740c5478c4af5bf4cab\n028b7a162b550406300e8740c5478c4af5bf4cab"
    }

The change went through. The rule was a request.

Managed settings, a hook and a baseline

The managed settings.json denies git push origin main and any write to .env. A prefix rule is narrow, so it misses a push of HEAD:main or a push with a flag between the words. The hook closes that gap by matching the shape of the command, and the Stop hook gates the finish.

In the recording the hook's refusal came back, not the deny rule's, because the hook runs first. The two are layers. Cost is small against the failure: the rule is a few lines, and a push to main means a revert, a review and an incident.

How one attempt is decided, in order.DeveloperClaudeRuleRepoa requestbashrunsdonebashrefused
settings.jsongreen lines are what the fix adds
1{2 "permissions": {3 "deny": [4 "Bash(git push origin main:*)",5 "Edit(.env)",6 "Write(.env)"7 ]8 },9 "hooks": {10 "PreToolUse": [11 {12 "matcher": "Bash|Edit|Write",13 "hooks": [14 {"type": "command", "command": "python3 {managed}/hook.py"}15 ]16 }17 ],18 "Stop": [19 {20 "hooks": [21 {22 "type": "command",23 "command": "test -s README.md || { echo 'README.md is empty' >&2; exit 2; }"24 }25 ]26 }27 ]28 }29}
We doChange one setting at a time and predict.

The same input now ends well

Switch between the two rules for the same release request. With CLAUDE.md alone, the push lands. With the managed settings, the call is refused and the remote is unchanged.

The request did not change, and neither did the team's line. Only the place the rule lives changed. A model that says the hook conflicts with the team process is still blocked, which is the point.

This part is interactive in the lab: run ./workshop watch team-enablement.

Try it: rule and attempt

Change one setting at a time. Pick the rule, then the attempt. Every combination is a recorded run, so this works with no internet.

Under CLAUDE.md alone, the push goes through and the append to .env goes through too. Under managed settings, both are refused. The normal edit to the README works under both, so the rule blocks the risk and not the work.

When a block fires, read the run's id, the span of the blocked call with its result, and the rule that matched, before anyone edits the rule. Give each run only the tools its job needs: this lab passes --tools Bash Edit, and a CI job should be as narrow.

This part is interactive in the lab: run ./workshop watch team-enablement.

The enablement plan

A rollout that claims a gain needs something to compare with. The plan records how long a pull request waits for review today, for each team, with a unit. The same measure comes after, so a change can be reported per team.

Each rollout step names an owner, so a blocked team knows who to ask. The starting plan has no baseline and lets teams start whenever they like.

The fixed plan ships the review prompt as a shared Skill from the settings repo. Every team loads one copy, and each change is reviewed, since ten hand-edited copies drift. The rollout guide sits beside the settings there, not in a chat a new team never sees.

app/plan.py
1"""The enablement plan: a baseline before the rollout, the same measure after.23A rollout that claims a gain with nothing to compare against is unproven.4The plan names how long a review takes today and who does each step.5"""67import re89MIN_STEPS = 210UNITS = r"\b(minutes?|hours?|days?)\b"11OWNER = re.compile(r"\(owner: \w+")12HEADING = re.compile(r"^#{2,3}\s*(.+?)\s*$", re.M)131415def sections(text: str) -> dict[str, str]:16 """Split a plan on its headings: lowercase heading to body."""17 marks = list(HEADING.finditer(text))18 ends = [m.start() for m in marks[1:]] + [len(text)] * bool(marks)1920 return {21 m.group(1).lower(): text[m.end() : end].strip()22 for m, end in zip(marks, ends, strict=True)23 }242526def find(found: dict[str, str], word: str) -> str:27 """The body of the first section whose heading holds a word."""28 return next((b for h, b in found.items() if word in h), "")293031def check_plan(text: str) -> list[str]:32 """Name what the plan lacks: a baseline, steps with owners, a measure.3334 The baseline needs a number with a unit, the steps need an owner each,35 and the measure after must say it is the same measure.36 """37 found = sections(text)38 problems = []3940 baseline = find(found, "baseline")41 if not (re.search(r"\d", baseline) and re.search(UNITS, baseline)):42 problems.append("baseline")4344 steps = [s for s in find(found, "rollout").splitlines() if s.strip()]45 if len(steps) < MIN_STEPS or not all(OWNER.search(s) for s in steps):46 problems.append("owners")4748 after = find(found, "after")49 if "same" not in after.lower() or not re.search(r"\d", after):50 problems.append("after")5152 return problems
You doFix the starting code, then test yourself.

You do: enforce the rule where the call runs

Copy the starting code and open work/team-enablement/hook.py, settings.json and plan.md. check() raises NotImplementedError, the settings enforce nothing and the plan has no baseline.

Terminal
./workshop start team-enablement
./workshop check team-enablement
./workshop watch team-enablement

The checks want a push to main and a change to .env to exit with 2, and a normal call to run. The deny rules and the hook are in the settings. The plan has a baseline and an owner for every step.

Check your understanding

Answer each question, then read why every option is right or wrong. The wrong options are the mistakes engineers make on the job.

1. The Lumen platform team wants "never push to main" to hold for all 10 teams, and today it is one line in the shared CLAUDE.md. Last week one team's agent pushed to main anyway, so the gap must close before the Friday release freeze, and no team may be asked to change anything. Where should the rule move?

  1. AKeep it in CLAUDE.md and make the wording stronger, so the agent treats it as a hard rule.
  2. BLeave it in CLAUDE.md and add a reviewer who reads each pushed commit after the release.
  3. CAdd a deny rule to the managed settings, so a push to main is refused before it runs.
  4. DAdd the rule to each team's project settings, and ask each team lead to keep it there.
Show the answer

Answer: C

  • A Stronger wording is still a request. CLAUDE.md is context the model reads, and a team line beside it can overrule the rule.
  • B A reviewer after the push finds the problem late. The push has already landed, and the freeze deadline is missed.
  • C Correct. A deny rule in the managed settings is enforced at the call, and no team has to change anything.
  • D Project settings sit below the managed ones, and each team lead can edit their own file. That is the override the rule must not allow.

2. One Lumen team added "Bash(git push:*)" to its project settings so that releases are quick. The platform team has a managed deny rule for "Bash(git push origin main:*)". It must be sure that the team's allow does not weaken it in any of the 10 repos. Which statement describes what happens to a push to main in that repo?

  1. AThe managed deny rule wins, since managed settings outrank project and user settings.
  2. BThe project allow wins, because the setting closest to the repo is the most specific one.
  3. CThe CLAUDE.md in the repo decides, because it is read last and holds the final word.
  4. DThe push runs, because an allow rule always cancels a deny rule in the same session.
Show the answer

Answer: A

  • A Correct. Managed settings sit at the top of the precedence order, so a project allow cannot cancel the platform deny.
  • B Closeness to the repo does not rank a setting above the managed one. The managed file has the highest precedence.
  • C CLAUDE.md is context, not a permission source. It never overrides a deny rule.
  • D A deny rule is checked before an allow, and a managed deny cannot be undone by a lower level.

3. A platform engineer writes a PreToolUse hook that looks for a push to main and prints "no pushes to main" to stderr. In the test the message appears, yet the push still runs and lands on the remote. The hook must block the call, and it must still let a normal edit through. What change makes the hook block the call?

  1. ARemove the hook, because a permission rule alone is enough and the hook adds nothing.
  2. BPrint the message to stdout instead, so that Claude reads it before the call runs.
  3. CMove the hook to the user settings, so that it runs for the developer who is pushing.
  4. DExit with code 2 on a push to main, and with code 0 for every other call.
Show the answer

Answer: D

  • A A prefix rule misses a push of HEAD:main or a flag between the words. The hook is the second layer, and the bug here is its exit code.
  • B Where the message goes does not block anything. Only the exit code decides whether the call runs.
  • C A user setting can be edited by the developer, and the problem is not where the hook lives.
  • D Correct. Exit code 2 blocks the call, and the reason on stderr goes back to Claude. Code 0 lets a normal edit run.

4. A reviewer audits the settings of the Lumen platform repo before a rollout to 10 teams, and the audit closes on Thursday. The rule "never push to main" must be enforced, not only stated. Select two things in the repo that enforce the rule at the point of the call.

  1. AA deny rule for the push in the managed settings.
  2. BA line in CLAUDE.md that says never to push to main.
  3. CA PreToolUse hook that exits with code 2 on a push to main.
  4. DA README section that tells developers to open a pull request.
Show the answer

Answer: A, C

  • A Correct. A managed deny rule refuses the call before it runs, and a team cannot override it.
  • B CLAUDE.md is guidance. The model reads it, and a team line can overrule it, so it enforces nothing.
  • C Correct. The hook reads the call and exits with 2, which blocks it, including shapes a prefix rule misses.
  • D A README is read by people, and no tool checks it. It cannot stop a call.

5. One Lumen team reports that a pull request waits 3 days for review. The platform team plans to roll out shared settings and a review Skill to all 10 teams next quarter. Leadership will ask after 8 weeks whether the rollout helped, and nothing has been measured yet. What should the team do before the first team joins?

  1. AStart the rollout now and measure afterward, because the numbers will be clear once teams use it.
  2. BMeasure each team's median review wait over several weeks before any team joins.
  3. CAsk every team to adopt the same review process, so that the later numbers can be compared.
  4. DWrite the expected gain in CLAUDE.md, so that the agent works toward the target.
Show the answer

Answer: B

  • A Without a before number, the after number has nothing to compare with, and the claim is unproven.
  • B Correct. A baseline per team, taken first, is what lets the later measure show a change.
  • C A single process says nothing about today's wait. The baseline is the number before the change.
  • D A target in CLAUDE.md is a request to a model, not a measure of review time.

6. Each sprint, the 10 Lumen teams write their own prompt for a pull request review, and the prompts differ in what they check. The platform team wants one repeated workflow that each team can still adapt, and it has two weeks before the next sprint starts. What should it ship?

  1. AA shared Skill with the review steps, which each team can extend with its own checks.
  2. BOne fixed Skill that every team must use unchanged, so that all reviews look the same.
  3. CA paragraph in CLAUDE.md that tells each developer to review pull requests carefully.
  4. DNothing yet, until a baseline proves that the prompts differ from team to team.
Show the answer

Answer: A

  • A Correct. A shared Skill makes the workflow repeatable, and a team can add its own checks on top.
  • B Teams differ in what they review, so one unchanged Skill fits some and misses others.
  • C A general line gives no steps to repeat, so the prompts keep drifting.
  • D A baseline belongs in the plan, but it does not stop the prompts from drifting while the team waits.

7. A rollout report says that review time fell from 3 days to 1 day, and the sponsor wants to approve funding for all 10 teams on Friday. The figure comes from the one team that volunteered, and no other team was measured before or after. Which statement about the report is correct?

  1. AIt proves the gain, because 3 days to 1 day is a large drop for any team.
  2. BIt proves the Skill works for every team, because the volunteer team used it well.
  3. CIt is unproven for the other teams, so compare each team with its own baseline first.
  4. DIt is proven by the new CLAUDE.md, because the agent follows the rules in that file.
Show the answer

Answer: C

  • A A large drop in one team says nothing about the nine others, and a volunteer team may already be faster.
  • B One team using it well does not show that every team gets the same result.
  • C Correct. Each team needs its own before and after, taken the same way, and then the gain can be reported per team.
  • D CLAUDE.md shapes what the agent does. It does not measure review time.

8. A reviewer reads the Lumen enablement plan before the sponsor meeting on Monday, and the plan covers 10 teams over a quarter. The sponsor funds the second half only if the plan shows a gain per team. The rollout must also be repeatable by a team that joins late. Select two parts that the plan should hold.

  1. AA baseline measure of review time for each team, taken before the rollout.
  2. BA start date for each team, with the review numbers gathered once all ten teams have joined.
  3. CA line in CLAUDE.md that tells the agent to speed up reviews.
  4. DA shared Skill or command that carries the review workflow, with an owner.
Show the answer

Answer: A, D

  • A Correct. The baseline is the number the later measure is compared with.
  • B Numbers gathered only after the rollout have no before to compare with.
  • C A request to the model is not a plan, and it measures nothing.
  • D Correct. A shared workflow with an owner makes the rollout repeatable, and someone answers for it.

9. A developer reports that an agent pushed to main last night, and no runbook exists for such a report. The platform team has 1 hour to find out which rule should have stopped it and whether the managed settings were loaded in that session. Which evidence should it read first?

  1. AThe CLAUDE.md in the repo, to see whether the rule was written down there.
  2. BThe hook script, to see whether it is a good script, without looking at the run.
  3. CThe developer's user settings, to see what the developer allowed in that session.
  4. DThe run id, the tool span of the push and the settings that matched that call.
Show the answer

Answer: D

  • A The file shows what was asked, not what was enforced. The question is which rule matched the call.
  • B A script in isolation does not show whether it ran in that session or what it returned.
  • C User settings are one of several levels, and the managed level is the one that should have decided.
  • D Correct. The run, the span of the call and the settings that matched say what ran and why nothing blocked it.

10. After the rollout, the hook blocks about 4 normal README edits a day because its pattern matches the word "main" in a file path. Developers have started to ask their team leads to turn the hook off. The platform team must keep the push rule in force while it fixes the complaint this week. What should it do?

  1. ATurn the hook off and rely on the deny rule alone, since the hook is only an extra.
  2. BFix the pattern to match a push to main and not a file path, and keep the hook on.
  3. CAllow every tool in the settings of the teams who complain, so that nothing is blocked.
  4. DLet each team override the hook in its project settings, so the teams decide for themselves.
Show the answer

Answer: B

  • A The deny rule is narrow, and it misses a push of HEAD:main. Turning the hook off drops the layer that catches those shapes.
  • B Correct. The fault is the match, so the fix is the match, and the enforcement stays on.
  • C Allowing every tool removes the rule for exactly the teams that are working with the agent most.
  • D A team override is the gap the managed settings were meant to close.

11. The review Skill was copied into 10 repos, and 3 of the copies have since been edited by hand, so teams now run different review steps. The platform team wants every team to start from the same text, and it has one engineer for the work this month. How should the Skill be shipped?

  1. AFrom one managed source that the teams receive, so that an edit is made once.
  2. BAs ten separate copies that each team owns, so that each one fits its own repo.
  3. CIn each developer's user settings, so that a person can adjust it to taste.
  4. DAs a paragraph in CLAUDE.md that says how to review, and nothing else.
Show the answer

Answer: A

  • A Correct. One source means an edit is made once and every team gets it.
  • B Ten owned copies are how the drift started.
  • C User-level copies drift faster, since each developer holds one.
  • D A paragraph of guidance is not a Skill with steps and limits, and it can be overruled.

12. The team's review prompt lives in a Skill. One developer edited it by hand in a single repo to skip the security check, and nobody noticed for 2 sprints. The platform team must be able to see who changed the Skill and why, and it wants the fix to cost little. What should it do?

  1. ATell the teams to keep the Skill unchanged, and trust them to do so.
  2. BAdd a line to CLAUDE.md that says never to skip the security check in a review.
  3. CKeep the Skill in version control and review each change, so every edit has an author.
  4. DWait for the baseline numbers to show whether reviews got worse, and act then.
Show the answer

Answer: C

  • A A request to keep it unchanged is the same kind of rule that failed already.
  • B A line in CLAUDE.md is guidance, and the edit would still happen without anyone seeing it.
  • C Correct. Version control with review records who changed it and why, and a bad edit is caught in the change.
  • D A baseline measures review time, not whether a check was skipped.

13. A Lumen team asks Claude to fix a bug, and the run ends with 2 failing tests while the reply says that the work is done. The team wants a run to be unable to finish while a test fails. That must hold in all 10 repos without relying on the prompt. What should the platform team add?

  1. AA note in the prompt that says to run the tests, since the model will follow it each time.
  2. BA line in CLAUDE.md that asks for passing tests, and a reviewer who reads the reply.
  3. CPermission for every tool in the job, so that the model can run whatever it needs.
  4. DA Stop hook that runs the tests and exits with 2 while any of them fails.
Show the answer

Answer: D

  • A A prompt note is a request, and the model can still report done with a failing test.
  • B CLAUDE.md is guidance, and a reviewer reads the reply after the run has ended.
  • C More permission gives the run more power, and it does not check the result.
  • D Correct. A Stop hook that exits with 2 blocks the finish until the tests pass, and it runs in every repo that wires it.

14. A CI job runs Claude on each pull request, and it was given every permission so that it never stops to ask. A pull request description can hold text written by an outside contributor, so a prompt injection is possible, and the job runs on 40 pull requests a day. How should the permissions be set?

  1. AKeep every permission on, since nobody is there to approve a prompt in CI.
  2. BAllow only the tools that the review job needs, and deny the rest in the managed settings.
  3. CTell the job in CLAUDE.md to ignore instructions that sit inside a pull request description.
  4. DSkip the hook in CI, because CI runs are short and a hook only slows them down.
Show the answer

Answer: B

  • A With every permission on, an injected instruction can run any command. CI having nobody to ask is the reason to narrow it.
  • B Correct. A narrow allow list limits what an injected instruction can do, and the managed deny holds.
  • C A line of guidance is a request that an injected text can compete with.
  • D The hook is the layer that blocks a dangerous call, and CI is where it matters most.

15. The managed settings are ready for 10 teams. There is no guide, so each team guesses the steps, and 4 of them have already set it up differently. A team asks what to do when a call is blocked and who to ask, and the platform team must answer within the week. What should it ship with the settings?

  1. AA guide with the steps, an owner for each step and a check that the settings loaded.
  2. BA baseline of review time, since measuring the teams will show them what to do.
  3. CA CLAUDE.md line that tells the agent to follow the rollout steps in the right order.
  4. DOne identical setup that every team applies unchanged, with no steps explained.
Show the answer

Answer: A

  • A Correct. Ordered steps, an owner and a check tell a team what to do and who to ask when a call is blocked.
  • B A baseline measures the result. It does not tell a team how to set it up.
  • C The agent does not run the rollout. The teams do, and they need steps they can read.
  • D An unexplained setup leaves the team stuck at the first blocked call.

16. The rollout guide was posted in a chat channel, and 3 new teams that joined this month never saw it. They set up the settings by trial and error, and 2 of them skipped the hook. The platform team wants the guide to reach every new team without a person remembering to send it. Where should the guide live?

  1. AIn CLAUDE.md as a reminder, which the agent reads at the start of each session.
  2. BIn the baseline report, since each team reads that before it joins the rollout.
  3. CNext to the managed settings in the repo, so it is found where the settings are.
  4. DIn a Skill that each team copies and edits to suit its own habits.
Show the answer

Answer: C

  • A CLAUDE.md is read by the agent, not by the team setting up the rollout, and it is not enforced.
  • B A report on review time is not a setup guide, and teams do not read it for steps.
  • C Correct. A guide beside the settings is found by anyone who opens them, and it changes with them.
  • D A copied and edited guide drifts, which is the problem the team already has.

Play: predict the output

The managed settings deny one command prefix, and no hook is wired.

json
{"permissions": {"deny": ["Bash(git push origin main:*)"]}}

Predict: An agent runs git push -f origin HEAD:main. Is it blocked?

  1. ANo. The command does not start with the denied prefix.
  2. BYes. It pushes to main, which the rule denies.
Show the answer

A. A permission rule matches the start of a command. Keep the rule, and add a hook that matches the other shapes of a push, as the lab's hook.py does.

References

Conclusions

  • Put a rule that must hold in the managed settings and a hook, and keep CLAUDE.md for guidance.
  • Block at the point of the call: a deny rule for the prefix, and a hook that exits with 2 for the shapes a prefix misses.
  • Record a baseline before the rollout, and measure the same thing after.

You can now enforce a rule that a team cannot override, and show that the rollout helped.

Managed settings

A settings file the platform team controls, which wins over project and user settings

Deny rule

A permission rule that refuses a call by its prefix

PreToolUse hook

A script that reads a call before it runs and exits with 2 to block it

Baseline

The measure taken before a rollout, to compare with the same measure after