implement-specs

name	implement-specs
description	Реализация утверждённой фичи по PRODUCT.md и TECH.md с поддержанием спек и кода синхронными в одном PR. Использовать после утверждения спек, когда следующий шаг — сборка фичи. Канонический источник правил «спеки и код в одном PR» и «держи спеки актуальными».
vibeVersion	1.1.0

implement-specs

Реализовать утверждённую фичу по PRODUCT.md и TECH.md из specs/<id>/.

Предусловия

• PRODUCT.md существует; TECH.md существует, если фича его заслуживала.
• Спеки прошли ревью и утверждены достаточно, чтобы начинать реализацию.

Процесс

1. Сначала прочитать спеки

• PRODUCT.md — источник правды о пользовательском поведении.
• TECH.md — источник правды об архитектуре, последовательности работ и форме реализации.

До кода — понять ожидаемое поведение, ограничения, риски и план валидации.

2. Опциональные помощники для больших фич

Перед стартом больших/долгих фич можно предложить пользователю (это помощники, не обязательные артефакты):

• PROJECT_LOG.md — чекпоинты, исследованные пути, промежуточные находки, текущее состояние реализации;
• DECISIONS.md — конкретные продуктовые и технические решения, принятые по ходу.

Предлагать, когда они снизят путаницу или избавят будущих агентов от повторного исследования тех же путей.

3. Один PR на спеки и код

Реализацию по возможности пушить в тот же PR, что и спеки. Итерации по PRODUCT.md, TECH.md и коду идут в одном PR — ревью остаётся привязанным к фиче, которая реально поедет в прод.

4. Держать спеки актуальными (каноническое правило)

Реализация показала, что поведение или дизайн должны измениться, — обновить закоммиченные спеки, а не дать им протухнуть:

• PRODUCT.md — когда меняются пользовательское поведение, UX, edge cases или критерии успеха;
• TECH.md — когда меняются архитектура, последовательность, границы модулей или стратегия валидации;
• обновления спек — в том же PR, что и соответствующие правки кода, сразу при изменении решения, а не «причешем в конце».

PR описывает фичу, которая реально шипится, а не первоначальный черновик спек.

5. Верифицировать против спек

До признания работы завершённой — убедиться, что код соответствует текущим спекам:

• unit-тесты и регрессионное покрытие критичной логики;
• интеграционные/e2e тесты ключевых пользовательских сценариев;
• каждый важный нумерованный инвариант из PRODUCT.md должен отображаться в конкретный тест или шаг проверки из TECH.md.

Связанные скиллы

spec-driven-implementation, write-product-spec, write-tech-spec