houseplan-card/docs/specs/282-stable-wall-segment-identity.md

# Issue #282 — стабильная идентичность сегментов стен (ADR Stage 1)

- **Issue:** https://github.com/Matysh/houseplan-card/issues/282
- **ADR:** [`docs/adr/282-wall-geometry-representation.md`](../adr/282-wall-geometry-representation.md)
- **Статус:** принято независимым ревью; Stage 1 реализован и проверен
- **Тип / приоритет:** tech-debt / P1
- **Поставляемый этап:** Stage 1 — stored identity
- **Целевая версия модели:** `PLAN_MODEL_VERSION = 8`
- **Пользовательское изменение:** да, но без нового интерфейса

## 1. Сценарий

**Персона:** администратор дома из `docs/SCOPE.md`, который уже построил план и
поддерживает его в Plan editor на desktop. **Момент:** Resize, Split, Merge,
изменение толщины, размещение проёма, импорт либо Optimize меняют геометрию
существующего плана. View, kiosk и touch-потребители затем должны увидеть тот же
дом без пропавшей толщины, переехавшего проёма или нового шва.

Задача обслуживает J6: «Keep the plan true as the home evolves». Это не новая
возможность рисования, а устранение причины, по которой уже сохранённая стена
теряет смысл после дальнейшего редактирования.

## 2. Что человек увидит до и после

**До:** после сложного изменения внешне та же стена иногда теряет толщину,
получает толщину соседнего участка либо отделяется от своего проёма. **После:**
та же операция сохраняет принадлежность толщины и проёмов стене; внешний вид и
состав кнопок не меняются.

Единственное новое видимое состояние — честный отказ от структурной записи,
если старый план невозможно преобразовать без потери данных. View продолжает
работать по compatibility reader; диалог/тост называет причину, предлагает
сначала запустить «Оптимизировать планы», а при повторном отказе — исправить
конфликтующую геометрию стен.

## 3. Проблема и подтверждённая причина

Сегодня contour wall одновременно является:

1. ребром `rooms[].poly`;
2. разреженной записью толщины `space.walls[]`, найденной по вычисленному
   `wallKey` (квантованные midpoint + angle);
3. пространственно найденным носителем room opening без сохранённой ссылки.

