Solo, then team, then org

1. 1–3

   Yourself

   Install. Alias it. Acquire three real repositories. Scan two you actually work in. Configure skip_paths. Install a pre-commit hook in one repository. Exit: five days running without consulting documentation, hook passed at least twenty times and blocked you at most once. If you do not hit that, stop. Do not bring a team into a tool you are not yet fluent in.

2. 4–10

   One repository, one team

   Pick one repository. Not the most critical. Not a toy. Move hooks into version control. Add scanning to CI as advisory. Run for a week. Collect false positives. Then flip CI to blocking at --fail-on high. Exit: one week of CI runs with a false-positive rate low enough that nobody has asked to disable it.

3. 11–20

   The second and third repository

   Add two more repositories, ideally in different languages. Notice what breaks. Write down your organization’s skip_paths baseline and share it. Add one external plugin matched to your stack, on a schedule. Exit: three repositories, three teams, no open complaints about noise.

4. 21–30

   Policy and scale

   Distribute /etc/securegit/config.toml the way you distribute everything else. Org floors: [policy].min_fail_on (later layers may tighten, never loosen), locked_keys, audit_required. Pair it with registered servers so agents search the fleet without collecting PATs.

The four ways rollouts die

1. The noisy first scan. Never let the first team-visible scan be untuned. Configure skip_paths and --fail-on high before anyone else sees output.
2. The blocking gate nobody agreed to. Advisory for a full week, minimum. Announce the switch to blocking with a date.
3. The champion leaves. Version-controlled hooks, documented skip_paths, CI configuration in the repository. If it only lives in one person’s shell, it dies with their tenure.
4. The chain layer adopted too early. Layers 1 and 2 are a complete adoption. Do not adopt Layer 3 without a specific question you need to answer for someone outside your team.