@jetrabbits/agentic 0.0.1

package/areas/devops/ci-cd/workflows/onboard-repo.md

@@ -0,0 +1,73 @@
+---
+name: onboard-repo
+type: workflow
+trigger: /onboard-repo
+description: Set up CI/CD pipeline for a new repository — from zero to production-grade pipeline with quality gates and deployment automation.
+inputs:
+  - repo_name
+  - language/framework
+  - ci_platform (github-actions|gitlab-ci)
+  - deploy_target (kubernetes|vm)
+outputs:
+  - pipeline_config
+  - first_successful_run
+roles:
+  - devops-engineer
+  - developer
+execution:
+  initiator: developer
+related-rules:
+  - pipeline-standards.md
+  - quality-gates.md
+  - supply-chain-security.md
+uses-skills:
+  - github-actions-patterns
+  - gitlab-ci-patterns
+  - pipeline-security
+quality-gates:
+  - pipeline runs green on first PR
+  - all mandatory stages present
+  - no hardcoded secrets in pipeline config
+---
+
+## Steps
+
+### 1. Assess & Plan — `@devops-engineer`
+- **Actions:**
+  - Confirm language, build tool, test framework
+  - Identify external dependencies (registry, cloud, K8s cluster)
+  - Choose CI platform (GitHub Actions vs GitLab CI) based on repo location
+  - Identify secrets needed: registry creds, kubeconfig, cloud role
+- **Output:** pipeline design doc (stages, auth method, environments)
+- **Done when:** design approved by developer and team-lead
+
+### 2. Secrets & Environments Setup — `@devops-engineer`
+- **Actions:**
+  - Create OIDC cloud role (preferred) or minimal-privilege service account
+  - Configure CI secrets: registry login, kubeconfig (base64), vault token
+  - Create environment definitions (staging, production) with protection rules
+- **Done when:** secrets configured; OIDC trust policy in place
+
+### 3. Write Pipeline Config — `@devops-engineer`
+- **Actions:**
+  - Create `.github/workflows/ci.yml` or `.gitlab-ci.yml`
+  - Implement all mandatory stages (lint → test → build → scan → deploy)
+  - Add caching for dependencies (pip/npm/go modules)
+  - Add image signing (cosign) and SBOM generation
+  - Configure coverage reporting and test result upload
+- **Output:** pipeline config committed to feature branch
+- **Done when:** `yamllint` passes; no syntax errors
+
+### 4. First Run & Debug — `@devops-engineer` + `@developer`
+- **Actions:**
+  - Open PR to trigger pipeline
+  - Fix any failing stages (missing deps, wrong paths, auth issues)
+  - Verify each stage output matches expectations
+- **Done when:** all stages green on PR; deployment to staging succeeds
+
+### 5. Document — `@devops-engineer`
+- Write `docs/ci-cd.md`: stages, how to run locally, how to add a new secret
+- **Done when:** documentation committed
+
+## Exit
+Green pipeline + staging deploy + documentation = repo onboarded.

package/areas/devops/ci-cd/workflows/pipeline-debug.md

@@ -0,0 +1,66 @@
+---
+name: pipeline-debug
+type: workflow
+trigger: /pipeline-debug
+description: Diagnose and fix a failing CI/CD pipeline — from error classification to root cause and verified fix.
+inputs:
+  - pipeline_url_or_job_id
+  - error_description
+outputs:
+  - root_cause_summary
+  - pipeline_fix
+roles:
+  - devops-engineer
+execution:
+  initiator: developer
+related-rules:
+  - pipeline-standards.md
+uses-skills:
+  - github-actions-patterns
+  - gitlab-ci-patterns
+quality-gates:
+  - pipeline passes on fixed branch before merging fix
+---
+
+## Steps
+
+### 1. Classify Failure — `@devops-engineer`
+- Fetch full logs; identify failing stage and step
+- Categories: dependency install failure / test failure / auth failure / build failure / deploy timeout
+- Check: is this a flaky test or a real regression? (re-run once to distinguish)
+- **Done when:** failure mode and stage identified
+
+### 2. Diagnose by Category
+
+**Auth failure (registry, cloud, K8s):**
+- Check secret expiry / OIDC trust policy / runner network access
+- `kubectl auth can-i` / `aws sts get-caller-identity` in job debug step
+
+**Dependency install failure:**
+- Cache key stale? Lock file changed? Private registry down?
+- Add `--verbose` flag, check resolver output
+
+**Test failure:**
+- Run tests locally with same env vars
+- Check for env-dependent tests (timezone, locale, missing fixture)
+
+**Build/Docker failure:**
+- Check base image digest changed (pin to digest)
+- Layer cache invalidation causing unexpected rebuild
+
+**Deploy timeout:**
+- Check `helm status` / `kubectl rollout status` in target namespace
+- Look at pod events for the deployment being rolled out
+
+### 3. Fix & Verify — `@devops-engineer`
+- Apply fix on feature branch; push to trigger CI
+- Confirm the previously failing stage now passes
+- No unrelated regressions in other stages
+- **Done when:** full pipeline green on fix branch
+
+### 4. Merge & Monitor — `@devops-engineer`
+- Merge fix; confirm pipeline green on main
+- If flaky test: add to quarantine list; file follow-up ticket with `flaky-test` label
+
+## Exit
+Pipeline green + root cause documented in ticket = debug complete.

