Глава 4: Уточнения (Refinements)

Новые идеи в этой главе

• refine как универсальный глагол для изменений: Вместо множества команд, таких как create, edit или spawn, система использует один мощный примитив, refine, для всех значимых событий, изменяющих состояние.
• Троица изменений: targets, instructions, budgets: Каждый вызов refine определяется тем, что изменяется (targets), как оно изменяется (instructions) и полномочиями/ресурсами для этого изменения (budgets).
• Бюджеты как активные авторизаторы: Авторизация — это не просто проверка разрешений. Budgets — это живые экономические механизмы, чья schema действует как конституция, определяя, допустима ли операция refine.
• Делегирование как уточнение бюджета: Полномочия не просто передаются; они делегируются путем уточнения (refining) родительского Budget в новый, более конкретный дочерний Budget с суженной (narrowed) областью действия и выделенными средствами.
• Уточнение схемы как универсальная эволюция: Принцип сужения схем (narrowing) последовательно применяется ко всем типам Vibe, от Records до Roles и Budgets, обеспечивая единую модель для эволюции.

Примитив Refine: Внесение изменений

Примитив refine — это способ изменять и создавать Vibe. Это основной механизм, который:

• Берёт общий Vibe и делает его более конкретным
• Создаёт новые Vibe из шаблонов
• Модифицирует существующие Vibe контролируемым образом

Каждое значительное изменение в системе происходит, когда вы применяете к чему-то refine. Это действие:

• Создаёт чёткую запись о том, как Vibe развиваются
• Отслеживает создание новых данных и процессов
• Управляет проведением экспериментов и внесением изменений

Примитив Refine: Единый механизм изменений

В основе того, как Vibe развиваются, становятся более конкретными и в конечном итоге превращаются в реальные решения, лежит один мощный примитив: refine. Это универсальный механизм для всех видов модификации и создания Vibe, который переводит Vibe из более общего или абстрактного состояния в более определённое и конкретное. Думайте об этом как о процессе уточнения и конкретизации, который эффективно сужает (narrowing) его область действия. Каждый раз, когда вы применяете refine к Vibe, вы приближаете его к ощутимому результату, более сфокусированной цели или, в конечном счёте, к готовому решению. Этот путь постепенного уточнения, управляемый инструкциями и бюджетами, является основой работы и принятия решений в системе. Важно отметить, что действия refine представляют собой окончательные, изменяющие состояние события в системе. Они составляют основную линию наследования — «дерево происхождения» — значительных изменений, включая создание новых данных, эволюцию процессов и запуск экспериментов. Это отличает их от других, более временных взаимодействий с Vibe или общих сообщений, которые, хотя и могут быть частью истории, не формируют эту основную эволюционную запись.

Вызов примитива

результирующийVibe(ы) = refine(targets, instructions, budgets)

Этот единственный глагол, refine, принимает три основных аргумента. Каждый аргумент может быть как одним Vibe, так и массивом Vibe:

• targets: Один или несколько Vibe-записей, которые будут уточнены, или шаблонные Vibe, из которых будут создаваться новые Vibe. Если предоставлен массив targets, примитив refine применяется к каждому целевому Vibe, фактически выполняя пакетное действие, которое может привести к созданию массива результирующих Vibe.
• instructions: Один или несколько Vibe (которые могут быть данными или процессами), описывающие, как targets должны быть уточнены или как должны быть сгенерированы новые Vibe. Если предоставлен массив instructions, schema авторизующего бюджета должна определять, как эти несколько инструкций следует интерпретировать (например, как последовательность для применения или как набор входных данных для объединения).
• budgets: Один или несколько Budget Vibe, которые предоставляют авторизацию и, при необходимости, ресурсы для операции. schema бюджета действует как его конституция, определяя, какие действия он может одобрять и какие ресурсы может тратить. Если вызов refine требует финансирования, предоставленные Budget(ы) должны иметь достаточный баланс. Если вызов требует определённого разрешения, schema Budget(ов) должна разрешать преобразование данных targets с помощью данных instructions. В некоторых контекстах может неявно использоваться бюджет по умолчанию или окружающий бюджет.

