sinfactura-types 1.10.261 → 1.10.263

package/dist/auth.d.ts

@@ -280,8 +280,16 @@ declare global {
      * - `wrong_totp` — the step-up code was wrong.
      * - `totp_replay` — an already-used code was presented again and rejected.
      * - `totp_locked` — brute-force lockout active on the TOTP leg.
+     * - `enrollment_required` — the credentials were correct and the store's
+     *   mandatory-2FA grace window has closed on a user who never enrolled. Like
+     *   `requires_2fa` this is NOT a completed login, but it is the opposite
+     *   diagnosis: `requires_2fa` means somebody stalled at a factor they HAVE,
+     *   this means they have none to present. ⚠️ Emitted on OPERATOR logins only
+     *   — the mandate is scoped to operator surfaces, and there is no customer
+     *   enrolment endpoint for a web mandate to be satisfiable against, so a
+     *   `kind: 'CUSTOMER'` row can never carry it.
      */
-    type LoginOutcome = 'success' | 'wrong_password' | 'disabled' | 'blocked' | 'requires_2fa' | 'wrong_totp' | 'totp_replay' | 'totp_locked';
+    type LoginOutcome = 'success' | 'wrong_password' | 'disabled' | 'blocked' | 'requires_2fa' | 'wrong_totp' | 'totp_replay' | 'totp_locked' | 'enrollment_required';
     /**
      * One row of `GET /auth?mode=login-history[&days=N]` — a storefront
      * customer's own login audit trail. The stored row reaches the wire

package/dist/customer.d.ts

@@ -191,6 +191,56 @@ declare global {
         lastReminderAt?: number;
         marketing?: CustomerMarketing;
         minBuy?: number;
+        /**
+         * How many appointments this customer has been marked `NO_SHOW` for, so a
+         * booking-time policy can be evaluated SERVER-SIDE against a durable number
+         * instead of against whatever date window a browser happened to read. Two
+         * operators with different date filters derive different counts for the same
+         * customer; this field is the one both of them share.
+         *
+         * ⚠️ **NOT A HISTORICAL TOTAL — it counts from the day it shipped.** This
+         * repo is forward-only and never backfills, so a customer with years of
+         * prior no-shows starts ABSENT and reads exactly like one who has never
+         * missed an appointment. A policy that auto-flags at 4+ will treat a
+         * long-standing offender as clean until they accumulate four MORE. That is a
+         * known consequence, not an oversight: what to do about it (a grace window,
+         * an operator override, showing the client-derived range count beside this
+         * one) is the app's decision — but it must not be a surprise.
+         *
+         * ⚠️ **Absence means "nothing recorded since this shipped"**, never "never
+         * no-showed". Coerce with `noShowCount ?? 0` for arithmetic, but do not
+         * render that fallback as a measured zero.
+         *
+         * ⚠️ **A LOWER BOUND.** The bump is issued after the appointment's own
+         * status write has already committed, and is deliberately best-effort: an
+         * appointment must still be markable `NO_SHOW` when the customer row has
+         * since been deleted. A lost bump undercounts by one and can never
+         * overcount — so a threshold that has been crossed was really crossed.
+         *
+         * ⚠️ **MONOTONIC, because `NO_SHOW` is TERMINAL — there is no decrement
+         * path.** `stacks/services/appointments.ts`'s transition table gives
+         * `NO_SHOW` an empty successor list, and the two writers that could move a
+         * terminal row (`cancelAppointment`, `rescheduleAppointment`) both condition
+         * on the status still being one of the four non-terminal ones. A booking
+         * marked `NO_SHOW` in error is corrected by creating a new appointment, not
+         * by reverting the old one. If a revert is ever added it owes a
+         * floor-guarded decrement in the SAME change, and the app must stop
+         * treating this as monotonic on the same day.
+         *
+         * ⚠️ **Written by an atomic `ADD noShowCount :one`**, like the `ADD balance`
+         * deltas on this same row. Never read-modify-write it: two operators
+         * clearing the same morning's board would both read the same value and one
+         * of the two events would vanish silently.
+         *
+         * ⚠️ Deliberately absent from `CUSTOMER_LIST_DISPLAY_FIELDS`, and therefore
+         * from `CUSTOMER_OPERATOR_BROADCAST_FIELDS`, which is DEFINED as that list
+         * plus frame mechanics. Behavioural data about a named person (Ley 25.326)
+         * does not belong on a store-wide list served to every staff-tier token, and
+         * a customer must not receive their own tally on a socket. It is served by
+         * the capability-gated `?customerId=` point read — the surface a booking
+         * screen already uses.
+         */
+        noShowCount?: number;
         /**
          * Unsettled debits denormalised onto this row so the accounts report can
          * bucket them by age without a per-customer query — the same

package/dist/order.d.ts

@@ -97,8 +97,58 @@ declare global {
          * drift. The APPOINTMENT is authoritative: it is the row the scheduler
          * writes under a conditional update, and a stale pointer here must be
          * treated as absent rather than followed.
+         *
+         * ⚠️ **This field, {@link Order.appointmentDate} and
+         * {@link Order.appointmentTime} are ONE stamp.** Every writer sets all
+         * three in a single `UpdateExpression` on this row (`SET` when a booking
+         * is made or moved, `REMOVE` when it is cancelled), so they cannot drift
+         * apart from ONE ANOTHER: all three present, or all three absent — the
+         * one exception being a row written before the date/time existed, which
+         * carries this pointer alone and is never backfilled. What can still lag
+         * is the stamp AS A WHOLE, because the write follows an already-committed
+         * appointment and is best-effort; that is the drift the paragraph above
+         * is about, and it is why the appointment stays authoritative.
          */
         appointmentId?: string;
+        /**
+         * The booked slot's LOCAL date, `YYYYMMDD` in the store's (Buenos Aires)
+         * time — a copy of `Appointment.date`, denormalised so a page of orders
+         * can render, sort and filter a «Turno» column without reading the
+         * appointments table at all. The three alternatives it replaces are each
+         * wrong in a different way: a range read over appointments misses any
+         * booking outside the window, and renders "sin turno" on exactly the
+         * orders an operator is hunting for; a per-row lookup is N+1 with no
+         * `orderId` filter to collapse it; and neither can sort a grid by a key
+         * that is not on the row.
+         *
+         * ⚠️ **NOT a Unix timestamp.** `20260315` is the fifteenth of March, not
+         * an instant. It copies the AUTHORITATIVE local pair the appointment row
+         * is keyed by (`${date}#${startTime}#${appointmentId}`) rather than the
+         * derived `Appointment.startTimestamp`, so this row and that key can
+         * never denote different slots.
+         *
+         * ⚠️ **Absent means "nothing to render", and that includes an order
+         * written before this field existed.** The platform is forward-only and
+         * nothing backfills, so a row may carry {@link Order.appointmentId} with
+         * no date or time: render no turno rather than inventing one, and follow
+         * the pointer only from a detail view that can afford the read. The next
+         * booking or reschedule on such an order stamps all three.
+         *
+         * ⚠️ A COPY, for display and ordering. The APPOINTMENT stays
+         * authoritative for whether the slot is still live — a cancel clears the
+         * stamp, but a clear that failed leaves it stale, so nothing that charges
+         * money or promises a customer a time may read this without the
+         * appointment.
+         */
+        appointmentDate?: number;
+        /**
+         * The booked slot's LOCAL start time, `HHmm` — a copy of
+         * `Appointment.startTime`, written and cleared by the same single update
+         * as {@link Order.appointmentDate} and under exactly the same rules:
+         * absent means nothing to render, and the appointment remains
+         * authoritative for whether the booking still stands.
+         */
+        appointmentTime?: string;
         /**
          * OPTIONAL. The eleven readers that forced this to be required have all
          * been closed, and the widening was gated on a measured zero-error

package/dist/store.d.ts

@@ -499,6 +499,55 @@ declare global {
                  */
                 nextSequence?: number;
             };