package/areas/devops/ci-cd/workflows/release-pipeline.md

@@ -0,0 +1,115 @@
+---
+name: release-pipeline
+type: workflow
+trigger: /release-pipeline
+description: Run a full production release — version tagging, changelog generation, image signing, staging validation, canary deploy to production.
+inputs:
+  - version (semver: v1.2.3)
+  - release_notes (optional)
+outputs:
+  - published_release
+  - deployed_version
+  - deployment_report
+roles:
+  - devops-engineer
+  - developer
+  - team-lead
+  - pm
+execution:
+  initiator: developer
+related-rules:
+  - pipeline-standards.md
+  - quality-gates.md
+  - supply-chain-security.md
+uses-skills:
+  - github-actions-patterns
+  - artifact-management
+  - pipeline-security
+quality-gates:
+  - all CI gates pass on release commit
+  - image signed and SBOM attached before deploy
+  - staging deploy healthy ≥ 15 min before production gate
+  - manual approval from team-lead for production
+---
+
+## Steps
+
+### 1. Pre-Release Checks — `@devops-engineer` + `@team-lead`
+- **Actions:**
+  - Confirm no active P0/P1 incidents
+  - Verify staging is healthy and running the release candidate
+  - Run final security scan on release image: `trivy image <image>:<version>`
+  - Check dependency review — no new Critical/High CVEs introduced
+  - Confirm changelog complete and reviewed
+- **Done when:** all checks green; team-lead approves release to proceed
+
+### 2. Tag Release — `@developer`
+- **Actions:**
+  ```bash
+  # Create annotated git tag
+  git tag -a v${VERSION} -m "Release v${VERSION}: ${RELEASE_NOTES}"
+  git push origin v${VERSION}
+  ```
+- **Output:** git tag triggers release pipeline in CI
+- **Done when:** CI pipeline starts on the tag event
+
+### 3. CI Release Pipeline (automated) — CI system
+- **Stages:**
+  1. `validate` — lint + test suite must pass on tagged commit
+  2. `build` — Docker image tagged with semver + SHA digest
+  3. `sign` — `cosign sign` + `syft` SBOM generation + `cosign attach sbom`
+  4. `scan` — Trivy image scan on the exact release image; block on Critical/High
+  5. `publish` — push to releases registry; create GitHub Release with changelog
+- **Done when:** CI pipeline green; release published to registry
+
+### 4. Deploy Staging — `@devops-engineer`
+```bash
+helm upgrade --install order-service charts/order-service \
+  --set image.tag=v${VERSION} \
+  --namespace staging \
+  --atomic --timeout 5m
+```
+- Monitor for 15 minutes: error rate, p99 latency, pod restarts
+- Run automated smoke test suite against staging
+- **Done when:** 15 min stable; smoke tests pass
+
+### 5. Production Gate — `@team-lead` (manual approval)
+- Review staging metrics: confirm no anomalies
+- Check error budget: confirm budget not exhausted
+- Approve in CI platform (GitHub Environment approval / GitLab manual job)
+- **Done when:** approval recorded
+
+### 6. Deploy Production (canary) — `@devops-engineer`
+```bash
+# Canary: 10% traffic to new version
+helm upgrade --install order-service charts/order-service \
+  --set image.tag=v${VERSION} \
+  --set canary.enabled=true \
+  --set canary.weight=10 \
+  --namespace production \
+  --atomic --timeout 5m
+
+# Watch for 5 minutes
+# If SLO breach → auto-rollback
+# If healthy → progress to 100%
+helm upgrade order-service charts/order-service \
+  --set image.tag=v${VERSION} \
+  --set canary.enabled=false \
+  --namespace production \
+  --atomic --timeout 5m
+```
+- **Done when:** 100% traffic on new version; no SLO breaches
+
+### 7. Post-Deploy Validation — `@qa` + `@pm`
+- Run production smoke tests
+- Verify key business metrics not degraded
+- Announce release in #deployments channel
+
+### Rollback (if needed at any step)
+```bash
+helm rollback order-service -n production
+# or: deploy previous version tag explicitly
+```
+
+## Exit
+Production 100% + smoke tests pass + team notified + deployment report = release complete.

