---
doc_id: DLV-CK8S-AGENT-MANAGER
type: delivery-plan
title: kodex — поставка agent-manager
status: active
owner_role: EM
created_at: 2026-05-12
updated_at: 2026-06-03
related_issues: [733, 739, 744, 749, 755, 759, 772, 322, 782, 795, 809, 820, 834, 842, 862, 866, 891, 897, 905, 918, 937, 946, 954, 968, 984, 994, 999, 1011, 1015, 1022, 1027]
related_prs: []
related_docsets:
  - docs/domains/agent-orchestration/product/requirements.md
  - docs/domains/agent-orchestration/architecture/design.md
  - docs/domains/agent-orchestration/architecture/data_model.md
  - docs/domains/agent-orchestration/architecture/api_contract.md
  - docs/domains/agent-orchestration/ops/agent_manager_runbook.md
  - docs/domains/agent-orchestration/ops/agent_manager_monitoring.md
approvals:
  required: ["Owner"]
  status: approved
  request_id: "owner-2026-05-12-agent-manager-kickoff"
  approved_by: "ai-da-stas"
  approved_at: 2026-05-12
---

# Поставка agent-manager

## TL;DR

`agent-manager` поставляется малыми срезами: сначала доменный пакет документации, затем транспортные контракты, сервисный каркас, модель flow/role/prompt, сессии и `Run`, интеграции с package/runtime, машина приёмки, follow-up задачи, связи с provider/governance/interaction контурами и эксплуатационный контур первого backend deploy.

## Входные артефакты

| Документ | Путь |
|---|---|
| Требования домена | `docs/domains/agent-orchestration/product/requirements.md` |
| Дизайн домена | `docs/domains/agent-orchestration/architecture/design.md` |
| Модель данных | `docs/domains/agent-orchestration/architecture/data_model.md` |
| API-обзор | `docs/domains/agent-orchestration/architecture/api_contract.md` |
| Runbook | `docs/domains/agent-orchestration/ops/agent_manager_runbook.md` |
| Наблюдаемость | `docs/domains/agent-orchestration/ops/agent_manager_monitoring.md` |
| Карта Issue | `docs/delivery/issue-map/domains/agent-orchestration.md` |

## Срезы поставки

