diff --git a/plugin-designs/my-upg-100-list/upg-100-list.vue b/plugin-designs/my-upg-100-list/upg-100-list.vue
index ef1cd7f0a..2f0647d23 100644
--- a/plugin-designs/my-upg-100-list/upg-100-list.vue
+++ b/plugin-designs/my-upg-100-list/upg-100-list.vue
@@ -1713,22 +1713,19 @@ function applySelectZone(zoneId) {
   // map's tapestry layer is not up, which at t=4.9s it was not. So the readiness signal was never
   // legendNodes or mapRef -- it is THE LAYER, and the old code cleared _pendingZoneId here as though
   // the work were done. Keeping it means ensureLayers() can drain it the moment the layer exists.
-  // ★ ASK THE APPLIER, DO NOT INFER FROM A SIDE EFFECT -- and the inference was WRONG IN BATCH MODE.
-  // upg100-plugin caught this prospectively: onLegendSelect feeds the selection UNION in batch mode
-  // and returns without ever setting selectedKey, because isolating is not what it should do there.
-  // So `!selectedKey.value` read that correct behaviour as a failure, and retaining on it would have
-  // re-applied the zone and toggled it back OUT of the union. Un-isolating (node == null) is the same
-  // shape: the un-isolate IS the action, and selectedKey is null afterwards BY DESIGN.
-  // They have made onLegendSelect return a boolean for exactly this (fb076c8b on packet/vertical),
-  // where false means one thing only: the map was not ready.
-  // FORWARD-COMPATIBLE ON PURPOSE. That change is not on main yet, and a function with no explicit
-  // return yields undefined, which is FALSY -- so depending on it today would read every success as a
-  // failure and retry it, which is the very trap they warned about. So the boolean is authoritative
-  // WHEN IT IS A BOOLEAN, and until then the old inference stands with batch mode excluded.
-  const ok = (typeof applied === 'boolean')
-    ? applied
-    : (batchMode.value ? true : !!selectedKey.value);
-  if (!ok) { _pendingZoneId = zoneId; _markZoneState('applied-but-no-selection', zoneId); return false; }
+  // ★ THE COMPATIBILITY FALLBACK IS GONE, and this is the promised cleanup rather than a change of
+  // behaviour. onLegendSelect now returns an EXPLICIT boolean on all four of its paths — false when
+  // the tapestry layer is not up, true for batch mode (it fed the union), true for the un-isolate
+  // (the un-isolate IS the action) and true on success. So there is no path that yields undefined,
+  // and the `typeof applied === 'boolean'` capability check it guarded can never fall through.
+  //
+  // WHY IT EXISTED AT ALL, kept as the reason not to reintroduce the inference: I used to read
+  // !selectedKey.value as "it failed". That is a proxy for "did it ISOLATE", not for "did it work",
+  // and the two differ in exactly the two paths above — batch mode and the un-isolate both leave
+  // selectedKey unset while having succeeded. Retaining on that would have re-applied the zone and
+  // toggled it back OUT of the selection union. upg100-plugin caught that before it bit anyone, and
+  // added the boolean so the applier could be ASKED instead of inferred from.
+  if (!applied) { _pendingZoneId = zoneId; _markZoneState('applied-but-no-selection', zoneId); return false; }
   _markZoneState('applied', zoneId);
   return true;
 }