package/areas/devops/database-ops/AGENTS.md

@@ -0,0 +1,47 @@
+# Database Operations — guidance index
+
+## What this area covers
+
+Operational database management: backup verification, performance tuning, migration safety, incident response, PostgreSQL and Redis operations. Focus is on production database reliability, not application-level ORM usage.
+
+## Guidance chain
+
+1. Project `.agent/` baseline
+2. `database-ops/rules/*` — load all
+3. `database-ops/skills/*/SKILL.md` — load only the skill matching the current task
+4. `database-ops/workflows/*` — load the workflow matching the triggered command
+
+## Cross-cutting constraints
+
+- **Backups are not optional** — every production database has a verified backup and a tested restore procedure.
+- **Migrations are backward-compatible** — no breaking schema change without a multi-step rollout plan.
+- **No production access without audit log** — all direct DB sessions in production are logged and justified.
+- **Verify before restore** — backup integrity is tested on a schedule; untested backups are treated as non-existent.
+
+## Spec map
+
+```text
+database-ops/
+├── rules/
+│   ├── backup-policy.md         ← frequency, retention, offsite requirements
+│   ├── access-control.md        ← least-privilege roles, audit logging, break-glass
+│   └── migration-runbook.md     ← pre/post checks, rollback gates, zero-downtime patterns
+├── skills/
+│   ├── backup-restore/SKILL.md       ← pg_dump, WAL archiving, PITR, restore drills
+│   ├── db-performance/SKILL.md       ← EXPLAIN ANALYZE, index design, vacuum, slow query
+│   ├── migration-safety/SKILL.md     ← expand/contract pattern, lock avoidance, online DDL
+│   ├── postgres-operations/SKILL.md  ← replication, failover, extensions, pg_stat_*
+│   └── redis-operations/SKILL.md     ← persistence modes, eviction, cluster, keyspace audit
+├── workflows/
+│   ├── backup-verify.md    ← /backup-verify
+│   └── db-incident.md      ← /db-incident
+└── prompts/
+    └── *.md
+```
+
+## Discovery patterns
+
+- `rules/*.md`
+- `skills/*/SKILL.md`
+- `workflows/*.md`
+- `prompts/*.md`

package/areas/devops/database-ops/prompts/backup-verify.md

