@fiado/type-kit 3.289.0 → 3.290.0

package/bin/benefitCenter/enums/BenefitFlowEnum.d.ts

@@ -0,0 +1,11 @@
+export declare enum BenefitFlowEnum {
+    TOPUPS = "TOPUPS",
+    BILL_PAYMENT = "BILL_PAYMENT",
+    CREDIT = "CREDIT",
+    INSURANCE = "INSURANCE",
+    DONATION = "DONATION",
+    PHARMACY = "PHARMACY",
+    REMITTANCE = "REMITTANCE",
+    /** Fondeo de wallet PCF con efectivo via provider externo (Equality/Passport, OpenPay, …) — spec 13. */
+    WALLET_FUNDING = "WALLET_FUNDING"
+}

package/bin/benefitCenter/enums/BenefitFlowEnum.js

@@ -0,0 +1,15 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.BenefitFlowEnum = void 0;
+var BenefitFlowEnum;
+(function (BenefitFlowEnum) {
+    BenefitFlowEnum["TOPUPS"] = "TOPUPS";
+    BenefitFlowEnum["BILL_PAYMENT"] = "BILL_PAYMENT";
+    BenefitFlowEnum["CREDIT"] = "CREDIT";
+    BenefitFlowEnum["INSURANCE"] = "INSURANCE";
+    BenefitFlowEnum["DONATION"] = "DONATION";
+    BenefitFlowEnum["PHARMACY"] = "PHARMACY";
+    BenefitFlowEnum["REMITTANCE"] = "REMITTANCE";
+    /** Fondeo de wallet PCF con efectivo via provider externo (Equality/Passport, OpenPay, …) — spec 13. */
+    BenefitFlowEnum["WALLET_FUNDING"] = "WALLET_FUNDING";
+})(BenefitFlowEnum || (exports.BenefitFlowEnum = BenefitFlowEnum = {}));

package/bin/loanConfig/enums/ModifiableByRoleEnum.d.ts

@@ -0,0 +1,11 @@
+/**
+ * Rol RBAC mínimo que puede modificar un parámetro (RBAC a nivel de parámetro, modelo-datos §8).
+ * `retailer_admin` = "Admin VentasLuga" de M6 §8. Valores = identificadores de rol de RBAC F0.
+ * TD-004: confirmar mapeo super_admin ↔ platform_super_admin con el naming real de F0.
+ * @enum {string}
+ */
+export declare enum ModifiableByRoleEnum {
+    SUPER_ADMIN = "super_admin",
+    SOFOM_ADMIN = "sofom_admin",
+    RETAILER_ADMIN = "retailer_admin"
+}

package/bin/loanConfig/enums/ModifiableByRoleEnum.js

@@ -0,0 +1,15 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.ModifiableByRoleEnum = void 0;
+/**
+ * Rol RBAC mínimo que puede modificar un parámetro (RBAC a nivel de parámetro, modelo-datos §8).
+ * `retailer_admin` = "Admin VentasLuga" de M6 §8. Valores = identificadores de rol de RBAC F0.
+ * TD-004: confirmar mapeo super_admin ↔ platform_super_admin con el naming real de F0.
+ * @enum {string}
+ */
+var ModifiableByRoleEnum;
+(function (ModifiableByRoleEnum) {
+    ModifiableByRoleEnum["SUPER_ADMIN"] = "super_admin";
+    ModifiableByRoleEnum["SOFOM_ADMIN"] = "sofom_admin";
+    ModifiableByRoleEnum["RETAILER_ADMIN"] = "retailer_admin";
+})(ModifiableByRoleEnum || (exports.ModifiableByRoleEnum = ModifiableByRoleEnum = {}));

package/bin/places/dtos/CashInFeeDto.d.ts

@@ -0,0 +1,17 @@
+import { CurrencyId } from '../../currency/enums/CurrencyId';
+/**
+ * Comisión que cobra un punto de cash-in (lo que el lambda MUESTRA, no cobra).
+ * - GreenDot (US): representativo por cadena → `fixed` + `cap` (cada tienda cobra hasta el tope).
+ * - Passport (MX): por red → `fixed` + `percentage`.
+ * Response DTO — sin decoradores de validación.
+ */
+export declare class CashInFeeDto {
+    /** Comisión fija, en la moneda del país. */
+    fixed?: number;
+    /** Porcentaje del monto depositado (0–100). */
+    percentage?: number;
+    /** Tope máximo de comisión (GreenDot: el asociado cobra hasta este cap). */
+    cap?: number;
+    /** Moneda del fee: USD (GreenDot) | MXN (Passport). */
+    currency: CurrencyId;
+}

