snice 7.6.0 → 7.8.0

package/dist/react/SniceProvider.js

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/dist/react/SniceRouter.js

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/dist/react/index.js

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/dist/react/matchRoute.js

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/dist/react/useRequestHandler.js

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/dist/request-response.d.ts

@@ -23,5 +23,28 @@ export declare function request<T = any>(requestName: string, options?: RequestO
  * @param options Optional configuration
  */
 export declare function respond(requestName: string, options?: RespondOptions): (target: any, context: ClassMethodDecoratorContext) => void;
-export declare function setupResponseHandlers(instance: any, element: EventTarget): void;
+export interface SetupResponseHandlerOptions {
+    /**
+     * Runs on every incoming request and must settle before the responder method
+     * is invoked. Controllers use it to accept requests that arrive while their
+     * host is still becoming ready: discovery resolves at once, the answer
+     * follows as soon as the controller is attached.
+     */
+    claim?: () => Promise<void>;
+    /**
+     * Keep a `@respond({ daemon })` handler unregistered — and silent — when its
+     * daemon is not resolvable yet, instead of warning and dropping it. A caller
+     * that registers early (before the host is connected or ready) passes this
+     * and calls `setupResponseHandlers` again later; the second call registers
+     * whatever was deferred and warns then if it is still unresolvable.
+     */
+    deferUnresolvableDaemons?: boolean;
+}
+/**
+ * Helper to setup response handlers for elements and controllers.
+ *
+ * Safe to call more than once for the same instance: a handler already
+ * registered is skipped rather than double-bound.
+ */
+export declare function setupResponseHandlers(instance: any, element: EventTarget, options?: SetupResponseHandlerOptions): void;
 export declare function cleanupResponseHandlers(instance: any): void;

package/dist/symbols.cjs

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/dist/symbols.esm.js

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/dist/testing-dom.cjs

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/dist/testing-dom.esm.js

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/dist/transitions.cjs

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/dist/transitions.esm.js

@@ -1,5 +1,5 @@
 /*!
- * snice v7.5.1
+ * snice v7.7.0
  * A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.
  * (c) 2024
  * Released under the MIT License.

package/docs/ai/DEVELOPMENT.md

@@ -140,7 +140,7 @@ All CDN builds use the shared runtime (external `snice` imports). Load `snice-ru
 - IIFE: `.js` + `.min.js`
 - Sourcemaps + README
 
-**Size:** Runtime ~34KB gzip, components ~1-110KB each
+**Size:** Runtime ~34KB gzip, components ~1-111KB each
 
 **Features:**
 - Shared runtime (external snice imports)

package/docs/ai/components/calendar.md

@@ -33,12 +33,15 @@ cellSizing: 'square'|'stretch' = 'square'; // attribute: cell-sizing — square:
 
 - `calendar-change` -> `{ value: Date, calendar: SniceCalendarElement }`
 - `calendar-event-click` -> `{ event: CalendarEvent, calendar: SniceCalendarElement }`
+- `calendar-more-click` -> `{ date: Date, count: number, calendar: SniceCalendarElement }` — "+N more" chip clicked; does NOT fire `calendar-change`
 
 ## CSS Parts
 
 - `base` - Main calendar container
 - `header` - Header with title and navigation buttons
 - `grid` - Day cells grid
+- `more-chip` - Per-day "+N more" overflow chip
+- `event-bar` / `event-avatar` / `event-tooltip` / `event-popover` - Event bar internals
 
 ## Basic Usage
 
@@ -57,6 +60,11 @@ calendar.events = [
 // at week boundaries (squared corners on the continuing side, title repeats).
 // Concurrent events stack into lanes (start asc, longer first on ties);
 // max 3 lanes, deeper stacks collapse to a per-day "+N more" chip.
+// Chip: part="more-chip", role="button" tabindex=0 (Enter/Space), click ->
+// calendar-more-click { date, count }; the click never falls through to day
+// selection. Use it to open your own day/agenda view:
+//   calendar.addEventListener('calendar-more-click',
+//     (e) => showDay(e.detail.date, e.detail.count));
 // Bars: part="event-bar", click -> calendar-event-click.
 // Styling: color -> background; avatar?: string | {src?,name?,alt?} ->
 // <snice-avatar> on each bar (part="event-avatar"; name -> initials fallback);

package/docs/ai/components/tag-input.md

@@ -51,6 +51,10 @@ readonly labels: NodeList | null;
 - `tag-remove` -> `{ tag: string; index: number; value: string[] }`
 - `tag-change` -> `{ value: string[] }`
 
+Emitted only by tag edits (`addTag()`, `removeTag()`, and the user actions that
+call them). Assigning `value`, `clear()`, reset, and restoration are silent, so a
+`.value` binding fed from `tag-change` cannot loop.
+
 ## CSS Parts
 
 - `base` - Outer wrapper div

package/docs/ai/controllers.md

@@ -78,21 +78,37 @@ el.controller = UserController;                  // snice elements
 1. Controller instance created
 2. `element` property set
 3. Router application context passed (if available)
-4. Element's `ready` promise awaited
-5. `attach()` called
-6. `@context` handlers registered and caught up with the current Router context
-7. Observers set up
-8. Channel/response handlers set up
+4. Channel/response handlers (`@respond`) set up
+5. Element's `ready` promise awaited
+6. `attach()` called
+7. `@context` handlers registered and caught up with the current Router context
+8. Observers set up
 9. Event handlers set up
 10. `controller-attached` event dispatched
 
-Exception to step 4: `await attachController(this, ControllerClass)` inside the
+Exception to step 5: `await attachController(this, ControllerClass)` inside the
 host's own `@ready` handler attaches immediately because initial render is
 already complete. Awaiting that same host's `ready` would self-deadlock. An
 attachment targeting any other element still waits for the target's `ready`.
 This runtime safeguard does not make attaching a controller to a routed page a
 good architecture; pages should orchestrate directly.
 
+`@respond` is installed at step 4, before the wait — the same ordering elements
+use (an element installs `@respond` on connection, not at `ready`). A child's
+mount-time `@request` therefore finds the controller even while the host is
+still becoming ready: discovery resolves immediately, the request releases the
+step-5 wait, and the handler runs once `attach()` and the remaining setup are
+done. Without that ordering, a host whose `@ready` awaits a child that requests
+on mount would deadlock — the child waits for a responder that is waiting for
+the host's `ready` — and the attachment would fail. The responder body still
+never runs before `attach()`, so state built there is safe to use.
+
+`@respond('name', { daemon })` needs the host's app context to resolve its
+target, and that context is unreachable while the host is still disconnected
+(`attachController(el, C)` before `appendChild`). Resolvable → registered at
+step 4 like the rest; not resolvable → registered after step 6 instead of being
+dropped.
+
 **Detachment flow:**
 1. `detach()` called
 2. `element` property set to null

package/docs/components/calendar.md

@@ -75,6 +75,7 @@ interface CalendarEventAvatar {
 |-------|--------|-------------|
 | `calendar-change` | `{ value: Date, calendar: SniceCalendarElement }` | Fired when selected date changes |
 | `calendar-event-click` | `{ event: CalendarEvent, calendar: SniceCalendarElement }` | Fired when an event is clicked |
+| `calendar-more-click` | `{ date: Date, count: number, calendar: SniceCalendarElement }` | Fired when a day's `+N more` chip is clicked (or activated with Enter/Space). The day is not selected and `calendar-change` does not fire |
 
 ## CSS Parts
 
@@ -85,6 +86,11 @@ Style internal elements from outside the shadow DOM using `::part()`.
 | `base` | The main calendar container |
 | `header` | The header with month title and navigation buttons |
 | `grid` | The day cells grid |
+| `more-chip` | A day's `+N more` overflow chip |
+| `event-bar` | An event stripe (plus any `className` you set on the event) |
+| `event-avatar` | The `<snice-avatar>` rendered at the start of an event bar |
+| `event-tooltip` | The shared tooltip overlay shown on event hover |
+| `event-popover` | The popover opened by a `popover`-enabled event |
 
 ```css
 snice-calendar::part(base) {
@@ -135,6 +141,24 @@ shown; days with deeper stacks get a `+N more` chip. Each bar exposes a
 `part="event-bar"` for styling and dispatches `calendar-event-click` when
 clicked.
 
+The `+N more` chip is a control of its own: it exposes `part="more-chip"`, is
+keyboard-reachable (`role="button"`, Enter/Space), and dispatches
+`calendar-more-click` with the day it belongs to and how many events are
+hidden there. Its click never falls through to day selection, so opening a
+day view does not change the selected date:
+
+```typescript
+calendar.addEventListener('calendar-more-click', (e) => {
+  // e.detail.date  -> the day whose events overflowed
+  // e.detail.count -> how many events are hidden on that day
+  showDayAgenda(e.detail.date, calendar.getEventsForDate(e.detail.date));
+});
+```
+
+```css
+snice-calendar::part(more-chip) { color: #2563eb; }
+```
+
 Bars are styleable per event: `color` sets the background, `avatar` renders a
 small `<snice-avatar>` at the start of each bar (`part="event-avatar"`) — an
 image when `src` is given, initials from `name` otherwise — and `className` is

package/docs/components/tag-input.md

@@ -55,7 +55,12 @@ A chip/tag-style input field where users can add tags by typing and pressing Ent
 |-------|--------|-------------|
 | `tag-add` | `{ tag: string, value: string[] }` | A new tag was added |
 | `tag-remove` | `{ tag: string, index: number, value: string[] }` | A tag was removed |
-| `tag-change` | `{ value: string[] }` | The tag list changed (add or remove) |
+| `tag-change` | `{ value: string[] }` | A tag was added or removed |
+
+`tag-add`, `tag-remove`, and `tag-change` describe tag edits: typing, removing a
+tag, selecting a suggestion, `addTag()`, and `removeTag()`. Assigning `value`,
+calling `clear()`, form reset, and form restoration change the tags silently, so
+binding `value` to the `tag-change` payload never re-enters.
 
 ## CSS Parts
 

package/docs/controllers.md

@@ -128,15 +128,15 @@ through the element's reactive properties or events.
 1. Controller instance is created
 2. `element` property is set
 3. Router application context is passed (if available)
-4. Element's `ready` promise is awaited
-5. `attach()` method is called
-6. `@context` handlers are registered and caught up with the current Router context
-7. Observers are set up
-8. Channel/response handlers are set up
+4. Channel/response handlers (`@respond`) are set up
+5. Element's `ready` promise is awaited
+6. `attach()` method is called
+7. `@context` handlers are registered and caught up with the current Router context
+8. Observers are set up
 9. Event handlers are set up
 10. `controller-attached` event is dispatched
 
-The step-4 wait has one safe exception: when an element calls
+The step-5 wait has one safe exception: when an element calls
 `await attachController(this, ControllerClass)` from its own `@ready` handler,
 Snice attaches immediately. Initial rendering has already completed at that
 point, and waiting for `ready` would otherwise create a self-deadlock because
@@ -145,6 +145,57 @@ other element still awaits that element's `ready` promise.
 This runtime safeguard does not make attaching a controller to a routed page a
 good architecture; pages should orchestrate directly.
 
+#### Responders Are Reachable Before the Host Is Ready
+
+`@respond` handlers are installed at step 4, *before* the wait — the same
+ordering elements use, where `@respond` is installed on connection rather than
+at `ready`. This matters for the common shape where a host's `@ready` waits on
+a child that makes a request as it mounts:
+
+```typescript
+@element('report-host')
+class ReportHost extends HTMLElement {
+  @ready()
+  async onReady() {
+    // The host cannot finish becoming ready until the child does...
+    await this.chart.ready;
+  }
+
+  @render()
+  renderContent() { return html`<report-chart></report-chart>`; }
+}
+
+@element('report-chart')
+class ReportChart extends HTMLElement {
+  @request('report-data')
+  async *load(): Response<void> {
+    // ...and the child cannot finish until something answers this.
+    this.data = await (yield { range: '30d' });
+  }
+
+  @ready()
+  async onReady() { await this.load(); }
+}
+```
+
+With `<report-host controller="report-controller">` answering `report-data`, the
+child's request reaches the controller while the host's `ready` is still
+pending: discovery resolves immediately, the request releases the step-5 wait,
+and the responder runs once `attach()` and the remaining setup have completed.
+If the responder were only installed after `ready`, the two sides would wait on
+each other until a timeout fired and the attachment would fail outright.
+
+The responder *body* still never runs before `attach()`, so anything the
+controller builds in `attach()` is safe to use inside a `@respond` method.
+
+`@respond('name', { daemon: 'x' })` has one extra condition. A daemon target is
+resolved through the host's app context, which is unreachable while the host is
+still disconnected — the shape where `attachController(el, Controller)` runs
+before `el` is appended. When the context already resolves, the daemon-scoped
+responder registers at step 4 with every other responder; when it does not, it
+registers after `attach()` instead of being dropped, exactly where it registered
+before.
+
 ### Detachment Flow
 
 1. `detach()` method is called

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "snice",
-  "version": "7.6.0",
+  "version": "7.8.0",
   "type": "module",
   "description": "A decorator-driven web component library with routing, controllers, daemons, and 130+ UI components. For better coding-agent results, run npx snice init-ai.",
   "main": "dist/index.cjs",