StoryChainWorkflow

Что это за задача

StoryChainWorkflow — следующий срез фабрики: проходит все задачи одной стори по очереди. Сейчас DevPipeline умеет сделать одну задачу от спеки (ТЗ) до кода. StoryChain берёт целую стори — несколько задач — и гонит их последовательно.

Зависит от: CH-1, SA-3.

Главное правило: не перепрыгивать

Цепочка строгая: ТЗ следующей задачи не генерируется, пока предыдущая не смёржена.

• Задачи стори идут строго по очереди, в заданном порядке.
• Следующая задача не начинается, пока предыдущая не закрыта (мерж MR).
• Закрытие стори — следствие прохождения всех задач, а не отдельное действие.

Зачем так строго: задачи стори часто зависят друг от друга — следующая строится на коде предыдущей. Если гнать параллельно, они конфликтуют; если перепрыгивать — следующая не имеет базы.

Остановка несёт причину

Цепочка останавливается не «просто так», а с явной причиной. Классы остановки (четыре из среза CH-2-S2 плюс пятый из решения Р-8):

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

Откуда запускается

Снаружи цепочку стартуют по номеру стори — через новый endpoint (его пишем в срезе 1). Вход — идентификатор стори (артефакт kind=user_story), а не список задач: порядок задач workflow узнаёт сам. story_id детерминирован (uuid5 от координаты + заголовка, решение 2026-08-17) — поэтому workflow_id цепочки детерминирован от story_id, и повторный запуск той же стори не создаёт второй цепочки.

# вход извне — один идентификатор стори
handle = await client.start_workflow(
    StoryChainWorkflow.run,
    "story-uuid-…",        # id стори (артефакт user_story)
    id="story-chain-1",
    task_queue="dev-factory",
)

Как это ложится на уже готовое

StoryChain не строит механизм заново — он переиспользует готовые части:

Тесткейсы

Кейсы, привязанные к этой задаче в листе «Тесткейсы» (колонка «Единица бэклога»):

Срезы CH-2

Задача разбита на три среза — каждый делает свой шаг к цепочке. Статус ToDo: это план, а не результат.

Связанные задачи

Полный контекст CH-2 по всем листам таблицы: задачи-соседи, подзадачи, срезы, решения, UX-сценарии и UX-контракты. Всё, чтобы сделать CH-2 целиком по всем репозиториям.

Задачи-соседи (лист «Задачи»)

Подзадачи CH-2 (лист «Подзадачи»)

Подзадачи CH-3: CH-3.1 (приёмник парсит pull_request и маршрутизирует сигнал: merged → переход, closed без merge → остановка «закрыт человеком»), CH-3.2 (оба исхода MR руками в Forgejo).

Срезы CH-2 и соседей (лист «Срезы», репозитории)

Решения, на которые опирается CH-2 (лист «Решения»)

UX-сценарии и UX-контракты

Репозитории

nikell28/mr_meeseeks — основная работа CH-2: StoryChainWorkflow, domain/failure_reason.py (4 класса причины), facade-эндпоинт в webhook_receiver.py (CI-6), тесты. nikell28/artifacts-service — входные данные CH-2: пакет стори, порядок задач (CH-1-S1), spec с base_sha (SA-3). meeseeks/chat-gateway — потребитель исхода CH-2 (GW-1: /run, GW-2: push об остановке/закрытии), заводится IC-9.

Открытые вопросы CH-2-S1

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

Что уже решено (из таблицы и сайта)

• Срез стартует и берёт первую задачу стори → запускается DevPipeline (спека → код → MR).
• Эндпоинт — маршрут в существующий webhook_receiver (ci-webhook-receiver, порт 8300), не новый процесс.
• Ответ: chain_id (= workflow_id) + первая задача. Вызов синхронный.
• Повторный вызов → тот же chain_id, второй цепочки не создаётся.
• Порядок задач читается из пакета стори (artifacts-service), однозначно.

Вопрос 1. Как эндпоинт узнаёт первую задачу?

Сначала — что уже есть и чего ещё нет, чтобы вопрос был понятен.

• Задачи стори уже упорядочены и лежат в базе. CH-1 записал стори и её задачи в artifacts-service; у каждой задачи есть поле order (1, 2, 3…). Сервис умеет их отдать по порядку (list_story_tasks).
• DevPipeline сейчас делает одну задачу, а не стори. Его вход — spec_id/task_id одной задачи: спека (ТЗ) → код → MR. Про стори и порядок он не знает.
• Кода, который читает задачи стори и гонит их по очереди, сейчас нет. Это и есть CH-2: новый workflow StoryChainWorkflow принимает story_id, читает задачи по порядку из artifacts-service и берёт первую.

Вопрос в одном месте: внешний вызов POST /story-chains должен в ответе вернуть «первая задача» — откуда эндпоинт возьмёт её, чтобы ответить?

Решено: A — эндпоинт стартует workflow и спрашивает у него через query. Эндпоинт workflow создаёт — он же у него и читает. Сам в сервис не ходит.

Вопрос 2. По какому адресу дёргать эндпоинт?

Конкретики в таблице нет — берём вариант по рекомендации: POST /story-chains.

• A — POST /story-chains (рекомендация)
• B — POST /story-chains/start
• C — POST /run

Вопрос 3. Как выкладывать на дев-стенд?

Решено: для задачи CH-2 заводим одну большую ветку с именем вида ch2-implementation — в каждый затронутый репозиторий пушим свою копию этой ветки с изменениями. Когда будем тестировать на дев-стенде, подтягиваем все эти ветки, а на мастере разбираемся, как возводить контейнеры.

Баги

Известные проблемы, найденные при проверке поведения на дев-стенде. Не блокируют CH-2-S2/S3 (барьер работает от сигнала, а не от самого MR), фиксируются отдельно.

Связи