кейс · разработка # Сквозная разработка: от идеи владельца до принятого кода Так у нас идёт разработка. Владелец подкидывает идею — а дальше её раскачивают, формализуют, планируют, раскладывают на дерево задач и делают волнами агентов, а агенты разных движков критикуют и ревьюят каждый шаг. Каждый шаг — задача в SKEIN, к которой приложено всё: решения, исследования, раунды критики, файлы. Весь путь от идеи до принятого кода можно отследить. Слияние и деплой остаются за человеком. **«Хочу, чтобы…»** идея, иногда одной фразой **Отвечает на вопросы** 3–5 за ход, у каждого варианты и рекомендация постановка **Раскачка задачи** zask **Разведка** код, интерфейс, права, похожие фичи **Черновик постановки** допущения подсвечены **Опрос по рубрикам** цель, поведение, границы, интерфейс до иконки, права *батч 1* **zask-ready** или zask-gaps с пробелами Технические вопросы zask не решает. Пишет «решают разработчики». 1. *коммент* `[исходная формулировка]` снимок до правки 2. *задача* `[zask] Повтор платежа` переписана на месте 3. *метки* `zask` `zask-gaps` 4. *описание* ответы `Q → A` после каждого батча 5. *метка* `zask-ready` 6. *связи* `related`, дубли закрыты **Отвечает батчами** и задаёт конфиг: кто пишет, кто критикует этап 1 **Опрос и сбор контекста** zdox **Ведущий** Claude, Codex или Grok **Разведка репозиториев** свежие копии, реальный код **Рекап понимания** при auto решает, нужны ли спека и план ⟦zdox-config⟧ critics.spec = grok, codex, fable · stage3.author = grok · stage4.author = codex · critics.review = grok, codex 1. *захват* головная `sk-412` · in_progress 2. *метка* `zdox` и коммент «взята прогоном» 3. *описание* рекап и реестр исходных задач 4. *эпик* «Планирование» **Решает развилки** критики помечают их `[USER-DECISION]`, приходят одним батчем **СТОП-вопросы** новая зависимость, сервис, ломка контракта этапы 2–4 **Спека, план, тест-план** zdox спека **пишет ведущий** что, зачем, контракты *круг 1* grok codex fable READY-FOR-PLANNING план **пишет grok** потоки и группы *круг 1* grok codex PLAN-READY тест-план **пишет codex** матрица покрытия *круг 1* grok codex TESTS-READY Критики работают параллельно. Каждую находку ведущий сверяет с источником. Движок, не давший своих находок, со следующего круга снимают. 1. *задача* «Этап 2 · Спека» 2. *задачи* «Критика раунд N» → по одной на движок 3. *вложение* `spec-r1-grok.md` лог каждого критика 4. *коммент* «codex#3 отклонено, потому что…» 5. *вложение* `spec.md` 6. *вложение* `plan.md` и логи кругов 7. *вложение* `tests.md` и логи кругов 8. *коммит* один круг критики = один коммит этап 5 **Дерево задач** zdox **заводит grok** тело задачи: выдержка спеки, приёмка, тесты *круг 1* **критик полноты codex** требование → задача → тест, без дыр 1. *эпик* «Реализация», группы G0…G3 2. *задачи* каждая со спекой, приёмкой и тестами в теле 3. *связи* `blocks`: граф зависимостей 4. *вложение* `tasks-analyze.md` и лог критика 5. *эпик* «Ревью кода» **Решает, если ревью не сходится** два круга без улучшения или критикалы после третьего **Смотрит в любую сессию** `tmux attach` этап 6 **Волны разработки** zdox · zagents · zcoderev Один исполнитель на репозиторий. Это живая сессия агента в tmux, она ведёт все волны своего потока. G0 · общий контракт: остальные ждут **skein-api** [сокол] · tmux волна 1 ревью фикс ⟲ волна 2 ревью поток готов **skein-web** [ворон] · tmux волна 1 ревью волна 2 ревью фикс ⟲ поток готов **skein-frontend** [рысь] · tmux волна 1 ревью фикс ⟲ ревью волна 2 поток готов **Задача → коммит** захватил, сделал, один коммит, закрыл. В конце волны тесты **Ревью волны · zcoderev** ревьюеры под стек: go, typescript, html-css… codex grok *круг 1* **Триаж и фикс** больше двух критикалов: ещё круг по фиксам **сокол** Поле обязательно или нет? Жду ответа. **ведущий** Обязательно, см. ИНВ-3 в спеке. 1. *коммент* реестр: `сокол / sokol · skein-api` 2. *захват* `[сокол]` в заголовке задачи 3. *коммит* одна задача = один коммит 4. *закрыта* `[агент сокол · волна 412/api/1]` 5. *коммент* сводка волны, «Волна 1» в заголовке группы 6. *задачи* `[coderev]` по одной на движок, отчёт вложением 7. *закрыта* таблица находок critical / warning / info 8. *коммент* `[круг ревью] волна 412/api/1 · круг 2` 9. *коммент* `[ретро]` исполнитель пишет трение сразу 10. *коммент* `[набор] skein-api · волна 2` тесты волны **Решает, если красное не уходит** после трёх кругов этап 7 **Финальные тесты и приёмка** zdox **Сверка контрактов** между потоками **Все integration и e2e** красное чинит исполнитель этого потока **Мутационный прогон** выжившие мутанты по одному **Приёмка** исходные задачи владельца 1. *коммент* `[сверка контрактов]` пункты, круги 2. *коммент* `[mutation]` выжило, пробелы, фиксы 3. *закрыта* исходные задачи с коммитами 4. *закрыто* дерево снизу вверх, головная последней **Принимает правки скилла** ретро только предлагает **Слияние и деплой** ветки zdox не трогает этап 8 **Ретроспектива** zdox **Журнал трения** записи `[ретро]` со всех этапов **Числа прогона** волны, круги, сходимость критики **Предложенные правки** файл, раздел, текст 1. *задача* ретро в эпике ретроспектив, связь с головной 1. **Идея.** Владелец пишет, чего хочет. Иногда одной фразой. 2. **Разведка.** zask сначала читает код и интерфейс, чтобы не спрашивать то, что там уже видно. Потом пишет черновик постановки. 3. **Опрос.** Вопросы идут батчами по 3–5, у каждого варианты и рекомендация. После каждого батча ответы ложатся в описание задачи. 4. **Вердикт.** Блокирующих пробелов нет, поэтому метка zask-ready. Технические решения остаются разработчикам. 5. **zdox берёт задачу.** Захватывает её, читает конфиг прогона, смотрит репозитории и задаёт владельцу свои вопросы. Рекап пишется в описание. 6. **Спека.** Ведущий пишет её сам: что делаем, зачем, контракты и инварианты. Несущие решения проверяет спайком. 7. **Критика спеки.** Критики трёх движков читают спеку параллельно. Ведущий сверяет находки с источником, правит и запускает новый круг. Продуктовые развилки уходят владельцу. 8. **План.** План пишет другой движок. Он режет работу на потоки по репозиториям и на группы задач. Его тоже критикуют кругами. 9. **Тест-план.** Каждому требованию свой тест и момент прогона: в волне или в финале. И снова круги критики. 10. **Дерево задач.** План переносится в SKEIN задачами с зависимостями. Критик полноты проверяет, что ни одно требование не потерялось. 11. **Исполнители.** На каждый репозиторий поднимается одна сессия агента в tmux. Репозитории идут параллельно, внутри репозитория строго по порядку. 12. **Волна.** Исполнитель берёт группы задач целиком: захватил, сделал, один коммит, закрыл. В конце волны гоняет тесты. 13. **Ревью.** Волну проверяет zcoderev: Codex и Grok параллельно, ревьюеры подобраны под стек. Каждый движок пишет отчёт в свою задачу. 14. **Фиксы.** Подтверждённые находки чинит тот же исполнитель. Больше двух критикалов значит ещё круг ревью. Ревью не сходится, тогда решает владелец. 15. **Вопрос вместо догадки.** Наткнулся на неясность, исполнитель спрашивает ведущего и ждёт. Человек может открыть любую сессию и смотреть. 16. **Следующие волны.** Новая волна начинается после ревью предыдущей. Потоки друг друга не ждут, кроме задач с общим контрактом. 17. **Финал.** Сверка контрактов между потоками, все integration и e2e, мутационный прогон. Красное чинит исполнитель того потока. 18. **Приёмка.** Исходные задачи владельца закрываются с коммитами. Дерево закрывается снизу вверх, головная последней. 19. **Ретро.** Трение записывали по ходу. Ретро собирает его и предлагает правки скилла, а принимает их человек. Слияние и деплой тоже за ним. 20. **Всё в SKEIN.** От фразы владельца до последнего коммита: задачи, круги критики, отчёты ревью, решения и вопросы. Любой шаг можно найти и открыть. ## Задач — очень много. И это нормально. На одну задачу, поставленную владельцем, в SKEIN вырастает дерево, в котором задач больше, чем вы прочитаете за вечер. Это не беда, а норма работы через агентов: агенты раскладывают работу подробно, потому что им так удобнее её делать и проверять. дерево одной задачи владельца: задачи · эпики · закрытые Человека это не накрывает: задачи, которые агент разложил сам, не превращаются в поток уведомлений. Вам приходит только ваше — а дерево ждёт, когда вы спросите «Эй, агент, как там дела?». ### Что видно постфактум - У каждой задачи — происхождение: человек, агент по поручению или агент сам. - Каждое действие привязано к сессии агента: от строки в аудите можно дойти до его чата. - Решения, исследования и раунды критики приложены к задачам, а не разбросаны по чатам. - Коммиты привязаны к задачам; итог закрытия честный: done, won't do, duplicate, superseded. Так мы делаем SKEIN самим SKEIN — и всё остальное тоже. ← Все кейсы Кейс: поддержка →