Результатом refine всегда является новый, неизменяемый Vibe или массив новых, неизменяемых Vibe, если было указано несколько targets; оригинальные Vibe остаются нетронутыми.

Примитив refine универсален и поддерживает различные контексты. Например, Vibe может уточнять (refine) сам себя (самоуточнение), один Vibe может влиять на другой (перекрёстное уточнение), или расходящиеся версии могут быть согласованы (уточнение слиянием). Особенно важным применением является генеративное уточнение (spawn), где новый Vibe создается из шаблонного target на основе instructions. Когда refine используется для генерации новых сущностей, эти действия являются фундаментальными для эволюционной записи системы, внося значительный вклад в основную линию изменений.

Другое распространённое применение refine — это распределение бюджета и делегирование полномочий. Вместо разделения абстрактных возможностей, сам Budget Vibe — живой экономический механизм — является объектом refine. Общий, высокоуровневый Budget может быть уточнён (refined) для создания и финансирования новых, более специфичных «дочерних» Budget Vibe с ограниченными ассигнованиями. Это создаёт иерархию бюджетов, позволяя делегировать полномочия командам или проектам ясным и проверяемым образом.

Например, чтобы выделить часть бюджета отдела на конкретный проект:

Допустим, у нас есть:

• DepartmentBudget: Vibe типа Budget с балансом $50 000 на общий маркетинг.
• DelegateBudgetInstructions: Vibe с instructions, например, { "createSubBudget": { "name": "Project Alpha Marketing", "amount": 10000, "purpose": "..." } }.
• Budget, принадлежащий менеджеру, который даёт ему право уточнять DepartmentBudget для создания подбюджетов.

Вызов refine можно представить так: NewBudget = refine(targets: DepartmentBudget, instructions: DelegateBudgetInstructions, budgets: ManagerBudget)

Эта единственная операция выполняет две ключевые функции:

1. Создаёт новый Vibe бюджета: Создаётся новый, неизменяемый ProjectAlphaBudget Vibe. Его собственная schema определяет его конкретную цель и правила расходования, фактически формируя «устав для микроэкономики».

2. Финансирует новый бюджет: В реестр записывается атомарная транзакция, списывающая $10 000 с DepartmentBudget и зачисляющая $10 000 на новый ProjectAlphaBudget. solution (текущий баланс) обоих бюджетов обновляется, чтобы отразить это.

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

Примитив `refine` — это краеугольный камень изменений. Его сигнатура: `refine(targets, instructions, budgets)`.
Он принимает три аргумента, каждый из которых может быть одним Vibe или массивом Vibe:
`targets` (что изменить/из чего создать), `instructions` (как изменить) и `budgets` (полномочия и ресурсы для изменения).
Он всегда создаёт новый, неизменяемый Vibe (или несколько), оставляя оригиналы нетронутыми.

Алиса: «Так значит, вместо целой кучи разных команд, вроде ‘create‘, ‘edit‘, ‘spawn‘ или ‘refine‘, у нас есть только один этот примитив refine для всего, что делает Vibe более конкретным или создает новый?» Боб: «Точно! Один основной примитив, который управляет развитием Vibe. Ты приносишь свои targets — Vibe или Vibe'ы, которые хочешь использовать как основу. Затем представляешь свои instructions, подробно описывая, как должен быть сформирован новый Vibe. И наконец, ты можешь предоставить один или несколько budgets. budget — это твой пропуск и кошелёк в одном флаконе. Его внутренние правила — его schema — определяют, разрешена ли операция. Если действие что-то стоит, budget также предоставляет средства. Если budget одобряет, то — вуаля! — появляется совершенно новый, неизменяемый Vibe (или набор Vibe)!»

Каковы три обязательных аргумента для примитива `refine`?
* [x] `targets`: Vibe для уточнения или шаблоны для создания новых.
* [x] `instructions`: Vibe, описывающие, как должно происходить уточнение.
* [x] `budgets`: Vibe, предоставляющие авторизацию и ресурсы для уточнения.

