No way to clear a drift report on a healthy node — Rebuild is gated on the refusal state

[simons-plugins]

What happened

Observed live 2026-08-06. After a last-fabric factory reset and a fresh pairing, one map entry was legitimately stale (indigo-459564566 expected 5, live 2) and the drift alarm fires on every attach. Rebuild Matter Endpoint Map… refuses:

Matter export: the bridge node is NOT refusing to serve endpoints, so there is nothing to rebuild. Rebuilding anyway would discard the retained endpoint numbers of every device that is not currently exported, and those are what make re-adding one restore the same accessory.

The reasoning is sound and the gate was added deliberately (PR #128 review, finding M11: run on a healthy node, rebuild drops retained allocations for non-live exports). But it leaves no route to clear a drift report unless the node is also refusing to serve — and drift is explicitly designed to be reported, never auto-repaired, so it persists forever.

Why this state is reachable and legitimate

A factory reset — from Reset Matter Export Pairings… or from unpairing the last ecosystem — wipes matter.js's own number allocation while the endpoint map survives by design. Post-reset drift is therefore expected, is documented as expected, and is harmless once the ecosystems have been re-paired (no ecosystem remembers the old numbers). The user is left with a permanent warning about a condition the docs told them to expect.

Options

1. Allow rebuild on a healthy node behind an extra confirmation that states exactly what is lost (retained numbers for devices not currently exported), rather than refusing outright.
2. Offer a narrower action — acknowledge/adopt the current drift set only, leaving other retained entries untouched. This is what the user actually wants and is strictly safer than a full rebuild.
3. Auto-adopt after a factory reset, since the node knows it just erased matter.js's allocation and that any resulting drift is its own doing.

(2) or (3) look right; (3) removes the interaction entirely for the common case. Whichever, the drift log line should say how to clear it.

Files: plugin.py:menuRebuildEndpointMap, bridge-node/src/endpoint-map.ts (rebuild, check), bridge-node/src/node.ts:factoryReset.

[simons-plugins]

Sharper statement of the problem — the node instructs a remedy the plugin refuses

Observed live 2026-08-06, after Reset Matter Export Pairings… on a healthy node:

Endpoint-number map preserved and 1 endpoint(s) already differ from it — that is
the reset's own renumbering, reported exactly as designed; rebuild the map (§3.11)
to accept it

That is the node telling the user, correctly, that a rebuild is the way to accept post-reset renumbering. Rebuild Matter Endpoint Map… then answers:

the bridge node is NOT refusing to serve endpoints, so there is nothing to rebuild

So the two halves of the product disagree in the user's face, on the routine path the docs themselves walk them down (reset pairings → re-pair). The drift line then repeats on every attach and every restart, permanently.

This raises the priority: it is not just "a warning that cannot be cleared", it is a documented instruction that the UI blocks.

Of the three options in the issue body, (3) auto-adopt after a factory reset now looks clearly right — the node knows it just erased matter.js's allocation, so any drift it then observes is its own doing and there is nothing for the user to adjudicate. Option (2) (adopt only the currently-reported drift set) remains the general-purpose escape hatch for drift arising any other way.

Whatever is chosen, the node's own message must stop naming a remedy the plugin will refuse.