Идея: фрактальное планирование, lowering и поэтапное развитие решения
1. Зачем сохранён этот документ
01Владелец предложил методику и попросил сохранить важные идеи перед передачей дополнительного исследования. Здесь зафиксированы исходное намерение, обсуждённая модель и вопросы для дальнейшей проверки. Сохранение документа не меняет действующие правила, задания, зависимости, приёмку или разрешения и не запускает кампанию.
02Исходная проблема: сложное решение трудно одновременно изобрести, реализовать и сразу оформить по всем требованиям AI-Native Languages и production-ready кода. Владелец предложил для подходящих задач сначала прототип, затем функциональный MVP, затем продуктизацию. Такой маршрут можно предусмотреть в крупном плане, развернуть при lowering или применить локально при обнаружении сложности во время исполнения.
2. Фрактально-рекурсивная природа
03Обсуждённый общий цикл: задача → уточнение результата → выбор способа работы → lowering → исполнение → проверка → при необходимости локальное уточнение. Одинаковая форма применяется к задаче Владельца, направлению работ, отдельной задаче и внутренней подзадаче. Рекурсия действует как при первоначальном планировании, так и динамически при исполнении.
04Вниз передаются цель, требования, ограничения, зависимости, границы полномочий и условия приёмки. Вверх возвращаются артефакты, доказательства, проверенные наблюдения, обнаруженные проблемы и предложения изменить ближайший затронутый участок. Новые знания могут уточнить верхний замысел; локальный исполнитель не подменяет его собственным.
05Рекурсия заканчивается на достаточно понятном и проверяемом действии. Простое действие выполняется прямо. Дальние части плана сохраняются крупными, ближайшие уточняются по необходимости. Повторение процедуры само по себе не считается прогрессом; новая итерация должна разрешать названную неопределённость или проблему.
3. Маршруты зрелости конкретного результата
06Прототип отвечает на конкретную неопределённость: работает ли алгоритм, подход, интеграция или архитектурная идея. Выход — воспроизводимый опыт, вывод, ограничения и решение продолжать, пересмотреть или отбросить подход. Полнота функций и окончательное оформление не требуются. Полезное опровержение гипотезы тоже может завершить эксперимент.
07Функциональный MVP реализует весь заявленный сценарий данной задачи и подтверждает его существенное поведение. «Вся функциональность» относится к объявленному результату, а не обязательно ко всему продукту. Часть структурных и формальных требований может быть явно отложена. Ограничения MVP и допустимое использование остаются видимыми.
08Продуктизация доводит результат до полного конечного контракта: закрывает отложенные требования к структуре, типовым границам, диагностике, карточкам, traceability, документации и другим применимым качествам. Проверяется сохранение согласованного поведения. Ошибочное поведение MVP не становится нормой лишь потому, что было зафиксировано тестом.
09Предлагаемые маршруты: прямое выполнение; прототип → готовое решение; MVP → продуктизация; прототип → MVP → продуктизация. Выбор зависит от неопределённости, объёма и стоимости проверки. Не требуется проводить каждую задачу и каждый уровень рекурсии через все три этапа.
10Зрелость артефакта, состояние узла плана и уровень приёмки — разные оси. Завершённый эксперимент может быть принят именно как эксперимент; родительское функциональное обязательство остаётся открытым до конечной приёмки. Также отдельно существуют профиль планирования standard/ultra, операции VibeVM create/build/verify и общий прототипный режим продукта. Продуктизация одной задачи не объявляет весь VibeVM вышедшим из прототипного режима: это отдельное решение Владельца.
4. Отсрочка требований с сохранением обязательств
11Разрешение на эксперимент должно действительно облегчать работу: подготовка прототипа не должна предварительно требовать завершения всех карточек, оболочек и полного conform. Предлагается заранее разрешать подходящие категории отсрочек, а конкретный оставшийся объём уточнять по результатам этапа. Отложенное требование сохраняет смысл, место закрытия и проверяемый критерий завершения.
12Краткая запись для выбранного маршрута должна показывать результат и область кода, разрешённые отсрочки и причину, требования текущего этапа, место и владельца интеграции, этап закрытия каждой обязанности и нужное доказательство. Это не бесконтрольное «AI-Native выключен» и не необходимость перечислять все будущие диагностические сообщения до первого эксперимента.
13Требования разделяются по смыслу. Размещение файлов, часть оформления карточек и связей со спецификациями можно отложить. Некоторые типовые оболочки обеспечивают существенный инвариант — временная реализация тогда сохраняет эту защиту иным способом. Полномочия, честность результатов и сохранность реально используемых данных действуют на каждом применимом этапе. Исследование формата на изолированных данных и изменение формата, который уже читает реальный потребитель, требуют разных гарантий.
14Прототип и MVP могут сохраняться в отдельном worktree, ветке или явно экспериментальной области с контролируемым подключением. Возможность коммита не означает продуктовую приёмку. Невыполненные формальные проверки отражаются честно; расширение общего baseline исключений или отключение глобального gate не считается погашением долга. Конкретный механизм временных исключений ещё требуется спроектировать.
15Для рискованного решения полезно рано довести один показательный фрагмент до окончательных ограничений: например, один интерфейс, одну сериализацию или одну восстановительную операцию. Это проверяет возможность последующей продуктизации до завершения большого MVP. Такой опыт нужен при конкретной неопределённости, а не как обязательный дополнительный проход для каждого изменения.
16Код прототипа можно выбросить или переписать. Проверенные наблюдения, причины выбора и отказа от альтернатив, характерные примеры и полезные независимые проверки должны сохраниться. Контекстная память исполнителя и сам прототип не становятся единственным хранилищем этих знаний.
5. Крупный план → lowering → исполнимый план
17Lowering — перевод замысла и конечных требований в исполнимый контракт. Крупный план задаёт нужный результат и может выбрать маршрут зрелости; lowering разворачивает его в задания, зависимости, проверки и условия переходов. Во время исполнения та же процедура применяется локально, если первоначально подробная задача оказалась слишком крупной или неопределённой.
18Вход: стабильный родительский результат, конечные критерии приёмки, существенные инварианты и применимые правила, зависимости и интерфейсы, известные доказательства, открытые вопросы, полномочия и область изменений. Неопределённости остаются названными входами для исследования.
19Выход: ограниченные исполнимые задания либо внутренние этапы одного задания. Для них определены доступные входы, рабочие файлы, ожидаемое поведение, необходимые проверки, безопасная остановка и доказательства. Ещё не существующая команда или тест помечаются как требующие создания или уточнения; сам факт генерации подробного плана не делает их существующими.
20Предлагаемое правило сохранения: каждый исходный пункт получает место реализации и проверки; каждая отсрочка — обязательное место закрытия; каждое новое задание имеет объяснимое происхождение. Сохраняются смысл родителя, границы полномочий и реальные зависимости. Итоговая приёмка включает совместную работу частей. Потерянный пункт или отсутствие продуктизации должны обнаруживаться при проверке lowering.
21Выбор архитектуры, достаточность доказательств и содержательное разбиение требуют суждения. Идентичности, полноту явных соответствий, структуру зависимостей, наличие обязательного закрытия отсрочек и отсутствие преждевременной приёмки можно проверять алгоритмически. Совпадение числа пунктов не доказывает сохранение их смысла.
6. Самостоятельность исполнителя и продолжение работы
22Если пакет заранее разрешает маршрут и его границы, исполнитель может самостоятельно выбрать предусмотренные внутренние этапы и пройти их без нового вопроса Владельцу на каждом переходе. Если требуются новые полномочия, область записи, зависимости или изменение конечной приёмки, он возвращает центральному координатору конкретное предложение локального уточнения. Сам исполнитель не меняет центральный план и не принимает свою работу.
23Рекурсивное разбиение не даёт права уменьшать родительское обязательство. Внутренние этапы могут оставаться частями одного задания. Если промежуточные результаты должны независимо приниматься или разблокировать другие работы, координатор явно отражает это в существующей иерархии и зависимостях. Потребитель получает только гарантии, установленные для нужного ему результата.
24После потери контекста сохраняются текущий этап, артефакты, доказательства и непогашенные обязанности; перезапуск не обнуляет долг. Параллельные исполнители работают по согласованным входам и границам, а результаты интегрируются и проверяются. Применяются уже принятые принципы узких проверок, повторного использования пригодных доказательств и ограничения бесполезных повторов.
7. Связь с существующим multi-user-planning и планом
25В multi-user-planning уже есть полный маршрут, постепенно уточняемый ближайший участок, конкретные пакеты и приёмка снизу вверх. Обсуждённая идея добавляет явный контракт lowering и выбранные маршруты зрелости. Начать можно с внутренних этапов подходящих существующих заданий; отдельно разворачивать их в дочерние узлы только при реальной необходимости. Автоматическое умножение всех задач на три этапа не требуется.
26Обсуждённые примеры: сначала проверить алгебру feature effects на маленьких таблицах, затем реализовать заявленные эффекты и завершить формализацию; либо сначала проверить обслуживание одного управляемого долгого задания, затем полный заявленный сценарий событий и управления, затем продуктизировать структуру. Небольшая задача точного сохранения XML, для которой уже есть дешёвая прямая проверка байтов, обычно допускает прямое выполнение.
8. Что сопоставить с предстоящим исследованием
27Исследование ещё не передано. Следующий проход должен сохранить эту исходную идею и явно показать, что исследование подтверждает, опровергает или уточняет, а не заменять обсуждение без следа.
- 28Как выбирать маршрут и критерии переходов так, чтобы выигрыш превышал стоимость дополнительных этапов?
- Как выразить временные отсрочки и их область действия совместно с AI-Native Languages и фактическими инструментами проверок?
- Как машинно представить и проверить соответствие родительских требований заданиям и доказательствам, сохранив совместимость существующих планов?
- Как задать самостоятельность воркера, остановку рекурсии и возврат к координатору без лишней церемонии и потери обязательств?
- Какие гарантии промежуточного результата достаточны для его использования другими задачами и как это отражать в зависимостях?
- Как измерить пользу по времени до принятого результата, объёму переделок и стоимости проверок, а не по числу стадий, агентов или строк плана?