Какая характеристика результата работы примитива `refine` является гарантированной?
* [x] Он всегда создаёт новый, неизменяемый Vibe.
* [ ] Он изменяет `targets` на месте.
* [ ] Иногда он может возвращать несколько новых Vibe.
* [ ] `budgets` расходуются и становятся недействительными после использования.
* [ ] Для его завершения всегда требуется вмешательство LLM.

Бюджеты: Авторизация изменений

Авторизация всех операций refine управляется через Budget Vibe. Budget — это не просто пул средств; это живой экономический механизм, чья schema действует как конституция, определяя правила, цели и ограничения того, что можно делать в рамках его полномочий. Это страж всех значительных изменений.

Основные принципы авторизации через бюджеты

• Единство полномочий и ресурсов: Budget Vibe объединяет разрешение на действие с ресурсами, необходимыми для этого действия. Его schema определяет правила (полномочия), а его solution отслеживает расходуемые активы (ресурсы). Действие авторизовано, если оно соответствует правилам schema и если solution содержит достаточно средств.

• Конституция (schema): Полномочия Budget чётко определены в его schema. Эта «конституция» указывает, какие targets могут быть уточнены и с помощью каких instructions. Например, schema «Маркетингового бюджета» может разрешать только вызовы refine, которые создают Vibe, связанные с рекламой.

• Делегирование как уточнение бюджета: Полномочия делегируются путём уточнения (refining) родительского Budget для создания нового, более конкретного «дочернего» Budget. Операция refine выделяет часть средств родителя дочернему бюджету и, что особенно важно, даёт дочернему бюджету собственную schema, которая сужает (narrows) объём полномочий. Директор по маркетингу может уточнить (refine) основной Marketing Budget, чтобы создать Social Media Budget для руководителя своей команды, у которого будет меньший пул средств и schema, разрешающая траты только на платформах социальных сетей.

• Неизменяемость и отслеживаемость: Budget Vibe неизменяемы. Когда Budget уточняется для делегирования полномочий, создаётся новый Budget Vibe. Это обеспечивает чёткую, проверяемую цепочку делегирования, отслеживая каждый подбюджет до его родителя. Отзыв Budget осуществляется созданием нового Vibe, который помечает его как недействительный, аннулируя любые дочерние Budgets, которые из него черпают средства.

Загрузка системы: Первоначальные операции refine

Для работы примитива refine(targets, instructions, budgets) требуются уже существующие Vibe. Это естественно подводит к вопросу: как создаются самые первые Vibe в системе? Эта фаза «начальной загрузки» или «генезиса» опирается на фундаментальные элементы, предоставляемые самой платформой.

1. Начальные budgets (Полномочия Платформы): Первоначальная авторизация предоставляется базовым «Бюджетом Платформы». Он действует как основная лицензия, позволяя выполнить первый набор вызовов refine. Его schema настроена так, чтобы разрешать создание основных, фундаментальных схем Vibe (для определения Vessels, Processes и т.д.). Этот Budget предоставляет «пропуск», чтобы начать создавать, и обычно сам по себе не содержит финансовых ресурсов.

2. Начальные targets (Базовые шаблоны): Платформа предоставляет набор минимальных, «начальных» шаблонных Vibe, которые служат исходными targets (первый аргумент) для создания фундаментальных сущностей. Обычно к ним относятся:

   • aug:/types/Vessel?1: Очень общий шаблон для создания новых типов Vessel.
   • aug:/types/Process?1: Минимальный шаблон для определения новых типов Process.
   • aug:/types/Data?1: Базовый шаблон для новых типов структурированных записей Record (например, может содержать только корневое поле id или базовую структуру метаданных).

3. Начальные instructions (Намерение пользователя): instructions (второй аргумент) для этих первых уточнений обычно создаются пользователем или в процессе настройки/онбординга. Они указывают, как пользователь хочет изменить или специализировать один из начальных шаблонов. Например, инструкции могут подробно описывать, как уточнить (refine) aug:/types/Data?1, чтобы создать новый Vibe схемы Invoice.

Принцип уточнения схемы при начальной загрузке:

Когда вы изменяете схему базового шаблона с помощью refine, вы должны делать её более конкретной (сужая (narrowing) её определение), а не полностью другой. Думайте об этом так:

