feat: the deploy rail's second half — promotion, rollback, and the Phase 9 skeletons

[MCKRUZ]

Closes part of #11 (the promotion/rollback half; the dependency axis is #11's other half, in the follow-on PR).

GOLD-STANDARD promised rollback plans (Phase 8) and incident runbooks (Phase 9). The kit shipped deploy-dev.yml, which reaches the development environment and stops.

What this adds

deploy-promote.yml across the core and both CI/CD packs. Manual trigger only. Two rules that were prose are now mechanical:

• It refuses to run against a target environment with no approver configured. Without that check, promotion beyond dev is silently automatic — the standard's most protected stop, absent, with nothing on screen to say so.
• It refuses to promote a build the source environment has never run. Otherwise an operator can send a green CI run straight to prod having skipped test, and the pipeline obliges.

The go/no-go is the platform's own approval mechanism (GitHub required reviewers, Azure DevOps environment checks) rather than logic in a workflow file — the client's security team can already audit it, and it can't be edited away without branch protection noticing.

Three closing-phase skeletons: ROLLBACK.md, ALERTS.md, INCIDENT-PLAYBOOK.md. Documents with reusable structure get one; records of an event don't, so the go/no-go record and drill log stay drafted from the real system.

ROLLBACK.md forces the question teams skip — what a rollback does not undo. Code reverts cleanly; a destructive migration or a published message does not, and the restored version may not understand the data it finds.

The platform split, deliberately

GitHub's environment: key creates a Deployment record queryable by environment name, so that pack asks the API. Azure records deployments against an environment ID behind a separate service area, so that pack has the deploy stamp deployed-<env> on the CI build and the promotion require it. Same governance rule, each realized in the idiom its platform makes reliable — which is what the two-axis pack model is for.

Coupling worth knowing: removing the tagging step from the Azure deploy-dev.yml makes dev a dead end — nothing becomes promotable. Called out in that pack's RAILS.md.

Drift fixed on the way in

Both pack copies of deploy-dev.yml still hard-failed every merge, having never received the DEPLOY_WIRED guard the core file gained. The pack copies are what clients actually install.

Test plan

• python scripts/check_standard.py — no drift (193 rooted paths, 81 enumerated components)
• python -m pytest scripts/tests -q — 46 passing
• All kit YAML parses; both pack manifests consistent with disk (declared / overlaid / present)

Not yet proven, and the standard is explicit that this is what counts: none of it has been made to fail on purpose. docs/the-rails.md §9 — a rail that has never failed safely has not been proven. The three new drills are in RAILS.md; the promotion gate and the skip-an-environment refusal both need exercising against a real repo.

Two things I could not verify and did not pretend to: whether GITHUB_TOKEN can read environment protection rules under every repo visibility, and the exact Azure REST api-version behaviour. Both fail closed with messages that distinguish "no gate configured" from "couldn't check", and both are flagged in-file as rehearsal-verified.

🤖 Generated with Claude Code