@jetrabbits/agentic 0.0.1

package/areas/software/platform/prompts/cost-audit.md

@@ -0,0 +1,117 @@
+---
+workflow: cost-audit
+---
+
+# Prompt: `/cost-audit`
+
+Use when: auditing cloud spend, finding waste, and producing an optimisation plan with ROI estimates.
+
+---
+
+## Example 1 — Monthly cost review
+
+**EN:**
+```
+/cost-audit
+
+Cloud: AWS (all services, eu-west-1 + us-east-1)
+Period: August 2024
+Current monthly spend: $18 400 (budget: $15 000 — 23% over)
+Data source: AWS Cost Explorer export (cost-explorer-aug-2024.csv attached)
+Top cost drivers (from Cost Explorer):
+  - EC2/EKS: $9 200 (50%)
+  - RDS: $3 100 (17%)
+  - Data transfer: $2 800 (15%)
+  - ElastiCache: $1 400 (8%)
+  - Other: $1 900 (10%)
+Focus areas: EC2 rightsizing, data transfer optimisation, identify idle/orphaned resources
+Output: cost-audit-aug-2024.md — waste findings, savings estimate per fix, effort level (easy/medium/hard)
+```
+
+**RU:**
+```
+/cost-audit
+
+Облако: AWS (все сервисы, eu-west-1 + us-east-1)
+Период: август 2024
+Текущие ежемесячные расходы: $18 400 (бюджет: $15 000 — превышение на 23%)
+Источник данных: экспорт AWS Cost Explorer (cost-explorer-aug-2024.csv приложен)
+Главные статьи затрат (из Cost Explorer):
+  - EC2/EKS: $9 200 (50%)
+  - RDS: $3 100 (17%)
+  - Передача данных: $2 800 (15%)
+  - ElastiCache: $1 400 (8%)
+  - Остальное: $1 900 (10%)
+Области фокуса: rightsizing EC2, оптимизация передачи данных, выявление простаивающих/заброшенных ресурсов
+Результат: cost-audit-aug-2024.md — находки по расточительству, оценка экономии на каждое исправление, уровень усилий (лёгкий/средний/тяжёлый)
+```
+
+---
+
+## Example 2 — Targeted EC2 rightsizing
+
+**EN:**
+```
+/cost-audit
+
+Scope: EC2 and EKS node groups only
+Environment: production + staging
+Data: AWS Compute Optimizer recommendations (export attached) + CloudWatch CPU/memory metrics (last 30 days)
+Current cluster: 3 × m5.2xlarge (8 vCPU, 32 GB) — avg CPU 18%, avg memory 34%
+Hypothesis: overprovisioned by 50%; could downsize to m5.xlarge (4 vCPU, 16 GB)
+Savings estimate: m5.2xlarge $0.384/hr → m5.xlarge $0.192/hr × 3 nodes × 720hr = $415/mo
+Risk: memory spikes during peak (check p99 memory); CPU burst capacity
+Output: rightsizing recommendation with p99 metrics evidence + migration plan (rolling node replacement)
+```
+
+**RU:**
+```
+/cost-audit
+
+Скоуп: только EC2 и EKS node groups
+Окружение: production + staging
+Данные: рекомендации AWS Compute Optimizer (экспорт приложен) + метрики CPU/memory CloudWatch (последние 30 дней)
+Текущий кластер: 3 × m5.2xlarge (8 vCPU, 32 GB) — средний CPU 18%, средняя память 34%
+Гипотеза: избыточное обеспечение на 50%; можно уменьшить до m5.xlarge (4 vCPU, 16 GB)
+Оценка экономии: m5.2xlarge $0.384/ч → m5.xlarge $0.192/ч × 3 узла × 720ч = $415/мес
+Риск: всплески памяти в часы пик (проверить p99 память); пиковая пропускная способность CPU
+Результат: рекомендация по rightsizing с доказательствами метрик p99 + план миграции (поочерёдная замена узлов)
+```
+
+---
+
+## Example 3 — Orphaned resources cleanup
+
+**EN:**
+```
+/cost-audit
+
+Scope: find and clean up orphaned/idle resources
+Cloud: AWS eu-west-1
+Check for:
+  - Unattached EBS volumes (> 7 days unattached)
+  - Unused Elastic IPs (not associated with running instance)
+  - Old snapshots (> 90 days, not referenced in Terraform)
+  - Stopped EC2 instances (> 14 days stopped, not scheduled)
+  - Empty/unused S3 buckets
+Tool: use AWS CLI + boto3 script to enumerate; cross-reference Terraform state
+Output: deletion candidate list with last-used date and monthly cost per resource
+Approval: list for human review before deletion — do not auto-delete
+```
+
+**RU:**
+```
+/cost-audit
+
+Скоуп: найти и очистить заброшенные/простаивающие ресурсы
+Облако: AWS eu-west-1
+Проверить:
+  - Не прикреплённые EBS тома (> 7 дней без прикрепления)
+  - Неиспользуемые Elastic IP (не связаны с работающим instance)
+  - Старые снапшоты (> 90 дней, не используются в Terraform)
+  - Остановленные EC2 instances (> 14 дней остановлены, не по расписанию)
+  - Пустые/неиспользуемые S3 bucket
+Инструмент: использовать AWS CLI + boto3 скрипт для перечисления; сверить с Terraform state
+Результат: список кандидатов на удаление с датой последнего использования и ежемесячной стоимостью за ресурс
+Одобрение: список для ручного ревью перед удалением — не удалять автоматически
+```