• Вы можете добавлять в схему новые поля и детали
• Вы должны оставаться в рамках первоначального назначения шаблона
• Вы не можете изменять его фундаментальную природу

Например:

• Шаблон записи (Record) может стать шаблоном записи счёта-фактуры (Invoice Record), если добавить поля, специфичные для счетов
• Но вы не должны превращать шаблон записи в систему управления процессами

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

Начальная загрузка системы с помощью `refine(targets, instructions, budgets)`
опирается на элементы, предоставляемые платформой:
1. Начальные `targets`: Минимальные базовые шаблоны, такие как
   `aug:/types/Vessel?1`, `aug:/types/Process?1` и
   `aug:/types/Data?1`.
2. Начальные `instructions`: Инструкции, определяемые пользователем, которые указывают, как
   настроить эти базовые шаблоны.
3. Начальные `budgets`: Фундаментальный «Бюджет Платформы» от владельцев,
   позволяющий выполнять начальные действия. Его `schema` разрешает эти основополагающие
   создания, обычно не требуя финансовых ресурсов.
**Уточнение** схемы обычно следует принципу сужения (`narrowing`), специализируя шаблоны
в рамках ограничений `schema` авторизующего `Budget`.

Алиса: «Понятно, для refine нужны targets и instructions. Но откуда берутся полномочия для самого первого вызова? Его аист приносит?» Боб: «Ха! Не совсем аист, но платформа выступает в роли курьера. Она предоставляет базовые шаблонные targets (простое тесто) и фундаментальный Platform Budget (твоя лицензия на выпечку). Тебе просто нужно предоставить instructions (твой первый рецепт).»

Как предоставляются первоначальные полномочия для первых уточнений?
* [x] Они предоставляются фундаментальным «Бюджетом Платформы» от администраторов/владельцев платформы.
* [ ] Они генерируются автоматически из `targets`.
* [ ] Пользователь создаёт их с помощью специальной команды.
* [ ] Они клонируются из `instructions`.

Что служит начальными `targets` на этапе начальной загрузки?
* [x] Минимальные, начальные шаблонные Vibe, предоставляемые платформой (например, для Vessels, Processes, Data).
* [ ] Пользователь должен создавать их с нуля, используя внешние инструменты.
* [ ] Можно использовать любой существующий Vibe из публичного репозитория.
* [ ] Сами `budgets` также выступают в качестве первых `targets`.

Что такое «принцип **уточнения** схемы» в контексте **уточнения** базовых шаблонов?
* [x] Результирующие схемы, как правило, должны быть специализациями (суженными (`narrowed`) версиями), добавляющими детали в концептуальных границах шаблона.
* [ ] Схемы можно произвольно расширять без ограничений.

Как бюджеты авторизуют операции refine

Вот как система проверяет, разрешён ли вызов refine, когда предоставлен один или несколько budgets:

1. Перебор budgets: Система будет поочерёдно проверять каждый предоставленный Budget Vibe.

2. Проверки для каждого Budget: Чтобы вызов refine был авторизован конкретным Budget, должны быть выполнены все следующие условия:

   • Проверка полномочий: schema (конституция) бюджета должна разрешать запрашиваемую операцию. Это включает проверку предоставленных targets и instructions на соответствие правилам, определённым в schema.
   • Проверка баланса: Если операция требует расходования ресурсов (например, валюты, токенов, кредитов), solution (текущий баланс) бюджета должен содержать достаточно средств.
   • Проверка состоятельности: Списание требуемых средств не должно приводить Budget в «несостоятельное» состояние, то есть он всё ещё должен соответствовать своим минимальным финансовым или операционным требованиям, определённым в его schema.

3. Окончательное решение:

   • Если хотя бы один предоставленный Budget успешно проходит все вышеуказанные проверки, то refine одобряется.
   • Затем вызов refine выполняется. Если действие было экономическим, в реестр записывается транзакция, списывающая средства с авторизующего Budget.
   • Если ни один из предоставленных Budget не может авторизовать операцию, вызов refine отклоняется.

Эта система обеспечивает чёткий аудиторский след. Каждое действие refine связано с конкретным Budget, который его авторизовал и профинансировал, обеспечивая полную и непрерывную историю для каждого изменения и каждой потраченной единицы ценности.

