Готовится первый выпуск. Он ещё не объявлен

Довести намерение до результата, который можно принять

Planveyor организует работу ИИ над проектом. Цель ставит человек, задачу ведут роли Architect, Planner, Coder и Reviewer. Работу они передают через файлы в репозитории — план, черновик кода и ревью, — чтобы результат можно было проверить по ним, не читая переписку с моделью.

Как устроен процесс Пример реальной задачи

Путь плана Статус в шапке плана показывает, чей сейчас ход

Owner задаёт цель и ограничения, отвечает на вопросы ролей

Architect цель, границы и критерии приёмки Architect initial draft
Planner черновик кода: точные файлы и проверки Ready for Planner
Coder код, тесты и доказательства Ready for Coder
Reviewer две линии ревью: риски и соответствие задаче Ready for Review
Architect Arch review: решение о приёмке Ready for Arch review
Owner смотрит набор файлов и разрешает коммит close --commit → Done

Managerпо статусу плана запускает следующую роль. Oracle проверяет статус, маршрут и свежесть ревью; переход разрешают квитанции и проверки закрытия. После коммита роли закрывают документы задачи.

01Откуда появился продукт

Процесс вырос из задач

Planveyor вырос из закрытого промышленного стека разработки с ИИ. Планы, роли и проверки закреплялись по мере работы над реальными изменениями.

Октябрь 2025Продуктовая разработкаЗакрытый продукт
Февраль 2026Роли, планы, проверкиЗакрытые инструменты разработки
Сентябрь 2026PlanveyorНейтральное ядро и контракт для других репозиториев

Общее отделили от стекаВ Planveyor остаётся процесс. Код продукта, команды проверки и окружение принадлежат конкретному проекту.

02Задача продукта

От намерения до проверенного результата

Planveyor связывает работу ИИ-ролей явной задачей, границами изменений и проверяемыми передачами.

01ЦельЧто нужно получить
02ДоговорённостьЧто меняем и как примем
03ИсполнениеКод, документы и проверки
04ПриёмкаРевью, решение и Git

Вход

Намерение человека

Владелец продукта (Owner) задаёт результат, ограничения и важные решения. Неясности превращают в вопросы и записанные решения.

Работа

Каждый шаг оставляет след

Следующая роль получает план, точные файлы и доказательства предыдущего шага. От статуса зависит, что можно делать дальше.

Выход

Проверенное изменение

Согласованный diff, актуальные результаты проверок, замечания и решения по ним, точный набор файлов в коммите.

Для новой роли контекст должен восстанавливаться из артефактов, а не из памяти предыдущего чата.

Содержательную работу делают модели. Скрипты Planveyor следят за формальными условиями: можно ли передать работу дальше, на месте ли нужные файлы и не устарели ли проверки.

Один процесс для разных задачНовая функция продукта, исследование, декомпозиция, изменение самого процесса.

03Путь задачи

Ролевая модель: от постановки до приёмки

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

Роль	За что отвечает	Что создаёт или обновляет
Owner	Цель, ограничения, спорные решения, разрешение на интеграцию	Ответы и принятые решения; настройки клиента и стека
Architect	Смысл задачи, границы, архитектура, критерии приёмки	План, решения и вопросы; Arch review с решением о приёмке
Planner	Исполнимость и полнота шагов	План и черновик кода: точные файлы, изменения и проверки
Coder	Изменить разрешённые файлы и проверить результат	Код и тесты; результаты команд и ссылки на отчёты
Reviewer	Проверить риски и соответствие договорённости	Проверка рисков; единое ревью с замечаниями и общим выводом
Manager	Выбрать допустимое продолжение и отследить передачу	Следующий шаг и открытые вопросы; координационные записи

До исполнения

Договориться о результате

Architect фиксирует решение и критерии приёмки. Planner уточняет файлы, действия и команды проверки.

На передаче

Подтвердить готовность

Роль обновляет документы и доказательства. Oracle только читает статус и ограничения плана. Manager сверяет результат и выбирает допустимый запуск.

При проблеме

Вернуть ответственной роли

Смысловой пробел — Architect. Недостающие шаги — Planner. Ошибка реализации — Coder. Возвращают по текущему статусу плана.

Обычный план принимает Architect. Когда роли запущены командами planveyor sibling, они не коммитят: Owner смотрит подготовленный набор файлов и подтверждает коммит, а команда закрытия переводит план в Done. Если роли запущены напрямую, без этих команд, коммит принятого набора делает Architect. Push и публикацию всегда делает Owner.