| Срез | Issue | Результат |
|---|---|---|
| AGO-0 | #733 | Доменная документация, границы `agent-manager`, модель данных, API-обзор, план поставки и карты связей готовы. |
| AGO-1 | #739 | gRPC и AsyncAPI контракты `agent-manager`, события `agent.*` и действия доступа готовы; сервисная реализация не входит в срез. |
| AGO-2 | #744 | Сервисный процесс, env-конфигурация, health, readiness, metrics, регистрация gRPC `AgentManagerService` и outbox-каркас готовы; бизнес-операции возвращают `Unimplemented`, outbox не имитирует успешную доставку. |
| AGO-3 | #749 | PostgreSQL-модель flow, stage, role, prompt template, версий, command result и service-local outbox готова; storage/use-case слой подключён к process readiness. |
| AGO-3b | #755 | gRPC handlers, casters и безопасное отображение ошибок для flow, role и prompt подключены к готовому storage/use-case слою; session/run не входят в срез. |
| AGO-4 | #759 | Сессии и agent `Run`: создание, чтение, статусы, снимки состояния, идемпотентность, защита активной session от дублей, stage-bound проверка роли и AsyncAPI-совместимые события готовы. |
| AGO-5 | #772 | Интеграция с `package-hub` для guidance packages готова: `agent-manager` выбирает установки, проверяет manifest/version metadata и фиксирует refs/summary в `Run` без checkout/mount. |
| AGO-6 | #782 | Контекст руководящих пакетов в workspace готов: зафиксирован MVP-путь передачи замороженных `guidance_refs` в `runtime-manager` как источников `guidance_package`, локальные пути `.kodex/guidance/<safe_local_name>`, проверка идентичности источника через `package-hub` и граница без checkout из `agent-manager`. |
| AGO-7 | #795 | Интеграция `StartAgentRun` с `project-catalog.GetWorkspacePolicy` и `runtime-manager.PrepareRuntime` готова: workspace request собирается из project/source refs, role/run context и `guidance_refs`; `Run` фиксирует только runtime refs, fingerprint/summary и безопасную классификацию ошибок. Runtime preparation управляется явным `KODEX_AGENT_MANAGER_RUNTIME_PREPARATION_ENABLED`. |
| AGO-8 | #809 | Базовая machine acceptance готова: `agent-manager` создаёт pending acceptance result по session/run/stage, записывает `passed`/`failed`/`waiting`/`skipped` через ожидаемую версию, ограничивает `target_ref` safe-ref форматом, хранит только safe refs/status/bounded details и публикует service-local outbox events без QA runner, Human gate decision, provider write pipeline и хранения raw payload. Для `human_gate` фиксируется только `waiting` с gate/risk/governance ref. |
| AGO-9a | #820 | Follow-up intent lifecycle готов в границах `agent-manager`: команда `CreateFollowUpIntent` сохраняет session/run/stage/acceptance refs, provider target refs, тип следующей provider-native задачи, safe title/summary/hints, idempotency trace и статус, публикует `agent.follow_up.requested` без provider write. |
| AGO-9b | #834 | Safe activity timeline готова: `agent-manager` хранит canonical persistent историю действий по session/run, операции `RecordAgentActivity` и `ListAgentActivities`, PostgreSQL-модель, idempotency, safe guards и gRPC handler без raw tool payload, stdout/stderr, prompt, transcript, provider payload или workspace paths. |
| AGO-9c | #842 | Интеграция follow-up intent с create-path provider-командой готова: `DispatchFollowUpIntent` переводит `planned/requested` intent через expected version, перед provider write атомарно резервирует dispatch локальным bump версии и deterministic provider command ref, вызывает только `provider-hub.CreateIssue`, сохраняет `provider_operation_ref`, safe result refs и статус `created`/`failed`, публикует `agent.follow_up.created`/`agent.follow_up.failed` без прямого GitHub/GitLab доступа из `agent-manager`. |
| AGO-9c.1 | #862 | Follow-up dispatch приведён к целевой typed-модели: `DispatchFollowUpIntent` принимает явный `FollowUpDispatchKind` и typed `oneof` для `create_issue`, `update_issue`, `create_comment` или `update_comment`, резервирует dispatch до provider write, вызывает только соответствующие typed команды `provider-hub`, сохраняет `provider_operation_ref`, safe result refs и статус `created`/`updated`/`commented`/`failed`, публикует `agent.follow_up.created`/`agent.follow_up.updated`/`agent.follow_up.commented`/`agent.follow_up.failed`. `UpdatePullRequest` и `CreateReviewSignal` вынесены в следующий явный срез. |
| AGO-9c.2 | #866 | Typed follow-up dispatch покрывает PR/MR и provider-native review signal: `DispatchFollowUpIntent` поддерживает `update_pull_request` и `create_review_signal`, вызывает только `provider-hub.UpdatePullRequest`/`CreateReviewSignal`, строго сверяет сохранённый PR/MR target ref, требует provider expected version для PR update, сохраняет safe operation/result refs и публикует `agent.follow_up.updated` или `agent.follow_up.review_signaled`. Review signal не является governance decision. |
| AGO-9d | #891 | Human gate wait/result lifecycle готов: `agent-manager` создаёт owner decision wait по session/run/stage/acceptance/provider refs, записывает normalized outcome `approve`/`reject`/`request_changes`/`answer` через expected version, хранит только interaction/governance refs, safe summary/status/idempotency и публикует `agent.human_gate.requested`/`agent.human_gate.resolved` без transport payload, governance body, prompt/transcript/logs/PII. |
| AGO-10 | #897 | Эксплуатационный контур `agent-manager` готов: Dockerfile, Kubernetes manifests, migration job, PostgreSQL bootstrap/env/secret wiring, `services.yaml`, проверка готовности, runbook и monitoring docs. |
| AGO-11 | #905 | Human gate resume consumer готов: `agent-manager` потребляет `interaction.request.response_recorded` из platform event log, находит wait по `owner_request_ref`, записывает normalized outcome через существующий `RecordHumanGateDecision`, сохраняет только safe interaction refs/status/fingerprint/version и не меняет `interaction-hub` producer/transport. |
| AGO-12 | #918 | Human gate request-side integration готова: при включённом `KODEX_AGENT_MANAGER_INTERACTION_HUB_REQUEST_ENABLED` `RequestHumanGate` вызывает typed `interaction-hub.RequestHumanGate`, передаёт safe owner/session/run/provider refs и bounded summary, сохраняет только `interaction_request_ref`, сохраняет replay/idempotency и не переносит delivery/owner inbox lifecycle из `interaction-hub`. |
| AGO-13 | #937 | Таксономия исходов Human gate выровнена с `interaction-hub`: request-side `RequestHumanGate` передаёт действия `approve`/`reject`/`request_changes`/`answer`, обработчик события нормализует те же значения из `interaction.request.response_recorded`, а документы разделяют отказ `reject` и доработку `request_changes` без хранения raw response payload. |
| AGO-14 | #946 | Runtime job dispatch готов: после `runtime-manager.PrepareRuntime` `agent-manager` при включённом `KODEX_AGENT_MANAGER_RUNTIME_JOB_DISPATCH_ENABLED` ставит `JOB_TYPE_AGENT_RUN` через `runtime-manager.CreateJob`, сохраняет `runtime_job_ref` и safe status/summary в `Run`, классифицирует retryable/permanent ошибки и не работает с Kubernetes напрямую. |
| AGO-15 | #954 | Поверхность чтения runtime job готова: `GetAgentRunRuntimeStatus` возвращает по `Run` сохранённый `runtime_job_ref`, актуальный статус job через `runtime-manager.GetJob`, safe error code/summary, timestamps, версии и признак ожидания Human gate без чтения Kubernetes, БД runtime, shell, сырые логи, prompt, provider payload или workspace paths. |
| AGO-16 | #958 | Связка governance policy refs готова: `AcceptanceResult`, `FollowUpIntent` и `HumanGateRequest` хранят typed `GovernanceContextRef` для risk/gate/release/policy контекста, публикуют safe `agent.*` refs и сохраняют idempotency/expected version без чтения БД governance-manager, governance decision body, release evidence, prompt/transcript/logs/PII или provider payload. |
| AGO-17 | #968 | Runtime job dispatch заполняет typed `AgentRunExecutionSpec`: `agent-manager` передаёт в `CreateJob` safe refs на run/slot/materialization/workspace/context, digest/fingerprint, runner profile/image, фиксированный runner mode, optional secret refs без значений и reporting targets только после `slot_status=ready` и `workspace_materialization_status=completed`; pending materialization переводит `Run` в waiting, terminal `failed`/`cancelled` фиксирует безопасный failed state, а replay создаёт job после готовности. |
| AGO-18 | #977 | Runner reporting lifecycle готов: `ReportAgentRunState` принимает bounded status report от `agent-runner` для `queued`/`running`/`completed`/`failed`, сверяет `run_id`, `session_id`, `runtime_slot_ref`, `runtime_job_ref` и expected version, поддерживает idempotent replay/conflict, обновляет `Run` и lifecycle events только safe refs/status/summary/digest/failure code без raw prompt/transcript/tool payload/stdout/stderr/provider payload/workspace paths/secrets. |
| AGO-19 | #984 | Операторская read surface готова: `ListAgentSessions` и `ListAgentRunSummaries` возвращают безопасные summaries для командного центра и списка исполнений по scope/session/provider/status/role/actor/time filters, показывают session/run refs, сохранённый runtime job ref, safe status/summary/error, Human gate/follow-up flags, latest activity summary, timestamps и version без чтения соседних БД, Kubernetes, provider API или live fan-out в runtime. |
| AGO-20 | #994 | Заполнение `CodexSessionExecutionSpec` на стороне `agent-manager` готово: при постановке `JOB_TYPE_AGENT_RUN` `agent-manager` дополняет `AgentRunExecutionSpec` вложенным spec только из refs/digest: instruction object ref/digest, result schema ref/digest, session/workspace snapshot refs, hook/callback refs, ограниченный timeout, фиксированный runner profile, output/result refs и allowed secret refs без значений; при недостающих refs/digest `Run` остаётся в безопасном состоянии waiting/diagnostic, а replay после готовности создаёт runtime job тем же deterministic command id. |
| AGO-21 | #999 | Run orchestration с runtime/runner выровнена: `ReportAgentRunState` принимает safe states `queued`/`running`/`started`/`completed`/`failed`/`cancelled`/`timed_out`, сверяет run/session/slot/job refs и expected version, поддерживает replay/conflict, публикует `agent.run.cancelled`, фиксирует `timed_out` как failed run с `runner_timeout` по умолчанию и отличает недоступный execution input кодом `execution_input_unavailable` без создания неполного runtime job. |
| AGO-22 | #1011 | Self-deploy orchestration plan готов: `CreateSelfDeployPlan` принимает safe provider/project signal или plan input, фиксирует pending approval state с project/repository/source refs, affected service keys, path categories, `services.yaml` ref/digest, expected runtime job types, governance refs, safe summary и fingerprint; `GetSelfDeployPlan`/`ListSelfDeployPlans` читают только safe plan surface, а runtime build/deploy jobs не создаются до owner/governance approval. |
| AGO-23 | #1015 | Self-deploy plan from signal готов: `CreateSelfDeployPlanFromSignal` принимает обязательный safe `provider_signal_ref` от provider/project contour, создаёт pending `SelfDeployPlan`, возвращает существующий plan при повторе того же signal/fingerprint и конфликтует при другом fingerprint по тому же signal ref; build/deploy runtime jobs по-прежнему не создаются до owner/governance approval. |
| AGO-24 | #1022 | Self-deploy signal wiring готов: встроенный consumer `agent-manager` читает `provider.repository.changed` только как trigger, вызывает `project-catalog.GetSelfDeploySignal`, создаёт pending `SelfDeployPlan` только при `ready` project-side input и не подставляет `path_digest` вместо `services_yaml_digest`; non-ready статусы остаются безопасной диагностикой ожидания без ложного plan. |
| AGO-25 | #1027 | Self-deploy governance gate готов: после ready `SelfDeployPlan` `agent-manager` через typed client вызывает `governance-manager.PrepareSelfDeployPlanGate`, сохраняет только safe `risk_assessment_ref`, `gate_request_ref`, `gate_decision_ref`, status/version и повторно публикует безопасный `agent.self_deploy.plan_requested`; replay переиспользует готовый gate и не создаёт build/deploy runtime jobs до `approved`. |
| AGO-26 | #1035 | Self-deploy build dispatch готов для build items, которые уже возвращает `project-catalog.GetSelfDeployBuildPlan`: `agent-manager` принимает только ready per-service items, ставит `runtime-manager.CreateJob(JOB_TYPE_BUILD)` с typed `BuildExecutionSpec`, сохраняет safe runtime build job refs/status/fingerprint и не создаёт deploy/health-check jobs. Runtime build context readiness теперь готовится отдельным `runtime-manager.PrepareBuildContext`; следующий enrichment-срез должен передать ready context refs в build plan. |
| AGO-27 | не назначено | Self-deploy gate decision consumer готов: `agent-manager` потребляет `governance.gate.resolved` только для target `self_deploy_plan`, сверяет `gate_request_ref`, идемпотентно сохраняет `gate_decision_ref`, переводит plan в `approved` для `approve`/`approve_with_conditions` и запускает существующий build dispatch; `reject` и `request_changes`/`revise` завершают plan без build. |