Авторизация `refine` бюджетом включает многоэтапную проверку для каждого предоставленного `Budget`:
1.  **Проверка полномочий**: Разрешает ли `schema` бюджета эту конкретную операцию `refine` над данными `targets` с данными `instructions`?
2.  **Проверка баланса**: Достаточно ли средств в `solution` бюджета?
3.  **Проверка состоятельности**: Сможет ли `Budget` после расходования средств соответствовать своим основным требованиям?

Если хотя бы один предоставленный `Budget` проходит все три проверки, операция одобряется. В противном случае она отклоняется. Это обеспечивает детальный, проверяемый контроль над всеми преобразованиями Vibe.

Алиса: «Так это как использовать кредитную карту. Когда я пытаюсь что-то уточнить (refine), система проверяет мой Budget Vibe. Она спрашивает: ‘Разрешает ли книга правил (schema) бюджета этот тип покупки (targets и instructions)? Достаточно ли денег на счету (solution)? И не опустошит ли эта покупка счет настолько, что я не смогу заплатить за аренду (solvability)?’ Если всё хорошо, транзакция проходит». Боб: «Идеальная аналогия! И если у тебя в кошельке несколько budgets, системе просто нужно найти один, который скажет ‘да’ на всю операцию».

Каково окончательное условие для одобрения `refine` бюджетом (или набором бюджетов)?
* [x] По крайней мере один предоставленный `Budget` должен иметь `schema`, которая разрешает операцию, и достаточно ресурсов для её финансирования без потери состоятельности.
* [ ] Все предоставленные `Budgets` должны единогласно одобрить вызов `refine`.
* [ ] `targets` Vibe должны содержать специальную метку, указывающую, что они разрешают уточнение представленными `budgets`.
* [ ] `instructions` Vibe должны быть подписаны цифровой подписью владельца `budgets`.

Какие аспекты `Budget` проверяются в процессе авторизации вызова `refine`?
* [x] `schema` бюджета, чтобы проверить, разрешают ли правила конкретные `targets` и `instructions`.
* [x] `solution` бюджета, чтобы убедиться, что на балансе достаточно необходимых ресурсов.
* [x] Общая состоятельность `Budget`, чтобы убедиться, что действие не нарушает его основные ограничения.
* [ ] Историческое количество успешных использований `Budget`.
* [ ] Вычислительная стоимость предлагаемой операции `refine`.

Развитие структур Vibe: Уточнение схемы

Примитив refine, после авторизации Budget, может использоваться для изменения не только solution (содержимого данных) Vibe, но и самого структурного определения, хранящегося в его поле schema. Это форма сужения (narrowing) схемы. Это применимо ко всем типам Vibe, обеспечивая последовательный механизм контролируемой эволюции во всей системе.

Принцип уточнения схемы

Уточнение схемы — это процесс, делающий определение schema Vibe более конкретным. Часто это включает добавление новых полей, объявление существующих полей обязательными, ужесточение ограничений (например, minLength для строки, maximum для числа) или уточнение типов данных. Ключевая идея в том, что новая схема является расширением или уточнением старой, сохраняя её основную концептуальную природу, но добавляя конкретики. Это обеспечивает cohérentное развитие Vibe. Например, общий Vibe записи «Товар» может быть уточнён до Vibe записи «Электронный товар» путём добавления полей, специфичных для электроники, но он не будет преобразован во что-то несвязанное, например, в «Профиль пользователя».

Важно отметить, что Vibe с уточнённой схемой остаётся совместимым с исходной, более общей схемой. Системы или процессы, разработанные для работы с Vibe, соответствующими исходной схеме, всё ещё могут взаимодействовать с уточнённым Vibe; они просто не будут знать о дополнительных, более специфичных полях или более строгих ограничениях, или будут их игнорировать. Например, если система ожидает Vibe «Транспортное средство» с полем color, она всё равно сможет обработать Vibe «Автомобиль» (уточнённое «Транспортное средство»), у которого есть поле color, а также дополнительное поле numberOfDoors; система просто будет использовать поле color, как и ожидалось.