+            /**
+             * Per-store mandatory-2FA obligation for OPERATOR logins.
+             *
+             * ⚠️ **It lives on the store row and NOT in the plan entitlement map,
+             * and that placement is the whole design.** The `mandatory2fa` FeatureKey
+             * gates which TIERS may impose the obligation; this leaf records whether a
+             * store actually has. Every other FeatureKey GRANTS a capability, so losing
+             * it withdraws something. This one OBLIGES — so resolving it from the
+             * entitlement map would mean `graceSweep` silently UN-mandating 2FA when it
+             * writes `planTier: 'basico'` on a delinquent store at day 14. A security
+             * posture does not lapse because an invoice did.
+             *
+             * Verified rather than assumed: `graceSweep` writes only `status`,
+             * `planTier`, `canceledFromTier`, `canceledAt` and `updatedAt`, and writes
+             * them to the SUBSCRIPTION row — it touches neither `totp` nor store
+             * config. So an obligation kept here survives the downgrade **by
+             * construction**, with no special case for anyone to remember and nothing
+             * to re-check when the sweep changes.
+             *
+             * Forward-only: absent means no obligation, and nothing backfills it.
+             */
+            mandatory2fa?: {
+                /** Whether operator logins for this store require an enrolled second factor. */
+                enabled: boolean;
+                /**
+                 * ms-epoch the obligation was last turned ON. The grace window runs from
+                 * here.
+                 *
+                 * ⚠️ BE-stamped, never client-writable. A client that could set this
+                 * could set it far enough in the past to close the window on every
+                 * operator at once — which is a lockout, not a configuration change.
+                 */
+                since: number;
+                /**
+                 * Days after `since` during which an unenrolled operator still receives a
+                 * full session — flagged `mustEnroll2fa` — rather than being refused.
+                 *
+                 * ⚠️ **The window is what makes the mandate satisfiable at all, not a
+                 * courtesy.** `/auth/2fa/enroll` and `/auth/2fa/verify-enrollment` both sit
+                 * behind the `userToken` authorizer, and the shipped step-up challenge is
+                 * stateless — it mints no partial token, the client just re-submits the
+                 * credential. So refusing to mint a token leaves an unenrolled operator
+                 * with no way to reach the endpoint that would let them comply: the
+                 * mandate would brick its own remedy. Enrolment happens inside the window;
+                 * once it closes the refusal is safe, because anyone who missed it is
+                 * recovered by an ADMIN toggling `enabled` back off.
+                 */
+                graceDays: number;
+            };
         };
         ecommerce?: Ecommerce;
         photoURL: string;

