sinfactura-types 1.10.261 → 1.10.262

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/package.json

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