package/bin/places/dtos/CashInFeeDto.js

@@ -0,0 +1,12 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.CashInFeeDto = void 0;
+/**
+ * Comisión que cobra un punto de cash-in (lo que el lambda MUESTRA, no cobra).
+ * - GreenDot (US): representativo por cadena → `fixed` + `cap` (cada tienda cobra hasta el tope).
+ * - Passport (MX): por red → `fixed` + `percentage`.
+ * Response DTO — sin decoradores de validación.
+ */
+class CashInFeeDto {
+}
+exports.CashInFeeDto = CashInFeeDto;

package/bin/platformRbac/dtos/ResendOtpRequest.d.ts

@@ -0,0 +1,22 @@
+import { MfaMethodEnum } from '../enums/MfaMethodEnum';
+/**
+ * Body del POST /auth/resend-otp (público, anónimo). DEC-RBAC-054.
+ * Reenvía el OTP del login re-disparando el challenge real CUSTOM_AUTH (EMAIL_OTP) para la
+ * identidad SIN password. `tenantId` obligatorio (DEC-064 — el picker ya lo resolvió, NO "solo email").
+ * El email se normaliza lowercase server-side. Postura anti-enumeración: respuesta 200 genérica
+ * siempre, sin filtrar existencia (ver AuthLoginManager.resendChallengeOtp).
+ */
+export declare class ResendOtpRequest {
+    email: string;
+    tenantId: string;
+}
+/**
+ * Respuesta del resend-otp. `session`/`mfaMethod` frescos del nuevo challenge CUSTOM_AUTH.
+ * Plain sin validators (no validamos lo que mandamos al cliente — fiado-validation-and-dtos § 7).
+ * Ambos opcionales: en los caminos de rechazo silencioso (anti-enumeración) o ramas sin CUSTOM_AUTH
+ * el server responde 200 genérico sin session ni método.
+ */
+export interface ResendOtpResponse {
+    session?: string;
+    mfaMethod?: MfaMethodEnum;
+}

package/bin/platformRbac/dtos/ResendOtpRequest.js