package/dist/subscription.d.ts

@@ -83,7 +83,7 @@ declare global {
      * quietly missing a feature), but it means the caller must be updated in the
      * same change. Adding a key is never only additive downstream.
      */
-    type FeatureKey = 'maxOrdersMonth' | 'maxInvoicesMonth' | 'maxProducts' | 'maxUsers' | 'maxCustomers' | 'maxStores' | 'priceListsMax' | 'afipInvoicing' | 'suppliers' | 'domesticPayments' | 'stripePayments' | 'cashManagement' | 'multiStore' | 'importExport' | 'advancedReports' | 'customBranding' | 'prioritySupport' | 'whatsappCommerce' | 'aiFeatures' | 'mobileApp' | 'customDomain' | 'advancedPricing' | 'marketplaceChannels' | 'storefront' | 'loyalty' | 'marketing';
+    type FeatureKey = 'maxOrdersMonth' | 'maxInvoicesMonth' | 'maxProducts' | 'maxUsers' | 'maxCustomers' | 'maxStores' | 'priceListsMax' | 'afipInvoicing' | 'suppliers' | 'domesticPayments' | 'stripePayments' | 'cashManagement' | 'multiStore' | 'importExport' | 'advancedReports' | 'customBranding' | 'prioritySupport' | 'whatsappCommerce' | 'aiFeatures' | 'mobileApp' | 'customDomain' | 'advancedPricing' | 'marketplaceChannels' | 'storefront' | 'loyalty' | 'marketing' | 'mandatory2fa';
     /** Resolved entitlements for a specific tenant (matrix + overrides applied). */
     type ResolvedEntitlements = Record<FeatureKey, Entitlement>;
     /**

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "sinfactura-types",
-	"version": "1.10.261",
+	"version": "1.10.263",
 	"description": "Shared wire and entity contracts for the SINFACTURA platform.",
 	"type": "module",
 	"main": "dist/index.js",