@adia-ai/web-modules 0.6.34 → 0.6.35

package/CHANGELOG.md

@@ -1,5 +1,46 @@
 # Changelog — @adia-ai/web-modules
 
+## [0.6.35] — 2026-05-24
+
+### Fixed — `<admin-shell>` warns at first click when `AdminSidebar` / `AdminCommand` is not registered (FB-55)
+
+- **Per-component import path silently no-opped sidebar toggles.** When a consumer imported `@adia-ai/web-modules/shell/admin-shell` (per-component path) instead of `@adia-ai/web-modules/shell` (cluster barrel), only `AdminShell` registered — `<admin-sidebar>` rendered (CSS targets by tag) but stayed an unupgraded `HTMLElement` with no `.toggle()` method. The optional-chain `sidebar?.toggle?.()` swallowed the no-op: zero console output. Same trap on `<admin-command>` via `command?.show?.()`. Documented in adia-ui-kit setup checklist (v2.27.1) but a substrate warn was missing — consumers who didn't read the checklist saw zero diagnostic at first click.
+- **NEW: substrate warns at first click**, exactly once per offender (deduped via `static #warned = new WeakSet()`). The warn names the element, the missing class, the per-component-vs-cluster-barrel import remediation, and a "Closes FB-55 silent-failure trap" anchor. Refires only if a new offender appears (dynamic insertion). Files: `shell/admin-shell/admin-shell.js`, `shell/admin-shell/admin-shell.test.js`.
+- **Bonus refactor (same patch): the per-button `addEventListener` at `connected()` time was replaced with delegated click handling on the host.** Discovered while authoring the FB-55 regression test — happy-dom's `document.body.innerHTML = …` path connects the parent BEFORE children land, so `this.querySelectorAll('[data-sidebar-toggle]')` returned empty at connect time. Real browsers parse children-first, so the bug never surfaced in production — but the same shape also silently dropped wiring for any button added AFTER connect (router swaps, deferred `.innerHTML += …`). Delegation re-resolves children on every click. Trade-off: one extra host listener vs. one-per-button; resilience win is large. 8/8 admin-shell tests pass.
+
+### Fixed — `editor-shell.examples.html` slot vocabulary aligned with yaml SoT (FB-57)
+
+- **Demo + prose drifted from yaml.** The `editor-shell.examples.html` "Basic shape" code-block demonstrated `<editor-toolbar>` using `<span slot="icon">`, `<span slot="heading">`, `<span slot="description">` — but `editor-toolbar.yaml` declares `title` / `status` / `action` / `action-leading` (matching `editor-shell.bespoke.css`'s positioning and `editor-toolbar.examples.html`'s per-component demo). Three-source agreement, demo dissented. The "Cluster vocabulary" prose bullet (line ~85) carried the same wrong vocabulary, so an agent reading the prose instead of the code-block was still misled.
+- **Fix**: demo code-block `slot="icon|heading|description"` → `slot="action-leading|title|status"`; prose bullet rewritten to match. Sweep-grep `slot="(icon|heading|description)"` under `editor/` now zero. No JS/CSS/API changes. Files: `editor/editor-shell/editor-shell.examples.html`.
+
+### Changed — `<editor-sidebar>` declares `[collapsible]` as reflected CSS-state marker (FB-61)
+
+- **Three-way drift across yaml / JS / demos resolved by aligning yaml + JS, not by changing behavior.** `editor-sidebar.yaml`'s `props:` block did not declare `collapsible`; the JS docstring + canonical demos (`editor-sidebar.examples.html`) used `<editor-sidebar slot="leading" collapsible>`; the JS itself never read the attribute — `.toggle()` / `.collapse()` / `.expand()` execute unconditionally. Compare to `<admin-sidebar>` which DOES declare `collapsible` in `static properties` (line 50) but also doesn't gate the public methods — same shape; the attribute is a CSS-state marker (consumers key CSS rules like `[collapsible] [data-toggle-handle]` off it), not a behavior gate.
+- **Fix**: `editor-sidebar.yaml` props block now declares `collapsible: { type: boolean, default: false, reflect: true }`; `editor-sidebar.js` `static properties` adds the same entry. Behavior unchanged (`.toggle()` stays always-callable). Yaml SoT now accurately reflects what the substrate observes. Demos stay valid. Sibling `<admin-sidebar>` convention preserved. Kit's `KNOWN_SUBSTRATE_YAML_DRIFT` allowlist can drop the editor-sidebar `[collapsible]` entry next cycle. Files: `editor/editor-sidebar/editor-sidebar.{yaml,js,d.ts,a2ui.json}`.
+
+### Changed — chat-cluster substrate sources strip dead `submit-on-enter` attribute (FB-63)
+
+- **`submit-on-enter` was decorative across every chat surface that documented it.** The substrate corpus + a2ui rules + canonical demos all used `<chat-input-ui submit-on-enter>` (and `<input-ui submit-on-enter>` in two adjacent prose bullets), but no implementation observed the attribute. Verified end-to-end: `chat-input.js` `static properties` doesn't include it; the keydown→submit handler lives in `textarea.class.js:97-106` and fires `submit` on Enter (without Shift) unconditionally — same in `input.class.js:713-727` for the plain `<input-ui>` primitive. The "only chat-input-ui reflects the [submit-on-enter] attribute" claim in `input.yaml` was factually wrong: NONE of the three input primitives observed it.
+- **Substrate-side fix**: `submit-on-enter` stripped from `chat-shell.examples.html` (4 occurrences), `chat-composer.examples.html` (3 occurrences), `patterns/chat-shell/chat-shell.examples.html` (1 occurrence), `chat-composer.js` docstring (1 occurrence), `chat-shell.yaml` (2 occurrences), `chat-composer.yaml` (2 occurrences). Plus `chat-input.yaml` event description and `chat-input.js` docstring now state the truth: "Enter→submit is unconditional, delegated from the inner `<textarea-ui>` which always emits `submit` on Enter without Shift. There is no `[submit-on-enter]` opt-in or opt-out attribute." Bundled in the same patch via `@adia-ai/web-components` (see its changelog).
+- Files (this package): `chat/chat-shell/chat-shell.{examples.html,yaml,a2ui.json}`, `chat/chat-composer/chat-composer.{examples.html,yaml,js,a2ui.json}`.
+
+### Changed — `<confirm-dialog-ui>` internals adopt canonical `slot=` vocabulary (was `part=`)
+
+- **`confirm-dialog.js` stamped its header/body/footer subtree with a mix of `part="..."` hooks** (header / header-icon / title / body / description / extra / footer / cancel / confirm). The dialog family's canonical vocabulary is `slot="..."` (icon / heading / description / action / action-leading / body / footer / close — same slots `<drawer-ui>`, `<admin-topbar>`, `<editor-toolbar>` all consume). Refactored so:
+  - Stamped icon: `slot="icon"` (was `part="header-icon"`)
+  - Stamped title: `slot="heading"` (was `part="title"`)
+  - Stamped description: `slot="description"` and moved into the **header** (was `part="description"` in the body — wrong region per card-ui convention)
+  - Stamped body wrapper: `slot="body"` only (dropped `part="body"`)
+  - Stamped footer wrapper: `slot="footer"` only (dropped `part="footer"`)
+  - Cancel / Confirm buttons: `slot="action"` + `data-confirm-action="cancel|confirm"` (was `part="cancel|confirm"`). Both buttons sit in the trailing action cluster per the modal-ui footer's flex-end alignment; `data-confirm-action` distinguishes them for JS + CSS without re-introducing the legacy `part=` hook.
+  - Inner modal-ui: no `part="modal"` attribute (it's the only `modal-ui` child — query selector is `:scope > modal-ui`).
+- **`confirm-dialog.css` rules retargeted** from `:scope [part="..."]` to `:scope [slot="..."]`. The header layout now uses a 2-col grid (icon | heading+description) so the icon vertically centers against the heading+description block; collapses to single-row when no description child is rendered. `confirm-variant="ghost"` + `[loading]` rules now target `[data-confirm-action="confirm"]` / `[data-confirm-action="cancel"]`.
+- Tests updated (22/22 passing). Files: `feedback/confirm-dialog/confirm-dialog.{js,css,test.js}`.
+
+### Fixed — `<date-range-selector-ui>` segmented preset clicks now propagate into the inner picker
+
+- **Clicking a segmented preset chip (`7d` / `30d` / `90d` / `ytd` / etc.) resolved the range on the host (updating `from` / `to` / `value` + dispatching `range-change`) but never pushed the resolved range onto `this.#picker.value`.** Result: the inner `<date-range-picker-ui>` stayed at its prior state — opening the picker afterward showed empty or stale dates. The render() method synced the segmented chip's selection from `this.value` but had no corresponding sync for the picker's value. Fix: `render()` now mirrors the host's resolved `from`/`to` onto `this.#picker.value` as a JSON-stringified range (the picker's `value` is a JSON-string at the attribute boundary per its `UIFormElement.properties` contract). Diff guard (`if (this.#picker.value !== targetValue)`) prevents render loops if the picker re-emits change. Files: `dashboard/date-range-selector/date-range-selector.js`.
+
 ## [0.6.34] — 2026-05-23
 
 ### Added — Wave 1 + Wave 2 component registrations

