Об этом проекте

## Обзор jira-integration — это плагин для Claude Code, который обрабатывает одну задачу Jira от создания ветки → проектирования подхода → реализации → тестирования → ревью → локального слияния и фиксирует результаты каждого этапа в Jira в виде комментариев, вложений и переходов статусов. Несколько задач помещаются в очередь и последовательно обрабатываются, после чего результаты прохождения/изоляции сводятся в один отчёт об исключениях, чтобы человек оценивал только изолированные случаи. ## Структура работы Состоит из двух циклов. - Цикл этапов (`auto`): одна задача выполняется в порядке start → approach → impl+test → review. Каждый этап выполняется изолированным субагентом, и для этапов назначаются разные модели. Шлюз ревью определяет результат по структурированным значениям — коэффициенту соответствия проектирования и реализации и количеству Critical; при непрохождении агент исправлений сводит задачу в цикле датчиков (до 5 раз), который запускает только lint, typecheck и связанные тесты, затем выполняет полный набор тестов и повторное ревью дельты по одному разу. Внешний цикл ограничен 2 итерациями. - Цикл задач (`loop`): последовательно расходует очередь, настроенную командой `init`, выполняя для каждой задачи auto → локальное слияние `--no-ff` → rebase оставшихся worktree. При непрохождении шлюза, сбое этапа или конфликте слияния/rebase изолируется только данная задача, и цикл переходит к следующей. Полная остановка происходит только при инфраструктурных сигналах (аутентификация 401/403, MCP-подключение, повреждение base) или при последовательных сбоях разных задач. В документации указано, что поток управления выполняется не интерпретацией промптов, а детерминированно скриптом Workflow (`scripts/auto.workflow.js`). ## Интеграция с Jira Ключу задачи соответствует ветка (`feature/<KEY>`), worktree и файл контекста. `.jira-context.json` в основном репозитории — это агрегат всей очереди, а в каждом worktree — состояние конкретной задачи. По командам происходят переходы статусов (to do → in progress → in review → done), комментарии, вложения (документы approach/review, отчёты о тестах). Изоляция не изменяет Jira и фиксируется только в локальном состоянии. За вызовы Jira отвечает `scripts/jira-cli.py` (REST), использующий только стандартную библиотеку; учётные данные хранятся в блоке `jira` файла `.jira-context.json` на уровне рабочего пространства и автоматически переносятся из переменных окружения и устаревших настроек MCP. Регистрация MCP-сервера опциональна. ## Основные команды - Создание задачи: `epic set/show/clear`, `discover`, `create` - Очередь/автоматизация: `init`, `loop`, `auto` - Отдельные этапы: `start`, `approach`, `impl`, `test`, `review`, `merge`, `pr`, `done` - Просмотр/очистка: `status`, `report`, `clean` - Прочее: `/jira setup`, `/jira dashboard` ## Правила работы Размер задачи оценивается как L1/L2/L3, и в зависимости от этого корректируются объём артефактов и глубина ревью; если затрагиваются модель данных, границы транзакций, контракты внешних API, конкурентность или границы безопасности, задача повышается до L2, даже если была L1. `start` может рекомендовать пропуск только для этапов approach и test; impl, review и merge не пропускаются. Все этапы записываются в `completedSteps`, и при повторном запуске завершённые этапы пропускаются. ## Артефакты и дашборд В `docs/` накапливаются документы requirements, approach, test, review, а также review-log и run-log (jsonl). run-log и review-log используются как наблюдательные данные самого харнесса: доля ложных срабатываний ревью, длительность этапов, частота исправлений, причины изоляции. Дашборд на `http://127.0.0.1:8765` в реальном времени показывает карточки по worktree (текущий этап, вызовы инструментов, статус Jira, граф blocks) через SSE; он доступен только с localhost и не требует аутентификации. ## Лицензия MIT.