package/areas/software/platform/prompts/deploy-production.md

@@ -0,0 +1,109 @@
+---
+workflow: deploy-production
+---
+
+# Prompt: `/deploy-production`
+
+Use when: executing a production deployment with canary rollout, progressive traffic shifting, and automated rollback gates.
+
+---
+
+## Example 1 — Canary deploy with progressive rollout
+
+**EN:**
+```
+/deploy-production
+
+Service: order-service
+Version: v2.5.0 → v2.6.0
+Deployment strategy: canary → progressive (10% → 50% → 100%)
+Infrastructure: Kubernetes (EKS), ArgoCD for GitOps
+Image: ghcr.io/myorg/order-service:2.6.0 (digest: sha256:abc...)
+Pre-flight checks:
+  - All integration tests passing on staging
+  - DB migration alembic upgrade head — already applied (non-breaking)
+  - Dependent services: payment-service v1.9+ (compatible), notification-service (no change)
+Rollback trigger: error rate > 1% OR p99 > 2s sustained for 5 min at any canary stage
+Monitoring: Datadog dashboard "order-service canary" — open during deploy
+On-call engineer: @devops-lead (PagerDuty)
+```
+
+**RU:**
+```
+/deploy-production
+
+Сервис: order-service
+Версия: v2.5.0 → v2.6.0
+Стратегия деплоя: canary → progressive (10% → 50% → 100%)
+Инфраструктура: Kubernetes (EKS), ArgoCD для GitOps
+Образ: ghcr.io/myorg/order-service:2.6.0 (digest: sha256:abc...)
+Pre-flight проверки:
+  - Все integration тесты проходят на staging
+  - Миграция БД alembic upgrade head — уже применена (non-breaking)
+  - Зависимые сервисы: payment-service v1.9+ (совместимо), notification-service (без изменений)
+Триггер отката: error rate > 1% ИЛИ p99 > 2s в течение 5 мин на любом этапе canary
+Мониторинг: Datadog dashboard "order-service canary" — открыт во время деплоя
+Дежурный инженер: @devops-lead (PagerDuty)
+```
+
+---
+
+## Example 2 — Hotfix emergency deploy
+
+**EN:**
+```
+/deploy-production
+
+Service: payment-service
+Version: v3.1.1 (hotfix) — patches critical payment failure bug (INC-2024-142)
+Deployment strategy: full rollout immediately (skip canary — confirmed fix, low risk change)
+Justification: 3-line fix to null check; confirmed root cause; no schema changes
+Approvals obtained: CTO + Lead Engineer (Slack thread attached)
+Pre-deploy: smoke test against staging with fix deployed — PASSED
+Post-deploy validation:
+  - Monitor error rate on /api/v1/payments for 15 minutes
+  - Confirm incident INC-2024-142 resolved (check Sentry error count drops to 0)
+Rollback: revert to v3.1.0 image (available in registry) if validation fails
+```
+
+**RU:**
+```
+/deploy-production
+
+Сервис: payment-service
+Версия: v3.1.1 (hotfix) — исправляет критический баг сбоя платежей (INC-2024-142)
+Стратегия деплоя: полный rollout немедленно (пропустить canary — подтверждённое исправление, низкий риск)
+Обоснование: исправление 3 строк для null check; корневая причина подтверждена; нет изменений схемы
+Полученные одобрения: CTO + Lead Engineer (Slack тред приложен)
+Pre-deploy: smoke test на staging с применённым исправлением — ПРОЙДЕН
+Валидация после деплоя:
+  - Мониторить error rate на /api/v1/payments 15 минут
+  - Подтвердить разрешение инцидента INC-2024-142 (проверить снижение счётчика ошибок Sentry до 0)
+Откат: вернуться к образу v3.1.0 (доступен в registry) если валидация не пройдёт
+```
+
+---
+
+## Example 3 — Multi-service coordinated deploy
+
+**EN:**
+```
+/deploy-production
+
+Services: [user-service v2.1.0, auth-service v1.8.0] — must deploy together (breaking API contract change)
+Coordination: auth-service first (backward-compatible for 30 min window), then user-service
+Downtime window: none — both services must be live simultaneously during transition
+Validation: run auth integration test suite against prod after each service deploy
+Rollback order: user-service first, then auth-service (reverse deploy order)
+```
+
+**RU:**
+```
+/deploy-production
+
+Сервисы: [user-service v2.1.0, auth-service v1.8.0] — должны деплоиться вместе (breaking изменение API контракта)
+Координация: сначала auth-service (обратно-совместимый в течение 30-минутного окна), затем user-service
+Окно простоя: нет — оба сервиса должны работать одновременно в период перехода
+Валидация: запустить набор auth integration тестов против прода после деплоя каждого сервиса
+Порядок отката: сначала user-service, затем auth-service (обратный порядок деплоя)
+```