**Уточнение** схемы делает определение `schema` Vibe более конкретным, например, добавляя
поля, ужесточая ограничения или **уточняя** типы. Это расширение старой
схемы, сохраняющее основную концепцию Vibe, но добавляющее детали. **Уточнённый** Vibe
остаётся совместимым с системами, ожидающими исходную, общую схему; эти
системы просто проигнорируют новые, специфичные части. Это обеспечивает
согласованное развитие Vibe (например, общий «Товар» может стать более конкретным
«Электронным товаром», но не несвязанным «Профилем пользователя»).

Алиса: «То есть, уточнение схемы — это как взять общую идею, скажем, ‘транспортное средство’, и сделать её более конкретной, например, ‘двухдверный электрический спорткар с сиденьями из веганской кожи’? И мы не превращаем его в ‘велосипед’ или ‘лодку’?» Боб: «Именно! Ты добавляешь детали и ограничения, но сохраняешь фундаментальную природу. Цель — уточнение и повышение точности, а не полная смена идентичности. Новая, уточнённая схема всё равно будет удовлетворять требованиям исходной, более общей схемы. Если система умеет работать только с ‘транспортными средствами’ и их базовыми свойствами, она всё равно сможет обработать твой ‘двухдверный электрический спорткар’, просто посмотрев на те части, которые она понимает».

Какова основная цель «**уточнения** схемы»?
* [x] Сделать определение `schema` Vibe более конкретным, сохраняя при этом его основную концептуальную природу и обеспечивая совместимость с системами, ожидающими исходную схему.
* [ ] Полностью изменить определение `schema` Vibe на что-то несвязанное.
* [ ] Уменьшить количество полей в определении `schema` Vibe, чтобы сделать его проще.
* [ ] Сделать определение `schema` Vibe более общим и менее ограниченным.
* [ ] Преобразовать схему Record Vibe в схему Process Vibe.

Уточнение схемы для разных типов Vibe

Принцип «уточнения схемы» — делая направляющее определение schema Vibe более конкретным (т. е. сужая (narrowing) его) — применим ко всем типам Vibe, а не только к Record Vibe. Каждый раз, когда refine изменяет определение schema Vibe, это приводит к созданию нового Vibe с этой уточнённой структурой. Характер этого уточнения зависит от типа Vibe:

Это последовательное применение уточнения схемы через примитив refine позволяет всей системе, для всех типов Vibe, развиваться контролируемым, проверяемым и всё более уточнённым (и суженным (narrowed)) образом.

Миграция экземпляров во время уточнения

Когда Vibe подвергается уточнению, пользователю предоставляется выбор, как распространить уточнённые изменения на существующие экземпляры этого Vibe:

1. Распространение под контролем пользователя: Система предлагает варианты применения изменений уточнения к существующим экземплярам, позволяя пользователю выбрать подходящую стратегию миграции.

2. Миграция уточнений: Вместо того чтобы пересоздавать экземпляры с нуля, система применяет конкретные изменения уточнения к каждому отдельному существующему Vibe, сохраняя исходный экземпляр, но включая в него уточнённую схему и изменения на входе.

3. Целевое применение: К существующим экземплярам применяются только те конкретные изменения, которые были внесены в ходе уточнения (новые поля, обновлённые ограничения, улучшенные промпты и т. д.), сохраняя их существующие данные и контекст там, где это совместимо.

4. Стратегии миграции: Пользователи могут выбирать из различных подходов к распространению:

   • Немедленная миграция: применить уточнения ко всем экземплярам сразу
   • Выборочная миграция: выбрать конкретные экземпляры для миграции
   • Постепенное развёртывание: мигрировать экземпляры поэтапно с проверкой
   • Тестирование на ветках: протестировать уточнения на копиях перед применением к оригиналам

Этот механизм миграции гарантирует, что уточнения могут распространяться по системе контролируемым образом, при этом пользователь определяет, как и когда происходит эволюция в архитектуре Vibe.