@@ -0,0 +1,36 @@
+"use strict";
+var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
+    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+    return c > 3 && r && Object.defineProperty(target, key, r), r;
+};
+var __metadata = (this && this.__metadata) || function (k, v) {
+    if (typeof Reflect === "object" && typeof Reflect.metadata === "function") return Reflect.metadata(k, v);
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.ResendOtpRequest = void 0;
+const class_transformer_1 = require("class-transformer");
+const class_validator_1 = require("class-validator");
+/**
+ * Body del POST /auth/resend-otp (público, anónimo). DEC-RBAC-054.
+ * Reenvía el OTP del login re-disparando el challenge real CUSTOM_AUTH (EMAIL_OTP) para la
+ * identidad SIN password. `tenantId` obligatorio (DEC-064 — el picker ya lo resolvió, NO "solo email").
+ * El email se normaliza lowercase server-side. Postura anti-enumeración: respuesta 200 genérica
+ * siempre, sin filtrar existencia (ver AuthLoginManager.resendChallengeOtp).
+ */
+class ResendOtpRequest {
+}
+exports.ResendOtpRequest = ResendOtpRequest;
+__decorate([
+    (0, class_transformer_1.Expose)(),
+    (0, class_validator_1.IsEmail)(),
+    (0, class_validator_1.IsNotEmpty)(),
+    __metadata("design:type", String)
+], ResendOtpRequest.prototype, "email", void 0);
+__decorate([
+    (0, class_transformer_1.Expose)(),
+    (0, class_validator_1.IsString)(),
+    (0, class_validator_1.IsNotEmpty)(),
+    __metadata("design:type", String)
+], ResendOtpRequest.prototype, "tenantId", void 0);

package/bin/platformRbac/dtos/ResendSelfRegisterOtpRequest.d.ts

@@ -0,0 +1,11 @@
+/**
+ * Body del POST /self-register/resend-otp (público, anónimo). DEC-RBAC-054.
+ * Re-envía el OTP del autoregistro (mecanismo messages-business, NO Cognito) tras validar un
+ * `pending` existente. Misma postura anti-enumeración del start. El email se normaliza lowercase
+ * server-side. DTO propio por endpoint (NO reusa SelfRegisterStartRequest, que exige roleId/scope/
+ * scopeRef, ni SelfRegisterVerifyOtpRequest, que exige otp).
+ */
+export declare class ResendSelfRegisterOtpRequest {
+    tenantId: string;
+    email: string;
+}

package/bin/platformRbac/dtos/ResendSelfRegisterOtpRequest.js

@@ -0,0 +1,36 @@
+"use strict";
+var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
+    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+    return c > 3 && r && Object.defineProperty(target, key, r), r;
+};
+var __metadata = (this && this.__metadata) || function (k, v) {
+    if (typeof Reflect === "object" && typeof Reflect.metadata === "function") return Reflect.metadata(k, v);
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.ResendSelfRegisterOtpRequest = void 0;
+const class_transformer_1 = require("class-transformer");
+const class_validator_1 = require("class-validator");
+/**
+ * Body del POST /self-register/resend-otp (público, anónimo). DEC-RBAC-054.
+ * Re-envía el OTP del autoregistro (mecanismo messages-business, NO Cognito) tras validar un
+ * `pending` existente. Misma postura anti-enumeración del start. El email se normaliza lowercase
+ * server-side. DTO propio por endpoint (NO reusa SelfRegisterStartRequest, que exige roleId/scope/
+ * scopeRef, ni SelfRegisterVerifyOtpRequest, que exige otp).
+ */
+class ResendSelfRegisterOtpRequest {
+}
+exports.ResendSelfRegisterOtpRequest = ResendSelfRegisterOtpRequest;
+__decorate([
+    (0, class_transformer_1.Expose)(),
+    (0, class_validator_1.IsString)(),
+    (0, class_validator_1.IsNotEmpty)(),
+    __metadata("design:type", String)
+], ResendSelfRegisterOtpRequest.prototype, "tenantId", void 0);
+__decorate([
+    (0, class_transformer_1.Expose)(),
+    (0, class_validator_1.IsEmail)(),
+    (0, class_validator_1.IsNotEmpty)(),
+    __metadata("design:type", String)
+], ResendSelfRegisterOtpRequest.prototype, "email", void 0);

package/bin/retailWizard/dtos/SaleLogEntry.d.ts

@@ -26,4 +26,17 @@ export interface SaleLogEntry {
     /** Motivo, cuando la acción lo exige (cancelación, excepción aplicada). */
     reason: string | null;
     changes: SaleLogChange[];
+    /**
+     * Datos de la venta que la acción NO cambió y que se guardan para poder leer la entrada sin abrir
+     * otra pantalla (en un `SALE_CANCEL`: el tipo de venta, el monto, el enganche, el crédito).
+     *
+     * Va aparte de `changes` a propósito. Antes viajaba dentro de `new` y `changes` lo pintaba como un
+     * alta: la bitácora afirmaba que en la cancelación el tipo de venta había pasado «de nada a CASH».
+     * En una auditoría un cambio inventado es peor que un dato faltante.
+     *
+     * **El front lo pinta como contexto, NUNCA como «antes → después».** `null` cuando la acción no
+     * mandó contexto. Valores serializados a string igual que `changes`; y como `changes`, NUNCA
+     * lleva PII.
+     */
+    context: Record<string, string | null> | null;
 }

package/bin/retailWizard/dtos/responses/BackofficeSalesStatsResponse.d.ts

@@ -7,20 +7,36 @@
  * contra el que el front ya mockeó la pantalla. Cambiarlas a inglés por consistencia rompería una
  * pantalla ya construida sin ganar nada. Decisión de Andrés, 2026-08-03.
  *
- * `contado` + `credito` == `total`. `surekeep` + `externas` == `credito`: las dos particiones son
- * completas y NO se solapan (ver `helpers/saleFinancier`).
+ * **Las identidades del contrato** (las tres se cumplen siempre y están cubiertas por tests):
+ *
+ * - `contado` + `credito` + `sinProveedor` == `total`
+ * - `surekeep` + `externas` == `credito`
+ *
+ * `contado`, `credito` y `sinProveedor` particionan `total`; `surekeep` y `externas` particionan
+ * `credito`. Ninguna de las dos particiones se solapa (ver `helpers/saleFinancier`).
  */
 export interface BackofficeSalesStatsResponse {
     /** Ventas del retailer en la ventana consultada. */
     total: number;
     /** Subconjunto de `total` con `soldAt` en el día de hoy. */
     hoy: number;
-    /** `type: CASH`. */
+    /** `type: CASH`. Efectivo de verdad — ver `sinProveedor`. */
     contado: number;
-    /** `type: CREDIT` o `EXTERNAL_REFERRAL` — todo lo que no es contado. */
+    /** Derivadas con financiera CONOCIDA: `type: CREDIT`, o `EXTERNAL_REFERRAL` con proveedor. */
     credito: number;
     /** Financiadas por la SOFOM (`type: CREDIT`). */
     surekeep: number;
     /** Financiadas por un tercero (`EXTERNAL_REFERRAL` con proveedor). */
     externas: number;
+    /**
+     * `type: EXTERNAL_REFERRAL` **sin** `externalProvider` — derivadas cuya financiera no quedó
+     * registrada. Es un DATO ROTO, no una forma de pago.
+     *
+     * Vive en su propia llave y NO en `contado` porque antes caía ahí y la pantalla las leía como
+     * EFECTIVO, que es la lectura más cara de equivocar. Tampoco entra en `credito`: `surekeep` +
+     * `externas` == `credito` y una venta sin financiera no pertenece a ninguna de las dos.
+     * Análisis ya las descartaba de su mix, y por eso Ventas y Análisis contaban distinto el mismo
+     * período. Un valor > 0 es una invitación a ir a corregir esas filas.
+     */
+    sinProveedor: number;
 }

package/bin/retailWizard/dtos/responses/BackofficeSellerKpisResponse.d.ts

@@ -22,6 +22,13 @@ export interface SellerKpiRow {
  *
  * Mismo criterio que A3: el eje es la venta, así que solo aparecen los vendedores que vendieron en
  * la ventana. El roster completo vive en `retail-org-business`.
+ *
+ * ⚠️ **Sin la ★ de encargado de tienda** que pinta el mockup (`es_admin_tienda`). Ese flag es del
+ * padrón (`RetailUser_GT`, de `retail-org-business`), no del snapshot de la venta: la pantalla lo
+ * trae de ahí y lo une por `sellerRetailUserId`.
+ *
+ * ⚠️ Tampoco lleva variación contra la semana pasada — el mockup de Vendedores no la pinta, solo el
+ * de Tiendas (ver `StoreKpiRow.weekOverWeekChangePct`).
  */
 export interface BackofficeSellerKpisResponse {
     items: SellerKpiRow[];

package/bin/retailWizard/dtos/responses/BackofficeStoreKpisResponse.d.ts

@@ -15,6 +15,21 @@ export interface StoreKpiRow {
     averageTicketCents: number | null;
     /** ISO-8601 de la venta más reciente de la tienda en la ventana. `null` si no vendió. */
     lastSaleAt: string | null;
+    /**
+     * Variación porcentual del volumen colocado contra la MISMA ventana corrida 7 días atrás, con un
+     * decimal. Es el chip `+12%` / `-8%` de la pantalla Tiendas.
+     *
+     * `null` en tres casos, todos «no sé» y ninguno «no cambió»:
+     * - la ventana pedida abarca **más de 7 días**, así que el baseline se solaparía con ella y el
+     *   delta compararía un período contra sí mismo (con el default de 90 días, siempre);
+     * - la tienda no vendió nada esa semana — no se divide por cero;
+     * - los números vienen del data lake y no hay fila para esta tienda en el baseline.
+     */
+    weekOverWeekChangePct: number | null;
+    /** Volumen colocado de la ventana de hace 7 días — el denominador del chip, explícito. */
+    baselineSameWeekdayCents: number | null;
+    /** Piezas de esa misma ventana. La pantalla las pinta debajo del chip («N piezas semana pasada»). */
+    baselineSameWeekdayUnits: number | null;
 }
 /**
  * GET /backoffice/stores/kpis — la pantalla Tiendas del Admin VL (A3).
@@ -22,6 +37,18 @@ export interface StoreKpiRow {
  *
  * El eje es la VENTA: solo aparecen las tiendas que vendieron en la ventana. El roster completo
  * (incluidas las que no vendieron) lo tiene `retail-org-business`; la pantalla los cruza.
+ *
+ * ⚠️ **Tres columnas del mockup NO salen de acá y no van a salir**, porque no están en el snapshot
+ * congelado de la venta sino en el padrón:
+ *
+ * | Columna | Dónde vive |
+ * |---|---|
+ * | código de tienda | `Store` — `retail-org-business` |
+ * | tipo propia / subdistribuidor | NO es un campo de `Store`: un subdistribuidor es un *retailer hijo*, así que sale de `GET /retailers/{retailerId}/hierarchy` |
+ * | vendedores activos | `RetailUser_GT` — `retail-org-business` |
+ *
+ * La pantalla las trae de ahí y las une por `storeId`. Devolverlas desde este endpoint obligaría al
+ * silo de ventas a consultar el padrón en cada lectura de tablero.
  */
 export interface BackofficeStoreKpisResponse {
     items: StoreKpiRow[];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fiado/type-kit",
-  "version": "3.289.0",
+  "version": "3.290.0",
   "description": "",
   "main": "bin/index.js",
   "types": "bin/index.d.ts",

package/src/retailWizard/dtos/SaleLogEntry.ts

@@ -27,4 +27,17 @@ export interface SaleLogEntry {
     /** Motivo, cuando la acción lo exige (cancelación, excepción aplicada). */
     reason: string | null;
     changes: SaleLogChange[];
+    /**
+     * Datos de la venta que la acción NO cambió y que se guardan para poder leer la entrada sin abrir
+     * otra pantalla (en un `SALE_CANCEL`: el tipo de venta, el monto, el enganche, el crédito).
+     *
+     * Va aparte de `changes` a propósito. Antes viajaba dentro de `new` y `changes` lo pintaba como un
+     * alta: la bitácora afirmaba que en la cancelación el tipo de venta había pasado «de nada a CASH».
+     * En una auditoría un cambio inventado es peor que un dato faltante.
+     *
+     * **El front lo pinta como contexto, NUNCA como «antes → después».** `null` cuando la acción no
+     * mandó contexto. Valores serializados a string igual que `changes`; y como `changes`, NUNCA
+     * lleva PII.
+     */
+    context: Record<string, string | null> | null;
 }

package/src/retailWizard/dtos/responses/BackofficeSalesStatsResponse.ts

@@ -7,20 +7,36 @@
  * contra el que el front ya mockeó la pantalla. Cambiarlas a inglés por consistencia rompería una
  * pantalla ya construida sin ganar nada. Decisión de Andrés, 2026-08-03.
  *
- * `contado` + `credito` == `total`. `surekeep` + `externas` == `credito`: las dos particiones son
- * completas y NO se solapan (ver `helpers/saleFinancier`).
+ * **Las identidades del contrato** (las tres se cumplen siempre y están cubiertas por tests):
+ *
+ * - `contado` + `credito` + `sinProveedor` == `total`
+ * - `surekeep` + `externas` == `credito`
+ *
+ * `contado`, `credito` y `sinProveedor` particionan `total`; `surekeep` y `externas` particionan
+ * `credito`. Ninguna de las dos particiones se solapa (ver `helpers/saleFinancier`).
  */
 export interface BackofficeSalesStatsResponse {
     /** Ventas del retailer en la ventana consultada. */
     total: number;
     /** Subconjunto de `total` con `soldAt` en el día de hoy. */
     hoy: number;
-    /** `type: CASH`. */
+    /** `type: CASH`. Efectivo de verdad — ver `sinProveedor`. */
     contado: number;
-    /** `type: CREDIT` o `EXTERNAL_REFERRAL` — todo lo que no es contado. */
+    /** Derivadas con financiera CONOCIDA: `type: CREDIT`, o `EXTERNAL_REFERRAL` con proveedor. */
     credito: number;
     /** Financiadas por la SOFOM (`type: CREDIT`). */
     surekeep: number;
     /** Financiadas por un tercero (`EXTERNAL_REFERRAL` con proveedor). */
     externas: number;
+    /**
+     * `type: EXTERNAL_REFERRAL` **sin** `externalProvider` — derivadas cuya financiera no quedó
+     * registrada. Es un DATO ROTO, no una forma de pago.
+     *
+     * Vive en su propia llave y NO en `contado` porque antes caía ahí y la pantalla las leía como
+     * EFECTIVO, que es la lectura más cara de equivocar. Tampoco entra en `credito`: `surekeep` +
+     * `externas` == `credito` y una venta sin financiera no pertenece a ninguna de las dos.
+     * Análisis ya las descartaba de su mix, y por eso Ventas y Análisis contaban distinto el mismo
+     * período. Un valor > 0 es una invitación a ir a corregir esas filas.
+     */
+    sinProveedor: number;
 }

package/src/retailWizard/dtos/responses/BackofficeSellerKpisResponse.ts

@@ -23,6 +23,13 @@ export interface SellerKpiRow {
  *
  * Mismo criterio que A3: el eje es la venta, así que solo aparecen los vendedores que vendieron en
  * la ventana. El roster completo vive en `retail-org-business`.
+ *
+ * ⚠️ **Sin la ★ de encargado de tienda** que pinta el mockup (`es_admin_tienda`). Ese flag es del
+ * padrón (`RetailUser_GT`, de `retail-org-business`), no del snapshot de la venta: la pantalla lo
+ * trae de ahí y lo une por `sellerRetailUserId`.
+ *
+ * ⚠️ Tampoco lleva variación contra la semana pasada — el mockup de Vendedores no la pinta, solo el
+ * de Tiendas (ver `StoreKpiRow.weekOverWeekChangePct`).
  */
 export interface BackofficeSellerKpisResponse {
     items: SellerKpiRow[];

package/src/retailWizard/dtos/responses/BackofficeStoreKpisResponse.ts

@@ -15,6 +15,21 @@ export interface StoreKpiRow {
     averageTicketCents: number | null;
     /** ISO-8601 de la venta más reciente de la tienda en la ventana. `null` si no vendió. */
     lastSaleAt: string | null;
+    /**
+     * Variación porcentual del volumen colocado contra la MISMA ventana corrida 7 días atrás, con un
+     * decimal. Es el chip `+12%` / `-8%` de la pantalla Tiendas.
+     *
+     * `null` en tres casos, todos «no sé» y ninguno «no cambió»:
+     * - la ventana pedida abarca **más de 7 días**, así que el baseline se solaparía con ella y el
+     *   delta compararía un período contra sí mismo (con el default de 90 días, siempre);
+     * - la tienda no vendió nada esa semana — no se divide por cero;
+     * - los números vienen del data lake y no hay fila para esta tienda en el baseline.
+     */
+    weekOverWeekChangePct: number | null;
+    /** Volumen colocado de la ventana de hace 7 días — el denominador del chip, explícito. */
+    baselineSameWeekdayCents: number | null;
+    /** Piezas de esa misma ventana. La pantalla las pinta debajo del chip («N piezas semana pasada»). */
+    baselineSameWeekdayUnits: number | null;
 }
 
 /**
@@ -23,6 +38,18 @@ export interface StoreKpiRow {
  *
  * El eje es la VENTA: solo aparecen las tiendas que vendieron en la ventana. El roster completo
  * (incluidas las que no vendieron) lo tiene `retail-org-business`; la pantalla los cruza.
+ *
+ * ⚠️ **Tres columnas del mockup NO salen de acá y no van a salir**, porque no están en el snapshot
+ * congelado de la venta sino en el padrón:
+ *
+ * | Columna | Dónde vive |
+ * |---|---|
+ * | código de tienda | `Store` — `retail-org-business` |
+ * | tipo propia / subdistribuidor | NO es un campo de `Store`: un subdistribuidor es un *retailer hijo*, así que sale de `GET /retailers/{retailerId}/hierarchy` |
+ * | vendedores activos | `RetailUser_GT` — `retail-org-business` |
+ *
+ * La pantalla las trae de ahí y las une por `storeId`. Devolverlas desde este endpoint obligaría al
+ * silo de ventas a consultar el padrón en cada lectura de tablero.
  */
 export interface BackofficeStoreKpisResponse {
     items: StoreKpiRow[];

package/bin/identity/enums/SelfieSourceEnum.d.ts

@@ -1,10 +0,0 @@
-/**
- * Con qué criterio se resolvió cuál archivo de S3 es la selfie del usuario.
- * Le dice al consumidor qué tan confiable es el match antes de mandarla a un facematch.
- */
-export declare enum SelfieSourceEnum {
-    /** Matcheó el verificationId de la verificación vigente en People. */
-    VERIFICATION = "VERIFICATION",
-    /** No hubo match por verificación: se tomó el archivo de selfie más reciente del bucket. */
-    LATEST = "LATEST"
-}

package/bin/identity/enums/SelfieSourceEnum.js

@@ -1,14 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.SelfieSourceEnum = void 0;
-/**
- * Con qué criterio se resolvió cuál archivo de S3 es la selfie del usuario.
- * Le dice al consumidor qué tan confiable es el match antes de mandarla a un facematch.
- */
-var SelfieSourceEnum;
-(function (SelfieSourceEnum) {
-    /** Matcheó el verificationId de la verificación vigente en People. */
-    SelfieSourceEnum["VERIFICATION"] = "VERIFICATION";
-    /** No hubo match por verificación: se tomó el archivo de selfie más reciente del bucket. */
-    SelfieSourceEnum["LATEST"] = "LATEST";
-})(SelfieSourceEnum || (exports.SelfieSourceEnum = SelfieSourceEnum = {}));