sdlc-milestones git:20261103.df4d27aA

Immutable. This exact content never changes and is served at /api/v1/blob/ae8a962407dd2dd9.

---
name: sdlc-milestones
description: Вехи разработки по плейбуку Anthropic «AI-native SDLC» поверх оркестрации агентов — шесть стадий (Plan, Design, Build, Test, Deploy, Maintain), на каждой коммит артефакта (intent.md, spec.md, plan.md, дифф с выводом проверки, PR с ревью, инцидент) и ворота, кто его принимает. Применять при старте фичи или изменения кода, перед наймом исполнителя, перед PR и вливанием, при инциденте, по «зафиксируй веху», «на какой стадии задача», «intent.md», «spec.md», «plan.md», /sdlc-milestones.
---

# Вехи AI-native SDLC

Источник: [The AI-Native SDLC Playbook](https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/6aba736348bdf4f08183f463_AI%20Native%20SDLC%20Playbook_designv2%20(1).pdf), Louis Claxton, Anthropic. Ниже пересказ, приложенный к работе с агентами; за формулировками и примерами идите в оригинал.

Скилл не говорит, как нанимать агентов: это делает ваш режим оркестрации (например, [harness](../harness/SKILL.md) или [fable-ruki-agenty](../fable-ruki-agenty/SKILL.md)). Он говорит, какой артефакт должен лечь в 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](../manager/SKILL.md)).

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

## Шесть вех

| # | Стадия | Артефакт в git | Кто пишет | Ворота: кто принимает | Запускает |
|---|---|---|---|---|---|
| 1 | Plan | `intent.md` | планировщик-лид со слов владельца | владелец правит и принимает | веху 2 |
| 2 | Design | `spec.md` рядом с intent | планировщик-лид по скиллам-политикам | владелец решает спорные места | plan mode |
| 3 | Build | `plan.md`, затем дифф | планировщик-лид в plan mode, исполнитель в worktree | планировщик-лид сверяет план; высокий риск — владелец | исполнителя |
| 4 | Test | вывод проверки в PR | исполнитель, свежий verifier | ревьюер: проверка зелёная, вывод вставлен | PR |
| 5 | Deploy | PR с находками ревью | ревьюер, редакторы | одобрение ревьюера, вливает владелец; прод — по слову владельца | выкладку |
| 6 | Maintain | новый `intent.md` из инцидента + eval | агент мониторинга или дежурный | владелец: чинить сейчас, позже или отклонить | веху 1 |

### 1. Plan — замысел

1. Владелец говорит проблему своими словами; формальный язык не нужен.
2. Агент задаёт вопросы аналитика: рамки, кто затронут, ограничения, как выглядит успех, что не входит (по одному вопросу за раз — см. [grill-me](../grill-me/SKILL.md)).
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-истории (путь к скрипту — от папки скилла):

```bash
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 до владельца — ревьюер.

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

| Веха | Опережающий | Запаздывающий |
|---|---|---|
| 1 | часы от разговора до intent.md | доля intent.md, принятых в веху 2 |
| 2 | время intent.md → spec.md | правки spec.md после первого plan.md |
| 3 | доля PR, влитых с первого прохода | совпадение влитого диффа с plan.md |
| 4 | доля зелёного CI с первого раза | время ревью одного PR |
| 5 | время до первого ревью | дефекты до мержа против дефектов в проде |
| 6 | время от алерта до intent.md | повторные инциденты того же класса |