Prompt Server Runbook

Статус: placeholder для planned capability.

1. Операционный обзор

Будущий сервис:

  • будет обслуживать downstream consumers published prompts;

  • будет обслуживать published prompt registry lookups и deterministic render;

  • должен иметь высокую значимость для delivery-side клиентов;

  • не должен зависеть от draft authoring state.

Критичность:

  • высокая для downstream consumers

2. Владение и модель поддержки

Основной владелец:

  • будущий platform/runtime owner

Смежные владельцы:

  • владелец prompt library

  • security owner

3. Ключевые сигналы и наблюдаемость

Нужно будет смотреть:

  • repository access failures;

  • authn/authz failures;

  • render error spikes;

  • registry lookup failures;

  • нарушения published-only policy;

  • latency and availability of deterministic resolve/render.

4. Типовые сбои

Ожидаемые failure modes:

  • published store unavailable;

  • invalid runtime parameter requests;

  • misconfigured access control;

  • accidental attempt to access draft data;

  • compatibility mismatch between clients and runtime contract;

  • registry metadata endpoints inconsistent with render endpoints.

5. Реакция на инцидент

Ожидаемый порядок действий:

  1. Проверить published repository connectivity.

  2. Проверить authn/authz rules.

  3. Проверить registry resolution for affected asset ids and versions.

  4. Проверить published-only access enforcement.

  5. Проверить deterministic render path on representative published assets.

  6. Убедиться, что нет fallback to draft data.

6. Режимы деградации

Потенциально допустимые режимы деградации:

  • read-only degraded mode;

  • отключение optional introspection endpoints;

  • fail closed при недоступности published store.

Недопустимая деградация:

  • переход на draft data как "временный обход".

7. Восстановление и проверка

После восстановления необходимо:

  1. Восстановить доступ к published repository.

  2. Повторить registry lookup and deterministic render test cases.

  3. Проверить, что draft data не видны через runtime API.

  4. Проверить representative client flows, включая Python/backend clients.

8. Когда эскалировать

Эскалировать нужно, если:

  • нарушена published-only policy;

  • есть признаки утечки draft data;

  • downstream clients не могут воспроизвести published render behavior;

  • access control сломан или двусмысленен.

9. Контакты эскалации

  • Platform owner

  • Prompt library owner

  • Security owner