Геометрическая операция обязана заново вывести все три связи. Пропущенный или
слегка отличающийся re-key теряет толщину (#253/#258); частичное совпадение
создаёт неоднозначную роль (#299); Split/Resize вынуждены материализовать и
переименовывать атомы до изменения контура. Канонизация координат #291 убрала
битовый noise, но не устранила вывод идентичности из изменяемой геометрии.

Independent `partitions[]` уже имеют стабильный `id`, а hosted openings уже
ссылаются на него. Stage 1 переносит этот доказанный принцип на contour walls и
на незавершённые draft segments. Renderer и вычисление junction geometry пока
не переписываются: они получают compatibility projection из новой модели.

## 4. Скоуп

В задачу входят:

- стабильный persisted `id` каждого атомарного contour segment;
- ссылки комнат на эти ID в порядке обхода контура;
- толщина на самом segment record, включая отсутствие физического тела;
- стабильные ID draft segments; существующие partition IDs сохраняются;
- wall-host для door/window/gate/passage на contour segment;
- детерминированная v7 → v8 миграция и runtime-проекция без записи на read;
- единый identity writer/barrier для Resize, Split, Merge, Delete, draw/close,
  thickness, opening placement, Optimize, Undo/recovery и import/export;
- compatibility projection `rooms[].poly`, `walls[]`, legacy unhosted openings;
- backend validation, limits, import remap и fail-closed stale-client policy;
- unit/backend/invariant/mutation/smoke/golden/performance evidence;
- обновление канонической документации и обоих changelog.

## 5. Не-скоуп

- integer node indices и новый `STORAGE_VERSION` (ADR Stage 2);
- отказ от `rooms[].poly` как compatibility projection (Stage 3);
- единый persisted planar graph для room walls и partitions (Stage 3);
- closed-form junction renderer и удаление polygon booleans (Stage 4);
- новый UI, изменение жестов, новые инструменты или иная геометрия результата;
- исправление видимого дефекта конкретного junction, не вызванного identity;
- индивидуальная настройка ID либо их показ пользователю;
- автоматическое притягивание authored off-grid geometry;
- удаление legacy reader в этом релизе.

Stages 2–4 требуют отдельных issues и поставляются независимо. Закрытие #282
после Stage 1 означает завершение текущего исполнимого этапа ADR, а не отмену
оставшегося направления.

## 6. Целевая persisted-модель

### 6.1 Contour segments

В пространство добавляется полный каталог атомарных contour walls:

```ts
interface StoredWallSegment {
  id: string;        // stable, unique inside one space
  a: [number, number];
  b: [number, number];
  cm: number;        // 0..100; 0 = axis without a physical body
}

interface RoomCfg {
  poly: number[][];  // required compatibility projection in v8
  wall_ids: string[]; // one id for every consecutive poly edge
}

interface SpaceCfg {
  wall_segments: StoredWallSegment[];
  walls?: LegacyWallEntry[]; // generated compatibility projection
}
```

`wall_segments[]` содержит **каждый** атом contour, а не только участок с
положительной толщиной. В v8 `wall_segments[].id/a/b/cm` и
`rooms[].wall_ids[]` являются authoritative для identity и толщины.

`rooms[].poly` остаётся authoritative для формы комнаты до ADR Stage 3, но в
v8 его стороны и `wall_ids` обязаны образовывать exact согласованную пару:

- `wall_ids.length === poly.length`;
- segment с соответствующим ID совпадает с ребром `poly[i] → poly[i+1]` в
  прямом либо обратном направлении;
- один ID может ссылаться из одной комнаты (`outer`) или двух комнат (`shared`);
- ссылка из трёх и более комнат, orphan segment либо дублированный ID невалидны;
- shared segment обязан иметь одни exact endpoints и один `cm` для владельцев.

Если общий участок занимает только часть длинной стороны комнаты, миграция
добавляет коллинеарные vertices и делит сторону на атомы. Площадь, winding,
silhouette и видимый SVG при этом не меняются.

### 6.2 Толщина 0

`cm: 0` в catalog означает действующее сегодняшнее состояние «контур есть,
физического wall body нет». Это техническое представление полной модели, а не
пользовательская возможность issue #306:

- Plan UI в #282 по-прежнему предлагает прежний диапазон и инструменты;
- legacy sparse interval без `walls[]` мигрирует в segment `cm: 0`;
- virtual/open boundary продолжает определяться `open_spans/open_to`, а не
  одним `cm: 0`;
- body/area/opening/light semantics остаются byte/geometry-equivalent v7.

Разрешение пользователю рисовать zero-thickness walls и отказ от virtual walls
остаются в приостановленном #306 и не входят скрытым изменением сюда.

### 6.3 Independent walls и drafts

`partitions[].id` уже является стабильной identity и не мигрирует в новый
catalog до Stage 3. Его endpoints/cm остаются на partition record.

Каждая `room_drafts[].segments[]` получает `id`:

```ts
segments: Array<{ id: string; cm: number }>
```

ID сохраняется при продолжении/перемещении draft. При превращении draft в
partition либо contour соответствующий segment наследует ID, если его carrier
не был разделён. При split действуют lineage-правила §8.

### 6.4 Openings

Host становится tagged union:

```ts
type OpeningHost =
  | { kind: 'partition'; id: string; t: number }
  | { kind: 'wall'; id: string; t: number };
```

Новые room openings всегда сохраняют wall host. `t` направлен от stored `a` к
`b`; визуальный flip/створка от направления segment не зависят. Legacy opening
без host остаётся читаемым и получает runtime host spatial resolver. На первой
структурной записи host материализуется только при единственном доказанном
carrier; неоднозначность блокирует миграцию, а не выбирает ближайший наугад.

### 6.5 Compatibility projection `walls[]`

`walls[]` временно остаётся persisted projection для старых клиентов и
неизменённого renderer:

- генерируется централизованно из `wall_segments` (положительные `cm`, exact
  `a/b`, вычисленный compatibility `key`);
- не является source of truth в v8;
- v8 backend проверяет его semantic parity с catalog, но key drift сам по себе
  не делает catalog невалидным;
- новый frontend никогда не присваивает `walls[]` напрямую;
- runtime geometry получает прежний `WallEntry[]` через один adapter;
- в v7 отсутствие catalog сохраняет нынешний reader без записи.

Re-key остаётся только деталью compatibility serializer. Ни Resize, ни Split,
ни business logic не используют key как identity после v8 migration.

## 7. Атомизация и deterministic migration v7 → v8

### 7.1 Breakpoints

До вычисления breakpoint в том же local candidate и до любых v8 ID/ref
запускается существующий write-barrier #291 `canonicalizeConfigGeometry`.
Порог и правило принадлежат только ему: текущий `LATTICE_NOISE_STEPS = 1e-4`
шага сетки. Все слова `exact` ниже означают побитовое равенство **уже
канонизированных** координат; дополнительный wall-thickness epsilon и третий
допуск Stage 1 не вводит. Если канонизация или последующая атомизация
отклоняет candidate, исходный v7 document остаётся byte-equivalent.

Каждая room boundary разбивается в точках:

- vertices всех room polygons;
- начала/концы коллинеарного overlap другой комнаты;
- exact `walls[].a/b` и доказанные границы key-only legacy record;
- `open_spans` и доказанные shared `open_to` spans;
- пересечения с structural nodes, уже используемые текущим wall profile.

Opening edges не делят segment сами по себе: opening хранит `t` и ширину.
Нулевая длина, self-overlap, конфликтующие positive thickness records либо
неоднозначный key-only carrier блокируют миграцию всего пространства.

### 7.2 Толщина

Для каждого атома выбирается ровно действующий v7 resolver:

1. exact matching `walls[].a/b`;
2. exact covering record;
3. legacy key/midpoint fallback;
4. отсутствие записи → `cm: 0`.

Разные positive candidates на одном атоме — blocker, не `min/max/last wins`.
Open boundary не удаляет segment и не меняет `cm`; light/body projection
применяет open cut отдельно, как до миграции.

### 7.3 ID migration

Первоначальный ID детерминирован для повторяемой миграции одного v7 document:

```text
wall-<base32(sha256(space-id | canonical-a | canonical-b | sorted-owner-ids))[0:20]>
```

Endpoint order не влияет на hash. Collision после усечения разрешается
детерминированным `-2`, `-3` после сортировки полной digest; collision полного
digest либо duplicate resulting ID блокирует миграцию.

Это **только seed миграции**. После сохранения ID никогда не вычисляется заново
из geometry. Новые IDs создаёт один monotonic/random id factory с проверкой
уникальности в space; импорт использует общий bounded remapper.

### 7.4 Момент миграции

Read-only загрузка v7 не пишет Store и не повышает model version. Runtime строит
immutable projected catalog для View и editor selection.

Атомарная v8 materialization выполняется:

- перед первой успешной structural config mutation пространства;
- явным Optimize plans;
- при добавлении v7 space в уже v8 config;
- при full/space import candidate, если target требует v8.

Изменение только настроек устройства/пространства, layout marker position или
View state не мигрирует wall model. Успешная materialization записывает catalog,
room refs, hosted openings, compatibility projection и `model_version: 8` одной
config transaction/Undo command. Ошибка оставляет candidate byte-equivalent.

## 8. Identity lineage при операциях

ID сохраняется, когда физический/топологический carrier остаётся тем же объектом,
даже если изменились endpoints, angle, length, owner или compatibility key.

### 8.1 Move и Resize

- whole segment, перенесённый/растянутый одной доказанной операцией, сохраняет ID;
- shared segment, одинаково преобразованный обоими owners, остаётся одним ID;
- несовместимые transforms owners отклоняются preflight;
- изменение только endpoints никогда не создаёт новый ID.

### 8.2 Split одного segment

При появлении breakpoint исходный ID получает ровно один child:

1. child, содержащий старый midpoint внутри;
2. при midpoint на новой границе — child, содержащий canonical old `a`;
3. остальные children получают новые IDs в геометрическом порядке от old `a`.

Openings rehost по их physical centre/interval и получают пересчитанный `t`.
Opening, пересекающий новую границу между children с разными условиями,
блокирует операцию до записи.

### 8.3 Merge segments

Слияние разрешено только для коллинеарных соседей с одинаковыми `cm`, owner set,
open-boundary role и без semantic breakpoint. Survivor ID выбирается:

1. segment с большим количеством существующих opening hosts;
2. затем самый длинный;
3. затем лексикографически меньший ID.

Все refs/hosts переводятся на survivor с пересчитанным `t`. Остальные IDs
исчезают; tombstone не хранится, поскольку Undo содержит полный snapshot.

### 8.4 Split/Merge/Delete rooms

- смена outer ↔ shared сама по себе ID не меняет;
- segment, остающийся на границе хотя бы одной surviving room, сохраняется;
- полностью удалённый carrier удаляется только в уже подтверждённом user flow;
- Keep walls переводит contour segment в partition с тем же ID, если ID не
  конфликтует с существующим partition;
- обратное включение unambiguous partition в contour сохраняет ID.

### 8.5 Draft close/cancel

Сохранённый draft segment сохраняет ID между сессиями. Незавершённый in-memory
rubber band ID не получает. Cancel не расходует persisted ID. Закрытие room
переносит IDs; atomization применяет §8.2.

### 8.6 Undo/Redo и concurrency

Undo/Redo восстанавливает exact snapshots с теми же IDs. Config revision guard
проверяется до lineage calculation и ещё раз при commit; stale revision не
может частично сохранить catalog. Concurrent edit получает обычный conflict и
перезагружает authoritative snapshot.

## 9. Writers и единый identity barrier

Новый pure-модуль (рабочее имя `src/wall-segment-model.ts`) владеет:

- v7 projection/migration;
- validation/parity;
- compatibility `walls[]` projection;
- ID lineage split/merge/rehost;
- persisted/runtime fingerprints.

Каждая structural mutation работает над local candidate, сначала пропускает
его через `canonicalizeConfigGeometry` #291, затем через
`commitWallSegmentModel(candidate)` и только после этого достигает
`_commitPhysicalGeometry`/backend write. Канонизация и identity migration входят
в одну атомарную commit-транзакцию; результат первой является единственным
координатным input второй.
Source guard перечисляет все structural writer entrances и падает, если новый
путь записывает `rooms.poly`, `walls`, `wall_segments`, `partitions`, drafts или
architectural openings мимо barrier.

Запрещено исправлять задачу добавлением ID assignments в десятки обработчиков.
Локальные контроллеры могут передать lineage hint, но один barrier доказывает и
пересобирает согласованную модель.

Backend mirror проверяет:

- schema bounds/unique IDs/references;
- geometry/ref/parity invariants;
- v8 catalog ↔ compatibility projection;
- wall/partition opening host and `t` fit;
- отсутствие direct Store writer bypass.

Backend не придумывает lineage для валидного v8 candidate; он либо принимает
его целиком, либо отклоняет.

## 10. Старые клиенты и совместимость

### 10.1 v7 data на новом клиенте

View/read работает через runtime projection. Первая structural write предлагает
тот же operation вместе с migration; успех атомарный. Export до migration
сохраняет фактический v7 document, не штампует v8.

### 10.2 v8 data на старом клиенте

Старый клиент может сохранить неизвестные поля, но не способен согласованно
обновить refs/catalog. Backend обнаруживает изменение structural projection без
соответствующего v8 catalog и отклоняет весь config write кодом
`wall_model_client_outdated`. UI нового клиента локализует его как требование
обновить/перезагрузить карточку. View/read старого клиента может использовать
compatibility `poly/walls`; безопасное редактирование старым клиентом не
обещается.

### 10.3 Import/export/duplicate

- full replace v8 сохраняет IDs после полной validation;
- space import и duplicate remap every wall/draft/partition ID and all
  `wall_ids`/opening hosts одним lineage table;
- collision с target никогда не resolve-ится геометрическим совпадением;
- v7 import в v7 target сохраняется v7; в v8 target материализуется до merge;
- plan-only export/import включает catalog/refs/hosts и не оставляет dangling IDs;
- future unknown fields сохраняются на record/room/space как сейчас;
- future model version отклоняется до migration.

### 10.4 Configuration lifecycle

`wall_segments`, `rooms[].wall_ids`, `room_drafts[].segments[].id` и wall host
регистрируются в `scripts/config-field-registry.mjs` как current v8. `walls.key`
и unhosted room openings получают documented compatibility statuses, но reader
удаляется только отдельной задачей после окна поддержки.

## 11. UX, accessibility, touch и security

- кнопки, поля, значения толщины и pointer gestures не меняются;
- View/kiosk output и actions не меняются;
- hover/hit-test/selection используют ID internally, но показывают прежние ink;
- editor остаётся desktop-first; touch View acceptance блокирующий;
- screen reader/keyboard contract не расширяется;
- ID никогда не показываются в обычном UI и не попадают в toast/telemetry;
- новые HA service calls, URL/HTML или permission boundaries отсутствуют;
- failure UI не раскрывает geometry/config data, только локализованный класс
  blocker и действие пользователя.

## 12. i18n

Новые RU/EN ключи (точное имя можно привести к namespace проекта):

| Key | RU | EN |
|---|---|---|
| `toast.wall_model_migration_blocked` | `Не удалось обновить модель стен: {reason}. План не изменён. Запустите «Оптимизировать планы»; если ошибка повторится, исправьте конфликтующую геометрию стен.` | `The wall model could not be updated: {reason}. The plan was not changed. Run “Optimize plans”; if the error repeats, fix the conflicting wall geometry.` |
| `toast.wall_model_client_outdated` | `Обновите карточку и перезагрузите страницу перед редактированием плана.` | `Update the card and reload the page before editing the plan.` |
| `gs.wall_segments_migrated` | `Стабилизировано сегментов стен: {n}.` | `Wall segments stabilised: {n}.` |

Reason names проходят через bounded enum и отдельные localized labels; raw IDs,
exception text и config values не интерполируются.

## 13. Лимиты и производительность

- catalog ограничен суммой допустимых room polygon sides после atomization;
  hard backend cap — `MAX_ROOMS × MAX_POLY_POINTS` (текущие 200 000), а общий
  import/export byte cap остаётся более строгим практическим ограничением;
- duplicate IDs, refs и parity проверяются O(V + E) через maps;
- spatial atomization migration допускает O(E log E), но не O(E²) на обычном
  payload; shared-axis grouping обязано иметь spatial/axis index;
- read/render tick не мигрирует и не хэширует полный config повторно;
- runtime projection и catalog fingerprint кэшируются по config revision;
- large-house structural render p95 и editor commit p95 не регрессируют более
  чем на 20% same-run baseline;
- migration 10 000 contour atoms укладывается в 500 ms p95 в Node benchmark и
  не создаёт второго полного deep clone сверх transaction snapshot;
- новые limits не отклоняют ни один валидный v7 fixture до попытки migration.

## 14. Критерии приёмки

### AC1. Детерминированная lossless migration

v7 fixtures с outer/shared/partial-overlap/T/X/diagonal/open span/key-only,
exact walls и lattice-noise по обе стороны порога #291 дважды дают
byte-equivalent v8 candidate. Шум внутри порога сначала канонизируется и не
создаёт micro-segments; координата вне порога не схлопывается молча. Polygon
area, winding, wall-body path, clean floor, opening projection, Glow/sun
barriers и isometric geometry до/после равны по существующим строгим/golden
контрактам.

**Доказательство:** TS migration unit matrix + golden/static path comparison +
backend fixture parity.

### AC2. Полный и валидный catalog

Для каждого v8 space все contour atoms имеют unique stable ID; каждая poly side
имеет ровно один wall ref; owner count 1/2; orphan/dangling/duplicate/third-owner,
zero-length и conflicting thickness отклоняются. Positive legacy thickness и
thin contour сохраняют прежний вид.

**Доказательство:** frontend/backend shared valid+invalid JSON fixture.

### AC3. Identity не зависит от geometry после migration

Move/Resize/angle/length/key change whole segment сохраняют ID. Мутант,
перевычисляющий ID из endpoints после каждого commit, убивается тестом.

**Доказательство:** pure lineage tests + Resize browser smoke.

### AC4. Split/merge lineage

Split выбирает survivor по midpoint/old-a; merge — по hosts/length/id. Room refs
и hosted opening `t` обновляются атомарно. Повторение операции после Undo/Redo
возвращает exact те же IDs.

**Доказательство:** parameterized unit tests для directions/ties/openings +
Split/Merge smoke.

### AC5. Все structural operations проходят barrier

Draw/close, wall thickness, opening placement/move/delete, Resize, Split, Merge,
room Delete/Keep walls, partition conversion, Optimize, Undo/Redo/recovery и
import вызывают один identity barrier. Direct assignments не могут попасть в
persisted write.

**Доказательство:** executable source/AST guard + bypass mutant для каждого
writer family.

### AC6. Room openings hosted

Новый room opening всегда имеет `{kind:'wall', id, t}`. Legacy unique carrier
материализуется; ambiguous/missing/intersecting split блокирует transaction.
Door/window/gate/passage, flip, contact/lock и Glow tunnel не меняются.

**Доказательство:** opening unit matrix + `smoke_opening_measure`/targeted host
smoke + backend schema tests.

### AC7. Compatibility projection

v8 → legacy `poly/walls/unhosted visual input` projection даёт текущим full,
static, hidden-isometric и light consumers прежние inputs. Runtime code не ищет
business identity через `wallKey`; key генерирует только adapter/compat layer.

**Доказательство:** source guard + projection snapshots + existing geometry
suite.

### AC8. Read-only и атомарный failure

Открытие v7 config, View, kiosk, navigation и device/layout-only save не пишут
catalog/model version. Structural migration blocker оставляет config/layout/rev
byte-equivalent и сохраняет работающий View.

**Доказательство:** store call-count tests + failure fixture + browser smoke.

### AC9. Старый клиент fail-closed

Попытка изменить v8 `poly/walls/openings` без согласованного catalog отклоняется
bounded error; ни один partial Store write не происходит. Byte-equivalent
round-trip старого клиента принимается.

**Доказательство:** backend old-client write tests.

### AC10. Import/export и ID remap

Full/space/plan-only export-import, duplicate and backup restore сохраняют либо
полностью remap-ят ID/ref/host graph. Collision, dangling ref и future model
отклоняются до apply; preview counts согласованы с candidate.

**Доказательство:** HA import/export harness + shared lineage fixture.

### AC11. Limits и unknown fields

Boundary cases catalog/draft IDs/refs проходят или fail atomically. Unknown
sibling fields на config/space/room/segment/opening survive migration and
round-trip. Atomization не truncates data ради лимита.

**Доказательство:** backend validation/property tests.

### AC12. Geometry regression floor

Все тесты #197/#224/#249/#253/#258/#261/#271–#280/#288–#302 остаются зелёными.
Точный ID не является поводом удалить существующую union isolation либо
ослабить geometry preflight.

**Доказательство:** `npm test`, model invariants, named wall smokes/goldens.

### AC13. View/touch parity

Desktop View, kiosk и phone/touch fixture визуально равны pre-migration baseline;
room/device/opening taps и pinch не получают editor behaviour.

**Доказательство:** targeted Playwright view/touch smoke + golden comparison.

### AC14. Performance

Выполнены budgets §13; migration не запускается на render/live HA tick.

**Доказательство:** same-run benchmark с machine-readable result.

### AC15. Optimize UX

Optimize preview отдельно сообщает количество materialized segment IDs. Cancel
— zero writes; Confirm — одна config transaction и одна Undo; второй run no-op.

**Доказательство:** optimizer unit test + targeted dialog smoke.

### AC16. Документация и compatibility registry

Обновлены `WALL-THICKNESS.md`, `ARCHITECTURE.md`, `CONFIG-COMPATIBILITY.md`,
`CANVAS.md`, user guides RU/EN, `TESTING.md`, ADR status и config-field registry.
Термины ID/catalog не попадают в пользовательскую инструкцию кроме объяснения
автоматического обновления старого плана.

**Доказательство:** docs/config audit gates.

### AC17. Gates

Перед code review зелёные:

- `npm run typecheck`;
- `npm test`;
- `npm run build` + `npm run bundle:sync` и bundle parity;
- native Windows pure-backend subset;
- named identity/Resize/Split/Merge/opening/import smokes из AC;
- model invariants, mutation gate, config audit и migration benchmark.

Полный Linux backend, all-smoke, golden и performance_smoke остаются точным-SHA
предрелизным gate по процессу.

## 15. План реализации

1. Ввести pure catalog types, deterministic migration и shared fixtures без
   подключения product writers.
2. Добавить backend schema/parity и model version, оставить read-only v7 path.
3. Подключить runtime compatibility projection; доказать render equivalence.
4. Перевести room wall selection/thickness/opening host на ID.
5. Подключить writer barrier и lineage hints по операциям, затем source guard.
6. Подключить import/export/duplicate/Undo/recovery и stale-client rejection.
7. Добавить Optimize preview/report, i18n, docs и changelog.
8. Прогнать fast gates, named smokes, build/sync; передать независимому reviewer.

Каждый промежуточный commit компилируется и не включает half-migrated writer в
default path. Feature flag в persisted config не добавляется: v8 включается
только фактом успешной materialization.

## 16. Риски и меры

| Риск | Мера |
|---|---|
| Catalog и poly расходятся | один commit barrier + backend parity + stale-client reject |
| Shared partial edge получает два ID | global atomization по axis/owners + shared fixture AC1/2 |
| Resize пересоздаёт ID | explicit lineage hints + AC3 mutant |
| Split теряет opening | deterministic child rule и physical rehost AC4/6 |
| Старый клиент портит v8 | compatibility projection для read, fail-closed structural write AC9 |
| Migration выбирает неверный key-only wall | текущий resolver без новых эвристик; ambiguity blocks |
| 200k theoretical edges дают freeze | indexed O(E log E), async preview boundary, benchmark/limits |
| Новый writer обходит model | executable source/AST guard AC5 |
| Новая identity используется для удаления старых geometry guards | explicit AC12 prohibition |
| #306 конфликтует с моделью `cm:0` | #282 не меняет UI/open-boundary semantics; #306 later rebases on catalog |

## 17. Откат

До первой v8 записи — чистый revert кода, данные v7 не менялись. После v8
materialization старый stable release может показать compatibility `poly/walls`,
но безопасное редактирование им не гарантируется.

Штатный rollback продукта:

1. отключить structural v8 writes, сохранив v8 read/projection;
2. выпустить follow-up reader hotfix;
3. не удалять catalog и IDs автоматически;
4. восстановить pre-migration config только из обычного backup/Undo,
   инициированного пользователем.

Автоматический downgrade v8 → v7 запрещён: он теряет hosted wall identity и
может неоднозначно схлопнуть атомы. Revert implementation-коммита без v8 reader
после публикации также запрещён.

## 18. Release-артефакты

- implementation commit: `Issue: #282`, `User-Visible: yes`;
- оба changelog со ссылкой на #282 и формулировкой про устойчивое редактирование,
  без обещания нового UI;
- generated bundle snapshots синхронизированы;
- новые golden baselines принимаются только при реальной visual delta и только
  из полного Linux artifact по процессу;
- beta/RC обязательна до stable;
- issue закрывается только после успешного beta gate на exact SHA.

## 19. Принятые технические предположения (оспоримы ревьюером)

1. Stage 1 поставляется в #282; Stages 2–4 получают отдельные issues.
2. `wall_segments + room.wall_ids` — canonical identity/thickness, а `poly` и
   generated `walls[]` временно остаются compatibility projection до Stage 3.
3. Independent partitions не переносятся в catalog: их ID уже stable. Draft
   segment IDs добавляются, потому что draft переживает сессию и конвертируется.
4. `cm:0` нужен для полного catalog, но не открывает пользователю функционал
   #306 и не заменяет `open_spans/open_to` этой задачей.
5. Migration выполняется lazy on structural write/Optimize, не на read и не на
   device/layout-only save; внутри одной транзакции она всегда получает
   candidate после `canonicalizeConfigGeometry` #291 с его порогом `1e-4` шага.
6. Старый client может читать projection, но structural writes в v8 fail-closed.
7. Deterministic hash используется только для первоначальной migration; после
   неё geometry никогда не определяет ID.
8. Existing wall renderer и junction algorithms получают adapter projection и
   не переписываются до ADR Stage 4.