Files
houseplan-card/demo
Claude 7fb609e48a fix(zigbee): keep the neighbour endpoint core above routes in 2.5D (#809)
In the 2.5D View every marker sits on z-index 2 through
`.stage.projection-iso.mode-view .dev` (0,4,0), which beats the #464
endpoint lift `.dev[data-hp-zigbee-topology-endpoint]` (0,2,0). The
hovered endpoint survived only through its higher-specificity hover
duplicate, so the unhovered neighbour endpoint stayed under the route
layer (z 7) and the line crossed its face. Flat was unaffected.

The endpoint contract is repeated for the 2.5D View at (0,5,0), next to
the #464 rules. Narrowing the 2.5D rule with :not(endpoint) was rejected:
it would reach (0,5,0) and beat the hovered non-endpoint's z-index 5.
No stylesheet order or new file changes; .oplock is untouched.

Witnesses in demo/smoke_device_battery_zigbee.mjs:
- {flat,iso}_neighbourCorePaintsOverRoutes: along the drawn local route,
  inside the neighbour core (outside its battery frame) the route layers
  change no pixels, outside both cores they do. Red on dev in 2.5D
  (16 of 16 core samples changed), green here (0 of 16).
- iso_nonEndpointKeepsBaseLayer / iso_hoveredNonEndpointKeepsHoverLayer:
  computed z-index 2 for unlinked markers and 5 for a hovered marker
  outside the topology; the :not(endpoint) variant turns the latter red.

Mutant zigbee-iso-neighbour-endpoint-under-routes removes the new rule;
the browser guard is listed in the inventory (paint 44, total 248).

Issue: #809
User-Visible: yes
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd
2026-10-07 04:51:20 +03:00
..
2026-08-07 07:47:37 +03:00