package/areas/software/platform/prompts/drift-check.md

@@ -0,0 +1,107 @@
+---
+workflow: drift-check
+---
+
+# Prompt: `/drift-check`
+
+Use when: detecting infrastructure drift — differences between IaC state and actual cloud resources — and deciding whether to remediate or update state.
+
+---
+
+## Example 1 — Scheduled drift audit
+
+**EN:**
+```
+/drift-check
+
+Environment: production (AWS eu-west-1)
+IaC tool: Terraform
+State location: s3://tf-state-myapp/envs/prod/terraform.tfstate
+Scope: full — all modules (network, compute, database, IAM, monitoring)
+Command: terraform plan -detailed-exitcode (exit 2 = drift detected)
+Expected drift (known manual changes to accept):
+  - RDS instance class bumped from db.t3.large to db.t3.xlarge last week (approved emergency change)
+  - CloudWatch alarm threshold on order-service-latency adjusted manually
+Classification needed:
+  - ACCEPT: expected/approved manual changes → update tfvars to match
+  - REMEDIATE: unauthorised changes → revert via terraform apply
+  - INVESTIGATE: unknown changes → escalate to security review
+Output: drift-report-2024-09-15.md with classified findings
+```
+
+**RU:**
+```
+/drift-check
+
+Окружение: production (AWS eu-west-1)
+Инструмент IaC: Terraform
+Расположение state: s3://tf-state-myapp/envs/prod/terraform.tfstate
+Скоуп: полный — все модули (network, compute, database, IAM, monitoring)
+Команда: terraform plan -detailed-exitcode (exit 2 = обнаружен drift)
+Ожидаемый drift (известные ручные изменения для принятия):
+  - Класс RDS instance повышен с db.t3.large до db.t3.xlarge на прошлой неделе (одобренное экстренное изменение)
+  - Порог CloudWatch alarm на order-service-latency скорректирован вручную
+Необходимая классификация:
+  - ПРИНЯТЬ: ожидаемые/одобренные ручные изменения → обновить tfvars чтобы соответствовало
+  - ИСПРАВИТЬ: несанкционированные изменения → откатить через terraform apply
+  - РАССЛЕДОВАТЬ: неизвестные изменения → эскалировать в security review
+Результат: drift-report-2024-09-15.md с классифицированными находками
+```
+
+---
+
+## Example 2 — Post-incident drift check
+
+**EN:**
+```
+/drift-check
+
+Trigger: post-incident INC-2024-088 — during incident response, engineer manually scaled EKS node group from 3 to 8 nodes; incident resolved but infra not reverted
+Environment: production EKS cluster (eu-west-1)
+Focus: EKS node groups, auto-scaling group desired counts
+Expected: node count in Terraform = 3; actual = 8
+Decision needed: scale back to 3 (traffic is back to normal) vs. update Terraform to 8 (if load justifies)
+Load check: CloudWatch — current CPU < 40% on 8 nodes (3 nodes would be fine)
+Action: scale back to 3 via Terraform, import new ASG config to state
+```
+
+**RU:**
+```
+/drift-check
+
+Триггер: post-incident INC-2024-088 — во время реагирования на инцидент инженер вручную масштабировал EKS node group с 3 до 8 узлов; инцидент разрешён но инфра не откачена
+Окружение: production EKS кластер (eu-west-1)
+Фокус: EKS node groups, желаемые количества auto-scaling group
+Ожидается: количество узлов в Terraform = 3; фактически = 8
+Необходимое решение: уменьшить до 3 (трафик вернулся к норме) или обновить Terraform до 8 (если нагрузка оправдывает)
+Проверка нагрузки: CloudWatch — текущий CPU < 40% на 8 узлах (3 узла было бы достаточно)
+Действие: уменьшить до 3 через Terraform, импортировать новую конфигурацию ASG в state
+```
+
+---
+
+## Example 3 — IAM permissions drift (security focus)
+
+**EN:**
+```
+/drift-check
+
+Scope: IAM only — detect permission creep in production AWS account
+Tool: terraform plan scoped to iam/ module + AWS Config rules
+Concern: 3 IAM roles had policies attached manually last month (not in Terraform)
+Detection: compare Terraform state IAM attachments vs. AWS IAM actual attached policies
+Risk classification: any admin-level policy attached outside Terraform = CRITICAL drift
+Output: list of unexpected IAM changes with attached policy names; immediate remediation for CRITICAL
+```
+
+**RU:**
+```
+/drift-check
+
+Скоуп: только IAM — обнаружить расширение прав в production AWS аккаунте
+Инструмент: terraform plan с ограничением модуля iam/ + правила AWS Config
+Озабоченность: к 3 IAM ролям были прикреплены политики вручную в прошлом месяце (не в Terraform)
+Обнаружение: сравнить прикрепления IAM в Terraform state с фактически прикреплёнными политиками AWS IAM
+Классификация рисков: любая политика уровня admin прикреплённая вне Terraform = КРИТИЧЕСКИЙ drift
+Результат: список неожиданных изменений IAM с именами прикреплённых политик; немедленное исправление для КРИТИЧЕСКИХ
+```