Память процесса

Пять артефактов одной задачи

На примере SQL-задачи видно, что передаёт каждый артефакт.

План

Найти активные товары, которым нужно пополнение. Учесть уже заказанные единицы.
Architect → Planner: цель, границы, критерии и вопросы
Черновик кода

Какие SQL-файлы и тесты меняем; как собираем, проверяем и принимаем.
Planner → Coder: точные файлы и план исполнения
Доказательства

Что запускали, какой код проверяли, результат и где лежат доказательства.
Coder → Reviewer: команды, отчёты и снимки
Ревью

Какие риски найдены, выполнены ли требования, что ещё нужно исправить.
Reviewer → Architect: риски, контракты и общий вывод
Закрытие задачи

Как разрешены замечания и какой проверенный набор файлов принят.
Architect: приёмка; коммит подтверждает Owner (в SQL-задаче 28.09 коммиты сделал Architect)

Если проверяемые файлы изменились, доказательства обновляют: старый зелёный отчёт автоматически не переносится.

04Как идёт работа

Тип задачи определяет контур исполнения

Для неопределённой задачи нужен анализ, для большой — декомпозиция. Ограниченное изменение можно сразу вести в контуре разработки. Исследование и разбиение дают собственный проверяемый результат до начала реализации.

Разработка

Сделать ограниченное изменение

Вход:: понятные границы и критерии.
Работа:: Architect → Planner → Coder → Reviewer → Arch review.
Выход:: реализация, актуальные проверки и принятые изменения.

Анализ

Снять неопределённость

Вход:: вопрос, неизвестные и границы исследования.
Роли:: Architect ставит вопрос, Planner выбирает способ проверки, Coder исследует, Reviewer проверяет выводы.
Выход:: отчёт и решение: разработка, декомпозиция, вопрос Owner, отложить или отклонить.

Декомпозиция

Разделить большую задачу

Вход:: инициатива, которую нельзя безопасно исполнить одним изменением.
Роли:: Architect задаёт цель, Planner — контракты частей, Coder пишет дочерние планы, Reviewer проверяет качество.
Выход:: дочерние планы, зависимости и решение о запуске.

Контур выбирают явноАнализ и декомпозиция уже есть. Хранение пакета анализа и запуск дочерних планов ещё дорабатываются.

Запуск

Способ запуска выбирает Owner

От режима зависит, кто организует переходы между сессиями; роли и критерии приёмки не меняются.

Вызов ролиНапример: продолжить работу Coder
Подготовленный входПроект, план, инструкция и сессия
ИИ-клиентCodex CLI выполняет этот шаг Coder
Результат вызоваВывод сессии и технический итог

Обёртка и runtime

Обёртка (wrapper) готовит вызов роли и задаёт проверяемый вход: сама подставляет инструкцию, выбранный проект и способ продолжения сессии, чтобы их не приходилось собирать вручную. Runtime проверяет, допустим ли запуск сейчас, создаёт или продолжает нужную сессию и связывает запуск, задачу и сохранённый вывод.

Успешный запуск — ещё не приёмка

Клиент выполнил вызов и вернул результат. Чтобы принять задачу, роли ещё проверяют файлы, тесты и замечания ревью.

По шагам

Запускать выбранную роль

Owner выбирает проект и план, запускает нужную роль и читает её результат. Этот режим удобен, когда переходы нужно контролировать вручную.

Координация

Передать маршрут Manager

Manager читает состояние плана, организует следующий допустимый шаг и проверяет передачу результата. Открытые вопросы он возвращает Owner.

Настройка

Выбрать ИИ-клиент

Owner задаёт клиент, аккаунт, модель и настройки рассуждения. В отдельных сессиях Codex CLI доступен всем ролям, Claude Code — Planner и Reviewer при явном выборе.

Команды Owner planveyor sibling init→скилл плана→architect / answer→run→close→close --commit→run→close→ready

Скилл плана — инструкция агенту, который заводит план; второй run — закрытие документов. Обычный запуск проекта, planveyor sibling run, поднимает роли как субагентов Codex. Режим выбирают явно: Manager не должен сам менять проект, клиент или источник доступа. Полное восстановление прерванного Manager пока не реализовано, оно запланировано после первого выпуска.

05Проверка и приёмка

Две линии Reviewer и Arch review

Это две последовательные линии одной роли Reviewer. После их общего вывода решение принимает Architect.

