Prompt Server PRD

он должен стать published prompt registry;

он должен предоставлять deterministic resolve/render API;

он должен отделить authoring workbench от runtime consumption;

он должен дать командам способ использовать TextFoundry не только как desktop tool, но и как инфраструктурный prompt layer;

он должен быть доступен как из C++, так и из Python.

внешние и внутренние клиенты не должны ходить напрямую в authoring workflow или local storage;

опубликованные prompt assets требуют отдельной runtime boundary;

нужен способ получать render по composition id + version + params;

нужен registry-side контракт для published blocks and compositions;

есть продуктовая возможность закрыть часть сценариев, для которых сейчас команды используют Langfuse-like prompt storage или самописные registry;

remote runtime contract должен быть одинаково пригоден для C++ и Python clients.

предоставить published-only runtime для resolve/render prompt assets;

сделать published prompt assets адресуемыми и доступными по API;

сохранить deterministic delivery contract;

не превратить сервер в удалённый редактор;

создать server boundary, поверх которой позже можно строить Python SDK или C++/Python client layers;

сохранить симметричную multi-language story: local engine surfaces и remote server surfaces.

capability включена в целевую архитектуру;

отдельного server runtime пока нет;

доступ к assets идёт через authoring-oriented surfaces и локальный engine.

нет выделенного delivery runtime;

published-only boundary пока не воплощена в отдельном сервисе;

есть риск смешать authoring и consumption semantics;

нет внешнего API для published prompt registry;

downstream clients не могут стабильно запрашивать render как серверную функцию;

продукт пока сильнее как workbench, чем как runtime platform.

сервер обслуживает prompt assets для LLM use cases;

он может стать альтернативой prompt-storage части Langfuse-like решений;

при этом сам базовый delivery contract должен оставаться deterministic, а не зависеть от live model execution.

backend services, которым нужен published render;

Python-based clients и evaluation scripts;

C++ runtime clients;

agent runtimes и orchestration layers;

external/internal clients, consuming published prompt assets;

platform owner;

integrators, которым нужен read-only runtime contract.

resolve composition by id and version;

render with runtime parameters;

inspect available published assets and versions;

получать metadata о том, какие block versions вошли в render;

использовать published assets без доступа к drafts и authoring operations;

вызывать один и тот же published prompt из Python, C++ backend и agent clients по единому API.

клиенты смогут потреблять published assets без доступа к drafts;

published blocks and compositions будут адресуемыми как registry entities;

render будет вызываться как понятная серверная функция;

runtime behavior будет воспроизводимым;

граница между authoring и delivery останется чистой и понятной;

downstream clients смогут использовать TextFoundry как prompt registry, а не только как локальный editor.

published-only policy доказуема тестами и API shape;

server contract не требует знания внутренних authoring surfaces;

downstream clients не зависят от GUI/TUI semantics;

API позволяет безопасно строить как Python, так и C++ remote clients поверх того же server boundary.

предоставлять published-only access;

адресовать blocks and compositions по identity и version;

уметь resolve-ить published assets по идентичности и версии;

выполнять deterministic render с runtime params;

возвращать metadata о resolved versions;

поддерживать server-side lookup published assets;

валидировать входные параметры;

возвращать понятные runtime errors;

не изменять authoring state;

быть language-neutral на уровне contract semantics.

быть воспроизводимым и предсказуемым;

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

не fallback-ить к draft data;

иметь более узкий и строгий контракт, чем authoring engine;

поддерживать ясную security boundary;

быть пригодным для использования из нескольких типов клиентов;

иметь version-aware compatibility policy.

capability пока не реализована;

storage model уже различает published и draft сущности;

будущая реализация не должна размывать существующие authoring boundaries;

Prompt Server не должен описываться как complete Langfuse replacement.

published repositories и renderer останутся базой delivery runtime;

отдельный API слой будет добавлен позже;

operational, security и compatibility policy будут оформлены до реализации;

local C++ и Python surfaces будут жить поверх общей engine model;

remote C++ и Python clients будут жить поверх общего server contract.

published repository access;

renderer;

parameter validation layer;

server API layer;

authn/authz and deployment decisions;

compatibility policy;

local bindings strategy;

remote client SDK decisions.

platform owner;

prompt authors;

downstream clients;

C++ runtime integrators;

Python/runtime integrators;

security and operations owners.

published-only resolve/render contract работает на representative assets;

published registry endpoints позволяют получать versions and metadata;

draft data не попадают в server responses;

failure behavior понятен и безопасен;

базовый Python и C++ client могут вызвать render без знания desktop internals.

operational constraints формализованы;

security model определена;

compatibility policy согласована;

server не выполняет authoring mutations ни напрямую, ни косвенно;

целевая роль как published prompt registry + deterministic render API зафиксирована и отражена в API shape.