**Уточнение** схемы применяется ко всем типам Vibe, делая их направляющие определения `schema`
более конкретными. Для Record Vibe **уточняется** JSON Schema. Для Instruction Vibe параметры
и правила преобразования становятся более детальными. Для `Budgets` правила
становятся более строгими (делегирование, сужение (`narrowing`) полномочий). Для Roles конфигурации инструментов специализируются.
Для Processes рабочие процессы становятся более подробными. Каждый вызов `refine` порождает новый
Vibe с **уточнённой** схемой, обеспечивая контролируемое, проверяемое развитие всей системы.
Пользователи контролируют, как изменения от уточнения мигрируют на существующие экземпляры.

Алиса: «Так это уточнение схемы не только для записей данных? Если у меня есть Budget, чтобы править миром, я могу его уточнить (refine), чтобы править, скажем, только моей местной пекарней, эффективно сужая (narrowing) его власть? И это тоже уточнение схемы?» Боб: «Точно! schema полномочий Budget становится более конкретной — более строгие правила, меньшие ассигнования. То же самое и с Role Vibe; его schema конфигураций инструментов может быть уточнена, чтобы сделать его специалистом. Или schema рабочего процесса Process Vibe может быть уточнена, чтобы обрабатывать очень специфичную подзадачу с дополнительной проверкой. Это универсальный принцип».

Как **уточнение** схемы проявляется в `Budget` Vibe (т. е. как сужаются (`narrowed`) его полномочия)?
* [x] Его `schema` становится более строгой, а его средства обычно разделяются, что представляет собой делегирование меньшего объёма полномочий.
* [ ] В его `solution` добавляются новые, несвязанные инструменты.
* [ ] `target` схемы, с которыми он может работать, становятся шире.
* [ ] Его метаданные `issuerRef` удаляются.
* [ ] Он получает возможность обходить операции `refine`.

Каков результат **уточнения** схемы для Role Vibe?
* [x] Его определение `schema` (коллекция инструментов/мемов и их оркестровка) становится более специализированным.
* [ ] Он преобразуется в Process Vibe.
* [ ] Он теряет все свои встроенные инструменты.
* [ ] Его способность одновременно активировать инструменты удаляется.
* [ ] Он может производить только `solutions` типа Record Vibe.

Эволюция схем Record Vibe: Концептуальный обзор

«Принцип уточнения схемы» — делая схемы более конкретными — является фундаментальным для адаптации системы. Budget Vibe могут разрешать изменения не только solution (данных) Record Vibe, но и структурного определения в его поле schema. Это делается с помощью refine на Record Vibe с instruction Vibe, который определяет эволюцию.

Два основных сценария эволюции схемы:

1. Аддитивное уточнение: Добавляются новые поля или ужесточаются ограничения. Новая схема является прямым расширением старой. Например, добавление stockLevel и price к базовой схеме продукта при преобразовании рекламного объявления в полноценный товар для электронной коммерции.
2. Миграция на новую основную версию: Для более фундаментальных («ломающих») изменений (например, переименование или удаление полей, значительное изменение типов) определяется новая версия схемы (например, «ProductSchemaV2» из «ProductSchemaV1»). Существующие Vibe мигрируют с помощью refine, где данные старого Vibe (как часть instruction) используются для заполнения нового экземпляра Vibe, соответствующего новой версии схемы. Это обеспечивает чистое разделение и явное преобразование.

Этот подход, основанный на бюджетах, рассматривает эволюцию схемы как неотъемлемую часть эволюции данных, управляемую тем же примитивом refine и авторизацией на основе бюджетов. Это гарантирует, что структуры данных развиваются контролируемо, проверяемо и безопасно, отражая изменения в бизнес-требованиях.

Эволюция схемы Record Vibe (т. е. сужение (`narrowing`) схемы) управляется вызовами `refine`, авторизованными
`Budget` Vibe. Обычно она включает либо аддитивное **уточнение** (новые поля,
более строгие ограничения), либо миграцию на новую основную версию (определение новой версии схемы
и преобразование данных старого Vibe под неё). Это обеспечивает контролируемое, проверяемое
развитие структур данных, рассматривая изменения схемы как часть эволюции данных.

