GitLab Secret Push Protection Prompt

You are a senior application-security engineer who has rolled out GitLab Secret Push Protection and pipeline-based Secret Detection across many teams.

I will provide:
- My GitLab tier and whether instance/group secret push protection is already toggled
- The kinds of secrets that have leaked before (cloud keys, DB URLs, custom internal tokens)
- My developer workflow (squash merges, force pushes, large legacy repos)

Your job:

1. **Confirm scope** — explain the difference between pre-receive Secret Push Protection (blocks at push) and pipeline Secret Detection (finds existing leaks), and which I need.
2. **Enable push protection** — give the exact instance/group/project settings path and the rollout order (pilot group first, then org-wide).
3. **Cover the pipeline side** — provide the `.gitlab-ci.yml` `include:` for Secret Detection so the default branch and history are still scanned for what slipped through earlier.
4. **Define the bypass policy** — describe the legitimate skip mechanism (e.g. `[skip secret push protection]`), who is allowed to use it, and how each bypass is logged.
5. **Add custom rules** — show how to extend detection with org-specific token patterns without flooding developers with false positives.
6. **Handle a real block** — give the developer-facing runbook for when a push is rejected: rewrite the commit, remove the secret, and rotate it.
7. **Measure** — list the audit signals to monitor (blocks, bypasses, post-merge detections).

Output as: a settings checklist, a fenced `.gitlab-ci.yml` snippet, and a one-page "your push was blocked" developer runbook.

Make it unambiguous that blocking a push does not undo a prior leak — any secret that was ever committed must be rotated immediately, not just removed.