EnRuУпрощ. EnУпрощ. Ru
Черновики

Подробный пример: развитие схем записывающих Vibe

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

Рассмотрим сценарий развития простого промо-сайта в полноценную e-commerce платформу.

Начальное состояние: Изначально у компании есть записывающие Vibe для своих продуктов, например, aug:products/superwidget?1 (где ?1 означает ревизию). Эти Vibe соответствуют структуре, определённой в Vibe-образце, скажем, aug:products/example?1 (представляющем базовую структуру продукта).

  • Поле schema для aug:products/example?1 (и, следовательно, для aug:products/superwidget?1) содержит определение JSON Schema для этой начальной базовой структуры продукта.
  • Поле solution для aug:products/example?1 содержит примерные/шаблонные данные для базового продукта.

Эта начальная структура (aug:products/example?1#schema) может выглядеть так:

// Содержимое поля 'schema' для aug:products/example?1 и его производных
{
  "type": "object",
  "properties": {
    "productName": { "type": "string" },
    "description": { "type": "string" },
    "promoImage": { "type": "string", "format": "uri" }
  },
  "required": ["productName", "description"]
}

Бизнес-цель и требуемое изменение схемы: Когда компания решает запустить полноценный интернет-магазин, возникает новое критическое требование: отслеживать остатки на складе и цены. Это требует изменения записывающих Vibe продуктов, чтобы они включали поля stockLevel и price. Это значит, что определение JSON Schema в их поле schema должно измениться.

Операция Refine: развитие схемы и решения Vibe Чтобы это реализовать, операция Refine нацеливается на существующий aug:products/superwidget?1:

  • target (цель): aug:products/superwidget?1.
  • instruction (инструкция): Vibe aug:migrations/evolve-to-shop-item?1. Его поле solution играет ключевую роль; оно указывает, как изменить определение JSON Schema в поле schema целевого Vibe и как адаптировать его данные (solution): 
    // Пример: содержимое поля 'solution' для aug:migrations/evolve-to-shop-item?1
// Формат не имеет значения
{
  "schemaModifications": {
    "addProperties": {
      "stockLevel": { "type": "integer", "minimum": 0, "description": "Текущий остаток на складе" },
      "price": { "type": "number", "format": "currency", "description": "Розничная цена" }
    },
    "addToRequired": ["stockLevel", "price"]
  },
  "solutionUpdate": {
    "stockLevel": 0, // Инициализировать новое поле stockLevel в решении
    "price": "0.00" // Инициализировать новое поле price в решении
  }
}
  • capability (полномочие): Полномочие, которым владеет роль, например, «Системный архитектор», разрешающее преобразовывать базовые продукты в продукты для интернет-магазина.

Вызов Refine будет выглядеть так:

aug:products/superwidget?2 = Refine(aug:products/superwidget?1, aug:migrations/evolve-to-shop-item?1, aug:capability-architect-master?1)

Эта операция создаёт новую ревизию того же Vibe (aug:products/superwidget?1), потому что инструкция migrations/evolve-to-shop-item?1 приводит к схеме, которая является совместимым уточнением (более конкретной версией) исходной. Это означает, что любая система, которая умела работать с базовой структурой продукта, всё равно сможет понять и новую, расширенную структуру; она просто проигнорирует новые поля stockLevel и price, если не была запрограммирована на их использование. Система записывает это в реестр как следующую ревизию для aug:products/superwidget?1. Если бы изменение схемы было принципиально несовместимым, это привело бы к созданию Vibe с новым, отдельным идентификатором.

Результатом является новая ревизия Vibe, теперь идентифицируемая как aug:products/superwidget?2 (система управляет версионированием внутри, эта запись — для ясности примера). Эта новая ревизия и есть версия продукта, готовая для магазина:

  • Её поле schema теперь содержит новое, расширенное определение JSON Schema («Структура товара для магазина»): 
    // Содержимое поля 'schema' для aug:products/superwidget?2
{
  "type": "object",
  "properties": {
    "productName": { "type": "string" },
    "description": { "type": "string" },
    "promoImage": { "type": "string", "format": "uri" },
    "stockLevel": { "type": "integer", "minimum": 0, "description": "Текущий остаток на складе" },
    "price": { "type": "number", "format": "currency", "description": "Розничная цена" }
  },
  "required": ["productName", "description", "stockLevel", "price"]
}
  • Её поле solution теперь содержит исходные данные плюс новые поля stockLevel и price, соответствующие новой «Структуре товара для магазина»: 
    // aug:products/superwidget?2#solution
{
  "productName": "Супер Виджет",
  "description": "Лучший виджет для ваших нужд.",
  "promoImage": "http://example.com/superwidget.png",
  "stockLevel": 0,
  "price": "0.00"
}
    Исходный aug:products/superwidget?1 остаётся в реестре без изменений. Другие базовые Vibe продуктов (например, aug:products/anotheritem?1) пройдут через аналогичные операции Refine, чтобы превратиться в свои версии для магазина (например, aug:products/anotheritem?2).

Последующие обновления данных по новой схеме: Теперь, когда aug:products/superwidget?2 имеет «Структуру товара для магазина» в своём поле schema, «Менеджеру по запасам» можно предоставить полномочия для обновления его solution.

  • target (цель): aug:products/superwidget?2.
  • instruction (инструкция): Vibe aug:updates/update-stock?1, solution которого указывает { "stockLevel": 150 }.
  • capability (полномочие): Полномочие, которым владеет «Менеджер по запасам».

Вызов Refine: aug:products/superwidget?3 = Refine(aug:products/superwidget?2, aug:updates/update-stock?1, aug:capability-inventory-mgr?1)

Это создаёт aug:products/superwidget?3 — новую ревизию Vibe продукта с обновлённым количеством на складе в его solution. Его поле schema остаётся «Структурой товара для магазина» (как определено в aug:products/superwidget?2).

Продвинутое развитие схемы: миграция на новую версию

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

Основная идея — использовать данные старого Vibe продукта (в качестве instruction) для заполнения и финализации нового Vibe (target), который уже структурирован по новой версии схемы и представляет собой конкретную мигрируемую сущность.

Сценарий: добавление priceInCents и удаление price

Допустим, наши существующие Vibe продуктов версии 1 (например, aug:products/superwidget?3) были созданы на основе Vibe-образца aug:products/example?1.

  • Поле schema для aug:products/example?1 (а значит, и для aug:products/superwidget?3) определяет структуру продукта V1, которая включает строковое поле price.
  • Поле solution для aug:products/example?1 содержит примерные значения для продукта V1.

Теперь мы хотим перевести эти продукты V1 на новую структуру V2, представленную новым Vibe-образцом aug:products/example-v2?1. Эта новая структура V2 будет использовать целочисленное поле priceInCents для большей точности и удалит старое поле price.

  1. Проектирование Vibe-образца aug:products/example-v2?1: Этот Vibe задаёт шаблон для всех продуктов V2. Он будет включать:

    - **`input`**: Примерные или типичные входные поля для `aug:products/example-v2?1` (например, `{"id": "generic-products/example-v2-guid", "productId": "PROD-V2-EXEMPLAR"}`).
- **`schema`**: Это поле содержит новое определение JSON «ProductSchemaV2»:
  ```json
  // "ProductSchemaV2" - для встраивания в поле .schema для `aug:products/example-v2?1` и его производных
  {
    "type": "object",
    "properties": {
      "productId": {
        "type": "string",
        "description": "Уникальный бизнес-идентификатор продукта"
      },
      "productName": { "type": "string" },
      "description": { "type": "string" },
      "promoImage": { "type": "string", "format": "uri" },
      "stockLevel": { "type": "integer", "minimum": 0 },
      "priceInCents": {
        "type": "integer",
        "minimum": 0,
        "description": "Розничная цена в центах"
      }
    },
    "required": ["productId", "productName", "description", "stockLevel", "priceInCents"]
  }
  ```
- **`solution`**: Пример `solution`, соответствующий «ProductSchemaV2», показывающий стандартные данные V2 для `aug:products/example-v2?1`:
  ```json
  {
    "productId": "PROD-V2-EXEMPLAR",
    "productName": "Универсальный продукт V2",
    "description": "Это стандартный продукт версии 2.",
    "promoImage": "http://example.com/generic-v2.png",
    "stockLevel": 0,
    "priceInCents": 0
  }
  ```
  При миграции конкретного продукта, такого как SuperWidget, целевой Vibe (`target`), например `aug:products/superwidget-v2-base?1`, будет экземпляром или производным, который принимает эту структуру V2 (т.е. его поле `schema` будет идентично `aug:products/example-v2?1#schema`, а его `solution` будет иметь поля V2, основанные на `aug:products/example-v2?1#solution` и особенностях SuperWidget).

  2. Операция Refine для миграции (Пример: SuperWidget): Чтобы создать Vibe V2 для SuperWidget, соответствующий структуре из aug:products/example-v2?1#schema и заполненный данными из aug:products/superwidget?1:

    - **`target` (цель)**: Сам Vibe-образец `aug:products/example-v2?1`. Этот Vibe (определённый в Шаге 1) предоставляет структурный шаблон (его поле `schema`) и значения V2 по умолчанию (его поле `solution`) для создаваемого Vibe.

- **`instruction` (инструкция)**:
  Как правило, `solution` Vibe-инструкции предоставляет данные или директивы для операции `Refine`. Его формат очень гибкий и не предписан системой; это может быть естественный язык, исполняемый код, структурированные данные (например, JSON или XML) или даже примеры «до и после». Процесс, авторизованный `capability`, отвечает за интерпретацию этого `solution`, возможно, с использованием инструментов, таких как LLM, или специальных парсеров и логики.

  В этом конкретном сценарии миграции мы иллюстрируем простой подход, где существующий Vibe продукта V1 сам служит в качестве `instruction`. Для миграции SuperWidget:
    - `instruction` — это `aug:products/superwidget?3` (Vibe SuperWidget V1, используя номер ревизии из ваших предыдущих правок).
    - Его `solution` (содержащее все данные продукта V1, такие как исходные `productName`, `description`, `price`, `stockLevel` и т.д.) напрямую предоставляет исходный материал для миграции.

  Процесс, авторизованный `capability` (см. ниже), отвечает за интерпретацию этих данных V1. Он обычно:
    - Использует `aug:products/example-v2?1#schema` (из целевого Vibe) в качестве структурного шаблона для нового продукта V2.
    - Извлекает соответствующие данные из `solution` Vibe-инструкции (т.е. `aug:products/superwidget?3#solution`).
    - Выполняет необходимые преобразования (например, конвертирует строку `price` в целое число `priceInCents`).
    - Заполняет новую структуру V2. Любые поля, специфичные для V2, которые нельзя напрямую получить из данных V1 (например, новый `productId` для версии V2, если это необходимо, или значения по умолчанию для совершенно новых полей V2), будут либо сгенерированы этой логикой миграции, либо взяты из `solution` по умолчанию целевого образца (`aug:products/example-v2?1#solution`).

- **`capability` (полномочие)**: Полномочие, скажем, `aug:migrations/product#v1-to-v2`. Это разрешение авторизует операцию `Refine` над образцом `aug:products/example-v2?1`, используя Vibe продукта V1 (например, `aug:products/superwidget?3`) в качестве инструкции для создания нового Vibe продукта V2. Логика преобразования данных и заполнения полей V2 инкапсулирована в процессе, действующем под этим полномочием.

Вызов `Refine` приведёт к созданию нового Vibe с отдельным идентификатором:
`aug:products/superwidget-v2?1 = Refine(target: aug:products/example-v2?1, instruction: aug:products/superwidget?3, capability: aug:migrations/product#v1-to-v2)`

  3. Результат (SuperWidget): Создаётся новый записывающий Vibe, aug:products/superwidget-v2?1 (обратите внимание на новый идентификатор):

    • Его поле schema идентично aug:products/example-v2?1#schema (унаследовано от целевого образца).
    • Его поле solution теперь заполнено в соответствии с aug:products/example-v2?1#schema. Данные получены процессом миграции (авторизованным capability) с использованием данных V1 из aug:products/superwidget?3#solution в качестве основного источника: 
      // aug:products/superwidget-v2?1#solution
{
  "productId": "SW-001", // Перенесено из V1 для сохранения идентичности продукта
  "productName": "SuperWidget Pro", // Возможно, обновлено в процессе миграции
  "description": "Следующее поколение SuperWidget.", // Возможно, обновлено в процессе миграции
  "promoImage": "http://example.com/superwidget-v2.png", // Возможно, обновлено в процессе миграции
  "stockLevel": 150, // Перенесено из данных V1 (aug:products/superwidget?3#solution)
  "priceInCents": 1999 // Преобразовано из цены V1 (aug:products/superwidget?3#solution)
}
    • Исходные Vibe (aug:products/superwidget?3 и aug:products/example-v2?1) остаются нетронутыми.

    (Примечание: productId, показанный здесь, является бизнес-идентификатором продукта, определённым его схемой и являющимся частью его solution. Это отличается от уникального системного UUID Vibe, который является метаданными вне solution.)

  4. Миграция другого продукта (например, SuperGizmo): Чтобы мигрировать другой продукт V1, скажем, aug:products/supergizmo?1 (предполагая, что это продукт V1), в его версию V2:

    • target остаётся Vibe-образцом aug:products/example-v2?1.
    • instruction будет сам aug:products/supergizmo?1.
    • Можно использовать то же capability (aug:migrations/product#v1-to-v2).
    • Вызов Refine: aug:products/supergizmo-v2?1 = Refine(target: aug:products/example-v2?1, instruction: aug:products/supergizmo?1, capability: aug:migrations/product#v1-to-v2) Это создаст aug:products/supergizmo-v2?1, соответствующий схеме, определённой в aug:products/example-v2?1#schema.

Преимущества этого подхода к миграции:

  • Чистые версии схемы: Новые Vibe (aug:products/superwidget?1) являются чистыми экземплярами новой версии схемы, не неся в своей структуре устаревшие поля.
  • Явная логика преобразования: Vibe-инструкция (или процесс, интерпретирующий её, авторизованный capability) явно определяет логику преобразования или миграции с V1 на V2. Сама эта логика поддаётся аудиту и может быть версионирована.
  • Полная неизменяемость и отслеживаемость: Исторический Vibe (aug:products/superwidget?1) остаётся, обеспечивая полный аудиторский след. Происхождение aug:products/superwidget?1 от его истоков V1 ясно.
  • Возможность поэтапного внедрения: Системы, использующие данные о продуктах, могут со временем обновляться для понимания «ProductSchemaV2». Во время перехода некоторые системы могут читать Vibe V1 (если они всё ещё существуют и актуальны), а другие — Vibe V2.

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

Цепочка авторизации и эволюции: Этот пример иллюстрирует цепочку:

  1. Высокоуровневая бизнес-потребность (запуск магазина) запускает...
  2. Авторизованный персонал (Системный архитектор) выполняет эволюцию схемы, применяя операцию Refine к существующим записывающим Vibe с определёнными Vibe-инструкциями. Поле solution этих инструкций диктует изменения как в содержимом поля schema (структуре), так и в содержимом поля solution (данных) целевого Vibe, под действием авторизующего Полномочия.
  3. В результате создаются новые записывающие Vibe, каждый из которых содержит обновлённое структурное определение в своём поле schema и соответствующие данные в поле solution.
  4. Эта развитая структура затем позволяет другим ролям (Менеджер по запасам) получать Полномочия для выполнения новых типов операций с данными в solution этих Vibe.

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

Практическое управление разрешениями для операций Refine

Разрешения являются гранулярными и ориентированными на задачи, предоставляются через конкретные допуски (permits). Эти допуски могут разрешать действия с конкретными экземплярами Vibe или, что более мощно, с любым Vibe, который соответствует указанной схеме (определённой в Vibe-образце). Ниже приведены примеры из электронной коммерции, иллюстрирующие это, где каждый сценарий разбит на шаги с использованием aug:/... для глобальных/абсолютных путей и aug:... для локальных путей (подразумевается в контексте текущей компании):

  • Продакт-менеджеры и запуск нового продукта: Продакт-менеджер запускает различные новые электронные гаджеты.

    • Выданное разрешение: «Разрешение на создание новых карточек товаров из утверждённых образцов продуктов с использованием стандартных инструкций по запуску», экземпляр aug:/permits/spawn-policy?1.
    • Действие: Продакт-менеджер уполномочен изменять (refine) любой целевой Vibe-образец, поле schema которого определяет структуру электронного продукта (например, aug:products/electronics-product?1, который служит базовым Vibe для электронных продуктов), используя любую инструкцию, соответствующую схеме aug:schema-instruction-launch?1.
    • Результат: Это позволяет создавать различные новые Vibe продуктов. Например, для создания конкретных умных часов целью может быть aug:products/smartwatch?1 (Vibe-образец для умных часов, который сам может быть производным от aug:products/electronics-product?1), а инструкцией — aug:announcements/smartwatch-gen5-details?1. Результатом будет aug:products/smartwatch-gen5?1. Аналогично для aug:products/earbuds-pro?1 из образца aug:products/earbuds?1.

  • Менеджеры по запасам и корректировка уровня запасов: Менеджеру по запасам необходимо обновлять уровни запасов для любого продукта на основе поступающих данных.

    • Выданное разрешение: «Разрешение на обновление количества запасов для любого продукта с отслеживанием инвентаря через системные каналы», экземпляр aug:/permits/input-change?1.
    • Действие: Менеджер по запасам уполномочен изменять (refine) любой целевой Vibe продукта, чьё поле schema соответствует структуре, определённой в образце aug:products/inventory-tracked-product?1, используя конкретную инструкцию, такую как aug:feeds/stock-feed?1.
    • Результат: Поле stockLevel в любом допустимом Vibe продукта (например, aug:products/smartwatch-gen5?1, aug:products/charger-c30?1) может быть обновлено.

  • Специалисты по маркетингу и настройка промо-кампаний: Специалисту по маркетингу необходимо определять различные типы правил скидок для распродаж.

    • Выданное разрешение: «Разрешение на определение новых правил скидок в системе промо-акций через утверждённые структуры правил», экземпляр aug:/permits/schema-govern?1.
    • Действие: Специалист по маркетингу уполномочен изменять (refine) целевой aug:schema-promo-rules?1, используя любой Vibe-инструкцию, который соответствует aug:schema-instruction-discount?1 (например, инструкции для скидок в процентах, «купи один — получи второй в подарок» или многоуровневых скидок).
    • Результат: Различные новые структуры правил скидок (например, percentage-off-category-x, bogo-on-accessories) могут быть добавлены в глобальную схему правил промо-акций.

  • Контент-райтеры и обновление описаний продуктов: Контент-райтеру необходимо обновлять маркетинговые тексты на любой странице продукта.

    • Выданное разрешение: «Разрешение на обновление контента страниц продуктов для любого продукта в соответствии с SEO-рекомендациями», экземпляр aug:/permits/editorial?1.
    • Действие: Контент-райтер уполномочен изменять (refine) любой целевой Vibe страницы продукта, соответствующий схеме aug:schema-prod-page?1, используя конкретную инструкцию aug:guide-seo-desc?1.
    • Результат: Поля description и marketingCopy в решении любого допустимого Vibe страницы продукта (например, aug:products/smartwatch-gen5?1) могут быть обновлены.

  • Руководители службы поддержки и корректировка заказов: Руководителю службы поддержки необходимо обрабатывать различные типы стандартных корректировок заказов.

    • Выданное разрешение: «Разрешение на корректировку заказов клиентов в соответствии со стандартными протоколами обслуживания», экземпляр aug:/permits/merge-policy?1 (или более конкретное разрешение на корректировку).
    • Действие: Руководитель поддержки уполномочен изменять (refine) любой целевой Vibe заказа клиента, соответствующий схеме aug:schema-order?1, используя любую инструкцию, которая соответствует утверждённой aug:schema-instruction-order-adj?1 (например, для частичных возвратов, изменений в доставке, замены товаров, определённых конкретными протоколами).
    • Результат: Могут быть созданы новые версии различных Vibe заказов клиентов (например, aug:order-12345?1, aug:order-67890?1), отражающие авторизованные корректировки.

Когда любой Vibe пытается изменить (refine) другой, система проверяет, что он владеет Полномочием (Capability), содержащим действительное разрешение. Это разрешение должно явно разрешать преобразование цели (либо конкретного Vibe, либо Vibe, соответствующего схеме) с помощью конкретной инструкции (либо конкретного Vibe, либо Vibe, соответствующего схеме). Само разрешение через своё определение и связанные схемы для цели и инструкции, использующие эти соглашения об именовании (глобальные aug:/ против локальных aug:), чётко определяет объём и ограничения разрешённого действия.