package/chat/chat-composer/chat-composer.a2ui.json

@@ -57,7 +57,7 @@
     ],
     "slots": {
       "default": {
-        "description": "Default — primary input child (typically <chat-input-ui> or <input-ui submit-on-enter>)."
+        "description": "Default — primary input child (typically <chat-input-ui>; <input-ui> also works — both emit a `submit` event on Enter without Shift)."
       },
       "attach": {
         "description": "Future — attachment trigger button (paperclip icon to upload)."

package/chat/chat-composer/chat-composer.js

@@ -1,6 +1,6 @@
 /**
  * <chat-composer disabled?>
- *   <chat-input-ui placeholder="..." submit-on-enter></chat-input-ui>
+ *   <chat-input-ui placeholder="..."></chat-input-ui>
  *   <!-- future: <button-ui slot="attach" icon="paperclip">  -->
  * </chat-composer>
  *

package/chat/chat-composer/chat-composer.yaml

@@ -38,8 +38,9 @@ events:
 slots:
   default:
     description: >-
-      Default — primary input child (typically <chat-input-ui> or
-      <input-ui submit-on-enter>).
+      Default — primary input child (typically <chat-input-ui>;
+      <input-ui> also works — both emit a `submit` event on Enter
+      without Shift).
   attach:
     description: >-
       Future — attachment trigger button (paperclip icon to upload).
@@ -64,7 +65,9 @@ a2ui:
     - >-
       chat-composer is the bespoke replacement for legacy
       <chat-input-ui data-chat-input> inside <chat-shell>. Place an
-      inner <chat-input-ui submit-on-enter> as the primary input.
+      inner <chat-input-ui> as the primary input — it emits `submit`
+      on Enter without Shift (unconditional; delegated from the
+      inner textarea).
     - >-
       The host listens for 'composer-submit' on the composer (not on
       the inner input). The event detail mirrors the inner submit

package/chat/chat-shell/chat-shell.a2ui.json

@@ -130,7 +130,7 @@
     ],
     "slots": {
       "default": {
-        "description": "Bespoke children compose here in document order — typically <chat-thread> (with optional <chat-empty> inside) for the message surface, then <chat-composer> wrapping a <chat-input-ui submit-on-enter> for the input. Optional <chat-header>, <chat-sidebar slot=\"leading|trailing\">, <chat-status>."
+        "description": "Bespoke children compose here in document order — typically <chat-thread> (with optional <chat-empty> inside) for the message surface, then <chat-composer> wrapping a <chat-input-ui> for the input. Optional <chat-header>, <chat-sidebar slot=\"leading|trailing\">, <chat-status>."
       }
     },
     "states": [

package/chat/chat-shell/chat-shell.yaml

@@ -112,9 +112,9 @@ slots:
     description: >-
       Bespoke children compose here in document order — typically
       <chat-thread> (with optional <chat-empty> inside) for the message
-      surface, then <chat-composer> wrapping a <chat-input-ui
-      submit-on-enter> for the input. Optional <chat-header>,
-      <chat-sidebar slot="leading|trailing">, <chat-status>.
+      surface, then <chat-composer> wrapping a <chat-input-ui> for
+      the input. Optional <chat-header>, <chat-sidebar
+      slot="leading|trailing">, <chat-status>.
 
 states:
   - name: idle
@@ -131,8 +131,8 @@ a2ui:
       chat-shell takes bespoke chat-* children only. The canonical
       composition is <chat-thread> (with optional first-child
       <chat-empty>) followed by <chat-composer> wrapping a
-      <chat-input-ui submit-on-enter>. Add <chat-header> /
-      <chat-sidebar> / <chat-status> as needed.
+      <chat-input-ui>. Add <chat-header> / <chat-sidebar> /
+      <chat-status> as needed.
     - >-
       Don't nest col-ui / row-ui or generic layout primitives directly
       inside chat-shell — the shell's CSS reads child tag selectors to