# AppRafter — План разработки

> **Источник истины:** [`spec.md`](./spec.md) (revision 4).
> **Назначение:** разбить spec на упорядоченные actionable-фазы, каждая из которых пригодна как самостоятельный цикл «план → реализация».
> **Статус:** живой документ. Обновляется по мере закрытия фаз и появления новых решений.

---

## 0. Как пользоваться этим документом

1. **Цикл работы:** выбираем одну подфазу (например, `1.4`), раскрываем её через skill `superpowers:writing-plans` в детальный TDD-план в `docs/superpowers/plans/YYYY-MM-DD-<feature>.md`, исполняем через `subagent-driven-development` или `executing-plans`, отмечаем чекбоксы здесь.
2. **Гранулярность:** каждая подфаза — это **один цикл разработки** (~1–5 рабочих дней). Если оказывается больше — делим на лету.
3. **Зависимости:** идти по фазам сверху вниз. Внутри фазы соблюдать указанные `Зависит от:`. Параллелить можно ветки без общих зависимостей.
4. **Размер (T-shirt):** `XS` ≈ полдня, `S` ≈ 1–2 дня, `M` ≈ 3–5 дней, `L` ≈ ≥1 неделя (кандидат на дробление).
5. **Acceptance:** перед закрытием подфазы должны выполниться все её критерии приёмки. Без этого галка не ставится.
6. **Критерий «готовности к запуску цикла»:** spec-ссылка ясна, зависимости закрыты, acceptance проверяемы. Если что-то размыто — сначала ADR в `docs/adr/`.

### Условные обозначения

- `[ ]` — не начато
- `[~]` — в работе (с пометкой ветки/PR в скобках)
- `[x]` — закрыто (с пометкой даты и коммита)
- `🔒` — заблокировано (с указанием блокера)
- `⚡` — критический путь
- `🌱` — можно запараллелить
- `> 🏁 SR:` — speedrun bucket: **A** keep (launch) · **B** pull-up (launch) · **C** defer post-launch (+ trigger) · **D** drop (+ reactivate). "order N" = OSS-core build sequence (speedrun §4.2). See `speedrun-plan.md`.

---

## 1. Карта фаз

| Фаза | Название | Соответствие spec | Размер | Зависит от |
|------|----------|-------------------|--------|------------|
| 0 | Основания и подготовка | M0 finalization | M | — |
| 1 | MVP single-node | M1 | L | 0 |
| 1.9 | Dev Mode MVP (1B) | dev-mode-task.md §20 Phase 1B | M+ | 1.5 |
| 2 | Платформенные сервисы | M2 | L | 1 |
| 2.9 | Dev Mode + Services (2B) | dev-mode-task.md §20 Phase 2B | M | 1.9, 2 |
| 3 | Multi-node + observability | M3 | L | 2 |
| 3.9 | Dev Mode Full (3B) | dev-mode-task.md §20 Phase 3B | M | 2.9, 3 |
| 4 | External Surface + Access | M4 | L | 3 |
| 5 | Tier 3 — bare metal | M5 | L | 4 |
| 6 | Tier 4 — confidential | M6 | M | 5 |
| 7 | Plugin ecosystem | (cross-cut) | L | 2 (gRPC), 3 (infra) |
| 8 | 1.0 release | M7 | M | 4 (минимально), идеально 6 |
| ∞ | Сквозные направления | — | — | running |

Phase 7 запускается параллельно с 3+ как только готов CRD ServiceProvider (закроется в фазе 2).

---

## Фаза 0 — Основания и подготовка ⚡

**Цель фазы:** превратить repo из черновика spec в готовую к контрибьюторам монорепу с зафиксированными решениями M0.

**Spec:** §6 (M0), §7 (Resolved → license, codename), Appendix A.

### 0.1 Структура монорепы 🌱

**Статус:** ✅ закрыто 2026-05-06.

**Цель:** создать каркас директорий по Appendix A с README-заглушками.

**Поставка:**
- [x] Создать каталоги: `cli/`, `operator/`, `schemas/`, `providers/{pg-integrated,pg-aws,jetstream-integrated,clickhouse-integrated,redis-integrated,s3-integrated}/`, `backstage-plugins/`, `manifests/`, `docs/`, `examples/`, `docs/adr/`, `docs/superpowers/plans/`.
- [x] В каждом каталоге — README.md с одним абзацем «что здесь».
- [x] Корневой `README.md` с vision, схемой, ссылкой на `spec.md` и `plan.md`.
- [x] `.editorconfig`, `.gitattributes`, базовый `.gitignore` (Rust, Node, Bun, OS-артефакты).

**Acceptance:** `tree -L 2` соответствует Appendix A; README рендерится в GitHub-flavoured markdown.

**Размер:** XS

---

### 0.2 Лицензия FSL-1.1-MIT 🌱

**Статус:** ✅ закрыто 2026-05-06.

**Цель:** оформить лицензионное решение из §7.

**Поставка:**
- [x] `LICENSE` в корне с текстом FSL-1.1-MIT (канонический шаблон с fsl.software, copyright «AppRafter Authors», year 2026).
- [x] `LICENSE-MIT` для будущей конверсии (для прозрачности).
- [x] `NOTICE` с описанием модели (2-летнее окно → MIT). Только английский — публичный документ (см. правило о языке проекта).
- [x] SPDX-заголовок-шаблон в `docs/contributing/license-headers.md`.
- [x] Подпапки плагинов (`providers/`, `backstage-plugins/`) — отдельный `LICENSE` MIT (см. §7).

**Acceptance:** GitHub распознаёт лицензию (текст канонический FSL-1.1-MIT с fsl.software — Linguist распознаёт по характерному тексту); SPDX-header задокументирован для всех будущих исходников.

**Размер:** XS

---

### 0.3 ADR-процесс и шаблон

**Статус:** ✅ закрыто 2026-05-06.

**Цель:** зафиксировать формат принятия архитектурных решений.

**Поставка:**
- [x] `docs/adr/0000-template.md` (по шаблону Майкла Найгарда + risk/owner/re-evaluation).
- [x] `docs/adr/0001-license-fsl-1-1-mit.md` — FSL-1.1-MIT для core, MIT для плагинов (§7 + §8).
- [x] `docs/adr/0002-codename-apprafter.md` — выбор кодового имени (§7 open-question 9).
- [x] `docs/adr/0003-rust-operator-over-crossplane.md` (§8).
- [x] `docs/adr/0004-cue-over-pkl.md` (§7 + точка пересмотра M5).
- [x] `docs/adr/0005-kine-nats-over-etcd.md` (§4.2 + §8).
- [x] `docs/adr/0006-openbao-over-vault.md` (§4.4 + §8).
- [x] `docs/adr/0007-tier-1-sealedsecrets-tier-2-openbao.md` — переназначено с дублирующего FSL-обоснования на принцип 1.8 (§1.8 + §4.4 + §8).
- [x] `docs/adr/0008-http-first-notifications-api.md` (§4.6 + §8).
- [x] `docs/adr/0009-platform-only-templates.md` (§4.6 + §8).
- [x] `docs/adr/0010-dockerfile-first-build.md` (§4.9 + §8).
- [x] `docs/adr/0011-hybrid-rust-sdk-tofu-shim.md` (§3.7 + §4.12 + §8).
- [x] `docs/adr/0012-migrationplan-as-first-class.md` (§3.8 + §8).
- [x] `docs/adr/README.md` обновлён индексом всех ADR.

**Acceptance:** все «Resolved»-решения §7 и тех-обоснования §8 закодифицированы как ADR; индекс соответствует фактическому содержимому каталога.

**Размер:** S

---

### 0.4 CUE-модуль и валидация

**Статус:** ✅ закрыто 2026-05-06.

**Цель:** инициализировать единый CUE-модуль для всех схем платформы.

**Решения по ходу:**
- `cue.mod/` положен **в корень репо**, не в `schemas/` — стандартная CUE-практика для monorepo (один модуль, schemas + examples в нём).
- Имя модуля — `apprafter.io` (вместо `github.com/apprafter/schemas`); короче, согласовано с `apiVersion: apprafter.io/v1alpha1`.
- Каркас 9 CRD — skeleton с минимальным набором полей. Полные production-grade схемы (`Application` с env-overrides, `ServiceProvider` с tier-defaults, и т.д.) докручиваются в фазах 1.7 / 2.1 / 2.2 / 4.1 / 4.5 / 4.16 / 5.x.
- `schemas/k8s/` пока пустой каталог с README — импорт upstream Kubernetes типов через `cue import` подключается в фазе 1.7, когда renderer операторa получит конкретные `Deployment`/`Service`/Gateway типы.

**Поставка:**
- [x] `cue.mod/module.cue` (`module: "apprafter.io"`, language v0.10.0).
- [x] `schemas/k8s/` — placeholder с README; импорт отложен до фазы 1.7.
- [x] `schemas/v1alpha1/` — skeleton всех 9 CRD: `Application`, `ServiceProvider`, `ResourceClaim`, `AccessGrant`, `MigrationPlan`, `ExternalSurface`, `Infrastructure`, `ServiceProviderPlugin`, `InfrastructureProviderPlugin`, плюс общий `types.cue`.
- [x] `scripts/lint-cue.sh` — `cue fmt --check` + `cue vet` для schemas и examples; fallback на `nix run nixpkgs#cue` если нет локального бинарника.
- [x] `examples/applications/parser.cue` — валидная фикстура (упрощённая версия §3.1).

**Acceptance:**
- ✅ `scripts/lint-cue.sh` зелёный (CUE 0.16.0 через `nix run`).
- ✅ Невалидный пример (`replicas: "three"`, `port: "not-a-port"`, `public: "yes"`) валится с понятными сообщениями `conflicting values <wrong> and <expected> (mismatched types ...)` со ссылками на line:column в schema и в example.

**Размер:** M

---

### 0.5 Bootstrap CI 🌱

**Статус:** ✅ закрыто 2026-05-06.

**Цель:** GitHub Actions / CI-пайплайн с минимальным набором проверок.

**Решения по ходу:**
- Lefthook config назван `lefthook.yml` (без leading dot — стандартный путь, который lefthook ищет по умолчанию).
- Rust- и Bun-job'ы условные: пока в репе нет ни `Cargo.toml`, ни `package.json`, оба пропускают шаги с `::notice`. Реальная проверка включится в фазе 1.1 (cli) и 1.6 (Backstage).
- SPDX-чек реализован через `scripts/check-spdx-headers.sh` — `git ls-files` против явного списка `PATTERNS`. Markdown-доки и сгенерированные файлы исключены.
- Conventional-commits enforce'ится в двух местах: PR-title через GitHub Action `amannn/action-semantic-pull-request@v5`, локальный commit-msg — через `scripts/check-commit-msg.sh` (привязан в `lefthook.yml`).

**Поставка:**
- [x] `.github/workflows/lint.yml` — три job'а: CUE (`./scripts/lint-cue.sh`), Rust (`cargo fmt --check` + `cargo clippy -D warnings`, conditional), Bun (`bun lint`, conditional).
- [x] `.github/workflows/test.yml` — Rust (`cargo test`) + Bun (`bun test`), оба conditional.
- [x] `.github/workflows/license-check.yml` — `./scripts/check-spdx-headers.sh`.
- [x] `.github/workflows/conventional-commits.yml` — PR-title проверка.
- [x] `.github/CODEOWNERS` (с placeholder-handle `@apprafter-authors`).
- [x] `.github/PULL_REQUEST_TEMPLATE.md`.
- [x] `.github/ISSUE_TEMPLATE/{bug,feature,adr-proposal}.yml`.
- [x] `lefthook.yml` — pre-commit (`lint-cue.sh`, `check-spdx-headers.sh`) и commit-msg (`check-commit-msg.sh`).
- [x] `scripts/check-spdx-headers.sh` — проходит на всех 25 текущих source-файлах.
- [x] `scripts/check-commit-msg.sh` — Conventional Commits validator (тот же набор типов, что и в CI).

**Acceptance:**
- ✅ `scripts/check-spdx-headers.sh` зелёный для всех 25 tracked source-файлов; добавление файла без SPDX → fail с `::error file=...::missing SPDX-License-Identifier`.
- ✅ `scripts/check-commit-msg.sh` принимает `feat(repo): ...`, отвергает «random non-conventional message» с понятным сообщением.
- ✅ `scripts/lint-cue.sh` (вызывается lint workflow) продолжает быть зелёным.

**Размер:** S

---

### 0.6 DevContainer / dev-окружение 🌱

**Статус:** ✅ закрыто 2026-05-06.

**Цель:** контрибьютор клонирует repo и в один шаг получает всё нужное.

**Решения по ходу:**
- Три параллельных install-пути: Nix flake (рекомендуемый), VS Code Dev Container (postCreate скачивает CUE/k3d/just/lefthook/cosign), и manual через `mise.toml` для language runtimes + ручная установка остальных. Все три ведут к одному `just bootstrap && just e2e-up`.
- `Justfile` вместо Makefile — современный синтаксис, рекурсивные shebang-блоки для условных шагов.
- `flake.lock` закоммичен — pinning nixpkgs revision для воспроизводимости.

**Поставка:**
- [x] `.devcontainer/devcontainer.json` (Rust + Node + Bun + Go + kubectl + helm + docker-in-docker через features) и `.devcontainer/post-create.sh` (CUE, k3d, just, lefthook, cosign).
- [x] `flake.nix` — полный devShell: cue, cargo+rustc+rustfmt+clippy+rust-analyzer, bun, kubectl, k9s, helm, k3d, argocd, cilium-cli, talosctl, cosign, syft, trivy, grype, just, lefthook, age, sops, jq, git. `nix flake check` — зелёный.
- [x] `flake.lock` — пин nixpkgs (rev 549bd84d…) и flake-utils.
- [x] `mise.toml` — rust/bun/node/just/go (language runtimes; для остальных тулз ссылка на Nix flake / dev container).
- [x] `Justfile` — 8 таргетов: `default`, `bootstrap`, `lint`, `fmt`, `test`, `e2e-up`, `e2e-down`, `stats`. `just --list` рендерит дерево.
- [x] `docs/contributing/setup.md` — три install-пути, bootstrap, e2e-up/-down, common issues.
- [x] `docs/contributing/README.md` — индекс contributor-документов.
- [x] Корневой `README.md` дополнен секцией Quick Start.

**Acceptance:**
- ✅ `nix flake check --no-build` — зелёный (devShell + formatter эвалюируются).
- ✅ `nix run nixpkgs#just -- --justfile Justfile --list` — выводит все 8 рецептов.
- ✅ Контрибьютор: `git clone` → `nix develop` (или Dev Container reopen) → `just bootstrap && just e2e-up` без чтения дополнительных доков (Quick Start в корневом README покрывает базовый flow).

**Размер:** S

---

### 0.7 Базовый docs-skeleton

**Статус:** ✅ закрыто 2026-05-06.

**Цель:** заготовка под TechDocs (M7), сейчас — навигационный каркас.

**Решения по ходу:**
- `docs/README.md` (Phase 0.1) удалён — конфликтовал с `docs/index.md` и блокировал mkdocs strict mode. Содержимое перенесено в `docs/index.md` (mkdocs landing page).
- mkdocs `exclude_docs` исключает `superpowers/` (локальный gitignored каталог, который физически виден mkdocs на диске).
- `validation.nav.omitted_files: info` — ADR-страницы доступны по URL, но не дублируются в боковом nav (одной ссылкой «ADRs» → `adr/README.md` достаточно).
- mkdocs-material в `flake.nix` (вместе с базовым mkdocs) — `nix develop` сразу даёт `mkdocs serve/build`.
- В `Justfile` добавлены `docs-serve` (live preview) и `docs-build` (strict).

**Поставка:**
- [x] `docs/index.md` — landing page с tier-таблицей и ссылками на разделы.
- [x] `docs/architecture/index.md` — stub, ссылки на §2/§4 spec.md.
- [x] `docs/concepts/index.md` — stub, таблица §3-объектов и порядок чтения.
- [x] `docs/operator-guide/index.md` — stub.
- [x] `docs/dev-guide/index.md` — stub.
- [x] `docs/reference/index.md` — stub.
- [x] `mkdocs.yml` с Material theme, plugins (search), pymdownx-расширениями и валидной nav.
- [x] `CONTRIBUTING.md` (root) — entry point для новых контрибьюторов.
- [x] `CODE_OF_CONDUCT.md` — Contributor Covenant 2.1.
- [x] `SECURITY.md` — disclosure policy.
- [x] `GOVERNANCE.md` — роли и decision-making (lazy consensus + ADR-process).
- [x] `Justfile` — таргеты `docs-serve`, `docs-build`.
- [x] `flake.nix` дополнен `python3Packages.mkdocs-material`.
- [x] `.gitignore` дополнен `site/`.

**Acceptance:**
- ✅ `mkdocs build --strict` (через `nix-shell -p (python3.withPackages [mkdocs mkdocs-material])`) — зелёный, 0 warnings, build за 0.39 s.
- ✅ Навигация согласована со spec: Architecture/Concepts/Operator/Dev/Reference + Contributing + ADRs соответствуют §2/§3/§4/§7/§8.

**Размер:** S

---

### 0.8 Закрытие чек-листа M0 spec

**Статус:** ✅ закрыто 2026-05-06.

**Цель:** обновить `spec.md` §6 (M0): зачеркнуть «Repository structure defined» и «License chosen».

**Решения по ходу:**
- Версия не `v0.0.0-foundations` (как было в первоначальной редакции плана), а `v0.0.8` — в соответствии с патч-нумерацией, которой мы ведём всю Phase 0 (по решению пользователя «начнём с 0.0.1 и пойдём по патч-версиям»).
- License-комментарий в spec.md переписан с «candidates: MPL-2.0, Apache-2.0» на «FSL-1.1-MIT for core, MIT for plugins; see ADR 0001» — фактическое решение.

**Поставка:**
- [x] `spec.md` §6 M0 — оба оставшихся пункта переведены в `[x]`.
- [x] `docs/changelog/history.md` — Keep a Changelog v1.1 формат, секция Phase 0 (v0.0.1 → v0.0.8) с Added/Changed.

**Acceptance:**
- ✅ spec.md M0 полностью закрыт.
- ✅ Tag `v0.0.8` (заменяет упомянутый в исходном плане `v0.0.0-foundations`).

**Размер:** XS

---

## Фаза 1 — MVP single-node (M1) ✅

**Цель фазы:** на чистом Hetzner CX22 за один `platform-cli init` поднять Tier 1 кластер и задеплоить hello-world `Application` через GitOps.

**Spec:** §6 M1, §4.1 (Tier 1), §4.5, §4.12, §3.1.

### 1.1 platform-cli — каркас CLI

**Статус:** ✅ закрыто 2026-05-06.

**Цель:** Rust-бинарник `platform-cli` с командами-заглушками `init|plan|apply|status|login|upgrade-tier`.

**Решения по ходу:**
- Версионная схема Phase 1: `0.1.x` (минор = фаза, патч = подфаза).
- State хранится как JSON (`.apprafter/state.json`), не CUE-encoded. Переход на CUE-encoded — позже, когда схема состояния стабилизируется.
- CUE-доступ через subprocess (`cue export ... --out json`); FFI-вариант (`cuelang-go`) отложен.
- Workspace из четырёх крейтов: `platform-cli` (бинарь), `cli-core` (ошибки + Tier + логи + CUE), `cli-state` (state-файл), `cli-providers` (трейт + `DryRunProvider`).
- `cue::export_in(workdir, path)` добавлен в API: `cue` отказывается от абсолютных путей и требует относительный путь от module-root, поэтому wrapper вызывает `cue` с `current_dir(workdir)`. Простой `export(path)` — обёртка над `export_in(cwd, path)`.
- Все команды печатают «would …» с указанием будущей фазы plan.md, в которой стаб станет реальной операцией.

**Поставка:**
- [x] Cargo workspace `cli/` с тремя крейтами + бинарь (`platform-cli`, `cli-core`, `cli-state`, `cli-providers`).
- [x] CUE-доступ через subprocess (`cli-core::cue::{export, export_in}`), `CUE_BIN` env-override.
- [x] Структурированный логгер (`tracing` + `tracing-subscriber` с `EnvFilter`).
- [x] State-файл `.apprafter/state.json` (JSON в skeleton-фазе) с `load_or_default` / `save`.
- [x] Шесть команд-стабов через clap derive API.

**Acceptance:**
- ✅ `platform-cli --help` показывает все шесть subcommand'ов.
- ✅ `platform-cli plan` на пустом state выдаёт `no changes`.
- ✅ Workspace проходит `cargo fmt --all -- --check`, `cargo clippy --workspace --all-targets -- -D warnings`, `cargo test --workspace`.

**Зависит от:** 0.4

**Размер:** M

---

### 1.2 Hetzner Cloud built-in provider

**Статус:** ✅ shipped — sub-phase 1.2 полностью закрыта серией циклов `v0.1.2`–`v0.1.7`, покрывающих server / SSH-keys / network / firewall / CUE-parsing / floating IP / state import.

**Цель:** нативный provider в `platform-cli` через прямую интеграцию с Hetzner Cloud REST API (через `ureq`, blocking).

**Решения по ходу:**
- Используем `ureq` (blocking) + ручные wire-types вместо third-party `hcloud`-crate'ов: тоньше, без async, без неактивных внешних зависимостей.
- Mock-тесты через `mockito` 1.x (sync HTTP).
- Метим все managed-ресурсы лейблом `apprafter=true` — идемпотентность и будущий `import` строятся вокруг этого фильтра.
- `Provider` trait расширен: добавлен `destroy()`, `Plan.changes` переименован в `Plan.actions: Vec<Action>` (типизированные `CreateServer` / `DestroyServer` / `Noop`).
- `State` дополнен `hetzner_cloud: Option<HetznerCloudState>` (server_id + server_name).
- Server boot пока без SSH-ключей (Hetzner возвращает root-password). SSH-keys приедут вместе с network/firewall в следующем цикле.

**Поставка (server-CRUD ветка, v0.1.2):**
- [x] `cli-providers/hetzner_cloud/`: серверный CRUD (list / create / delete) с mockito-тестами.
- [x] `Provider::destroy()` + типизированный `Action`.
- [x] `HetznerCloudClient` (list / create / delete server) с idempotent 404-on-delete.
- [x] `HetznerCloudProvider` impl `Provider`: refresh + diff + apply + destroy.
- [x] CLI `destroy --yes` команда + дисциплина `apply` (требует `HCLOUD_TOKEN`, без него — внятная ошибка).
- [x] `examples/infrastructure/tier-1-hetzner.cue` фикстура.
- [x] `#[ignore]`-тагнутый e2e-тест против реального Hetzner.

**Поставка (SSH-keys, v0.1.3):**
- [x] `HetznerCloudClient` методы для SSH-keys: list / create / delete.
- [x] `Action::CreateSshKey` / `DestroySshKey`, `SshKeySpec`.
- [x] `ServerCreateRequest.ssh_keys` (`Option<Vec<u64>>`, serde-skip).
- [x] `HetznerCloudProvider.ssh_keys: Vec<SshKeySpec>` — refresh + idempotent create + ordered apply (ssh-keys → server) + ordered destroy (server → ssh-keys).
- [x] `HetznerCloudState.ssh_key_ids` cache (back-compat через `#[serde(default)]`).
- [x] `apply` читает `APPRAFTER_SSH_PUBLIC_KEY` env: при наличии — boot с SSH-key (без root-password).

**Поставка (Network + Firewall, v0.1.4):**
- [x] `HetznerCloudClient` методы для Network: list / create / delete.
- [x] `HetznerCloudClient` методы для Firewall: list / create / delete.
- [x] `ServerCreateRequest.networks` + `ServerCreateRequest.firewalls` (Option, serde-skip).
- [x] `Action::CreateNetwork` / `DestroyNetwork` / `CreateFirewall` / `DestroyFirewall`.
- [x] `NetworkSpec`, `FirewallSpec`, `FirewallRuleSpec`.
- [x] `HetznerCloudProvider.{networks,firewalls}` — ordered apply (ssh → net → fw → server) и destroy (server → fw → net → ssh).
- [x] `HetznerCloudState.{network_id,firewall_id}` cache.
- [x] CLI `apply` строит дефолтные `NetworkSpec` (10.0.0.0/16 + 10.0.0.0/24 в `eu-central`) и `FirewallSpec` (SSH 22 + HTTPS 443 ingress) из имени кластера.

**Поставка (CUE Infrastructure parsing, v0.1.5):**
- [x] CUE schema `Infrastructure` расширена optional полями (`region`, `network` с `subnet`, `firewall.ingress`, `sshKeys`, `osImage`).
- [x] `examples/infrastructure/tier-1-hetzner.cue` — полный пример (network 10.0.0.0/16 + subnet eu-central + SSH/HTTPS ingress + osImage).
- [x] `cli-core::manifest` модуль — `InfrastructureManifest` типы и `parse_infrastructure(workdir, path)` через `cue::export_in`.
- [x] `apply.rs`: при `APPRAFTER_MANIFEST=<path>` читает manifest и накладывает на v0.1.4-дефолты (server_type, image, network/subnet/zone, firewall rules, ssh keys). Без env var поведение v0.1.4 не изменилось.

**Поставка (Floating IP, v0.1.6):**
- [x] `HetznerCloudClient` методы для Floating IPs: list / create / delete (404-idempotent).
- [x] Wire-types `FloatingIp`, `FloatingIpListResponse`, `FloatingIpCreateRequest`/`Response`, `HomeLocation`.
- [x] `Action::CreateFloatingIp` / `DestroyFloatingIp`, `FloatingIpSpec`.
- [x] `HetznerCloudProvider.floating_ips` — refresh + idempotent create + ordered apply (ssh → net → fw → server → fip с `server` атрибутом сразу при создании) + ordered destroy (fip → server → fw → net → ssh).
- [x] `HetznerCloudState.floating_ip_ids` cache (back-compat через `#[serde(default)]`).
- [x] CUE schema: `network.floatingIPs: [...string]` (оставалось зарезервированным с v0.1.5).
- [x] CLI `apply` читает `network.floatingIPs` из manifest, префиксует имена кластером и передаёт как `FloatingIpSpec` (`ipv4`, `home_location = region`).
- [x] `examples/infrastructure/tier-1-hetzner.cue` — `floatingIPs: ["egress"]`.

**Поставка (`platform-cli import`, v0.1.7):**
- [x] `Commands::Import { force, dry_run }` clap-вариант + dispatch в `main.rs`.
- [x] `commands::hcloud::hcloud_base_url()` — общий хелпер для `apply`/`destroy`/`import`, читает `APPRAFTER_HCLOUD_BASE_URL` (test-only) с фолбэком на `DEFAULT_BASE_URL`.
- [x] `commands::import::run` — read-only сканирование `apprafter=true` ресурсов, сборка `HetznerCloudState` по `cluster_name`, флаги `--dry-run` (печатает summary, не пишет state) и `--force` (перезаписывает существующий `state.hetzner_cloud`).
- [x] Integration-тесты на `assert_cmd` + `mockito`: happy-path с записью state, `--dry-run` без записи, "no matching server" → friendly message, фильтр по `apprafter` лейблу, `--force` overwrite-guard.
- [x] `cli/README.md` — новая секция "Recovering state with `import`".

**Полное закрытие 1.2:**
- [x] `plan.md` отражает все 6 циклов как ✅; sub-phase 1.2 переведён из 🚧 partial в ✅ shipped.

**Acceptance (v0.1.2):**
- ✅ `platform-cli apply` (с валидным state + `HCLOUD_TOKEN`) поднимает 1× CX22.
- ✅ Повторный `platform-cli apply` — no-op (refresh видит сервер, Plan = пустой).
- ✅ `platform-cli destroy --yes` сносит сервер и чистит state.
- ✅ Mocked-тесты (12 шт.) + `#[ignore]` integration test компилируются и запускаются вручную с реальным Hetzner.

**Зависит от:** 1.1

**Размер:** L (разбит на 6 циклов: server-CRUD `v0.1.2` ✅, SSH-keys `v0.1.3` ✅, network+firewall `v0.1.4` ✅, CUE-parsing `v0.1.5` ✅, floatingIP `v0.1.6` ✅, import `v0.1.7` ✅)

---

### 1.2 AUDIT — Hetzner Cloud built-in provider: IPv6 support ✅

> v0.1.70 — 1.2 AUDIT shipped (partial): wire-type IPv6 parsing, k3s dual-stack cluster/service CIDRs, Hetzner Firewall ICMP allow-rule. `--node-ip` dual-binding и реальный pod-level dual-stack smoke прицеплены к зависимым подфазам (3.1 HA-bootstrap пересекает `--node-ip`; 1.4 AUDIT закрывает Cilium values для pod connectivity).

**Source:** ADR 0017.

**Поставка:**
- [x] `cli-providers/src/hetzner_cloud/types.rs` — новый `PublicIpv6 { ip: String }` (хранит `<prefix>::/64` CIDR-строку как Hetzner возвращает) + `PublicNet.ipv6: Option<PublicIpv6>`. Два regression-guard теста в `tests/types_test.rs` пинят deserialize sample response (dual-stack + только-v6 forward-compat ветка). Re-export `PublicIpv6` через `cli-providers::hetzner_cloud`.
- [x] **Hetzner private network остаётся IPv4-only** (фундаментальное ограничение Hetzner — public IPv6 идёт через server's public interface, private network — внутрикластерная IPv4). Без изменений в `NetworkSpec`; ADR 0017 это явно признаёт.
- [x] `cli-providers/src/hetzner_cloud/user_data.rs` — `K3sBootstrapOptions { dual_stack: bool }` (`Default::default()` = `true`), `build_k3s_user_data` теперь добавляет `--cluster-cidr=10.42.0.0/16,fd00:42::/64 --service-cidr=10.43.0.0/16,fd00:43::/112` per ADR 0017. Константы `CLUSTER_CIDR_DUAL_STACK` / `SERVICE_CIDR_DUAL_STACK` экспортируются для shared-use. Два regression-guard теста — default install line содержит CIDR-пару, opt-out `dual_stack: false` дропает их без касания других disable-флагов.
- [x] `cli/platform-cli/src/commands/apply.rs::default_ingress_rules` — новый ICMP-rule (`direction: in, protocol: icmp, port: None, source_ips: ["0.0.0.0/0", "::/0"]`) per ADR 0017 §Per-tier. Hetzner Cloud Firewall не различает ICMPv4 и ICMPv6 — один `protocol: icmp` правило покрывает обе family. Два regression-guard теста — `default_ingress_rules_emits_one_rule_per_default_port_plus_icmp` (счётчик правил) + `default_ingress_rules_include_icmp_for_pmtu_and_ndp` (shape).
- **Отложено:** `--node-ip` dual-binding пока не передаётся — требует cloud-init substitution с runtime-detected IPv4 + IPv6 host addresses (multi-line bash в `runcmd`), что в Tier 1 single-node не блокирует connectivity (k3s auto-detects). Закроется в 3.1 (HA bootstrap), когда heterogeneous-nodes сценарий делает выбор node IP критичным.
- **Отложено:** Full e2e dual-stack pod connectivity smoke — зависит от 1.4 AUDIT (Cilium Helm values dual-stack), pod не получит v6 интерфейс без Cilium-конфига. После 1.4 AUDIT добавим pod-level v4+v6 reachability assertion в `e2e/mvp.sh`.

**Acceptance:** Hetzner provider парсит IPv6 prefix из API; k3s install line содержит dual-stack CIDR-пару; ICMP allowed в Hetzner Firewall. Pod-level connectivity подтверждается после 1.4 AUDIT (Cilium).

**Зависит от:** —

**Размер:** M (доставлен как single-cycle audit ~v0.1.70; реальный pod-connectivity smoke выкатим вместе с 1.4 AUDIT)

---

### 1.3 k3s bootstrap на свежем VDS

**Статус:** ✅ shipped — sub-phase 1.3 закрыта серией циклов `v0.1.8`–`v0.1.10`: cloud-init bootstrap (k3s + ufw + fail2ban) → kubeconfig retrieval (SSH fetch + URL rewrite) → age-encryption кеша.

**Цель:** автоматическая установка k3s в single-node режиме после провижионинга VM.

**Поставка (cloud-init bootstrap, v0.1.8):**
- [x] `cli-providers::hetzner_cloud::user_data::build_k3s_user_data` — pure builder для `#cloud-config` YAML; собирает install-команду для k3s c `--disable=traefik --disable=servicelb`, ufw default-deny + whitelist (22/6443/80/443 tcp + 51820 udp), fail2ban для SSH jail.
- [x] `ServerCreateRequest.user_data: Option<String>` (serde-skip when None) + `ServerSpec.user_data` + проброс через `HetznerCloudProvider::create_request`.
- [x] CLI `apply` ставит `user_data = Some(build_k3s_user_data(...))`; default Hetzner-firewall расширен до tier-1 whitelist (тот же набор портов, что и в ufw).

**Поставка (kubeconfig retrieval, v0.1.9):**
- [x] `Server.public_net.ipv4.ip` wire field — `cli-providers::hetzner_cloud::types` теперь декодирует public IPv4 с list-ответа.
- [x] `cli-providers::hetzner_cloud::kubeconfig` — `rewrite_server_url(yaml, public_ip)` + `KubeconfigFetcher` trait + `SshKubeconfigFetcher` impl (shell out на системный `ssh`, BatchMode/StrictHostKeyChecking=accept-new); `default_ssh_identity_path()` читает `APPRAFTER_SSH_PRIVATE_KEY` с фолбэком на `~/.ssh/id_ed25519`.
- [x] `HetznerCloudState.kubeconfig_yaml: Option<String>` (`#[serde(default)]`).
- [x] `Commands::Kubeconfig { refresh }` + `commands::kubeconfig::run` + `compute_kubeconfig` orchestrator (cached / cold-fetch / `--refresh`).
- [x] Unit-тесты на `rewrite_server_url`, argv-shape `SshKubeconfigFetcher`, `compute_kubeconfig` через `FakeFetcher` (cold/cached/--refresh); integration на missing-state error + cached print без SSH.
- [ ] (defer to v0.1.10) age-encryption кеша — на этом цикле сохраняем plaintext.

**Поставка (age-encryption, v0.1.10):**
- [x] `cli-core::secrets` — wrapper над `age` 0.10: `load_or_create_identity` (mode 0600, parent dirs auto), `encrypt_for_recipient` (armored), `decrypt_with_identity`, `default_age_key_path()` (env override + `~/.config/apprafter/age.key` fallback).
- [x] `HetznerCloudState.kubeconfig_age: Option<String>` (armored, serde-default); `kubeconfig_yaml` остаётся читаемым один цикл как legacy-fallback и обнуляется на ближайшем `--refresh`.
- [x] `commands::kubeconfig::run` шифрует на запись (recipient = .to_public() identity), расшифровывает на чтение, fallback на plaintext-поле.
- [x] Integration round-trip через предзаписанный age-blob + `APPRAFTER_AGE_KEY` env override; in-file тесты `cli-core::secrets` (round-trip / wrong-identity / persist+reload / mode-0600 / env override / bech32 sanity).

**Acceptance (v0.1.8):** `platform-cli apply` отправляет в Hetzner POST `/v1/servers` с непустым `user_data`-полем; mocked-тесты + unit-тесты builder'а пинят форму YAML.

**Acceptance (1.3 целиком, после v0.1.9):** через ~5 минут после `platform-cli init && platform-cli apply` команда `platform-cli kubeconfig | KUBECONFIG=/dev/stdin kubectl get nodes` показывает Ready single node.

**Зависит от:** 1.2

**Размер:** M (разбит на 3 цикла: cloud-init `v0.1.8` ✅, kubeconfig retrieval `v0.1.9` ✅, age encryption `v0.1.10` ✅)

---

### 1.4 Cilium + Gateway API установка

**Статус:** ✅ shipped — sub-phase 1.4 закрыта серией циклов `v0.1.11`–`v0.1.12`: Cilium через Helm + Gateway API CRDs (1.4a) → default-deny NetworkPolicy + real-cluster smoke (1.4b).

**Цель:** заменить flannel на Cilium с kube-proxy replacement и Gateway API.

**Поставка (Cilium + Gateway API CRDs, v0.1.11):**
- [x] `cli-providers::k8s::cilium_values::cilium_values_yaml()` — pure builder для tier-1 Helm-values (`kubeProxyReplacement: true`, `ipam: kubernetes`, `hubble: enabled: false`, `operator: replicas: 1`).
- [x] `cli-providers::k8s::helm` — `HelmRunner` trait + `HelmCli` shell-out + `HelmUpgradeArgs` + `CILIUM_CHART_VERSION = "1.16.5"`.
- [x] `cli-providers::k8s::kubectl` — `KubectlRunner` trait + `KubectlCli` shell-out + `ManifestSource` enum + `gateway_api_crds_url()` (pinned `v1.2.1`).
- [x] `Commands::ClusterBootstrap` + `commands::cluster_bootstrap::run()` + pure `perform_bootstrap<H, K>` orchestrator (helm repo add → helm upgrade --install → kubectl apply -f gateway CRDs); driven с fake runners в in-file tests.
- [x] `build_k3s_user_data` теперь добавляет `--disable-kube-proxy` к k3s install line — без этого `kubeProxyReplacement: true` бессмыслен.

**Поставка (NetworkPolicy + smoke, v0.1.12):**
- [x] `cli-providers::k8s::network_policy::default_deny_network_policy_yaml(namespace)` — pure builder для `NetworkPolicy` (apiVersion `networking.k8s.io/v1`, podSelector `{}`, policyTypes ingress + egress, label `apprafter=true`).
- [x] `perform_bootstrap` теперь применяет default-deny на `default` namespace после Gateway API CRDs; kube-system намеренно exempt; `kubectl apply -f` идёт из tempfile.
- [x] Renamed FakeKubectl test (`perform_bootstrap_runs_helm_repo_then_install_then_two_kubectl_applies`) пинит call sequence + ManifestSource type для каждого apply.
- [x] `cli/platform-cli/tests/cluster_smoke_test.rs` — `#[ignore]`-tagged real-cluster smoke; opt-in через `APPRAFTER_K8S_SMOKE=1` + `KUBECONFIG`; проверяет `cilium status --wait`, `kubectl apply --dry-run=server -f Gateway`, наличие default-deny NetworkPolicy.

**Acceptance (v0.1.11):** `platform-cli cluster-bootstrap` выводит сводку и завершается успешно (mocked-runner test); реальный smoke (`cilium status` зелёный, `kubectl apply` Gateway проходит admission) — после v0.1.12.

**Зависит от:** 1.3

**Размер:** M (разбит на 2 цикла: Cilium + Gateway API CRDs `v0.1.11` ✅, NetworkPolicy + smoke `v0.1.12` ✅)

---

### 1.4 AUDIT — Cilium + Gateway API установка: dual-stack Helm values ✅

> v0.1.71 — 1.4 AUDIT shipped: `cilium_values_yaml()` явно декларирует `ipv4.enabled: true` + `ipv6.enabled: true`; `e2e/mvp.sh` получил Phase 6.4 с pod-level dual-stack assertion (закрывает отложенный 5-й чекбокс 1.2 AUDIT).

**Source:** ADR 0017.

**Поставка:**
- [x] Cilium Helm values builder лежит в `cli-providers/src/k8s/cilium_values.rs` (`cilium_values_yaml()`).
- [x] Assess текущего state (v0.1.70): `ipv4.enabled` не объявлен явно (Helm chart 1.16.x default = true, но это implicit); `ipv6.enabled` не объявлен (default = false) → поды никогда не получают v6 интерфейс даже когда k3s выдаёт dual-stack podCIDR. IPAM mode = `kubernetes` (правильно — k3s публикует pod CIDR через Node API, Cilium читает оттуда без собственного allocator'а).
- [x] Updated Helm values на dual-stack: добавлены два явных блока `ipv4: { enabled: true }` и `ipv6: { enabled: true }`. IPAM `mode: kubernetes` сохранён без изменений.
- [x] Gateway API CRDs install path — verified: `kubectl apply -f gateway-api/standard-install.yaml` ставит **type definitions only**, не listeners. Family-binding происходит при создании Gateway resource'ом (см. позже в 4.1a), и Gateway API spec поддерживает `listener.protocol: HTTPS` без family-restriction — listener bind'ится на любую family, доступную на node (после v0.1.71 — обе). Никаких изменений в install path не требуется.
- [x] E2E `Phase 6.4: dual-stack podIPs assertion` в `e2e/mvp.sh` — после Phase 6 (endpoint curl green) делает `kubectl get pod -l app=e2e-hello -o jsonpath='{.items[0].status.podIPs[*].ip}'` и assert'ит наличие **обоих** v4-адреса из `10.42.0.0/16` (k3s podCIDR) и v6-адреса из `fd00:42::/64` (k3s podCIDR v6 + Cilium ipv6.enabled). Без 1.4 AUDIT этот assert валится с понятным сообщением "Cilium ipv6.enabled likely false". Реальный outbound v6 curl-тест (curl -6 ipv6.google.com из pod'а) отложен в Phase 3.x — pod-image `nginxdemos/hello:plain-text` не имеет curl, добавление test-pod с `curlimages/curl:latest --ipv6` пересекается с network observability (Hubble), которую закроет 3.7a.

**Acceptance:** `cilium_values_yaml()` декларирует обе family explicit; unit-test `dual_stack_enabled_per_adr_0017` пинит наличие `ipv4:` + `ipv6:` blocks и счётчик `enabled: true` ≥ 2; `e2e/mvp.sh` Phase 6.4 валится если у pod'а отсутствует v6 IP.

**Зависит от:** 1.2 AUDIT (Hetzner provider dual-stack) ✅

**Размер:** S — доставлен как single-cycle audit ~v0.1.71.

**Known wart (deferred to Track B 1.70):** `helm upgrade cilium` патчит `cilium-config` ConfigMap, но **не** триггерит rotation cilium DaemonSet pods (chart v1.16.x не имеет `checksum/config` аннотации в template'е). На свежий install это не влияет (агенты сразу стартуют с новыми values), но на upgrade существующего кластера оператору приходится вручную `kubectl rollout restart daemonset cilium -n kube-system` + пересоздать pod'ы, чтобы они получили v6 IP. Quick-fix в `cluster-bootstrap` (один `kubectl rollout restart`) добавил бы ~30с к каждому re-run; вместо этого ждём 1.70 (`cluster-bootstrap` rewrite в Argo CD-managed flow), где Argo CD resource hooks решают это нативно — disposable код мы тогда не пишем.

---

### 1.5 Argo CD установка и bootstrap

**Статус:** ✅ shipped — sub-phase 1.5 закрыта серией циклов `v0.1.13`–`v0.1.17`: helm install (1.5a) → admin password (1.5b) → cert-manager + ClusterIssuer (1.5c) → Gateway + HTTPRoute (1.5d) → bootstrap-Application + smoke (1.5e).

**Цель:** Argo CD как единственный механизм применения манифестов в кластер.

**Поставка (Argo CD Helm install, v0.1.13):**
- [x] `cli-providers::k8s::argocd_values::argocd_values_yaml()` — pure builder для tier-1 Helm-values (Dex off, Redis-HA off, ApplicationSet on, Notifications off, ClusterIP server, single replicas).
- [x] `ARGOCD_CHART_VERSION = "7.7.7"` в том же модуле.
- [x] `perform_bootstrap` теперь делает helm repo add `argo` + helm upgrade --install `argocd` после default-deny NP; renamed FakeRunner test пинит call sequence для обеих helm releases (cilium → argocd) и обоих kubectl applies.
- [x] `cluster-bootstrap` дропает 4-й tempfile (Argo CD values) рядом с kubeconfig / Cilium values / default-deny NP.

**Поставка (admin password retrieval, v0.1.14):**
- [x] `KubectlRunner::get_secret_value(name, namespace, key, kubeconfig)` — wraps `kubectl get secret -o jsonpath={.data.<key>}` + base64-decodes; argv-shape unit test.
- [x] `Commands::ArgocdPassword { refresh }` + `commands::argocd_password::run` + pure `compute_argocd_password<K>` orchestrator.
- [x] `HetznerCloudState.argocd_admin_password_age: Option<String>` (serde-default).
- [x] In-file FakeKubectl tests + cli_smoke missing-state error + integration test для cached-path round-trip через `APPRAFTER_AGE_KEY`.

**Поставка (cert-manager + self-signed ClusterIssuer, v0.1.15):**
- [x] `cli-providers::k8s::cert_manager_values::cert_manager_values_yaml()` — pure builder для tier-1 Helm-values (`installCRDs: true`, single replicas, Prometheus off).
- [x] `CERT_MANAGER_CHART_VERSION = "v1.16.2"` в том же модуле.
- [x] `cli-providers::k8s::issuer::selfsigned_cluster_issuer_yaml()` — pure builder для `cert-manager.io/v1 ClusterIssuer` `apprafter-selfsigned` (`spec.selfSigned: {}`, label `apprafter=true`); имя issuer'а как `pub const APPRAFTER_SELFSIGNED_ISSUER` чтобы будущие HTTPRoute / Certificate manifests могли ссылаться без магических строк.
- [x] `perform_bootstrap` теперь делает helm repo add `jetstack` + helm upgrade --install `cert-manager` после Argo CD, и kubectl apply self-signed issuer; renamed FakeRunner test пинит 3 helm repos / 3 installs / 3 kubectl applies в правильном порядке.
- [x] `cluster-bootstrap` дропает 5-й и 6-й tempfile (cert-manager values + selfsigned issuer) рядом с существующими.

**Поставка (Gateway + HTTPRoute для Argo CD UI, v0.1.16):**
- [x] CUE schema: `spec.argocd.domain?` optional поле в `#Infrastructure`.
- [x] Rust manifest mirror: `cli_core::manifest::ArgocdBlock { domain: Option<String> }` + `InfrastructureSpec.argocd: Option<ArgocdBlock>`.
- [x] `cli-providers::k8s::argocd_gateway::argocd_gateway_yaml(domain)` — pure builder для 3-document манифеста (Gateway + HTTPRoute + Certificate); все ресурсы в namespace `argocd`, label `apprafter=true`, Certificate ссылается на `apprafter-selfsigned` ClusterIssuer.
- [x] `perform_bootstrap` подросла `argocd_gateway_path: Option<&Path>` параметром; при Some — kubectl apply после self-signed ClusterIssuer; при None — bootstrap идентичен v0.1.15.
- [x] `cluster_bootstrap::run` парсит `APPRAFTER_MANIFEST` если установлен, извлекает domain, conditionally дропает 7-й tempfile.
- [x] `examples/infrastructure/tier-1-hetzner.cue` — закомментированный пример opt-in.

**Поставка (bootstrap-Application + закрытие 1.5, v0.1.17):**
- [x] CUE schema: `spec.argocd.bootstrapRepo?` + `spec.argocd.bootstrapPath?` optional поля.
- [x] Rust manifest mirror: `ArgocdBlock.bootstrap_repo: Option<String>` (rename `bootstrapRepo`) + `bootstrap_path: Option<String>` (rename `bootstrapPath`).
- [x] `cli-providers::k8s::bootstrap_app::bootstrap_application_yaml(repo_url, path)` — pure builder для `argoproj.io/v1alpha1 Application` `bootstrap` (namespace `argocd`, syncPolicy.automated.prune+selfHeal, label `apprafter=true`); `BOOTSTRAP_APP_DEFAULT_PATH = "."` для пустого пути.
- [x] `read_argocd_settings_from_manifest` возвращает struct (domain + bootstrap_repo + bootstrap_path); `cluster_bootstrap::run` conditionally дропает 8-й tempfile.
- [x] `perform_bootstrap` подросла `bootstrap_app_path: Option<&Path>` параметром; при Some — kubectl apply после optional Argo CD Gateway.
- [x] Real-cluster smoke в `cluster_smoke_test.rs`: `kubectl get application bootstrap -n argocd` под gate `APPRAFTER_BOOTSTRAP_REPO_SMOKE=1`.
- [x] Sub-phase 1.5 status: ✅ shipped.

**Acceptance (v0.1.13):** `perform_bootstrap` производит `helm install cilium`, `kubectl apply` Gateway CRDs, `kubectl apply` default-deny NP, `helm install argocd` в этом порядке (mocked). Реальный smoke (Argo CD pods Ready, UI reachable, root app sync) — после v0.1.15.

**Зависит от:** 1.4

**Размер:** M (разбит на 5 циклов: helm install `v0.1.13` ✅, admin password `v0.1.14` ✅, cert-manager + ClusterIssuer `v0.1.15` ✅, Gateway + HTTPRoute `v0.1.16` ✅, bootstrap-Application + smoke `v0.1.17` ✅)

---

### 1.6 Backstage минимальный деплой

**Статус:** ✅ shipped — sub-phase 1.6 закрыта серией циклов `v0.1.18`–`v0.1.20`: k8s-манифесты (1.6a) → app-скаффолд + Dockerfile (1.6b) → app-config ConfigMap + OAuth stub (1.6c).

**Цель:** Backstage как pod в кластере, доступный через Gateway.

**Поставка (k8s-манифесты + cluster-bootstrap, v0.1.18):**
- [x] CUE schema: `spec.backstage.domain?` + `spec.backstage.image?`.
- [x] Rust manifest mirror: `BackstageBlock { domain, image }`; `Default` derived.
- [x] `cli-providers::k8s::backstage_manifests::backstage_manifests_yaml(domain, image)` — pure builder для 6-document манифеста (Namespace + Deployment + Service + HTTPRoute + Gateway + Certificate); `BACKSTAGE_DEFAULT_IMAGE = "ghcr.io/apprafter/backstage:placeholder"` для пустого image.
- [x] `read_argocd_settings_from_manifest` переименован в `read_cluster_settings_from_manifest`, struct расширен backstage-полями.
- [x] `perform_bootstrap` подросла `backstage_manifests_path: Option<&Path>` параметром; при Some — kubectl apply после bootstrap-Application.
- [x] `manifests/tier-1/backstage/{example.yaml, README.md}` — статический рендеринг builder'а + recipe для refresh через `cargo run --example backstage_example`.

**Поставка (app-скаффолд + Dockerfile, v0.1.19):**
- [x] `backstage-plugins/host/Dockerfile` — multi-stage Backstage 1.x шаблон (Node 20 builder + slim runtime, копия skeleton/bundle tarballs, EXPOSE 7007, USER node).
- [x] `backstage-plugins/host/.dockerignore` — node_modules, build-output, local config, secrets out of context.
- [x] `backstage-plugins/host/scripts/scaffold.sh` — обёртка над `npx @backstage/create-app@latest --skip-install` с preflight'ом (Node 20+, target пустой), drop'ом Dockerfile/.dockerignore рядом, печатью next-steps. Shellchecked.
- [x] `backstage-plugins/host/README.md` — 6-step workflow scaffold → install → build → push → manifest → cluster-bootstrap; cross-links к Dockerfile, scaffold-скрипту, rendered example manifest, Rust-builder'у.
- [x] `cli/README.md` — blockquote-cross-link к host-app README рядом со step 10.

**Поставка (app-config ConfigMap + OAuth stub, v0.1.20):**
- [x] `cli-providers::k8s::backstage_app_config::backstage_app_config_yaml(domain)` — pure builder для tier-1 `app-config.yaml` (`app.title`, `app.baseUrl`, `backend.baseUrl` + `cors.origin` от `domain`, `backend.listen 0.0.0.0:7007`, `database better-sqlite3 :memory:`, `auth.providers.guest.dangerouslyAllowOutsideDevelopment: true`).
- [x] `backstage_manifests_yaml` теперь эмитит 7-document YAML — добавлен `ConfigMap` `backstage-config` с `data["app-config.yaml"]: |<rendered>`, и Deployment получил `volumeMount` (subPath, readOnly) в `/app/app-config.yaml`.
- [x] `manifests/tier-1/backstage/example.yaml` пере-рендерён.
- [x] Sub-phase 1.6 status: ✅ shipped.

**Acceptance:** `https://backstage.<domain>` открывается, виден catalog (пустой), `auth.providers.guest` пускает без логина (`dangerouslyAllowOutsideDevelopment: true`).

**Зависит от:** 1.5

**Размер:** M (разбит на 3 цикла: k8s-манифесты `v0.1.18` ✅, app-скаффолд `v0.1.19` ✅, app-config + OAuth `v0.1.20` ✅)

---

### 1.7 Application CRD v1alpha1 ✅

> v0.1.25 — schema refactor: `base` + `environments` moved under `spec` for k8s-convention alignment before phase 1.8.

**Цель:** зарегистрировать CRD `Application` в кластере, схема валидируется через CUE.

**Поставка:**
- [x] OpenAPI v3 схема CRD: hand-rolled YAML мирорит CUE `#ApplicationSpec` (v0.1.22 — `cli-providers::k8s::application_crd` + apply через cluster-bootstrap; `cue cmd export-crd` автогенерация откладывается до v0.2.x).
- [x] Поля v1alpha1: `image`, `expose`, `replicas`, `env` (только литералы), `environments` map (v0.1.21 — schema + Rust parser).
- [x] Admission webhook (Rust, axum + rustls) в отдельном pod с auto-rotated cert (cert-manager Certificate в `apprafter-system`, `cert-manager.io/inject-ca-from` синхронит `caBundle` на ValidatingWebhookConfiguration; v0.1.23 — webhook crate + Dockerfile, v0.1.24 — k8s-манифесты + cluster-bootstrap wiring).
- [x] Невалидный manifest реджектится с понятной ошибкой (v0.1.24 — webhook возвращает `Application is invalid: <field>: <reason>` через AdmissionReview, kube-apiserver включает это сообщение в ответ `kubectl apply`).

**Acceptance:** `kubectl apply` валидного Application проходит; невалидного — с сообщением, указывающим поле и причину.

**Зависит от:** 0.4, 1.5

**Размер:** M

---

### 1.8 Application operator — каркас на kube-rs ✅

> v0.1.26 — sub-phase 1.8a shipped: 3 library crates (`operator-core` + `operator-rendering` + `operator-controllers/application`).
> v0.1.27 — sub-phase 1.8b shipped: `apprafter-operator` binary + 3 Prometheus signals + axum `/healthz` / `/readyz` / `/metrics`.
> v0.1.28 — sub-phase 1.8c shipped: Lease-based leader election (`operator-core::leader`).
> v0.1.29 — sub-phase 1.8d shipped: Helm chart at `operator/charts/apprafter-operator/`. Phase 1.8 ✅.

**Цель:** Rust-операторный pod с reconcile-loop по `Application`.

**Поставка:**
- [x] `operator/` — workspace с подпакетами `operator-core`, `operator-controllers/application`, `operator-rendering` (v0.1.26).
- [x] Контроллер на `kube-rs`, leader election через Lease (v0.1.27 + v0.1.28).
- [x] Метрики Prometheus: `reconcile_total`, `reconcile_duration`, `reconcile_errors` (v0.1.27).
- [x] Структурированный лог (tracing) (v0.1.27 — `tracing-subscriber::EnvFilter` в `apprafter-operator/main.rs`).
- [x] Health/readiness endpoints (v0.1.27 — `/healthz` + `/readyz` axum routes).
- [x] Helm chart для деплоя оператора (v0.1.29 — `operator/charts/apprafter-operator/`).

**Acceptance:** оператор запускается, видит Application-объекты, пишет «reconciled» в лог; metrics endpoint отвечает.

**Зависит от:** 1.7

**Размер:** M

---

### 1.9 Application reconcile: image + expose + replicas ✅

> v0.1.30 — sub-phase 1.9a shipped: pure `render_application` for Deployment + Service.
> v0.1.31 — sub-phase 1.9b shipped: reconcile applies children via SSA + updates `status`.
> v0.1.32 — sub-phase 1.9c shipped: per-environment expansion (`APPRAFTER_ENV` selects override). Phase 1.9 ✅. HTTPRoute deferred to a later phase that owns Gateway domain config end-to-end.

**Цель:** Application → Deployment + Service + HTTPRoute.

**Поставка:**
- [x] Renderer (pure-функция) `Application → [k8s Resource]` (v0.1.30 — Deployment + Service; HTTPRoute deferred to a phase that owns Gateway domain config end-to-end).
- [x] Per-environment expansion (v0.1.32 — pure-Rust merge; functionally equivalent to CUE unification for our v1alpha1 schema, switchable to CUE FFI when CUE-only constructs are added).
- [x] Apply-семантика: server-side apply с field manager `apprafter-operator` (v0.1.31).
- [x] Status subresource: `phase`, `observedGeneration`, `conditions`, `endpointURL` (v0.1.31).
- [x] Удаление Application удаляет дочерние ресурсы (ownerReferences) (v0.1.30).

**Acceptance:** манифест Application с image+expose даёт работающий HTTP endpoint, доступный изнутри кластера; `curl` на endpoint отвечает.

**Зависит от:** 1.8

**Размер:** M

---

### 1.10 Backstage Application plugin (status view) ✅

> v0.1.33 — sub-phase 1.10a shipped: TypeScript scaffold + types + pure handler stubs.
> v0.1.34 — sub-phase 1.10b shipped: `KubeApplicationStore` proxies kube apiserver via in-cluster SA token.
> v0.1.35 — sub-phase 1.10c shipped: applications-frontend scaffold + `ApplicationsApi` interface + pure `applicationsToRows` transform.
> v0.1.36 — sub-phase 1.10d shipped: `ApplicationsTable` + `ApplicationDetail` + `EnvironmentTabs` React components + per-env helpers. Backstage `createApiRef` + `createPlugin` wiring documented as a consumer-side snippet (keeps the package's dep tree light enough to publish independently). Phase 1.10 ✅.

**Цель:** в Backstage — список Application, статус, ссылка на endpoint, последние события.

**Поставка:**
- [x] Backstage backend plugin читает k8s API напрямую (через kubeconfig service account) (v0.1.33 + v0.1.34 — `@apprafter/applications-backend` с `KubeApplicationStore` через in-cluster service-account token).
- [x] Frontend plugin: таблица + drilldown (v0.1.36 — `ApplicationsTable` + `ApplicationDetail` React components).
- [x] События: replicas / status / последние deploys (v0.1.36 — `ApplicationDetail` рендерит `status.phase` + `status.observedGeneration` + полный список `conditions` с `lastTransitionTime`).
- [x] Per-environment вкладки (dev/staging/prod) (v0.1.36 — `EnvironmentTabs` controlled component + `applicationsForEnvironment` filter helper).

**Acceptance:** в Backstage виден задеплоенный hello-world, статус Ready, ссылка работает.

**Зависит от:** 1.6, 1.9

**Размер:** M

---

### 1.11 Golden-path template: Bun HTTP service ✅

> v0.1.37 — sub-phase 1.11a shipped: `examples/templates/bun-http/` starter (OneBun + multi-stage Dockerfile + v1alpha1 Application.cue).
> v0.1.38 — sub-phase 1.11b shipped: Backstage Software Template (`template.yaml` + `skeleton/`) + operator quickstart at `docs/dev-guide/quickstart.md`. Phase 1.11 ✅.

**Цель:** Backstage Software Template, генерирующий стартер на OneBun.

**Поставка:**
- [x] Template в `examples/templates/bun-http/`: `package.json`, `Dockerfile` (multi-stage, distroless), `src/index.ts` + `app.module.ts` + `health.controller.ts` + `config.ts` (OneBun controllers + envSchema), `apprafter/Application.cue` (v0.1.37).
- [x] Backstage software template manifest с параметрами (имя, репо, домен) (v0.1.38 — `template.yaml` + `skeleton/` subdir со scaffolder Nunjucks templating).
- [x] Документация в `docs/dev-guide/quickstart.md` (v0.1.38).

**Acceptance:** через UI Backstage за 3 клика создаётся репо с готовым стартером; коммит → Argo CD → задеплоилось.

**Зависит от:** 1.10

**Размер:** S

---

### 1.12 End-to-end MVP smoke-тест ✅

> v0.1.39 — sub-phase 1.12a shipped: `e2e/mvp.sh` orchestration script + operator-guide quickstart.
> v0.1.40 — sub-phase 1.12b shipped: `.github/workflows/nightly.yml` (cron 04:00 UTC + workflow_dispatch). Phase 1.12 ✅ pending operator's "5 greens in a row" judgment call — the automation lands here, the verdict lands when the streak holds.

**Цель:** воспроизводимый E2E-тест полного пути: чистый Hetzner-аккаунт → задеплоенный hello-world.

**Поставка:**
- [x] Скрипт `e2e/mvp.sh`: `platform-cli init` → ждёт готовности → деплоит hello-world → проверяет HTTP-endpoint (v0.1.39 — Application-via-template путь живёт в operator-guide quickstart до публикации образа оператора).
- [x] CI nightly job (с реальным Hetzner project под отдельный billing-tag) (v0.1.40 — `.github/workflows/nightly.yml`, cron 04:00 UTC + workflow_dispatch; billing-tag через `apprafter=true` label, выделенный CI tag отложен до propagation labels через provider).
- [x] Таймер: фиксируем «time-to-first-application», цель < 30 минут (v0.1.39 — `START_NS` + `elapsed` в mvp.sh; observed 6-9 min, well under 30-min budget).
- [x] `docs/operator-guide/quickstart.md` — те же шаги вручную (v0.1.39).

**Acceptance:** nightly зелёный 5 раз подряд; ручной прогон по docs работает у нового человека.

**Зависит от:** 1.11

**Размер:** M

---

### 1.13 Закрытие чек-листа M1 spec ✅

**Поставка:**
- [x] Обновить `spec.md` §6 M1 — все пункты `[x]` (v0.1.41).
- [x] Tag `v0.1.0-mvp` (v0.1.41 — the v0.1.41 commit also carries an annotated `v0.1.0-mvp` tag pointing at the same SHA).
- [x] Release notes (v0.1.41 — `docs/changelog/history.md` graduates the Phase 1 section into a `v0.1.0-mvp` release block).

**Размер:** XS

---

### 1.14 Level B integration cycle (default-on operator + webhook) ✅

> v0.1.64 — sub-phase 1.14 shipped: `cluster-bootstrap` installs the AppRafter operator + admission-webhook by default from ghcr.io images published by `release-operator.yml`. Default-on semantics with opt-out via `spec.{operator,admissionWebhook}.enabled: false`. Fork builds override via `image` + `tag` fields; variant-C resolution semantics (full-ref ignores `tag`).

**Поставка (v0.1.64):**
- [x] `cli-providers::k8s::image_ref` — `RELEASED_OPERATOR_VERSION` const + `resolve_image_ref` variant-C helper (6 unit tests).
- [x] `cli-providers::k8s::operator_values` — pure values-YAML builder (3 unit tests).
- [x] `cli-providers::k8s::operator_chart` — `include_dir!`-embedded helm chart + runtime extractor (2 tests).
- [x] `cli-core::manifest` — `OperatorBlock` + extended `AdmissionWebhookBlock` (4 schema tests).
- [x] `HelmUpgradeArgs.version` → `Option<String>` (allows local-path chart installs).
- [x] `perform_bootstrap` gains operator + webhook orchestration steps in `apprafter-system` (step 8 + step 9 per spec).
- [x] 5 new orchestration tests (default install order; operator opt-out; webhook opt-out; full-ref override; tag-only override).
- [x] CUE schema extension: `spec.operator?:` block + extended `spec.admissionWebhook?:`.
- [x] `e2e/mvp.sh` Phase 6.5 — apply Application CR + poll status `Ready` + assert child Deployment `Available` (60s deadline).
- [x] `docs/operator-guide/quickstart.md` §5 rewrite (operator pod required → operator pod installed by default).

**Acceptance:** против чистого Hetzner кластера новый оператор проходит manual walk из spec §1.14 (init → apply → kubeconfig → cluster-bootstrap → kubectl apply Application → `.status.phase == Ready` за 60с → child Deployment живой) без `helm install` руками и без «build your own image».

**Зависит от:** 1.13

**Размер:** S (один цикл, ~3 рабочих дня)

---

### 1.15 Level C GitOps cycle (env-driven Argo CD repo credentials) ✅

> v0.1.65 — sub-phase 1.15 shipped: `cluster-bootstrap` provisions the `apprafter-bootstrap-repo-creds` Argo CD Secret automatically when `APPRAFTER_ARGOCD_REPO_TOKEN` is set, enabling private GitHub/GitLab `spec.argocd.bootstrapRepo` without `kubectl apply` of a Secret by hand. Public-repo path unchanged. 4-quadrant manual walk documented in `docs/operator-guide/gitops-walk.md`.

**Поставка (v0.1.65):**
- [x] `cli-providers::k8s::argocd_repo_secret` — pure builder + 2 constants (4 unit tests).
- [x] `cluster_bootstrap::read_argocd_repo_creds` testable helper over injected env-lookup closure (4 unit tests).
- [x] `ClusterSettings` gains `argocd_repo_creds: Option<(String, String)>`; `default_cluster_settings` + `read_cluster_settings_from_manifest` populate it from env.
- [x] `perform_bootstrap` gains `argocd_repo_secret_path: Option<&Path>` parameter at bootstrap step 9.5 (between webhook and Argo CD HTTPRoute).
- [x] `run()` builds the tempfile when both creds + `bootstrap_repo` are `Some`, wires path through.
- [x] Success-message suffix mentions repo-creds Secret when applied.
- [x] 3 new orchestration tests (token+repo creates Secret before bootstrap App; token absent skips Secret but keeps App; no bootstrap repo skips both).
- [x] 8 pre-existing orchestration tests updated for the new arg position.
- [x] `docs/operator-guide/gitops-walk.md` — 4-quadrant runbook (GitHub × GitLab × public × private) with prereqs, DoD checklists, troubleshooting matrices, token-rotation + revoke sections.
- [x] `docs/operator-guide/quickstart.md` §3 gains the env-var opt-in bullet.

**Acceptance:** против чистого Hetzner кластера новый оператор проходит manual walk из spec §1.15 (все 4 квадранта end-to-end), каждый walk заканчивается зелёным DoD checklist (Argo CD UI: bootstrap = Synced + Healthy; child Application reconcilen оператором; для private — Secret присутствует в argocd ns).

**Зависит от:** 1.14

**Размер:** S (один цикл, ~2 рабочих дня кода + manual walk)

---

## Фаза 1.5 — Self-managing platform rethink (M1.5) ⚡
> 🏁 SR: A · order 1 — M1.5 Track B subset (ADR 0025/0028/0029: GitOps + platform-stack distribution + CUE CMP); managed substrate, largely closed

**Цель фазы:** архитектурный rethink из ADR 0025–0029. Переход от imperative `cluster-bootstrap` к Argo CD-managed platform stack из versioned OCI chart, declarative version control через PlatformStack CRD, unified MigrationPlan для application + platform scopes, CUE compilation для user app repos через CMP sidecar.

**Spec:** §3.10, §3.11 (PlatformStack), §3.8 (MigrationPlan unified). ADRs 0025–0029.

**Almighty target:** «happy path» first user experience сжимается до ~30 минут end-to-end (install binary → `apprafter init` → `apprafter bootstrap-all` → `apprafter open argocd` → add app repo via UI → app deployed). Каждая подфаза landing'ится как `v0.1.66`–`v0.1.83` patch release (loose recommendation, точное mapping commit-driven). После закрытия M1.5 — tag `v0.2.0-self-managing`, после чего Phase 2 (M2) стартует с `v0.2.0-services` уже на правильном фундаменте.

**Numbering:** под-фазы M1.5 используют 1.66–1.83 как continuation Phase 1 namespace, поскольку landing'ятся последовательными `v0.1.66`–`v0.1.83` releases перед `v0.2.0-services`. Major version stays `0`; minor reflects phase number (`v0.2.x` для всего между M1.5 и M3 closure, `v0.3.x` для M3 series, etc.).

**Blocks Phase 2** потому что Phase 2 (ServiceProviders, ResourceClaims, Tenant logic) builds on the GitOps-managed platform. Landing Phase 2 поверх split-brain дизайна приведёт к технического долгу — все ServiceProviders придётся reframing когда M1.5 doлжен будет landить позже.

### M1.5 Track positioning — CLI DX rework + Platform rethink + Dev-mode integration

M1.5 содержит **три work tracks**, выполняемых **последовательно** в указанном порядке. Каждый track имеет свой authoritative spec:

| Track | Order | Authoritative spec | Description |
|---|---|---|---|
| **A. CLI DX rework** | First | `cli-dx-task.md` §17 (12 items) | Target store, `apprafter target {add,list,use,...}`, `whoami`, `doctor`, `bootstrap-all` wrapper, miette errors, rename `platform-cli` → `apprafter`, aliases, color/NO_COLOR. **Prerequisite for Track B** потому что platform rethink relies on new CLI infrastructure (target resolution, bootstrap-all, manifest auto-discovery). |
| **B. Platform rethink** | Second | this file, sub-phases **1.66 — 1.83** (18 items, numbered below) | Argo CD as control surface, PlatformStack CRD + Controller, MigrationPlan unification, CUE → OCI chart distribution, CMP for user app CUE. Lands after Track A is complete. |
| **C. Dev-mode Phase 1B** | Third | `dev-mode-task.md` §20 Phase 1B | Minimum viable dev mode — `apprafter dev {cluster up, init, up, down, list, logs}` on local k3d. Lands after Track B closure (after `v0.2.0-self-managing` tag). |

**Why this order**:

- **Track A first**: bootstrap-all wrapper, target resolution, и miette errors are required for the minimal `cluster-bootstrap` rewrite (Track B 1.70) to provide acceptable UX. Без Track A, platform rethink landed бы на том же `cargo run --bin platform-cli` from-source workflow, который сейчас documented gap. Reverse order would create two sub-optimal user experiences during M1.5.
- **Track B second**: platform rethink uses CLI infrastructure from Track A. Once `cluster-bootstrap` rewritten и PlatformStack CRD in place, M1.5 closes with `v0.2.0-self-managing` tag.
- **Track C third**: dev-mode Phase 1B benefits from Track A CLI rework AND reuses Track B platform-stack chart's tier-1 overlay (with new `tiers/dev.cue` overlay). Lands after `v0.2.0-self-managing` as a follow-up patch series before M2 begins.

**Dependencies between tracks (sequential)**:
- Track A `target store` (`cli-dx-task.md` §5.1–5.6) → Track B `cluster-bootstrap` rewrite (1.70) requires target resolution instead of env vars.
- Track A `bootstrap-all` orchestrator (`cli-dx-task.md` §5.11) → Track B 1.70 — these should be one cohesive piece of work, landed within Track A.
- Track A `apprafter open` (referenced in Track B 1.79) → either land as part of Track A late items или Track B 1.79 — choose at implementation time when Track A is nearly done.
- Track C dev-mode Phase 1B references Application CRD operator (already shipped в Phase 1 v0.1.7-v0.1.65), benefits from Track A CLI rework, и reuses Track B's `tiers/dev.cue` overlay.

**M1.5 closure**: tag `v0.2.0-self-managing` after **both Track A and Track B** complete. Track C dev-mode Phase 1B lands as a follow-up patch series (e.g., `v0.2.1`, `v0.2.2` patch numbers depending on how it splits across commits). Phase 2B и Phase 3B из dev-mode-task.md лежат в later milestones (after M2 and M3 respectively).

**Total M1.5 aggregate**: Track A (12 small-medium items per `cli-dx-task.md` §17) + Track B (18 items, 1 L + 7 M + 8 S + 2 XS) ≈ **L+ overall**, with Track C following as a separate ~M-aggregate series. The heavy work concentrates in Track B 1.73 (PlatformController — the only L item with distributed-systems penalty applied); most other items are S or M.

---

## Фаза 1.5 / Track A — CLI DX rework (`cli-dx-task.md` §17)

> 12 sub-versions, one per `cli-dx-task.md` §17 row, landed as `v0.1.69`–`v0.1.80` patch releases. Each row owns a focused slice (feature + test + docs). Track B (sub-phases 1.66 onwards) **does not start** until Track A is closed — its `cluster-bootstrap` rewrite depends on the target store + `bootstrap-all` orchestrator + miette errors landed here.

### 1.66A.1 Rename `platform-cli` → `apprafter` + deprecation shim ✅

> v0.1.69 — sub-phase 1.66A.1 shipped: Cargo package + binary flipped to `apprafter`; legacy `platform-cli` survives as a deprecated shim that warns + forwards; user-facing docs swept.

**Source:** `cli-dx-task.md` §12 + §17 row 1.

**Цель:** перевести user-facing binary с легаси-имени `platform-cli` на каноничное `apprafter` без слома существующих скриптов. Foundation для всех остальных Track A под-фаз (target store, `bootstrap-all`, `doctor`, `whoami`), которые landятся последовательно в `v0.1.70`–`v0.1.80`.

**Поставка:**
- [x] `cli/platform-cli/Cargo.toml` — package переименован в `apprafter`; `[[bin]] name = "apprafter"` (path `src/main.rs`) — каноничная точка входа; второй `[[bin]] name = "platform-cli"` (path `src/bin/platform-cli.rs`) — shim, помеченный к удалению в `v0.2.0`.
- [x] `cli/platform-cli/src/bin/platform-cli.rs` — shim: печатает 3-строчный deprecation warning на stderr, потом `Command::new(apprafter)` + `.args(skip(1))` + forward exit code; cross-platform (`.exe` suffix на Windows).
- [x] `cli/platform-cli/src/cli.rs` — `#[command(name = "apprafter", ...)]` для clap-help; about-line обновлён.
- [x] `cli-core::logging::init` — дефолтный `EnvFilter` теперь `warn,apprafter=info,cli_core=info,cli_state=info,cli_providers=info`; без этого фикса INFO-логи фильтровались после переименования крейта (regression поймана `cli_smoke::tracing_logs_go_to_stderr_not_stdout`).
- [x] User-facing error hints (`run \`platform-cli init …\` first` и т.п.) в `commands/apply.rs`, `commands/argocd_password.rs`, `commands/cluster_bootstrap.rs`, `commands/import.rs`, `commands/kubeconfig.rs` теперь ссылаются на `apprafter`.
- [x] Internal docstrings + Cargo descriptions в `cli/cli-core`, `cli/cli-providers`, `cli/cli-state` обновлены — grep-discoverability осталась консистентной.
- [x] Все 4 integration-теста (`cli_smoke`, `argocd_password_test`, `import_test`, `kubeconfig_test`, `cluster_smoke_test`) переключены на `Command::cargo_bin("apprafter")`.
- [x] Новый regression-guard `cli_smoke::platform_cli_shim_warns_and_forwards` — пинит обе половины контракта shim'а (deprecation banner на stderr + forwarded `plan` output untouched на stdout + exit code).
- [x] User-visible docs sweep: `README.md`, `cli/README.md`, `e2e/{README.md,mvp.sh}`, `operator/{README.md,charts/apprafter-operator/README.md}`, `backstage-plugins/host/{README.md,scripts/scaffold.sh}`, `manifests/**/README.md`, `examples/templates/bun-http/**`, `schemas/v1alpha1/{infrastructure,infrastructureproviderplugin}.cue`, `docs/{architecture,dev-guide,operator-guide,reference}/**/*.md`, `.github/ISSUE_TEMPLATE/bug.yml`, `SECURITY.md`, `.gitignore` — все ссылаются на `apprafter`.
- [x] `spec.md` swept (kept `cli/platform-cli/` dir name in Appendix A repository tree with explicit comment that dir is renamed in `v0.2.x`).
- [x] `docs/changelog/history.md` — new `v0.1.69` block с Changed/Added/Docs/Backwards-compatibility секциями; historic v0.1.x entries сохранены as-is (no rewriting of past system state).

**Acceptance:**
- ✅ `cargo build --workspace` зелёный — обе bin entry (`apprafter` + `platform-cli`) компилируются.
- ✅ `cargo test --workspace` зелёный (61+ unit + 16 integration, включая новый shim-test).
- ✅ `cargo clippy --workspace --all-targets -- -D warnings` зелёный.
- ✅ `cargo fmt --all -- --check` зелёный.
- ✅ Manual walk (см. ниже) — `apprafter --help` работает, shim прячет deprecation warning на stderr + forwards exit code, существующие env-var-based workflows (`HCLOUD_TOKEN=… apprafter init …`) функционируют без изменений.

**Out-of-scope (отложено в следующие Track A слоты):**
- Persistent target store (`apprafter target {add,list,use,show,rename,remove}`) — Track A.2/A.3.
- Interactive wizard через `inquire` + miette-diagnostic errors — Track A.4.
- `apprafter doctor`, `apprafter whoami` — Track A.6/A.7.
- `apprafter bootstrap-all` orchestrator — Track A.9.
- `apprafter auth` stubs — Track A.6.
- Aliases (`apprafter t`), `--color` flag, `NO_COLOR` support — Track A.11.
- ADR `docs/adr/0014-cli-command-structure.md` — Track A.12 (после всей Track A landed).
- Переименование dir `cli/platform-cli/` → `cli/apprafter/` — отложено до `v0.2.0-self-managing` (M1.5 closure) одной cleanup-коммитой.

**Зависит от:** 1.65 (последняя закрытая Track-B-prerequisite).

**Размер:** S (один цикл, ~0.5 рабочего дня механического свипа + один новый файл shim + один regression-guard тест).

---

### 1.66A.2 Target file structure + IO module ✅

> v0.1.72 — sub-phase 1.66A.2 shipped: `cli-core::target` module — types (`GlobalConfig`, `TargetConfig`, `TargetCredentials`, `Target`, `TargetStorePaths`) + atomic load/save IO + 0600 enforcement on credentials. No CLI commands wired yet — pure foundation for A.3+ wizards.

**Source:** `cli-dx-task.md` §4 (file layout), §8 (deps), §17 row 2.

**Поставка:**
- [x] Новые workspace deps: `serde_yaml = "0.9"` + `dirs = "5"`; `tempfile` промотан из dev-dependencies cli-core в обычные (atomic-write использует его в prod-коде).
- [x] `cli-core/src/target.rs` (~570 строк):
    - `default_config_root()` → `dirs::config_dir().join("apprafter")` — cross-platform XDG.
    - `TargetStorePaths { root }` testable locator с методами `global_config_file`/`targets_dir`/`target_dir`/`target_config_file`/`target_credentials_file`/`auth_dir`/`auth_keep_file`/`state_dir` — миррорит spec §4 на тип-уровне.
    - `GlobalConfig { active_target, version }` с `TARGET_STORE_VERSION = 1` форвард-compat кодом.
    - `TargetConfig { provider, region, default_tier, cluster_name, ssh_key_path }` (`#[serde(default)]`).
    - `TargetCredentials { hetzner_token: Option<String> }` — **manual `Debug` impl** с `<redacted>` маркером (никогда не derive — лекит токен в любом `println!("{:?}", ...)`).
    - `load_global_config`/`save_global_config`/`load_target`/`save_target`/`list_target_names`/`remove_target`.
    - `atomic_write(path, bytes, secret)` — tempfile-in-same-dir + fsync + chmod (0600 для secret, 0644 для public) + `persist()` rename (POSIX-atomic, ReplaceFileW на Windows).
    - `ensure_auth_placeholder()` — создаёт `auth/.keep` на любом первом write, чтобы reserved namespace existed для будущего Managed.
- [x] `cli-core/src/error.rs`: новые варианты `InvalidTargetConfig { path, message }`, `TargetNotFound { name, available }`, `Yaml(serde_yaml::Error)` через `#[from]`.
- [x] `cli-core/src/lib.rs`: pub use re-export всех target-типов и функций; модуль `target` зарегистрирован.
- [x] 16 regression-guard unit-tests (inline в `target.rs`):
    - `default_config_root_points_at_user_config_dir_under_apprafter` — leaf path sanity guard.
    - `paths_compose_per_spec_directory_layout` — пин on-disk shape против spec §4 (если кто-то ренеймит `TARGETS_DIR` константу, тест отлетит).
    - `load_global_config_returns_none_on_fresh_store` — first-run case ОК.
    - `save_then_load_global_round_trips_active_target` — round-trip global.
    - `save_global_creates_auth_placeholder_directory` — auth/.keep всегда создаётся.
    - `load_global_config_returns_invalid_target_config_on_corrupt_yaml` — corrupt YAML → typed error.
    - `save_then_load_target_round_trips_both_halves` — round-trip per-target config + creds.
    - `load_target_returns_target_not_found_with_available_list` — error message включает comma-separated список существующих имён.
    - `load_target_tolerates_missing_credentials_file` — dotfiles-only сценарий (config есть, credentials нет — возвращает empty creds, не ошибку).
    - `credentials_file_lands_at_mode_0600` (Unix-only `#[cfg(unix)]`) — пин разрешений: credentials.yaml = 0600, config.yaml = 0644.
    - `list_target_names_returns_empty_on_fresh_store` + `list_target_names_returns_sorted_names_skipping_dot_dirs` — список target'ов сортирован, hidden dirs (`.scratch` от atomic-write tempfiles) скрыты.
    - `remove_target_deletes_both_files_and_state_dir` — удаление каскадно сносит `state/<name>/`.
    - `remove_target_returns_target_not_found_when_missing` — idempotency помощник.
    - `credentials_debug_redacts_token` — пинит `<redacted>` маркер в Debug формате (защита от случайного println).
    - `atomic_write_leaves_no_temp_files_on_success` — после успешного save в корне нет `.apprafter-tgt-*.tmp` файлов.

**Acceptance:**
- ✅ `cargo build --workspace` зелёный (новые `serde_yaml`, `dirs`, `tempfile` deps скомпилированы).
- ✅ `cargo test --workspace`: 26 cli-core тестов (16 новых target + 10 pre-existing), 0 failures across весь workspace.
- ✅ `cargo clippy --workspace --all-targets -- -D warnings` — clean.
- ✅ `cargo fmt --all -- --check` — clean.
- ✅ `scripts/check-spdx-headers.sh` (150 файлов) + `scripts/lint-cue.sh` — green.
- ✅ Module re-exports проверены: `use cli_core::{TargetStorePaths, GlobalConfig, Target, TargetConfig, TargetCredentials, save_target, load_target, list_target_names, remove_target}` компилируется в чистом downstream crate'е (semantics test through smoke tests in Track A.3).

**Out-of-scope (отложено в зависимые слоты):**
- Никаких CLI команд — `apprafter target add/list/use/...` приходят в Track A.3 (non-interactive) → A.4 (interactive wizard) → A.5 (CRUD-набор).
- Provider validator framework (`token format regex`, API ping) — Track A.4.
- Resolution chain plumbed в existing commands (`init/apply/cluster-bootstrap` берут токен из active target) — Track A.8.
- Migration существующего `<cwd>/.apprafter/state.json` в per-target `<root>/state/<name>/` — Track A.8.
- `secrecy::Secret<String>` wrapper для in-memory защиты — добавится в Track A.3/A.4 когда credentials handling попадает в hot path. Сейчас защита через manual Debug-redact + mode 0600 на файле.

**Зависит от:** 1.66A.1 ✅

**Размер:** S (один цикл, ~1 рабочий день кода + тестов).

---

### 1.66A.3 `apprafter target add` non-interactive ✅

> v0.1.73 — sub-phase 1.66A.3 shipped: clap subcommand `apprafter target add <name>` (+ alias `apprafter t add`) с pure flag-driven flow, валидация (name shape, provider whitelist, token format, ssh-key readable), `--force` / `--renew` семантика, первый target auto-promotes в active. Interactive wizard via `inquire` — отложен в A.4.

**Source:** `cli-dx-task.md` §5.1 (non-interactive flow), §10 (error patterns), §11 (validation rules), §17 row 3.

**Поставка:**
- [x] `cli/platform-cli/src/cli.rs` — новый `Commands::Target { action }` варинт + `TargetCommand::Add { name, provider, token, ssh_key, region, tier, cluster_name, force, renew, no_interactive }` enum-вариант. `#[command(alias = "t")]` на `Target` группе → `apprafter t add …` работает идентично `apprafter target add …`. `--token` читает `HCLOUD_TOKEN` env var через `#[arg(env)]`, `--ssh-key` — `APPRAFTER_SSH_PUBLIC_KEY_PATH`. `--force` и `--renew` помечены `conflicts_with` для clap-уровневого reject комбинации.
- [x] `cli/platform-cli/src/commands/target.rs` — handler-модуль:
    - `run(action) → match → run_add(args)`.
    - `validate_target_name(name)` — non-empty, ≤64 chars, `[A-Za-z0-9-]+`, без leading/trailing `-`.
    - `require_known_provider(opt)` — non-None + whitelist (`["hetzner-cloud"]` пока).
    - `require_token(provider, opt)` — non-None + per-provider format check. Для hetzner-cloud зовёт `cli_core::target::validate_hetzner_token_format`.
    - `verify_ssh_key_readable(path)` — `path.exists()` + `read_to_string` success.
    - `run_renew(paths, args)` — error если target отсутствует; refuses конфиг-флаги (только credentials); зовёт `save_target(existing.with(new creds))`.
    - `ensure_active_target(paths, name)` — `save_global_config({active_target: name})` только если `load_global_config` возвращает None (first-run case); subsequent saves не трогают active pointer.
- [x] `cli/platform-cli/src/main.rs` — `match args.command` (move) + dispatch `Commands::Target { action } => commands::target::run(action)?`. Существующие command::run сигнатуры (`&str` / `bool`) совместимы через `&owned` / Copy.
- [x] `cli-core::target` extensions:
    - `CONFIG_DIR_ENV = "APPRAFTER_CONFIG_DIR"` — env override для `default_config_root()` (testing ergonomics + power-user redirect). Используется verbatim, без `.join("apprafter")` суффикса.
    - `validate_hetzner_token_format(token)` — `^hcloud_[a-zA-Z0-9]{60,}$` без `regex` crate (string-методы достаточно для такой простой проверки). Возвращает `Result<(), String>` — caller-level wrap в `CliError::Other` с context'ом.
- [x] 17 integration-тестов (`tests/target_test.rs`):
    - happy path (`writes_config_and_credentials_and_promotes_first_target_to_active`) — пинит на-disk layout, active pointer, token landed.
    - mode 0600 (`credentials_file_is_mode_0600`, Unix-only).
    - env-var fallback (`uses_hcloud_token_env_var_as_fallback`) — clap `#[arg(env)]` works.
    - missing token (`errors_when_token_missing_entirely`).
    - unknown provider (`errors_on_unknown_provider`).
    - malformed token (`errors_on_malformed_hetzner_token`).
    - invalid name (`errors_on_invalid_target_name`).
    - no-force overwrite reject (`refuses_to_overwrite_existing_target_without_force`) — error message включает оба `--force` и `--renew` hint'а.
    - force overwrite (`force_overwrites_existing_target_and_keeps_active_pointer`) — active pointer **не** меняется на second-save.
    - renew rotate (`renew_rotates_credentials_without_touching_config`).
    - renew on missing (`renew_on_missing_target_errors_with_hint`).
    - renew refuses config flags (`renew_rejects_config_flags`).
    - clap-level conflict (`force_and_renew_are_mutually_exclusive`).
    - ssh-key path verified (`with_ssh_key_path_verifies_file_exists`).
    - ssh-key missing (`errors_when_ssh_key_path_missing`).
    - second save preserves active (`second_target_save_keeps_first_as_active_and_reports_so`).
    - alias `t` works (`target_alias_t_subcommand_resolves_to_target`).
- [x] 10 unit-тестов inline в `commands/target.rs` (pure validators): `validate_target_name` × 5 cases, `require_known_provider` × 2, `require_token` happy + bad, `verify_ssh_key_readable` × 2.
- [x] 6 unit-тестов в `cli_core::target` (валидатор + env override): `default_config_root_honours_apprafter_config_dir_env_override`, `_ignores_empty_env_override`, `validate_hetzner_token_format` × 4.

**Acceptance:**
- ✅ `apprafter target add default --provider hetzner-cloud --token hcloud_…` создаёт целый target + ставит active.
- ✅ Subsequent `target add another --provider … --token …` создаёт, **не** трогает active.
- ✅ `target add existing` без `--force` → error с hint'ом на оба `--force` и `--renew`.
- ✅ `target add existing --force` → overwrites; `target add existing --renew --token …` → только credentials, config preserved.
- ✅ `apprafter t add … ` — alias работает.
- ✅ `--force --renew` одновременно — clap reject (`conflicts_with`).
- ✅ Malformed token / unknown provider / invalid name — typed error на stderr.
- ✅ `cargo test --workspace`: 0 failures (17 new integration + 10 unit + 6 cli-core validator = +33 vs v0.1.72). fmt + clippy + SPDX (151 files) — clean.

**Out-of-scope (отложено):**
- Interactive wizard через `inquire` — Track A.4 (v0.1.74).
- `apprafter target list / use / show / rename / remove` — Track A.5.
- `apprafter target add` real API ping (`GET /v1/locations` against Hetzner) — Track A.4 validator framework.
- `apprafter whoami` aggregator (показать active target + provider verified status) — Track A.6.
- Resolution chain в существующие `init / apply / cluster-bootstrap` — Track A.8.

**Зависит от:** 1.66A.2 ✅ (target store IO).

**Размер:** S (один цикл, ~1 рабочий день).

---

### 1.66A.4 Provider validator framework + Hetzner API ping ✅

> v0.1.75 — sub-phase 1.66A.4 (split as A.4a) shipped: `cli-providers::validators` module с `ProviderValidator` trait + `HetznerCloudValidator` (`GET /v1/locations`); `target add` теперь делает real API ping по умолчанию + flag `--no-ping` / env `APPRAFTER_NO_PING` для CI/offline. Interactive wizard через `inquire` — отложен в **1.66A.4b** (v0.1.76).

**Source:** `cli-dx-task.md` §5.1 (token verified step) + §11 (validation framework), §17 row 4.

**Поставка:**
- [x] `cli/cli-providers/src/hetzner_cloud/types.rs` — новые wire-types `Location { id, name, description, country, city, network_zone }` + `LocationListResponse`. Re-exported через crate root.
- [x] `cli/cli-providers/src/hetzner_cloud/client.rs::list_locations()` — `GET /v1/locations` с тем же error-mapping шаблоном как остальные list_X методы (на 2xx parse, на 4xx/5xx → `CliError::Hetzner`, на transport-fail → `CliError::Other`). Reused validator-ом и (будущим в A.4b) wizard-region-picker'ом.
- [x] `cli/cli-providers/src/validators.rs` — новый модуль:
    - `pub trait ProviderValidator { fn validate_credentials(&self) -> Result<()>; }` — минимальная поверхность (region/type lookups придут с wizard'ом в A.4b).
    - `pub struct HetznerCloudValidator { client: HetznerCloudClient }` + `new(base_url, token)` + impl `ProviderValidator` через `self.client.list_locations().map(|_| ())`.
    - 3 unit-теста с mockito: 200 OK (валид) / 401 → typed `CliError::Hetzner` / closed-port → `CliError::Other` transport.
- [x] `cli-providers::lib.rs` — re-export `HetznerCloudValidator` + `ProviderValidator`.
- [x] `cli/platform-cli/src/cli.rs::TargetCommand::Add` — новый флаг `--no-ping` с env-binding `APPRAFTER_NO_PING` через `BoolishValueParser` (принимает `1/0/yes/no/true/false/on/off` — не только canonical `true`/`false`, чтобы shell-сcripty `APPRAFTER_NO_PING=1 apprafter target add ...` работал).
- [x] `cli/platform-cli/src/commands/target.rs::ping_provider(provider, token)` — orchestrator: знает per-provider маршруты, для hetzner-cloud зовёт `HetznerCloudValidator::new(hcloud_base_url(), token).validate_credentials()`. Error-mapping расширен с human-readable hint'ами:
    - 401 → "Hetzner Cloud rejected the token (HTTP 401)..."
    - non-401 HTTP error → "Hetzner Cloud API ping failed (HTTP {status})..." + reassurance что target NOT saved.
    - transport-fail → "could not reach Hetzner Cloud at {base}..." + `--no-ping` hint.
- [x] `run_add` теперь делает ping после format/ssh-key checks но ДО save (так, чтобы failed ping не оставлял half-state на диске). `run_renew` — analogous, ping после `require_token`.
- [x] Success-message в `target add` теперь упоминает статус: `... (token verified against Hetzner Cloud)` или `... (token NOT verified — \`--no-ping\` was passed)`. Closes the cli-dx-task.md §5.1 "✓ Token verified" UX promise on the non-interactive flow (interactive wizard will reuse the same string in A.4b).
- [x] 5 новых integration-тестов (`tests/target_test.rs`):
    - `target_add_pings_provider_by_default_and_announces_verified_status` — mockito 200, target saved + UI says "verified". `mockito::Mock::expect(1)` пинит, что ping реально был сделан.
    - `target_add_surfaces_typed_error_on_hetzner_401` — mockito 401 + assertion что target dir на диске **не** создан (нет half-state).
    - `target_add_surfaces_helpful_error_when_api_is_unreachable` — closed port 1 → error message содержит либо "could not reach" либо "API ping failed" (зависит от платформы) + `--no-ping` hint.
    - `target_add_no_ping_flag_skips_validator_and_announces_unverified` — `--no-ping` короткозамыкает на нereachable base URL.
    - `target_add_no_ping_env_var_also_skips_validator` — `APPRAFTER_NO_PING=1` равноценен флагу.
- [x] 17 prior integration-тестов получили `APPRAFTER_NO_PING=1` через sed-инжект (focus тех тестов — file IO / clap parsing, не API; новые ping-тесты эту поверхность покрывают отдельно).

**Acceptance:**
- ✅ `apprafter target add <name> --token <valid>` ходит в Hetzner, success-message содержит "(token verified against Hetzner Cloud)".
- ✅ С невалидным токеном — typed error "(HTTP 401)" + target **не** сохранён.
- ✅ С недоступным API — typed error + `--no-ping` hint.
- ✅ `--no-ping` / `APPRAFTER_NO_PING=1` — short-circuit, success-message "(token NOT verified)".
- ✅ Existing env-var-based `apply` / `cluster-bootstrap` flow не затронут — ping живёт только в `target add`.
- ✅ `cargo test --workspace`: 22 target_test (17 prior +5 new) + 118 cli-providers (115 +3 validator) — 0 failures. fmt + clippy + SPDX (153 files) — clean.

**Out-of-scope (отложено):**
- Interactive wizard через `inquire` — Track 1.66A.4b (v0.1.76).
- Region validator + region-picker (использует уже готовый `list_locations`) — пойдёт в A.4b вместе с wizard'ом.
- `secrecy::Secret<String>` обёртка для in-memory tokens — A.10/A.11 (miette + secret hardening pass).
- Resolution chain в operational `init/apply/cluster-bootstrap` — A.8.

**Зависит от:** 1.66A.3 ✅ (target add non-interactive).

**Размер:** S (один цикл, ~1 рабочий день).

---

### 1.66A.4b Interactive wizard via `inquire` ✅

> v0.1.76 — sub-phase 1.66A.4b shipped: `commands::target_wizard` модуль с `inquire`-based prompts (Text/Password/Select), default-when-TTY поведение, inline validation внутри token prompt'а (format + API ping), region-picker через `list_regions()`. `--no-interactive` отключает wizard явно; CRUD команды (`list/use/show/...`) и `whoami`/`doctor`/`bootstrap-all` — следующие итерации.

**Source:** `cli-dx-task.md` §5.1 (interactive flow) + §9 (TTY detection) + §17 row 4.

**Поставка:**
- [x] Workspace dep `inquire = "0.7"`; `dirs` поднят в platform-cli (использует для `~/.ssh/id_ed25519.pub` default'а и tilde expansion в SSH-key prompt).
- [x] `cli-providers::validators::ProviderValidator` расширен `fn list_regions() -> Result<Vec<RegionInfo>>`. `RegionInfo { name, description }` с `Display` impl `<name> — <description>` для удобного scanning в `Select`. `HetznerCloudValidator::list_regions()` мапит `client.list_locations()` → отсортированный по `name` Vec. +2 mockito-тестa (sorted output + Display fallback на empty description).
- [x] `cli/platform-cli/src/cli.rs`: positional `name` теперь `Option<String>` — wizard может его спросить; ошибка surface'ится после wizard'а если name всё ещё None (non-TTY/`--no-interactive` сценарий).
- [x] `commands/target.rs::check_target_name(&str) -> Result<(), String>` — pure helper экспортирован для wizard'а (validation сообщения консистентны между CLI surface и `inquire::Validation::Invalid`). `validate_target_name` остаётся как CliError-обёртка.
- [x] `commands/target_wizard.rs` — новый модуль:
    - `should_use_wizard(no_interactive, stdin_tty, stdout_tty, all_required_present)` — pure decision, testable. Wizard fires только когда **обе** consoli TTYs И `--no-interactive` не передан И хотя бы один required input отсутствует. Если все флаги supplied — non-interactive path даже на TTY (respect explicit intent).
    - `run_add_wizard(initial: &AddArgs) -> Result<WizardOutput>` — последовательность из 6 prompts по spec §5.1:
        1. **Target name** — `Text` с default `default`, валидатор вызывает `check_target_name`.
        2. **Provider** — `Select` (сейчас одна опция `hetzner-cloud`, оставлен Select-shape для forward-compat).
        3. **Provider token** — `Password` с `PasswordDisplayMode::Masked`. Inline-валидатор сначала проверяет формат, потом, если не `--no-ping`, делает API ping через `HetznerCloudValidator::validate_credentials()`. Failure → `Validation::Invalid("…")` → инквайр перепросит. Success → eprintln `✓ Token verified`.
        4. **SSH public key path** — `Text` с default `<home>/.ssh/id_ed25519.pub` (через `dirs::home_dir`); пустая строка = "skip". Tilde expansion `~/...` через `expand_tilde` helper.
        5. **Default region** — `Select` из `validator.list_regions()` (когда token verified). При `--no-ping` fallback на `Text` с default `nbg1` (нет API → нет picker'а).
        6. **Default tier** — `Select` по spec choices: `solo / team / prod / regulated` с `Display` impl `<key> — <human label>`.
    - `run_renew_wizard(provider, no_ping)` — упрощённый prompt только токена (config preserved).
    - Все prompts мапят `InquireError::OperationCanceled/Interrupted` → `CliError::Other("wizard aborted by user")` (Ctrl-C / Esc не дают backtrace).
- [x] `commands/target.rs::run_add`:
    - Сначала evaluate `should_use_wizard(...)`, если true — `run_wizard_into_args(&mut args)` заполняет missing поля.
    - После wizard'а (или без него) `name` обязан быть `Some`; иначе typed error "target name required — pass it as a positional argument ... or run on a TTY".
    - `--renew` wizard ветвится отдельно: если name отсутствует — спрашиваем сначала name (Text + `check_target_name`), потом загружаем existing target для определения provider'а, потом `run_renew_wizard` для нового токена.
    - Save-time ping остаётся (re-verifies даже когда wizard уже ping'нул — cheap ~200ms, save-time check — authoritative).
- [x] 5 unit-тестов inline в `target_wizard.rs` (pure helpers): `should_use_wizard` (4 ветки), `expand_tilde` (3 cases: `~/`, abs path, `~user/` not expanded), `inline_ping_error` (401 vs 5xx сообщения), `validate_for_provider` (good/bad/unknown), `TierChoice` Display.

**Acceptance:**
- ✅ `apprafter target add` на TTY → wizard просит все поля по порядку, inline-показывает `✓ Token verified` после успешного ping'а.
- ✅ `apprafter target add work --provider hetzner-cloud --token <X>` на TTY → wizard НЕ fires (все required supplied), сразу не-interactive path.
- ✅ `apprafter target add work --no-interactive` без token'а → typed error "is required" (TTY не помогает когда явно non-interactive).
- ✅ Pipe / CI → no TTY → wizard skipped, как раньше.
- ✅ Esc / Ctrl-C во время wizard'а → "wizard aborted by user" (без backtrace, exit-code 1).
- ✅ `cargo test --workspace`: 22 target_test (без изменений) + 5 target_wizard unit + 64 cli-core + 120 cli-providers (+2 list_regions) — 0 failures.
- ✅ fmt + clippy + SPDX (154 files) + CUE — clean.

**Out-of-scope (явно отложено):**
- E2E wizard testing с PTY-harness — overkill для текущего MVP; manual walks покрывают prompt UX.
- "✓ Token verified (account: …, project: …)" detail per `cli-dx-task.md` §5.1 — Hetzner `/v1/locations` не возвращает account info, нужен `/v1/me`-style endpoint (Hetzner такого не имеет). Текущий "✓ Token verified" — достаточный signal.
- `apprafter target list / use / show / rename / remove` — Track 1.66A.5.
- `secrecy::Secret<String>` обёртка для tokens in-memory — A.10/A.11 hardening pass.

**Зависит от:** 1.66A.4a ✅ (validator framework + API ping).

**Размер:** M (один цикл, ~1.5 рабочих дня).

---

### 1.66A.5 Target CRUD — `list / use / show / rename / remove` ✅

> v0.1.79 — sub-phase 1.66A.5 shipped: 5 новых subcommand'ов поверх target store (`tabled`-based table в `list`, kubectl-style `use/show`, `rename` с FS move + active-pointer обновлением, `remove` с `--yes` opt-in или interactive confirm). v0.1.77 + v0.1.78 wizard polish — затрагивает только `target add`; CRUD-набор полностью отдельный.

**Source:** `cli-dx-task.md` §5.2–§5.6 + §6 (aliases) + §17 row 5.

**Поставка:**
- [x] Workspace dep `tabled = "0.15"` (для `target list` рендера); promoted в platform-cli как direct dep.
- [x] `cli_core::target::rename_target(paths, from, to)` — атомарный `fs::rename` target-директории + best-effort move per-target state cache (`state/<from>/`). Refuses на missing-source (`CliError::TargetNotFound`) и existing-destination (`CliError::Other`). Re-exported через crate root. 4 unit-теста: happy path с state cache + missing source + dest collision + no-state-cache path.
- [x] `cli/platform-cli/src/cli.rs`: новые `TargetCommand::{List, Use, Show, Rename, Remove}` варианты per spec §5.2–5.6. `Remove` имеет `--yes` flag.
- [x] `cli/platform-cli/src/commands/target.rs`:
    - **`run_list`** — собирает rows через `list_target_names` + `load_target` per name (skip-with-tracing-warn на unreadable, не валит вся листинг). Tabled-derive struct `TargetListRow { active, name, provider, region, tier }` с `Style::sharp()` (чистая ASCII-таблица). Empty store → onboarding hint "apprafter target add". Trailing summary `N targets configured. Active: '<name>'.`.
    - **`run_use(name)`** — validates target exists (через `load_target`), updates `GlobalConfig.active_target` через `save_global_config`. Polite no-op message если уже active.
    - **`run_show(name)`** — `name` Optional, default → active. Если no-active + no-name → typed error с hint'ом. Печатает Provider/Region/Default tier/Cluster name/SSH key/Hetzner token (через `token_summary(opt)` который выдаёт `"set (N chars; read credentials.yaml for the raw value)"` или `"not set"` — НЕ echo'ит токен). Trailing — на-диске пути config.yaml + credentials.yaml (mode 0600).
    - **`run_rename(from, to)`** — validates `to` через `check_target_name`, refuses identical from==to, вызывает `cli_core::target::rename_target`, потом если `active_target == from` — обновляет global config на `to`.
    - **`run_remove(name, yes)`** — `load_target` для existence + canonical TargetNotFound hint. Если `!yes`: на TTY показывает `inquire::Confirm` (default `false`), на non-TTY refuses ("non-interactive invocation: pass `--yes` to confirm ..."). После `remove_target`: если был active — pointer ре-assigned на alphabetically next remaining target; если targets закончились — `config.yaml` deleted (фреш-сторе-поведение возвращается).
- [x] `token_summary` pure helper + unit-тест: НЕ leak'ит byte'ы токена даже частично.

**Тесты (16 новых integration в `target_test.rs` + 4 cli-core unit + 1 platform-cli unit = 21 total):**
- `target_list_on_empty_store_prints_onboarding_hint`
- `target_list_renders_table_with_active_marker_and_columns`
- `target_use_switches_active_pointer_and_reports_the_swap`
- `target_use_on_already_active_is_a_polite_noop`
- `target_use_on_missing_target_surfaces_available_hint`
- `target_show_with_no_args_renders_active_target_with_masked_token` (пинит что token НЕ появляется в output)
- `target_show_with_explicit_name_renders_named_target_without_active_marker`
- `target_show_on_empty_store_errors_with_onboarding_hint`
- `target_rename_moves_files_and_updates_active_pointer`
- `target_rename_non_active_target_leaves_active_pointer_alone`
- `target_rename_refuses_when_destination_exists`
- `target_rename_rejects_invalid_destination_name`
- `target_rename_refuses_identical_source_and_destination`
- `target_remove_with_yes_flag_deletes_and_reassigns_active_alphabetically`
- `target_remove_last_target_clears_active_pointer`
- `target_remove_non_active_target_keeps_active_pointer_intact`
- `target_remove_non_interactive_without_yes_refuses`
- `target_remove_on_missing_target_surfaces_available_hint`
- + `token_summary` unit
- + 4 `rename_target` cli-core unit-тестов

**Acceptance:**
- ✅ `apprafter target list` рисует таблицу с `*` маркером на active, или onboarding hint на empty store.
- ✅ `apprafter target use <name>` свитчит active; missing → friendly error c available-listом.
- ✅ `apprafter target show [name]` показывает details; токен замаскирован как `set (N chars; ...)` без leak'а.
- ✅ `apprafter target rename <from> <to>` атомарен (либо обе директории на месте при collision, либо ровно одна после успеха), active-pointer follows automatically.
- ✅ `apprafter target remove <name>` требует `--yes` на non-TTY, prompt'ит на TTY; удаление active → reassign alphabetically.
- ✅ `apprafter t list/use/show/rename/remove` alias works (через существующий `#[command(alias = "t")]` на `Target`).
- ✅ `cargo test --workspace`: 36 target_test (16 новых CRUD + 20 prior) + 74 cli-core (+4 rename) — 0 failures. fmt + clippy + SPDX (155 files) — clean.

**Out-of-scope (отложено):**
- "Last used" / "Account" / "Cluster status" колонки в `list` + `show` — нужна telemetry-wire-up через A.8 (operational commands записывают `last_used_at`) и/или Hetzner `/v1/account`-style endpoint которого у Hetzner нет публично.
- ADR `docs/adr/0014-cli-command-structure.md` про resource-first grouping + auth namespace — Track A.12 (docs+ADR final pass).
- `apprafter whoami` / `apprafter auth …` (stub) — Track A.6.

**Зависит от:** 1.66A.4b ✅ (wizard) — используем тот же target store API.

**Размер:** M (один цикл, ~1 рабочий день кода + tests).

---

### 1.66A.6 `apprafter whoami` + `auth` stubs ✅

> v0.1.80 — sub-phase 1.66A.6 shipped: top-level `apprafter whoami` (identity + active target + verified status) + hidden `apprafter auth login/logout/status` stubs (per spec §3.1 reserved namespace для Managed AppRafter Cloud).

**Source:** `cli-dx-task.md` §5.7 (auth stubs) + §5.8 (whoami) + §3.1 (two-layer identity/target model) + §17 row 6.

**Поставка:**
- [x] `apprafter whoami` — новая top-level команда с одним флагом `--no-ping` (+ env `APPRAFTER_NO_PING` через `BoolishValueParser`). Рендер:
    - `Identity:     anonymous (self-hosted mode)` — placeholder до Track A.10+ когда Managed Cloud auth wires in.
    - `Target:       <name> (active)` или onboarding hint на empty store.
    - `Provider:     hetzner-cloud (<verification status>)` — статус: `verified ✓` / `verified ✓` skipped (если `--no-ping`) / `verification failed ✗ — token rejected (HTTP 401). Run \`apprafter target add <name> --renew\` ...` / `... HTTP <N> from provider API` / `... provider unreachable (network?)`. **Failed ping НЕ валит whoami** — операторы на flaky network'е получают остальную инфо.
    - `Region:`, `Default tier:`, `Cluster name:`, `SSH key:` (с маркером `(loaded)` если файл существует, `(missing!)` если path в config'е есть но файла нет на диске, `not set` если не задан). `~/...` tilde-abbreviation через локальный `abbreviate_home` (3 строки, без cross-module surface).
- [x] `apprafter auth login/logout/status` — три hidden stub'а per spec §5.7. `Commands::Auth` помечен `#[command(hide = true)]` → не появляется в `apprafter --help` (не загромождает new-user discovery surface). Под-команды реальны (`apprafter auth --help` работает): `login` и `logout` печатают friendly redirect "AppRafter Cloud is not yet available... apprafter target add"; `status` — "self-hosted mode active. Use `apprafter whoami`...". Все три имеют ссылку на `https://apprafter.dev`. `AuthCommand` enum — реальный Subcommand (не stub-string), чтобы future Managed impl заполнял ветки без CLI surface re-shape.
- [x] `cli/platform-cli/src/commands/whoami.rs` (~150 LOC + 5 unit-тестов): pure `verified_status(target, no_ping)` + `ssh_key_status(opt)` + `abbreviate_home(p)` helpers; orchestrator `run(no_ping)`. Best-effort ping → не валит whoami.
- [x] `cli/platform-cli/src/commands/auth.rs` (~60 LOC): три `run_X` функции через shared `print_redirect` helper.
- [x] `cli/platform-cli/src/cli.rs`: `Commands::Whoami { no_ping }` + `Commands::Auth { #[command(hide = true)] action: AuthCommand }` + `AuthCommand { Login, Logout, Status }`.
- [x] `cli/platform-cli/src/main.rs`: dispatch обеих новых веток.

**Тесты:** 10 integration в `whoami_auth_test.rs` + 5 unit в `whoami.rs`:
- `whoami_on_empty_store_prints_onboarding_hint`
- `whoami_with_active_target_renders_summary_and_honours_no_ping` — пинит что синтетический токен **никогда** не появляется в stdout (regression-guard на leak).
- `whoami_with_real_ping_reports_verified_on_mockito_200`
- `whoami_with_real_ping_reports_failure_hint_on_mockito_401` — проверяет что 401 не валит exit code + содержит `--renew` hint.
- `whoami_with_real_ping_reports_failure_when_provider_unreachable` — closed-port path.
- `auth_login_prints_friendly_redirect_to_target_add`
- `auth_logout_prints_friendly_redirect_with_nothing_to_logout_phrasing`
- `auth_status_explains_self_hosted_mode_and_points_at_whoami`
- `auth_group_is_hidden_from_top_level_help` — `apprafter --help` НЕ содержит `auth`.
- `auth_subcommand_help_is_still_reachable` — `apprafter auth --help` работает (hide ≠ delete).
- 5 unit: `verified_status` × 2 (no_ping + no_token), `ssh_key_status` × 3 (loaded / missing / not-set).

**Acceptance:**
- ✅ `apprafter whoami` на TTY/CI без active target → onboarding hint + Identity-line.
- ✅ С active target — рендер всех полей + verified status (или skip с `--no-ping`).
- ✅ Token никогда не leak'ится в stdout.
- ✅ `apprafter auth login/logout/status` печатают friendly redirect + Managed-roadmap URL.
- ✅ `apprafter --help` не показывает `auth`; `apprafter auth --help` показывает все три subcommand'а.
- ✅ `cargo test --workspace`: 36 (target_test без изменений) + 10 (whoami_auth_test новый) + 120 (cli-providers без изменений) — 0 failures. fmt + clippy + SPDX (155 files) — clean.

**Out-of-scope (отложено):**
- "Account" / "Last used" / "Cluster: provisioned/not" в whoami — нужны (a) Hetzner endpoint которого нет публично, (b) per-target state cache wire-up через A.8, (c) telemetry on operational commands. Закроется когда A.8 land'нет state-per-target.
- Real AppRafter Cloud auth — Managed offering, далеко за пределами M1.5.
- ADR `docs/adr/0014-cli-command-structure.md` про резервирование `auth` namespace + resource-first grouping — Track A.12 (final docs+ADR pass).

**Зависит от:** 1.66A.5 ✅ (target store + load_target).

**Размер:** S (один цикл, ~0.5 рабочего дня).

---

### 1.66A.7 `apprafter doctor` ✅

> v0.1.81 — sub-phase 1.66A.7 shipped: self-diagnostic команда (target checks + env checks + DNS probe; trichotomy PASS/WARN/FAIL; FAIL → exit 1 для CI gates).

**Source:** `cli-dx-task.md` §5.9 + §17 row 7.

**Поставка:**
- [x] `apprafter doctor [--target <name>] [--no-ping]` — новая top-level команда.
- [x] `cli/platform-cli/src/commands/doctor.rs` (~520 LOC + 11 unit-тестов): pure `Check { name, status, detail, hint }` + `DoctorReport { target_name, target_checks, env_checks }` data layer, отдельные `build_target_checks` / `build_env_checks` / `print_report` функции; orchestrator `run` зовёт всё + exit-1 на FAIL.
- [x] **Target checks** (когда target resolved):
    - `Config file readable` — через `load_target`; on `TargetNotFound` сразу FAIL с available-hint'ом.
    - `Credentials file present (mode 0600)` — на Unix проверяет permissions, WARN если drift'нул от 0600; на других OS просто existence-check.
    - `Provider \`X\` supported` — whitelist (`hetzner-cloud`).
    - `Token format valid` — `validate_hetzner_token_format`; FAIL с `--renew` hint'ом если сломан.
    - `Token verified against provider API` — `HetznerCloudValidator::validate_credentials()` с timing (`{ms} ms`); WARN если `--no-ping` / нет токена; FAIL с разделением 401 (token rejected → `--renew` hint) / non-401 HTTP / transport.
    - `SSH key readable` — exists + read_to_string + parse algo из OpenSSH-первой строки; FAIL если path в config'е есть но файла нет на диске (stale config); WARN если path не задан.
- [x] **Env checks** (всегда):
    - `\`kubectl\` on PATH` / `\`helm\` on PATH` / `\`ssh\` on PATH` — `Command::new(tool).args(...).output()`, PASS с первой непустой строкой (stdout ИЛИ stderr — `ssh -V` пишет в stderr), WARN с hint'ом если binary не найден. Лояльно — отсутствие optional-tool не валит doctor.
    - `DNS resolves \`api.hetzner.cloud\`` — `ToSocketAddrs::to_socket_addrs("host:443")`; PASS с `443/tcp` detail или FAIL с resolver-error hint'ом.
- [x] **Rendering**: `  ✓ name (detail)` / `  ⚠ name (detail)` / `  ✗ name (detail)` + `      hint: <hint>` на отдельной indented строке. Trailing summary с разными формулировками для clean / warning-only / FAIL'ed runs.
- [x] **Exit policy**: FAIL anywhere → `std::process::exit(1)`; WARN-only → exit 0 + "Ready to go; review warnings".

**Тесты (17 новых):**
- 11 unit в `commands::doctor::tests`:
    - `check_status_glyph_renders_distinctly`
    - `report_counters_split_by_status`
    - `report_has_failures_returns_false_when_only_warns`
    - `check_dns_resolves_localhost_passes` (RFC reserved 127.0.0.1)
    - `check_dns_resolves_invalid_tld_fails` (RFC 6761 `.invalid`)
    - `check_tool_warns_on_missing_binary` (no `apprafter-doctor-no-such-binary` on $PATH)
    - `check_provider_known_fails_for_unknown_provider` / `_passes_for_hetzner`
    - `check_token_format_passes_canonical_token` / `_fails_on_missing_token`
    - `check_token_ping_warns_when_no_ping_flag_set`
- 6 integration в `tests/doctor_test.rs`:
    - `doctor_on_empty_store_errors_with_onboarding_hint`
    - `doctor_renders_target_and_env_checks_with_summary` (Target/Env разделы, --no-ping → WARN на ping, summary mentions target name)
    - `doctor_target_flag_inspects_non_active_target` (`--target secondary`)
    - `doctor_ssh_key_missing_path_fails_the_run_with_exit_1` (configure ssh-key path → удалить файл → FAIL + exit 1)
    - `doctor_target_not_found_fails_with_available_hint` (`--target ghost`)
    - `doctor_summary_line_phrases_outcomes_clearly` (warning-only run → "warning(s)", no FAIL в выводе)

**Acceptance:**
- ✅ `apprafter doctor` на empty store → typed error + onboarding hint.
- ✅ С active target — все 10 (~6 target + ~4 env) checks отрисованы; summary с count'ом PASS/WARN/FAIL.
- ✅ `--target <name>` инспектирует non-active target.
- ✅ `--no-ping` → token-ping check как WARN с "skipped — --no-ping".
- ✅ Любая FAIL → exit 1 (для CI gates).
- ✅ Никаких token leaks в output.
- ✅ `cargo test --workspace`: 36 target_test + 10 whoami_auth_test + 6 doctor_test + 120 cli-providers + ... — 0 failures.
- ✅ fmt + clippy (-D warnings) + SPDX (158 files) clean.

**Out-of-scope (отложено):**
- "Region in known list" check — нужен hardcoded list (brittle) или API call (уже есть в ping). Implicit: если ping проходит с этим region'ом, он валиден.
- "No active cluster" check — нужен cli-state cross-ref per target. Track A.8.
- Color output для PASS/WARN/FAIL — Track A.11 (color/NO_COLOR).
- miette-стиль diagnostics — Track A.10.

**Зависит от:** 1.66A.4a ✅ (validator), 1.66A.5 ✅ (CRUD load_target).

**Размер:** M (один цикл, ~1 рабочий день).

---

### 1.66A.8 Wire `apply` / `destroy` / `import` в target resolution ✅

> v0.1.82 — sub-phase 1.66A.8 shipped: credential resolution chain (`--flag > env > target store`) реально подключена к operational commands. После v0.1.82 — `apprafter target use prod && apprafter apply` без `HCLOUD_TOKEN=...` действительно работает.

**Source:** `cli-dx-task.md` §5.10 + §7 + §17 row 8.

**Поставка:**
- [x] `cli/cli-core/src/credentials.rs` — новый модуль:
    - `resolve_hetzner_token(cli_flag, paths, target_override) -> Result<String>` — implements 3-step chain. cli_flag (highest) > `HCLOUD_TOKEN` env > active target's credentials.yaml (или `--target <name>` override).
    - `resolve_hetzner_ssh_public_key(paths, target_override) -> Result<Option<String>>` — analogous chain для SSH public key BODY. Env `APPRAFTER_SSH_PUBLIC_KEY` > target store path → read file.
    - `read_ssh_public_key_body(path)` pure helper.
    - Constants `HCLOUD_TOKEN_ENV` / `SSH_PUBLIC_KEY_ENV` для shared use.
    - Error messages enumerate **все 3** пути (flag / env / `apprafter target add`) чтобы оператор сразу видел альтернативы.
- [x] cli-core re-export через `pub use credentials::*`.
- [x] `cli_core::TEST_ENV_MUTEX: pub(crate) static Mutex<()>` в `lib.rs` (cfg(test)-gated) — serialises env-touching unit tests across modules (target.rs + credentials.rs обе flip'ают HCLOUD_TOKEN / CONFIG_DIR_ENV, race без shared mutex).
- [x] `commands/apply.rs::run(target_override: Option<&str>)` — заменил direct `env::var("HCLOUD_TOKEN")` на `resolve_hetzner_token(None, &target_store, target_override)`. `build_ssh_specs` теперь thread'ит target_store + target_override и вызывает `resolve_hetzner_ssh_public_key`; manifest `sshKeys` block по-прежнему wins (highest precedence на той ветке).
- [x] `commands/destroy.rs::run(yes, target_override)` — analogous wiring. Empty-state early-exit моложе credential resolution чтобы `destroy --yes` в no-Hetzner-state директории не падал на missing-creds.
- [x] `commands/import.rs::run(force, dry_run, target_override)` — analogous.
- [x] `cli.rs` — новый `--target <name>` flag на `Apply` / `Destroy` / `Import`.
- [x] `main.rs` dispatch обновлён.

**Тесты (16 новых cli-core unit + 1 integration smoke):**
- 16 в `cli_core::credentials::tests`:
    - CLI flag wins over env + store
    - env wins over store when no flag
    - store fallback when flag + env absent
    - `--target <name>` override picks named target not active
    - error with 3-paths hint when nothing configured
    - error when target exists but no token stored
    - error with override for missing target surfaces "available" hint
    - SSH key env wins over target path
    - SSH key reads target path when env absent (with trim)
    - SSH key returns None when nothing configured
    - SSH key errors loudly on unreadable path
- 1 в `tests/cli_smoke.rs` integration:
    - `apply_target_flag_routes_resolution_at_named_target_and_surfaces_not_found` — seed target store с `real`, run `apply --target ghost` → typed error содержит `ghost`, `not found`, `real` (available hint).
- 3 prior `apply_without_token_*` / `import_without_token_*` integration тесты обновлены: добавлен `APPRAFTER_CONFIG_DIR=<tempdir>` для изоляции от user's real `~/.config/apprafter/`; assertions enumerate новые "3-paths" error message tokens (`--token`, `HCLOUD_TOKEN`, `apprafter target add`).

**Acceptance:**
- ✅ `apprafter apply` без `HCLOUD_TOKEN` env читает токен из active target — главная цель Track A.
- ✅ `--target <name>` override per-invocation, без switching active.
- ✅ Existing CI scripts (`HCLOUD_TOKEN=... apprafter apply`) работают без изменений — backwards-compat preserved (env остаётся step 2 в chain).
- ✅ Empty-store + no env + no flag → typed error с **всеми 3** путями выхода в сообщении.
- ✅ Stale `--target <name>` → "did you mean..." hint via canonical TargetNotFound.
- ✅ `cargo test --workspace`: 90 cli-core (+16 credentials) + 47 cli_smoke (+1 new integration, 3 prior updated) + 42 target_test + 10 whoami_auth_test + 6 doctor_test + ... — 0 failures.
- ✅ fmt + clippy (-D warnings) + SPDX (160 files) clean.

**Out-of-scope (отложено):**
- `--token <X>` flag на `apply`/`destroy`/`import` (secrets в shell history — wait until A.10 miette pass решает UX).
- Migration `<cwd>/.apprafter/state.json` → per-target `state/<name>/state.json` — отдельная iteration после bootstrap-all.
- `kubeconfig` / `argocd-password` / `cluster-bootstrap` — не используют HCLOUD_TOKEN напрямую (работают на kubeconfig); скип.
- `init` — не нужны creds (stub-like, write state.json only).

**Зависит от:** 1.66A.5 ✅ (target store CRUD).

**Размер:** M (один цикл, ~1.5 рабочих дня).

---

### 1.66A.9 `apprafter bootstrap-all` orchestrator ✅

> v0.1.84 — initial landing: 3-phase wrapper `apply` → kubeconfig-poll → `cluster-bootstrap` под единым `indicatif::MultiProgress` UX, `--dry-run` со списком subcommand-команд.
> v0.1.85 — hotfix UX после ручного walk'а v0.1.84: `MultiProgress` рендерил finished spinner'ы поверх каждого helm/kubectl `println` (10+ дублированных строк); spinner Phase 1/3 fought с tracing-логами apply/cluster-bootstrap за тот же row; dry-run печатал `<active target>` placeholder вместо реального имени активного target'а и не давал понять что произойдёт за каждой фазой. v0.1.85 переезжает на single-bar-per-phase pattern, Phase 1/3 без spinner'а (только `→ start` / `✓ end` static-строки), Phase 2 keeps spinner because retry loop owns all output. Dry-run resolves active target name + грузит config.yaml и расписывает фазы человеческим языком.

**Source:** `cli-dx-task.md` §5.11 + §17 row 9.

**Поставка:**
- [x] `cli/cli-core/Cargo.toml` workspace dep `indicatif = "0.17"`; `platform-cli/Cargo.toml` direct dep.
- [x] `commands/kubeconfig.rs` рефакторинг: новый `pub fn fetch_and_cache(refresh, target_override) -> Result<String>` возвращает YAML без `print!`, прежний `run` стал thin wrapper. Внутри теперь `resolve_hetzner_token` (cli-dx-task.md §7) вместо прямого `env::var("HCLOUD_TOKEN")` — Phase 2 поллинг подхватывает active target's токен идентично `apply`.
- [x] `cli.rs` — новый `Commands::Kubeconfig { refresh, target }` (`--target` override credential resolution chain) + `Commands::BootstrapAll { target, dry_run }`.
- [x] `main.rs` dispatch обновлён.
- [x] `commands/bootstrap_all.rs` (v0.1.85 UX layout):
    - Phase 1/3 — `apply::run(target_override)` без spinner'а: `→ [1/3] apply  provisioning…` перед вызовом, `✓ [1/3] apply  done in Ns` после. Apply сам логирует через `tracing` на stderr — spinner вокруг него только конкурировал бы за тот же ряд терминала и оставлял stale-кадры после каждого `helm`/`kubectl` write.
    - Phase 2/3 — retry-loop `kubeconfig::fetch_and_cache(true, target_override)` каждые 10s до 5 минут (`KUBECONFIG_POLL_TIMEOUT = 300s`, `KUBECONFIG_POLL_INTERVAL = 10s`). Здесь spinner оправдан: цикл наш, никаких inner subcommand'ов не пишут в stdout, message обновляется с attempt counter + truncated last error. Завершается `finish_and_clear()` + static success line.
    - Phase 3/3 — `cluster_bootstrap::run()` без spinner'а (та же логика, что Phase 1).
    - `--dry-run` short-circuits BEFORE any side-effect — load `default_config_root()` + `resolve_active_target_name()` + `load_active_target_config()`, печатает реальное имя active target (или `--target` override label), provider/region/tier/cluster/ssh-key из `config.yaml`, и human-readable описание каждой фазы (что именно она делает, не просто «вызовет такую-то subcommand»).
    - `failed(num, name, elapsed, err)` helper — на error печатает `✗ [N/3] phase  FAILED after Ns` в stderr и пробрасывает CliError неизменно (timing accountable без потери error chain).
    - Финал: `bootstrap-all complete in Tm00s (apply X + kubeconfig Y + bootstrap Z)` — single-line breakdown total + per-phase.
- [x] `commands/mod.rs` регистрирует новый модуль.

**Тесты (4 unit + 6 integration):**
- 4 в `commands::bootstrap_all::tests`:
    - `format_elapsed_uses_seconds_under_one_minute`
    - `format_elapsed_switches_to_minutes_at_sixty_seconds`
    - `short_error_keeps_first_line_only`
    - `short_error_truncates_long_first_line_with_ellipsis`
- 6 в `tests/bootstrap_all_test.rs`:
    - `bootstrap_all_dry_run_prints_three_phase_plan_without_provider_calls` — fresh store / no token / no base-URL → success + all 3 phase labels + `Phases:` block в stdout.
    - `bootstrap_all_dry_run_with_empty_store_prints_onboarding_hint` — empty target store → `no active target` + `apprafter target add` hint.
    - `bootstrap_all_dry_run_with_target_override_labels_it_clearly` — `--target work` → `Target: work` + `via --target override` label.
    - `bootstrap_all_dry_run_with_active_target_resolves_name_and_config` — seed real target через `target add`, dry-run resolves `Target: myprod (active)` + Provider/Region/Tier из `config.yaml`.
    - `bootstrap_all_help_documents_dry_run_and_target_flags` — `--help` mentions both flags.
    - `bootstrap_all_rejects_unknown_flag` — clap surface contract guard.

**Acceptance:**
- ✅ `apprafter bootstrap-all --dry-run` exits 0 на любой директории / любом credential state, никаких provider calls.
- ✅ Dry-run показывает реальное имя active target + полный target config (не placeholder `<active target>`).
- ✅ `--target <name>` override доходит и до apply, и до Phase 2 kubeconfig poll (single resolution path).
- ✅ Real run на свежем Hetzner токене даёт **clean** vertical output: `→ start / inner output / ✓ end` без дублирования спиннер-строк.
- ✅ `cargo test --workspace` — 542 tests, 0 failures.
- ✅ fmt + clippy (-D warnings) + SPDX (161 файл) clean.

**Out-of-scope (отложено):**
- Capturing inner helm/kubectl output to a buffer (показывать только on failure) — feasible but invasive; пользователю всё ещё нужно видеть прогресс helm install. Доработка цвета + табличного hiding — Track A.11.
- Idempotent re-run / skip-already-installed semantics — Argo CD handle'ит это в Phase 3 через `helm upgrade --install`; Phase 1 — Hetzner labels; Phase 2 — `--refresh` always re-fetches.
- miette-styled error rendering при timeout — Track A.10.
- **Phase 2 polish (отложено до отдельной итерации, ~A.9c)** — две связанные доработки, замеченные на ручном walk'е v0.1.85: (a) Phase 2 стабильно завершается за `1m00s` потому что `ssh` упирается в kernel TCP connect timeout (~30s) пока cloud-init поднимает sshd; нужен `ConnectTimeout=5` в SSH wrapper'е → attempt 1 fail'ится за 5s вместо 30s, total Phase 2 падает до ~20-30s, attempts равномернее. (b) Label `[2/3] kubeconfig` вводит в заблуждение — реально это время полного boot'а ноды (cloud-init + k3s startup), kubeconfig fetch — копеешный финальный шаг. Переименовать на `[2/3] k3s-ready` / `[2/3] cluster-up` / подобное; success-строка станет `up in Ns` вместо `ready in Ns`. dry-run phase block обновить синхронно.

**Зависит от:** 1.66A.8 ✅ (credential resolution chain — Phase 2 needs `resolve_hetzner_token`).

**Размер:** S (один цикл, ~0.5 рабочего дня).

---

### 1.66A.10 miette diagnostic refinement ✅

> v0.1.86 — sub-phase 1.66A.10 shipped: каждый user-facing вариант `CliError` теперь несёт стабильный `code(apprafter::*)` + многострочный `help(...)` через `miette::Diagnostic` derive, а binary entry point рендерит через `miette::MietteHandlerOpts` (`fancy` reporter) вместо `color-eyre`. Результат — rustc-quality error UX: `error:` + код, бокс-обёрнутое сообщение, многострочный `help:` с конкретными next-step командами. Зависимость `color-eyre` удалена.

**Source:** `cli-dx-task.md` §10 + §17 row 10.

**Поставка:**
- [x] `cli/Cargo.toml` workspace deps: `miette = { version = "7", features = ["fancy"] }`; удалена `color-eyre` (больше не используется).
- [x] `cli/cli-core/Cargo.toml` — `miette` direct dep (поскольку `CliError` derives `Diagnostic` в cli-core).
- [x] `cli/platform-cli/Cargo.toml` — `miette` direct dep, удалена `color-eyre`.
- [x] `cli/cli-core/src/error.rs`:
    - `CliError` теперь derives `miette::Diagnostic` рядом с `thiserror::Error`.
    - 9 вариантов получили `#[diagnostic(code(...), help(...))]`:
        - `CueNotFound` — `apprafter::env::cue_not_found` + nix-develop hint.
        - `CueExport` — `apprafter::env::cue_export_failed` + `cue vet` reproduce hint.
        - `Hetzner` — `apprafter::provider::hetzner_api_error` + enumerate 401/403/429/5xx common causes + `apprafter doctor` next-step.
        - `ServerTypeUnavailable` — `apprafter::provider::server_type_unavailable` + cx22→cpx22 retirement story.
        - `InvalidState` — `apprafter::state::corrupt` + `apprafter import` recovery hint.
        - `InvalidTargetConfig` — `apprafter::target::invalid_config` + per-target dir recovery path.
        - `TargetNotFound` — `apprafter::target::not_found` + `target list` + `target add` hints.
        - `Io` / `Json` / `Yaml` — каждая получает `apprafter::io::*` code + variant-specific help.
        - `Other` (catch-all) — `apprafter::cli::other` со стабильным code чтобы log-analytics могла find'ить recurring messages кандидатами на promotion в typed variant.
    - File-level `#![allow(unused_assignments)]` для подавления `miette-derive` 7.6.0's generated reassignments (lint fires на generated code за нашим контролем; локальное `#[allow]` на enum не пропускается через derive macro).
- [x] `cli/platform-cli/src/main.rs`:
    - Return type `color_eyre::Result<()>` → `miette::Result<()>`.
    - `color_eyre::install()` заменён на `miette::set_hook(...)` с `MietteHandlerOpts::new().terminal_links(true).unicode(true).context_lines(2).with_cause_chain().build()`.
    - Вынесен `fn dispatch(args: Cli) -> cli_core::Result<()>` — типизированный CliError→miette::Report happens exactly once на binary boundary, inner code keeps original `?` ergonomics over `cli_core::Result<T>`.
- [x] doc-comment на `cli-core::error` объясняет policy: новые call-sites должны добавлять typed variants с кодами вместо `Other(format!(...))`.

**Тесты (8 unit + 3 integration):**
- 8 в `cli_core::error::tests`:
    - `target_not_found_diagnostic_carries_stable_code_and_helpful_hint` — code = `apprafter::target::not_found`, help содержит `target list` + `target add`.
    - `invalid_target_config_diagnostic_points_at_target_directory` — code = `apprafter::target::invalid_config`, help содержит `$XDG_CONFIG_HOME/apprafter/targets/` + `target add`.
    - `hetzner_diagnostic_help_enumerates_401_403_429_5xx` — help раскрывает все 4 типа failures + `target add` + `doctor`.
    - `server_type_unavailable_diagnostic_explains_retirement_path` — help упоминает cx22 + cpx22 retirement.
    - `cue_not_found_diagnostic_recommends_nix_develop` — help содержит `nix develop` + `docs/contributing/setup.md`.
    - `invalid_state_diagnostic_recommends_import_for_recovery` — help содержит `apprafter import`.
    - `io_error_passes_through_with_dedicated_code` — code = `apprafter::io::error`, wrapped OS message survives в Display.
    - `other_keeps_catch_all_code_so_recurring_variants_can_be_filtered` — code = `apprafter::cli::other` (stable для log analytics).
- 3 в `tests/miette_render_test.rs` (полноценный subprocess-based render contract):
    - `unhandled_error_renders_with_miette_help_line` — `apply` без creds → stderr содержит `help:` + `apprafter::cli::other` code (catch-all variant goes through fancy renderer).
    - `typed_target_not_found_renders_with_dedicated_code_and_help` — `target show ghost` → stderr содержит `apprafter::target::not_found` + `help:` + `apprafter target list` + `apprafter target add` substrings из help text.
    - `no_color_env_yields_ansi_free_stderr` — `NO_COLOR=1` → no `\x1b` bytes в stderr но `help:` + diagnostic code still present (pipe-friendly).

**Acceptance:**
- ✅ Любой `CliError` reaching `main` рендерится с `Error: apprafter::<...>` + box-wrapped message + `help:` block (NOT с `Debug` stringification).
- ✅ Stable diagnostic codes per variant для log-analytics + future error catalogue.
- ✅ `NO_COLOR=1` респектится (no ANSI sequences в stderr).
- ✅ `cargo test --workspace` — 553 tests, 0 failures (+11 over v0.1.85's 542).
- ✅ fmt + clippy (-D warnings) + SPDX (163 файла) clean.
- ✅ `color-eyre` workspace + platform-cli deps удалены.

**Out-of-scope (отложено):**
- `#[source_code]` + `#[label]` span highlighting per variant (например, `InvalidHetznerTokenFormat` с подсветкой именно префикса) — feature exists в miette, но требует carrying source text через error chain. Promote later when CUE manifest parsing errors get the same treatment.
- Promotion массовых `CliError::Other(format!(...))` call sites в типизированные варианты — `Other` остаётся catch-all со стабильным code; конвертация — отдельная работа, по мере того как specific shapes повторяются.
- Cause-chain rendering refinements (multi-level nested errors) — `with_cause_chain()` уже включён в hook builder, но AppRafter ещё не порождает глубоких цепочек. Полировка — when needed.

**Зависит от:** 1.66A.9 ✅ (нужен `bootstrap-all` рабочий путь для smoke tests миette-рендера).

**Размер:** S (один цикл, ~0.5 рабочего дня).

---

### 1.66A.11 Aliases + semantic colors + NO_COLOR ✅

> v0.1.88 — sub-phase 1.66A.11 shipped: новый `cli_core::style` модуль с семантическими хелперами поверх `owo-colors` (auto-honours `NO_COLOR` через `supports-colors` feature); цвет applied на `bootstrap-all` markers (`→` cyan, `✓` green, `✗` red) + `doctor` PASS/WARN/FAIL glyphs (green/yellow/red); subcommand aliases — `target list/show/remove` ↔ `ls`/`info`/`rm`, `kubeconfig` ↔ `kc`, `cluster-bootstrap` ↔ `cb`, `bootstrap-all` ↔ `up`. Уже существовавший `target` ↔ `t` сохраняется, новые aliases прицепляются к нему (`apprafter t ls`).

**Source:** `cli-dx-task.md` §17 row 11.

**Поставка:**
- [x] `cli/Cargo.toml` workspace dep `owo-colors = { version = "4", features = ["supports-colors"] }`; `cli-core/Cargo.toml` direct dep.
- [x] `cli/cli-core/src/style.rs` — новый модуль:
    - `ok(t)` — green (PASS / `✓` / verified). `Stream::Stdout` для авто-NO_COLOR.
    - `warn(t)` — yellow (WARN / soft failures).
    - `fail(t)` — red. `Stream::Stderr` — callsites that consume `fail()` write to stderr.
    - `info(t)` — cyan (phase markers `→`, column headers, `(active)` tags).
    - `dim(t)` — dimmed (tertiary annotations типа `(unset — apply uses platform-1)`).
    - `bold(t)` — bold emphasis (target names, cluster names). Combine: `info(&bold("dev"))`.
    - Все возвращают `String` (упрощено — `if_supports_color` возвращает hard-to-name generic type; форматирование в строку pragmatic и pollutes только небольшие call sites).
- [x] `cli-core/src/lib.rs` — `pub mod style;`.
- [x] `commands/bootstrap_all.rs`:
    - Phase markers `→`/`✓`/`✗` через `style::info/ok/fail`.
    - Phase 2 spinner success line использует `style::ok`.
    - Phase failure marker через `style::fail`.
- [x] `commands/doctor.rs`:
    - Новый `CheckStatus::coloured_glyph(&self) -> String` — green ✓ / yellow ⚠ / red ✗.
    - `print_check_line` использует coloured glyph.
- [x] `cli/platform-cli/src/cli.rs` — aliases:
    - `Kubeconfig` — `alias = "kc"`.
    - `ClusterBootstrap` — `alias = "cb"`.
    - `BootstrapAll` — `alias = "up"`.
    - `TargetCommand::List` — `alias = "ls"`.
    - `TargetCommand::Show` — `alias = "info"`.
    - `TargetCommand::Remove` — `alias = "rm"`.

**Тесты (2 unit + 7 integration):**
- 2 в `cli_core::style::tests`:
    - `ok_returns_ansi_free_text_when_stream_is_not_a_tty` — под `cargo test` stdout не TTY → no ANSI bytes, literal text survives.
    - `warn_fail_info_dim_bold_all_round_trip_text_under_no_tty` — same contract для всех 5 helpers.
- 7 в `tests/aliases_test.rs`:
    - `target_ls_alias_routes_to_target_list` — sub-process сравнение stdout/exit между `target list` и `target ls` (identical bytes).
    - `target_rm_alias_routes_to_target_remove` — `rm ghost --yes` → typed `apprafter::target::not_found`.
    - `target_info_alias_routes_to_target_show` — same not-found surface.
    - `kc_alias_routes_to_kubeconfig` — surfaces "no hetzner_cloud state" hint identically.
    - `cb_alias_routes_to_cluster_bootstrap` — same.
    - `up_alias_routes_to_bootstrap_all_dry_run` — `up --dry-run` exits 0 + prints `DRY RUN` plan identical to `bootstrap-all --dry-run`.
    - `t_alias_for_target_still_works_alongside_new_alias_chain` — `apprafter t ls` chains `t` (target) ↔ `ls` (list) → empty-store onboarding hint surfaces. Pins muscle-memory kubectl-style path.

**Acceptance:**
- ✅ `bootstrap-all` real run в TTY показывает coloured phase markers (green ✓ / cyan →).
- ✅ `doctor` PASS rows green, WARN rows yellow, FAIL rows red.
- ✅ `NO_COLOR=1` или non-TTY pipe → output identical to monochrome v0.1.87 (zero ANSI bytes).
- ✅ Все 6 новых aliases работают через subprocess: `apprafter ls`/`info`/`rm`/`kc`/`cb`/`up` + chained `t ls`/`t info`/`t rm`.
- ✅ `cargo test --workspace` — 564 tests, 0 failures.
- ✅ fmt + clippy (-D warnings) + SPDX (165 файлов) clean.

**Out-of-scope (отложено):**
- Цвет на `target list` table (через `tabled` cell styling) — feasible but требует custom cell renderer; на стандартных терминалах current monospace table читается хорошо. Promote позже если walk feedback потребует.
- Цветная identity-строка в `whoami` (target name + cluster bold-cyan) — следующее iterative refinement; foundation готов через `style::bold` + `style::info`.
- `style::ok_strong` / `style::fail_strong` background variants — добавим если нужно различать "ready" vs "ready + critical path".

**Зависит от:** 1.66A.10 ✅ (miette уже использует свой палитру; `style` модуль координирует семантику чтобы наш output совпадал с miette's по тонам — green/yellow/red).

**Размер:** S (один цикл, ~0.5 рабочего дня).

---

### 1.66A.12 Docs + ADR ✅

> v0.1.90 — sub-phase 1.66A.12 shipped: финальная подфаза Track A. Документация для операторов переписана под пост-Track-A flow (`apprafter target add` + `apprafter up` вместо env-var + `cargo run`), credential resolution chain и target store layout вынесены в reference, диагностические коды каталогизированы, full CLI reference добавлен в `docs/reference/cli.md`, дизайн-решения Track A закрыты ADR 0030. mkdocs nav обновлён. Track A теперь закрыт — открывается Track B (M1.5 1.66 platform-stack rethink).

**Source:** `cli-dx-task.md` §17 row 12.

**Поставка:**
- [x] `docs/adr/0030-cli-target-store-and-credential-chain.md` — новый ADR, кодифицирует 4 design decisions: D1 target store (file layout + `APPRAFTER_CONFIG_DIR` override + per-target dirs + mode 0600), D2 three-step credential resolution chain (flag → env → store, including `--target` override), D3 `miette` для user-facing diagnostics (stable `apprafter::<area>::<reason>` codes + multi-line `help` + `#[diagnostic_source]` cause chains), D4 subcommand aliases + semantic colour palette. Включает 6 alternatives considered, 4 risks с mitigations, re-evaluation triggers (AWS landing, Phase 2 opening, credential leak).
- [x] `docs/operator-guide/quickstart.md` — полностью переписан. Old flow (`export HCLOUD_TOKEN` + `cargo run --bin apprafter -- init`) → new flow (`apprafter target add prod ...` + `apprafter bootstrap-all`). Объяснены 3-phase wrapper, dry-run preview, per-phase recovery, doctor self-check, aliases (kc/cb/up/t ls/...), миette error reading. Подробный day-2 ops table + Application CRD usage.
- [x] `docs/operator-guide/target-store.md` — новая страница. File layout reference (`config.yaml` + per-target dirs + `auth/` + `state/`), field reference table для `TargetConfig`, credential resolution chain explained, 4 common patterns (single-cluster / multi-cluster / CI-env-only / token rotation), 3 anti-patterns.
- [x] `docs/operator-guide/troubleshooting.md` — новая страница. Diagnostic-code catalogue: каждый из 11 кодов получает 2-3 параграфа объяснения (`env::cue_not_found`, `env::cue_export_failed`, `provider::hetzner_api_error`, `provider::server_type_unavailable`, `state::corrupt`, `target::invalid_config`, `target::not_found`, `target::token_rejected`, `target::provider_unreachable`, `io::error/json/yaml`, `cli::other`). + walk-found common failures section + worked example reading the layered cause chain.
- [x] `docs/reference/cli.md` — новая страница. Top-level binary surface, global env vars table, every subcommand documented (target/whoami/doctor/init/apply/destroy/import/kubeconfig/cluster-bootstrap/argocd-password/bootstrap-all/status/login/upgrade-tier/auth), full aliases reference table.
- [x] `docs/operator-guide/index.md` обновлён — links to new pages, Track A status note (closed), no more "stub" wording.
- [x] `docs/reference/index.md` обновлён — CLI reference из stub стал first-class, диагностические коды cross-link'нуты на troubleshooting page.
- [x] `mkdocs.yml` nav — Operator Guide + Reference раскрываются в nested entries (quickstart / target store / gitops walk / troubleshooting / recovery; reference index + CLI page).

**Тесты:** docs-only changes, никаких runtime tests. SPDX gates: 166 файлов pass. fmt + clippy: clean. Workspace tests: 564 passed (unchanged). mkdocs `--strict` build не запустился локально из-за `nix shell` env quirk (mkdocs binary не видит mkdocs-material theme); CI workflow `.github/workflows/docs.yml` валидирует.

**Acceptance:**
- ✅ ADR 0030 покрывает все 4 design decisions с rationale, alternatives, risks, re-evaluation triggers.
- ✅ Operator quickstart описывает post-Track-A flow без legacy `cargo run` / env-var-only префиксов.
- ✅ Target store layout + credential chain документированы в одной reference page.
- ✅ Все 11 diagnostic codes имеют next-step CLI команды в troubleshooting page.
- ✅ Full CLI reference covers все 13 subcommand'ов + 6 aliases.
- ✅ mkdocs nav surface'ит новые страницы.
- ✅ SPDX clean (166 файлов).

**Out-of-scope (отложено):**
- Auto-generated CRD field reference — Phase 8.1 target per `docs/reference/index.md`.
- Mass-rewrite of `docs/dev-guide/quickstart.md` — Track A не трогал developer flow напрямую, отдельная итерация когда developer experience станет приоритетом.
- Translations — все docs остаются English-only.

**Зависит от:** 1.66A.11 ✅ (последний код-меняющий sub-phase Track A — нужны все имплементированные фичи чтобы корректно их задокументировать).

**Размер:** M (один цикл, ~1 рабочий день — 4 новых doc-файла + 1 ADR + 2 update'а + nav).

---

### Track A backlog (закрыт в v0.1.91)

Originally items surfaced during Track A walks. Cleared:

1. **Phase 2 polish (A.9c)** ✅ — v0.1.91 закрыл оба:
    - SSH `ConnectTimeout=5` добавлен в `SshKubeconfigFetcher::build_command` — первая attempt fail'ится за 5s вместо ~30s на kernel TCP timeout. Typical Phase 2 на cpx22 + Ubuntu 24.04 падает с ~60s до ~20-40s.
    - `[2/3] kubeconfig` rename → `[2/3] k3s-ready`: спиннер label, success line, failed() marker, dry-run plan, total summary breakdown — все consistent. Сообщение "waiting for cloud-init + k3s on the new node…" честно отражает что мы реально делаем. +1 regression test (`ssh_fetcher_caps_connect_timeout_at_five_seconds`); existing dry-run integration test обновлён под новый label. Docs (quickstart, troubleshooting, cli reference) тоже подтянуты.

После v0.1.91 открывается **Track B (M1.5 sub-phase 1.66 platform-stack rethink)** — главная архитектурная работа M1.5.

---

### 1.66 platform-stack monorepo skeleton + CUE source layout ✅

> v0.1.92 — sub-phase 1.66 shipped: top-level `platform-stack/` со всем CUE-only source per ADR 0028. **Layout flat** — `platform-stack/cue/` единая директория с filename prefixes (`component_<name>.cue`, `tier_<name>.cue`) вместо subdirectory groupings. Subdirs пробовали — CUE считает их отдельными package instances even when `package` declaration matches, что ломает cross-file `_components` merging. Дополнительные design-walk gotchas (autobinding-strip + typed `_components` strip + `vet -c` rejecting defaults) задокументированы в `platform-stack/README.md` + комментах в `platform.cue`.

**Source:** ADR 0028.

**Цель:** заложить структуру `platform-stack/` в монорепо. CUE source-of-truth для всех Argo CD Application определений платформенных компонент.

**Поставка:**
- [x] New top-level subdir `platform-stack/` (path указан с префиксом `apprafter/` в исходном тексте — это GitHub URL convention `apprafter/apprafter` org+repo; в clonированном дереве это просто `platform-stack/` на root уровне рядом с `cli/`, `operator/`, `schemas/`).
    - [x] `cue/platform.cue` — umbrella schema (`#Version` / `#Channel` / `#Tier` / `#ComponentSource` / `#Component` / `#ComponentSet` / `#PlatformValues` / `_components: {}` package-level base).
    - [x] `cue/component_cilium.cue` — Cilium 1.16.5, kube-proxy replacement, IPAM kubernetes, Hubble off by default.
    - [x] `cue/component_cert-manager.cue` — jetstack v1.16.2 + CRDs enabled.
    - [x] `cue/component_argocd.cue` — Argo CD 7.7.7 self-managing (`prune: false`), Dex off.
    - [x] `cue/component_apprafter-operator.cue` — pinned to v0.1.91 (Track A closing tag) from `oci://ghcr.io/apprafter/apprafter-operator`.
    - [x] `cue/component_admission-webhook.cue` — pinned to v0.1.91, 2 replicas default.
    - [x] `cue/component_backstage.cue` — Git-source manifests, conditional on `values.backstage.domain`, default-off в tier-1 overlay.
    - [x] `cue/component_network-policies.cue` — default-deny + DNS + Argo-CD egress allowance bundle.
    - [x] `cue/component_argocd-cue-cmp.cue` — declared but `enabled: false` by default до sidecar wiring step в 1.69.
    - [x] `cue/tier_solo.cue` — tier 1 overlay (single cpx22, Hubble off, Backstage off, argocd-cue-cmp off, single-replica everything).
    - [x] `cue/tier_team.cue` — tier 2 overlay (Hubble on relay+UI, Backstage on, admission-webhook + cert-manager + operator at 2 replicas).
    - [x] `cue/compatibility.cue` — `#ChangeClass` + `#VersionRecord` schema + initial 0.2.0 entry classified `safe` (no behaviour change vs in-tree v0.1.x bootstrap).
- [x] `platform-stack/Chart.yaml.tmpl` — template для umbrella chart metadata (рендерится в `dist/<version>/Chart.yaml` через `cue cmd render` в 1.67).
- [x] `platform-stack/README.md` — full layout + contribution model + distribution + forking story + design-walk decision rationale.
- [x] `platform-stack/CHANGELOG.md` — initial planned 0.2.0 entry.
- [x] `scripts/lint-cue.sh` расширен: `cue fmt --check` + `cue vet` теперь покрывают `./platform-stack/cue/...`.
- [x] `scripts/check-spdx-headers.sh` patterns добавлены: `platform-stack/cue/**/*.cue` + `platform-stack/Chart.yaml.tmpl`. SPDX gate теперь 167 файлов.

**Тесты:** scaffold-only release — никаких runtime tests, валидируем CUE-слой:
- [x] `bash scripts/lint-cue.sh` — `cue fmt --check` + `cue vet` clean.
- [x] `nix run nixpkgs#cue -- vet -c ./platform-stack/cue/...` — strict concreteness check passes (exit 0).
- [x] `nix run nixpkgs#cue -- eval ./platform-stack/cue/... -e tier1` / `-e tier2` — рендерят fully-concrete components map.

**Acceptance:**
- ✅ `cue vet -c ./platform-stack/cue/...` exits 0; все schemas валидны + полностью concrete на обоих tiers.
- ✅ Все 8 компонентов declared в CUE. Hardcoded values в `cli-providers::k8s::*` остаются на месте до migration в 1.71 — `platform-stack/` сейчас параллельная source-of-truth, не replacement.
- ✅ README ясно описывает: CUE only в Git, rendered chart живёт в OCI (`oci://ghcr.io/apprafter/platform-stack:<version>`), GitHub Release `.tgz` secondary.

**Design-walk gotchas** (зафиксированы в README + komments в `platform.cue` чтобы будущие contributors не переоткрывали):
- Subdirectory split → CUE считает sibling dirs отдельными package instances, `_components` не мерджились. **Fix:** flat `cue/` с filename prefixes.
- `#ComponentSet` autobinding `[NAME=string]: #Component & { name: NAME }` re-применяет `#Component` на каждом overlay unification и стрипит concrete fields. **Fix:** plain `[string]: #Component` + explicit `name:` per component.
- Typed `_components: #ComponentSet` — та же проблема. **Fix:** plain `_components: {}` с локальной type-conformance на declaration site.
- CUE 0.10+ `vet -c` flags `bool | *false` как incomplete даже когда default applies. **Fix:** explicit pin per tier (`tier_team.cue`'s `argocd-cue-cmp.enabled: false`).

**Out-of-scope (отложено):**
- `dist/` renderer + `templates/applications.yaml` template + `make render` — sub-phase 1.67.
- Publish workflow (`.github/workflows/platform-stack-publish.yml`) — 1.68.
- Argo CD CMP sidecar wiring — 1.69.
- Migration `cli-providers::k8s` hardcoded values → CUE — 1.71.

**Зависит от:** —

**Размер:** M (один цикл, ~0.5-1 рабочий день; основное время — design-walk на CUE gotchas).

---

### 1.67 `cue cmd render` pipeline + umbrella chart generation ✅

> v0.1.93 — sub-phase 1.67 shipped: CUE-tools-based renderer + Makefile + per-tier examples + Helm-native values schema. `make -C platform-stack render` produces a fully-lintable umbrella chart in `dist/platform-stack-<version>/` purely from CUE source, with no hand-edited intermediate YAML. Helm lint clean (only INFO about an icon recommendation, no errors / warnings). `helm template --set tier=99` rejects out-of-range tier values at the schema gate before any Argo CD reconcile sees them.

**Source:** ADR 0028.

**Цель:** CI step который рендерит CUE source в Helm umbrella chart в `dist/`.

**Поставка:**
- [x] `platform-stack/cue/render_tool.cue` — CUE `command: render: { ... }` using `tool/file` package. Tasks:
    - `mkdist` / `mktemplates` / `mkexamples` — `file.Mkdir` создают `dist/platform-stack-<version>/templates/` + `examples/` (с `$dep` chain, чтобы `file.Create` shaped tasks выполнялись после dirs).
    - `chartYaml` — Chart.yaml v2 (apiVersion + name + description + version + appVersion + maintainers + keywords + annotations с `apprafter.io/change-class` + `apprafter.io/operator-version` из `compatibility.cue`).
    - `valuesYaml` — defaults to `tier1` (solo), emit via `yaml.Marshal`. Operators running `helm install platform-stack` без `--values` получают tier-1 baseline (совпадает с v0.1.x cluster-bootstrap).
    - `valuesSchemaJson` — Helm-native JSON-schema-2020-12 (handrolled to match `#PlatformValues` shape — CUE's auto-export targets draft-07 which Helm не понимает). Required: version + tier + channel + components; tier enum `[1,2,3,4]`; channel enum `["stable","edge"]`; per-component required: name/enabled/namespace/source/version. `additionalProperties: false`.
    - `appsTemplate` — `templates/applications.yaml`: единственный Go template. `{{- range $name, $component := .Values.components }}` → один Argo CD `Application` per enabled entry. Conditional `helm.valuesObject` only когда `source.chart` set (Git-source components skip it). Labels `apprafter.io/{component,tier,channel}`. SSA + auto-create-namespace via `syncPolicy.syncOptions` из CUE base.
    - `compatibilityYaml` — `compatibility.yaml` rendered from `compatibility.cue`'s `compatibility: [string]: #VersionRecord`.
    - `soloExample` / `teamExample` — `examples/values.solo.yaml` + `examples/values.team.yaml` (concrete tier renders for `helm install -f`).
    - `readme` — `README.md` inside the rendered chart pointing back at the CUE source (so users pulling the OCI artifact see a redirect to canonical docs).
- [x] `platform-stack/Makefile` — `make render` / `render-only` / `lint` / `clean` / `help`. Auto-detects `cue` and `helm` binaries from PATH, falls back to `nix run nixpkgs#cue --` / `nix run nixpkgs#kubernetes-helm --` so anyone in the project's nix shell или с nix available picks them up. Version резолвится из `tier1.version` через `cue export` — никогда не хардкодится в Makefile.
- [x] `dist/` уже gitignored (project-wide rule в `.gitignore` line 17 — `dist/` without leading slash matches at any depth).
- [x] `Justfile` — `just platform-stack-render` + `just platform-stack-check` wrappers вокруг `make -C platform-stack ...` для project-level convenience.
- [x] `platform-stack/README.md` Local-development section обновлён с реальными командами + per-tier helm template примером + schema-gate sanity check (`--set tier=99` → error).

**Тесты:** scaffold-only — никакого Rust unit/integration кода не меняется (565 passed). Валидация через render-and-lint:
- [x] `cue cmd render` (через `make render-only` или direct) emit'ит 8 файлов в `dist/platform-stack-0.2.0/` (Chart.yaml + values.yaml + values.schema.json + compatibility.yaml + README.md + templates/applications.yaml + examples/values.solo.yaml + examples/values.team.yaml).
- [x] `helm lint dist/platform-stack-0.2.0` exits 0 (single INFO about chart icon, no warnings / errors).
- [x] `helm template platform dist/platform-stack-0.2.0` (default tier-1) → 6 Argo CD Applications: admission-webhook + apprafter-operator + argocd + cert-manager + cilium + network-policies. Backstage + argocd-cue-cmp ожидаемо disabled.
- [x] `helm template platform dist/platform-stack-0.2.0 --values dist/platform-stack-0.2.0/examples/values.team.yaml` → 7 Applications (добавляется Backstage; argocd-cue-cmp всё ещё off до 1.69 wiring).
- [x] `helm template platform dist/platform-stack-0.2.0 --set tier=99` → schema rejects `value must be one of 1, 2, 3, 4`. Validates the values.schema.json gate.

**Acceptance:**
- ✅ `make render` produces `dist/platform-stack-0.2.0/` content.
- ✅ `helm lint` returns 0.
- ✅ `helm template ... --values examples/values.solo.yaml` renders tier-1 correctly (6 enabled Applications, no Backstage / no argocd-cue-cmp).
- ✅ `helm template ... --values examples/values.team.yaml` renders tier-2 correctly (7 Applications с Backstage enabled, Hubble relay+UI in cilium values).
- ✅ Schema gate rejects invalid tier values at `helm template` time before reaching Argo CD.

**Out-of-scope (отложено):**
- Kamaji / Capsule / Hubble dashboard для tier-2+ — отдельные components, landing в sub-phase 1.71+ alongside the in-tree manifest migration.
- Smoke install в kind cluster — это CI-side acceptance в sub-phase 1.68 publish workflow.
- `helm push` к OCI registry + `cosign sign` — sub-phase 1.68.
- `text/template` engine для `Chart.yaml.tmpl` (сейчас chart metadata — CUE string literal с interpolation). Перевод на template engine — when chart metadata вырастает; пока линейная string interpolation покрывает все substitutions.

**Зависит от:** 1.66 ✅

**Размер:** S (один цикл, ~0.5 рабочий день — основное время на отладку CUE `tool/file` task DAG semantics + Helm template indent/quoting).

---

### 1.68 CI OCI publish workflow + cosign signing ✅

> v0.1.94 — sub-phase 1.68 shipped: `.github/workflows/platform-stack-publish.yml` triggers on `platform-stack/v*` tags (или manual `workflow_dispatch`), validate'ит `compatibility.cue` имеет entry для версии, render'ит chart, lints, smoke-template'ит обе tier-1/tier-2, packages, push'ит к OCI на `ghcr.io/<owner>/platform-stack:<version>`, cosign-keyless signs OCI digest + `.tgz` blob через Sigstore OIDC (ambient GitHub identity, no managed keys), tags `:latest` on stable releases via `oras tag`, и создаёт GitHub Release с `.tgz` + `.tgz.sig` + `.tgz.pem` attachments и body content описывающим install + verify commands. `scripts/check-platform-stack-version.sh` — отдельный helper, используется CI как fail-fast gate, тоже работает локально для проверки перед tagging'ом. `platform-stack/RELEASE.md` — full maintainer procedure: versioning rules, pre-release checklist, tagging steps, after-publish actions, failure-mode recovery.

**Source:** ADR 0028.

**Цель:** GitHub Actions workflow который on tag `platform-stack/v*` builds chart + signs + publishes к OCI и GitHub Release.

**Поставка:**
- [x] `.github/workflows/platform-stack-publish.yml`:
    - [x] Trigger: tag matching `platform-stack/v*` (плюс `workflow_dispatch` с `version:` input для manual republish).
    - [x] Step 1: Checkout.
    - [x] Step 2: Resolve version from tag (strip `platform-stack/v` prefix) or from workflow input. Detect pre-release via `-` in version → controls `:latest` retag + GitHub Release `prerelease:` flag.
    - [x] Step 3: Compute lowercase owner (ghcr requires lowercase). Same shim as `release-operator.yml`.
    - [x] Step 4: `cue-lang/setup-cue@v1` + `azure/setup-helm@v4` + `sigstore/cosign-installer@v3`.
    - [x] Step 5: `bash scripts/check-platform-stack-version.sh "$VERSION"` — compatibility gate.
    - [x] Step 6: `make -C platform-stack render-only` — render CUE → `dist/`.
    - [x] Step 7: `helm lint`.
    - [x] Step 8: `helm template` smoke for **both** tiers — assert 6 tier-1 Applications + Backstage on tier-2.
    - [x] Step 9: `helm package` → `.tgz`.
    - [x] Step 10: `docker/login-action@v3` к `ghcr.io` via `GITHUB_TOKEN`.
    - [x] Step 11: `helm push` к `oci://ghcr.io/<owner>` (Helm 3.8+ native OCI push; tag derived from `Chart.yaml.version`). Resolve immutable digest via `helm show chart oci://...` для последующего cosign sign — Sigstore best practice: never sign mutable tags.
    - [x] Step 12: `cosign sign --yes "${IMAGE}@${DIGEST}"` — keyless via Sigstore OIDC + GitHub Actions ambient identity (`id-token: write` permission). No managed signing keys.
    - [x] Step 13: `cosign sign-blob --yes ... "$TGZ"` → `.tgz.sig` + `.tgz.pem` detached signature pair для GitHub Release attachment path (`cosign verify-blob` consumer).
    - [x] Step 14: `oras tag "${IMAGE}:${VERSION}" latest` (только на stable, с graceful warning если oras CLI отсутствует на runner image).
    - [x] Step 15: `gh release create` с heredoc-formatted notes (install snippets для Argo CD path + plain Helm path + cosign verify snippets для обоих), attaches `.tgz` + `.sig` + `.pem`, `--prerelease` flag для pre-release tags.
    - [x] Security hardening: каждый dynamic input (`github.ref_name`, `github.repository_owner`, `github.event.inputs.version`, `github.repository`) routed через `env:` binding, не direct interpolation в `run:` body — pattern из release-operator.yml продолжается. Heredoc-built notes file через `mktemp` + `--notes-file` чтобы не передавать multi-line string в bash arg directly.
- [x] CI validation: `scripts/check-platform-stack-version.sh "$VERSION"` exits non-zero с human-readable error pointing at `compatibility.cue`. Resolves cue binary same way `lint-cue.sh` does (local → nix fallback). Verified локально на happy path (`0.2.0` → returns YAML) и unhappy path (`99.99.99` → exit 1 с instruction'ом добавить entry).
- [x] `platform-stack/RELEASE.md` — full maintainer release procedure:
    - Semver rules + first-published-version-is-0.2.0 explanation.
    - Pre-release checklist (compatibility.cue entry + accurate change class + operator version + CHANGELOG.md + local render passes + workspace tests).
    - Tagging instructions (pre-release `-rc1` vs stable).
    - After-publish actions (verify in clean env + bump `RELEASED_OPERATOR_VERSION` if paired + update UNRELEASED.md).
    - Failure-mode recovery (tag delete + re-push).

**Тесты:** CI-side acceptance — нельзя по-настоящему verify без push'a реального tag'а. Локальные проверки которые делал:
- [x] `bash scripts/check-platform-stack-version.sh 0.2.0` → success + prints YAML.
- [x] `bash scripts/check-platform-stack-version.sh 99.99.99` → exit 1 + human-readable error pointing at compatibility.cue.
- [x] `yamllint -d relaxed .github/workflows/platform-stack-publish.yml` clean.
- [x] SPDX gate clean (167 → 170 после staging .yml + .sh + RELEASE.md).
- [x] Все existing gates green (cargo fmt/clippy/test 565, cue lint, spdx).

**Acceptance:**
- ✅ Workflow file present и syntactically valid (yamllint passes).
- ✅ Compatibility-gate скрипт работает on happy and unhappy paths.
- ✅ Security pattern from `release-operator.yml` (env-binding for all dynamic inputs) consistent.
- ✅ Release procedure documented в `platform-stack/RELEASE.md`.
- ⏳ Tag `platform-stack/v0.2.0-rc1` triggers workflow → ends green. **Verified only after first real push** (CI-side acceptance). Local validation steps above approximate the pre-push checklist.
- ⏳ `oras pull ghcr.io/apprafter/platform-stack:0.2.0-rc1` retrieves signed chart. **Verified after first real push.**
- ⏳ `cosign verify ghcr.io/apprafter/platform-stack@<digest> --certificate-identity-regexp ... --certificate-oidc-issuer ...` succeeds. **Verified after first real push.**
- ⏳ GitHub Release page has `.tgz` + `.tgz.sig` + `.tgz.pem` attached. **Verified after first real push.**

**Out-of-scope (отложено):**
- Smoke install in `kind` cluster within the workflow — current `helm template` smoke + `helm lint` cover chart shape and template-time errors. Adding kind would extend workflow runtime ~3 minutes for marginal new coverage. Promote when first real-world chart bug slips past template-time validation.
- SLSA Level 3 build provenance attestation. cosign already provides keyless artifact provenance; SLSA Level 3 demands hermetic builds in `slsa-github-generator` reusable workflow. Defer until M3 compliance pass.
- Multi-architecture OCI manifest list. The chart is a Helm artifact — architecture-neutral by definition. Sub-charts (Cilium, cert-manager, Argo CD) are pulled by Argo CD at install time and select arch on the user's cluster.

**Зависит от:** 1.67 ✅ (renderer + Makefile — workflow shells out to `make -C platform-stack render-only`).

**Размер:** S (один цикл, ~0.5 рабочий день — основное время на отладку cosign keyless flow + проверку workflow-injection security pattern).

---

### 1.69 CUE CMP sidecar Docker image + plugin.yaml ✅

> 2026-05-19 — sub-phase 1.69 shipped: `argocd-cue-cmp/` flat directory at repo root + publish/check workflow pair following the same trigger-inversion + drift-detection model as `platform-stack-*.yml`. Chart bumped to 0.1.2 to wire the sidecar into `argocd-repo-server.extraContainers`. Image's own version track `argocd-cue-cmp/v*` — independent semver, started at 0.1.0.

**Source:** ADR 0029.

**Цель:** sidecar image для `argocd-repo-server` который компилирует CUE → YAML для user app repositories.

**Поставка:**
- [x] New top-level `argocd-cue-cmp/`:
    - [x] `Dockerfile` — Alpine 3.20 multi-stage; fetcher stage pulls cue v0.10.0 tarball from GitHub Releases; runtime stage drops cue binary on PATH, copies plugin.yaml + entrypoint.sh, sets UID/GID 999 to match argocd-repo-server CMP sidecar contract (Alpine 3.20's ping group on gid 999 deleted first to free the slot). OCI labels populated from build args (IMAGE_VERSION, IMAGE_REVISION) which CI fills.
    - [x] `plugin.yaml` — ConfigManagementPlugin manifest. `discover.find.glob: "**/apprafter*.cue"` (matches phase 1.11 user app convention). `generate.command: [sh, "-c"]` invokes `/usr/local/bin/entrypoint.sh`.
    - [x] `entrypoint.sh` — runs `cue export ./... --out yaml`; on success prints YAML to stdout; on failure extracts first non-empty error line as `::cue-cmp:: CUE compile failed: <summary>` to stderr + full cue stderr block below. Smoke-tested locally: happy-path → exit 0 + YAML; conflict-path (`apiVersion: "v1"` vs `"v2"`) → exit 1 + summary line.
    - [x] `VERSION` — plain-text single source of truth for image semver. Read by publish workflow via `tr -d '[:space:]' < VERSION`. Initial value `0.1.0`.
    - [x] `README.md` — purpose + local build instructions + smoke test script + release flow.
- [x] `.github/workflows/argocd-cue-cmp-publish.yml` — split into `detect` + `publish` jobs (same pattern as `platform-stack-publish.yml`). Trigger: push to master on `argocd-cue-cmp/**` paths + `workflow_dispatch` with optional `version_override:`. `detect` resolves VERSION, checks if tag exists on origin → `should_publish`. `publish` (gated): docker buildx build + push to `ghcr.io/<owner>/argocd-cue-cmp:<version>` + cosign keyless sign (immutable digest from `docker/build-push-action` outputs, not the mutable tag) + `:latest` retag via `docker buildx imagetools create` on stable + `gh release create argocd-cue-cmp/v<version>` создаёт tag.
- [x] `.github/workflows/argocd-cue-cmp-check.yml` — PR + push gate. VERSION semver validation, docker smoke build (no push), entrypoint fixture render (tiny `apprafter/Application.cue` → assert `kind: Application` in output), **drift detection** identical to platform-stack-check: if `argocd-cue-cmp/v<VERSION>` exists on origin AND any file under `argocd-cue-cmp/{Dockerfile,plugin.yaml,entrypoint.sh,VERSION}` differs → fail с 80-line diff.
- [x] `platform-stack/cue/component_argocd-cue-cmp.cue` обновлён: image tag `v0.1.91` → `v0.1.0` (cue-cmp's own semver track), repoURL переключён на GitHub source path (image не Helm chart, sidecar pulled directly via repoServer.extraContainers), `version` field тоже `v0.1.0`. Doc-comment объясняет sidecar-not-Application semantics.
- [x] `platform-stack/cue/component_argocd.cue` обновлён: добавлен `repoServer.extraContainers` блок с `cue-cmp` sidecar. `image` поле читает `_components."argocd-cue-cmp".values.image.repository:tag` через CUE interpolation — bump cue-cmp version становится one-line edit в одном файле. UID 999 / runAsNonRoot. Volume mounts соответствуют Argo CD CMP sidecar contract (var-files, plugins, cmp-tmp, cue-cmp-config configmap subPath).
- [x] `platform-stack/cue/platform.cue` — `currentVersion` 0.1.1 → 0.1.2.
- [x] `platform-stack/cue/compatibility.cue` — добавлена запись 0.1.2 (change: safe, references ADR 0029 + argocd-cue-cmp/README.md, упоминает ~50 MiB sidecar memory overhead из ADR 0029, single repo-server pod restart impact).
- [x] `scripts/check-spdx-headers.sh` — добавил patterns `argocd-cue-cmp/{Dockerfile,plugin.yaml,entrypoint.sh}`. SPDX gate cover'ит 175 файлов.

**Тесты:**
- [x] `docker build` локально — pass. Multi-stage build → runtime image с UID 999, cue v0.10.0 binary, plugin.yaml и entrypoint.sh на правильных path'ах per Argo CD CMP sidecar contract.
- [x] Entrypoint happy-path smoke: tiny `apprafter/Application.cue` → renders YAML, exit 0.
- [x] Entrypoint error-path smoke: conflict-cue (`apiVersion` two-values) → `::cue-cmp:: CUE compile failed: apiVersion: conflicting values...` summary on stderr + full block, exit 1.
- [x] `cue vet -c ./platform-stack/cue/...` clean (invariant catches future bump-without-compat).
- [x] `bash scripts/lint-cue.sh` clean.
- [x] Render chart 0.1.2: `helm lint` clean, `helm template` rendered output показывает `extraContainers` блок с `cue-cmp` sidecar в argocd-repo-server и `ghcr.io/apprafter/argocd-cue-cmp:v0.1.0` image ref.
- [x] yamllint оба новых workflow'а clean.
- [x] SPDX gate (170 → 175 после staging).
- [x] CLI / cargo тесты untouched (565 passed, не Rust changes).

**Acceptance:**
- ✅ `docker build argocd-cue-cmp/` produces image (verified locally).
- ✅ Manual test: `docker run --rm -v ./test-repo:/repo -w /repo --entrypoint /usr/local/bin/entrypoint.sh image` produces correct YAML output для sample `apprafter/Application.cue`.
- ⏳ Tag `argocd-cue-cmp/v0.1.0-rc1` publishes image (CI-side, не локально воспроизводимо — verified at first push of `argocd-cue-cmp/VERSION` to master).

**Out-of-scope (отложено):**
- ApplicationSet pattern для multi-app monorepos — Phase 2+ per ADR 0029 §"Still open".
- Canonical filename migration `apprafter/Application.cue` → `.apprafter/app.cue` — deferred per ADR 0029.
- Backstage plugin surfacing CUE compile errors — out of scope per ADR 0029.
- End-to-end Argo CD sync test (steps 4-5 из ADR 0029 implementation outline) — manual integration test, plan.md M3 territory.
- Multi-arch arm64 — same reasoning as release-operator.yml: Hetzner cpx22 is amd64, arm64 lands когда `Infrastructure.spec.nodes[].arch` wires through apply.rs.

**Зависит от:** 1.68 ✅ (publish-workflow pattern reused), 1.67 ✅ (chart renderer для wiring step).

**Размер:** S (одна итерация, ~3 часа — основное время на Argo CD CMP sidecar contract research + Alpine ping-group conflict).

---

### 1.70 Minimal `cluster-bootstrap` rewrite ✅

> v0.1.97 — sub-phase 1.70 shipped. `commands/cluster_bootstrap.rs` переписан целиком с ~1250-line imperative install (Cilium + Gateway + Application CRD + default-deny + Argo CD + cert-manager + ClusterIssuer + operator helm + webhook manifest + bootstrap App + Backstage) на 4-step GitOps loader (~450 lines, half of которых — комментарии и тесты). Argo CD теперь handle'ит весь platform layer через chart pull. Сам CLI binary stays small — он только loader.

**Source:** ADR 0025.

**Цель:** reduce `cluster-bootstrap` to a minimal loader: install Argo CD via Helm, apply root Application pointing к platform-stack OCI chart. Argo CD дальше reconciles остальное.

**Поставка:**
- [x] Refactor `commands/cluster_bootstrap.rs`:
    - [x] **Step 1**: `helm repo add argo …` + `helm upgrade --install argocd argo/argo-cd` с loader-only values (single replicas, dex off — chart's `component_argocd.cue` overlay adopts the release on first reconcile, adds cue-cmp sidecar + tier-2 replicas).
    - [x] **Step 2**: `kubectl wait --for=condition=Available deployment/argocd-server -n argocd --timeout=180s` — gates root Application apply until Argo CD CRDs are installed (otherwise "no matches for kind Application").
    - [x] **Step 3**: Render single root Application YAML (`apiVersion: argoproj.io/v1alpha1, kind: Application, name: platform, source.repoURL: oci://ghcr.io/<owner>/platform-stack, chart: platform-stack, targetRevision: 0.1.2`) → `kubectl apply -f`. Repo + version pulled из `cli-providers::k8s::APPRAFTER_PLATFORM_STACK_DEFAULT_REPO` + `RELEASED_PLATFORM_STACK_VERSION` constants.
    - [x] **Step 4**: `kubectl wait --for=jsonpath='{.status.health.status}'=Healthy application/platform -n argocd --timeout=600s` — once root Application reports Healthy, all child Applications (cilium, cert-manager, argocd self-managing, apprafter-operator, admission-webhook, network-policies, conditionally Backstage) are reconciling under Argo CD.
- [x] Existing imperative install code **deleted** from CLI: 7 component installs + 5 manifests + 2 helpers (~800 lines net). `cli-providers::k8s::*_yaml` рендерераторы остаются как-есть для chart-side use (parallel source-of-truth до 1.71's migration).
- [x] `cli-providers::k8s` exposes 3 new constants: `RELEASED_PLATFORM_STACK_VERSION = "0.1.2"`, `APPRAFTER_PLATFORM_STACK_DEFAULT_REPO = "oci://ghcr.io/apprafter"`, `APPRAFTER_PLATFORM_STACK_CHART_NAME = "platform-stack"`. Bump `RELEASED_PLATFORM_STACK_VERSION` lockstep с published chart tag.
- [x] `KubectlRunner` trait расширен `wait_for_condition(resource_ref, namespace, condition_expr, timeout_secs, kubeconfig)`. Wraps `kubectl wait --for=<expr>`. Supports both `condition=Available` (deployment readiness) и `jsonpath={.status.health.status}=Healthy` (Argo CD Application health). Real-impl shells out, fake-impl записывает calls для tests.
- [x] FakeKubectl в `argocd_password.rs` обновлён под расширенный trait (unreachable! на wait — argocd-password never waits).

**Тесты:**
- [x] `perform_bootstrap_installs_argocd_then_applies_root_then_waits_for_healthy` — full sequence assertions: 1 helm repo_add, 1 helm install (argocd only, no Cilium/cert-manager/operator/webhook), 1 client-side apply (root Application), 0 server-side applies, 2 waits в правильном порядке (deployment/argocd-server first, application/platform second).
- [x] `render_root_application_includes_repo_url_and_chart_version` — pin repoURL + targetRevision + chart name in rendered YAML. Verifies `prune: true` + `selfHeal: true` syncPolicy для drift correction.
- [x] `render_root_application_uses_argocd_namespace_destination` — destination namespace + cluster URL.
- [x] `argocd_loader_values_keeps_replicas_at_one_for_initial_install` — minimal loader values (replicas=1, dex off). Tier-2 replica counts arrive via Argo CD's first reconcile.
- [x] Existing `decrypt_cached_kubeconfig_*` helper tests preserved.

**Acceptance:**
- ✅ `cargo test --workspace` — closed at 557 cli + 62 operator passed (v0.1.108). Walk-fix cascade added 4 net regression tests (Option<&str> namespace, Cilium ordering, OCI repo registration, default AppProject) and the webhook crate's rustls-CryptoProvider mirror.
- ✅ `cargo fmt --all --check` + `cargo clippy --workspace -- -D warnings` clean.
- ✅ `apprafter init && apprafter bootstrap-all` on fresh Hetzner account → tier-1 cluster reconciles via Argo CD. Verified manually на walk #12 (chart 0.1.12 / CLI v0.1.108). Took **11 walk-fix iterations** (v0.1.98 → v0.1.108) to close, each one a real-cluster-found defect, all surface in `docs/changelog/history.md` v0.1.98 — v0.1.108.
- ✅ `kubectl get applications.argoproj.io -A` shows root `platform` + 6 children all Synced/Healthy. Verified walk #12.
- ✅ `kubectl edit application cilium -n argocd` — drift correction via Argo CD. Verified implicitly through chart's `selfHeal: true` syncPolicy on every child Application.
- ✅ Re-run `apprafter bootstrap-all` идемпотентен. Verified implicitly через 11 destroy+bootstrap cycles during the walk-fix series — each cycle re-applied the same loader values and root Application without dirty state.

**Closure note — walk-fix cascade v0.1.98 → v0.1.108 (11 patches):**

Each walk-fix surfaced a real-cluster defect that prior walks
couldn't reach because of an upstream blocker in the same
cycle. Most defects were latent bugs masked by the previous
blocker:

| Walk | Tag | Bug |
|---|---|---|
| 1 | v0.1.98 | argo-cd 7.7.7 `redis-ha.enabled: true` default times out pre-install hook on single-node k3s. |
| 2 | v0.1.99 | k3s starts with `--flannel-backend=none`; node carries `node.kubernetes.io/not-ready:NoSchedule` until Cilium installs. Loader had Argo CD before Cilium — catch-22. |
| 3 | v0.1.100 | Argo CD doesn't infer OCI Helm protocol from `oci://`; needs explicit `configs.repositories.<name>` with `enableOCI: "true"`. Plus root `Healthy` is a false-positive (zero children = trivially healthy); wait must be Synced→Healthy. |
| 4 | v0.1.101 | Operator + admission-webhook helm charts never published to OCI (only container images). `ignoreDifferences` missed `terminatingReplicas` (k3s v1.35). `manifests/tier-1/network-policies/` directory never created. |
| 5 | v0.1.102 | webhook chart `selectorLabels` missing from `labels` → invalid Deployment. Operator + webhook missed `ignoreDifferences`. network-policies git pin `v0.1.91` predates the directory. Missing sync-wave ordering for cert-manager. |
| 6 | v0.1.103 | `component_cilium.cue` values differed from loader's; Argo CD applied chart-overlay on top of loader, breaking Cilium operator with `KUBERNETES_SERVICE_HOST=auto`. cert-manager `ignoreDifferences` missed. |
| 7 | v0.1.104 | `default` AppProject not auto-created by chart 7.7.7 or Argo CD 2.13.1 server. Every Application referencing it fails. |
| 8 | v0.1.105 | `ghcr.io/apprafter/apprafter-operator:v0.1.91` image was broken months ago (binary missing); never exercised before. `apprafter-selfsigned` ClusterIssuer never moved into a chart template after the v0.1.97 imperative-to-GitOps rewrite. `RELEASED_OPERATOR_VERSION` stale at `v0.1.64`. |
| 9 | v0.1.106 | webhook `main.rs` never called `install_rustls_crypto_provider()` (operator had it since v0.1.61). Masked since the v0.1.91 image's binary never ran. |
| 10 | v0.1.107 | chart added cue-cmp sidecar in 0.1.2 with a volumeMount on ConfigMap `cue-cmp-plugin-config` but never declared the ConfigMap. Masked through walks #5-9 by upstream blockers. |
| 11 | v0.1.108 | `argocd-cue-cmp-publish.yml` workflow tagged image as `:0.1.0` (no `v` prefix); chart pinned `:v0.1.0`. The lone workflow inconsistent with operator + webhook's `:v<version>` convention. |

The pattern reveals a class of defect this track creates and
**B.1.71 eliminates**: duplication between CLI loader values
and chart values (Cilium drift in walk #6 is the canonical
example, the eight `*_yaml` renderers in `cli-providers::k8s`
are the inventory). After B.1.71 the chart is the single
source of truth; the loader extracts CUE-rendered values
instead of carrying parallel definitions.

**Out-of-scope (отложено):**
- `apprafter bootstrap-all` per-component progress sub-bars (cilium ⏳, cert-manager ⏳, ...). Current implementation has single-bar "[2/3] kubeconfig" + "[3/3] bootstrap" UX without per-child polling. Adding `kubectl get applications -n argocd -o jsonpath='...'` poll loop is a UX-polish iteration, not blocking 1.70.
- `apprafter cluster-bootstrap --manifest <path>` flag + auto-discovery from CWD — current `APPRAFTER_MANIFEST` env-var still works. Manifest overlay → root Application's `helm.valuesObject` requires CLI knowledge of chart values shape; defer to 1.71 cutover.
- Idempotent resume на каждом шаге (pre-launch P1 requirement) — `helm upgrade --install` + `kubectl apply` уже idempotent на step level; what's NOT yet idempotent — partial state when waits timeout (e.g. argocd-server up but root Application apply failed). Defer полная resume semantics.
- E2E test (`e2e/mvp.sh`) update — currently tests imperative install. Rewriting it для GitOps path = separate iteration после first real-cluster verification.

**Зависит от:** 1.66 ✅, 1.67 ✅, 1.68 ✅, 1.69 ✅ (platform-stack chart must be publishable + CMP sidecar wired before CLI references it).

**Размер:** M (один цикл, ~3 часа — rewrite + tests + trait extension + Cargo bump).

---

### 1.71 Migrate platform component values from CLI to chart ✅

> v0.1.109 — sub-phase 1.71 shipped. `cli/cli-providers/build.rs` extracts `_loaderValues.{cilium,argocd}` + `currentVersion` from `platform-stack/cue/` at compile time. 12 dead `*_yaml` renderer files deleted; `cluster_bootstrap.rs` consumes generated constants. CUE invariants enforce chart↔loader agreement structurally.

**Source:** ADR 0025.

**Цель:** все existing Helm values builders в `cli-providers::k8s::*` переезжают в `apprafter/platform-stack/cue/components/*.cue` как CUE-typed values. CLI больше не содержит platform component конфигурации.

**Поставка:**
- [x] Audit existing CLI source:
    - `cilium_values_yaml()` → `cue/components/cilium.cue` values block
    - `cert_manager_values_yaml()` → `cue/components/cert-manager.cue` values
    - `argocd_values_yaml()` → `cue/components/argocd.cue` values (включая CMP sidecar config от 1.69)
    - `apprafter_operator_values_yaml()` → `cue/components/apprafter-operator.cue`
    - Admission webhook manifests → `cue/components/admission-webhook.cue`
    - Backstage values → `cue/components/backstage.cue` (conditional на values.domain)
    - default-deny NetworkPolicy → `cue/components/network-policies.cue`
- [x] Self-managing Argo CD: Argo CD's own Application within chart has `syncPolicy.automated.prune: false` to prevent self-destructive upgrades.
- [x] Delete migrated Rust code from `cli-providers::k8s::*`.
- [x] Smoke: rendered chart + applied → cluster matches what previous CLI-installed setup produced (value-by-value diff).

**Acceptance:**
- `git grep -E "(cilium_values|cert_manager_values|argocd_values|backstage_values)_yaml" cli/` returns no matches in source (only possibly in tests as legacy reference).
- Tier 1 bootstrap через new pipeline produces functionally identical cluster (Cilium config, cert-manager ClusterIssuer, Argo CD UI, admission webhook).
- Argo CD UI shows Argo CD как один из child Applications с prune=false visible.

**Зависит от:** 1.66, 1.70

**Размер:** M

---

### 1.71b Close remaining version drift classes ✅

> v0.1.110 — sub-phase 1.71b shipped.

**Source:** Track B.1.71's "Deferred to follow-up" closure note.

**Цель:** close the 6 version-duplication classes B.1.71 explicitly carved out — Cilium + Argo CD upstream chart versions, operator + admission-webhook image tags, cue-cmp image version.

**Поставка:**
- [x] `_loaderValues.{cilium,argocd}` schema extended with `chartVersion` field; CUE invariant `_components.<comp>.version ≡ _loaderValues.<comp>.chartVersion`; build.rs emits `CILIUM_CHART_VERSION` + `ARGOCD_CHART_VERSION`; `helm.rs#CILIUM_CHART_VERSION` + `argocd_values.rs` deleted.
- [x] `operator/charts/<chart>/Chart.yaml#appVersion` becomes SoT for operator + webhook image tag; `values.image.tag` dropped from both component cues; build.rs reads both Chart.yaml via line-prefix grep, asserts equal, emits `RELEASED_OPERATOR_VERSION`; `image_ref.rs#RELEASED_OPERATOR_VERSION` deleted.
- [x] `argocd-cue-cmp/VERSION` → `argocd-cue-cmp/version.cue` (`package argocdcuecmp; version: "0.1.1"`); chart's `component_argocd-cue-cmp.cue` imports the package and uses `argocdcuecmp.version`; publish + check workflows read via `cue export -e version --out text` (setup-cue step added to detect job).

**Acceptance:**
- `cargo test --workspace` clean inside `nix develop` (or with `~/bin/cue` wrapper) — 3 new regression tests added.
- Chart-YAML byte-equivalent: `cue export -e _components.<comp>` diff before/after empty for cilium, argocd, apprafter-operator, admission-webhook, argocd-cue-cmp.
- No hand-maintained version const in `cli-providers/src/k8s/*.rs` for the affected classes (verified by `grep RELEASED_OPERATOR_VERSION\|CILIUM_CHART_VERSION\|ARGOCD_CHART_VERSION cli/cli-providers/src/k8s/*.rs` returning only generated consts in `loader_values.rs`).
- Real-cluster walk verifies no behavioural regression vs 0.1.13.

**Зависит от:** 1.71 ✅.

**Размер:** S (один цикл, 3 tasks + closure).

---

### 1.72 PlatformStack CRD schema + admission webhook
> 🏁 SR: A · order 2 — PlatformController + MigrationPlan CRD, condensed (1.72–1.78); closes killer features #3 + #7. SPLIT: 4.16 Backstage MigrationPlan plugin → C

**Source:** ADR 0026.

**Цель:** CUE-typed schema для PlatformStack CR + admission webhook validation.

**Поставка:**
- [x] `schemas/v1alpha1/platformstack.cue` — full schema per spec.md §3.11:
    - `spec.channel` (enum stable | beta | edge)
    - `spec.pin` (optional, semver string)
    - `spec.autoUpgrade` (bool, default false)
    - `spec.source.upstream` + `spec.source.repoURL` (OCI references)
    - `spec.source.checkInterval` (duration, default 6h)
    - `spec.values` (free-form, tier/domain/etc.)
    - `spec.overrides` (per-component freezes)
    - `status` with currentVersion, **targetVersion**, availableVersion, lastUpstreamCheck, components[], versionHistory (ring buffer), conditions[]
- [x] Generated OpenAPI v3 schema (hand-rolled mirror in `operator/charts/apprafter-operator/templates/crd-platformstack.yaml`; Application CRD restored in `crd-application.yaml`, sync-wave -5 both).
- [x] Admission webhook validation rules:
    - Exactly one PlatformStack CR per cluster (rejected if a second is created), named `default` в namespace `apprafter-system`.
    - `spec.channel` is one of `stable | beta | edge`.
    - `spec.source.checkInterval` ≥ 1h (prevent rate-limit abuse).
    - `spec.pin` is valid semver if set.
- [x] Bootstrap integration: 1.70 step adds creation of default `PlatformStack` CR с `spec.channel: stable`, `spec.pin: unset`, `spec.source.upstream/repoURL = oci://ghcr.io/apprafter/platform-stack`.

**Acceptance:**
- `kubectl apply` of a second PlatformStack CR rejected by admission webhook.
- Invalid channel value rejected.
- Default PlatformStack created during bootstrap is visible через `kubectl get platformstack default -n apprafter-system`.

**Зависит от:** 1.70 (bootstrap creates the CR)

**Размер:** S

---

### 1.73 PlatformController core: reconcile loop + OCI client + diff

**Source:** ADR 0026.

**Цель:** core PlatformController component — kube-rs reconcile loop, OCI registry client, helm render + diff vs current state, patches umbrella Argo CD Application.

**Поставка:**
- [x] ~~New crate `operator-platform-controller/` в workspace~~ — **адаптировано**: PlatformController landed как новый workspace member `operator-controllers/platform-stack` (peer to `operator-controllers/application`), запускается в том же `apprafter-operator` binary как второй controller (session 2026-05-20 design adapt).
- [x] kube-rs reconcile loop watching `PlatformStack` CRs.
- [x] Leader election (kube standard pattern with lease в `apprafter-system` namespace) — переиспользуется существующий `LeaderElection::for_apprafter_operator` lease; оба controllers поднимаются после acquire'a.
- [x] OCI registry client:
    - Pull chart by tag from `spec.source.repoURL` (via `oci-distribution` 0.11 + flate2/tar для compatibility.yaml extraction).
    - List available tags by channel.
- [x] ~~Helm render~~ — **delegated to Argo CD**: PlatformController patches только parent Application's `spec.source.helm.valuesObject`; Argo CD's repo-server рендерит chart через argocd-cue-cmp sidecar. Manifest-level diff против rendered output не делается в 1.73 (future enhancement если потребуется).
- [x] Diff logic: compare `parent.spec.source.helm.valuesObject` + `parent.spec.source.targetRevision` vs desired payload from PlatformStack. Classify diff using `compatibility.yaml#<version>.change` (fetched via OCI tarball pull).
- [x] On non-destructive diff (safe + requires-restart): SSA patch parent Application with field manager `platform-controller`.
- [x] On destructive diff (data-migration | breaking, OR pin unset + autoUpgrade=false): push condition (`MigrationPending=True` или `UpgradeAvailable=True`), no auto-bump. MigrationPlan auto-create deferred to 1.74 — `PolicyHooks::request_migration_plan` stub'нут в `NoOpHooks`.
- [ ] ~~Environment check at apply time: confirm cluster's k8s version ≥ chart's `minimumKubernetesVersion`~~ — **deferred**: chart's `compatibility.yaml` shape пока не объявляет `minimumKubernetesVersion`. Future iteration (add field в compatibility schema + reconciler check). Не блокирует 1.73 acceptance — chart's `kubeVersion` constraint в `Chart.yaml` уже даёт helm-level guard.
- [x] Status updates: `currentVersion`, `targetVersion`, `availableVersion`, `lastUpstreamCheck`, `conditions[]`. `components[]` + `versionHistory[]` поля присутствуют в schema но пока не заполняются (требует full child-app health introspection — separate future task).

**Walk-found / additional deliverables (B.1.73 expanded beyond plan.md base):**
- [x] Single-writer pattern via SSA field manager `platform-controller` (single writer for `spec.source.{targetRevision, helm.valuesObject}`).
- [x] Outside-writer detection via `metadata.managedFields` — foreign field manager на spec.source ⇒ force-revert + `UnauthorizedSourceModification=True` condition.
- [x] Conservative race resolution — wait for parent App Sync=Synced before next bump (no aggressive cancel of in-flight syncs).
- [x] Chart-side override pattern в `_applicationsTemplate`: `.Values.overrides.<component>.{pin, values, enabled}` projects onto rendered children (mergeOverwrite на values, replace на pin/enabled).
- [x] Hooks для 1.74 / 1.74a — `PolicyHooks` trait + `NoOpHooks` default impl.

**Acceptance:**
- Edit `PlatformStack.spec.pin` from `0.2.0` to `0.2.1` (с safe-only changes в compatibility metadata) → controller pulls chart 0.2.1, computes diff classified as safe, patches umbrella Application; child Applications (Cilium etc.) reconcile to new versions within ~3 minutes.
- Edit `spec.overrides.cilium.pin: "1.16.5"` while platform is on 0.2.1 → Cilium frozen even after stack bump to 0.2.2.
- k8s version mismatch — clear error in `status.conditions`, no patch applied.

**Зависит от:** 1.71 (umbrella chart structure), 1.72 (CRD)

**Размер:** L — distributed-systems penalty applies (new distributed component, leader election, OCI client reliability)

---

### 1.74 PlatformController upstream check + status updates

**Source:** ADR 0026.

**Цель:** periodic check task, version history tracking, UpgradeAvailable condition surfacing.

**Поставка:**
- [x] Periodic check task spawned by PlatformController (`Action::requeue(spec.source.checkInterval)` + watch events on PlatformStack + parent Application; реализовано в B.1.73):
    - Pull OCI tag list from `spec.source.upstream` (via `oci-distribution` Rust crate)
    - Filter by channel (stable / beta / edge via semver-suffix conventions, see `oci::channel_matches`)
    - Pick latest semver tag
    - Update `status.availableVersion`, `status.lastUpstreamCheck`
- [x] `status.versionHistory` ring buffer (capped at 10, FIFO). On each successful SSA patch that actually changes `targetRevision`, push `{version, appliedAt, outcome: "succeeded"}`. `append_version_history` helper в `status.rs`.
- [x] `status.conditions`:
    - `Ready` — derived from `parent.status.health.status` (B.1.74).
    - `UpgradeAvailable` — semver comparison `channel_latest > target_for_patch` (B.1.73 walk-fix #3).
    - Plus `Synced`, `MigrationPending`, `UnauthorizedSourceModification` (B.1.73).
- [x] Auto-upgrade logic: pin OR autoUpgrade=true + safe class → SSA patch parent Application. Breaking/data-migration → push `MigrationPending=True` (B.1.75 will land actual MigrationPlan auto-create).
- [ ] ~~Caching: ETag-aware OCI requests~~ — **deferred**. Existing `MIN_OCI_POLL_INTERVAL_SECS=60` throttle + cached `availableVersion` reuse already saturate the bandwidth concern. ETag would shave bytes-per-poll without changing cadence; YAGNI per CLAUDE.md.

**Acceptance:**
- Publish new platform-stack version (0.2.2 with safe changes only) → within `checkInterval` (или after manual `kubectl annotate platformstack default apprafter.io/refresh-upstream=true`), `status.availableVersion = 0.2.2`.
- With `autoUpgrade: true` + safe classification → controller bumps spec.pin → reconcile path completes → status.currentVersion = 0.2.2.
- With `autoUpgrade: true` + new version classified as breaking → MigrationPlan created (см. 1.78); no spec.pin bump.
- `kubectl get platformstack default -o jsonpath='{.status.versionHistory}'` shows history entries.

**Зависит от:** 1.73

**Размер:** S

---

### 1.74a Yanking support для опубликованных platform-stack версий

**Source:** ADR 0028 (extension, motivated by "published-with-bug" scenario).

**Цель:** возможность retroactively пометить конкретную опубликованную версию platform-stack как yanked. Controller перестаёт предлагать её новым пользователям через `availableVersion`, существующие кластеры на этой версии получают warning, но не форсятся автоапгрейдом. Аналог `cargo yank` / `npm deprecate` / PyPI yank для OCI-distributed chart.

**Зачем:** OCI tag immutable per (repo, version) → если опубликовал версию с регрессией, единственный путь — publish next patch, но нет механизма мягко увести с битой версии тех кто на ней. Yanking даёт «soft recall» без принудительного апгрейда (всё ещё уважает MigrationPlan семантику).

**Поставка:**

- [x] Extend `compatibility.cue` schema в `apprafter/platform-stack/`:
    ```cue
    versions: [_]: {
        classification: "safe" | "breaking"
        // новые поля:
        yanked: bool | *false
        yankedReason?: string  // required when yanked=true
    }
    ```
- [x] CI guard в `platform-stack-publish.yml` (расширение 1.68 валидации compatibility.cue): PR ставящий `yanked: true` без непустого `yankedReason` → fail с понятным сообщением. Реализовано в обоих workflow'ах: `platform-stack-check.yml` (PR time) + `platform-stack-publish.yml` (publish time). Текст «PR без bump version → публикация не триггерится» в исходной формулировке преждевременен: текущая drift-detection логика заставит делать bump чтобы chart source change достиг master без CI fail; revisit при first practical yank scenario.
- [x] PlatformController (расширение 1.74) изменения:
    - `availableVersion` resolution через channel skip'ает entries с `yanked: true`. Кластер с `spec.channel: stable` видит только non-yanked stable версии. Реализовано в `resolve_non_yanked_latest` + `tags_in_channel` (вместо `latest_in_channel`) + `fetch_compatibility_doc` pull на top channel tag.
    - Если `status.currentVersion` matches yanked entry → push condition `YankedVersion=True` с `Message: <yankedReason>`, surfaces в `kubectl describe platformstack`. Условие — informational/warning, не Ready=False. Реализовано через `COND_YANKED_VERSION` константу + reconcile loop emit.
    - Upgrade flow **не модифицируется** — yanked это метаданные про версию, не override на user policy. ✓ (existing code uses target_for_patch independent of yank status).
    - Если `spec.pin` точно указывает на yanked версию → condition `YankedVersion=True`, pin остаётся в силе. ✓ (lookup over `target_for_patch` includes pinned versions; UpgradeAvailable + safe-class auto-bump natural flow does not change).
- [ ] Surface yank warning в UI'ях с framing «update strongly recommended»: deferred to `apprafter platform` CLI subcommand work (B.1.8?) и Backstage platform plugin (Phase 2). На данном этапе warning visible через `kubectl describe platformstack default` → `Conditions` section + Kubernetes Events (через standard PlatformStack visibility — не требует UI shim).

**Acceptance:**

- Publish `platform-stack/v0.2.5` нормальный → fresh кластер с `channel: stable` резолвит `availableVersion=0.2.5`.
- Update `compatibility.cue` (PR без bump): для `0.2.5` поставить `yanked: true, yankedReason: "regression в X"`, publish `0.2.6` → fresh кластер резолвит `availableVersion=0.2.6` (skip 0.2.5).
- Кластер уже на `0.2.5`, `spec.autoUpgrade: false`: `status.conditions` содержит `YankedVersion=True` с reason, `apprafter platform status` показывает warning «update strongly recommended → 0.2.6», `spec.version` без изменений (manual policy уважена).
- Кластер уже на `0.2.5`, `spec.autoUpgrade: true`, `0.2.6` classification=safe: normal safe-upgrade path срабатывает → controller бампает на `0.2.6` (yank ничего не меняет в policy, просто получилось что естественный апгрейд уводит с битой версии).
- `spec.pin: "0.2.5"` (explicit) на yanked версии → warning есть, но pin не меняется (явный user choice уважён).
- CI guard fail на PR ставящем `yanked: true` без `yankedReason`.

**Зависит от:** 1.74 (PlatformController + status fields)

**Размер:** S

---

### 1.75 Unified MigrationPlan CRD + admission webhook

**Source:** ADR 0027.

**Цель:** unified MigrationPlan CRD с scope discriminator (application | platform).

**Поставка:**
- [x] `schemas/v1alpha1/migrationplan.cue` per spec.md §3.8 rewrite:
    - `spec.scope.type` (enum, application | platform)
    - `spec.scope.application` (required if type=application): ref, environment
    - `spec.scope.platform` (required if type=platform): affected components list
    - `spec.trigger` (kind + field-specific data)
    - `spec.risks` (classification, estimatedDowntime, dataVolume, reversible, requiresFullBackup)
    - `spec.plan[]` (steps with action, estimatedDuration, reversible)
    - `spec.approvers[]` (emails)
    - `spec.previousSpecSnapshot` annotation (for platform-scope rollback)
    - `status.phase` (pending-approval | approved | rejected | executing | completed | failed)
    - `status.approvedBy`, `status.approvedAt`
    - `status.executedSteps[]`
- [x] OpenAPI v3 schema with `oneOf` discriminator on `spec.scope.type`. Реализовано без `oneOf` в structural schema (apiserver rejects most oneOf shapes in CRDs); вместо этого scope.{application,platform} оба optional на CRD layer, conditional invariant enforced webhook'ом.
- [x] Admission webhook deeper validation:
    - [x] Required fields per scope type — `validate_application_scope` + `validate_platform_scope` в `validator_migrationplan.rs`.
    - [x] Approver email format validation — `is_emailish` (light RFC5322).
    - [x] Reject changes to `spec.scope` after CR creation (immutable) — UPDATE-time check via `AdmissionRequest.oldObject`.
    - Deferred to B.1.76: reject `status` patches not from MigrationController. Controller doesn't exist в 1.75; защищать status сейчас означало бы `Unable to find auth principal` корнер кейсы. Защита status'а — concern controller-existence-aware и B.1.76 lands it as part of MigrationController wiring (controller владеет всеми status'ами через единственный SSA field manager `migration-controller`; admission webhook отвергает status patches от других managers).

**Acceptance:**
- `kubectl apply` valid application-scope MigrationPlan succeeds.
- `kubectl apply` valid platform-scope MigrationPlan succeeds.
- Apply with missing scope-required fields → rejected.
- Apply with invalid approver emails → rejected.

**Зависит от:** —

**Размер:** S

---

### 1.76 MigrationController + strategy dispatch

**Source:** ADR 0027.

**Цель:** MigrationController reconciler with Rust trait dispatch для application + platform strategies.

**Поставка:**
- [x] Extend `apprafter-operator` workspace с `MigrationController` reconciler. Реализован как новый workspace member `operator-controllers/migration` (peer to application + platform-stack), spawn'ится из main.rs после acquired lease.
- [x] `MigrationStrategy` trait (отклонение от pseudo-code в plan.md):
  ```rust
  trait MigrationStrategy {
      async fn execute_step(&self, plan: &MigrationPlan, step: &MigrationStep) -> Result<StepOutcome, MigrationError>;
      async fn reject(&self, plan: &MigrationPlan) -> Result<(), MigrationError>;
  }
  ```
  - `detect_destructive` + `create_plan` **НЕ** в trait — signatures differ per scope (Application diff vs version+compat-doc), forcing one shared signature через associated type или generic context либо breaks trait-object dispatch либо loses information callers need. Detection лежит как concrete fn per strategy struct; B.1.77 + B.1.78 callers wire их in.
- [x] `ApplicationMigrationStrategy` impl: skeleton в B.1.76 — `execute_step` returns Succeeded (free-form action text без machine semantics в 1.75/1.76 schema), `reject` no-op per ADR 0027. Detection concrete fn deferred to B.1.77 (caller сам в Application reconciler знает diff).
- [x] `PlatformMigrationStrategy` impl: `execute_step` skeleton Succeeded; `reject` **real** — reads `plan.spec.previousSpecSnapshot.pin`, SSA-patches `PlatformStack.spec.pin` back с field manager `migration-controller-strategy` (different from `platform-controller` чтобы differentiate). Идемпотентно — repeated rejects byte-equivalent. Detection deferred to B.1.78.
- [x] Reconcile loop processes MigrationPlans in phase=executing, executes plan steps sequentially, updates status. `executed_steps.len()` doubles as progress marker — replay-safe (mid-step reconcile re-runs idempotent step). Step failure → seal в `failed`; all-steps-done → `completed`.
- [x] Approve transition: `pending-approval → approved` (external) → controller writes phase=executing then runs step-by-step.
- [x] Reject transition (platform-only): `pending-approval → rejected` (external) → controller invokes `PlatformMigrationStrategy.reject()` which reverts `PlatformStack.spec.pin` via SSA. Annotation source (`apprafter.io/previous-spec`) per plan.md прозаически переписан на `spec.previousSpecSnapshot` field (already in 1.75 CRD schema) — annotation approach был ADR 0027 placeholder, structured field cleaner.

**Acceptance:**
- MigrationPlan в pending-approval state — controller doesn't touch underlying resources.
- Patch status.phase = approved → controller starts executing.
- Patch status.phase = rejected on platform-scope plan → PlatformStack.spec.pin reverts to previous.
- Patch status.phase = rejected on application-scope plan → admission webhook rejects the patch (no reject for application scope per ADR 0027).

**Зависит от:** 1.75

**Размер:** M

---

### 1.77 Application reconciler integration: gate pause/resume

**Source:** ADR 0027.

**Цель:** existing `Application` reconciler (delivered в Phase 1) теперь respects pending MigrationPlans — pauses child resource patching, sets status.phase=AwaitingMigrationApproval.

**Поставка:**
- [x] Update Application reconciler (`operator/operator-controllers/application/src/lib.rs`):
    - Before patching child resources (Deployment, Service), check for existing MigrationPlan в namespace `apprafter-system` with phase non-sealed (matches `pending-approval` | `approved` | `executing` | `failed` | empty; resumes on `completed` | `rejected`). Filter pulls scope.type=application AND scope.application.ref.{name,namespace} matching this app AND scope.application.environment matching ctx.env_name (skipped when env is None — wildcard).
    - If found: skip child patching, set `Application.status.phase = AwaitingMigrationApproval` + `Ready=False/MigrationPending` + `MigrationPending=True/MigrationPlanPending` (plan name in message). EndpointURL preserved (children still running prior version). Requeue 30s.
    - If no pending plan: continue normal reconcile.
    - Detection (`ApplicationMigrationStrategy::detect_destructive`) NOT invoked в B.1.77 reconcile — current v1alpha1 Application schema (image / replicas / expose / env) per spec.md §3.8 carries no destructive operations, so detect always returns None. Concrete fn signature `(old, new) -> Option<DestructiveChange>` shipped on the strategy struct + `create_plan_for(...)` builder for future Phase 2.x callers wiring detection alongside `needs.*` / storage class / breaking image migration schema fields.
- [x] Custom Argo CD health check (Lua script в argocd-cm ConfigMap via chart's `configs.cm.resource.customizations.health.apprafter.io_Application` key) for Application CR. Returns `Degraded` with the MigrationPlan name in the message when `Application.status.phase=AwaitingMigrationApproval` (reads `status.conditions[type=MigrationPending].message` for the verbatim text). Returns `Healthy` on `phase=Ready`. Surfaces в Argo CD UI as `Degraded` card.

**Acceptance:**
- User pushes destructive change в app repo (e.g., changes `needs.pg.selector`) → Argo CD syncs Application CR → reconciler creates MigrationPlan and pauses → Deployment continues running с prior version, Application UI shows Degraded with MigrationPlan reference.
- Approve plan через `kubectl patch migrationplan <name> -p '{"status":{"phase":"approved"}}' --type=merge --subresource=status` (или CLI/Backstage) → controller resumes, executes plan steps, Application reaches Ready.
- User revert в Git → Argo CD syncs reverted spec → reconciler observes non-destructive → existing MigrationPlan superseded.

**Зависит от:** 1.76

**Размер:** M

---

### 1.78 PlatformController MigrationPlan integration

**Source:** ADR 0027.

**Цель:** PlatformController detects destructive platform diffs, creates MigrationPlan instead of immediately patching umbrella Application.

**Поставка:**
- [x] Update PlatformController reconcile path (from 1.73):
    - [x] After computing diff and classifying, when classification != `safe`:
        - [x] Save current spec.pin в MigrationPlan **`spec.previousSpecSnapshot.pin`** (вместо `metadata.annotations[apprafter.io/previous-spec]` per plan.md placeholder — structured field из B.1.75 CRD schema preferred over annotation approach).
        - [x] Create MigrationPlan with scope.type=platform, scope.platform.components — pre-check by deterministic `platform-<from>-to-<to>` name (idempotent); если plan exists с этим name → block bump regardless of classification.
        - [x] Skip patching umbrella Application; conditions UpgradeAvailable=True/BlockedByMigrationPlan + MigrationPending=True/<class> with plan name в message.
    - [x] On MigrationPlan approved: MigrationController executes → plan reaches `completed` → PlatformController's next reconcile sees plan completed (not blocking) → patches umbrella Application; Argo CD reconciles.
    - [x] On MigrationPlan rejected: PlatformMigrationStrategy.reject() (B.1.76, already implemented) reverts PlatformStack.spec.pin к `spec.previousSpecSnapshot.pin`. Same-transition retry blocked by rejected plan presence — operator must delete plan or pin к different target.

**Acceptance:**
- Publish platform-stack 0.3.0 (with breaking changes per compatibility metadata) → PlatformController creates MigrationPlan; PlatformStack.status.conditions[UpgradeAvailable]=True with "blocked by MigrationPlan".
- Approve MigrationPlan → upgrade flows through.
- Reject MigrationPlan → PlatformStack.spec.pin reverts; status reflects.

**Зависит от:** 1.74, 1.76

**Размер:** S

---

### 1.79 CLI thin wrappers + `apprafter open` commands ✅

> v0.1.142 — sub-phase 1.79 shipped. `apprafter platform {status,upgrade}` + `apprafter migration {list,approve,reject}` + `apprafter open argocd` (port-forward + clipboard + browser launch) + npm-style version check + Argo CD UI Resource Action Lua scripts для MigrationPlan approve/reject. `platform {freeze,unfreeze,rescue}` rolled forward в 1.79a part 5 (closed v0.1.142). `platform channel` deferred к Phase 2 (multi-channel UX waits for stable/edge divergence); `open {backstage,grafana,hubble}` deferred к Tier 2+ (не tier-1 residents).

**Source:** ADR 0025, 0026, 0027.

**Цель:** CLI commands operating on declarative resources + UI access helpers + npm-style version check.

**Поставка:**
- [x] New CLI subcommands в `apprafter` binary:
    - [x] `apprafter platform status` — read PlatformStack.status, format человекочитаемо (current version, available, components healthy count, recent history). Implemented via kubectl shellout + `tabled` rendering (conditions + last-5 versionHistory).
    - [x] `apprafter platform upgrade [--to <version>]` — patch PlatformStack.spec.pin (или channel resolution if --to not specified). `--to <v>` pins; без `--to` clears `spec.pin` + flips `autoUpgrade=true`.
    - [ ] `apprafter platform channel <name>` — switch channel. **Deferred to 1.79a** — single-channel `stable` only ships в M1.5; multi-channel UX waits for Phase 2 where alternate channels actually exist.
    - [ ] `apprafter platform freeze <component> [--version <v>]` — patch overrides.<component>.pin. **Deferred to 1.79a** — component-level pinning is a polish layer over the chart-level pin already shipped; ships alongside ResourceClaim CRUD в 1.79a.
    - [ ] `apprafter platform unfreeze <component>` — remove override. **Deferred to 1.79a** (paired с freeze).
    - [ ] `apprafter platform rescue` — reinstall Argo CD from loader (emergency recovery). **Deferred to 1.79a** — covered by `apprafter cluster-bootstrap --re-adopt` path that 1.79a's loader extensions formalise.
    - [x] `apprafter migration list` — list MigrationPlans, filter by phase/scope. Filters деференцированы (CLI list iterates ALL plans; phase/scope filtering trivial follow-up if operator demand surfaces).
    - [x] `apprafter migration approve <name>` — patch status.phase=approved. Status-subresource merge-patch via kubectl.
    - [x] `apprafter migration reject <name>` — patch status.phase=rejected (rejected by webhook for application scope; works for platform). Webhook denial message surfaces verbatim.
    - [x] `apprafter open <ui>` — open browser to UI:
        - [x] `argocd` — `kubectl port-forward svc/argocd-server -n argocd 8080:443` + auto-fetch admin password from cluster secret + open https://localhost:8080. Cross-platform spawn (`xdg-open` / `open` / `cmd /c start`); blocks on child.wait() so Ctrl+C tears down the forward.
        - [ ] `backstage` — analogously. **Deferred to 1.79a / Tier 2+** — Backstage stack not tier-1 resident yet.
        - [ ] `grafana` — **Deferred Tier 2+**.
        - [ ] `hubble` — **Deferred Tier 2+**.
- [x] npm-style CLI version check on every invocation:
    - [x] Cache в `~/.cache/apprafter/version-check.json` with 24h TTL.
    - [x] Fetch latest CLI release from `api.github.com/repos/apprafter/apprafter/releases/latest`.
    - [x] If newer: print warning line at start of output ("apprafter X.Y.Z available; you have ..."). Fail-quiet — network errors / GitHub rate-limit / JSON parse failures swallowed silently (debug log only); версия check is courtesy, not operational prerequisite.
- [x] Argo CD Resource Action Lua script (added to argocd-cm ConfigMap via platform-stack chart): "Approve Migration" button on MigrationPlan resources в Argo CD UI. Discovery disables both Approve + Reject once `status.phase` leaves `pending-approval`; webhook denial of application-scope rejects surfaces в UI с the verbatim ADR 0027 message.

**Acceptance:**
- `apprafter platform status` outputs structured table within 2s.
- `apprafter open argocd` opens browser with credentials filled in within 5s on second-run (cached password).
- `apprafter migration approve <name>` succeeds; status updates within reconcile cycle.
- CLI shows update warning when version stale.
- Argo CD UI shows Approve button on MigrationPlan resources.

**Зависит от:** 1.72, 1.75, 1.76 (CRDs must exist для thin wrappers)

**Размер:** M

---

### 1.79a CLI app/repo subcommands + AppProjects + `open` polish ✅

> v0.1.142 originally; v0.1.160 + platform-stack 0.1.47 + argocd-cue-cmp v0.1.5 fully validated. Sub-phase shipped через 5 parts (AppProjects + project field; `open argocd` polish; `app {add,list,status,remove}`; `app {logs,rollback}`; `repo creds {add,list,show,rotate,remove}`) + `platform {freeze,unfreeze,rescue}` rollup. Real-cluster manual walk surfaced 12 walk-fixes (history rows below — #1 sync-wave/AppProject race, #2 standalone AppProject manifests at wave -30, #3 release-cli CUE install, #4 version_check tag stream picker, #5/#5b CMP entrypoint flat-stream + apprafter/ dir layout, #6 per-target state migration, #7 EXDEV cross-mount + richer-legacy preference, #8/#8b CMP discover glob→command + cue-cmp v0.1.4 rebuild, #9 channel-latest resolver decouples CLI from chart, #10 CMP discover stdout fix `grep -q` removed, #11 Namespace permitted в apps AppProject, #12 wizard defaults destination namespace к apprafter). Each walk-fix landed с regression-guard test; phase boundary tech-debt = zero. Deferred с rationale: interactive wizard для `repo creds add` (flag-driven sufficient, operator feedback gates); inline PAT prompt при private-repo cred miss (hint sufficient); API ping для PAT validation (format regex catches most copy-paste errors, adds flakiness); App CR conditions + pending MigrationPlan section в `app status` (Phase 2 destructive change detection prerequisite); last-used / expires в `repo creds list` (Argo CD / GitHub не surface'ят данные); `open backstage` (Tier 2+); URL pre-fill username `?username=admin` (Argo CD 7.7.7 не поддерживает — negative result).

**Source:** ADR 0025, 0026 (Argo CD projects model); продолжение 1.79.

**Цель:** убрать необходимость заходить в Argo CD UI для повседневных операций (добавление repo, deploy status, rollback) и разделить платформенные приложения от пользовательских визуально и через RBAC.

#### Поставка — AppProjects в platform-stack chart

- [x] Добавить три `AppProject` ресурса в umbrella chart (через `_loaderValues.argocd.values.configs.projects`, а не отдельную папку — Argo CD chart 7.7.7 сам создаёт AppProjects из этого block'а):
    - [x] `platform` — для core platform components. `sourceRepos: ["*"]`, `destinations: [{namespace: "*", server: "https://kubernetes.default.svc"}]`, `clusterResourceWhitelist: [{group: "*", kind: "*"}]`, `namespaceResourceWhitelist: [{group: "*", kind: "*"}]` (открыто на M1.5 — RBAC enforcement через AccessGrant приедет в Phase 4).
    - [x] `platform-providers` — для ServiceProvider operators (CNPG, Dragonfly, NATS, Kamaji). Те же permissions что и `platform`, разделение чисто визуальное + lifecycle-категория. Project заводится сейчас (а не лениво в Phase 2), чтобы UI selector показывал его сразу после bootstrap'а.
    - [x] `apps` — для user applications. `sourceRepos: ["*"]` (пока не введён RBAC через AccessGrant Phase 4), `destinations: [{namespace: "*", server: "https://kubernetes.default.svc"}]`, `clusterResourceWhitelist: []`, `namespaceResourceWhitelist: [{group: "apprafter.io", kind: "Application"}, {group: "", kind: "ConfigMap"}, {group: "", kind: "Secret"}, {group: "gateway.networking.k8s.io", kind: "HTTPRoute"}]`.
- [x] Update umbrella Helm templates — все chart-managed Applications получают `spec.project: {{ default "platform" $component.project }}` через новое поле `#Component.project: string | *"platform"`. Default = `platform`; tier overlays / ServiceProvider charts могут override на `platform-providers` per-component. CLI loader's root platform Application также переехал на `spec.project: platform` (`cluster_bootstrap::render_root_application`).
- [x] CMP plugin (`argocd-cue-cmp`) рендерит user Application CRs с `spec.project: apps` по умолчанию. **Закрыто:** `apprafter app add` wizard (`app_wizard.rs`) defaults parent Argo CD Application's `spec.project` к `apps` (clap default), а CMP-rendered user manifests (apprafter.io/Application) сами не несут `spec.project` (это Argo CD-specific поле, не AppRafter); end-to-end проверено walk-fix #10/#11/#12 на real cluster — landing-web/landing-cms apps зарегистрированы в Argo CD под project `apps`.

#### Поставка — `apprafter open` polish

- [x] `apprafter open argocd` URL → `/applications?proj=apps` по умолчанию.
- [x] Флаги `--project <name>` (default `apps`) и `--all-projects` (убирает фильтр). Конфликтуют через `conflicts_with = "project"`.
- [x] Output формат при открытии:
    ```
    $ apprafter open argocd

    Opening Argo CD UI...
      URL:       https://localhost:8080/applications?proj=apps
      Username:  admin
      Password:  H7x4kP9aB3...  (copied к clipboard)

    ✓ Browser opened
    ℹ Press Ctrl+C к stop port-forward
    ```
- [x] Password copy to clipboard через `arboard` crate (cross-platform). Fail-quiet — headless / no-clipboard envs показывают `(clipboard unavailable — copy manually)` без error'а.
- [x] Password также печатается в terminal в plaintext — юзер может подсмотреть если clipboard засрался другим контентом.
- [ ] Попытка pre-fill username через URL `?username=admin` — Argo CD UI это не поддерживает (проверил empirically на 7.7.7); оставили только display + clipboard. **Закрыто negative-result'ом.**
- [ ] Аналогичная обработка для `apprafter open backstage` (когда появится). **Deferred к Tier 2+** — Backstage не tier-1 resident.

#### Поставка — `apprafter app` подкоманды

- [x] `apprafter app add [<git-url>]`:
    - [x] Без аргумента: детектит git origin из cwd через `git remote get-url origin`, нормализует (SSH→HTTPS, убирает `.git`).
    - [x] Флаги: `--name <name>` (default = repo name), `--branch <branch>` (default = current branch для cwd-режима, `main` для explicit URL), `--path <path>` (default `/`), `--project <name>` (default `apps`), `--remote <name>` (default `origin`), `--no-ping` (skip reachability check).
    - [x] Interactive: спрашивает name/branch/path с дефолтами; non-interactive: использует defaults или fails если `--git-url` не задан. **Закрыто v0.1.145** через `cli/platform-cli/src/commands/app_wizard.rs` (Text+Select prompts, cwd-detect для path/branch/origin, inline DNS-1123 валидация); v0.1.160 (walk-fix #12) добавил шестой prompt «Destination namespace» с DNS-1123 валидацией. `--no-interactive` opt-out для CI/headless.
    - [x] Проверка доступности репо — `git ls-remote` через subprocess (поддерживает HTTPS auth check без token, для private — детект unauthorized). `--no-ping` для air-gapped CI.
    - [ ] Если репо private и не зарегистрирован cred — inline prompt: "Use existing PAT / Add new PAT / Skip". **Deferred к v0.1.141** — лендится вместе с `apprafter repo creds add`. Сейчас auth failure surfaces hint pointing к `apprafter repo creds add`.
    - [x] Пишет Argo CD `Application` CR в `argocd` namespace с label `apprafter.io/managed-by: apprafter` и annotation `apprafter.io/source: cli`. CR указывает на пользовательский repo, CMP plugin рендерит `apprafter/Application.cue` оттуда.
- [x] `apprafter app list [--project <name>] [--all-projects]`:
    - [x] Default filter `--project apps`.
    - [x] Таблица: name, project, repo, revision, sync state, health. (last sync time не surfaced — Argo CD CR не carry'ит human-friendly timestamp в `status.sync`; добавим если operator feedback потребует).
    - [x] `--all-managed` toggle drops the managed-by label filter.
- [x] `apprafter app status <name>`:
    - [x] Detail view: Argo CD Application sync/health + source + destination + recent revisions (last 3 из `status.history`).
    - [x] AppRafter Application CR conditions (если CMP уже отрендерил) + перечень child resources. **Закрыто v0.1.164** через `apprafter app status <name> --resources`/`-r` flag — рендерит Argo CD's `status.resources[]` (NAME/KIND/NAMESPACE/STATUS/HEALTH) + Pods в destination ns через operator's `app.kubernetes.io/name=<inner-name>` label (READY/STATUS/RESTARTS/AGE с kubectl-style waiting.reason heuristic — surfaces ImagePullBackOff / CrashLoopBackOff / etc. что Argo CD app-level Healthy aggregation скрывает). Pod fetch non-fatal — соблюдает Argo CD's view как authoritative для sync/health. Operator-side health propagation (CR status.phase отражающий actual Pod state) остаётся Phase 2/3 concern (ResourceClaim wait semantics).
    - [ ] Если есть pending MigrationPlan для этого app — выводит в верхней секции с approve-командой. **Deferred к v0.1.140 / Phase 2** — нужны user-app MigrationPlans из Phase 2 destructive change detection.
- [x] `apprafter app logs <name> [--follow] [--tail <N>] [--container <c>] [--pod <name>]`:
    - [x] Wrapper над `kubectl logs` с label selector `app.kubernetes.io/instance=<app-name>` (Argo CD's documented standard label, stamped на every child resource).
    - [x] Multi-pod: aggregate by default через selector form с `--prefix=true` + `--max-log-requests=10`; `--pod <name>` narrows к single pod (selector mode skipped).
    - [x] Pure helpers `build_kubectl_logs_target` + `build_kubectl_logs_args` exhaustively tested без spawning kubectl.
- [x] `apprafter app rollback <name> [--to <revision>]`:
    - [x] Без `--to`: rollback к предыдущей Git revision (читает `status.history` из Argo CD Application через pure `pick_previous_revision` helper — chronologically ordered list, second-to-last entry).
    - [x] С `--to <sha>`: rollback к указанному коммиту.
    - [x] Внутри — patch `spec.source.targetRevision` через JSON merge-patch, Argo CD ресинкает на следующем reconcile cycle.
    - [x] Confirmation prompt в interactive (`inquire::Confirm` default No), `--yes` для non-interactive.
    - [x] Pre-flight refuse когда target revision matches current (no-op).
- [x] `apprafter app remove <name>`:
    - [x] Confirmation prompt через `inquire::Confirm` (default No), `--yes` для non-interactive.
    - [x] Удаляет Argo CD Application через `kubectl delete`, в каскаде — child resources (Argo CD reconciles via ownerRefs).
    - [x] `--keep-data` опция — flips `syncPolicy.automated.prune: false` ДО delete, child resources (PVC/ResourceClaims) сохраняются.

**Alias:** [x] `apprafter a` → `apprafter app` (проверил — `apprafter apply` не конфликтует с `a` потому что clap резолвит alias строго; `apprafter a add` работает, `apprafter a apply` не существует).

#### Поставка — `apprafter repo creds` подкоманды

- [x] `apprafter repo creds add <name>`:
    - [ ] Interactive wizard для всех полей. **В v0.1.141 flag-driven only** (`--url-prefix` required, `--type pat` default, `--username git` default); token reads из stdin через `inquire::Password` masked когда `--token` opused и stdin = TTY. Wizard приедет если поступит реальный operator feedback.
    - [x] Token validation:
        - [x] GitHub: `github_pat_*` (fine-grained, 80+ char body) или `ghp_*` (classic, 40 chars total), regex check. **API ping deferred** — adds network round-trip и failure modes (rate limiting, transient network); validation gates на shape suffices для most copy-paste errors.
        - [x] GitLab: `glpat-*`, 20+ char body length check.
        - [x] Generic fallback: 20+ chars (Gitea/Codeberg/Forgejo); `--no-validate` для bypass.
        - [x] Basic auth: any non-empty password accepted.
    - [x] Создаёт k8s Secret в namespace `argocd` с labels:
        - [x] `argocd.argoproj.io/secret-type: repo-creds`
        - [x] `apprafter.io/managed-by: apprafter`
        - [x] `apprafter.io/cred-name: <name>`
        - [x] `stringData` (НЕ `data` — kubectl base64-encodes server-side): `url`, `username`, `password`.
        - [x] Annotation `apprafter.io/auth-type: <pat|basic>` чтобы `rotate` мог re-validate against original auth type.
- [x] `apprafter repo creds list`:
    - [x] Таблица: name, URL prefix, type, username. **last-used / expires deferred** — Argo CD не stamps usage timestamps на the Secret и GitHub fine-grained PATs don't expose `exp` через token shape; будем surface когда appear полезный signal.
- [x] `apprafter repo creds show <name>`:
    - [x] Detail view, password замаскирован (`****`) + pointer к `kubectl get secret -o jsonpath='{.data.password}' | base64 -d` для plaintext decode когда нужно.
- [x] `apprafter repo creds rotate <name>`:
    - [x] Prompt только для нового token, остальные поля сохраняются.
    - [x] Patch existing Secret через JSON merge-patch (не пересоздаёт — repo-server caches resourceVersion).
    - [x] Re-validation token'а перед patch против recorded `apprafter.io/auth-type` annotation.
- [x] `apprafter repo creds remove <name>`:
    - [x] **Dependency check** by default — refuses когда есть Argo CD Applications с `spec.source.repoURL` starting with the creds' `url` field. Pure helper `find_apps_matching_prefix` walks the Application list filter testable без cluster.
    - [x] `--force` skips dependency check (для migrations к а different creds entry).
    - [x] `--yes` skips только confirmation prompt (still runs dependency check).

#### Поставка — context-aware error hints

- [x] При `apprafter app add` без `.git` в cwd: hint "не удалось запустить git remote get-url ... Запусти из git-репозитория или передай URL явно через `apprafter app add <git-url>`."
- [x] При попытке `app add` для private репо без creds в non-interactive: error "git ls-remote отказал в доступе ... Зарегистрируй creds через `apprafter repo creds add` и повтори `apprafter app add`."
- [x] При попытке `app add` с конфликтным именем (Application с таким name уже есть): error "Application '<name>' уже зарегистрирован в namespace argocd. Запусти `apprafter app status <name>` чтобы посмотреть текущее состояние, или `apprafter app remove <name>` для каскадного удаления, либо передай другой `--name`."

#### Поставка — `apprafter platform` extension (закрывает остатки от 1.79)

- [x] `apprafter platform freeze <component> [--version <v>]` patches `PlatformStack.spec.overrides.<component>.pin`. Без `--version` reads effective version из `status.componentVersions.<component>` и locks that. CRD schema (`schemas/v1alpha1/platformstack.cue`) already supports `overrides` map (B.1.74 era).
- [x] `apprafter platform unfreeze <component>` — RFC 7396 merge-patch с null value strips `overrides.<component>` entry. Component falls back к chart's curated pin.
- [x] `apprafter platform rescue [--yes]` — thin wrapper over `apprafter cluster-bootstrap` с recovery confirmation banner. Use case: Argo CD self-adopt stuck (stale chart, corrupted ConfigMap, pod-eviction loop).

#### Acceptance

- [x] `apprafter open argocd` открывает UI с фильтром `apps`, username отображается в выводе, password в clipboard.
- [x] В Argo CD UI верхний project selector показывает три проекта (+ legacy `default`); `apps` пустой при свежем bootstrap, `platform` и `platform-providers` содержат соответствующие Applications.
- [x] `cd <git-repo> && apprafter app add` без аргументов корректно детектит origin и регистрирует app.
- [ ] `apprafter app add` для private репо без creds → **hint pointing на `apprafter repo creds add`** (inline interactive prompt deferred — flag-driven flow + hint sufficient).
- [x] `apprafter repo creds add` с невалидным GitHub PAT → fail с regex error до API call.
- [ ] `apprafter repo creds add` с валидным форматом но revoked token → **API ping deferred** (см. above — adds network round-trip + flakiness; format validation alone catches most copy-paste errors).
- [x] `apprafter app rollback <name>` без `--to` откатывает к предыдущей revision; Argo CD синкает в течение reconcile cycle.
- [x] `apprafter app remove` удаляет Application каскадно, `--keep-data` сохраняет PVC.
- [x] `apprafter repo creds rotate` обновляет token, existing apps продолжают синкаться без даунтайма Argo CD repo reconcile.

#### Не входит в этот item

- AccessGrant / RBAC enforcement через AppProject (Phase 4 целиком).
- Reverse proxy для `apprafter open` (отдельный item, после M2, когда понадобится Backstage с теми же проблемами).
- `apprafter app scale`, `apprafter app env set` — высокоуровневые ops-команды (M2+, после ServiceProvider/ResourceClaim).
- Backstage Application plugin — отдельный item в Phase 3.

**Зависит от:** 1.79 (CLI thin wrappers infrastructure + `open` для argocd базовый).

**Размер:** M

---

### 1.79b CLI app ergonomics — `app open` + scaffolding + runtime templates ✅

> v0.1.174 + platform-stack 0.1.48 + argocd-cue-cmp v0.1.6 — sub-phase 1.79b shipped через parts 1–3b: `apprafter app open <name>` (part 1, v0.1.161 — port-forward + Service-resolution + browser launch + graceful Ctrl+C), runtime detection primitives (part 2, v0.1.166 — filesystem-marker → runtime mapping с High/Medium/Low/Fallback confidence), `apprafter app scaffold` + embedded `.cue.hbs` template engine (part 3, v0.1.167) + scaffold wizard в `app add` step 0 + interactive runtime picker (part 3b, v0.1.168). Real-cluster manual walk surfaced walk-fixes (post-B.1.79b #1–#4 v0.1.162–165: app-open label-resolution off operator's `app.kubernetes.io/name` + kubectl stderr surfacing + `app status --resources` child workload state + Cargo.lock/bun-smoke sync; post-Part-3b #1–#6 + #11 v0.1.169–174 + chart 0.1.48 / cue-cmp v0.1.6: scaffold UX/SPDX/namespace/cred-hint polish, `spec.source.path` absolute-path fix, CUE-import drop, schema inline→vendored CUE module под `apprafter/cue.mod/`, image-ref derived from git origin, CMP entrypoint cds into package dir). Each walk-fix landed с regression-guard test; phase boundary tech-debt = zero. Design divergences (приняты): template engine ships 2 consolidated `.cue.hbs` (default + blank) вместо 12 per-runtime files (port defaults baked into `defaults_for`); multi-stack default = first-High-in-order. Deferred с rationale (Part 4, ещё не отгружено): `examples/applications/` reference manifests, `docs/user-guide/cli/app-scaffold.md`, quickstart update, `spec.resources`/`spec.healthcheck` template fields (v1alpha1-only сейчас), `--lang ru|en` template comments (English-only).

**Source:** Продолжение 1.79a. Closes gaps в quickstart flow для unfamiliar users.

**Цель:** убрать k8s complexity из первого запуска приложения. Юзер не должен знать про port-forward / kubectl, и не должен с нуля писать `apprafter/Application.cue` если у него стандартный stack.

#### Поставка — `apprafter app open <name>`

- [x] Wrapper над `kubectl port-forward` для пользовательского app'а:
    - Резолвит Application name → Service в namespace (через AppRafter Application CR labels).
    - Определяет primary port из Application.expose.port или Service.spec.ports[0].
    - `kubectl port-forward svc/<app> 8080:<port>` в background process.
    - Открытие `http://localhost:8080` в браузере через `open` (Linux/Mac) / `start` (Windows) / `xdg-open`.
    - Output формат:
        ```
        $ apprafter app open my-parser

        Forwarding to my-parser on namespace 'default'...
          Service:   my-parser
          Port:      3000 (container) → 8080 (localhost)
          URL:       http://localhost:8080

        ✓ Browser opened
        ℹ Press Ctrl+C to stop port-forward
        ```
- [x] Флаги:
    - `--port <port>` — override local port (default 8080, со shift на 8081/8082/etc. если занят).
    - `--container-port <port>` — override container port если app exposed multiple.
    - `--no-browser` — только port-forward, без открытия браузера (для CI/scripts).
- [x] Error handling:
    - App не найден → "Application '<name>' not found. List with `apprafter app list`."
    - App not Healthy → warning "Application is in state <state>; port-forward may fail. Continue anyway? [y/N]".
    - Local port занят → auto-increment до 8090, дальше error.
    - kubectl missing → error с hint к target add.
- [x] Graceful shutdown по Ctrl+C — kill port-forward, exit clean.

#### Поставка — Runtime detection в `apprafter app add`/`scaffold`

- [x] Detection heuristic из cwd:

  | Маркер | Detected runtime | Priority |
      |---|---|---|
  | `bun.lock` или `bun.lockb` | `bun` | High |
  | `pnpm-lock.yaml` | `node-pnpm` | High |
  | `yarn.lock` | `node-yarn` | High |
  | `package-lock.json` | `node-npm` | High |
  | `package.json` без lock-файла | `node-npm` (fallback) | Medium |
  | `pyproject.toml` с `[tool.poetry]` | `python-poetry` | High |
  | `pyproject.toml` с `[tool.uv]` или `uv.lock` | `python-uv` | High |
  | `Pipfile` | `python-pipenv` | High |
  | `requirements.txt` без других | `python-pip` | Medium |
  | `Cargo.toml` | `rust` | High |
  | `go.mod` | `go` | High |
  | `Dockerfile` без других маркеров | `docker` (build-only template) | Low |
  | Ничего | `blank` (пустой шаблон с TODO) | Fallback |

- [x] Confidence levels:
    - `High`: явный lock-файл = runtime установлен, версии воспроизводимы. Default-select без вопросов в auto-mode.
    - `Medium`: маркер есть, но lock отсутствует — менее уверенно, confirm prompt всё равно.
    - `Low` / `Fallback`: prompt со списком всех runtimes, юзер выбирает руками.

- [x] Multiple маркеры одновременно (monorepo, мультистек):
    - Если детектится 2+ runtime с High confidence — prompt со списком, default = первый по алфавиту.
    - Можно подсказать через CLI флаг `--runtime <name>` сразу для non-interactive.

#### Поставка — Application.cue templates

- [x] Template engine: Handlebars-like substitution на статичных `.cue.hbs` файлах в CLI binary через `include_str!` (embedded в release).
- [x] Variables в шаблоне:
    - `{{app_name}}` — из cwd name или CLI flag.
    - `{{image_ref}}` — placeholder `ghcr.io/<org>/<app>:latest` для пользовательской подстановки.
    - `{{primary_port}}` — defaults per runtime (bun/node: 3000, python: 8000, rust/go: 8080, docker: 8080).
    - `{{healthcheck_path}}` — default `/health` со комментарием "// adjust if your app uses different path".
- [x] Шаблоны (`cli/templates/application/*.cue.hbs`):
    - `bun.cue.hbs` — runtime=bun, build с bun build script.
    - `node-pnpm.cue.hbs`, `node-yarn.cue.hbs`, `node-npm.cue.hbs` — соответствующий package manager в build steps.
    - `python-poetry.cue.hbs`, `python-uv.cue.hbs`, `python-pipenv.cue.hbs`, `python-pip.cue.hbs`.
    - `rust.cue.hbs` — cargo build --release.
    - `go.cue.hbs` — go build, static binary.
    - `docker.cue.hbs` — assume Dockerfile в корне, no build steps generation (юзер сам Dockerfile управляет).
    - `blank.cue.hbs` — пустой Application с TODO-комментариями на все required поля.
- [x] Каждый шаблон содержит:
    - `apiVersion`, `kind`, `metadata.name`
    - `spec.image` — placeholder
    - `spec.expose` — minimal (port + comment "set public: true и hostname when ready to expose")
    - `spec.resources` — sensible defaults (100m CPU / 128Mi RAM с комментарием "tune based on observed usage")
    - `spec.healthcheck` — default path `/health` с note про customization
    - Inline-комментарии на русском или английском объясняющие что каждое поле делает (selectable через `--lang ru|en`, default `en`)

#### Поставка — Scaffold flow в `app add` и `app scaffold`

- [x] `apprafter app add` (расширение из 1.79a):
    - Шаг 0 (before any prompts): проверка наличия `apprafter/Application.cue` в cwd.
    - Если **отсутствует**:
        - Run runtime detection.
        - Wizard prompt: "No `apprafter/Application.cue` found. Generate one? [Y/n]". На "Y" — continue scaffolding.
        - List с pre-selected default = detected runtime. Юзер может выбрать другой.
        - Запрос на app name (default = repo dir name).
        - Confirm: "Generate `apprafter/Application.cue` and `.gitignore` entries?".
        - Создание файла из template, append `.apprafter/local/` в `.gitignore` если отсутствует (для будущих local secrets).
        - Print "✓ Created apprafter/Application.cue — review and adjust before committing".
    - Если **присутствует**: пропускает scaffold step, идёт к existing flow (`git remote get-url origin` → register Application).
    - В non-interactive mode без `--scaffold`: если файл отсутствует — fail с hint к `apprafter app scaffold`.

- [x] `apprafter app scaffold` — standalone команда для re-scaffolding или explicit-only flow:
    - Без аргументов: detection + interactive wizard, генерит файл.
    - Флаги: `--runtime <name>` (override detection), `--name <app>`, `--lang ru|en` (комментарии), `--force` (overwrite existing).
    - Без `--force` отказывается перезаписать existing `apprafter/Application.cue` — exit code 2.

#### Поставка — README updates + examples directory

- [ ] `examples/applications/` в monorepo — реальные working Application.cue для каждого preset (используются как fixture для тестов template engine + reference в docs). **Deferred — Part 4 (ещё не отгружено).**
- [ ] `docs/user-guide/cli/app-scaffold.md` — описание templates, runtime detection logic, customization guide. **Deferred — Part 4 (ещё не отгружено).**
- [ ] Update `docs/operator-guide/quickstart.md` — шаг "Write Application.cue" заменён на "Run `apprafter app add` — it scaffolds for you". **Deferred — Part 4 (ещё не отгружено).**

#### Acceptance

- [x] `cd <bun-project> && apprafter app add` детектит bun, генерит `apprafter/Application.cue` с bun preset, регистрирует Argo CD Application.
- [x] `apprafter app open <name>` после `apprafter app status` показывающего Healthy → port-forward работает, browser открывается на app'е.
- [x] `apprafter app open` для app в Pending/CrashLoopBackOff показывает warning, но всё равно делает port-forward по confirmation.
- [x] Multiple маркеры (e.g., python-poetry + Dockerfile) → prompt со списком, не auto-pick.
- [x] `apprafter app scaffold` для пустого репо генерит `blank` template с TODO-комментариями.
- [x] `apprafter app scaffold` для существующего `Application.cue` без `--force` → exit 2.
- [x] Generated `apprafter/Application.cue` проходит `cue vet` (валидный CUE).
- [ ] Generated файл с `image` placeholder + push в репо → Argo CD синкает; AppRafter Application reaches `OutOfSync` / `Suspended` until юзер обновит image. Status condition объясняет что делать. **Partial** — scaffold + push + Argo CD sync через CMP shipped (ImagePullBackOff на placeholder-image видно через `apprafter app status --resources`, walk-fix #3); operator-side `Suspended` phase + explanatory status condition остаётся Phase 2/3 (CR health-propagation, как app-status в 1.79a).

#### Не входит в этот item

- Auto-generation Dockerfile для runtime presets (отдельный future item, нетривиально и небезопасно).
- Backstage Software Templates integration (Phase 3, Backstage plugin).
- Live `cue vet` + linting в CLI на каждом save (Phase 3+).
- AI-assisted Application.cue refinement (вне scope OSS платформы).

**Зависит от:** 1.79a (`apprafter app add` базовый flow, AppProjects, repo creds).

**Размер:** S-M

---

### 1.79c Private-repo credential flow — `SourceCredential` CRD
> 🏁 SR: A · order 3 — private-repo credential flow (`SourceCredential`, ADR 0039); **must follow the 2.11 SealedSecrets controller+seal slice** в SR-порядке (cross-phase dep — phase-номера немонотонны: Phase-1 item выполняется после Phase-2 slice, это ожидаемо; см. `speedrun-plan.md` §4.2).
>
> ✅ **ЗАКРЫТО** (walk пройден чисто 2026-06-01, без багов; запушено, образы opera­тора v0.1.137 + platform-stack 0.1.51 опубликованы, кластер сошёлся). S0–S5 + acceptance #1/#2/#3/#5/#6 валидированы на живом кластере. **Остаётся только осознанно отложенное** (не долг, cross-phase): acceptance #4 live-wiring (admission создаёт MigrationPlan + pause на host-removal) co-отложен с application-scope **B.1.77**; config-repo (GitOps) delivery → **Phase-3 Backstage**. Работа велась на `master`, design+plan в `docs/superpowers/{specs,plans}/2026-05-30-1-79c-*`. S0–S4 ВАЛИДИРОВАН end-to-end на живом кластере: `repo creds add`→seal→derive, `app add`→Argo клонит приватный репо→под тянет приватный ghcr-образ (1-й acceptance), `app remove`→Argo каскадит CR→оператор+ownerRef убирают workload без зависания. Walk-fixes #1 (seal-label `/`), #2 (registry-host lowercase), #4 (operator `deletionTimestamp`-guard), #6 (Argo cascade finalizer name — `resources-finalizer`, не `-finalization`); тупиковые #3/#5 откачены в #6. **S5 поставлен** (validity-probe · coverage-gate `confirmed` · derived-Secret GC finalizer · scoped CLI RBAC seed · `detect_destructive` классификатор) одним координированным релизом. Версии: CLI `0.1.184` (тег `v0.1.184` локально) · operator `v0.1.137` · platform-stack `0.1.51`. **Ждёт:** пользователь пушит master → CI публикует operator/webhook образы + platform-stack чарт → auto-update кластера сходится → ручной walk (acceptance #2/#3/#4 + validity + GC; см. инструкции в ответе ассистента). **spec.md уже актуализирован** (Revision 9: §3.12 SourceCredential, §4.5 деривация+validity, §4.7, CLI-секция — описывает весь ADR 0039 включая S5-поведения; новой правки не требует — план-заметка отставала).
> **S0 ✅** (v0.1.175 + platform-stack component, chart-only): sealed-secrets controller компонент (bitnami 2.18.6, ns `apprafter-system`, `fullnameOverride` пинит Service) + **нативный Rust-seal** в `cli-providers::k8s::sealing` (RSA-OAEP-SHA256 ⊗ AES-256-GCM single-use, strict scope, bitnami wire-format; cert fetch через kube API service-proxy `KubectlRunner::get_raw`) + команда `apprafter secret seal`. Вынесенный вперёд prereq-slice из 2.11.
> **S1 ✅** (v0.1.176): `SourceCredential` CRD в 3 слоя — CUE schema + example; kube-rs тип (per-half status conditions); OpenAPI v3 CRD (sync-wave -5); admission `validator_sourcecredential.rs` (at-least-one-of git/registry, exactly-one backend, non-empty coverage) + dispatch + integration-тесты; bootstrap CRD-Established wait.
> **S2 ✅** (operator-only): новый крейт `operator-controllers/sourcecredential` — watch SourceCredential, read unsealed material, derive prefix-matched Argo `repo-creds` (argocd ns) + status `GitPresent`/`GitValid=Unverified`; field manager `apprafter-sourcecredential`; RBAC (sourcecredentials + secrets); wired 4-м контроллером в `main.rs`.
> **S3 ✅** (operator-only): registry-половина — canonical `dockerconfigjson` (apprafter-system) + `RegistryPresent`/coveredHosts; **Seam A** — Application-контроллер host-match rendered image → SSA-копия pull-secret в app ns → `Deployment.imagePullSecrets`. Pure matching в `application/src/pull_secret.rs`.
> **S4 ✅** (v0.1.177): CLI `repo creds` → thin front-end над SourceCredential. `add` seal + SealedSecret + CR (git всегда; ghcr.io/<org> инферится для github); `list`/`show` читают `.status` (никогда материал); `rotate` re-seal; `remove` delete CR+SealedSecret за reverse-dep gate; `app add` coverage-hint читает SourceCredential. Legacy raw repo-creds флоу cut over (без shim).
> **S5 ✅ поставлен** (operator v0.1.137 / platform-stack 0.1.51 / CLI v0.1.184): `SourceCredentialMigrationStrategy.detect_destructive` (классификатор coverage-removal→breaking + 7 тестов + экспорт; live plan-creation wiring co-отложен с B.1.77) · live validity-probe (представительный репо/образ из матчащегося Argo/AppRafter Application → git smart-HTTP / scoped registry v2 token-exchange; консервативный mapping, egress-blocked → `Unverified`, не `Invalid`; `lastValidated`) · coverage-gate `present`|`confirmed` (`app add --coverage-gate`) · derived-Secret GC finalizer (`apprafter.io/derived-secrets-cleanup`, cross-ns без ownerRef-каскада; RBAC `delete` на secrets) · scoped CLI credential-author Role seed (unbound, no read на derived Secrets). config-repo delivery — **DEFER** (→ Phase-3 Backstage). Запись в `plan-history.md` добавлена.
> ⚠️ **Release-координация — СДЕЛАНО:** координированный bump одним коммитом `chore(release): publish 1.79c S5` (тег `v0.1.184`): operator+webhook `Chart.yaml` appVersion v0.1.136→**v0.1.137** + chart version v0.1.117→v0.1.118; platform-stack component-пины следом; `currentVersion` 0.1.50→**0.1.51** + `safe` compatibility-запись; `RELEASED_OPERATOR_VERSION` деривится build.rs из appVersion (проверено: v0.1.137); CLI v0.1.183→**0.1.184**. `operator/v0.1.137` + `platform-stack/v0.1.51` — воркфлоу-managed на push. Ждёт `git push` пользователя.

**Source:** ADR 0039. Продолжение 1.79a (repo/app subcommands). Новый item — не затрагивает отгруженный 1.79b (`app open`/scaffolding/runtime templates сохраняют свой номер и историю v0.1.161–v0.1.174).

**Цель:** один безопасный credential-флоу к приватным client-репозиториям — git-read для Argo CD + registry-pull для kubelet — из одного источника, без сырых ungated-ресурсов и без plaintext-секретов. Закрывает три дефекта текущего 1.79a-флоу: **(1)** CLI создаёт raw Argo `Application` + raw `repo-creds` Secret в обход admission+оператора (credential change не классифицируется как потенциально деструктивная операция); **(2)** credential лежит plaintext в kube Secret (несовместимо с SealedSecrets 2.11 / ADR 0024 Layer 2); **(3)** pull-secret не заводится вообще — приложения с приватным registry не стартуют.

#### Поставка — `SourceCredential` CRD (config-only, ноль материала)
- [x] CUE schema `schemas/v1alpha1/sourcecredential.cue`: `spec.git? { backend, repoPrefixes: [...] }`, `spec.registry? { backend, hosts: [...] }`; `#Backend = { sealedSecretRef } | { openBaoPath }`. Обе половины независимы; single-PAT кейс = один backend в обоих. В `spec` — никакого токена/base64.
- [x] CRD OpenAPI v3 + admission webhook (cross-field: хотя бы одна из git/registry; непустые prefixes/hosts; валидный backend ref).
- [x] `status.conditions` per-half: `Present` / `Valid` / `Invalid` / `Unverified` + covered prefixes/hosts + `lastValidated`.

#### Поставка — operator derivation
- [x] git → **prefix-matched** Argo `repo-creds` Secret в `argocd` ns (Argo клонит по URL-prefix; derived output, не hand-managed).
- [x] registry → static `dockerconfigjson` pull-secret в workload ns; **auto-attach** к workload SA / `Deployment.imagePullSecrets` по **registry-host match** (`image: ghcr.io/...` → `SourceCredential` с host `ghcr.io/...`).
- [x] Reconcile держит derived Secrets консистентными с CR + материалом (single source of truth; `rotate` материала → передеривка обеих производных).
- [x] RBAC оператора: read `SourceCredential`, read unsealed material, write argocd repo-cred + workload pull-secret, patch SA/Deployment.

#### Поставка — operator validation + status
- [x] git validity: smart-HTTP `GET <repo>/info/refs?service=git-upload-pack` (Basic auth, reqwest) против **представительного репо** из матчащегося Argo Application (префикс — орга, нужен конкретный объект; решение в `validity.rs`). registry validity: scoped v2 token-exchange (oci-distribution) против представительного образа из матчащегося AppRafter Application. On-change + каждые 60s (1/min — в пределах GitHub rate-limit). Консервативный mapping: Valid только на 2xx/success, Invalid только на явный auth-reject (401/403 / auth-failure), всё неоднозначное → Unverified.
- [x] Egress-blocked → `Unverified` (не `Invalid`) — network-error никогда не даёт Invalid. `GitValid`/`RegistryValid` + `status.lastValidated` пишутся. Нет матчащегося app → тоже `Unverified` (нечего пробить).
- [x] Coverage-gate конфигурируем `present` | `confirmed` (`app add --coverage-gate`, ValueEnum, default `present`): `present` — warn-only post-registration по наличию prefix (как было); `confirmed` — pre-flight БЛОКИРУЕТ регистрацию приватного (`https`) репо, пока покрывающий `SourceCredential` не в `GitValid=True` (pure `valid_credential_covers` читает `.status.conditions`). Egress-restricted → дефолт `present` (validity остаётся `Unverified`). [ADR 0039 §Validation and status]

#### Поставка — CLI front-end refactor (`repo creds` → `SourceCredential`)
- [x] `apprafter repo creds add`: shape-check (existing regex) → seal материал client-side (kubeseal публичным сертом контроллера; серт **пинится** / fetch через TLS kube API) → create/update `SourceCredential` CR + SealedSecret. Опц. поллит `.status` несколько сек для validity-фидбэка; иначе «submitted, validity pending».
- [x] `list` / `show`: читают `.status` (coverage + validity), **никогда** материал (CLI не может расшифровать SealedSecret — нет cluster private key).
- [x] `rotate`: re-seal материал на эквивалентный валидный cred (оператор передеривает обе производные; non-destructive).
- [x] `remove`: delete CR с reverse-dep gate (переиспользует `find_apps_matching_prefix` из 1.79a).
- [x] `app add` coverage-check: гейтит по «есть `Valid` cred, покрывающий repo prefix» из `.status` (вместо CLI-догадки); режим гейта = coverage-gate (`present`/`confirmed`) из operator-секции выше.
- [x] Scoped CLI RBAC role (Phase-4 scoped-identity seed, фиксируется уже сейчас): `Role` `<fullname>-credential-author` в release-ns (`operator/charts/.../templates/rbac-cli.yaml`, gate `.Values.cliRole.create`), shipped **UNBOUND** (Phase 4 биндит к scoped identity). read `SourceCredential` (+`status`), write `SourceCredential` / `SealedSecret` (bitnami.com), **no read** на core/v1 Secrets — крипто-нечитаемость материала из CLI по построению, не только RBAC. Public-cert fetch через service-proxy — отдельный non-sensitive grant, не в seed. [ADR 0039 §CLI as a thin front-end]
- [x] **Cut over** от legacy raw `repo-creds` Secret флоу — без migration shim (pre-1.0, флоу живёт только в dev-кластере).

#### Поставка — MigrationPlan integration (destructive credential change)
- [x] `SourceCredentialMigrationStrategy` с `detect_destructive(old, new) -> Option<DestructiveChange>`: rotate-to-equivalent-valid = `None`; coverage removal (repo-prefix / registry-host, включая drop целой half) = destructive → `DestructiveChange{trigger:"coverage-removal", classification:"breaking"}`. Actor-agnostic классификатор поставлен + 7 юнит-тестов + экспорт. **Live plan-creation wiring** (reconcile-time snapshot→build MigrationPlan→pause derivation) + `create_plan_for` + scope-вариант `sourcecredential` в MigrationPlan CRD (kube-rs/OpenAPI/CUE/admission) **co-отложены** с application-scope live-wiring (B.1.77 — «один call-site, который раскомментируют»; ADR 0039 §169 определяет вклад 1.79c в gate именно как «adds a `MigrationStrategy.detect_destructive`»). `delete-while-referenced` (удаление CR при матчащихся приложениях) уже закрыт reverse-dep gate в CLI `repo creds remove` (S4); admission-side actor-agnostic вариант — с тем же B.1.77. Зависит от MigrationPlan CRD (1.72–1.78).

#### Поставка — delivery modes
- [x] CLI→cluster: `kubectl apply` SealedSecret + CR.
- [~] config-repo (опц. инфра-репо): commit sealed + CR, Argo синкает (материал sealed → git-safe). Pure-GitOps-без-cluster-read: coverage-match по declared prefixes, validity в Backstage. **DEFER** (явное решение на закрытии 1.79c, 2026-05-31): помечен «опц.» в исходном scope; pure-GitOps-без-cluster-read (validity в Backstage) — заметный кусок, ближе к Backstage-фазе (Phase 3). Архитектурно уже поддержан (материал sealed → git-safe в обоих режимах — ADR 0039 §"Delivery is mode-agnostic"); закрытие 1.79c не требует. Подтянуть с Phase-3 Backstage-вью.

#### Поставка — credential type
- [x] Launch default: single classic PAT (`repo` + `read:packages`) в обе половины. GitHub-ограничение (нет `repo:read`-only; fine-grained без packages; App-токен ghcr.io не берёт) — принимается; платформа хранит sealed.
- [x] Schema split-ready с первого дня (git ≠ registry backend). Wizard split (deploy-key/fine-grained git + `read:packages`-only registry с package-level access; GitLab — один `read_repository`+`read_registry` токен) — **opt-in, не дефолт**; визард-выбор откладывается до operator feedback.

#### Acceptance
- [x] Private GitHub репо + приватный ghcr.io образ: `repo creds add` (classic PAT) → `SourceCredential` `Valid` → `app add` проходит coverage-check → Argo клонит (prefix-matched repo-cred) → оператор рендерит Deployment с auto-attached pull-secret → под стартует, образ тянется.
- [x] Org-cred (`repoPrefixes: ["github.com/myorg/"]` + `hosts: ["ghcr.io/myorg/"]`) покрывает второе приложение орги без отдельного `repo creds add` (auto-match); в `Application.cue` про credentials ничего. **Валидировано walk'ом 2026-06-01.**
- [x] `repo creds rotate` на валидный новый PAT → обе производные передериваются, Argo + kubelet продолжают без даунтайма; MigrationPlan не создаётся (non-destructive; `detect_destructive`=`None`). **Валидировано walk'ом 2026-06-01.**
- [~] Убрать registry-host из покрытия CR, пока приложение на него матчится → admission создаёт MigrationPlan; derived pull-secret не трогается до approve. **Классификатор поставлен** (`detect_destructive` → `coverage-removal`/`breaking`, 7 тестов), но **live admission-creates-MigrationPlan + pause co-отложен с B.1.77** (паритет с application-scope; ADR 0039 §169 — вклад 1.79c = «adds `detect_destructive`»). Сейчас удаление host'а проходит, derived pull-secret передеривается под reverse-dep gate CLI; полное end-to-end gating — с B.1.77.
- [x] `repo creds show` / `list` / `kubectl get sourcecredential -o yaml` — нигде plaintext токена; SealedSecret нерасшифровываем без cluster private key.
- [x] Restricted-egress кластер: валидный PAT → status `Unverified` (не `Invalid`); coverage-gate в `present`-режиме пропускает.

#### Не входит в этот item
- OpenBao backend (T2) — с 2.7–2.8 / 3.11; schema `backend` уже предусматривает `openBaoPath`.
- Wizard выбора credential-типа (single vs split) — flag-driven + дефолт single PAT; визард по operator feedback.
- Short-lived-token registry + refresher / kubelet credential provider — не нужно для classic-PAT GHCR; managed-era / cloud-registry concern.
- GitHub App credential path — managed-era refinement (git-половина).
- Backstage `SourceCredential` view — Phase 3 Backstage plugin.

**Зависит от:** 1.79a (repo/app subcommands, `find_apps_matching_prefix`); **2.11** (SealedSecrets controller + kubeseal-in-CLI slice — **cross-phase, см. `speedrun-plan.md` §4.2 SR ordering**); 1.72–1.78 (MigrationPlan CRD — для destructive-gating подчасти).

**Размер:** L

---

### 1.80 `apprafter platform fork` GitHub API automation
> ⏸️ **DEFERRED (2026-06-01)** — power-user one-command fork; **не на managed-launch критическом пути** (no SR bucket marker). Явно отложен при закрытии M1.5 (решение пользователя). Не блокирует M1.5: `e2e/fork.sh` дропнут, docs fork = 1 строка-ссылка сюда. Подтянуть post-launch / по запросу power-users.

**Source:** ADR 0028.

**Цель:** one-command fork bootstrap для power users.

**Поставка:**
- [ ] `apprafter platform fork --to <oci-ref> [--private]`:
    - Validates GitHub PAT exists (env or target credentials store).
    - Fork `github.com/AppRafter/apprafter` to user's GitHub account/org via API.
    - Add `.github/workflows/platform-stack-publish.yml` to the fork (copied from upstream — это same workflow что был залит в 1.68, отображённый для fork-specific OCI namespace).
    - Trigger initial publish (push tag → CI builds → OCI publishes).
    - Patch local PlatformStack CR: `spec.source.repoURL = <new oci ref>`, keep `spec.source.upstream` pointing to AppRafter upstream for tracking.
- [ ] Documentation в `docs/operator-guide/fork.md`: when to fork, how to maintain, sync from upstream procedure.

**Acceptance:**
- `apprafter platform fork --to ghcr.io/myorg --private` on test account → fork created, workflow added, initial OCI publish ends green, local cluster's PlatformStack updated to pull from `ghcr.io/myorg`.
- Edit CUE in fork → tag → next bootstrap or upgrade pulls from fork.
- Upstream tracking: PlatformStack.status.availableVersion still reflects AppRafter upstream releases.

**Зависит от:** 1.68 (workflow template), 1.79 (CLI infra)

**Размер:** M

---

### 1.81 e2e tests update

**Source:** ADR 0025, 0026, 0027, 0028, 0029.

**Цель:** end-to-end coverage всех new flows.

> ✅ **CLOSED (2026-06-02):** k3d e2e-гейт зелёный (run `26815926016`, `gitops-walk.sh` 3m16s) → spec.md §6 M1.5 box флипнут + Revision 9→10. Деталь раунда ниже. **SCOPED CLOSE (2026-06-01, ревизия 2026-06-02):** локальный кластер проекта — **k3d** (не kind, формулировка ниже устарела). Сэндбокс ассистента **не запускает k3d** (Podman без `/var/run/docker.sock`) → k3d-скрипты написаны + `shellcheck`-clean + заведены в CI, валидатор — CI (аналог ручного walk). Общий `e2e/lib.sh` harness извлечён. **2026-06-02 (CI-разбор):** `migration-platform.sh` **снят с k3d-гейта** (Option C) — фундаментально несовместим со средой: PlatformController-OCI-клиент **HTTPS-only** (`oci-distribution ClientConfig::default()`), а локальный реестр k3d — **plain-HTTP**, поэтому контроллер не может стянуть compat-doc фикстур in-cluster → классификация перехода падает, план не создаётся даже на CR-уровне. Net: k3d-гейт = `gitops-walk.sh`; `mvp.sh` = Hetzner-nightly; миграционный гейт покрыт unit+integration тестами оператора + (follow-up) real-infra walk на nightly Hetzner.
>
> **Поставка:**
- [x] `e2e/mvp.sh` rewritten — 9-step → 3-step (init → bootstrap-all → Application smoke); **+ассерт что platform-компоненты Argo-CD-managed** (не CLI-applied). Общий `e2e/lib.sh`. Hetzner-nightly. (commit `bfcd95d`)
- [x] `e2e/gitops-walk.sh` — k3d: fixture app repo (local git daemon) → `app add` → CMP рендерит Application CR → Argo синкает → operator reconciles Deployment → push `Application.cue` change → сходится. shellcheck-clean; CI-validated. (commit `a7a4051`)
- [~] `e2e/migration-app.sh` — **DEFER → Phase 2**: тестит `needs.pg` end-to-end provision (ResourceClaim + ServiceProvider + CloudNativePG); `needs` **явно удалён** из v1alpha1 (`schemas/v1alpha1/application.cue:18`), реализуем только после 2.2/2.3.
- [~] `e2e/migration-platform.sh` — **DROP с k3d-гейта (2026-06-02, Option C)**: скрипт удалён. CI-разбор вскрыл, что walk нереализуем на k3d на нескольких уровнях, и все блокеры упираются в **неотгруженную/отложенную** инфру, а не в баг гейта (1.78 корректен, покрыт unit+integration): (1) PlatformController-OCI **HTTPS-only** vs plain-HTTP реестр k3d → compat-doc фикстур не тянется; (2) `PlatformController` пробрасывает родителю только `targetRevision`+`helm.values`, **не `repoURL`** → реальный деплой редиректнутого реестра = fork-история **1.80 (deferred)**; (3) попытка пропатчить `targetRevision` на отсутствующую в ghcr версию вешает in-flight гейт; (4) исходный скрипт был написан против неверной модели триггера (доступность-сама-создаёт-план вместо pin→breaking). Корректный blueprint будущего real-infra теста (pin-driven, nudge PlatformStack после `approve`, HTTPS-реестр) — в memory `project_m1_5_close`. **Follow-up'ы:** (a) env-gated insecure/HTTP OCI в контроллере (dev-mode/1.9 территория); (b) `apprafter migration approve` мог бы пинать PlatformStack — сейчас bump доезжает лишь на следующем reconcile (до `checkInterval` ≤6h), т.к. PlatformController не watch'ит MigrationPlan.
- [~] `e2e/fork.sh` — **DROP**: item 1.80 (`platform fork`) сейчас не делаем.
- [x] All scripts callable from CI; budget < 30 min per script на **k3d** cluster — `Justfile` (`e2e`/`e2e-gitops`) + CI `e2e-k3d.yml` (PR-triggered); `mvp.sh` остаётся nightly. (commit `6921670`; dist-render step + `e2e-migration-platform` recipe убраны 2026-06-02 вместе с descope)

**Acceptance:**
- [x] **(CI-gate GREEN 2026-06-02, run `26815926016`)** `just e2e` (= `gitops-walk.sh`) ran green on k3d in CI in 3m16s — bootstrap (Cilium→Argo→platform-stack 0.1.52, PlatformStack/default tier=1) + the full loop (`app add` → CMP render → Argo Synced/Healthy → operator Deployment Available → replicas 1→2 propagates). `mvp.sh` is the nightly real-Hetzner complement. **This flipped the spec.md §6 M1.5 box + Revision 9→10.**
- Major M1.5 code paths exercised: cluster-bootstrap + Application reconcile (mvp), CMP→Argo→operator loop (gitops-walk). PlatformStack pin→breaking→MigrationPlan→approve/reject gate covered by **operator unit + integration tests** (k3d walk descoped — see migration-platform.sh note above). `needs.pg`/migration-app path → Phase 2; fork path → 1.80 (deferred); real-infra migration walk → nightly-Hetzner follow-up.

**Зависит от:** all 1.66–1.80 (1.80 deferred — `fork.sh` dropped accordingly)

**Размер:** M

---

### 1.82 Docs update

**Source:** ADR 0025, 0026, 0027, 0028, 0029.

**Цель:** rewrite outdated quickstart, add new operator/dev guides.

**Поставка:**
> ✅ **DONE (2026-06-01, commit `a7efe69`)** — все доки написаны, `mkdocs build --strict` чист (0 warnings/errors), `cyrillic`-хук clean. Fork = одна строка-defer (1.80). Доки реально валидируемы (в отличие от e2e).
- [x] `docs/operator-guide/quickstart.md` rewritten: 3-step (install → `target add`/`init` → `bootstrap-all`), Argo-CD-managed platform на first read, `apprafter open argocd`, **CX22 → CPX22**, smoke через `Application` CRD.
- [x] `docs/operator-guide/platform-management.md` (new): PlatformStack lifecycle, каналы (stable/beta/edge), upgrade/freeze/rescue. **Fork = 1 строка** (power-user, 1.80 not yet shipped) — не отдельная секция (scoped).
- [x] `docs/operator-guide/migration-plans.md` (new): destructive change; approve/reject by scope (application = approve-only + revert commit per ADR 0027; platform = approve/reject); surfaces (CLI сейчас; Backstage/Argo UI — позже).
- [x] `docs/dev-guide/application-cue.md` (new): `apprafter/Application.cue`, CMP render + troubleshooting, multi-env (`spec.environments` + `APPRAFTER_ENV`).
- [x] `docs/operator-guide/gitops-walk.md` updated: Application-CRD end-to-end (не raw Deployment+Service); + `mkdocs.yml` nav.
- [x] Update root `README.md` reference links + dev-quickstart CX22→CPX22 fix.

**Acceptance:**
- New user reading quickstart end-to-end can get to running app in ~30 min.
- Docs explain Argo CD's role clearly without contradictions.
- Mental model "platform reconciles itself" передаётся on first reading.

**Зависит от:** 1.81

**Размер:** S

---

### 1.83a Chart: gateway component (host-network) + gateway-api-crds + per-domain listeners + redirect
> 🏁 SR: A · order 3.5 — public ingress MVP (completes T1 demo); minimal slice — full ingress остаётся order 5 (4.1/4.1a/4.4a)

> 🔁 **ПИВОТ при реализации (2026-06-11): host-network, НЕ LB-IPAM+L2.** Cilium L2-announcement — bare-metal-only (ARP на общем L2-сегменте, IPv6/NDP не поддерживает); на Hetzner Cloud публичный IP узла маршрутизируется SDN провайдера, не через ARP → LB-IPAM/L2 не назначат и не анонсируют адрес. Правильный механизм для single-node-cloud (у узла уже есть публичный IP) — Gateway API **host-network mode**: Envoy биндит host-netns порты 80/443 прямо на узле, `node-IP:443` → Gateway, БЕЗ LoadBalancer-Service / LB-IPAM / L2. Релиз **platform-stack 0.2.25** (chart-only, БЕЗ CLI — cilium loader-values байт-идентичны). Build отгружен на master; **1.83a ЗАКРЫТ 2026-06-13** — чистый T8 live-Hetzner-ретест зелёный (F1–F4, мульти-домен, teardown, без ручных рестартов) после фиксов 0.2.27 (F1/F2-v1) → 0.2.32 (F2-rollOutPods весь cilium-стек) + cli v0.2.14 (F3 ignoreDifferences) + F4-резолв через F3-Gateway.

**Source:** инфра-долг (servicelb выключен с 1.3); precursor для 4.1 platform Gateway.

**Цель:** платформенный Gateway на одном узле публично обслуживает домены (host-network: Envoy слушает 80/443 на публичном IP узла). Для каждой entry в `gateway.allowedDomains[]` — пара HTTPS-listener'ов (apex + wildcard) со static cert-ref на per-entry imported-cert Secret + один catch-all HTTP listener + platform-wide redirect HTTPRoute (HTTP→HTTPS 301). Пустой массив ⇒ ноль gateway-ресурсов (zero-impact на existing solo).

**Поставка (отгружено в 0.2.25, host-network):**
- [x] `gateway.allowedDomains` values-схема (`#AllowedDomainEntry` + `#GatewayValues` в `platform.cue`; default пусто). Поля entry: `domain`, `certMode:"imported"`, `importedCertRef`, `addedAt`, `addedBy`; + `nodePublicIP?`/`nodePublicIPv6?` (для DNS / 1.83f; в host-network чартом не используются).
- [x] Cilium КОМПОНЕНТ (Argo-managed, НЕ loader) включает Gateway API **host-network mode**: `gatewayAPI.hostNetwork.enabled` + envoy `NET_BIND_SERVICE` caps (standalone-envoy, cilium 1.16.5). Loader-values **байт-идентичны** (no CLI change, no CLI bump) — паттерн `_loaderValues.cilium.values & {extras}` как у argocd-компонента. Прежние `l2announcements`/`externalIPs` — дропнуты.
- [x] `gateway-api-crds` Argo-компонент (sync-wave **−25**, до cilium −20) — ставит upstream Gateway API **v1.2.1** CRD (git-source `kubernetes-sigs/gateway-api`, path `config/crd/standard`; прецедент network-policies). Доставка через Argo, НЕ через bootstrap (bootstrap минимален).
- [x] `gateway.yaml` render-шаблон (umbrella-emitted в `render_tool.cue`, guarded `{{- if .Values.gateway.allowedDomains }}`): `Gateway` `platform` в `apprafter-system` (gatewayClassName cilium, label `apprafter.io/platform-gateway: "true"` — adoption-shim для 4.1; per-entry apex+wildcard HTTPS-listener'ы, имена dot-free через `replace "." "-"` + http catch-all) + `platform-http-redirect` HTTPRoute (301). **БЕЗ** LoadBalancer-Service / `CiliumLoadBalancerIPPool` / `CiliumL2AnnouncementPolicy` (дропнуты — host-network их не требует).
- [x] Регресс-гард `scripts/check-gateway-render.sh` + врезка в CI (`platform-stack-check`): empty→ноль gateway-ресурсов; populated→1 Gateway + 4 https-listener'а (apex+wild ×2) + 1 http + 1 redirect-301, без IPPool/L2; dot-free имена.
- [x] kind apiserver-валидация (структурная приёмка Gateway+HTTPRoute против v1.2.1 CRD; PROGRAMMED не валидируется — нет cilium-контроллера в kind) + релиз platform-stack **0.2.25** (`currentVersion`/compat `change: requires-restart`; operator/cli не бампались).
**T8 walk-fixes (live-Hetzner 2026-06-12 — known gotchas cilium host-network Gateway on GitOps):**
- [x] **F1 (BLOCKER, 0.2.27):** `gateway-api-crds` → **experimental** канал (`config/crd/experimental`), не standard — cilium 1.16.5 gateway-контроллер на старте требует `tlsroutes.gateway.networking.k8s.io` (v1alpha2, только в experimental); без него контроллер падает на required-resources-check → **Gateway никогда не Programs** (NB: `GatewayClass.Accepted` на cilium 1.16.5 остаётся `Unknown` даже при здоровом Programmed Gateway — несущий сигнал = `Gateway.Programmed`, НЕ GatewayClass.Accepted; мой прежний runbook-чек на GatewayClass был неверным). + регресс-гард в `check-gateway-render.sh`.
- [x] **Gateway-walk регресс-гард (sandbox-run — дыра, что kind не закрыл):** новый `e2e/gateway-walk.sh` — реальный Cilium 1.16.5 + gateway-контроллер под `sandbox-run` (rootful microVM, memlock unlimited; в kind под rootless podman cilium-gateway не живёт) → experimental CRD + наш отрендеренный `gateway.yaml` → assert `Gateway.Programmed=True` + listeners. **Прогнан ЗЕЛЁНЫМ:** positive (experimental → Programmed) + negative (`APPRAFTER_GW_WALK_NEGATIVE=1`: standard → Gateway никогда не Programs — F1-симптом воспроизведён). + nightly workflow. Закрывает test-gap: контроллерный уровень F1 был sandbox-валидируем (а я пунтанул всё в Hetzner).
- [x] **F2 (operability — РАСШИРЕН в Run 2, 0.2.27→0.2.32):** cilium читает config-ФЛАГИ только на старте → включение gateway-api/host-network на ЖИВОМ кластере требует рестарта ВСЕГО стека: **agent (`ds/cilium`** — отдаёт CiliumEnvoyConfig в Envoy по xDS), **operator** (Gateway→CEC), **standalone envoy (`ds/cilium-envoy`** — биндит host-netns 80/443). Run-2 walk поймал: Gateway `Programmed=True`, но Envoy не биндит 80/443, т.к. agent на старом конфиге не пушит CEC-listener → только ручной `rollout restart` всех трёх анблокировал. Прежний 0.2.27-фикс (`operator.podAnnotations.cilium-config-rev`) катил ТОЛЬКО оператора. **Заменён на штатные cilium-values `rollOutCiliumPods`/`operator.rollOutPods`/`envoy.rollOutPods: true`** (config-checksum на pod-template → авто-ролл каждого пода при изменении cilium-config) — 0.2.32, chart-only (loader байт-идентичен, no operator/CLI). Fresh-инсталлы не затронуты (upgrade-корректность).
- [x] **F3 (cosmetic, CLI v0.2.14):** `ignoreDifferences` на root `platform` Application — иначе Gateway+HTTPRoute вечно OutOfSync в Argo (selfHeal зря churn'ит). **Поля по ЖИВОМУ Argo DIFF (T8 Run 2 — apiserver-дефолтинг, НЕ финалайзеры):** Gateway `.spec.listeners[].tls.certificateRefs[].group` (apiserver дозаполняет пустой core-group `''`); HTTPRoute `.spec.parentRefs[].group` (`gateway.networking.k8s.io`) + `.spec.parentRefs[].kind` (`Gateway`) + `.spec.rules[].matches` (apiserver дефолтит match-all `PathPrefix /`, наш redirect-rule без matches). В `render_root_application` (новые bootstrap'ы) + регресс-тест `render_root_application_ignores_gateway_api_defaulting`; existing-кластер — одноразовый `kubectl patch application platform ... spec.ignoreDifferences` (поле оператор НЕ владеет → переживает его SSA-патчи).
- [x] **T8 — live Hetzner host-network smoke (приёмка) — ✅ ВЗЯТ (чистый ретест 2026-06-13, F1–F4 все зелёные вживую, БЕЗ ручных рестартов):** Gateway `Programmed=True` за 1s, 3 listener'а Accepted/Programmed/ResolvedRefs, `curl -I http://demo.apprafter.dev` → **301** → https, :443 TLS-терминируется (404 = нет app-route); **мульти-домен** (2-я entry demo2 → +2 listener'а apex+wildcard, curl 301); **teardown** (`allowedDomains:[]`) → Gateway+HTTPRoute сами `NotFound`, root App `Synced`; F2-rollOutPods отработал (Programmed без ручного restart'а cilium-стека), F3-ignoreDifferences → root Synced, F4 → проекция+prune сами. GatewayClass `Accepted=Unknown` — informational cilium-quirk, не гейтили. Gateway `Programmed=True`, Envoy биндит ОБА порта 80/443, `curl -I http://<zone>` → 301. F1+F2 разблокируют Programmed (0.2.27). Острые углы: cilium [#42786](https://github.com/cilium/cilium/issues/42786) (PROGRAMMED:False)=F2; [#39422](https://github.com/cilium/cilium/issues/39422) (80+443) — по `ss -tlnp`. Домен/серт вручную (1.83e/1.83f дальше). **Runbook (исправлен R1-R4):** `NODE_IP` из `InternalIP`+`awk '{print $1}'` (Hetzner без CCM не вешает ExternalIP; InternalIP отдаёт v4+v6); проверять cilium-config, НЕ Argo-`application` (CRD-коллизия с `applications.apprafter.io`); openssl через `nix run nixpkgs#openssl req --`; без `yq`. Полные команды — в отчёте/ответе ассистента 2026-06-12.

**Acceptance (= T8):**
- Создать `kubernetes.io/tls` Secret (SAN на apex+wildcard) + выставить `PlatformStack.spec.values.gateway.allowedDomains: [{domain, certMode:"imported", importedCertRef, addedAt, addedBy}]` ⇒ `kubectl get gateway platform -n apprafter-system` → `Programmed: True`, listener'ы `https-apex-<san>` + `https-wild-<san>` + `http`.
- Вторая entry ⇒ ещё два HTTPS-listener'а после reconcile, каждый на свой Secret.
- `curl -I http://<zone>/` → `301` `Location: https://<host>/`; `curl -Ik https://<zone>/` достаёт Gateway.
- Пустой массив ⇒ нет gateway-ресурсов; existing solo-кластера не ломаются (cilium переконфигурируется на host-network через Argo на апдейте — `change: requires-restart`).

**Зависит от:** 1.4 ✅, 1.71 ✅.

**Размер:** M+ (build отгружен; остаётся T8 live-Hetzner-walk)

---

### 1.83b Schema: `expose.hostname` + `expose.tls` + allowedDomains admission
> 🏁 SR: A · order 3.5 — public ingress MVP (completes T1 demo); minimal slice — full ingress остаётся order 5 (4.1/4.1a/4.4a)

> ✅ **CLOSED 2026-06-13** (delivered as ONE vertical, merging 1.83b schema/webhook + 1.83c operator HTTPRoute). Release: operator v0.2.30 / platform-stack 0.2.33 / cli v0.2.15. kind+Cilium live walk GREEN (e2e/gateway-walk.sh). **Deviations from the original 1.83b/1.83c wording:** (1) `expose.public` (bool) DROPPED — `network: "public"` is the single visibility trigger (the bool was never consumed). (2) `expose.tls` KEPT as the minimal `bool | *true` (full `#TlsOptions` deferred to 4.1b, NOT cancelled); `tls:false`+public is webhook-rejected for now. (3) The hostname↔allowedDomains zone check is a SOFT operator `PublicRouteReady` condition (route still emitted; adding the zone later attaches it), NOT a hard webhook reject — the webhook only checks DNS-1123-subdomain shape. (4) The landing-manifest migration to `expose.hostname` (1.83b "Поставка" last bullet) is a SEPARATE landing-repo change, NOT done here.

**Source:** срез 4.1a schema extension + 4.1b `allowedDomains` admission rule.

**Цель:** ввести поля `hostname` и `tls` в Application; admission webhook валидирует hostname против `PlatformStack.spec.values.gateway.allowedDomains`. Оба rules signature-stable с 4.1b — миграция == webhook читает `ExternalSurface.spec.allowedDomains` вместо PlatformStack.

**Поставка:**
- [x] `schemas/v1alpha1/application.cue` — расширить `#Expose`:
    ```cue
    #Expose: {
        port:     int
        public:   bool | *false
        network:  "public" | "internal" | "vpn" | *"internal"
        hostname: string | *""   // required when public: true (validated в admission)
        tls:      bool | *true   // default on для public; full #TlsOptions в 4.1b
    }
    ```
- [x] OpenAPI v3 CRD пересгенерирована (или hand-rolled mirror) + apply через chart upgrade.
- [x] Admission webhook (existing `apprafter-admission-webhook`):
    - Rule 1: `public: true ⇒ hostname != ""` с error «expose.public: true requires expose.hostname (defaultDomain auto-generation lands в 4.1b)».
    - Rule 2: `public: true` ⇒ `hostname` matches минимум одной entry в `PlatformStack.spec.values.gateway.allowedDomains[]`:
        - Exact apex match: `hostname == entry.domain`.
        - Single-label wildcard match: `hostname == "<label>." + entry.domain`.
        - Multi-label deep matches (например `a.b.entry.domain`) ⇒ reject (slice purposefully не поддерживает deep — Gateway listener wildcard это один level).
        - Mismatch ⇒ reject «hostname '<x>' not in cluster's allowed domains. Run `apprafter target domain add <zone> --cert <name>` first».
    - Webhook читает PlatformStack singleton (`default` в `apprafter-system`) на каждый validate (низкочастотный path, кэш не делаем в slice).
    - Пустой `allowedDomains` ⇒ Rule 2 пропускается на Rule 1's error (нет где match'ить).
- [x] `expose.tls: false` + `public: true` ⇒ пока reject (в slice нет HTTP-only маршрута; добавится в 4.1b как `#TlsOptions{enabled: false}`).
- [ ] Migration лендинг-манифеста: убрать label `apprafter.io/hostname` (см. PART 0.6 чек 2 — если label не используется, пропустить), добавить `spec.base.expose.hostname: "apprafter.dev"`.
  > 🐞 **Довесок к этому же пункту — мягкий 404 лендинга (найдено в 2.19g, НЕ правилось там).** в `landing/web/Caddyfile` директива `try_files` имеет хвост `/404.html` (`grep -n try_files landing/web/Caddyfile`): неизвестный URL переписывается в существующий файл, `file_server` падать не на чем, и **любой** неизвестный URL отвечает **200** с телом 404-страницы. Краулеры индексируют такой ответ как настоящую страницу. Перемерено A/B на реальном `landing/web/Caddyfile` поверх реально собранного `dist`; правильная форма — убрать хвост и ловить в `handle_errors`, как сделано в `docs-site/Caddyfile`.
  > **Почему это ждёт здесь, а не было починено на месте:** `.github/workflows/landing-autotag.yml` срабатывает на любом пуше в дефолтную ветку с дифом по `landing/**` → автотег `landing-v*` → `release-landing.yml` → `landing-web:latest` → оператор перерезолвит дайджест и выкатит. Любая правка под `landing/**` = прод-деплой лендинга, поэтому она делается ОСОЗНАННО и вместе с остальными изменениями лендинга, а не мимоходом из чужой подфазы. Тот же механизм — причина, по которой переключатель `docsUrl` в 2.19g стал шагом оператора, а не придержанным коммитом.

**Acceptance:**
- `kubectl apply` лендинга с `expose.hostname: "apprafter.dev"` после `apprafter target domain add apprafter.dev --cert ...` проходит.
- `kubectl apply` Application с `hostname: "foo.com"` (вне `allowedDomains`) ⇒ reject с понятным error.
- `kubectl apply` с `public: true` без hostname ⇒ reject.
- `kubectl apply` с `hostname: "a.b.apprafter.dev"` (deep) ⇒ reject.
- `kubectl apply` с `hostname: "cms.apprafter.dev"` (single-label wildcard match) ⇒ accept.

**Зависит от:** 1.7 ✅, 1.72 ✅.

**Размер:** S+

---

### 1.83c Operator: HTTPRoute emission из `expose.public + expose.hostname`
> 🏁 SR: A · order 3.5 — public ingress MVP (completes T1 demo); minimal slice — full ingress остаётся order 5 (4.1/4.1a/4.4a)

**Source:** core 4.1a (срез без Certificate emission и без rewrites/ws/sticky).

**Цель:** Application с `public: true` + `hostname` → operator-rendered HTTPRoute. Gateway API сам резолвит listener по hostname matching (apex или wildcard какой угодно зарегистрированной зоны), оператор не знает про количество listener'ов / зон. Certificate не эмитим — cert живёт на per-listener cert-ref'ах статически (1.83a + 1.83e). Multi-zone naturally работает без правок renderer'а.

**Поставка:**
- [x] `operator-rendering` — extension `render_application`:
    - `expose.public: true` + `hostname != ""` ⇒ render `HTTPRoute`:
        - Name `<app>-public` в namespace Application'а.
        - `parentRefs: [{name: platform, namespace: apprafter-system, kind: Gateway}]` — **без `sectionName`**, Gateway сам выбирает listener по SNI.
        - `hostnames: [<expose.hostname>]`.
        - `rules: [{matches: [{path: {type: PathPrefix, value: "/"}}], backendRefs: [{name: <service-name>, port: <expose.port>}]}]`.
    - OwnerRef → Application (cascading delete через 1.9 mechanism).
    - **Никакого Certificate** в slice-variant.
- [x] HTTPRoute и Service Application'а в одном namespace ⇒ `ReferenceGrant` не требуется. Cross-namespace Gateway↔HTTPRoute разрешён через `allowedRoutes.namespaces.from: All` (1.83a).
- [x] Status: `Application.status.endpointURL` ⇒ `https://<hostname>` при `public: true` (вместо internal cluster-DNS endpoint).
- [x] Тесты:
    - In-file: pure renderer тест на HTTPRoute shape для public+hostname.
    - In-file: assert что Certificate не рендерится.
    - In-file: assert renderer не зависит от количества зарегистрированных зон.
    - Real-cluster smoke (gated `APPRAFTER_INGRESS_SMOKE=1`): apply Application с public+hostname ⇒ HTTPRoute появляется, `curl https://<hostname>` отвечает.

**Acceptance:**
- Apply Application с `expose.public: true, hostname: "apprafter.dev"` (после регистрации) ⇒ HTTPRoute создан в течение 30s, `Accepted: True`, `ResolvedRefs: True`.
- Apply Application с `hostname: "foo.apprafter.dev"` ⇒ HTTPRoute matches wildcard listener того же Gateway, тот же cert.
- Apply Application с `hostname: "bar.apprafter.io"` (после регистрации второй зоны) ⇒ HTTPRoute matches apex listener apprafter.io, другой cert.
- Удаление Application ⇒ HTTPRoute удаляется через ownerRef.
- `expose.public: false` ⇒ HTTPRoute не создаётся, status.endpointURL = internal.

**Зависит от:** 1.7 ✅, 1.8 ✅, 1.9 ✅, 1.83a, 1.83b.

**Размер:** M — standard kube-rs renderer, distributed-penalty не применяется.

---

### 1.83d Origin firewall в Hetzner Cloud builder (CF IPs only, fail-fast)
> 🏁 SR: A · order 3.5 — public ingress MVP (completes T1 demo); minimal slice — full ingress остаётся order 5 (4.1/4.1a/4.4a). NB: net-new, в order-5 launch-пути отсутствует (тот предполагает external-dns automation, не CF-orange).

> ✅ **CLOSED 2026-06-14** (ADR-less slice; design `docs/superpowers/specs/2026-06-14-1-83d-origin-firewall-design.md`). Release: cli **v0.2.18** + cue-cmp **v0.1.11** + platform-stack **0.2.35** (the infra schema bundle — `infrastructure.cue` gained `cloudflareOrigin`, and cue-cmp bundles `schemas/v1alpha1`). **Deviations from the original wording above:** (1) **OPT-IN, not always-on** — gated by `Infrastructure.spec.firewall.cloudflareOrigin: bool|*false`; always-on would break any cluster NOT fronted by Cloudflare (direct DNS / outer Caddy), and a manifest flag persists across re-applies unlike a per-invocation CLI flag. Default off ⇒ today's `0.0.0.0/0` behaviour unchanged. (2) **Implementation shape** — not a standalone `cf_ingress_firewall_rules()`; instead `cli-providers::cloudflare::fetch_cloudflare_ips` (a `CloudflareIpSource` seam, fail-fast, NO fallback CIDRs) + `apply.rs::resolve_cf_ips` (fetch-FIRST, before any cloud mutation) + the pure `apply_cf_origin` rewriting **only** `tcp/80`+`tcp/443` sources (22/6443/51820/ICMP untouched — **6443 deliberately stays open**, CF doesn't proxy the kube-apiserver so gating it would break `kubectl`). (3) **Bonus — closed the create-only firewall reconcile gap:** added `client.set_firewall_rules` (`POST /firewalls/{id}/actions/set_rules`) + `Action::SetFirewallRules` + an order-insensitive `rules_differ`, so CF-IP drift (and ANY rule change) now refreshes on re-apply instead of being ignored. (4) The live `hcloud firewall describe` + `curl`-bypass acceptance is a **closure-smoke on a real Hetzner cluster** (rides the next nightly `e2e/mvp.sh` / a manual check) — all logic is unit-covered (CF-fetch seam, fail-fast ordering, rule-building, set_rules diff).

**Source:** CF orange без origin firewall = theatre (атакующий ходит мимо CF по IP узла).

**Цель:** Hetzner Cloud Firewall разрешает 80/443 inbound только из CF IPv4/v6 сетей; остальное deny. Один firewall обслуживает все зарегистрированные зоны — CF IPs универсальны across CF zones. Label `apprafter=true` на firewall-ресурсе для существующего idempotency-слоя. Fail-fast при недоступности CF endpoints — никакого stale snapshot'а.

**Поставка:**
- [x] `cli-providers` — CF IP fetcher (delivered as `cloudflare::fetch_cloudflare_ips` + `CloudflareIpSource` seam, NOT a `cf_ingress_firewall_rules()` builder):
    - Pull `https://www.cloudflare.com/ips-v4` и `ips-v6` на каждый apply (text body, по CIDR на строку).
    - **Fail-fast:** non-200 / network error / empty body ⇒ apply abort'ится с error «cannot fetch Cloudflare IP ranges; aborting to avoid stale firewall». Никаких hardcoded fallback CIDRs.
    - Build inbound rules: `tcp:80 from <cf-v4 ∪ cf-v6>`, `tcp:443 from same set` (via `apply_cf_origin`). SSH (22) / 6443 / 51820 / ICMP — не трогаем (6443 нельзя CF-gate'ить — `kubectl`).
- [x] `commands/apply.rs` — `resolve_cf_ips()` (opt-in `cloudflareOrigin`) фетчит CF IPs **ПЕРЕД** любой cloud-mutation, затем `build_firewall_spec(..., cf_ips)`; firewall аттачится к серверу существующим путём, label `apprafter=true` сохранён.
- [x] Idempotency: дельта против existing firewall — **закрыт create-only gap**: `set_firewall_rules` (`POST .../actions/set_rules`) + `Action::SetFirewallRules` + order-insensitive `rules_differ` ⇒ CF drift (и любое изменение правил) подхватывается на re-apply.
- [x] Tests: in-file mock на CF endpoints (`CloudflareIpSource` seam) — фиксированный набор + fail-fast paths (non-200/transport/empty) + ordering-тест (failing source ⇒ apply abort'ится до cloud-call'а) + rule-building + set_rules diff.
- [x] Doc-note: «Origin firewall pulls CF IPs on every `apprafter apply`; periodic re-apply (quarterly) recommended; PlatformController-managed cloud-firewall — future work» — записан в compatibility.cue 0.2.35 notes + design §Out-of-scope.

**Acceptance:**
- [x] На свежем bootstrap: `hcloud firewall describe <name>` показывает текущие CF v4 + v6 диапазоны на 80/443 — **closure-smoke** (real Hetzner, рядом со следующим `e2e/mvp.sh`).
- [x] `curl --resolve <любая-зона>:443:<node-ip> https://<зона>/` минуя CF ⇒ connection refused/timeout — **closure-smoke** (real Hetzner).
- [x] `curl https://<зона>/` через CF ⇒ 200 — **closure-smoke** (real Hetzner).
- [x] Mock network outage на CF endpoints ⇒ `apprafter apply` aborts до изменения cloud state — **unit-covered** (`resolve_cf_ips_fail_fast_propagates_when_on`).

**Зависит от:** 1.2 ✅, 1.83a.

**Размер:** S

---

### 1.83e `apprafter target cert import` — multi-call под imported certs
> 🏁 SR: A · order 3.5 — public ingress MVP (completes T1 demo); minimal slice — full ingress остаётся order 5 (4.1/4.1a/4.4a)

> ✅ **CLOSED 2026-06-14** (design `docs/superpowers/specs/2026-06-14-1-83e-cert-import-design.md`). Release: cli **v0.2.19** (CLI-only — no schema/operator/chart change). **Decisions/deviations:** (1) **imperative `kubectl` server-side-apply** of a plain `kubernetes.io/tls` Secret (field-manager `apprafter-cli`), NOT sealed/GitOps — the Gateway terminates TLS from a plain tls Secret, and this is a `target`-level admin op like its siblings. (2) **RSA-only** this slice (CF Origin CA is RSA 2048); a non-RSA key → a clear "unsupported (deferred to 4.1b)" error. (3) **Expiry: reject only already-invalid** (notAfter past / notBefore future), **warn (not reject) at `<30d`** — the plan's literal "expiry > 30 days" would block a legitimate short-validity cert. (4) Implemented as a pure `cli-providers::cert` module (parse/validate/expiry/build, openssl-fixture unit tests + a redacting `Debug` that never prints the key) + a thin `target.rs` command; everything that can fail aborts BEFORE any cluster write. (5) Live acceptance (Secret applied + Gateway pickup) is a **closure-smoke on the end-of-1.83-track manual walk** (real Hetzner), NOT unit-tested — the pure logic is fully unit-covered.

**Source:** subset 4.1b `apprafter target cert import`.

**Цель:** import imported-cert как `kubernetes.io/tls` Secret с labels/annotations, точно совпадающими с full 4.1b spec — для bit-identity при landing'е 4.1b. CLI-сигнатура идентична 4.1b: `apprafter target cert import <name> --cert <path> --key <path>`. Может вызываться много раз для разных registrable-зон (один Secret per zone).

**Поставка:**
- [x] `apprafter target cert import <name> --cert <pem> --key <pem> [--namespace apprafter-system] [--replace]`:
    - Pre-validation: PEM parse, cert matches key (RSA), SANs extracted; **expiry — reject только already-invalid, warn при `<30d`** (не «> 30 days» hard-reject).
    - Creates Secret в `apprafter-system` (default ns для platform certs), type `kubernetes.io/tls`, name из позиционного аргумента; imperative `kubectl` SSA (field-manager `apprafter-cli`).
    - Labels (точно как в 4.1b):
        - `apprafter.io/managed-by: apprafter`
        - `apprafter.io/cert-mode: imported`
        - `apprafter.io/cert-name: <name>`
    - Annotations: `apprafter.io/cert-not-before`, `apprafter.io/cert-not-after`, `apprafter.io/cert-sans`.
    - `--replace`: in-place update Secret'а (no downtime — Gateway API подхватывает новый Secret); без `--replace` существующее имя → reject.
- [x] Output: SANs, valid-until, hint `apprafter target domain add <zone> --cert <name>` + ссылка на CF-origin doc-page.
- [x] Doc-page «Cloudflare Origin CA certificate» (`docs/public-ingress/cloudflare-origin-cert.md`, в mkdocs nav «Public ingress»).
- [x] Deferred to full 4.1b (subset note): `cert list`, `cert show`, `cert renew`, `cert remove`, `--chain` flag, ECDSA/EdDSA ключи, MigrationPlan при remove с active references.

**Acceptance:** (логика unit-покрыта; live-применение Secret'а на кластере = **closure-smoke на track-end walk**, real Hetzner)
- [x] `apprafter target cert import cf-origin-cert-apprafter-dev --cert ./d.pem --key ./d.key` создаёт Secret с правильными labels/annotations — **closure-smoke** (build_tls_secret shape unit-покрыт).
- [x] Повторный вызов с другим именем создаёт отдельный Secret — multi-zone, никаких коллизий — **closure-smoke**.
- [x] Mismatched cert/key ⇒ fail до записи Secret — **unit-covered** (`rejects_cert_key_mismatch` + fail-before-cluster-write ordering).
- [~] `--replace` обновляет Secret in-place, listener'ы подхватывают новый cert без рестарта — **closure-smoke**.
- [x] Labels/annotations bit-identical с тем, что произведёт 4.1b на том же входе — **unit-covered** (`build_tls_secret_has_locked_shape`).

**Зависит от:** 1.79a.

**Размер:** S

---

### 1.83f `apprafter target domain` — multi-zone CLI
> 🏁 SR: A · order 3.5 — public ingress MVP (completes T1 demo); minimal slice — full ingress остаётся order 5 (4.1/4.1a/4.4a)

> ✅ **CLOSED 2026-06-15** (design `docs/superpowers/specs/2026-06-15-1-83f-target-domain-design.md`). Release: cli **v0.2.20** (CLI-only — `#AllowedDomainEntry` уже полный + `spec.values` preserve-unknown ⇒ нет chart/cue-cmp/operator бампа). **Decisions/deviations:** (1) запись массива через **JSON merge-patch (`kubectl_merge_patch`), НЕ SSA** — `allowedDomains` под preserve-unknown `spec.values`, чья SSA-гранулярность apiserver-зависима; merge-patch path-scoped и доказуемо сохраняет sibling-поля (`tier`/`nodePublicIP`/`egress`). (2) `addedBy` = `--added-by` ∥ `$USER` ∥ "unknown" (в CLI нет identity-системы). (3) apps-using guard считает **любую** matching-hostname app (base+per-env), не только public — консервативно. (4) `add` apex-only (reject `*.`). (5) `remove` сначала проверяет domain-registered, потом apps-guard; cert Secret сохраняется. (6) Чистая логика unit-покрыта в `commands/target_domain.rs`; live merge-patch + Gateway-listener-генерация + `curl` = **closure-smoke на track-end walk** — walk обязан проверить, что merge-patch сохранил `tier`/`nodePublicIP`/`egress` + `allowedDomains` переживает reconcile. (7) `apprafter` — BINARY-крейт, поэтому хелперы + их command-вызыватели легли одним коммитом (`-D warnings` dead_code на невызванных хелперах; в отличие от 1.83e, где cert-модуль жил в LIBRARY-крейте `cli-providers`).

**Source:** subset 4.1b `apprafter target domain` группа.

**Цель:** идиоматическая регистрация зон с массивом entries; CLI-сигнатура и UX идентичны 4.1b. Под капотом slice-impl патчит `PlatformStack.spec.values.gateway.allowedDomains: [#AllowedDomainEntry]`; full 4.1b impl переносит storage в `ExternalSurface.spec.allowedDomains` — **массив тот же, shape entry тот же, CLI-команда та же**. Stability promise screencast-friendly.

**Поставка:**
- [x] Shape entry в `values.gateway.allowedDomains[]` (уже объявлен в chart'е как `#AllowedDomainEntry`, 1.83a — CLI его не добавлял, а использует; bit-identical с 4.1b `#DomainEntry` минус computed `wildcard`):
    ```cue
    {
        domain:           string         // например "apprafter.dev"; apex registrable, без префикса "*."
        certMode:         "imported"     // slice-only literal; 4.1b расширяет enum
        importedCertRef:  string         // имя Secret'а из 1.83e
        addedAt:          string         // ISO timestamp (CLI заполняет)
        addedBy:          string         // identity (CLI: from active target's user record или env)
    }
    ```
- [x] `apprafter target domain add <domain> --cert <cert-name>`:
    - Validation: `<domain>` это RFC 1123 hostname без префикса `*.` (apex registrable; wildcard listener генерится chart'ом автоматически из apex entry).
    - `--cert <name>` **required в slice** (нет LE-дефолта; в 4.1b становится optional с дефолтом `letsencrypt-http01`, signature-stable — existing вызовы с `--cert` продолжают работать).
    - Pre-check 1: Secret `<cert-name>` существует в `apprafter-system` с label `apprafter.io/cert-mode: imported`. Не существует ⇒ error «Cert '<x>' not found. Run `apprafter target cert import <x> --cert ... --key ...` first».
    - Pre-check 2: domain уже в массиве ⇒ reject «Domain already registered: <existing>. Use `apprafter target domain remove <existing>` to swap».
    - Action: **merge-patch** `PlatformStack.spec.values.gateway.allowedDomains` (`kubectl_merge_patch`, path-scoped — НЕ SSA; сохраняет sibling-поля), append entry с `certMode: "imported"`, `importedCertRef: <cert-name>`, `addedAt: <now>`, `addedBy: <identity = --added-by ∥ $USER ∥ "unknown">`.
    - Output: registered domain, public IP узла из `spec.values.gateway.nodePublicIP{,v6}` (для DNS A/AAAA records у регистратора), hint про CF setup (orange + Full strict) и `apprafter target domain list`.
- [x] `apprafter target domain list`:
    - Таблица: Domain, Cert, Apps (count Application'ов с matching `expose.hostname`), Added At, Added By.
    - Пустой массив ⇒ "No domains registered. Run `apprafter target domain add <zone> --cert <name>`".
- [x] `apprafter target domain remove <domain>`:
    - Pre-check: domain-registered FIRST (иначе «Domain not registered»), затем scan Application'ов с `expose.hostname` matching `<domain>` (apex) или `<label>.<domain>` (single-label wildcard), base+per-env. Active apps есть ⇒ error «<N> applications using <domain>: [list]. Remove apps first or use `--force` (apps will lose external access)».
    - `--force`: clears entry, output warning per affected app.
    - merge-patch удаляющий entry из массива.
    - Cert Secret **не удаляется** (matches 4.1b separation `domain remove` vs `cert remove`; orphan cert acceptable в slice).
- [x] Deferred to full 4.1b (subset notes): `--cert` optional (LE default), wildcard `*.example.com` domain entries (slice — apex only), `target domain verify`, `set-default`, `status`, MigrationPlan для destructive ops, cert renewal flows, `target cert remove` orphan-check.
- [x] **Stability promise** в UNRELEASED/RELEASE notes: «`apprafter target domain add/list/remove` сигнатура стабильна между slice-impl (PlatformStack-storage) и full 4.1b (ExternalSurface-storage). Array shape entry и CLI-сигнатуры идентичны».

**Acceptance:** (чистая логика — apex-validation, entry-build, dedup, hostname-match, apps-scan — unit-покрыта; всё ниже = **closure-smoke на track-end walk**, real Hetzner; walk также проверяет, что merge-patch сохранил `tier`/`nodePublicIP`/`egress` + `allowedDomains` переживает reconcile)
- `apprafter target domain add apprafter.dev --cert cf-origin-cert-apprafter-dev` ⇒ массив получает entry; через ~2-3 минуты Gateway получает пару listener'ов (apex + wildcard) для apprafter.dev.
- Второй `add apprafter.io --cert cf-origin-cert-apprafter-io` ⇒ ещё одна entry; Gateway получает ещё пару listener'ов на другом cert.
- `list` показывает обе зоны с правильным count apps.
- `add apprafter.dev ...` второй раз ⇒ reject (duplicate).
- `add foo.dev --cert non-existent` ⇒ reject (cert not found).
- `add "*.example.com" --cert ...` ⇒ reject (wildcard input not supported в slice — apex only).
- `add example.com` без `--cert` ⇒ reject (cert required в slice).
- `remove apprafter.io` без active apps ⇒ entry удалена; Gateway теряет соответствующие listener'ы; Secret остаётся.
- `remove apprafter.dev` с active landing app ⇒ reject; `--force` clears + warning.

**Зависит от:** 1.72 ✅, 1.73 ✅, 1.79a, 1.83a, 1.83e.

**Размер:** S+

---

### 1.83g One-time DNS + CF setup runbook (per-zone iteration)
> 🏁 SR: A · order 3.5 — public ingress MVP (completes T1 demo); minimal slice — full ingress остаётся order 5 (4.1/4.1a/4.4a). NB: manual stand-in для 4.4a — после landing 4.4a (external-dns) этот runbook deprecated.

> ✅ **CLOSED 2026-06-15** (docs-only — НЕТ cli-бампа/монорепо-тега). Runbook-страница `docs/public-ingress/connect-a-domain.md` («Connect a domain») + mkdocs nav (под «Public ingress», выше cert-страницы). Структура: (1) one-time cluster prep — включить CF origin firewall (`Infrastructure.spec.firewall.cloudflareOrigin: true` + `apprafter apply`, 1.83d) — добавлено к плановому per-zone flow, т.к. firewall cluster-wide; (2) per-zone loop (CF add-site → NS swap → DNS A/AAAA proxied → Full strict → Origin CA cert (линк на существующую `cloudflare-origin-cert.md`, не дублирует) → `target cert import` → `target domain add` → apply Application с `expose.hostname`); (3) verify (per-zone curl, cross-zone, firewall-bypass-blocked, `target domain list`) + removing-a-zone. Strict mkdocs build GREEN. **Живая verify-проверка (curl'ы) = closure-smoke на track-end ручном walk** (real Hetzner) — страница её документирует, не исполняет. **Это последняя subphase 1.83-трека**; следующее — консолидированный track-end walk (НЕ phase closure — 1.83 = order-3.5 pulled-up, не нумерованная фаза, spec.md не актуализируется).

**Source:** outside-of-code, замыкает acceptance слайса.

**Цель:** documented one-time flow для каждой registrable-зоны: registrar → CF NS swap → CF Origin CA cert → `apprafter target cert import` → `apprafter target domain add`. Повторяется столько раз, сколько зон.

**Поставка (docs):** (всё ниже задокументировано в `connect-a-domain.md`; живые curl-проверки — на track-end walk)
- [x] **Per registrable zone** (повторяется per domain):
    - CF: Add site `<zone>` → Free plan → записать два NS.
    - У registrar'а (GoDaddy/Namecheap/etc.): выключить DNSSEC; Nameservers → custom → CF NS.
    - CF: ждать «Active»; DNS records:
        - `A @ <node-v4>` proxied
        - `AAAA @ <node-v6>` proxied
        - `CNAME www <zone>` proxied (опционально)
    - CF: SSL/TLS mode → **Full (strict)**.
    - CF: SSL/TLS → Origin Server → Create Certificate (hostnames `<zone>` + `*.<zone>`, RSA 2048, validity 15 years). Скачать cert + key.
    - `apprafter target cert import cf-origin-cert-<sanitized-zone> --cert ./origin.pem --key ./origin.key` (1.83e).
    - `apprafter target domain add <zone> --cert cf-origin-cert-<sanitized-zone>` (1.83f).
- [x] Apply Application'ов с обновлённой схемой (`expose.hostname: "<some-zone-or-subdomain>"`, 1.83b) — задокументировано.
- [x] Verify per zone: `curl -v https://<zone>/` — CF cert на edge, response от соответствующего Application — **track-end walk**.
- [x] Verify cross-zone: на одном кластере одновременно отвечают `https://apprafter.dev/` и `https://apprafter.io/` (или сколько зон зарегистрировано), каждая со своим cert на edge — **track-end walk**.
- [x] Verify firewall bypass blocked: `curl --resolve <zone>:443:<node-ip> https://<zone>/` минуя CF — connection refused/timeout (1.83d) — **track-end walk**.

**Acceptance:** все зарегистрированные зоны отдают свои Application'ы через CF; direct-to-node connections refused; `apprafter target domain list` показывает все зоны с правильным apps-count.

**Зависит от:** 1.83a–f.

**Размер:** S

---

### 1.83h `apprafter target firewall` — manifest-free origin-firewall toggle
> 🏁 SR: A · order 3.5 — public ingress MVP (completes T1 demo). NB: net-new, всплыло из T1-UX вопроса пользователя — замыкает последний manifest-bound кусок public-ingress флоу.

> ✅ **CLOSED 2026-06-15** (net-new; design `docs/superpowers/specs/2026-06-15-1-83h-target-firewall-design.md`). Release: cli **v0.2.21** (CLI-only — `TargetConfig` Rust-only, без CUE/CRD-мирора; firewall out-of-cluster). **Проблема:** включение CF origin firewall (1.83d) было ЕДИНСТВЕННОй manifest-bound частью T1-флоу (требовало `Infrastructure.spec.firewall.cloudflareOrigin: true` + `apprafter apply`); всё остальное (`target cert import`/`target domain`/`platform egress set`) уже императивно. **Решение/decisions:** (1) `apprafter target firewall cloudflare-origin enable|disable` — **persist** toggle в target-store (`TargetConfig.firewall.cloudflareOrigin`) + **сразу реконсайл live Hetzner-firewall** (переиспользует 1.83d: `fetch_cloudflare_ips` + `build_firewall_spec` + `set_firewall_rules`; enable → 80/443 на CF-диапазоны, disable → wide-open). (2) `apply`/`up` уважают toggle через чистый `cf_origin_enabled(manifest, target)` (manifest `cloudflareOrigin` override > target-store > false) — manifest-less re-provision не сбрасывает firewall. (3) Не запровижен (firewall ещё нет) → persist-only + warn. (4) firewall-spec билдеры вынесены из `apply.rs` в `commands/firewall_spec.rs` (DRY) + `rule_spec_to_wire` → pub. (5) Live `set_firewall_rules` реконсайл = **closure-smoke на track-end walk**; чистая логика (TargetConfig round-trip, cf_origin_enabled precedence, build_firewall_spec) unit-покрыта.

**Поставка:**
- [x] `TargetConfig.firewall: Option<FirewallConfig{cloudflareOrigin: bool}>` (cli-core, serde-default, без schema).
- [x] `apprafter target firewall cloudflare-origin enable|disable` — persist + live reconcile (или persist-only + warn если кластер не запровижен).
- [x] `apply` fallback: `cf_origin_enabled(manifest, target)` (manifest override > target-store > false); `resolve_cf_ips(enabled: bool)`.
- [x] Вынос `commands/firewall_spec.rs` (`build_firewall_spec`/`default_ingress_rules`/`apply_cf_origin`/`rule_from_manifest`) + pub `rule_spec_to_wire`.
- [x] Runbook `connect-a-domain.md` §1 → команда (manifest-путь оставлен как fork/IaC-заметка).

**Acceptance:** (чистая логика unit-покрыта; live ниже = **closure-smoke на track-end walk**, real Hetzner)
- [x] `apprafter target firewall cloudflare-origin enable` (без манифеста) → `hcloud firewall describe <cluster>-fw` показывает CF v4+v6 на 80/443 (22/6443/51820/ICMP открыты).
- [~] `... disable` → 80/443 обратно на `0.0.0.0/0`+`::/0`.
- [~] enable затем `apprafter up` (без манифеста, re-provision) → firewall остаётся CF-restricted (target-store toggle переживает, без clobber).
- [~] enable до provision → persist + warn; последующий `up` поднимает firewall CF-restricted.

**Зависит от:** 1.2 ✅, 1.83d ✅.

**Размер:** S+

---

### 1.83i `apprafter target ip` — node public IP readout
> 🏁 SR: A · order 3.5 — public ingress MVP (completes T1 demo). NB: net-new, всплыло на проходе runbook §2.2 (не было способа узнать IP ноды для DNS A/AAAA без kubectl-escape-hatch).

> ✅ **CLOSED 2026-06-15** (net-new; design `docs/superpowers/specs/2026-06-15-1-83i-target-ip-design.md`). Release: cli **v0.2.22** (CLI-only). **Проблема:** на §2.2 runbook'а не было чистого способа узнать публичные IP ноды для DNS-записей — `PlatformStack.nodePublicIP` vestigial (документирован, но CLI его не выставляет; чарт не потребляет с 1.83a host-network), state.json хранит только server_id, ни одна команда IP не показывала. **Решение:** `apprafter target ip` берёт IP **живьём из Hetzner API** (`list_servers().public_net`, server_id из state, токен из target) → печатает `A → <v4>` / `AAAA → <v6>`. IPv6 = адрес ноды `<prefix>::1` (выведен из /64-делегации Hetzner). Не запровижен → «run `apprafter up` first». **Decisions:** (1) чистые хелперы (`node_ipv6_address`/`extract_public_ips`) + live `node_public_ips` — в **cli-providers** (lib-крейт, dead_code-exempt, unit-тест; правильный Hetzner-слой; обход bin-крейт dead_code-ловушки 1.83h). (2) `target domain add`'s IP-подсказка теперь **ссылается** на `apprafter target ip` (убран вечно-пустой nodePublicIP-read), не дублирует lookup. Live-readout (+ `::1` vs реальный v6 ноды) = closure-smoke на track-end walk; чистая логика unit-покрыта.

**Поставка:**
- [x] cli-providers: `node_ipv6_address` + `extract_public_ips` (pure, unit-тест) + `node_public_ips` (live `list_servers`).
- [x] `apprafter target ip` (`TargetCommand::Ip`) → live A/AAAA readout; «run up first» если не запровижен.
- [x] `target domain add`'s IP-подсказка → ссылка на `apprafter target ip` (drop nodePublicIP-read).
- [x] Runbook `connect-a-domain.md` §2.2 → `apprafter target ip` (+ caveat про Hetzner INTERNAL-IP в fallback).

**Acceptance:** (чистая логика unit-покрыта; live = **closure-smoke на track-end walk**)
- [x] `apprafter target ip` на запровиженном T1 → печатает v4 (совпадает с Hetzner-консолью) + v6 `::1`; подтвердить, что `::1` = реальный v6 ноды.
- [~] `apprafter target ip` до provision → «run `apprafter up` first».
- [x] `target domain add` печатает ссылку на `apprafter target ip` (нет «not recorded»).

**Зависит от:** 1.2 ✅.

**Размер:** S

---

### 1.83j `apprafter platform env set/show` + `app list` ENV-колонка
> 🏁 SR: A · order 3.5 — public ingress MVP track (env-management UX). NB: net-new, всплыло на проходе runbook'а (вопрос «как из CLI выставить/посмотреть дефолтный env кластера и env задеплоенного app»).

> ✅ **CLOSED 2026-06-15** (net-new; design `docs/superpowers/specs/2026-06-15-1-83j-platform-env-design.md`). Release: cli **v0.2.23** (CLI-only). **Проблема:** `PlatformStack.spec.defaultEnvironment` (soft per-cluster default, ADR 0044) выставлялся только сырым `kubectl patch` — не было `apprafter`-команды, хотя CLI его уже *читает* (преселект env-пикера `app add`); и `app list` не показывал env задеплоенных приложений (per-deployment env показывает только `app status`). **Решение:** (1) `apprafter platform env set <env>` / `show` — set/show `spec.defaultEnvironment` через path-scoped JSON **merge-patch** (поле структурное+опциональное, без REQUIRED-siblings → merge-patch проще/безопаснее SSA-dedicated-manager'а egress'а; зеркало `platform freeze`/`unfreeze`); семантика остаётся **SOFT** (преселект визарда, НЕ меняет рендеринг) — оба вывода печатают `SOFT_ENV_NOTE`-дисклеймер, `show` без поля → `(unset)`. (2) `apprafter app list` получил колонку **ENV** (через существующий `deployment_environment` → label `apprafter.io/environment` / `(base)`), так что `app list` и `app status` согласованы по env. **Decisions:** (a) merge-patch, НЕ SSA (нет REQUIRED-siblings под `spec.defaultEnvironment`). (b) SOFT-семантика не усиливается (hard-default = ADR-ревизит, out of scope). (c) НЕТ команды смены env задеплоенного app — env = идентичность Argo-app'а `<name>-<env>`; «смена» = задокументированный `app remove --env old` + `app add --env new` (user-confirmed). Чистые `validate_env`/`default_environment_patch_body` + ENV-колонка unit-покрыты; live merge-patch/get = closure-smoke на track-end walk. Исполнено subagent-driven через Workflow (последовательный implement → параллельное spec+quality Explore-ревью на задачу — обе SHIP, blocking нет).

**Поставка:**
- [x] clap `EnvCommand{Show,Set{env}}` + `PlatformCommand::Env` (зеркало Egress) + main.rs dispatch.
- [x] `platform env set` (merge-patch `spec.defaultEnvironment` + `SOFT_ENV_NOTE`) / `show` (read + `(unset)`).
- [x] `app list` ENV-колонка (после NAME) через `deployment_environment`.

**Acceptance:** (чистая логика + колонка unit-покрыты; live = **closure-smoke на track-end walk**)
- [x] `platform env set staging` патчит `spec.defaultEnvironment` (tier/source/values/network не тронуты — merge-patch сохраняет siblings); `show` печатает значение/`(unset)` + дисклеймер.
- [x] после `env set staging` интерактивный `app add` преселектит `staging`.
- [x] `app list` показывает ENV-колонку с env каждого деплоя (`<env>` / `(base)`).

**Зависит от:** 2.9 ✅ (ADR 0044).

**Размер:** S

---

### 1.83 — Track-end ручной walk (закрытие order-3.5 public-ingress трека)
> 🏁 SR: A · order 3.5 — консолидированный live-прогон на real Hetzner; батчит отложенные «closure-smoke на track-end walk» хвосты 1.83d/e/f/g/h/i/j.

> ✅ **WALK PASSED 2026-06-18** (real Hetzner, user-confirmed) — закрывает order-3.5 public-ingress MVP трек целиком. Код 1.83a–j был закрыт ранее (v0.2.14…v0.2.23); этот прогон снимает все отложенные live-проверки из `connect-a-domain.md`: CF origin firewall активен + bypass (`curl --resolve … минуя CF`) refused (1.83d/h), `target cert import` → Gateway терминирует TLS импортированным сертом (1.83e), multi-zone `target domain` listeners + per-zone/cross-zone `curl https://<zone>/` через CF = 200 + merge-patch сохранил `tier`/`nodePublicIP`/`egress` siblings (1.83f/g), `target ip` отдаёт верные A/AAAA (1.83i), `platform env`/`app list` ENV (1.83j). **НЕ phase closure** — 1.83 = pulled-up order-3.5, не нумерованная фаза → spec.md НЕ актуализируется, монорепо-тег НЕ ставится (docs/plan-only). **Следующее по SR-порядку: `2.6c`** (order 3.5 — needs.disk durability + cross-app SharedVolume).

---

## Фаза 1.9 — Dev Mode MVP (Phase 1B из dev-mode-task.md)
> 🏁 SR: D — dev mode dropped from launch (managed users don't bootstrap local clusters); reactivate after managed traction

**Цель фазы:** ship minimum viable dev mode для локальной разработки на k3d. CLI команды: `apprafter dev cluster up/down/status/wipe`, `apprafter dev init`, `apprafter dev up`, `apprafter dev down`, `apprafter dev list`, `apprafter dev logs`. Manifest layering 4 уровня (Application.base + environments.dev + DevProfile + DevProfileLocal). `needs.*` resolution в эту фазу **не входит** — лендится в Фазе 2.9. Помечается `experimental` для users.

**Source of truth:** `dev-mode-task.md` §20 Phase 1B (sub-items 1B.1 – 1B.12).

**Spec:** `spec.md` §3.10, §3.11.

**Зависит от:** Phase 1.5 closed. Нужны: PlatformStack CRD (1.72), MigrationPlan CRD (1.75), `tiers/dev.cue` overlay в platform-stack chart (опт-ин/опт-аут defaults per dev-mode-task.md §12.2), Application reconciler dev-awareness hooks.

**Поставка:** items 1B.1 – 1B.12 из `dev-mode-task.md` §20 перетаскиваются сюда AI-агентом по мере реализации (как 1.6.1, 1.6.2, …), с реальными размерами и acceptance criteria для каждого. Тот же паттерн, что Track A из Phase 1.5 (где cli-dx items живут в `cli-dx-task.md` §17 и lend'ятся в plan.md по факту).

**Версии:** `v0.1.x` patch series (без closing tag — M2 стартует следующим коммитом с bump на `v0.2.0`).

**Размер (aggregate):** M+ (~1.5–2 недели FT по dev-mode-task.md §20). Корректируется по факту перетаскивания items.

---

## Фаза 2 — Платформенные сервисы (M2) ⚡

**Цель фазы:** Application может декларировать `needs.{pg,jetstream,redis}` — операторы и ServiceProvider'ы выделяют ресурсы автоматически.

**Spec:** §6 M2, §3.2, §3.3, §4.4, §4.6, §3.1 (per-env overrides).

### 2.1 ServiceProvider CRD
> 🏁 SR: A · order 3 (Phase-2 minimum)
> v0.2.1 — 2.1 shipped: ServiceProvider CRD (CUE schema + OpenAPI v3 CRD + kube-rs type + admission validator/dispatch/webhook + cue-vet example + tests). Namespaced. Tier-aware defaults deferred to 2.4–2.6.
> v0.2.2 — 2.1 re-release (release-pipeline fix): the v0.2.1 operator+webhook images were clobbered on ghcr by their own Helm charts (chart and image share the repo path `ghcr.io/apprafter/apprafter-operator`; uniform chartVersion==appVersion let the chart push overwrite the image tag → pods crash-looped `exec: no such file`). Fix: charts now publish to the `ghcr.io/apprafter/charts` OCI sub-namespace (new `apprafter-charts` enableOCI registration in loader_values.cue; components' repoURL points there). v0.2.1 abandoned.

**Поставка:**
- [x] CUE-схема + admission webhook.
- [x] Поля: `type`, `backend`, `labels`, `config` (raw map), `status.health`.
- [x] Built-in типы (закрытый enum в v1alpha1): `pg`, `jetstream`, `clickhouse`, `redis`, `s3`, `notifications`.
- [ ] Tier-aware defaults в схеме (через `if tier == 1 ...`). — **deferred to 2.4–2.6** (concrete tier-default provider instances land with the actual providers; 2.1 ships schema + admission only)

**Acceptance:** ServiceProvider валидируется; неизвестный `type` без плагина — ошибка admission.

**Зависит от:** 1.7

**Размер:** S

---

### 2.2 ResourceClaim CRD
> 🏁 SR: A · order 3 (Phase-2 minimum)
> v0.2.3 — 2.2 shipped: ResourceClaim CRD (CUE schema +status.conditions + OpenAPI v3 CRD + kube-rs type + operator-only admission validator/dispatch/webhook + cue-vet example + tests). Namespaced. Operator-only CREATE (operator SA OR system:masters); UPDATE ungated. status.conditions schema-only (writer in 2.3); no creator until 2.4.

**Поставка:**
- [x] CUE-схема + admission webhook.
- [x] Поля: `type`, `selector`, `spec` (size, etc.), `status.{provider, connectionSecretRef, ready, conditions}`.
- [x] Создаётся **только** оператором, юзер-create запрещён admission.

**Зависит от:** 2.1

**Размер:** S

---

### 2.3 Selector matching и provider scheduler
> 🏁 SR: A · order 3 (Phase-2 minimum)
> v0.2.4 — 2.3 shipped: ResourceClaim scheduler controller (operator-controllers-resourceclaim-scheduler, 5th controller). Type-equal + selector-superset match, cluster-wide provider listing, alphabetical tie-break; on match writes status.provider + Scheduled=True; no-match -> Scheduled=False + NoMatchingServiceProvider event + apprafter_claim_unmatched_total. Pending claims re-evaluate on a 300s requeue (a ServiceProvider watch needs a reflector Store — deferred). ready/connectionSecretRef + provisioning deferred to 2.4.

**Цель:** Reconcile ResourceClaim → matching ServiceProvider по labels.

**Поставка:**
- [x] Лог matching-логики: точное соответствие labels, default `tier: integrated`.
- [x] При нескольких подходящих — детерминированный выбор (alphabetical `name`).
- [x] При отсутствии подходящего — Status `Pending`, событие.
- [x] Метрики: `claim_unmatched_total`.

**Deferred (tracked follow-up, not debt-blocking):**
- [ ] `Controller.watches(ServiceProvider)` for **immediate** self-heal of `Pending` claims. 2.3 shipped a **300s requeue** fallback instead — a late-arriving provider rescues a Pending claim within ≤5 min, not instantly. Deferred because the event→claims mapper needs a `reflector::Store<ResourceClaim>` (cross-resource fan-out), out of the 2.3 MVP scope and moot until claims exist. Revisit in/after **2.4** (once the Application operator generates claims) or when claim volume/latency warrants; mind the O(claims×providers) fan-out at scale.

**Зависит от:** 2.2

**Размер:** S

---

### 2.4 needs.pg → CloudNativePG
> 🏁 SR: A · order 3 (Phase-2 minimum) — needs.pg, the launch database

**Первая user-facing фича Фазы 2** — закрывается подробным ручным walk'ом на реальном Tier-1 (2.4g, см. [[feedback_phase_closure_validation]] / [[feedback_walk_ux_coverage]]). NOTE: 2.4 ≠ закрытие Фазы 2 — НЕ флипать §6 M2 на 2.4g (M2 закрывается после 2.5/2.6/2.10–2.12).

**Сквозной поток:** `Application.spec.base.needs.pg {selector?, size?}` → Application-контроллер генерирует дочерний `ResourceClaim` (type pg, ownerRef, дефолтный selector `{tier:integrated}` инжектится контроллером) + ставит app в новую фазу-паузу `AwaitingResourceClaim` (зеркало AwaitingMigrationApproval) → scheduler 2.3 (переиспользуется) матчит → `status.provider=pg-integrated` + `Scheduled=True` → новый 6-й контроллер `resourceclaim-provisioner` провижинит per-claim CNPG Database+role+Secret и пишет `status.ready`+`connectionSecretRef`+`Ready` под СВОИМ field manager → operator-rendering инжектит DSN (`DATABASE_URL` через secretKeyRef) в Deployment env → app коннектится. На delete: finalizer снапшотит в `RetainedClaim` (retainUntil=now+7d) → GC дропает DB+Secret после истечения.

**Зафиксированные решения (с пользователем, 2026-06-02):**
- **CNPG footprint на Tier-1 = оператор always-on, shared-кластер LAZY.** platform-stack ставит CNPG-оператор (always-on, лёгкий) + `pg-integrated` ServiceProvider CR, но НЕ сидит shared Cluster. `resourceclaim-provisioner` создаёт shared `platform-postgres` CNPG Cluster **лениво + идемпотентно на первом матченном claim'е** (единоличный owner — нет гонки контроллеров). Solo-кластеры без pg-приложений не платят за Postgres-под. Первый pg-claim имеет повышенную латентность (boot кластера ~30–60с) — её закрывает пауза-гейт `AwaitingResourceClaim`. Кластер НЕ сносится при опустошении claim'ов.
- **Provisioner = НОВЫЙ generic-крейт `operator-controllers/resourceclaim-provisioner`** (6-й контроллер), свой field manager — НЕ расширение scheduler'а (сохраняет чистый SSA-split: scheduler владеет `status.provider`+`Scheduled`, provisioner — `ready`+`connectionSecretRef`+`Ready`). Generic, чтобы 2.5 jetstream / 2.6 redis переиспользовали крейт (dispatch по типу/backend claim'а).
- **`needs.pg` = объект `{selector?, size?}`** на тип сервиса (закрытый enum), пере-добавляется в 4 зеркала (CUE application.cue + kube-rs ApplicationBaseSpec + OpenAPI v3 crd-application.yaml + admission webhook). `needs` был удалён на f81e350; CUE — пермиссивно, non-empty-selector / size-enum / reserved-`DATABASE_URL` → CRD+webhook.

**Декомпозиция (порядок сборки):**
- [x] **2.4a** ✅ — CNPG-оператор как platform-stack component (`component_cloudnative-pg.cue`, chart 0.28.2 → operator appVersion 1.29.1, ns cnpg-system, sync-wave -5, project platform-providers) + сид `pg-integrated` ServiceProvider через НОВЫЙ data-driven umbrella-шаблон `templates/serviceproviders.yaml` (зеркало `appProjects`-механизма: `#ServiceProviderSeed` + `_serviceProviders` + render-task; `SkipDryRunOnMissingResource=true` на CRD-гонку), tier-aware `instances` (T1=1 / T2=3). **platform-stack-only**: `currentVersion` 0.2.4→0.2.5 + compatibility (change=safe, `operatorVersion` остаётся v0.2.4); БЕЗ operator appVersion bump, БЕЗ cli bump, БЕЗ monorepo-тега; `platform-stack/v0.2.5` — workflow-made на пуше. **БЕЗ сида Cluster CR** (lazy — 2.4c создаст лениво). Реализовано subagent-driven (6 коммитов) + двухстадийная ревизия (spec ✅ / quality Approved-with-nits → breadcrumb-фиксы применены). Гейт зелёный. Ждёт пуша + CI.
- [x] **2.4b** ✅ — пере-добавлен `needs` в 3 зеркала (CUE `application.cue` `#ServiceNeed` + `needs?: [#PlatformServiceType]: #ServiceNeed`; kube-rs `operator-core` `ServiceNeed` + поле на `ApplicationBaseSpec`; OpenAPI v3 CRD под base И environments — `selector` minProperties 1 + `size` enum) + webhook (отклоняет неизвестные `needs`-ключи, base + per-env). `f81e350` снёс лишь skeleton-заглушку — форма спроектирована заново по spec §3.1. Чистая схема, без поведения контроллера (генерация claim'ов — 2.4d; reserved-`DATABASE_URL` guard — 2.4e). **Уточнение по зеркалам:** CLI-копия Application CRD (`cli-providers::k8s::application_crd`) удалена ещё в B.1.71 — CRD шипает только чарт оператора, поэтому 2.4b **НЕ трогает cli/** → operator+platform-stack release **0.2.6** (re-uniform после platform-stack-only 2.4a@0.2.5), БЕЗ cli-bump/monorepo-тега. subagent-driven (6 коммитов) + двухстадийная ревизия (spec ✅ / quality Approved-with-nits → 3 фикса применены: точный CUE-комментарий о закрытости + sync-нота webhook'а на 4 сайта + multi-bad-key тест). Гейт зелёный. Ждёт пуша + CI.
- [x] **2.4c** ✅ — `resourceclaim-provisioner` контроллер (6-й контроллер, field manager `resourceclaim-provisioner`): для каждого `Scheduled=True` pg-claim'а лениво SSA-applies shared CNPG `Cluster` (`platform-postgres`, создаётся на первом claim'е — solo-кластеры без pg-приложений не платят за Postgres-под), провижинит per-claim role (RMW unkeyed `spec.managed.roles` с retry на 409) + basic-auth Secret (ns cnpg-system) + декларативный CNPG `Database` CR + connection Secret с `DATABASE_URL` (claim ns, ownerRef→claim → каскад на delete), пишет ТОЛЬКО `status.ready`/`connectionSecretRef`/`Ready` под своим field manager (НЕ трогает scheduler-owned `status.provider`/`Scheduled`). Внешние CNPG CR применяются через `DynamicObject` + `ApiResource::from_gvk` (нет compile-time CNPG-типов). **Cleanup — скелет** (решено): connection Secret каскадит по ownerRef; role+DB НЕ удаляются на delete (retained до 2.4f); finalizer на delete только логирует "retained pending 2.4f GC" и снимает себя. Новый RBAC: `postgresql.cnpg.io` clusters+databases CRUD (secrets уже cluster-wide). Новая метрика `apprafter_claim_provisioned_total{backend,namespace}`. Coordinated operator+platform-stack release **0.2.6→0.2.7** (оба чарта version+appVersion, оба component-пина, currentVersion 0.2.7 + compatibility change=safe operatorVersion v0.2.7); БЕЗ CRD-изменений, БЕЗ cli-bump/monorepo-тега; `operator/v0.2.7` + `platform-stack/v0.2.7` — workflow-made на пуше. TDD на pure-хелперах (cnpg builders + decision points), gated smoke `#[ignore]`. Гейт зелёный (fmt/clippy -D warnings/test --workspace, cue vet -c, render-only, helm lint, SPDX). Ждёт пуша + CI + 2.4g manual walk.
- [x] **2.4d** ✅ — генерация claim'а Application'ом + пауза-гейт `AwaitingResourceClaim` (зеркало MigrationPlan-гейта). Контроллер Application для каждого `needs`-ключа эффективного спека SSA-применяет дочерний `ResourceClaim` `{app}-{type}` (DNS-1123-fold, дефолтный селектор `{tier: integrated}` при отсутствии, `size` проброшен при наличии, ownerRef→Application controller=true/blockOwnerDeletion=true для каскада) — пишет **только spec+metadata, НИКОГДА status** (scheduler владеет status.provider/Scheduled, провижионер — status.ready/connectionSecretRef/Ready; строгий SSA-сплит под field manager `apprafter-operator`, payload без ключа `status`); затем пауза в новой фазе `AwaitingResourceClaim` (зеркало `AwaitingMigrationApproval`: `Ready=False`/`ResourceClaimPending` + `ResourceClaimPending=True` с именами unready-claim'ов, observedGeneration+endpointURL сохранены, lastTransitionTime сохранён при already-True) пока каждый claim не отрапортует `status.ready==true` И `connectionSecretRef` (ОБА — закрывает half-ready resume-гонку). Резюм — мгновенный через новый `.owns(ResourceClaim)` watch. **S0-фикс (латентная дыра 2.4b):** `effective_spec` теперь мёржит `needs` на env-override (per-key whole-object replace, зеркало `expose`). **Решения (reversible, в compatibility-нотах):** смена `needs.*.selector` НЕ-деструктивна в 2.4d (без MigrationPlan-гейта; revisit в 2.5+); predicate readiness = ready AND connectionSecretRef. Новый RBAC: правило `resourceclaims` получает `create` (SSA-apply, создающий объект, требует его) — отщеплено от `resourceclaims/status` (контроллер Application никогда не пишет status claim'а). **Scope held:** БЕЗ инъекции DSN/`DATABASE_URL` в Deployment (это 2.4e — `needs.pg`-апп резюмится БЕЗ `DATABASE_URL` до тех пор); БЕЗ Application-side finalizer/GC (2.4f). Coordinated operator+platform-stack release v0.2.7→v0.2.8 (оба чарта version+appVersion, platform-stack component-пины + currentVersion 0.2.7→0.2.8, compatibility change=safe operatorVersion v0.2.8); БЕЗ CRD-изменений, БЕЗ cli-bump/monorepo-тега. Полный цикл generate→provision→resume — на 2.4g real-cluster walk. Гейт зелёный. Ждёт пуша + CI.
- [x] **2.4e** ✅ — инъекция DSN `DATABASE_URL` в Deployment needs.pg-аппа. Три скоординированных изменения, рендерер остаётся ЧИСТОЙ функцией: (A) `operator-rendering` получает проброшенный параметр `needs_secrets: Option<&BTreeMap<String,String>>` (needs-type → connectionSecretRef) и для каждого известного need'а с разрешённым connection-Secret'ом добавляет EnvVar `valueFrom.secretKeyRef{name: <connectionSecretRef>, key: "DATABASE_URL", optional: false}` в контейнер — ПОСЛЕ литерального `env`, итерируя `needs.keys()` (BTreeMap) → байт-стабильный Deployment (SSA no-op; недетерминированный порядок крутил бы оператор). Модульная таблица pg→DATABASE_URL (`NEEDS_ENV_VAR_NAME`) держит **только-pg** (jetstream/redis — 2.5/2.6). (B) reconcile резолвит ready-claim'ы в эту мапу через новый чистый хелпер `resolve_needs_secrets(&[ResourceClaim])` (key=`spec.type_`, value=`status.connectionSecretRef`, пропуск claim'ов без secret-ref), построенный из ТЕХ ЖЕ `current` ready-claim'ов, которые валидировал 2.4d-гейт, ПОСЛЕ прохождения гейта — оператор только ЧИТАЕТ status claim'а (провижионер-owned), НИКОГДА не пишет его (SSA-сплит сохранён); пробрасывает `Some(&map)` (или `None` при пустой/pre-gate) в рендер. (C) admission-webhook отклоняет Application с `needs.pg` И литеральным `env.DATABASE_URL` (коллизия) — ЖЁСТКИЙ reject (не warn; консистентно с hard-enforce-позицией платформы, revisit на UX-polish), ГЛОБАЛЬНО/cross-scope (pg в base ИЛИ любом environment резервирует DATABASE_URL везде), multi-error (по ошибке на поле, без short-circuit). **Scope held:** только-pg; БЕЗ полного 2.12 `claim.*`/`secret()` reference-engine; БЕЗ cross-namespace; БЕЗ CRD/CUE/operator-core схемных изменений; 2.4d readiness AND-гейт НЕ ослаблен (инъекция строго post-gate). Coordinated operator+platform-stack release v0.2.8→v0.2.9 (оба чарта version+appVersion, platform-stack component-пины + currentVersion 0.2.8→0.2.9, compatibility change=safe operatorVersion v0.2.9); БЕЗ cli-bump/monorepo-тега. Полный цикл generate→provision→resume→DSN-injected — на 2.4g real-cluster walk. Гейт зелёный. Ждёт пуша + CI.
- [x] **2.4f** ✅ — `RetainedClaim` CRD + finalizer-снапшот + 7-дневный grace GC-контроллер. Поставлено ОДНИМ юнитом (CRD+finalizer+GC — floor без GC тёк бы вечно, хуже 2.4c; инжектированные часы снимают единственную причину сплита). Новый immutable namespaced `RetainedClaim` CRD (5 hand-rolled зеркал: CUE `retainedclaim.cue` + cue-vet пример, OpenAPI v3 `crd-retainedclaim.yaml` с CEL `self == oldSelf` immutability + БЕЗ status-сабресурса, kube-rs `operator-core` тип, admission `validator_retainedclaim.rs` operator-only CREATE + spec-immutability-on-UPDATE + диспатч в server.rs + VWC). На delete pg-claim'а провижионер-finalizer СНАПШОТИТ его в `RetainedClaim` в **`apprafter-system`** (USER-CHOSEN, leak-safe: platform-ns переживает tenant-ns → GC сработает даже если ns приложения снесён; lineage в `spec.claimRef`, `metadata.name = cnpg::k8s_name(claim_ns, claim_name)`, `retainUntil = deletionTimestamp + 7d`) **ДО** снятия finalizer'а (crash-safe: краш по дороге переприменяет байт-идентичный идемпотентный SSA-снапшот, затем снимает finalizer). Новый **7-й контроллер** (`gc.rs`, та же crate — без нового workspace-member) смотрит `Api::<RetainedClaim>::all` и после `retainUntil` дропает по порядку, каждый шаг идемпотентен + 404-tolerant: per-claim role (RMW unkeyed `spec.managed.roles` через новый pure `cnpg::remove_role` + retry на 409), database через **`spec.ensure: absent` SSA-patch — НЕ delete CR** (Postgres reclaim default = retain, удаление CR НЕ дропнуло бы БД; ensure:absent — правильный дроп, ~1 KB tombstone self-heal'ится при возврате приложения), password Secret (cnpg-ns, без ownerRef → без каскада), затем сам `RetainedClaim`. Un-e2e-able 7-дневный таймер вынесен в PURE `grace.rs` (`compute_retain_until`/`should_gc`/`remaining_grace`) с ИНЖЕКТИРОВАННЫМ `now: DateTime<Utc>` (прод — `Utc::now()`; unit-тесты — ФИКСИРОВАННЫЕ инстанты, без реального ожидания, без env-gated silent-skip; malformed `retainUntil` логирует + requeue, не паникует). Новая метрика `apprafter_claim_gc_total{result,namespace}`; новый RBAC (`retainedclaims` get/list/watch/create/patch/delete + `delete` на cnpg clusters/databases). SSA-сплит сохранён — finalizer только СОЗДАЁТ RetainedClaim (никогда не пишет status ResourceClaim'а); GC читает только spec RetainedClaim'а. TDD на pure-частях (`remove_role` 4 кейса, grace-часы, snapshot-билдер `retained_claim_object`, webhook-валидатор). Coordinated operator + platform-stack release v0.2.9 → v0.2.10 (оба чарта version+appVersion, platform-stack component-пины + currentVersion 0.2.9 → 0.2.10 + compatibility change=safe operatorVersion v0.2.10); БЕЗ cli/Cargo.toml-bump, БЕЗ monorepo v0.x.y-тега; `operator/v0.2.10` + `platform-stack/v0.2.10` — workflow-made на пуше. Гейт зелёный (fmt/clippy -D warnings/test --workspace, cue vet -c, check-platform-stack-version, render-only, helm lint, SPDX). delete → snapshot → GC loop (assert БД реально ДРОПНУТА, не только CR) — на 2.4g real-cluster walk. Ждёт пуша + CI + 2.4g.
- [x] **2.4g** ✅ — `e2e/needs-pg-walk.sh` (k3d, подключён в Justfile + nightly `e2e-pg-nightly.yml`) + **подробный ручной walk на реальном Tier-1** (scaffold→add→provision→DSN→delete→recover→GC). Walk выявил два 2.4f GC-бага → пофикшены walk-fixами (operator v0.2.11 hardening) и **live-подтверждены** на перепрогоне 2026-06-05: (A) recovery time-bomb — ре-провижен отменяет `RetainedClaim` + GC live-guard пропускает дроп живого claim'а (лог `live ResourceClaim present (recovery) … skipping drop`); (B) role-leak — phased drop (`ensure:absent` после DB-дропа → CNPG дропает роль → прун после подтверждения), `pg_roles` пуст после полного GC. Walk также вскрыл отдельный thread platform-version-resolver'а (PlatformController): OCI-пагинация + ghcr `tags:null` (v0.2.12), channel-tag resolver O(1) + publish-side `oras tag` (ADR 0041, v0.2.13), pin-enforcement-survives-poll-failure + condition `UpstreamReachable` (v0.2.14) — каждый adversarial-verified. CLI walk-fixes (app logs inner-name, app status pods+services+claims, scaffold --needs, app add publicness probe, skip-if-current loader, Tier-1 autoUpgrade opt-out, group-qualified Argo wait — 8 коммитов) собраны в **platform-cli v0.2.5** (монорепо-тег v0.2.5). Гейт зелёный (cli build/clippy -D warnings/test + cue vet -c). **NOTE: 2.4 ≠ закрытие Фазы 2 — §6 M2 НЕ флипать.** Ждёт пуша.

**Acceptance:** манифест из §3.1 (parser) с `needs.pg` поднимается, в pg-кластере появляется DB, приложение коннектится.

**Зависит от:** 2.3

**Размер:** L (декомпозирован в 2.4a–g; полный дизайн — память `project_2_4_needs_pg`)

---

### 2.4h — Image tag→digest resolution & auto-rollout (ADR 0040)
> 🏁 SR: A — push→deploy на мутабельном теге; launch-critical UX, притянут через 2.4g walk; **закрыть ДО 2.6**

**Контекст:** re-push образа под тем же тегом (`:latest`) сейчас НЕ катит workload — fake-consistency (Git=`latest`, кластер=`latest`, но разные байты; «что в Git, то в кластере» молча нарушено). Клиентский CI тегает `:latest` из протектед-ветки = деплой (индустриальная практика) → платформа берёт pull-половину push-pull → push-and-it-deploys. Полный дизайн + альтернативы (A / Image-Updater / annotation-вариант) + риски — **ADR 0040**.

**Сквозной поток:** контроллер Application на reconcile резолвит `spec.base.image` (тег) → текущий registry-digest (OCI manifest HEAD, auth через `pick_pull_credential`/`dockerconfigjson` из ADR 0039, публичные — анонимно) → рендерит Deployment запиненным на `repo@sha256:<digest>` → пишет `status.image.{tag,resolved,resolvedAt}` → сдвинулся тег → новый digest → обычный rolling update. Requeue ~60с (существующий цикл, conditional). Рендерер ОСТАЁТСЯ ЧИСТЫМ (I/O в контроллере, digest приходит строкой). Argo не трогаем (зона манифестов vs зона образов). Graceful-fallback на verbatim-тег + condition `ImageResolved=False`, резолв НИКОГДА не блокирует rollout.

**Решения/инварианты:**
- **Opt-out** `spec.base.imagePolicy.resolve: "digest"|"off"` (дефолт `digest`, **все тиры**; `off` = verbatim ref, digest писать не заставляет, registry НЕ опрашивается).
- **Pin в `image:`** (не annotation-триггер) — под бежит ровно резолвнутый digest, без TOCTOU.
- **Гейта НЕТ** (ни авто, ни pinned) — авто-апдейт с паузой сломал бы UX; Regulated несёт свой регламент.
- **Приватные реестры в scope** — переиспользуем `SourceCredential.registry` (ADR 0039), новой cred-инфры нет.
- **Status = правда** (`status.image.resolved` = running digest) → аудируемость, `app status` показывает.

**Декомпозиция:**
- [x] **2.4h-a** — OCI-registry-клиент (новый модуль): manifest HEAD/GET → `Docker-Content-Digest`, Bearer-token-флоу (`WWW-Authenticate` realm/service/scope для ghcr/dockerhub), auth из `dockerconfigjson`, анонимный путь. Pure-парсеры + мокнутый HTTP. Основная масса.
- [x] **2.4h-b** — схема: `spec.base.imagePolicy.resolve` + `status.image.{tag,resolved,resolvedAt}` + condition `ImageResolved` в 4 зеркала (CUE `application.cue` + kube-rs `operator-core` + OpenAPI `crd-application.yaml` + webhook). cue-vet пример.
- [x] **2.4h-c** — `operator-rendering`: принимает резолвнутый digest-параметр, рендерит `image:` как digest (или verbatim при `off`/fallback). Остаётся чистой функцией.
- [x] **2.4h-d** — интеграция в контроллер application: resolve (2.4h-a + `pick_pull_credential`) → requeue ~60с conditional → status-write (свой field-manager, SSA-split) → render-with-digest → graceful-fallback + `ImageResolved=False`. Метрика `apprafter_image_resolve_total{result}`; image-change мимо MigrationPlan.
- [x] **2.4h-e** — `apprafter app status` показывает running-digest (`status.image.resolved` + tag + resolvedAt-age).
- [x] **2.4h-f** — dev-guide про цикл итерации (push→auto-deploy, opt-out, escape-hatch `rollout restart`); shipped-пример + CMS-манифест с явным `imagePolicy`. Координированный operator+platform-stack release bump.

> ✅ **2.4h закрыт (2026-06-05).** Subagent-driven (12 TDD-тасков) на ветке `feat/2.4h-image-digest`: hand-rolled OCI-resolver (manifest HEAD → `Docker-Content-Digest`, bearer/dockerconfigjson/anon, инжектируемый `RegistryHttp`-seam; `oci_distribution::Reference` для парса — корректнее hand-rolled), 4 зеркала схемы, чистый renderer-параметр, контроллер-интеграция (throttle ~60с на `status.image.resolvedAt` как у PlatformController; record-tag-on-failure; dedup cred-list; graceful-fallback никогда не блокирует rollout), `app status` running-digest, dev-guide. Whole-feature adversarial-review (6 dimensions × 3-skeptic) нашёл 14 подтверждённых (critical: no-throttle storm; majors: tag-not-in-status, digest-validation, per-env merge, cred-dedup) → все пофикшены sweep'ом + verified. Метрика `apprafter_image_resolve_total{result}`. Релиз: operator+platform-stack **v0.2.15** (CRD-additive, change=safe, default-ON all tiers) + cli **v0.2.6**. Acceptance ниже — на real-cluster walk (после merge+push).

**Acceptance:** re-push того же тега → в пределах reconcile-интервала Deployment катится на новый digest без правки манифеста в Git; `app status` показывает running-digest; `imagePolicy.resolve: off` → resolve не происходит, ref verbatim; приватный образ с covering `SourceCredential` резолвится, без креда — graceful-fallback на тег + `ImageResolved=False`.

**Зависит от:** 2.4 (рабочий Application-reconcile), ADR 0039 (pull-creds), ADR 0040

**Размер:** L (OCI-клиент + контроллер-интеграция — основная масса). Закрыть ДО 2.6.

---

### 2.5 needs.jetstream → NATS account/stream
> 🏁 SR: A — **un-dropped из bucket D 2026-09-11**: внешний проект требует JetStream на AppRafter, то есть наступило условие «2+ explicit requests» из самого маркера. **3.2 (kine+NATS) при этом НЕ требуется и остаётся отложенным** — связь была только через прежний план «NATS embedded в kine», от которого дизайн отказался.

**Полный дизайн + измерения + альтернативы + риски — ADR 0061.** Три факта из него переписали исходную постановку ниже: lifecycle-оператора у NATS нет (`nats-operator` заархивирован) → официальный helm-чарт как **лениво включаемый компонент** platform-stack, а не «NATS-кластер embedded в kine»; аккаунт выдаётся **на namespace**, а не на claim, и заводится **config-file-аккаунтами** (`user`/`password`, как у redis), а не JWT/NKEY; персистентность — свойство **стрима** (`storage: file|memory`), поэтому `persistent` для jetstream отклоняется.

**Поставка:**
- [x] `component_nats.cue` + `component_nack.cue` (`enabled: false`), namespace `nats-system` отгружается безусловно; провижионер включает компонент merge-патчем `PlatformStack.spec.overrides.nats.enabled` и жнёт по предикату ADR 0042 §9.1.
- [x] Сид `jetstream-integrated` ServiceProvider с **пином образа сервера** и tier-aware маппингом `#Size` → квота аккаунта.
- [x] `Backend::Nats` в `resourceclaim-provisioner` (модуль `nats_accounts.rs` — чистый рендер; `nats_client.rs` — I/O): аккаунт `ns_<namespace>`, юзер на claim, `mgr_<ns>`, файл аккаунтов выводится ЦЕЛИКОМ из живого множества claim'ов, единственный писатель.
- [x] **Allow-список перечисляет глаголы и ЯВЛЯЕТСЯ границей безопасности**; deny лишь вырезает дыры в том, что он впустил. `dynamicStreams` — решение allow-списка, НЕ blanket-deny (ADR 0061 §4.3: позиционные паттерны полны против замкнутого множества и дырявы против произвольной глубины токенов — измерено).
- [x] Deny-вектор: **по позициям, не по именам глаголов** для полностью запрещённых стримов; обе формы `$JS.ACK`/`$JS.FC` (v1 и v2); вектор на **консьюмеров** для разделённых стримов.
- [x] `#JetStreamNeed` в схеме: `{selector?, size?, dynamicStreams?, streams?, consume?}` + `name?`/`persistent?` объявлены ТОЛЬКО чтобы вебхук их отклонял (иначе apiserver вырежет их молча). Четыре зеркала + `crdgen` + `just crd-validate`.
- [x] Connection-Secret: `url host port user pass account subjectPrefix inboxPrefix`; `jetstream` уходит из `CLAIM_UNSUPPORTED_TYPES`.
- [x] Объявленные стримы и дюрейблы через NACK CR в `nats-system` (cross-namespace ownerRef запрещён → удаление явное, как у `needs.disk`).
- [x] Триггеры ADR 0052 #14/#15/#16 + переформулировка carve-out #7.
- [x] Детектор `ForeignSubjectCapture` (`report`/`delete`), условия `QuotaExceeded`, `PrefixPreCaptured`, `NamespaceDrainRisk`, `WorkqueueSubjectOverlap`.
- [x] `shipped.rs` `jetstream`: `Declared` → `Shipped`; `operator-guide/jetstream.md`, страница в `how-it-works/`, строка в `docs/status.md`.

**Acceptance:** приложение объявляет `needs.jetstream` со стримом и `consume` на стрим соседа — оба работают; третье приложение упирается в `NOPERM`; подделка ack и подписка на `_INBOX.>` отклоняются; `dynamicStreams: false` не может создать стрим с `sources` на чужой; удаление claim'а сносит его стримы и не трогает соседские.

**Открытое после закрытия 2.5** (найдено при написании доксов в part 4; ни один гейт этого не ловит):
- ✅ **ЗАКРЫТО** (2026-09-12, follow-up-пасс; строка в `plan-history.md`): арм `jetstream` → `nats-system:4222` (селектор `app.kubernetes.io/name=nats` + `.../component=nats`, снят с живого `nats-0`), census-тест на весь класс (перечисляет ключи из схемы самого `Needs`) и acceptance #15 в walk'е (14 → 15), который читает применённый CNP и проверяет селектор против живого пода. Enforcement на настоящем Cilium по-прежнему не доказан — это единственное, что осталось. Исходная запись сохранена как история: ~~**Egress-правила для NATS нет.**~~ ADR 0061 §1 обещает, что координаты сервера попадают в needs-derived egress-политику (ADR 0045) как тройка `(namespace, podSelector, port)` — но `default_target` в `operator-rendering/src/egress.rs` арма `jetstream` не имеет. CNP рендерится всегда, egress становится default-deny, `world` не покрывает in-cluster endpoints — то есть под приложения с `needs.jetstream` НЕ дотягивается до `nats-system:4222` на любом профиле. Walk этого показать не мог: он поднимается без Cilium (`k3d_up`, не `kind_up_cilium`), а весь NATS-трафик в нём идёт из `nats-box`, который не Application и никаким CNP не селектится. Доки говорят об этом прямо (guide + how-it-works), и `docsgen behaviour::CLAIMS` заставит их отозвать фразу в тот день, когда арм появится.
- ✅ **ЗАКРЫТО** (2026-09-12, тот же пасс): `validate_jetstream_env_overrides` отклоняет override, который опускает `streams`/`consume`, перечисляя теряемое; триггер — отсутствие КЛЮЧА, а не пустота, так что явный `streams: []` остаётся способом сказать «в этом окружении их нет». Исходная запись как история: ~~**Вебхук не отклоняет per-env override, который роняет `streams`/`consume`.**~~ ADR 0061 §6 обещает отказ с указанием того, что теряется; в `validate_jetstream_need` такой проверки нет, а merge в `effective_spec` остаётся per-key whole-object replace. Значит `environments.prod.needs.jetstream: {size: …}` молча сносит весь контракт продьюсера/консьюмера для этого окружения. Документировано как поведение, не как баг — но обещание ADR не выполнено.
- **`status.account`/`subjectPrefix`/`inboxPrefix` на claim не пишутся** (ADR 0061 §8 их называет) — значения есть только в connection-Secret. Возможно, это правильнее; расхождение с ADR зафиксировано, чтобы не считаться потерей.
- ✅ **ЗАКРЫТО** (2026-09-12, тот же пасс): колонка заполняется из `status.streams` (declared + dynamic, `unattributed` не считается — это capture, а не ёмкость; consume-only читается как `no streams`). Попутно выяснилось, что `pg` печатает `—` ровно так же и это честно: CNPG не пишет ни `instance`, ни `volumeClaimRef`. Исходная запись как история: ~~**`backing_resource` в `app status` для jetstream-claim'а печатает `—`**~~ (нет `instance`/`dbnum`/`volumeClaimRef`). Косметика.
- **Глобальная сумма квот не зажата** — ADR 0061 §6 сам это помечает открытым; ceiling пер-namespace, PVC один на сервер.
- **`--needs jetstream` у `app scaffold` нет** (`KNOWN_NEEDS` = pg/redis/disk). Guide учит писать блок руками.
- ✅ **ЗАКРЫТО** (2026-09-12, walk-пасс; строка в `plan-history.md`): acceptance **#16** в `needs-jetstream-walk.sh` (15 → 16). Фикстура `feeder` (объявляет стрим `inbox` над `["feeder.own.>", "arrival.>"]`) + `arrival` + `bystander`. Позитив: на claim'е `arrival` появляется `PrefixPreCaptured`/`PrefixDeclaredElsewhere` с СОСТАВНЫМ именем `feeder_inbox`, и claim при этом **доходит до Ready** — это отчёт, а не гейт; `ForeignSubjectCapture` на нём молчит (за объявленный fan-in namespace поручился). `feeder.own.>` не декорация: без него у self-фильтра `p.app != me.app` нечего было бы отфильтровывать и негатив проходил бы по неправильной причине. Оба негатива гейтятся на наличии `status.streams.observedAt` — инвентарь и условия едут ОДНИМ SSA-apply, так что «условия нет» отличимо от «правила не отрабатывали». Живая мутация: снимаем `arrival.>` с объявления — условие ГАСНЕТ (сужение; арм 1 триггера #16 срабатывает только на ДОБАВЛЕНИЕ чужого сабджекта, так что аппрува не нужно — проверено отсутствием MigrationPlan). Исходная запись как история: ~~**`PrefixPreCaptured` покрыт только юнит-тестами**~~ — на живом кластере не наблюдался ни разу.
- **Сумма `max_mem` аккаунтов не зажата, и переполнение НЕ падает громко** (найдено при написании #16; измерено на пиннутом `nats:2.14.3-alpine` в podman). Каждый namespace получает `max(file_quota/10, 64Mi)` памяти (`account_max_mem_bytes` + `ACCOUNT_MAX_MEM_FLOOR_BYTES`), `component_nats.cue` пинит `memoryStore.maxSize: 192Mi` — под это влезает ~три namespace'а. Комментарий в `component_nats.cue` предсказывает, что на переполнении сервер «fail to (re)start … cluster-wide»; **на пути SIGHUP-релоада это не так и хуже**: сервер логирует `Error enabling jetstream on configured accounts: insufficient memory resources available (10028)`, следом печатает `Reloaded server configuration` и продолжает работать — старые аккаунты живы, а НОВЫЙ остаётся вообще без JetStream, при этом его юзеры нормально аутентифицируются. Провижионер вечно крутится на `AwaitingNatsReady` («the server may not have reloaded the accounts file yet») — ровно то, что как раз произошло успешно. Два следствия: (1) зажать сумму `max_mem` там же, где ADR 0061 §6 зажимает сумму файловой квоты; (2) сообщение `AwaitingNatsReady` вводит в заблуждение — стоит различать «не перезагрузился» и «перезагрузился, но у аккаунта нет JetStream». Именно поэтому #16 живёт в `demo`, а не в своём namespace: четвёртый аккаунт туда уже не влезал.

**Зависит от:** 2.3, ADR 0061

**Размер:** L (координированный релиз operator + platform-stack + **CLI** — `app validate` вшивает схему через `include_str!`)

---

### 2.6 needs.redis → Dragonfly
> 🏁 SR: A · order 3 — needs.redis; pulled C→A (closes 2/6 platform services)

**Полный дизайн + альтернативы + риски — ADR 0042.** Зеркалит 2.4 (needs.pg→CNPG), ПЕРЕИСПОЛЬЗУЯ generic-машинерию: `resourceclaim-provisioner` (dispatch по `ServiceProvider.spec.backend` — `dragonfly`-арм сейчас возвращает `None`), генерацию claim'а Application'ом + гейт `AwaitingResourceClaim` (2.4d), DSN-инъекцию (2.4e), `RetainedClaim` 7-дневный GC (2.4f), scheduler (2.3).

**Зафиксированные решения (с пользователем, 2026-06-05; ADR 0042 — переписан на per-DB `$N`):**
- **Deployment = dragonfly-operator always-on + ПУЛ shared-инстансов LAZY** (как CNPG). platform-stack ставит dragonfly-operator + сид `redis-integrated` ServiceProvider (`type: redis`, `backend: dragonfly`). Provisioner лениво создаёт shared `Dragonfly` CR по классу persistence (`platform-redis-ephemeral-<NNN>` / `platform-redis-persistent-<NNN>` со snapshot→PVC). Solo без redis-приложений не платит за под. **Инстанс-инварианты (ИЗМЕРЕНО 2026-06-05):** `--dbnum=1024` (жёсткий max `kMaxDbId`; пустые БД бесплатны — ленивая аллокация, idle-RSS плоский по dbnum), `--num_shards=1` (**дефолт, ВСЕ тиры**) через `spec.args` — оператор НЕ ставит ни dbnum, ни num_shards (иначе авто-шардинг по vCPU ноды раздувает память на tenant'а: floor = 280 кБ × shards). Число шардов — **operator-override на platform-манифесте** (seed `redis-integrated` ServiceProvider / platform values — там же tier-aware sizing типа CNPG `instances`): хочешь больше throughput — поднимаешь руками без правки кода. `maxmemory-policy noeviction`. dbnum **иммутабелен в рантайме** (restart-only) → рост ёмкости только ГОРИЗОНТАЛЬНО (новый инстанс пула) при 1024 claim'ах/инстанс.
- **Изоляция = своя нумерованная БД + `$N`-pinned ACL-user** (НЕ key-prefix; НЕ requirepass — server-global; НЕ голый logical-DB — `SELECT` не граница). Provisioner ИМПЕРАТИВНО (новый redis-клиент, admin-кред инстанса) создаёт `claim_<ns>_<app>_redis` с `$<N> resetkeys ~* resetchannels &claim_<ns>_<app>_redis:* +@all -@admin -@dangerous +info +client|… +sort_ro`. `$N` пинит юзера к БД N (`SELECT` чужой → NOPERM) — **жёсткая граница БЕЗ key-prefix на стороне приложения**, `SCAN`/`RANDOMKEY` заперты в БД N (нет утечки имён ключей). Канал-prefix `&claim_x:*` — только для pub/sub (каналы не DB-scoped). Скриптинг разрешён (declared-keys default Dragonfly + `$N` запирают Lua) — queue/lock (BullMQ/Redlock) — основной кейс.
- **Аллокация DB-номера = claim → `(instance, dbnum)` в `ResourceClaim.status`** (k8s-объект, переживает рестарт инстанса, GC'ится RetainedClaim-машинерией). Lowest-free `dbnum<1024`; free/used индекс — кэш из живых claim-статусов. Нет слота → новый инстанс пула (или `InsufficientCapacity` до auto-grow). **Recycle-safety:** `FLUSHDB` на аллокации (не только teardown) + всегда свежий ACL-user — чтобы новый tenant не унаследовал ключи мёртвого при сбойной очистке.
- **ACL-reconcile loop** (обязателен): per-claim юзеры — runtime-state (in-memory, теряются на reload пода). Луп смотрит readiness инстансов пула и на (ре)старте ре-применяет `ACL SETUSER` всем живым claim'ам инстанса (re-pin к `dbnum` из status), + периодический resync. Расширяет `resourceclaim-provisioner` (он уже владеет redis-клиентом/секретами/индексом).
- **Persistence = per-claim opt-in → placement.** `#ServiceNeed` получает `persistent?: bool` (дефолт false) → 4 зеркала. Persistence в Dragonfly — **на уровне инстанса** (RDB/AOF — весь датасет, нет per-DB snapshot/restore): `{}` → ephemeral-инстанс пула; `{persistent:true}` → persistent-инстанс. Изолированная durability (свой RPO/restore) → per-claim-instance tier.
- **DSN = DB-pinned URL + channel-only prefix.** connection-Secret: `REDIS_URL = redis://claim_x:<pass>@<instance>.dragonfly-system.svc:6379/<N>` (`/<N>` + `$N` ACL → жёсткий пин к БД N, **ключи без prefix**) + `REDIS_CHANNEL_PREFIX = claim_x:` (только для имён pub/sub-каналов). Таблица needs→env рендерера (2.4e) обобщается до СПИСКА пар: pg→[(DATABASE_URL,DATABASE_URL)]; redis→[(REDIS_URL,REDIS_URL),(REDIS_CHANNEL_PREFIX,REDIS_CHANNEL_PREFIX)]. webhook reserved-env guard отклоняет литеральные `REDIS_URL`/`REDIS_CHANNEL_PREFIX` при `needs.redis`.
- **GC = per-DB `FLUSHDB`.** Dragonfly-путь в 2.4f GC: после grace — `SELECT N; FLUSHDB ASYNC` (один командой, не `SCAN MATCH|UNLINK`) + `ACL DELUSER claim_x` (рвёт живые коннекты юзера) + вернуть N в free-pool + удалить connection-Secret. Shared-инстансы остаются.

**Измерено (2026-06-05, Dragonfly v1.38.1, подтверждено исходниками):** dbnum max=1024; пустой dbnum бесплатен (ленивый DashTable); активная БД ≈ **280 кБ × num_shards** (floor, независим от ключей); dbnum immutable. → 1-shard Tier-1 инстанс держит полные 1024 tenant'а за ~287 МБ структур. Детали + Pre-merge #3–6 (cross-DB containment, in-script ACL, client-lib init, restart-durability/recycle — на in-cluster walk) — в ADR 0042.

**Декомпозиция (порядок сборки).** Метки `2.6-N`, а не `2.6a–f`: `2.6a` (KEDA) / `2.6b` (needs.disk) — намеренные insert-соседи на уровне `### 2.6` (устоявшийся паттерн вставки доп. пунктов), не дети redis; отдельная нумерация снимает коллизию и даёт стабильные кросс-ссылки.
- [x] **2.6-1** — dragonfly-operator как platform-stack component + сид `redis-integrated` ServiceProvider + шаблон pool-инстанса (`spec.args`: `--dbnum=1024` + `--num_shards=1` дефолт все тиры, override-knob на seed/platform values, классы ephemeral/persistent). **platform-stack-only** (как 2.4a).
- [x] **2.6-2** — схема: `persistent?: bool` на `#ServiceNeed` (4 зеркала) + поля аллокации `status.{instance,dbnum}` на `ResourceClaim` (kube-rs + CRD). Чистая схема.
- [x] **2.6-3** — provisioner `Backend::Dragonfly`: ленивое создание pool-инстанса (по persistence) + аллокатор claim→`(instance,dbnum)` (free/used индекс из живых claim-статусов, `FLUSHDB`-on-allocation recycle-safety, `InsufficientCapacity`).
- [x] **2.6-4** — per-claim `$N` ACL-user (императивный redis-клиент, новая dep) + connection-Secret (`REDIS_URL` с `/N` + `REDIS_CHANNEL_PREFIX`).
- [x] **2.6-5** — ACL-reconcile loop: re-pin всех живых claim'ов инстанса на (ре)старте + periodic resync.
- [x] **2.6-6** — DSN-инъекция: рендерер needs→env до списка пар (`REDIS_URL`+`REDIS_CHANNEL_PREFIX`) + webhook reserved-env guard.
- [x] **2.6-7** — GC: dragonfly-путь (`SELECT N; FLUSHDB`; `DELUSER`; вернуть N; Secret) в 2.4f GC-контроллер.
- [x] **2.6-8** — `e2e/needs-redis-walk.sh` + подробный ручной walk (incl. Pre-merge #3–6 in-cluster) + dev-guide + координированный operator+platform-stack release.

**Acceptance:** Application с `needs.redis` получает рабочий `REDIS_URL` (DB-pinned, ключи без prefix) + `REDIS_CHANNEL_PREFIX`; два claim'а изолированы (claim B `SELECT`/`SCAN` не видит БД A → NOPERM); `persistent: true` переживает рестарт пода; per-claim юзер переживает рестарт инстанса (reconcile loop).

**Зависит от:** 2.3, 2.4 (вся переиспользуемая машинерия), ADR 0042

**Размер:** L (per-DB аллокация + ACL-reconcile loop сверх 2.4-паттерна)

---

### 2.6a KEDA install + ScaledObject rendering
> 🏁 SR: C — trigger: first autoscaling customer signal

**Source:** ADR 0019.

**Цель:** KEDA как official autoscaling backend; `Application.autoscale.on:` рендерит ScaledObject.

**Поставка:**
- [ ] Install KEDA Helm chart как platform-service — post-M1.5 это означает adding KEDA как component в `apprafter/platform-stack/cue/components/keda.cue`, not direct install via CLI. KEDA arrives через Argo CD reconciliation.
- [ ] Default enabled at Tier 1 (sufficient KEDA footprint ~50MB для opt-in autoscaling), но Application receives ScaledObject только когда `autoscale:` declared.
- [ ] Operator renderer (`operator-rendering` crate) генерирует `ScaledObject` resource из `Application.autoscale`.
- [ ] Supported triggers in v1: `jetstream_lag`, `cpu`, `memory`, `http_rps`.
- [ ] Per-trigger rendering:
    - `jetstream_lag` → KEDA `nats-jetstream` scaler with stream + consumer.
    - `cpu` / `memory` → KEDA built-in CPU/memory scalers (HPA passthrough).
    - `http_rps` → KEDA Prometheus scaler reading Gateway metrics.
- [ ] Unit tests на rendering coverage для каждого trigger типа.
- [ ] Integration test: Application с `autoscale: {on: cpu, min: 1, max: 10}` реально скейлится под cpu load на 3-node test cluster (можно re-use Tier 1 single-node для базового test'а).
- [ ] Backstage Application view: текущий replica count + autoscaling state (Pending / Active / scale events history).

**Acceptance:**
- Application с `autoscale.on: cpu` rendered ScaledObject видим через `kubectl get scaledobject`.
- Под load (искусственный CPU stress) replicas действительно растут от min к max.
- Backstage показывает autoscaling activity.

**Зависит от:** 2.6 needs.redis (как proxy для готовности базовых ServiceProvider'ов), 1.83 (M1.5 closure)

**Размер:** M

---

### 2.6b needs.disk → persistent block storage
> 🏁 SR: A · order 3 — needs.disk block storage; launch scope (not in earlier speedrun revisions)

> ✅ **ЗАКРЫТО (launch-срез, 2026-06-06).** Subagent-driven по декомпозиции 2.6b-1…2.6b-6 (ветка `feat/2.6b-needs-disk`). `needs` обобщён до **(type, name)** скаляр\|массив (закрытая структура + `OneOrMany<T>`); Application генерирует один `ResourceClaim` на entry (`<app>-<type>[-<name>]`), рендерер дизамбигуирует инъекцию (`DATABASE_URL_<NAME>` для named pg; unnamed остаётся `DATABASE_URL`). Диск — **через ResourceClaim**: `Backend::Disk` создаёт **unowned** RWO PVC (matched к сиду `disk-local`; class local / local-path на T1), рендерер монтирует в `mountPath` + пивотит Deployment в `strategy:Recreate`, GC снапшотит disk-RetainedClaim (volumeClaimRef+namespace) → unowned PVC переживает grace → reattach при redeploy (cancel-on-reprovision) → force-GC дропает PVC+снапшот. **Live-walk `e2e/needs-disk-walk.sh` GREEN end-to-end** (10 фаз, kind+podman, LOCAL_OPERATOR, ~3.5 мин): generate→schedule→provision(unowned RWO PVC)→resume+mount+Recreate→data-durability(переживает рестарт пода)→delete+snapshot+PVC-survives→reattach(data intact)→force-GC(PVC дропнут) + multi-pg-массив assertion (2 CNPG DB + `DATABASE_URL_PRIMARY`/`_ANALYTICS`). **Walk вскрыл баги — все пофикшены + re-walk GREEN:** (operator) gate-readiness требовал `connectionSecretRef`, которого у disk-claim нет → принимает `volumeClaimRef`; ServiceProvider CRD `type`-enum без `disk`; ResourceClaim `spec.size` t-shirt-enum → per-type (quantity для disk, t-shirt для service); (harness) PVC RBAC additive, ожидание терминации старого webhook-пода (rollout-race), **Phase-4 transient-gate**: диск провижится мгновенно (single-pass local-path + pre-warmed CNPG) → `AwaitingResourceClaim` ненаблюдаем поллингом → гейт доказывается ДЕТЕРМИНИРОВАННО (claim-генерация + Phase-7 mount/env; pause-логика — юнит-тесты). **scaffold `--needs` расширен на `redis`+`disk`** (решение пользователя — закрыл pre-existing mismatch: redis-walk-док уже документировал `--needs redis`, которого не было). **Релиз:** operator+platform-stack **v0.2.21** (CRD-additive, change=safe, CRD-compatible 0.2.20) + cli **v0.2.7** (монорепо-тег `v0.2.7` локально; binary изменился — scaffold). Гейты: cargo fmt/clippy -D warnings/test --workspace (cli+operator) + just lint + cue vet + `just crd-validate` (7 CRD Established) + `just platform-stack-check` + strict mkdocs. Доки: `operator-guide/needs-disk-walk.md` (ручной Tier-1 walk) + dev-guide needs-reference + nightly `e2e-disk-nightly.yml` (07:00 UTC). **NOTE: 2.6b ≠ закрытие Фазы 2 — §6 M2 НЕ флипать.** **Запушено + опубликовано** (0.2.21; теги `operator/v0.2.21` + `platform-stack/v0.2.21` на origin, монорепо `v0.2.7`). **Валидировано на published-релизе 2026-06-07:** все 4 e2e-walk'а зелёные на kind+podman пользователя (disk/gitops/pg/redis); non-LOCAL disk-walk бутстрапит platform-stack 0.2.21 из ghcr, пропускает сборку и зелёный за **2m52s** → релизный v0.2.21 реализует весь needs.disk-чейн для реальных юзеров (disk-local seed, 2.6b CRD, provision+GC PVC в опубликованном чарте; ClusterRole `rbac.yaml` даёт PVC create/delete). **2 follow-up'а (на origin/master, post-release):** `de943fc` (operator/webhook Dockerfile `FROM rust:` → `docker.io/library/rust:` — иначе podman short-name prompt вешает LOCAL-сборку) + `9f2293f` (`just e2e-disk`/nightly по умолчанию на published-образ, как pg/redis; LOCAL_OPERATOR за явным флагом для pre-release-валидации). Отложенный full-vision (StatefulSet/per-replica/replicated/shared/snapshots/auto-expand) — чекбоксы ниже, per ADR 0043 §Decision, НЕ входит в launch.

**Source:** design session 2026-05-27; **ADR 0043** (needs.disk + named multi-claim needs) + design `docs/superpowers/specs/2026-06-06-needs-disk-named-claims-design.md`.

**Дизайн (2026-06-06, ADR 0043) — revised vs набросок «Поставка» ниже:** диск идёт **через ResourceClaim** (`Backend::Disk` создаёт unowned RWO PVC, рендерер монтирует, RetainedClaim GC удерживает→grace→чистит + reattach при redeploy) — НЕ renderer-only StatefulSet. Несущая часть фазы — обобщение `needs` до **(type, name)** (скаляр\|массив + имя, backward-compat `DATABASE_URL`/`_<NAME>`), реализуется для всех типов. Launch = `class: local`, `replicas:1` Deployment (Recreate); StatefulSet/per-replica + всё T2 (replicated/shared/снапшоты/auto-expand) — отложено (набросок ниже = full vision, на launch берём срез).

**Декомпозиция (launch, 2.6b-1…2.6b-6) — ✅ ВСЕ ЗАКРЫТЫ** (live-walk GREEN + опубликовано v0.2.21; см. `> ✅ ЗАКРЫТО` выше + plan-history 2026-06-06/07):
- [x] **2.6b-1** — схема (обобщённый `needs` скаляр\|массив+name, `#DiskClaim`, `status.volumeClaimRef`; crd-validate).
- [x] **2.6b-2** — generalization-движок (claim-gen по (type,name) + env-дизамбигуация `DATABASE_URL_<NAME>` + webhook (type,name)-гарды; acceptance на pg-массиве ДО диска).
- [x] **2.6b-3** — provisioner `Backend::Disk` + сид `disk-local`.
- [x] **2.6b-4** — disk renderer (mount+Recreate) + disk webhook-гарды.
- [x] **2.6b-5** — disk GC (RetainedClaim disk-поля + reattach/cancel).
- [x] **2.6b-6** — `needs-disk-walk.sh` + multi-claim walk + ручной walk + dev-guide + координированный release.

**Цель (launch):** declarative persistent block storage через `needs.disk` (claim-backed PVC, рендерер монтирует в Deployment — **НЕ** StatefulSet на launch), tier-portable через `disk-local.config.storageClass`. Несущая часть фазы — обобщение `needs` до named-multi-claim (type,name) для всех типов. Full-vision (StatefulSet/snapshots/auto-expand/replicated/shared) — в «Отложено» ниже.

**Поставка (launch):** детально — в декомпозиции 2.6b-1…2.6b-6 выше + spec `docs/superpowers/specs/2026-06-06-needs-disk-named-claims-design.md` + ADR 0043; план реализации `docs/superpowers/plans/2026-06-06-2.6b-needs-disk-named-claims.md`.

**Отложено (T2+ / post-launch — full-vision roadmap; НЕ входит в launch-срез, per ADR 0043 §Decision/§Alternatives):**

Schema:
- [ ] CUE schema `#DiskClaim` в `schemas/v1alpha1/application.cue` под `needs.disk?: #DiskClaim | [...#DiskClaim]` (union scalar | array).
- [ ] Поля: `name?` (string, optional), `size` (string, e.g. "10Gi"), `mountPath` (string), `class?: "local" | "replicated" | "shared" | *"local"`, `shareMode?: "per-replica" | "shared" | *"per-replica"`, `readOnly?: bool | *false`, `backup?: { enabled, schedule, retention }`, `autoExpand?: { enabled, threshold, maxSize }`.

Admission webhook:
- [ ] Name uniqueness validation across array entries (implicit name from `mountPath` segment когда `name` omit'нут — `/data` → `data`, `/var/lib/uploads` → `uploads`; explicit wins; conflict → reject с suggestion).
- [ ] `shareMode: shared` requires `class` supporting RWX (`shared` only в v1) — reject otherwise с suggestion.
- [ ] `class: replicated` или `class: shared` на T1 → reject («single-node tier does not support replicated/shared storage; use `local` or upgrade to T2»).
- [ ] `class: replicated` или `class: shared` на T2 без opt-in platform values (`enableReplicatedStorage` / `enableSharedStorage`) → reject с install hint.
- [ ] Optional advisory warning: `shareMode: per-replica` + `replicas > 1` → не reject, но print warning «new replicas start with empty disks; if shared data needed, use shareMode: shared».
- [ ] Quota enforcement: sum `disk.size` across all claims в Application против Tenant quota → reject если over.

Operator rendering (`operator-rendering` crate):
- [ ] Detect `needs.disk` non-empty в Application → emit StatefulSet вместо Deployment (existing renderer pivot).
- [ ] Normalize union format: scalar → single-element array внутри renderer pipeline.
- [ ] Per claim emit: PVC template (для `shareMode: per-replica`) или standalone PVC (для `shareMode: shared`) с tier-mapped StorageClass.
- [ ] VolumeMount per claim в container spec.
- [ ] StorageClass resolution table (per tier from platform values):
    - T1: `local` → `local-path` (k3s default).
    - T2: `local` → `hcloud-volumes` (Hetzner CSI), `replicated` → `longhorn` (opt-in), `shared` → `rook-nfs` (opt-in).
    - T3+: `local` → `linstor-single-replica`, `replicated` → `linstor-three-replica`, `shared` → `rook-nfs` / `cephfs`.
    - T4: cloud-provider specific (EBS gp3, Azure Premium SSD, GCP PD).

Backup integration (CSI snapshot):
> Это **T2 CSI-комплемент** к 2.6d: 2.6d поставил T1-путь (restic pull через ephemeral RO-helper — работает и на single-node без CSI-snapshot-capable драйвера); per-claim `backup.enabled` CSI-snapshot ниже — его T2+ дополнение (VolumeSnapshot вместо restic-pull, когда драйвер поддерживает снапшоты). Оба сходятся в один `restore`-опыт.
- [ ] При `backup.enabled: true` operator создаёт `VolumeSnapshotClass` reference + AppRafter CronJob per claim (Velero отклонён, ADR 0050; CSI-VolumeSnapshot заменяет restic-pull только на T2+ где драйвер поддерживает снапшоты).
- [ ] Snapshot schedule per claim's `backup.schedule` (default daily `0 2 * * *`), retention per `backup.retention` (default 30d).
- [ ] Snapshots store в external S3 destination (configured platform-wide через 4.12, fallback на local CSI snapshot если 4.12 не deployed).

Auto-expand:
- [ ] При `autoExpand.enabled: true` operator periodically reads PVC usage (через `kubelet_volume_stats_used_bytes` metric или `df` exec в pod).
- [ ] При usage > `autoExpand.threshold` (default 80%) → patch PVC.spec.resources.requests.storage к next size step (e.g., +20% или next round Gi) до `autoExpand.maxSize`.
- [ ] Online expansion supported большинством modern StorageClass (CSI provisioner + ExpandInUsePersistentVolumes feature gate).

Platform-stack chart:
- [ ] Component `local-path-provisioner` (k3s ships это automatically, но explicit pin в chart values для T2 если k3s не используется).
- [ ] Optional components с opt-in flags: `longhorn` (replicated), `rook-nfs` (shared), gated по `enableReplicatedStorage` / `enableSharedStorage` platform values.

Documentation:
- [ ] `docs/operator-guide/storage.md` — disk claims reference, class semantics, shareMode behaviour при scaling, restore procedure.
- [ ] `docs/operator-guide/disaster-recovery.md` — per-claim restore steps (manual procedure: identify VolumeSnapshot → create PVC from snapshot → patch Application's claim к нему). Automation deferred к later DR drill phase.

Tests:
- [ ] CUE schema validation: scalar + array forms, name conflict detection, shareMode/class compatibility.
- [ ] Renderer unit tests: per-replica vs shared rendering, StatefulSet emission, StorageClass selection по tier.
- [ ] Webhook unit tests: validation rules (quota, T1 reject for replicated/shared, opt-in reject T2, mountPath uniqueness).
- [ ] Integration test (T1 single-node k3s): SQLite-app с `needs.disk.db: { size: "1Gi", mountPath: "/data" }` стартует, file persists через pod restart, через `dev down` + `dev up`.
- [ ] Integration test (T2 multi-node): `shareMode: shared` + `class: shared` (с installed Rook-NFS) deploys multi-replica app с shared storage, все replicas видят writes друг друга.
- [ ] Snapshot test: backup schedule создаёт VolumeSnapshot, retention enforces deletion старых.

**Acceptance (launch):**
- `replicas:1` app с `needs.disk.data: {size:"1Gi", mountPath:"/data"}` → файл переживает рестарт пода И delete+redeploy в окне grace (reattach к удержанному PVC); force-GC после grace удаляет PVC.
- Multi-disk app (массив, два разных `mountPath`) → обе PVC создаются и монтируются.
- App с `needs.pg`-массивом из двух именованных → две CNPG DB + `DATABASE_URL_<NAME>` для каждой; unnamed-single по-прежнему `DATABASE_URL` (нулевая миграция).
- `needs.disk` + `replicas>1` → webhook reject с понятным сообщением.

**Acceptance (отложено — full vision, T2+):**
- SQLite-app deploys через `needs.disk` с `class: local`, single replica → file persists через pod restart, через node reboot.
- Multi-disk app (массив с двумя `disk` claims разных `mountPath`) deploys корректно, обе PVCs создаются, mounts работают.
- `shareMode: shared` + RWX class deploys multi-replica app, cross-replica file visibility verified.
- `shareMode: per-replica` + `replicas: 3` → 3 separate PVCs, каждая replica имеет own data, scaling to 5 создаёт 2 fresh empty PVCs.
- `autoExpand.enabled: true` + filling disk past threshold → PVC автоматически resize'ит до `maxSize`.
- Backup schedule emits VolumeSnapshots по cron; retention удаляет старые.
- T1 reject для `class: replicated/shared` с helpful message.
- T2 без opt-in → reject с install hint.
- Quota over → reject с remaining quota info.

**Зависит от (launch):** 1.83 (M1.5 closure). (4.12 нужен только для отложенного backup-destination, не для launch.)

**Размер:** L

---

### 2.6c capacity-signal + cross-app SharedVolume

> ✅ **CLOSED 2026-06-19.** Координированный CRD-additive release **operator v0.2.31 / platform-stack 0.2.37 / cue-cmp 0.1.13 / cli v0.2.28** (monorepo tag v0.2.28, локально). Что зашипилось: новый namespaced **`SharedVolume` CRD** (`spec:{size,class}`, `status:{ready,pvcRef,refCount}`) с explicit lifecycle (`apprafter volume create/rm/list/status`); cross-app `needs.disk.ref` (referenced `{ref,mountPath,readOnly?}` vs owned `{name,size,mountPath}`, webhook разводит по shape; reference-arm биндит существующий PVC, не провижинит/не GC'ит backing; renderer mount БЕЗ форса `Recreate`); новый backend-тип **`shared-disk`** (не кросс-матчится на owned-`disk`) + `shared-local` ServiceProvider seed (T1 local-path); **capacity-signal** через kubelet Summary API (RBAC `nodes/stats`) → condition + Warning Event при node-free<threshold, surface в `app status`/`volume status`. ADR 0049 + `operator-guide/shared-volumes.md`. **kind+podman live walk GREEN end-to-end** (2 app в одном ns ref один SharedVolume читают/пишут общий dir, rolling update не роняет mount, `volume rm` отказывает пока референсится). **node-free capacity live-read** — best-effort, **SOFT-skipped на kind** (kubelet `nodes/stats` reachability cluster-зависим — валидируется на реальном кластере позже). 2.6c ≠ Phase closure (это order-3.5 pulled-up, §6/spec.md не трогаются). spec.md актуализация не требуется. Следующее по SR-порядку: 2.6d (export/backup) / далее order 4.

> 🏁 SR: A · order 3.5 (post-T1-demo, pre-T2-substrate) — capacity-signal (owned+shared диски) + cross-app SharedVolume (`needs.disk.ref`, single-node same-ns). Early-adopter unblocker (pm2 с shared-папкой → AppRafter, изоляция лучше pm2). Cross-ns / multi-node shared И intra-app `shareMode: shared` — НЕ здесь, остаются T2 (2.6b-deferred).

Storage-примитивы поверх 2.6b owned-disk пайплайна. Жёсткий T1-инвариант: на single-node `local-path` requested-`size` НЕ энфорсится как квота — разогнавшийся том заполняет диск ноды целиком, утаскивая k3s/etcd; значимый сигнал — node-disk-free.

**Декомпозиция:**

- [x] **2.6c-1 — capacity-signal (owned + shared).** Оператор читает per-PVC `usedBytes`/`capacityBytes` + node-level `fsAvailableBytes` через kubelet Summary API (`/stats/summary`, RBAC `nodes/stats`) — **без зависимости от full OTel** (он order 5). Condition в `status` + Warning Event при `node-free < threshold` (default 15%). Surface в `apprafter app status` / `apprafter volume status`. Defer: Grafana/Alertmanager → order 5.
- [x] **2.6c-2 — SharedVolume backend + `shared-local` provider + объект lifecycle.** Новый backend-тип **`shared-disk`** (НЕ `disk`) → scheduler не кросс-матчит на owned-`disk` линейку. `shared-local` ServiceProvider (T1): `storageClass: local-path`, провижинит ОДИН unowned PVC, `accessMode: ReadWriteOnce` (node-level — на single-node N подов монтируют корректно). T2-расширение свопает `shared-local`→`shared-nfs` (RWX), не трогая манифесты. SharedVolume — **выделенный namespaced CRD `apprafter.io/SharedVolume`** (`spec:{size,class}`, `status:{ready,pvcRef,refCount}`) с explicit lifecycle (`apprafter volume create/rm`), независим от приложений. Объектом, не «ref на голый PVC» — ради portability 0.2 (`ref` стабилен, backing меняется local-path→NFS).
- [x] **2.6c-3 — `ref`-грамматика + reference-arm + renderer + CLI.**
    - [x] `needs.disk: { ref, mountPath, readOnly? }` (referenced) vs `{ name, size, mountPath }` (owned); webhook разводит по shape.
    - [x] Webhook: reject `ref` на несуществующий SharedVolume; **reject cross-ns ref** на T1 (single-node same-ns инвариант) с hint «cross-namespace → T2 (NFS)».
    - [x] Provisioner reference-arm: биндит существующий PVC, не провижинит backing, **не GC'ит** при удалении app.
    - [x] Renderer: mount, **БЕЗ форса `strategy: Recreate`** (owned-arm форсит из-за single-PVC-cross-node; reference-arm на single-node RWO-multi-pod терпит RollingUpdate).
    - [x] CLI: `apprafter volume create/rm/list/status`; `rm` отказывает пока есть референсы. Refcount-GC с grace — defer.
- [x] **2.6c-4 — walk + docs + ADR 0049 + release.** `e2e/shared-volume-walk.sh` (2 app один ns ref один SharedVolume → оба видят writes; rolling update не роняет mount второго; `volume rm` отказывает пока референсится). Docs `operator-guide/shared-volumes.md`. ADR 0049 (cross-app SharedVolume, reference-концепт в claim-грамматике — cross-cutting как `(type,name)` в 0043). Координированный release operator+platform-stack+cli (CRD-additive).

**Не входит (отложено):** intra-app `shareMode: shared` (multi-replica RWX) → 2.6b-deferred/T2; cross-ns + multi-node SharedVolume (вкл. dev/prod в одну папку) → T2 + NFS (`ref` forward-compatible); CSI-snapshot/autoExpand/quota → 2.6b-deferred.

**Acceptance:** 2 app `ref` на один SharedVolume в одном ns деплоятся, читают/пишут общий том; `volume status` показывает used/free; `volume rm` отказывает «still referenced»; cross-ns `ref` на T1 → reject; заполнение до node-free<threshold → Warning + condition; owned-disk 2.6b не регрессирует.

**Зависит от:** 2.6b (owned-disk пайплайн).

**Размер:** M.

---

### 2.6d data export + backup/restore (restic-движок)

> 🏁 SR: A · order 3.5 (post-T1-demo) — `export` (Kind 1, native, inspect/migrate-out) + restic-based backup/restore (Kind 2). **T1 default backup = local pull на машину оператора + restore с него**; automated S3 backup = opt-in. Без реального restore prod на платформу не доверят. S3-automated tail + T2-warning/internal-S3 — follow-on (ниже).

> ✅ **CORE CLOSED 2026-07-15** (order-3.5 pulled-up, sub-subphases 2.6d-1…2.6d-3 core + 2.6d-5). **CLI-only release** (`cli/` + `e2e/` + `docs/` — НИ ОДНОГО operator/schema/chart-изменения → нет operator/platform-stack/cue-cmp bump). Что зашипилось: три cluster-scope команды поверх одной extraction — `apprafter export <ns>` (Kind 1: native `pg_dump -Fc` + деревья файлов через ephemeral RO-helper-pod → плоская самодостаточная папка, ноль restore-логики), `apprafter backup` (restic-обёртка тех же dumps + сериализованные AppRafter+Argo CR + расшифрованные секреты + manifest → зашифрованный restic-репо; local-filesystem default, ноль форса бакета), и `apprafter restore --into <fresh-cluster>` (Kind 2 restore-ordering apply-CR→provision→`pg_restore`/restic-restore→re-seal секретов в target'а SealedSecrets, auto-register всех приложений без ручного re-add) + `--data-only` (recover тома/БД в существующий кластер без пересоздания app). **Два-кластерный kind+podman walk (`e2e/backup-restore-walk.sh`) GREEN end-to-end** (export → зашифрованный restic backup → restore-into-fresh → `--data-only`, прогнан дважды). Walk вскрыл + пофиксил **3 реальных product-бага** (все прошли unit/review: pg_dump/pg_restore major-version-match helper-image selection + claim-ready-vs-DB-ready race — commit `3d22d92` с regression-тестом; image-name/pg18/target-registry walk-fixes — `f170d6a`) и **2 platform-фикса surface'нул**, поставленных отдельными релизами: sealed-secrets chart-source repoint (**platform-stack 0.2.38**, `564cba0`) + 2.4h `imagePolicy.resolve: "off"` CRD-YAML фикс (operator v0.2.32 / **platform-stack 0.2.39**). ADR 0050 + `operator-guide/backup-restore.md`. Release: **cli v0.2.29** (monorepo tag v0.2.29, локально). **`--reprovision` (mode a, T13) — SHIPPED + real-Hetzner-validated 2026-07-16 (cli v0.2.31)** (clone-to-new: destroy source → restore --reprovision → fresh box + data intact; walk `e2e/restore-reprovision-hetzner.sh` GREEN); **automated S3 push (2.6d-4) — SHIPPED 2026-07-17** (cli/runner v0.2.33 / operator v0.2.33 / platform-stack 0.2.42 / cue-cmp v0.1.14 / runner-образ `apprafter-backup:v0.2.33`; 0.2.40+0.2.41 yanked; AppRafter CronJob-restic, opt-in `PlatformStack.spec.backup`; ✅ **файловая + S3 backup/restore GREEN на real Hetzner** после 2 раундов live-фиксов — 1 release-coordination + 7 runner-багов, все прошли unit/CRD/review; ⏳ push 1 коммита за юзером); полная DR-валидация (`restore` за <1ч на реальном кластере) едет на real-Hetzner manual run. 2.6d ≠ Phase closure (order-3.5 pulled-up, §6/spec.md не трогаются). Следующее по SR-порядку (speedrun §4.2): **3.7 / 2.16b** (App-scope migration: auto-detect destructive app-ops + авто-app-scope-MigrationPlan + in-Argo аппрув), затем **4** (T2 substrate). (`--reprovision` T13 + полная DR-валидация на real-Hetzner — DONE 2026-07-16, cli v0.2.31.) **T12 (persistent-redis backup+restore) — SHIPPED 2026-08-28 (cli v0.2.51):** закрыл redis-ногу 2.6d, которая шипилась deferred (backup-таблица обещала redis-снапшот, которого никакой код не делал — 2.19j это назвал). `export`/`backup` захватывают `persistent:true` redis как whole-instance Dragonfly-снапшот (`SAVE`+tar → `redis/<ns>/<claim>/dump.tar`, дедуп по инстансу); `restore` (`--into` + `--data-only`) заливает обратно live-загрузкой в РАБОТАЮЩИЙ инстанс через `DFLY LOAD` (без scale → провизионер не видит исчезновения, не ре-провижнит/не FLUSH'ит). Первый cut скейлил CR 0→1 (освободить RWO-PVC под helper) → провизионер FLUSH'ил восстановленное на same-cluster `--data-only` — заменено на no-scale DFLY LOAD. `e2e/backup-restore-walk.sh` GREEN на ОБОИХ restore-путях (SET t12key → dump.tar → recovery на fresh + `--data-only`). CLI-only (нет operator/chart/cue-cmp).

> ⚠️ **Known wart / техдолг (2026-07-16, deferred → backlog):** upgrade ЖИВОГО кластера ЧЕРЕЗ границу, где новый platform-stack сид зависит от нового CRD-enum (напр. 2.6c: `shared-local` ServiceProvider `type: shared-disk` + расширенный ServiceProvider CRD enum), ловит transient **seed-vs-CRD-discovery гонку** — сид применяется, пока apiserver ещё не прогнал structural-schema discovery обновлённого CRD (CRD на sync-wave `-5`, но discovery-refresh отстаёт) → seed reject (`Unsupported value "shared-disk"`) → Argo исчерпывает 5 ретраев → **parent platform Application залипает degraded**, что даёт ДВА симптома: (1) stale seed-sync ошибку в Argo, (2) блок дальнейших авто-апгрейдов (PlatformController не продвигает `target`, пока parent не чистый Synced+Healthy — отсюда `available>current` при `UpgradeAvailable=False`). **Наблюдалось на реальном кластере (2026-07-16):** живой апгрейд-through-2.6c залип на 0.2.37 27 дней; ручной форс-синк platform Argo-app разрулил ОБА симптома → кластер доехал до channel-latest 0.2.39. Свежий kind-walk это структурно НЕ ловит (CRD ставится с нуля, гонки нет) — класс «ловит только живой апгрейд» (ср. 2.9 deployment-selector-immutable). **Fix (правильный, при upgrade-robustness / T2 работе):** усилить Argo retry/backoff на platform app-of-apps (перекрыть discovery-лаг) ИЛИ развести sync-wave «сид строго-после-CRD» с запасом, чтобы CRD-enum+сид апгрейды не залипали и не требовали ручного форс-синка. **Deferred** — не срочно (recoverable форс-синком, не data-loss).

Два вида поверх одной extraction (native dumps: `pg_dump -Fc` / дерево файлов / redis-snapshot), один restore-путь. `export` — read-only утилита (ноль restore-логики), `backup`/`restore` — restic-обёртка тех же dumps + CR-serialization + секреты.

**Архитектурные решения (зафиксированы в обсуждении — для ADR 0050 / spec §1.9):**
- **Velero отклонён.** Поддерживает только object storage как BSL; restic-FSB не stand-alone (всё равно нужен bucket); локальный artifact + restore-from-file — открытый незакрытый feature request. Форсить покупку *любого* S3-бакета в дефолтном пути = продуктовое трение. Не годится для дефолта.
- **Движок = restic, оркестрирует AppRafter.** Backend'ы restic: local-filesystem, SFTP, rclone (~70 провайдеров), S3 → репозиторий переносимый и restorable plain-restic'ом откуда угодно. No-lock-in на уровне формата.
- **T1 default backup = local pull на машину оператора** (через ephemeral RO-helper). Ноль форса бакета. Automated S3 backup = opt-in.
- **Scheduled-runner — РЕШЕНО (2.6d-4, 2026-07-17): AppRafter CronJob-restic** (`apprafter-backup` runner переиспользует тот же `backup-core` движок — один backup-путь, ноль нового in-cluster operator'а). K8up отклонён (добавил бы CNCF-operator + его CRD + дублирующий движок; см. ADR 0050 Alternatives).
- **`export` (Kind 1) ≠ backup.** Native dumps на машину оператора для (1) изучить локально, (2) выйти/мигрировать. Восстановление из него — это `backup`/`restore` (Kind 2), не `export`.
- **`restore` (Kind 2) = в аналогичный свежий кластер** (DR «source мёртв»): replay сериализованных CR (auto-register всех приложений, без ручного re-add) + reload данных + re-seal секретов в SealedSecrets/OpenBao target'а. Не cross-version/cross-topology.
- **No-lock-in (§1.9)** — данные и манифесты забираемы наружу в нативном, напрямую-используемом виде; одновременно happy-path-свойство И механизм доверия для migration-in.

**Декомпозиция (порядок сборки):**

- [x] **2.6d-1 — `export` (Kind 1).** Per-resource native pull на машину оператора: `apprafter export <ns>` энумерит stateful-claim'ы → `pg_dump -Fc` (НЕ CNPG barman — он in-cluster PITR), дерево файлов (volume/SharedVolume), redis-snapshot (если persistent). Плоская самодостаточная папка (`pg/*.dump`, `volumes/<name>/...`, `manifest.json`). Цель: изучить локально + migrate-out. **Не backup.** Транспорт вниз — ephemeral RO-helper-pod → `tar`/stream (kubectl-cp семантика; на single-node RWO node-level → helper монтирует RO рядом с работающим app без contention).
- [x] **2.6d-2 — restic-движок + local-pull backup (T1 default).** AppRafter оркестрирует restic против extraction'а. **Default backend = local-filesystem на машине оператора** (через тот же ephemeral RO-helper → restic в локальный репо). Артефакт = `data (native dumps) + сериализованные AppRafter+Argo CR + секреты (расшифрованные) + manifest`, restic-wrapped (dedup/incremental). Репо шифруется (содержит секреты; ключ у оператора). Ноль форса бакета.
- [x] **2.6d-3 — `restore` с local pull (Kind 2) — restore-into-running.** Единственный restore-путь, в **аналогичный свежий кластер** (DR «source мёртв»): apply сериализованных CR → оператор провижинит свежие claim'ы → restic restore данных / `pg_restore` в них → **re-seal секретов** в SealedSecrets/OpenBao target'а. **Auto-register всех приложений** из бэкапа (Argo Application CR пересоздаются → ворклоады из Git); **ручного re-add приложений нет.** Restore-ordering (apply→provision→load→re-seal) — основная сложность блока. Также data-restore в существующий кластер (`--data-only`: recover тома/БД без пересоздания app). **Restore-into-running (`--into <running-target>` / `--data-only`) — DONE, walk-GREEN.** ✅ **`--reprovision` (mode a — provision свежего кластера как часть restore, T13) — SHIPPED + real-Hetzner-validated 2026-07-16** (cli v0.2.31). `bootstrap_all::run(target)` провижинит свежий кластер в таргете ПЕРЕД replay'ем (топология+токен из local target-config, R2; version-alignment через существующий version_warning + ApplyPlatformStack); ленивый kc резолвится после reprovision-шага; `--reprovision`+`--data-only` reject up front. Walk `e2e/restore-reprovision-hetzner.sh` GREEN: provision→CMS+seed→backup→**destroy (source dead)**→restore --reprovision→verify (server id сменился 151688298→151689614, CMS auto-Ready, секрет+маркер целы).
- [x] **2.6d-4 — automated S3 backup (opt-in) — SHIPPED 2026-07-17 (cli/runner v0.2.33 / operator v0.2.33 / platform-stack 0.2.42 / cue-cmp v0.1.14 / runner-образ `apprafter-backup:v0.2.33`; 0.2.40+0.2.41 yanked).** Scheduled push того же restic-репо в remote S3-бакет юзера. **Два раунда фиксов на живых Hetzner-walk'ах:** (1) release-coordination — operatorVersion сначала оставили на уже-опубликованной v0.2.32 (2.4h imagePolicy) → gate release-operator скипнул ребилд → operator-сторона не зашипилась + ps 0.2.40 запинил stale operator; + cue-cmp drift-guard упал → operator v0.2.33 + cue-cmp v0.1.14 + ps 0.2.41, 0.2.40 YANKED. (2) **runner-фиксы (7 багов, все прошли unit/CRD/review, вскрыл только live S3-walk):** RBAC — pods `patch` (SSA helper-pod), pods/exec `get` (kube-rs WebSocket exec = GET, не kubectl-POST), secrets `list`, `sourcecredentials`, configmaps `create` split (нельзя ограничить resourceNames); код раннера — singular `secret`→plural (kube-rs discovery) + `eprintln!` фатальной ошибки в stderr. **Validated end-to-end на real Hetzner** (fixtest-образ + RBAC: полный backup в Hetzner Object Storage → snapshot закоммичен + lastSuccess → restic restore из S3 чистый) → ps 0.2.42 + runner v0.2.33, 0.2.41 YANKED. ✅ **файловая + S3 backup/restore регрессии GREEN на real Hetzner.** ⏳ push (1 коммит) + опциональный финальный walk на опубликованном 0.2.42 — за юзером. **Runner = AppRafter CronJob-restic** (`apprafter-backup` бинарь поверх общего `backup-core` движка; K8up отклонён — см. ADR 0050). Chart-owned delivery (`templates/backup.yaml`, guard `{{- if .Values.backup.enabled }}` → SA/scoped-RBAC + nightly backup CronJob + weekly `restic check` CronJob + CiliumNetworkPolicy egress-pin). Config на `PlatformStack.spec.backup` (opt-in, default off, GitOps-native). CLI: `apprafter backup enable/disable/status/prune/check/unlock` (enable/disable/status — декларативные merge-patch spec.backup после fail-closed preflight; prune/check/unlock — operator-side restic с полными creds юзера) + `--staging-mode monolithic|sequential` на local-pull backup + `restore s3:… --credential-file`. **StagingMode**: monolithic (default, 1 snapshot/run, manifest v1) / sequential (per-claim snapshot-set, manifest-snapshot ПОСЛЕДНИМ как commit-point, peak-disk = max(claim)). **Retention**: host+format-aware `plan_prune` (фиксированный `--host apprafter-backup`, keep 7/4/6 на manifest-представителях, forget по explicit-id), `enforce: operator` (default, prune вне кластера) / `cluster`. **Two-tier creds**: оператор владеет полными creds вне кластера; cluster Secret scoped (Put/Get/List + Delete только `locks/*` → append-only history). Creds НИКОГДА в chart values (только `credentialRef.name` через `envFrom: secretRef`). Status в non-chart-owned `apprafter-backup-status` CM. **Не дефолт, opt-in.** Walks: `e2e/backup-s3-hetzner.sh` (real-Hetzner monolithic, user-gated на бакет юзера) + `e2e/backup-s3-sequential-kind.sh` (kind+MinIO sequential). ⏳ real-Hetzner walk-run + push — за юзером.
- [x] **2.6d-5 — walk + docs + ADR 0050 + release.** `e2e/backup-restore-walk.sh`: `export` даёт открываемые dumps; local-pull backup → restore в свежий kind-кластер поднимает app'ы (auto-register) + данные + секреты; data-restore в существующий кластер. Docs `operator-guide/backup-restore.md` (local-pull default, S3 opt-in, restore-into-fresh, restic repo portability). ADR 0050 (backup/restore + data portability: restic-движок, Kind1/Kind2, local-default+S3-opt-in, restore-ordering, re-seal, Velero-rejected rationale). **Два-кластерный kind+podman walk GREEN дважды** (см. CORE-closed note выше).
- [ ] **2.6d-6 — захват данных JetStream (закрывает вторую половину A6).** 2.6d закрылся 2026-07-15, `needs.jetstream` — 2026-09-12: тип claim'а, которого не существовало, в объём попасть не мог, и ADR 0061 `## Scope` держит «backup and restore of JetStream stores» вне 2.5 явным пунктом. Первая половина A6 (снапшот выглядел полным) закрыта `0608e9e` — маркер `no_data` в манифесте + предупреждение в `backup create`/`backup show`/`export`; вторая — сам захват — этот пункт. **Три неизвестные сняты замерами до написания кода** (2026-09-19): (1) `mgr_<ns>` уже рендерится с `publish/subscribe: allow [">"]` (`nats_accounts.rs::render_account`) — прав на `$JS.API.STREAM.SNAPSHOT`/`RESTORE` и на delivery-subject хватает, **operator не трогаем**, и это ровно та идентичность, которую ADR 0061 §4.2 зарезервировал за ADR 0050 («Snapshot is `mgr_<ns>`'s job»); (2) на пиннутом `nats:2.14.3-alpine` + `nats` CLI v0.2.3: `nats stream backup <stream> <dir>` кладёт `backup.json` + `stream.tar.s2`, консьюмеры включены по умолчанию, `nats stream restore <dir>` **поверх существующего стрима отказывает** (`Stream "X" already exist`, exit 1), а после `stream rm -f` восстанавливает и сообщения, и консьюмеров с их состоянием; (3) права in-cluster-раннера уже cluster-wide (`pods` create/get/patch/delete + `pods/exec` + `secrets` get/list), default-deny NetworkPolicy висит только на `default`, helper-под живёт в `nats-system` рядом с сервером → **ни чарта, ни CNP, ни RBAC не трогаем**. Итог: нога **CLI + один пин в чарте**. Код — только `cli/` (operator, RBAC, CNP не трогаются), но scheduled-раннер запускается ОДНИМ образом, чей тег — литерал в `platform.cue` (`#BackupValues.image`), и ничто его не выводит: без бампа пина ночной CronJob продолжил бы писать снапшоты без jetstream-данных, а `apprafter backup` с ноутбука — с ними. Поймал `scripts/check-backup-runner-pin.sh` (гейт, написанный ровно после того, как пин протух на 15 образов). Пин `v0.2.66` → `v0.2.76` едет чартом **platform-stack 0.2.78**.
  - [x] **Захват.** `DataKind::JetStream`; арм `"jetstream"` в `plan_extraction` порождает элемент на КАЖДЫЙ стрим из `status.streams.declared + dynamic` (`unattributed` не берём — claim за них не отвечает, ADR 0061 §9), claim без инвентаря пропускается как непровизионенный. Координаты сервера — из connection-Secret'а самого claim'а (`host`/`port`), namespace NATS выводится из host'а, креды — Secret `nats-mgr-<ns>` (ключи `user`/`password`) в нём же. Helper-под в namespace NATS на пиннутом `natsio/nats-box` (четвёртый образ в `images.rs`), `nats stream backup … >/dev/null 2>&1 && tar c -C /tmp/bk .` → `jetstream/<ns>/<claim>/<stream>.tar` (stdout несёт ТОЛЬКО tar).
  - [x] **Восстановление.** Шаг в `restore.rs` после провижининга claim'ов: untar → `nats stream rm -f <stream>` → `nats stream restore` с ретраем на `already exist` (NACK пересоздаёт объявленный стрим пустым по своему циклу — это гонка, а не ошибка; конфиг после restore доводит NACK, Git остаётся источником правды для конфигурации, снапшот — только для данных). Работает и для `--data-only`; удаление живого стрима перед заливкой — разрушительно по определению, говорится вслух.
  - [x] **Снятие предупреждения.** `jetstream` уходит из `CLAIM_TYPES_WITHOUT_DATA_CAPTURE`; тест на дизъюнктность двух таблиц уже стоит и заставит это сделать в одном коммите с армом планировщика. Механика A6 остаётся живой (следующий нешипнутый тип), её тесты переезжают на синтетический тип.
  - [x] **Доки + релиз.** Строка `jetstream` в таблице `## What a backup captures` переехала из «captured as configuration only» в захватываемые (с оговоркой про `unattributed` и про снапшоты старше 0.2.76); `operator-guide/jetstream.md` переписан с «a backup does not carry the messages» на «what a backup carries»; `--help` у `export`/`restore` больше не перечисляет только pg/volumes/redis. **Запись в `docsgen behaviour::CLAIMS`** на фразу «no jetstream data is in this» с анкером на арм планировщика — гейт мутационно проверен (возврат фразы в доки роняет `docsgen gate`). CLI-релиз v0.2.76 (он же версия раннера) + platform-stack **0.2.78** с бампом пина раннера; operator и cue-cmp не трогаются.
  - [x] **Walk — GREEN 2026-09-19 (10 ассерций 2.6d-6).** `e2e/backup-restore-walk.sh` вырос на jetstream-фикстуру (стрим + сообщения + консьюмер → backup → restore-into-fresh → сообщения и консьюмер на месте). Блокер снят: `platform-stack/v0.2.77` (фикс nack) уже на origin. **Прогоны 2026-09-19 нашли две поломки, обе НЕ в предмете подпункта:** (1) `maxBytes` у объявленного стрима обязателен намеренно («a stream without it silently claims the whole account quota») — apiserver отклонял Application целиком, дефект был в моей фикстуре; (2) **walk сломан с 2.28**: с ADR 0065 §1.3 `expose.port` без объявленной readiness получает TCP-пробу по умолчанию, а приложение-фикстура (мигратор + sleep) на 5432 не слушает — deployment не мог стать Available. Никакой CI этот walk не гоняет, поэтому поломка жила молча с 2026-09-15. Декоративный `expose` из фикстуры убран. (3) NATS-имя стрима СОСТАВНОЕ (`nats_stream_name` = `<app>_<declared>` → `shop_orders`), и фикстура звала его по объявленному имени; попутно вскрылось, что публикация ДО создания стрима уходит в core NATS и пропадает, а `nats pub` всё равно рапортует успех — поэтому walk теперь сначала дожидается, что `status.streams.declared` перечислил стрим (это ровно то поле, из которого планирует захват, так что пустой инвентарь больше не может дать «зелёный бэкап ни о чём»). (4) PURGE приложению запрещён (`allowPurge` по умолчанию false), состояние цели готовит менеджерская идентичность — отказ закреплён отдельной ассерцией.

    **Что доказано на кластере:** инвентарь → 3 сообщения + durable → артефакт `jetstream/demo/shop-jetstream/shop_orders.tar` (5120 B, `backup.json` + `stream.tar.s2`, снят helper-подом в `nats-system` под `nats-mgr-demo`) → **Phase 3b**: стрим приведён в состояние цели (существует и ПУСТ, durable снят) → `restore --data-only` → 3 сообщения и durable вернулись. Phase 3b НЕ гейтится вторым кластером специально: двухкластерные фазы на этой машине дважды ушли в SOFT-SKIP (корневое Argo-приложение свежего кластера не доходит до `Synced` за 600 с — предсуществующее ограничение харнесса, не связанное с 2.6d-6), и без неё restore остался бы непроверенным. До прогона захват доказан на пиннутом `nats:2.14.3-alpine`: оба шипящихся скрипта прогнаны дословно против настоящего сервера в podman — дамп 5.6 KB tar, цель с пересозданным ПУСТЫМ стримом (0 сообщений/0 консьюмеров) → после restore 13 сообщений и консьюмер `worker` со своим pending. Это доказывает механизм, но не k8s-путь (helper-под, RBAC, координаты из Secret'ов).


> **Попутная находка 2.6d-6 — ИСПРАВЛЕНО (cli v0.2.76):** `find_claim_data_dir` (`restore.rs`)
> распознавал per-claim-снапшот по каталогам `pg` / `redis` / `disk`, а экстрактор пишет тома в
> `volumes/` — и `disk/` не писала НИ ОДНА версия (`git log -S 'join("disk")'` пуст). То есть
> sequential-бэкап claim'а `needs.disk` давал снапшот, который restore пропускал с note'ом и
> рапортовал успех: том не восстанавливал никто. Класс тот же, что у D26 (`a75f0dc`, который эту
> функцию и завёл), на один каталог позже; sequential-walk (`backup-s3-sequential-kind.sh`)
> поднимает pg+redis и disk-claim'а не имеет, поэтому не мог этого увидеть. **Фикс:** раскладка
> стала ОДНИМ утверждением — `DataKind::payload_dir` (исчерпывающий match: новый kind не
> компилируется, пока не назовёт каталог) + `DataKind::ALL`, который проверяется тестом через
> планировщик. Обе стороны бэкапа читают одну таблицу вместо двух литералов.

**Follow-on (T2-эра, не order 3.5):**
- [ ] **«Backups not configured» warning** на T2, когда automated backup не настроен (local-pull остаётся дефолтом).
- [ ] **Internal redundant/cross-node S3 default** — OPEN: на T2 дефолтом может стать внутренний S3 (на другой ноде / с резервированием), когда появится; либо остаётся local-pull-default + warning. Решить на T2.

**Open decisions:** ~~scheduled-runner K8up vs CronJob-restic~~ — РЕШЕНО в 2.6d-4 (AppRafter CronJob-restic; ADR 0050 Alternatives). Ещё открыто (T2): T2-default local-pull+warning vs internal-redundant-S3; нужен ли отдельный шифрованный-бандл формат vs «папка + restic-репо».

**Acceptance:** `export <ns>` → локально открываемые `pg_dump`/деревья, `pg_restore` в локальный pg работает; local-pull backup → `restore --into <fresh-cluster>` поднимает все app'ы (auto-register, без ручного re-add) + данные + re-sealed секреты; restore данных в существующий кластер восстанавливает том/БД; restic-репо читается plain-restic'ом (no-lock-in).

**Зависит от:** 2.6b (owned-disk), 2.6c (SharedVolume — чтобы export/backup покрывал shared-тома), 2.11 (SealedSecrets — расшифровка/re-seal), `needs.pg`/`needs.redis` (источники dumps). Full OTel — НЕ зависимость.

**Размер:** L (extraction + restic-оркестрация + CR-serialization + restore-ordering + re-seal; default-local-pull можно дать раньше S3-opt-in'а).

---

### 2.7 SPIRE installation + workload identity
> 🏁 SR: C — SPIRE; trigger: first Tier-2 OpenBao-grade or compliance ask

**Поставка:**
- [ ] SPIRE server + agent на каждой ноде.
- [ ] Trust domain `platform.local` (или из ExternalSurface).
- [ ] Регистрация workloads по labels оператором.
- [ ] Metrics + audit log.

**Acceptance:** под получает SVID через unix socket; `spire-agent api fetch` возвращает X.509-cert.

**Зависит от:** 1.8

**Размер:** L

---

### 2.8 Credential injection через SPIFFE
> 🏁 SR: C — credential injection via SPIFFE; with 2.7

**Поставка:**
- [ ] Замена «mounted Secret with DSN» на «приложение получает DSN через workload identity (короткоживущие credentials)».
- [ ] Для PG: интеграция через CNPG `pg_ident.conf` + SPIFFE-aware sidecar.
- [ ] Fallback на mounted Secret с пометкой «deprecated, use workload identity».

**Acceptance:** под без переменной окружения с паролем PG, аутентификация через SPIFFE; ротация SVID каждый час, приложение продолжает работать.

**Зависит от:** 2.7

**Размер:** L

---

### 2.9 Per-environment overrides через CUE unification
> 🏁 SR: A — multi-env на ОДНОМ кластере по namespace'ам (dev+staging / dev+prod для T1); un-dropped из launch (был D) 2026-06-04, естественный порядок, рано НЕ притягиваем

> 🎨 **Дизайн (2026-06-07, ADR 0044 + spec `docs/superpowers/specs/2026-06-07-2.9-per-env-deploy-design.md`):** env — **deploy-time** селектор per-Application, НЕ cluster-global (инертный `APPRAFTER_ENV` выпиливается). Модель **scalar**: один env-агностичный манифест → **один Argo-апп на env-деплой** (`<name>-<env>`), self-contained в своём namespace (ownerRef-каскад как есть), группировка лейблами `apprafter.io/application` + `apprafter.io/environment` (ключи **уже устоявшиеся** — migration-strategy ставит их на **MigrationPlan'ы** как discoverability-теги, `strategy.rs:163-175`; 2.9 переиспользует те же ключи на **Argo-аппе** (CLI `app add`) + **children** (рендерер) — та же семантика «принадлежит app X / env Y»; migration-гейт матчит по spec-полям `scope.application.ref`, НЕ по лейблам). `Application.spec.environment` (инжектит CMP) выбирает override; `effective_spec(app, spec.environment)` сливает; webhook `env ∈ environments`. Namespace **ортогонален** (выбор юзера на `app add`: existing/new). Мягкий дефолт `PlatformStack.spec.defaultEnvironment` (пред-выбор в CLI, не гейт). Single-CR fan-out (cross-ns ownerRef нельзя), dev-mode форсинг (1.9/2.9/3.9 dev-слайсы), Backstage-вкладки, `apprafter promote` (= cross-CR копирование image между `<name>-<src>`/`<name>-<dst>`) + env-миграция — **отложены** (ADR 0044 §Decision/§Non-goals). Удаление `Context.env_name` ре-вайрит и MigrationPlan-гейт (`find_blocking_migration_plan` ← `app.spec.environment`). Поставка ниже = доуточняется планом. **NB: `### 2.9 Per-environment overrides` (это) ≠ `## Фаза 2.9 — Dev Mode` (стр. ~3190 + roadmap-таблица «2.9 Dev Mode») — разные 2.9; dev-mode отложен.**

> ✅ **ЗАКРЫТО (2026-06-07).** Subagent-driven (T1–T12, ветка `feat/2.9-per-env-deploy`). env — **deploy-time per-CR** `Application.spec.environment` (инжектит cue-cmp из Argo `plugin.env APPRAFTER_APP_ENV`), `effective_spec` сливает override на base; инертный cluster-wide `APPRAFTER_ENV` + `Context.env_name` выпилены (MigrationPlan-гейт ре-вайрен на `app.spec.environment`). Scalar: `app add --env` → один Argo-апп `<name>-<env>` self-contained в выбранном namespace, группировка существующими лейблами `apprafter.io/application` + `apprafter.io/environment`; `app status`/`remove` агрегируют по лейблу; webhook `env ∈ environments`; `PlatformStack.defaultEnvironment` — мягкий дефолт. **Live-walk `e2e/gitops-walk-per-env.sh` GREEN end-to-end** (Approach A — side-load operator+webhook+cue-cmp; 9 фаз, ~3.5 мин): app add --env → plugin env → cue-cmp инжектит → operator env-резолвит → два namespace'а (replicas 1 vs 2, TIER dev/prod) → status агрегирует → remove --env хирургичен. **Walk вскрыл критический баг (был бы инертен в проде):** Argo CD префиксует `plugin.env` переменные `ARGOCD_ENV_`, поэтому cue-cmp читал голый `$APPRAFTER_APP_ENV` и НИКОГДА не инжектил `spec.environment` (всё рендерилось base, `--env` молча игнорился; host-тест это маскировал) → фикс `f91bdf0` (читает префиксную форму) + регресс-тест (test-inject 15/15). **Релиз:** operator+platform-stack **v0.2.22** + cli **v0.2.8** (монорепо-тег v0.2.8) + **argocd-cue-cmp v0.1.8** (фикс инъекции; platform-stack деривит тег из `version.cue`). Гейты: cargo fmt/clippy -D/test --workspace (cli+operator) + just lint + cue vet + `just crd-validate` (CRD-additive, change=safe) + `just platform-stack-check` (рендерит 0.2.22). **NB: 2.9 ≠ закрытие Фазы 2 — §6 M2 НЕ флипать** (M2 закрывается после 2.10–2.12). spec.md §3.1 reconciliation (unification→override-wins; substrate→scalar) — на phase-close актуализации (трекнуто в ADR 0044 §References). **Findings:** `parse_application` распознаёт только Style-B манифесты → CLI-side env-валидация для Style-A скипается (webhook бэкстопит) — non-blocking follow-up. **Ждёт пуша** (push policy).

**Цель:** реализовать §3.1 пример (dev/staging/prod в одном файле) — несколько окружений **со-резидентно на одном кластере**, каждое в своём namespace.

**Контекст (находка 2.4g walk 2026-06-04):** shipped `APPRAFTER_ENV` (1.9c) — **кластер-wide overlay БЕЗ конфиг-поверхности**: ни values в чарте оператора, ни проброса в platform-stack, ни CLI, нигде не surfaced, + Argo откатит ручной `kubectl set env` self-heal'ом → механизм есть, но env **выбрать нельзя**, фича инертна (всегда рендерится `base`). 2.9 **заменяет** кластер-wide-модель на namespace-per-env (модельная цель пользователя: dev+staging или dev+prod на одном кластере) + даёт реальную конфиг/selection-поверхность. Сейчас landing/cms катается как `base` (= prod-конфиг), а его блок `environments.dev` мёртв.

**Поставка — ✅ ЗАКРЫТО (launch-срез), кроме явно отложенного:**
- [x] Renderer учитывает `environments.<env>` (override-wins merge) per-CR — `effective_spec(app, app.spec.environment)` вместо инертного cluster-wide `APPRAFTER_ENV`.
- [x] Каждый env-деплой = **отдельный `app add --env <env>`** → один Argo-апп `<name>-<env>` → один namespace (**выбор юзера**, ортогонален env — НЕ авто-суффикс). Несколько env со-резидентно = несколько `app add` в разные namespace'ы; группируются лейблом `apprafter.io/application`. Заменяет cluster-wide `APPRAFTER_ENV` (scalar, ADR 0044 — НЕ operator fan-out).
- [x] **Конфиг/selection-поверхность:** `app add --env` (+ интерактив: env из declared, дефолт из `PlatformStack.defaultEnvironment`; namespace existing/new); env **виден** (`app status <name>` агрегирует по лейблу + `status.environment`). Закрывает gap инертного `APPRAFTER_ENV`.
- [x] Selector ServiceProvider различен по env — **выпадает из override-механизма** (блок `environments.prod` сам задаёт `needs.*.selector`), отдельного кода нет (managed-тиров на launch нет).
- [ ] ~~Backstage показывает вкладки по env'ам~~ — **отложено** (Phase 3 Backstage, ADR 0044 §Non-goals).

**Acceptance:** один Application-манифест + три `app add --env {dev,staging,prod}` в три (выбранных юзером) namespace'а на ОДНОМ кластере → три Argo-аппа `<name>-<env>`, каждый со своим override-резолвом (разные ресурсы); все env-деплои видны (`app status <name>` агрегирует по лейблу `apprafter.io/application`); webhook отклоняет `--env` не из `environments`; CUE-валидация ловит конфликт типов base↔env override.

**Зависит от:** 1.9, 2.4

**Размер:** M (+конфиг/selection-поверхность — пересмотреть при дизайне)

---

### 2.10 needs → NetworkPolicy auto-derivation
> 🏁 SR: A · order 3 — needs→NetworkPolicy auto-derivation (free security win)

> 🎨 **Дизайн (2026-06-08, ADR 0045 + spec `docs/superpowers/specs/2026-06-08-2.10-needs-networkpolicy-design.md`):** оператор эмитит **ОДИН `CiliumNetworkPolicy` (cilium.io/v2) на Application** (per-CR; строится `json!`/`DynamicObject` — внешний-CR паттерн, не hand-rolled тип). Baseline = DNS + same-ns + `world` (интернет) + по egress-rule на каждый declared **сетевой** need (pg/redis; `disk` — без сетевой цели, исключён); кросс-сервисный in-cluster egress закрыт → Hubble drop. Постура **config-driven**: новое поле `PlatformStack.spec.network.egress.profile` (`internet`|`internal`|`strict`; дефолт `internet` на всех тирах, оператор fallback'ит на `internet` при отсутствии) + CLI `apprafter platform egress show/set` (SSA, field manager `apprafter-cli`; PlatformStack — CLI-bootstrap-seeded control-plane, не Argo-reconciled → live-set переживает синк, §1.4 per-tier control-surface). Launch = `internet` (интернет открыт — `connects` ещё нет; T2+→`internal` отложено до ExternalSurface). Декомпозиция 2.10-1…5 — в спеке. **NB: 2.10 ≠ закрытие Фазы 2 — §6 M2 НЕ флипать** (M2 после 2.10–2.12).

**Цель:** при `needs.pg` оператор создаёт egress NetworkPolicy к pg-кластеру.

> ✅ **ЗАКРЫТО (2026-06-09).** Subagent-driven (T1–T5, ветка `feat/2.10-needs-networkpolicy`). Оператор эмитит **ОДИН** `CiliumNetworkPolicy` (`<rendered-name>-egress`, owner-ref на Application) per-CR через `json!`/`DynamicObject`: default-deny egress + DNS + same-ns + `world` + по правилу на каждый сетевой need (pg→cnpg-system:5432, redis→dragonfly-system:6379; disk исключён). Apply гейтится startup-пробой CRD `ciliumnetworkpolicies.cilium.io` (non-Cilium кластеры рендерят, но не применяют). Постура config-driven: новое `PlatformStack.spec.network.egress.profile` (`internet`(деф)|`internal`|`strict`), CLI `apprafter platform egress show/set`. **Live-walk `e2e/needs-networkpolicy-walk.sh` GREEN end-to-end на kind+Cilium** (8 фаз, sandbox-run rootful microVM): эмиссия CNP → enforcement-контраст (noproxy→pg DROPPED, web→pg FORWARDED) → internet/internal/strict переключение через CLI. **Walk вскрыл 2 продуктовых бага (юнит/CRD/ревью пропустили):** (1) egress pg-селектор был на устаревшем `postgresql.cnpg.io/cluster` вместо `cnpg.io/cluster` → egress к Postgres молча дропался (фикс `8b4b3e1`); (2) `egress set` под bootstrap-овским field-manager `apprafter-cli` прунил REQUIRED `spec.source`/`spec.values` PlatformStack → apiserver reject → выделенный `apprafter-cli-egress` (фикс `0bf309e`). Плюс walk-харнесс: RBAC-рендер без `-n` затирал ClusterRoleBinding subject (`test(e2e)` `3ac1972`). **Релиз:** operator+webhook+platform-stack **0.2.22 → 0.2.23** (оба чарта version+appVersion, component-пины + currentVersion + compatibility change=safe) + cli **0.2.9 → 0.2.10** (monorepo-тег v0.2.10). Гейты зелёные: cargo fmt/clippy -D/test (cli+operator), `just platform-stack-check` (рендерит 0.2.23). **NB: 2.10 ≠ закрытие Фазы 2 — §6 M2 НЕ флипнут** (M2 после 2.11–2.12). spec.md §-актуализация — на закрытии Фазы 2. **Ждёт пуша** (push policy: operator/v0.2.23 + platform-stack/v0.2.23 — workflow-made на пуше; monorepo v0.2.10 — локальный).

**Поставка:**
- [x] Каталог connection-targets для каждого ServiceProvider type (label-selector + порт).
- [x] Renderer эмитит **ОДИН** CiliumNetworkPolicy на Application (per-CR), с одним egress-rule на каждый declared need внутри (не CNP-на-need).
- [x] Launch egress-дефолт = profile `internet` (DNS + same-ns + `world` + needs): интернет открыт (`connects` ещё нет), кросс-ns in-cluster закрыт и гейтится через needs (Hubble drop). `connects`-гейтинг интернета + T2+`internal` — отложено до ExternalSurface (ADR 0045).
- [x] Hubble drops на forbidden flows видны в логах (Hubble best-effort — tier-1 ships его off, ADR 0020; enforcement в walk доказан connectivity-контрастом web vs noproxy к одному pg-Service).

**Acceptance:** Application без `needs.pg` не может коннектится к pg-кластеру (Hubble drop); с `needs.pg` — может.

**Зависит от:** 2.4, 2.5, 2.6

**Размер:** M

---

### 2.11 SealedSecrets интеграция (Tier 1 секреты)
> 🏁 SR: A · order 3 — SealedSecrets (default Tier-1 secrets). **Controller + `secret seal` slice carved к фронту order 3 как prereq для 1.79c** (`SourceCredential`, см. `speedrun-plan.md` §4.2); Backstage encrypt-wizard + UI rotation-warning — позже в order 3.

> ✅ **ЗАКРЫТО (2026-06-09) — launch-scope выполнен; Backstage-UI явно отложен на пост-запуск.** Функциональная возможность шифровать секреты (launch-требование CP2 «secrets management — SealedSecrets», FEATURE_TRACKER) уже зашипана: sealed-secrets controller (платформенный компонент `component_sealed-secrets.cue`, bitnami, `fullnameOverride` пинит имя для cert-fetch) + нативный Rust-seal в `cli-providers::k8s::sealing` + команда `apprafter secret seal` — всё поставлено форвард-слайсом S0 (v0.1.175) как prereq для 1.79c (ADR 0039). CLI приватный ключ не держит: cert фетчится **живьём** из контроллера через kube API service-proxy. Acceptance (CLI шифрует → commit → Argo синкает → в кластере обычный Secret) достижим уже сегодня. **Отложено на пост-запуск (см. ниже #4/#5):** Backstage encrypt-wizard + posture-warning — порталь­ный UI, который НЕ входит в launch-минимум Backstage (launch-checklist §1.1 = Application/ResourceClaim/AccessGrant/Notifications плагины) и едет в **post-launch first bundle (PL1)** рядом с MigrationPlan approval-UI (FEATURE_TRACKER PL1; ADR 0036 «a Backstage approval surface follows in the post-launch bundle»; hosted-portal buildout = CP4). **#3 снят как OBSOLETE** — live cert-fetch вытеснил статический pubkey-файл. Docs-only закрытие (контроллер+seal зашипаны ранее) — без version-bump/тега. **NB: 2.11 ≠ закрытие Фазы 2** — §6 M2 НЕ флипать (закроется после 2.12). Launch-time secret-история продолжается OpenBao + migration-path (launch-checklist §1.1) в Фазе 3+.

**Поставка:**
- [x] Установка sealed-secrets controller. ✅ S0/v0.1.175 (`component_sealed-secrets.cue`).
- [x] CLI helper в `apprafter`: `apprafter secret seal --name foo --from-literal=...`. ✅ S0/v0.1.175 (нативный Rust-seal, `secret.rs` + `sealing.rs`).
- [x] ~~Public-key экспортируется и публикуется в `manifests/tier-1/sealed-secrets/`.~~ **OBSOLETE** — CLI фетчит cert живьём через kube API service-proxy (`fetch_controller_public_key`); статический pubkey-файл не нужен.
- [ ] Backstage UI: «Encrypt secret» wizard для Tier 1. → **ОТЛОЖЕНО: post-launch portal bundle (PL1)**.
- [ ] Прометейный warning в UI: «вы используете SealedSecrets — без ротации, без dynamic. Tier 2+ → OpenBao». → **ОТЛОЖЕНО: post-launch portal bundle (PL1)**.

**Acceptance:** разработчик через CLI шифрует секрет, коммитит, Argo CD синкает, в кластере появляется обычный Secret. ✅ достижимо через зашипанный `apprafter secret seal` + контроллер.

**Зависит от:** 1.5

**Размер:** M

---

### 2.12 Application.env: secret() и claim.* references
> 🏁 SR: A · order 3 — secret()/claim.* refs in Application.env

> ✅ **ЗАКРЫТО (2026-06-10) — закрывает платформенно-сервисное ядро M2 по гейту 2.10-2.12; §6 M2-бокс флипнут.** (Post-gate Phase-2-номера НЕ M2-functionality-gating: 2.13-2.16 Notifications — SR:D drop; 2.16a per-claim rotation — launch follow-on, SR:A; 2.17 — M2-checklist housekeeping.) Subagent-driven (ADR 0046 + spec `docs/superpowers/specs/2026-06-09-2.12-env-references-design.md`, T0–T8, ветка `feat/2.12-env-references`). `Application.spec.*.env`-значение теперь: **литерал** (строка), **claim-ссылка** (голый CUE-селектор `claim.<type>.<field>`, вкл. разложенные `user|pass|host|port|db` и именованные `claim.<type>.<name>.<field>`; pg+redis), или **secret-ссылка** (braceless `secret: "<name>/<key>"`). На уровне CR — string-discriminated маркеры `{claim:"pg.url"}`/`{secret:"name/key"}`; чистый рендерер резолвит в `EnvVar{valueFrom: secretKeyRef}`. Провижионер пишет канонические разложенные ключи connection-Secret (`url user pass host port db`+redis `channelPrefix`), дропнув композитные `DATABASE_URL`/`REDIS_URL` (`acl_reconcile`→`pass`). **2.4e авто-инъекция `DATABASE_URL` УДАЛЕНА** (это её правильная замена; collision-guard снят). cue-cmp (**v0.1.8→v0.1.9**) инжектит актуальную схему + генерируемый `claim`-биндинг в эфемерный workspace (cross-package: comprehension в пакете манифеста через экспортируемую `#ClaimFieldsFor`; two-pass needs-extraction; env-agnostic union) → голые селекторы рендерятся; **scaffold перестал вендорить схему**, новый `apprafter app validate` гоняет ту же инъекцию локально (parity-verified). Валидация слоями: cue vet (claim) + webhook (формат) + рантайм (нет Secret'а → `Ready=False` reason `EnvSecretMissing`). **Live-walks GREEN на kind+podman:** `needs-env-refs-walk` (3 источника + missing-secret→NotReady→recover; под видит `DATABASE_URL=postgresql://…`/`DB_USER`/`STRIPE_KEY=s3cr3t`), `needs-disk-walk` (именованные `claim.pg.primary.url`/`.analytics.url`), `needs-redis-walk` (`claim.redis.url`/`channelPrefix`); все обновлены под снятый auto-inject. **Ни одного продуктового бага в walk'ах** (юниты их закрыли: rendering/application/webhook/provisioner). Гейты зелёные: cargo fmt/clippy -D/test (cli+operator), `just lint`, `just crd-validate` (CRD-additive), `just platform-stack-check` (рендерит 0.2.24), `test-inject.sh`. **Релиз:** operator+webhook+platform-stack **0.2.23→0.2.24** + cue-cmp **0.1.9** + cli **0.2.10→0.2.11**. spec.md §3.1/§4.4/§4.5 (env-value-model + 2.9-deferred unification→override-wins/substrate→scalar) актуализированы, Revision 10→11. **§6 M2-бокс флипнут по гейту 2.10-2.12.**

**Поставка:**
- [x] CUE-функции `secret(...)` и `claim.<type>.<field>` в схеме. ✅ Реализовано как **голый CUE-селектор** `claim.pg.url` (cue-cmp/CLI инжектят `claim`-биндинг из needs через `#ClaimFieldsFor`) + braceless `secret: "name/key"`; CR-маркеры `{claim:"…"}`/`{secret:"…"}` (NB: не CUE-«функции» — у CUE нет call-синтаксиса; claim резолвит cue-cmp в рантайме рендера, не cue-eval). `uri`→`url`.
- [x] Renderer резолвит: `secret(...)`→`secretKeyRef{name,key}`; `claim.<type>.<field>`→`secretKeyRef{name:<connectionSecretRef>, key:<field>}` (pure `resolve_env`, нитка `(type,name)→connectionSecretRef`). Vault Agent — Phase 3 (отложено).
- [x] Литералы (`LOG_LEVEL: "info"`) — обычный env.
- [x] Ошибка resolve — Application Status NotReady с понятной причиной (`EnvSecretMissing`; claim-existence гарантирован 2.4d-гейтом).

**Acceptance:** Application с тремя источниками env (literal, secret, claim) запускается, под видит все три переменные. ✅ live-доказано (`needs-env-refs-walk`).

**Зависит от:** 2.4, 2.11

**Размер:** M

---

### 2.13 Notifications service — каркас (HTTP API + NATS внутрь)
> 🏁 SR: D — Notifications service dropped from launch (managed portal + direct transactional email); reactivate with AccessGrant

**Поставка:**
- [ ] OneBun-сервис `notifications` в `providers/notifications-integrated/`.
- [ ] HTTP `/send` endpoint, авторизация через workload identity (JWT с SPIFFE claims).
- [ ] Внутрь — publish в NATS JetStream stream `notifications.<account>.outbox`.
- [ ] CUE-схема `needs.notifications` (см. §4.6).
- [ ] Auto-provision streams + DLQ при первом claim.

**Acceptance:** `curl` с правильным JWT публикует сообщение, оно появляется в outbox-stream.

**Зависит от:** 2.5, 2.7

**Размер:** L

---

### 2.14 Notifications channels: SMTP / Slack / Telegram
> 🏁 SR: D — Notifications channels; with 2.13

**Поставка:**
- [ ] Воркеры на OneBun: `email-worker`, `slack-worker`, `telegram-worker`.
- [ ] Подписка на outbox, доставка по каналу, exponential backoff retry.
- [ ] DLQ после N retries, alert на escalation channel.
- [ ] Конфигурация SMTP/Slack/Telegram через ExternalSurface (3.x ещё не готов — пока через ConfigMap).

**Acceptance:** отправка через `/send` доходит до email/Slack/TG; искусственная ошибка SMTP уводит в DLQ + alert.

**Зависит от:** 2.13

**Размер:** L

---

### 2.15 Platform-only notification templates
> 🏁 SR: D — Notification templates; with 2.13

**Поставка:**
- [ ] `templates/access-grant/{issued,renewal-reminder,expired,revoked}.{html,md}`.
- [ ] `templates/operational/{dlq-stuck,service-down,quota-exceeded,migration-pending,backup-digest}.{html,md}`.
- [ ] `templates/bootstrap/cluster-initialized.{html,md}`.
- [ ] Template-engine (Handlebars или Liquid) в notifications-сервисе.
- [ ] Override-механизм: ConfigMap `platform-notification-templates` перебивает встроенные.

**Acceptance:** платформенное событие (например, бутстрап кластера) уходит email с правильным шаблоном.

**Зависит от:** 2.14

**Размер:** M

---

### 2.16 Backstage notifications-плагин
> 🏁 SR: D — Notifications Backstage plugin; with 2.13

**Поставка:**
- [ ] Inbox-view: pending / sent / failed / DLQ per Application.
- [ ] DLQ viewer: retry, drop actions.
- [ ] Per-channel success-rate dashboard.
- [ ] Alert-баннер в UI «N стуков в DLQ».

**Acceptance:** в Backstage виден реальный inbox; retry из UI воскрешает сообщение.

**Зависит от:** 2.14, 1.10

**Размер:** M

---

### 2.16a — Per-claim password rotation
> 🏁 SR: A — автоматическая ротация кредлов всех claim-ролей (security baseline); притянут в launch, surfaced на 2.4g walk

**Контекст (находка 2.4g walk 2026-06-04):** пароль per-claim роли генерится ТОЛЬКО на (ре)провижне (claim Scheduled→ready) — первый провижн + восстановление; на reconcile готового claim'а и на рестартах (под/оператор) НЕ ротируется (`should_provision`=false когда ready). **Периодической/плановой ротации НЕТ** — кредл статичен на всю жизнь claim'а. CNPG умеет ротировать через basic-auth Secret, но никто это не автоматизирует.

**Цель:** автоматическая периодическая ротация паролей всех claim-ролей (pg сейчас; обобщить на jetstream/redis по мере появления).

**Поставка:**
- [ ] Политика ротации (интервал, per-tier дефолт — Regulated короче; opt-out/override на claim).
- [ ] Контроллер/таймер регенерит пароль роли → обновляет basic-auth Secret → CNPG ALTER ROLE → пересобирает connection Secret; rolling, без даунтайма (под перечитывает Secret).
- [ ] Метрика last-rotated + surface в `app status`; ручная ротация по запросу.

**Acceptance:** пароль claim-роли ротируется по интервалу автоматически; приложение продолжает коннектиться (перечитывает обновлённый Secret).

**Зависит от:** 2.4 (claim-провижн), 2.8/2.11 (secret-инфра)

**Размер:** M · топически ближе к 2.8/2.11 — номер 2.16a по просьбе (slot перед закрытием M2); перенести при желании

---

### 2.16b — App-scope migration: auto-detect + Argo approval surface
> 🏁 SR: A · order 3.7 (после слайса 1.83, перед T2 substrate; см. `speedrun-plan.md` §4.2) — «флип» детекта деструктивных операций приложения + безопасная in-Argo приёмка аппрува для app-scope MigrationPlan.
> ✅ **ЗАКРЫТО 2026-07-18** (order-3.7, SR:A; ADR 0051 + spec `docs/superpowers/specs/2026-07-17-2.16b-app-scope-migration-design.md`, T1–T16 subagent-driven, ветка `feat/2.16b-app-scope-migration`). App-scope деструктив-детект ВКЛЮЧЁН: классификатор `detect_destructive` по **эффективной per-env** спеке vs застампленный `status.lastAppliedSpec` baseline. Gated — `needs-removal`→data-migration; `scale-to-zero`/`image-path-change`/`domain-change`/`network-visibility-change`/`env-ref-removal`→requires-restart (ОДИН primary детерминированно: severity↓, trigger↑, field↑). Soft (не гейт, шлёт `SoftDestructiveChange` Event) — env-литерал removal, `needs.*.selector`/`.size`, image-tag, scale-down N→M. App-scope `MigrationPlan` в **namespace приложения** + controlling ownerRef→Application CR (каскад на delete, RBAC ns-scoped); approve через Argo-узел / `apprafter migration approve` (auto-resolve ns; `list` cluster-wide) → render new spec → re-stamp baseline → consume (delete plan) + anti-loop + `.owns(MigrationPlan)` instant-consume; **reject только через Git** (revert → план само-удаляется; approve-only, spec.md §3.8). **Two-env kind+Argo walk (`e2e/app-migration-walk.sh`) GREEN end-to-end** (baseline-stamp → effect-per-env gate [dev gated, prod untouched] → plan shape+ownerRef → self-heal → CLI approve→consume→anti-loop → soft-Event → revert=reject-via-Git). Walk вскрыл **2 реальных product-бага** (оба прошли unit/CRD/review): (1) `status.lastAppliedSpec` пруннился в `{}` — bare `type:object` под status-preserve-unknown = structural pruning boundary → явный preserve-unknown statusSchemaPatch (`a6f7b0c`, regression-guard fails-when-reverted); (2) pause-статусы теряли baseline — `apply_status` это SSA под одним field-manager, пропуск поля ПРУННИТ его → гейт само-отменялся за ~200мс → все 4 pause-builder'а пере-слают baseline (`a40bdf7`, 4-builder regression-тест); + 1 walk-harness fix (progress→stderr в plan-name capture). **Продуктовый нюанс:** `network-visibility-change` никогда не standalone-primary для webhook-валидной правки (webhook связывает hostname↔public двусторонне → флип public→internal со-удаляет hostname → tie-break даёт `domain-change`) — корректная defense-in-depth. ADR 0051 + spec.md §3.8/§3.1 (Revision 11→12) актуализированы; `operator-guide/migration-plans.md` расширен; корневая таблица `2.16b-destructive-ops.md`. Гейты зелёные: cargo fmt/clippy -D/test --workspace + just crd-check/crd-validate + just platform-stack-check (0.2.43) + final code-review SHIP. **Релиз:** operator+webhook charts v0.2.33→**v0.2.34**, cue-cmp 0.1.14→**0.1.15** (`schemas/v1alpha1/application.cue` изменилась), platform-stack currentVersion 0.2.42→**0.2.43** (compatibility change=safe, operatorVersion v0.2.34), cli 0.2.33→**v0.2.34** (Task 13 тронул бинарь; monorepo tag v0.2.34 local). 2.16b ≠ Phase closure (order-3.5/3.7 pulled-up; §6-бокс не трогается — но spec.md §3.8/§3.1 актуализированы как описание shipped-поведения). Post-gate по SR: **2.16b-sc** (SourceCredential-scope, тот же флип), затем **4** (T2 substrate).

**Контекст:** unified MigrationPlan (1.76-1.78) уже умеет application-scope, но **детект выключен**: `ApplicationMigrationStrategy::detect_destructive` безусловно возвращает `None` (`strategy.rs`), `create_plan_for` зовётся только из тестов (`application/src/lib.rs` — документировано как future Phase-2.x флип), потому что v1alpha1-схема (image/replicas/expose/env) на момент 1.77 не несла деструктивных операций. Теперь они **есть** (needs из 2.4, домены из 1.83, scale, image-path). Пауза УЖЕ видна юзеру: при блокирующем плане контроллер ставит Application CR в `phase: AwaitingMigrationApproval`, а health `apprafter.io_Application` (chart) рисует узел Degraded «awaiting MigrationPlan approval». Чего НЕТ: (а) авто-детекта+авто-создания app-плана, (б) кликабельного approve в дереве Argo-апа юзера (платформенный аналог — ADR 0048).

**Таксономия деструктивных операций (что гейтить):**
- **Hard (data-loss → класс `data-migration`):** удаление `needs.*` — триггерит ResourceClaim GC (2.4f) → потенциальная потеря данных (БД/диск). Гейт обязателен.
- **Surface/availability (класс `requires-restart`/destructive):** удаление/смена домена (`expose.hostname`/allowedDomains из 1.83 — апп становится недоступен на старом домене, churn серта); **scale-to-zero** (replicas N→0 — намеренный даунтайм); **смена пути образа** (репозиторий, не тег — это потенциально другой апп/breaking).
- **Soft / не гейтить:** **удаление env** — НЕ data-loss и НЕ даунтайм: rolling update само-защищается (новые поды без нужного env крашатся/не проходят readiness → старые поды продолжают обслуживать, rollout зависает, откатывается правкой; recoverable). → warn/caution, не hard-гейт; **ужесточить только если удаляется env с claim/secret-ссылкой** (нагруженнее литерала). **Смена тега образа** (тот же репо, плавающий типа `latest`) — НЕ деструктивно (резолв tag→digest + авто-роллаут, 2.4h). `needs` add, scale-from-zero, env add/смена-литерала — не гейтятся.

**Цель:** включить app-scope детект деструктивных операций + авто-создание MigrationPlan + безопасную in-Argo приёмку аппрува на самом приложении.

**Поставка:**
- [x] Классификатор `detect_destructive(old, new) -> Option<DestructiveChange>` по таксономии выше (per-op класс); юнит-таблица всех случаев (вкл. env-edge-кейсы и image tag-vs-path).
- [x] Врезка детекта в Application reconcile loop (сейчас не вызывается) + авто-создание app-плана через `create_plan_for` (не только из тестов).
- [x] **Безопасная Argo-обвязка (ОТЛИЧИЕ от ADR 0048):** app-план + ownerRef **в ОДНОМ namespace** — либо план в namespace приложения + ownerRef на Application CR (он managed-узел в дереве Argo-апа юзера), либо per-app anchor в namespace приложения. **НЕ** план в `apprafter-system` + cross-ns ownerRef на Application CR — k8s GC тихо удалит план (тот же foot-gun, что обошли для платформы одной-ns anchor'ом). Тогда existing approve/reject-action (`apprafter.io_MigrationPlan`) загорается на узле плана под приложением юзера.
- [x] Health-Lua узла плана (как `apprafter.io_MigrationPlan` для платформы — детали «from→to / op / awaiting approval»). Пауза на Application CR (AwaitingMigrationApproval health) — уже есть, интегрировать.
- [x] Live kind+Argo walk (per `feedback_phase_closure_validation`): деструктивная правка апа → план создан + видим на апе + approve в дереве кликается → flip → reconcile применяет; same-ns ownerRef не удаляется GC (assert «план жив через 60с»).

**Acceptance:** правка апа с деструктивной операцией (напр. убрать `needs.pg`, удалить домен, scale-to-zero, сменить путь образа) → авто-создаётся app-scope MigrationPlan, апп паузится (AwaitingMigrationApproval), план виден+кликабелен на приложении в Argo, approve через UI/CLI снимает паузу; недеструктивные правки (смена тега, env-литерал, scale-from-zero) проходят без гейта.

**Зависит от:** 1.76-1.78 (MigrationPlan + контроллер), 2.4 (needs/claim GC), 1.83 (domain-операции), 2.4h (image tag→digest), ADR 0048 (платформенный паттерн — переиспользовать, но ns-correct). **Связан с** [[project_argo_approval_surface]].

**Размер:** M-L · детект (классификатор + врезка) — основная масса; Argo-обвязка ~как ADR 0048 минус cross-ns-нюанс. SR:A order 3.7.

---

### 2.16b-sec — App-migration security axis
> 🏁 SR: A · order 3.7 (расширение 2.16b — та же машина, вторая ось) — гейт **аддитивных/эскалационных** правок манифеста (инвертированная модель угроз) + структурное упрочнение самого гейта.
> ✅ **ЗАКРЫТО 2026-08-06** (order-3.7, SR:A; ADR 0052 + spec `docs/superpowers/specs/2026-08-06-2.16b-security-axis-design.md`, ветка `feat/2.16b-security-axis`). 2.16b гейтит ось **availability/data-loss** (removal ломает работающий сервис). Инвертированная модель — актор с write-доступом к манифесту (человек ИЛИ агент, ADR 0036) **не удаляет, а ДОБАВЛЯЕТ/ЭСКАЛИРУЕТ**: почти вся soft-колонка soft именно потому, что аддитивна = это и есть направление атаки. Добавлены: (a) новый класс **`security-boundary` (severity 4, выше `data-migration`=3** — потеря данных покрывается restic-бэкапами, утёкший креденшл — нет; irreversible+uncoverable → бьёт primary в мульти-op правке); (b) **семь триггеров** #7–#13 (все `security-boundary`, все PAUSE-for-approval, ни один — не webhook-reject): #7 `env-secret-ref-add` (только `secret:`, `claim.*` self-scoped → soft), #8 `env-ref-downgrade` (ref→литерал), #9 `env-secret-ref-retarget` (secret→secret), #10 `network-visibility-escalation` (не-public→public), #11 `public-hostname-add` (любой новый public-хост в наборе), #12 `public-port-retarget` (смена public-порта), #13 `image-policy-relaxation` (`imagePolicy.resolve` off→не-off на плавающем теге; already-digest = no-op, `digest→off` = hardening/soft); `image-path-change` **переклассифицирован** requires-restart→`security-boundary`; (c) **rollup** `spec.risks.classifications[]` + drill-in `spec.changes[]` (каждый change: `type`/`field`/`classification`/`severity`/`from`/`to` — wire-поле триггера = **`.type`**, т.к. `MigrationChange.trigger` это `#[serde(rename="type")]`) — убивает approve-laundering (класс не может спрятаться за benign primary). **Три структурных фикса:** **S-4** — approve привязан к контент-хешу `spec.trigger.approvedSpecHash` (полный candidate-set, collision-free; approve-X-нельзя-apply-Y, re-gate при дрейфе; legacy-план без хеша всё ещё consume'ится); **S-1** — `applications/status` под webhook-защитой (только fieldManager `apprafter-operator` пишет `Application.status` → нельзя обнулить `lastAppliedSpec` baseline); **§7.2** — `spec.environment` immutable на UPDATE (флип env свопает всю эффективную спеку → laundering-вектор, режется на webhook до классификатора). **Tripwire** `needs.*.selector`: классификатор чистый (не читает кластер), но контроллер best-effort считает `ServiceProvider`'ов этого типа — если >1 → LOUD `error!` + Warning Event + `apprafter_soft_destructive_total` (list-tolerant, никогда не роняет reconcile). **Soft-observability:** `EventType::Warning` для трёх (`needs.*.selector`, env-литерал removal, scale-down N→M) + метрика `apprafter_soft_destructive_total{trigger,namespace}` на КАЖДЫЙ soft-op; `apprafter_claim_retained_total{backend,namespace}` заканчивает тихое создание RetainedClaim (review S-3 — метрика зашипилась, gate — нет, отдельный item ниже). **Live walk GREEN** (security-эскалация → план → `classifications` содержит `security-boundary` → approve → applied; S-4 stale-approval re-gates; S-1 status-patch отклонён; §7.2 env-флип отклонён; tripwire на 2 провайдерах; негативы не гейтятся). ADR 0052 + spec.md §3.8 (Revision 12→13) актуализированы; Argo health-Lua (`component_argocd.cue`) расширен drill-in'ом classifications+changes[]. **Отложено отдельными plan-items** (ниже): S-2 (authority-модель), S-3 (delete-finalizer), §5 (pre-registration новых полей), §10 (deny-by-default `@mp`).

**Контекст:** 2.16b (ADR 0051) закрыл ось «removal ломает running-сервис». Мотивирующая гейт угроза (ADR 0036) — **не** случайное удаление, а актор с manifest-write, который **эскалирует** (public-exposure, secret-refs, image-policy relaxation). Плюс review нашёл 3 структурных дыры, обезоруживающих сам гейт независимо от набора триггеров: (S-4) approve переносим между правками (сравнивался только `(trigger,field)`, не `from/to`), (S-1) `Application.status` не защищён (любой с `patch applications/status` обнуляет baseline), (§7.2) `spec.environment` мутабелен (флип свопает всю эффективную спеку).

**Поставка:**
- [x] Класс `security-boundary` (sev 4) + переклассификация `image-path-change`; `classification_severity` + `pick_primary`-тесты.
- [x] Триггеры #7–#13 (полная юнит-таблица + негативы: claim-ref add НЕ гейт, literal→literal НЕ гейт, non-public port НЕ гейт, `digest→off` НЕ гейт).
- [x] Rollup `classifications[]` + `changes[]` (+ 4 инварианта: primary∈changes; classifications=distinct(changes)-sorted; changes непусто ⟺ план создан; primary.severity=max).
- [x] S-4 `approvedSpecHash` (полный candidate-set, consume-time re-verify, re-gate при дрейфе) + regression-тест.
- [x] S-1 `applications/status` webhook rule + fieldManager-reject.
- [x] §7.2 `spec.environment` immutable-on-UPDATE (oldObject в валидатор).
- [x] Tripwire `needs.*.selector` (>1 провайдер → loud+event+метрика, list-tolerant) + инвариант-тест.
- [x] Warning-events для 3 soft-op + `apprafter_soft_destructive_total`; `apprafter_claim_retained_total` (S-3 observability).
- [x] Health-Lua drill-in (classifications badges + `changes[]` list, всё строками, nil-guards).
- [x] Live kind+Argo security walk (эскалация → план → approve; S-4/S-1/§7.2/tripwire/негативы).

**Acceptance:** эскалационная правка (`internal→public`+hostname, `secret:`-ref add, image-policy off→digest, image-repo change) → авто-план с классом `security-boundary`, `changes[]` несёт весь набор; approve снимает паузу; approve НЕ переносится на другую правку (S-4); status-обнуление не-оператором отклонено (S-1); env-флип отклонён (§7.2); `claim.*`-ref add / literal→literal / non-public-port / `digest→off` НЕ гейтятся.

**Зависит от:** 2.16b / ADR 0051 (машина классификатора + app-scope MigrationPlan), ADR 0046 (`claim.*` vs `secret:`), ADR 0036 (agent-модель угроз), 1.83 (expose/public), 2.4h (imagePolicy). **Связан с** [[project_argo_approval_surface]].

**Размер:** M-L · упрочнение (S-1/S-4/§7.2) + вторая ось классификатора + rollup. SR:A order 3.7.

---

#### 2.16b-sec-S2 — Approve-authority hardening (manifest-write ≠ approve)
> 🏁 SR: A · doc-first, отложено из 2.16b-sec §E — задокументировано в spec.md §3.8 (S-2), но **RBAC-scoping status-write требует ревизии**.

**Контекст:** SSA-fieldManager — это **метка владения, не токен аутентификации**. S-1 отклоняет `Application.status`-запись, если fieldManager ≠ `apprafter-operator`, но целостность этого держится только на RBAC: `patch applications/status` ДОЛЖЕН быть scoped на SA оператора, иначе другой subject предъявит тот же fieldManager. Авторитетный approve-путь — k8s `kubectl patch --subresource=status` (RBAC на MigrationPlan/status), Argo-кнопка — convenience поверх Argo-RBAC. Git-write в одиночку approve'ить не должен.

- [ ] Аудит + scoping RBAC: подтвердить, что `patch applications/status` и `patch migrationplans/status` даны ТОЛЬКО SA оператора (и approve-субъектам явно) — не широким ролям.
- [ ] Документировать authority-модель в operator-guide (write ≠ approve; кто может approve и через что).
- [ ] (открытое решение) рассмотреть userInfo-гейт как defense-in-depth поверх fieldManager, если найдётся subject с легитимным SSA под тем же менеджером.

**Зависит от:** 2.16b-sec (S-1 shipped). **Размер:** S · doc + RBAC-аудит.

---

#### 2.16b-sec-S3 — Application-delete finalizer (reattach-by-name gate)
> 🏁 SR: A · order 3.7+ — метрика `apprafter_claim_retained_total` зашипилась в 2.16b-sec, GATE — нет.

**Контекст:** удаление `Application` с `needs` НЕ гейтится: RetainedClaim создаётся тихо (теперь под метрикой), а reattach использует `cnpg::k8s_name(ns,name)` **без UID-проверки** → повторное имя re-адоптит данные в пределах 7-дневного grace → adoption-вектор. Метрика 2.16b-sec ends «тихое» создание, но не закрывает сам вектор.

- [ ] Finalizer на `Application`: при delete, если `spec.needs` непуст → создать `data-migration` MigrationPlan (gate до фактического GC/retain claim'а), по образцу app-scope ns/ownerRef/CLI (ADR 0051).
- [ ] Reattach-by-name: UID-check или explicit-adopt подтверждение, чтобы same-name не re-адоптил чужие данные молча.
- [ ] Юнит + walk: delete app с needs → план создан → approve → GC; reattach другого app с тем же именем → не тихая адопция.

**Зависит от:** 2.16b-sec (метрика), 2.4f (RetainedClaim/GC), ADR 0051 (scope-паттерн). **Размер:** M.

---

#### 2.16b-sec-S3-approver — Named non-admin approver role (managed-track)
> 🏁 SR: C · deferred → Tier-2/managed. Сегодня T1 approve'ит через admin-CLI (`apprafter migration approve`, полный kubeconfig) ЛИБО Argo-кнопку (пишет phase-only под RBAC контроллера Argo). Отдельной approve-роли ещё нет.

**Контекст:** approve деструктивной правки сейчас требует ЛИБО admin-уровня доступа (полный kubeconfig → CLI пишет `migrationplans/status`), ЛИБО клика в Argo (действие пишет только `status.phase`, F-1b-совместимо, под RBAC-контроллера Argo — см. S-2). Для managed/multi-tenant нужен **именованный не-admin subject**, который может approve, НЕ имея прав на всё остальное. N-3 (surface hash re-gate to user) уже делает re-gate видимым approve'еру без operator-log — но сам approve-субъект в managed-потоке ещё не смоделирован.

- [ ] Named ClusterRole `apprafter:migration-approver` — verbs: `patch migrationplans/status` (сам approve — flip phase pending-approval→approved) + `get`/`list migrationplans` (увидеть, что approve'ить). Никаких прав на `applications`/`applications/status`/child-ресурсы.
- [ ] Binding-решение: **Argo-SA vs люди**. Argo-кнопка пишет под controller-RBAC Argo (не под ролью юзера) — привязать роль к Argo-SA ИЛИ к человеческим subject'ам напрямую (для CLI-approve без полного kubeconfig)? Вероятно оба, но с разными bindings (namespaced RoleBinding для tenant-scoped approve).
- [ ] Multi-tenant / outbound-agent approve-путь: клиент managed-плана approve'ит через hosted-UI / MCP / `apprafter-agent` (ADR 0031/0036) — та же роль+webhook (S3-attribution) ИЛИ отдельная agent-identity? (см. открытый вопрос ниже.)

**Открытый вопрос (общий для S3-approver + S3-attribution):** managed-plan approve-путь — клиент через hosted UI / MCP / outbound-agent: одна и та же `migration-approver` роль + attribution-webhook, ИЛИ отдельная agent-identity, отличимая от человека? Через Argo identity — это Argo-SA, а не реальный человек/агент; для managed это надо развести.

**Зависит от:** 2.16b-sec (S-2 authority-модель), ADRs 0034–0038 (managed-track), ADR 0031 (outbound-agent). **Размер:** S-M · роль + binding-решение + managed-approve-путь. SR:C (managed).

---

#### 2.16b-sec-S3-attribution — Approve-attribution webhook (`approvedBy`/`approvedAt`)
> 🏁 SR: C · deferred → managed approve-flow, где реальная identity человека/агента имеет значение. Сегодня approve не атрибутируется (кто approve'ил — не пишется).

**Контекст:** при переходе `pending-approval → approved` мы не фиксируем, КТО approve'ил. На T1 это неважно (approve = admin с полным доступом). В managed-потоке (клиент approve'ит через hosted-UI/MCP/agent) реальная identity approve'ера — аудит-критична.

- [ ] Mutating webhook на `migrationplans` UPDATE: при `pending-approval → approved` штампует `status.approvedBy` / `status.approvedAt` из `request.userInfo` (username/uid/groups) — не доверяя клиентскому телу.
- [ ] Рендер `approvedBy`/`approvedAt` в Argo health-Lua (узел MigrationPlan показывает, кто approve'ил + когда), рядом с существующими upgrade-* аннотациями (ADR 0048).
- [ ] **Открытый вопрос (см. S3-approver):** через Argo-кнопку `request.userInfo` — это Argo-SA, а не человек, кликнувший в UI. Для реальной attribution в managed нужен либо approve НЕ через Argo-controller-identity, либо проброс user-identity из hosted-UI в webhook. Развести до managed-launch.

**Зависит от:** 2.16b-sec-S3-approver (approve-субъект), 2.16b-sec (S-2), ADR 0048 (Argo health-Lua render-паттерн), ADRs 0035–0036 (Minimal Data Exposure / MCP agentic-safety). **Размер:** M · mutating webhook + Lua-render + identity-проброс. SR:C (managed).

---

#### 2.16b-sec-S5 — Pre-registration новых полей в таксономию (каждое — с gate-решением)
> 🏁 SR: A · «each must land WITH a gate decision» — новые/растущие поля схемы не должны попадать в gate-слепую зону.

**Контекст:** несколько полей ещё не классифицированы (нет ни gate, ни явного soft-решения) — при добавлении/изменении проходят без разбора. Каждое надо явно отнести к hard/security/soft ПРИ приземлении соответствующего поля.

- [ ] `connects.egress.external` (изменение egress-allowlist) — gate-решение.
- [ ] `expose.rewrites` / `expose.paths` (path-роутинг) — gate-решение.
- [ ] `expose.tls` → `#TlsOptions` (когда 4.1b раскроет полный TLS) — gate-решение.
- [ ] `confidential: true → false` (де-эскалация конфиденциальности) — вероятно `security-boundary`.
- [ ] `egressIP.pool` (смена исходящего IP) — gate-решение.
- [ ] `needs.*.version` major (major-upgrade сервиса) — вероятно `data-migration`/`breaking`.
- [ ] `needs.disk.class` (смена storage-класса) — вероятно `data-migration`.

**Зависит от:** 2.16b/2.16b-sec (таксономия), приземление соответствующих полей (1.83/4.1b/2.4). **Размер:** S каждое · чекбоксы-заметки в соответствующих plan-items.

---

#### 2.16b-sec-S10 — Deny-by-default `@mp` CUE-атрибут + CI-coverage-gate
> 🏁 SR: A · **ADR-first** — архитектурный сдвиг: каждое поле схемы обязано нести явный `@mp(...)` классификатор, иначе CI падает.

**Контекст:** сейчас таксономия — allowlist в коде классификатора; новое поле схемы по умолчанию **не** классифицировано (slip-through, см. S5). Deny-by-default: `@mp` на КАЖДОМ поле `schemas/v1alpha1/**` (`gate`/`soft`/`security` + класс) + CI-гейт, проверяющий 100%-покрытие полей атрибутом — новое поле без `@mp` роняет CI, заставляя принять gate-решение до merge.

- [ ] ADR: модель `@mp`-атрибута (значения, семантика, как классификатор его читает vs хардкод-таблица).
- [ ] `@mp(...)` на всех полях `schemas/v1alpha1/**`.
- [ ] CI-coverage-gate: каждое поле схемы несёт `@mp` (иначе fail).
- [ ] (опц.) классификатор читает `@mp` как источник истины вместо/поверх хардкод-таблицы.

**Зависит от:** 2.16b/2.16b-sec (таксономия), ADR 0047 (CUE как единственный источник схемы). **Размер:** L · ADR + туча аннотаций + CI-гейт.

---

#### CLI-hardening A — эфемерный kubeconfig (`apprafter kc` TTL)
> 🏁 SR: B (pull-up, ДО 1.0 / публичного OSS-релиза) — **гигиена креденшла, НЕ agent-defense.** Как только `kc` начинают вызывать чужие люди на чужих машинах, вечный cluster-admin-kubeconfig в профиле становится их проблемой (забытый файл) — без всякого агента. Откладывать до MCP неправильно. (Происхождение: разбор в ходе ревью S3, вышло за scope таблицы деструктивных операций.)

**Контекст:** всё в 2.16b/2.16b-sec защищает путь **git→cluster** (`spec.md` §3.8). Локальный слой «рабочая станция + артефакты CLI» сейчас без владельца. `apprafter kubeconfig` (alias `kc`, `cli.rs:133`) SSH-фетчит `/etc/rancher/k3s/k3s.yaml` (кешируется age-шифрованно, 1.3).

**A.0 (УСТАНОВЛЕНО в S3 — природа креденшла, делать выводы отсюда):** это **статический k3s admin CLIENT-СЕРТИФИКАТ** (`client-certificate-data`), НЕ SA-JWT (подтверждено `cli-providers/hetzner_cloud/kubeconfig.rs`; тест-фикстура `client-certificate-data: …`). ⇒ короткий TTL — НЕ параметр `expirationSeconds`, а **выбор ветки**:
- (a) ре-платформить `kc` на **TokenRequest API**: создать (один раз) cluster-admin SA + ClusterRoleBinding, на каждый `kc` — TokenRequest (`spec.expirationSeconds`) → собрать kubeconfig вокруг короткого токена + cluster CA + server URL. Размер **S–M** (меняет природу вывода: static-cert → эфемерный token; потребители kubeconfig с token работают). **Рекомендация — эта ветка, «do it right».**
- (b) короткоживущие client-cert'ы из k3s CA — отдельный процесс выпуска. Размер **M–L**.

Из-за (a)/(b) TTL «качественно + быстро» inline НЕ делается → пункт до 1.0, не сразу.

**Поставка:**
- [ ] A.1 — короткий TTL по умолчанию (ориентир 1–4ч; точное значение — по реальной длительности сессий при имплементации; хуже всего «бессрочно»).
- [ ] A.2 — флаг `--duration` (длинная сессия; верхняя граница есть, но не жёсткая). **Флаг НЕ ослабляет модель:** кто может вызвать `kc`, продлевает повторным вызовом, а не флагом — влияет только на удобство человека.
- [ ] A.4 — acceptance: `kc` без флагов → короткий TTL, факт истечения проверяется в тесте (после истечения запрос **отвергается API-сервером**, не «поле выставлено»); `--duration` работает; `spec.md`/docs фиксируют эфемерность + как получить новый.

**Побочный эффект (важно для Item B):** короткий TTL закрывает и «забытый kubeconfig», и бОльшую часть «агент утащил артефакт из профиля» (протухший kubeconfig неопасен независимо от того, кто прочитал) ⇒ если `kc` эфемерен, шифрование профиля (B.4) перестаёт быть приоритетом.

**Зависит от:** нет. **Размер:** S–M (ветка a) / M–L (ветка b) — см. A.0. **Открытый вопрос:** JWT-vs-client-cert РЕШЁН (client-cert); конкретный дефолтный TTL — по реальным сессиям.

---

#### CLI-hardening B — agent-aware CLI hardening
> 🏁 SR: C (managed / **MCP** — заявляется, когда заявляется агентная поверхность; тогда же и защиты). Дифференциатор #3 = **MCP-native agentic safety** ⇒ «как CLI ведёт себя под агентом» — часть продукта (показуемая в README/лендинге), а не внутренняя практика. (Происхождение: ревью S3.)

**Контекст:** локальный агент (Claude Code на машине оператора) в путь git→cluster НЕ входит: тот же UID, тот же kubeconfig, за спиной у всех кластерных контролов — для API-сервера это оператор. Ни один admission-webhook его не видит.

**B.0 (модель противника — записать ДО имплементации, иначе бесконечное упрочнение):**
- **Non-goal:** решительный противник с исполнением кода под UID оператора (`kc` даёт cluster-admin, keyring разблокирован, PATH пишется, PTY аллоцируется) — не сдерживаем.
- **Цель:** агент, делающий ОЧЕВИДНОЕ — зовёт `apprafter migration approve`, т.к. это следующий разумный шаг. Против него дешёвые контролы работают почти идеально.
- **Явный non-goal:** шифрование артефактов профиля с ключом, доступным тому же UID (обфускация, не защита; имеет смысл ТОЛЬКО через системный keyring — B.4).

**Поставка:**
- [ ] B.1 — TTY-жест на деструктивных командах: промпт из **`/dev/tty`** (не stdin → отсекает пайп/редирект; обход = PTY-обвязка = вне B.0); **дефолта нет** (пустой Enter = отказ, т.к. ввод не совпал, а не «дефолт no»); `--yes`/`--force` НЕ существуют; ввод простой (`yes`), одинаковый для всех scope. **Защита — в КАНАЛЕ (`/dev/tty`), не в содержании ввода** (уникальная строка/хеш копируется процессом дешевле, чем набрать `yes`, + создаёт ложное свидетельство «аппрувящий видел план»). Дешёвая проверка: поведение `inquire` при не-TTY stdin (возможно, половина уже есть).
- [ ] B.2 — `migration approve`: весь `spec.changes[]` (не только primary — иначе rollup §1.2 не доезжает до места решения) + `classifications[]` видимо+различимо; TTY-жест; показать хеш аппрува (для ОТОБРАЖЕНИЯ, не ввода — «что показали»=«что аппрувили»). Зависимость (зафиксировать явно): промпт рендерит план, доверяет ПЛАНУ а не манифесту (закрыто approvedSpecHash+F-1b).
- [ ] B.3 — `apprafter kc`: TTY-жест (kc даёт cluster-admin → обходит approve; замок на approve при свободном kc бессмыслен). Ортогонален Item A: TTL ограничивает срок артефакта, жест — его выдачу; оба нужны.
- [ ] B.4 — профиль + keyring: оценивать ТОЛЬКО после Item A (если kc эфемерен — ценной цели в профиле нет). Если долгоживущее осталось — шифровать ТОЛЬКО с ключом в системном keyring (обход → keyring API → возможен GUI-промпт, B.7). Ключ рядом с файлом / под тем же UID вне keyring — НЕ делать.
- [ ] B.5 — ревизия деструктивных команд: один проход по всему CLI (`app remove`, claim-операции, всё сносящее/переконфигурирующее) → список → решение по каждой (жест/оставить). Иначе гейт на approve, а рядом команда без плана.
- [ ] B.6 — `approvedVia`: `cli-tty` (жест был) / `cli-noninteractive` (жеста не было — ЭТО сигнал «процесс, не человек») / `argo`. `cli-forced` не нужен (нет `--yes`). Проверить: если FSM уже пишет `conditions[].lastTransitionTime` на переход в `approved` — «когда» уже есть, остаётся «каким путём».
- [ ] B.7 (горизонт, НЕ в этом item'е) — GUI-жест: текстовый канал имеет потолок (любая копируемая строка копируется процессом); выше — жест мимо stdout/stdin (GUI keyring-промпт, focus-loss lock, hardware touch). Ложится на `apprafter-core` + Tauri-портал (уже спланировано), новой архитектуры не тянет.
- [ ] B.8 — acceptance: `echo yes | apprafter migration approve <plan>` НЕ аппрувит; approve без TTY = отказ (не зависание); полный `changes[]`+классы до промпта; `--yes`/`--force` отсутствуют (тест на surface команд); `kc` требует жеста; `approvedVia` различает `cli-tty`/`cli-noninteractive`.

**Зависит от:** Item A (объём B.4), `apprafter-core` (общий домен CLI/GUI/портал), 2.16b-sec (rollup/approvedSpecHash — B.2), ADR 0036 (MCP agentic-safety). **Размер:** M. **Продуктовое:** довести до показуемого (README/лендинг) — конкуренты этот слой не ставят (у imperative-PaaS агент дёргает API напрямую, вопрос «а если агент решил лишнего» там не поставлен).

---

### 2.16b-sc — SourceCredential-scope MigrationPlan wiring
> 🏁 SR: A · order 3.7 (следом за 2.16b — тот же «флип», другой scope) — включить live-создание MigrationPlan при деструктивной правке `SourceCredential` (ре-анкор co-отложенного 1.79c S5).
> ✅ **ЗАКРЫТО 2026-08-07** (order-3.7, SR:A; spec `docs/superpowers/specs/2026-08-07-2.16b-sc-design.md`, ветка `feat/2.16b-sc`). Live-создание MigrationPlan при деструктивной правке `SourceCredential` ВКЛЮЧЕНО — «тот же флип, другой scope» поверх 2.16b (ADR 0051). Добавлен **новый scope-вариант `sourcecredential`** дискриминатора MigrationPlan (kube-rs тип + OpenAPI CRD + CUE schema + webhook-валидатор + approve-only phase-rule), `SourceCredentialStatus.lastAppliedSpec` (preserve-unknown baseline для diff'а), и **общая consume-ticket state machine хойстнута в `operator-core`** (`decide`/`plan_state`/`MigrationDecision`/`PlanState`/`plan_hash_matches` — реюз verbatim обоими контроллерами, ноль клонирования; app-scope тесты прошли без правок). Coverage-narrowing (удаление `git.repoPrefixes` / `registry.hosts` при матчащемся приложении, `detect_destructive`→`coverage-removal`/`breaking`) → `create_plan_for` создаёт `sourcecredential`-scope план в **namespace самого credential'а** + controlling ownerRef→SourceCredential CR (каскад GC), **паузит ОБЕ половины derivation** (старые wider-coverage repo-creds + pull-secret не трогаются → in-flight аппы сохраняют доступ), consume на approve (re-derive narrowed + GC непокрытого). **Approve-only** (reject через webhook заблокирован; откат = re-widen спеки → нет деструктив-дельты → `DeleteThenRender` GC'ит устаревший план; `previous_spec_snapshot=None`). Actor-agnostic (raw `kubectl edit` тоже триггерит). CLI `migration list`/`approve` scope-agnostic (без hard-assume `scope.application`); `repo creds remove` reverse-dep gate оставлен как комплементарный best-effort UX. **kind+podman walk (`e2e/sourcecredential-migration-walk.sh`) GREEN end-to-end** (register SC → app матчится → удалить covering host → авто-план в cred-ns + ОБЕ derivation паузятся [старые Secret'ы целы] + Argo-clickable + `migration approve` резюмит+GC'ит; + kubectl-edit actor-agnostic вариант). **Закрывает 1.79c acceptance #4.** **Релиз:** operator+webhook charts v0.2.35→**v0.2.36**, cue-cmp 0.1.16→**0.1.17** (`schemas/v1alpha1/{migrationplan,sourcecredential}.cue` изменились), platform-stack currentVersion 0.2.44→**0.2.45** (compatibility change=safe, operatorVersion v0.2.36), cli 0.2.34→**v0.2.36** (Task 8 тронул `migration`/`repo creds` бинарь; 0.2.35 был operator-only → пропущен в cli-стриме; monorepo tag v0.2.36 local). 2.16b-sc ≠ Phase closure (order-3.7 pulled-up; §6-бокс не трогается).

**Контекст:** 1.79c S5 поставил классификатор `SourceCredentialMigrationStrategy::detect_destructive` (coverage-removal / drop-half → `breaking`, 7 тестов), но **live plan-creation co-отложил** «с application-scope live-wiring (B.1.77 флип)» (`plan.md §1.79c` S5). 2.16b ЕСТЬ этот флип — но он включает только **application**-scope. SourceCredential-scope — отдельный **новый scope-вариант** дискриминатора MigrationPlan (не «раскомментировать один call-site»): нужны свои mirror'ы ns/ownerRef/webhook-form/CLI по образцу application-scope (ADR 0051) + врезка в SourceCredential reconciler. Пока этого нет, удаление покрытия репо/реестра проходит без гейта (derived pull-secret передеривается под reverse-dep gate CLI `repo creds remove` из S4; полного end-to-end gating нет).

**Цель:** `sourcecredential`-вариант MigrationPlan-scope + live-создание плана в SourceCredential reconciler, когда ротация/удаление credential деструктивно (coverage-removal при матчащихся приложениях), паузя derivation до approve.

**Поставка:**
- [x] Scope-вариант `sourcecredential` в MigrationPlan (kube-rs тип + OpenAPI CRD + CUE schema + admission `validator_migrationplan.rs` — required-fields per scope, как application/platform).
- [x] `create_plan_for` для SourceCredential: план в namespace SourceCredential CR (или release-ns) + controlling ownerRef на SourceCredential CR (same-ns GC-safe, паттерн ADR 0051); webhook-valid form; `previous_spec_snapshot` по семантике reject (approve-only vs revert — решить, зеркалит ли application-scope). → approve-only (mirror app-scope), `previous_spec_snapshot=None`.
- [x] Врезка `detect_destructive` (уже есть) в SourceCredential reconcile loop → авто-создание плана + пауза derivation derived Secret'ов до `completed`; consume-ticket по образцу 2.16b (approve → apply → delete plan). Паузятся ОБЕ половины; state machine хойстнута в operator-core.
- [x] CLI `migration list` уже cluster-wide (2.16b) — подтвердить, что sourcecredential-план видим; approve-путь тот же.
- [x] Live walk: убрать registry-host из покрытия CR при матчащемся приложении → авто-план + derived pull-secret не трогается до approve (закрывает 1.79c acceptance #4).

**Acceptance:** удаление covering repo-prefix / registry-host, пока приложение матчится → авто-создаётся `sourcecredential`-scope MigrationPlan, derivation паузится, план виден+кликабелен + `apprafter migration approve` снимает паузу; ротация на эквивалентный валидный credential проходит без гейта.

**Зависит от:** 1.79c S5 (классификатор + актор-agnostic detect), 2.16b / ADR 0051 (scope-вариант ns/ownerRef/webhook-form/CLI-паттерн для реюза), 1.76-1.78 (MigrationPlan + контроллер). **Связан с** [[project_1_79c_sourcecredential]].

**Размер:** S-M · классификатор готов; масса — новый scope-вариант (4 hand-rolled mirror'а: kube-rs/OpenAPI/CUE/admission) + reconciler-врезка + walk. SR:A order 3.7.

---

### 2.16c — Per-environment partial override для struct-полей (deep-merge `expose`)
> 🏁 SR: A — устранить асимметрию base↔override: env должен нести только diff, а не полную копию struct-поля. Surfaced дегфудингом launch-лендинга (procvue/landing) — есть обходной костыль, не hard-блокер.
> ✅ **ЗАКРЫТО 2026-08-08** (order-3.7, SR:A; spec `docs/superpowers/specs/2026-08-07-2.16c-deep-merge-struct-fields-design.md`, ветка `feat/2.16c-deep-merge-struct`). Per-environment override `expose`/`imagePolicy` теперь **частичный** (deep-merge по подполям, override-wins): env несёт только diff, env-инвариантные подполя (`expose.port`) наследуются из `base` — дублирование порта в env-override больше не требуется. Новый all-optional тип **`#ApplicationEnvOverride`** бэкает `environments[*]` (CUE + Rust `ApplicationEnvOverride`/`ExposeOverride`); `base` остаётся `#ApplicationSpec` с обязательным-when-present `expose.port`, поэтому «забыл порт в base» ловится локально `cue vet`. Оператор `effective_spec` мёржит по подполям и теперь **fallible** (base-отсутствует + env-only `expose` без порта → `Ready=False`/`InvalidEffectiveSpec`, ничего не применяется — `Err` обрабатывается ДО `detect_all`, не пропускает миграционный гейт «применив что-то»); webhook инфорсит «env-only `expose` (нет `base.expose`) обязан нести `port`»; `crd-check` получил рекурсивный `#ApplicationEnvOverride ⊇ #ApplicationSpec` drift-gate + assertion «в сгенерированных CRD нет OpenAPI `default:`». Унаследованные `expose.hostname`/`tls` потребляются только под `network: "public"` (иначе inert). **`needs.*` deep-merge ВЫДЕЛЕН в новый item 2.16i** (OneOrMany-merge undefined + partial-override меняет имя ResourceClaim → GC → пустая БД = data-loss + reopen 2.4d selector-gate — своя миграционная аналитика). Self-correction: тест `effective_spec_env_override_replaces_expose_block` инвертирован под deep-merge. **kind LOCAL-BUILD walk `e2e/expose-deep-merge-walk.sh` GREEN.** change=requires-restart (на апгрейде partial-`public`-override без hostname наследует base-hostname → live 2.16b destructive-gate фаерит → app паузится на `AwaitingMigrationApproval` до аппрува; две compat-заметки: hop-через-0.2.34 не стампит baseline → гейт не фаерит на первом reconcile; НЕТ даунгрейда ниже этого релиза после записи partial `environments[*].expose`). spec.md §3.1/§4.4 (Revision 13→14) актуализированы. **Релиз:** operator + admission-webhook charts v0.2.36→**v0.2.37**, cue-cmp 0.1.17→**0.1.18** (`schemas/v1alpha1/application.cue` изменилась), platform-stack currentVersion 0.2.46→**0.2.47** (compatibility change=requires-restart, operatorVersion v0.2.37); НЕ CLI, нет monorepo tag (манифест-семантика чисто in-cluster). 2.16c ≠ Phase closure (order-3.7 pulled-up; §6-бокс не трогается).

**Контекст (находка 2026-06-15, dogfood landing):** ожидание «общее пишем в `base`, в окружении переопределяем только то, что реально отличается» выполняется почти для всех полей — `image`/`replicas`/`imagePolicy` наследуются (replace-if-set), `env`-мапа и `needs` deep-merge'атся (ключи base выживают). НО **`expose` (struct) заменяется ЦЕЛИКОМ**: `effective_spec` (`operator-rendering/src/lib.rs:233-235`) делает `if env_override.expose.is_some() { effective.expose = env_override.expose.clone() }`. Плюс на CUE-слое `environments?: [string]: #ApplicationSpec` (тот же тип, что base; `application.cue:30`) — `expose?.port` обязателен-когда-`expose`-присутствует, без cross-inheritance. Итог: чтобы в `dev` поменять только `expose.network: "internal"`, юзер ВЫНУЖДЕН переписать весь expose, включая env-инвариантный `port` (порт контейнера — он не меняется от окружения к окружению). То же касается `imagePolicy` (тоже struct, тоже wholesale-replace). Костыль на landing (дублирование `port` в `dev.expose`) — оставлен временно; DRY достижим и сейчас CUE-композицией (вынести инвариант в скрытое поле), но это не то, что должна давать base↔override-модель.

**Цель:** per-environment override struct-полей становится **частичным** (deep-merge по подполям, override-wins) — env несёт только diff; инвариантное наследуется из base. Драйвер — `expose`; `imagePolicy` разрешить в том же духе (или явно задокументировать, если оставляем wholesale — решить в spec).

**Механизм (три согласованных части, по образцу уже сделанной релаксации `image` v0.1.42 — CUE ослаблен, инвариант в CRD/webhook):**
- [x] **Оператор:** `effective_spec` мёржит `expose` по подполям (`port`/`network`/`hostname`/`tls` — override-wins per field), а не целиком; тест `effective_spec_env_override_replaces_expose_block` → deep-merge-тест; решить то же для `imagePolicy`. (Реализовано через all-optional `#ApplicationEnvOverride`/`ExposeOverride` + per-field merge fns; `effective_spec` теперь fallible — env-only `expose` без порта → `InvalidEffectiveSpec`; `imagePolicy` тоже deep-merge.)
- [x] **CUE:** `expose.port` → `port?` (опциональный) в `#ApplicationSpec`, чтобы частичный `environments[*].expose` экспортировался (`cue export` больше не требует конкретный port в env-override). Schema-change ⇒ cue-cmp пересобирает (bundle `schemas/v1alpha1`). (Финально: `base` держит `#ApplicationSpec` с обязательным `expose.port`; частичность несёт отдельный all-optional `#ApplicationEnvOverride` — «забыл порт в base» ловится `cue vet`; cue-cmp 0.1.18.)
- [x] **Webhook:** кросс-полевой инвариант «у **эффективного** expose есть `port`» — `port` присутствует в `base.expose` ИЛИ в каждом переопределяющем `environments[*].expose` (ровно как существующее правило «image в base ИЛИ в каждом env»). Не даём смёржиться в expose-без-порта.
- [x] **Walk:** манифест с `base.expose:{port,network:public,hostname}` + `environments.dev.expose:{network:"internal"}` (только diff) → cue-cmp экспортит, оператор рендерит dev с `port` из base + internal (без публичного route), prod наследует публичный expose. Подтвердить на kind. (`e2e/expose-deep-merge-walk.sh` GREEN на kind LOCAL-BUILD.)

**Acceptance:** в манифесте можно написать `environments.dev: expose: network: "internal"` (без `port`/`hostname`) → валидно (cue-cmp + webhook), и dev-деплой получает `port`/`tls` из `base.expose`, переопределив только `network`. Дублирование env-инвариантных полей больше не требуется.

**Зависит от:** 2.9 (per-env модель), 2.12 (env-value-модель + релаксация-через-webhook прецедент), webhook image-rule (образец кросс-полевого инварианта). **Релиз:** operator + webhook + schema ⇒ cue-cmp bump + platform-stack bump + operator-chart appVersion (НЕ CLI — манифест-семантика чисто in-cluster).

**Размер:** M · оператор deep-merge — мелочь; основная масса — schema-relax + webhook effective-invariant + CRD-regen + walk. Сам wholesale→deep-merge касается осмысления base↔override в целом (struct-поля), в русле замысла 2.9.

---

### 2.16d — Resource requests baseline: seed-or-explicit + backends + LimitRange
> 🏁 SR: A — ни один под не BestEffort (safety baseline); live T1 prod (Hetzner cpx22, ~788Mi headroom, no swap; замер 2026-06-17: kubepods ws ~1.07G / k3s.service ~1.5G) сейчас весь BestEffort. Хочет раннего слота — перенести при желании.

> ✅ **ЗАКРЫТО 2026-08-08** (order-3.7, SR:A; ADR **0053** + re-spec `docs/superpowers/specs/2026-08-08-2.16d-resource-baseline-respec.md` + замер `docs/measurements/2.16d-baseline-2026-08-08.md`, ветка `feat/2.16d-resource-baseline`). Ни один под (платформа или приложение) не BestEffort — QoS выбран по роли из **реального замера solo-узла** (Hetzner solo-tier, ~4GB, published ps 0.2.47; не cpx22/8GB — замер поправил допущение спеки). **Поставка:** (1) новое поле **`resources`** на `Application` (base + per-env на `#ApplicationEnvOverride` из 2.16c) с **deep-merge MAP-of-map** — `requests`/`limits` мёржатся независимо по ключу (env-override `limits.memory` НЕ роняет base `limits.cpu`; образец — merge `env`, не struct); (2) **app-seed Burstable** измеренный (`requests {cpu:25m, memory:32Mi}`, `limits {memory:512Mi}`, БЕЗ cpu-limit) — щедрый-но-**присутствующий** memory-limit (отсутствующий ломает render-детерминизм 2.4e / T2-well-formedness / local↔in-cluster parity 2.12; низкий 128Mi детерминированно OOMKill'ит Node/JVM/Python); явный `spec.resources` уважается дословно (override-wins, seed только когда опущено); (3) **backends Guaranteed** (`requests==limits`) с когерентными DB-параметрами — CNPG 256Mi + `shared_buffers=32MB` + ephemeral-storage; Dragonfly 320Mi + `--maxmemory=256mb` (оба ниже cgroup-limit); замер ассертит `status.qosClass==Guaranteed` на живом поде (init-контейнер без resources молча демоутит); (4) **platform-stack requests/limits** на всех компонентах (argocd/cilium/cert-manager/cnpg-op/dragonfly-op/cue-cmp-sidecar + добавлен отсутствовавший limit на sealed-secrets → был requests-only BestEffort) из таблицы замера; (5) **node-резервации** (`system-reserved=1500Mi` под out-of-`kubepods` `k3s.service` в `system.slice` / `kube-reserved=256Mi,100m` / `eviction-hard<100Mi` / `OOMScoreAdjust=-999`) в CLI/k3s-installer на bootstrap + **retrofit-команда `apprafter node reserve-headroom`** (SSH + config + `systemctl restart k3s`, ~30s API-outage за confirmation-prompt); (6) **webhook** `validate_resources` (валидность quantity через `is_k8s_quantity` + `request <= limit` по ключу с реальным сравнением quantity). **No PriorityClass** (ядро OOM-score QoS-derived, не priority-derived); **LimitRange ОТЛОЖЕН** до Capsule policy-layer (ResourceQuota делает его обязательным) — deviation от исходного deliverable, рендерер+provisioner покрывают каждый AppRafter-owned под и так удовлетворяют acceptance; **VPA-vs-backends non-goal** записан в ADR (VPA реверсит pod-level правки на CNPG/Dragonfly CR → backend right-sizing = recommendation-only в `ServiceProvider.spec.config`, тема 2.16e). **D2 budget-close ЗАКРЫВАЕТСЯ** на ~4GB solo-узле с запасом (allocatable после резерваций ~1958Mi > platform-requests ~800Mi + backend-Guaranteed 576Mi + app-seed 32Mi ≈ 1408Mi) — ladder не понадобился (без pull-forward 2.16f, без подъёма T1-минимума, без trim компонентов). spec.md §3.1/§4.5/§4.12 (Revision 14→15) актуализированы; ADR 0053 записан. **Релиз:** operator + admission-webhook charts + schema + platform-stack + **CLI** (installer-половина = node-резервации → CLI bump + monorepo tag, в отличие от 2.16c) — версии: op/wh **v0.2.38** / cue-cmp **0.1.19** / ps **0.2.48** / cli **0.2.38**; compatibility change=`requires-restart` (retrofit = k3s restart, re-render добавляет limits → роллит поды). 2.16d ≠ Phase closure (order-3.7 pulled-up; §6-бокс не трогается).

**Контекст:** реквесты не настроены (давний near-term gap). Все поды — app Deployments, `platform-postgres-1` (CNPG-инстанс), Dragonfly — BestEffort QoS. Под memory pressure ядро может OOM-killнуть stateful Postgres так же легко, как контроллер: нет QoS-приоритета. Stateful backend под ножом — худший исход (OOM посреди записи).

**Цель:** ни один под не BestEffort; контейнер приложения и backends получают requests/limits по умолчанию; явный override для тех, кто точно знает (pro-mode).

**Поставка (рендерер — чистая функция; override-wins по образцу `image`):**
- [x] `operator-rendering` эмитит блок `resources` на контейнере приложения. Default seed = **Burstable: low memory/cpu request + memory limit**. NB: «limit-only» НЕ вариант — limit без request авто-выставляет request=limit (это уже не BestEffort и резервирует весь limit); нужен явный низкий request + потолок-limit. Asymmetry: memory request щедро (incompressible → не OOM), CPU скромно (compressible → throttle, не kill). Seed **runtime-agnostic** консервативный (runtime-detector отвергнут как хрупкий для прода; наблюдение из 2.16e поправит точнее, чем угадывание по рантайму).
- [x] **Pro-mode:** если `Application.spec.*.resources` задан юзером — берётся дословно (override-wins); seed применяется ТОЛЬКО когда поле опущено. Per-env merge (как `expose`/`needs`).
- [x] **Backends:** provisioner проставляет `resources` в CNPG `Cluster` CR и Dragonfly CR (они тоже BestEffort; stateful Postgres — самый опасный). Tier-aware дефолт (как CNPG `instances`).
- [~] **LimitRange** per tenant namespace (`defaultRequest`/`default`/`min`/`max`) — catch-all backstop для всего, что рендерер не владеет (jobs, raw-поды). Платформенный chart. **→ ОТЛОЖЕН до Capsule policy-layer** (ADR 0053: LimitRange обязателен только рядом с ResourceQuota; рендерер+provisioner покрывают каждый AppRafter-owned под и так удовлетворяют acceptance «ни один под не BestEffort»).
- [x] CRD-additive: опциональное `resources` на Application spec; `just crd-validate`.
- [x] Live walk: апп без `resources` → под **Burstable** (assert `kubectl get pod -o jsonpath='{.status.qosClass}'` ≠ BestEffort); апп с явным `resources` → дословно; CNPG/Dragonfly поды не BestEffort.

**Acceptance:** ни один под платформы/приложений не BestEffort; явный `resources` уважается verbatim; stateful backends (Postgres/Dragonfly) имеют QoS-приоритет выше новых/stateless ворклоадов.

**Зависит от:** 2.4 (provisioner — для resources на backend CR), 2.9 (per-env merge), webhook image-rule + 2.12 (образец override-wins / schema-relax-через-webhook). **Релиз:** operator + webhook + schema ⇒ cue-cmp bump + platform-stack bump (манифест-семантика чисто in-cluster, CLI вряд ли — как 2.16c).

**Размер:** M · seed + pro-override в рендерере — основная масса; LimitRange + backend resources — мелочь.

---

### 2.16e — Vertical autoscaling через VPA (InPlaceOrRecreate)
> 🏁 SR: A · после 2.16d — авто-коррекция requests по наблюдаемому usage; seed из 2.16d закрывает только safety, не over/under. Постоянный движок (дневные/недельные пики), не разовый bootstrap.

**Контекст:** seed из 2.16d консервативен — safe, но переплачивает; over/under для произвольных аппов закрывает только наблюдение. На t=0 данных нет ни у кого (ни VPA, ни любой stats-engine), поэтому seed + bootstrap-окно неизбежны → VPA берёт верх после накопления истории (~24-48h до осмысленной rec, неделя+ до cyclic-aware). **Adopt VPA, НЕ строить recommender** — decaying histogram (затухание, cross-restart, percentile, по памяти не ниже peak) зрелый; «do it right once». Дифференциатор — путь применения (in-place / GitOps-clean), не алгоритм.

**Предусловия (✅ закрыты на T1):** k8s v1.35.5 (in-place resize GA, без feature gates), containerd 2.2.3 (≥2.0 для UpdateContainerResources CRI), cgroup v2. → `InPlaceOrRecreate` без рестарта снимает single-node eviction-возражение.

> ✅ **ЗАКРЫТО 2026-08-10** (order-3.7, SR:A; спек `docs/superpowers/specs/2026-08-08-2.16e-vpa-design.md` (4 раунда внешнего ревью + adversarial), план `docs/superpowers/plans/2026-08-08-2.16e-vpa-autoscaling.md`, **ADR 0054**; собрано subagent-driven, FF-merge в master). Оператор right-size'ит app-requests **in-place** через upstream VPA: эмитит **один** `VerticalPodAutoscaler` на managed CR-env (**`updateMode: InPlace`** — не InPlaceOrRecreate, тот evict'ит single-replica; `containerName:"*"`, RequestsOnly, `minReplicas:1`, minAllowed=seed 32Mi/25m, maxAllowed.memory=512Mi), prune на managed→pro, зеркалит `VPA.status.recommendation`→`Application.status.recommendedResources` (+`app status`). Трёхзначный кноб `PlatformStack.spec.resources.autoscale.mode ∈ {full(default), up-only, off}`; `apprafter platform autoscale set/show`. Чарт `vertical-pod-autoscaler` 0.11.0 (VPA 1.7.1), self-managed certGen (без cert-manager), `failurePolicy:Ignore`, feature-gate `InPlaceOrRecreate=true` (alpha, на updater+admission), metrics-server = hard-prereq. Память корректируется только в `[32Mi,512Mi]` (RequestsOnly cap на seed-лимите). GitOps: **Option A** (VPA владеет живым подом in-place, оператор — константным seed-шаблоном; НЕ writeback — Phase 3). Backend-recommendation + KEDA-exclusion guard — вынесены в follow-up (ADR 0054; KEDA-guard → 2.6a). Обесценивает D2-budget-close 2.16d. **Live-walk на реальном Hetzner GREEN end-to-end** (все сценарии, оба проекта = 0) — и он ОКУПИЛСЯ: поймал **3 бага, невидимых unit/CRD/review**: (1) зеркало не персистило — `recommendedResources` объявлено голым `{...}` → CRD `type:object`-без-preserve-unknown → apiserver пруна́л вложенные поля на SSA (фикс: структурная схема); (2) **`vpa_available` startup-race** — one-shot проба проиграла CRD-инсталляции 0.06с → VPA молча выключен на всю жизнь пода (фикс: ленивая перепроба `Arc<AtomicBool>`); (3) VPA certgen Job был BestEffort (фикс: resources). Все диагностированы детерминированно на локальном kind. **Релиз (несколько итераций):** op/wh **v0.2.41** / cue-cmp **0.1.21** / ps **0.2.52** / cli **v0.2.39** (монорепо-тег v0.2.39); op/ps/cue-cmp v* — workflow-made. 2.16e ≠ Phase closure (order-3.7 pulled-up; §6-бокс не трогается; spec.md актуализируется на закрытии фазы).

**Поставка:**
- [x] VPA в platform-stack (recommender + updater + admission-controller). Mode `InPlace` (см. 🚧-заметку выше: `InPlaceOrRecreate` отвергнут, трёхзначный кноб, дефолт `full`).
- [x] **Recommender tuning под недельные пики:** `--memory-aggregation-interval=24h` + `--memory-aggregation-interval-count=14` (14д окно) + `--memory-histogram-decay-half-life=168h` (7д half-life). NB: дефолтный 24h half-life стирает недельный пик (2⁻⁷≈0.8%) → недопровижн cyclic-аппов. Trade-off: длиннее окно = медленнее реакция на снижения (консервативнее) — на узком узле в правильную сторону. `--memory-saver=true` (рекоммендер держит state только для VPA-таргетнутых подов → меньше его RAM на тесном T1).
- [x] **`minAllowed.memory` floor — обязателен** per-VPA. Defense: checkpoint float→int rounding bug может выдать 0-memory rec после рестарта рекоммендера → OOM-loop; плюс incompressible memory. `maxAllowed` тоже.
- [x] **GitOps-reconciliation** (VPA мутирует live spec out-of-band → Argo видит drift на `resources`): решить в ADR — либо Argo `ignoreDifferences` на `/spec/template/spec/containers/*/resources` для VPA-managed, либо writeback рекомендации в манифест. Writeback чище под GitOps-as-sole-control-surface + ложится на MCP-agent approval-gate.
- [x] **Pro-mode opt-out:** аппы с явным `resources` (2.16d) → VPA `Off`/не таргетятся (юзер владеет; advisory-нотификация «actual=X» в портал — единственный осмысленный сток в pro-режиме).
- [x] **KEDA-эксклюзия:** VPA НЕ на одном CPU/mem-метрике с KEDA-скейлингом (ADR 0019) — death-spiral (VPA↓request → HPA-математика едет → реплики взрываются → гистограммы скашиваются). Гард + докум.
- [x] VPACheckpoint персист (CRD в datastore — на single-node k3s это kine/sqlite); пережить рестарт рекоммендера.
- [x] Live walk: апп без `resources` → VPA набирает историю → `InPlaceOrRecreate` поднимает/опускает request на живом поде **без рестарта** (assert `RESTARTS=0`, под не пересоздан); minAllowed держит пол.

**Acceptance:** VPA авто-корректирует requests аппов по usage без рестарта (in-place); недельный пик в окне тянет memory-request вверх; minAllowed предотвращает 0-rec; pro-mode аппы не трогаются; KEDA-ворклоады исключены.

**Зависит от:** 2.16d (resource-модель + pro-override field), KEDA (3.x — эксклюзия), новый ADR resource governance (~0049). **Footprint-нюанс:** VPA-компоненты сами едят память (histograms в RAM) — на узком T1 это meta-overhead; `--memory-saver` смягчает, на T2+ некритично.

**Размер:** M-L · VPA-деплой + tuning + minAllowed — умеренно; GitOps-reconciliation (ignoreDifferences vs writeback) — основной дизайн-вопрос; walk на in-place.

---

### 2.16f — Argo CD footprint tuning (T1)
> 🏁 SR: A — срезать платформенный footprint на узком T1 (live prod 788Mi headroom); НЕЗАВИСИМ от 2.16d/e, быстрый reversible win, может ехать раньше. Перенести при желании.

> ✅ **ЗАКРЫТО 2026-08-11** (SR:A; спек `docs/superpowers/specs/2026-08-10-2.16f-argocd-footprint-design.md` (4 раунда внешнего ревью R1–R4 + независимая перепроверка несущих механик), план `.../plans/2026-08-10-2.16f-argocd-footprint.md`, замер `docs/measurements/2.16f-argocd-footprint-2026-08-11.md`; на master, config-only). Тюнинг argocd-компонента через chart-values: `GOMEMLIMIT`/`GOGC` env на app-controller (256MiB) + repo-server (128MiB, M2 — форкает helm/git), `resource.exclusions` в `argocd-cm` (Endpoints/Event/events.k8s.io-Event/EndpointSlice/Lease/metrics.*/Cilium identity+endpoint/VPACheckpoint — kind-scoped, `CiliumNetworkPolicy` остаётся), `applicationSet.replicas:0` (в 7.7.7 НЕТ `enabled`-гейта → replicas:0 под prune:false, без orphan). Релиз **ps 0.2.53** (+ `0.2.53-rc.1` walk-vehicle prerelease), change=safe, без operator/cue-cmp/CLI, без монорепо-тега; M1(b) rc-as-walk-vehicle, F2 dotted `-rc.N`, F4 no-CLI-release-в-rc-окне. **REFRAME (live-driven, user-approved):** свежий throwaway app-controller RSS шумный (359/206/211/144, ~206 БЕЗ тюнинга — холодный старт) → GOMEMLIMIT=256 не связывает на свежем; польза (кэп роста worn-in + −CPU) видна только на обжитом кластере. Walk гейтит **delivery+no-reg** (env применён, Synced/Healthy, appset 0/0, exclusions, no OOM/restart), RSS/CPU **recorded не gated**; RSS-снижение валидируется на dogfood. **ПОДТВЕРЖДЕНО на реальном dogfood (0.2.46→0.2.53):** app-controller **344→208Mi (−40%)**, CPU **131→15m (−88%)**, appset-под убран, 208<256-кэп → кэп связывает и работает. **F1 fresh-install SSA GREEN** (throwaway MODE=stable walk, реальный Hetzner: appset сходится к 0/0 на свежем bootstrap'е — cross-manager SSA helm-replicas:1↔Argo-0 разрешается; + delivery/no-reg/exclusions/no-OOM на обоих легах Leg3-fresh+Leg2-upgrade; cleanup оба проекта=0). Walk также поймал **harness-баг** (`set -o pipefail` + `kubectl -o json | grep -q` на большом STS-JSON → grep-q матчит рано → SIGPIPE kubectl → pipefail ложно роняет env-assert; DIAG показывал env ВСЕГДА → продукт исправен; фикс = capture-в-переменную + bash-match, детерминистически доказан локально). **Единственный follow-up:** request re-pin из осевшего dogfood-замера (208→~180-200 vs 288, ~90-110Mi allocatable) — минорная allocatable-оптимизация, отдельный ps-бамп когда dogfood устаканится. Пред-апгрейд backup dogfood'а снят (`apprafter backup create`, native local restic). 2.16f ≠ Phase closure (order-3.7 pulled-up; §6-бокс не трогается).

**Контекст:** на live T1 (4GB) Argo CD — самый тяжёлый «арендатор»: app-controller ~305Mi + repo-server ~109Mi на горстку Applications (замер 2026-06-17). Контроллер — Go-приложение: держит resource-tree всех аппов в памяти (~40% его памяти — live-resource-cache) + Go-runtime не отдаёт freed heap до удвоения. На Cilium-кластере вдобавок трекает churny `CiliumIdentity`/`CiliumEndpoint` без нужды.

**Цель:** снизить working set Argo-компонентов на T1 без потери функциональности (ожидание: app-controller 305→~175Mi, итого ~−140Mi → headroom 21%→~24%). NB: пол ~150-200Mi (Go-runtime + informer baseline) — ниже не упасть; k3s control plane (~1.4GB) тюнингом Argo НЕ трогается.

**Поставка (всё через platform-stack chart values — НЕ kubectl; инвариант «платформа реконсилится через Argo»):**
- [x] `GOMEMLIMIT` на app-controller (256MiB) + `GOGC=50` + repo-server (128MiB — M2, форк-headroom helm/git под 256Mi-cap). Доставлено (env живьём на обоих workload'ах, verified).
- [x] `resource.exclusions` в `argocd-cm`: `Event` + `events.k8s.io/Event`, `Endpoints`/`EndpointSlice`, `Lease`, `metrics.k8s.io/*`, `cilium.io CiliumIdentity/CiliumEndpoint` (+ `autoscaling.k8s.io/VerticalPodAutoscalerCheckpoint` — 2.16e). Kind-scoped (`CiliumNetworkPolicy` остаётся). Доставлено.
- [x] Отключён `applicationset-controller` — через **`applicationSet.replicas:0`** (в 7.7.7 нет `enabled`-гейта; replicas:0 держит объект в desired под prune:false, без orphan). Под убран (verified на dogfood).
- [x] Замер до/после — в `docs/measurements/2.16f-argocd-footprint-2026-08-11.md` (не PROJECT_STATS): dogfood app-controller **344→208Mi**, CPU 131→15m; throwaway RSS recorded (шумный, reframe).
- [x] Skip: sharding + Kyverno-exclusions (как планировалось).

**Acceptance:** Argo-компоненты на T1 потребляют ощутимо меньше (app-controller < ~200Mi) при сохранении sync/health; платформа по-прежнему реконсилится без ручного apply.

**Зависит от:** — (независим). Связан с 2.16d (та же цель — освободить headroom на live T1).

**Размер:** S · конфиг-only (env + `argocd-cm` в chart values) + замер.

---

### 2.16g — Provisioned swap + NoSwap behaviour (node-substrate default, tier-aware)
> 🏁 SR: A — превратить OOM-склонный no-swap дефолт в прощающий: host-своп поглощает спайки control plane (на live T1 `k3s.service` пикал 2.8G при 788Mi headroom), поды НЕ свопятся (NoSwap → Postgres в RAM). T1-часть launch-scope; T2-тюнинг активируется с 3.1.

> ✅ **ЗАКРЫТО 2026-08-11** (order-3.7, SR:A; спек `docs/superpowers/specs/2026-08-11-2.16g-node-swap-design.md` — **4 раунда внешнего ревью R1-R4 + upstream/working-tree верификация**, план `.../plans/2026-08-11-2.16g-node-swap.md`, **ADR 0055**; ветка `feat/2.16g-node-swap`, subagent-driven). Новая **`apprafter node prep`** — идемпотентный umbrella (2.16d reservations + host-swap `min(RAM,8Gi)` + `GOMEMLIMIT=2GiB` на k3s), **hard-remove `reserve-headroom`**; + **`apprafter node status`** (live swap-posture, [api]/[ssh]-labels, graceful degradation). **Поставка:** (1) swap = **`min(RAM,8Gi)`** swapfile (dd `oflag=direct`+ionice, fstab `sw,nofail`) + `swappiness=10` + kubelet **drop-in** (`failSwapOn:false` + `memorySwap.swapBehavior:NoSwap`) — **не kubelet-arg** (B1: swapBehavior это KubeletConfiguration-поле, не флаг), Option-A managed-dir (Q4); (2) **`GOMEMLIMIT=2GiB`** на `k3s.service` (R3 — k3s это Go, своп без GOMEMLIMIT = thrash; бьёт Go-heap-компонент, residual покрывает своп — P6); (3) **bootstrap: `INSTALL_K3S_SKIP_START`** → бинарь ставится не стартует → `k3s --version`+cgroup2-гейт → пишем конфиг → `systemctl start k3s` (**fail-soft**: сбой swap = рабочая нода без подушки, никогда не незапущенная — Q2/P2); (4) retrofit-гейт `kubeletVersion` ≥1.34 (P3, не configz) + cgroup2, на <1.34 **REFUSE+upgrade-hint** (не silent-skip); (5) **atomic apply + whole-step rollback** (trait-backed unit-стейт-машина: `failSwapOn:false` убирается ПОСЛЕДНИМ и никогда при живом свопе — P1; `swapoff` с таймаутом; `rm` недостижим из swapoff-fail-ветки); (6) **inline `memory.swap.max=0`** на существующих kubepods-cgroup'ах (depth-agnostic `find` — NoSwap применяется при СОЗДАНИИ контейнера, N18/Q3); (7) **encrypted-swap residual-risk** = Hetzner-снапшот (N11), записан в ADR 0055; (8) **T1-only** (swap-шаг tier-gated; T2 etcd/`swappiness=1` deferred @3.1, T3/T4 deferred). **Real-Hetzner walk GREEN end-to-end** (`e2e/node-swap-walk.sh`, 8 шагов, 2 ноды в 2 проектах): configz NoSwap + swap active + GOMEMLIMIT + fstab-nofail; pod-NoSwap; **подушка сработала под давлением** (pswpout+2.2M, k3s.service выжил, /readyz up); **SKIP-gate + no-swap→swap transition + Q7** (inline-set пережил VPA-resize → роллить workload'ы НЕ обязательно) + idempotent; reboot-persistence + post-boot-self-healing. Walk окупился — **4 итерации harness-багов** (pod-OOM-ассерт противоречил «NoSwap защищает НОДУ не workload'ы»; node-selection: label-anchor project-wide → 2-я нода в OTHER-проекте; env HCLOUD_TOKEN перебивал stored-token), **продукт ни разу не был причиной**. dogfood k3s v1.35.5 ≥1.34 (N1 clear). **Релиз:** CLI-only (node prep/status + installer) → **cli v0.2.40 + monorepo-тег v0.2.40**; ps/operator/cue-cmp не трогаются. spec.md не трогается (Rev 15). **Follow-up'ы ЗАКРЫТЫ в cli v0.2.41 (real-Hetzner STEP6-walk GREEN; tag v0.2.41 supersedes сломанный v0.2.40 — его stale `Cargo.lock` не собирался под `release-cli --locked`):** Q10 — `node status` читает API-поля через кэш-kubeconfig (SSH-down больше не гасит их); STEP6 — undocumented `APPRAFTER_NODE_SWAP_FORCE_INVALID_DROPIN` fault-hook + разводка walk-STEP6 на retrofit-ноду. **STEP6-walk поймал реальный продуктовый баг (unit/review пропустили):** `wait_for_recovery` пробил только apiserver `/readyz`, а битый kubelet-drop-in кладёт **kubelet** при (недетерминированно) живом apiserver → rollback НЕ срабатывал, забрикованная нода жила (и на реальном failSwapOn-брике так же) → фикс `bb20d00`: probe требует ещё и kubelet через node-proxy configz + regression-guard. **dogfood-retrofit `apprafter node prep` на `platform-1` ВЫПОЛНЕН пользователем 2026-08-11** (swap 3.7G active, NoSwap, swappiness=10, swapBehavior=NoSwap) — и вскрыл 2 бага ОТОБРАЖЕНИЯ `node status` (не свопа): (1) `GOMEMLIMIT: unknown` на всех нодах — `probe_gomemlimit` делал `strip_prefix("GOMEMLIMIT=")` на токене `Environment=GOMEMLIMIT=2GiB` (не срезал `Environment=`); (2) `provision: unknown` на ретрофит-нодах — breadcrumb писался только на bootstrap-пути. Фикс **cli v0.2.42**: чистый `parse_gomemlimit` + retrofit пишет provision-breadcrumb + walk теперь зовёт `node status` (walk маскировал баг: читал GOMEMLIMIT через `--value`+substring, `node status` не звал). Девиации: swap=`min(RAM,8Gi)` (не «2-4G скромный» plan.md — R4), drop-in (не kubelet-arg), T2 deferred. 2.16g ≠ Phase closure (order-3.7 pulled-up; §6-бокс не трогается).

**Контекст:** ноды провижатся БЕЗ свопа (swap=0). При тонком headroom транзиентный спайк host-процесса (apiserver/kubelet/datastore) → reclaim → OOM, без подушки. `NoSwap` (дефолт k8s) даёт ровно нужное: поды свопиться не могут (Postgres/apps в RAM, без latency-яда), а системные демоны вне scope k8s (включая k3s-процесс) — могут, поглощая спайк. **Бенефит tier- и node-size-agnostic** (любая нода с control plane — хоть cx22, хоть ccx — выигрывает от подушки; спайк относителен размеру ноды). Substrate у T1 и T2 ОДИН (любая hcloud-нода cx/cax/cpx/ccx); отличие T1↔T2 — node count + datastore + HA, **НЕ класс ноды**. Единственный risk-водораздел для свопа — datastore, и он контринтуитивен: на T2 своп не «меньше нужен», а **рискованнее**.

**Развилка по тирам (datastore-driven, НЕ node-class):**
- **T1 — 1 hcloud-нода, kine/sqlite** (disk-backed, swap-толерантен): своп безопасен, `swappiness=10`. Single-node = нет HA-fallback → OOM control plane = полный простой кластера → подушка особенно ценна (независимо от размера ноды).
- **T2 — 3+ hcloud-нод, embedded etcd, quorum:** per-node spike-risk и бенефит подушки — **те же** (substrate тот же, любая нода). HA смягчает *последствие* отсутствия свопа (quorum переживёт OOM одной ноды), но **etcd делает сам своп опасным**: swap-latency → пропуск heartbeat'ов → leader-election churn. etcd встроен в k3s-процесс (host) → при NoSwap host МОЖЕТ его свопнуть. Значит `swappiness=1` (агрессивно-консервативно) + защита etcd от свопа (mlock/исключение) — open research.
- **T3 (bare metal, Robot) / T4 (гиперскейлеры):** Talos — своп вероятно не поддерживается (immutable OS), **verify**; на T4 provisioning вообще hyperscaler-specific (managed node pools) → отдельная история. Revisit при kine+NATS.

**Поставка (CLI node-provisioning / k3s-installer path):**
- [x] Swapfile при node-setup (`dd oflag=direct`+ionice, fstab `sw,nofail`, disk-precheck vs 2.6c-15%). **Размер = `min(RAM,8Gi)`** — DEVIATION от «2-4 ГБ скромный» (R4: на T1-4GB это 4G = RAM, кап на бо́льшие ноды; bigger swap = дольше thrash-runway перед OOM, не безопаснее).
- [x] `vm.swappiness=10` на T1 (sysctl drop-in, переживает reboot — verified). T2=1 — deferred @3.1.
- [x] `failSwapOn:false` + `memorySwap.swapBehavior:NoSwap` — через KubeletConfiguration **drop-in** (Option-A managed-dir), НЕ kubelet-arg (B1: swapBehavior — поле KubeletConfiguration, не флаг); version-gated ≥1.34 (B2, `INSTALL_K3S_SKIP_START` → `k3s --version`); configz-verified в walk.
- [~] T2 etcd-swap-protection (mlock / `swappiness=1`) — **deferred @3.1** (open research, НЕ блокер T1; как и планировалось).
- [~] encrypted swap — **residual-risk записан в ADR 0055** (Hetzner-снапшот `/swapfile` с apiserver-секретами — N11; `swapoff+rm` перед любым snapshot-flow); random-key encryption deferred (R5).
- [x] **Real-Hetzner walk GREEN** (`e2e/node-swap-walk.sh`, 8 шагов, 2 ноды): подушка свопит спайк (pswpout>0, k3s.service выжил, /readyz up), Postgres NoSwap (`VmSwap≈0` + cgroup `swap.max=0`), SKIP-gate + no-swap→swap transition + Q7-survives-resize + idempotent + reboot-persistence.

**Acceptance (T1 launch — DONE):** T1-ноды провижатся со свопом `min(RAM,8Gi)` + NoSwap (`swappiness=10`); спайк control plane поглощается свопом вместо OOM (k3s.service выживает, /readyz up); поды (особенно Postgres) в RAM (`swap.max=0`); `apprafter node prep` идемпотентен + gate-first + whole-step-rollback + refuse-<1.34; `reserve-headroom` убран. **(T2 acceptance — `swappiness=1` + etcd swap-protection — deferred @3.1.)**

**Зависит от:** CLI node-provisioning / k3s-installer (1.x). T2-строка — с 3.1 (HA-bootstrap, embedded etcd). **Связан с** 2.16d (та же тема — тесный узел безопасен по умолчанию).

**Размер:** S-M · swapfile + sysctl + kubelet-arg — мелочь; etcd-swap-protection research на T2 — основная неизвестность.

---

### 2.16h — Machine picker: региональная матрица SKU в CLI (provision-time)
> 🏁 SR: A · order 3.7. Surfaced в обсуждении «CLI выбор машины и архитектура провайдеров» (2026-06-21). Load-bearing на T1: одна коробка под 1 или под 100 сервисов, размер решает на provision-time. **НЕ 3.1** — та добавляет *per-node* гетерогенность поверх, отдельная штука. Доступность SKU **зависит от региона** ⇒ выбор — матрица `(region × SKU)`, а не две независимых оси.

> ✅ **ЗАКРЫТО 2026-08-12** (cli **v0.2.43**, монорепо-тег `v0.2.43`, CLI-only; ADR **0056** + spec `docs/superpowers/specs/2026-08-12-2.16h-machine-picker-design.md` rev 6; ветка `feat/2.16h-machine-picker`, subagent-driven через Workflow-разведку). Единый `(region × SKU)` machine-picker (single-endpoint из `/v1/server_types` — план-овый `/v1/datacenters` **мёртв** после 2026-10-01, вскрыто разведкой; `with_scorer` а не `with_filter`) + **Decision 0 (2.16h-a, BREAKING): убран implicit `cpx22`-дефолт** — провижн без явного типа → `server_type_not_selected`, existing-кластеры self-heal через backfill. **Real-Hetzner walk GREEN** (`e2e/machine-picker-walk.sh`, non-interactive плечи: no-type→error+0-ресурсов / explicit-type→точный SKU+факт / legacy-backfill / `target machine` refuse-on-provisioned; sweep→0). Спека прошла **5 раундов внешнего ревью** (R1 вскрыл мёртвый API+scorer, R2–R4 достроили блёст-радиус Decision 0, R5 затяжка). Ручная приёмка владельца → **3 UX-коррекции:** `target machine` refuse на запровиженном кластере (смена машины = `backup`+`restore --reprovision`, не in-place resize), мёртвый deferred-intent-гард убран, stale-подсказка убрана. Девиации от плана: single-endpoint (не datacenters), sort-Select не `sort:`-токен (discoverability), matrix-filter не переживает sold-out-toggle (inquire 0.7.5 не отдаёт набранный фильтр). 2.16h ≠ Phase closure (order-3.7 pulled-up; §6-бокс не трогается — Phase 2 закрывается на 2.11–2.12).

> **Уточнения из спека (rev 6, C1/C2):**
> - `GET /v1/datacenters` — **deprecated 2026-06-02**, `410 Gone` после 2026-10-01. **Не используется.** Вся информация — в `GET /v1/server_types`: `locations[]` (`{available, recommended, deprecation}`) + `prices[]` per-location. Нового `list_datacenters()` нет.
> - `inquire 0.7.5` использует `with_scorer` (`Fn(&str,&T,&str,usize)->Option<i64>`) вместо `with_filter`. Scorer = filter+rank по одному полю.

**Контекст (текущее состояние до поставки):** server-type сейчас **не выбирался** через основной CLI-flow. Был `DEFAULT_SERVER_TYPE = cpx22` (v0.1.42), override только через CUE-манифест (`APPRAFTER_MANIFEST` → `nodes[0].kind`), + pre-flight `validate_server_type` (`.../server_type.rs`, v0.1.42). Чего не было: выбора SKU (флаг/wizard), персиста, учёта region-зависимости availability.

**Цель:** единый machine-picker — матрица валидных `(region × SKU)` строк с ценой, latency и спеками, с fuzzy+numeric-фильтром и переключаемой сортировкой. Каталог/цены/availability тянутся live. Выбор пишет **обе** оси в target. **2.16h-a (см. ниже): удаление implicit cpx22-дефолта (BREAKING).**

**Поставка — данные:**
- [x] **Offer-модель + fetch-join.** `MachineOffer { location, sku, cores, memory_gb, disk_gb, arch, cpu_type, price_monthly_net, price_hourly_net, available, recommended, deprecation }`. Источник: **один** `GET /v1/server_types` (join `locations[]` + `prices[]` per-location). Latency probe once-per-location. Pagination (loop `page`/`per_page=50` до `meta.pagination.next_page==null`).
- [x] **Availability заранее из API.** `locations[].available` читается upfront → sold-out строки скрыты (toggle раскрывает, non-selectable). `ServerTypeUnavailable` расщеплён на `Unknown / NotOfferedInRegion / Retired` (структурная, до выбора) vs `OutOfCapacity` (transient, provision-time).
- [x] **Единый источник picker↔validator.** `ProviderValidator::list_machine_offers() -> Result<Vec<MachineOffer>>`. Picker и validator делят один join.

**Поставка — UX (wizard, `inquire`):**
- [x] **Fuzzy + numeric filter (`with_scorer`).** Предикаты AND по пробелам: `cpu>=N`/`cores>=N`, `ram>=N`, `disk>=N` (+ `>`,`<`,`<=`,`=`); `arch:arm|x86`, `cpu:shared|dedicated`; `loc:`/bare, `sku:`/bare; свободный текст → case-insensitive substring по композиту (arg2, NOT arg3 rendered string). Toggle `ShowSoldOut` — filter-immune, pinned `Some(i64::MIN)` (bottom), appended last.
- [x] **Pre-picker sort-key `Select` (не live, не `sort:` токен).** `Latency ↑` (default) / `Price ↑ / Cores ↓ / RAM ↓ / Disk ↓ / Location`. Sортирует `Vec` до матрицы; scorer сохраняет порядок.
- [x] **ASCII-рендер строки ≤~64 char.** Маркеры: `*`=recommended, `-`=sold-out-mode, `!`=deprecating (без `+`). Легенда — одним `eprintln`; `with_page_size(15)`; `with_help_message` для nav-hint.

**Поставка — persist / flag / resolution:**
- [x] **Персист + флаг.** `TargetConfig.{server_type, region}` (`#[serde(default)]`). `--server-type` на `target add`/`apply`/`up`/`restore --reprovision`/`target machine`. `APPRAFTER_SERVER_TYPE` env (отдельный низкий rung, НЕ привязан к clap-флагу). Валидация ТОЛЬКО явного значения перед `save_target`.
- [x] **Резолюция в `apply` (обе оси).** `--flag > manifest(nodes[0].kind) > state(HetznerCloudState.server_type) > TargetConfig.server_type > APPRAFTER_SERVER_TYPE env > [default: type=error | region=nbg1]`. Источник типа печатается при provision.
- [x] **Рефактор A.4b region-step.** Standalone region-`Select` в add-wizard **заменён** матрицей. `--no-ping` shunt сохранён (Text+nbg1 + notice).
- [x] **`target show` / `whoami`.** `Server type: <sku or "not selected — run apprafter target machine">`.
- [~] *(Отложено)* T-shirt→SKU алиас-мапа — явно деferred, ADR 0056.

**Поставка — `apprafter target machine` (2.16h-a):**
- [x] Новая подкоманда: interactive → та же матрица над текущим target; `--server-type <sku>` → direct patch (без token re-prompt); пишет **обе** оси. `--target <name>`. `--no-ping` без `--server-type` → explicit error.
- [x] На provisioned target смена региона → confirm.

**Поставка — no-default (2.16h-a, BREAKING):**
- [x] `DEFAULT_SERVER_TYPE` const удалён. `ServerSpec.server_type: Option<String>`. Ошибка `ServerTypeNotSelected` (stable code `apprafter::provider::server_type_not_selected`) ТОЛЬКО на create-пути.
- [x] `HetznerCloudState.server_type: Option<String>` (#[serde(default)]) — fact при CREATE.
- [x] Backfill self-heal (legacy targets): при missing state/TargetConfig type → live-read pinned by `server_id` → write both stores. Best-effort.
- [x] Guards split: fact-drift (state vs live) → WARNING; deferred-intent (target vs live) → INFO once per run.
- [x] `import` fills `HetznerCloudState.server_type`.
- [x] `destroy` prints tombstone с type/region.
- [x] `restore --reprovision` resolves type через цепочку, `ServerTypeNotSelected` если не разрешён.
- [x] `e2e/mvp.sh` фикс: `--server-type ${APPRAFTER_E2E_SERVER_TYPE:-cpx22}`.

**Acceptance (полный — включая walk):** матрица показывает валидные `(region × SKU)` с ценой + latency + спеками; `cpu>=8 ram>=32 arch:arm` сужает; sort-key меняет порядок (default cursor = top row, не toggle); sold-out скрыты по дефолту, toggle сохраняет filter; будущий deprecated selectable с `!`; выбор пишет region+server_type; `apply` поднимает коробку выбранного типа; **fresh provision без типа → `ServerTypeNotSelected`, ни одного CREATE**; **existing cluster `apply` после upgrade → успех + backfill live type (dogfood)**; **`target machine` refuse на запровиженном кластере** (смена машины = `backup`+`restore --reprovision`); out-of-band change → warning (единственный гард); `restore --reprovision` воспроизводит тип или explicit error; невалидная пара → structural error с альтернативами; `--no-ping` interactive работает; zero-selectable → typed error; env-credential provision; старые target'ы загружаются. **✅ Real-Hetzner walk GREEN 2026-08-12.**

**Отложено (зафиксировано в ADR 0056):** T-shirt aliases; `ratatui` TUI; tier-aware SKU filtering; latency-as-filter (sort-only); backup-manifest-carries-type (cross-target clone DR).

**Размер:** L (реализовано). Ветка: `feat/2.16h-machine-picker`.

### 2.16h-a — No implicit server-type default (BREAKING, часть одного релиза с 2.16h)

> ✅ **ЗАКРЫТО 2026-08-12** вместе с 2.16h в ОДНОМ релизе (cli **v0.2.43**). Real-Hetzner walk GREEN. `DEFAULT_SERVER_TYPE` убран; create-путь без типа → `server_type_not_selected`; existing-кластеры self-heal (backfill). `target machine` refuse-on-provisioned. См. ADR 0056 §(d),(g).

Decision 0 (ADR 0056 §d): provisioning — это spending decision, implicit `cpx22` молча это скрывал. Удалён `DEFAULT_SERVER_TYPE`; create-path без типа → `ServerTypeNotSelected`; reconcile-path (existing server) типа не требует. Backfill + guards описаны выше в 2.16h. BREAKING задокументирован в UNRELEASED.md (migration: existing clusters self-heal на первом `apply`; fresh targets требуют явного типа).

---

### 2.16i — Per-environment deep-merge для `needs.*` (split-out из 2.16c)
> 🏁 SR: A · order 3.7 — **ВЫДЕЛЕНО из 2.16c** (design R3-H3/R4-N2): `needs.*` deep-merge — provisioning-layer data-loss путь, требует своей миграционной аналитики, поэтому 2.16c оставил `needs` на сегодняшнем per-key wholesale-replace, а этот item владеет всеми тремя под-проблемами. НЕ закрыто.

**Контекст:** 2.16c сделал per-environment override struct-полей `expose`/`imagePolicy` частичным (deep-merge по подполям). `needs.*` намеренно НЕ тронут: в отличие от `expose`, частичный override `needs.<type>` пересекает провижионер и может уничтожить данные, а форма `OneOrMany` делает сам merge неоднозначным. Пока `needs` остаётся на per-key wholesale-replace (env-ключ целиком заменяет base-ключ) — новой data-loss-поверхности 2.16c не добавил.

**Три под-проблемы (каждая — свой дизайн-вопрос, все три должны быть решены вместе):**
- [ ] **(a) `merge_needs` для `OneOrMany` (scalar|array) не определён.** `needs.<type>` это `#ServiceNeed | [...#ServiceNeed]` (`OneOrMany`) — что значит «deep-merge» массива под-нужд? Решить: match-by-name (мёржить одноимённые записи) / wholesale-on-array (массив = замена целиком, deep-merge только для скалярной формы) / reject (запретить partial override для array-формы на webhook). Определить семантику ДО реализации.
- [ ] **(b) partial `needs.<type>` override, наследующий `name`, меняет имя ResourceClaim.** Имя claim'а — `{app}-{type}[-{name}]`; наследование `name` из base под изменённым override сдвигает имя → GC старого claim (7-дневный RetainedClaim grace) → пустая БД (**data-loss**). Нужна своя миграционная аналитика: как ведёт себя upgrade-originated мутация имени, гейтить ли её как destructive (2.16b machinery), защищать ли данные.
- [ ] **(c) re-open 2.4d «`needs.*.selector` changes — NON-destructive».** Решение 2.4d («смена `needs.*.selector` не деструктивна») принято для **юзерской** правки; upgrade-originated мутация selector'а через deep-merge — другой контекст, требует пере-рассмотрения (может ре-таргетнуть claim на другого провайдера → тот же data-loss-класс).

**Acceptance:** per-environment override `needs.*` становится частичным без риска потери данных — либо через match-by-name merge с явной защитой claim-name/GC-пути, либо через осознанное решение оставить array-форму wholesale + гейтить опасные мутации. Все три под-проблемы закрыты с regression-guard'ами.

**Зависит от:** 2.16c (struct-deep-merge machinery + `#ApplicationEnvOverride`), 2.4d (`needs.*.selector` decision — re-open), 2.4f (RetainedClaim/GC), 2.4 (provisioner + claim-naming), 2.9 (per-env модель). **Связан с** 2.16b (destructive-gate — если мутацию имени/selector'а гейтить).

**Размер:** M · сам merge-код мелкий; масса — определение семантики `OneOrMany`-merge + миграционная аналитика claim-name/GC-пути + re-open 2.4d selector-решения.

---

### 2.17 Закрытие чек-листа M2 spec

- [ ] Обновить `spec.md` §6 M2.
- [ ] Tag `v0.2.0-services`.
- [x] ~~Update `docs/dev-guide/needs.md`~~ — доставлено тремя поверхностями, а не одной страницей;
      разбор в 2.18.

**Размер:** XS · оба оставшихся пункта — действия закрытия фазы, и оба ждут 2.25.

---

### 2.18 Known Limitations docs sync — ЗАКРЫТА в 2.20c (2026-08-29, `57dfd96`)

**Source:** tracker §1.1.

> Закрыта внутри долга протухания 2.20c: `spec.md § Known limitations` переписан. Три пункта
> описывали `confidential`, `connects.egress.external` и `network.egressIP` как «declared in the
> manifest schema and accepted by the operator» — ни одного из трёх нет в `schemas/v1alpha1`,
> то есть читатель по ним писал манифест, который отвергает webhook. Плюс HTTPRoute и
> MigrationPlan-реконсайлер числились отложенными, хотя отгружены (последний ещё и утверждал,
> что изменения применяются «without approval gating»).

**Цель:** перед `v0.2.0-services` tag убедиться, что `spec.md` § Known limitations of v0.1.x отражает реальное состояние закрытого Phase 2.

**Поставка** (сверено с деревом 2026-09-07 — боксы отставали от того, что уже сделано):
- [x] Update `spec.md` Known limitations section — сделано в 2.20c. Секция переписана и теперь
      прямо называет поля, которых **нет в схеме**, вместо прежнего «accepted by the operator».
- [x] ~~Update `docs/dev-guide/needs.md`~~ — **доставлено другой формой, и форма из пункта сегодня
      была бы неверной.** Отдельной `needs.md` нет и не будет: workflow разложен по трём
      поверхностям, как того требует ADR 0058 — рецепт в `operator-guide/{postgres,redis,
      persistent-disk}.md`, поля в `dev-guide/application-cue.md`, механика в
      `how-it-works/needs-{pg,redis,disk}.md`. И `jetstream` из формулировки пункта документировать
      было бы ложью: схема ключ объявляет, провайдер не отгружен.
- [x] ~~Update `e2e/mvp.sh` — extend для `needs.*`~~ — **тоже другой формой:** вместо одного
      разросшегося mvp пять отдельных прогонов, `e2e/needs-{pg,redis,disk,removal,networkpolicy}-walk.sh`.
      `mvp.sh` не содержит ни одного `needs` и не должен: он про голый провижн-путь.
- [ ] Tag `v0.2.0-services` после всех Phase 2 closures. **Единственный по-настоящему открытый
      пункт здесь** — и он не может быть закрыт, пока открыта 2.25.

**Acceptance:** spec.md Known limitations accurate per state; e2e зелёный с pg flow.

**Зависит от:** all other Phase 2 подфазы closed.

**Размер:** XS

---

### 2.19 Documentation system — сайт, drift-гейты, LLM-артефакты, CLI-UX
> 🏁 SR: A · order 3.7 — публичные доки как продуктовая поверхность (`docs.apprafter.dev`). Всё, что зашипилось в 2.9–2.16h, сегодня существует только в `--help` и в plan.md: сайт не опубликован, лендинг рендерит «Docs — Soon», а единственная CLI-референс-страница описывает 15 из 27 top-level команд. Трек **широкий** (машинерия + контент + CLI-UX, одна закрывающая ручная прогулка), поэтому разложен на подфазы **a–j**; закрывается целиком только на 2.19j.

> ✅ **ВСЕ ДЕСЯТЬ ПОДФАЗ ЗАКРЫТЫ (2.19a–2.19j).** Но строка в `FEATURE_TRACKER.md` остаётся 🚧, и это осознанное чтение её же правила: правило говорило «флип на 2.19j», а ОБОСНОВАНИЕМ давало «сайт, который никто не может открыть, — не поставленная возможность». Обоснование переживает свой триггер: между веткой и читателем стоят пять ручных шагов владельца (DNS, видимость пакета в реестре, регистрация приложения), и `https://docs.apprafter.dev/` пока не отвечает. Строка флипнется, когда сайт вернёт страницу. **2.19j несёт CLI-патч `v0.2.48`** — см. пункт (j). **Ни релиза, ни монорепо-тега** несут a–f; **2.19g несёт CLI-патч `v0.2.45`** — см. пункт (g), реверс первоначального ответа зафиксирован там, а не подправлен; **2.19h несёт CLI-патч `v0.2.46`** (новая команда `completion` + секция `Examples:` в `--help` у 75 команд), и её запись говорит вслух, что дефект, с которого начался трек, — неописанный `--namespace` у `secret seal` — был закрыт ДО неё ранними walk-фиксами, а вклад подфазы другой; **2.19i несёт CLI-патч `v0.2.47`** — не ради контента, а ради ДВУХ `about`: у `apprafter plan`, обещавшего диф, которого команда не считает, и у `apprafter destroy`, чья справка утверждала узкую область («infrastructure managed by this state»), тогда как удаляется всё помеченное `apprafter=true` в проекте токена; вторую нашли ревью — зачистка прозы поправила восемь страниц и пропустила предложение, которое читатель разрушительной команды встречает первым, и её запись фиксирует главную поправку трека: «~15 гайдов» из спека — оценка, которую семь подфаз никто не перемерял, а по дереву команд их **пять** (плюс три команды, осознанно оставленные без гайда, потому что не реализованы). Дизайн: `docs/superpowers/specs/2026-08-17-documentation-system-design.md` (rev 3, актуализирован под 2.19c — переписан после 4-линзового adversarial-ревью: 8 P0 + 40+ P1, три собственных фактических утверждения спека оказались неверны и исправлены). Ветка `feat/2.19-docs-system` (2.19c — на `feat/2.19c-drift-gate`, план `docs/superpowers/plans/2026-08-18-docs-2.19c-drift-gate.md`). **ADR ратифицирован постфактум:** `docs/adr/0057-documentation-system.md` (`Accepted`, 2026-08-18) — долг трека закрыт с опозданием (спек §8 требовал ADR перед 2.19b, а он написан после неё; сам ADR это фиксирует и помечает каждое ещё не реализованное решение). **Ни релиза, ни монорепо-тега:** чарты/оператор/cue-cmp не тронуты, `docsgen` — dev/CI-only крейт, сайт по-прежнему не отдаётся — 2.19g поставила ВСЮ машинерию публикации (образ, Caddyfile, `Application.cue`, `release-docs.yml`), но между веткой и читателем стоят ШЕСТЬ ручных шагов оператора, перечисленных в записи (g) и в раннбуке (2.19g при этом режет CLI-патч 0.2.45 — см. (g)). Но **бинарь CLI изменился** (утверждение «поведение CLI не изменилось» верно только для 2.19a/b — там это были lib-таргет + правки doc-comment'ов): 2.19c встроил в `apprafter app validate` все четырнадцать файлов `schemas/v1alpha1` вместо `types` + `application`, так что манифест, называющий любой другой kind пакета (`#SharedVolume`, `#SourceCredential`, ещё десять), больше не падает с «undefined field» — ошибкой про наш временный workspace, а не про файл пользователя. Тот же бандл использует CUE-чек гейта, так что встраивание одно, а не два. Бампа версии это не требует (никакой команды/флага/дефолта не двигали), но молчать об этом нельзя. **2.19d** (ветка `feat/2.19d-docs-xref-health`) шипнутый бинарь не трогает вовсе — вся его машинерия живёт в `cli/docsgen`, — так что «ни релиза, ни тега» для неё верно без оговорок. **2.19e** (ветка `feat/2.19e-hooks-llm`) — тоже: два build-хука `mkdocs` + `description` во frontmatter + четвёртый проход `scripts/docs-check.sh`; единственная правка Rust — docstring в `cli/docsgen/src/scan.rs`, который её же замер и опроверг. ADR 0057 получил amendment по 2.19e (что поставлено и что осознанно НЕ построено). **2.19f** (ветка `feat/2.19f-information-architecture`) шипнутый бинарь не трогает вовсе — `cli/platform-cli` не изменён ни на строку, так что `apprafter --help` и `commands.json` байт-идентичны, а единственные правки Rust — комментарии в `cli/docsgen`, называвшие переименованные страницы. Её amendment в ADR 0057 фиксирует и то, чего она НЕ построила: карты редиректов нет, потому что редиректить не от чего (см. (f) ниже).

**Контекст (замеры спека §1, до трека):** 93 tracked-страницы (58 ADR + 35 не-ADR); `mkdocs build --strict` проходил, но **не валидировал ничего** — 64 страницы висели вне nav под `validation.nav.omitted_files: info`, битые ссылки и якоря не проверялись; Nix-fallback в `Justfile` **никогда не работал** (`nix shell nixpkgs#python3Packages.mkdocs-material` не даёт бинаря `mkdocs`), и `CLAUDE.md:18` документировал сломанный путь как рабочий; **docs-only PR гонял ноль CI-джобов** (в `lint.yml` нет docs-фильтра); `edit_uri` указывал на несуществующий `main`. Шесть подтверждённых дрифтов код↔доки, **пять из шести живут вне code-fence'ей** (таблицы и проза) — отсюда вся форма гейта 2.19c. CLI: 27 top-level + 68 вложенных = **95 command-path'ов**, ни одного usage-примера, ни completions, ни snapshot-тестов.

**Цель:** довести доки до состояния продуктовой поверхности — опубликованный сайт на своих финальных URL'ах, машинно-проверяемая связь код↔доки (drift ломает `just lint`, а не всплывает на аудите), LLM-артефакты, и CLI, который сам себя объясняет.

**Поставка (подфазы; закрыты a–f):**
- [x] **(a) Foundations** *(= W0 спека)*. Один `python3.withPackages` env в `flake.nix` (mkdocs-material + literate-nav + redirects), docs-таргеты `Justfile` ходят через `nix develop`. Строгая сборка впервые **валидирует**: `not_in_nav` allow-list, `validation.links.{not_found,anchors,unrecognized_links}`, `nav.omitted_files: warn` — `operator-guide/node-prep.md` оказался невидимым юзер-гайдом и вернулся в nav. Внутренние страницы (`changelog/history.md`, `changelog/plan-history.md`, `measurements/`) больше не публикуются на сайт (`history.md` **остаётся на своём пути** — его парсит `release-cli.yml`). Лицензия доков названа: проза **CC-BY-4.0** (`LICENSE-CC-BY-4.0`), сэмплы кода **Apache-2.0** — в `docs/license.md`, `README.md`, `NOTICE` и футере сайта; пять залётных `FSL-1.1-Apache-2.0` SPDX-заголовков на Markdown под `docs/` убраны (противоречили новой лицензии), `contributing/license-headers.md` теперь говорит, что Markdown под `docs/` per-file-заголовка не несёт. Новый гейт `just docs-check` (strict build + reference drift) вкручен в `just lint`, lefthook-хук и `.github/workflows/docs.yml`.
- [x] **(b) Generated CLI reference** *(= W1)*. У `cli/platform-cli` появился lib-таргет: `dispatch` уехал в `src/dispatch.rs`, `main.rs` — тонкий шим над `apprafter::run()`; публичная поверхность = `run()` + фасад `docs_api` из двух пунктов (осознанное расширение API, а не побочный эффект рефактора). Новый крейт `cli/docsgen` генерирует `docs/reference/cli/**` — 26 страниц по top-level командам, индекс, literate-nav `SUMMARY.md` и машиночитаемый `commands.json` на все 95 command-path'ов — а `docsgen check` **байт-в-байт** сверяет их с clap-деревом в `just lint`, lefthook и CI: переименованный флаг теперь роняет сборку. Рукописный `docs/reference/cli.md` (15 из 27 команд, при этом заявлявший полноту) удалён; новый `docs/reference/environment.md` описывает 25 переменных окружения, которых генератор не видит (их читают `std::env::var` или зависимости). Генератор сработал как аудит doc-comment'ов: `status`/`login`/`upgrade-tier` теперь **первым предложением** признаются скелетами, документированы семь ранее безымянных флагов `backup enable` и `platform upgrade`, у `--no-ping` убрано ложное «любое непустое значение», а внутреннее Rust-имя `nodes[0].kind` заменено на реальный ключ манифеста `type` в трёх help-строках и в `operator-guide/troubleshooting.md` (там оно учило операторов писать непарсящийся ключ).
- [x] **(c) Drift-гейт по гайдам** *(= W2)*. Три чек-гейта в `cli/docsgen`, вкрученные в `just lint`, pre-commit-хук и CI (`scripts/docs-check.sh`) над **33** гайдами в скоупе (`spec.md` вне скоупа осознанно — это roadmap, не описание того, что поставлено; сгенерированный `docs/reference/cli/**` тоже вне скоупа — он уже байт-сверяется отдельным гейтом 2.19b): **CLI-инвокации** — путь команды + имена флагов (никогда не значения, никогда обязательность аргумента) резолвятся против `commands.json`, и во fence'ах, и в инлайн-спанах — **384** вызова; строгий резолвер, парсящий значения/`required`, ронял бы валидную документацию массово — 38 инвокаций в скоупе это usage-синопсис (`[--namespace <ns> ...]`), `\|` в половине случаев альтернация в скобках, а не пайп, и 161 из 213 инлайн-спанов — голые command-path без единого аргумента (корпус КАК НАЙДЕН, на `dc4c5de`; после правок этой подфазы — 165 из 219, 75 %). **Schema-идентификаторы** — backtick-пути резолвятся против CRD-полей плюс пяти CUE-only kind'ов; `Kind.spec.…` резолвится только против ЭТОГО kind'а, что закрывает silent-pass плоского union'а — **236** резолвится, из них **115** (чуть меньше половины) — только под узлом `x-kubernetes-preserve-unknown-fields`, то есть «резолвится» ≠ «проверено», и гейт печатает это соотношение каждый прогон, а не прячет его в общий счётчик. **Полные CUE-документы** — батчевым `cue vet -c -i` (**2** документа этим прогоном; фрагменты — вне скоупа, см. ниже). Обязательства выводятся из **содержимого** fence'а, никогда из его языкового тега: у ручного shell четыре разных тега и 14 fence'ов вовсе без тега, так что гейт на теге тривиально глушится удалением тега. Маркеры-исключения типизированы (закрытый словарь причин), датированы, стареют против РЕАЛЬНОЙ даты git-тега (а не даты коммита), недействительны без даты и репортятся, если не совпали ни с чем — молчаливое неиспользуемое исключение тоже находка.
  Гейт нашёл **33** проблемы, все починены: `apprafter promote` и другие непоставленные обещания убраны из `dev-guide/index.md`; примеры `--env`/`--namespace` сверены с реальным размещением флагов в `cli.rs`; `expose.public` → `expose.network` в восьми местах (два — внутри `kubectl apply`-heredoc'ов, где apiserver молча дропает неизвестный ключ, и читатель получает workload без экспозиции и без единой ошибки, объясняющей почему); 14 fence'ам проставлены info-строки; модель `DATABASE_URL`/`REDIS_URL` (снятая ADR 0046 в пользу decomposed-ключей `url`/`user`/`pass`/`host`/`port`/`db`) поправлена на 25 из 30 строк в трёх файлах (`application-cue.md` 5, `needs-pg-walk.md` 11, `needs-redis-walk.md` 14 — замер по in-scope-корпусу на `dc4c5de`) — оставшиеся пять уже были верны (они называют переменную окружения, которую читает приложение, а не ключ Secret'а); достроена таблица полей (`resources`, `imagePolicy`, `needs`, `environments`, `expose.hostname`, `expose.tls`). Два места исключены маркером, а не правкой, каждое с типизированной датированной причиной: `operator-guide/node-prep.md` документирует СНЯТУЮ команду (`reason=historical` — новая причина в словаре маркера ровно под этот случай) и `dev-guide/application-cue.md:36` корректно документирует схему **Argo CD**, а не нашу (`reason=external-tool`). 20 фикстур с парными негативными контролями (`cli/docsgen/testdata/drift/`) пинят каждый найденный дрифт и доказывают, что чек не срабатывает на лексически похожем, но корректном соседе.
  **Сознательно не покрыто:** CUE **фрагменты** не валидируются — 15 из 17 `cue`-fence'ов в скоупе это фрагменты, а не полные документы (один скелет не обслужит семь разных anchor-глубин; батч-валидатор проверяет только полные документы). `requires`/`conflicts` (класс «`--namespace` без `--select`») **нереализуем**: clap 4.6 держит их `pub(crate)` без геттера — пункт СНЯТ из дизайна, а не отложен на будущее. Протухший ключ Secret'а внутри `jsonpath` (ADR 0046 переименовал ключи pg-коннекшн-Secret'а, `{.data.DATABASE_URL}` теперь читает пустоту на живом кластере) — известная дыра: ни один существующий чек её не видит (строка не называет `apprafter`-подкоманду, не содержит dotted schema-путь, не является CUE-документом), зафиксирована фикстурой с парным негативным контролем и комментарием, что понадобится для закрытия (новый чек, резолвящий документированные ключи Secret'а против того, что реально пишет provisioner — а не расширение identifier-чека, который резолвит против CRD, а ключ Secret'а не CRD-поле). `spec.md` вне скоупа по решению — доки описывают то, что поставлено СЕГОДНЯ, а `spec.md` — это roadmap. Заодно ADR 0042 §7 и ADR 0043 §1 помечены superseded-in-part ADR 0046 (composed `REDIS_URL`/`REDIS_CHANNEL_PREFIX` и авто-инжект `<VAR>_<NAME>`, которые каждый из них описывал).
- [x] **(d) Xref + health-метрики** *(= W3)*. Ветка `feat/2.19d-docs-xref-health`. **Ни релиза, ни монорепо-тега:** `cli/Cargo.toml` не тронут, чарт/оператор/cue-cmp не двигались, `docsgen` — build-time-крейт, не входящий ни в один релизный артефакт. Поставлено четыре механизма плюс канал исключений; два пункта исходного списка СНЯТЫ по замеру, один ОТЛОЖЕН по замеру, ещё один оказался не нужен.
  **1. Обязательства переживают расфенсивание блока.** Отступ в четыре пробела на верхнем уровне и HTML-`pre` теперь несут ровно то же, что и fence. Закрыт обход, с которым гейт зашипился: контрибьютору, которому сказали «пометь fence», дешевле снести делимитеры и сдвинуть тело — рендерится идентично как код, а для всех чеков блок исчезал, и в диффе это не читается как подавление. Трекинг контейнеров тут load-bearing, а не косметика: `pymdownx.tabbed`, admonition'ы и list item'ы отступают теми же четырьмя пробелами, и без него чек даёт **шесть** ложных срабатываний на одном только `docs/dev-guide/quickstart.md`. Незакрытый `pre` — свой класс (`unclosed-pre`), потому что чинится другой правкой, чем незакрытый fence.
  **2. `code-path`** — путь репозитория, названный в backtick-спане или в относительной ссылке, которого нет. Две поверхности резолвятся по-разному: спан — от корня репозитория (читатель грепает его оттуда), таргет ссылки — относительно каталога страницы (как это делает MkDocs), а спан, являющийся ТЕКСТОМ ссылки, своего утверждения не делает — проверяется таргет. Глобы душатся на резолве, а не на извлечении, и набор паттерн-символов — `*` `?` `{` `}`, **но НЕ** `[`/`]`: три tracked-файла несут скобки в именах (динамические роуты Next.js), и считать их паттерном значило бы душить ровно эти ссылки жёстче всего именно в тот момент, когда один из файлов переезжает. У класса **нет ignore-ключа**: чужой путь называется чужим в предложении, а не исключается, иначе читатель будет грепать его в НАШЕМ репозитории.
  **3. `adr-reference`** — цитата, не называющая ни одного ADR, либо называющая решение со статусом `Superseded` / `Deprecated` / `Unused` (зарезервированный и брошенный слот). Читаются обе орфографии (`ADR 0046`, `ADR-0027`), множественное число, цитата, **перенесённая через разрыв строки**, и номер, зашитый в таргет ссылки или в путь файла. Вердикт берётся из **ведущего токена** тела `## Status`, поэтому частичное вытеснение («§7 superseded in part by …», которое несут четыре ADR) корректно НЕ находка; подстрочное правило на том же корпусе давало только ложные срабатывания.
  **4. `adr-check-ignore`** — канал исключений для этого класса, на той же машинерии, что `cli-check-ignore` и `schema-check-ignore`: те же типизированные причины, тот же `since=`, стареющий против РЕАЛЬНЫХ дат тегов, то же «без даты — недействительно» и тот же аудит неиспользованных. Ключ — канонический `ADR NNNN`, поэтому один ключ покрывает все написания одной цитаты. Осознанно цитировать снятое решение легитимно (это наша же идиома — предложение, которое объявляет вытеснение тем же вздохом), а класс зашипился вообще без способа это сказать.
  **5. Census + два health-класса.** `docs/measurements/docs-health.json` коммитит **семь** чисел, `docsgen gate` сверяет их **по значению**: шесть obligation-счётчиков не могут уменьшаться (рост проходит молча и намеренно — гейт, заставляющий перезаписывать файл ради написания страницы, это гейт, вокруг которого ходят), а `exemptions` сверяется на **равенство в обе стороны**, так что и объявление, и снятие исключения дают ровно одну ревьюабельную строку диффа. Перезапись — `docsgen metrics`. Отсутствующий или непарсящийся census — **exit 2** (сломан гейт), никогда exit 1.
  **СНЯТО/ОТЛОЖЕНО по замеру (не по вкусу):** **staleness-гейт СНЯТ** — нежизнеспособен ни на каком пороге: самой старой странице корпуса 104 дня, так что правило на 180 дней не может сработать ещё месяцами; правило на 90 дней вечно бьёт по одним и тем же четырём абстрактным страницам; 24 из 33 страниц делят две даты последнего касания и пересекают ЛЮБОЙ порог одновременно; обе стрелки сбрасываются на не-событиях (прогон SPDX-заголовков, прогон форматтера); `git log -1 -- <path>` не ходит через переименования, а одну страницу корпуса уже переименовывали; и из последних 100 коммитов, тронувших `schemas/**` или `cli.rs`, страницу в скоупе тронули **три**. Если staleness вернётся — его форма это дифф против опубликованного тега с явным pathspec (ровно то, что уже делает `scripts/check-operator-version-bump.sh`), а не прошедшие дни. **Типизированные `verified-by`-биндинги ОТЛОЖЕНЫ** — 17 из 28 tracked-скриптов `e2e/*.sh` не запускаются ничем автоматическим (ни workflow, ни `Justfile`-таргет), и в этом множестве `backup-restore-walk.sh`, который страница корпуса УЖЕ называет как своё подтверждение; требовать поле на ~20 dev/operator-страницах значит изготовить ~15 утверждений, которые читаются как проверенные и не являются таковыми. **Отдельный anchor-чекер НЕ НУЖЕН** — `validation.links.anchors: warn` под `--strict` уже роняет сборку на мёртвом якоре, и все 28 якорных ссылок в скоупе резолвятся. **Три ранее предложенных ратчета ЗАМЕНЕНЫ:** `blocks_executed` нереализуем (ключ `run=` принимает только `local`, а гейт репортит `run=local` как находку, потому что документированный блок никто не исполняет ⇒ ратчет вечно читает `0 >= 0`); `check_none` на нуле запрещает, а не ратчетит — на этом значении он банит тот самый типизированный датированный протухающий канал исключений, который решение и построило; а **байт-сверяемый** census покраснел бы на следующий день после коммита без единого коммита между, потому что три изначально предложенных поля — функции `now` (семь оставленных — нет).
  **Честный заголовок: все три новых чека находят на корпусе НОЛЬ дефектов сегодня.** Это замер, а не надежда, и это причина такого порядка работ: 2.19i добавляет ~15 гайдов, которые будут густо цитировать ADR'ы и пути репозитория, а страж, поставленный ПОСЛЕ контента, лишь узаконивает то, что контент уже сделал неправильно. Гейт, который в день поставки не репортит ничего, — честен; описывать его так, будто он что-то нашёл, — нет.
  **Предел, названный, а не замазанный:** счётчики меряют кардинальность, никогда специфичность — обязательство, ЗАМЕНЁННОЕ (а не удалённое), не стоит ничего: rich-инвокация на голую, глубокий путь на мелкий, конкретный файл на его каталог — все семь чисел держатся; проза, не несущая ни одного считаемого утверждения, невидима для census'а целиком. Эти ратчеты защищают от небрежного, не от мотивированного — от мотивированного защищает ревью.
- [x] **(e) mkdocs-хуки + LLM-слой** *(= W4)*. Ветка `feat/2.19e-hooks-llm`, план `docs/superpowers/plans/2026-08-19-docs-2.19e-hooks-and-llm-artefacts.md`; ADR 0057 получил amendment по факту поставки. **Ни релиза, ни монорепо-тега:** `cli/Cargo.toml` не тронут, чарт/оператор/cue-cmp не двигались, единственная правка Rust — docstring в `cli/docsgen/src/scan.rs`, который замер этой же подфазы и опроверг. Два хука в `docs/hooks/`, зарегистрированных ключом `hooks:` в `mkdocs.yml`; **ни один артефакт не коммитится** — все выводятся из закоммиченного контента на сборке, поэтому дрифтовать им не с чем (ровно поэтому пакет и мог приехать в любой точке трека).
  **1. CUE-лексер, но поставка тут — самопроверка, а не лексер.** pygments 2.20.0 лексера для CUE не несёт, а корпус пишет **37** `cue`-fence'ей на 20 tracked-страницах, **31** из них доезжает до сайта (остальные шесть — в changelog-рабочем файле, исключённом из сайта). Без хука все 31 рендерятся простым текстом, и сборка при этом **зелёная**: `pymdownx.highlight` глотает исключение неудавшегося lookup'а и молча откатывается на `text`. Поэтому `on_config` не просто регистрирует: он резолвит алиас (ловя `ClassNotFound` и объясняя последствие), проверяет, что алиас указывает **на НАШ** лексер (а не на чужой, занявший имя), и требует от сэмпла шесть семейств токенов (comment/keyword/string/name/number/operator) — через иерархию токенов pygments, так что перетокенизация в дочерний подтип ложно НЕ срабатывает, а потеря конструкции срабатывает. Оба режима отказа **пронаблюдены падающими** до коммита: самопроверка, падения которой никто не видел, — это самопроверка, про которую никто не знает, работает ли она. R1 в ADR называл митигацией «обязательный unit-тест»; зашипилось строже — проверка живёт в `on_config` и гоняется на КАЖДОЙ сборке (превью, `just lint`, CI), а не в наборе, который надо позвать.
  **Замер плана не воспроизвёлся и исправлен, а не подогнан:** в плане стояло 34 fence'а. Реально **37** tracked / **31** на сайте; счёт, требующий, чтобы fence открывал строку, даёт 33 — молча теряя четыре (три внутри blockquote'ов, один с отступом под list item'ом). Сборка подтверждает независимо: число блоков с токенами на сайте выросло ровно на 31.
  **2. `description` на каждой странице, которую индексирует `llms.txt`.** 31 рукописная страница получила строку. Из **34** страниц в скоупе гейта 33 несут frontmatter с описанием; единственное исключение — корневой `README.md`, который не является страницей сайта, так что ему нечего заполнять (ни записи в индексе, ни meta-тега). До подфазы описание было ровно у ОДНОЙ рукописной страницы — сгенерированные командные страницы несли `title`/`description`/`audience`/`status` изначально, их пишет генератор. На собранном сайте страниц, отдающих **своё** HTML-`meta`-описание, стало 28 → **60**; оставшиеся 60 — это 59 ADR'ов и 404, они падают на `site_description`, то есть на одно и то же предложение везде. Цена поля она же и его предел: три черновика переписаны ДО коммита, потому что каждый утверждал то, чего страница не поддерживает (секция enforcement'а в будущем времени, описанная как настоящее; команда, посчитанная в группу, к которой не относится; platform-scope-глагол, поданный как доступный на приложение). Описание — проза, и не проверяет его ничто, кроме ревью.
  **3. `llms.txt` / `llms-full.txt` / markdown-двойник рядом с каждой страницей.** Замер на собранном сайте: **119** опубликованных страниц, 59 из них под `adr/`; **60** в индексе, **119** в бандле, **119** двойников. Раскол по ADR'ам: **в бандл и в двойники — да, в индекс — нет.** Каждый ADR описывает мир на день ратификации (ровно поэтому drift-гейт держит их вне скоупа), и это половина всего, что публикует сайт, — индексировать их значило бы похоронить гайды: модели, которой отдали весь корпус, они нужны; модели, которой отдали карту, — не должны попадаться по дороге. Две формы, которых дизайн не предвидел: индексу понадобилась секция **`Other pages`** (две опубликованные страницы лежат в `not_in_nav`, и чисто nav-овый индекс молча бы их потерял; с секцией индекс ПОЛОН по опубликованным не-ADR-страницам — это и позволило написать сторожа как полноту, а не как переписанный список имён групп), и вложенные nav-секции несутся **префиксом ярлыка**, а не расплющиваются, потому что расплющенная *Reference* показывала две разные страницы как «Overview». Хук **роняет сборку**, если у индексируемой страницы нет `description`: план называл это контрактом, но не обеспечивал ничем.
  **4. Четвёртый проход в `scripts/docs-check.sh`.** mkdocs не знает, что эти три артефакта должны были появиться, так что переставший писать хук оставляет зелёную сборку и опубликованный сайт со сломанным машиночитаемым слоем. Проход делает **десять** утверждений: индекс есть и называет лицензию, его ссылки абсолютны, каждая резолвится в страницу, которая на сайте ЕСТЬ, каждая опубликованная не-ADR-страница в индексе ПРИСУТСТВУЕТ, бандл есть и держит по записи на страницу, и запись эта с телом, а не голый заголовок, названный двойник существует, и число двойников равно числу страниц. Все ожидания **выводятся из только что собранного сайта** — ни одного переписанного списка страниц, поэтому завтрашняя страница покрыта без правки скрипта.
  **СНЯТО/ОТЛОЖЕНО — оба пункта той же формы, на которой трек уже обжигался:** **`since` во frontmatter СНЯТ.** Это ровно то, что провалилось у `verified-by` подфазой раньше: per-page-утверждение о версии, которое НЕЧЕМ проверить — его не читает ни один гейт, на нём не падает сборка, и читатель не отличит актуальный `since` от верного два релиза назад; пишется один раз при авторстве и тухнет молча. Требовать его = изготовить по одному непроверяемому утверждению на страницу, то есть ровно тот класс дефекта, ради удаления которого вся система и строится. Контраст, который вопрос и решает, живёт в этом же репозитории: `since=` в ИСКЛЮЧЕНИИ остаётся, потому что гейт резолвит тег в дату коммита и обнуляет исключение через 180 дней. Дело не в имени поля, а в том, может ли что-то в дереве назвать утверждение неверным; версию, если она нужна странице, называют в ПРОЗЕ, где её видит читатель и спрашивает ревьюер. `audience` выживает по тому же тесту с другой стороны — он ВЫВОДИМ (frontmatter → nav-группа → группа ближайшего каталога-предка → `general`), поэтому опционален, а не обязателен. **`<llm-only>` / `<llm-exclude>` ОТЛОЖЕНЫ** — замер: **ноль мест использования** во всём репозитории. Естественный дом для них — проход markdown-двойника, а он теперь существует, так что добавить их позже = горсть строк против РЕАЛЬНОГО места использования, а не механизм, угаданный заранее (именно так система, разобранная в §Context ADR'а, и набрала машинерию, которую не гонял ни один CI-джоб). То же самое записано в самом хуке про `--8<--`-инклюды (двойник несёт строку инклюда, а не содержимое): тоже ноль мест использования сегодня.
- [x] **(f) Информационная архитектура** *(= W5)*. Ветка `feat/2.19f-information-architecture`, план `docs/superpowers/plans/2026-08-19-docs-2.19f-information-architecture.md`; ADR 0057 получил amendment по факту поставки. **Ни релиза, ни монорепо-тега:** `cli/Cargo.toml` не тронут (0.2.44), чарт/оператор/cue-cmp не двигались. Rust всё же правился, и это стоит назвать точно, потому что первая редакция этой строки утверждала обратное и была опровергнута собственной веткой: doc-комментарий в `cli/platform-cli/src/cli.rs` говорил «later sub-phases» — внутренняя координата, которую пользователь читает в `apprafter --help`, — и его переписали, отчего байт-сверяемый `commands.json` сдвинулся на строку (гейт этого и требует, регенерация в том же коммите). Плюс комментарии в `cli/docsgen`, называвшие переименованные страницы (комментарий, указывающий на несуществующий файл, — ровно тот класс дефекта, ради которого весь этот гейт и строился).
  **1. Доки перестали говорить с инсайдерами.** Внутренние координаты роадмапа («в фазе 8.2»), коды подфаз и указатели в `spec.md` переписаны в терминах читателя либо удалены там, где предложение и без них полное; где спецификация действительно и есть ответ — абсолютный GitHub-URL, и **само предложение говорит, что это roadmap репозитория**, чтобы читатель понимал, что уходит из документации. Число не записываем — записываем команду: `git ls-files -- 'docs/*.md' | grep -vE '^docs/(adr|changelog|measurements|superpowers)/' | xargs grep -nEi 'phase[- ]?[0-9]|\b[0-9]+\.[0-9]+[a-z]\b|\bplan\.md\b|\bspec\.md\b|\bM[0-9]|track [ab]\b|sub-?phase|plan item'` даёт **36** на `fa3472e` и **7** после корректировок ревью. **Паттерн РАСШИРЕН по итогам ревью** — первая его версия (`\bphase [0-9]` + три литерала) давала 25 → 7 и пропускала мимо себя десять инсайдерских координат, записанных иначе (см. блок корректировок ниже). Эти семь — осознанные и все разные: четыре абсолютных URL-цитаты спецификации; одна — `contributing/documentation-gate.md`, где `spec.md` назван **путём репозитория** в таблице путей, которые гейт исключает (https-ссылка заставила бы страницу описывать собственный скоуп в терминах, которых она не использует); и две — link-таргеты сгенерированного референса на страницу команды `apprafter plan`, то есть **ложное срабатывание паттерна, а не утечка**. Команда осознанно ограничена `docs/`: `README.md` входит в корпус гейта, но не является страницей сайта, и ссылки на роадмап там для читателя РЕЗОЛВЯТСЯ — человек на титульной странице репозитория может открыть `plan.md`.
  **2. Две страницы-заглушки удалены, а не «разрешены на месте».** `architecture/index.md` и `concepts/index.md` открывались «**Status:** stub», отправляли читателя в файл, которого сайт не несёт, и занимали два из девяти top-level-слотов nav. Страница, существующая только чтобы сказать «меня ещё нет», хуже 404: 404 хотя бы не стоит клика. Nav: **9 top-level → 6**.
  **3. Единственную ценную таблицу ПЕРЕСОБРАЛИ, а не перенесли.** План велел перенести CRD-таблицу концептов в `docs/reference/index.md` на основании «она верна сегодня». Она не была верна: против CRD, которые реально ставит Helm-чарт оператора, она называла четыре объекта, не имеющих CRD вовсе (`AccessGrant`, `ExternalSurface`, `ServiceProviderPlugin` и `Infrastructure` — последний вообще не кластерный объект ни в одной фазе, а локальный манифест, который парсит CLI), и теряла четыре поставленных (`PlatformStack`, `RetainedClaim`, `SharedVolume`, `SourceCredential`). Перенесена ФОРМА таблицы; строки выведены из шаблонов чарта, назначение каждого — из docstring'а его CUE-схемы. Перенести как есть значило бы повысить ошибку заглушки до статуса референса.
  **4. Семь переименований через `git mv` + `Public ingress` свёрнут в operator-секцию.** «walk» — слово ЭТОГО репозитория для e2e-скрипта (`e2e/needs-pg-walk.sh`); на сайте это был заголовок и URL, которые читателю нечем интерпретировать. Страницы названы по тому, что читатель получает (`postgres.md`, `redis.md`, `persistent-disk.md`, `egress-policy.md`, `connect-a-git-repository.md`). Две страницы public-ingress переехали КАТАЛОГОМ, а не только nav-строкой: оставить `/public-ingress/` под секцией «Operator Guide» — ровно то расхождение, ради устранения которого подфаза и существует. `license.md` и `contributing/README.md` сняты с `not_in_nav` в реальные позиции nav (лицензию посетитель ищет по имени). **Имена `e2e/*-walk.sh` сохранены** — это то, что поставлено, `code_paths`-флор гейта их резолвит, и там слово верное; неверным было одолжить его читателю.
  **5. Карта редиректов НЕ построена — решение с замером, а не недосмотр.** Редиректить не от чего: ни один URL этого сайта никогда не был публичным (сайт не опубликован, ни один workflow его не публикует, лендинг рендерит «Soon» из пустого `docsUrl`; `docs.apprafter.dev` теперь стоит в `mkdocs.yml` — см. корректировку `site_url` ниже — но никто его не отдаёт). Запись отображала бы URL, которого никто никогда не держал, в URL, до которого пока никто не может дойти. **Триггер назван явно: первая страница, переехавшая ПОСЛЕ публикации (2.19g), требует записи**, а `mkdocs-redirects` уже лежит в python-окружении флейка — это блок конфига, а не смена зависимости. Один класс URL публичным БЫЛ и никакой картой редиректов не обслуживается в принципе: относительные ссылки `README.md` в `docs/` — это GitHub-blob-URL'ы, куда плагину MkDocs не дотянуться; единственное лекарство — правка README тем же коммитом, что и переименование (сделано).
  **И безопасными переименования делает НЕ census.** Все его счётчики — тоталы, поэтому семь переименований оставили `pages` неподвижным: для census'а переименование и удаление неразличимы. Различает их `mkdocs build --strict` с валидацией ссылок **и якорей**, который падает на первой же входящей ссылке или заголовочном якоре, названном с обеих сторон. Ревьюабельным перенос URL делает линк-валидатор, а не census.
  **Census:** `pages` 34 → 32 (ровно два удаления), `identifiers` 236 → **238**; остальные шесть счётчиков не двинулись. Гейт поймал РЕАЛЬНУЮ потерю: переписывание списка ссылок в operator-индексе снесло идентификатор `needs.pg` вместе с текстом ссылки, где он сидел, и `identifiers` вернулся 235 против коммитнутых 236 — утверждение вернули (и лучше поставили: список теперь называет поле за каждым из трёх гайдов), а не занизили число под факт.
  **Из формулировки ADR НЕ сделан раскол «contributor walks vs user guides» — раскалывать нечего.** Каждая из этих страниц описывает задачу владельца кластера, то есть оси contributor/user, по которой их можно было бы разрезать, там просто нет. Контрибьюторскими были СЛОВАРЬ и несколько секций, и убран/понижен именно он. (Замер, которым это обосновывалось раньше, был НЕВЕРЕН — считался `apprafter\s+[a-z]`, то есть и упоминания в прозе; внутри fence'ов четыре dependency-гайда доминированы `kubectl`, а не `apprafter`. См. блок корректировок ниже.) Ось operator/developer (кто владеет кластером vs кто шипит приложение) замером держится и сохранена.
  **Три per-item-замера плана НЕ воспроизвелись** (корпусные счётчики воспроизводились точно — не воспроизводились именно утверждения о содержимом): (1) «две ссылки на `plan.md` — в СГЕНЕРИРОВАННОМ референсе, значит это clap-doc-comment, и его читают в `--help`» — такого doc-comment'а нет: `grep -c 'plan.md' docs/reference/cli/commands.json` даёт 0, `apprafter --help` не содержит строки вовсе, а обе строки — markdown-link-таргеты на реальную страницу `docs/reference/cli/plan.md`; следование букве плана заставило бы гоняться за фантомом и, возможно, править посторонний внутренний комментарий ради движения числа; (2) CRD-таблица «верна сегодня» — см. пункт 3; (3) «12 внутренних кросс-ссылок + 1 README» — сильно занижено; число не записываем (оно уже было записано неверно один раз), записываем команду: `git grep -nE '\]\((\./)?(\.\./)*(docs/operator-guide/|operator-guide/|public-ingress/)?(gitops-walk|needs-pg-walk|needs-redis-walk|needs-disk-walk|needs-networkpolicy-walk|cloudflare-origin-cert|connect-a-domain)\.md' fa3472e -- . | grep -v '^fa3472e:docs/changelog/'`. Греп самого плана не видел ссылок в том же каталоге (`](./gitops-walk.md)`, `](needs-pg-walk.md)`) и вовсе не покрывал `public-ingress/`.
  **Известные дыры, названные, а не замазанные:** концептуальной страницы на сайте больше нет вообще (вся концептуальная часть — таблица на референс-странице; это честнее двух извинений в лучших слотах nav, но меньше того, что подразумевает ссылка с лендинга в 2.19g — «что это такое» пишется в 2.19i, третья заглушка ответом не является); `Infrastructure` теперь НАЗВАН на референс-странице и не документирован нигде (ближайшая поверхность — строка `APPRAFTER_MANIFEST` в `docs/reference/environment.md`) — гайд в 2.19i; **nav** operator-guide остался плоским списком из 17 записей (осознанно: группировка nav — это поведение `navigation.sections` и, возможно, сегменты URL, а ремит подфазы — устаканить URL'ы, а не импортировать docs-фреймворк); при этом ИНДЕКС секции по итогам ревью переписан в карту с группировкой по задачам, потому что как карта он не работал — линковал 11 страниц из 16.
  **КОРРЕКТИРОВКИ ПО ИТОГАМ ТРЁХ РЕВЬЮ (first-time visitor / honesty / adversarial).** Общая форма всех находок одна: **паттерн переписи — не чтение**. Регексп свипа сам себе задал критерий успеха, и четыре документа записали его результат как полноту. Это ровно P1 — ожидание, выведенное из той же стороны, которую проверяют. **(1) Десять инсайдерских координат уцелели**, каждая записана иначе, чем видит паттерн: `Phase-4`/`Phase-8.5` (через дефис — `phase\s+[0-9]` их не берёт), `M3 target`, `M2+`, `Track A`, `Track B 1.70`, `plan item 1.80`, «later sub-phases» в clap-doc-комментарии (а он уходит в `apprafter --help`, `commands.json` и две сгенерированные страницы) и две строки с «walk» как существительным про документ, о котором читатель не слышал. Одна из них стояла тремя строками ниже blockquote'а, который этот же свип и почистил, — страница противоречила собственной уборке. Все переписаны в терминах читателя (не подменены другой внутренней координатой); паттерн расширен ПОСЛЕ чтения, а не вместо него; `docsgen-generate` прогнан тем же коммитом; **бампа версии и тега по-прежнему нет** — `cli/Cargo.toml` бампается под РЕЛИЗНЫЙ тег в том коммите, что его режет, а правка help-строки требует регенерации `commands.json`, а не бампа. **Чтение нашло то, чего не берёт и расширенный паттерн:** `DoD checklist` как пользовательский заголовок на четырёх страницах, `MANDATORY: psql DROP assertion` и два его брата, и `## Platform-CLI coverage` с «this guide exercises every shipped `platform-cli` subcommand … `kubectl` are sanity-only supplements» — имя КРЕЙТА вместо имени продукта и словарь walk-дисциплины в заголовках трёх гайдов. **(2) Замер command-dominance был ложным** и был ЕДИНСТВЕННЫМ заявленным основанием решения: считался `apprafter\s+[a-z]`, то есть и упоминания в прозе. Внутри fence'ов (то, что читатель реально выполняет) `postgres.md` — 40 `kubectl` против 10 `apprafter`, `redis.md` 39/10, `persistent-disk.md` 36/10, `egress-policy.md` 17/5. Вывод (не раскалывать) устоял на ДРУГОМ основании — все эти страницы про задачу владельца кластера; ложное доказательство удалено, истинная форма записана: dependency-гайды `kubectl`-доминированы, потому что наблюдения, которым они учат, — это `kubectl`-чтения. **(3) `ServiceProvider` помечен «пишет Operator»** — ни одна подкоманда `apprafter` его не создаёт, все сидированы umbrella'ой (`platform-stack/cue/service_providers.cue`), а четыре другие страницы сайта уже говорят «the **seeded** `pg-integrated`». Ячейка перенесена из заглушки дословно, то есть «пересборка таблицы» покрыла набор СТРОК, но не ячейки; остальные четыре «Operator» пересобраны поиском писателя в дереве, каждая теперь называет команду/компонент. **(4) `site_url` кодировал дизайн, который ADR 0057 (решение 8) ОТВЕРГ** — `https://apprafter.dev/docs`, путь на origin'е лендинга. Это не косметика: значение запекается в абсолютные URL'ы `llms.txt`, `llms-full.txt`, 117 markdown-двойников и `sitemap.xml`, то есть отвергнутый дизайн публиковался в четырёх классах артефактов. «URL'ы устаканены» было НЕВЕРНО, пока это стояло. Теперь `https://docs.apprafter.dev/`; пересобрано, артефакты последовали. **(5) Три ссылки на переименованные страницы уцелели ВНЕ `docs/`** — живая markdown-ссылка в `e2e/README.md`, комментарий в `cli/docsgen/tests/invocation_test.rs` и — худшее — `e2e/lib.sh`, печатавший мёртвое имя страницы оператору, у которого только что упал memlock-preflight, прямо перед `exit 2`. Это опровергает правило, которое ADR институционализировал («переименование — проблема `mkdocs --strict`, а не грепа; доверяй сборке»): корпус гейта — `git ls-files -- docs README.md`, `--strict` не видит ничего вне `docs_dir`, в `docs.yml` нет триггера на `e2e/**`. Правило исправлено на верное, каталоги названы поимённо, команда свипа записана. **(6) Два входа не выполняли работу, ради которой существуют:** operator-индекс линковал 11 страниц из 16 (в т.ч. `backup-restore.md` — поставленный гайд на 650 строк — не линковался вовсе, а слово «backups» встречалось дважды и оба раза внутри списков непостроенного) → переписан в карту по задачам с одним блоком «not documented yet»; operator-quickstart отвечал на «поставь это на мой сервер» через `nix develop` + `cargo install --path cli/platform-cli`, т.е. предполагал checkout репозитория → теперь ведёт релизным бинарником. Туда же: `## Step 0 — run the k3d e2e first` открывал четыре dependency-гайда, предписывая читателю сайта прогнать наш собственный e2e как обязательный гейт → перенесён в подвал как опциональная заметка для контрибьюторов. **(7) Мелочи:** `docs/index.md` заявлял «generated reference for every command and **object**» (сгенерированного object-референса нет — это net-new оверклейм этой же ветки); `VERSION=v0.2.27` в dev-quickstart отставал на 17 релизов → заменён командой, которая резолвит последний релиз (P2: удаляем цифру, оставляем команду); `docs/adr/README.md` рендерил `# docs/adr/` как заголовок вкладки и открывался контрибьюторским процессом → «Architecture Decision Records» + `description` + индекс под лидом; контрибьюторская инструкция «не редактируй `docs/reference/cli/` руками» уехала с пользовательской референс-страницы в `docs/contributing/documentation.md`; секционные индексы используют заголовки страниц вместо голых имён файлов; `contributing/README.md` стал списком ссылок вместо таблицы неликабельных code-span'ов; замер в докстринге `cli/docsgen/src/health.rs` перевыведен (точнее — цифры удалены, свойство оставлено), там же исправлена ссылка на страницу, с которой уехал `cli/docsgen/src/render.rs`.
  **Старые пути остаются названными в записях закрытых подфаз** — §1.15 и §1.82 (`gitops-walk.md`), §1.83e (`docs/public-ingress/cloudflare-origin-cert.md`), §1.83g (`docs/public-ingress/connect-a-domain.md`) и запись самой §2.19c (`needs-pg-walk.md` / `needs-redis-walk.md`): это исторические записи о том, что было поставлено ТОГДА, и они не переписываются (то же правило, по которому не переименовывается зашипленное). Актуальные пути перечислены здесь; переименования полностью — в `git log --follow` и в записи `plan-history.md`.
- [x] **(g) Публикация** *(= W6)*. Ветка `feat/2.19g-publication`, план `docs/superpowers/plans/2026-08-19-docs-2.19g-publication.md`; ADR 0057 получил amendment по факту поставки, решение 8 перестало быть «decided, not yet implemented». **CLI-патч-релиз; ни чарта, ни оператора, ни cue-cmp — и ответ ПЕРЕВЕРНУЛСЯ по ходу ревью, что записано в ту сторону, в которую он двигался.** Первая редакция утверждала «ни релиза, ни тега» и была верна для дерева без правок в `cli/`; ревью нашло, что шипнутый манифест не читается парсером самого CLI, и фикс лёг в `cli-core`. Перевывести: `git diff --name-only <base>..HEAD -- cli/ operator/ schemas/ platform-stack/ argocd-cue-cmp/` — всё, кроме `cli/`, пусто; `cli/` не пусто (`ApplicationExpose.port` стал `Option<u16>`), поведение `apprafter app add` меняется, поэтому `cli/Cargo.toml` бампнут 0.2.44 → 0.2.45 в том же коммите, а ветка несёт монорепо-патч-тег. `docs/reference/cli/commands.json` сдвинулся ровно на строку `cli_version` — это проекция бампа, а не движение поверхности команд; регенерирован тем же коммитом. Новый образ `ghcr.io/apprafter/docs` версионируется SHA коммита, а не git-тегом, так что публикация не заводит и собственного тег-стрима.

  **Софт готов, сайт НЕ отдаётся.** Это главное, что должна сказать эта запись: между веткой и читателем стоят пять ручных шагов, которых репозиторий сделать не может (пуш; проверка зоны; DNS-запись в Cloudflare; однократная регистрация приложения; `docsUrl` в CMS + придержанный лендинг-коммит). Раннбук `docs/operator-guide/publish-the-docs-site.md` написан так, чтобы средние три делались по нему без плана и без ADR.

  **1. Сборка живёт в workflow, а не в Dockerfile — решение с замером.** `docs-site/Dockerfile` — одна стадия над `caddy:2-alpine`, копирующая ГОТОВЫЙ `site/`; build-стадии в нём нет, и причина записана в самом файле, потому что это ровно то «улучшение», которое сделает следующий контрибьютор. `pip install mkdocs-material` внутри образа завёл бы вторую, незапиненную тулчейн-цепочку, которая производит опубликованный сайт, пока гейт валидирует собранный ИНАЧЕ; решение 2 ADR'а ввело единое `python3.withPackages` ровно против этого, и дрифт был бы невидим — обе сборки зелёные, различаются только опубликованные байты. Поэтому `release-docs.yml` гоняет `mkdocs build --strict` под `nix develop` и отдаёт результат в `docker/build-push-action`.

  **2. Релизный workflow гейтит СЕБЯ, а не полагается на `docs.yml`.** Workflow'ы, поднятые одним событием, независимы: `needs:` между ними нет, вывод чужой джобы никто не читает, так что пуш, роняющий гейт, доводит этот workflow до конца и публикует. Пути тоже расходятся именно в публикующую сторону — `docs-site/**` роняет релиз и в фильтре `docs.yml` не встречается вовсе. И `--strict` заменой не является: он ловит мёртвые ссылки, якоря, страницы вне nav и недостающие include'ы, но не ловит устаревший сгенерированный CLI-референс, утверждение, переставшее резолвиться против продукта, битый `llms.txt`/двойник и ссылку в `exclude_docs`'нутую страницу (mkdocs репортит её на INFO — ниже досягаемости `--strict`, и `scripts/docs-check.sh` грепает её отдельно). Поэтому релизная джоба гоняет `scripts/docs-check.sh` сама, делит rust-cache-ключ с `docs.yml` и чекаутится на `fetch-depth: 0` — `docsgen gate` старит исключения против реальных дат тегов.

  **3. Path-фильтр срабатывает на изменение ОПУБЛИКОВАННЫХ байтов, и это НЕ копия `exclude_docs`.** Список исключений перечитывается командой `sed -n '/^exclude_docs:/,/^\$/p' mkdocs.yml` и раскладывается натрое: внутренний changelog и `measurements/` — в негации (это и есть разряженный пункт Re-evaluation: они трогают `docs/` почти каждым коммитом и не меняют ничего, что видит читатель); `superpowers/` нет ни в одном списке, потому что дерево в gitignore и в диффе пуша появиться не может (паттерн под недостижимый случай — мёртвый конфиг); а `hooks/` и `reference/cli/SUMMARY.md` из сайта исключены, но релиз ронять ОБЯЗАНЫ — хуки на сборке ИСПОЛНЯЮТСЯ и формируют каждую страницу, а `SUMMARY.md` и есть nav всех опубликованных страниц. Фильтр, транслитерированный из `exclude_docs`, сделал бы правку хука и правку nav непубликуемыми молча. `mkdocs.yml` и `flake.nix`/`flake.lock` ронят релиз (бамп темы переписывает HTML каждой страницы и меняет отпечатки ассетов, пока в `docs/` не двигается ничего); `docs-site/**` ронит (Caddyfile запечён в образ — иначе правка кэш-заголовка доехала бы до прода лишь тогда, когда кто-то следующий раз тронет страницу), а `docs-site/apprafter/**` вырезан обратно (манифест Argo CD читает из конфиг-источника кластера; он не вход образа, и его правка не должна чеканить новый digest). Продуктовый исходник отсутствует намеренно: он меняет то, что гейт ПРОВЕРЯЕТ, а не то, что сайт СОДЕРЖИТ, а обязательная следом регенерация трогает `docs/` и релиз роняет. **Связка `exclude_docs` ↔ фильтр названа и НЕ обеспечена гейтом:** удаление записи из `exclude_docs` публикует страницу, правки которой больше не режут релиз, и это не проверяет ничто.

  **4. Кэш-правила выведены из того, что mkdocs РЕАЛЬНО кладёт.** Отпечатками помечены ровно бандл, search-воркер и две таблицы стилей (`<name>.<8-hex>.min.<css|js>` плюс `.map` к каждому), и это **не весь** `assets/`: фавиконка и языковые стеммеры lunr отпечатка не несут — перепроверяется `find site/assets -type f | grep -vE '\.[0-9a-f]{8}\.min\.'`. Поэтому лендинговое сплошное `header /_astro/* … immutable` не переносится, хотя ТАМ оно верно (Astro хеширует каждое имя, которое отдаёт): копирование запинило бы мутабельные URL'ы на год, и апгрейд темы, поменявший стеммер, не доехал бы до читателя, у которого закеширован старый. Вместо этого три непересекающихся матчера: `path_regexp` на форму отпечатка → immutable; два неотпечатанных поддерева → сутки; всё остальное → 300 с. Якорь длины `{8}` несущий, а не декоративный: под свободное `[0-9a-f]+` подпадают `lunr.da.min.js` и `lunr.de.min.js` (`d`, `a`, `e` — hex-цифры). Всё под `assets/`, не попавшее ни в одно правило, намеренно проваливается БЕЗ `Cache-Control`: недокэшировать — поправимо, запинить мутабельный URL на год — нет. HTML держит 300 с, а не лендинговый час, потому что `search/search_index.json` отпечатка не несёт и не должен переживать страницы, которые индексирует. `.md` принудительно отдаётся как `text/plain`: базовый образ через `mailcap` подсовывает `text/markdown`, который браузер предлагает СКАЧАТЬ, обессмысливая двойники, — вход, который этот репозиторий не пинит и не тестирует, поэтому заголовок ставится явно.

  **5. Новому поддомену не нужна ни новая зона, ни новый сертификат — перевыведено, а не процитировано.** `platform-stack/cue/render_tool.cue` на каждую запись `gateway.allowedDomains` печатает ДВА HTTPS-листенера, `https-apex-<san>` и `https-wild-<san>`, и оба называют один и тот же секрет `importedCertRef`: одна регистрация, один сертификат, оба хоста. `render_httproute` оператора ставит `parentRefs[0]` на Gateway `platform` порт 443 БЕЗ `sectionName`, так что маршрут цепляется по совпадению hostname и никому не надо сообщать, что wildcard-листенер существует. Предел стоит знать: правило покрытия — РОВНО одна метка в обоих слоях (`hostname_covered_by_zone` принимает апекс или префикс без точки, `hostname_matches_domain` в CLI согласен), так что `docs.apprafter.dev` покрыт зоной `apprafter.dev`, а вложенный хост — уже нет. Поддомен на один уровень бесплатен, глубже — новая зона.

  **6. Лендинг-переключатель — ШАГ ОПЕРАТОРА, а НЕ придержанный коммит.** Сначала он был сделан отдельным коммитом — по посылке «коммит можно не пушить». Посылка неверна: `.github/workflows/landing-autotag.yml` срабатывает на ЛЮБОМ пуше в дефолтную ветку, чей диф трогает `landing/**`, бампает патч свежайшего `landing-v*`, пушит тег и диспатчит `release-landing.yml`, который публикует `ghcr.io/apprafter/landing-web` и `:<tag>`, и `:latest` — а манифест лендинга смотрит именно на `:latest`, который оператор перерезолвит в дайджест на каждом reconcile. То есть смёржить такой коммит = задеплоить его, без отдельного одобрения; плюс он лежал НЕ на конце ветки, так что «выкинуть» его значило бы ребейзить закрывающий коммит поверх. Коммит удалён с ветки (`git rebase --onto`), `docsUrl` вернулся в `""`, а порядок (сначала сайт отвечает — потом ссылка) записан шагом 5 раннбука. Содержательная часть, которая от этого не изменилась: `landing/web/src/data/fallback/siteSettings.json` — это РЕЛИЗНЫЙ путь (образ собирается с `LANDING_USE_FALLBACK=1`), а глобал Payload — превью-путь, значит ставить надо ОБА; `Header.astro` подставляет `<githubUrl>#readme` и вешает бейдж «Soon», только пока `docsUrl` пуст; значение байт-идентично `site_url` из `mkdocs.yml`, а его хост равен `expose.hostname` в `docs-site/apprafter/Application.cue`.

  **Находки, о которых сообщено и которые НЕ правились здесь:** (а) лендинговый `try_files … /404.html` переписывает неизвестный URL в существующий файл, так что `file_server` не на чем упасть и **любой** неизвестный URL отвечает **200** с телом 404-страницы (мягкий 404 — краулеры индексируют его как настоящую страницу) — перемерено на реальном `landing/web/Caddyfile` поверх реально собранного `dist`; docs-Caddyfile fallback не несёт и отдаёт настоящий 404. **Почему не правится здесь — тот же механизм, что и в пункте 6:** любой коммит, трогающий `landing/**` и доехавший до дефолтной ветки, автотегает и публикует лендинг, так что однострочный фикс мимоходом в докерской подфазе означал бы незапланированный прод-деплой ДРУГОГО сайта. Это работа того, кто следующим осознанно меняет лендинг — записано прямо в открытом пункте «Migration лендинг-манифеста» (§1.83b, PART 0.6), чтобы находка ждала там, куда этот человек придёт. (б) `scripts/lint-cue.sh` вет'ит `schemas/`, `platform-stack/cue/` и `examples/` — и НЕ трогает `docs-site/` и `landing/`, то есть оба деплоимых манифеста не валидирует никто; это не гипотеза: `cue vet ./landing/web/apprafter` проходит, а `cue fmt --check` на той же директории падает, называя оба файла, — так выглядит непокрытый путь через год. (в) SPDX-проверка не достаёт ни до `docs-site/**`, ни до `landing/**` (в `PATTERNS` нет ни глоба под эти деревья, ни общего `**/*.cue`), так что заголовки на новых файлах верные и необеспеченные. (г) `scripts/docs-artefacts-check.py` падает трейсбеком на НОВОЙ странице, которая написана, но ещё не застейджена (`source` строится из `git ls-files`, `published` — из сборки), причём собственный страж `orphan_pages` под этот же случай стоит НИЖЕ строки, которая первой разыменовывает недостающий ключ.
- [x] **(h) CLI UX** *(= W7)*. Ветка `feat/2.19h-cli-ux`, план `docs/superpowers/plans/2026-08-19-docs-2.19h-cli-ux.md`; ADR 0057 получил amendment по факту поставки. **CLI-патч-релиз `v0.2.46`; ни чарта, ни оператора, ни cue-cmp** — `git diff --name-only <base>..HEAD -- cli/ operator/ schemas/ platform-stack/ argocd-cue-cmp/` пуст везде, кроме `cli/`, а шипнутый бинарь меняется дважды: новая команда `completion` и секция `Examples:` в `--help` у 75 команд. `cli/Cargo.toml` бампнут 0.2.45 → 0.2.46 тем же коммитом, `commands.json` сдвинулся ровно на строку `cli_version` (регенерация тем же коммитом).

  **Дефект, с которого начался весь трек, был закрыт ДО этой подфазы — и это первое, что должна сказать запись.** Исходный запрос называл `apprafter secret seal` командой, у которой не описан `--namespace`. Он описан: `apprafter secret seal --help` печатает `-n, --namespace <NAMESPACE>` вместе с дефолтом, а doc-комментарий несёт ещё и последствие («the sealed blob only unseals as `<namespace>/<name>`» — ровно то, что кусается, см. память про namespace-футган). По всему дереву — **187 аргументов, 0 без описания, 0 команд без `about`**, и это перемерено на закрытии тем, что печатает САМ clap (свип по `-h` всех 97 help-страниц, скрипт целиком — в amendment'е ADR), а не проекцией `commands.json`; два счётчика сошлись с разных сторон. Закрыли это ранние walk-фиксы, а не трек. **Вклад этой подфазы — вторая половина запроса: примеры, и машинерия, которая не даёт сгнить обеим половинам.** У свипа есть тонкость, стоящая записи: clap печатает описание в ДВУХ раскладках (в той же строке или с отступом на следующей, когда help длинный), и парсер, знающий только первую, репортит на этом дереве пять ложных пустых — первая редакция свипа так и делала.

  **1. Страж — ПЕРВЫМ, примеры — вторым, потому что примеры жили в слепом пятне между двумя гейтами.** `docsgen check` байт-сверяет `docs/reference/cli/**` со свежим рендером: он доказывает, что страницы соответствуют исходнику, но НЕ что исходник верен — пример с опечаткой во флаге рендерится одинаково оба раза и проходит. `docsgen gate` это дерево осознанно исключает (им владеет `check`), так что чек, резолвящий `apprafter`-вызовы, ни одного примера не читает. Каждый гейт выводит ожидание из той же стороны, которую проверяет. 124 примера, написанные в эту щель, были бы 124 непроверенными утверждениями в артефакте, весь смысл которого — быть правдой. Страж (assertion C в `cli/docsgen/src/examples.rs`) показан падающим на заведомо неверных примерах ДО того, как написан первый настоящий, причём демонстрация шла с `docsgen generate` ПЕРВЫМ — байт-сверка была чистой, пока `docs/reference/cli/secret.md` публиковал `apprafter secret seal db-url --namesapce web`. Это и есть слепое пятно, показанное, а не описанное. **Попутная корректировка цитаты:** план этой подфазы ссылался на `scan::EXCLUDED`; там лежит `["docs/adr/", "docs/changelog/", "docs/measurements/"]` и CLI-референса нет — исключение сделано отдельным правилом по префиксу `render::DIR` внутри `scan::is_in_scope`. Вывод не изменился, цитата была неверна.

  **2. Примеры — структурная таблица, а не разделитель в `after_help`.** `pub const EXAMPLES: &[CommandExamples]` в `cli/platform-cli/src/examples.rs`, реэкспорт через фасад `docs_api`; бинарь рендерит её в `after_help`, `docsgen` читает структурно. Решающая причина не в том, что парсить прозу некрасиво: **парс, который ничего не нашёл, ПРОХОДИТ.** Поменяй разделитель, оберни блок, покрась его или напиши пример, содержащий разделитель, — и страж молча судит ноль записей, продолжая печатать OK; та же форма вакуумности, что и у чека, выводящего ожидание из проверяемой стороны. Отсюда же следствие: запись, которую страж прочитать не смог, — **находка, а не пропуск**. Пять классов: неразрешимый путь, неразрешимый флаг, запись без единого `apprafter`-вызова, пустая запись и пример, подшитый не к той команде (`apprafter app list` под `backup enable` — настоящий вызов и ложная страница; копирование соседа — самый вероятный способ такое написать). Алиасы резолвятся в канонический путь.

  **3. Покрытие: 124 строки примеров на ВСЕХ 75 видимых листьях.** Корень, 18 групповых узлов и 3 скрытых листа `auth` не несут ни одного — по правилу. Второй редакторский проход удалил 32 комментария и одну запись целиком: они пересказывали help флага, напечатанный шестью строками выше. Правило, которое выжило и записано на самой константе: комментарий остаётся только там, где делает читаемой голую или неоднозначную строку (`apprafter app add` без аргумента, `apprafter volume list` без `--namespace`) либо называет сценарий для комбинации флагов. Формы значений сверены с кодом, который их парсит, а не с памятью: `up-only`/`off` (`platform.rs:881`), `internet|internal|strict` (`platform.rs:673`), `pg|redis|disk` (`app_scaffold.rs:353`), `monolithic|sequential`, `solo|team|prod|regulated` (`cli-core/src/tier.rs`), а два примера `backup enable` — это РОВНО две легальные формы `construct_repo_url` (`backup.rs:224`), взаимоисключающие, поэтому ни один не смешивает `--endpoint` со схемным bucket'ом. SKU (`cx22`/`cx32`) взяты из собственного help'а CLI, а не выдуманы; `cpx*` из юнит-фикстур `apply.rs` НЕ подняты — это фикстуры строкового парсинга, а не утверждение о каталоге Hetzner.

  **4. Completions берут `clap_complete::Shell` как ТИП, а не локальный enum поверх него.** Локальный enum был бы вторым, руками поддерживаемым утверждением о множестве, которым владеет чужой крейт, — а `Shell` помечен `#[non_exhaustive]`, так что этот второй список молча замёрз бы на сегодняшних пяти. Все пять шеллов отдают скрипт, и каждый АССЕРТИТСЯ в `cargo test` через шипнутый бинарь (итерация по `Shell::value_variants()`, не по списку в тесте). Рецепты установки покрывают **bash, zsh, fish** — рецепт под конвенции, по которым никто здесь не ходил, был бы выдуман, а не написан; страница называет эти три и отсылает к `apprafter completion --help` за полным списком, чтобы документированное множество не разошлось с аргументом. Глагол `completion` в единственном числе — как у `kubectl`/`helm`/`argocd`/`k9s`; алиаса нет (did-you-mean clap'а сам отвечает на `completions`). Рецепты пройдены руками под изолированным `HOME` (bash 5.3.9 — `_apprafter` прогнан аргументами, которые bash даёт `-F`-функции; zsh 5.9 — `fpath`+`compinit`; fish 4.6.0), и прогулка нашла два апстримных поведения, записанных, а не обойдённых: **(а)** `#[command(hide = true)]` убирает `auth` из `--help`, но НЕ из completion-скриптов — `clap_complete` фильтрует только скрытые possible-values; не чинится, потому что clap не даёт удалить сабкоманду из собранного дерева, а пересобранный руками `Command` молча теряет то, что пересборка забыла; **(б)** значения ПОЗИЦИОНАЛА дополняют только bash и zsh — `apprafter completion <TAB>` под fish/elvish/PowerShell падает в дополнение по файлам.

  **5. Страж от гниения help'а пинит СВОЙСТВА, и один закоммиченный список — намеренно.** Полный снапшот каждой help-страницы падает на любом улучшении формулировки и регенерируется не глядя — хуже, чем никакого теста. Планка: **ревьюер диффа не заметит, что свойство сломано, а ломается при этом что-то вне диффа.** Прошли семь: у каждого видимого листа есть пример; у скрытой команды примера НЕТ (иначе `auth` возвращается и в `--help`, и в референс — отмена решения с дальней стороны); ни один пример не пуст и ни одна строка таблицы не обещает строк, которых у неё нет; у каждой команды есть `about`; у каждого флага и позиционала есть короткий help; алиасы, которые ПЕЧАТАЮТ гайды, доезжают до своей команды; и гайды всё ещё печатают каждый алиас, который таблица заявляет. Шесть из семи выводятся из clap-дерева на момент теста. **Седьмой — закоммиченный список, и это дизайн, а не срез угла:** вывести «какими алиасами пользуются гайды» из clap-дерева — ровно циклично (удали алиас `t`, и список из дерева просто перестанет его содержать, то есть чек пройдёт на несуществующем алиасе). Список — другая сторона, а седьмое свойство держит его честным против корпуса. Он ВЫВЕДЕН, а не угадан: alias-aware индекс из `commands.json` + обход всех `apprafter …`-токенов в `docs/**` даёт семь вызовов на пяти страницах и семь токенов — `t`, `ls`, `info`, `rm`, `kc`, `cb`, `up` (план называл пять — `t`, `kc`, `up`, `ls`, `rm`; два, `cb` и `info`, план не называл, и `apprafter volume rm` правильно НЕ попал: там `rm` — каноническое имя). Непокрытое названо: гайд, который НАЧНЁТ печатать новый алиас, в список сам не добавится — это ловит `docsgen gate`, резолвящий все вызовы в скоупе, включая алиасы; перевыводить множество внутри теста значило бы завести второй токенайзер вызовов, а этот трек уже видел, как два токенайзера расходятся.

  **6. ПЯТЬ пунктов исходного списка (h) НЕ построены, и ни один не снимается замером — каждый пропробован и является реальной дырой.** Список (h) называл восемь вещей; поставлены три (`EXAMPLES` + `after_help`, shell-completions, help-coverage-тест) плюс страж, которого список не называл. Не поставлены: **`secret list`** (`apprafter secret --help` показывает `seal`, `remove`, `help`); **namespace-мастер для `secret seal`** (в `commands/secret.rs` пикера нет, `--namespace` дефолтится в `apprafter-system` — тот самый футган); **`status.conditions[]` с remediation в `app status`** (`commands/app.rs` читает `/status/phase` и `Scheduled` у клейма, но `conditions[]` самой Application CR не читает НИКОГДА, хотя `operator-core/src/application.rs` их эмитит); **`requires = "select"` на `--namespace`** (атрибута `requires` в `cli/platform-cli/src/cli.rs` нет вообще, `export` и `backup create` до сих пор пишут «Ignored unless `--select` is also passed» прозой); **`app open --yes`** (`commands/app_open.rs` спрашивает `Continue anyway?` на нездоровом приложении и в неинтерактивном шелле ЖЁСТКО отказывает — выхода для CI нет). У первых двух есть триггер внутри трека: гайд по sealed-secrets в 2.19i не сможет рассказать, как посмотреть, что засилено и в каком namespace, не имея `secret list` и мастера; гайд по `app status` не покажет remediation, которую команда не печатает. Оставшиеся два — изменения СЕМАНТИКИ команд, требующие собственного решения, а не докерской подфазы: `requires = "select"` превращает молча игнорируемый флаг в ошибку парсинга у `export` и `backup create` (ломает любой скрипт, передающий `--namespace` в одиночку), а `app open --yes` меняет то, что позволено неинтерактивному шеллу.

  **Находка, о которой сообщено повторно и которая НЕ правилась:** `scripts/docs-artefacts-check.py` снова упал трейсбеком (`KeyError: 'reference/cli/completion/'`) на НОВОЙ странице, написанной, но ещё не застейдженной, — тот же дефект, что записан находкой (г) в 2.19g. Стейджинг лечит; репортится второй раз, по-прежнему не починено.
- [x] **(i) Контент** *(= W8)*. Ветка `feat/2.19i-missing-guides`, план `docs/superpowers/plans/2026-08-20-docs-2.19i-the-missing-guides.md`; ADR 0057 получил amendment по факту поставки. **CLI-патч-релиз `v0.2.47`** — не ради гайдов, а ради одного `about` (см. ниже): шипнутый бинарь меняется, `cli/Cargo.toml` бампнут 0.2.46 → 0.2.47 тем же коммитом, `commands.json` сдвинулся ровно на строку `cli_version`. Ни чарта, ни оператора, ни cue-cmp.

  **«~15 гайдов» — оценка, которую семь подфаз никто не перемерял, и она НЕВЕРНА: гайдов ПЯТЬ.** Перемерено по дереву команд, а не по оценке (команда — в amendment'е ADR 0057). **Сама команда из плана подфазы тоже была дефектной и давала ТРИ разных ответа на один вопрос:** корпус ключевался по `p.name`, поэтому страницы с одинаковым базовым именем затирали друг друга (`docs/index.md` / `dev-guide/index.md` / `operator-guide/index.md` схлопываются в одну запись, как и два `quickstart.md`), а какая уцелеет — порядок вставки в dict. План намерил **12** на `0a2ba48`, повторный прогон его же команды на том же дереве дал **11**, по полному пути — стабильные **10**. Двое лишних у плана — `apprafter target show` и `apprafter upgrade-tier`, оба уже упомянуты на страницах, проигравших коллизию базового имени. Из стабильных 10 трое — осознанные отсутствия (ниже), так что реальной работы было **семь неописанных листьев**, и они ложатся на пять поверхностей: `dev-guide/resources-and-autoscaling.md` (`platform autoscale set|show`), `dev-guide/secrets.md` (`secret remove`), `dev-guide/environments.md` (`platform env set|show`), `operator-guide/choosing-the-machine.md` (поднимает capability с одного упоминания до страницы) и — двумя расширениями, а не новой страницей — `operator-guide/target-store.md` (`target show|rename|remove`) + `dev-guide/image-iteration.md` (`app rollback`).

  **ТРИ команды остаются недокументированными ОСОЗНАННО, и это находка, а не дыра:** `apprafter login` и `apprafter upgrade-tier` — обе «NOT IMPLEMENTED» в собственном `about`, `apprafter plan` — скелет над `DryRunProvider`. Гайд на любую из них описывал бы будущее. Они СНОВА всплывут в любом будущем прогоне инвентарной команды — не писать. `upgrade-tier` при этом из вывода команды выпал, потому что теперь НАЗВАН отсутствующим в `docs/operator-guide/index.md` (там же исправлена формулировка «`apprafter upgrade-tier` exists и safety-семантика идёт через `MigrationPlan`», читавшаяся как «capability есть, нет только гайда»): чек — тест на УПОМИНАНИЕ, а не на обучение, и ровно здесь эта разница кусается.

  **Один дефект, который инвентаризация вскрыла и который починен, а не задокументирован:** `about` у `apprafter plan` обещал «Show the diff between the desired state and what is live», тогда как `commands/plan.rs` строит `DryRunProvider` и провайдера не читает вовсе. Переписан caveat-first (генерируемый референс поднимает первое предложение в overview-таблицу и в `description` страницы, так что оговорка во втором предложении невидима ровно там, где читатель решает); указывает на `apprafter apply` как на место, где сравнение реально живёт, и на `target show` / `platform status` / `app status` как на read-only-виды. `apprafter status` НАМЕРЕННО не назван — его собственный `about` говорит, что он скелет и кластера не трогает.

  **Четыре расхождения между гайдами, написанными параллельно, найдены и сведены на этапе разводки:** (1) `--env` на неоднозначном приложении — таблица в `environments.md` говорила «asks», её же проза двумя секциями ниже — «errors»; `single_deployment_or_guidance` возвращает `Err`, таблица исправлена; (2) `metadata.namespace`, запиненный в мультиэнвовом примере, — и `application-cue.md`, и `resources-and-autoscaling.md` демонстрировали ровно ту ловушку, о которой предупреждает новая страница (запиненный namespace рендерит один и тот же объект на каждый env, CMP штампует `spec.environment` и лейбл, но CR НЕ переименовывает), у обоих убран; (3) пять правил per-field merge были выписаны дважды почти дословно — канон оставлен в `application-cue.md` (это семантика поля, а страница — филд-референс), `environments.md` сжат до одного предложения + ссылка; (4) `examples/applications/parser.cue` описан в индексе как «worked multi-environment manifest», хотя пинит `metadata.namespace: "demo"`, а его `dev`-оверрайд ставит `expose.network: "vpn"`, который вебхук отвергает — указатель убран (сам файл — `cue vet`-фикстура, не тронут).

  **Оба индекса секций перестроены в карты:** `dev-guide/index.md` был плоским списком из шести пунктов, девять бы никто не читал — сгруппирован по задаче тем же приёмом, каким 2.19f перестроила индекс operator-guide.

  **Census вырос по каждой оси и не упал ни по одной** (`0a2ba48` → закрытие): 33 → 37 страниц, 427 → 566 инвокаций, 248 → 322 идентификаторов, 2 → 5 полных CUE-документов в 17 → 22 `cue`-fence'ах, 104 → 104 путей репозитория, 70 → 76 цитат ADR; LLM-артефакты 60 → 64 / 119 → 123 / 119 → 123. **Exemptions остались 2** — пяти новым страницам не понадобилось ни одного эскейпа. `code_paths` не сдвинулся ВООБЩЕ — это правило «читатель без чекаута» в виде числа: где нужен файл репозитория, страницы дают абсолютный GitHub-URL. Коммитнутый пол при этом успел отстать от живого замера (`32/398/246/2/17/91/68/2`, писался до 2.19h) — он ратчетится только на падение, — поэтому перезаписан `docsgen metrics` тем же коммитом: без этого новые страницы можно было выпотрошить бесплатно.

  **Записано, но НЕ починено (каждое — с пробой, не списано):** help у `ServerTypeNotSelected` называет несуществующее поле манифеста `nodes[0].kind` (ключ — `type`; `kind` — только имя Rust-поля под `serde(rename)`) — правка в `cli/cli-core/src/error.rs` сдвинула бы `commands.json` второй раз в подфазе, чья правка CLI должна быть одним `about`; `cli/platform-cli/src/examples.rs` в пяти местах использует `cx22`/`cx32`, которые собственный changelog репозитория объявляет снятыми, и без токена провайдера вопрос не решается — поэтому `choosing-the-machine.md` не называет НИ ОДНОГО типа машины и учит пикеру как списку; `docs/operator-guide/troubleshooting.md` под `server_type_unavailable` советует передать `--server-type` «вместе с `--region`» на команде провижининга, где `--region` не существует (гейт это пропускает, потому что два флага нигде не написаны в одном вызове — живой пример «гейт проверяет имена, а не истину»).

  **Триггер двух из пяти непостроенных пунктов 2.19h сработал не так, как та запись предсказывала:** она ждала, что гайд по sealed-secrets не сможет рассказать, что засилено и в каком namespace, без `secret list` и мастера. Гайд отвечает на оба вопроса — через `kubectl get sealedsecrets --all-namespaces` и листинг ключей, — что честно, но это `kubectl`-ответ на странице, весь предмет которой — first-class CLI-задача. `secret list` и мастер по-прежнему не построены, и гайд теперь не блокер, а доказательство спроса.
- [x] **(j) Закрытие** *(= W9)*. Прогулка по КАЖДОМУ гайду релизным бинарём 0.2.47: четыре ходока по непересекающимся наборам страниц, пятый читает собранный сайт как посторонний, шестой сводит и **перепроверяет каждую блокирующую находку сам**. Живой кластер не трогали (решение владельца): мутирующие шаги проверялись чтением кода, который их реализует. **35 находок, 30 блокирующих, 23 из них гейт поймать СТРУКТУРНО не мог** — девять подфаз зелёных гейтов о них не говорили, потому что гейт резолвит имена и никогда не проверяет истину. **Две инструкции вели к потере данных:** `apprafter destroy --target <старый>` (область — весь проект токена по метке `apprafter=true`, имя кластера не читается никогда, то есть снесло бы и новый кластер) и смена окружения через `app remove` без предупреждения, что `ResourceClaim` уходит вместе с развёртыванием, база живёт 7 дней в `RetainedClaim` и потом удаляется, а новое окружение получает пустую. **Одна страница на 298 строк** (`connect-a-git-repository.md`) описывала возможность, удалённую в v0.1.97, и проходила гейт девять подфаз, потому что вестигиальное `spec.argocd.bootstrapRepo` держало все идентификаторы резолвящимися — страница отозвана, поля схемы оставлены владельцу решением (`docs/measurements/schema-followups.md`). Прочее того же класса: обещание снапшотов redis, которых `export` не делает (обе ветки только печатают «deferred… skipping»); `--check-cron off` как трижды предложенный выход, отвергаемый apiserver'ом; недосказанный радиус `platform rescue` (переустанавливает Cilium, все Application теряют Sync/Healthy); четыре уровня риска миграций из пяти с пропуском САМОГО высокого. **Найден продуктовый дефект, не документационный:** контроллеры VPA в CrashLoopBackOff с момента появления компонента (2.16e) — чарт передаёт `--feature-gates=InPlaceOrRecreate=true` образу 1.7.1, который флаг не принимает; рекомендации считаются, не применяется ничего. Чарт НЕ трогали: снятие флага запустило бы вытеснение подов на живом кластере, это решение владельца. **Один найденный «дефект» отклонён после проверки** — `choosing-the-machine.md` цитирует диагностику дословно и тут же исправляет `kind` на `type` в прозе, что и есть верное обращение. **Тесты были КРАСНЫМИ на master** от собственного фикса прогулки (`bae5559` переписал `app rm` на `app remove`, а сторож пиннит литерал) — поймал сторож, не гейт: `just lint` тестов не запускает, и это записанный пробел композиции. Несёт CLI-патч `v0.2.48`: шаблон scaffold писал в КАЖДЫЙ пользовательский манифест, что схемы вендорятся под `apprafter/cue.mod/pkg/` и `cue vet` сработает — не вендорятся с ADR 0046, команда падает; плюс справка `app add --path` описывала несуществующее правило `discover.find.glob`.

**Acceptance (полный, по §11 спека):** `just lint` падает на каждом из — дрифтнувший CLI-референс, непомеченный fence, негейченный inline-вызов, невалидный CUE-сниппет, неразрешимый `apprafter`-вызов, таблица полей вразрез со схемой, ложное `claims:`, запрещённая фраза, мёртвая ссылка/якорь, отсутствующий frontmatter/`verified-by`, регрессия ратчета. `docs.apprafter.dev` отдаёт сайт на финальных URL'ах, лендинг ведёт на него без «Soon», ни одна внутренняя страница не достижима. `llms.txt`/`llms-full.txt` — абсолютные URL, строка лицензии, описание на каждую страницу. У каждой capability из §5 есть гайд, у каждого гайда — типизированный `verified-by`. У каждой команды есть `about` и ≥1 пример. Закрывающая ручная прогулка зелёная.

**Acceptance закрытых подфаз:** *(a)* `just docs-check` и `just docs-build` зелёные в чистом checkout'е через `nix develop`; ни одной страницы вне nav без записи в allow-list; внутренние страницы не в `site/`. *(b)* `docsgen check` роняет `just lint` на любой правке clap-дерева без `just docsgen-generate`; `commands.json` покрывает все 95 путей; `reference/cli.md` удалён вместе с четырьмя входящими ссылками. *(c)* `cli/docsgen -- gate` роняет `just lint` на дрифтнувшем `apprafter`-вызове, дрифтнувшем schema-идентификаторе или невалидном полном CUE-документе в скоупе; 20 фикстур с негативными контролями пинят каждый исторически найденный дрифт; гейт печатает census-строку (страниц / инвокаций / идентификаторов / opaque-доли / exemptions) на каждый прогон; реальный корпус зелёный (`docsgen gate OK`). *(d)* расфенсенный блок (отступ или `pre`) несёт те же обязательства, что и fence, а незакрытый `pre` — своя находка; несуществующий путь репозитория в спане или в относительной ссылке роняет гейт, глоб — нет; цитата снятого ADR роняет гейт, а `Draft`/`Proposed` и частичное вытеснение — нет; `adr-check-ignore` глушит цитату по каноническому ключу и стареет как остальные исключения; удаление документированной поверхности роняет гейт против коммитнутого `docs/measurements/docs-health.json`, рост проходит молча, движение `exemptions` в ЛЮБУЮ сторону — находка, а отсутствующий/битый census — exit 2, не exit 1; реальный корпус зелёный, и все три новых чека находят на нём ноль. *(e)* сломанная регистрация CUE-лексера роняет `mkdocs build` с внятным сообщением, а не отдаёт зелёную сборку с нехайлайченными fence'ами (пронаблюдено падающим в обе стороны: и «не зарегистрировался», и «зарегистрировался, но токенизирует в одно»); страница без `description` роняет сборку с перечислением страниц; отключённый LLM-хук роняет `scripts/docs-check.sh` с именем недостающего артефакта; каждый URL в `llms.txt` абсолютен и резолвится и в страницу сайта, и в её markdown-двойник по правилу, которое сам `llms.txt` и объявляет; census не уменьшился ни по одному счётчику. *(f)* строгая сборка падает на любой входящей ссылке и на любом заголовочном якоре, сломанном переименованием ВНУТРИ `docs/` (именно она, а не census, — сеть безопасности: счётчики census'а тоталы и переименование от удаления не отличают), а ВНЕ `docs/` — `e2e/`, `cli/`, `operator/`, `platform-stack/`, `scripts/`, `landing/`, `.github/` — единственный инструмент это греп, и он прогоняется тем же коммитом; ни одна страница сайта в скоупе гейта не называет фазу, код подфазы, милестоун, трек или `plan.md` по РАСШИРЕННОМУ паттерну (не по тому, которым свип проверял сам себя), а оставшиеся упоминания `spec.md` — абсолютные URL, объявляющие себя роадмапом в самом предложении; `llms.txt`-счётчики не упали ни от одного из семи переименований; карта редиректов ОТСУТСТВУЕТ намеренно, с записанным замером и названным триггером (первая страница, переехавшая после 2.19g). *(g)* образ, собранный из ГОТОВОГО `site/` (build-стадии в Dockerfile нет), отдаёт четыре пробы плана — `200 text/html` на корне, `200 text/plain` на `llms.txt`, `200` на странице гайда и настоящий **404** на несуществующем URL (перемерено на закрытии, на реально собранном образе, вместе с новой страницей раннбука и её markdown-двойником); отпечатанные ассеты отдаются `immutable`, неотпечатанные под `assets/` — сутки, всё прочее — 300 с, и ни один неотпечатанный URL под `assets/` не запинен на год; `.md` отдаётся как `text/plain`, а не предлагается к скачиванию; релизный workflow гоняет `scripts/docs-check.sh` САМ и собирает опубликованные байты со `--strict`, так что путь, публикующий негейченный сайт, отсутствует; path-фильтр не срабатывает на внутренний changelog и `measurements/`, но срабатывает на `hooks/` и `reference/cli/SUMMARY.md`; `docs-site/` не требует исключения ни в `scan::in_scope`, ни в `exclude_docs` (проверено пробой, а не предположено), а собранный сайт не коммитится; имя образа в workflow и в `Application.cue` сверено как СТРОКА, а не на глаз; манифест проходит `cue vet` и `apprafter app validate` (и проба с заведомо невалидным значением роняет оба — проверка отличает состояния); лендинг-переключатель НЕ лежит коммитом на ветке — `git diff --name-only <base>..HEAD -- 'landing/**'` пуст, `docsUrl` остался `""`, — потому что `landing-autotag.yml` публикует лендинг с любого пуша по `landing/**` и «придержать коммит» невозможно; переключатель записан шагом 5 раннбука вместе с названным механизмом; ШЕСТЬ ручных шагов оператора записаны в ADR и ПЯТЬ из них в раннбук так, что доводятся до конца без плана, включая шаг про приватность GHCR-пакета с пробой, различающей public/private; серверный слой закрыт двумя гейтами, каждый показан срабатывающим и НЕ срабатывающим: `caddy validate` слоем сборки образа (битый Caddyfile ⇒ build exit 1) и `scripts/docs-site-smoke.sh` между build и push (он валит дофиксовый образ на .md-404 и валит образ с блэнкетным `/assets/* immutable` на всех 35 неотпечатанных ассетах); `.md`-404 отдаёт короткий text/plain, а не HTML-страницу под видом plain; манифест читается парсером самого CLI (`expose.port` стал опциональным — до этого `app add` прятал пикер окружений). *(h)* `docsgen check` роняет `just lint` на примере с неразрешимым флагом, с флагом от ЧУЖОЙ команды, на пустой записи, на записи без `apprafter`-вызова и на примере, подшитом не к той команде (все пять показаны падающими, и первые два — на РЕАЛЬНОЙ таблице после `docsgen generate`, то есть при чистой байт-сверке и уже опубликованной ложной странице); каждый из 75 видимых листьев несёт ≥1 пример, а корень, групповые узлы и 3 скрытых листа — ни одного; 187 аргументов и 0 без описания перемерены тем, что печатает clap, а не проекцией `commands.json`, и оба счётчика сошлись; все пять шеллов `clap_complete` отдают скрипт, называющий команды ЭТОГО CLI (ассерт по `Shell::value_variants()`, не по списку в тесте), а рецепты для bash/zsh/fish пройдены руками под изолированным `HOME` до реального дополнения; семь свойств help-rot-стража показаны падающими и восстановленными, шесть из них выводятся из clap-дерева на момент теста, а седьмой (алиасы гайдов) — закоммиченный список, который сам проверяется против корпуса и несёт floor против опустошения; `after_help` цепляется в `run()`, и откат к `Cli::parse()` роняет отдельный тест, а не проходит молча; census не уменьшился ни по одному счётчику; ПЯТЬ пунктов исходного списка (h) НЕ построены и названы поимённо с пробой на каждый, а не списаны. *(i)* инвентарь недостающих гайдов перемерен по дереву команд, а не взят из оценки, и перемер включает разбор того, почему исходная команда давала три разных ответа (ключевание по базовому имени страницы); каждая из пяти страниц лежит в корпусе гейта (`docsgen gate OK` — ни одного нового exemption), стоит в nav `mkdocs.yml` И в индексе своей секции (строгая сборка ловит битую ссылку, но НЕ несвязанную страницу), несёт `description` во frontmatter, попадает в `llms.txt` и в markdown-двойник; ни одна страница не называет фазу, подфазу, роадмап-координату или `plan.md`/`spec.md`; ни один путь репозитория не добавлен (`code_paths` 104 → 104 — где нужен файл, дан абсолютный GitHub-URL); каждая команда, безопасная без кластера, ПРОГНАНА, а каждое значение, которое гейт не проверяет (SKU, режимы, имена полей), сверено с кодом, который его парсит; три команды оставлены без гайда ОСОЗНАННО и записаны с причиной; расхождения между параллельно написанными гайдами сведены поимённо, а не замазаны; коммитнутый census перезаписан `docsgen metrics`, потому что пол отстал от живого замера и не защищал новые страницы.

**Зависит от:** — (машинерия автономна). **Связан с** 2.16h/2.16g/2.12/2.9 (их поверхности — основной контент 2.19i) и с лендингом (2.19g правит трекнутый `docsUrl` релизного пути отдельным коммитом; одноимённый глобал Payload — превью-путь — за аутентифицированным API и остаётся за оператором). 2.19h меняет clap-дерево ⇒ регенерирует референс тем же коммитом.

**Размер:** XL · a–i (закрыты) — L; впереди только j (прогулка по каждому гайду + шесть ручных шагов оператора из (g), без которых сайт не отдаётся).

> 🚧 **Presentation-walk (Tier A + SYS-1/2/3) — на ветке `feat/presentation-walk`, ожидает push + prod-promote + live-smoke.**
> Двадцать коммитов `3626d5c…e9e10de` закрывают: PRES-01/03/04/05/06/07/08 (Tier-A точечные правки: CTA → operator-quickstart, product-path README, абсолютные ссылки docs, формулировки MVP, `llms-guides.txt` в machine-readers, версионный футер, ADR-index relabel), SYS-1 (фазовый реестр `phases.json` + `PhaseChip` на лендинге + PRES-02 boringTech chips + PRES-09 decoupled public phases), SYS-2 (публичная страница `/status/` с колонкой Phase + per-phase поле subscribe на форме; строка в `docs/status.md` добавлена этим треком), SYS-3 (content-gate: live-smoke скрипт + workflow + schema-тест + Payload validate). Дизайн-спек: `docs/superpowers/specs/2026-08-23-presentation-walk-design.md`.

---

## Фаза 2.9 — Dev Mode + Services (Phase 2B из dev-mode-task.md)
> 🏁 SR: D — dev mode dropped from launch
> ⚠️ **NB: это НЕ `### 2.9 Per-environment overrides` (per-env deploy, ADR 0044, SR:A, in-launch).** Совпадение «2.9» историческое — это отдельный отложенный dev-mode трек. «§2.9» / «ADR 0044 §2.9» всегда = per-env subphase.

**Цель фазы:** dev mode поддерживает `needs.{pg, jetstream, redis}` end-to-end локально через lightweight in-cluster providers (single-node Postgres pod, embedded NATS, single Redis). Дев-кластер на `dev cluster up` поднимает все ServiceProviders по умолчанию с `--without` opt-out флагом. Helper команда `dev claim status <app>` для диагностики ResourceClaim. Помечается `experimental` (полный DX в Фазе 3.9).

**Source of truth:** `dev-mode-task.md` §20 Phase 2B.

**Spec:** `spec.md` §3.10, §3.2 (ServiceProvider/ResourceClaim).

**Зависит от:** Phase 1.9 closed + Phase 2 closed (ServiceProvider CRD 2.1, ResourceClaim CRD 2.2, scheduler 2.3, реализации `needs.pg` 2.4 / `needs.jetstream` 2.5 / `needs.redis` 2.6).

**Поставка:** items из `dev-mode-task.md` §20 Phase 2B перетаскиваются сюда AI-агентом по мере реализации.

**Версии:** `v0.2.x` patch series.

**Размер (aggregate):** M (~1 неделя FT). Корректируется по факту.

---

### 2.20 Гайды — это рецепты (ADR 0058) — ЗАКРЫТА 2026-08-30

> 🏁 SR: A · order 3.7b — публичная поверхность как продукт

**Цель:** гайд перестаёт быть переписанным прогоном. Рецептный путь несёт только
`apprafter`-команды и законно-внешние инструменты; всё остальное маршрутизируется по роли.

**Spec:** `docs/superpowers/specs/2026-08-29-guides-are-recipes-design.md`. **ADR:** 0058
(+ амендмент к 0057). **Замер:** 27 страниц, 478 `apprafter` против 325 чужих команд
(VERIFY 153 · TROUBLESHOOT 60 · EXPLAIN 51 · SETUP 61), 96 блоков рвут happy path,
11 из 27 страниц нельзя пройти одними `apprafter`-командами. Четыре худшие страницы —
четыре из пяти, что ссылаются на e2e-прогон.

- [x] **2.20a — ADR-first + два продуктовых бага** (2026-08-29, `36d7e33…6328cdf`)
  ADR 0058; амендмент к 0057 (что измерение опрокинуло + резолюция противоречия в решении 7);
  `spec.md` Appendix B + §1.5 + Revision 16. `import --force` чинит нечитаемый `state.json`
  (`load_or_recover` переименовывает, не удаляет); `app add <git-url>` больше не требует
  манифест в cwd. Третий предложенный фикс (`node_prep.rs:421`) **отозван при проверке** —
  это `SWAPOFF_FAILED_RUNBOOK` на пути неудавшегося отката, а перекат ворклоадов после
  `node prep` реально нужен (inline-запись `memory.swap.max` — временная мера). Spec §5.4.
- [x] **2.20b — гейт `recipe-purity`** (2026-08-29, `4648391`, `bef81ff`, `8ebe68d`)
  **174 находки на 14 страницах, 4 разные команды (kubectl 171, hubble 3), ноль изобретённых.**
  Ранжирование воспроизвело перепись независимо (postgres 40, redis 39, persistent-disk 36,
  egress-policy 21). НЕ подключён к `docsgen gate`: красная проверка в прогоне, который зовут
  lefthook и `just lint`, сделала бы репозиторий незакоммитабельным до конца 2.20c — живёт за
  `docsgen recipe-report`, он же рабочий список для 2.20c. Красность закреплена тестом, включая
  негативный контроль (четыре чистые страницы обязаны молчать) и проверку, что break-glass
  исключение не декоративное. Два решения с замером: inline-спаны вне области (проза даёт первое
  слово предложения), теги ИСКЛЮЧАЮТ но не выбирают (без этого CUE/mermaid/YAML дают ~30
  выдуманных команд). Аллоулист пополнен `vault` и `loginctl` по осмотру.
- [x] **2.20c — перестройка 27 страниц** + слой механики + долг протухания. Гейт зеленеет.
  - [x] **часть 1 — долг протухания** (2026-08-29, `57dfd96`): два дефекта backup-restore
    (раздел + обходные шаги в обеих последовательностях + пункт верификации),
    `choosing-the-machine` в трёх местах, Cilium в troubleshooting, redis в `export`/`restore`
    `--help` + регенерация референса, `spec.md § Known limitations` → **закрывает 2.18**.
    Перепись перезаписана в том же коммите (652 → 646): ратчет считает только вверх, поэтому
    удаление ложного раздела — единственная операция, против которой он возражает.
  - [x] **часть 2 — перестройка страниц** (2026-08-30, `0782e8a…065502f`): **174 → 0**
    находки. Четыре худшие (postgres 40, redis 39, persistent-disk 36, egress-policy 21) были
    прогонами/лабораторией — переписаны в рецепты, механика вынесена в новый слой
    `docs/how-it-works/` (6 страниц). Хвост из 9 страниц — точечные вкрапления, свёрнуты или
    удалены. Адверсариальное ревью переписанного дало **10 подтверждённых дефектов**, включая
    неверную историю удаления на всех 6 страницах.
  - [x] **часть 3** — `recipe-purity` подключён в `Gate::corpus()`; корпус-тест перевёрнут с
    «красный» на «зелёный» + ассерт, что каждое `check=none` типизировано и датировано.
- [x] **2.20d — гейт `behaviour-claim`** (2026-08-30, `e0003fd`): класс, на который слепы
  все остальные проверки — они резолвят ИМЕНА, а протухшая запись о дефекте называет только
  то, что всё ещё существует. **Не список запрещённых фраз** (решение 7 ADR 0057): каждая
  запись привязана к ФАКТУ В КОДЕ (файл + якорь + present/absent), так что таблица говорит,
  за какой фразой следить, а ответ даёт дерево — откати фикс, факт перевернётся, фраза снова
  станет истинной и проверка замолчит сама. Засеян пятью, включая ещё открытый: RBAC без
  глагола `delete` на `resourceclaims`. **Доказан историей, а не собой** —
  `behaviour_history_test.rs` достаёт реальные страницы из git на `894bdfd` и требует, чтобы
  все три исторических клейма были пойманы, а исправленные страницы молчали.

**Вне объёма:** новых существительных CLI нет (`claim`, `app exec`, `app restart` отклонены);
`env-secrets-hash` вынесен отдельно — он тянет релизную цепочку оператора.

### 2.21 Публичный ледгер фич

> 🏁 SR: A · order 3.7b

**Цель:** `/status/` перестаёт быть опубликованным `FEATURE_TRACKER.md` и соединяется с
роадмапом лендинга по стабильному `id` реестра.

**Spec:** `docs/superpowers/specs/2026-08-29-public-feature-ledger-design.md`.

- [x] **Баг подписки** (2026-08-29, `a52ae93`) — кнопка «Get notified when Phase 8+ ships»
  постила `federation` в `interests`, где такой опции нет; Payload отвечал 400, форма
  показывала успех, строка не писалась. Класс закрыт гейтом в `landing-content-gate.test.ts`.
> ✅ **ЗАКРЫТО 2026-09-06** (docs+landing-only, без бампа CLI и монорепо-тега). План:
> `docs/superpowers/plans/2026-09-06-2.21-public-feature-ledger.md` (gitignored, локально).
> Страница 204 → **202** строки; 47 → **64** строки данных; блокквот-проза 965 → **237** слов;
> ноль → **21** ячейка-ссылка. Числа пересчитаны 2026-09-07 после догона 2.21c и разбора аудита —
> первая редакция этого блока (177 строк / 59 строк / 125 слов / 15 ссылок) была верна на коммите
> закрытия и устарела через сутки. Экономия строк ушла на то, что аудит вскрыл: пять новых строк
> с фазой, которую лендинг уже продаёт, и записанные исключения. Обе выкладки `*-check-ignore`
> сняты: нестроенная строка называет **способность**, а не команду и не ключ схемы.

- [x] **2.21a** — пункт ледгера в ADR 0058; решение по `Post-launch` в реестре; чистка
  утечки `Product 1` / `Product 2` в `roadmap.json`.
  - **Решение по `Post-launch` (и заодно по дробной `Phase 4.5`): записи в реестре НЕ будет,
    и ячейки не становятся ссылками.** Оба варианта спеки неверны на доказательствах.
    Свернуть в `managed` — ложь: обе строки (T1→T2 миграция, approval-UI в портале) это
    OSS-core на кластере клиента, а `managed` — «Managed offering launch». Отдельная запись —
    ссылка в никуда: `Roadmap.astro` рисует карточку на запись **контента CMS**, а не реестра,
    и кнопка подписки живёт на карточке; запись без карточки даёт якорь, которого страница
    никогда не эмитит. Это ровно правило §2.2 самой спеки — «ледгер не обещает контрол,
    которого нет» — применённое к случаю, который спека пометила как блокер.
  - Утечка закрыта и **зафенсена** тестом в `landing-content-gate.test.ts`; живой CMS несёт те
    же две строки и вынесен в `CMS_PROD_CHANGES.md` (действие владельца).
- [x] **2.21b** — переписывание страницы: убрать колонки `plan.md` и `order/CP`, продуктовые
  группы вместо `## order N`, схлопнуть блокквот-прозу, колонка «Документация»,
  расширенный словарь отметок для политик и архитектурных свойств.
  - Второй словарь: **`◆` в силе сегодня · `◇` ещё нет**. `◇` — это ровно поправка §4.2:
    свойство утверждается только когда построено то, на чём оно стоит.
  - Колонка «Документация» ссылается на гайд, который покрывает фичу; `code-path` её резолвит,
    так что переименование страницы ломает гейт, а не тихо ссылку.
- [x] **2.21c** — перенос матрицы killer features под правилами редактуры; девять
  отсутствовавших строк добавлены; каждое не-`☐` проверено против кода.
  - **Догон 2026-09-07:** секция «Deferred / out of scope» — последний пункт §3 спеки, который
    первый проход пропустил. Она несла два противоречия, оба внесённые тем же проходом:
    Kamaji hard multi-tenancy стояла и в списке отложенного, и строкой `Phase 4` (реестр
    называет Phase 5 «Production Tier 3 + multi-tenancy» — то есть фаза была неверной), а
    Tier 3 и Tier 4 значились «вне объёма», хотя роадмап лендинга активно их обещает с
    кнопкой подписки. Три строки уехали в таблицу с корректными `Phase 5` / `Phase 6`;
    остаток переписан двумя честными списками — «сделаем по запросу» и «сознательно не
    делаем», по пункту на строку вместо двух прогонов через `·`.
  - Две живые переоценки поправлены попутно: строка safety-gate называла себя **MCP-native**
    (grep по `cli/`+`operator/` — ни крейта, ни зависимости, ни бинаря), строка скаффолда
    называла `apprafter app new`, которой нет.
  - Редактурное правило спеки соблюдено буквально: **лог редактуры не едет вместе с
    отредактированным выводом** — колонки `notes` нет, слова «redacted» нет.
- [x] **2.21d** — соединение: ячейки Phase несут стабильный `id` реестра в href при видимом
  лейбле в тексте; три теста в файле, который уже читает реестр (каждая ссылка резолвится в
  `id`; фаза с контролом подписки — ссылка, без контрола — нет; лендинг ссылается назад);
  обе стороны проверены мутацией. Обратная ссылка живёт в **компоненте**, а не в CMS-поле
  `closing`, поэтому существует без правки прода.

### 2.22 Day-2 дефекты: разбор `day2-followups.md` D4–D14

> 🏁 SR: A · order 3.7c — то, что 2.19j/2.20c задокументировали вместо того, чтобы починить

**Цель:** закрыть одиннадцать продуктовых дефектов, найденных при переписывании гайдов и
разобранных по одному с владельцем 2026-08-30/31. Детали, доказательства и фиксы против кода —
в `docs/measurements/day2-followups.md` (записи **D4–D14**); здесь только порядок, группировка
и релизные цепочки. **Плоский порядок D4→D14 отвергнут:** дефекты кластеризуются по ОБЩЕМУ
фиксу, и поштучный проход трогал бы один и тот же код по три раза и гнал бы три релиза
оператора там, где хватает одного.

**Три сквозных урока разбора** (держать при исполнении каждой подфазы):
1. **Утверждение, которое удовлетворяется вырожденным случаем, хуже отсутствующего.** Три раза
   подряд: `[ "$REQ" = "$RECO" ]` при обеих сторонах 32Mi (D10), тест, закреплявший устаревший
   `nodes[0].kind` (D3), и 420-секундный дедлайн, узаконивший аварию ACL (D5).
2. **Владение ≠ время жизни.** `ownerReference` отвечает «что будет, когда родитель умрёт», и
   никогда — «родитель больше не хочет этого ребёнка» (D4/D12/D13).
3. **Форма доставки определяет доступный контроль.** Императивный сеал отревьюить нельзя →
   остаётся раскрытие; диff манифеста ревьюится → можно гейтить (D14, `§∞.10`).

- [x] **2.22a — преflight и таксономия ошибок CLI** (D11) · CLI-only, без цепочки оператора
  Самое дешёвое из тяжёлых и единственное, на что владелец напоролся лично.
  - [x] `preflight_tool(...)` в начале КАЖДОЙ команды, которая спавнит внешний бинарь — до
        промпта, до похода в кластер, до платного шага. Преflight уже написан
        (`backup.rs:2142`, у него есть ветка `NotFound`) и зовётся ровно из одной команды.
  - [x] Порядок, худшее первым: `restore --reprovision` (гейтит пароль НАМЕРЕННО, с
        комментарием, и не гейтит бинарь → отсутствующий restic стоит оплаченного поднятого
        кластера), `bootstrap-all` (helm нужен в фазе 3/3, после платных ресурсов),
        `repo creds add` (боевой PAT собирается до проверки дубликата/кластера; `rotate` в том
        же файле делает правильно), `backup create`/`list`, `prune`/`check`/`unlock` (созданы
        работать БЕЗ кластера, но ходят в него первыми).
  - [x] Тест на команду: до преflight'а нет ни промпта, ни вызова провайдера.
  - [x] `ExternalToolNotFound { tool, needed_by, purpose, install }` + фраза, которая важна
        после промпта: **ничего никуда не отправлено и кредл не использован**. `min_version`
        НЕ добавлен: «установлен ли» и «достаточно ли новый» падают по-разному и заслуживают
        разных сообщений — вторым вопросом остаётся владеть `preflight_restic_version`.
  - [x] `Kubectl` + `Restic` с чистыми классификаторами stderr (`cli_core::diagnose`):
        недоступен / запрещено / kind не обслуживается, и неверный пароль ≠ отсутствующий
        репозиторий ≠ залипший лок. Вкручены **в узкие места** (7 хелперов `k8s_helpers`,
        оба спавна `restic_runner`), а не в 39 мест вызова — запись прямо говорит, что 584
        не надо гнать к нулю. Консервативны: нераспознанное → `Other` и исходный текст.
  - [x] `doctor` несущий: FAIL вместо WARN для бинаря, без которого CLI не работает (сейчас
        отсутствующий kubectl даёт exit 0 и «Ready to go», **и это закреплено тестом**);
        добавить `restic` (8 спавнов, нигде не проверяется, нет даже в предусловиях quickstart)
        и `git`; половину окружения гонять БЕЗУСЛОВНО (сейчас без активного таргета
        first-run-пользователь — аудитория из докстринга — не узнаёт ничего).
  - **Не гнать 584 к нулю.** Catch-all — правильный дом для разового отказа и неправильный для
    шести команд на пути аварийного восстановления.

- [x] **2.22b — владение: оператор удаляет то, что породил** (D4 + D12 + D13) · оператор + RBAC + chart
  > **Walk GREEN** (`e2e/needs-removal-walk.sh`, 2026-08-31, kind+podman). Четыре прогона: он
  > **до своего предмета дошёл только с четвёртого раза**, а по дороге нашёл **D15** —
  > гейт разрушающих изменений был полностью инертен для base-only приложений, в CRD И в
  > вебхуке, с юнит-тестом, охранявшим вторую половину. Плюс harness-дыра: фаза 1b
  > применяла branch-CRD, но не branch-RBAC, поэтому prune молча 403-ил.
  Один релиз оператора на три дефекта: обобщённый диff owned-детей их все покрывает.
  - [x] LIST детей этого Application + удаление тех, кого нет в желаемом наборе. Предикат —
        UID владельца (лейблов на клеймах нет), тот же, что уже гоняет `.owns()`-watch и
        `list_resource_claims_for_app`. Ближайший внутрикрейтовый образец —
        `delete_all_key_plans_except` (`lib.rs:1974-1995`, чистый фильтр `:2304-2324`).
  - [x] **НЕ «третья prune-ветка в той же форме»**: `has_needs` (`lib.rs:504`) гейтит весь блок
        по НОВОЙ спеке, поэтому удаление ПОСЛЕДНЕГО need'а пропускает блок целиком и любой
        `else` внутри не выполнится. Prune живёт СНАРУЖИ гейта.
  - [x] Глагол `delete` на `resourceclaims` в `rbac.yaml` — **в том же изменении**, что и код
        (повторный урок: ADR 0048 и фикс GC 0.2.31).
  - [x] Порядок несущий: удаление только ПОСЛЕ апрува плана и применения новой спеки, и
        финализатор провизионера обязан отработать → снапшот пишется, 7-дневное окно
        открывается как задокументировано.
  - [x] D12: `else`-ветка для Service (`lib.rs:726`) и CNP (`:736-740`). У Service `delete` в
        RBAC есть с самого начала. Проверить `is_destructive` для снятия `expose`.
  - [x] D13 — **форму рендера менять не нужно, это была ложная развилка** (владелец, 2026-08-31).
        `ownerReferences` — СПИСОК, и GC удаляет зависимый объект, только когда исчезли ВСЕ
        владельцы: это подсчёт ссылок, исполняемый apiserver'ом. Копия несёт по одной
        non-controller ownerRef на каждое потребляющее Application (тот же namespace, несколько
        владельцев, `blockOwnerDeletion: false` — удаление приложения не должно ничем блокироваться).
        Field manager **пер-аппный**: SSA владеет `ownerReferences` как map по `uid`, поэтому
        записи сосуществуют; один общий менеджер прунил бы ту, которую не отправил в этот раз,
        и два приложения выселяли бы друг друга по очереди.
        Вторая зависимость — от PAT — кросс-неймспейсная, а Kubernetes такие ownerRef запрещает
        (это уже знали: докстринг финализатора и `rbac.yaml:432` говорят об этом прямо). Её
        закрывает уже существующий финализатор: копии проставлен `apprafter.io/source-credential`,
        а `gc_derived_secrets` подметает **кластерно по лейблу**, а не по двум зашитым namespace —
        namespace'ы приложений оттуда не вычислимы, а удаление PAT это ровно тот момент, когда
        отозвать надо ВСЁ производное.
        UX удаления, о котором был вопрос, **уже есть**: `repo creds remove` отказывается, когда
        под префиксы креденшла попадают Argo-приложения, перечисляет их и требует `--force`.
  - [x] Walk: приложение с ДВУМЯ needs, убрать ОДИН → RetainedClaim появился, второй клейм не
        тронут. Ни один из четырёх needs-walk'ов этого не делал — все удаляют приложение
        целиком, поэтому все гейты и проходили. **Поставлено `e2e/needs-removal-walk.sh`**
        (фазы 3–6: два именованных pg-клейма, снятие одного, RetainedClaim + `retainUntil`,
        сосед сверен ПО UID, негативный контроль — клейм чужого Application). GREEN
        многократно, последний раз 2026-09-01 (11 фаз, 40 `ok`).
  - [x] Walk: удалить приложение → в его namespace не осталось `dockerconfigjson`-Secret'а.
        Это утверждение поймало бы все три.

- [x] **2.22c — секреты: раскрытие, индекс, распространение** (D14 + D7 + D6)
  > **ЗАКРЫТА 2026-08-31.** Порядок пришлось перевернуть: план ставил docs-половину первой как
  > «бесплатную», но раздел траблшутинга нёс `kubectl`-обход под исключением `known-broken`
  > ровно потому, что D7 не был починен — писать гайд раньше кода значило бы описывать
  > несуществующее (урок ADR 0058). Код → потом один проход по документации, который и разделил
  > страницу по читателю, и снял исключение. Ратчет перезаписан тем же коммитом (11 → 10).
  - [x] **Сначала бесплатное (docs-only):** три поставки из поправки к ADR 0007 —
        сказать это на каждой поверхности (`apprafter secret` = операторский инструмент T1,
        замена OpenBao, без гранулярного доступа и аудита); перенести
        `docs/dev-guide/secrets.md` (половина про привязку остаётся у разработчика, workflow
        сеаливания уезжает в операторский гайд).
  - [x] Оператор, две строки: `check_env_secret_refs` (`lib.rs:1553-1578`) РАЗЛИЧАЕТ «нет
        Secret'а» и «нет ключа» и схлопывает в один `bool` — назвать реальную причину и
        namespace (он в скоупе строкой выше).
  - [x] `apprafter secret list` — имя, namespace, **имена ключей, никогда значения**, флаг
        all-namespaces. Пробел зафиксирован ТРИЖДЫ независимо (амендмент 2.19h к ADR 0057
        предсказал, walk 2.19j увидел, 2.20c напоролся).
  - [x] Индекс в ОБЕ стороны из одного прохода (LIST Applications + скан `env` на
        `EnvValue::Ref(EnvRef::Secret(_))`): app→секреты в `app status` (D7, диагностика),
        секрет→apps в точке сеаливания (D6, радиус) и в раскрытии (D14).
  - [x] Хеш разрешённого конфига на pod-темплейте + показ дрейфа в `app status`.
        **Автоматический роллаут НЕ дефолт на T1** (неизвестный радиус: несколько приложений
        на один секрет; и `rollout: manual` негде жить — у секретов нет декларативной
        поверхности). Роллаут — явное действие того, кто видит, что он затронет.
  - [x] Аннотация автора/времени на сеал — для инсайдерской ошибки и форензики, не как контроль.
  - **Отклонено письменно:** гейт на сеал (апрув непрозрачного блоба — театр, и облагает
    налогом единственную операцию, которая обязана быть быстрой). Автоматика — вопрос T2+
    (`autoRestartAppsOnEnvChanges`), где ревизии наблюдаемы и актор проаудирован.
  - **Предпосылка для 2.16a:** его acceptance-критерий («приложение перечитает Secret») ложен —
        `secretKeyRef` резолвится один раз при старте пода.

- [x] **2.22d — сигналы, которые никому не доходят** (D8 + D10) · оператор + chart + CLI
  > **Код готов, ПРОГОНОВ НЕТ — оба долга явные.** `e2e/vpa-walk.sh` переписан (второе
  > приложение с реальным следом от самого образа, утверждение на `containerStatuses`,
  > hard-fail), но **не запускался**: in-place resize требует настоящего Hetzner, kind/k3d
  > его не умеют. Шага прохода для баннера дискового давления (D8) **не существует вовсе** —
  > запись «Ships with» была планом, а не поставкой. Оба идут в батч прогонов на закрытии 2.22.
  >
  > По дороге исправлены два собственных ошибочных утверждения: (1) «у оператора нет SQL-клиента,
  > значит размер БД непрактичен» — экспортер CNPG снимает вопрос целиком и лучше клиента
  > (своё соединение, не ест слот из `max_connections` арендаторов); (2) «читать in-place
  > condition у VPA» — **такого условия нет**, VPA не пишет в свой CR об этом ничего, факт
  > заявляет kubelet на поде (`PodResizePending`). Для redis байты недостижимы по-настоящему
  > (проверено по исходникам v1.37.0 и `main`) → честная цифра — счётчик ключей, так и подписан.
  - [x] D8: `CapacityWarning` — это диск НОДЫ (`node_free_fraction` = `/node/fs/*`), но
        застамплен на `SharedVolume` → кластер без единого SharedVolume не предупреждается
        вообще, хотя на той же ФС живут owned-диски, данные CNPG, снапшоты Dragonfly, образы
        и логи. Увести на node-scoped носитель (синглтон `PlatformStack`).
  - [x] D8: предупреждать на КАЖДОЙ команде, жёлтым, по форме
        `commands::version_check::maybe_warn_about_newer_version()` (один вызов, `lib.rs:92`).
        Best-effort — недоступный кластер не превращает предупреждение в ошибку.
  - [x] D8: отпорожить по-томовый семпл, который УЖЕ берётся (`pvc_usage` → `status.capacity`,
        но `is_capacity_warning` принимает только node-долю) и показать в `volume status`.
  - [x] D8: колонка состояния в таблице клеймов `app status` (`print_resource_claims`,
        `app.rs:1605` — сейчас NAME/PROVIDER/READY/SCHEDULED/SECRET). Начать с цифр томов и
        дисков, которые уже есть; зонд размера БД — follow-on, не блокирует.
  - [x] D10: сделать walk способным упасть — засеять приложение ВЫШЕ пола, утверждать на
        `status.containerStatuses[].resources` (не на `spec`), hard-fail вместо лога.
  - [x] D10: оживить `notApplied` (единственный прод-вызов хардкодит `infeasible: false`,
        `lib.rs:870`; CRD-поле, тип и рендер CLI построены и недостижимы).
  - [x] D10: преflight k8s-пререквизита так же, как это делает путь смены ноды
        (`node_prep.rs`, `k8s_ge_134`). Отдельный вопрос — пинить ли версию Kubernetes вообще
        (третья поправка к ADR 0054 его не решает).

- [x] **2.22e — откат приложения по скользящему тегу** (D9) · оператор + chart + CLI
  - [x] Хранить предыдущий дайджест: `StatusImage` уже несёт `{tag, resolved, resolvedAt}` →
        `previous` аддитивен. `status.lastAppliedSpec` НЕ помощник (в нём тег, а тег тот же).
  - [x] **Откат обязан пиновать** — иначе следующий реконсиляй перерезолвит тег и накатит
        плохую сборку обратно внутри 60-секундного requeue. Значит это смена РЕЖИМА.
  - [x] Глагол возврата на скользящую модель — **обязателен**, иначе `rollback` дверь в один
        конец из главной фичи.
  - [x] Где живёт пин: `PlatformStack` кластерный (гит не оспаривает) — поэтому `platform pin`
        это одна merge-patch; CR приложения рендерится CMP из репозитория пользователя, и синк
        снесёт запись. Кандидат — аннотация на CR под выделенным SSA-менеджером (ADR 0048 дал
        эмпирику: SSA-аннотация переживает синк без `ignoreDifferences`), она же исчезает
        вместе с приложением. Альтернатива — карта пинов на `PlatformStack`, но это app-scoped
        данные на объекте платформы + своя сборка мусора = дефект D4 на новом месте.
  - [x] `--to sha256:…` = дайджест образа, всё прочее = гит-ревизия (флаг уже занят ревизией).
  - [x] Видимость: жёлтым в `app status` с версией удержания; список запиненных в
        `platform status`; ветка в `resource.customizations.health.apprafter.io_Application`
        (`component_argocd.cue:142`) → **`Suspended`, не `Degraded`**. Здесь health
        АГРЕГИРУЕТСЯ (CR — managed-ресурс приложения, в отличие от заякоренного плана из
        ADR 0048), поэтому меняет здоровье пользовательского Argo-приложения → проверять живым
        прогоном, а не чтением правил (класс, на котором A5 был опровергнут).
  - [x] Walk: пуш второго образа в тот же тег → откат вернул первый **и держится минимум два
        реконсиляя** (наивный фикс проходит первое утверждение и валится на втором).
  > **Walk GREEN** (`e2e/image-rollback-walk.sh`, 2026-08-31, kind+podman, 30 утверждений). ADR 0059. Разведка из 5 страндов + состязательная
  > проверка каждого несущего допущения окупилась: два из четырёх не устояли.
  > (1) «У VPA есть in-place condition» — **такого условия нет** вообще (это было D10,
  > но той же природы). (2) **`Suspended` РЕАЛЬНО вешает синк** — не-hook задача
  > оседает только на Healthy/Degraded, и операция паркуется в Running при multiStep.
  > `CreateNamespace=true` его НЕ взводит (проверяющий сам снял мою тревогу), взводят
  > waves/hooks/managedNamespaceMetadata — которых у нашей формы нет, поэтому это
  > **инвариант**, а проход утверждает `operationState.phase == Succeeded`.
  > (3) Плитка условна: `Suspended` — ВТОРОЙ по здоровью код, перебивает только
  > `Healthy`, поэтому ветка ключуется на маркере пина и стоит ВЫШЕ fall-through.
  > (4) Выживание SSA-аннотации на CR **измерено на живом apiserver** (kind 1.35,
  > наш CRD), а не выведено — по-ключевое владение внутри `metadata.annotations`
  > у CR было честным поводом сомневаться.
  >
  > Попутно найдены ДВА отдельных дефекта. (a) Пять builder'ов статуса **стирали
  > `status.image`** на любой паузе (гейт миграции, ожидание клейма, EnvSecretMissing,
  > невалидный spec) — безвредно, пока поле никто не читал; фатально, когда в нём цель
  > отката. (b) **D18**: `kubectl` вырезает `managedFields` из `get -o json` без
  > `--show-managed-fields`, поэтому ДВА guard'а владения (egress из 2.10 и новый pin)
  > никогда не могли сработать — юнит-тесты строили вход, который в проде не приходил.
  > Оба переведены на новый getter + тест на класс (проверен на отказ).
  >
  > Три бага харнесса по дороге, один мой процессный: я **редактировал скрипт, пока он
  > выполнялся** — bash читает по смещениям, они сдвинулись, и он выполнил мусор.
- [x] **2.22f — долговечность ACL Dragonfly** (D5) · ADR-first
  - [x] **Сначала поправка к ADR 0042**: он отклонил файловые ACL с условием «revisit if
        file-based ACLs are officially confirmed». Условие ВЫПОЛНЕНО (проверено против
        upstream v1.37.0: `LoadToRegistryFromFile` разбирает строки тем же `ParseAclSetUser`,
        что и рантаймовый `ACL SETUSER` — одно определение, два call-site; `$N`, `~*`,
        `&user:*` работают).
  - [x] Билдер файловой формы + байтовое сравнение с `SETUSER`-argv. Осторожно:
        `MaterializeFileContents` режет по ОДИНОЧНОМУ пробелу и требует, чтобы строка
        начиналась с литерала `USER` и несла ≥4 токена — сравнивать надо с ФАЙЛОВОЙ формой.
  - [x] Per-instance Secret + `spec.aclFromSecret`. **Ловушка:** `optional` принимается схемой
        CRD и молча игнорируется (`SecretVolumeSource.Optional` не выставляется) → CR на
        несуществующий Secret даёт под, который не стартует. Secret пишется ДО поля.
  - [x] Строка `default` обязательна и её ошибка запирает провизионер снаружи его же инстанса
        — единственное здесь, что нельзя выпускать без живой проверки.
  - [x] **Один писатель**: файлом владеет петля ресинка; `provision`/`gc` продолжают
        императивные `SETUSER`/`DELUSER` и Secret не трогают. Провизионер и петля — РАЗНЫЕ
        tokio-задачи, и фикс гонки dbnum (`7890d9e`) был СЕРИАЛИЗАЦИЕЙ (`.concurrency(1)`),
        которая их друг с другом не сериализует. И доминирующее окно — не устаревший снапшот:
        `claims_to_repin` фильтрует по `status.ready`, который приходит ПОСЛЕ создания ACL, так
        что параллельная сборка теряет строку даже при LIST строго после чужой записи.
  - [x] Ужесточить walk: Phase 9/10 `needs-redis-walk.sh` УЖЕ рестартят инстанс (`:1203`,
        `:1307`) и УЖЕ проверяют переаутентификацию — но с дедлайном 420с под комментарием,
        который аварию узаконивает. Дельта — одно слово: «восстановился за 420с» →
        «не терял аутентификацию вовсе».
  - [x] Отдельно: образ сервера Dragonfly платформой НЕ пинится (тег берётся из
        скомпилированного дефолта оператора) — все ACL-факты выше про тег, который мы не
        контролируем.
  > **Walk GREEN** (`e2e/needs-redis-walk.sh`, 2026-08-31, kind+podman, 106 утверждений;
  > решающее — вход с ПЕРВОЙ попытки после перезапуска при операторе, погашенном в 0).
  > Первый прогон нашёл ПРОДУКТОВЫЙ дефект, которого не предвидели ни разбор, ни дизайн:
  > петля добавляла `aclFromSecret` живому CR → оператор катил StatefulSet → первый клейм
  > на новом инстансе получал рабочее соединение и тут же перезапуск. Починено рождением
  > CR сразу с полем + засев файла провизионером (create-if-absent).
  > ADR 0042 §10 + §11 ратифицированы. Разведка опровергла
  > два моих собственных утверждения из реестра, оба в опасную сторону.
  > (1) Строка `default` обязательна **не потому**, что её ошибка запирает провизионер:
  > файл БЕЗ неё даёт активного `nopass +@all ~* &*` и **выключает аутентификацию**
  > на инстансе, обслуживающем всех арендаторов кластера. Проверено живьём: `PING` без
  > пароля → `PONG`, `SET` → `OK`. Запирание тоже реально, но от другого — строки
  > `default` без `on`. (2) Правило про одиночные пробелы неверно: `SkipEmpty` их
  > допускает, апстрим это тестирует намеренно. Плюс `ACL LOAD` **запрещён вовсе** —
  > он чистит реестр и рвёт соединения всех арендаторов, причём даже когда файл
  > идеально синхронен.
  > Аргумент безопасности, который стоит помнить: битый файл грузит НОЛЬ пользователей,
  > и сервер всё равно стартует на `requirepass`-дефолте — то есть деградирует ровно
  > до сегодняшнего поведения, не хуже.
  >
  > D17 решён владельцем: снять `+info` И добавить `-pubsub`. `PUBSUB CHANNELS` не
  > фильтруется по `&{user}:*` и возвращает **имена namespace и приложений** соседей —
  > утечка крупнее той, ради которой всё затевалось. Цена одна именная: BullMQ нужен
  > `skipVersionCheck: true`.
  >
  > Записан, но НЕ починен: `CLIENT` выдан и не скоупится по подкомандам на этой версии,
  > поэтому любой арендатор может перечислить и **убить** соединения соседа. Это больше,
  > чем закрывает §11.
- [x] **2.22g — расписание бэкапа: заменить поверхность, а не валидировать** (D2) · CLI + schema + chart
  Независим от a–f, можно вытянуть вперёд. Docs-половина уехала в 2.19j, CLI-половина — нет,
  и этот раскол ровно то, как запись забывается: симптом перестал быть виден, дефект остался.
  - [x] `--at 03:00` вместо `--cron`. Таймзона по умолчанию — **машины оператора**, `--timezone`
        для оверрайда. Время без зоны — не время, а зона, которую оператор имеет в виду, это его
        собственная; UTC разумно просить и плохо предполагать. CLI собирает cron сам и ставит
        `spec.timeZone` на CronJob → ни то, ни другое не забота оператора.
  - [x] `backup status` печатает расписание обратно **в той же зоне**, в которой его задали.
  - [x] Частота — продуктовое решение (ежедневно бэкап, еженедельно проверка). Если понадобится
        второе значение, это `--every day|week`, а не поле cron.
  - [x] `--check off` настоящей веткой (`checkSchedule: ""` → omit в чарте), чтобы отключение
        перестало требовать даты, которая не наступает: страница до 2.19j учила
        `--check-cron "0 6 31 2 *"` — 31 февраля — как подставку под отсутствующий выключатель.
  - [x] **Таймзона сейчас не выставлена и не названа нигде** — ни в чарте, ни в схеме, ни в CLI,
        и ни одна страница не говорит «UTC». CronJob без неё крутится в зоне
        kube-controller-manager. Это ловушка корректности, а не эргономики, и никакая
        валидация синтаксиса её не ловит.
  - [x] Сырой cron как escape hatch допустим позже, но не единственной поверхностью и не той,
        которой учит гайд.
  > **Готово, гейты зелёные** (CRD провалидирован против настоящего apiserver, рендер чарта
  > проверен четырьмя вариантами, 654 юнит-теста CLI). Разведка опровергла несущее допущение
  > НЕ там, где ждали: опасность не в том, что `CronJob.spec.timeZone` вырежет старый
  > Kubernetes (GA с 1.27), а в том, что **наш собственный CRD** структурный — оператор
  > старее поля даёт 200, сохраняет все известные поля и молча роняет это одно. Команда
  > при этом ПОЛУУСПЕШНА: бэкапы включены и идут не в той зоне, а CLI рапортует зону,
  > которую якобы поставил. Поэтому `enable` теперь ЧИТАЕТ ПОЛЕ ОБРАТНО и падает громко.
  > Попутно: `| default` в шаблоне проверки НЕ надо было удалять — измерено на настоящем
  > helm, что достаточно и необходимо только обёрнуть блок в `{{- if $b.checkSchedule }}`.

**Релизная политика 2.22 (решение владельца 2026-08-31):** резать один релиз по завершении
ВСЕЙ 2.22, а не по подфазе. Оговорка, принятая вместе с решением: **walk'и гонять по мере
готовности каждой подфазы, а не копить валидацию на конец.** Причина — 2.22b качественно
отличается от остальных: это единственная подфаза, после которой оператор начинает УДАЛЯТЬ то,
чего раньше не удалял (всё прочее добавляет сигналы, глаголы и сообщения). В общем релизе её
ошибка стоит данных, а история показывает, что и меньшие релизы приходилось янкать (0.2.15 →
хотфикс → янк, 0.2.19 → янк по needs.redis). Живой прогон по подфазе даёт точку отката без
бисекта по большому релизу.

- [x] **2.22h — отказ реконсиляции должен быть виден без чтения логов** (D16) · оператор + CLI
  > ✅ **ЗАКРЫТО (2026-09-01).** Реализация: `operator-core/problems.rs` (`ProblemLedger` —
  > in-memory, `std::sync::Mutex`, cap 5 причин на объект / 512 объектов) + `status.recentProblems[]`
  > + жёлтые строки в `apprafter app status`. Прогон `e2e/needs-removal-walk.sh` фаза 9 — **GREEN**
  > (kind+podman, 11 фаз, 38 `ok`, 0 ошибок).
  >
  > **Главная поправка к плану, сделанная до написания кода: инцидент, ОТКРЫВШИЙ D16, вообще не
  > доходит до `error_policy`.** `prune_orphaned_claims` пишет `warn!` и возвращает `Ok(())` —
  > и правильно делает (ADR 0048: декоративный отказ не имеет права рвать реконсиляцию). Поэтому
  > пункт плана «событие из `error_policy` — единственное узкое место» **неверен**: дизайн,
  > повешенный только на `error_policy`, закрыл бы D16, не покрыв сам D16. Тот же силуэт ещё у
  > четырёх мест `warn!`-and-continue. Реестр вызывается из ОБОИХ классов: `error_policy`
  > синхронен и не может `await`, но мутировать память может — а это ровно то, чем реестр и является.
  >
  > **Второе отклонение: Events не используются, RBAC не менялся.** План предлагал Events ради
  > бесплатных dedup/count/TTL; взамен — поле на объекте, потому что часовой TTL событий короче
  > интервала редко повторяющегося отказа, а условие на объекте переживает GC событий, которым
  > читатель не управляет. Даром достался и нулевой RBAC-дифф (памятка «глагол едет с кодом» —
  > здесь новых глаголов нет; `applications/status` уже имеет `patch`+`update`).
  >
  > **Третье отклонение — ЗАКРЫТО 2026-09-01 по запросу владельца.** `platform status` получил
  > обзор по кластеру: «какие приложения сейчас с проблемами», иначе это выяснялось запуском
  > `app status` по каждому приложению. Три сознательных инверсии относительно соседнего
  > pin-обзора (тот декоративный, этот — сигнал здоровья): печатает и когда всё хорошо (иначе
  > отсутствие секции неотличимо от «проверка не отработала»), громко сообщает о неудачном
  > чтении (RBAC-отказ, отрендеренный как «всё чисто», — единственный вывод, которого эта
  > секция не имеет права давать), и называет приложение **логическим** именем, которое
  > принимает `app status`, а не `metadata.name` CR. Незарегистрированное в Argo приложение
  > всё равно перечисляется с пометкой — именно они чаще всего и сломаны. Обе поверхности
  > делят ОДИН фильтр рендера (`live_problems`), и тест на нерасхождение это фиксирует;
  > проверен вводом расхождения. В отличие от `app status`, обзор **покрыт проходом**
  > (позитивная + негативная ветки).
  >
  > **Долг прохода, явный:** рендер `apprafter app status` в проходе НЕ покрыт — команда
  > резолвит приложение через регистрацию в Argo (`status.resources[]`), а этот проход строит
  > голые CR. Подделывать `status.resources` отказался: поле принадлежит Argo и перезаписывается,
  > а проверка, подпёртая поддельной фикстурой, — это ровно тот проход по null-случаю, от
  > которого файл прохода предостерегает дважды. Проход печатает `NOT COVERED HERE` на каждом
  > зелёном прогоне. Покрыто юнит-тестами (`format_problem_lines`, 6 случаев).
  >
  > **Два зноба ретенции** (`APPRAFTER_PROBLEM_TTL_SECS`, `APPRAFTER_PROBLEM_REFRESH_FLOOR_SECS`,
  > сгруппированы в `ProblemTuning`) — оба логируются на старте, чтобы «состарилось» и «не
  > записалось» различались. Порог обновления сделан настраиваемым **потому что проверка
  > накопления `count` иначе неисполнима внутри прохода**, а неисполнимая проверка не может упасть.
  >
  > **Девять прогонов, и продуктовый код был верен с первого.** Все восемь падений — харнесс, и
  > все одного вида: проверка, неспособная наблюдать то, что заявляет. Разобраны в `bbf7973`;
  > самое поучительное — `kubectl logs | grep -q` под `set -o pipefail`: `grep` закрывает канал
  > по первому совпадению, `kubectl` умирает от SIGPIPE, и **совпадение читается как промах**.
  > Три прогона обвиняли продукт. Назвала причину диагностика, добавленная в падающую ветку.
  >
  > Побочно: фаза 6 получила проверку самого гейта (прогон 2 встал на пять минут и упал тремя
  > шагами ниже — на отсутствующем RetainedClaim), а общий дамп `e2e/lib.sh` теперь печатает
  > MigrationPlan'ы, заявленные `needs` и ownerRef-uid клеймов. Зависание записано как **D20**
  > честно, как невоспроизведённое: окно лога не покрыло одобрение, причина не доказана, фикс
  > не угадан.
  Найдено на walk'е 2.22b: три прогона подряд оператор 403-ил на удалении клейма каждые 30
  секунд, и видно это было **только** в `kubectl logs`.
  - [x] Важное различие: **спроектированные** отказы surface'ятся хорошо
        (`AwaitingResourceClaim`, `EnvSecretMissing`, `ImageResolved`, `MigrationPending` — все
        в `status.conditions` и в `app status`). Исчезает **непредусмотренный** — тот, что
        доходит до `error_policy` через `?`. То есть ровно тот, которого никто не ждал.
  - [x] `error_policy` (`application/src/lib.rs:1018-1031`) целиком: `warn!` + два счётчика +
        requeue. **48** мест `?`/`return Err` втекают в него; `recorder.publish` во всём
        контроллере — **2**, и оба про design-time уведомления, ни одного про отказ.
  - [~] ~~Событие из `error_policy` — это **единственное узкое место**~~ — **посылка опровергнута
        до написания кода, реализовано иначе.** Инцидент, открывший D16, до `error_policy` не
        доходит вовсе: `prune_orphaned_claims` пишет `warn!` и возвращает `Ok(())` (ADR 0048).
        Ещё четыре места того же силуэта. «Узкое место» покрыло бы 48 путей через `?` и НЕ
        покрыло бы сам D16. Events не используются: часовой TTL событий короче интервала редко
        повторяющегося отказа, а поле на объекте переживает GC событий. RBAC-дифф нулевой.
  - [x] Ограниченный `status.recentProblems[]` рядом: TTL событий (час по умолчанию) короче
        интервала медленно повторяющегося отказа, и условие на объекте переживает GC событий,
        которым читатель не управляет. Ограниченный по длине, с `lastSeen`, стареет сам.
  - [~] Печатать в `app status` — **сделано** (жёлтым, до строки VPA). В `platform status` —
        **НЕ сделано, долг явный:** реестр per-Application, у платформенного контроллера своя
        поверхность, и сводить одно к другому без отдельного решения не стал.
  - [x] Две ловушки: повторяющаяся ошибка обязана **дедуплицироваться, а не спамить** (иначе
        30-секундные ретраи пишут статус дважды в минуту вечно), и переставший повторяться
        отказ обязан **стареть сам**, иначе поверхность превращается в список того, что когда-то
        было сломано, и его учатся не читать.
  - [x] Walk: намеренно вызванный отказ (403 — очевидная фикстура, воспроизводится удержанием
        одного глагола RBAC) виден в `app status` без чтения лога.

**Вне объёма 2.22:** `∞.10` (inline sealed env value) — бэклог; 2.16a (периодическая ротация
кредлов клеймов) — ждёт хеш из 2.22c как предпосылку.

### 2.23 Разбор презентационного прохода по лендингу, доке и CLI

> 🏁 SR: A · order 3.7d — источник: `actual_bugs_findings.md` (владелец, 2026-09-05)

**Цель:** закрыть 26 находок прохода владельца по трём публичным поверхностям. Порядок из
файла не сохраняется: находки сгруппированы по **общему фиксу и релизной цепочке**, как в 2.22,
иначе один и тот же quickstart правился бы четыре раза, а CLI релизился бы дважды.

**Сквозная установка владельца, держать при исполнении каждой подфазы:** *дока должна стать
проще и понятнее.* Флоу оператора (1–9) и разработчика (1–10) из файла — это **порядок чтения
существующего материала**, а не заявка на новые страницы. Подфаза, которая увеличивает объём
доки, не выполняет задачу. Счёт по 2.23e, пересчитанный по дереву: **две** страницы уходят
из операторского setup-пути (node-prep в day-2, publish-the-docs-site в Contributing), **четыре**
новых файла, три из которых — распил существующих. Бюджет строк: 6 страниц / 2 080 строк →
10 страниц / ≤1 995. Сокращение **не берётся из распила** — cut-and-paste нейтрален по строкам;
оно берётся ровно из одного места, и это решение, а не следствие: `choosing-the-machine.md:305-445`
документирует ту же процедуру смены машины второй раз целиком (141 строка, и сам текст на `:368`
признаёт пересечение). Если её не сложить в новую страницу ранбука — подфаза выходит в **плюс**
по строкам.

**Три решения владельца, не подлежащие пересмотру при исполнении:**
1. `up` — каноническое имя команды, `bootstrap-all` уезжает в алиас.
2. `platform` управляет платформой. Ошибок приложений в `platform status` быть не должно.
3. Знак `+` в упоминаниях фаз убирается.

- [x] **2.23a — CLI: `up` каноническое, `status` несущий, `platform` только про платформу**
      · одна релизная цепочка CLI, **голова очереди** (2.23d/e правят текст под эти имена)
  - [x] `cli.rs:235` — поменять местами `name`/`alias`: `#[command(name = "up", alias =
        "bootstrap-all")]`. Алиас остаётся — ничего у пользователя не ломается.
  - [x] `commands/status.rs` сегодня — скелет из первого коммита CLI (`8f4267e`): читает
        локальный state и печатает `would show status …`. Переписать как **композицию поверх
        уже написанных читателей**, нового чтения кластера не добавляется:
        заголовок таргета (`resolve_state_paths` + `State::load_or_default`, то, что печатается
        сейчас, одной строкой) → версия/доступный апгрейд PlatformStack → все условия
        `!= True` → проблемные приложения → запиненные приложения → неодобренные MigrationPlan'ы.
  - [x] `platform.rs:70` `status()` — снять обе прикладные секции: `print_pinned_applications`
        (`:236`) и `print_problem_applications` (`:165`) вместе с двумя `kubectl_get_json_by_selector`
        (`:107`, `:108`). `problem_app_rows` / `pinned_app_rows` / `problem_heading` уже
        `pub(crate)` — это перенос вызовов, а не новый код. `platform status` остаётся тем, чем
        назван: канал/пин/autoUpgrade/тир, current/target/available, таблица условий, история,
        componentVersions.
  - [x] Деградация вместо ошибки: `status` при недоступном кластере обязан напечатать локальный
        заголовок таргета и пометить кластерные секции недостижимыми — образец рядом,
        `node_prep.rs:1201` с метками `[api]`/`[ssh]`. Оператору, у которого кластер лёг, эта
        команда нужна именно тогда.
  - [x] Тест на нерасхождение двух поверхностей, который 2.22h уже завёл для `live_problems`,
        переезжает вместе с секциями — он и есть гарантия, что перенос ничего не потерял.
  - [x] Цепочка обязательного: `just docsgen-generate` (меняются четыре байт-сравниваемых
        артефакта — `reference/cli/{up,status}.md`, `index.md`, `commands.json`, `SUMMARY.md`),
        `help_rot_test.rs:681` GuideAlias переворачивается, `aliases_test.rs:122`
        переименовывается, `cli_smoke.rs:177`, `examples.rs:466`. Bump `cli/Cargo.toml` **и
        регенерация `cli/Cargo.lock` в том же коммите** — иначе `--locked` в release-cli.yml.
  - [x] ADR 0057 (`:1968`) фиксирует прямо обратное решение («`apprafter status` осознанно не
        назван: это скелет»). Правка отменяет его — **сначала поправка к ADR, потом код.**

- [x] **2.23b — установка, которая работает** · лендинг + дока, без bump CLI
  - [x] Раздел скачивания на лендинге, чтобы не гнать посетителя на GitHub (`:24`): секция
        `#download` на `/` + тонкая страница `/download`, чтобы у доки был стабильный URL.
  - [x] `landing/web/public/install.sh` — Astro отдаёт `public/` как есть, значит
        `https://apprafter.dev/install.sh` без дополнительной проводки. Определение
        `uname -s`/`uname -m` → три публикуемых триплета, честный отказ на linux aarch64
        (`release-cli.yml:53` его не собирает), проверка `.sha256` до установки.
  - [x] **Резолв версии — не деталь реализации, а суть.** Монорепо публикует пять серий
        релизов, поэтому `/releases/latest` возвращает свежайший **по всем** и может выдать
        `operator/v0.1.134`. Сломанных мест **четыре**, а не три: `README.md:97` и оба quickstart
        (`operator-guide/quickstart.md:41`,
        `dev-guide/quickstart.md:38`) берут версию именно так. CLI уже умеет правильно —
        `version_check.rs:160` `pick_canonical_cli_tag`), плюс `dev-guide/quickstart.md:46` —
        `gh release download` **без тега**, что резолвит тот же отравленный «latest» другим путём.
        Осторожно: rust-фильтр НЕ годится для установщика дословно — `canonicalise_cli_tag`
        (`:179`) снимает `v` и парсит semver, а semver **принимает** prerelease, поэтому реальный
        тег `v0.1.0-mvp` (его собирает тот же `v0.*`-триггер, у него есть ассеты) проходит.
        `install.sh` берёт ту же логику серий, но сужает до `^v[0-9]+\.[0-9]+\.[0-9]+$`, и это
        расхождение записывается во всех трёх копиях.
  - [x] Версия на странице не запекается в `dist/`: резолвится на клиенте тем же фильтром.
        Захардкоженная версия на лендинге протухает молча — `landingHero.json:6` уже такой
        случай, оба гейта сверяют его с CMS, а не с реальностью.
  - [x] Плюс третье место с той же поломкой, которого в находке не было: баннер апгрейда
        самого CLI (`version_check.rs:70`) вёл на `/releases/latest` — тот же отравленный URL,
        только для человека. Правка версии фетча в v0.1.151 починила половину бага.
  - [x] Из доки вести на лендинг: `dev-guide/quickstart.md:28`, `operator-guide/quickstart.md:40`,
        `README.md:96`. Ручной путь через GitHub Releases остаётся второй вкладкой — это
        единственный путь, не зависящий от доступности apprafter.dev.

- [x] **2.23c — лендинг: упоминания фаз** · один контент-проход + один гейт
  - [x] `PhaseChip.astro:30` — `width: fit-content` + `justify-self: start`. Чип `inline-flex`
        внутри grid-элемента блокифицируется во `flex` и растягивается на всю дорожку
        (`BoringTech.astro:90`, `grid-template-columns: 200px 1fr`). Соседние два чипа
        (`Advantages.astro:85`, `TierLadder.astro:119`) уже несут `align-self: flex-start` —
        конвенция в репозитории есть, до `PhaseChip` не доехала.
  - [x] Ссылка на фазу в turnkey-ячейке (`comparison.json:60`) не выделена ничем: `global.css:25`
        снимает все признаки ссылки, а scoped-стили Astro **не достают до `set:html`**.
        Значит чип для CMS-контента обязан жить в `global.css` — класс `.phase-ref`.
  - [x] Sticky-заголовок наезжает на кнопку подписки: `.roadmap-waitlist` авторазмещается в
        строку 2 колонки 1 — ровно ту, по которой едет sticky `.phase-meta`, и позиционированный
        бокс красится поверх статичного. Чинить **разметкой** (обернуть `<ul>` + кнопку в
        `.phase-body`), не `z-index` — z-index прячет столкновение, а не убирает его.
  - [x] Контент-проход: лейблами оформлены 3 упоминания фазы из ~20. Остальные — проза в CMS-полях.
        `.phase-ref` даёт механизм, дальше — проход по `fallback/*.json` + гейт в
        `landing-content-gate.test.ts` (у него уже есть блок «fallback ⊆ registry»), иначе
        регрессирует на следующей правке копирайта.
  - [x] **Знак `+` убирается.** Он значил «эта фаза или позже» и приехал из внутреннего
        design brief, где нигде не объяснён посетителю; применён вдобавок непоследовательно
        (у 3 и 4 его нет, у 5/6/8 есть, а `Phase 4.5+` — третий смысл и вне реестра).
        **21 строка / 22 вхождения**, не 18 — и четыре пропущенных как раз те, что кусаются:
        `web.smoke.test.ts:458` (`toContain('Phase 8+')` — ЖЁСТКОЕ утверждение, падает в момент
        правки `roadmap.json`), `web.smoke.test.ts:240` (негативный гард протухает),
        `cms/payload-types.ts:680` (генерируемое зеркало `Roadmap.ts:34` — регенерировать тем же
        коммитом), `waitlist-payload.test.ts:26` (комментарий). Плюс `advantages.json:9` несёт
        ДВА вхождения в одной строке. И одна поверхность вне лендинга: `docs/index.md:86` и `:88`
        печатают подписи реестра дословно (`[Phase 5+]`, `[Phase 6+]`) — без правки дока протухнет.
        Основной список:
        `phases.json:26,33,40` и `roadmap.json:35,46,54` — **в одном коммите**, они связаны по
        подписи (`Roadmap.astro:17`), дальше tierLadder / advantages / comparison / transparency /
        waitlistCopy / `waitlistInterestOptions.ts` / `cms/globals/Roadmap.ts:34`.
  - [x] **Правка контента лендинга — правка в двух местах.** Прод рендерится из Payload,
        `fallback/*.json` работает только под `LANDING_USE_FALLBACK=1`, а `seedGlobals.ts`
        сеет if-empty. Коммит в репозиторий сам по себе прод не меняет: правка админки/сид —
        действие владельца, с записью в `CMS_PROD_CHANGES.md`.

- [x] **2.23d — правда на страницах** · docs-only, без переездов файлов; **после 2.23a**
  - [x] `migration-plans.md` — admonition (`:67-76`, считая пустую строку на `:67`: именно она
        обрывает таблицу, удаление одного `:68-76` её не чинит) вставлен **внутрь** таблицы: она
        обрывается, и последние 8 из 13 строк вываливаются сырым pipe-текстом, а заявление
        «Thirteen edits gate» (`:57`) становится ложным. Удалить блок целиком — и таблица
        срастается, и утверждение снова верно.
  - [x] Тот же «Known gap: approving a `needs.*` removal does not release the data»
        **неактуален**: 2.22b (`a4cc7ef`, operator/v0.2.45) научил оператор удалять незаявленные
        клеймы. Текст живёт на четырёх страницах — `migration-plans.md:62`, `postgres.md:143`,
        `redis.md:152`, `persistent-disk.md:136`. ADR 0051 (`:30`, `:108`) и `spec.md` (`:555`,
        `:575`) править **не надо** — вопреки тому, что я написал в первой редакции: `651c0db`
        их не трогал, они по-прежнему говорят «garbage-collected», и post-2.22b это снова правда.
        Проверку зафиксировать явно, а не молча пропустить.
  - [x] Блоки про более ранние билды не нужны до 1.0 (`:16`): `quickstart.md:305`
        (`spec.operator.enabled: false`), `choosing-the-machine.md:20`, `troubleshooting.md:276`,
        `node-prep.md:23` (вместе с его front-matter исключением `cli-check-ignore`),
        `backup-restore.md:461-479` (весь блок `### Two defects the validation runs found`, а не
        одна строка `:464`). Удаление осиротит ещё актуальный абзац про stock restic на
        `:481-489` — ему нужен свой заголовок, а не удаление.
  - [x] Фраза, дезавуирующая Amazon упоминанием Amazon (`backup-restore.md:568`, повтор `:614`).
        Сказать положительно: канонические ключи называют протокол, а не вендора.
        `:528` не трогать — там AWS S3 в фактическом перечне провайдеров.
  - [x] `Infrastructure.cue` в quickstart (`:126-151`): убрать 20-строчный `infra.cue` и
        формулировку «the right place to pin the substrate», оставив ссылку на
        `choosing-the-machine.md` §3. **Ни одного из двух вариантов владельца в CLI сегодня нет**
        (в кластере — `reference/index.md:60` фиксирует «not a cluster object»; отдельный
        инфра-репо — отозван ADR 0025 / `79c3307`), поэтому это переформулировка, а любой из
        двух вариантов = ADR-first, отдельной подфазой.
  - [x] Пикер машины: quickstart подаёт `--server-type` обязательным флагом и шлёт за выбором в
        `apprafter target machine`, хотя интерактивный `target add` показывает ту же матрицу
        последним шагом мастера (`target_wizard.rs:121`, и `choosing-the-machine.md:138` это уже
        говорит). Ведущим рецептом становится `apprafter target add prod`; флаговая форма —
        второй фенс «для CI без TTY». То же в `dev-guide/quickstart.md:200`.
  - [x] `doctor` — в преквизиты, до шага 1. Он **уже** годится: после 2.22a (`18d378d`)
        окружение проверяется безусловно, «нет таргета» — WARN и exit 0. Второй прогон на шаге 3
        остаётся: он добавляет шесть таргетных проверок.
  - [x] Проход по корпусу `bootstrap-all` → `up` и снятие ложного утверждения про
        `apprafter status` в `quickstart.md:243`. Осторожно: `help_rot_test.rs:788` требует
        сохранения конкретных литералов на конкретных страницах.

- [x] **2.23e — дока проще: порядок под флоу и распил разросшегося** · docs-only
  - [x] `mkdocs-redirects` включается **первым** и отдельно. Плагин лежит в `flake.nix:75`
        именно под это, но в `mkdocs.yml` `plugins:` его нет — сегодня любой переезд страницы
        молча 404-ит опубликованный URL.
  - [x] `backup-restore.md` — 989 строк, вдвое длиннее следующей операторской страницы. Оба
        простых пути закопаны: локальный бэкап на 89-й строке, включение S3 — на 571-й из 989,
        между ними 356 строк внутренностей restore и 248-строчный ранбук апгрейда субстрата.
        Страница росла приписыванием в конец, поэтому хронология стала порядком чтения — точная
        инверсия частоты нужды. Разбор: страница остаётся под своим именем (все входящие ссылки
        живы) и начинается с двух простых путей — «копия на моей машине» и «копия в S3»;
        restore и DR уезжают в `restore.md`; ранбук смены машины — в отдельную страницу.
        `### Two defects the validation runs found` (`:461-489`) удаляется: это запись changelog,
        она уже есть в `plan-history.md:232`.
  - [x] **Решение владельца (2026-09-05): смена машины — отдельная страница.** Операция редкая и
        не на критическом пути, поэтому она не имеет права стоять ни в `backup-restore.md`, ни
        внутри `choosing-the-machine.md`. Отсюда же берётся сокращение строк, и другого источника
        у него нет: `choosing-the-machine.md:305-445` описывает **ту же** процедуру второй раз
        целиком (141 строка, текст сам признаёт пересечение на `:368`) — эти строки переезжают в
        новую страницу, а на их месте остаётся указатель. Без этого переезда распил
        line-нейтрален и подфаза выходит в плюс.
  - [x] Заодно, раз эти секции всё равно переписываются: `backup enable --endpoint/--prefix`
        (`cli.rs:1579`) в доке **отсутствует**, и «простой путь S3» задокументирован в самой
        неудобной форме — ручной сборкой URL. Плюс `backup create --staging-mode`.
  - [x] `Node preparation` — из setup-пути в day-2. На хэппи-пасе не нужен: резервирования и
        swap кладёт cloud-init при провижене (ADR 0055, решение 7). Страница остаётся на месте
        (переезд файла = редиректы), меняется позиция в nav и вводный абзац: «это ретрофит».
  - [x] `Publish the documentation site` — из операторского гайда в Contributing. Это внутренний
        ранбук публикации **нашей** доки, включая шаг, правящий `landing/` этого репозитория;
        комментарий в nav (`mkdocs.yml:197`) защищает его тремя шагами из пяти, а два умалчиваемых
        — ровно проектные. Перечисление в другой группе nav без переезда файла: восемь входящих
        ссылок живы, `audience` в `llms.txt` переключается сам.
  - [x] nav обоих гайдов под флоу владельца. Сегодня он упорядочен по семействам артефактов:
        бэкап 15-й из 19 под заголовком «Day 2, and getting out of trouble», хотя страница сама
        говорит «Set this up before you need it»; объяснение скользящего тега — на последней
        позиции гайда разработчика, хотя это шаг 4 его флоу.
  - [x] `image-iteration.md` несёт две разные точки чтения: «что платформа делает с моим тегом»
        (до написания манифеста) и «мой деплой плохой, откатись» (после). Распил на этой границе
        закрывает шаги 4 и 10 флоу разработчика без единой новой темы.
  - [x] Две дыры флоу разработчика, где содержимого нет **вообще**: докеризация (шаг 3) и рецепт
        CI со скользящим тегом (шаг 4). Это одна непрерывная история «исходник → образ → тег»,
        поэтому одна страница, а не две; контракт из ADR 0010 плюс один настоящий пример через
        `pymdownx.snippets` (настроен в `mkdocs.yml:158`, не использован ни одной страницей),
        а не пять Dockerfile'ов, которые придётся тащить за пятью экосистемами.
  - [x] **Блокер снят, и он был настоящий:**
        `scripts/docs-artefacts-check.py:1202` (`lost_block`) требует, чтобы тело каждого фенса из
        КОММИТНУТОГО исходника нашлось среди отрендеренных блоков страницы. Инклюд `--8<--` — это
        ровно тело, подменённое между markdown и HTML, поэтому **первый же** инклюд в корпусе
        красит гейт. Плюс `docs/hooks/llm_export.py:99` сам пишет, что близнец унесёт строку
        инклюда вместо файла, и называет это «academic: no published page uses one». Обе правки
        идут отдельной задачей ПЕРЕД страницей, которая инклюд использует.
  - [x] Всё, что решено **не** писать сейчас, уезжает в честный список «Not documented yet»
        (`operator-guide/index.md:98`) — у гайда разработчика такого списка нет, завести.
  - [x] **Замер, а не намерение.** Было: `backup-restore.md` 972 + дублирующая процедура в
        `choosing-the-machine.md` = 1 459 строк на двух страницах. Стало: 296 + 212 + 213 + 342
        + 346 = 1 409 на пяти. Минус 50 строк, и — что важнее — страница первого чтения ужалась
        с 972 до 296, а оба простых пути стоят на 22-й и 58-й строке вместо 89-й и 571-й.
  - [x] `--strict` поймал пять оборванных якорей — ровно тот класс, о котором предупреждал план:
        секция уезжает на другую страницу и уносит свой `#fragment`. `mkdocs-redirects` тут не
        помогает (он не делает якоря), поэтому чинятся ссылающиеся строки.
  - [x] Что блокер был настоящим — проверено возвратом проверки к прежнему поведению: без
        резолвера `lost_block` падает на `dev-guide/build-and-push/` с сообщением, которое само
        называет вторую, тихую половину бага — «*с LLM-артефактами, собранными из исходника до
        рендера, всё ещё ручающимися за них*». То есть близнец нёс бы строку инклюда, и об этом
        не сообщил бы никто.

- [x] **2.23f — хром сайта документации** · docs-only
  - [x] Пугающий баннер на старте — это не наш дев-сервер, а протестное уведомление
        mkdocs-material 9.7.6 про MkDocs 2.0 (`material/templates/__init__.py:37`), и печатается
        оно **на каждом** вызове mkdocs, включая `docs-build` и CI-лог. Гасится одной переменной
        в devShell `flake.nix` — она накрывает все три места вызова разом.
  - [x] **Дыра в доставке, найденная при разборе:** `overrides/**` не входит в path-фильтры ни
        `.github/workflows/docs.yml`, ни `release-docs.yml`. Изменение под `overrides/` сегодня не
        гоняет ни одного гейта и не публикуется — в этой дыре уже лежит `overrides/main.html`.
        Чинится до партиала Plausible, иначе партиалу некуда доехать.
  - [x] Лого и favicon: `mkdocs.yml` не задаёт ни `theme.logo`, ни `theme.favicon`, поэтому в
        шапке стоит стоковый значок темы. Единственный отдельный знак в `docs/` захардкожен в
        `#1e293b` и на индиговой шапке нечитаем — нужен светлый вариант.
  - [x] 23 ссылки на **10** файлах (не 12) показывают имя файла с `.md` как видимый текст, хотя href
        давно без него. Заменить на заголовки страниц из nav и **завести класс в docsgen**
        (`gate.rs:249` рядом с `CODE_PATH`) — иначе вернётся следующей правкой. Чинить
        **после** переездов 2.23e: девять попаданий — на страницах, которые переедут.
  - [x] Plausible как на лендинге — **решение владельца (2026-09-05): подключать**. Штатный путь
        material — партиал `overrides/partials/integrations/analytics/` + `extra.analytics.provider`.
        Ловушка: `navigation.instant` (`mkdocs.yml:85`) переключает страницы через `pushState`,
        поэтому либо подписка на `location$`, либо history-режим в самом Plausible, **но не оба** —
        иначе каждый внутренний переход считается дважды.
  - [x] Политика приватности правится **вместе** с подключением, и правится по существу, а не
        ради галочки. Сегодня `legalPrivacy.json` описывает только `apprafter.dev` и первым
        пунктом «чего мы не делаем» говорит «No third-party trackers» — формально это уже неверно
        про лендинг. Формулировка владельца: Plausible **не трекер** в том смысле, который этот
        пункт отрицает — он не ставит куки, не строит профиль и не следит за посетителем между
        сайтами. Значит текст должен говорить это ЯВНО: cookieless-аналитика без персональных
        данных и без межсайтового отслеживания, названный процессор, оба хоста в области действия.
        Правка контента лендинга — в двух местах (репозиторий + Payload), прод — действие
        владельца с записью в `CMS_PROD_CHANGES.md`.
  - [x] Мелкая блок-схема на `dev-guide/application-cue/#field-reference`: `flowchart LR` из
        6 узлов с 212 символами подписей → естественная ширина ~2000px против ~736px колонки,
        и mermaid уменьшает **весь** рисунок вместе с текстом. Лечится в источнике (`TD` +
        короткие подписи), а не CSS: `useMaxWidth: false` покупает горизонтальный скролл.
        Тот же класс, мягче — `operator-guide/quickstart.md:193` (одна подпись в 142 символа).
  - [x] `docs/status.md` переписать. Две строки застряли в состоянии ветки («awaiting push»,
        «not yet publicly served»), команда названа легаси-именем, нет ни одной строки про всю
        программу 2.20/2.22 (девять закрытых подфаз), а три ячейки таблицы — это 1–3 килобайта
        релизной ретроспективы, которой место в `plan-history.md`. Строки ставить честно:
        ✅ только доставлено И проверено.
  - [x] Вопрос, на который разведка ответить не могла, закрыт замером:
        `https://docs.apprafter.dev/` отвечает **200**, лендинг-смоук зелёный — обе строки
        `🚧` в `docs/status.md` переведены в `✅`, а заметки про состояние ветки («awaiting
        push», «not yet publicly served») удалены. Такие состояния истекают сами, но истекать
        им нечем.
  - [x] Строка Backstage понижена `✅`→`🚧`: она и `reference/cli/open.md` не могли быть верны
        обе, и подвинулась та, что забежала вперёд продукта. Портал ставится опциональным
        компонентом чарта, но пути к нему нет — `apprafter open` умеет только Argo CD и прямо
        это говорит.
  - [x] Новый класс `link-text-path` **родился зелёным** (24 замены до него) и тут же поймал
        родственную форму, которой в находке не было: путь репозитория как подпись ссылки —
        ещё 9 мест. Плюс поймал собственную иллюстрацию в `documentation-gate.md`: страница,
        объясняющая правило, обязана назвать неправильную форму, поэтому пример переписан
        инлайн-кодом, а не живой ссылкой.
  - [x] Дыра в доставке закрыта в обеих workflow: `overrides/**` не входил ни в один
        path-фильтр, то есть изменение партиала не гоняло ни одного гейта и не публиковалось —
        а именно туда и кладётся партиал Plausible.

**Итог 2.23a–h:** восемь подфаз закрыты. Релизы `v0.2.60` и `v0.2.61` (локальные теги).
Правки живого Payload перечислены в `CMS_PROD_CHANGES.md` §C — без них половина 2.23c и
политика приватности из 2.23f на прод не доедут.

- [x] **2.23g — CI следит за версиями внешних компонентов** · CI-only, без bump
  - [x] Автоматики нет никакой: ни `dependabot.yml`, ни Renovate, ни одной из **28** workflow,
        проверяющей апстрим. ~60 внешних пинов в **восьми** синтаксисах (cargo TOML, package.json,
        Dockerfile `FROM`/`ARG`, workflow `uses:`, входы flake, CUE `version:`/`chartVersion:`,
        workflow `with: version:`, литералы `curl .../releases/download/`), большая часть — осень
        2024 в дереве от 2026-09.
  - [x] **Решение владельца (2026-09-05): свой скрипт, а не бот.** Формулировка владельца —
        «если можно бесплатными тулзами, то лучше ими; если они вообще нужны — так-то мы можем
        скриптом проверять новые версии трекуемых пакетов и пытаться по ним прогнать тесты
        (хотя бы юнит и смоук)». Renovate **отклонён**, и не по цене: он закрывает нативно 4
        класса из восьми, а остальные четыре (CUE-пины чартов, входы flake, `with: version:`,
        литералы `curl .../releases/download/`) всё равно требуют регулярок, которые мы пишем
        и сопровождаем сами. То есть мы платим за третью сторону в организации (или за PAT
        в secrets) ровно тем же объёмом кода, что и без неё, и вдобавок отдаём формат коммита,
        расписание и модель PR инструменту, который придётся отговаривать от `build(deps):`,
        от правки первопартийных версий в `platform-stack/cue/component_*.cue` и от драки
        с publish-workflow. Dependabot не рассматривается: те же 4 класса и без регулярок вовсе.
  - [x] Форма: **один инвентарь, один читатель, один отчёт.** Инвентарь пинов — данные
        (по одной записи на пин: файл, как достать текущее значение, где спросить апстрим),
        рядом с ними скрипт, который читает дерево, спрашивает апстрим и печатает таблицу
        «текущее → доступное». Плановый workflow гоняет его и держит **одну** живую issue,
        переписывая её тело, а не плодя по issue на пакет. Ноль PR на первом этапе — именно это
        и просила находка.
  - [x] Второй этап — то, ради чего это вообще стоит писать самим: **попытаться прогнать тесты
        по обновлённой версии**. Скрипт правит пин в рабочей копии, гоняет юнит и смоук того
        стека, которому пин принадлежит, и записывает в отчёт исход — «новее есть, тесты
        зелёные» против «новее есть, тесты красные» — потому что второе и есть настоящая
        стоимость обновления, и её сегодня не знает никто. Это ровно то, что бот дать не может:
        он открывает PR и ждёт, что человек прочитает CI.
  - [x] **Не заводить override версий через env.** `cli-providers/build.rs` осознанно делает CUE
        единственным источником правды на этапе сборки; правильная форма — скрипт правит пин
        в дереве и гоняет существующие гейты по правленому дереву.
  - [x] Границы: **ноль автомержа и ноль автокоммитов**. Отчёт — вход для человека. Первопартийные
        версии (`platform-stack/cue/component_*.cue`, `argocd-cue-cmp/version.cue`,
        `operator/charts/*/Chart.yaml`) в инвентарь не входят вовсе: их двигают релизные workflow,
        и «апстрима» у них нет.
  - [x] **Первый прогон нашёл то, чего не видит ни один существующий гейт.** 49 записей,
        35 отстают: cert-manager `v1.16.2→v1.21.1`, Argo CD `7.7.7→10.8.0`, Cilium
        `1.16.5→1.20.1`, Gateway API `v1.2.1→v1.6.2`, cue `v0.10.0→v0.17.1`, kubectl
        `v1.31.0→v1.37.0`, nixpkgs на 122 дня. Плюс **два дрейфа**, независимо перепроверенных:
        `azure/setup-helm` — `v3.16.4` в `release-operator.yml:311` против `v3.16.2` в
        одиннадцати других, и `ALPINE_VERSION=3.20` в `argocd-cue-cmp/Dockerfile` против
        `alpine:3.21` в `cli/apprafter-backup/Dockerfile`. Дрейф — всегда баг, независимо от
        того, есть ли апстрим новее, поэтому у него своя секция, а не строка в общей таблице.
  - [x] Правило «никаких тихих проходов» проверено ломанием, а не чтением: убитый regex у
        `chart-cert-manager` даёт `UNREADABLE` и exit 1, исчерпанный анонимный лимит GitHub
        даёт 29 записей `UNREACHABLE`, выведенных первыми, и exit 1. Ложного «всё в порядке»
        не бывает ни в одном из двух случаев.
  - [x] `scripts/*.py` добавлен в `check-spdx-headers.sh` — иначе заголовок в новом скрипте
        был бы декоративным.

- [x] **2.23h — четыре дефекта, найденные первым живым прогоном `status`** · cli v0.2.62
  Сводка из 2.23a впервые прогнана на реальном кластере. Ни один из четырёх не был виден
  юнит-тестам, гейтам и ревью, которые её пропустили.
  - [x] **Два здоровых условия сообщались как проблемы.** Чистый кластер печатал
        «2 condition(s) not healthy» про `Ready=True` и `UnauthorizedSourceModification=False`.
        Таблица полярности знала шесть типов условий, а оператор объявляет **восемь**.
  - [x] **Тест полноты, который существовал ровно ради этого, поймать не мог**: его список из
        шести взялся из того же grep'а, что и таблица, — то есть он утверждал, что сборка
        классифицирует то, что сборка уже классифицирует. Теперь читает объявления `COND_*`
        самого оператора, с полом по количеству, чтобы переименование префикса не оставило его
        судить пустой список. Проверено откатом фикса — падает.
  - [x] `status` печатал весь стор над своим же отчётом: `info!(?state, …)`, унаследованный от
        скелета, где эта структура и БЫЛА выводом. Смоук-тест теперь пинит отсутствие дампа.
  - [x] `Node disk:` мог печататься вечно из отравленного кэша: свежесть считалась как
        `now.saturating_sub(fetched_at)`, а для метки из будущего это ноль — внутри любого TTL.
        На машине лежала метка 5138 года, и баннер `Node disk: warm` печатался над каждой
        командой двое суток на ноде с 69% свободного места.
  - [x] Тир читался `(unset)` на кластере, у которого он есть: `State.tier` пишет `init`,
        а кластер, поднятый документированным путём (`target add` → `up`), через него не
        проходит. Фолбэк на тир таргета, но состояние по-прежнему выигрывает — у таргета это
        умолчание для следующего провижена, у состояния — то, что реально поднято.

- [x] **2.23i — правило записывается, иначе свип — это вкус** · ADR-first, блокер для 2.23n/o
  ADR 0058 **не говорит про размещение ADR-цитат ничего**: в нём есть строка `Explain → a separate
  mechanism layer`, а слова `citation`/`cite` не встречаются вовсе. То есть «ADR-ссылки только в
  how-it-works» — ваше расширение решения, а не его текст, и сейчас оно нигде не записано. Свип по
  ненаписанному правилу нечем судить и нечем защищать.
  - [x] Поправка к ADR 0058 (не переписывание — сам ADR требует именно поправок, `:240`): пятая
        строка маршрутизации **Cite** → назначение `how-it-works/` и корпус ADR; форма — гайд
        ссылается на страницу механики, страница механики цитирует ADR.
  - [x] Зеркало в `docs/contributing/documentation-gate.md` (таблица классов `:55-69`), чтобы
        контрибьютор встретил правило там же, где остальные.
  - [x] **Тест на абзац, применяемый по порядку, первое попадание выигрывает** — в
        `docs/contributing/documentation.md`. Разведка вывела рабочую форму: (0) ролевой гейт
        ADR 0058 `:139-144`; (1) **тест переимплементации** — «если завтра заменить реализацию,
        сохранив каждый наблюдаемый контракт, придётся ли переписать абзац?» да → механика;
        (2) **тест подлежащего** — грамматическое подлежащее читатель/его артефакт → рецепт,
        компонент платформы («оператор», «провизионер», «финализатор») → механика; годится как
        дешёвый поиск кандидатов, но сам по себе перестреливает; (3) **тест фальсификации** —
        как читатель проверит, что это правда: командой из гайда → рецепт, открыв `operator/**`
        или ADR → механика.
  - [x] **Решение владельца (2026-09-06): правило на весь файл**, а не только на счастливый путь.
        Хвостовые `Related` тоже: цитата в подвале рецепта — всё равно приглашение читать запись
        решения вместо того, чтобы доделать задачу. Корпус был сам с собой не согласен ровно здесь
        (четыре переработанные страницы зависимостей убрали даже хвостовые ссылки, а
        `egress-policy.md:109` и `dev-guide/resources-and-autoscaling.md:383` сохранили), и строгое
        чтение стало правилом.
  - [x] **И вторая половина того же решения, которая меняет маршрутизацию по существу:** ADR — это
        не более глубокое объяснение того, **как** работает, а запись того, **почему решено, что
        будет работать так**. Это на слой дальше механики и адресовано тому, кто может решение
        изменить, а не тому, кто под ним работает. Значит цитата, найденная в гайде, чаще всего
        подлежит **удалению**, а не переносу: читателю рецепта не нужны ни механика, ни
        обоснование. Три поверхности, три читателя, каждая в одном клике от предыдущей.
  - [x] Поправка к ADR 0058 написана (пятая строка маршрутизации **Cite**), тест на абзац —
        в `docs/contributing/documentation.md` («Which surface does this paragraph belong on?»)
        с рабочим примером из `postgres.md` до переработки 2.20c; зеркало в таблице классов
        `documentation-gate.md`, включая два ещё не построенных класса.

- [x] **2.23j — точечные правки, ни от чего не зависящие** · docs-only + три комментария в коде
  - [x] Дубль в руководстве по бэкапу: фраза «The backup distinguishes user material from platform
        material…» стоит дважды подряд в голове `## What a backup captures` — это моя склейка при
        распиле 2.23e, интро-предложение и первая строка перенесённого куска.
  - [x] `## What a backup captures` перечисляет объекты Kubernetes и redis и **не говорит, что
        база и том захватываются вообще** — а спрашивают именно это. Плюс не говорит, какие типы
        `needs` молча пропускаются. Сверить с `cli/backup-core/src/extract.rs`; там же поправить
        цитату строки кода, которая сейчас указывает на закрывающую скобку.
  - [x] `image-iteration.md` → `## Private images` объясняет, что нужен `SourceCredential`, и
        цитирует ADR вместо ссылки на страницу, которая показывает, как его завести. На всей
        странице ссылки на `private-repos-and-registries.md` нет ни одной.
  - [x] `dev-guide/application-cue.md` — последняя ссылка подписана «Operator quickstart», а ведёт
        на quickstart разработчика в том же каталоге.
  - [x] Три протухших комментария, все три — запись, а не сборка: обоснование в `gate.rs` для
        сканирования цитат внутри фенсов называет цитату в `postgres.md`, которой больше нет
        (фенсовых ADR-цитат в корпусе теперь **ноль**); `cb2208c` осиротил докстринг —
        однострочник `page_directory` уехал на `link_texts_naming_a_page`; комментарий в
        `docsgen/src/main.rs` всё ещё говорит, что recipe-purity держат вне `docsgen gate`,
        хотя его вкрутили в 2.20c.
  - [x] Секция «What a backup captures» переписана не подрезкой, а сменой порядка: **сначала
        данные за `needs`** — таблица по типу дependency с тем, что реально попадает в
        репозиторий (`pg_dump` базы, tar тома, whole-instance снапшот Dragonfly) и что не
        попадает, — и только потом объекты Kubernetes. И явное предупреждение, которого не было
        нигде: `jetstream`, `clickhouse`, `s3` и `notifications` **пропускаются молча**
        (`extract.rs:133`), то есть кластер, использующий любой из них, бэкапом покрыт не
        полностью, и об этом ничто не сообщает во время бэкапа.

- [x] **2.23k — порядок операторского nav и распил target-store** · docs-only
  - [x] Порядок подтверждён неверным по всем трём пунктам. `Secrets` **вверх с 16 на 9**:
        `backup-restore.md:122` уже отсылает к нему, а `:90` запечатывает SealedSecret **до** того,
        как читатель встретил запечатывание; `postgres.md` и `redis.md` тоже предполагают, что
        секреты уже есть. `Choosing the machine` **вниз с 3 на 19** — quickstart прямо говорит, что
        мастер уже сделал этот выбор и «искать заранее нечего», страница осталась справочником
        исключений. `Moving to a bigger machine` **вниз с 10 на 20** — она разрывает блок бэкапа.
  - [x] `Target store reference` не одна вещь: примерно 40% — механика (раскладка на диске,
        сериализация, цепочка разрешения кредов), 60% — рецепт (add / rotate / show / rename /
        remove). Переносить целиком нельзя, надо **делить**.
  - [x] **Рецептная половина сохраняет имя файла** `operator-guide/target-store.md` (заголовок
        меняется на «Managing targets»), и это не эстетика: `mkdocs-redirects` **не умеет якоря**
        (`mkdocs.yml:153` это прямо говорит), а `#destroy-scope` — самая опасная глубокая ссылка
        в гайде, на неё смотрят `quickstart.md`, `troubleshooting.md` и `recovery.md`. При
        сохранении имени `redirect_maps` остаётся `{}`, и ни одна из трёх ссылок не правится.
  - [x] Механическая половина → `how-it-works/the-target-store.md`, вместе с обеими цитатами
        ADR 0030. Побочно: докстринг `docsgen/src/adr.rs:114` ссылается на ту цитату как на
        источник правила склейки строк — обновить, иначе провенанс правила протухнет.
  - [x] Гейт `docs-artefacts-check.py` третий раз подряд падал голым `KeyError` на новой
        неотслеженной странице — `source` строится из `git ls-files`, поэтому собранная, но не
        добавленная в индекс страница ему невидима. Теперь он это и говорит, вместо трейсбека,
        который читается как поломка самого гейта.

- [x] **2.23l — гайд разработчика перестаёт дублировать операторский** · docs-only
  - [x] `dev-guide/quickstart.md` §1 «Register a target and bring the cluster up» пересказывает
        шаги 1–3 операторского quickstart втрое короче, и сокращение **портит порядок**: `doctor`
        оказывается после того, как платный сервер уже создан — ровно та ошибка, которую 2.23d
        починила на операторской стороне. Секция становится ссылкой.
  - [x] То же в §5 про домен: пересказ `connect-a-domain.md` и `cloudflare-origin-cert.md` с
        потерей шага DNSSEC, ожидания статуса зоны Active, параметров сертификата и способа
        выбраться из блокировки фаерволом.
  - [x] Проверено и снимает опасение: `GUIDE_ALIASES` в `help_rot_test.rs` **не пинит** ни одного
        литерала к этой странице, так что обе секции свободно превращаются в ссылки.
  - [x] Обе секции теперь ссылки, и §1 честно называет, почему копия была не просто лишней:
        сокращение уже разошлось с оригиналом — `doctor` в нём стоял **после** того, как платный
        сервер создан, ровно та ошибка, которую 2.23d починила на операторской стороне.
  - [x] §5 разделена по владельцу, а не сокращена: кластерная половина (фаервол, сертификат,
        регистрация зоны, DNS) уходит целиком в операторские ранбуки, у разработчика остаётся
        одно поле `expose` и проверка. Плюс предупреждение, которого не было: переход в `public`
        и добавление хоста — гейтящиеся правки.

- [x] **2.23m — MigrationPlan доезжает до разработчика** · docs-only
  - [x] Строка `MigrationPlan` не встречается в `docs/dev-guide/` ни разу, а все тринадцать
        app-scope триггеров — это правки, которые разработчик вносит в **свой собственный
        манифест**. Из-за этого три страницы гайда разработчика активно врут о том, что читатель
        увидит после правки, которая гейтится.
  - [x] Важное уточнение, чтобы не искать несуществующий долг: в плане 2.23e этого **не было** —
        `D10` там означает шаг 10 флоу (rollback), и он построен. Это неспланированный пробел, а
        не невыполненный пункт. (Единственное невыполненное из 2.23e — секция «Not documented yet»
        в `dev-guide/index.md`.)
  - [x] Новая короткая страница (60–80 строк) в конце блока «опиши своё приложение», до шагов
        отгрузки: таблица тринадцати, переписанная как **правки читателя** («вы убираете
        `needs.pg`», «вы ставите `network: public`»), а не как имена триггеров; что он увидит
        (`AwaitingMigrationApproval`, плитка Degraded в Argo CD); что reject для app-scope нет и
        обратный ход — revert в Git; кто одобряет. Механику одобрения не дублировать — ссылка на
        операторскую страницу.
  - [x] Таблица тринадцати переписана как **правки читателя**, разбита на «что-то убирают» и
        «что-то добавляют, и это расширяет доступ» — вторая группа и есть неожиданная. Плюс явный
        список того, что НЕ гейтится, потому что «поменял тег» — самая частая правка вообще.

- [x] **2.23n — сам свип: механика уезжает в how-it-works** · docs-only, самый большой; **после 2.23i**
  - [x] Масштаб измерен: **53 из 90** ADR-цитат корпуса (59%) сидят в двух рецептных деревьях, на
        32 страницах; 34 из них — на счастливом пути, 19 — в хвостовых списках; три страницы дают
        24 из 53. Механика вкраплена во все страницы `dev-guide/` кроме `build-and-push.md`;
        `application-cue.md` — примерно 40% механики по строкам, `image-iteration.md` с неё
        начинается.
  - [x] Шесть новых страниц `how-it-works/`, в порядке «дешевле и изолированнее — раньше»:
        резервирования и swap ноды; shared volumes; и — отдельно — **`gitops-and-the-cue-cmp.md`,
        которой сейчас нет вовсе**: именно она забирает пассаж про shell-пробу CMP из
        `application-cue.md` → `## The canonical filename`. От секции остаётся одно повелительное
        предложение и ссылка. Вместе с пассажем переезжает и front-matter исключение
        `schema-check-ignore` — оставленное на странице, которая больше не называет
        `spec.source.path`, оно станет мёртвым, а `exemptions` в цензе сверяется в обе стороны.
  - [x] Маршрутизация всех 53 цитат разобрана поимённо: **5** — механика, переезжает целиком;
        **13** — простое упоминание, снимается (осторожно: `migration-plans.md:52` — это H3, снятие
        меняет якорь); **35** — настоящий указатель, становится ссылкой на страницу механики, но
        **у 29 из них назначения ещё не существует**. Это и есть порядок работ: страницы прежде
        ссылок.
  - [x] **Ловушка снята первой, отдельным коммитом:** `behaviour-claim` — единственный класс
        гейта, проверяющий не имена, а истинность утверждений, — **не выполняется на
        `docs/how-it-works/`**. Мы собираемся перенести туда каждое поведенческое утверждение
        корпуса, то есть в единственное дерево, которого эта проверка не видит. Чинится
        перестановкой двух строк в `gate.rs`: `is_guide` продолжает гейтить recipe-purity (это
        верно — в how-it-works kubectl уместен), а цикл `behaviour::falsified` поднимается выше
        охранника.
  - [x] Блокер снят вместе с распилом node-prep: `kubectl rollout restart` учит `kubectl rollout restart` на
        рецептном пути без page-level исключения — recipe-purity выстрелит, как только кто-нибудь
        прогонит гейт красным. Либо схлопнуть, либо записать как разрешённый ADR 0058 `:151`
        случай.
  - [x] **Ход свипа.** Готовы три страницы механики из шести: GitOps + CUE-плагин (её не было
        вовсе — именно она забрала пассаж про shell-пробу), резервирования и swap ноды, и —
        в 2.23k — хранилище таргетов. Цитаты: **91 → 67**, то есть 24 снято или перенесено.
        Из оставшихся семи в гайдах шесть ждут своей страницы механики (shared volumes, бэкап,
        апгрейд платформы ×3, per-env deploy, digest-резолвинг), а `migration-plans.md` с её
        одиннадцатью — отдельный кусок: страница на 60% механика.
  - [x] **Свип закрыт.** Восемь страниц механики вместо запланированных шести: GitOps + CUE-плагин,
        резервирования и swap, хранилище таргетов, гейт одобрения, апгрейд платформы, cross-app
        shared volumes, порядок восстановления, per-env deploy, digest образа. Цитат в гайдах
        **ноль**, кроме двух на `publish-the-docs-site.md` — а она сама переезжает в how-it-works
        в 2.23p, где цитаты законны. По корпусу 91 → 63.
  - [x] Восемь распилов, и ни один не потерял якорь незамеченным: `--strict` ловил их четырежды
        (target-store ×2, restore, per-env, shared-volumes ADR-путь), и каждый раз это была
        секция, уехавшая вместе со своим `#fragment` — тот самый класс, который
        `mkdocs-redirects` не покрывает и покрыть не может.
  - [x] **Три верхних бокса закрыты 2026-09-07 после проверки по дереву, а не по памяти** (они
        описывали работу, которая была сделана, но так и остались неотмеченными). Проверено:
        девять страниц механики на месте; исключение `schema-check-ignore` на `spec.source.path`
        действительно уехало вместе с пассажем и живёт во front matter
        `gitops-and-the-cue-cmp.md` — то есть мёртвым не стало; в обоих деревьях гайдов **ноль**
        цитат `ADR NNNN`. Оговорка про H3 `migration-plans.md` тоже отработала — на её якорь
        ничего не ссылалось.
  - [x] **Предел слова «закрыт», записанный честно.** Свип закрыл **маршрутизацию цитат** — это то,
        что он и мерил. Механика как таковая из гайдов уехала **не вся**: состязательный аудит
        закрытий (2026-09-07) нашёл пять гайдов, которым некуда сослаться, потому что их страницы
        механики не существует, плюс целиком записанное решение в `recovery.md` и самую плотную
        оставшуюся механику в операторском quickstart. Этот долг — **2.25**, и он именно
        продолжение этого свипа, а не новая тема.
  - [x] Второй пустой заголовок того же класса, найденный тем же аудитом: `## Acting on a plan`
        в `migration-plans.md` стоял без тела, сразу за ним `## CLI surface`. `--strict` такое не
        видит: якорь существует, ссылок на него не было, а читатель приходил в пустоту. Заголовок
        получил своё предложение, `CLI surface` ушёл под него.

- [x] **2.23o — два класса гейта, оба рождены зелёными** · после 2.23n
  - [x] Измерено: 89 цитат, из них **49 ссылок, 37 голым текстом, 3 в бэктиках**, ноль внутри
        фенсов. `adr.rs` голый текст **видит** (это его основная грамматика), но форму отбрасывает —
        `AdrRef` несёт только строку и номер, — поэтому правило «цитата обязана быть ссылкой»
        расширением `adr-reference` не делается: рядом с ним встал отдельный сканер `adr_citations`,
        который написание сохраняет.
  - [x] `adr-citation-form` — 26 голых цитат превращены в ссылки одним коммитом. Литеральный
        показ — фенс и инлайн-код — из класса исключён: там страница **демонстрирует** написание,
        и ссылка сломала бы демонстрацию (список классов на странице гейта — ровно этот случай).
        От `adr-reference` класс на фенсах расходится сознательно, и это записано на месте вызова:
        тот спрашивает, стоит ли решение до сих пор (верно и внутри фенса), эти два — может ли
        читатель по нему перейти.
  - [x] `adr-citation-placement` — **родился зелёным, вопреки плану**. План закладывал recipe-purity
        образец (класс есть, в `just lint` не входит) под 29 цитат, которые некуда переносить.
        Слой механики из 2.23n забрал их все, а последние две в `publish-the-docs-site.md`
        перенаправлены на `how-it-works/the-image-digest.md` и на разобранный пример 2.23p — так что
        отдельная подкоманда отчёта не понадобилась, и оба класса сразу в `just lint`.
  - [x] Шесть тестов, обе стороны каждого правила; размещение проверено мутацией (`is_guide` →
        `false` роняет ровно его тест). Перепись пересчитана в том же коммите: `adr_references`
        63 → 59. Две цитаты ушли из гайда на страницы механики; ещё две — повторы того же номера
        абзацем ниже, которые при переносе строк свернулись в «тот же ADR несёт и это».

- [x] **2.23p — деплой как разобранный пример** · docs-only
  - [x] Ранбук публикации — пять шагов, из которых четыре родовые («приложение на поддомене») и
        только пятый специфичен для этого проекта; пятый уже выполнен, то есть страница сейчас —
        запись о завершённом деплое, а не инструкция.
  - [x] Две новые страницы в `how-it-works/`: как задеплоен сайт документации и как задеплоены
        лендинг с CMS. Именно туда, а не в Contributing: (а) это единственное дерево, где ваше
        правило разрешает ADR-цитаты, а обеим страницам они нужны; (б) `is_guide` — префикс пути,
        поэтому страницы там вне recipe-purity и могут показать настоящие `docker build`, `curl` и
        `kubectl`, которых пример требует, без исключений.
  - [x] Каждая страница: что именно деплоится и где живёт; **таблица «что за что отвечает и откуда
        берётся»**, по строке на звено цепи, в каждой ячейке — реальный путь; `--8<--` инклюд
        настоящих `Application.cue` и `Caddyfile` вместо копий (механизм заработал в 2.23e);
        схема триггеров; **и осознанные отсутствия** — чего в манифесте нет и почему.
  - [x] Цепочка лендинга — пять потоков образов, четыре workflow, три манифеста и **ни одной
        публичной страницы**; единственные сквозные описания это `landing/DEPLOY.md` и два
        gitignored русских файла в корне. Отсюда три фактические нестыковки, которые страница
        унаследует, если писать её с них: `DEPLOY.md` описывает host-деплой, который кластер уже
        заменил; preview-манифест запинен на неверный тег; и код-путь, и контент-путь пишут
        `:latest`. Их надо решить до написания, а не после.
  - [x] Список редакции — обязателен: креды, внутренние хостнеймы, всё, что запрещает правило
        гигиены `docs/`.
  - [x] Две из трёх нестыковок оказались **продуктовыми, а не текстовыми**, и записаны как
        `D30`/`D31` в `docs/measurements/day2-followups.md` вместо того, чтобы попасть на
        публичную страницу: preview-манифест лендинга запинен на `:latest` — тот же тег, что
        смотрит прод, — то есть хост предпросмотра сегодня показывает то, что уже опубликовано,
        и шаг инспекции, ради которого построена вся цепочка промоушена, инспектирует живое;
        и `landing/DEPLOY.md` описывает systemd+podman деплой, который кластер заменил.
        Обе — правки живого деплоя, поэтому за владельцем.
  - [x] Третья чинилась безопасно и починена: комментарий в манифесте CMS утверждал
        «DATABASE_URL auto-injected via needs.pg claim» прямо под строкой, которая связывает его
        явно, — автоинъекцию убрали в 2.12. Страница включает этот манифест дословно, так что
        публикация унесла бы и противоречие.

- [x] **2.23q — вернуть 2.21 то, чего у неё нет: план** · передача, не исполнение
  - [x] **План написан:** `docs/superpowers/plans/2026-09-06-2.21-public-feature-ledger.md`
        (дерево gitignored — файл только на этой машине). Пять задач = 2.21a–d + закрытие.
        Три решения, которые спека оставила открытыми, приняты в плане с доказательствами:
        **D1** `Post-launch` не получает записи в реестре и его ячейки не становятся ссылками —
        оба варианта спеки неверны (свернуть в `managed` = ложь: обе строки OSS-core на кластере
        клиента; отдельная запись = ссылка в никуда, потому что `Roadmap.astro` рисует карточку
        на запись CMS-контента, а не реестра, и кнопка живёт на карточке). **D2** второй словарь
        меток — `◆` в силе сегодня / `◇` ещё нет. **D3** две строки (#17, #18) выражены целиком
        внутренним словарём, публичная формулировка предложена и вынесена на приёмку.
  - [x] **Поправка к посылке:** переписывание статусной страницы принадлежит **2.21b**, а не 2.22 —
        2.22 про эту страницу не говорит вообще. То, что вы помните как правку, — 2.23f, и она
        была проходом на честность, а не переписыванием.
  - [x] Спека **жива и полна**: `docs/superpowers/specs/2026-08-29-public-feature-ledger-design.md`,
        290 строк, с §5 «The work», разбитым ровно на 2.21a–d. **Плана по ней нет** — подфаза
        остановилась на границе spec → plan. Осторожно: дерево `docs/superpowers/` gitignored,
        спека существует только на этой машине.
  - [x] Состояние страницы измерено и не изменилось структурно с базовой линии FEATURE_TRACKER:
        205 строк, 11 таблиц, 47 строк данных, **те же пять колонок в каждой таблице**, 8 секций
        `## order N`, **965 слов прозы в блоквотах** в 11 блоках, **ноль строк со ссылкой или
        якорем**. Корневой `FEATURE_TRACKER.md` был сокращён до пятистрочного указателя тем же
        коммитом, который опубликовал страницу, — то есть `/status/` буквально и есть
        опубликованный трекер.
  - [x] Честный учёт того, что 2.23f сделала здесь **хуже**: она добавила десять строк в старой
        пятиколоночной форме и свежее описание внутреннего процесса — то есть слегка увеличила
        объём работы 2.21b.
  - [x] Шаг 2.23: не переписывать страницу здесь, а **написать план по выжившей спеке** и поднять
        2.21. Заодно 2.21d сейчас нестартуема как записана: с лендинга на `/status/` не ведёт ни
        одна ссылка, ни одна ячейка Phase не является якорем, и метка `Post-launch` в реестре
        по-прежнему без записи.

### 2.24 Гайд не отправляет читателя в исходники

> 🏁 SR: A · order 3.7b — правило владельца от 2026-09-06, поверх ADR 0058

> ✅ **ЗАКРЫТО 2026-09-06** (docs-only + класс гейта; без бампа CLI и монорепо-тега).

**Правило (владелец):** «в гайдах такие ссылки должны вести только на страницы из How it works,
а там уже можно на исходники ссылаться, но лучше на ADR, т.к. код может меняться». Записано
поправкой к ADR 0058 «where the repository may be named».

- [x] **2.24a — ссылки.** 11 ссылок на 7 страницах гайдов. Семь удалены, а не перенаправлены:
      пять указывали на `schemas/v1alpha1/application.cue` как «authoritative field list», куда
      переносить **нечего** — `docs/reference/index.md` прямо говорит, что генерируемого field
      reference нет, а таблица полей самого гайда и есть опубликованный список; хуже, схема
      объявляет `jetstream`/`clickhouse`/`s3`/`notifications`, которые статусная страница держит
      вне объёма, то есть ссылка приглашала написать ключ, который скомпилируется и никогда не
      провизится. Две ссылки на `spec.md` — роадмап, намеренно не опубликованный, — отправляли
      оператора к непостроенным возможностям.
- [x] **2.24b — кодовые спаны.** Второй проход нашёл ещё 16 в формах, которые правило про ссылки
      не видит. Худшие: путь в чарт **с номером строки**; целая публичная секция
      «The executable version» про e2e-скрипт, который читатель не может запустить и который
      тратит реальные деньги; два раст-типа как авторитет для цепочки, где соседние слова уже
      называли те же ступени по-человечески.
- [x] **2.24c — класс `code-reference-placement`.** Две поверхности, судимые по-разному:
      **ссылка** — адресат, которого у сайта вне `docs/` нет, поэтому запрещена любая;
      **спан** — имя, которое читатель грепает, и часть таких имён законно его
      (`docs-site/Dockerfile` в ранбуке публикации). Спан ловится, только если открывается на
      дереве реализации, а это множество = git-листинг минус allowlist читательских деревьев,
      то есть новая директория покрыта по умолчанию. Одиннадцать тестов; обе половины проверены
      мутацией.
- [x] **2.24d — ссылки на рабочие примеры.** Вторая просьба владельца в том же сообщении.
      Семь мест, каждое привязано к моменту, когда читатель пишет манифест: таблица полей,
      гайд по окружениям, скаффолд и первый деплой, пара declare-and-bind в pg-гайде, три формы
      `env` в гайде по секретам, блок `expose` в гайде по домену, и раздел в индексе dev-гайда.
      Ещё 14 кандидатов отклонены — в основном потому, что ни один пример не объявляет то,
      о чём та страница.
- [x] **Дефект на самой странице примера,** найденный тем же проходом: оба манифеста лендинга
      несут блок `environments`, а страница о них молчала, при этом её единственная проза про
      «вторую копию приложения» — про отдельный preview-манифест. Читатель мог прочесть
      `environments.dev` как preview-хост. Страница теперь их разделяет.

**Порядок 2.23i–q.** `2.23i` первая и одна: без записанного правила свип нечем судить.
`2.23j`, `2.23k`, `2.23l`, `2.23m` ни от чего не зависят и идут когда угодно. `2.23n` — после
`2.23i`, и ловушку с `behaviour-claim` снимает внутри себя, а не после. `2.23o` — после `2.23n`,
потому что классу размещения нужны существующие назначения. `2.23p` независима. `2.23q` —
передача, исполнение уходит в 2.21.

### 2.26 `e2e-gateway-nightly` — красный 55 ночей подряд

> 🏁 SR: A · order 3.7c — найдено 2026-09-10 по указанию владельца

> ✅ **ЗАКРЫТО 2026-09-10** (e2e + docs; без бампа CLI и монорепо-тега). Прогон **зелёный
> локально дважды** в rootful microVM: 12м59с на первой редакции, повторно — после правки
> четырёх дефектов, которые состязательная проверка нашла в моём же коде.

- [x] **Диагноз: продукт был прав, прогон устарел.** Фаза 9 патчит `expose.network`
      `public → internal` и сразу ждёт прунинга HTTPRoute. Но 2.16b (коммит `90664d7`,
      **17 июля**) научил оператора гейтить деструктивную правку: он заводит `MigrationPlan`,
      встаёт на паузу — и маршрут **правильно** остаётся. Последний зелёный прогон — 17 июля,
      первое падение — 18-го. **55 падений за 55 дней.** Ни одна ночная джоба ни о чём не
      уведомляет, поэтому это никого не разбудило.
- [x] **Фаза 9 переписана и теперь покрывает больше, чем до поломки:** гейт срабатывает
      (`AwaitingMigrationApproval` + `MigrationPending=True`); **один** план гейтит **оба**
      кандидата (`domain-change` + `network-visibility-change` — один патч, два триггера,
      заголовок выигран по алфавиту, а не по важности); маршрут **держится и продолжает
      отдавать 200** всё окно удержания; одобрение потребляет план; и только тогда маршрут
      прунится, `endpointURL` переворачивается точным сравнением, а анти-луп проверяет, что
      гейт не перевзвёлся.
- [x] **Четыре ловушки, которые проверка сняла до прогона:** утверждение про исчезновение
      `PublicRouteReady` стало бы **тавтологией** — пауза пишет ровно два условия и заменяет
      весь массив, так что оно исчезает в момент гейта, а не прунинга; ожидание
      `.status.phase == pending-approval` на свежем плане **зависло бы на весь таймаут** (у
      плана вообще нет status, фаза дефолтится при чтении); имя плана нельзя собрать — в нём
      unix-таймстамп, ищется по лейблам, а прогресс обязан идти в stderr, иначе он попадает в
      `$(...)`; и `apprafter migration approve` здесь не работает — CLI резолвит kubeconfig
      через target-store, которого этот прогон не создаёт.
- [x] **Четыре дефекта в уже применённом коде,** найденные тем же ревью: сравнение
      `endpointURL` могло пройти на двух пустых строках; проба удержанного маршрута была
      однократной там, где фаза 7 ретраит до 18 раз — любой транзиент печатал бы «перестал
      отдавать, пока правка лишь удерживалась», то есть ложное падение, читающееся как
      регрессия продукта, в той самой ночной джобе, которую 55 раз прочли неправильно; проба
      не проверяла HTTP-код; и мой же комментарий обещал защиту от SIGPIPE, которой код не
      имел — `printf | grep -q` та же форма конвейера. Исправлено, включая идентичное место в
      фазе 7.
- [x] **Break-glass в гайде молча не работал.** `docs/operator-guide/migration-plans.md`
      документирует одобрение без `--subresource=status`. CRD объявляет статус-субресурс, поэтому
      apiserver **отбрасывает** stanza, `kubectl` печатает `patched` и выходит 0, план не
      двигается — а контроллер припаркован на `await_change()` и без мутации не просыпается.
      Путь последней надежды, отказывающий бесшумно. Плюс дописано, что нужен cluster-admin:
      не-админу разрешён только переход `pending-approval → approved`, а у свежего плана
      старая фаза пустая, то есть первый же write ему недоступен.
- [x] **Заголовок workflow врал про сборку** — утверждал «No Rust toolchain, no cargo», тогда
      как фаза 6 собирает оператор и вебхук и это половина времени прогона.
- [x] **Комментарий про GatewayClass винил «ненадёжность Cilium».** Механизм другой и
      детерминированный: Cilium 1.16.5 вендорит gateway-api v1.1.0 и пишет `supportedFeatures`
      строками в **том же** status-апдейте, что несёт условие Accepted; закреплённые CRD v1.2.1
      требуют объектов, apiserver отклоняет апдейт **атомарно**, и Accepted не может лечь
      никогда. Ошибка в логе cilium-operator ожидаема и к диагностике падений отношения не
      имеет — теперь так и написано, потому что она стоила этому расследованию времени.

- [ ] **Ночные прогоны никого не уведомляют** — за это 55 красных ночей прошли молча. Минимальная
      починка (джоба заводит/обновляет issue при падении) требует `issues: write`, а заголовок
      этого workflow отдельно фиксирует `permissions: contents: read` как минимум и несёт security-
      note. Расширение прав — решение владельца, не агента. **Вынесено, не сделано.**
- [ ] **Кнопка Approve в Argo CD, вероятно, не работает ни в одном scope** — и ни один прогон её
      не проверяет. У свежего плана `old_phase` пустая, а RBAC-биндинг к `cluster-admin` не даёт
      `system:masters`, поэтому короткого замыкания `is_operator_or_admin` не будет. Проверяется
      одной командой на живом кластере с висящим планом (клик → `kubectl get migrationplan -o
      jsonpath='{.status.phase}'` + лог вебхука): фаза не двинулась и в логе отказ — проблема в
      identity/FSM; фаза не двинулась и тишина — Argo вообще не трогает субресурс. **За владельцем:
      к живым кластерам агент не ходит.**

### 2.25 Долг, вскрытый состязательным аудитом закрытий

> 🏁 SR: A · order 3.7b — открыто 2026-09-07

**Как найдено.** После закрытия 2.21/2.23/2.24 запущен состязательный аудит: пять критиков,
каждый пытается **опровергнуть** то, что закрытия утверждают, плюс независимый проход
подтверждения. 94 находки, 77 подтверждены, 1 опровергнута. Сильнее всего сработал критик,
который шёл по документации **как посторонний, желающий задеплоить приложение**, а не как
ревьюер утверждений — ровно тот проход, который гейты структурно сделать не могут.

- [x] **Закрыто сразу** (коммиты `6d4143f`, `33a14eb`, `f361031`, `6df56d1`): мина в
      `check-cli-version-bump.sh` (сломала бы пуш); ссылки Phase 5/6/8, **сломанные на проде**
      из-за джойна по лейблу; шесть пунктов, которые лендинг продаёт, а ледгер звал
      незапланированными; строки-свойства с кнопкой подписки вопреки собственной легенде;
      блокквот про Backstage, обе половины которого опровергнуты кодом; README с `Phase 5+`;
      смоук-рецепт, который не мог сработать; отсутствие гейта одобрения в §2.5; пустой якорь,
      на который вела глубокая ссылка; три оборванных маршрута гайд → механика.
- [x] **Слой механики достроен.** Пять новых страниц — `sealing-a-secret`, `source-credentials`,
      `the-public-route`, `what-cluster-bootstrap-installs`, `backup-retention-and-checks` — плюс
      раздел про ёмкость, уехавший в `cross-application-shared-volumes`. **Маршрут цел в обе
      стороны:** 22 страницы механики, ни одной недостижимой из гайдов, ноль гайдов без выхода в
      слой механики.
  - **Как писалось.** Черновик каждой страницы делал агент, обязанный подкрепить **каждое**
    несущее утверждение файлом и строкой и отдельно перечислить, чего доказать не смог. Затем
    другой агент пытался опровергнуть, открывая файлы. Вердикты: шесть из шести
    «применить с исправлениями», 33 исправления суммарно. Это окупилось: страница публичного
    маршрута противоречила спецификации Gateway API, на которую опиралась (`*.example.com`
    матчит и `a.b.example.com` — верно то, что wildcard никогда не матчит apex); страница
    бэкапов говорила «два потолка» в трёх местах и перечисляла три; страница бутстрапа
    ссылалась на нумерацию, которой ниже нет.
  - **Найденные попутно противоречия в самом продукте:** справка `secret seal` утверждала, что
    `upgrade-tier` переносит запечатанное, тогда как команда печатает, что апгрейды тиров не
    реализованы; **ADR 0049 §6** описывал `CapacityWarning` как долю свободного места на **ноде**,
    хотя 2.22d перенаправил его на использование самого тома, а сигнал ноды — в `NodeDiskPressure`.
    Оба починены в тех же коммитах.
  - **Одно предложение верификатора отклонено.** Правка снимала типизированный, датированный и
    посчитанный в цензе маркер `check=none` и возвращала тот же `kubectl` инлайн-прозой, которую
    `recipe-purity` не видит по собственному решению. Это обмен проверяемого исключения на
    известную слепую зону. `kubectl` убран из гайда совсем: «когда началось» — это диагностика,
    а страница механики называть `kubectl` вправе.
- [x] **`recovery.md` несёт целиком записанное решение** — заведён **ADR 0060** «no emergency root
      password on a Tier-1 node». В ADR ушли и два варианта, которых гайд не называл (пароль,
      выдаваемый по требованию через API провайдера; и полное отсутствие rescue-пути), и риск,
      который он всегда подразумевал: на T3/T4 «пересобрать за три минуты» перестаёт быть правдой.
      Гайд оставил то, что нужно человеку в беде: консоль не пустит, это намеренно, вход — rescue,
      и консоль всё равно стоит открыть, потому что boot-вывод приходит раньше SSH. Цитаты в гайде
      нет: гайд утверждает, а не аргументирует.
- [x] **`operator-guide/quickstart.md` — самая плотная механика из оставшихся** — уехала в
      `what-cluster-bootstrap-installs.md` вместе с разделением, на которое у quickstart не было
      места: что CLI ставит сам, а что приезжает компонентом чарта под Argo CD. Таблица
      закреплённых версий не воспроизведена, а заменена тем, **откуда версия берётся**, — таблица
      версий на странице для читателя, которому нужны три команды, гниёт по определению.
- [x] **Секция ёмкости в `shared-volumes.md`** — перенесена в
      `cross-application-shared-volumes.md`, и обратная передача темы («читайте про сигнал
      ёмкости в гайде») снята: теперь оба конца указывают в правильную сторону. Секция вдобавок
      была устаревшей — описывала `CapacityWarning` как долю свободного места на ноде.
- [x] **`## Prerequisites` стоит предпоследним** — перенесён выше первого шага на трёх страницах
      зависимостей. Формулировка «verification blocks above» переехала вместе с блоком и стала
      «below». (`connect-a-domain.md` не входила: у неё подготовка кластера и так первым шагом.)
- [x] **Директивы `<!-- docs: … -->` уезжают в публикацию** — сняты в обеих независимых
      реализациях (`llm_export.py` и `docs-artefacts-check.py` выводят правило порознь, потому что
      побайтовое сравнение — «исходник против ожидания», а общий хелпер был бы хуком, который
      подтверждает сам себя). Правило: **целая строка вне фенса**. Половину про фенс написала не
      предусмотрительность — первая версия вычистила строку внутри фенса на странице, которая
      этому синтаксису учит, и артефакт-чек поймал это за один прогон. На живой сборке осталось
      два вхождения, оба — демонстрации на самой обучающей странице.
- [x] **`READER_FACING_TREES` слишком щедр** — измерено: `docs-site/`, `landing/`, `scripts/`,
      `.github/` использует **только** эта страница, все девять спанов на ней. Четыре дерева,
      открытые по всему корпусу ради одного файла, — правило, переставшее значить то, что говорит.
      Список сужен до того, к чему читатель гайда действительно прикасается, а страница
      исключена **по имени** и только из этого класса. Файл не переносили: 2.23e решила это
      сознательно, чтобы внешние ссылки жили.
- [x] **Лендинг продаёт как Phase 3 то, что уже отгружено** — это не маркетинговая правка, а
      исправление ложного утверждения: ледгер держит ту же строку как `Shipped ✅`, и читатель,
      пришедший по ссылке, получал два ответа на один вопрос. В fallback снято; живой CMS выписан
      в `CMS_PROD_CHANGES.md`. Automatic DNS остаётся Phase 3 — он и правда не отгружен.

**Вне объёма 2.23:** `Infrastructure` как объект кластера и GitOps-репозиторий инфраструктуры
(оба = ADR-first, см. 2.23d); полный перенос трёх `needs`-рецептов в гайд разработчика (переезд
файлов ради ролевой чистоты — не то, что просил проход); автомерж любых bump'ов.

---

### 2.27 Манифест — это бандл: CLI видит все воркloadы пакета

> 🏁 SR: A · order 3.7d — открыто 2026-09-14 по замечаниям владельца (`cli-fixes.md`)

**Как найдено.** Владелец положил два приложения в один `Application.cue`, поставил в кластер,
увидел в кубе поды обоих — а в `apprafter app list` одно. Разбор показал, что рендер и оператор
multi-app держат полностью (у cue-cmp даже есть фикстура `inject-fixture-multi`), а схлопывает
**только CLI**, в трёх местах «первый побеждает». Причём это не гипотеза: `landing/web/apprafter/`
в этом репозитории **уже** двухворкloadный бандл (`landingWeb` + `landingWebPreview`), и по
порядку имён prod выигрывает каждый из трёх путей — значит `landing-web-preview` недостижим из
CLI вообще.

**ADR:** 0062 (бандл как единица), 0063 (discovery + проверки консистентности), 0064 (`app restart`).
**Планы:** `docs/superpowers/plans/2026-09-14-2.27{a..f}-*.md` — шесть независимых подсистем,
которые **релизятся одним паком**, но планируются и исполняются порознь.

- [x] **a. cue-cmp: discovery по repo-relative пути + контенту, перечисление каталогов-пакетов
      вместо жадного `cd`, отказ на двусмысленную регистрацию и на неконсистентный бандл.**
      Измерено: четыре раскладки сегодня либо тихо прунят
      приложение, либо краснеют, либо рендерят 1 документ из 2 без предупреждения. Гейт на
      абсолютном `$PWD` запрещён — базу рабочего каталога CMP задают `ARGOCD_CMP_WORKDIR` и
      `TMPDIR`. Плюс `scripts/check-cue-cmp-mirror.sh`: зеркало `plugin.yaml` в
      `component_argocd.cue` монтируется **поверх** копии в образе, и ничто их не сверяло.
      Поставлено в argocd-cue-cmp 0.1.26 / platform-stack 0.2.72 (ADR 0063): вложенный каталог
      сворачивается в объемлющий пакет и называется на stderr, сиблинги под одной регистрацией —
      отказ; publish-workflow чарта теперь ждёт образ сайдкара, который чарт пинит.
      `apprafter app validate` двойников этих четырёх проверок пока не несёт — это `b`, поэтому
      отказ сознательно на него не ссылается. test-discover 5 → 20 кейсов, test-inject 43 → 105
      утверждений, всё проверено ещё и на busybox ash 1.36.1 (`alpine:3.20`).
- [x] **b. CLI: бандл-модель.** `parse_applications`, плюральный резолвер вместо
      `find_apprafter_app_name` (шим в итоге удалён, а не оставлен рядом), `app_index`, единая
      адресация `--workload <name>` при позиционном аргументе-регистрации (ADR 0062), переработка
      `list`/`status`/`remove`/`logs`/`open`/`rollback`/`unpin`, кардинальная pin-aware ячейка
      HEALTH, чтение `status.conditions[]` Argo в `app status`, локальный двойник проверок бандла
      в `app validate`, отказ на `--path` в файл.
      Плюс фикс `argo_app_selector` в `restore.rs` — он сравнивает имя CR с лейблом, чей смысл
      «имя регистрации», из-за чего `restore --data-only` грузит Postgres под живыми подами.
      Поставлено тремя планами: b-1 → `v0.2.67`, b-2 → `v0.2.68`, b-3 → `v0.2.69`.
- [x] **c. `app restart`** (ADR 0064). Прежний отказ был рамкой объёма подфазы 2.20 и уже отозван
      поимённо в `day2-followups.md` для случая ротации кредов. Измерено на kind: аннотация
      pod-template от CLI переживает SSA оператора и не откатывается Argo.
      Поставлено: частичный SSA только на `spec.template.metadata.annotations`, запись — на CR
      (расщепление ADR 0059). Три отказа: пауза миграции НЕ блокирует (роллится уже применённый
      шаблон, протолкнуть загейченное изменение нельзя — печатается строка об этом); ноль реплик
      отказывает, а не рапортует успех; регистрация, чей git рендерит Deployment напрямую,
      отказывает (Argo CD владеет объектом и откатил бы аннотацию).
- [x] **d. Namespace.** `secret seal` предлагает создать с подтверждением (молча — никогда,
      в том числе под `--yes`: блоб привязан к namespace необратимо); `secret remove` перестаёт
      печатать `✓ Removed` для того, чего не было; `secret list -n` и `volume list/status/remove`
      перестают читать отсутствующий namespace как пустой.
      **`app add` уже поднимал namespace сам** — Argo CD делает это через `CreateNamespace=true`
      в syncOptions, пункт был записан из неверной посылки. Реальный дефект оказался соседним:
      destination namespace и `metadata.namespace` манифеста никем не сверялись, а Argo CD создаёт
      первый и применяет воркloadы во второй, не примиряя их, — то есть при расхождении появляется
      пустой namespace, а приложение едет в тот, которого никто не создавал. Визард их
      синхронизировал, флаговый путь — нет; теперь расхождение отвергается с обеими починками.
      Проба namespace отвечает «отсутствует» только на однозначный 404: `Namespace` — объект
      cluster-scoped, и отказ RBAC не должен читаться как отсутствие, иначе namespace-ограниченный
      читатель теряет команды, на которые имеет право.
- [x] **e. `apprafter top`** — capacity / allocatable / requested / schedulable / in-use / free по
      памяти, CPU и диску, с разбивкой на платформу, интегрированные сервисы и приложения.
      IN-USE измеряется: `metrics.k8s.io` для CPU и памяти, kubelet Summary API для диска; где
      источника нет — ячейка `—` и предложение-ошибка кластера под таблицей, но НИКОГДА не `0`.
      Мультинодовость с самого начала; общий итог отсутствует, а не занижен, если хоть одна нода
      не измерилась. Диск — `ephemeral-storage`, то есть корневая ФС целиком, поэтому IN-USE ноды
      законно больше суммы колонки `DISK USE` (только writable layer, логи и emptyDir подов);
      вывод говорит это прямым текстом, а не оставляет вычесть. Строка `other` в норме пуста и
      существует, чтобы сдвинувшийся классификатор объявлял себя, а не терял поды молча.
- [x] **f. Слой отображения.** `cli_core::timefmt` (абсолютное + относительное) и
      `cli_core::quantity` (парсер и человекочитаемый рендер величин) — оба в `cli-core`, потому
      что формат был приватным для `platform.rs`, и именно поэтому не расходился.
      Переведены: `target domain list` (`addedAt`), `secret list` (`SEALED`), история ревизий и
      строка пина в `app status`, таймстамп в тегах `backup list`. Пункты `cli-fixes.md`: домен
      приложения и читаемые размеры VPA в `app status`, сортировка `backup list` от нового к
      старому. Namespace в `app list` и multi-app закрыты ещё в `b`; времени в `app list` больше
      нет вовсе — колонка ушла вместе с PROJECT/REV.
      Попутно: подсказка VPA про uncapped жёстко называла `resources.limits.memory` **изнутри
      цикла по ресурсам**, то есть при упёршемся CPU советовала поднять память.
      Аудит нашёл меньше мест, чем оценка «восемь»: `resolvedAt` уже рендерился относительным
      возрастом, `platform status` уже шёл через общий формат, а чтения `creationTimestamp`
      в `cluster-bootstrap` — арифметика, а не вывод.

> **Ручной прогон по треку 2.27 ещё не делался.** `c`–`f` поставлены и зелены на юнит-уровне
> (включая мутационные тесты на каждый нетривиальный гард), но ни одна из команд не исполнялась
> против кластера, а `top` вдобавок зависит от двух grant'ов, которые подтверждаются только живьём:
> `metrics.k8s.io` и `nodes/proxy`. Строки в `docs/status.md` до прогона — `🚧`, не `✅`.

> **Долг из 2.27a, едет со следующим функциональным изменением cue-cmp (не отдельным релизом).**
> `bundle_refuse` в `argocd-cue-cmp/entrypoint.sh` сознательно НЕ печатает строку «проверьте
> локально через `apprafter app validate`»: в 2.27a её убрали, потому что локальных двойников
> четырёх bundle-проверок не существовало и команда отвечала `✓ valid` ровно на то, что сайдкар
> отказывал. С b-3 (`v0.2.69`) они есть, и строку надо вернуть. Это правка chart-source ⇒
> принудительный бамп `argocd-cue-cmp` + `platform-stack`, поэтому по правилу «косметику не
> релизим отдельно» она ждёт ближайшую функциональную правку сайдкара — `c`–`f` её не затрагивают,
> так что метка живёт здесь.

**Вне объёма 2.27:** soft-condition `HostnameUnique` в операторе (ADR 0063, строка I5) — это
свойство **кластера**, а не бандла: два бандла из разных репозиториев сталкиваются так же.
Нужен оператор + ветка в Lua-healthcheck чарта, то есть свой план и своя релизная цепочка.
Автоматический ролл по хешу секрета (ADR 0064, alternatives) — отложен к Tier 2+ как opt-in;
он не заменяет глагол, потому что таймер не знает, где кончается последовательность правок.

---

### 2.28 Поверхность манифеста: пробы и тюнинг JetStream

> 🏁 SR: A · order 3.7e — открыто 2026-09-15 по двум находкам владельца в манифесте

> 🚧 **В РАБОТЕ.** Трек A закрыт с зелёным живым прогоном; у трека B нет прогона (см. ниже).
> Релиз не резан — 2.28 и 2.29 едут одним паком, потому что обе меняют CRD `Application`,
> а два CRD-апгрейда подряд на живом кластере — риск без выгоды.

**ADR:** 0065 (два раздела; раздел про jetstream — амендмент к ADR 0061 §6).
**Спек:** `docs/superpowers/specs/2026-09-15-2.28-probes-and-jetstream-tuning-design.md`.
**План трека A:** `docs/superpowers/plans/2026-09-15-2.28a-probes.md`.
**Замеры:** `docs/measurements/2.28-jetstream-2026-09-15.md` (nats-server 2.14.3).

- [x] **a. Пробы.** `#Probes`/`#Probe` на `#ApplicationSpec` и `#ApplicationEnvOverride`; форма
      разводится наличием `path` (есть — HTTP GET, нет — TCP connect), а не k8s-овским вложением
      `httpGet`/`tcpSocket`: та форма несёт пять видов действий, эта — два. Тайминги целыми
      секундами под именами k8s, чтобы `"500ms"` было невыразимо. Новый модуль
      `operator-rendering/src/probes.rs`, `merge_probes` в семью частичных override'ов 2.16c, пять
      правил вебхука, строка эффективной конфигурации в `app status`, блок в шаблоне `app scaffold`,
      фикстура `examples/applications/probes-app.cue`, регрессия на живом apiserver в
      `scripts/validate-crds.sh` (поля не прунятся + паттерн `^/` живой).
      **Два поведения платформа добавляет сверх объявленного** и оба названы в ADR: TCP-readiness по
      уже объявленному `expose.port`, когда readiness не объявлена (иначе каждый роллаут даёт окно
      502), и startup-проба, выведенная из liveness с собственной каденцией 5s/60 — период liveness
      отвечает на вопрос «как быстро поймать зависание», а не «сколько терпеть старт».
      **Прогон `e2e/probes-walk.sh` GREEN 8/8** на kind под rootless podman: readiness проверяется
      на `Endpoints`, а не на condition; liveness перезапускает **заклиненный** процесс, пока
      readiness на другом пути продолжает проходить; у фазы про выведенную startup есть контрольный
      случай, без которого она доказывала бы только «приложение успело».
      **Сознательно вне прогона** (названо в шапке скрипта): admission-webhook (его чарту нужен
      cert-manager) и любая команда CLI (все `app`-глаголы резолвятся через регистрацию Argo CD).
- [x] **b. Тюнинг JetStream + DLQ — код.** 12 полей стрима и 21 поле консьюмера, каждое 1:1 на
      одноимённое поле NACK, с проверенными по CRD написаниями перечислений (`byStartSequence`, не
      `by_start_sequence`). Одиннадцать полей **объявлены ради отказа** (шесть изоляционно-опасных
      + весь push-контур): структурная схема прунит неизвестное поле ДО вебхука, поэтому
      `mirror:` иначе исчезал бы молча. `deadLetter` разворачивается в **обычный declared stream**
      через единый список `materialised_streams`, который читают и `claim_view`, и реконсайлер —
      иначе DLQ существовал бы в NATS, а allow-list, deny-вектор, сумма квоты и детектор захвата о
      нём бы не знали. `stream_object`/`consumer_object` приняли типизированный аргумент вместо
      дюжины позиционных. `e2e/jetstream-nack-shape-check.sh` **GREEN** — все 31 поле принимает и
      хранит настоящий CRD запинённого nack 0.35.0.
      **Замеры изменили две записи ADR:** сообщение в `workqueue` после исчерпания `maxDeliver`
      **не удаляется** (тело достаётся через `STREAM.MSG.GET`, консьюмер идёт дальше), и
      `maxDeliver > len(backoff)` — **строго** больше (10116), где черновик писал «ограничен».
      Третий замер дал второе серверное кросс-правило: `discardPerSubject` требует `discard: new`
      **и** `maxMsgsPerSubject > 0` (10052).
- [x] **c. Живой прогон трека B — GREEN 21/21.** `needs-jetstream-walk.sh` вырос с 17 до 21
      проверки: тюнинг консьюмера и стрима читается с ЖИВОГО сервера, DLQ подтверждается как
      обычный declared stream, собирающий ровно advisory этой пары, и он **наполняется** после
      исчерпания редоставки. Строка в `docs/status.md` поднята до `✅`.
      **Поправка к более раннему утверждению в этом же файле:** я записал, что прогон блокирован
      потребностью в Cilium. Это неверно. `needs-jetstream-walk.sh` поднимает обычный kind с
      kindnet, bootstrap идёт с `APPRAFTER_BOOTSTRAP_SKIP_CILIUM=1`, а CNP там — инертный объект
      под stand-in CRD (сам файл это и говорит, прямым текстом). Ошибка возникла из грепа по
      СПИСКУ файлов на `kind_up_cilium`: совпадение было комментарием, объясняющим обратное, и я
      его не открыл. Прогон запускается на хосте.

> **Прогон нашёл мёртвый ключ, и это главный результат трека.** `consumerLimits` объявлялся,
> хранился и НИЧЕГО не делал: CRD его принимал, провижионер эмитил, NACK отвечал 200, а живой стрим
> показывал `consumer_limits: {}`. Причина не в сервере — она в NACK: запинённый
> `natsio/jetstream-controller:0.24.0` запускается в LEGACY-режиме (`--control-loop` по умолчанию
> `false`), а его строитель мапит сорок с лишним полей стрима и `ConsumerLimits` — ноль раз.
> Реализация есть только в новом controller-runtime, недоступном без флага, который сам лог NACK
> называет экспериментальным. Проверил так же остальную поверхность: **все** прочие поля стрима и
> **все** поля консьюмера в legacy-строителе есть; мёртвый ключ ровно один, и он переведён в
> declare-to-reject с отказом, называющим работающую альтернативу.
>
> **Методологическая половина важнее.** Пропустили три гейта, и все три отвечают на вопрос «принято
> ли поле»: CRD хранит, NACK-CRD хранит (`jetstream-nack-shape-check.sh` ровно это и утверждал),
> apiserver отвечает 200. Ни один не отвечает «читает ли это кто-нибудь». Round-trip — не доставка.
> Shape-check теперь несёт это ограничение в собственной шапке, а проверка №19 инвертирована:
> дешёвая ошибка здесь — вернуть ключ, увидеть, что CR его прекрасно хранит, и больше не посмотреть
> на живой стрим.

> **Попутно закрыты две дыры в самих гейтах**, обе найдены тем, что в них упёрлись.
> `crdgen` молча пропускал вид без Rust-арма (`_ => return None`), из-за чего новый CRD прошёл ось
> Rust↔CUE не будучи проверенным ни разу. `WORKSPACE_SCHEMAS` — рукописный список, чей комментарий
> обещает зеркало каталога `schemas/v1alpha1/`, но ничто это не сверяло; пропущенный файл **не
> ломает сборку**, он ломает docs-гейт сообщением про нашу же внедрённую копию, которое читается
> как сломанный манифест пользователя. Обе теперь с тестом, обе мутационно проверены.

> **Нейминг `probes`, а не `healthcheck`** — поднято владельцем, обсуждено, оставлено. `healthcheck`
> это канон Docker/Compose, `probe` — канон Kubernetes; решает то, что **содержимое блока уже
> k8s-ное** (целые секунды под именами `periodSeconds`/`failureThreshold`), поэтому докеровское
> существительное вокруг кубовых полей поместило бы несогласованность внутрь одного блока. Плюс
> единственное число держало бы три вещи с разными смыслами. Отложенное упоминание
> `spec.healthcheck` в 1.79b Part 4 этим отменяется.

---

### 2.29 Общая база данных и расширения PostgreSQL

> 🏁 SR: A · order 3.7f — открыто 2026-09-15; отдельный ADR и отдельный пункт по решению владельца,
> **релиз общий с 2.28**

> 🚧 **В РАБОТЕ.** Поверхность манифеста, валидация и SQL готовы; рантайма нет — общую базу пока
> ничем не создать.

**ADR:** 0066 (следует ADR 0049 и расходится с ним ровно в двух местах, оба аргументированы).
**Спек:** `docs/superpowers/specs/2026-09-15-2.29-shared-database-and-pg-extensions-design.md`.
**Замеры:** `docs/measurements/2.29-shared-database-2026-09-15.md` (PostgreSQL 18.4, Dragonfly v1.37.0).

- [x] **a. Схема и валидация.** CRD `SharedDatabase` (namespaced, свой жизненный цикл);
      `ref`/`access`/`extensions` на общем `#ServiceNeed` — это ось, которую ADR 0049 §2 сам назвал
      кросс-секущей; `sharedRef`/`access`/`extensions` на `ResourceClaimSpec`. Ссылочный need
      **порождает тот же claim**, что и собственный (в отличие от `needs.disk.ref`, который не
      порождает никакого): у привязки к базе есть что провижионить на потребителя — роль, пароль,
      секрет, — и это оставляет `claim.<type>.*`, egress-правило, гейт готовности и GC без единой
      правки. Правила вебхука: `ref` несовместим с `size`/`persistent`/`selector`, `access` без
      `ref` отклоняется (проигнорированный уровень доступа — это приложение, считающее себя
      read-only и не являющееся им), `ref` на неимплементированном типе отклоняется, `ref` с `/`
      получает отдельное сообщение про неймспейс. Расширения ограничены **allow-list'ом**, а
      требующие `shared_preload_libraries` отказываются **отдельной причиной**.
      В статусе `SharedDatabase` **намеренно нет `connectionSecretRef`** — у каждого потребителя
      свой кред, и общий секрет там был бы ровно тем, против чего CRD затевался; на отсутствие
      есть тест.
- [x] **b. SQL ролевой модели.** Чистые строители `shared_pg.rs` + `e2e/shared-pg-sql-check.sh`,
      который исполняет **их собственный вывод** на живом PostgreSQL 18.4 и заканчивается не на
      «операторы прошли», а на свойстве: таблица, созданная одним rw-потребителем, принадлежит
      **группе**; второй rw-потребитель её читает и пишет; ro читает, а его `INSERT` отклоняется;
      платформенная роль по-прежнему не суперпользователь. **GREEN.**
- [x] **c. Расширения для СОБСТВЕННОЙ базы — замкнуты.** Манифест → allow-list вебхука → claim →
      `Database` CR → проверка доступности на живом сервере → условие. `pgvector` работает через
      `needs.pg.extensions` без всякой общей базы. Список эмитится только когда он непустой: пустой
      список — это утверждение «у этой базы не должно быть расширений», которое подралось бы с тем,
      что пользователь создал руками; отсутствие ключа означает «манифест ими не управляет».
      Проверка доступности спрашивает **живой сервер**, а не выводит из allow-list: существует ли
      `vector` — свойство ОБРАЗА, образ не запинён, и бамп CNPG может унести его из-под живой базы.
      Отказ подключения при этом **не** валит claim — недоступный сервер и отсутствующее расширение
      это разные находки, и ронять claim на сетевом моргании было бы неверно.
- [x] **d. ACL общего кэша + pg-клиент.** Общий канальный префикс (каналы не скоупятся по `$N`,
      поэтому пер-юзерный префикс оставил бы двух потребителей одного кэша без общего pub/sub) и
      явные `-publish -spublish` у ro — потому что **измерено**: `-@write` их не запрещает.
      `pg_client.rs` по образцу redis/nats-швов; ни один вариант ошибки не несёт ни текста
      оператора, ни DSN — строка bind'а содержит пароль, поэтому сбой называется **индексом** в
      батче. `e2e/shared-pg-sql-check.sh` вырос до шести шагов и гоняет клиент против того же
      контейнера: psql не может наблюдать ни секвенирование батча, ни атрибуцию по индексу.
- [x] **e. Рантайм — прогон GREEN 67/67.** Контроллер `SharedDatabase` (обе ветки: pg через
      группы + CNPG `Database`, redis через собственный `$N`), путь привязки claim'а по `sharedRef`
      (обе ветки), CLI `apprafter db create/list/status/rm`, триггер ADR 0052 #17 на первый бинд
      пары + отдельный #17b на эскалацию `ro→rw`, RBAC в том же коммите, фикстуры,
      регрессия `crd-validate`, `e2e/shared-database-walk.sh` — **GREEN, 67 проверок, 0 отказов**.

> **Восемь дефектов, все молчаливые.** Шесть найдены сверкой кода с его же комментариями и
> обещаниями ADR, два — живым кластером. По убыванию последствий: реапер шёл на dwell, чтобы
> удалить CNPG-кластер под живой общей базой (каждая инвентаризация «этим кто-нибудь пользуется»
> написана в терминах claim'ов — аллокатор `$N`, снапшот `RetainedClaim` и реапер; общая база
> невидима всем трём); `drop_groups` не мог отработать никогда, потому что `DROP OWNED BY`
> действует в пределах одной БД, а путь удаления снимал финализатор в том же проходе — группы
> утекали **при каждом** удалении; `unbind_consumer` был написан, покрыт юнит-тестом на форму строк
> и **не имел вызывающего**, так что «отзыв доступа на приложение» был ложью, а когда вызывающий
> появился — падал, потому что `REASSIGN OWNED BY` требует членства, а не admin option (тот же
> класс, что уже исправил §3.1 ADR, одной функцией позже); allow-list расширений не применялся к
> `SharedDatabase` вовсе, и `--extension dblink` доезжал до superuser'ного `CREATE EXTENSION`;
> запись статуса на путях отказа **стирала** backing под SSA, из-за чего удаление во время сбоя
> бэкенда пропускало дроп базы; вебхука на удаление привязанной базы не существовало, хотя ADR §6
> его требует, — объект молча вис в Terminating; на свежем кластере pg-ветка 404-ила на
> CNPG-кластере, который создал бы собственный claim, и докладывала это **отсутствием статуса**.

> **`unbind_consumer` и `drop_groups` не исполнялись нигде** — написаны, покрыты юнит-тестами на
> форму строк, оставлены без вызывающего, и оба оказались сломаны, когда вызывающий появился.
> `e2e/shared-pg-sql-check.sh` вырос до восьми шагов и гоняет теперь и их: цикл диагностики минута
> вместо двенадцати, и именно он назвал обе причины, пока прогон мог сказать только `db error`.

> **Половина потерянных прогонов — дефекты самого прогона, и они дороже багов.** Автосинк Argo CD
> отключался ПОСЛЕ сборок образов и все эти минуты откатывал веточные CRD и ClusterRole; веточный
> `ValidatingWebhookConfiguration` не применялся никогда, так что новое правило вебхука было
> невидимо; `GROUPS=` — встроенная переменная bash, и проверка сверялась с GID; диагностика читала
> лог **умирающего** пода. Каждый симптом читался как баг продукта. Записано в
> `reference_walk_shell_assertion_traps`.

> **Аллокатор `$N` не видел общих баз, и это была потеря данных, а не неточность.** Общий кэш
> держит свой `$N` в СОБСТВЕННОМ статусе — у его потребителей `sharedRef` и никакого `dbnum`, —
> поэтому `used_dbnums`, читавший только claim'ы и снапшоты, выдал бы тот же номер следующему
> собственному redis-claim'у и посадил бы двух несвязанных арендаторов в одно пространство ключей,
> где GC любого из них делает `FLUSHDB` другому. Срез `SharedDatabase` сделан **обязательным**
> параметром, а не дефолтным: компилятор задаёт этот вопрос на каждом будущем месте вызова.

> **Паттерн имени расширения расходился с allow-list'ом вебхука.** Первый черновик запрещал `-`,
> а в allow-list'е двумя файлами дальше лежит `uuid-ossp` — apiserver отказывал в стандартном
> contrib-расширении, которое платформа в другом месте разрешает, и отказывал ошибкой паттерна,
> не называющей причину. Обе стороны теперь проверяются в `crd-validate`.

> **Поднятие pool-инстанса вынесено в одну функцию.** Общий кэш занимает `$N` на ТЕХ ЖЕ
> инстансах, что и собственный claim; две реализации означали бы, что вторая по порядку применит
> `Dragonfly` CR, противоречащий первой, и прокрутит StatefulSet под живым арендатором — ровно тот
> найденный прогоном отказ, из-за которого посев ACL-файла стоит перед созданием CR.

> **Замер опроверг ролевую модель, и это записано в ADR как исправление.** Черновик §3.1 поручал
> `managed.roles` создавать групповые и потребительские роли. Не работает: роль с `CREATEROLE` без
> суперпользователя администрирует только то, что создала сама, поэтому ни
> `ALTER ROLE … SET ROLE`, ни `CREATE ROLE … IN ROLE <группа>` над чужими ролями не проходят;
> а владеть базой от имени группы можно только будучи её участником **с SET**. Итог: CNPG создаёт
> одну роль, остальное — провижионер, и управление паролями потребителей общей базы уезжает из
> CNPG. Уцелела та половина, которую замер подтвердил прямо: участнику группы
> `ALTER DEFAULT PRIVILEGES FOR ROLE <группа>` разрешён.

> **Ещё один — в коде, а не в ADR.** Строители сначала эмитили `PASSWORD $1`. Обе половины
> невозможны: `DO`-блок не принимает параметров, а `CREATE ROLE` нельзя подготовить вообще. Пароль
> интерполируется через `quote_literal`, блок помечен тегом `$apprafter$`, чтобы пароль с `$$` не
> закрыл тело, и в модуле записано, что строка bind'а **несёт кред и не подлежит логированию**.
> Ни один ассерт на содержимое строки этого бы не поймал — поймало исполнение.

> **Вне объёма 2.29** (и записано в спеке): межнеймспейсный шеринг; третий уровень доступа `owner`;
> произвольный SQL из манифеста; пиннинг образа операнда CNPG — он ничего здесь не гейтит, а
> закрывает другую опасность (бамп CNPG может сдвинуть **мажор** под живым каталогом данных), и это
> отдельный пункт, а не довесок к фиче, которая от него не зависит.

---

## Фаза 3 — Multi-node + Observability (M3) ⚡

**Цель фазы:** платформа поднимается в HA на 3 нодах; observability stack по умолчанию для всех workload'ов.

**Spec:** §6 M3, §4.1 (Tier 2), §4.2, §4.10, §4.4 (OpenBao).

### 3.1 HA-bootstrap в platform-cli + dual-stack validation
> 🏁 SR: A · order 4 — HA-bootstrap (k3s 3-node + kube-vip + embedded etcd, NOT kine+NATS); T2 substrate, pulled C→A

**Source:** ADR 0017.

**Поставка:**
- [ ] `apprafter init --tier team --nodes 3`.
- [ ] k3s server ×3 с `--cluster-init` + joins.
- [ ] Embedded LB через kube-vip (или Hetzner LB).
- [ ] Smoke: убить мастер — kubectl продолжает работать.
- [ ] Explicit dual-stack validation на 3-nodes setup.
- [ ] Cluster-CIDR и service-CIDR должны быть dual notation на HA bootstrap.
- [ ] E2E: kill master node — kubectl continues working на обоих family.

**M1.5 carry-over:** HA bootstrap теперь means provisioning multiple Hetzner nodes + running through the same Argo CD-managed platform stack pipeline. Helm values for multi-node mode live в platform-stack chart's tier-2 overlay; CLI just orchestrates substrate provisioning + platform-stack reconciliation watch.

**Acceptance:** 3-нодовый кластер за один init; failover мастера < 30s; dual-stack connectivity sustained через node failure.

**Зависит от:** 1.83 (M1.5 closure), 1.13

**Размер:** L (без изменений; dual-stack adds little work поверх HA bootstrap)

---

### 3.2 kine + NATS JetStream как control-plane storage
> 🏁 SR: C — kine+NATS storage; trigger: audit-replayability marketing-critical OR etcd scale ceiling

**Поставка:**
- [ ] NATS JetStream cluster (3 replica, embedded или workload — ADR).
- [ ] kine в etcd-emulation режиме поверх NATS KV.
- [ ] k3s конфиг `--datastore-endpoint=nats://...`.
- [ ] Бенчмарк: API churn 1k objects, сравнение с baseline etcd.
- [ ] Stream подписки для CDC (event log платформы).

**Acceptance:** все стандартные k8s операции (deploy, watch, admission) работают; kine API соответствует etcdctl get/put/watch.

**Зависит от:** 3.1

**Размер:** L

---

### 3.3 Cilium mTLS между workloads
> 🏁 SR: A · order 4 — Cilium mTLS; T2 substrate, pulled C→A

**Поставка:**
- [ ] Включение Cilium service mesh с mTLS.
- [ ] Identity через SPIFFE (через 2.7).
- [ ] Default-deny дополняется identity-based ingress (`fromIdentity: ...`).
- [ ] Hubble видит mTLS handshake.

**Acceptance:** между двумя Applications трафик зашифрован (tcpdump показывает TLS); невалидный SPIFFE → drop.

**Зависит от:** 2.7, 3.1

**Размер:** L

---

### 3.4 OpenTelemetry pipeline по умолчанию
> 🏁 SR: B · order 5 — OTel/Tempo/Prometheus subset (EXCLUDES sidecar auto-inject + full ClickHouse)

**Поставка:**
- [ ] OTel Collector как daemonset.
- [ ] Auto-инжект env vars `OTEL_EXPORTER_OTLP_ENDPOINT` для Application pods (admission mutating webhook).
- [ ] Configurable sampling per Application (`observability.sampling: 0.1`).
- [ ] OneBun + Bun стартеры подключают `@onebun/trace` и `@onebun/metrics` по умолчанию.

**Acceptance:** новый Application без явной OTel-конфигурации шлёт metrics+traces+logs в коллектор.

**Зависит от:** 3.1

**Размер:** M

---

### 3.5 ClickHouse provider (logs + traces)
> 🏁 SR: C — ClickHouse provider; trigger: long-term traces/logs retention signal

**Поставка:**
- [ ] clickhouse-operator (Altinity).
- [ ] `clickhouse-integrated` ServiceProvider: DB per claim, RBAC.
- [ ] Системные DB `_logs`, `_traces` для платформенной observability.
- [ ] Vector / OTel exporter в ClickHouse.

**Acceptance:** логи и трейсы пишутся, видны через Grafana (Datasource ClickHouse).

**Зависит от:** 3.4, 2.3

**Размер:** L

---

### 3.6 VictoriaMetrics integration
> 🏁 SR: C — VictoriaMetrics; trigger: same as 3.5

**Поставка:**
- [ ] VictoriaMetrics single (Tier 2) / cluster (Tier 3+).
- [ ] OTel metrics → vmagent → VictoriaMetrics.
- [ ] Стандартные dashboards в Grafana (operator metrics, NATS, k3s, Cilium).

**Acceptance:** Grafana показывает per-Application latency / RPS dashboards.

**Зависит от:** 3.4

**Размер:** M

---

### 3.7a Hubble enable + Hubble UI + Grafana network dashboards
> 🏁 SR: B · order 5 — Hubble enable + UI subset

**Source:** ADR 0020.

**Поставка:**
- [ ] Включить Hubble в Cilium values within platform-stack chart (per-tier overlay: tier-2 has Hubble enabled, tier-1 doesn't).
- [ ] Hubble UI deploys via Cilium chart; expose internally через Service в `kube-system`; AccessGrant flow для external access.
- [ ] Grafana dashboards для network metrics (имеется `cilium/cilium` upstream dashboards — import + adapt).
- [ ] Standard dashboards: cluster-wide flows, per-namespace flows, per-Application flows (когда Application labels propagated).

**Acceptance:**
- Tier 2+ cluster: `kubectl -n kube-system get pods | grep hubble` показывает Hubble + UI pods running.
- Hubble UI доступен через AccessGrant'у oriented kubeconfig.
- Grafana dashboards показывают real-time flow metrics.

**Зависит от:** 3.1, 3.6 (VictoriaMetrics для metrics storage)

**Размер:** M

---

### 3.7b Backstage flow visualizer plugin
> 🏁 SR: C — Backstage flow visualizer; depends on Hubble + Backstage UX

**Source:** ADR 0020.

**Поставка:**
- [ ] Backstage plugin: card на Application page показывает real-time flow data из Hubble (через Hubble Relay API).
- [ ] «Convert observed flow to policy» button — генерирует PR в Git repository с дополнением Application's `connects.egress` (если destination not yet declared).
- [ ] Filter UI: namespace, identity, time range, L7 protocol.
- [ ] Drop visibility — показывает blocked flows (default-deny enforcement points).

**Acceptance:**
- Developer на Application page видит реальный трафик своего Application.
- Click кнопку → PR with `connects.egress` addition открывается автоматически.

**Зависит от:** 3.7a, 1.10 (Backstage с Application plugin)

**Размер:** M

---

### 3.8 Kamaji + Capsule — multi-tenancy primitives (REWORK)
> 🏁 SR: C — Kamaji + Capsule hard-MT; trigger: first hard-MT or MSP signal (ADR 0038: T2 opt-in)

**Source:** ADR 0023.

**Цель:** установить Kamaji controller и Capsule policy controller как platform services; provision first TenantControlPlane для default tenant.

**Поставка:**
- [ ] Add Kamaji + Capsule components в `apprafter/platform-stack/cue/components/` (kamaji.cue, capsule.cue) с tier-2 overlay enabling them by default.
- [ ] Kamaji datastore — `ResourceClaim` на `pg-integrated` provider (CNPG cluster, dedicated database для Kamaji controller).
- [ ] Provision **default** TenantControlPlane (`apprafter-default`) для случаев, когда юзер не declared explicit Tenant — все existing Applications mapped to default tenant.
- [ ] Capsule controller; configure default Capsule Tenant внутри default Kamaji TCP.
- [ ] Tier 1 path: Kamaji не enabled через tier-1 overlay; Capsule installed standalone на host cluster для policy enforcement (soft mt only).
- [ ] Backstage Tenant overview plugin (basic): list tenants, owners, status.

**Acceptance:**
- Tier 2 bootstrap: `kubectl get tcp -n kamaji-system` показывает default TenantControlPlane Active.
- `kubectl get tenants.capsule.clastix.io -A` показывает default Capsule Tenant.
- Kamaji datastore connects to CNPG; Kamaji state persists через controller restart.
- Tier 1 bootstrap: только Capsule controller; no Kamaji.

**Зависит от:** 2.4 (CloudNativePG), 3.1 (HA bootstrap)

**Размер:** L

---

### 3.8a AppRafter `Tenant` CRD operator integration
> 🏁 SR: C — Tenant CRD; with 3.8

**Source:** ADR 0023.

**Цель:** AppRafter `Tenant` CRD как user-facing primitive; operator translates Tenant declarations в Kamaji TCP + Capsule Tenant.

**Поставка:**
- [ ] CUE-схема `kind: Tenant` в `schemas/v1alpha1/tenant.cue` (полная схема per spec.md §3.9).
- [ ] Admission webhook: validation (datastore selector valid, owners non-empty, quotas reasonable).
- [ ] Operator controller (`operator-controllers/src/tenant.rs`):
    - Reconcile Tenant → Kamaji TenantControlPlane + Capsule Tenant внутри TCP.
    - Watch AccessGrants referencing this Tenant → create RoleBindings cluster-admin within TCP.
    - Status field: phase, observed TCP readiness, Capsule policy enforcement status, current owner count.
- [ ] `apprafter login --tenant <name>` — fetches tenant-scoped kubeconfig.
- [ ] Backstage Tenant view extended: applications inside tenant, current owners, quota usage, policy violations.
- [ ] Cascading deletion: Tenant deletion → graceful TCP drain → Capsule Tenant cleanup → Kamaji TCP deletion.
- [ ] Migration: existing v0.1.x Applications get auto-assigned to default tenant on Tier 2 upgrade.

**Acceptance:**
- Apply Tenant manifest → Kamaji TCP created within 60s, Capsule Tenant configured, AccessGrant references resolve to cluster-admin inside TCP only.
- `apprafter login --tenant blockchain-team` returns kubeconfig that works only for that TCP.
- Tenant deletion drains workloads and cleans up TCP + Capsule resources.

**Зависит от:** 3.8, 4.5 (AccessGrant — for owner mapping; but reconciler can degrade gracefully if 4.5 not yet landed)

**Размер:** L

---

### 3.9 Cilium Egress Gateway + family-aware static egress IPs
> 🏁 SR: C — Cilium Egress Gateway + static IPs; trigger: static-IP-for-third-party-API signal

**Source:** ADR 0017.

**Поставка:**
- [ ] CiliumEgressGatewayPolicy для Application с `network.egressIP.static: true`.
- [ ] Привязка floating IP (Hetzner) к egress-нодам.
- [ ] Family-aware allocation per `Application.network.egressIP.families`. If both `[ipv6, ipv4]` — provision both floating v4 и delegated /64 v6 prefix.
- [ ] Backstage Application view: показать current egress IPs для each family (copy button per address); смена floating IP отражается в UI.

**Acceptance:**
- Трафик от Application к `api.tron.network` идёт с фиксированного IP; смена floating IP отражается в UI.
- Application с `egressIP.families: [ipv6, ipv4]` имеет working egress через оба family; third-party могут whitelist оба адреса.

**Зависит от:** 1.2 (Hetzner provider), 3.1 (HA bootstrap)

**Размер:** M

---

### 3.10 upgrade-tier 1→2
> 🏁 SR: C — upgrade-tier 1→2; post-launch first bundle (~2-4 wks), bundled with 4.16

**Поставка:**
- [ ] Команда `apprafter upgrade-tier --to team`.
- [ ] Превращает single-node в 3+ heterogeneous nodes (добавляет 2+ ноды в Hetzner, joins, переключает kine на NATS HA).
- [ ] Бэкап перед миграцией (snapshot в S3).
- [ ] Rollback при failure.

**M1.5 carry-over:** upgrade-tier теперь means changing `PlatformStack.spec.values.tier: solo → team` + applying tier-2 overlay. PlatformController detects destructive change (significant: Kamaji + Hubble + Capsule come online), creates MigrationPlan; user approves. Underlying mechanism reuses 1.78 path.

**Acceptance:** Tier 1 кластер с задеплоенным hello-world превращается в Tier 2 без downtime > 1 минуты.

**Зависит от:** 3.1, 3.2, 1.78 (MigrationPlan path для platform-scope diff)

**Размер:** L

---

### 3.11 OpenBao как platform-service (Tier 2+)
> 🏁 SR: C — OpenBao HA; depends on SPIRE (2.7/2.8)

**Поставка:**
- [ ] OpenBao 3-node HA через Helm.
- [ ] Auto-unsealing: AWS KMS / GCP KMS / Shamir (выбор по конфигу).
- [ ] Workload identity через SPIRE → OpenBao auth method.
- [ ] Secret engines: kv-v2, database (PG), pki.

**Acceptance:** OpenBao unsealed автоматически после рестарта; Application получает dynamic PG-credentials через OpenBao.

**Зависит от:** 2.7, 3.1

**Размер:** L

---

### 3.12 Migration: SealedSecrets → OpenBao
> 🏁 SR: C — SealedSecrets→OpenBao migration; with 3.11

**Поставка:**
- [ ] `platform-cli upgrade-tier` шаг: импорт SealedSecrets в OpenBao kv-v2.
- [ ] Application manifests переписываются (CUE rewrite tool): `secret(...)` → тот же путь, но из OpenBao.
- [ ] Verification: тот же контент, тот же hash.
- [ ] SealedSecrets controller остаётся работающим (для legacy), warning в UI.

**Acceptance:** после миграции Application продолжает работать без изменения кода или env vars.

**Зависит от:** 3.11, 2.11

**Размер:** M

---

### 3.13 Закрытие чек-листа M3 spec

- [ ] Обновить `spec.md` §6 M3.
- [ ] Tag `v0.3.0-multinode`.

**Размер:** XS

---

## Фаза 3.9 — Dev Mode Full (Phase 3B из dev-mode-task.md)
> 🏁 SR: D — dev mode dropped from launch

**Цель фазы:** production-ready local dev experience. Heuristic runtime detection (Bun / Node / Rust / Go / Python), preset library (Bun HTTP service, Rust async worker, и т.д.), полный `dev reset / restore` lifecycle с backups, observability tab в Backstage equivalent для dev. Снимается `experimental` tag — dev mode становится официальной частью MVP completion.

**Source of truth:** `dev-mode-task.md` §20 Phase 3B.

**Spec:** `spec.md` §3.10, §3.11.

**Зависит от:** Phase 2.9 closed + Phase 3 closed (observability stack, Backstage flow visualizer).

**Поставка:** items из `dev-mode-task.md` §20 Phase 3B перетаскиваются сюда AI-агентом по мере реализации. По завершении — снимается `experimental` маркер в user-facing docs и CLI help.

**Версии:** `v0.3.x` patch series. По dev-mode-task.md §20 эта фаза лендится в planned pause между M3 и Phase 4 (managed offering research), не блокирует старт Phase 4.

**Размер (aggregate):** M (~1 неделя FT). Корректируется по факту.

---

## Фаза 4 — External Surface + Access (M4) ⚡

**Цель фазы:** ExternalSurface декларативен; AccessGrant — единственный путь к доступу для людей; build pipeline с auto-аудитом.

**Spec:** §6 M4, §3.4, §3.5, §4.7, §4.8, §4.9.

### 4.1 ExternalSurface CRD
> 🏁 SR: B · order 5 — ExternalSurface CRD
> 🔗 order-3.5 precursor: platform Gateway + LB-IPAM/L2 landed early в 1.83a с label `apprafter.io/platform-gateway: "true"`. Этот item = full ExternalSurface CRD + adoption существующего Gateway по ownerRef (НЕ пересоздавать).

**Поставка:**
- [ ] CUE-схема (§3.5).
- [ ] Reconciler: разворачивает компоненты в порядке зависимостей.
- [ ] Status per компонент (git/registry/access/notifications/synthetic/backups).

**Размер:** M

---

### 4.1a HTTPRoute auto-generation
> 🏁 SR: B · order 5 — HTTPRoute auto-gen (deployed = reachable; cheapest UX win)
> 🔗 order-3.5 precursor: HTTPRoute emission из `expose.public + hostname` landed в 1.83c (imported-cert path, БЕЗ Certificate-эмиссии). Этот item добавляет: per-app Certificate + issuerRef, rewrites/websocket/sticky/protocols, hostname-conflict admission webhook, Backstage TLS view, migration scan existing deployments.

**Source:** tracker 2.6.

**Цель:** operator автоматически генерирует HTTPRoute + Certificate для каждого Application с `expose.public: true`.

**Поставка:**
- [ ] CUE-схема Application расширена (per spec.md §3.1 update): `hostname`, `paths`, `tls`, `rewrites`, `websocket`, `sticky`, `protocols`.
- [ ] Operator renderer (`operator-rendering`):
    - HTTPRoute generation с `parentRefs` на platform Gateway (owned by ExternalSurface от 4.1), `hostnames`, `rules` с URLRewrite filters.
    - Certificate generation через cert-manager `Certificate` resource если `tls: true`; `issuerRef` на platform ClusterIssuer.
    - BackendLBPolicy generation для `sticky: true` (Gateway API beta feature).
    - Annotations / EnvoyFilter для WebSocket upgrade handling и extended idle timeout если `websocket: true`.
- [ ] Admission webhook: hostname conflict detection across namespaces (через kubectl-style list HTTPRoutes); reject Application apply с conflict error.
- [ ] Backstage Application view: показать current hostname, TLS status, traffic statistics из Hubble (Hubble plugin already лежит в 3.7b).
- [ ] Cascading delete: Application deletion → HTTPRoute + Certificate cleanup via ownerReferences.
- [ ] Migration: existing Tier 1 deployments (deployed без HTTPRoute) — operator detects missing HTTPRoute on reconcile, creates с auto-generated hostname (no manual intervention required).
- [ ] Update spec.md Known Limitations to remove «HTTPRoute auto-generation deferred to Phase 4» bullet.

**Acceptance:**
- Apply Application с `public: true` → HTTPRoute created within 30s, Certificate issued (cert-manager), Application accessible via HTTPS.
- Hostname conflict (two Applications с same hostname): admission webhook rejects with clear error.
- WebSocket Application: long-lived connection holds через sticky binding.
- Cascading delete: Application removal → HTTPRoute + Certificate gone.

**Зависит от:** 4.1 (ExternalSurface CRD with Gateway domain config)

**Размер:** M

---

### 4.1b TLS schema + custom cert import + manual DNS-01 + domain management
> 🏁 SR: C — advanced TLS/cert/DNS-01 beyond launch minimum (4.1a + 4.4a cover launch)
> 🔗 order-3.5 subset: `imported` cert mode + `target cert import` + `target domain add/list/remove` + `allowedDomains` array (`#DomainEntry`) landed в 1.83e/1.83f, storage в `PlatformStack.spec.values.gateway.allowedDomains`. Этот item добавляет: LE issuers (http01 + dns01-manual), полный `#TlsOptions`, `defaultDomain`, MigrationPlan для destructive ops — и МИГРИРУЕТ storage из PlatformStack.spec.values в ExternalSurface.spec (literal move, shape `#DomainEntry` идентичен). `imported` остаётся валидным режимом, не выпиливается.

**Source:** Продолжение 4.1a; ADR 0027 (MigrationPlan) для destructive domain ops. Automated DNS provider integration вынесен в 4.1c.

**Цель:** production-grade hostname/TLS support без обязательной DNS API integration. Юзер может использовать LE (HTTP-01 для specific hostnames, manual DNS-01 для wildcards) или принести собственный cert от любого CA (DigiCert/Comodo/Sectigo/etc.). Cluster получает domain management CLI и MigrationPlan-защиту от destructive operations.

#### Поставка — ExternalSurface schema расширение

- [ ] `ExternalSurface.spec` получает новые optional поля:
    ```cue
    spec: {
        // Existing fields из 4.1...

        // Default suffix для apps с expose.public=true без hostname.
        // Если задан, operator auto-generates `<app-name>.<defaultDomain>`.
        defaultDomain?: string

        // Whitelist доменов которые этот кластер обслуживает.
        // Apps с hostname вне этого списка отклоняются admission webhook.
        // Wildcard entries (`*.example.com`) матчат suffix.
        // Если массив пуст — нет whitelist (любой hostname accept'ится).
        allowedDomains?: [...#DomainEntry]
    }

    #DomainEntry: {
        domain:    string      // "example.com" или "*.example.com"
        wildcard:  bool | *false  // computed: true если starts with "*."
        certMode:  "letsencrypt-http01" | "letsencrypt-dns01-manual" | "imported" | *"letsencrypt-http01"
        importedCertRef?: string  // когда certMode == "imported", имя из target cert list
        addedAt:   string      // ISO timestamp
        addedBy:   string      // email/identity who added
    }
    ```

- [ ] PlatformController reconciles `ExternalSurface` → creates cert-manager `ClusterIssuer` ресурсы:
    - `apprafter-letsencrypt-http01` — для не-wildcard hostnames через HTTP-01 (всегда создан).
    - `apprafter-letsencrypt-dns01-manual` — для wildcards через manual DNS-01 (cert-manager в "manual" режиме, требует юзерского участия для каждого challenge).

#### Поставка — `tls: bool | TlsOptions` schema

- [ ] CUE schema (`apprafter/Application.cue`):
    ```cue
    #Expose: {
        public:   bool | *false
        hostname: string | *""
        tls:      bool | #TlsOptions | *true
        // ...
    }

    #TlsOptions: {
        enabled:    bool | *true
        redirect:   bool | *true        // HTTP→HTTPS 301 redirect
        hsts:       bool | *true        // Strict-Transport-Security header
        hstsMaxAge: int  | *31536000   // 1 year
        minVersion: "TLSv1.2" | "TLSv1.3" | *"TLSv1.2"
        // Future: cipherSuites, alpn, clientCert
    }
    ```
- [ ] Operator renderer:
    - `tls: true` → expand to `#TlsOptions{}` defaults; generates Certificate + HTTPRoute с HTTPS redirect filter + HSTS response header filter.
    - `tls: false` → no Certificate, HTTP-only HTTPRoute (port 80), no redirect, no HSTS. Никаких warnings (юзер явно выключил).
    - `tls: {...}` object → use provided values, fill missing с defaults.
- [ ] HTTPS redirect: HTTPRoute с `filters: [{type: RequestRedirect, requestRedirect: {scheme: "https", statusCode: 301}}]` для port 80 listener.
- [ ] HSTS: HTTPRoute с `filters: [{type: ResponseHeaderModifier, responseHeaderModifier: {set: [{name: "Strict-Transport-Security", value: "max-age=<hstsMaxAge>; includeSubDomains"}]}}]`.

#### Поставка — Custom cert import (`apprafter target cert ...`)

- [ ] `apprafter target cert import <name>`:
    - Флаги: `--cert <file>` (PEM-encoded certificate, fullchain), `--key <file>` (PEM-encoded private key), `--chain <file>` (optional separate intermediate chain если не включён в fullchain).
    - Pre-validation:
        - Parse PEM, проверить что cert и key соответствуют (key matches cert public key).
        - Extract subject + SANs + expiry; output для confirmation.
        - Warn если expiry < 30 days ("Certificate expires в N days. Continue? [y/N]").
    - Создаёт k8s Secret type `kubernetes.io/tls` в namespace `cert-manager` с labels:
        - `apprafter.io/managed-by: apprafter`
        - `apprafter.io/cert-name: <name>`
        - `apprafter.io/cert-mode: imported`
        - Annotations: `apprafter.io/cert-not-before`, `apprafter.io/cert-not-after`, `apprafter.io/cert-sans` (для бystrого querying без re-parsing).
    - Output:
        ```
        ✓ Certificate 'my-wildcard' imported

          Subject:     CN=*.example.com
          SANs:        *.example.com, example.com
          Issuer:      DigiCert TLS RSA SHA256 2020 CA1
          Valid from:  2025-11-12
          Expires:     2026-11-12 (in 357 days)

        Use in Application.cue:
          expose.tls.useCert: "my-wildcard"

        Or register associated domain:
          apprafter target domain add "*.example.com" --cert my-wildcard
        ```

- [ ] `apprafter target cert list`:
    - Таблица: name, subject, SANs (truncated если > 80 chars), expires (с цветовой подсветкой: red если < 30d, yellow < 60d, green иначе), used by (count apps + domains references).

- [ ] `apprafter target cert show <name>`:
    - Full detail: полные SANs, issuer chain, fingerprint, всех Applications/domains references.

- [ ] `apprafter target cert renew <name>`:
    - Для `imported` certs: instructional output "Re-purchase from CA, then run `apprafter target cert import <name> --cert <new-fullchain> --key <new-key> --replace`".
    - Для `letsencrypt-dns01-manual`: триггерит manual DNS-01 challenge cycle (см. ниже).

- [ ] `apprafter target cert remove <name>`:
    - Pre-check: scan domains и Applications references.
    - Если есть active references — error "Certificate used by domain '<domain>' and N applications. Remove references first или используй `--force` (apps will lose TLS)".
    - `--force` создаёт **platform-scope MigrationPlan** (см. ниже про MigrationPlan integration).

- [ ] `apprafter target cert import <name> --replace` для rotation:
    - Pre-validation идентична `import`.
    - Updates existing Secret in-place (sequence: validate → write new keys → no downtime).
    - HTTPRoutes референсящие этот cert автоматически подхватывают новый (cert-manager и Gateway API делают reload).

#### Поставка — Manual DNS-01 instructional flow

- [ ] Triggered через `apprafter target domain add "*.example.com"` (без `--cert` flag):
    - Wizard prompt:
        ```
        Wildcard certificates require DNS-01 challenge (LE limitation, not ours).
        
        How would you like to proceed?
          > Manual TXT record (one-time setup, manual renewal every ~60 days)
            Use existing certificate from a CA (Comodo, DigiCert, etc.)
            Configure automated DNS provider (requires API token)
            Cancel
        ```
    - "Use existing certificate" → редиректит к `apprafter target cert import` wizard.
    - "Automated DNS provider" → message "Available в Phase 4.1c (coming soon). Use manual TXT для now".
    - "Manual TXT record" → continue с challenge initiation.

- [ ] Manual TXT record sub-flow:
    1. CLI создаёт cert-manager `Certificate` resource с `issuerRef: apprafter-letsencrypt-dns01-manual`.
    2. cert-manager начинает challenge, generates required TXT record.
    3. CLI polls challenge status until TXT requirement доступен.
    4. CLI outputs:
        ```
        DNS configuration required:
          
          Type:    TXT
          Name:    _acme-challenge.example.com
          Value:   abc123XYZ_long_token_string...
          TTL:     300 (short, will be deleted after challenge)
        
        Steps:
          1. Add the TXT record above at your DNS registrar
          2. Wait 1-5 minutes for DNS propagation
          3. Run: apprafter target cert verify-challenge "*.example.com"
        
        Or, if you want CLI to wait и auto-verify:
          apprafter target cert wait-challenge "*.example.com" --timeout 10m
        ```
    5. `apprafter target cert verify-challenge` или `wait-challenge`:
        - Periodic `dig +short _acme-challenge.example.com TXT` поlling.
        - Когда matches expected value → notify cert-manager, ждёт issuance.
        - Successful → output cert details + reminder про renewal.
    6. Issuance complete → cert хранится в Secret аналогично imported cert, но с label `apprafter.io/cert-mode: letsencrypt-dns01-manual`.

- [ ] Renewal reminder:
    - cert-manager сам пытается renew в day 60 (стандартное LE поведение).
    - cert-manager в manual режиме surface'ит новое TXT-требование через event на Certificate resource.
    - AppRafter operator scan'ит Certificates с `cert-mode: letsencrypt-dns01-manual` и status `Renewing`, surface'ит в:
        - `Application.status.conditions[CertificateRenewalRequired]=True` с TXT details
        - `apprafter app status` показывает actionable instructions
        - (Phase 3, когда notifications service) — push notification по email/slack/telegram
    - CLI helper: `apprafter target cert continue-renewal "<domain>"` → выводит current TXT requirement, ждёт пока юзер не поставит, верифицирует.

#### Поставка — `public: true` + hostname validation rules

- [ ] Admission webhook расширение:
    - `expose.public: true` + `hostname` задан → используем заданный.
    - `expose.public: true` + `hostname` пустой + `ExternalSurface.spec.defaultDomain` задан → operator auto-generates `<app-name>.<defaultDomain>`, reflected в `Application.status.effectiveHostname` для visibility.
    - `expose.public: true` + `hostname` пустой + `defaultDomain` пустой → **reject** с error "expose.public: true requires either expose.hostname или platform-wide defaultDomain. Set hostname в Application.cue, или run `apprafter target domain set-default <domain>`".
- [ ] `allowedDomains` enforcement:
    - При не-пустом `allowedDomains` — hostname app'а должен match'ить минимум одну entry (exact или wildcard suffix).
    - Mismatch → reject с error "Hostname '<host>' not в cluster's allowed domains list. Add via `apprafter target domain add <domain>`".
    - При пустом `allowedDomains` — без enforcement (любой hostname accept'ится, для dev/experimental clusters).

#### Поставка — Path conflict detection (расширение 4.1a)

- [ ] Admission webhook для HTTPRoute:
    - Existing check: hostname conflict — из 4.1a.
    - New check: exact `(hostname, pathPrefix, pathType)` tuple duplication across Applications:
        - **Exact match** → reject с error "Path '<path>' on hostname '<hostname>' already claimed by Application '<other-app>'".
        - **Subset/superset paths** (catch-all `/` + specific `/api`) → **accept с warning** в admission response: "Application '<name>' acts as catch-all for `<hostname>`; requests not matching more specific paths will route here. This is correct per Gateway API spec but can be surprising. Consider explicit path prefixes if intended."
        - Warning visible в kubectl output ("Warning: ..."), не блокирует apply.

#### Поставка — `apprafter target domain` CLI группа

- [ ] `apprafter target domain add <domain> [--cert <imported-cert-name>]`:
    - Validation: формат (RFC 1123 hostname, wildcard `*.<domain>`).
    - `--cert <name>` — использовать existing imported cert. `certMode: imported`, `importedCertRef: <name>`.
    - Без `--cert`:
        - Для specific hostname — `certMode: letsencrypt-http01` (default).
        - Для wildcard — triggers manual DNS-01 wizard (см. выше).
    - Append в `ExternalSurface.spec.allowedDomains`.
    - Output: floating IP + DNS A/AAAA-record instructions + warning если домен уже резолвится не в кластер.

- [ ] `apprafter target domain list`:
    - Таблица: domain, type (specific/wildcard), cert mode (LE/imported/manual), cert status, DNS verification, apps count, added.

- [ ] `apprafter target domain verify <domain>`:
    - `dig <domain> +short` → сравнение с cluster floating IP (A для IPv4, AAAA для IPv6 если dual-stack).
    - LE rate limit pre-check: `--check-rate-limit` пингует LE rate-limit endpoint (полезно перед issuance multiple certs).

- [ ] `apprafter target domain status <domain>`:
    - Detail view: cert (mode, expiry, last renewal attempt + result), apps using, DNS resolution, recent challenges (last 5).

- [ ] `apprafter target domain set-default <domain>`:
    - Patches `ExternalSurface.spec.defaultDomain`.
    - Если domain не в `allowedDomains` — **explicit reject** ("Domain '<d>' not registered. Run `apprafter target domain add <d>` first") — без implicit auto-add, чтобы не было surprise mutations.
    - Если меняет existing default → **platform-scope MigrationPlan** (existing apps без explicit hostname могут получить новый effective hostname).

- [ ] `apprafter target domain remove <domain>`:
    - Pre-check: scan Applications использующих этот domain или его wildcard scope.
    - Active apps есть → **platform-scope MigrationPlan** создаётся, removal не происходит до approve.
    - Active apps нет → immediate remove, confirmation prompt + `--yes` для skip.

#### Поставка — MigrationPlan integration для destructive domain/cert ops

- [ ] При `target domain remove <domain>` с active apps создаётся MigrationPlan:
    - `scope.type: platform`
    - `scope.platform.target: ExternalSurface/default`
    - `trigger.kind: domain-removal`
    - `trigger.removing: "<domain>"`
    - `risks.classification: breaking`
    - `risks.affectedApps: ["<app1>", "<app2>", ...]`
    - `risks.estimatedDowntime: "immediate"`
    - `risks.reversible: true`
    - `plan` steps: remove from allowedDomains → cleanup HTTPRoutes referencing → cleanup orphaned Certificates → (M3) notify affected app owners.
- [ ] Аналогично для `target cert remove --force` с active references — platform-scope MigrationPlan с affected apps.
- [ ] `target domain set-default <new>` с existing default → platform-scope MigrationPlan с listing apps чей effective hostname изменится.
- [ ] Approve via `apprafter migration approve <name>` → PlatformMigrationStrategy выполняет; reject — no-op.

#### Поставка — `apprafter app status` cert visibility

- [ ] Расширить `app status` output для apps с TLS:
    ```
    Application: my-parser
      Sync:     Synced (12 seconds ago)
      Health:   Healthy

      Endpoints:
        Internal:  http://my-parser.default.svc.cluster.local:3000
        External:  https://parser.example.com
          Certificate: my-wildcard (imported)
            Issuer:      DigiCert TLS RSA SHA256 2020 CA1
            Valid until: 2026-11-12 (in 357 days)
          TLS:         enabled (redirect ON, HSTS ON, minVersion TLSv1.2)

      Pods:     1/1 Ready
    ```
- [ ] Cert status conditions:
    - `Valid until: 2026-XX-XX (in N days)` — normal state.
    - Pending issuance → `Certificate: pending issuance (HTTP-01 challenge, attempt 2/3)`.
    - Failed → `Certificate: FAILED (last attempt 5m ago: <error>). Will retry. See: kubectl describe certificate <name>`.
    - Close to expiry для LE → `Certificate: expires in 11 days (auto-renewal scheduled in 2 days)` — informational.
    - Close to expiry для imported → `Certificate: expires in 11 days. Re-purchase from CA and run \`apprafter target cert import <name> --replace\``.
    - Manual DNS-01 renewal required → `Certificate: renewal requires DNS TXT update. Run \`apprafter target cert continue-renewal "<domain>"\``.
- [ ] AppRafter operator periodically scan'ит Certificates и Secrets с label `apprafter.io/managed-by: apprafter`:
    - Bump `Application.status.conditions[CertificateExpiringSoon]=True` при < 30 days.
    - Bump `Application.status.conditions[CertificateRenewalRequired]=True` для manual DNS-01 в Renewing state.

#### Acceptance

- [ ] `apprafter target cert import` с валидным fullchain + key → Secret создан, cert details выведены, expiry правильно распарсен.
- [ ] `apprafter target cert import` с mismatched cert/key → fail с error до записи Secret.
- [ ] `apprafter target domain add app.example.com` (specific) → registered, DNS A-record instructions, certMode `letsencrypt-http01`.
- [ ] `apprafter target domain add "*.example.com"` без `--cert` → wizard offers manual DNS-01 / cert import / cancel.
- [ ] Manual DNS-01 flow: TXT instructions → юзер ставит record → `verify-challenge` → cert issued.
- [ ] `apprafter target domain add "*.example.com" --cert my-wildcard` (imported) → registered, certMode `imported`, никакого challenge не происходит.
- [ ] Application с `tls: false` + `public: true` — deployed без warnings, HTTP-only, accessible на port 80.
- [ ] Application с `tls: {redirect: false}` — TLS включён, но HTTP не редиректит.
- [ ] Two apps с same hostname + same path → second reject'ится.
- [ ] Two apps с same hostname, один `/`, другой `/api` → both accepted, warning в kubectl output.
- [ ] `expose.public: true` + no hostname + defaultDomain → effective hostname auto-generated, HTTPRoute generated.
- [ ] `expose.public: true` + no hostname + no defaultDomain → admission reject.
- [ ] `apprafter target domain set-default <new>` с existing default → MigrationPlan создан.
- [ ] `apprafter target cert remove <name>` с active references → MigrationPlan создан; без references → immediate remove с confirmation.
- [ ] `apprafter app status` для healthy app с imported cert показывает cert mode (imported), expiry, re-import instructions при < 30d.

#### Не входит в этот item

- Automated DNS provider integration для wildcard auto-issuance — **4.1c**.
- mTLS / client certificate auth (Phase 5+ для regulated workloads).
- Custom internal CA (Phase 6 для confidential containers tier).
- Notifications service integration для cert expiry alerts — depends on M3 notifications service.
- ALPN / HTTP/3 / QUIC support.

**Зависит от:** 4.1a (basic HTTPRoute + Certificate generation, hostname conflict detection); 1.79a (CLI infrastructure для `apprafter target ...` group).

**Размер:** L

---

### 4.1c Automated DNS provider integration + lazy add-on system
> 🏁 SR: C — automated DNS provider + lazy add-ons; beyond launch minimum

**Source:** Продолжение 4.1b. Закрывает renewal pain manual DNS-01 через автоматизацию DNS-01 challenge. Вводит lazy add-on activation: ExternalSurface — single source of truth, PlatformController реагирует.

**Цель:** zero-touch wildcard certificate issuance и renewal для built-in providers (Cloudflare, Route53, Google Cloud DNS, DigitalOcean) сразу через core platform-stack, и для community-maintained providers (GoDaddy, Hetzner DNS) через on-demand add-ons без раздувания default deployment.

#### Поставка — Add-on registry architecture

- [ ] **Built-in providers** (cert-manager native solvers, no extra deployment):
    - Cloudflare
    - Route53 (AWS)
    - Google Cloud DNS
    - DigitalOcean
- [ ] **Add-on providers** (community webhook plugins, lazy-deployed on-demand):
    - GoDaddy через `cert-manager-webhook-godaddy`
    - Hetzner DNS через `cert-manager-webhook-hetzner`
- [ ] **Out of scope (V1):**
    - Namecheap — IP allowlist + balance requirements + community webhook maturity не оправдывают MVP complexity. Может быть добавлен позже как community-contributed registry entry без архитектурных изменений.
    - Azure DNS, Akamai, Gandi и прочие — добавляются on-demand small items (XS каждый).
- [ ] Add-on registry: статичная таблица `addons/dns-providers/<name>/manifest.yaml` в platform-stack repo, каждая запись:
    - `name`: identifier (e.g., `godaddy`)
    - `displayName`: human-readable
    - `webhookChart`: OCI ref Helm chart
    - `chartVersion`: pinned version
    - `credentialsSchema`: keys которые Secret должен содержать
    - `validationEndpoint`: provider API endpoint для пинга при configure
    - `documentation`: link к provider's API token instructions

#### Поставка — Lazy activation через ExternalSurface (Path B)

- [ ] **Source of truth:** `ExternalSurface.spec.dnsProvider`. PlatformController watches это поле и реагирует.
- [ ] **State machine** в `ExternalSurface.status`:
    ```
    Pending → ResolvingAddon → InstallingAddon → ValidatingCredentials → Ready
                                                           ↓
                                                         Failed (with reason)
    ```
- [ ] **Reconcile logic** PlatformController при изменении `dnsProvider.type`:
    1. Если type — built-in (cloudflare/route53/google-cloud-dns/digitalocean):
        - Skip add-on installation, go straight to ValidatingCredentials.
        - Создаёт ClusterIssuer `apprafter-letsencrypt-dns01-auto` с native solver config.
    2. Если type — add-on (godaddy/hetzner-dns):
        - Lookup registry entry для type.
        - Создаёт Argo CD `Application` в project `platform-providers` для webhook chart.
        - Waits для webhook Application `Healthy` (с timeout 5 min).
        - После Healthy → создаёт ClusterIssuer с webhook solver config.
        - Если timeout — status.phase=Failed, conditions[AddonInstallFailed]=True с actionable hint.
    3. **ClusterIssuer создаётся только в фазе Ready** — это критично, чтобы cert-manager не пытался issue cert через несуществующий webhook.
- [ ] **Reconcile logic при removal** (юзер делает `dns-provider remove`):
    1. Удаляет ClusterIssuer.
    2. Если был add-on type — удаляет webhook Argo CD Application из `platform-providers`.
    3. Очищает Secret с credentials.
    4. status.phase → Pending (либо undefined если не configured).
- [ ] **Future extension point** (multi-tenant Phase 7+, не сейчас): `PlatformStack.spec.overrides.dnsProviders.<name>.policy: "auto" | "allow" | "deny"`. Default `auto` — текущее lazy поведение. `allow`/`deny` для explicit platform-admin override в multi-tenant scenarios. Backward-compatible добавление, не требует переписывания текущей логики.

#### Поставка — ExternalSurface schema расширение

- [ ] `ExternalSurface.spec.dnsProvider` field:
    ```cue
    spec: {
        // ...existing fields из 4.1, 4.1b...

        dnsProvider?: #DnsProviderConfig
    }

    #DnsProviderConfig: {
        // Type matches registry entry name.
        type: "cloudflare" | "godaddy" | "hetzner-dns" | "digitalocean" | "route53" | "google-cloud-dns"

        // Provider-specific credentials через Secret reference (не inline).
        credentialsSecretRef: {
            name:      string
            namespace: string | *"cert-manager"
            // Keys внутри Secret конкретны для provider:
            //   cloudflare:       "api-token"
            //   godaddy:          "api-key" + "api-secret"
            //   hetzner-dns:      "api-token"
            //   digitalocean:     "access-token"
            //   route53:          "access-key-id" + "secret-access-key" + "region"
            //   google-cloud-dns: "service-account-json"
        }

        // Optional zone hint когда есть несколько зон под одним provider.
        zoneSelector?: string
    }
    ```
- [ ] Также добавляется `certMode: "letsencrypt-dns01-auto"` в `#DomainEntry` (из 4.1b).

#### Поставка — Built-in provider configurations

- [ ] **Cloudflare** (priority 1):
    - Required: API Token с permission `Zone:DNS:Edit` для target zone (или `User:All Zones`).
    - cert-manager built-in solver `cloudflare`.
    - Wizard validation: `GET https://api.cloudflare.com/client/v4/user/tokens/verify`.

- [ ] **Route53** (AWS):
    - Required: AWS access key + secret + region.
    - cert-manager built-in solver `route53`.
    - Wizard validation: STS `GetCallerIdentity`.

- [ ] **Google Cloud DNS**:
    - Required: GCP service account JSON с роли `roles/dns.admin`.
    - cert-manager built-in solver `clouddns`.
    - Wizard validation: parse JSON + API call.

- [ ] **DigitalOcean**:
    - Required: DO API token.
    - cert-manager built-in solver `digitalocean`.
    - Wizard validation: API call.

#### Поставка — Add-on provider configurations

- [ ] **GoDaddy** add-on:
    - Webhook chart: `cert-manager-webhook-godaddy` (community).
    - Required: API key + API secret pair from developer.godaddy.com.
    - Token format: separate `<key>` and `<secret>` (NOT colon-separated string).
    - Pre-requirements (CLI выводит до prompt'а token):
        ```
        GoDaddy API access requires:
          • Active GoDaddy account with at least one registered domain
          • Production API keys (OTE test keys do NOT work for real DNS-01)
          • Get keys from: https://developer.godaddy.com/keys
        ```
    - Wizard validation: `GET https://api.godaddy.com/v1/domains` с `Authorization: sso-key <key>:<secret>`.

- [ ] **Hetzner DNS** add-on:
    - Webhook chart: `cert-manager-webhook-hetzner` (community).
    - Required: Hetzner DNS API token (отдельный от Hetzner Cloud token — выдаётся в Hetzner DNS Console, не в Hetzner Cloud Console).
    - Pre-requirements:
        ```
        Hetzner DNS API access requires:
          • Hetzner DNS Console account (separate from Hetzner Cloud account if applicable)
          • DNS API token from: https://dns.hetzner.com/settings/api-token
          
        Note: This is NOT the same as your Hetzner Cloud token (which AppRafter uses
        for infrastructure provisioning). DNS API tokens are managed separately.
        ```
    - Wizard validation: `GET https://dns.hetzner.com/api/v1/zones` с token.

#### Поставка — `apprafter target dns-provider` CLI группа

- [ ] `apprafter target dns-provider configure`:
    - Interactive wizard:
        ```
        ? Which DNS provider hosts your domain(s)?
            Built-in (no extra deployment):
            > Cloudflare
              DigitalOcean
              Route53 (AWS)
              Google Cloud DNS
            Add-ons (lazy-deployed):
              GoDaddy
              Hetzner DNS

        ? GoDaddy API Key: › ****
        ? GoDaddy API Secret: › ****
          ✓ Format valid
          ✓ Credentials verified (12 domains accessible)

        Installing GoDaddy webhook add-on...
          ✓ cert-manager-webhook-godaddy installed (Argo CD synced in 23s)
          ✓ ClusterIssuer apprafter-letsencrypt-dns01-auto ready

        ✓ GoDaddy DNS provider configured
        ℹ Wildcard certificates can now be auto-issued.
        ℹ Existing manual-DNS-01 domains will auto-migrate on next renewal.
        ```
    - Non-interactive: provider-specific флаги, e.g.:
        - `--type cloudflare --token "$CF_TOKEN"`
        - `--type godaddy --api-key "$GD_KEY" --api-secret "$GD_SECRET"`
        - `--type hetzner-dns --token "$HD_TOKEN"`
    - Под капотом:
        - Validates credentials через provider API.
        - Создаёт Secret в namespace `cert-manager`.
        - Patches `ExternalSurface.spec.dnsProvider`.
        - PlatformController берёт на себя add-on installation (если нужно) + ClusterIssuer creation.
        - CLI ждёт `ExternalSurface.status.phase=Ready` (или Failed) с progress indication.

- [ ] `apprafter target dns-provider status`:
    - Output:
        ```
        DNS Provider:  GoDaddy (add-on)
        Status:        Ready (validated 5m ago)
        Webhook:       cert-manager-webhook-godaddy v1.2.3 (Healthy)
        Zone access:   3 zones (example.com, example.org, example.dev)
        Last DNS-01:   2 hours ago (success, *.example.com renewal)

        Auto-renewal:  enabled для 4 domains
          *.example.com    (renews in 28d, auto)
          *.example.dev    (renews in 45d, auto)
          api.example.org  (specific, HTTP-01, renews in 12d, auto)
        ```
    - Для built-in providers webhook line опускается.

- [ ] `apprafter target dns-provider rotate`:
    - Wizard prompt только для новых credentials, остальные fields preserved.
    - Pre-validation, потом patches Secret in-place.

- [ ] `apprafter target dns-provider remove`:
    - Pre-check: scan domains с `certMode: letsencrypt-dns01-auto`.
    - Active wildcards с auto mode → **platform-scope MigrationPlan** (см. ниже).
    - No auto-mode wildcards → immediate remove с confirmation.
    - При add-on type — webhook Application автоматом удаляется PlatformController'ом.

- [ ] `apprafter target dns-provider list-available`:
    - Output: registry таблица всех supported providers, помечает "built-in" / "add-on" + ссылки на documentation.

#### Поставка — Migration existing manual-DNS-01 → auto

- [ ] При первом `dns-provider configure` после того как существуют wildcards с `certMode: letsencrypt-dns01-manual`:
    - Prompt:
        ```
        Found 2 existing wildcard domains using manual DNS-01:
          *.example.com   (next renewal in 28 days)
          *.example.dev   (next renewal in 45 days)

        Migrate to automated renewal? [Y/n]
        ```
    - "Y" → patches `DomainEntry.certMode: letsencrypt-dns01-manual` → `letsencrypt-dns01-auto`.
    - При следующем renewal cycle cert-manager использует auto issuer.
    - "n" → existing certs остаются manual до explicit `target cert migrate-to-auto <domain>`.

- [ ] `apprafter target cert migrate-to-auto <domain>` для explicit migration:
    - Patches certMode на auto.
    - Опционально с `--force-renew-now` — triggers immediate re-issuance.

#### Поставка — MigrationPlan integration

- [ ] При `dns-provider remove` с active auto-mode wildcards создаётся MigrationPlan:
    - `scope.type: platform`
    - `scope.platform.target: ExternalSurface/default`
    - `trigger.kind: dns-provider-removal`
    - `risks.classification: requires-restart`
    - `risks.affectedDomains: [...]`
    - `risks.estimatedImpact: "Wildcards will fail next renewal (~60 days). Apps lose TLS at that point."`
    - `risks.reversible: true`
    - `plan` steps: remove dns-provider config → uninstall add-on webhook (если был) → mark affected domains → (M3) notify owners.
- [ ] Approve/reject через standard `migration approve`/`migration reject`.

#### Поставка — Cert renewal monitoring (расширение 4.1b)

- [ ] AppRafter operator periodic scan Certificates с `cert-mode: letsencrypt-dns01-auto`:
    - Successful renewal in last 60 days → silently track `lastRenewalAt`.
    - Failed renewal с last attempt > 7 days ago → bump `Application.status.conditions[CertificateAutoRenewalStuck]=True` с last error.
    - Continuous failures (3+ attempts) → suggest action: "DNS provider credentials may be invalid. Run `apprafter target dns-provider check`."

- [ ] `apprafter target dns-provider check`:
    - Re-validate credentials через provider API.
    - Output статус каждого manageable zone.
    - `--full-check` opt-in флаг (5-10s overhead): создаёт + verifies + удаляет test TXT record для end-to-end проверки.

#### Acceptance

- [ ] `apprafter target dns-provider configure --type cloudflare` (built-in) → ExternalSurface переходит Pending → ValidatingCredentials → Ready за < 5s, no webhook deployment.
- [ ] `apprafter target dns-provider configure --type godaddy` → ExternalSurface проходит Pending → ResolvingAddon → InstallingAddon → ValidatingCredentials → Ready, webhook deployed в `platform-providers` project.
- [ ] Если webhook chart install failed (e.g., OCI registry недоступен) → ExternalSurface.status.phase=Failed, conditions[AddonInstallFailed]=True с actionable hint, ClusterIssuer не создаётся.
- [ ] Wildcard cert auto-issued через DNS-01 в течение 60s после `target domain add` (built-in или add-on provider).
- [ ] Existing manual-mode wildcard после `configure` + prompt "Y" → migrated к auto mode, next renewal automatic.
- [ ] `dns-provider remove` для add-on provider → webhook Application автоматом удаляется из `platform-providers` project.
- [ ] `dns-provider remove` с active auto-wildcards → MigrationPlan создан.
- [ ] `dns-provider check --full-check` создаёт + verifies + удаляет test TXT record, output success/failure detail.
- [ ] Invalid token (revoked у provider) после rotation → next renewal fails, `CertificateAutoRenewalStuck` condition bumped.
- [ ] Switch между providers (cloudflare → godaddy): cleanup старого + setup нового через standard `remove` + `configure` flow. CLI и controller handle gracefully.

#### Не входит в этот item

- Namecheap support — deferred из-за IP allowlist complexity + balance requirements. Может быть добавлен позже как community-contributed registry entry.
- Multi-tenant explicit add-on control (`PlatformStack.spec.overrides.dnsProviders.<name>.policy`) — future Phase 7+, backward-compatible extension.
- Concurrent multiple DNS providers per cluster (out of scope, single provider per cluster).
- External-DNS integration для automatic A/AAAA record provisioning (Phase 4, orthogonal item).
- HSM-backed certs / regulated workloads patterns.
- Cert pinning / Certificate Transparency monitoring.

**Зависит от:** 4.1b (custom cert import, manual DNS-01, ExternalSurface.spec.allowedDomains/defaultDomain, target domain/cert CLI groups); 1.79a (`platform-providers` Argo CD project для add-on deployment).

**Размер:** M

---

### 4.2 Forgejo (или GitLab self-hosted) deployable из манифеста
> 🏁 SR: D — Forgejo/GitLab self-hosted dropped (GitHub+ghcr.io suffice); reactivate for Group-C self-host compliance

**Поставка:**
- [ ] Helm chart (готовый upstream) обёрнут в ServiceProvider-style ресурс.
- [ ] Persistence на ClickHouse (для logs) и pg/s3 (data) — через ResourceClaim.
- [ ] Backups → external S3.
- [ ] HTTPRoute через Gateway, OIDC SSO.

**Acceptance:** `git push` в Forgejo триггерит CI runner.

**Зависит от:** 4.1, 2.4

**Размер:** L

---

### 4.3 Harbor registry deployable из манифеста
> 🏁 SR: D — Harbor dropped; with 4.2

**Поставка:**
- [ ] Helm chart Harbor.
- [ ] Storage backend → s3-integrated ResourceClaim.
- [ ] Cosign verification policy.
- [ ] Retention rules из ExternalSurface.

**Acceptance:** `docker push` работает; неподписанный image при `signing: required` блокируется.

**Зависит от:** 4.1, 2.x s3

**Размер:** M

---

### 4.4 Headscale + Tailscale Operator
> 🏁 SR: D — Headscale/Tailscale dropped (managed portal auth replaces VPN)

**Поставка:**
- [ ] Headscale-controller pod, persistence pg.
- [ ] Tailscale Operator для автоматической интеграции с k8s сервисами.
- [ ] OIDC SSO для регистрации устройств.

**Acceptance:** `tailscale up --login-server=https://headscale.<domain>` работает; устройство видит cluster routes.

**Зависит от:** 4.1

**Размер:** L

---

### 4.4a external-dns integration + `DNSZone` CRD
> 🏁 SR: B · order 5 — external-dns + DNSZone CRD (closes DNS friction)
> 🔗 order-3.5 manual stand-in: DNS records ставятся руками через runbook в 1.83g. Этот item автоматит через external-dns operator; после landing — 1.83g runbook deprecated.

**Source:** tracker 2.8.

**Цель:** automated DNS records для HTTPRoute / Application hostnames через external-dns operator.

**Поставка:**
- [ ] Install external-dns operator как platform-service (added to platform-stack chart components).
- [ ] CUE-схема `kind: DNSZone` в `schemas/v1alpha1/dnszone.cue`:
  ```cue
  kind: DNSZone
  name: apprafter-dev
  zone: "apprafter.dev"
  provider: cloudflare
  credentialsRef: secret("platform/cloudflare-token")
  pattern: "{app}.{env}.{tenant}.apprafter.dev"    // optional; default — let external-dns use HTTPRoute hostnames
  ```
- [ ] Operator translates DNSZone → external-dns DNSEndpoint resources + provider configuration.
- [ ] Provider integrations (initial set): Cloudflare, Hetzner DNS, AWS Route53.
- [ ] external-dns reads HTTPRoute hostnames in cluster, creates corresponding DNS records.
- [ ] Backstage DNSZone overview: list zones, provider, record count, last sync.

**Acceptance:**
- Apply DNSZone for `apprafter.dev` with Cloudflare credentials → external-dns синхронизируется, DNS records появляются.
- Apply Application с `hostname: "parser.apprafter.dev"` → DNS record создан в Cloudflare automatically.
- Update spec.md Known Limitations to remove DNS-related deferral.

**Зависит от:** 4.1 (ExternalSurface), 4.4 (Headscale — для credentials store integration через AccessGrant)

**Размер:** M

---

### 4.5 AccessGrant CRD + reconciler — tenant scoping + approvers (REWORK)
> 🏁 SR: C — AccessGrant + JIT; trigger: team-of-3+ (solo handled by portal auth)

**Source:** ADR 0023, ADR 0024.

**Поставка:**
- [ ] CUE-схема (§3.4).
- [ ] Add `tenant:` field — scopes grant к specific Kamaji TCP (см. spec.md §3.4 updates).
- [ ] Add `approvers:` field — two-person rule для host cluster-admin grants.
- [ ] Reconciler:
  - создаёт Headscale pre-auth key (одноразовый, 24h).
  - создаёт RoleBinding/ClusterRoleBinding в k8s.
  - создаёт OIDC group mapping.
  - публикует событие → notifications-сервис.
  - Если `tenant:` set → create RoleBinding inside Kamaji TCP, not host cluster.
  - Если `scope.cluster: host` and `scope.capabilities: ["cluster-admin"]` and `approvers` empty → admission webhook rejects (policy: host cluster-admin requires approvers).
  - Если `approvers:` non-empty → AccessGrant status = `pending-approval`; reconciler waits for approval signals through Backstage или API endpoint.
  - On all approvers signed → status → `active`, credentials issued (Headscale + RoleBinding + OIDC).
  - Audit-event на каждый approval action.
- [ ] Status: issued / pending-approval / pending-activation / active / expiring / expired.
- [ ] Backstage AccessGrant view: pending grants requiring my approval (per user); approve/reject UI; current grants and their tenant scope.

**Acceptance:**
- Apply AccessGrant → email с magic-link приходит; click → SSO+MFA → подключение работает.
- AccessGrant с `tenant: blockchain-team` → subject имеет kubectl access только в TCP «blockchain-team», not host или other tenants.
- AccessGrant `scope.cluster: host` + `scope.capabilities: cluster-admin` без `approvers` → rejected by admission.
- AccessGrant с `approvers: ["bob@"]` + Alice как subject → grant pending until Bob approves via Backstage; only then Alice can login.

**Зависит от:** 4.4 (Headscale), 2.13, 3.8a (Tenant CRD для tenant scoping)

**Размер:** L

---

### 4.5a JIT cluster-admin AccessGrant flow
> 🏁 SR: C — JIT cluster-admin; with 4.5

**Source:** ADR 0024.

**Цель:** короткоживущие emergency cluster-admin grants с auto-revocation и loud audit.

**Поставка:**
- [ ] Special AccessGrant variant: `scope.cluster: host`, `scope.capabilities: ["cluster-admin"]`, `expiry: 1h` (max for JIT grants).
- [ ] Policy enforcement: admission webhook requires `purpose:` field non-empty для JIT grants (forces operator to document why).
- [ ] Approval flow: same `approvers` mechanism, but typically expedited (one approver minimum, can be configured).
- [ ] Loud audit: dedicated event stream `audit.cluster-admin.jit`; immediate Backstage notification banner visible to entire team.
- [ ] Auto-revocation на expiry: kubeconfig invalidates, RoleBinding deleted, audit closes.
- [ ] Backstage emergency dashboard: «JIT access active» banner with grant details, time remaining, ability to view audit trail live.

**Acceptance:**
- JIT grant flow end-to-end (Alice requests с purpose, Bob approves quickly, Alice has 1h cluster-admin, banner visible all team) проходит за < 5 минут.
- After expiry: Alice's kubectl fails with proper auth error; audit shows full trail.

**Зависит от:** 4.5

**Размер:** M

---

### 4.6 OIDC SSO интеграция
> 🏁 SR: C — OIDC SSO; trigger: same as 4.5

**Поставка:**
- [ ] Поддержка внешних провайдеров (Authentik / Keycloak / Auth0 / Google Workspace).
- [ ] ExternalSurface поле `auth.oidc.{issuer,clientId,...}`.
- [ ] Auto-провижионинг конфигов для Argo CD, Backstage, Headscale, OpenBao.

**Acceptance:** один SSO-логин даёт доступ ко всем UI; MFA enforced.

**Зависит от:** 4.4

**Размер:** M

---

### 4.7 platform-cli login (OIDC kubeconfig)
> 🏁 SR: C — login OIDC kubeconfig; with 4.6

**Поставка:**
- [ ] Device-flow OIDC, токен 8h, auto-refresh.
- [ ] Записывает в `~/.kube/config` контекст с exec-credential.
- [ ] Audit-event на каждый login.

**Acceptance:** после AccessGrant пользователь делает `platform-cli login` и работает с `kubectl`.

**Зависит от:** 4.6

**Размер:** M

---

### 4.8 Magic-link flow для AccessGrant
> 🏁 SR: C — magic-link; with 4.6

**Поставка:**
- [ ] Notifications-template из 2.15 (`access-grant/issued`).
- [ ] Endpoint в `platform-cli login --magic-link <token>`.
- [ ] Один-time-use, 24h TTL.

**Acceptance:** flow §3.4 шаги 1–7 проходят за ≤ 5 минут от commit до active mesh.

**Зависит от:** 4.5, 4.7

**Размер:** S

---

### 4.9 Auto-revocation на expiry
> 🏁 SR: C — auto-revocation; with 4.6

**Поставка:**
- [ ] Cron-reconciler сканирует AccessGrant.expiry.
- [ ] T-5d: reminder через notifications.
- [ ] T+0: revoke (Headscale device removed, RoleBinding deleted, OIDC mapping cleared).
- [ ] Audit-event.

**Acceptance:** expired grant — пользователь не может ни в mesh, ни в k8s.

**Зависит от:** 4.5

**Размер:** S

---

### 4.10 Audit log в JetStream — cluster-admin tagging (REWORK)
> 🏁 SR: C — audit-log cluster-admin tagging; trigger: Group-C compliance

**Source:** ADR 0024.

**Поставка:**
- [ ] Stream `audit.platform` с retention 1 год.
- [ ] Все компоненты публикуют структурированные audit-события (кто, что, когда, на что).
- [ ] Tag cluster-admin actions specifically — route to dedicated stream `audit.cluster-admin`:
    - All k8s API server actions where user identity has cluster-admin RoleBinding.
    - All AccessGrant lifecycle events (created, approved, active, revoked).
    - All JIT access events (high-priority subset of cluster-admin).
- [ ] Separate retention policy: `audit.cluster-admin` retained longer (default 3 years vs 1 year for `audit.platform`) для compliance.
- [ ] Backstage audit-viewer plugin extended: filter by stream, search by user, time range, action type; cluster-admin actions highlighted.
- [ ] Export to external archive (S3) for cluster-admin stream specifically — compliance-grade retention beyond cluster lifetime.

**Acceptance:**
- Все события из §3.4 (login, AccessGrant lifecycle, MigrationPlan approval) видны и неизменяемы.
- Cluster-admin action (например, `kubectl delete deployment` на critical workload) appears in `audit.cluster-admin` with full context (who, when, what, from where).
- JIT grant audit trail searchable в Backstage end-to-end.
- S3 export job succeeds, audit blob is restorable.

**Зависит от:** 3.2 (kine + NATS), 4.5 (AccessGrant for user identity context)

**Размер:** M

---

### 4.11 Synthetic monitoring (Uptime Kuma external)
> 🏁 SR: D — synthetic monitoring dropped (external SaaS at launch)

**Поставка:**
- [ ] `platform-cli ext-vps init --provider hetzner-cloud --tier nano`.
- [ ] Provisioning Uptime Kuma на отдельном CX11.
- [ ] Targets из ExternalSurface (`syntheticMonitoring.endpoints`).
- [ ] Alerts через notifications.

**Acceptance:** упал Argo CD — alert приходит в течение 60s через telegram/slack/email.

**Зависит от:** 4.1, 2.14

**Размер:** M

---

### 4.12 Backups в external S3
> 🏁 SR: B · order 5 — backups to external S3

> ✅ **Ядро закрыто ранее в 2.6d-4 (2026-07-17):** scheduled off-site S3 push зашифрованного restic-репо (данные + CR + секреты + manifest) через AppRafter CronJob-restic (`apprafter-backup` runner). **Opt-in** (не «default ON» — zero-forced-purchase, ADR 0050 / [[project_2_6d4_s3_backup]]); Velero отклонён (ADR 0050 Alternatives). Остаток 4.12 = per-компонентные continuous-backup хвосты (ниже), НЕ restic-репо push.

**Поставка (остаток — per-component continuous backup, поверх 2.6d-4 restic-push):**
- [ ] CNPG continuous backup в S3 (Barman PITR — комплемент к logical `pg_dump` в restic-репо).
- [ ] NATS JetStream snapshot job.
- [ ] ClickHouse backup-job.
- [ ] Restore-runbook (`docs/operator-guide/disaster-recovery.md`).

**Acceptance:** test restore: новый кластер из бэкапа за < 1 час, данные совпадают.

> Ранняя (Tier-1 / early-adopter) реализация этого restore-механизма уже поставлена в **2.6d** (`export` + restic backup + `restore --into <fresh-cluster>`, auto-register + re-seal) — это тот самый restore-путь, который acceptance выше подразумевает. 4.12 добавляет *automated push в external S3 + scheduled runner* поверх него (2.6d-4 = его opt-in предтеча).

**Зависит от:** 4.1

**Размер:** L

---

### 4.13 Build pipeline: Trivy + Grype + Cosign + SBOM
> 🏁 SR: C — Trivy/Grype/SBOM; trigger: Phase-5+ security

**Поставка:**
- [ ] CI-шаблон (Forgejo Actions / GitLab CI / Woodpecker) для multi-stage build.
- [ ] BuildKit с inline-cache.
- [ ] Trivy + Grype scan, fail on HIGH (configurable).
- [ ] Syft → CycloneDX SBOM.
- [ ] Cosign sign + push в Harbor (mandatory для prod env).

**Acceptance:** PR с уязвимостью HIGH в base image — CI падает; merge запрещён.

**Зависит от:** 4.3, 4.2

**Размер:** L

---

### 4.14 Backstage Build Report plugin
> 🏁 SR: C — Build Report plugin; with 4.13

**Поставка:**
- [ ] View per Application image: размер, layers, CVE-list, SBOM, cache-эффективность, рекомендации.
- [ ] Diff между двумя build'ами (что прибавилось/убавилось).
- [ ] «Auto-fix where possible» — генерация PR с обновлённым base image.

**Acceptance:** разработчик видит CVE-отчёт без перехода в Trivy/Harbor UI.

**Зависит от:** 4.13, 1.10

**Размер:** M

---

### 4.15 Cost view в Backstage
> 🏁 SR: C — Cost view; managed portal billing covers launch

**Поставка:**
- [ ] Per Application: CPU/RAM/disk/network usage из VictoriaMetrics.
- [ ] Аллокация % cluster cost (rough percentages в v1.0).
- [ ] Per platform-service breakdown (DB rows, S3 GB, JetStream msgs).
- [ ] Экспорт CSV.

**Acceptance:** руководитель видит топ-5 самых дорогих Application.

**Зависит от:** 3.6, 1.10

**Размер:** M

---

### 4.15a Cilium FQDN policies for `connects.egress.external`
> 🏁 SR: D — Cilium FQDN policies (advisory only); reactivate with Tier-2 security ask

**Source:** tracker «Known limitations» elimination.

**Цель:** enforce `Application.connects.egress.external` declarations через Cilium FQDN-aware NetworkPolicies; eliminate «advisory only» limitation.

**Поставка:**
- [ ] Operator renderer (`operator-rendering`):
    - For each Application с `connects.egress.external: [...]` → generate `CiliumNetworkPolicy` с FQDN matchers per declared destination.
    - DNS-aware matching (Cilium DNS proxy integration): policy matches actual DNS resolution at runtime.
    - Wildcard support (`*.binance.com`) per Cilium FQDN policy capabilities.
- [ ] Backstage Application view: show declared external dependencies vs actual flows (cross-reference with Hubble drops для not-declared destinations).
- [ ] Update spec.md Known Limitations to remove «connects.egress.external not enforced» bullet.
- [ ] Migration: existing Applications без `connects.egress.external` declarations не affected (default-deny stays for declared destinations; undeclared traffic continues blocked by NetworkPolicy default-deny).

**Acceptance:**
- Application с `connects.egress.external: [{host: "api.tron.network", port: 443}]` имеет working egress only к этому destination.
- Attempt to call `api.binance.com` (not declared) → Cilium drop, Hubble logs it.
- Backstage shows: declared destinations green, observed-but-not-declared red с «add to policy» button (similar to 3.7b).

**Зависит от:** 4.13 (Build pipeline — для image scan), 3.7b (Backstage Hubble plugin), 3.3 (Cilium mTLS)

**Размер:** M

---

### 4.16 MigrationPlan Backstage UI (REWORK — alignment with M1.5)
> 🏁 SR: C — MigrationPlan Backstage UI; post-launch first bundle (with 3.10)

**Source:** ADR 0027.

**Цель:** после M1.5 closure, MigrationPlan CRD already exists with unified scope (application + platform). В Phase 4 остаётся Backstage UI plugin для MigrationPlan queue + notifications integration.

**Поставка:**
- [ ] Backstage MigrationPlan plugin: unified queue view (filter by scope/phase/owner), approve/reject buttons (gated by RBAC), audit trail view per plan.
- [ ] Notifications service integration: pending-approval plan → notification to approvers via email/webhook (Phase 4 also delivers notifications service).
- [ ] MigrationPlan template library: golden-path templates для common destructive operations (PG selector change, image major bump) — pre-populated `plan` array steps that user reviews and approves.

**Acceptance:** Backstage shows MigrationPlan queue with filters; approver receives notification on pending plan; one-click approve via Backstage UI works end-to-end.

**Зависит от:** 1.83 (M1.5 closure — CRD + controller already exist), 4.6 (OIDC SSO for Backstage RBAC), notifications service from Phase 4.

**Размер:** M

---

### 4.17 Закрытие чек-листа M4 spec

- [ ] Обновить `spec.md` §6 M4.
- [ ] Tag `v0.4-mvp`.

**Размер:** XS

---

## Фаза 5 — Tier 3, bare metal (M5)
> 🏁 SR: D — Tier 3 (Talos/LINSTOR/Kata) post-launch territory

**Цель фазы:** платформа разворачивается на Talos+EPYC; LINSTOR как replicated storage; Kata по умолчанию.

**Spec:** §6 M5, §4.1 (Tier 3), §3.7 (Hetzner Robot).

### 5.1 Talos installation flow

**Поставка:**
- [ ] `platform-cli init --tier prod --provider hetzner-robot --osImage talos-1.x`.
- [ ] PXE / ISO bootstrap через `talosctl`.
- [ ] Machine config generation через `talm`.
- [ ] State в Git (encrypted).

**Acceptance:** 3 EPYC ноды → Talos → k8s ready за < 30 минут от старта `init`.

**Зависит от:** 3.10

**Размер:** L

---

### 5.2 Hetzner Robot built-in provider

**Поставка:**
- [ ] Robot API SDK интеграция (Rust).
- [ ] Server lifecycle: order не автоматизируем (manual), но lifecycle (vSwitch, IP, reset, boot mode) — да.
- [ ] vSwitch для private network между серверами.
- [ ] Failover IP management.

**Acceptance:** `platform-cli plan` показывает diff Robot ресурсов; `apply` применяет.

**Зависит от:** 1.2

**Размер:** L

---

### 5.3 LINSTOR provisioning

**Поставка:**
- [ ] Piraeus operator (LINSTOR).
- [ ] StorageClass `linstor-replicated-3` по умолчанию для prod.
- [ ] Auto-provisioning DRBD volumes.
- [ ] Backup интеграция.

**Acceptance:** PVC с replicated SC получает 3-копийный volume; failover ноды без потери данных.

**Зависит от:** 5.1

**Размер:** L

---

### 5.4 Kata containers как default runtime

**Поставка:**
- [ ] Kata install через operator (kata-deploy).
- [ ] RuntimeClass `kata` на всех нодах prod.
- [ ] Application имеет `runtime: kata|containerd` (default — kata в Tier 3).
- [ ] Performance benchmark vs containerd.

**Acceptance:** Application с `runtime: kata` запускается, изоляция проверена (ps на хосте не видит процесс).

**Зависит от:** 5.1

**Размер:** L

---

### 5.5 MSP scenarios + multi-customer Kamaji scaling (REWORK)

**Source:** ADR 0023.

**Цель:** validated MSP scenario (multiple customers одного AppRafter HQ) + scaling patterns для Kamaji когда tenants растут.

**Поставка:**
- [ ] MSP onboarding flow:
    - Apply customer Tenant manifest → new Kamaji TenantControlPlane provisioned.
    - Customer admin AccessGrant scoped to TCP only.
    - Customer Applications deployed внутри TCP.
- [ ] Customer isolation guarantees verified end-to-end:
    - Customer A's employee cannot kubectl into Customer B's TCP.
    - Customer A's employee cannot kubectl into host cluster.
    - Customer A's quota exhaustion doesn't affect Customer B.
- [ ] Multi-customer scaling patterns:
    - Shared Kamaji datastore (CNPG cluster) serves multiple TCPs — verify scaling characteristics.
    - Per-TCP node selectors для tenant workload affinity (если customer wants dedicated workers).
- [ ] Customer cluster export hooks (для customer exit / migration to self-host) — initial implementation (refines in Phase 7+).
- [ ] Backstage MSP overview: list customers, per-customer resource usage, billing-relevant metrics.

**Acceptance:**
- 3+ customer Tenants на одном AppRafter HQ instance.
- Customer A admin attempts to access Customer B's TCP → fails with proper auth error.
- Customer cluster export creates portable manifest bundle.

**Зависит от:** 3.8a (Tenant CRD), 5.3 (LINSTOR — для customer data persistence), 4.16 (MigrationPlan UI — для customer migration scenarios)

**Размер:** L

---

### 5.6 KubeVirt enable для VM workloads

**Поставка:**
- [ ] KubeVirt operator.
- [ ] CUE-схема `kind: VirtualMachine` (parallel to Application).
- [ ] Backstage plugin (минимальный list+status).

**Acceptance:** VM запускается, доступна по SSH через AccessGrant mesh.

**Зависит от:** 5.1, 4.5

**Размер:** L

---

### 5.7 Migration Tier 2 → Tier 3

**Поставка:**
- [ ] `platform-cli upgrade-tier --to prod`.
- [ ] PG migration через CNPG → restored на Tier 3 LINSTOR.
- [ ] NATS migration через mirroring.
- [ ] Workloads переезжают через MigrationPlan.

**Acceptance:** Tier 2 кластер с реальной нагрузкой мигрируется без потери данных, downtime < 30 минут на claim.

**Зависит от:** 5.3, 4.16

**Размер:** L

---

### 5.8 MARKER — Karpenter на Hetzner via CAPI (opt-in для OSS Tier 2+)

**Source:** ADR 0021.

> When Cluster API (CAPI) infrastructure is established as part of Turnkey foundation (Phase 5+ separate work track), Karpenter on Hetzner becomes available as opt-in для OSS Tier 2+ clusters. Concrete deliverables, dependencies, and sizing are populated when CAPI is ready. Karpenter component will be added to platform-stack chart как opt-in tier-2 overlay enable.

**Размер:** TBD (depends on CAPI)

---

### 5.9 Закрытие чек-листа M5 spec

- [ ] Обновить `spec.md` §6 M5.
- [ ] Tag `v0.5.0-bare-metal`.

**Размер:** XS

---

## Фаза 6 — Tier 4, confidential (M6)
> 🏁 SR: D — Tier 4 (CoCo/AWS); trigger: compliance/sovereignty signal

**Цель фазы:** workloads с `confidential: true` на SEV-SNP / TDX нодах; attestation; AWS C8i интеграция.

**Spec:** §6 M6, §4.1 (Tier 4).

### 6.1 Kata-CC runtimeClass + nodepool selectors

> **Wording:** confidential — opt-in feature, decoupled from T4 (per ADR 0015). Любой тир может включать confidential workloads если соответствующий nodepool доступен; T4 — это "regulated" профиль (compliance, attestation, audit), не синоним "confidential".

**Поставка:**
- [ ] kata-cc установка.
- [ ] Nodepool labels `compute.confidential: tdx|sev-snp`.
- [ ] Application с `confidential: true` → scheduling на confidential nodepool + RuntimeClass kata-cc.

**Acceptance:** confidential workload запускается, attestation passes; non-confidential не попадает на confidential ноды.

**Зависит от:** 5.4

**Размер:** L

---

### 6.2 AWS provider (C8i / M7a) + Karpenter standalone (REWORK)

**Source:** ADR 0021.

**Поставка:**
- [ ] AWS SDK Rust интеграция в platform-cli.
- [ ] EC2 / VPC / EKS provisioning.
- [ ] Mixed Hetzner+AWS deployments (через Infrastructure provider композицию).
- [ ] AWS KMS для OpenBao auto-unseal.
- [ ] Karpenter standalone installation as part of AWS stack (Karpenter is native first-class on AWS, no CAPI required). Karpenter component added to platform-stack chart tier-4 overlay.
- [ ] Karpenter NodePool configurations per Application kind (default sizes, instance type preferences).
- [ ] Cluster-autoscaler explicitly **not** installed (per ADR 0021 «cluster-autoscaler not supported»).
- [ ] Verify Karpenter consolidation policy works well on AWS dual-stack instances.

**Acceptance:**
- Tier 4 на AWS C8i запускается; HA между AZ.
- AWS Tier 4 cluster bootstraps с Karpenter active.
- Application scaling triggers actual node provisioning (verify with Karpenter logs + EC2 instances list).
- Karpenter consolidates when load drops.

**Зависит от:** 1.2 (паттерн), 3.11 (KMS)

**Размер:** L (existing) + S (Karpenter additions) = L overall

---

### 6.3 Confidential service providers

**Поставка:**
- [ ] PG-confidential (CNPG на confidential nodes).
- [ ] OpenBao-confidential.
- [ ] Documentation: что нельзя сделать confidential (NATS — open question).

**Acceptance:** Application с confidential PG получает claim, который scheduling на confidential nodepool.

**Зависит от:** 6.1, 2.4

**Размер:** L

---

### 6.4 Attestation flow с workload identity

**Поставка:**
- [ ] Attestation report integration в SPIFFE workload identity (через SPIRE plugin).
- [ ] OpenBao policy: только attested workloads могут читать confidential secrets.
- [ ] Backstage badge «attested» на Application странице.

**Acceptance:** скомпрометированный (без attestation) под не получает confidential credentials.

**Зависит от:** 6.1, 3.11

**Размер:** L

---

### 6.5 Application.confidential: true flag

**Поставка:**
- [ ] CUE-схема дополнение.
- [ ] Renderer применяет nodepool selector + runtimeClass + attestation policy.
- [ ] Backstage UI отметка confidential.

**Acceptance:** один флаг включает весь стек confidential.

**Зависит от:** 6.1, 6.4

**Размер:** S

---

### 6.6 MARKER — NAT64 opt-in component

**Source:** ADR 0017.

> Implemented on-demand when first IPv6-only deployment requires outbound to legacy IPv4-only services. Component: NAT64 + DNS64 platform-service (added to platform-stack chart as opt-in component). Operator declaration: `Infrastructure.network.nat64.enabled: true` when `ipFamilies: [ipv6]` is set. Concrete deliverables added when scenario materialises.

**Размер:** TBD (deferred)

---

### 6.7 MARKER — Bare metal slow autoscaling research

**Source:** ADR 0021.

> Research item для Tier 3 bare metal autoscaling pattern. Design constraint: UX/DX must not degrade compared to faster tiers — Application API behavior identical, slow provisioning hidden through capacity headroom and predictive scaling. Possible paths: server auction cache + Robot API order automation. Research output: ADR + PoC; production implementation deferred until research conclusions.

**Размер:** L (research, not implementation)

---

### 6.8 Закрытие чек-листа M6 spec

- [ ] Обновить `spec.md` §6 M6.
- [ ] Tag `v0.6.0-confidential`.

**Размер:** XS

---

## Фаза 7 — Plugin ecosystem 🌱
> 🏁 SR: D — plugin ecosystem; community-contribution timeframe

**Цель фазы:** комьюнити может расширять платформу без trunk-доступа.

**Spec:** §3.6 (ServiceProviderPlugin), §3.7 (InfrastructureProviderPlugin), §4.12, §8 (three-tier plugin model).

> Запускать **параллельно** с 3+ как только есть ServiceProvider CRD (после 2.1).

### 7.1 ServiceProviderPlugin gRPC interface (proto)

**Поставка:**
- [ ] `proto/service_provider/v1.proto`: rpc Provision/Update/Deprovision/HealthCheck/Schema.
- [ ] Versioning policy.
- [ ] Codegen для Go, Rust, TypeScript, Python (CI).

**Acceptance:** генерация stub'ов в 4 языках без warning'ов.

**Зависит от:** 2.1

**Размер:** M

---

### 7.2 Plugin host runtime в operator

**Поставка:**
- [ ] Sidecar container management (operator поднимает gRPC plugin pod на ServiceProviderPlugin).
- [ ] mTLS plugin↔operator (через SPIFFE).
- [ ] Health/readiness, restart on failure.

**Acceptance:** plugin pod корректно стартует, hook'ается, перезапускается.

**Зависит от:** 7.1, 2.7

**Размер:** L

---

### 7.3 Reference community ServiceProviderPlugin: MySQL Percona

**Поставка:**
- [ ] Отдельный repo `apprafter-plugin-mysql-percona`, MIT.
- [ ] gRPC server (Go), wraps Percona Operator.
- [ ] Documentation, тесты.
- [ ] Публикация в plugin catalog.

**Acceptance:** `needs.mysql` работает после `kind: ServiceProviderPlugin` apply.

**Зависит от:** 7.2

**Размер:** L

---

### 7.4 Plugin catalog (отдельный репо)

**Поставка:**
- [ ] Static site (mdBook/Hugo) с perevody plugin'ов.
- [ ] CI checks: схема, лицензия, security review.
- [ ] Submit-PR flow.

**Acceptance:** community plugin виден на сайте после merge PR.

**Зависит от:** 7.3

**Размер:** M

---

### 7.7 WASM plugin runtime (R&D)

**Поставка:**
- [ ] Tracking ADR на состояние WASI (threading, async I/O).
- [ ] PoC в отдельной ветке.
- [ ] Decision-point: миграция или продление gRPC.

**Acceptance:** ADR с рекомендацией; код PoC.

**Зависит от:** 7.2

**Размер:** L (R&D, неблокирующее)

---

### 7.8 MARKER — kine+NATS как Kamaji datastore experimental

**Source:** ADR 0023, tracker 2.3.

> Experimental research: verify if Kamaji can use kine+NATS as datastore (kine officially supports etcd-API emulation поверх NATS; Kamaji not officially validated for this combination). If works — alternative single-substrate path для Kamaji's tenant state. If not — staying на integrated CNPG. Research output: feasibility report + (if positive) reference deployment.

**Размер:** M (research, opt-in)

---

### 7.9 MARKER — MigrationPlan future enhancements (skip + partial migration)

**Source:** ADR 0027 Still open.

> Future enhancements to MigrationPlan CRD considered post-Phase-7:
> - `skip` action: user acknowledges available upgrade without acting; PlatformStack.status.skippedVersions tracks skipped versions; only proposes next version when one becomes available. Useful for cycle skipping.
> - Partial migration: per-component approval when a platform upgrade touches multiple components. Plan splits into sub-plans or per-component approval entries.
>
> Both are extensions of existing CRD schema (additive); no breaking changes.

**Размер:** M (when triggered by user demand)

---

### 7.10 MARKER — Non-GitHub fork support

**Source:** ADR 0028 Still open.

> `apprafter platform fork` currently supports GitHub only (per 1.80). Extend to GitLab (and possibly Gitea/Forgejo) via vendor-specific API integration. Phase 2+ depending on user demand. Pattern: trait `GitHostForkProvider` with GitHub + GitLab implementations.

**Размер:** M (when triggered)

---

## Фаза 8 — 1.0 release (M7)

**Цель фазы:** стабилизация API, документация, бенчмарки, публичный релиз.

**Spec:** §6 M7.

### 8.1 CUE schema → v1 (semver guarantee)

**Поставка:**
- [ ] Заморозка CRD на v1, conversion webhooks v1alpha1→v1.
- [ ] Compatibility tests.
- [ ] Deprecation policy документ.

**Acceptance:** все CRD v1; v1alpha1 manifests продолжают работать с deprecation warnings.

**Размер:** M

---

### 8.2 TechDocs полный сайт

**Поставка:**
- [ ] Архитектура, концепты, operator guide, dev guide, reference (CRD field-by-field).
- [ ] Tutorials: «Solo founder» (Tier 1), «Small team» (Tier 2), «Production» (Tier 3), «Regulated» (Tier 4).
- [ ] FAQ.
- [ ] Search (Algolia / Stork).
- [ ] Hosted на app.apprafter.dev/docs.

**Acceptance:** новый разработчик находит ответ на 90% типовых вопросов через docs+search.

**Зависит от:** 0.7

**Размер:** L

---

### 8.3 Reference deployments (publish)

**Поставка:**
- [ ] Public Tier 1 demo cluster (read-only Backstage).
- [ ] Public Tier 2 demo.
- [ ] Bench cluster для performance reports.
- [ ] Open-source examples репо.

**Размер:** M

---

### 8.4 Public bootstrap-from-zero benchmark

**Поставка:**
- [ ] CI-job: время от `platform-cli init` до live Application.
- [ ] Цель: < 15 минут.
- [ ] Публичный dashboard с историей.

**Размер:** S

---

### 8.5 Disaster Recovery plans-as-code

> **2.6d — движок, который этот CRD обёртывает.** Shipped 2.6d (`export`/`backup`/`restore`, restic-движок, restore-ordering + re-seal) — исполнительный слой; будущий `DisasterRecoveryPlan` декларативно оркестрирует его вызовы под каждый scenario ниже (полная потеря кластера → `restore --into <fresh>`; corruption pg → data-restore в существующий кластер). CRD не переизобретает restore, а сшивает шаблоны + расписания вокруг него.

**Поставка:**
- [ ] `kind: DisasterRecoveryPlan` CRD.
- [ ] Шаблоны: «полная потеря кластера», «потеря одного компонента ExternalSurface», «coruption pg».
- [ ] Manual run книги на каждый scenario.
- [ ] Quarterly DR-drill в CI.

**Acceptance:** drill восстанавливает Tier 2 кластер из бэкапов за < 2 часа.

**Зависит от:** 4.12

**Размер:** L

---

### 8.6 Security review + responsible disclosure

**Поставка:**
- [ ] External pentest.
- [ ] SECURITY.md с PGP-ключом.
- [ ] CVE process.
- [ ] Bug bounty (HackerOne / self-hosted) — опционально.

**Размер:** L

---

### 8.7 Public 1.0 launch

**Поставка:**
- [ ] Release notes.
- [ ] Blog post / announcement.
- [ ] Public roadmap для post-1.0.
- [ ] Tag `v1.0.0`.

**Размер:** S

---

## Фаза M — Managed track (product 2)

> 🏁 Speedrun managed-specific work (`speedrun-plan.md` §3). No OSS plan.md backing — the §M.x numbers are NOT Phase 3 subphases. Ordered per speedrun §4.3 (PASS 1–6). Grounded in ADR 0034 (managed model), 0036 (MCP safety), 0037 (control-plane infra).

- [ ] **M.1 (PASS 1)** Hosted multi-tenant SaaS scaffolding — auth / customer registry / agent-bus (speedrun §3.1)
- [ ] **M.2 (PASS 1)** `apprafter-agent` + cluster registration (speedrun §3.2; ADR 0031)
- [ ] **M.3 (PASS 1)** Customer offboarding = revoke registration token (speedrun §3.2a)
- [ ] **M.4 (PASS 2)** Hosted Backstage — namespace-per-customer + `<customer>.apprafter.dev` (speedrun §3.3)
- [ ] **M.5 (PASS 2)** Subdomain delegation `*.<customer>.apprafter.dev` (speedrun §3.6)
- [ ] **M.6 (PASS 3)** Hosted MCP server + agent passthrough (speedrun §3.4; ADR 0036)
- [ ] **M.7 (PASS 3)** Destructive-op gate via MigrationPlan CRD (speedrun §3.5; ADR 0036). Approvals at launch: `apprafter` CLI + Argo CD approve/reject buttons; Backstage plugin post-launch
- [ ] **M.8 (PASS 4)** Stripe subscription + 14-day trial (speedrun §3.7)
- [ ] **M.9 (PASS 5)** Migration helpers — Supabase / Railway basic (speedrun §3.8)
- [ ] **M.10 (PASS 5)** Internal customer support tooling (speedrun §3.10)
- [ ] **M.11 (PASS 6)** Polish + soft launch (closed beta → invite waves → public)

---

## Сквозные направления (running concerns)

Эти задачи не привязаны к конкретной фазе и идут параллельно.

### ∞.1 ADR-дисциплина

- [ ] Каждое нетривиальное архитектурное решение → ADR в `docs/adr/`.
- [ ] Раз в квартал — ревью устаревших ADR.
- [ ] Зафиксировать ADR'ы 0014–0029 (исключая 0018 как Unused): добавить в `docs/adr/`, обновить `docs/adr/README.md` index. ADR 0011 mark as `Status: Superseded by 0016`.
- [x] **M1.5 carry-over:** ADRs 0025–0029 committed to `docs/adr/` (проверено 2026-09-07: все пять на месте — `0025-gitops-control-surface`, `0026-platformstack-crd`, `0027-migrationplan-unification`, `0028-platform-stack-distribution`, `0029-cue-cmp`). Чекбокс отставал от дерева.

### ∞.2 Dependency hygiene

- [ ] Renovate / Dependabot bot.
- [ ] Weekly digest в Backstage.
- [ ] Critical CVE → автоматический PR.

### ∞.3 Performance regression tracking

- [ ] Bench-CI (operator reconcile latency, build time, bootstrap time).
- [ ] Baseline + alert на > 10% регрессию.

### ∞.4 Open questions из spec §7 (still open)

- [ ] (1) kine + NATS scaling ceiling — empirical, требует production-данных.
- [ ] (2) CUE vs Pkl re-evaluation point — ADR на M5.
- [ ] (3) Multi-tenancy isolation choice — ADR в фазе 5.5.
- [ ] (4) Migration tooling depth — расширение runner'ов в v2.x.
- [ ] (5) Cost attribution model — улучшение метрик per-DB / per-queue.
- [ ] (6) Backstage vs custom portal — pulse-check на каждом milestone.
- [ ] (7) WASM plugin readiness — фаза 7.7.
- [ ] (8) Bidirectional self-healing — отдельный design в M5+.
- [ ] (9) Codename — ✅ AppRafter.
- [ ] (10) OneBun integration depth — фиксировать ADR per-сервис.
- [ ] (11) Per-environment substrate (federated multi-cluster) — v2.x.

### ∞.5 Community и governance

- [ ] CONTRIBUTING flow.
- [ ] Quarterly community calls.
- [ ] Public roadmap (этот документ + статус).
- [ ] Maintainership ladder.

### ∞.6 Backports и LTS-policy

- [ ] Определить LTS-окно (рекомендация: каждый minor LTS на 1 год; 2 параллельных LTS).
- [ ] Security-bugfixes — backport.

### ∞.7 Tier-1 Hetzner stability hardening (gate to M1.5)

> **Status:** ✅ Gate passed for M1.5 start. Все items закрыты per plan.md changelog v0.1.43–v0.1.65 (см. чек-боксы ниже).

Открытые баги, найденные в первом полном ручном E2E (2026-05-08…10). Закрыты до старта M1.5 (v0.1.66+) — иначе M1.5 строится на дрейфующей основе. Каждый — отдельный patch v0.1.4x–v0.1.5x.

- [x] **SSH host-key collision при destroy+apply на тот же IP.** ✅ закрыто `v0.1.46` 2026-05-10. `StatePaths::known_hosts_file()` → `.apprafter/known_hosts`; `SshKubeconfigFetcher` принимает path и передаёт `-o UserKnownHostsFile=…` + `-o StrictHostKeyChecking=accept-new`. `destroy --yes` сносит файл вместе со state. `~/.ssh/known_hosts` не трогаем.
- [x] **`HetznerCloudProvider::destroy()` race-condition.** ✅ закрыто двумя слоями: `v0.1.47` (server-level poll: `wait_for_server_gone()` ждёт исчезновения server из `GET /v1/servers`); `v0.1.50` (resource-level retry: `delete_with_retry_on_resource_in_use` для `delete_firewall` + `delete_network` — Hetzner reaps `firewall.applied_to` / `network.servers` ещё 1-15с после server-vanish, ловит на `422 resource_in_use`). Exponential back-off 500ms → 5s, 60s deadline в обоих слоях.
- [x] **noVNC console fallback при сетевой смерти VM.** ✅ закрыто `v0.1.49` 2026-05-10 (docs-only по варианту C). Новый `docs/operator-guide/recovery.md` с runbook'ом Hetzner Rescue Mode + chroot для триажа cloud-init / k3s / firewall логов с диска. Code-патч с опциональным `APPRAFTER_EMERGENCY_ROOT_PASSWORD` отложен до tier-3/4 (явный opt-in с audit-logging — не default для tier-1, который key-only by design).
- [x] **`default-deny` NetworkPolicy блокирует всё включая DNS+Service routing.** ✅ закрыто `v0.1.51` 2026-05-10. v0.1.0-mvp через v0.1.50 деплоил NP с `policyTypes: [Ingress, Egress]` и пустыми allow-rules → каждый workload в namespace в полной изоляции (только probes от kubelet работали, потому что host-network). Скрытно потому что nightly не пушился, а §4 quickstart никто не проходил end-to-end до 2026-05-10. Fix: Ingress-only с явными allow для same-ns (Service routing) и kube-system (Gateway/HTTPRoute/monitoring); egress без ограничений до phase 2.10.
- [x] **`tracing` logs идут в stdout вместо stderr.** ✅ закрыто `v0.1.44` 2026-05-09. `with_writer(std::io::stderr)` в `cli-core/src/logging.rs` + smoke-test guard в `cli_smoke.rs`. Affected commands: `apply`, `destroy`, `import`, `kubeconfig`, `argocd-password` теперь имеют чистый stdout, диагностика на stderr.
- [x] **k3s flannel конфликтует с Cilium VXLAN device.** ✅ закрыто `v0.1.45` 2026-05-09. k3s ships embedded flannel-vxlan daemon на UDP port 8472, тот же что нужен Cilium → `cilium_vxlan: address already in use` → cilium-agent CrashLoopBackOff → каждый `cluster-bootstrap` падал на Argo CD pre-install timeout. Fix: добавили `--flannel-backend=none --disable-network-policy` к k3s installer в `user_data.rs`; теперь 5 disabled-флагов вместо 3 (Cilium-recommended k3s recipe).

### ∞.8 CRD short-name rename pre-M2

**Source:** SPEC_REFINEMENTS cross-cut from ADR обсуждений.

- [ ] Rename `applications.apprafter.io` CRD short-name to `apps.apprafter.io` or `workloads.apprafter.io` to avoid shadowing Argo CD's `applications.argoproj.io`. Decision and rename must happen during M1.5 (ideally early, around 1.66–1.70) before more docs reference the short name.

**Размер:** XS (CRD spec change + admission alias + docs sweep). Affects existing tests minimally; mostly documentation.

### ∞.9 Smoke test design fix (closes Phase 1 quickstart contradiction)

**Source:** discussion of operator quickstart §4.

- [ ] Rewrite `e2e/mvp.sh` and `docs/operator-guide/quickstart.md` §4 to exercise the `Application` CRD end-to-end рядом с the platform stack, not раздельно as currently. Folded into 1.81 (e2e tests update) and 1.82 (docs update) within M1.5.

---

### ∞.10 Inline sealed env value — второй режим доставки секретов на T1 (BACKLOG)

> 🏁 SR: C — defer. Идея хорошая, но это заметный объём доп.работы ради T1; не блокирует launch.
> Контекст: разбор D6/D14 (`docs/measurements/day2-followups.md`) + поправка к ADR 0007 (2026-08-30).

**Суть.** Четвёртая форма значения `env`: не `Literal`, не `claim.<...>`, не `secret:"name/key"`,
а **шифротекст прямо в манифесте приложения**, расшифровать который может только кластер.

**Зачем.** Форма доставки определяет, какой контроль вообще доступен:

| форма | ревьюится? | доступный контроль |
| --- | --- | --- |
| `apprafter secret seal` (императивно) | нет, непрозрачный блоб | только **раскрытие** (поправка к ADR 0007) |
| inline шифротекст в манифесте | да — виден факт и переменная, не значение | **гейт через MigrationPlan** |

Сеал отревьюить нельзя по природе; инлайн-шифротекст — можно, потому что изменение становится
диффом спеки, который машинерия MigrationPlan и так видит на каждом реконсиляе. Ровно ту же
осторожность существующий код уже проявляет: `from`/`to` в `DestructiveChange` несут только
сентинелы, никогда значения.

**Ключевое упрощение (владелец, 2026-08-30): это сахар, а не новый криптопуть.** По сути форма
эквивалентна тому, как если бы в одном манифесте/репо лежали `kind: SealedSecret` с шифротекстом
И апп-манифест, который тут же ссылается на него через `ref`. Значит оператор ничего не
расшифровывает: он рендерит SealedSecret с производным именем + обычный `secretKeyRef`, а дальше
работает штатный sealed-secrets-контроллер. Отсюда — и strict scope сохраняется бесплатно
(производное имя `<app>-env-<VAR>` даёт настоящую пару `(namespace, name)`), и весь существующий
путь (`EnvSecretMissing`, рендерер, резолв ref'ов) не меняется.

**Минус (владелец): таким секретом нельзя пошариться между приложениями.** Владелец ровно один.
Это цена — и одновременно свойство: радиус поражения ровно одно приложение, тогда как именно
неизвестный радиус (несколько апп на один секрет) сделал автоматический роллаут небезопасным в D6.
Для секретов в этой форме автоматический роллаут снова становится обсуждаемым.

**Вторая цена:** ротация = коммит + синк вместо одной команды. Для «утёк ключ» это медленнее.
Поэтому это **второй режим, а не замена** — императивный путь остаётся нужен и для платформенных
кредлов в `apprafter-system`, у которых манифеста приложения нет вообще.

**Поставка (когда дойдут руки):**
- [ ] CUE `#EnvValue` + `EnvRef` — четвёртый вариант (`sealed`), CRD через `crdgen`, webhook-валидация формы.
- [ ] Рендер: производное имя + SealedSecret-объект + `secretKeyRef` (оператор не расшифровывает).
- [ ] CLI: получить шифротекст для вставки в манифест (переиспользовать путь `secret seal --stdout`).
- [ ] `ApplicationMigrationStrategy`: новый триггер, классификация `security-boundary`, симметрично
      `env-secret-ref-retarget`; `from`/`to` — сентинелы, не шифротекст.
- [ ] Per-env: оверрайд каждого окружения несёт свой блоб под своим производным именем.
- [ ] Walk: правка блоба в манифесте → план создан → апрув → под поднялся с новым значением.

**Не делать:** ослаблять scope SealedSecrets до namespace-/cluster-wide ради «инлайновости» —
блоб станет переносимым в чужой манифест, что подорвёт ровно тот гейт, ради которого всё затевается.

---

## История изменений плана

> Вынесено в отдельный файл: [`docs/changelog/plan-history.md`](docs/changelog/plan-history.md) — plan-level ledger на English (одна строка на под(под)фазу / патч; ранее таблица жила здесь). Детализация по релизам — `docs/changelog/history.md`.