946 Commits

Include renames

Author	SHA1	Message	Date
Matysh	706eb02d70	fix(led): polish glow and interactions (#784) ... Issue: #784 User-Visible: yes	2026-10-03 10:47:28 +03:00
Matysh	31b4ddda55	Release v1.79.0-beta.3 candidate ... Publish the three integrated S8 issues since beta.2. Synchronize all seven version sources, rebuild committed frontend assets, tighten ratchets to measured facts, and update release metadata for LED strips. Canonical documentation screenshots were reviewed from Linux CI and accepted in the preceding derived commit. Local checks: build/typecheck, bundle policy, bundle budgets, monolith checks and release-contract tests passed. Native-Windows unit run passed 3517 tests; two GNU-bash tests and one TypeScript diagnostic-shape test remain Linux-only. Full exact-SHA Validate is mandatory before publication. Release: v1.79.0-beta.3 Issue: #765 Issue: #780 Issue: #781 User-Visible: yes	2026-10-03 09:40:14 +03:00
Matysh	24671d4358	perf: снизить стоимость маски LED-лент (#780) ... Issue: #780 User-Visible: no	2026-10-03 00:10:28 +03:00
Matysh	6607a34973	perf: упростить SVG-поле LED-лент (#780) ... Issue: #780 User-Visible: no	2026-10-02 23:38:35 +03:00
Codex	a20ef2b9b0	chore(monolith): raise bundleBytes for the r1 LED fixes (#780) ... bundleBytes 2 667 879 → 2 670 566 (+2 687, over the 2 000 band): the value badge of a strip on the card and on the static card, the visibility gate before import(), the release of a card's LED caches on disconnect and the cache statistics of the lazy runtime/field chunks (r1 M1, M4, M5). The badge method moves below `_renderDevice`, outside the vacuum section the isometric contract reads. The review index is rebuilt after the rebase. Issue: #780 User-Visible: no	2026-10-02 20:58:11 +03:00
Codex	e447364636	perf(led): the led-strips-v1 profile proves caches, disconnect and a late import (#780) ... r1 M5: the runtime and field chunks release a card's frame and field cache on disconnect (ledRelease from disconnectedCallback), never cache for a disconnected card, and a chunk that lands after disconnect renders nothing (the card's LED hook is connected-only). The profile now reports the three caches of the shown space separately (shapes ≤ 50, visibility ≤ 50, retained per-emitter fans ≤ 2500) through the runtime's ledStats, asserts 0 retained entries and 0 live LED timers/frames/observers after every disconnect, judges the Long Tasks of a 100-step camera series as well as the interaction profile's camera scenario, runs one extra cold mount whose runtime response is held while the card is removed, and enforces ≥ 7 samples after ≥ 1 warm-up — also on reports merged from parts (--warmup-only, --merge). Issue: #780 User-Visible: no	2026-10-02 20:54:50 +03:00
Codex	b40e8ff58d	fix(led): badge at the anchor, room_id wins, chain stays in its space, hidden loads nothing (#780) ... r1 of the code review: - M1: a strip keeps its marker's value badge, passive, at the half-length anchor on the card and on the static card (no icon core, pulse or slot). - M2: one room resolver for the strip's Glow — an explicit valid room_id of the marker wins over the anchor room; a stale one falls back (stripRoom). - M3: the chain remembers the space it is drawn in; a space switch finishes it there, never in the space shown next, and opens no picker over it. - M4: visibility is decided before import(): a hidden marker or an HA-disabled device loads no LED chunk (ledVisible, also checks the stored marker so a just-hidden one does not slip through a stale device list). - M6: the static card is a full light_pools × live_states browser matrix. Unit tests for M2/M3, smokes for M1/M3/M4/M6, five registered mutants. Issue: #780 User-Visible: yes	2026-10-02 20:54:50 +03:00
Codex	5d3f29c249	fix(card): static «Show as LED strip» in the device dialog; demo icons (#780) ... The full Validate on a6c4001c found two things: - smoke_help_affordance: the device dialog shifted when the LED tool chunk arrived after it opened (the representation section appeared late). A device without a strip now gets the static section at once (label in the base dictionary); the press loads the tool, leaves the dialog through its own guard and starts drawing for the same marker. A strip's device still loads the tool with the dialog. The dialog alone no longer loads anything. - smoke_lazy_admin_locale counted nine namespace chunks (stale since the `tools` namespace); it now reads NAMESPACE_LOCALE_CHUNKS and accepts the editor's own `tools-de`. - demo/srv/assets/icons.js regenerated: the demo/golden ha-icon stub lacked mdi:led-strip-variant and mdi:link-variant(-off). Issue: #780 User-Visible: no	2026-10-02 20:54:50 +03:00
Codex	d515c42177	feat: LED strips — editor notes, docs, demo, smokes, golden scenes, profile (#780) ... Stage 5 of #780. - Import summary: «Strips left unbound after import: {n}» from the backend `unbound_led_strips` count; «Optimize plans» reports strips passing through walls per space and edits none (AC16). - Linear field for long strips (ТЗ §13.2): pieces of at most the radius along the polyline, emitters thinned to r/4, each piece clipped to the visibility fans of its own emitters as separate clipPath children (no boolean pass per piece), one floor clip for the whole layer, no fan at all where nothing blocks within the radius; a grid index of body faces and boxed inside tests; unchanged fields skip re-diffing. 50×50 on the large house: first stable frame ~1.4 s, warm space ~1.1 s locally. - led-strips-v1 profile: demo/benchmark_led_strips.mjs with the derived large-house fixture (10×5, 50×50, none), absolute limits of the ТЗ table in demo/performance/budgets-led-strips.json, exact counters (zero recomputes on HA ticks/camera/colour, ≤50 cache entries, no growth over 20 cycles); added to the full performance workflow. - Bundle: LAZY_LED_GZIP_CEILING 10 KiB, LAZY_LED_EDITOR_GZIP_CEILING 11 KiB (measured + 10 %, rounded up); overlaps with the initial and editor graphs refused; the lazy editor graph stays inside its ceiling. - Smokes smoke_led_strip_draw/bind/glow, linked in smoke-links; 13 mutants in the registry (7 browser guards in the inventory); config field registry entry `spaces[].led_strips`. - Golden: five new scenes on the `golden-led` space of the visual fixture (`ledStrips` option, the designer's four strips on #868D94), matrix v71. - Docs: LIGHT, DEVICE-PRESENTATION, USER-GUIDE (en/ru), UX-MODES, ARCHITECTURE, ISOMETRIC, CONFIG-COMPATIBILITY, TOUCH-SUPPORT, demo/stand README, performance README; docs/design/led-strips with the unchanged designer archive, two paired frames and ACCEPTANCE.md; both changelogs. Issue: #780 User-Visible: yes	2026-10-02 20:54:50 +03:00
Codex	d21fba11d6	feat(card): the LED strip tool in the Devices editor (#780) ... Stage 4 of #780 (ТЗ §4–§5). «LED strip» next to «Add» draws a chain with clean clicks only (pan, pinch, a second finger, cancel and the synthetic click after navigation add nothing), snaps to the grid and to physical wall faces / zero-wall axes, stops at the first face of masonry, partitions, columns and windows (doors, gates and passages are cut by geometry), Shift gives 45°. Ctrl+Z removes the chain's own point first, Esc finishes, a double click or a click on the first point (≥3 vertices) closes; fewer than two distinct points write nothing. A finished strip opens the device picker (lights first, taken markers explained, «New device…» binds in that dialog's own write, «Later» keeps unbound geometry). A selected strip shows its vertex handles (a drag re-checks both neighbours and the whole path) and a new Devices tray branch: device settings, bind/change, unbind, show as icon, delete. The device dialog gets the representation section: show as strip (restores a hidden shape at once or draws one for this marker, behind the dialog's own save/discard guard), show as icon, unbind/delete for a hidden shape. Every geometry or representation change is one optimistic write and one LED command of the device history; Undo/Redo restores only its own strip record and refuses when a newer change sits on it. A rebinding renames the link in the marker save, a deleted marker leaves an unbound strip, a bound marker may not move to another space. Plan/Background show strips as a passive translucent mark. The tool, its `led` dictionary (en static, ru/de/fr lazy) and placement geometry are a new lazy `led-strip-editor` chunk (9.5 KB gzip), loaded only on the tool, an editable strip in the shown space or a strip device's dialog. The initial graph gets the loader and delegation only (src/led-strip-card.ts); the lazy editor graph +122 B, inside its ceiling. Mutant anchors follow the moved code (marker dialog guard, static LED layer). Issue: #780 User-Visible: no	2026-10-02 20:54:50 +03:00
claude[bot]andCodex	ed238059e1	refactor(card): the LED linear field is its own lazy chunk (#780) ... ТЗ §13.1: the static card with light_pools:false must not load the linear field. led-strip-field.ts (2.1 KB gzip) is a dynamic import of the LED runtime (5.0 KB gzip), loaded only when a strip is on in a Glow room with a light scene, with the same fingerprint handshake and hashed-URL retry (manifest role led-field, retry token counted). Issue: #780 User-Visible: no	2026-10-02 20:54:50 +03:00
claude[bot]andCodex	8237bbc1cc	feat(card): LED strips in the 2.5D View (#780) ... Stage 3c of #780 (ТЗ §7). In the volumetric View the stripe is raised like a device tile: body lifted by ISO_TILE.lift (0.075 D), the edge swept ISO_TILE.depth (0.1 D) below it in isoEdgeColor, an inert blurred floor shadow from isoTileShadow for the current theme and floor; D takes the shared ISO_ICON_SCALE. The field stays on the floor plane, the hit path moves with the raised body, everything is in plan units so zoom cannot detach it. Editors and the static card keep Flat. Issue: #780 User-Visible: no	2026-10-02 20:54:49 +03:00
claude[bot]andCodex	05d62f053a	feat(card): LED strips on the static space card (#780) ... Stage 3b of #780 (ТЗ §8). houseplan-space-card draws a represented marker as a passive strip through the same lazy runtime: no icon, no auto slot, no round pool, no hit path, focus or actions. The stripe uses the drawn wall geometry for the face offset, so light_pools:false builds no barriers, visibility or timers; the linear field appears only with light_pools:true and Glow; with live_states:false the stripe is neutral. Strip points vote in the content frame. Probed in the demo: plain card — one passive stripe with the source-colour core, no field, no hit path; light_pools — the field. Issue: #780 User-Visible: no	2026-10-02 20:54:49 +03:00
claude[bot]andCodex	3a1cd7b1ad	feat(card): LED strips in View — lazy chunk, stripe, linear light (#780) ... Stage 3a of #780. - src/led-strip-gate.ts is the only initial-graph foothold (ТЗ §13.1): which markers a space shows as a strip (active and bound), the half-length anchor that replaces their icon position, and one page-wide load of the lazy led-strip-runtime chunk (fingerprint handshake, a hashed-URL retry on the next explicit entry, never in a loop). - The card: a represented marker takes no auto slot, draws no icon, casts no round pool and is placed at the anchor; two call sites render the stripe layer and the linear field from the chunk. The space model carries the stored strips untouched; scaling, validation and geometry are in the chunk. - src/led-strip-runtime.ts: the stripe is two strokes of one derived path (outline #383838 t, core t/2, round joins and caps, t = 0.08/0.12 D), white off, white core + field on with Glow, source-colour core without Glow, grey dashed unavailable without a field. The hit path takes the card's own device handlers (one action path) with radius max(22 px, t/2) and the nearest stripe as owner. The linear field is the exact distance field with the shared falloff: opaque grey bands of a luminance mask per piece, pieces joined by lighten (the maximum), each piece clipped to what its own emitters see, so a hidden part never lights through another part's visibility; buried emitters emit nothing; a failed clip is dark. A bounded per-space cache (50) counts geometry rebuilds. - The initial View graph had 501 B of headroom. The furniture library copy (furn.*, 104 keys × 4 languages, editor-only) moves into a new lazy `tools` namespace (#627 mechanism) that the editor runtime awaits; the initial View graph is 298 686 B gzip with the LED gate in it (−1 879 B vs the base). Tests: test/led-strip-runtime.test.mjs (6: representation, gate anchor = geometry anchor, falloff, states and radius, per-piece clipping and buried strips, bounded cache), bundle and i18n fixtures for the LED chunk and the fourth namespace. Issue: #780 User-Visible: no	2026-10-02 20:54:49 +03:00
claude[bot]andCodex	fb3071d3c1	feat(card): pure LED strip geometry and the space model field (#780) ... Stage 2 of #780. src/led-strip-geometry.ts (pure, not imported by the initial graph): the anchor at half the polyline length; stripPieces and visibleStripPath — a segment lying on a thick body face within epsilonGeom is shifted t/2 into free floor, free floor and zero-wall axes stay at 0, a face→floor transition is a connector without gap; emitter samples epsilon outward on a face and none inside a body; placement that stops at the first face and lets a strip touch and slide along it, a vertex drag clamped on its path and both neighbours; the screen hit owner with radius max(22 px, t/2) and a stable-id tie. SpaceModel gains optional led_strips (render units, data only, no geometry import in space-geometry.ts). Tests: test/led-strip-geometry.test.mjs (10). Issue: #780 User-Visible: no	2026-10-02 20:54:49 +03:00
claude[bot]andCodex	870237f3fb	feat(backend): LED strips are stored, normalised and transferred (#780) ... Stage 1 of #780 — the data model. A space carries an optional `led_strips: [{id, points, marker, active?}]` (custom_components/houseplan/ led_strips.py, pure, strict mypy). - Type schema inside SPACE_SCHEMA: 2–50 finite numeric points (no strings, booleans, NaN or off-canvas values), ≤50 strips per space including hidden shapes, strict boolean `active`, marker = non-empty string or null. - A config-level step after coordinate canonicalisation judges the shape (two distinct points, non-zero length, a closed strip needs three distinct vertices, a hidden shape needs a marker, unique ids per space) and the links in the order the spec fixes: duplicates are rejected before any normalisation (two links to the same missing id still conflict); a link to a marker that is not live becomes an unbound strip (marker null, active true, id and points kept), so a client that does not know strips can delete a bound marker without its save failing; a live marker with an empty space adopts the strip's space; a non-empty foreign space rejects the write. - config/set answers with `led_strips: {unbound, space_adopted}` when the write was normalised, so a new client re-reads; old clients ignore it. - Space import remaps links through the marker id map; a skipped or virtualised duplicate leaves the strip unbound; a coinciding old id never binds. Plan-only export keeps geometry and nulls every link. Import details report `unbound_led_strips`, computed by the server, never read from the file. - Coordinates get JSON-noise cleanup only, like stairs (face contacts are off-lattice), in both canonicalisers with a shared fixture case. - Support package: counters only (total/unbound/hidden), no coordinates or ids. Tests: tests_backend/test_led_strips.py (41, pure), test_ha_import_export (6 cases: full round trip with a hidden shape, orphan count, remap against a coinciding id, skip and virtual duplicates, plan-only), test_ha_websocket (old client deletes a bound marker → save stands, counters, foreign space rejects without a new revision). Full backend with the HA harness: 969 passed. Mutating the shape check, the duplicate check, the orphan normalisation or the space adoption each turns the pure suite red. Issue: #780 User-Visible: no	2026-10-02 20:54:49 +03:00
Matysh	d0c13bc555	Release v1.79.0-beta.2 candidate ... Publish the 58 integrated S8 issues since beta.1. Synchronize versions, rebuild committed frontend assets, refresh ratchets to measured facts, and update release metadata. All 11 documentation screenshots were accepted as pixel-identical in WSL, without replacing PNG bytes. Owner-authorized manual ship review covers all 13 ship issues; High 0. Local checks: build/typecheck, 3510 unit tests passed (30 skipped), 20 selected browser smokes, Stage 3 dense observable contract. Full exact-SHA Validate remains mandatory before publication. Release: v1.79.0-beta.2 Issue: #694 Issue: #703 Issue: #704 Issue: #705 Issue: #707 Issue: #708 Issue: #712 Issue: #714 Issue: #715 Issue: #716 Issue: #717 Issue: #718 Issue: #719 Issue: #720 Issue: #721 Issue: #722 Issue: #723 Issue: #724 Issue: #725 Issue: #726 Issue: #727 Issue: #728 Issue: #729 Issue: #730 Issue: #731 Issue: #732 Issue: #733 Issue: #734 Issue: #735 Issue: #736 Issue: #737 Issue: #738 Issue: #739 Issue: #740 Issue: #741 Issue: #742 Issue: #743 Issue: #744 Issue: #745 Issue: #746 Issue: #747 Issue: #748 Issue: #749 Issue: #750 Issue: #751 Issue: #752 Issue: #753 Issue: #754 Issue: #755 Issue: #756 Issue: #757 Issue: #758 Issue: #759 Issue: #760 Issue: #761 Issue: #762 Issue: #772 Issue: #775 User-Visible: yes	2026-10-02 07:55:09 +03:00
Claude	a86be350b1	perf(bundle): load the space-card GUI editor lazily to keep #744 under the initial View budget (#744) ... The floor-geometry key of #744 (+~143 B gzip) put the initial View graph at 301 097 B gzip, 31 B over the absolute 301 066 B wall in scripts/bundle-budget.mjs. The comment over that wall says the next growth is paid by moving code into lazy graphs, not by raising the budget. `src/space-card.ts` imported its Lovelace GUI config editor (`src/space-editor.ts`, the `houseplan-space-card-editor` element) statically, so every View paid for a form only the dashboard editor opens. `getConfigElement()` now imports it on demand, exactly as `houseplan-card.getConfigElement()` already does for `./editor`; Home Assistant awaits the returned promise. The editor's dependencies (lit, i18n, space-geometry) stay in the shared chunk, so the new `space-editor-*.js` chunk holds only the element itself (~1.1 KB gzip). Measured: initial View 301 097 -> 300 489 B gzip (-608 B), headroom to the 301 066 B budget 577 B. The beta ceiling (300 142 B, band 2 000 B above it, #699) and the budget are unchanged; lazy editor/onboarding graphs are not touched. Issue: #744 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-02 00:56:09 +03:00
Claude	f5b20e07f6	perf(floor): key the floor-geometry caches by the floor's content (#744) ... The physical bodies, the wall union pool, the inner room contours and the clean floor carried the global config epoch in their keys. Every edit of any floor bumps it, so after one edit every other floor was cold again: in large-house the first visit to an untouched floor rebuilt its wall union and paid ~0.7 s flat / ~0.65 s 2.5D instead of ~40-55 ms. A floor's geometry reads only its own config record (spaceModels) and constants, so the key is now a content fingerprint of that record (src/floor-geometry-key.ts), remembered per epoch and per record object. The geometry also reads the current floor's config next to the model it is given; when those records differ the key covers both. The live resize preview is its own record, so preview frames get their own key; the editor runtime seeds the pool and re-keys the bodies through the same reader. The stairs editor no longer clears the clean floors of every floor: the stairs are part of the floor's record. The #735 switch-cycle guard now also sees the union pool and the inner contours (optional members of the large-house card contract, so an older comparison bundle reads 0). smoke_floor_geometry_cache proves the warm other floor and the invalidation against an independent card (multi-floor push with shared walls, a stair, a resize preview and its cancel); two mutants guard it. Issue: #744 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-02 00:56:04 +03:00
Matyshandclaude[bot]	6149bcf866	refactor: keep room warm-draft construction in the lazy editor (#762) ... Issue: #762 User-Visible: no	2026-10-01 21:00:48 +00:00
Matyshandclaude[bot]	f2936813af	fix: keep warm editor adoption subordinate to user navigation (#762) ... Issue: #762 User-Visible: yes	2026-10-01 21:00:48 +00:00
Claudeandclaude[bot]	d709ea110d	perf(stairs): draw all treads of a stair as one path (#740) ... A floor with stairs pays for them on every switch to it: the stair layer is emptied on other floors, so Lit recreates every symbol on each return and the browser lays out and paints it again. With 250 stairs (the large-house fixture, the per-floor limit) that was 2,875 SVG elements and about 40 ms per entry locally; each stair carried 3-7 separate tread lines with four bound coordinates each. The treads of one stair are now a single <path class="hp-stair-tread"> with one `M a L b` subpath per tread, in geometry order and with the numbers the lines carried. Treads of one stair never overlap (straight: parallel, >= 20 cm apart; spiral: inner ends >= 6.7 cm apart at the 3.6 cm stroke), so the path paints the same pixels at any opacity. The outline points and the tread data are built once per cached geometry object (cachedStairMarkup, weak keys), not on every render. The View and plan-editor layers share the strings; outline, hit polygon, trapezoid, arrow, attributes and handlers are unchanged. Floor 1 of the fixture drops from 4,210 to 2,960 elements. Witnesses: the unit test for the path data and its cache, and the smoke_stairs markup checks in View and in the plan editor, are red on dev. The stairs-view-tread-lines mutant restores the View lines. Issue: #740 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 18:27:53 +00:00
Claudeandclaude[bot]	953f15b967	fix(plan): write every room state's transparency as colour plus opacity (#746) ... `.room { transition: 0.12s }` interpolates a room's colour and its fill-opacity / stroke-opacity independently, and the visible opacity is their product. The states without a fill kept their alpha in the colour with the default opacity 1 (.overlay transparent, .yard rgba 0.14, .outlined rgba 0.06 / 0.55, .picked rgba 0.25), while .styled writes an opaque colour plus fill-opacity: var(--room-fill-op). On a change between the two on the same node one half rose while the other fell, and mid-way the room was darker than at either end. Opening the space settings on a floor with no fill (the dialog shows "no fill" as its own colour at alpha 0) flashed every room grey for ~0.1 s, 0 -> 0.241 -> 0; cancelling the dialog after a preview, entering and leaving the plan editor briefly darkened the fill (0.18 -> 0.317 -> 0.06). Every .room state now writes an opaque colour plus *-opacity, and transparent only together with a zero opacity. The transition itself, .styled and the --room-* variables are unchanged; the space card takes the same styles. The resting paint is the same: the witness records each state's colour and visible opacity as dev drew them, and screenshots of seven resting states (View without fill, with fill and borders, plan editor, room picked for a merge, yard with and without borders, yard in the plan editor) are pixel-identical to dev outside the plan editor's tool hint, whose text shifts by a sub-pixel between runs on dev too. Witness: new demo/smoke_room_fill_transitions.mjs, deterministic. A MutationObserver pauses the room's transitions at their first frame right after Lit commits, and the smoke seeks them through 0..120 ms in 15 ms steps. Red on dev: fill overshoot 0.241 / 0.125 / 0.137 / 0.134 on the four paths, stroke 0.241 / 0.242 on the first two. A real colour change of the same room still runs a fill transition (catches `transition: none`). A card-mod rule that sets only `fill` on an unfilled room now meets fill-opacity 0; CHANGELOG and STYLING-HOOKS say to set the opacity with the colour (the values are generated, STYLING-HOOKS §3.3). Issue: #746 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 14:55:10 +00:00
Claudeandclaude[bot]	f0e1c0b8cc	fix(warm): revive the editor draft when write access arrives late (#756) ... A same-route remount that cannot edit yet - hass arrives after the element is inserted (the demo's own order), or a non-admin waits for the server's can_write - keeps the editor in _pendingNavMode and enters it later through _resumePendingNavMode -> _setMode. The draft revival was wired only into the immediate warm adoption (_requestMode(..., adopt)): on the pending path the draft was lost, _warmRevivePending stayed up for the instance's life, _warmSnapshot stopped writing dlg, and the next remount brought back the predecessor's stale draft. The adoption tail (draft revival once under a held refit, then the settled stage as the refit baseline) is shared by both paths: the sequencing lives in src/warm-mode-adoption.ts, the refit bookkeeping in the card's _holdWarmRefit/_releaseWarmRefit. The pending mode still enters through _setMode, the transition authority smoke_nav_persist holds it to; resumeWarmMode then settles the revival. _setMode ends the passive boot grace and refits the camera to a header measured before the editor chrome rendered, so a camera the pending window left untouched is put back and held exactly as an immediate adoption holds it; a camera that has already moved on (View refit, the user's pan, another space) is left to the ordinary refit. A mode that did not commit, an explicit mode command in the pending window and a route departure settle the revival too: no outcome leaves _warmRevivePending up. The core file gives back 4 lines. smoke_warm_dialogs gains section H through the UI: the three late-write orders keep mode, draft, dirty baseline and a frame-by-frame identical viewport; the chain carries this instance's draft, not the predecessor's; a space switch in the pending window eats the draft. 14 checks are red on dev. The mutant warm-pending-mode-leaves-revive-waiting is guarded by the smoke; docs/WARM-REMOUNT.md §2 describes the pending editor. Issue: #756 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 13:56:37 +00:00
Claudeandclaude[bot]	dc77852e0b	fix(space-card): key room shapes by space and id so a config change never repaints a stranger (#745) ... The space card drew its rooms with a bare map(), so Lit reused room nodes by position, and `.room { transition: 0.12s }` (planStyles is part of this card's styles too) drew a node's fill and stroke in from whichever room held it before. Two paths change the room set in the same DOM: a new `space` in setConfig of the same element (the card editor's preview), and a config event from any device that inserts, removes, reorders or re-zones a room of the shown space. Filled rooms faded out and back in for ~0.12 s, unfilled ones briefly darkened in a filled room's place. The list is now keyed(space.id, repeat(rooms, (r, i) => r.id || i, ...)), the same shape as the full card after #742: the outer key handles the space change, the inner one keeps a node bound to its room inside a space. An id-less room keys by its numeric index, which never equals a string id. The transition itself stays: it smooths a real fill change on the same room. The #742 note in plan.styles.ts now names the space card as well. Witness: a new section of smoke_space_card. The config is delivered by a server push (__hpTest.setServerConfig), the event the card subscribes to. Red on dev: node r1 reused for g1 with fill/fill-opacity transitions and a first-frame fill of rgba(0, 0, 0, 0) / 0; a room inserted first shifts all four nodes and replays fill transitions. A real custom_fill change still runs a fill transition on the same node (catches `transition: none`). One mutant: inner key replaced by map(), guarded by AC2 (checked by hand: red). Issue: #745 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 12:30:45 +00:00
Claudeandclaude[bot]	4091d83af3	fix(editor): a render no longer restarts a failed runtime load (#757) ... The lazy-runtime contract (#353) says a non-terminal failure waits for the next explicit intent and that there are no background retries. But _renderBody calls ensure() on every repaint while a surface waits for the editor or onboarding runtime, and to the loader that call was indistinguishable from an intent. Surfaces the core opens without the runtime - the kiosk size dialog after a 3 s hold, the floor import wizard on an empty plan, a dialog a warm remount revives - therefore turned one failure into a loop: the loader's own state change, the toast and its expiry, every hass tick repainted, started a new cycle and showed a new toast every ~3.5 s. A wall tablet whose old hashed chunks answer 404 after an integration update sat in that loop forever. EditorRuntimeLoader.ensure takes an intent: the render calls it as 'reconcile'. A reconcile starts the first cycle a surface needs, but after a non-terminal failure it returns false without loading until an explicit ensure() - a tab, an opener, _requestMode, "Add space" - has started a new cycle. Explicit calls, the terminal fingerprint failure, ready and an in-flight cycle behave as before, for every loader instance. The card's render lines stay line-neutral. smoke_lazy_editor_chunk gains the three surfaces offline through their real paths (a 3 s touch hold on a kiosk card, an empty plan pushed by the server, General settings revived by a remount): one cycle, one notice and an idle loader over 8 s, then the Plan tab and "Add space" heal. On dev: 4 requests / 3 notices, 6 / 2 and 3 / 2. The loader unit test pins reconcile versus intent; the mutant render-reconcile-restarts-editor-runtime-cycle is guarded by the smoke. Issue: #757 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 12:12:15 +00:00
Claudeandclaude[bot]	a0f72280ee	fix(plan): key room shapes by space and id so a floor switch never repaints a stranger (#742) ... The flat room list was a bare map(), so Lit reused room nodes by position. On a floor switch the previous floor's room node became the new floor's room and `.room { transition: 0.12s }` drew its fill and stroke in from the old computed values: one paper-white frame, then two or three frames darker than the final fill (alpha rises while fill-opacity falls), then the fill. Between two filled floors the fill bled in from the other floor's colour. The list is now keyed(space.id, repeat(rooms, (r, i) => r.id || i, ...)), the shape #534 settled on for openings and markers. The outer key handles the floor switch, including room ids repeated on two floors (ids are unique only within a space); the inner key keeps a node bound to its room inside a space, where inserts, merges, splits and the editor filter shift positions. An id-less room keys by its numeric index, which never equals a string id. The transition itself stays: it smooths hover and a real fill change on the same floor. Witness: a new section of smoke_space_switch_transitions, before physicalize (after it the first room changes template branch and the node is recreated anyway). Red on dev: five transitions on g1, node r1 reused for g1, computed fill rgba(0, 0, 0, 0) / 1; room nodes swapped by an insert; same-id case reuses r1. A real custom_fill change still runs a fill transition (catches `transition: none`). Two mutants: inner key removed, outer key removed. Issue: #742 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 10:13:50 +00:00
Claudeandclaude[bot]	9324d81b5f	perf(iso): keep the theme paper across floor switches in 2.5D (#739) ... In 2.5D with a backdrop image every floor switch rendered the card twice before the first frame. The paper key of the first-frame state (#654) held the space id, so each switch cleared the ready paper: the first render inserted the loading veil, updated() probed the computed card background with a temporary span and asked for a second full update, which removed the veil again. The colour itself never changed: it is the theme card background, and no space sets those variables. Locally this second pass was about 50 ms per warm switch on the large house. The paper under a backdrop is now resolved once per theme identity (dark mode, default and dark default theme, theme) and card mode. The state keeps the resolved paper of the current theme and mode beside the current paper, so a floor with a backdrop is ready in prepare() when that paper is known -- also after a drawn floor in between -- and the switch renders once: no veil, no probe, no second update. A drawn plan keeps its white paper without the DOM. Any change of the theme identity or the mode, also one made in Flat or in an editor, drops the kept paper, so the first backdrop floor after load, a theme change and a trip to an editor take the #654 path unchanged. isoPaperContext still takes the floor; it deliberately leaves it out of the identity. Witnesses: the #739 unit test is red on dev at "a floor switch shows no veil" and on a key-only variant (space dropped, no theme cache) at "drawn -> backdrop keeps the known theme paper"; the new smoke_iso_floor_switch is red on dev (2 updates, 1 colour probe and a veil insertion in every click task). The iso-paper-resolved-per-floor mutant puts the floor back into the theme identity. Issue: #739 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 10:06:38 +00:00
Claudeandclaude[bot]	36ebabaaec	fix(moon): the status line after a warm revive of General settings (#731) ... #718 K7 takes the moon status once per opening of General settings, outside the draft. A warm remount revives the open dialog on a new card instance, but `_warmReviveDialog` restored only the draft: the new instance had no opening of its own, so the "Now: ..." line never came back. A revive is an opening too. The `settings` branch now asks for the status the way `_openSettingsDialog` does - through the lazy editor runtime (`_openMoonStatus` -> `openMoonStatus`): at once when the runtime is there (an editor revives after `_requestMode(..., adopt)` has installed it), after it loads in View; once per revive and only while that revived dialog is still open. The snapshot of now, `hass.config` and `sun.sun` is the revive's own, nothing of the dead instance's opening is carried over, the draft key and the dirty flag do not change. The View graph gets no static moon-status import; other dialog kinds never ask for the moon chunk. demo/smoke_moon_status.mjs gains the revive scenarios - View, the plan editor, a revive while the chunk is still loading, a space-dialog revive that must not load the chunk; the first three are red on dev. test/moon-settings.test.mjs executes the revive as a new opening; the wiring itself is proven by the smoke, not by reading the monolith as text (#624). docs/SUN.md and docs/WARM-REMOUNT.md say a revive is an opening; scripts/smoke-links.mjs links the two new symbols to the smoke. Issue: #731 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 06:47:05 +00:00
Claudeandclaude[bot]	d5bdfde919	refactor(iso): drop the unused stageSize from the overlay fit input (#741) ... Since #713 the overlay fit envelope reserves no nudge budget, and since #725 _isoScene passes `stageSize: null` while resolveIsoOverlayFitEnvelope never reads the field. The room focus still built a { width, height } object from the stage for nothing. The optional field is removed from IsoOverlayFitEnvelopeInput together with both call-site arguments. The #725 AC3 unit compared bounds with stageSize null and 1000x500, which is now meaningless; it checks instead that the fit bounds follow only scene.frame and the tiles: the same bounds for every stage aspect, a moved frame moves them, an enclosing frame is returned as is. Issue: #741 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 05:59:54 +00:00
Claudeandclaude[bot]	b998b0b34a	feat(moon): the moon with any background, and its status in General settings (#718) ... The owner decided on 30.09 that the moon is not part of the "Follow the Sun" environment but a switch of its own: with a static background (global or a space's own) the card showed no moon even with the switch on, and the switch said nothing about why the moon was missing right now. With a static background there is no environment, so the moon stands in its own layer, `.hp-moon-sky`: the first child of `.stage` / `.hp-static-stage`, the whole scene, no z-index, filter or will-change, under the plan by DOM order, fading with the #101 View weight. Inside is the very #661 element, so place, size, art and fades are unchanged, and a background switch moves it to its new parent in the same render without a flicker. The phase comes from the same `resolveDayCycle`, computed only while the moon is on and on View; without `sun.sun` both cards keep their 30 s clock ticker and re-render only when the phase changes (the environment is still compared by its whole fingerprint). General settings get a second caption line under the moon switch (`data-moon-status`): one snapshot per opening, judged by the lazy chunk as if the switch were on, first reason wins (no home, day, below 3°, under 3 %), numbers rounded and clamped below the threshold they missed. `moonStatus` decides "shown" with the same `moonShownAt` as the element. It lives in a WeakMap beside the draft, so it never makes the dialog dirty; a closed opening's result is dropped. The dialog loads the chunk through the gate's loader (`withMoon`), now shared by every caller while a load is in flight, so there is still one fingerprint check and one retry token. Bundle (same build, against origin/dev): initial View 300 072 -> 300 248 B gzip (+176 B, under the 500 B of the spec; budget and ceiling not raised); lazy editor 238 558 -> 238 991 B (+433 B, the line and English strings); lazy moon 11 385 -> 11 712 B (+327 B, layer CSS and status). `src/moon.ts` stays out of the initial and the editor graph; bundle-budget now refuses an editor/moon overlap. Monolith metrics: hostRefs 4 885 -> 4 888 — the three `host.` reads of `src/editors/moon-status.ts` (hass, `_settingsDialog`, requestUpdate) through its own three-member interface, not the editor port; the other five metrics are unchanged. houseplan-editor-runtime.ts grows by two lines (import, call). Tests: AC9/AC10/AC15 and the sky layer in test/moon.test.mjs (the #661 "static -> nothing" check inverted), AC14 and the opening lifecycle in test/moon-settings.test.mjs, smokes demo/smoke_moon_static.mjs (AC1-AC6; AC1 and AC3 were red on dev) and demo/smoke_moon_status.mjs (AC11/AC12), AC7 in smoke_daycycle_layer_budget. Golden: two new scenes (static-bg-moon-gibbous-white-light, static-bg-moon-crescent-south-dark, matrix v70), the harness checks the moon's parent by background and waits for the status line in the General settings frames. Four new mutants; the clock ticker one is a browser guard (201 at the guideline of 200). Issue: #718 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 05:25:21 +00:00
Claudeandclaude[bot]	235f60e693	perf(card): a floor switch stops forcing layout and re-walking the config (#725) ... Profiling #694 found three costs on every View pass, paid even with the summary panel hidden. The summary panel read the safe-area probe's computed style in layout(), which the card reaches up to five times per render (renderControls, menuItems, renderPanel twice, the clock check), and its updated() measured the stage, probe and kiosk buttons after every DOM commit. The insets now live in the measured state: measureLayout is the only method that reads style or layout, and updated() calls it only when an input of the measurement changed (probe, kiosk buttons or stage element, title, language, mode, kiosk, kiosk scale, narrow, HA theme), after connect() or an identity change, on visibility, once after document.fonts.ready, and from resized() as before. A floor switch or an HA tick no longer measures. The _model getter rebuilt the config fingerprint (a walk over every space and room with JSON.stringify of room settings) on each of its dozens of reads per render. ConfigFingerprintPass remembers the whole cache key (epoch and fingerprint) from the start of willUpdate() to the end of render() while the epoch, the config object and its spaces array are unchanged. Remembering only the fingerprint and concatenating the key on every read was tried first: in 2.5D on the large house the switch cycle measured slower than without any memo, and CPU profiles showed several times more garbage collection on load and on the first visit of a floor; one remembered key per pass has neither. Outside the pass (handlers, updated(), timers) every read still builds the key, so an in-place edit without an epoch bump stays visible (HP-1454-04). No write to the fingerprinted fields is reachable from willUpdate() or render(). _isoScene read the stage box during render only to feed an aspect into the overlay fit, whose frame has not depended on the aspect since #713. It now uses the frame's own aspect and passes stageSize: null. render-layout-read.mjs now also judges _isoScene and the whole summary runtime except measureLayout, forbids layout property reads (clientWidth, offsetTop, ...) besides the two calls, and reports every violation. Two registered mutants restore the old reads. No visible change: panel caps, side, offsets and kiosk clearance are computed from the same values; the 2.5D frame is the same. Issue: #725 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 03:17:40 +00:00
Claudeandclaude[bot]	6f17b6cd4c	perf(card): a floor switch stops re-querying the same subtrees (#694) ... A floor switch replaces the whole stage, so the card's pointer-hover MutationObserver receives hundreds of records whose targets are the same few containers. Each record re-ran `matches` and a `.devlayer` subtree `querySelector` on its target, and kept doing so after the device layer had already been found. The batch logic moves to `deviceLayerMutated` in device-hit-owner.ts: a node is checked at most once per batch, the first hit ends the checks, and every added node still goes through `_syncPointerHoverSubtree` in record order. The card shrinks by 12 lines. The View stair layer read the card's `_model` getter once more for every navigable stair; the getter rebuilds the config fingerprint on each read. `renderLayer` now reads it once. `languageRenderGate` wrote `lang` on the host on every render. It now writes it only when the value differs (language switch, English fallback, a foreign value); an unchanged value is left alone. No behaviour changes: DOM, tooltips and pixels are the same. Unit tests count subtree queries per node, `_model` reads per render and `lang` writes; one mutant per change restores the old behaviour. Issue: #694 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 00:22:26 +00:00
Claudeandclaude[bot]	715735d753	refactor(iso): remove the empty overlay renderers and dead fixture fields (#732) ... After #714 and #724 the 2.5D overlays still carried stubs: - renderIsoOverlayGrounds and renderIsoRaisedOverlays returned an empty SVG on every frame. They go with IsoFramePresentation.grounds/raised and the two bindings in the card. The iso-overlays-svg element itself stays, now empty: it is the inert camera-viewBox layer the contract and live-touch smokes measure screen-facing HTML against, so the 2.5D DOM keeps its elements. - IsoOverlayRenderEntry.groundRadius was computed for every device, room label and lock and read only by the snapshot comparison that compared it. The overlay test fixtures passed view, referenceView, stageSize and layers (and one test selectedDeviceId), which IsoOverlaySceneInput does not have, and asserted that changing them keeps the placement - a claim the signature makes by itself. Those fields are gone from every fixture. The zoom/resize asserts of "Stage 4 reuses pure overlay placements" and "#713 AC3" (renamed to what it still checks) and the "#570 supersedes #473 W1" selection test go; the #724 AC2 test now zooms the way production does, through the live frame of resolveIsoScene, and checks that the structural geometry and so the overlay scene are reused. The #713 K8 fixture no longer passes stageSize, which resolveIsoOverlayFitEnvelope does not read. test/iso-overlay-fixture-types.test.mjs typechecks the overlay test files with the TypeScript compiler: their fixture types (OverlaySceneFixture, OverlayEntryFixture) are the keys of the production types with deliberately loose values, so a partial fixture is fine and a field the type lacks is an excess-property error. Three checks: no excess property in the fixture files; a probe shows the fixture types resolve to the real inputs and reject view, referenceView, stageSize, layers, selectedDeviceId and groundRadius; every call of the scene builder gets its argument through a checked type (a literal in overlayScene or a declaration of the fixture type). Each check is red when a dead field is put back into a declared fixture, an override literal or an entry, when a literal goes straight into the builder, when a fixture loses its annotation, and when groundRadius returns to the entry type. isometric-contract now asserts that nothing renders into the overlay surface and that the removed renderers and groundRadius stay gone. No mutant is anchored on the removed code; mutation-gate --check is unchanged (3 warnings). The 19 2.5D golden scenes pass in capture on the accepted baselines. Issue: #732 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-30 23:26:46 +00:00
Claudeandclaude[bot]	5f8e8ca7e8	refactor(iso): drop the 2.5D overlay data nothing reads (#724) ... After #714 the 2.5D overlay scene still carried what decides nothing: - src/iso-overlays.ts: IsoOverlayPlacement loses tether and grounding (always invisible) and raisedScene (always equal to visualScene); IsoOverlayOwner loses area; IsoOverlayPlacementInput loses hovered, focused, selected and filtersSupported, which the resolver ignored. IsoWallSilhouette and tetherGeometry go with them. - src/iso-scene-render.ts: the structural scene no longer projects wall silhouettes (isoWallSilhouettesOf and IsoSceneCacheEntry.wallSilhouettes) that served only as a cache key. The placement and render-scene caches are keyed by the wall geometry the scene is drawn with (IsoOverlaySceneInput. structure = scene.geometry): the structural LRU hands out the same object across zoom, stage resize and HA state, and a new one after any wall, room or opening edit. The resolveCollisions flag and its fit/live cache slots are gone: since #713 both held equal placements, and 2.5D renders only in View, where the fit probe and the live frame ask with the same devices, so they now read one snapshot. - src/houseplan-card.ts: the fit call passes no flag; the overlay scene gets structural.geometry. data-hp-iso-nudged stays the constant "false" read by the golden requireOneRise preflight, the live-touch smoke and the benchmark. Tests: iso-overlays pins the placement fields; iso-scene-render builds the structure with buildIsoWallGeometry, the #714 zoom/resize and #711 state tests stay, fit and live are asserted to share one snapshot, and two #724 AC2 tests run the production path (createIsoStructuralSource -> resolveIsoScene -> buildIsoOverlayRenderScene): a thicker wall with the same room rebuilds the scene (red with a key without walls, e.g. keyed by the room rows), and a room edit that moves the owner gives the new owner (red with a constant key). The silhouette-construction test goes with the construction. Mutants: #473 W2 (iso-placement-cache-survives-silhouette-change, id kept for history) now keys the placement cache by a constant instead of input.structure and its guard also runs the #724 AC2 tests; W6 patches the new structure line; the W5 description no longer speaks of a nudge. The isometric-contract regex checks the new key instead of the silhouette construction. docs/ISOMETRIC.md names the key. Live 2.5D output is unchanged: the 21 isometric golden scenes pass on the accepted baselines. Issue: #724 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-30 22:39:24 +00:00
Claudeandclaude[bot]	7574518575	refactor(iso): remove the dead #651 overlay placement search (#714) ... Since #713 every raised device tile and lock badge is its floor anchor lifted by one shared wall-top rise and room names stay on the floor, so the live scene no longer called the #651 search. What was left of it only cost code, build time and review attention: - src/iso-overlays.ts: resolveIsoOverlayRigidGroups, resolveIsoOverlayCollisions with their boundary-candidate machinery, the nudge search in resolveIsoOverlayPlacement (the vector to the room safe point, the near-wall test, the zoom hint), the safe point itself, the nudge/nearWall/cleared/capped and status/reason fields, and ISO_OVERLAY_MAX_NUDGE_CSS_PX / ISO_OVERLAY_SAFETY_GAP_CSS_PX. - src/iso-scene-render.ts: the zoom reuse fast path and the CSS-pixel scale it compared; a placement now depends only on anchor, owner, footprint and rise, so zoom and stage resize reuse it by signature. residualPairs is gone and the memo key is called layoutSignature. - src/houseplan-card.ts: the overlay scene no longer receives the view, the reference view or the stage rect it only fed to that scale; data-hp-iso-nudged stays as the constant "false" that the golden requireOneRise preflight, the live-touch smoke and the Stage 4 benchmark read. The #585/#651 unit tests and the seven mutants that guarded only the removed code are deleted; kept tests drop their nudge assertions, and a stage resize is now pinned as a non-layout event. docs/ISOMETRIC.md keeps #651 as history only. Live 2.5D output is unchanged: the 21 isometric golden scenes pass on the accepted baselines. Issue: #714 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-30 20:36:03 +00:00
Claude	dca0fd2876	Release v1.79.0-beta.1 candidate ... Issue: #661 Issue: #692 Issue: #693 Issue: #711 Issue: #713 User-Visible: yes Release: v1.79.0-beta.1 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-30 18:38:57 +03:00
Claude	0d641ffbfd	feat(iso): the 2.5D floor is the Flat plane, one wall-top rise for tiles (#713) ... - Vertical oblique projection: the floor matrix is the identity and a height rises straight up by z·sin 20°, so the on-screen wall height is unchanged and the cos 20° foreshortening of the plan, decor and anchors is gone. - Device tiles and lock badges stand on the wall-top plane with one common shift; the #651 placement search no longer runs in the live scene (its removal is #714). Room names keep their Flat floor point. - The 2.5D fit no longer reserves the 48 CSS px nudge budget. - Switching projection keeps the camera when the previous projection was on screen: saving the setting, entering an editor from 2.5D and adopting a warm memo from the other projection re-read only the scalar zoom. A cold 2.5D start still opens the 2.5D home. - Opening faces are ordered along the oblique projector (s·y + z). Witness: demo/smoke_iso_flat_parity.mjs (AC2–AC5, AC11) is red on the old code. Issue: #713 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-30 15:18:00 +03:00
Sergey MatyuninandClaude Opus 5.5	c8c470ed57	feat(view): the moon in its phase over the "Follow the Sun" background (#661) ... At dawn, dusk and night the environment shows the moon in the top-left corner of the scene, behind the plan: computed in the card from the home coordinates and the browser clock (short Meeus series + topocentric parallax, within 1.4° / 1.8 pp of JPL Horizons), one designer image under a continuous phase mask with the lit side always on the left (owner 2026-09-29), a feathered terminator, 3°/3 % thresholds and the 2 s fade of the window rays. Everything but a small gate lives in the lazy moon-runtime chunk, with its own 30 s ticker. General settings: "Sun" becomes "Sun and Moon" with one switch, on for new installations (DEFAULT_CONFIG), off for existing ones. The initial View graph sat 728 B under its budget: the gate is paid for by moving fifteen dialog-only strings of General settings into the lazy settings dictionary (#459) and by one build fingerprint literal instead of three, so the graph ends 4 B above dev. Golden: two new moon scenes, and the two General settings help frames show «Sun and Moon»; the WSL artifact test fixture now models scenes whose first capture awaits acceptance. Issue: #661 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-30 12:25:46 +03:00
Claude	a372b354c6	fix(2.5D): a device icon never moves because its state changed (#711) ... Owner's decision in #694: icons must not change position with state. Since #651 the rigid overlay layout sized a device by its value text and badges, which change with HA state: a light toggling on changed its width from 37.2 to 26.7 CSS px and re-laid out all 62 overlays of the dense scene (~385 of 495 ms of stateUpdate; v1.77.0 had 208 ms). - iso-scene-render.ts: the layout sees the state-free tile (icon at its configured size, no value text, badge or supplemental metrics). An HA-only change keeps the layout and refreshes only the visual extent that scene bounds read, without a collision search. - iso-overlays.ts: the rigid-group search skips candidates that already lose to the fallback on room, then wall violations (lexicographic bound). The result is unchanged — identical placement hash on the dense scene — at about 35 % less work. - docs/ISOMETRIC.md, changelogs; test #711; mutant iso-device-layout-follows-state-again (written, not run — #709). Local isometric-stage3-dense-v1, 3 samples: stateUpdate 522 → 89 ms (v1.77.0: 208), modelReady 3665 → 3129, switchCycle 5544 → 4700. Issue: #711 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-30 10:51:53 +03:00
Claude	18c9f8e77c	fix(stairs): View shows the link pointer over a stair, not the move cursor (#693) ... The Plan editor rule `.hp-stair.input-enabled .hp-stair-hit { cursor: move }` also matched the View layer, which sets input-enabled only to receive clicks. The hit area sits over the outline, so the link's pointer on the group was never visible and every stair in View showed a drag it cannot do. - src/stairs-view.ts: View stairs carry `hp-stair-view`. - plan.styles.ts: `move` applies only without it; in View the hit area keeps the group's cursor — pointer on a link, the stage's otherwise. - demo/smoke_stairs.mjs: computed cursors in View (link, no target) and in the Plan editor; the two View checks are red on the old code. - test/stairs.test.mjs: the cascade without Chromium; mutant view-stair-cursor-move-again. - docs/STAIRS.md, changelogs. Issue: #693 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-29 21:52:52 +03:00
Matysh	7d4d75bdfb	release: promote v1.78.0 from beta line ... Issue: #616 Issue: #649 Issue: #651 Issue: #654 Issue: #660 Issue: #663 Issue: #676 Issue: #683 Issue: #688 Issue: #691 User-Visible: yes Release: v1.78.0	2026-09-28 21:07:36 +03:00
Matysh	1ae0ea1c3b	Release v1.78.0-beta.9 candidate ... Issue: #688 Issue: #689 Issue: #691 User-Visible: yes Release: v1.78.0-beta.9	2026-09-28 20:44:43 +03:00
Claude	600330e187	fix(daycycle): stage-sized plan layers without a frozen raster; revert #685 hatch ... With the day/night background the plan went blurry after zooming from 100 % (sharp when the page was opened at 800 %) and navigating a strongly zoomed plan flashed the page white. Both came from #582's composition, not from the wall hatch that #685 replaced: - `.stage.daycycle.hp-safe-daycycle-outline .plan-svg` promoted the scene with `will-change: transform`; Chromium freezes the raster scale of such a layer, so the 100 % raster was shown stretched. The explicit layer #582 needs is now `will-change: opacity` (re-rasters at the current scale). - The filtered outline had `overflow: visible` and a gesture exposed every scene (#544) without bound, so the promoted layers grew with zoom squared (CDP LayerTree, ~460 %: plan-svg 15.9x, outline 13.2x the stage; 39x after navigating at 800 %). The full card clips its outline to its box and marks it data-hp-live-overflow="clip" (never exposed); the live viewport bounds every other exposure with an inline clip-path: inset(-25%) that leaves with it, so idle DOM stays byte-identical (#531). Owner-verified in Chrome 152 (built-in browser, DPR 2): sharp after 100 -> 800 %, no white flashes after reloading at 800 %. Owner decision: #685's analytic gradient is reverted (13af1d5e), the single <pattern> is back at every zoom; its close-up golden scenes stay and check the pattern, its terminal-frame smoke checks the pattern. Witnesses: demo/smoke_daycycle_zoom_layers.mjs (800 % x DPR 2: layers vs stage, the hint, reload path, button/wheel/pinch); #582/#532 smokes now pin the opacity hint; test/live-viewport.test.mjs (bounded exposure, clipped scene); test/daycycle-layers.test.mjs (cascade). Four Node-guarded mutants. Issue: #689 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-28 17:51:06 +03:00
Matysh	37fbb9824d	fix(touch): separate pan, edge swipe and double fit (#691) ... Issue: #691 User-Visible: yes	2026-09-28 16:27:45 +03:00
Matysh	c04d0778ae	fix(stairs): use one physical line weight (#688) ... Issue: #688 User-Visible: yes	2026-09-28 14:58:33 +03:00
Matysh	c047ca2230	Release v1.78.0-beta.8 candidate ... Issue: #684 Issue: #685 Issue: #686 Issue: #687 User-Visible: yes Release: v1.78.0-beta.8	2026-09-28 13:19:11 +03:00
Matysh	52fe4d6499	fix: вернуть paint-server штриховки в defs (#685) ... Полный smoke обнаружил нарушение порядка SVG-слоёв и устаревшее ожидание скрытых устройств после #687. Paint-server снова живёт в defs; общий mode-smoke проверяет видимые ориентиры устройств в Plan. Issue: #685 User-Visible: no	2026-09-28 12:04:48 +03:00
Sergey Matyuninandclaude[bot]	13af1d5e30	fix: стабилизировать штриховку после зума (#685) ... Issue: #685 User-Visible: yes	2026-09-28 07:35:39 +00:00
Claude	560849a1a7	feat(plan): device markers are landmarks in the Plan editor ... The Plan editor hid every device marker (display: none), so walls, openings and stairs were placed against devices from memory. It now shows them exactly as the Background editor does (#362): the same markers as View, at the Background editor's effective opacity, fully pointer-inert. The fade is filter: opacity(0.35) on each marker, not on .devlayer, because room labels and room settings buttons share that layer and stay opaque and interactive; filter multiplies the marker's own opacity (.unavail -> 0.35 x 0.35), as the Background layer does. Marker handlers already fail closed outside View/Devices. demo/smoke_plan_device_landmarks.mjs proves AC1/AC2: same markers as View, per-marker alpha equal to Background, core and capsule fall through, a real click on a marker reaches the Walls tool and a room settings button below, cursor and target unchanged, handlers inert, no tabindex. Three mutants guard hiding, opacity override and the pointer boundary. UX-MODES, DECOR-EDITOR, USER-GUIDE.ru mode table, changelogs. Issue: #687 User-Visible: yes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-28 09:38:26 +03:00