package/areas/software/platform/prompts/incident-response.md

@@ -0,0 +1,121 @@
+---
+workflow: incident-response
+---
+
+# Prompt: `/incident-response`
+
+Use when: a production incident is active — to coordinate triage, mitigation, communication, and postmortem.
+
+---
+
+## Example 1 — P1 service outage
+
+**EN:**
+```
+/incident-response
+
+Severity: P1 — complete service outage
+Affected: checkout flow (POST /api/v1/orders returns 503 for 100% of requests)
+Started: 14:32 UTC (23 minutes ago)
+Alert source: PagerDuty alert "order-service error rate 100%" + customer reports in Slack #support
+Initial observations:
+  - order-service pods restarting every 30 seconds (CrashLoopBackOff)
+  - Last deploy: order-service v2.6.1 — deployed 14:28 UTC (4 min before incident)
+  - DB: PostgreSQL healthy (no alerts), connection pool normal
+  - Error in logs: "FATAL: relation 'order_status_history' does not exist"
+Incident channel: #inc-2024-09-15-orders (already created)
+On-call: @alice (primary), @bob (secondary)
+Status page: needs update — "investigating checkout issues"
+```
+
+**RU:**
+```
+/incident-response
+
+Серьёзность: P1 — полный отказ сервиса
+Затронуто: поток оформления заказа (POST /api/v1/orders возвращает 503 для 100% запросов)
+Начало: 14:32 UTC (23 минуты назад)
+Источник алерта: PagerDuty алерт "order-service error rate 100%" + жалобы клиентов в Slack #support
+Начальные наблюдения:
+  - Поды order-service перезапускаются каждые 30 секунд (CrashLoopBackOff)
+  - Последний деплой: order-service v2.6.1 — задеплоен в 14:28 UTC (за 4 мин до инцидента)
+  - БД: PostgreSQL здоров (нет алертов), connection pool в норме
+  - Ошибка в логах: "FATAL: relation 'order_status_history' does not exist"
+Канал инцидента: #inc-2024-09-15-orders (уже создан)
+Дежурные: @alice (основной), @bob (вторичный)
+Status page: требует обновления — "расследуем проблемы с оформлением заказов"
+```
+
+---
+
+## Example 2 — P2 performance degradation
+
+**EN:**
+```
+/incident-response
+
+Severity: P2 — severe performance degradation (not full outage)
+Affected: product search — p99 latency 8s (baseline: 120ms); timeout errors at 12%
+Started: ~11:00 UTC (gradual, no single deploy triggered it)
+Observations:
+  - Only search endpoints affected; orders, auth, payments normal
+  - Elasticsearch CPU at 94% (normal: 30%)
+  - Spike in search traffic: 3x normal (Monday morning, promotional email sent at 10:45 UTC)
+  - No recent code changes to search module
+Hypothesis: Elasticsearch overwhelmed by traffic spike; may need circuit breaker
+Workaround available: disable real-time index refresh (performance mode) — data lag 60s acceptable
+Impact: users see slow search results; purchase flow unaffected
+Communication: notify #product (not public status page — not full outage)
+```
+
+**RU:**
+```
+/incident-response
+
+Серьёзность: P2 — серьёзная деградация производительности (не полный отказ)
+Затронуто: поиск продуктов — p99 задержка 8s (baseline: 120ms); ошибки таймаута 12%
+Начало: ~11:00 UTC (постепенное, не вызвано одним деплоем)
+Наблюдения:
+  - Затронуты только эндпоинты поиска; заказы, auth, платежи в норме
+  - CPU Elasticsearch на 94% (норма: 30%)
+  - Всплеск поискового трафика: 3x нормального (утро понедельника, промо email отправлен в 10:45 UTC)
+  - Нет недавних изменений кода в модуле поиска
+Гипотеза: Elasticsearch перегружен всплеском трафика; возможно нужен circuit breaker
+Временное решение: отключить real-time обновление индекса (режим производительности) — задержка данных 60s приемлема
+Влияние: пользователи видят медленные результаты поиска; поток покупки не затронут
+Коммуникация: уведомить #product (не публичная status page — не полный отказ)
+```
+
+---
+
+## Example 3 — Quick / Post-incident postmortem
+
+**EN:**
+```
+/incident-response
+
+Mode: postmortem (incident resolved — INC-2024-142 checkout outage, duration 34 min)
+Timeline: already documented in incident channel
+Root cause: DB migration in v2.6.1 created new table but deploy ran before migration (race condition in CI)
+Action items needed:
+  - Pre-deploy migration check (block deploy if pending migrations)
+  - Smoke test in canary phase checks table existence
+  - Runbook update: rollback procedure for failed migrations
+Format: blameless postmortem per Google SRE template
+Due: draft to team within 48h
+```
+
+**RU:**
+```
+/incident-response
+
+Режим: postmortem (инцидент разрешён — INC-2024-142 отказ оформления заказа, длительность 34 мин)
+Таймлайн: уже задокументирован в канале инцидента
+Корневая причина: миграция БД в v2.6.1 создала новую таблицу но деплой запустился до миграции (race condition в CI)
+Необходимые action items:
+  - Проверка миграции перед деплоем (блокировать деплой если есть ожидающие миграции)
+  - Smoke test на этапе canary проверяет существование таблицы
+  - Обновление runbook: процедура отката для неудачных миграций
+Формат: blameless postmortem по шаблону Google SRE
+Срок: черновик команде в течение 48ч
+```