Файлы и доказательстваРискиТребованияArch review

Reviewer · первая линия

Риски реализации

Корректность, ошибки, данные, права, крайние случаи и достаточность тестов. Замечания привязывают к конкретным проверяемым файлам.

Reviewer · вторая линия

Соответствие задаче

Проверяет согласованность плана, технического решения, кода, интерфейсов и документации. Учитывает первую линию и собирает единый вывод.

Architect

Решение о приёмке

Возвращает работу на исправление нужной роли. Критические замечания блокируют приёмку; по остальным нужно явное решение. Когда блокеры устранены, подтверждает результат.

Проверка передачи до ревью. Скрипты проверяют полноту артефактов. CENSOR — повторный проход Architect, Planner или Coder по своим артефактам перед передачей; применимость зависит от режима.

Финальная фиксация: актуальное ревью → проверка принятого набора файлов → завершение плана → сохранение той же версии → закрытие документов.

Зелёный CI — доказательство, но не достаточное само по себеРоли смотрят, какой код проверяли и что именно прошло.
Самоотчёт модели может быть доказательством, но не отменяет проверкуРезультат проверяет отдельная линия ревью.
Доказательство привязано к версии файловИзменились проверяемые файлы — проверки повторяют.

СлияниеПосле слияния: сохранить результат и разобрать остатки

Разбор начинает Owner: он указывает завершённые планы и объединённые изменения, дальше работу организует Manager.

Аудит

Проверить итог целиком

Architect связывает требования с итоговым кодом, проверками, документацией и ревью. Для интерфейса нужна визуальная проверка.

Последующие задачи

Решить, что делать дальше

Незавершённую работу оформляют отдельно. Предложения по улучшению процесса называют PI: их разбирают, выбирают решение и фиксируют в документации.

Память проекта

Сохранить нужные знания

Manager организует архивирование и готовит список временных планов и ревью для очистки. По текущему процессу Owner выбирает и удаляет их отдельным шагом.

В первой версии проверка после слияния работает в самом Planveyor; в sibling для неё пока нет команды.

06Свой проект

Sibling — отдельный продуктовый репозиторий

Sibling хранит продукт, стек и окружение отдельно от Planveyor и адаптирует общий процесс к своему продукту.

Общее ядро · Planveyor

Процесс и инструменты

Роли, инструкции, этапы и шаблоны документов
Runtime, обёртки и проверки процесса
Версия общих правил и описание изменений

Контрактдоставленные правила и шаблоны

Внешний runtimeинструменты запуска для выбранного проекта

Sibling · например, MS SQL

Отдельный проект

Собственный репозиторий, планы, код и тесты
Полученные общие и собственные локальные правила
Команды сборки, тестов и ограничения среды

Граница ответственностиПроект управляет своим окружением, клиентскими аккаунтами и доступом к данным. Planveyor предоставляет процесс и инструменты.

Сценарии

Что происходит между ядром и проектом

Сценарий зависит от того, где возникла задача и какой результат нужен. Изменения только своего продукта или стека проект делает внутри sibling.

Создание init

Создать проект с выбранным стеком

Init создаёт процессный каркас. Первая задача проекта — адаптация: Owner заводит её план скиллом плана, а роли согласуют назначение проекта и готовность стека — команды сборки и тестов, допустимую среду, ограничения работы с данными и нужные доказательства. Первую полезную задачу Owner ставит после адаптации отдельным поручением, обычным планом.

Для MS SQL: собрать SQL-проект → проверить допуск к тестовой БД → применить схему → выполнить SQL-тесты → сохранить отчёт.

Обновление upgrade

Принять новую версию общих правил

Owner выбирает новую версию Planveyor. Сначала обновляется отдельная копия проекта: конфликт останавливает замену, выделенные локальные секции защищены от перезаписи. Затем роли проходят план адаптации и проверяют, что процесс работает с этим стеком.

Успешный перенос файлов сам план адаптации не закрывает. Сквозной переход с версии на версию на нынешних командах ещё не проверяли: это запланировано после выпуска.

Предложение ядру upstream

Передать общую проблему процесса

Роль проекта готовит запрос: симптом, план и ссылки на доказательства, предложение и объяснение, почему проблема общая. Документированный канал — GitHub Issues: туда запрос отправляет Owner. Решение принимает Architect ядра; принятое исправление возвращается в проект новой версией и проходит локальную адаптацию.

Адресный пакет rollout

Отдельное изменение одному проекту

