ops-deploy

ops-deploy собирает единый статус деплоев по проектам. В его отчёте предусмотрены версии и состояние ECS-сервисов, последние и ожидающие Vercel-деплои, недавние GitHub Actions и общая стадия CI/CD. Навык принимает необязательный project alias, а также режимы ecs, vercel или all. Это operational dashboard, а не команда для изменения инфраструктуры: сначала собираются факты о состоянии, затем они сводятся в таблицу с временем последнего деплоя, окружением, коммитом и возрастом события. Перед сбором данных workflow загружает пользовательские настройки timezone и проверяет health-файл daemon. Если infra-monitor не запущен, это должно быть отмечено как риск свежести ECS-данных. Для AWS предусмотрен резервный вызов aws CLI: сначала можно использовать ops-infra, затем получить список кластеров, список сервисов и describe-services. Для сервиса отображаются имя, desired/running/pending counts, image или task definition и общий статус. Это позволяет отличить активный сервис от ситуации, когда желаемое и фактическое количество задач расходятся, не подменяя такую диагностику одним зелёным флагом. Для CI/CD источник GitHub Actions выбирается по registry проектов. Для каждого подходящего репозитория запрашиваются пять последних запусков с workflow-именем, веткой, статусом, conclusion, временем создания и database ID. Vercel-часть использует интеграцию списка проектов и деплоев с ограничением в пять последних записей на проект. Когда Vercel MCP недоступен, в источнике описан fallback через Vercel API; авторизационные данные должны передаваться только через уже настроенный VERCEL_TOKEN и не попадать в отчёт. В итоговой панели отдельно показываются ECS SERVICES с D/R/P, VERCEL DEPLOYMENTS с environment и commit, CI/CD PIPELINE со статусом и возрастом, а также PENDING DEPLOYS для веток, где нужна следующая стадия или merge. Для проекта можно перейти от общей панели к deep-dive: вывести только его деплой, последние десять CI-запусков и доступные действия. Для failed deploy разрешён просмотр build logs Vercel или CloudWatch-логов ECS. Ручной deploy не должен запускаться молча: перед действием нужно подтвердить окружение, ветку, последний commit и выбрать Deploy now, просмотр diff или отмену. Если пользователь просит следить за текущим запуском, workflow использует потоковый Monitor для gh run watch или ожидания стабильности ECS-сервиса. Tasks применяются для учёта проектов, пока deploy идёт, а после завершения состояние должно быть обновлено. Важная часть навыка — ledger guard от параллельных операций. Для каждой пары project/environment формируется CLAIM_KEY вида deploy:<project>:<env>. До запуска проверяется ledger за последние 24 часа: активный in_progress блокирует конкурирующий deploy, а недавний done требует подтверждения повторного запуска. При старте создаётся claim со статусом in_progress и TTL 1800 секунд; после успеха или ошибки он переводится в done с причиной. Поэтому ops-deploy полезен для read-only сводки и контролируемого перехода к логам или ручному запуску, но его данные зависят от доступности AWS, Vercel, GitHub, daemon и ledger. При отсутствии credentials, stale daemon или недоступном backend следует показывать ограничение и не выдавать неполную панель за подтверждённое production-состояние.