## Статус операций `AgentManagerService`

| Операция | Текущий статус | Плановый срез |
|---|---|---|
| `CreateFlow` / `UpdateFlow` / `CreateFlowVersion` / `ActivateFlowVersion` | storage/use-case слой и gRPC handlers готовы | AGO-3, AGO-3b |
| `GetFlow` / `ListFlows` | storage/use-case слой и gRPC handlers готовы; `GetFlow` возвращает активную версию при наличии `active_version_id` | AGO-3, AGO-3b |
| `CreateRoleProfile` / `UpdateRoleProfile` / `GetRoleProfile` / `ListRoleProfiles` | storage/use-case слой и gRPC handlers готовы | AGO-3, AGO-3b |
| `GetPromptTemplate` / `ListPromptTemplates` | storage/use-case слой и gRPC handlers готовы; `GetPromptTemplate` возвращает активную версию при наличии `active_version_id` | AGO-3, AGO-3b |
| `CreatePromptTemplateVersion` / `ActivatePromptTemplateVersion` / `GetPromptTemplateVersion` / `ListPromptTemplateVersions` | storage/use-case слой и gRPC handlers готовы | AGO-3, AGO-3b |
| `StartAgentSession` | Слой хранения, use-case и gRPC handlers готовы; создаёт авторитетную сессию, а при непустом provider target продолжает активную `open`/`waiting` session без нового события создания | AGO-4 |
| `StartAgentRun` | Слой хранения, use-case и gRPC handlers готовы; создаёт `Run`, фиксирует версии роли и prompt, проверяет stage-bound связку flow/stage/role, разрешает guidance hints через `package-hub`; при включённом `KODEX_AGENT_MANAGER_RUNTIME_PREPARATION_ENABLED` читает workspace policy у `project-catalog`, вызывает `runtime-manager.PrepareRuntime`; при включённом `KODEX_AGENT_MANAGER_RUNTIME_JOB_DISPATCH_ENABLED` ставит `JOB_TYPE_AGENT_RUN` через `runtime-manager.CreateJob` с typed `AgentRunExecutionSpec` и вложенным `CodexSessionExecutionSpec` только из refs/digest после готовности slot/materialization и обязательных execution refs/digest, а replay той же команды продолжает dispatch после готовности; при недоступном checked execution input фиксирует safe waiting/diagnostic `execution_input_unavailable`; сохраняет только runtime refs, `runtime_job_ref`, fingerprint/diagnostic summary и безопасный статус подготовки или постановки задания | AGO-4, AGO-5, AGO-6, AGO-7, AGO-14, AGO-17, AGO-20, AGO-21 |
| `RecordRunState` | Слой хранения, use-case и gRPC handlers готовы; требует ожидаемую версию, проверяет state machine, пишет результат команды и публикует lifecycle event только с обязательными полями AsyncAPI | AGO-4, AGO-6 |
| `ReportAgentRunState` | Слой хранения, use-case и gRPC handler готовы; команда принимает только typed runner states `queued`/`running`/`started`/`completed`/`failed`/`cancelled`/`timed_out`, требует expected version, сверяет run/session/slot/job refs с сохранённым `Run`, поддерживает replay/conflict, сохраняет только bounded summary, diagnostic digest и failure code без raw runner payload, переводит timeout в safe failed state и публикует cancelled event | AGO-18, AGO-21 |
| `GetAgentRunRuntimeStatus` | Слой хранения, use-case, gRPC handler и runtime-manager client готовы; читает `Run`, при наличии `runtime_job_ref` запрашивает `runtime-manager.GetJob`, возвращает safe status/error/summary/timestamps/version и не копирует логи runtime, `job_input_json`, workspace paths или состояние Kubernetes | AGO-15 |
| `RecordSessionStateSnapshot` | Слой хранения, use-case и gRPC handlers готовы; пишет метаданные снимка и обновляет указатель сессии через ожидаемую версию | AGO-4, AGO-6 |
| `RequestAcceptance` / `RecordAcceptanceResult` / `GetAcceptanceResult` / `ListAcceptanceResults` | Слой хранения, use-case и gRPC handlers готовы; request создаёт один pending check за команду, record требует expected version и принимает только bounded safe `target_ref`/`details_json`/`governance_context`; `human_gate` переводится только в `waiting` с owner/gate/risk/governance ref; outbox публикует requested/completed/failed события | AGO-8, AGO-16 |
| `CreateFollowUpIntent` | Слой хранения, use-case и gRPC handler готовы; команда валидирует session/run/stage/acceptance связи, поддерживает idempotency replay и conflict для отличающегося payload, хранит только safe provider refs/title/summary/hints/digest/status и optional governance refs, публикует `agent.follow_up.requested` без provider write | AGO-9a, AGO-16 |
| `DispatchFollowUpIntent` | Слой хранения, use-case, typed provider-hub client и gRPC handler готовы; команда требует expected version, поддерживает idempotency replay/conflict, резервирует dispatch до provider write, принимает `FollowUpDispatchKind` + typed `oneof`, вызывает `provider-hub.CreateIssue`/`UpdateIssue`/`CreateComment`/`UpdateComment`/`UpdatePullRequest`/`CreateReviewSignal`, обновляет intent до `created`/`updated`/`commented`/`review_signaled`/`failed` и хранит только safe operation/result refs | AGO-9c, AGO-9c.1, AGO-9c.2 |
| `RecordAgentActivity` / `ListAgentActivities` | Слой хранения, use-case и gRPC handlers готовы; record поддерживает idempotency replay/conflict и safe-storage guards для activity kind/status/tool metadata/timestamps/summary/digest/refs/details; list читает timeline по session/run с фильтрами и cursor pagination | AGO-9b |
| `RequestHumanGate` / `RecordHumanGateDecision` / `GetHumanGateRequest` / `ListHumanGateRequests` | Слой хранения, use-case и gRPC handlers готовы; request создаёт `waiting` owner decision state с idempotency replay/conflict и refs на interaction/governance request, при включённом request-side switch создаёт transport request через typed `interaction-hub.RequestHumanGate` с действиями `approve`/`reject`/`request_changes`/`answer`, record требует expected version и сохраняет normalized outcome + safe refs/summary без внешних payload; typed governance refs связывают wait/result с risk/gate/release policy контекстом без копирования decision body; event consumer `interaction.request.response_recorded` вызывает тот же lifecycle по safe refs/fingerprint/version; list/get читают ожидания по session/run/stage/status/outcome | AGO-9d, AGO-11, AGO-12, AGO-13, AGO-16 |
| `CreateSelfDeployPlan` / `CreateSelfDeployPlanFromSignal` / `GetSelfDeployPlan` / `ListSelfDeployPlans` | Слой хранения, use-case, gRPC handlers, outbox event и consumers для self-deploy signal/gate decision готовы; create фиксирует self-deploy plan из safe provider/project refs, affected service keys/path categories, `services.yaml` digest, expected runtime job types `build`/`deploy`/`health_check`, governance refs и fingerprint, поддерживает replay/conflict и не создаёт runtime jobs без approval. Signal-вход требует `provider_signal_ref`, возвращает существующий plan при том же fingerprint и конфликтует при изменённом fingerprint. Consumer читает `provider.repository.changed`, вызывает `project-catalog.GetSelfDeploySignal` и передаёт в command только `ready` input. После ready-плана `agent-manager` вызывает `governance-manager.PrepareSelfDeployPlanGate`, сохраняет safe gate refs/status/version и не создаёт второй gate request при replay. Consumer `governance.gate.resolved` сверяет self-deploy target и `gate_request_ref`, записывает `gate_decision_ref`, переводит plan в `approved` или terminal non-approved state и вызывает build dispatch только для approved outcome. После `approved` gate `agent-manager` сначала подготавливает runtime build context через `runtime-manager.PrepareBuildContext`; если context не `ready`, dispatch остаётся blocked. После build-plan enrichment с ready context refs `agent-manager` вызывает `project-catalog.GetSelfDeployBuildPlan`, создаёт `JOB_TYPE_BUILD` только по ready build items, сохраняет runtime build job refs/status/fingerprint и блокирует dispatch безопасной диагностикой при non-ready build plan; list требует сужающий фильтр | AGO-23, AGO-24, AGO-25, AGO-26, AGO-27 |
| `GetAgentSession` / `ListAgentRuns` | Слой хранения, use-case и gRPC handlers готовы; `GetAgentSession` возвращает последний снимок при наличии указателя | AGO-4 |
| `ListAgentSessions` / `ListAgentRunSummaries` | Слой хранения, use-case и gRPC handlers готовы; операции отдают bounded safe summaries для операторского UI, требуют сужающий фильтр, используют локальные session/run/Human gate/follow-up/activity данные и не читают runtime/provider/Kubernetes в списочном пути | AGO-19 |