package/areas/software/platform/prompts/provision-env.md

@@ -0,0 +1,113 @@
+---
+workflow: provision-env
+---
+
+# Prompt: `/provision-env`
+
+Use when: provisioning a new environment (staging, preview, feature env) from Terraform/Helm configs with cost estimation and DNS/smoke validation.
+
+---
+
+## Example 1 — New staging environment
+
+**EN:**
+```
+/provision-env
+
+Environment name: staging-v2
+Cloud: AWS (eu-west-1)
+IaC tool: Terraform (modules in infra/terraform/envs/staging/)
+Services to provision:
+  - EKS cluster (t3.medium × 3 nodes, spot instances)
+  - RDS PostgreSQL 16 (db.t3.medium, multi-AZ: false for staging)
+  - ElastiCache Redis 7 (cache.t3.micro)
+  - S3 bucket (staging-v2-assets) with versioning enabled
+  - ALB + Route53 record: staging-v2.myapp.internal
+Variable overrides vs. prod: smaller instance sizes; no multi-AZ; 7-day log retention
+Cost estimate required: yes — alert if projected monthly > $800
+DNS: staging-v2.myapp.com → ALB DNS (Route53 hosted zone: myapp.com)
+Smoke test after provisioning: curl https://staging-v2.myapp.com/health → 200
+State backend: S3 bucket tf-state-myapp, key envs/staging-v2/terraform.tfstate
+```
+
+**RU:**
+```
+/provision-env
+
+Имя окружения: staging-v2
+Облако: AWS (eu-west-1)
+Инструмент IaC: Terraform (модули в infra/terraform/envs/staging/)
+Сервисы для развёртывания:
+  - EKS кластер (t3.medium × 3 узла, spot instances)
+  - RDS PostgreSQL 16 (db.t3.medium, multi-AZ: false для staging)
+  - ElastiCache Redis 7 (cache.t3.micro)
+  - S3 bucket (staging-v2-assets) с включённым версионированием
+  - ALB + Route53 запись: staging-v2.myapp.internal
+Переопределения переменных vs. prod: меньшие размеры instance; без multi-AZ; хранение логов 7 дней
+Оценка стоимости обязательна: да — предупреждать если прогнозируемые затраты в месяц > $800
+DNS: staging-v2.myapp.com → ALB DNS (Route53 hosted zone: myapp.com)
+Smoke test после развёртывания: curl https://staging-v2.myapp.com/health → 200
+State backend: S3 bucket tf-state-myapp, ключ envs/staging-v2/terraform.tfstate
+```
+
+---
+
+## Example 2 — Feature preview environment (ephemeral)
+
+**EN:**
+```
+/provision-env
+
+Environment type: ephemeral feature preview (auto-destroy after PR merge)
+PR: #312 "Add product recommendations"
+Namespace: preview-pr-312 (Kubernetes namespace in shared staging cluster — not new cluster)
+Services: order-service:pr-312, recommendation-service:pr-312 (new service)
+Shared infra (reuse existing): PostgreSQL staging DB (separate schema: preview_pr312), Redis staging
+Ingress: pr-312.preview.myapp.internal (internal only, no public DNS)
+Seed data: run make seed-preview DB_SCHEMA=preview_pr312
+Lifetime: auto-destroy when PR #312 is closed or merged (GitHub Actions workflow)
+Cost: namespace only — no new cloud resources; ~$0 additional
+```
+
+**RU:**
+```
+/provision-env
+
+Тип окружения: эфемерная feature preview (авто-уничтожение после мержа PR)
+PR: #312 "Добавить рекомендации продуктов"
+Namespace: preview-pr-312 (Kubernetes namespace в shared staging кластере — не новый кластер)
+Сервисы: order-service:pr-312, recommendation-service:pr-312 (новый сервис)
+Общая инфра (переиспользовать существующую): PostgreSQL staging БД (отдельная схема: preview_pr312), Redis staging
+Ingress: pr-312.preview.myapp.internal (только внутренний, без публичного DNS)
+Seed данные: запустить make seed-preview DB_SCHEMA=preview_pr312
+Время жизни: авто-уничтожение когда PR #312 закрывается или мержится (GitHub Actions workflow)
+Стоимость: только namespace — нет новых облачных ресурсов; ~$0 дополнительно
+```
+
+---
+
+## Example 3 — Quick / DR environment verification
+
+**EN:**
+```
+/provision-env
+
+Purpose: disaster recovery drill — spin up DR environment in us-east-1 from prod snapshots
+Source: RDS snapshot rds:prod-postgres-2024-09-15, S3 sync from prod-assets bucket
+Target region: us-east-1 (DR region)
+Validation: verify app boots and read queries work; write operations disabled (DR = read-only)
+Time limit: DR environment must be ready within 2 hours (RTO target)
+Destroy after: 4 hours (drill complete, document RTO achieved)
+```
+
+**RU:**
+```
+/provision-env
+
+Назначение: учения по аварийному восстановлению — развернуть DR окружение в us-east-1 из prod снапшотов
+Источник: RDS снапшот rds:prod-postgres-2024-09-15, S3 sync из bucket prod-assets
+Целевой регион: us-east-1 (DR регион)
+Валидация: убедиться что приложение запускается и read запросы работают; операции записи отключены (DR = read-only)
+Ограничение времени: DR окружение должно быть готово в течение 2 часов (цель RTO)
+Уничтожить после: 4 часа (учения завершены, задокументировать достигнутый RTO)
+```

