The registry contract demanded that every guard name a `.mjs` file, which was
true until this task added the first backend mutant —
junction-limit-backend-raw-baseline is guarded by pytest, and the mutation-gate
job already installs it. My mistake: I ran `--check` and the single mutant
after adding it, but not the unit suite that owns the registry contract, so CI
caught what I should have.
The contract keeps its point: a guard must name a file that exists.
Issue: #329
User-Visible: no
AC10 was asserted, never shown. Optimize runs alignAllToGrid and
repairNearAxisRoomWalls, which move nodes by fractions of a centimetre, and
none of П1-П5 carries a margin wider than the grid step in general — so
"obviously true by construction" was not available.
Two units, both counting violations the way the write barrier does (each side
through commitWallSegmentModel first):
- the owner's fixture in legacy storage — the inherited apex is there before
Optimize, and no rule's count grows after;
- the П4 boundary — two rooms exactly 5 cm apart, where snapping could have
pulled a node under the limit, stay clean.
The first test asserts the baseline actually carries a violation, so it cannot
pass by measuring an empty plan; violationsByRule fails loudly if the space or
its catalogue goes missing, for the same reason. Spec revision 7 records the
proof and the other three review answers.
Issue: #329
User-Visible: no
The Russian guide carried the junction-limits section twice, word for word.
And both guides described Resize as silently stopping, in contrast to a toast
from drawing and Thickness — it stops AND names the rule once per gesture
(resize.limit_stopped, pinned by the smoke). Wording follows the code.
Issue: #329
User-Visible: no
002795f7 said "the clip helper and its cap plumbing are gone" while leaving
clipPolygonOutsideCap(), degenerateApexCaps() and the apexCaps ring field in
place — exported, uncalled and untested. They belong to the flat chamfer the
owner rejected; the apex now ends in one point on both faces, so the quads
have no caller and no meaning.
The orphaned JSDoc block that described degenerateApexCaps went with them, and
the wallBodiesGeometry documentation this change had earlier separated from
its function is reattached: the #329 constant and predicate now sit above it.
Golden verify stays green on the whole matrix, which is the evidence the
removed code was indeed dead.
Issue: #329
User-Visible: no
The limits read `wall_segments`, so a document older than the catalogue
reports no walls at all — and therefore no violations, whatever its geometry.
Comparing that raw baseline against a candidate the card had already migrated
counted every inherited violation as new, and a legacy plan could not take an
unrelated edit at all: renaming a room was refused with junction_limit_angle.
Spec §3 forbids exactly this, and the frontend had already learned the same
lesson in 4758767e; the backend mirror simply never got the second half.
validate_junction_limits now runs both documents through
commit_wall_segment_model before counting. A document that cannot be migrated
is not this validator's verdict — the wall-model barrier owns that error and
reports it with its own code — so it degrades to "no baseline to inherit".
The regression is pinned twice: a test that asserts the legacy baseline reads
clean raw and carries the apex once migrated, and the mutant
junction-limit-backend-raw-baseline. Both fixtures that exercise the barrier
were rebuilt as real documents (rooms plus walls), because the previous ones
put walls in wall_segments with no rooms and did not survive migration.
Issue: #329
User-Visible: no
The branch was rebased onto the extracted resize controller (#264), which
changes the source fingerprint the documentation screenshots are pinned to.
The images themselves are byte-identical — only the recorded fingerprint moves.
Issue: #329
User-Visible: no
Reviewed the candidate produced by the Linux CI job of run 33106626544 on
issue/329-junction-limits, where golden failed with exactly one line —
"missing-baseline sharp-apex-legacy-dark" — and accepted only that image. The
nine unrelated baselines whose bytes drifted in the same artifact were
restored to their reviewed versions, so this commit changes one picture.
Baseline-Reviewed: run 33106626544, job 98638432113 (Golden-кадры против принятых эталонов)
Release: v1.68.2
Issue: #329
User-Visible: no
custom_components/houseplan/junction_limits.py repeats П1-П4 for the write
barrier in websocket_api, counting per rule so an inherited violation still
round-trips, and raises JunctionLimitError with the stable code
junction_limit_<rule>.
П5 is deliberately not mirrored — it judges the rendered wall bodies, and a
second mitre/inset pipeline in Python would drift more dangerously than the
rule it guards. Optimize stays outside the check for the same reason migration
and import do: it repairs existing geometry.
test_parity_with_the_frontend_checks feeds identical fixtures to the TS
functions and to this module and demands the same verdict, so the two
implementations cannot silently diverge.
Issue: #329
User-Visible: no
The owner's spike room (≈9.9°, 15 cm walls) is extracted into
test/fixtures/329-sharp-apex.json and rendered on its own so a returning
trident, a flat chamfer or a jagged edge fails the pixel gate. Baseline
follows from the CI candidate, as the process requires.
Issue: #329
User-Visible: no
Measured what Resize itself already forbids: a room cannot be squeezed below
30 cm (two 15 cm walls), so П3 and П5 are unreachable through shrinking and
the gate merely fails closed there. П4 IS reachable on a fine grid, so the
smoke drags a real handle on a 2 cm grid: two rooms 10 cm apart, a 6 cm pull
would leave 4 cm between foreign nodes, the wall stops at 6 cm and exactly one
toast names the 5 cm rule.
Spec revision 6 records both the measurement and the two corrections it forces
on AC7a: a dimmed handle cannot express a per-step limit, and the plan is NOT
byte-unchanged — the allowed part of the gesture is a legitimate edit.
Issue: #329
User-Visible: no
П3 measures the WALL, not the catalogue atom: a short filler segment that
compensates a thickness step (owner's fixture, 5 cm = (30-20)/2) is a legal
continuation of a long same-thickness wall, so the rule walks the maximal
collinear run through the shared nodes before judging the length.
Resize stops at the last allowed position and names the broken rule instead
of the generic "geometry cannot be saved"; the Thickness dialog refuses
through its own toast. Both channels are pinned by demo/smoke_junction_limits
plus three mutants (angle threshold, write barrier, degenerate apex bevel).
Issue: #329
User-Visible: yes
Owner decision (chat, 2026-08-27): keep П3 and fix the smoke. A 10 cm island
room is a column, and columns have their own tool (wall_columns) — that was
the reasoning behind the limit in the first place. The island of the smoke is
now 25 cm, and a new case pins the contract: a 10 cm island is refused.
Issue: #329
User-Visible: no
Owner report: small serrations remained on the outer edges between the inner
and the outer vertex. Measured on the fixture ring: two ~4 cm steps plus four
micro-vertices at the tip. Their source was the inset contour's two-point
bevel folding into a bow-tie, and the earlier half-plane clip of that fold,
which left a 0.2 cm sliver the boolean union turned into steps. The inset now
ends in ITS own mitre point at a degenerate apex — mirroring the sharp outer
tip — so there is no fold to clip and no sliver to smear: the room ring is
exactly three vertices, every side longer than the half depth. The clip
helper and its cap plumbing are gone. The user-visible wording of this work
already stands in both changelogs from the #329 entry.
Issue: #329
User-Visible: no
The baseline for inheritance was the raw previous document, which for a
legacy space carries no wall catalogue at all — so every inherited short
segment of a real plan looked new and the resize smoke's legitimate write was
refused (executed: two 5 cm segments against their own 30 cm thickness).
Both sides now cross commitWallSegmentModel first, and inheritance is counted
per rule rather than per subject, because a structural write re-keys the
carriers it re-atomises.
Issue: #329
User-Visible: no
Owner correction (chat, 2026-08-27): no flat chamfer at the tip — a plain
sharp apex. Proven by execution on the issue fixture: the outset contour fell
back to a two-point bevel (the 4·h mitre limit against an 87 cm reach) while
the inset contour folded into a bow-tie, and subtracting that fold carved the
V-notches — together they made the trident. Now a degenerate corner (below 15
degrees, inner faces meeting inside both walls) contributes ONE outset point
at the plan's own vertex — no bevel, no metres-long mitre needle — and its
inset is clipped at the convergence line so no fold is subtracted. Plain and
merely sharp pairs keep the full mitre of #310. The write-side limits of
П1-П5 stop new plans from creating such corners at all.
Issue: #329
User-Visible: yes
The owner's five limits as pure functions: minimum 15 degrees between
neighbouring rays of a node (a straight wall through the node is a 180 pair,
not a violation), at most 6 walls per node, a segment at least
max(20 cm, its own thickness), 5 cm clearance between non-incident nodes and
between a node and a foreign wall (a T-joint sitting exactly on that wall is
incidence, not a near miss), and a room interior of at least 25 cm2 after the
masonry is subtracted. Thresholds are absolute and do not scale with cell_cm.
newViolations() implements the spec's inheritance boundary: only violations
introduced by the write are reported.
Issue: #329
User-Visible: no
The bundle embeds the source fingerprint, which covers package.json; the
release:notes script addition moved it, so the three bundle copies must be
rebuilt in the same change.
Issue: #328
User-Visible: no
A stable body aggregates the changelog since the previous STABLE release,
not since the last beta; in-beta-only bugfixes are excluded by the curator
(the draft lists every candidate with its source section); the small-fixes
filler line is legal only when the range carries user-visible work not
itemised in the body — a single-issue hotfix ships without it, and body
bullets must link their issues so the rule stays checkable.
scripts/release-notes.mjs prints the aggregation draft and verifies
docs/RELEASE-NOTES.md (npm run release:notes -- <tag> [--verify]); the
verifier rejects the v1.68.1-style empty filler by execution. STATUS.md
release mechanics updated in the same commit.
Issue: #328
User-Visible: no
Owner decision (chat, 2026-08-27): the running check's name must say what it
does, in Russian. Scripts locate workflows by file name (release-gate.mjs ->
validate.yml), so display names are free; job ids and needs are untouched.
The same content is cherry-picked to main because release workflows execute
from the default branch and process.yml must stay identical in main and dev.
Issue: #327
User-Visible: no
Revert of caf6e6c3. The owner's field report disproved the diagnosis: HACS
2.0.5 downloads zip_release assets fine, because async_download_file strips
the 'tags/' prefix from the composed URL before requesting (hacs/base.py) —
the prefix only survives in the error-log message, which prints the
unnormalized URL. The dacha installed every beta and v1.68.0 through HACS
with zip_release active. The observed 'Failed to download' was a transient
network failure fetching release-assets.githubusercontent.com (five retries
exhausted, one occurrence), not a routing bug.
Issue: #325
User-Visible: no
(cherry picked from commit 5ad0c1cdc3)
Revert of caf6e6c3. The owner's field report disproved the diagnosis: HACS
2.0.5 downloads zip_release assets fine, because async_download_file strips
the 'tags/' prefix from the composed URL before requesting (hacs/base.py) —
the prefix only survives in the error-log message, which prints the
unnormalized URL. The dacha installed every beta and v1.68.0 through HACS
with zip_release active. The observed 'Failed to download' was a transient
network failure fetching release-assets.githubusercontent.com (five retries
exhausted, one occurrence), not a routing bug.
Issue: #325
User-Visible: no
claude[bot]