---
doc_id: MAP-CK8S-DOMAIN-PROJECTS-AND-REPOSITORIES
type: issue-map
title: kodex — карта Issue домена проектов и репозиториев
status: active
owner_role: KM
created_at: 2026-04-25
updated_at: 2026-06-10
---

# Карта Issue — проекты и репозитории

## TL;DR

Долгоживущая карта домена `projects-and-repositories`.

## Матрица

| Issue/PR | Документы | Волна | Статус | Примечание |
|---|---|---|---|---|
| #628 | `docs/domains/projects-and-repositories/**`, `docs/delivery/waves/wave-008-projects-and-repositories.md`, `docs/delivery/issue-map/waves/wave-008-projects-and-repositories.md` | wave 8 | закрыта как выполненная | Стартовый срез домена: требования, дизайн, модель данных, API-контракт, план поставки и очередь малых PR-срезов. |
| #629 | `docs/domains/projects-and-repositories/architecture/api_contract.md`, `proto/kodex/projects/v1/project_catalog.proto`, `specs/asyncapi/project-catalog.v1.yaml`, `services/internal/project-catalog/**` | wave 8 | закрыта как выполненная | Контракты, сервисный каркас и доменные интерфейсы `project-catalog`. |
| #630 | `docs/domains/projects-and-repositories/architecture/data_model.md`, `services/internal/project-catalog/**` | wave 8 | закрыта как выполненная | PostgreSQL-модель, миграции, слой репозитория, outbox и тесты. |
| #631 | `docs/domains/projects-and-repositories/architecture/api_contract.md`, `services/internal/project-catalog/**`, `libs/go/grpcserver/**`, `libs/go/eventlog/**` | wave 8 | закрыта как выполненная | gRPC-операции, граница проверки доступа через `access-manager`, outbox-публикация в `platform-event-log`, доменные и транспортные тесты. |
| #632 | `docs/domains/projects-and-repositories/product/requirements.md`, `docs/domains/projects-and-repositories/architecture/design.md`, `docs/domains/projects-and-repositories/architecture/data_model.md`, `services/internal/project-catalog/**` | wave 8 | закрыта как выполненная | Политика `services.yaml`, источники проектной документации, операторские переопределения и политика рабочего контура. |
| #633 | `docs/domains/projects-and-repositories/delivery/wave8_project_catalog.md`, `deploy/base/project-catalog/**`, `scripts/**`, `bootstrap/local/steps/70_finalize_and_report.sh` | wave 8 | закрыта как выполненная | Правила веток, релизная политика, политика размещения, манифесты, проверочный путь и закрытие Wave 8. |
| #639 | `docs/design-guidelines/go/**`, `services/internal/project-catalog/**`, `services/internal/access-manager/**`, `libs/go/**` | после wave 8.2 | закрыта как выполненная | Системный перевод PostgreSQL-сканеров на штатные помощники `pgx`, где не нужна ручная доменная конвертация. |
| #281, #282 | `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/**`, `docs/delivery/issue-map/domains/provider-native-work-items.md` | wave 8 + wave 10 | модель выбрана, ждёт реализации | Проектный каталог и основание проектной политики готовы. Владелец выбрал гибридный вариант C: `services.yaml` остаётся Git-декларацией, workspace собирается платформой, шаблоны репозиториев приходят через `package-hub`, Git submodule используется только явно. |
| #794 | `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/projects-and-repositories/architecture/design.md`, `proto/kodex/projects/v1/project_catalog.proto`, `services/internal/project-catalog/**`, `deploy/base/project-catalog/**` | ONB-1 | готово | `project-catalog` добавил project-side команду bootstrap PR для существующего repository binding: проверяет provider target, `base_branch`, prepared files, watermark и проверенную политику `services.yaml`, а provider-native запись делегирует `provider-hub`. |
| #810 | `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/projects-and-repositories/architecture/design.md`, `docs/domains/provider-native-work-items/architecture/api_contract.md`, `proto/kodex/projects/v1/project_catalog.proto`, `services/internal/project-catalog/**` | ONB-2 | готово | `project-catalog` добавил project-side команду создания provider repository/base ref через `provider-hub CreateRepository`, резервирует pending binding, сохраняет безопасные provider refs и оставляет import `services.yaml` после merge отдельным срезом. |
| #818 | `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/**`, `docs/domains/provider-native-work-items/architecture/api_contract.md`, `proto/kodex/projects/v1/project_catalog.proto`, `specs/asyncapi/project-catalog.v1.yaml`, `services/internal/project-catalog/**` | ONB-3 | готово | `project-catalog` добавил project-side команду `ImportBootstrapServicesPolicy`: принимает проверенный merge/artifact-сигнал, импортирует checked `services.yaml`, переводит pending binding в `active` и публикует безопасное project-событие без raw provider payload. |
| #864 | `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/**`, `docs/domains/provider-native-work-items/**`, `proto/kodex/projects/v1/project_catalog.proto`, `services/internal/project-catalog/**` | ONB-4 | готово | `project-catalog` добавил явную project-side команду `ReconcileBootstrapMergeSignal`: принимает safe provider bootstrap merge signal и checked artifact metadata, проверяет signal/artifact/binding и вызывает `ImportBootstrapServicesPolicy` без прямого GitHub/GitLab доступа. |
| #881 | `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/**`, `services/internal/project-catalog/**` | ONB-5 | готово | `project-catalog` добавил журнал `OnboardingSignalReconciliation` для safe bootstrap merge signal: fingerprint, refs, artifact metadata, imported/failed status и safe error summary без raw provider payload. |
| #893 | `docs/platform/architecture/data_model.md`, `libs/go/eventconsumer/**`, `libs/go/eventlog/**`, `services/internal/project-catalog/**`, `docs/domains/projects-and-repositories/**` | event-log consumer | готово | Добавлен общий consumer framework поверх `platform-event-log`: claim/read через `eventlog.Store`, `consumer_name`, lease owner, checkpoint, registry по event type/version, retry/backoff, bounded poison и safe hooks/logs. Consumer `project-catalog` читает `provider.repository.bootstrap_merged`, восстанавливает safe signal input и вызывает доменный use-case: при наличии checked artifact metadata, normalized `services.yaml` payload и watermark payload он запускает `ReconcileBootstrapMergeSignal`, а при неполном provider-only сигнале фиксирует `OnboardingSignalReconciliation(needs_review, missing_checked_artifact)` без импорта по неполным данным. |
| #917 | `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/**`, `services/internal/project-catalog/**`, `deploy/base/project-catalog/**` | adoption import | готово | `project-catalog` добавил project-side adoption import path: consumer `provider.repository.adoption_merged` принимает safe merge signal с checked artifact/payload, вызывает `ReconcileAdoptionMergeSignal`, ведёт safe `OnboardingSignalReconciliation(adoption_merge)` и импортирует checked `services.yaml` projection без GitHub/GitLab-клиента. |
| #281, #282 | `proto/kodex/projects/v1/project_catalog.proto`, `proto/gen/go/kodex/projects/v1/**`, `services/internal/project-catalog/internal/transport/grpc/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md` | onboarding runner prerequisite | готово | Публичный gRPC RPC `ReconcileAdoptionMergeSignal` подключён к уже существующей доменной adoption reconcile логике: внешний Go integration runner может вызывать typed product API с safe adoption merge signal и checked artifact metadata/payload без доступа к БД, consumer internals, GitHub/GitLab или raw YAML. Сам runner остаётся следующим срезом, #281/#282 не закрыты. |
| #281, #282 | `cmd/onboarding-runner/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/provider-native-work-items/delivery/provider_hub_delivery.md` | onboarding product API runner | готово | Добавлен минимальный Go runner: dry-run проверяет публичные gRPC API `project-catalog`/`provider-hub`, repository binding, safe merge signals, adoption scan read surface и checked input; apply включается только явно, требует safe target policy и вызывает `ReconcileBootstrapMergeSignal`/`ReconcileAdoptionMergeSignal` с typed checked input без БД, shell smoke, прямого GitHub/GitLab и вывода сырого YAML/webhook/provider payload. #281/#282 остаются открытыми до полного пользовательского сценария. |
| #281, #282 | `cmd/onboarding-runner/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/provider-native-work-items/delivery/provider_hub_delivery.md` | onboarding checked artifact producer | готово | Runner готовит checked artifact input из уже нормализованного JSON payload: проверяет JSON-объект, вычисляет `content_hash` как обычный SHA-256 от байтов payload, передаёт совместимый `artifact_digest = content_hash`, формирует artifact ref/version, добавляет watermark payload из сценария или безопасного JSON-файла и вызывает project-side reconcile только через публичные gRPC product API. Runner не валидирует сырой YAML, не создаёт GitHub/GitLab repo/PR и не печатает checked payload. #281/#282 остаются открытыми до полного пользовательского сценария создания repo/PR и операторского запуска. |
| #281, #282 | `cmd/onboarding-runner/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/provider-native-work-items/delivery/provider_hub_delivery.md` | onboarding bootstrap setup runner | готово | Runner поддерживает `bootstrap_setup`: dry-run планирует, а apply по safe target policy вызывает публичные product API `CreateProviderRepository` и `CreateRepositoryBootstrapPullRequest`, получает `repository_id` из `project-catalog`, передаёт подготовленные файлы только в typed bootstrap PR command и не выводит подготовленные файлы, checked payload, raw webhook/provider response или секреты. #281/#282 остаются открытыми до операторского интерфейса, слияния владельцем, adoption deep scan/report и полного пользовательского запуска. |
| #281, #282 | `cmd/onboarding-runner/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/provider-native-work-items/delivery/provider_hub_delivery.md` | self-repo adoption signals | готово | Runner поддерживает self-adoption для существующего `codex-k8s/kodex`: dry-run планирует `AttachRepository` и safe `repository_change` summary, apply требует точный allowlist owner/repository и привязывает repository binding через публичный `project-catalog` API без прямого GitHub/GitLab, shell smoke, auto deploy и вывода raw YAML/webhook/provider payload. Safe summary фиксирует изменение root `services.yaml`, deploy-relevant path categories, commit/ref и digest как вход для будущего ручного или управляемого update plan. #281/#282 остаются открытыми до публичного webhook ingress, операторского запуска и полного пользовательского сценария. |
| #281, #282 | `cmd/onboarding-runner/**`, `proto/kodex/providers/**`, `services/internal/provider-hub/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/provider-native-work-items/**` | self-repo live signal | готово | Self-adoption path для `codex-k8s/kodex` теперь ждёт live `RepositoryChangeSignal` от `provider-hub`: GitHub `push` по `main` даёт safe flags `services_policy_changed`/`deploy_relevant_changed`, category counters, commit sha и fingerprint, а `pull_request merged` фиксирует merge fact без path summary, если provider webhook не несёт путей. `project-catalog` остаётся владельцем repository binding и checked `services.yaml` import, не читает GitHub/GitLab напрямую и не запускает build/deploy; сигнал служит входом для будущего ручного или управляемого self-deploy plan. #281/#282 остаются открытыми до операторской поверхности, живой доставки на кластере и полного пользовательского запуска. |
| #281, #282 | `proto/kodex/projects/v1/project_catalog.proto`, `proto/gen/go/kodex/projects/v1/**`, `services/internal/project-catalog/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/projects-and-repositories/architecture/data_model.md` | project-side self-deploy signal | готово | `project-catalog GetSelfDeploySignal` обогащает safe provider `RepositoryChangeSignal` проверенной project-owned проекцией: repository binding, `services_yaml_ref`, `services_yaml_digest`, policy version/fingerprint, affected service keys, path categories, expected runtime job type hints и gate-required marker. Если `services.yaml` изменён, но checked projection не обновлена до commit сигнала, возвращается `needs_services_policy_reconcile`; `path_digest` не используется как `services_yaml_digest`, raw webhook/provider payload/full YAML не отдаются. #281/#282 остаются открытыми до создания pending `SelfDeployPlan`, owner/governance gate и управляемого запуска. |
| #281, #282 | `cmd/onboarding-runner/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/agent-orchestration/ops/agent_manager_runbook.md` | onboarding runner project bootstrap | готово | Runner умеет без переданного `project_id` найти active project `kodex` по `organization_id` + slug/name через `ListProjects`, создать его через `CreateProject` в apply-режиме, найти existing active self-repo binding через `ListRepositories` или выполнить `AttachRepository` для `codex-k8s/kodex`, а затем напечатать safe `project_id`/`repository_id` для настройки `KODEX_AGENT_MANAGER_SELF_DEPLOY_SIGNAL_PROJECT_ID`. Прямые SQL-вставки, ручные UUID, shell smoke, GitHub/GitLab calls и вывод секретов не используются. #281/#282 остаются открытыми до полного пользовательского onboarding/adoption сценария и управляемого deploy запуска. |
| #281, #282 | `proto/kodex/projects/v1/project_catalog.proto`, `proto/gen/go/kodex/projects/v1/**`, `services/internal/project-catalog/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/agent-orchestration/**`, `docs/domains/runtime-and-fleet/architecture/api_contract.md` | self-deploy build plan read surface | готово | `project-catalog GetSelfDeployBuildPlan` разделяет статический рецепт сборки из checked `ServicesPolicy` и materialized build context, который готовит `runtime-manager`. Первый read без context возвращает items с рецептом по сервисам, recipe/item fingerprints и статус `build_context_required`; повторный read с `materialized_build_contexts` возвращает `BuildExecutionSpec`-совместимые refs для `JOB_TYPE_BUILD`: source ref/commit, service key/ref, image ref/tag, runtime build context ref/digest, Dockerfile ref/target, builder image ref, allowed secret refs без значений, output refs и стабильный plan fingerprint. Источник рецепта — только checked `ServicesPolicy`: явный `service.build` поддержан, а текущая корневая форма `services.yaml` выводит image/Dockerfile/builder policy из `spec.images`/`spec.versions` без дублирования. Stale policy, missing service, missing build spec, missing context и context mismatch возвращаются safe статусами неготовности `policy_stale`, `service_not_found`, `build_plan_unavailable`, `build_context_required`, `build_context_invalid`. `agent-manager` не парсит `services.yaml`, `runtime-manager` не читает project policy. #281/#282 остаются открытыми до runtime-owned context preparation, approval-driven job dispatch и deploy execution. |
| #281, #282 | `cmd/onboarding-runner/**`, `services/internal/governance-manager/**`, `services/staff/staff-gateway/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/risk-and-release-governance/architecture/api_contract.md`, `docs/domains/console-and-operations-ux/README.md`, `docs/domains/access-and-accounts/architecture/api_contract.md` | self-deploy service access rules | готово | Self-repo apply path runner после создания или нахождения project/repository binding создаёт или переиспользует через публичный `access-manager PutAccessRule` узкие project-scoped правила. `service/agent-manager` получает `project.policy.read`, `governance.risk.evaluate/read` и `governance.gate.request/read` для подготовки self-deploy gate; `service/staff-gateway` получает `project.policy.read`, `governance.risk.read` и `governance.gate.read` для self-deploy summary. `governance.gate.decide`, owner decision, release write/admin и policy manage права сервисам не выдаются. После записи runner проверяет итоговый `CheckAccess`, поэтому existing deny или конфликт политики дают безопасную диагностику вместо ложной готовности. SQL, широкие admin-права, секреты, raw provider payload и deploy-мутации не используются; #281/#282 остаются открытыми до полного управляемого self-deploy запуска. |
| #281, #282 | `services/internal/project-catalog/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/projects-and-repositories/architecture/data_model.md` | self-deploy signal binding resolution | готово | `project-catalog GetSelfDeploySignal` разрешает provider-owned `RepositoryChangeSignal`, который не содержит project/repository refs, через явный project/repository context и active repository binding. Сопоставление идёт по канонической provider identity, provider repository id, branch и commit через `provider-hub ListRepositoryChangeSignals`; signal другого repository не связывается, неполная provider identity и отсутствие checked policy возвращают точные безопасные причины вместо общего `NotFound`. `provider-hub` остаётся владельцем provider facts, а `project-catalog` не читает GitHub/GitLab напрямую и не запускает build/deploy. #281/#282 остаются открытыми до полного управляемого self-deploy запуска. |
| #281, #282 | `cmd/onboarding-runner/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/projects-and-repositories/architecture/data_model.md` | self-repo services policy import | готово | Runner поддерживает штатный live-safe импорт checked `services.yaml` для `codex-k8s/kodex`: блок `services_policy_import` читает локальный YAML/JSON только в операционном Go-контуре, нормализует его в JSON input, вычисляет `content_hash`, выдаёт service actor узкое `project.policy.import` на `services_policy` через `access-manager` и вызывает публичный `project-catalog ImportServicesPolicy` без SQL, GitHub/GitLab, shell smoke, raw YAML в выводе или секретов. Это снимает live-блокер `services_policy_not_found`; #281/#282 остаются открытыми до полного управляемого self-deploy запуска. |
| #281, #282 | `cmd/onboarding-runner/**`, `docs/platform/architecture/repository_onboarding.md`, `docs/domains/projects-and-repositories/architecture/api_contract.md`, `docs/domains/access-and-accounts/architecture/api_contract.md` | self-repo repository read access | готово | Runner в self-repo apply path создаёт или переиспользует через публичный `access-manager PutAccessRule` узкое правило `service/onboarding-runner`: `repository.read` на конкретный repository binding с `resource_id=<repository_id>` и `scope=project/<project_id>`, затем проверяет итоговый `CheckAccess` до `project-catalog GetRepository`/`ImportServicesPolicy`. Ручное live-добавление этого права больше не является частью штатного запуска; широкие admin-права, provider write, policy import сверх отдельного правила и доступ к секретам не выдаются. #281/#282 остаются открытыми до полного управляемого self-deploy запуска. |
| #322 | `docs/domains/projects-and-repositories/README.md`, `docs/delivery/issue-map/domains/risk-and-release-governance.md` | wave 15 | active | Уточнена граница: `project-catalog` остаётся владельцем project/repository/release policy, а `governance-manager` использует эту policy для risk/gate/release decisions без дублирования проектной истины. |