@@ -0,0 +1,83 @@
+---
+workflow: backup-verify
+---
+
+# Prompt: `/backup-verify`
+
+Use when: verifying database backup integrity or practicing a PITR restore.
+
+---
+
+## Example 1 — Weekly backup verification (automated)
+
+**EN:**
+```
+/backup-verify
+
+Database: postgres-primary / Backup tool: pgBackRest / Stanza: main
+Task: weekly automated backup verification
+Steps:
+  1. Check backup catalog: pgbackrest --stanza=main info
+  2. Verify latest full backup age < 24h
+  3. Perform restore test to isolated postgres instance (restore-test pod in K8s)
+  4. After restore: run integrity queries (row counts on 5 critical tables vs production)
+  5. Report result to #ops-monitoring Slack channel
+  6. If any step fails → alert on-call immediately (P1)
+Expected runtime: < 30 min total
+```
+
+**RU:**
+```
+/backup-verify
+
+База данных: postgres-primary / Инструмент бэкапа: pgBackRest / Stanza: main
+Задача: еженедельная автоматизированная верификация бэкапа
+Шаги:
+  1. Проверить каталог бэкапов: pgbackrest --stanza=main info
+  2. Убедиться что возраст последнего полного бэкапа < 24ч
+  3. Выполнить тест восстановления в изолированный postgres instance (restore-test под в K8s)
+  4. После восстановления: проверочные запросы (количество строк в 5 критических таблицах vs production)
+  5. Отправить результат в Slack канал #ops-monitoring
+  6. Если любой шаг завершился неудачей → немедленный алерт on-call (P1)
+Ожидаемое время выполнения: < 30 мин
+```
+
+---
+
+## Example 2 — Emergency PITR after accidental DELETE
+
+**EN:**
+```
+/backup-verify
+
+Database: postgres-primary / DB: production_db
+Incident: developer accidentally ran "DELETE FROM payments WHERE status='pending'" at 14:33 UTC
+Deleted rows: ~12,000 payment records
+Recovery target: 14:32 UTC (1 min before deletion)
+Backup tool: pgBackRest / WAL archiving: enabled (to MinIO)
+Procedure needed:
+  1. Identify correct recovery target timestamp
+  2. Restore to isolated instance at 14:32:00 UTC (PITR)
+  3. Extract deleted rows: SELECT * FROM payments WHERE status='pending'
+  4. Re-insert into production (NOT full restore — use surgical row recovery)
+  5. Verify row count matches pre-deletion state
+  6. Document as incident; follow up with safer DB access controls
+```
+
+**RU:**
+```
+/backup-verify
+
+База данных: postgres-primary / БД: production_db
+Инцидент: разработчик случайно выполнил "DELETE FROM payments WHERE status='pending'" в 14:33 UTC
+Удалённые строки: ~12,000 записей платежей
+Цель восстановления: 14:32 UTC (за 1 мин до удаления)
+Инструмент: pgBackRest / WAL архивирование: включено (в MinIO)
+Необходимая процедура:
+  1. Определить правильную временную метку цели восстановления
+  2. Восстановить в изолированный instance в 14:32:00 UTC (PITR)
+  3. Извлечь удалённые строки: SELECT * FROM payments WHERE status='pending'
+  4. Повторно вставить в production (НЕ полное восстановление — хирургическое восстановление строк)
+  5. Убедиться что количество строк соответствует состоянию до удаления
+  6. Задокументировать как инцидент; устранить более безопасные контроли доступа к БД
+```

package/areas/devops/database-ops/prompts/db-incident.md