Алиса: «То есть, если моему Vibe продукта нужно добавить, скажем, поле ‘carbon_footprint’, это ‘аддитивное уточнение’? А если я хочу полностью изменить способ хранения цен, с строки вроде ‘$19.99’ на целое число для центов, это уже больше похоже на ‘миграцию на новую основную версию’?» Боб: «В точку. Аддитивное — это как добавить новую комнату к дому. Миграция — это как переезд в новый дом с другой сантехникой: тебе нужен процесс, чтобы упаковать вещи из старого дома и правильно расставить их в новом. Оба используют refine, но instruction Vibe выглядит по-разному».

Каковы два основных сценария эволюции схем Record Vibe, как они описаны?
* [x] Аддитивное уточнение: добавление новых полей или ужесточение ограничений в существующей схеме.
* [x] Миграция на новую основную версию: определение новой версии схемы и преобразование данных из старых Vibe для соответствия ей.
* [ ] Удаление схемы: полное удаление поля `schema` из Record Vibe.
* [ ] Автоматическое обобщение схемы: система со временем автоматически делает схемы менее конкретными.

Подробные примеры этих сценариев эволюции схем, включая примеры вызовов refine и JSON-структуры, см. в сопроводительном документе: 04_refinements_examples.md.

Практическое управление разрешениями для операций refine: Концептуальный обзор

Разрешения на использование refine являются гранулированными и ориентированными на задачи, предоставляемыми через schema Budget Vibe. Эти правила schema могут разрешать действия над конкретными экземплярами Vibe или, что более мощно, над любыми Vibe, соответствующими указанным схемам для их аргументов targets и instructions.

Это гарантирует, что все изменения, от обновлений данных до эволюции схем (сужение схемы (narrowing)), включая действия, которые потребляют или требуют определённых ресурсов (например, токенов бюджета или достижений по метрикам, хранящихся в Budget), контролируются и проверяются. Система проверяет, что представленный Budget (или один из них, если их несколько) содержит в своей schema правила, которые явно разрешают преобразование targets Vibe(s) с помощью конкретных instructions Vibe(s), и имеет для этого достаточные ресурсы.

Разрешения для `refine` управляются через `schema` `Budget`
Vibe. Эта `schema` определяет гранулированные, ориентированные на задачи авторизации,
позволяя действия над экземплярами Vibe или любыми Vibe, соответствующими схемам `target`
и `instruction`, и предоставляя ресурсы для действия.
Эта система гарантирует, что все изменения контролируются, проверяются и верифицируются
в соответствии с явными определениями `Budget`.

Алиса: «Так эти Budget схемы очень специфичны? Например, один Budget может позволить мне изменить цену продукта, а для изменения его описания нужен другой, отдельный Budget? И во втором Budget может даже не быть денег, только полномочия?» Боб: «Именно. Или schema одного Budget может позволить менеджеру по продукту уточнять (refine) ‘Vibe шаблона продукта’ с помощью ‘Vibe инструкции по запуску утверждённого продукта’, но только если у этого Budget также есть баланс не менее 10 000 ‘маркетинговых долларов’. Ключевым является гранулированный контроль над целями, инструкциями и ресурсами».

Как система гарантирует, что при использовании `refine` процесс контролируется и проверяется?
* [x] Путём проверки того, что представленный `Budget` Vibe имеет `schema`, которая явно разрешает `targets` и `instructions`, и имеет достаточные `ресурсы` в своём `solution`.
* [ ] Требуя, чтобы все вызовы `refine` одобрялись администратором-человеком в реальном времени.
* [ ] Шифруя все `instructions` Vibe так, чтобы только авторизованные `targets` Vibe могли их расшифровать.
* [ ] Ограничивая `refine` так, чтобы он влиял только на поле `solution`, но никогда на поле `schema`.
* [ ] Позволяя любому Vibe быть `budget`, если его имя начинается с «budget-».

Примеры из электронной коммерции, иллюстрирующие практическое управление разрешениями для различных ролей и задач (например, запуск продуктов менеджерами по продукту, корректировка запасов менеджерами по инвентаризации), см. в сопроводительном документе: 04_refinements_examples.md.

Этот последовательный способ уточнения (refine) схемы позволяет всей системе, для всех типов Vibe, развиваться контролируемым, проверяемым и всё более уточнённым (и суженным (narrowed)) образом.