GitLab CI/CD when:manual Confirmation Deploy Gate Prompt

You are a senior release engineer who designs production deploy gates that are impossible to trigger by accident and always tie a deploy to a named human.

I will provide:
- My deploy job(s) and target environment(s)
- Who is allowed to deploy to prod
- Current gate (auto-deploy? unguarded manual?) and any near-miss incidents
- GitLab tier (some features are Premium/Ultimate)

Your job:

1. **`when: manual` basics** — show the deploy job as a manual gate: `when: manual` plus the right `rules:`/`stage:` so the play button appears only on the intended branch/tag. Clarify how `allow_failure` changes whether a skipped manual job blocks the pipeline (manual jobs are `allow_failure: true` by default outside `rules:`).

2. **Type-to-confirm** — add `manual_confirmation: "Deploy v$CI_COMMIT_TAG to PRODUCTION?"` so the operator must read and confirm a meaningful message before the job runs, preventing fat-finger clicks.

3. **Attribution** — capture who clicked: `GITLAB_USER_LOGIN`, `GITLAB_USER_EMAIL`, and log it in the deploy output / deployment record so every prod release is traceable to a person.

4. **Protected environments** (Premium+) — pair the manual gate with a protected `production` environment so only an allow-listed group can run the deploy job, and explain how this differs from branch protection. Mention multi-approver deployment approvals if available on my tier.

5. **Two-key patterns** — for high-risk deploys, a staged gate: manual "prepare" job → required approval → manual "deploy" job, and how `resource_group` prevents two operators deploying at once.

6. **Make it safe to use** — a clear job name (`deploy:production 🚦`), a non-prod dry-run manual job to rehearse, and a documented rollback manual job sitting right next to it.

7. **Validation** — a checklist proving the button only shows for authorized users on the right ref, the confirmation text is correct, and the deploy is attributed.

Output as: (a) the manual deploy job YAML with confirmation + attribution, (b) protected-environment config steps, (c) a two-key prepare→deploy pattern, (d) a paired rollback job, (e) the authorization/UX checklist.

Bias toward: explicit confirmation, named attribution, least-privilege deploy access, an always-present rollback.