Как должен работать Prompt Server и как синхронизируются изменения клиента и сервера

Этот документ написан как объясняющий материал, а не как формальный ADR.

Его задача:

  • максимально понятно объяснить, почему Prompt Server сейчас описан как published-only;

  • показать, как в этой модели синхронизируются изменения между workbench и server runtime;

  • сравнить это с вариантом, где сервер сам умеет authoring mutations;

  • показать, почему оба варианта используют один и тот же core engine, но по-разному ограничивают его снаружи.

1. Короткий ответ

Если сформулировать совсем коротко:

  • Workbench создаёт и редактирует drafts;

  • Publish превращает draft в immutable published version;

  • Prompt Server читает только published versions;

  • синхронизация между клиентом и сервером происходит не на уровне "живых правок", а на уровне publish.

То есть синхронизируется не editor state, а опубликованные версии.

2. Почему вообще возникает вопрос про синхронизацию

Интуитивно хочется представить систему так:

  • есть клиент;

  • есть сервер;

  • клиент что-то меняет;

  • сервер должен как-то синхронизировать это с собой.

Но у TextFoundry есть важная особенность:

  • система различает Draft и Published.

Из-за этого существует два принципиально разных класса синхронизации:

  • синхронизация черновиков и живых редакторских сессий;

  • синхронизация опубликованных immutable versions.

Именно между ними проходит главная архитектурная граница.

3. Базовая модель продукта

Diagram

Что это означает:

  • workbench и server не конкурируют за одну и ту же роль;

  • workbench отвечает за authoring;

  • server отвечает за delivery;

  • server не должен обслуживать незавершённые черновики как production truth.

4. Где именно происходит синхронизация

В текущей архитектурной ставке событие синхронизации выглядит так:

  • пользователь редактирует draft локально;

  • выполняет review;

  • выполняет publish;

  • новая published version становится доступна server runtime.

Diagram

Ключевая мысль:

  • единица синхронизации здесь не draft change;

  • единица синхронизации здесь published version.

5. Почему это проще и надёжнее

Когда синхронизируются только published versions:

  • server не нужно понимать dirty state;

  • server не нужно знать про edit sessions;

  • server не нужно разруливать merge conflicts по drafts;

  • server не нужно решать, какой незавершённый edit "настоящий";

  • проще делать audit и воспроизводимость.

С архитектурной точки зрения это означает:

  • sync event = publish;

  • source of truth для delivery = published;

  • runtime clients никогда не видят случайный промежуточный state.

6. Как это связано с запретом publish/update/delete/deprecate на сервере

Если Prompt Server не имеет mutation endpoint-ов, то он:

  • не участвует в authoring;

  • не создаёт drafts;

  • не меняет published state;

  • не становится второй точкой входа в lifecycle assets.

Из этого следует, что sync story становится очень простой:

  • workbench меняет;

  • publish фиксирует;

  • server читает.

Это и есть главная причина, почему такой вариант легче сопровождать.

7. Но разве сервер и клиент не должны использовать один и тот же движок

Должны. И это важный момент.

Нынешняя идея не в том, чтобы делать два разных engine. Идея в том, чтобы один и тот же core engine использовать через разные boundary.

Diagram

То есть:

  • engine общий;

  • domain model общая;

  • renderer общий;

  • versioning logic общая.

Разница не в движке, а в том, какой слой имеет право вызывать какие операции.

8. Что значит "тот же engine, но другой boundary"

Это означает примерно следующее.

Workbench может использовать engine для:

  • draft editing;

  • validation;

  • publish;

  • deprecate/delete;

  • compare/update;

  • AI-assisted authoring workflows.

Prompt Server может использовать тот же engine только для:

  • read published asset;

  • resolve published composition;

  • validate runtime params;

  • deterministic render.

То есть engine один, а permission surface разная.

9. Как practically может быть устроена синхронизация published state

Есть три реалистичных варианта.

9.1. Общий storage

Diagram

Смысл:

  • workbench и server смотрят в одно и то же versioned хранилище;

  • publish создаёт новую published version;

  • server начинает видеть её сразу или почти сразу.

