Вехи AI-native SDLC

Источник: The AI-Native SDLC Playbook, Louis Claxton, Anthropic. Ниже пересказ, приложенный к работе с агентами; за формулировками и примерами идите в оригинал.

Скилл не говорит, как нанимать агентов: это делает ваш режим оркестрации (например, harness или fable-ruki-agenty). Он говорит, какой артефакт должен лечь в git до перехода к следующей стадии.

Главная мысль плейбука: каждая стадия кончается коммитом артефакта, который читает следующая стадия; цепочка коммитов и есть журнал аудита — кто попросил, что сделал агент, кто одобрил. Внимание человека стоит на воротах: он принимает артефакт, подготовленный агентом, и не начинает стадию с нуля.

Роли

• Владелец задачи — человек, который ставит задачу и принимает ворота 1, 2 и 5 (вливание и прод).
• Планировщик-лид (вехи 1–3) — агент, который пишет intent.md, spec.md и plan.md, носит их владельцу на принятие, нанимает исполнителя только после закоммиченного plan.md и сверяет вехи скриптом. Отдельного агента нет — эту роль берёт оркестратор сессии или встроенный агент планирования харнеса (в Claude Code — Plan).
• Исполнитель — агент в своём worktree, работает по plan.md.
• Ревьюер (вехи 4–5) — агент, который не писал этот код: сверяет дифф с plan.md, требует вывод проверки в PR и порядок «падающий тест, потом починка», ставит одобрение, после которого PR видит владелец.
• Веха 6 и веха 1 следующего круга снова у планировщика-лида: диагноз инцидента он оформляет новым intent.md.

Где лежат артефакты

В репо, где живёт код задачи, папка intent/<YYYY-MM-DD>-<slug>/:

intent/2026-11-03-claims-status/
  intent.md    # веха 1 — что и зачем, словами автора
  spec.md      # веха 2 — требования и дизайн, спорные места
  plan.md      # веха 3 — файлы, порядок, риски, чем доказано
  lessons.md   # веха 6 — только если был инцидент

Шаблоны — templates/. Дифф, тесты и ревью живут в PR. Issue задачи ссылается на папку; в issue после каждой вехи строка Веха N · <артефакт> · <sha> (как вести issue — скилл manager).

Масштаб. Правка в один-два файла без решений по дизайну проходит короткой цепочкой: замысел — в теле issue, план — в описании PR, вехи 4–5 обязательны. Полная папка — для фичи, нового модуля, изменения данных, денег, доступа или всего, что трогает несколько репо.

Шесть вех

1. Plan — замысел

1. Владелец говорит проблему своими словами; формальный язык не нужен.
2. Агент задаёт вопросы аналитика: рамки, кто затронут, ограничения, как выглядит успех, что не входит (по одному вопросу за раз — см. grill-me).
3. Агент пишет intent.md по шаблону: Problem, Proposed outcome, Affected users and systems, Constraints, Open questions; автор и статус в шапке.
4. Владелец правит то, что агент понял неверно. Его решение с датой — в intent.md.
5. Коммит в репо задачи. Веха закрыта, когда intent.md в origin/main или в принятом PR.

2. Design — спека

1. Агент читает принятый intent.md и пишет spec.md: требования и дизайн одним проходом, в рамках скиллов-политик проекта (бренд и вёрстка, правила текста, безопасность, данные людей).
2. Спорные места — отдельный раздел: где политики противоречат друг другу или intent.md молчит. Каждое — вопрос владельцу нумерованным пунктом.
3. Открытые вопросы intent.md закрыты или явно перенесены.
4. Коммит spec.md рядом с intent.md. Пара фиксирует, что просили и что решили.
5. Принятие spec.md владельцем запускает веху 3; без него сборка не начинается.

3. Build — план и сборка

