СРЕЗ 0 · фундамент (свой VCS, свой CI, распил)
Задачи в порядке выполнения (по зависимостям). Каждая задача — отдельная страница.
CI-1 · Done
Свой git-сервер Forgejo — Поднимаем собственный Forgejo (compose-сервис) — свой git-сервер фабрики, вместо внешнего GitHub. Создаём администратора и организацию под будущие репозитории.
зависит от —
CI-2 · Done
Read-бот Forgejo — Заводим служебного «бота» в Forgejo: токен только на чтение репозиториев (read:repository). Используется исключительно для клонирования, кладётся в Vault.
зависит от CI-1
CI-3 · Done
Контракт task_result.json — Договориваемся, как агент докладывает о результате: последним действием пишет файл task_result.json со статусом (success/failed/escalate). Обёртка переводит статус в код возврата 0/1/3; если обязательное расширение недоступно — быстрый отказ с кодом 2 до запуска Goose.
зависит от —
NM-1 · Done
Доставка кода до агента (repo-fetch) — Собираем образ repo-fetch и добавляем prestart-таск в Nomad-джобу агента: код репозитория скачивается и распаковывается ДО старта главного таска, вне сети агента.
зависит от —
CI-4 · Done
Каркас VerificationWorkflow — Создаём каркас единого CI — Temporal-воркфлоу проверки (VerificationWorkflow). Принимает (repo, ref), команду проверки берёт из .meeseeks/project.yml. Это единственный CI, Forgejo Actions не используется.
зависит от —
RS-1 · Done
Распил nomad-dispatch — Выносим общий код запуска Nomad-джоб (dispatch_job_with_meta + идемпотентность по step_id) в отдельный пакет, общий для нескольких продуктов.
зависит от CI-1
NM-2 · Done
Клонирование на HTTPS — Пишем activity клонирования на HTTPS с токеном read-бота: полный клон репозитория (включая .git) складывается в MinIO как тарбол.
зависит от CI-1,CI-2
RS-2 · Done
Распил dev-agent — Выносим identity-образ дев-агента (промпт, скилы, конфиг Goose) в отдельный репозиторий со своим Dockerfile; фабрика ссылается на него по тегу из registry.
зависит от CI-1
CI-5 · Done
CI на верном SHA — Шаг воркфлоу после агента запускает VerificationWorkflow на SHA из task_result.json, а не на «последнем коммите ветки».
зависит от CI-3,CI-4
NM-3 · Done
Пуш, коммит и MR без доступа агента — Агент не получает доступ к репозиторию: коммит и пуш делает poststop-таск той же Nomad-джобы, с эфемерным ключом только внутри него. Агент выдаёт текст коммита и MR через task_result.json, а сам MR создаёт отдельная Temporal-activity после завершения джобы.
зависит от CI-1,NM-2
NM-4 · Done
Составной образ агента — В джобе дев-агента вместо голого identity-образа используется составной (среда репозитория + identity) по тегу из отдельного репозитория.
зависит от RS-2
NM-6 · Done
Различить сбой доставки и провал агента — Учим воркфлоу различать: репозиторий не доехал (инфраструктурный сбой) vs агент отработал плохо. Вводим явный reason — сбой доставки как внешний источник, не самоотчёт агента.
зависит от NM-1
NM-5 · Done
VerificationWorkflow переиспользует repo-fetch — Проверка кода использует тот же механизм доставки, что и агент: клонирует конкретный коммит из шага CI-5, права на запись CI не нужны.
зависит от CI-4,NM-1,NM-2
RS-3 · Done
Распил artifacts-service — Выносим сервис артефактов (models, REST/MCP-фасады, миграции) в отдельный репозиторий; связность с воркером — только по HTTP.
зависит от CI-1
RS-4 · Done
Распил mpstats-mcp — Выносим mpstats-сервис целиком в отдельный репозиторий с версионированным образом в общем registry.
зависит от CI-1
RS-5 · Done
Распил wb-leadmagnet — Выносим телеграм-бот и агентские воркфлоу в отдельный репозиторий со своим compose и Makefile.
зависит от CI-1
RS-6 · Done
Чистка монорепо — Удаляем вынесенные пути из монорепо и выпиливаем их таргеты из Makefile/compose.
зависит от RS-1,RS-2,RS-3,RS-4,RS-5
RS-7 · Done
Общий стенд — Деплоим все репозитории вместе на стенд и настраиваем доступы — каждый контур видит только свои внешние зависимости.
зависит от RS-6,CI-5,NM-4,NM-5
CI-6 · Done
Приёмник webhook Forgejo — Ставим приёмник вебхуков Forgejo: человеческий push или MR запускает или сигналит VerificationWorkflow без участия агента.
зависит от —
СРЕЗ 1 · карта, контур, артефакты, стори, спека
Задачи в порядке выполнения (по зависимостям). Каждая задача — отдельная страница.
CM-1 · Done
Карта кодовой базы — Составляем рукописную карту кодовой базы пилотного репозитория (mr_meeseeks): docs/codebase-map.md, конфиги проверки архитектуры (.importlinter, tach.toml), реестр точек входа, снимки REST/MCP-контрактов.
зависит от —
CM-2 · Done
Онбординг-гейт репозитория — Гейт при онбординге: перед стартом агента проверяется комплектность карты кодовой базы. Карта неполна — агент не стартует, ошибка называет недостающие файлы, reason отличим от провала агента.
зависит от CM-1, DP-1-CM-1,DP-2-NM-6
AS-1 · Done
Схема тела артефакта — Вводим схему тела артефакта: колонки body_json, class, версия рендера; инвариант «ровно одна из форм тела заполнена»; расширяем виды (user_story, task, subtask, test_case, decision, job, repository) и состояния.
зависит от —
AG-1 · Done
consumer/factory в meta джобы — prepare_agent_run получает реальные значения шага (consumer/factory) вместо дефолта «dev-agent» — без этого нельзя запускать спека-агента и ревьюера с верной атрибуцией.
зависит от —
CI-10 · Done
Пакет task-result-contract — Выносим базовый контракт task_result.json в отдельный пакет с публикацией на pypiserver; дев-агент переходит на него по пину версии.
зависит от —
AS-2 · Done
Валидация тела по видам и типизированные ручки — Для каждого вида (task, subtask, test_case, decision, repository) — своя pydantic-модель и своя ручка записи create_* вместо одной create_artifact с union. Валидация живёт в сервисном слое.
зависит от AS-1
AS-3 · Done
Рёбра references и джобы как артефакты — Вводим таблицу связей артефакт→артефакт (отдельно от parent_id) и девять джоб как адресуемые артефакты вида job; ручка create_user_story требует ссылку стори→джоба.
зависит от AS-1, AS-2
IC-1a · Done
Каркас контура identity-service — Создаём репозиторий identity-service: схема субъектов (human, agent_role, agent_run, service), ролей, прав и привязок; чтение ключа подписи из Vault при старте; образ в общем registry по git-тегу.
зависит от —
IC-1b · Done
Токены и admin-поверхность контура — Выпуск и проверка токенов контура, эндпоинт JWKS; ручки admin.subject.write / role.write / grant.write и деактивация субъекта; первый субъект-администратор с правами admin.*.
зависит от IC-1a
IC-1c · Done
Обмен Nomad identity на идентичность запуска — Контур принимает подписанный Nomad JWT аллокации и step_id: проверяет подпись, выводит роль из nomad_job_id, сверяет step_id с meta аллокации через Nomad API. Создаёт запись agent_run с TTL и выдаёт токен идентичности запуска.
зависит от IC-1b
IC-1d · Done
API реплики контура — Версионированный read-only снимок субъектов, ролей, прав и их состояний для локальной проверки; синхронных обращений в контур на каждый запрос нет.
зависит от IC-1b
IC-2 · Done
Пакет-клиент контура — Отдельный пакет identity-client: проверка подписи токена по JWKS, локальная read-only реплика прав, вычисление решения PDP по (субъект, операция, скоуп); публикуется на pypiserver с пином версии.
зависит от IC-1b,IC-1d
IC-3 · Done
Контур на стенде — Деплоим identity-service на стенд, кладём ключ подписи в Vault, заводим людей, роли и службы по текущему фактическому поведению (без сужения прав).
зависит от IC-1a,IC-1b
IC-4 · Done
artifacts-service в режиме наблюдения — Фасады артефактов подключают пакет-клиент контура: разбирают токен, считают решение PDP и пишут его в структурный лог, но запросы не отклоняют. Появляется картина «кто ходит без токена».
зависит от IC-2, IC-3
IC-6 · Done
Блок identity в джобе dev-agent — Nomad-джоба дев-агента получает блок identity: подписанный JWT аллокации с claims (nomad_job_id, allocation_id, task, namespace) доступен таске файлом.
зависит от IC-3
IC-13 · Done
Обмен ключа службы на токен контура — Службы меняют долгоживущий ключ на JWT контура и предъявляют фасадам токен; выпуск идёт тем же механизмом подписи, что идентичность запуска, с typ=service.
зависит от IC-1b, IC-2
IC-7 · Done
Entrypoint агента: обмен на идентичность запуска — Дев-агент до старта Goose предъявляет Nomad JWT и step_id контуру и получает токен идентичности запуска; подставляет его в заголовки расширения artifacts. Недоступность контура — код возврата 2.
зависит от IC-6,IC-1c
IC-5 · Done
Службы предъявляют токен — temporal-worker (заголовок в ArtifactsClient, ключ из Vault) и ci-webhook-receiver предъявляют токен контура. По логу PDP запросов служб без токена не остаётся.
зависит от IC-3, IC-4, IC-13
RA-1 · Done
Identity-образ агента-ревьюера — Собираем отдельный образ ревьюера: без расширения artifacts, без git write и deploy key, CORE неотменяемо запрещает merge/approve/push/edit; явный список расширений; версия git-tag в registry.
зависит от —
SA-1 · Done
Identity-образ спека-агента — Собираем образ спека-агента: слои identity с CORE последним по позиции, явный список расширений (developer + artifacts включены, extensionmanager выключен), версия git-tag, composite-сборка поверх dev-env.
зависит от CI-10
CH-1 · Done
Внесение пакета стори одной командой — Один вызов регистрирует стори целиком: стори, её задачи с порядком, подзадачи и тесткейсы, со связями parent/child. Повторный идентичный вызов возвращает тот же story_id без второй регистрации.
зависит от AS-1, AS-2, AS-3
SA-2 · Done
Диспетч спека-агента и генерация ТЗ — Спека-агент с read-only доступом к репозиторию: на входе пакет задачи и каталог ADR/Решений, на выходе — артефакт spec (draft) с base_sha и версиями источников. Неустранимая развилка — варианты в ТЗ явно, без молчаливого выбора.
зависит от SA-1,CH-1,AG-1,CM-2
SA-3 · Done
Гейт ТЗ — Спека (ТЗ) проходит человека перед разработкой: approve запускает дев-агента на base_sha ТЗ (тело ТЗ — промпт задачи), reject с фидбеком даёт новую версию ТЗ (rework спека-агента), а не правку прежней. Подробнее на странице про <a href="/gate">Gate</a>.
зависит от SA-2
CH-2 · Done
StoryChainWorkflow — Цепочка задач стори: задачи идут строго по очереди, ТЗ следующей не генерируется до мержа предыдущей, стори закрывается следствием прохождения всех задач, остановка несёт причину. Подробнее на странице про <a href="/task-ch-2">StoryChainWorkflow</a>.
зависит от CH-1,SA-3
CI-9 · In Progress
Nomad-диспатч verify-джобы — Проверка кода исполняется не в воркере, а в Nomad-джобе: repo-fetch prestart + dind-сайдкар + verify main-таск. Парсер .meeseeks/project.yml расширен на секции lint.steps / verify.command / test.steps. Подробнее на странице про <a href="/task-ci-9">CI-9</a>.
зависит от CI-4,CI-5,NM-1,NM-5
CI-7 · ToDo
Вердикт CI как commit-status Forgejo — Результат VerificationWorkflow публикуется как commit-status в Forgejo на проверенном SHA. Домен — источник истины, Forgejo — зеркало; публикация отдельной activity с RetryPolicy. Заблокирована CI-9-S2: вердикта пока нет. Подробнее на странице про <a href="/task-ci-7">commit-status</a>.
зависит от CI-5,CI-9
RA-2 · ToDo
Диспетч агента-ревьюера после зелёного CI — После зелёного CI запускается ревьюер: read-only чекаут того же SHA, самостоятельный прогон тестов, отчёт — расширенный task_result.json (verdict, findings), verdict детерминированно по худшей находке. Отчёт персистится и читается эндпоинтом /report.
зависит от RA-1,AG-1,CI-7
RA-3 · ToDo
Гейт «CI зелёный на SHA» в цепочке — Гейт после проверки: pass — code в pending_review, MR у дев-ревьюера; rework — findings на вход fix-промпта дев-агента, потолок общий с fix-циклом; fail — стоп; escalate — человеку.
зависит от RA-2
MT-1 · ToDo
Метрики стори — Выгрузка метрик по стори из task_result.json всех ролей и истории Temporal: доля first-pass, реворки (ТЗ и кода раздельно), минуты внимания человека; атрибуция по consumer/factory. На незакрытой стори — пометка «в процессе».
зависит от AG-1
IC-10 · ToDo
Фасады артефактов в режиме отказа — Запрос без валидного токена отклоняется на REST, MCP и attribution-ручке. Actor выводится из типа субъекта, поле actor уходит из тела запроса.
зависит от IC-4, IC-5, IC-7, IC-9, CM-3
CM-3 · ToDo
Проверка свежести карты в CI — CI проверяет свежесть карты кодовой базы: стадии import-linter/tach в VerificationWorkflow, сверка указателей entrypoints.yml, diff снимков контрактов против живого сервиса.
зависит от CM-1,CI-9
CH-3 · ToDo
Сигнал о судьбе MR — Приёмник вебхука (CI-6) транслирует merged в сигнал перехода StoryChainWorkflow к следующей задаче, а closed без merge — в сигнал остановки цепочки с причиной «закрыт человеком».
зависит от CH-2,CI-6
CI-8 · ToDo
Проверки изоляции в CI-гейте — CI-гейт дополнен проверками, которые раньше предполагались: ветка отдельная, основная не тронута шагом, MR открыт. Каждое нарушение — отрицательный вердикт со своей причиной.
зависит от CI-5,NM-3
GW-1 · ToDo
Chat-gateway: синхронные команды — Telegram-бот: /submit → внесение стори (CH-1), /run → старт цепочки (CH-2), /report → отчёт ревьюера (RA-2), /stats → метрики (MT-1). Апдейт бота маппится в (actor, intent, artifact_ref), chat_id сопоставлен с человеком.
зависит от CH-1,CH-2,RA-2,MT-1
GW-2 · ToDo
Push-канал событий боту — Бот сам пишет человеку о событиях: спека в pending_review, MR открыт с вердиктами, остановка цепочки с причиной, закрытие стори. Доставка идемпотентна по событию.
зависит от CH-2,SA-3,RA-3,GW-1
GW-3 · ToDo
Гейт ТЗ в боте — Кнопки «Апрувить»/«Вернуть с фидбеком» в боте: сверка version с текущей версией спеки до вызова decide_transition, гашение повторного нажатия, приём фидбека следующим сообщением с TTL сессии.
зависит от SA-3,GW-2
IC-9 · ToDo
Человеческий канал в контуре — Субъект типа service для chat-gateway; делегированный токен (sub — человек); привязка chat_id к человеку в контуре. Вердикт от имени бота невозможен: права перехода в approved у service нет.
зависит от IC-3, GW-1, GW-3
PL-1 · ToDo
Пилотный сквозной прогон — Одна стори типового класса задач проходит цепочку целиком через бота: /submit, /run, гейт ТЗ кнопками, push-уведомления, мерж в Forgejo, /stats. Снятые метрики сверяются с ручным подсчётом.
зависит от CH-3,RA-3,CM-3,CI-8,MT-1,GW-1,GW-2,GW-3
ДОЛГ · технический долг
Задачи в порядке выполнения (по зависимостям). Каждая задача — отдельная страница.
DP-1-CM-1 · Done
Поле contract в реестре точек входа — Добавляем в .meeseeks/entrypoints.yml поле contract (rest|mcp|none) и переформулируем применимость снимков контрактов через него вместо эвристики по команде.
зависит от CM-1
DP-2-NM-6 · Done
Быстрый отказ при сбое доставки — Короткий первый порог ожидания (3 минуты) при провале prestart-таски: если ясно, что это сбой доставки (reason=infra_delivery), шаг завершается быстро, а не ждёт все 30 минут.
зависит от NM-6
DP-7-CI-3 · Done
Починка гейта расширения artifacts — Чиним баг: гейт проверки расширения artifacts в entrypoint.sh не срабатывал никогда (кавычки вокруг %{http_code} ломали сравнение). Теперь отказом считаются ненулевой код, пустой вывод и значение 000.
зависит от DP-6-RS-6.1
DP-3-CM-2 · ToDo
Канал доставки диагностики из аллокации — Когда prestart-таск падает, наружу сейчас выходит только код возврата. Нужен механизм, доставляющий текст причины (например, перечень недостающих файлов карты) в лог шага DevPipeline.
зависит от CM-2, DP-2-NM-6
DP-4-CM-1 · ToDo
Сверка каталогов тестов с project.yml — Структурный тест падает при появлении каталога тестов, не покрытого ни одной командой .meeseeks/project.yml; секции приведены в соответствие с реальным деревом.
зависит от CM-1
DP-5-CM-2 · ToDo
Привязка стаб-джоб к боевому HCL — Стаб-джоба интеграционного теста несёт собственную копию prestart-блока; правка боевого dev-agent.nomad.hcl должна ронять тест. Рендер стаба из того же источника либо структурный тест состава блока.
зависит от CM-2
DP-8-RS-6.1 · ToDo
Приёмка уровня образа по контракту слоя — Кейсы проверки собранных образов ролей (состав /opt/agent-layer/, исполнимость goose, доезд новых файлов, обе координаты в registry) — отложены до появления среды с Docker-демоном.
зависит от DP-6-RS-6.1, CM-3
DP-9-RS-6.1 · ToDo
Тегирование repo-fetch и temporal-signal-cli — Образы repo-fetch и temporal-signal-cli переходят на схему тегирования: стабильный тег + тег коммита, гейт неопределённого SHA до вызова docker, координаты :latest уходят из nomad/dev-agent.nomad.hcl и mock-agent.nomad.hcl.
зависит от DP-6-RS-6.1
DP-6-RS-6.1 · Done
Контракт слоя агента — Список копируемых путей в составном образе заменяется контрактом слоя: выделенная стадия собирает /opt/agent-layer/ в dev-agent, Dockerfile.agent сводится к одному COPY, HCL ссылается на стабильный тег. Правило распространяется на спека-агента и ревьюера.
зависит от -
DP-3-RS-6.1 · Done
Контракт task_result.json — в dev-agent — Контракт task_result.json и мост в result.json сводятся к одному определению в репозитории dev-agent; из mr_meeseeks убирается каталог goose/dev-agent и копии тестов.
зависит от RS-6.1, CI-5.1, NM-3.2
Противоречия в таблице
Расхождения между листами проекта, найденные при сверке. Отмечены, потому что влияют на решение, какую формулировку считать верной.
| Что расходится | Где | Суть |
|---|---|---|
| Классы причины остановки цепочки (CH-2) | «Задачи» (CH-2) · «Срезы» (CH-2-S2) · «Подзадачи» (CH-2.3) · «UX-сценарии» (UX-9) · «Решения» (Р-8) | «Задачи» и UX-9 называют три класса (сбой доставки / провал агента / max_rework), «Срезы» CH-2-S2 и «Подзадачи» CH-2.3 — четыре (плюс закрытие MR человеком), а решение Р-8 добавляет пятый — эскалацию (human_verdict_timeout). Сайт показывает четыре из среза + пятый из Р-8. |
| «отдельный процесс» против «маршрут в существующий» | «Срезы» (CH-2-S1) против сайта | Срез CH-2-S1 говорит: эндпоинт — отдельный FastAPI/uvicorn-процесс поверх образа temporal-worker. Мы на сайте уточнили: маршрут добавляется в существующий webhook_receiver. Суть одна — worker остаётся чистым поллером; форма («отдельный процесс» vs «новый маршрут в том же процессе») в таблице не решена однозначно. |
| Подзадача как вид | «Список артефактов» (subtask) · «Решения» (2026-08-17) · лист «Подзадачи» | Решение 2026-08-17 упраздняет подзадачу как единицу (единицей стал срез), но лист «Подзадачи» (171+ строк) существует, и перенос в «Срезы» ещё не выполнен. На сайте задачи собраны по листу «Задачи» — недомолвка не влияет на порядок. |
| Канонический путь репозитория | «Репозитории» (nikell28/<repo>) · «Решения» (2026-09-02 Р-3) | Лист «Репозитории» называет nikell28/<repo>, решение 2026-09-02 — организация meeseeks в Forgejo. Расхождение известное и названное самим решением («лист переписывается отдельным действием человека»). |
Статусы
- готово — задача закрыта;
- в работе — сейчас реализуется (сейчас это в работе — Nomad-диспатч verify-джобы CI-9);
- запланировано — следующая крупная цель (RA-2, RA-3, бот, пилот);
- ДОЛГ — технический долг, не блокирует срезы.