diff --git a/docs/superpowers/specs/2026-06-16-d2b-widget-generalization-design.md b/docs/superpowers/specs/2026-06-16-d2b-widget-generalization-design.md
index ad4fb859..12dcd6c5 100644
--- a/docs/superpowers/specs/2026-06-16-d2b-widget-generalization-design.md
+++ b/docs/superpowers/specs/2026-06-16-d2b-widget-generalization-design.md
@@ -51,6 +51,41 @@ real widget type) **dissolves**: the resolved Type is already correct. The facto
 just needs to *register* generic widgets for those Types instead of skipping them
 or dropping to `UiDatElement`.
 
+### 1.2 Why this matters beyond chat (the strategic purpose)
+
+Chat is the **proving ground**, not the destination. The payoff is that every
+future panel — **inventory, spell bar, vendor, character sheet, trade, skills** —
+becomes *assembled from dat data + a thin controller* instead of being hand-built
+from scratch. That is exactly how retail did it (`gm*UI::PostInit` everywhere on a
+shared `UIElement` toolkit), and it is the reason to do this pass carefully now.
+
+**What this pass gives all future windows (the foundation):**
+- The **generic widget toolkit** — `UiButton`, `UiField`, `UiScrollbar`, `UiText`,
+  `UiMenu` — built automatically by `DatWidgetFactory` from the dat layout.
+- The **thin-controller pattern** — find-widget-by-id → bind-live-data — proven and
+  cemented on chat. Inventory's controller, vendor's controller, etc. all take the
+  same shape.
+
+**What those specific windows additionally need (out of scope here; cheap once the
+pattern exists):**
+- **A few more widget Types** — inventory/vendor lists want `UiListBox` (Type 5)
+  and `UiPanel` (Type 8); item slots want **drag-drop**, which retail builds into
+  `UIElement_Field` (the decomp shows `Field` has `CatchDroppedItem` /
+  `MouseOverTop` drag-drop hooks — so drag-drop rides on the Field widget this pass
+  already builds). Each gets *registered when that window needs it* — which is
+  exactly why §3 bounds "full registry" to the Types chat+vitals use today rather
+  than speculatively building all 14 retail classes.
+- **The window manager** — open/close/z-order/persist, drag-bars (Type 2),
+  resize-grips (Type 9). This is the *other* half of Plan 2 — a sibling piece to
+  this one — and lands alongside, because pop-up/stackable windows (inventory,
+  vendor) need it.
+- **Per-domain data plumbing** — item icons, live container contents, vendor stock
+  lists. Game-state work, separate from the UI toolkit.
+
+This pass is therefore the **reusable toolkit + assembly pattern** that makes those
+later windows mostly-free to build. It is the load-bearing first half of the road
+to inventory/vendor/spell-bar, not the whole road.
+
 ---
 
 ## 2. Retail reference (the registry + the PostInit pattern)