sprint-pr-cycle

name	sprint-pr-cycle
description	Оркестрация полного PR-цикла спринта — от создания PR до готовности к merge. Контролирует порядок шагов, запуск субагентов, публикацию отчётов. Используй когда PM завершил кодирование спринта и готов к ревью-циклу.
user-invocable	true

Sprint PR Cycle

Оркестратор полного ревью-цикла спринта. Ведёт PM по обязательным шагам, не позволяя пропустить ни один.

Контекст

Прочитай перед началом:

• .agents/AGENT_ROLES.md — роли и правила
• .memory_bank/status.md — текущее состояние

Фаза 1: Подготовка PR

Шаг 1.1: Проверка готовности

# Все тесты должны пройти
npm run build && npm run test

Если тесты падают — СТОП. Исправь перед продолжением.

Шаг 1.2: Push всех изменений

git status --porcelain
# Если есть незакоммиченные — закоммить и запуш
git push

Шаг 1.3: Создание PR

Проверь, существует ли PR для текущей ветки:

BRANCH=$(git branch --show-current)
gh pr list --head "$BRANCH" --json number,title --jq '.[0]'

Если PR не найден — создай:

gh pr create --title "Sprint N: [краткое описание]" --body "$(cat <<'EOF'
## Summary
- [список ключевых изменений]

## Issues
- [список закрытых beads issues]

## Test plan
- [ ] npm run build
- [ ] npm run test
- [ ] Ручное тестирование на проде

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

ОБЯЗАТЕЛЬНО: Запиши номер PR — он понадобится на всех следующих шагах.

Фаза 2: Внутреннее ревью

Шаг 2.1: Запуск reviewer субагентов (параллельно по направлениям)

Запусти три субагента параллельно, каждый по своему направлению:

Архитектура:

Ты Reviewer. Прочитай .agents/AGENT_ROLES.md секция "3. Reviewer".
Задача: проверь PR #<NUMBER> — аспект АРХИТЕКТУРА.
Фокус: server-authority, разделение слоёв (server/client/shared), паттерны reconnect-safety, идемпотентность через operationId, соответствие архитектурному документу.
Результат: вердикт APPROVED / CHANGES_REQUESTED с обоснованием.

Безопасность:

Ты Reviewer. Прочитай .agents/AGENT_ROLES.md секция "3. Reviewer".
Задача: проверь PR #<NUMBER> — аспект БЕЗОПАСНОСТЬ.
Фокус: валидация ввода, SQL injection, XSS, утечка данных клиенту, OWASP top-10, race conditions в DuelCoordinator, double-spend билетов/осколков.
Результат: вердикт APPROVED / CHANGES_REQUESTED с обоснованием.

Качество:

Ты Reviewer. Прочитай .agents/AGENT_ROLES.md секция "3. Reviewer".
Задача: проверь PR #<NUMBER> — аспект КАЧЕСТВО.
Фокус: покрытие тестами, edge-cases, производительность < 100мс, формулы из shared/formula.ts, пороги лиг, массообмен.
Результат: вердикт APPROVED / CHANGES_REQUESTED с обоснованием.

Шаг 2.2: Запуск tester субагента

Ты Developer. Прочитай .agents/AGENT_ROLES.md секция "2. Developer".
Задача: напиши и запусти тесты для изменений в PR #<NUMBER>.
Покрыть: happy path + edge cases + error cases.

Шаг 2.3: Публикация отчёта внутреннего ревью

ОБЯЗАТЕЛЬНО опубликуй результаты всех трёх направлений в PR:

gh pr comment <NUMBER> --body "$(cat <<'EOF'
## Внутреннее ревью (Claude)

### Архитектура
**Вердикт:** [APPROVED / CHANGES_REQUESTED]
[резюме]

### Безопасность
**Вердикт:** [APPROVED / CHANGES_REQUESTED]
[резюме]

### Качество
**Вердикт:** [APPROVED / CHANGES_REQUESTED]
[резюме]

### Тесты
**Результат:** [✅ все пройдены / ❌ N падений]
[список запущенных тестов]

— PM (Claude Opus 4.6)
EOF
)"

