Prompt Server System Design

Статус: planned, not implemented.

1. Краткое резюме

Prompt Server задуман как deterministic delivery boundary поверх published assets. Он должен отделить authoring system от runtime consumption и работать только с опубликованными данными, не наследуя draft или GUI-specific semantics.

В целевом виде это не просто remote render endpoint, а published prompt registry + deterministic render API.

2. Контекст и границы

В области охвата:

  • published prompt registry;

  • read-only resolve/render API;

  • published-only access;

  • parameter validation;

  • deterministic delivery runtime.

Вне области охвата:

  • authoring;

  • draft mutation;

  • AI-assisted editing;

  • automatic semantic rewrite;

  • доступ к GUI review states и raw preview semantics.

Смежные и целевые будущие клиенты:

  • C++ remote client;

  • Python remote client / SDK;

  • backend services;

  • agent runtimes.

3. Архитектурные требования

Будущий server boundary должен:

  • работать только с published repository view;

  • использовать deterministic render path как основной runtime contract;

  • делать blocks and compositions адресуемыми server entities;

  • не иметь mutation endpoints;

  • fail closed при недоступности published data;

  • не fallback-ить к draft state;

  • иметь более строгий API, чем внутренний authoring engine.

4. Предполагаемые компоненты

Планируемые компоненты:

  • server API layer Внешний контракт для registry lookups, resolve и render.

  • published repository access layer Читает только published assets.

  • renderer Выполняет deterministic resolve/render published compositions.

  • optional parameter validation layer Проверяет runtime params до render.

  • authn/authz layer Ограничивает доступ к delivery API.

  • future remote client layer Вне server runtime, включает C++ и Python clients к одному server contract.

  • local bindings layer Вне server runtime, включает local C++ and Python surfaces поверх того же engine semantics.

5. Базовый сценарий

Diagram

Шаги:

  1. Клиент на C++ или Python запрашивает published composition, block или render.

  2. Server resolve-ит identity и version через published repository.

  3. Для render-запроса выполняется parameter validation.

  4. Renderer строит deterministic result.

  5. Server возвращает metadata и, если нужно, rendered text клиенту.

6. Целевые API-группы

На уровне capability ожидаются три группы endpoint-ов:

  • registry endpoints lookup published blocks/compositions, versions and metadata.

  • resolve endpoints получить resolved composition view и входящие published dependencies.

  • render endpoints получить deterministic rendered prompt с runtime params.

На этом этапе не фиксируется окончательный transport, но shape контракта должен поддерживать примерно такие сценарии:

  • GET /blocks/{id}

  • GET /compositions/{id}

  • GET /compositions/{id}/versions

  • POST /render

  • POST /resolve

7. Language Surface Model

В целевой архитектуре нужно различать четыре поверхности:

  • C++ local API local engine access.

  • Python local API local engine access with Python-idiomatic form.

  • C++ remote client server access over remote contract.

  • Python remote client server access over the same remote contract.

Server design не должен предполагать, что Python является единственным или основным удалённым клиентом.

8. Границы безопасности и доверия

Ключевые правила:

  • draft assets недоступны server runtime;

  • publish/update/delete не являются частью server API;

  • server не должен выполнять authoring-side AI workflows;

  • GUI-specific preview modes не являются частью delivery contract.

9. Надёжность и деградация

При недоступности published repository:

  • сервис должен fail closed.

При некорректных параметрах:

  • сервер должен возвращать validation error.

При отсутствии runtime implementation:

  • документация должна явно помечать capability как planned, а не как уже работающий сервис.

10. Сравнение с adjacent systems

Этот server design ближе к prompt registry/render service, чем к:

  • generic LLM gateway;

  • observability platform;

  • remote authoring API.

Поэтому его корректнее сравнивать с prompt-management частью Langfuse-like систем, а не с full tracing platform.

Сильные стороны такого выбора:

  • сохраняется asset-centric модель;

  • версии и identity остаются first-class concepts;

  • deterministic render остаётся центральным runtime contract.

11. Операционные свойства

Ожидаемые свойства:

  • published-only policy;

  • deterministic rendering;

  • stricter runtime API surface;

  • отдельный operational surface по сравнению с GUI/TUI workbench;

  • возможность использовать один и тот же published prompt через несколько типов клиентов и из двух language surfaces.

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

Upstream:

Downstream: