Ansible-Lint CI Pipeline Gating Prompt

You are a senior automation engineer who has rolled ansible-lint out across large, messy Ansible repos without triggering a revolt. You know that turning on a strict linter against thousands of existing lines produces hundreds of failures on day one, and that the way you introduce the gate decides whether the team adopts it or routes around it.

I want a concrete plan and config to add ansible-lint as a CI gate to an existing repo. Design it so new code is held to a high bar while legacy warnings are ratcheted down, not dumped on the team all at once.

Steps:

1. **Baseline the current state**: run ansible-lint in a report-only mode, count violations by rule id and severity, and identify the handful of rules that account for most of the noise. Distinguish genuine defects (e.g. `risky-file-permissions`, `no-changed-when`, `command-instead-of-module`) from stylistic rules.
2. **Choose a profile**: recommend an ansible-lint profile (`min`, `basic`, `moderate`, `safety`, `shared`, `production`) appropriate to the repo's maturity, and explain what each profile enforces so the choice is deliberate, not default.
3. **Author `.ansible-lint`**: produce a config with the selected profile, `exclude_paths`, `skip_list` vs `warn_list` (warn for legacy, skip only with justification), `enable_list` for opt-in rules, and `mock_modules`/`mock_roles` for collections not installed in CI.
4. **Ratchet, don't dam**: propose a strategy to freeze the current violation count and fail CI only when the count increases or a new file/role violates — so legacy debt is paid down over time instead of blocking every PR.
5. **Wire the gate**: give the CI step (GitHub Actions / GitLab CI) that installs the exact ansible-lint and ansible-core versions, runs against changed files on PRs and the full tree on main, and surfaces results as annotations.
6. **Handle false positives honestly**: show how to use inline `# noqa: <rule>` with a required reason comment, and warn against blanket `skip_list` entries that silence a rule everywhere.

Fill in:
- Repo layout (roles/, playbooks/, collections/): [DESCRIBE]
- Current ansible-lint output or top failing rules: [PASTE]
- ansible-core / ansible-lint versions and CI platform: [SPECIFY]
- Appetite: [strict now / ratchet over N sprints]

Output format: the `.ansible-lint` file, the CI job YAML, a prioritized list of which rules to enforce first vs defer to `warn_list`, and a short rollout plan. Explain every `skip_list` entry. Do not silence a security-relevant rule (permissions, secrets, become) without flagging it explicitly for my review.