@@ -0,0 +1,127 @@
+---
+workflow: db-incident
+---
+
+# Prompt: `/db-incident`
+
+Use when: responding to a production database incident or high-risk operational change affecting performance, locks, or stateful data services.
+
+---
+
+## Example 1 — Identify and fix slow queries
+
+**EN:**
+```
+/db-incident
+
+Database: production_db / DB: order_db
+Symptom: order-service p99 latency increased from 80ms to 450ms 3 days ago
+Observation: CPU on postgres-primary up from 15% to 65% (Prometheus)
+Available: pg_stat_statements extension enabled
+Investigation:
+  1. Top-10 queries by total_time (pg_stat_statements, last reset: 3 days ago)
+  2. Check for: sequential scans on large tables, high rows_examined vs rows_returned ratio
+  3. EXPLAIN ANALYZE the top offender
+  4. Identify missing index (likely new query after code deploy)
+  5. Test index creation on staging first (measure latency improvement)
+  6. Apply CREATE INDEX CONCURRENTLY in production (verify no lock)
+Output: slow query + EXPLAIN output + CREATE INDEX CONCURRENTLY statement
+```
+
+**RU:**
+```
+/db-incident
+
+База данных: production_db / БД: order_db
+Симптом: p99 latency order-service вырос с 80мс до 450мс 3 дня назад
+Наблюдение: CPU на postgres-primary вырос с 15% до 65% (Prometheus)
+Доступно: расширение pg_stat_statements включено
+Расследование:
+  1. Топ-10 запросов по total_time (pg_stat_statements, последний сброс: 3 дня назад)
+  2. Проверить: sequential scans на больших таблицах, высокое отношение rows_examined к rows_returned
+  3. EXPLAIN ANALYZE для главного виновника
+  4. Определить отсутствующий индекс (вероятно новый запрос после деплоя кода)
+  5. Протестировать создание индекса на staging сначала (измерить улучшение latency)
+  6. Применить CREATE INDEX CONCURRENTLY в production (убедиться в отсутствии блокировки)
+Результат: медленный запрос + вывод EXPLAIN + оператор CREATE INDEX CONCURRENTLY
+```
+
+---
+
+## Example 2 — Safe migration: add non-null column to large table
+
+**EN:**
+```
+/db-incident
+
+Database: production_db / Table: orders (85M rows)
+Migration: add column processed_at TIMESTAMPTZ NOT NULL DEFAULT now()
+Problem: naive ALTER TABLE would lock 85M rows for minutes (unacceptable in production)
+Required approach:
+  1. Estimate lock duration on staging with production-size data first
+  2. Use safe sequence: ADD COLUMN (nullable, no default) → backfill in batches of 10k → ADD NOT NULL constraint
+  3. Backfill script: Python with batched UPDATE + commit every 10k rows + sleep 50ms between batches
+  4. Estimate total backfill time: 85M / 10k per batch × ~100ms per batch ≈ ?
+  5. Final constraint: ALTER TABLE orders ALTER COLUMN processed_at SET NOT NULL (fast, no backfill needed if no NULLs)
+  6. Rollback: DROP COLUMN processed_at (fast even on large table)
+Show: complete migration SQL + backfill Python script + timing estimate
+```
+
+**RU:**
+```
+/db-incident
+
+База данных: production_db / Таблица: orders (85М строк)
+Миграция: добавить столбец processed_at TIMESTAMPTZ NOT NULL DEFAULT now()
+Проблема: наивный ALTER TABLE заблокирует 85М строк на минуты (недопустимо в production)
+Необходимый подход:
+  1. Оценить продолжительность блокировки на staging с данными размером production сначала
+  2. Использовать безопасную последовательность: ADD COLUMN (nullable, без default) → backfill батчами по 10k → ADD NOT NULL constraint
+  3. Скрипт backfill: Python с батчевым UPDATE + коммит каждые 10k строк + sleep 50мс между батчами
+  4. Оценить общее время backfill: 85М / 10k на батч × ~100мс на батч ≈ ?
+  5. Финальный constraint: ALTER TABLE orders ALTER COLUMN processed_at SET NOT NULL (быстро, без backfill если нет NULL)
+  6. Откат: DROP COLUMN processed_at (быстро даже на большой таблице)
+Показать: полный SQL миграции + Python скрипт backfill + оценка времени
+```
+
+---
+
+## Example 3 — Redis memory pressure: eviction policy tuning
+
+**EN:**
+```
+/db-incident
+
+Redis setup: standalone Redis 7.2 (K8s StatefulSet), 2Gi maxmemory
+Symptom: Redis hitting maxmemory; evicting keys needed for active sessions (data loss)
+Current eviction policy: allkeys-lru (evicting ALL keys by LRU)
+Use cases in this Redis instance:
+  - User sessions (must not evict, TTL 24h)
+  - Rate limiting counters (can evict, TTL 60s)
+  - Cache of DB query results (can evict, TTL 5m)
+Solution needed:
+  1. Separate key namespaces: sessions:*, rate:*, cache:*
+  2. Change eviction to volatile-lru (only evict keys WITH TTL set)
+  3. Verify: sessions never have TTL (prevent eviction), cache/rate always have TTL
+  4. Add Redis memory monitoring: alert at 80% usage, 90% critical
+  5. Long term: split into 2 Redis instances (session store vs cache)
+```
+
+**RU:**
+```
+/db-incident
+
+Redis конфигурация: standalone Redis 7.2 (K8s StatefulSet), 2Gi maxmemory
+Симптом: Redis достигает maxmemory; вытесняет ключи нужные для активных сессий (потеря данных)
+Текущая политика вытеснения: allkeys-lru (вытесняет ВСЕ ключи по LRU)
+Use cases в этом Redis:
+  - Пользовательские сессии (нельзя вытеснять, TTL 24ч)
+  - Счётчики rate limiting (можно вытеснять, TTL 60с)
+  - Кэш результатов DB запросов (можно вытеснять, TTL 5м)
+Необходимое решение:
+  1. Разделить пространства имён ключей: sessions:*, rate:*, cache:*
+  2. Изменить вытеснение на volatile-lru (вытеснять только ключи С установленным TTL)
+  3. Убедиться: sessions никогда не имеют TTL (предотвращение вытеснения), cache/rate всегда имеют TTL
+  4. Добавить мониторинг памяти Redis: алерт при 80% использовании, critical при 90%
+  5. Долгосрочно: разделить на 2 Redis инстанса (session store vs cache)
+```

