The contract named benchmark and golden tooling, which is exactly why the smoke
launcher was allowed to skip the check for so long. It now covers every browser
check, names where each one gets it, and records why a stale bundle is worse
than a plain failure: part of the assertions go red and part stay green.
Issue: #236
User-Visible: no
Golden runs, benchmarks and documentation captures each called
assertFreshDemoBundle; the smoke launcher never did, so all ~128 smokes could
silently test a stale demo/srv/assets bundle. On #234 that cost a round of
analysis: three assertions went red and a fourth went green, because the old
code was wrong in two places that agreed with each other, and a mixed result
reads as a logic defect rather than a stale artefact.
launch() now runs the check once for every smoke, against the repository root
rather than the serving root — demo/srv has no src/** to fingerprint.
HP_ALLOW_STALE_BUNDLE=1 skips it for debugging and warns out loud, because a
guard that says nothing when it steps aside is the silent success this project
keeps removing. A mutation entry proves the call cannot quietly disappear.
Issue: #236
User-Visible: no
Golden runs, benchmarks and documentation captures each called
assertFreshDemoBundle; the smoke launcher never did, so all ~128 smokes could
silently test a stale demo/srv/assets bundle. On #234 that cost a round of
analysis: three assertions went red and a fourth went green, because the old
code was wrong in two places that agreed with each other, and a mixed result
reads as a logic defect rather than a stale artefact.
launch() now runs the check once for every smoke, against the repository root
rather than the serving root — demo/srv has no src/** to fingerprint.
HP_ALLOW_STALE_BUNDLE=1 skips it for debugging and warns out loud, because a
guard that says nothing when it steps aside is the silent success this project
keeps removing. A mutation entry proves the call cannot quietly disappear.
Issue: #236
User-Visible: no
Golden runs, benchmarks and documentation captures each called
assertFreshDemoBundle; the smoke launcher never did, so all ~128 smokes could
silently test a stale demo/srv/assets bundle. On #234 that cost a round of
analysis: three assertions went red and a fourth went green, because the old
code was wrong in two places that agreed with each other, and a mixed result
reads as a logic defect rather than a stale artefact.
launch() now runs the check once for every smoke, against the repository root
rather than the serving root — demo/srv has no src/** to fingerprint.
HP_ALLOW_STALE_BUNDLE=1 skips it for debugging and warns out loud, because a
guard that says nothing when it steps aside is the silent success this project
keeps removing. A mutation entry proves the call cannot quietly disappear.
Issue: #236
User-Visible: no
Golden runs, benchmarks and documentation captures each called
assertFreshDemoBundle; the smoke launcher never did, so all ~128 smokes could
silently test a stale demo/srv/assets bundle. On #234 that cost a round of
analysis: three assertions went red and a fourth went green, because the old
code was wrong in two places that agreed with each other, and a mixed result
reads as a logic defect rather than a stale artefact.
launch() now runs the check once for every smoke, against the repository root
rather than the serving root — demo/srv has no src/** to fingerprint.
HP_ALLOW_STALE_BUNDLE=1 skips it for debugging and warns out loud, because a
guard that says nothing when it steps aside is the silent success this project
keeps removing. A mutation entry proves the call cannot quietly disappear.
Issue: #236
User-Visible: no
Golden runs, benchmarks and documentation captures each called
assertFreshDemoBundle; the smoke launcher never did, so all ~128 smokes could
silently test a stale demo/srv/assets bundle. On #234 that cost a round of
analysis: three assertions went red and a fourth went green, because the old
code was wrong in two places that agreed with each other, and a mixed result
reads as a logic defect rather than a stale artefact.
launch() now runs the check once for every smoke, against the repository root
rather than the serving root — demo/srv has no src/** to fingerprint.
HP_ALLOW_STALE_BUNDLE=1 skips it for debugging and warns out loud, because a
guard that says nothing when it steps aside is the silent success this project
keeps removing. A mutation entry proves the call cannot quietly disappear.
Issue: #236
User-Visible: no
The spec review found the i18n section missing outright — the analysis
comment claimed it was untouched, the document itself said nothing, and a
DoR section cannot be inferred from a comment. It now says so explicitly,
and adds that the absence of i18n files from the diff is part of the
contract rather than an accident.
The waived Low is closed too: the old wallChainSegments treated a recorded
zero as valid while the new contract requires strictly positive values, so
zero is now named in the AC1 examples instead of being derivable from the
prose.
Issue: #234
User-Visible: no
Гейт мутаций работает в изолированном `git worktree`, где `test-build/` не
существует: юнит-гвард, идущий сразу в `node --test`, падает с
`ERR_MODULE_NOT_FOUND` ещё на чистом прогоне — то есть не проверяет ничего, а
еженедельный прогон реестра останавливается на первом же таком мутанте и не
доходит до остальных. Соседние юнит-мутанты этого не допускают: их гвард
начинается с `npx tsc -p tsconfig.test.json && node scripts/fix-test-build.mjs`.
Четыре мутанта #230 теперь тоже.
Проверено штатным харнессом, а не вручную: `node scripts/mutation-gate.mjs
--id=<каждый>` — «поймано 1 из 1» для всех семи мутантов задачи, включая три
смоковых, которые и раньше работали.
Тем же дефектом страдают юнит-мутанты #220 и #229 — это чужой скоуп и предмет
[#235](https://github.com/Matysh/houseplan-card/issues/235); здесь не трогаю.
Issue: #230
User-Visible: no
Две сцены и только они: `large-house-zoom-040-dark` (шаг штриховки был 20
юнитов, стал 8) и `large-house-zoom-250-dark` (был 3.2, стал 8). Расхождение
осмотрено покадрово: меняется только плотность штриховки тел стен, колонн и
перегородок — геометрия, цвета, устройства и свет идентичны. Это прямое
следствие решения владельца §4.2 ТЗ, ради которого зумовая компенсация и
убиралась.
Принято `npm run golden:accept -- --reviewed`. `accept` переснимает весь набор,
поэтому пять сцен, разошедшихся на шуме рендера
(`isometric-large-warm-remount-dark`, `room-label-parity-plan-dark`,
`tray-medium-group-en`, `wall-junctions-plan-preview-light`,
`wall-junctions-plan-t-dark`), возвращены к прежним байтам вместе с их хэшами
в индексе: `verify` считал их совпадающими в пределах допуска, и принимать их
задача #230 права не имеет.
Baseline-Reviewed — прогон, где job `golden` прошёл на Linux ровно на этих
эталонах.
Issue: #230
User-Visible: no
Release: v1.67.0-beta.1
Baseline-Reviewed: https://github.com/Matysh/houseplan-card/actions/runs/32480753934
`edf1cca` принял два эталона внутри продуктового коммита, а по правилу
процесса коммит, трогающий `demo/golden/baselines/**`, обязан нести `Release:`
и `Baseline-Reviewed:`. Локально это не остановилось: в моём клоне не был
выставлен `core.hooksPath`, и `commit-msg` попросту не запускался — теперь хуки
установлены, проверено повторным прогоном скрипта вручную.
История не переписывается (AGENTS.md: «never rewrite published history to
satisfy trailers»): эталоны снимаются этим коммитом и возвращаются следующим,
уже с положенными трейлерами.
Issue: #230
User-Visible: no
Release: v1.67.0-beta.1
Baseline-Reviewed: https://github.com/Matysh/houseplan-card/actions/runs/32480753934
Одна и та же стена 15 см выглядела на планах с разным `cell_cm` по-разному:
шаг паттерна был константой в юнитах, а толщина стены переводится в юниты через
`cell_cm`, — значит число полос было пропорционально `1/cell_cm`. Разброс между
крайними масштабами достигал 25 раз, а при `cell_cm ≥ 10` в стену не попадало
и одной полосы: штриховка вырождалась в случайные штрихи или исчезала.
Шаг стал физической величиной: `wallHatchStepUnits(cellCm)` возвращает
`8 × (5 / cell_cm)` — это 9.6 см плана при любом масштабе сетки и ровно
исторические 8 юнитов при эталонном `cell_cm: 5`, так что старые планы не
двигаются. Толщина штриха следует за шагом, поэтому соотношение «штрих к
просвету» тоже перестало зависеть от масштаба.
Формула из описания issue (`cell_cm / 5`) не годилась: она увеличивает шаг там,
где стена и без того тонкая в юнитах, и разброс не исчезает, а растёт — 39
полос против 0.06 на краях диапазона. Множитель обратный; на эту ошибку
поставлен отдельный мутант `hatch-step-inverted`.
Зумовая компенсация `1/zoom` убрана по решению владельца (§4.2 ТЗ): стена,
которая меняет штриховку при зуме, — это тот же дефект, только по другой оси.
От каши на дальнем конце зума защищает второй порог `wallHatchNeedsSolid`
рядом с существующим `wallBodyNeedsSolid`; шаг клампится в [0.5, 80] юнитов,
чтобы патологический `cell_cm` не выродил паттерн.
Статический рендерер (`space-render.ts`) нёс собственную константу 8 и вообще
не знал про зум — то есть уже сегодня расходился с картой при любом зуме,
кроме единицы. Теперь оба читают шаг из одной функции; смок проверяет, что они
согласны между собой, а не только каждый сам с собой.
Два golden-эталона переснято осознанно (`golden:accept -- --reviewed`):
`large-house-zoom-040-dark` (шаг был 20 юнитов, стал 8) и
`large-house-zoom-250-dark` (был 3.2, стал 8). Расхождение осмотрено: меняется
только плотность штриховки тел стен, колонн и перегородок, геометрия и цвета
идентичны. Остальные 80 сцен не тронуты — `accept` переснимает весь набор, и
пять сцен, разошедшихся на шуме рендера, возвращены к прежним байтам вместе с
их хэшами в индексе.
Issue: #230
User-Visible: yes
Дефект High-1 был одинаковым в двух местах — и в живом рисовании, и в
«Оптимизировать планы», — потому что каждый вызывающий собирал геометрию
примыканий сам. Ревью r2 справедливо заметило, что и защита получилась
однобокой: юнит и мутант сторожили только оптимизатор, а путь карты — тот, где
дефект и был виден пользователю, — не сторожил никто. Заплатка в виде второго
мутанта-близнеца оставила бы причину на месте: два списка координат, которые
обязаны совпадать, но ничем не связаны.
Поэтому геометрия переехала в `spaceMergeGeometry(space, { excludeDraftId })`:
один источник комнат, колонн и концов черновиков, одни координаты, одно место,
где можно ошибиться. Оба вызывающих теперь строчка вызова.
Покрытие идёт за причиной, а не за симптомом: три юнита в
`test/wall-merge.test.mjs` проверяют масштаб полигонов (включая комнаты в форме
x/y/w/h и комнату без геометрии), исключение активного черновика и сам T-стык к
середине стороны комнаты. Мутанты `partition-merge-rescales-rooms` и
`chain-merge-sees-own-draft` перенацелены на общий модуль и теперь краснеют для
обоих путей сразу: 2 и 1 падение, проверено применением патча.
Сценарий с комнатой в смоке пробовал — не взлетел: рисование в комнату
поднимает `_offerWallFaces`, и цепочка не завершается штатно. Ломать смок под
тест не стал, юниты общего модуля покрывают оба пути честнее.
Issue: #229
User-Visible: no
**High-1.** Комнаты хранятся в тех же координатах, что и перегородки:
`roomPoly` отдаёт сырой полигон конфига. Обе обвязки делили его на `NORM_W`
ещё раз, комната уезжала в область ~0.0001, и `junctionAt` не находил ни
одного совпадения. Узел на T-стыке к середине стены комнаты — тот самый
случай, ради которого ТЗ прошло два раунда ревью, — молча исчезал.
Воспроизведено вызовом `optimizePlans`: `partitionsMerged === 1` там, где
ожидается 0.
**High-2.** Завершаемая цепочка к моменту слияния ещё лежит в `room_drafts`:
каждый клик персистит её через `_persistActiveDraftSegment`, а удаляется
черновик строкой ниже вызова слияния. Собственные концы цепочки считались
чужим примыканием, и стык с существующей стеной не срастался. Активный
черновик теперь исключается — ровно так же, как это делает
`plan-snap-overlay` (`activeDraftId`).
Дыры в тестах, которые это пропустили, закрыты по существу, а не заплаткой:
- `demo/smoke_wall_chain_merge.mjs` рисует продолжение реальными кликами через
`_markupClick`, а не присваиванием `_path`, — то есть исполняет тот путь, на
котором дефект и жил. Клики задаются в координатах плана и переводятся через
живой view box, иначе смок целится мимо только что нарисованной стены.
- `test/plan-optimizer.test.mjs` получил комнату с примыканием к середине
стороны: юниты модуля этого не ловили, потому что передают полигон уже в
согласованном масштабе, минуя обвязку.
- Мутанты `partition-merge-rescales-rooms` и `chain-merge-sees-own-draft`
сторожат оба места: проверены применением патча, 1 и 2 падения.
Issue: #229
User-Visible: no
`scripts/check-docs.mjs` держит скриншоты в соответствии с исходниками через
отпечаток `src/**`. Отпечаток был просрочен ещё до этой задачи — проверено
исполнением на чистом dev, — так что перезахват закрывает чужой долг заодно с
изменением, которое отпечаток всё равно бы сдвинуло. Содержательно кадры те
же: меняется только шум рендера.
Issue: #229
User-Visible: no
Рисование прямой стены в несколько кликов оставляло по записи на каждый
отрезок. Швы невидимы, пока их не тронешь: выделение хватает кусок,
перетаскивание ломает стену пополам, толщина задаётся пофрагментно. У стен
комнат этого давно нет — `normalizeWallIntervals` схлопывает каждый сплошной
участок одной толщины. Независимые перегородки жили по другому правилу.
Новый чистый модуль `src/wall-merge.ts` даёт им то же правило:
- `mergeCollinearPartitions` сращивает соседей одинаковой толщины и
направления до неподвижной точки, но только там, где узел никому не нужен.
Узел остаётся, если в него приходит третья перегородка, стена комнаты
(стороной, а не только вершиной), колонна или конец сохранённого черновика.
- Направление выжившей записи канонизируется лексикографически: иначе одна и
та же физическая стена выходила то a→b, то b→a в зависимости от порядка
входа, и каждый host.t вдоль неё переворачивался вместе с ней.
- `applyOpeningMoves` переносит проёмы на выжившую запись: и авторитетный
`host`, и legacy-проекцию `x/y/angle`, которую рисует старый читатель
конфига (docs/CONFIG-COMPATIBILITY.md, #132). Проекция здесь не кэш —
канонизация направления разворачивает угол на 180°.
Рисование сращивает только свою цепочку и то, чего она коснулась (§8.6 ТЗ):
молча править чужие швы в стороне оно не вправе — для этого есть
«Оптимизировать планы» с предпросмотром, отчётом и отменой. Оптимизация
проходит по всему пространству без seed-ограничения и отдельной строкой
сообщает, сколько записей исчезло.
Issue: #229
User-Visible: yes
The tolerance fix in r2 named the room's nearest polygon vertex as the point
of contact, which silently excluded the T-junction — a partition meeting the
middle of a room wall. That is a documented product case (141-wall-junctions
§13.1) and the code already measures distance to the edge, not the vertex
(distToSegment over roomEdges). Merging would have run straight through a
legitimate node.
AC2 now proves the room case with a T-junction into the middle of a long
side, and a mutant restores the vertex-only search.
Issue: #229
User-Visible: no
M1: "merge across the whole space when a chain ends" quietly overreached the
owner's split — drawing fixes its own seam, the optimiser fixes what has piled
up, and only the latter comes with a report and an undo. Section 8.6 now scopes
it to the connected component the new chain belongs to.
M2: the tolerance for "something else meets here" was only defined for a
partition-to-partition joint. Room edges, columns and drafts now use the same
EPS_JOIN — a gap cannot be a junction in one case and not in another.
M3: an opening also carries a materialised x/y/angle projection that
CONFIG-COMPATIBILITY (#132) requires to stay in step with its host, and the
code already re-materialises it after every host change. Merging is such a
change; AC3 now fails if only host.t is recomputed and the projection goes
stale.
Issue: #229
User-Visible: no
Written on the owner's decisions of 2026-08-21: merge as the chain is
finished, sweep already-drawn plans from "Optimise plans", and keep merging
even when an opening sits on the seam.
The part that is easy to miss is that last one. An opening stores its
position as a fraction of its host's length, so merging two partitions
changes the length under it and moves the door unless the fraction is
recomputed. AC3 therefore checks the door's coordinates in plan units, not
that a field was rewritten.
Issue: #229
User-Visible: no
Three code-review rounds on #220 published a verdict and then failed the
run: the document never reached the branch, so the #171 guard refused
before the label step and neither the merge nor S8-merged happened. The
cause was structural. The document lived as an untracked file inside the
very checkout the reviewer edits while proving that a test can fail, and
restoring that tree — git checkout, git clean — deletes an untracked file.
Spec rounds survived only because they never mutate anything.
The reviewer now writes to REVIEW_DOC under RUNNER_TEMP, outside the
repository, and the publish step copies it into docs/reviews before
committing. Tree cleanup can no longer destroy the artefact, and the
reviewer no longer needs to touch docs/reviews at all.
Verified against a local git fixture on five paths: document outside the
repo with a mutated tree, nothing anywhere (loud failure), document only in
the working copy, document already committed by the reviewer, and a branch
that moved during the review.
Same file as main, byte for byte.
Issue: #220
User-Visible: no
Review CODE-REVIEW-220-r2/r3, F1.
The M1 fix installs window listeners for the length of the gesture, and
disconnectedCallback — which takes down everything else, down to the other
local gesture — did not take those down. Losing the card mid-drag (Lovelace
rebuilding its tree, the user leaving the view with the button still down)
left them alive: the closure holds the instance and its config, and the next
pointerup anywhere on the page would have an invisible card write its order.
The smoke now holds a tab, removes the card, and checks that the release it
should no longer hear changes nothing. Registered as a mutant too.
Issue: #220
User-Visible: no
Review CODE-REVIEW-220-r1.
H1: markersNeedingPlacement decided who depends on the order by reading
marker.area alone, while resolveExplicitMarkerPlacement reads
`marker.area || <area of the HA device>`. The ordinary marker — bind an HA
device, store neither field — is anchored by the registry and never depended
on the order, yet it was being written a space it never asked for. Dormant
today, and the day that HA area changes it moves the marker to whatever space
used to be first. The resolver now asks for the area actually in force.
M1: a mouse released past the panel left the gesture stuck, swallowing the
next click. Pointer capture is the usual answer and is now taken, but it is
not a guarantee — the browser grants it only for a live pointer. The window
listener is what actually closes the gesture.
M2: the fifth mutant from the spec is registered, plus a sixth for the stuck
drag above.
Writing the smoke for M1 turned up why the first attempt passed against
broken code: synthetic PointerEvents default to composed:false and never
leave the shadow root, so nothing outside the panel could ever hear them.
Real pointer events are composed; the smoke now says so.
Issue: #220
User-Visible: no
The order of config.spaces used to be whatever order the spaces were created
in, and there was no way back other than deleting a space and drawing it
again.
The gesture is deliberately narrow — mouse, editors only. The same tabs are
the primary way to switch spaces in View, where touch is first class, so a
drag there would compete with the tap that switches. Recorded in the spec as
"Touch editor: not exposed".
The part that needed care is not the drag. Position in the array feeds three
things: the marker placement fallback, the swipe neighbour and a positional
`floor`. So the write that stores the new order also writes down the
placement that used to depend on it: a marker with neither an explicit space
nor an area that names one gets the space it has right now. Both changes go in
one save; splitting them would leave a window in which markers move on their
own. The positional `floor` cannot be fixed from here, so the card says so
once.
Issue: #220
User-Visible: yes
Section 4 now says what the pipeline does: a cycle is a verdict with
blocking findings followed by a return to the author, so a green verdict
consumes nothing — the case that cost #225 an arbitration after a failed
merge forced a rebase and a third attempt.
The canon also separates the two quantities the verdict line carries. The
attempt number names the review document, because two runs sharing a
number would overwrite each other's artefact; the budget counts blocking
cycles only. That is why the document threshold in the process gate sits
above the cycle limit, and why the guard reports a recount of review-4
rather than removing the label itself.
Issue: #227
User-Visible: no
The pipeline punished what it prescribed: after a failed merge it tells the
author to rebase and restore S7-code-review, and that attempt finished the
budget. On #225 a green code review with green CI ended in review-4.
Only yellow and red verdicts spend the budget now; a green verdict returned
nothing and consumes nothing. Attempts and cycles became separate
quantities: the attempt number names the review document, the limit
compares blocking cycles. The exhaustion comment lists what it counted, and
the guard reports a recount instead of stripping review-4 on its own.
Same file as main (41325a8), byte for byte.
Issue: #227
User-Visible: no
The pipeline punished what it prescribed: after a failed merge it tells the
author to rebase and restore S7-code-review, and that attempt finished the
budget. On #225 (light track, limit 2) the sequence yellow, green, rebase
produced review-4 on a task whose code review was green and whose CI was
green, with no product change after the verdict — the owner had to
arbitrate work that was already accepted.
A cycle under section 4 is a verdict with blocking findings followed by a
return to the author, so only yellow and red verdicts spend the budget now.
A green verdict returned nothing and consumes nothing, which also removes
any need to mark rebase re-runs specially.
Attempts and cycles are now separate quantities. The attempt number keeps
naming the document, because two runs sharing a number would overwrite each
other's review artefact, while the limit compares blocking cycles only. The
exhaustion comment lists the verdicts it counted, and the guard no longer
strips review-4 — it reports the recount and leaves the decision with the
owner.
Rule 7 of the process gate follows: its document threshold rises above the
cycle limit, because legitimate attempts can exceed cycles and a threshold
equal to the limit would refuse the very rebase the pipeline demands.
Issue: #227
User-Visible: no
Matysh