Один пакет — одно адресное изменение с основанием. Принимающий проект сам выбирает решение. Sibling так пока не обновляется: изменения приходят к нему через обновление. Оставить ли адресные пакеты, ещё решается.

Развитие ядра

Planveyor меняется по тому же процессу

Задачей для Planveyor могут стать его собственные инструкции, проверки, обёртки и runtime.

НаблюдениеРоль, Owner или аудит
Предложение · PIПроблема и возможное улучшение
РазборРешение и приоритет
План измененияГраницы и критерии
ПриёмкаПроверенный результат

Как меняется ядро

Предложение проходит отдельный план

Проблему записывают с наблюдениями и доказательствами. Architect определяет решение и границы, Owner задаёт приоритет. Planner готовит шаги, Coder меняет разрешённые файлы и проверки, Reviewer и Architect проверяют и принимают изменение. Сама запись PI не запускает изменение правил или выполнение задач.

Ядро и проект

Улучшение ядра и обновление проекта — разные шаги

Самоулучшение ядра не даёт права незаметно переписывать sibling: совместимость новой версии подтверждают в самом проекте. Новое правило или runtime могут оказаться несовместимы с локальной адаптацией. Проверки снижают этот риск, но не гарантируют, что ошибок нет.

Runtime берётся из внешней копии репозитория Planveyor, поэтому её версию тоже нужно контролировать: сохранённые файлы контракта не изолируют проект от смены runtime.

07Пример

Как процесс работает на реальной SQL-задаче

Задача в sibling на MS SQL: найти товары с нехваткой запаса и учесть ожидаемую поставку. Это исторический прогон 28 сентября 2026 года: роли тогда запускали вручную, команд planveyor sibling ещё не было.

Вход · тестовые данные

Товар	Порог	На складе	Заказано
№1 · One	12	3	4
№2 · Two	9	1	2

12 − (3 + 4) = 5

Запас и ожидаемая поставка вместе ниже порога. Для товара №1 обеспечено 7 единиц при пороге 12, не хватает ещё 5. One и Two — имена синтетических товаров в реальных тестах.

Выход · процедура GetReorderCandidates

IDНазваниеДефицит
1One5
2Two6

Ожидаемый ответ, подтверждённый тестом

В ответ попадают активные товары с положительным дефицитом; снятые с продажи исключаются.
В этом кейсе согласовано: отсутствующее количество (NULL) считается нулём.
Расчёт идёт в более широком числовом типе, чтобы избежать переполнения.

Процедура возвращает список для пополнения. Размещение заказа и изменение остатков остаются за её пределами.

ИсполнениеЧто сделали роли

Участник	Действие	Передаваемый результат
Architect	Согласовал поведение и границы	План: формула, исключения, порядок ответа и критерии приёмки
Planner	Подготовил точные изменения и проверки	Черновик кода: 6 изменяемых файлов и 10 неизменных зависимостей проверок
Coder	Реализовал процедуру и тесты	SQL-код, 7 проверок поведения, проверка порядка и тестовая инфраструктура
Исполнитель с доступом к тестовой БД	Выполнил проверки этого кейса	Отчёт о запуске в dev-среде, результаты SQL-тестов и проверенная версия файлов
Reviewer	Проверил риски, требования и доказательства	Единое ревью с результатами двух линий и сверкой версии файлов
Architect	Принял результат и сделал коммиты кода и документов	Arch review, завершённый план, сохранённые код и документы

Доступ к dev-БД понадобился именно этому примеру; исполнитель с нужными правами — не новая роль Planveyor. В другом проекте проверки задаёт его стек: например, локальные тесты или контейнеры.

Видимые тестыТесты проверяют правила отбора и крайние случаи

Основные группы проверок: тест сравнивает фактический ответ процедуры с ожидаемым.

Сценарий	Порог	Склад	Заказ	Продажа	Ожидание
Дефицит	12 / 9	3 / 1	4 / 2	активен	товар 1 → 5, товар 2 → 6
Запаса достаточно	10 / 10	5 / 8	5 / 5	активен	нет строк
Статус товара	10	2	1	активен / снят / не задан	только активный → 7
Количество не задано	7 / 7	NULL / 3	2 / NULL	активен	дефицит 5 и 4
Таблица пуста	—	—	—	—	нет строк
Границы числового типа	32767 / 32767	−32768 / 32767	−32768 / 32767	активен	98303; отрицательный дефицит исключён