package/areas/devops/database-ops/rules/access-control.md

@@ -0,0 +1,20 @@
+# Rule: Database Access Control
+
+**Priority**: P0 — Database access follows least-privilege; no wildcard grants.
+
+## Role Separation
+
+| Role | Permissions | Who/what |
+|:---|:---|:---|
+| `app_<service>` | SELECT, INSERT, UPDATE, DELETE on owned tables | Application service |
+| `readonly_<service>` | SELECT only | Reporting, analytics, support |
+| `migration_<service>` | DDL (CREATE, ALTER, DROP) on owned schema | CI/CD migration runner (transient) |
+| `superuser` | ALL | DBAs only; MFA required; session-logged |
+
+## Rules
+
+1. **Application role never has DDL permissions** — migrations run as a separate migration role.
+2. **No shared passwords** — each service has its own credential in Vault/Secrets Manager.
+3. **Connection pooling required** — all apps connect via PgBouncer (transaction mode); no direct K8s pod → PostgreSQL.
+4. **Access log** — `pgaudit` extension enabled for all DDL and suspicious DML patterns.
+5. **Public schema dropped** — `DROP SCHEMA public; CREATE SCHEMA <service>` — no default public schema exposure.

package/areas/devops/database-ops/rules/backup-policy.md

@@ -0,0 +1,33 @@
+# Rule: Database Backup Policy
+
+**Priority**: P0 — Missing or unverified backups are a critical operational failure.
+
+## Backup Requirements
+
+1. **Continuous WAL archiving** — PostgreSQL WAL archived to object storage (S3/GCS/MinIO) for PITR.
+2. **Daily full snapshots** — in addition to WAL archiving; retained per schedule below.
+3. **Backup verification** — weekly restore test to isolated environment; result logged.
+4. **Backup encryption** — all backups encrypted at rest (AES-256 or KMS).
+
+## Retention Schedule
+
+| Backup type | Retention |
+|:---|:---|
+| Hourly (WAL) | 7 days |
+| Daily full | 30 days |
+| Weekly full | 3 months |
+| Monthly full | 1 year |
+| Pre-migration snapshot | Until next major release |
+
+## Recovery Objectives
+
+| Tier | RTO | RPO |
+|:---|:---|:---|
+| Tier 1 (revenue-critical) | 30 min | 15 min (PITR) |
+| Tier 2 (internal tools) | 4 hours | 1 hour |
+
+## Monitoring
+
+- Alert if no backup completed in last 26 hours.
+- Alert if backup size deviates > 20% from rolling average (data loss or corruption indicator).
+- Backup storage capacity alert at 70% full.

package/areas/devops/database-ops/rules/migration-runbook.md

@@ -0,0 +1,32 @@
+# Rule: Production Migration Safety
+
+**Priority**: P0 — Unsafe migrations cause data loss or production downtime.
+
+## Safe Migration Principles
+
+1. **Expand-and-Contract pattern** for breaking changes:
+   ```
+   Phase 1 (expand): add new column/table; old code still works
+   Phase 2 (dual-write): code writes to both old and new; read from new
+   Phase 3 (migrate): backfill data from old to new
+   Phase 4 (contract): remove old column/table; code reads only from new
+   ```
+   Never rename a column directly in production — use expand-and-contract.
+
+2. **Backward compatibility required** — migration must not break the current version of the app.
+   Running migration before deploy means old code still runs against new schema.
+
+3. **Test migration on staging with production-size data** — migration that takes 10s on 1K rows may take 30 min on 50M rows.
+
+4. **Pre-migration backup required** — snapshot before every production migration.
+
+5. **Lock-safe DDL** — prefer `CREATE INDEX CONCURRENTLY`; avoid `ALTER TABLE ... ADD COLUMN NOT NULL DEFAULT` on large tables (locks entire table).
+
+## Migration Checklist
+
+- [ ] Tested on staging with production row count (or estimated)
+- [ ] Estimated execution time documented (seconds / minutes / hours)
+- [ ] Pre-migration backup taken and verified
+- [ ] Rollback SQL prepared and tested
+- [ ] Maintenance window communicated if > 5 min impact
+- [ ] Connection pool configured to handle migration lock wait