Prompt Server Delivery Plan

Статус: planned capability.

1. Область поставки

В будущую поставку должны входить:

  • runtime API;

  • prompt registry endpoints для published assets;

  • published-only repository boundary;

  • deployment/runtime topology;

  • authn/authz;

  • deterministic resolve/render behavior.

2. Текущий статус

Текущее состояние:

  • capability запланирована;

  • в кодовой базе пока не реализована;

  • документы описывают будущую boundary, а не текущий executable runtime.

3. Рабочие потоки и владельцы

Основные workstreams:

  • platform owner Service runtime and deployment.

  • core owner Published repository access and deterministic render integration.

  • security owner Access control, published-only enforcement, audit.

  • integration owner Client contract, Python SDK/client strategy, downstream adoption.

4. Карта зависимостей

Ключевые зависимости:

  • final API contract;

  • published-only repository access model;

  • deployment topology;

  • authn/authz policy;

  • compatibility policy;

  • decision on first downstream client surface.

5. Предварительные этапы rollout

Рациональная последовательность:

  1. Выделить API contract для registry, resolve и render.

  2. Formalize repository access model.

  3. Определить deployment topology.

  4. Зафиксировать compatibility policy.

  5. Провести architecture and security review.

  6. Реализовать representative deterministic runtime path.

  7. Добавить первый downstream client, например Python client.

6. Блокеры и риски

Основные блокеры:

  • нет реализованного server runtime;

  • не сформирована final API compatibility policy;

  • не детализированы authn/authz и deployment decisions.

Основные риски:

  • server accidentally becomes authoring surface;

  • server sees draft data;

  • runtime contract окажется слишком широким и нестабильным;

  • server mistakenly drifts toward generic LLM gateway;

  • client strategy будет выбрана раньше, чем server boundary.

7. Критерии готовности

Capability можно считать готовой к запуску только если:

  • published-only model proven in tests;

  • deployment topology agreed;

  • security review passed;

  • deterministic render replay stable;

  • no draft access paths remain;

  • registry endpoints и render endpoints согласованы как единый contract.

8. Следующий шаг после текущей итерации

Следующая полезная работа:

  • при старте реализации не смешать server rollout с Python bindings rollout;

  • сначала зафиксировать API для published prompt registry and render;

  • затем отдельно принять решение о Python client/bindings strategy;

  • отдельно оформить authn/authz и deployment ADR, если это потребуется.