houseplan-card/docs/reviews/SPEC-REVIEW-500-r3.md

# SPEC-REVIEW-500-r3

- **Issue:** #500 — одна граница владения config/adoption
- **Этап:** ТЗ на ревью (PROCESS.md §2.4)
- **Заход:** r3 · блокирующих циклов израсходовано 2 из 4 (лимит лёгкого трека
  не действует — трек полный, лимит 4; заход r3 сам по себе бюджет не тратит,
  если вердикт зелёный, §4/#227)
- **Материал раунда:** ветка `issue/500-config-adoption-boundary`, коммит
  `622470ffb57285c6a2ffc9fa3d913004212fe00a` (докс-only, `docs(spec): #500 r3
  — post-write profile keeps caller tails untouched`), поверх коммита
  документа ревью r2 `3f6b991c2839e7c2aa2586b38b4292571e742cf6`. ТЗ:
  `docs/specs/500-config-adoption-boundary.md`, блоб на этом коммите
  `596ca78a…` (см. `git show 622470ff:docs/specs/500-config-adoption-boundary.md`).
  Материал доступен локально (fetch выполнен), код продукта не менялся ни в
  одном из трёх заходов — ТЗ описывает существующий код `origin/dev`, а не
  вносит изменений в `src/**`.

## Скоуп разбора (по §2.10)

Это третий заход. Предыдущий вердикт (r2, документ
`docs/reviews/SPEC-REVIEW-500-r2.md`) — жёлтый, одна блокирующая находка
High-3, материал которой зафиксирован как коммит `c35ecf13206b`, дерево
`9a354a9fa366fcca195773d22a15f7947caf5d14`, блоб ТЗ
`5cfc36e2614361d1e90d4d9a8a9a7358d4bec3b9`. SHA живой, дельта построена как
`git diff c35ecf13..622470ff -- docs/specs/500-config-adoption-boundary.md`.

Дельта r3 нелокальной не является: правка ограничена одним понятием
(«профиль `post-write`») внутри одного раздела ТЗ (§6.3), одной строкой в
списке особенностей `import/apply`, одной строкой AC3, одной строкой риска
§12 и одним пунктом §15. Она не меняет выбранную границу, не переоткрывает
закрытые High-1/High-2, не добавляет новую подсистему и не сопоставима по
объёму с исходной задачей — значит, объём разбора по дельте оправдан, полный
повторный проход не требуется. Разбор ниже проверяет ровно то, до чего
дотягивается дельта: правильность нового описания профиля `post-write`,
согласованность AC3/AC4/§12/§15 между собой и с кодом, и то, что High-1/High-2
не пострадали от этой правки (они дельту не задевают — оба живут в §3 п.1–3 и
AC1/AC2, которые в дельте r3 не тронуты).

## Как проверялось

Материал сверен построчным чтением `src/**` на `origin/dev` (тот же код, что
и в r1/r2 — эта задача ещё не реализована, ТЗ описывает текущее поведение):

- `houseplan-editor-runtime.ts:9757` — подтверждена цитата ТЗ: `if
  (this.host._hasFixedFloor) this.host._adoptInitialSpace(this.host._model,
  true); else this.host._commitSpace(nextSpace);` внутри `_applyBackupImport`.
  Именно это утверждение High-3 назвал неверно описанным в r2 («сегодня их
  там нет»); r3 признаёт факт и меняет модель профиля, а не сам факт.
- Тайл `import/apply` после этой ветки: `_backupImportDialog = null`,
  `_cacheSnapshot()`, `requestUpdate()`, `_showToast(...)` — совпадает с
  текстом «выбор пространства (…), `_cacheSnapshot`» в списке особенностей
  вызывающих (§6.3, последний абзац).
- `houseplan-onboarding-runtime.ts:476-483` и байт-в-байт дубликат
  `houseplan-editor-runtime.ts:8677-8699` (`space/delete`, оба входа) —
  `_commitSpace(...)` вызывается условно (`if (this.host._space === spaceId)`),
  что соответствует формулировке «`_commitSpace` при удалении текущего
  пространства» из того же списка; в обоих `_cfgRev`/`_layoutRev`
  действительно перезаписываются из ответа `space/delete` **после**
  `_adoptStructuralResponses` — подтверждает и I2, и таблицу AC4.
- `houseplan-editor-runtime.ts:9569-9591` (`_undoPlanOptimization`, `plan/
  optimize_undo`) — тайл: сброс `_canOptimizeUndo`/`_undoKind`, очистки
  историй, `_cfgEpoch++`, `_cacheSnapshot()`, toast — совпадает с текстом ТЗ.
- Проверена внутренняя согласованность документа: `grep` по терминам
  «пост-шаг», «профил», `_adoptInitialSpace`, `_commitSpace`, `_restoreZoom`,
  `_resumePendingNavMode` по всему файлу (`/tmp/spec_r3.md`) — нового
  противоречия между §3 п.2 (описание «до»), §6.3 (описание «после»), AC3,
  §12 и §15 п.7 не найдено; все места, где раньше стояло «post-write получает
  общие пост-шаги `_cacheSnapshot`/`_regSignature`/`_maybeRebuildDevices`»,
  переписаны на «пост-шагов нет, хвост остаётся у вызывающего» одновременно.
- Гейты (`typecheck`/`test`/`build`) не запускались: класс изменения —
  докс-only (`docs/specs/**`), продуктовый код не тронут ни в этом заходе, ни
  в предыдущих двух. Это тот же объём, что r1 и r2 сочли достаточным для
  этапа ТЗ; код появится только после `S5-ready`, и именно код-ревью будет
  отвечать на вопрос «оно работает» автотестами.

## Закрытие раунда r2

| Находка r2 | Чем закрыта | Где это видно |
|---|---|---|
| High-3: §6.3 утверждал «`_adoptInitialSpace`/… в профиль post-write не входят: сегодня их там нет», что неверно для `import/apply` при `_hasFixedFloor` (`houseplan-editor-runtime.ts:9757`, тогда `:9756`) | ТЗ признаёт факт и меняет модель: профиль `post-write` объявлен без пост-шагов вовсе — «последовательность заканчивается шагом 4», а `_adoptInitialSpace`/`_commitSpace` остаются частью нетронутого хвоста каждого вызывающего, а не шагом профиля. Формулировка больше не утверждает отсутствия вызова — она выносит его за пределы модуля | `docs/specs/500-config-adoption-boundary.md` §6.3 (строки «Профиль `post-write` **пост-шагов не имеет**: …включая `_adoptInitialSpace(_model, true)` в ветке `_hasFixedFloor` у `import/apply` (`houseplan-editor-runtime.ts:9757`)»), синхронно поправлены список особенностей `import/apply`, AC3, риск-строка §12, §15 п.7. Цитата с номером строки перепроверена чтением кода в этом заходе (см. «Как проверялось») |

High-1 и High-2 (заход r1) дельта r3 не задевает — они разрешены в r2 и
подтверждены зелёной частью вердикта r2 («обе High-находки r1 закрыты
содержательно»); ниже они наследуются без повторной проверки.

## Унаследовано из r2

Принято без повторной проверки в этом заходе, со ссылкой на материал, где
вывод был получен:

- **Семь вызывающих `_adoptStructuralResponses`** (три `reload` + четыре
  `post-write`, включая оба входа `space/delete`) и **18 присваиваний
  `_serverCfg =` в 8 модулях** (включая оба vacuum-writer'а) — перепроверены
  чтением `src/**` в раунде r2 и подтверждены дословным совпадением чисел с
  текстом ТЗ. Источник: `docs/reviews/SPEC-REVIEW-500-r2.md`, материал
  `c35ecf13206b` / дерево `9a354a9fa366fcca195773d22a15f7947caf5d14`.
- Пересчитанные числа `_layoutRev =` (7/4), fingerprint config (10/5),
  fingerprint layout (5) — там же, не изменились дельтой r3 (эти строки вне
  диффа `c35ecf13..622470ff`).
- `_resumePendingNavMode`/`_restoreZoom` действительно не встречаются на
  post-write путях — проверено в r2 и остаётся верным независимо от того, что
  сам профиль в r3 переопределён как «без пост-шагов»: отсутствие вызова этих
  двух функций на post-write путях не оспаривалось, менялась только модель
  «откуда» это отсутствие проистекает (не выбор профиля, а отсутствие шага 5
  вообще).
- Обязательные разделы §7.1, обоснование отказа от `small`, блок §15
  «принято предположительно» по назначению — подтверждены в r1, дельты не
  касались.

## Находки

Нет. Ни High, ни Medium, ни Low в этом заходе не обнаружено.

## Что проверено и корректно

- Единственная блокирующая находка r2 (High-3) закрыта по существу, а не
  переформулировкой в обход: автор не стал спорить с фактом (цитата кода
  подтверждена), а изменил модель профиля так, что факт больше не противоречит
  тексту. Это тот редкий случай, когда правильный фикс — не «добавить
  исключение», а «снять избыточное обобщение» (было false claim «этого шага
  нет», стало honest «этот шаг не наш, мы его не трогаем»).
- Новая формулировка внутренне согласована по всем пяти местам документа,
  которые о ней говорят (§6.3, список особенностей `import/apply`, AC3, риск
  §12, допущение §15 п.7) — правки синхронны, нигде не осталось старой
  формулировки «post-write получает общие пост-шаги `_cacheSnapshot`/
  `_regSignature`/`_maybeRebuildDevices`».
- Все процитированные в дельте номера строк (`houseplan-editor-runtime.ts:9757`)
  и утверждения о телах функций (`_commitSpace`, `_adoptInitialSpace`,
  тайл `optimize_undo`) подтверждены чтением текущего `origin/dev`, а не
  приняты на слово автора.
- Изменение не вводит нового продуктового вопроса и не расширяет скоуп:
  правка — уточнение технической модели существующего рефакторинга,
  подпадает под §15 «принято предположительно, менять свободно» и не требует
  решения владельца (продуктовых вопросов по-прежнему нет — пользователь
  ничего не наблюдает).
- AC4 (единственное намеренное изменение поведения — гейт `prepareImage` и
  источник ревизии на post-write путях) дельтой r3 не задет и остаётся
  доказанным описанным в r1/r2 способом.

## Чего не проверял

- Достижимость самого рефакторинга — кода ещё нет, ревью ТЗ оценивает план,
  не реализацию.
- Автотесты/typecheck/build не запускались — класс изменения r3 докс-only,
  как и r1/r2; гейты кода — предмет код-ревью (§2.7), когда появится код.
- Полный повторный построчный аудит `plan-optimize-write.ts`/
  `space-copy-runtime.ts`/`serialized-write-queue.ts` на предмет иных,
  ранее не поднятых расхождений — не проводился; фокус остался на том, что
  дельта r3 реально меняет (модель профиля `post-write`) плюс проверка, что
  High-1/High-2 не пострадали. Полный аудит этих трёх файлов был предметом
  r1 и не повторяется третий раз без сигнала, что дельта их задевает — не
  задевает (вне диффа `c35ecf13..622470ff`).
- Не проверялась (и не должна проверяться на этом этапе) корректность будущей
  реализации хвостов вызывающих «без изменений» — AC3 сам называет способ
  доказательства: «сверка диффом на ревью», то есть это станет предметом
  код-ревью, когда появится реальный диф `houseplan-editor-runtime.ts`/
  `houseplan-onboarding-runtime.ts`.

## Вердикт

Дельта r3 закрывает единственную блокирующую находку r2 содержательно и без
побочных повреждений уже принятого материала. Новых High/Medium/Low не
обнаружено.

**Вердикт: зелёный · заход r3 · блокирующих циклов 2/4 · High: 0 · Medium: 0 → в задаче**

---

<!-- material-anchors: сгенерировано конвейером (#414) -->

## Материал раунда

- Ветка: `issue/500-config-adoption-boundary`, коммит `622470ffb572` — ребейз его осиротит, и это нормально: ниже якоря, которые ребейз не меняет.
- Дерево материала: `22a334b5fe6188377bba675b5115d0b48735029e`
  ```
  git log --all --format='%H %T' | grep 22a334b5fe61
  ```
- ТЗ `docs/specs/500-config-adoption-boundary.md`, блоб `596ca78ac25df5d829d803a733cc165635cc689c`
  ```
  git log --all --find-object=596ca78ac25df5d829d803a733cc165635cc689c -- docs/specs/500-config-adoption-boundary.md
  ```
- Вердикт конвейера: `green` · High 0