@reblu/site-blocks 0.12.0 → 0.12.1

package/dist/index.d.cts

@@ -752,13 +752,20 @@ declare function AddedToCartToast({ status, productName, quantity, imageUrl, car
 /**
  * `CheckoutLoginPrompt` — the "login prompt hook" the checkout flow needs
  * (REB-829): a guest-checkout identification dialog offering "continue with
- * this email" (so the SITE can check for an existing account via
- * `client.shop.checkEmail`) or "continue as guest" outright. Fully
- * controlled/presentational — it performs NO fetch itself (unlike
- * demo-site's original `CheckoutLoginModal`, which called
- * `/api/shop/check-email` internally); the consuming SITE owns `email`
- * state and the `checkEmail` call, and drives `checking`/`error` from its
- * own result.
+ * this email" or "continue as guest" outright. Fully controlled/presentational
+ * — it performs NO fetch itself; the consuming SITE owns `email` state and
+ * decides what `onSubmitEmail` does.
+ *
+ * Never reveal whether an account exists (REB-834). Do NOT wire
+ * `onSubmitEmail` to `client.shop.checkEmail` (deprecated, it always answers
+ * `{ exists: false }`) or build any UI on an `exists` answer. Treat both
+ * actions the same way for every email: `onSubmitEmail` carries the typed
+ * email into the checkout (or into the SITE's own login page), and
+ * `onContinueAsGuest` proceeds without it. If a guest's email belongs to an
+ * account, the server links the order to it after payment — the browser is
+ * never told before. `checking`/`error` remain for a SITE's own synchronous
+ * work (e.g. saving the email to its checkout state); leave them unset
+ * otherwise.
  */
 interface CheckoutLoginPromptLabels {
     title: string;
@@ -793,6 +800,13 @@ declare function CheckoutLoginPrompt({ open, email, onEmailChange, onClose, onSu
  * dependency surface minimal); the consuming SITE owns validation and wires
  * its own `onSubmit`.
  *
+ * Account handling (REB-834): render the same form for every email. The
+ * `loginPrompt` slot is a static «Iniciar sesión o continuar como invitado»
+ * offer — never a branch on whether the typed email has an account (the
+ * deprecated `client.shop.checkEmail` always answers `{ exists: false }`). If
+ * a guest's email belongs to an account, the server links the order to it
+ * after payment.
+ *
  * Scope note: shipping/billing address collection is intentionally OUT of
  * this component — those field sets vary by tenant shop config (shipping
  * enabled/disabled, invoicing requirements) far more than the guest-email +

package/dist/index.d.ts

@@ -752,13 +752,20 @@ declare function AddedToCartToast({ status, productName, quantity, imageUrl, car
 /**
  * `CheckoutLoginPrompt` — the "login prompt hook" the checkout flow needs
  * (REB-829): a guest-checkout identification dialog offering "continue with
- * this email" (so the SITE can check for an existing account via
- * `client.shop.checkEmail`) or "continue as guest" outright. Fully
- * controlled/presentational — it performs NO fetch itself (unlike
- * demo-site's original `CheckoutLoginModal`, which called
- * `/api/shop/check-email` internally); the consuming SITE owns `email`
- * state and the `checkEmail` call, and drives `checking`/`error` from its
- * own result.
+ * this email" or "continue as guest" outright. Fully controlled/presentational
+ * — it performs NO fetch itself; the consuming SITE owns `email` state and
+ * decides what `onSubmitEmail` does.
+ *
+ * Never reveal whether an account exists (REB-834). Do NOT wire
+ * `onSubmitEmail` to `client.shop.checkEmail` (deprecated, it always answers
+ * `{ exists: false }`) or build any UI on an `exists` answer. Treat both
+ * actions the same way for every email: `onSubmitEmail` carries the typed
+ * email into the checkout (or into the SITE's own login page), and
+ * `onContinueAsGuest` proceeds without it. If a guest's email belongs to an
+ * account, the server links the order to it after payment — the browser is
+ * never told before. `checking`/`error` remain for a SITE's own synchronous
+ * work (e.g. saving the email to its checkout state); leave them unset
+ * otherwise.
  */
 interface CheckoutLoginPromptLabels {
     title: string;
@@ -793,6 +800,13 @@ declare function CheckoutLoginPrompt({ open, email, onEmailChange, onClose, onSu
  * dependency surface minimal); the consuming SITE owns validation and wires
  * its own `onSubmit`.
  *
+ * Account handling (REB-834): render the same form for every email. The
+ * `loginPrompt` slot is a static «Iniciar sesión o continuar como invitado»
+ * offer — never a branch on whether the typed email has an account (the
+ * deprecated `client.shop.checkEmail` always answers `{ exists: false }`). If
+ * a guest's email belongs to an account, the server links the order to it
+ * after payment.
+ *
  * Scope note: shipping/billing address collection is intentionally OUT of
  * this component — those field sets vary by tenant shop config (shipping
  * enabled/disabled, invoicing requirements) far more than the guest-email +