1. Планировщик-лид в plan mode читает intent.md, spec.md и код, ничего не меняя, и пишет plan.md: Files that change, Order of work, Risks, Proof.
2. Допрос плана: что сломается, какой шаг самый рискованный, какие варианты отброшены и почему.
3. План готов, когда исполнитель, не видевший разговора, реализует его по одному файлу. Коммит plan.md до первой строки кода.
4. Исполнитель работает в своём worktree по плану. Разошёлся с планом — правит plan.md в том же коммите.
5. Знание проекта — в AGENTS.md/CLAUDE.md репо: команды сборки, тестов, линтера, соглашения, «что агент делает не так». Агент дважды ошибся одинаково — правка идёт в AGENTS.md, не в бриф.
6. Повторяющееся единообразное знание оформляется скиллом; то, что должно выполняться без исключений, подпирается хуком (защищённые пути, секреты в диффе, форматтер).

4. Test — цикл обратной связи

1. В брифе исполнителя измеримая цель проверки: «тесты в test_x.py зелёные», «скриншот 1440×900 совпадает с макетом», «эндпоинт отдаёт 200 с новым полем».
2. Проверка запускается одной командой (make test, npm test); она перечислена в AGENTS.md с примером нормального вывода.
3. Баг: сначала падающий тест, коммит теста, потом починка без правки теста. Тестовые файлы во время починки агент не трогает.
4. Интерфейс: реализовать, снять скриншот, сравнить, поправить — два-три круга.
5. «Готово» = дословный вывод проверки вставлен в отчёт и в PR. Финальная проверка — свежий verifier-субагент, который только запускает и докладывает, ничего не чиня.
6. Изменения AGENTS.md, скиллов и хуков, которые направляют агентов, проверяются набором evals так же, как код: инцидент даёт новый eval.

5. Deploy — ревью и ворота

1. PR ссылается на intent/spec/plan. Ревью проходами: баги, безопасность, соответствие spec.md и plan.md. Important — ломает поведение, данные или политику; остальное nit, не больше пяти.
2. Автор кода не одобряет свой код. Ревьюер сверяет объём с plan.md и проверяет, что вехи 1–4 закрыты; для текстов — ещё редактор; владелец видит PR только после одобрения ревьюера.
3. Находку, которая повторилась во втором ревью, чинят в AGENTS.md репо.
4. Агент доходит до ворот прода и не проходит их: выкладка в прод, миграции, деньги, наружные сообщения — только по слову владельца на это действие. Откат — отрепетированная команда, известная до выкладки.
5. Веха закрыта мержем; задача закрывается после мержа, не по ветке.

6. Maintain — замыкание цикла

1. Триггер — алерт, сообщение пользователя, падение CI, ошибка в проде.
2. Обнаружение детерминированное (скрипт по метрике и порогу), модель диагностирует. Уровни: 1σ — лог, 2σ — диагноз только на чтение, 3σ — PR в ворота ревью или заранее одобренный ранбук.
3. Диагноз записывается как новый intent.md (аномалия и доказательства, желаемый результат, затронутые системы, открытые вопросы) и идёт по циклу с вехи 1.
4. После починки — eval или регрессионный тест на этот инцидент и строка в lessons.md.

Фиксация вехи

Веха считается пройденной, когда выполнены оба условия:

1. Артефакт закоммичен и запушен (sha есть в origin).
2. В issue задачи строка Веха N · <артефакт> · <sha> · принял <кто>; на вехе 5 issue закрывается после мержа.

Если вы ведёте задачи ещё и в трекере агентов, обновите там запись тем же sha.

Статус папки по git-истории (путь к скрипту — от папки скилла):

python3 <папка скилла>/scripts/milestones.py <repo>/intent/<дата>-<slug> [--pr owner/repo#N]

Скрипт печатает по каждой вехе: есть ли артефакт, первый и последний коммит, автор, и следующие ворота. Он же считает показатели плейбука: время intent → spec → plan → мерж и правки spec.md после первого коммита plan.md (переделка требований во время сборки). Флаг --pr читает состояние PR через gh.

В оркестрации

• В чек-листе этапов пункты — это вехи: ✓ 1 intent, ✓ 2 spec, ← сейчас 3 plan, …
• Бриф исполнителю ссылается на plan.md и называет проверку вехи 4; без закоммиченного plan.md исполнителя на код не нанимать.
• На доске задач карточка показывает номер текущей вехи.
• Ворота людей: вехи 1, 2 и 5 (вливание и прод) — владелец; веха 3 — планировщик-лид, высокий риск — владелец; вехи 4–5 до владельца — ревьюер.

Как понять, что работает