Шаг 2.4: Исправление замечаний (если есть)

Если хотя бы один аспект — CHANGES_REQUESTED:

1. Запусти developer субагента на исправления
2. npm run build && npm run test
3. git push
4. ОБЯЗАТЕЛЬНО опубликуй отчёт об исправлениях в PR:

   gh pr comment <NUMBER> --body "$(cat <<'EOF'
   ## Исправления по внутреннему ревью
   
   | # | Замечание | Направление | Статус |
   |---|----------|-------------|--------|
   | 1 | [описание] | [Архитектура/Безопасность/Качество] | ✅ Исправлено |
   
   ### Тесты после исправлений
   - build: ✅
   - test: ✅ (N тестов)
   
   — PM (Claude Opus 4.6)
   EOF
   )"
   

5. Вернись к шагу 2.1 для повторной проверки исправленных направлений

Фаза 3: Внешнее ревью

Шаг 3.1: Подготовка промптов для внешних ревьюеров

Перед запросом внешнего ревью — подготовь детальные промпты для каждого ревьюера. Промпт должен включать контекст изменений, чтобы ревьюер проверял точечно.

Собери данные:

# Список изменённых файлов
gh pr diff <NUMBER> --name-only

# Список закрытых issues
bd list --status=in_progress

# Краткий diff для контекста
gh pr diff <NUMBER> --stat

Сгенерируй промпт для каждого ревьюера по шаблону:

PM заполняет только секции, помеченные [PM заполняет]. Остальное — фиксированный шаблон, менять запрещено.

ChatGPT-5.4 (архитектура + безопасность):

Ты независимый Senior Reviewer. Твоя задача — найти проблемы, а не подтвердить качество.
Проверь PR #<NUMBER> репозитория komleff/surprise-arena.
Будь строгим. Не принимай компромиссов. Если сомневаешься — помечай как CRITICAL.

## Контекст проекта (неизменный)
Surprise Arena — мобильная PvP-игра. Стек: Preact + Express + PostgreSQL + Colyseus.
Сервер авторитетен — клиент НЕ источник истины. Боевая математика в shared/formula.ts.
Идемпотентность через operationId. Все мутации в транзакциях PostgreSQL.
Reconnect-safe: клиент восстанавливает состояние через REST.

## Что изменилось [PM заполняет]
- Issues: [список с кратким описанием]
- Файлы: [список из gh pr diff --name-only]
- Области: [DuelCoordinator / TicketWalletService / ...]

## Обязательные проверки
- [ ] Server-authority: клиент не принимает решений о массе, билетах, исходе боя
- [ ] SQL injection: все запросы параметризованы
- [ ] Race conditions: параллельные бои, двойное списание билетов
- [ ] Утечка данных: клиент не получает чужие данные (opponent weight в snapshot, а не live)
- [ ] Идемпотентность: повторный запрос не дублирует эффект
- [ ] Reconnect-safety: результат доступен через REST после разрыва WS

## Формат ответа (обязательный)
Для каждого замечания:
| Файл | Строка | Серьёзность | Описание |
|------|--------|-------------|----------|

Серьёзность — ТЫ решаешь, не PM:
- **CRITICAL** — баг, уязвимость, потеря данных. Блокирует merge.
- **WARNING** — потенциальная проблема, неоптимальный код. Требует внимания.
- **INFO** — предложение по улучшению.

Итоговый вердикт: **APPROVED** / **CHANGES_REQUESTED**
Подпиши именем своей ИИ-модели. Опубликуй как комментарий в PR.

ChatGPT-5.3-Codex (compliance):

Ты независимый Compliance Auditor. Проверяешь, что каждый фикс решает описанную проблему.
Проверь PR #<NUMBER> репозитория komleff/surprise-arena.
Будь строгим. Если фикс не полный — помечай как CRITICAL.

## Матрица соответствия [PM заполняет таблицу]
| Issue | Описание | Файлы | Ожидаемый результат |
|-------|----------|-------|---------------------|
| [id] | [описание] | [файлы] | [что должно работать] |

