rarus-echo-maintainer

name	rarus-echo-maintainer
description	Используй, когда работаешь с GitHub issues, процессом сопровождения, OpenSpec, ветками, pull requests или CI для mesilov/rarus-echo-php-sdk.
user-invocable	true

Сопровождение RARUS Echo

Репозиторий: mesilov/rarus-echo-php-sdk

Используй этот скилл для сопровождения репозитория через GitHub issue: чтение задачи, планирование реализации, решение о необходимости OpenSpec, создание ветки, запуск проверок, открытие pull request и контроль CI.

Начало работы

1. Перед реализацией загрузи GitHub issue. Прочитай заголовок, описание, labels, milestone, assignees, комментарии и связанные pull requests.
2. Из корня репозитория проверь текущее состояние:

   pwd
   git status --short --branch
   openspec list
   openspec list --specs
   

3. Сохраняй несвязанные локальные изменения. Не сбрасывай, не удаляй, не добавляй в индекс и не форматируй файлы вне области issue.
4. Используй dev как базовую ветку для работы по issue, если пользователь явно не указал другое.
5. Создай ветку с именем:

   feature/<issue-number>-<short-slug>
   bugfix/<issue-number>-<short-slug>
   docs/<issue-number>-<short-slug>
   

Политика OpenSpec

Создавай или обновляй OpenSpec change для:

• изменений публичного SDK API;
• поведения, видимого пользователям SDK;
• изменений архитектуры или сервисного слоя;
• изменений CI, процесса поддержки или процесса сопровождения.

OpenSpec можно пропустить для исправления опечаток, обновления зависимостей, механического форматирования и тривиальных правок документации в одном файле.

Когда OpenSpec обязателен:

1. Проверь пересекающиеся активные изменения через openspec list.
2. Создай или продолжи openspec/changes/<change-id>/.
3. Синхронизируй proposal.md, design.md при необходимости, tasks.md и дельты спецификаций с реализацией.
4. Проверь:

   make lint-openspec
   

5. Архивируй завершенные изменения только после merge соответствующего pull request:

   openspec archive <change-id> --yes
   

Правила реализации

• Следуй существующей структуре SDK: Services, Core, Infrastructure, Contracts, immutable result/configuration objects, strict types и PSR-compatible dependencies.
• Держи изменения в рамках issue.
• Добавляй или обновляй тесты, когда меняется runtime-поведение PHP-кода.
• Обновляй README.md, CONTRIBUTING.md или артефакты OpenSpec, когда меняется процесс или публичное использование.
• Не добавляй правила, специфичные для Bitrix24, generated result-item contracts, OpenAPI refresh steps или выбор веток v1/v3. Это относится к другим SDK, не к этому репозиторию.

Проверка

Для OpenSpec или изменений только процесса запускай:

make lint-openspec
git diff --check
make test-unit
make lint-all

Для изменений PHP-поведения дополнительно запускай точечные unit-тесты, покрывающие измененный код. Integration tests запускай только когда issue затрагивает поведение реального API и доступны учетные данные:

make test-integration

Если обязательную проверку нельзя запустить из-за отсутствующей инфраструктуры или учетных данных, укажи точный блокер и не описывай issue как завершенную.

Pull Request

Открывай pull request только после зеленой локальной проверки или после явно задокументированного внешнего блокера.

Правила:

• Отправь issue branch в origin.
• Открой pull request в dev.
• Добавь Closes #<issue-number> в тело PR как обычный текст.
• Укажи команды проверки, которые прошли.
• Проверь PR CI после открытия или обновления PR.
• Проверь inline review threads и top-level comments от agent reviewers: Codex, Claude и других review bots.
• Для каждого agent comment проверь обратную связь по текущему коду, внеси корректную правку или ответь технической причиной, если комментарий устарел или неприменим.
• Резолвь review thread только после правки, устаревания комментария или ответа с причиной, почему изменение не требуется.
• Не сообщай, что issue завершена, пока обязательные CI checks не стали зелеными и agent review threads не обработаны.