@hachther/akilio-widget 1.0.0 → 1.1.0

package/README.md

@@ -774,3 +774,53 @@ Use `data-starter-prompts='[]'` to hide prompts. Dedicated logo/name attributes
 override corresponding values in `data-theme`. Malformed prompt JSON falls back
 to configuration defaults. Custom React launchers and external HTML buttons using
 `launcher: 'hidden'` with `open()`, `close()`, or `toggle()` remain supported.
+### Direct product-card cart actions
+
+Product cards and product details expose Add to cart automatically when backend
+capability discovery includes executable `commerce.add_to_cart`. Available
+variants receive direct actions independent of the LLM response. Clicking the
+button supplies consent; backend capability confirmation is still executed.
+Shopify products on their own storefront use the Shopify adapter. The selected variant is added through
+the Shopify Ajax Cart API, sharing the website's browser cart, without a chat or
+LLM round trip. Cards retain their variant selector, display update feedback,
+and link to the storefront cart after success. Themes can listen for the
+`akilio:cart-updated` window event to refresh their cart counter or drawer.
+
+The backend product payload supplies `cart_provider: "shopify"` to select the
+native adapter when applicable. Other products execute the advertised backend
+cart capability. Actions are hidden for unavailable products and blocked
+business-rule decisions. A backend-managed cart does not necessarily share the
+website browser cart; direct website-cart adapters beyond Shopify are not implemented.
+
+### Voice messages
+
+The composer now supports recording, playback preview, send, and cancel on browsers
+with MediaRecorder and microphone permission. HTTPS (or supported localhost access)
+is required. Recording is capped at five minutes and 10 MiB. EN/FR copy can be
+overridden through the existing translation/copy configuration.
+
+Sending uploads to the authenticated public chat voice endpoint, polls private
+transcription status, then submits the transcript through normal chat. The backend
+must include the shared voice migrations and a transcription worker (or the existing
+explicit development synchronous-processing mode). Voice input produces text replies;
+this does not enable synthesized voice responses.
+
+Voice uploads and polling use the existing widget bearer-token/origin mechanism.
+Microphone capture stops when the panel closes or consent becomes unavailable.
+Update your distributed bundle to make these controls available in deployed widgets.
+
+### Email verification
+
+Once a conversation exists, the widget offers **Verify your email** above the composer. The inline form requests an email code, displays the server's masked email, confirms the code, and restores the verified badge from the conversation's server session. It supports resend cooldowns, expiry, cancellation, retry limits, unavailable providers, and English/French copy overrides (`identity*` keys).
+
+Verification uses the dedicated `/customer-identity/verifications/`, `/{id}/confirm/`, `/{id}/resend/`, and `/customer-identity/session/` routes under `apiBaseUrl`, with the existing widget authentication. Codes are submitted directly as strings and cleared from the input; they are never chat messages or widget analytics events. Challenge IDs and pending questions are held only in memory. The server determines verification and authorization.
+
+A chat response (including a streaming final response) may include `identity_verification_required: { methods: ['email'], purpose: 'identity' }` (`step_up` is also supported). This opens the form. On successful confirmation and an authoritative session lookup, the widget submits the paused question once in the same conversation without duplicating the user's chat bubble. Cancel or a new question discards that continuation. This is a new optional response contract; the backend must emit it when protected actions require verification. It does not itself enforce access to protected actions.
+
+The actual verification provider remains a backend integration. Until that provider is configured, delivery returns an unavailable message. No eSauti calls or credentials are implemented in the widget.
+
+### Multiple widget installations
+
+Create installations in Portal → Widget. Each has its own public key, assigned Agent, appearance and allowed domains. Use `widgetKey` with the React component or `data-widget-key` on the script tag. The existing `projectKey` / `data-project-key` spelling remains supported. Keys identify installations; the workspace remains the tenant boundary. New conversations use the assigned Agent, while existing conversations retain their original Agent.
+
+Managed installations: omit host text/theme and presentation props to follow published Agent text and widget appearance. Public configuration supplies layout, launcher, tour, sound and contextual-prompt options; explicit host props still take precedence. Existing embeds with inline overrides must remove those overrides or replace their snippet once to follow portal publications.