## Обязательные проверки
Для каждого issue:
- [ ] Фикс действительно решает описанную проблему
- [ ] Нет регрессии в связанных модулях
- [ ] Тесты покрывают исправленный сценарий
- [ ] Edge-cases учтены (нулевая масса, пустой кошелёк, параллельные бои)

## Формат ответа (обязательный)
Матрица:
| Issue | Статус | Обоснование |
|-------|--------|-------------|
| [id] | ✅ / ❌ / ⚠️ | [почему] |

Серьёзность — ТЫ решаешь:
- **CRITICAL** — фикс не решает проблему или создаёт регрессию
- **WARNING** — решает частично
- **INFO** — решает, есть предложения

Итоговый вердикт: **APPROVED** / **CHANGES_REQUESTED**
Подпиши именем своей ИИ-модели. Опубликуй как комментарий в PR.

Сохрани промпты в .review-sprint-N/ для переиспользования.

Шаг 3.2: Запрос внешнего ревью

Сообщи оператору:

✅ Внутреннее ревью пройдено. PR #<NUMBER> готов к внешнему ревью.

Промпты подготовлены в .review-sprint-N/:
1. prompt-gpt54-architecture.md — для ChatGPT-5.4
2. prompt-codex-compliance.md — для ChatGPT-5.3-Codex
3. GitHub Copilot — inline ревью в PR

Передай промпты внешним ревьюерам.

СТОП. Жди, пока оператор передаст результаты внешнего ревью.

Шаг 3.3: Обработка замечаний внешних ревьюеров

После получения комментариев от внешних ревьюеров в PR:

1. Прочитай все комментарии:

   gh pr view <NUMBER> --comments --json comments
   

2. Проанализируй замечания, классифицируй по серьёзности

3. Запусти developer субагентов на исправления

4. npm run build && npm run test

5. git push

6. ОБЯЗАТЕЛЬНО опубликуй отчёт об исправлениях в PR:

   gh pr comment <NUMBER> --body "$(cat <<'EOF'
   ## Отчёт PM: исправления по внешнему ревью
   
   ### Исправлено
   | # | Замечание | Источник | Статус |
   |---|----------|----------|--------|
   | 1 | [описание] | [GPT-5.4/Codex/Copilot] | ✅ Исправлено |
   
   ### Принято без изменений (с обоснованием)
   | # | Замечание | Обоснование |
   |---|----------|-------------|
   
   ### Тесты
   - build: ✅
   - test: ✅ (N тестов)
   
   — PM (Claude Opus 4.6)
   EOF
   )"
   

7. Сообщи оператору: "Исправления опубликованы. Запроси повторное ревью."

Шаг 3.4: Повторное ревью

СТОП. Жди результатов повторного ревью от оператора.

Цикл повторяется (шаги 3.3–3.4) пока все внешние ревьюеры не выдадут APPROVED.

Фаза 4: Landing the Plane

После получения APPROVED от всех ревьюеров:

Шаг 4.1: Обновление Memory Bank

# Обновить status.md (текущее состояние + прогресс)

Отрази в Memory Bank:

• Текущее состояние спринта → завершён
• Закрытые issues
• Ключевые решения и изменения
• Метрики (количество issues, файлов, тестов)

Шаг 4.2: Закрытие Beads issues

bd close <id1> <id2> ...
bd dolt push

Шаг 4.3: Push изменений

git pull --rebase && git push

Шаг 4.4: Финальный отчёт в PR

gh pr comment <NUMBER> --body "$(cat <<'EOF'
## ✅ Sprint N завершён

### Метрики
- Issues закрыто: N
- Файлов изменено: N
- Тестов: N
- Раундов ревью: N

### Ревьюеры
- Claude Reviewer: APPROVED
- ChatGPT-5.4: APPROVED
- ChatGPT-5.3-Codex: APPROVED
- GitHub Copilot: APPROVED

### Готово к merge
PR готов. Оператор может выполнить merge.

— PM (Claude Opus 4.6)
EOF
)"

Шаг 4.5: Уведомление оператора

✅ Sprint N полностью завершён.
- Memory Bank обновлён
- Beads issues закрыты
- Финальный отчёт опубликован в PR #<NUMBER>

Можно мержить.