docs: add deployment operation skills

.agents/skills/deploy-production/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: deploy-production
+description: Deploy SHD.build main to production through Gitea Actions and verify the live application. Use for a production release or a failed production deployment.
+---
+
+# Deploy Production
+
+Production deploys from `main` through `Validate and deploy production`. The workflow builds the candidate while the current app remains online, stops only the SHD app and scheduler, creates a database backup, migrates, then health-checks the replacement.
+
+## Workflow
+
+1. Confirm that the commit passed `npm run check` and `npm run build`, then push it to `main` through `git@git.jb.codes:jb/shd.build.git`.
+2. Open the Gitea production workflow for that commit. Confirm `validate` and `deploy` both succeed.
+3. Verify `https://shd.build/api/health`. Confirm `ready` is true and the database check reports `ok`.
+4. When host access is required, use `ssh f302` and inspect `/opt/shd-build-production` with its `.env.deploy` and `compose.production.yml` files. Confirm the app is healthy and the scheduler is running.
+
+## Migration Failure
+
+1. Open the failed `Deploy production` log and identify the failing statement and target schema state.
+2. Do not patch the production database by hand. Fix the idempotent migration in source, validate it locally, commit it, and push a new commit.
+3. The next workflow deployment creates a new production backup before it retries the migration. Confirm the recovery deployment reaches a healthy app state.
+
+## Guardrails
+
+- Do not use `docker compose down --volumes` or delete production volumes.
+- Do not run a second manual deployment while a Gitea deployment is active.
+- Routine deployment preserves production data. Use `replace-production-database` only with explicit approval for a full clone.
+- Report the commit SHA, workflow result, production health response, and backup path from any migration attempt.