package/areas/software/platform/rules/cost-governance.md

@@ -0,0 +1,11 @@
+# Rule: Cost Governance
+
+**Priority**: P1 — Cost overruns trigger mandatory audit.
+
+## Constraints
+
+1. **Budget alerts**: Every AWS account/GCP project must have billing alerts at 80% and 100% of monthly budget.
+2. **No oversized defaults**: Default instance type for new services is `t3.small` (AWS) / `e2-small` (GCP). Larger requires justification.
+3. **Data transfer awareness**: Cross-AZ and cross-region transfer costs estimated before architectural decisions.
+4. **Unused resource policy**: Resources with zero traffic for 7 days trigger review notification. Idle for 30 days → terminated.
+5. **Reserved/committed use**: Any workload running continuously > 3 months must have RI/CUD analysis completed.

package/areas/software/platform/rules/immutability.md

@@ -0,0 +1,17 @@
+# Rule: Immutable Infrastructure
+
+**Priority**: P0 — No exceptions. Manual changes to running infra are a firing-level incident.
+
+## Constraints
+
+1. **No SSH/console patching**: Running instances are never modified in place. Fix = new image + redeploy.
+2. **All infrastructure is code**: Every resource in production must have a corresponding Terraform resource. Resources without IaC are subject to automatic termination.
+3. **Terraform is the single source of truth**: Never use the cloud console to create, modify, or delete resources.
+4. **Module versioning**: All Terraform modules pinned to specific version tags. No `?ref=main` in production.
+5. **Immutable image tags**: Container images in production use content-addressed digests (`image@sha256:...`), never `:latest`.
+
+## Enforcement
+
+- `terraform plan` reviewed in every PR via automated comment
+- Drift detection runs every 6 hours via `/drift-check` workflow
+- OPA policy blocks `terraform apply` if plan contains manually-created resources

