Service Implementation Orchestrator

Сквозная реализация сервиса

Доводить всю заявленную цель до общего результата. Не считать завершение отдельного слоя, компонента, теста или проверки завершением пользовательской задачи.

Для многоэтапной работы полностью прочитать progress-template.md, создать .orchestration/implementation-progress.md и поддерживать его актуальным до завершения.

Основной принцип

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

После каждого этапа сверять progress-реестр с Definition of Done и немедленно переходить к следующему незавершённому шагу. Не завершать ответ предложением могу продолжить, если продолжение уже входит в запрос пользователя.

Подготовка

1. Прочитать инструкции репозитория и проверить состояние рабочего дерева.
2. Сохранить незавершённые изменения пользователя; не включать их в область без необходимости и не откатывать.
3. Определить заявленную цель, область и явно исключённые части.
4. Найти нормативные документы области. Не восстанавливать отсутствующее продуктовое решение из существующего кода.
5. Отделить нормативные требования от примеров, предложений, черновиков и открытых вопросов.
6. Вывести стартовую сводку: цель, область, источники требований, предполагаемые компоненты, исключения, проверки и progress-файл.
7. Определить порог исправления замечаний аудита без отдельного вопроса. Если пользователь явно не задал иное, использовать Все: исправлять Высокий, Средний и Низкий. Явно заданные альтернативы: До среднего — Высокий и Средний; Только высокий — только Высокий. Записать применённый порог в progress-файл.
8. Найти корень Git-репозитория и проверить его .gitignore. Если отдельных строк .orchestration/ или .review/ нет, предложить пользователю добавить отсутствующие строки. Не изменять .gitignore без согласия и не использовать .git/info/exclude вместо проектных правил.
9. Создать или актуализировать .orchestration/implementation-progress.md. Не стирать пользовательские решения и сведения предыдущего запуска.

Построение полного плана

1. Преобразовать нормативные требования в проверяемые элементы реализации.
2. Для каждого элемента указать источник, компонент, зависимости, ожидаемые артефакты, профильный скил и способ проверки.
3. Включить не только основной код, но и требуемые тесты, миграции, конфигурацию, composition root, entrypoints, lifecycle, logging, интеграцию и документацию репозитория.
4. Отмечать компонент Не требуется только с доказательством из области и требований, а не потому, что он ещё не рассмотрен.
5. Строить порядок по фактическим зависимостям. Не зашивать фиксированный список слоёв или технологий.
6. Динамически обнаруживать implementation-скилы по актуальному каталогу среды. Отбирать кандидатов по metadata, полностью читать выбранные SKILL.md и назначенные ими references. Не поддерживать закрытый список имён.
7. Если применимого скила нет, следовать требованиям и конвенциям репозитория и отметить отсутствие профильного скила в progress-файле; не блокировать однозначную реализацию только из-за этого.

Реализация

1. Поддерживать один актуальный план выполнения вместе с progress-файлом.
2. Перед началом элемента ставить В работе; после изменения запускать наиболее узкие относящиеся проверки.
3. Ставить Выполнено только после создания всех артефактов элемента и успешной проверки его ожидаемого поведения.
4. При падении проверки диагностировать причину, исправить относящуюся реализацию и повторить проверку. Не считать диагностируемый локальный отказ блокером.
5. После элемента сразу переходить к следующему готовому по зависимостям.
6. Периодически сообщать краткий прогресс, не запрашивая разрешение продолжать.
7. Не создавать коммит без явной просьбы и не выполнять удалённые операции.

Полные проверки

После завершения элементов реализации:

1. Выполнить обязательные formatter-check, lint, type-check и test-команды репозитория без автоисправления.
2. Выполнить integration- и process-level проверки, требуемые затронутыми компонентами и доступные в разрешённом окружении.
3. Не выдавать частичный или прерванный запуск за успешную проверку.
4. Исправить собственные ошибки и повторять проверки до успеха либо настоящего блокера.

Независимый audit/fix loop

1. Динамически обнаружить review-скил проверки реализации по применимым implementation-скилам и выполнить полный аудит заявленной области.
2. Отдельно обнаружить review-скил сверки реализации с нормативной документацией и выполнить полный аудит той же области.
3. Не ослаблять read-only границы аудиторов: они создают отчёты, но не исправляют реализацию.
4. Прочитать созданные отчёты и отделить замечания, входящие в согласованный порог. Замечания ниже порога не исправлять, не переводить в Исправлено и не удалять; перечислить их в progress-файле и итоговой сводке.
5. Для каждого входящего в порог Актуально выбрать профильный implementation-скил, внести исправление, заполнить обязательный блок Решение и выполнить относящиеся проверки.
6. Не исправлять входящее в порог Требует согласования без записанного пользовательского решения.
7. Повторно выполнить оба аудита после исправлений.
8. Продолжать цикл, пока в согласованном пороге остаётся Актуально. Замечания ниже порога считать согласованно отложенными, но сохранять их фактический статус. Другие исключения допускать только по явному решению пользователя.
9. Если review-скил недоступен, отметить невыполненный quality gate как блокер завершения, не подменяя независимый аудит самооценкой.

Настоящие блокеры

Останавливаться и запрашивать пользователя только когда:

• отсутствует решение, существенно меняющее доменное, публичное или системное поведение;
• нормативные источники противоречат друг другу;
• требуется отдельное разрешение на разрушительное, внешнее или небезопасное действие;
• необходимы недоступные секреты, учётные данные или обязательная инфраструктура;
• несколько несовместимых архитектурных вариантов нельзя выбрать по требованиям;
• пользователь явно назначил контрольную точку.

Не считать блокером большой объём, переход к следующему компоненту, необходимость прочитать новый скил, диагностируемое падение теста, собственную ошибку реализации, сжатие контекста или отсутствие повторной команды продолжай.

При блокере завершить все остальные независимые безопасные элементы, записать точный вопрос, влияние и уже выполненную работу в progress-файл и только затем запросить решение.

Definition of Done

Считать цель завершённой, только если одновременно выполнено следующее:

• каждый элемент заявленной области имеет Выполнено или обоснованное Не требуется;
• все обязательные артефакты, тесты и интеграционные связи созданы;
• узкие и полные обязательные проверки успешно завершены;
• выполнены оба независимых аудита;
• в согласованном пороге нет Актуально либо пользователь явно исключил конкретное замечание;
• в согласованном пороге нет Требует согласования и других блокеров;
• все замечания ниже порога сохранены и перечислены как согласованно отложенные;
• progress-файл отражает фактическое итоговое состояние;
• .orchestration/ и .review/ исключены корневым .gitignore либо пользователь явно отказался от предложенного изменения;
• проверены git status и итоговый diff без затрагивания чужих изменений.

Финальный ответ должен сообщать реализованный объём, проверки, результаты аудитов, оставшиеся явные исключения и путь к progress-файлу. Не объявлять успех, если Definition of Done не выполнен.