## Синхронизация с параллельными доменами

| Домен | Когда синхронизироваться | Причина |
|---|---|---|
| `package-hub` | Готово для AGO-5 | Используются чтения установок, package/version metadata и manifest validation state; `agent-manager` не хранит manifest payload и не меняет установки. |
| `runtime-manager` | Готово для AGO-7/AGO-10/AGO-14/AGO-15/AGO-17/AGO-20/AGO-21/AGO-22/AGO-26 и self-deploy MVP | `agent-manager` вызывает `PrepareRuntime(agent_run_id, workspace policy, runtime profile, placement constraints)` при включённой runtime preparation, `CreateJob(job_type=JOB_TYPE_AGENT_RUN, AgentRunExecutionSpec)` при включённом runtime job dispatch и `GetJob` для безопасного чтения runtime job по `Run`; вложенный `CodexSessionExecutionSpec` передаётся только из refs/digest после готовности instruction/schema/snapshot refs, а runner status возвращается через `ReportAgentRunState` без записи runtime state в `agent-manager` из executor. Для self-deploy plan `runtime-manager.PrepareBuildContext` готовит runtime-owned build context readiness через typed refs и SecretRef; готовый context передаётся в build-plan enrichment. После ready build plan `agent-manager` вызывает `CreateJob(job_type=JOB_TYPE_BUILD)` только с typed `BuildExecutionSpec` из `project-catalog.GetSelfDeployBuildPlan`; после successful build и checked `GetSelfDeployDeployPlan` вызывает `CreateJob(job_type=JOB_TYPE_DEPLOY)` только с typed `DeployExecutionSpec`. Health-check jobs остаются отдельным переходом. Deploy-контур включает явные env switch и gRPC secret ref, а workspace, job state, build context lifecycle, Kubernetes и executor остаются у runtime. |
| `provider-hub` | Готово для AGO-9c.2/AGO-10 | `agent-manager` вызывает typed `CreateIssue`, `UpdateIssue`, `CreateComment`, `UpdateComment`, `UpdatePullRequest` и `CreateReviewSignal`, хранит только safe operation/result refs; deploy-контур включает provider-hub gRPC secret ref, но provider write pipeline, adapter state и provider-native истина остаются у `provider-hub`. |
| `risk-and-release-governance` | Готово для self-deploy gate preparation и policy refs | `agent-manager` хранит typed governance refs и normalized outcome; для self-deploy вызывает `PrepareSelfDeployPlanGate` с safe plan refs/digest/fingerprint и сохраняет только `risk_assessment_ref`, `gate_request_ref`, `gate_decision_ref`, status/version. Governance/risk/release decision body, release evidence и policy engine остаются у `governance-manager`. |
| `interaction-hub` | Готово для request-side Human gate creation и resume consumer; producer/поверхность чтения развивается в домене `interaction-hub` | `agent-manager` создаёт Human gate transport request через typed `RequestHumanGate` с действиями `approve`/`reject`/`request_changes`/`answer`, хранит `interaction_request_ref`/`interaction_response_ref` и normalized outcome, а consumer читает safe `interaction.request.response_recorded` по `owner_request_ref`; transport request/response lifecycle, callback body, delivery каналы и owner inbox остаются у `interaction-hub`. |
| `codex-hook-ingress` | После AGO-9b | Persistent timeline готова в `agent-manager`; следующий CHI-срез должен маршрутизировать sanitized `PreToolUse`/`PostToolUse` в `RecordAgentActivity`, сохраняя `codex-hook-ingress` как sanitizer/router/realtime ops feed без долгого хранения tool calls. |
| `project-catalog` | Готово для AGO-7/AGO-10/AGO-22/AGO-24/AGO-26 | `agent-manager` читает проверенную workspace policy и использует project/repository refs без владения проектной политикой. Для self-deploy signal wiring он вызывает `GetSelfDeploySignal` по provider signal ref и получает только project-owned safe input: active repository binding, checked `ServicesPolicy`, `services.yaml` ref/digest/version, affected service keys, path categories, expected runtime job types и governance refs или non-ready status. Для approved self-deploy build dispatch он использует `GetSelfDeployBuildPlan` только после build-plan enrichment с готовыми runtime context refs; `project-catalog` возвращает ready per-service `BuildExecutionSpec` из checked `ServicesPolicy`, а non-ready build plan блокирует runtime dispatch. Deploy-контур включает project-catalog gRPC secret ref для runtime preparation и self-deploy signal/build enrichment. |
| `access-manager` | Перед открытием команд через gateway/MCP | Действия доступа заведены в AGO-1; текущие gRPC use-case не обходят будущие сервисные проверки, но не реализуют полноценный контур авторизации команд. |
| `platform-mcp-server` | Перед AGO-5 и далее | MCP-0 зафиксировал границы и MVP-группы инструментов. Для реальных вызовов session, `Run`, gate и операторских списков нужен отдельный MCP/gateway срез поверх готовой gRPC-поверхности владельца; `agent-manager` остаётся владельцем состояния. |

