platform-types 1.10.738 → 1.10.739

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/auth.d.ts CHANGED
@@ -153,18 +153,23 @@ declare global {
153
153
  * (`storeContactFooter`), and `phone` also on the emisor block of every
154
154
  * invoice PDF.
155
155
  *
156
- * ⚠️ A STORE `email` is also a live DESTINATION from the first day, so the
157
- * client must confirm it is a MONITORED business address, not just a
158
- * public one:
159
- * - it is the `Reply-To` of every store-branded mail to the store's
160
- * customers sent under the platform envelope, so a customer's answer goes
161
- * there;
162
- * - it receives the storefront's survey responses (suppressed for a demo
163
- * store);
164
- * - it is the one recipient of the scheduled sales digest, once the store
165
- * opts in and is entitled to it;
166
- * - it is the last-resort recipient of an integration re-authorisation mail,
167
- * used when the request names no address and the founding admin has none.
156
+ * ⚠️ A STORE `email` becomes a DESTINATION once its inbox confirms it, so
157
+ * the client must confirm it is a MONITORED business address, not just a
158
+ * public one. Registering with it mails a single-use confirmation link
159
+ * there (platform-branded, valid 48 h), and until that link is followed:
160
+ * - customer-facing store-branded mail sent under the platform envelope
161
+ * carries NO `Reply-To`; once confirmed, the address is that `Reply-To`,
162
+ * so a customer's answer goes there. Customer mail never falls back to
163
+ * the founder's address;
164
+ * - the storefront's survey responses (suppressed for a demo store) and
165
+ * the scheduled sales digest (once the store opts in and is entitled
166
+ * to it) go to the founding admin's verified login email instead, and
167
+ * to no one when that account is disabled or its email unverified;
168
+ * once confirmed, they go to this address. Without a store `email`
169
+ * neither is sent at all;
170
+ * - an integration re-authorisation mail that names no address goes to
171
+ * the founding admin's verified login email, and to this address only
172
+ * when that one is unusable AND this one is confirmed.
168
173
  *
169
174
  * STRICT, like `acquisition`: an unknown key refuses the WHOLE
170
175
  * registration, and so does an empty object — send at least one key or
package/dist/store.d.ts CHANGED
@@ -409,6 +409,34 @@ declare global {
409
409
  /** Unix ms — the registration's own `createdAt`, the instant the STORE item is stamped with. */
410
410
  capturedAt: number;
411
411
  }
412
+ /**
413
+ * The ownership check on the STORE row's `email`: whether whoever reads that
414
+ * inbox has confirmed it, by following a single-use link the api mailed to it.
415
+ *
416
+ * ⚠️ Server-owned: no request body may set it. Every write that puts a NEW
417
+ * `email` on the row stamps it `pending` for that exact address; the
418
+ * confirmation link flips it to `verified` only while the row still holds
419
+ * that address. Clearing `email` KEEPS the record: it names the address it
420
+ * is about, so it can only vouch for a later `email` that really is that
421
+ * verified address.
422
+ *
423
+ * ABSENT means verified (rows that predate it are grandfathered); a PRESENT
424
+ * record that is `null` or malformed counts as unverified. The one reader of
425
+ * "verified" is `isStoreEmailVerified` (`stacks/helpers/storeEmailVerified.ts`).
426
+ */
427
+ interface StoreEmailVerification {
428
+ /** `pending` until the link mailed to `address` is followed, then `verified`. */
429
+ status: 'pending' | 'verified';
430
+ /**
431
+ * The normalised address the record is about. A record whose `address` is
432
+ * not the row's current `email` says nothing about that email.
433
+ */
434
+ address: string;
435
+ /** Unix ms — when the api stamped it `pending`. */
436
+ requestedAt: number;
437
+ /** Unix ms — when the link was followed. Present only once `verified`. */
438
+ verifiedAt?: number;
439
+ }
412
440
  /**
413
441
  * The shop's public address, as every link minter and every client reads it.
414
442
  * Computed by the api from server-owned row fields that never reach a client
@@ -529,6 +557,16 @@ declare global {
529
557
  * and every operator-created tenant.
530
558
  */
531
559
  registrationPrefill?: StoreRegistrationPrefill;
560
+ /**
561
+ * Whether `email` has been confirmed by its inbox. Admin-only; written only
562
+ * by the server.
563
+ *
564
+ * ⚠️ **Absent means verified.** A row whose `email` predates verification
565
+ * carries no record, and that address is grandfathered as verified — it is
566
+ * never backfilled. Only a record that is `pending`, or `verified` for an
567
+ * address other than the current `email`, makes the email unverified.
568
+ */
569
+ emailVerification?: StoreEmailVerification;
532
570
  /**
533
571
  * Response-time join, not a persisted Store attribute — and TWO different
534
572
  * shapes depending on the endpoint: `GET /tenants` (SUPERVISOR) attaches the
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "platform-types",
3
- "version": "1.10.738",
3
+ "version": "1.10.739",
4
4
  "description": "Shared wire and entity contracts for the platform.",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",