Storyblok Schema 1.0: структура контента в TypeScript и CLI
10 сентября 2026 года Storyblok объявил стабильную версию пакета @storyblok/schema 1.0. Модели блоков, полей и источников данных можно описывать объектами TypeScript и применять через CLI — инструмент командной строки. Для разработчиков и AI-агентов это делает структуру содержания частью проверяемой кодовой базы проекта.
Термин «схема содержания» означает правила организации материала: какие поля содержит карточка, какие значения обязательны и как связаны сущности. Такая схема влияет на редактора и отображение сайта. Поэтому её изменение требует большего внимания, чем добавление очередного абзаца в статью.
Что меняет стабильная версия
В официальном анонсе Storyblok описан перенос существующих схем в TypeScript, работа через команды CLI и обнаружение несовместимых изменений. При необходимости система предлагает заготовку миграции. Это именно заготовка: логику преобразования содержания разработчик должен определить и написать самостоятельно.
Есть существенное правило синхронизации. После перехода код объявляется единственным источником схем, а разделы Block Library и Datasources в интерфейсе не должны использоваться как параллельный редактор. Таким образом, речь идёт об осознанном выборе рабочего процесса, а не о двух равноправных местах, где можно независимо менять структуру.
Почему это полезно при работе с агентом
Представим студию, которая добавляет к карточкам проектов новое поле «регион». Агенту можно поручить подготовить описание поля и изменения отображения. Когда схема хранится рядом с кодом, команда видит точный набор правок, может обсудить его и повторить на другой среде. Поручение становится конкретнее: изменить определённый контракт, сохранив действующее содержание.
Но программный помощник не определяет смысл поля за владельца продукта. Нужно решить, допускается ли несколько регионов, какие значения считаются корректными и что делать с существующими карточками. Если эти вопросы не обсуждены, типизация поможет обнаружить часть ошибок, но не выберет нужную бизнес-модель.
Кодовая схема также упрощает передачу проекта между исполнителями. Новому разработчику легче увидеть устройство данных и историю изменения требований. Это преимущество проявляется, когда команда поддерживает описание и использует его в своей проверке, а не просто один раз выгружает настройки и забывает о файлах.
Где начинается настоящая миграция
Добавление необязательного поля и превращение его в обязательное — разные изменения. Во втором случае старые материалы могут перестать соответствовать новым правилам. Команда должна определить, чем заполнять поле, какие записи требуют ручного решения и как проверять результат. Автоматически предложенный файл миграции не отвечает на эти вопросы.
Для пилота полезно выбрать небольшую модель с несколькими существующими записями. Сначала добавить поле, затем подготовить заполнение и проверить отображение. После этого отдельно рассмотреть несовместимое изменение на тестовых данных. Такой процесс помогает понять, что именно CLI обнаруживает, а какая ответственность остаётся у разработчика и редактора.
Особенно важно соблюдать правило одного источника структуры. Если один участник меняет схему в коде, а другой — в интерфейсе, появляются расхождения и неясность при следующем применении. Команде нужен понятный порядок: где предлагается изменение, кто его проверяет и когда оно становится действующим для редакции.
Какой вывод можно сделать
Storyblok Schema 1.0 показывает движение CMS к воспроизводимым контрактам, с которыми могут работать и люди, и программные инструменты. Для AI-разработчика это полезная основа: он видит структуру явно и может подготовить обозримое изменение. Полноценная поддержка сайта всё равно включает решения о содержании, миграции и приёмке.
Смежная тема: AI-агенты внутри Storyblok и их полномочия. Источник и правила работы со схемами проверены 9 октября 2026 года. Статья не обещает автоматическую миграцию произвольной модели данных.