## Критерии начала кода

- Принят пакет доменной документации `agent-orchestration`.
- Для каждого кодового PR есть отдельный GitHub Issue.
- Контрактный PR создаёт proto и AsyncAPI до реализации бизнес-операций.
- Старый код из `deprecated/**` не используется как основа реализации.
- Соседние доменные контракты не обходятся локальными заглушками без отдельного согласования.

## Критерии завершения домена

- `agent-manager` имеет свой контур данных, миграций, контрактов и событий.
- `agent-manager` имеет Dockerfile, Kubernetes manifests, migration job, env/secret inventory, путь проверки готовности, runbook и monitoring docs для первого backend deploy.
- Flow, stage, role, prompt, session, run, acceptance и follow-up имеют авторитетные команды и чтения.
- Сервис публикует `agent.*` события через outbox и `platform-event-log`.
- `package-hub`, `runtime-manager`, `provider-hub`, `governance-manager`, `interaction-hub`, `project-catalog`, `access-manager` и `platform-mcp-server` связаны через согласованные контракты.
- Документы и карты Issue обновлены, хвосты перенесены в следующие срезы явно.

## Апрув

- request_id: `owner-2026-05-12-agent-manager-kickoff`
- Решение: approved
- Комментарий: план поставки `agent-manager` согласован как стартовое целевое состояние.