package/areas/software/platform/rules/reliability.md

@@ -0,0 +1,19 @@
+# Rule: Reliability Standards
+
+**Priority**: P1 — Required before production promotion.
+
+## SLO Defaults
+
+| Service Tier | Availability | RTO | RPO |
+|:---|:---|:---|:---|
+| Tier 1 (revenue-critical) | 99.9% | 30 min | 15 min |
+| Tier 2 (internal tools) | 99.5% | 4 hours | 1 hour |
+| Tier 3 (batch/async) | 99.0% | 24 hours | 24 hours |
+
+## Constraints
+
+1. **No single points of failure**: All Tier 1 services run with minimum 2 replicas across 2 AZs.
+2. **Graceful shutdown**: All containers handle `SIGTERM` with ≥ 30s drain before `SIGKILL`.
+3. **Readiness before liveness**: K8s probes must define `readinessProbe` before `livenessProbe`.
+4. **Defined resource limits**: Every container must specify `resources.requests` and `resources.limits`.
+5. **Chaos budget**: Tier 1 services must pass a basic chaos test (pod kill, node drain) before going live.

package/areas/software/platform/rules/security-posture.md

@@ -0,0 +1,12 @@
+# Rule: Security Posture
+
+**Priority**: P0 — Violations block deployment.
+
+## Constraints
+
+1. **Least Privilege (IAM)**: Every IAM role scoped to minimum actions and resources. Wildcards (`*`) in `Action` or `Resource` forbidden in production without documented exception.
+2. **No secrets in state or code**: Terraform state must be encrypted (S3 + KMS). No credentials in `.tf` files or CI YAML.
+3. **Encrypted at rest and in transit**: All storage (S3, RDS, EBS) encrypted. All inter-service communication uses TLS ≥ 1.2.
+4. **Network isolation**: Production workloads in private subnets. Public exposure only via load balancer with WAF. Security groups default-deny inbound.
+5. **Tagging compliance**: Every resource must have tags: `Owner`, `Environment`, `CostCenter`, `Terraform=true`.
+6. **MFA on human IAM users**: All human AWS accounts require MFA. Service accounts use IAM roles, never long-lived access keys.