INSERT INTO #Actual EXEC [dbo].[GetReorderCandidates];
INSERT INTO #Expected VALUES (1, N'One', 5), (2, N'Two', 6);
EXEC [tSQLt].[AssertEqualsTable] @Expected = N'#Expected', @Actual = N'#Actual';

Отрицательные количества и NULL в статусе — искусственные тестовые данные. В исходной схеме статус не может быть NULL.

Доказательства

Что доказал завершённый SQL-прогон

Когда препятствие устранили, повторный прогон прошёл.

8/ 8

Все тесты прошли

7 проверок поведения и проверка наличия таблицы. Ошибок и падений нет.

15/ 15

Контрольные суммы совпали

Файлы совпали с версией, для которой получен успешный отчёт.

Маршрут к принятому результату

Первый запуск остановился до SQL-тестов: проверка допуска выявила проблему тестовой среды.
После согласованного исправления прошли сборка, проверки, применение схемы в dev-БД и SQL-тесты.
Сортировку проверили отдельно: порядок ответа не должен зависеть от порядка добавления товаров.
Reviewer и Architect приняли результат. Сохранены проверенные изменения и завершённый план.

Добавили строки: 30 · 10 · 20Получили ответ: 10 · 20 · 30

Передачи плана, 28.09.2026

00:06Architect initial draftArchitect создал план
00:13Ready for PlannerЛинтер плана прошёл со второй попытки, план передан Planner
00:21Ready for CoderЧерновик готов, предварительная проверка насчитала 19 файлов
01:40Ready for ReviewВторой прогон на dev-базе прошёл, Coder передал работу
01:54Ready for Arch reviewРевью без замечаний; финальная проверка насчитала 22 файла
02:17DoneКоммит кода с планом в статусе Done

Промежуточные статусы и первая неудачная попытка закрытия (02:03–02:09) не показаны. От первой строки плана до коммита кода прошло 2 часа 11 минут; роли в этом прогоне запускали вручную.

tSQLt — SQL-тесты, JUnit XML — формат сохранённого отчёта. Доказательство относится к сохранённой версии файлов; нового запуска и проверки production здесь нет.

08Запуск продукта

Готовность к первому выпуску

На 07.10.2026 механики работают, идёт работа над итоговым примером MS SQL. Окончательная версия ядра, приёмка комплекта и публикация впереди.

Подготовлено

Основные механики работают

Роли, планы и проверяемые передачи; две линии Reviewer и Arch review.
Запуск сессий через обёртки и runtime с явным выбором клиента.
Создание sibling и настройка команд стека.
Кандидат ядра от 05.10 прошёл полный набор проверок; SQL‑кейс 28.09 дошёл до принятого результата.

Поддерживаемая среда первой версии — macOS и Python 3.12; runtime требует zsh.

До запуска

Принять комплект целиком

Собрать окончательную версию ядра и прогнать на ней полный набор проверок.
Завершить итоговый пример MS SQL от этой версии по постоянной инструкции: адаптация и её проверка, затем полезная задача отдельным поручением Owner.
Проверить передачу пользователю: ядро, SQL-проект и возможность создать его копию под другим именем.
После приёмки опубликовать согласованный комплект.

После запуска

Надёжность, обновления, сложные задачи

Это не условия первого выпуска. Сроков пока нет, приоритеты задаёт Owner.

Надёжность

Продолжать длительную работу

Восстанавливать прерванную координацию Manager и раньше замечать препятствия закрытию.
Сделать вопросы к Owner и передачу результата понятнее.
Расширять поддерживаемые среды за пределы macOS после отдельных проверок.

Обновление проектов

Проще принимать новые правила

Поддержать более сложные переходы между версиями и изменения файлов контракта.
Упростить передачу улучшений из проекта в ядро и отслеживание решения.
Определить, когда применять отдельный адресный пакет, а когда достаточно обновления проекта.

Сложность и эффективность

Брать большие задачи и измерять затраты

Улучшать постановку исследования, отчёт и разделение задачи на части.
Проверять работу очереди: набор связанных планов с зависимостями и порядком исполнения.
Измерять время и расход моделей; по данным сокращать повторную работу и ожидание.

Следующий практический шагПосле первого выпуска — провести одно небольшое общее улучшение обычным планом и доставить его в MS SQL sibling; затем — анализ, декомпозиция и связанные планы. Каждое улучшение проходит отдельную приёмку.

Planveyor

Первый выпуск готовится

Следить в Telegram