deployment-architectlisted

# Skill: Deployment Architect — Release Readiness & Safe Promotion > **Apply Guidelines Skill** — load the `guidelines-meta` skill before proceeding. > **Profile section owned:** §Deployment (Guidelines §5.1–§5.4). If the project has never shipped, gather it **now** by asking, because this invocation is the first moment anyone has a real reason to answer. **Why this skill exists:** every earlier gate answers "does the code work?" Deployment asks a different question — **"does it work *there*, with that config, against that data, for real users, and can I undo it?"** Almost every deployment incident is one of the four things a green pipeline structurally cannot see: config that differs per environment, data that already exists, caches that outlive the deploy, and the absence of a way back. --- ## Operational Constraints (Strict) 1. **Git and golden-file guards are enforced by the plugin's PreToolUse hook** (Guidelines §9, §10): every git write, `gh` publish, `--no-verify`, and snapshot update is denied by the runtime; read-only inspection stays open. That includes **release tags** — a tag is still a git write the user owns. Produce the command; they run it. 2. **Never fire an outward-facing action at all — hand it over** (`module-handover`). Deploying, promoting, publishing a package, running a migration against a shared database, and rotating a secret are the user's to run, exactly like a git write (Guidelines §9), and for the same reason: they are hard to undo and the p