Плюсы:

  • просто;

  • почти нет дополнительной sync-логики;

  • один source of truth.

Минусы:

  • tighter coupling;

  • server и authoring сильнее связаны инфраструктурно;

  • сложнее изолировать delivery environment.

9.2. Репликация published entities

Diagram

Смысл:

  • publish в authoring системе создаёт published version;

  • затем published version реплицируется в server-side store;

  • server работает только со своей published replica.

Плюсы:

  • чище отделены authoring и delivery;

  • легче делать отдельный deployment;

  • можно контролировать release flow.

Минусы:

  • появляется replication lag;

  • нужен отдельный propagation pipeline.

9.3. Export/import published bundles

Diagram

Смысл:

  • publish создаёт не просто запись в storage, а переносимый release artifact;

  • server импортирует такие published bundles.

Плюсы:

  • очень чистая release model;

  • хорошо для controlled environments;

  • удобно для auditable delivery.

Минусы:

  • heavier operational flow;

  • меньше ощущение "живой" синхронизации.

10. Какой вариант кажется самым естественным

Если говорить про эволюцию проекта по шагам:

  • сначала естественнее shared storage или very thin published replication;

  • позже, если появится отдельная server platform, логичнее перейти к replicated published store.

Почему:

  • это сохраняет простую mental model;

  • это не требует сразу строить сложную release platform;

  • это согласуется с тем, что server работает только с published data.

11. Что ломается, если сервер тоже умеет authoring mutations

Теперь посмотрим на альтернативу:

  • server умеет publish, update, delete, deprecate;

  • возможно, умеет и draft operations.

Тогда система перестаёт быть простой.

Diagram

Здесь уже возникает вопрос:

  • кто владелец draft;

  • как синхронизировать одновременные изменения;

  • как отлавливать конфликты между GUI и remote clients;

  • как представлять dirty state;

  • как устроены edit sessions;

  • где проходит review before publish.

То есть ты уже строишь не prompt registry/render server, а distributed authoring system.

12. Что это меняет в модели синхронизации

В authoring-capable server уже недостаточно publish propagation. Нужна полноценная distributed sync model.

Diagram

В такой системе уже нужны:

  • revision ids;

  • optimistic locking;

  • conflict resolution;

  • draft ownership model;

  • merge semantics;

  • edit session protocol.

Это не "плохая" система. Но это заметно более сложный продукт.

13. Почему текущая ставка архитектурно легче

Сравнение:

Published-only Prompt Server:

  • проще sync model;

  • проще security;

  • проще API compatibility;

  • проще observability of correctness;

  • проще объяснить пользователям.

Authoring-capable Server:

  • гибче;

  • сильнее как удалённая платформа;

  • но требует намного более сложного lifecycle and consistency model.

Поэтому текущая ставка не утверждает, что mutation endpoints "никогда нельзя". Она утверждает другое:

  • для первого server product layer лучше published-only model.

14. Что это означает для рендера

Важно: рендер всё равно остаётся на том же engine.

Diagram

То есть render path не страдает от того, что server read-only. Наоборот, он становится чище:

  • server берёт published composition;

  • engine resolve-ит published block versions;

  • renderer строит deterministic output;

  • клиент получает результат и metadata.

15. Практический вывод

Если сформулировать совсем прямо:

  • да, клиент и сервер могут использовать один и тот же engine;

  • нет, это не требует, чтобы server умел все те же mutation operations;

  • в текущей модели синхронизация происходит через publish, а не через distributed live editing;

  • именно поэтому published-only Prompt Server пока выглядит более устойчивой и понятной архитектурной ставкой.

16. Когда стоит пересматривать эту модель

Текущую ставку стоит пересмотреть, если продукту действительно понадобится:

  • remote authoring from multiple clients;

  • shared draft editing;

  • server-side publish workflows;

  • multi-user collaborative prompt editing;

  • central admin/API control over prompt lifecycle.

Тогда уже нужно будет честно проектировать не просто Prompt Server, а Remote Authoring Platform.

17. Связанные документы