Imported from CybernetKZ/sdd-kit (profiles/conversation_flow/.claude/skills/tz-implement/SKILL.md). Install upstream with npx skills add CybernetKZ/sdd-kit --skill tz-implement. Copyright stays with the author.

Реализация change'а - фазы и СТОП-гейты

Вход - openspec/changes/tz-NNN-<slug>/ (proposal + спек-дельты + tasks.md), прошедший /tz-review (вердикт "готово к реализации") и гриль (## Grill заполнена). Выход - реализация, зелёные тесты, применённая спек-дельта, обновлённый docs/DOCUMENTATION.md, серия логических коммитов, архивированный change.

Ничего не пушить без явной просьбы пользователя.

Фаза 0 - входные условия и сверка с кодом (до любого плана)

1. Прочитать change целиком + openspec/specs/ затронутых capability + прежние ТЗ и §§, на которые он ссылается (шапка-цитата, ## Что затрагивается).
2. Проверить входные условия - при провале СТОП, не начинать:
   • вердикт /tz-review есть и он "готово к реализации";
   • ## Grill заполнена и несёт шапку провенанса (Grilled by: ... | questions: N | plan changes: ...); на тире deep провенанс обязан быть plan-griller agent, session inline на deep - СТОП;
   • тесты по Scenario'ям написаны test-author и RED; их нет - сначала тесты, не код. Тест, который неожиданно зелёный, - находка (поведение уже есть), а не повод "сделать его красным";
   • npx -y @fission-ai/openspec@1.7.0 validate --all --strict и bash scripts/sdd/check.sh зелёные на входе;
   • light-тир: гриля нет законно; RED-тест по единственному Scenario - обязателен.
3. Проверить по коду каждый фактический пункт change'а: существуют ли названные файлы/поля/точки расширения, реализовано ли то, что ## Why называет уже работающим, указывают ли якоря enforced: дельты на существующие символы. Якоря дельты spec-lint.py проверяет сам (блок spec-lint: N change delta(s) checked, M with findings); нерезолвящийся - совет (note: anchor does not resolve yet: ...), гейт не валит: дельта законно может назвать символ, который change только создаст. Разобрать каждую note: файл создаётся этим change'ем и задача на это есть в tasks.md - ожидаемо; файл существует, а символа нет - расхождение по п. 4 (доложить, не "дописать символ, чтобы совпало"). Метаданные дельты (unknown_key, missing_id, missing_enforced, #### Scenario: под ## Invariants) - уже нарушения, на входе их быть не должно.
4. Правило "код важнее спеки": change противоречит фактическому коду (поле не там, механизм устроен иначе, "уже есть" отсутствует) ⇒ остановиться и доложить расхождение пользователю, а не подгонять код под документ и не "чинить" change молча. Change задним числом не редактируется - коррекция решением пользователя (правка активного change'а через /tz либо новый номер, если этот уже архивирован).
5. Пункты ## Проверить перед реализацией - проверить сейчас (документация вендора, код плагина, пиновая версия); результат - в отчёт фазы 0.
6. Расхождения кода со спекой вне scope change'а - в sdd-kit/docs/DEFECTS_CF.md как материал для тикета; молча не "чинить".

Фаза 1 - план и первый СТОП-гейт

• Разбить tasks.md на последовательность логических коммитов (обычно 1 коммит ≈ 1-2 §: схема+регенерация; бэкенд; API; UI+i18n; спека+документ).
• СТОП-гейт: показать разбивку пользователю и дождаться подтверждения перед началом. Отдельный СТОП-отчёт - перед каждым рискованным шагом: alembic-миграция, правка engine/schema.py, массовые правки, изменение поведения существующих тестов, правка кросс-репо контракта.
• Кому реализовывать (таблица "тир -> конвейер -> модели" в скилл feature-flow плагина code-conventions, §1b): проходы по tasks.md отдаются субагенту executor (sonnet) - строго по задачам, чужие тесты не правит, не коммитит, любое отклонение = стоп-отчёт. Диспуты с test-author, решения "менять ли план" и финальное ревью остаются у главной сессии.

Фаза 2 - реализация

• Идти по tasks.md сверху вниз, отмечая - [x] по факту выполнения.
• Один логический коммит на изменение; сообщение - русское, со ссылкой "ТЗ №NN §M" (как принято в истории репо) и id change'а. Коммитит разработчик (или главная сессия по его явной команде, после ревью) - executor не коммитит.
• Перед каждым коммитом зелёные:
  • PY=/opt/anaconda3/bin/python3.12 make test (lint_brand + lint_migrations + lint_imports + ruff + pytest, ~60 с);
  • nvm use 20 && npm --prefix editor run build (включает tsc --noEmit) - если тронут фронт; при правках только бэкенда достаточно финального коммита.
• Дом-конвенции - раздел «Конвенции» в AGENTS.md: знать заранее, а не ловить линтами/хуками. Специфика реализации поверх них: правка engine/schema.py ⇒ сразу python scripts/gen_ts_types.py (руками flow.gen.ts не трогать - заблокирует PreToolUse-хук); разделяемое состояние API - через атрибуты api.main, не переносить.
• Чужие тесты не правятся: тест выглядит неверным - вернуть его на шаг test-author вместе с Scenario, на который он трассирует.
• Латентностные задачи (кэши, стриминг, горячий путь диалога): замерить before/after (p50/p90) на одинаковом сценарии; числа - в отчёт, в §17 и в спеку. Без замера утверждение "стало быстрее" не делается.

Фаза 3 - спека (канон) и документ (параллельно)

Порядок важен: сначала openspec - он канон, затем документ генерируется из той же дельты. Оба - в тех же коммитах, что и код.

1. Применить спек-дельту в openspec/specs/<capability>/spec.md: openspec sync-specs-путь (скилл .claude/skills/openspec-sync-specs/) или руками; обновить в затронутых Requirement маркер > Last verified: <дата> (commit <sha>) и якоря enforced: на реальные символы реализации (grep -n '<Symbol>' <path> - проверить, а не вписать).
2. Перенести то же изменение в docs/DOCUMENTATION.md: затронутые §8.x, карта проекта §14, глоссарий §16, запись в §17 changelog + bump minor-версии 1.NN.0 (версия - в шапке документа). Текст генерируется из спек-дельты; при конфликте прав openspec. Living-spec-фрагмент pre-commit предупреждает, если код закоммичен без документа - игнорировать предупреждение нельзя.
3. Тесты: файл(ы) по Scenario'ям с трейсерами # spec: <requirement-id> / <scenario>; добавить строку в карту tests/README.md.
4. Финальный прогон целиком зелёный:

   PY=/opt/anaconda3/bin/python3.12 make test
   nvm use 20 && npm --prefix editor run build
   bash scripts/sdd/check.sh          # включает openspec validate --strict и spec-lint (последний advisory)
   SPEC_LINT_STRICT=1 python3 .claude/scripts/spec-lint.py   # здесь - как гейт: дельта уже в каноне

   Вторая строка не дубль первой: внутри sdd-check spec-lint выходит с 0 и его находки - лишь отчёт, а после применения дельты в канон метаданные и якоря обязаны быть чистыми (строгий режим покрывает и канон, и ещё не заархивированную дельту). note по якорям к этому моменту быть не должно: код написан, символы существуют. Осталась - либо якорь врёт, либо задача не выполнена.

Фаза 4 - ревью, приёмка, архивация

1. Ревьюеры на диффе: backend-reviewer, плюс database-reviewer при правках SQL/ORM/миграций. CRITICAL/HIGH в scope - исправить; вне scope - TODO/NOTE со ссылкой на ТЗ, scope не расширять. После правок - перепрогнать тесты.
2. Пройти вручную QA-Scenario'и на локальном/стейдж-контуре.
3. Отметить все - [x] в tasks.md; каждый критерий приёмки - подтверждён фактом (тест, замер, живая проверка), а не "сделано".
4. Архивировать change - скилл .claude/skills/openspec-archive-change/ (openspec/changes/tz-NNN-* -> changes/archive/tz-NNN-*), после того как спека применена и документ обновлён.

Финальный отчёт

Что реализовано по каждому пункту tasks.md (с номерами); чем закрылись пункты ## Проверить перед реализацией; результаты замеров latency; список коммитов; что применено в openspec/specs/ и какие §§ документа + версия обновлены; дефекты, отправленные в DEFECTS_CF.md. Расхождения и осознанные отступления от change'а - явно, а не между строк. Не пушить - только по явной просьбе.