evo360-types 1.3.608 → 1.3.612

package/dist/apps/evo-med/calendar/zod-schemas.js

@@ -105,6 +105,10 @@ exports.zMedCalendarNotificationConfigSchema = zod_1.z
 // Os únicos limites que o zod IMPÕE são os que a decisão declarou: retenção
 // 7..730 (D32) e duração 15..480 (plan §12). Os demais têm só teto de sanidade
 // — recusar um valor que a spec não proibiu seria inventar regra de negócio.
+//
+// O teto de 480 da duração NÃO acompanhou o teto de plataforma de 1h30 de
+// 2026-09-25, e a razão está no comentário do campo: escrita permissiva,
+// leitura clampada.
 exports.zMedCalendarVirtualCareRecordingSchema = zod_1.z
     .object({
     mode: zod_1.z
@@ -137,6 +141,15 @@ exports.zMedCalendarVirtualCareConfigSchema = zod_1.z
         .nullable()
         .optional(),
     allow_late_end: zod_1.z.boolean().nullable().optional(),
+    // `.max(480)` e NÃO 90 (o teto de plataforma de 1h30, 2026-09-25). Este é
+    // limite de ESCRITA, e baixá-lo quebraria o save de agenda já gravada:
+    // `CalendarModel.setProperties` relê o doc com `parseDoc` e valida o MERGE
+    // de doc + input com este schema, então uma agenda com 120 (o default
+    // publicado) ou 480 passaria a recusar o save de QUALQUER campo — o nome da
+    // agenda, a cor, o horário — por causa de um campo de telemedicina que o
+    // usuário nem abriu. Quem aplica o teto é a LEITURA
+    // (`VIRTUAL_CARE_PLATFORM_MAX_DURATION_MINUTES` em `packages/model`), que
+    // clampa e registra; a tela usa `VIRTUAL_CARE_MAX_DURATION_MINUTES_MAX`.
     max_duration_minutes: zod_1.z.number().int().min(15).max(480).nullable().optional(),
     end_warning_minutes: zod_1.z.number().int().min(0).max(1440).nullable().optional(),
     // feat-160 R6 (D38): provider sugerido ao agendar telemedicina nesta agenda.

package/dist/apps/evo-med/calendar/zod-schemas.ts

@@ -109,6 +109,10 @@ export const zMedCalendarNotificationConfigSchema = z
 // Os únicos limites que o zod IMPÕE são os que a decisão declarou: retenção
 // 7..730 (D32) e duração 15..480 (plan §12). Os demais têm só teto de sanidade
 // — recusar um valor que a spec não proibiu seria inventar regra de negócio.
+//
+// O teto de 480 da duração NÃO acompanhou o teto de plataforma de 1h30 de
+// 2026-09-25, e a razão está no comentário do campo: escrita permissiva,
+// leitura clampada.
 export const zMedCalendarVirtualCareRecordingSchema = z
   .object({
     mode: z
@@ -144,6 +148,15 @@ export const zMedCalendarVirtualCareConfigSchema = z
       .nullable()
       .optional(),
     allow_late_end: z.boolean().nullable().optional(),
+    // `.max(480)` e NÃO 90 (o teto de plataforma de 1h30, 2026-09-25). Este é
+    // limite de ESCRITA, e baixá-lo quebraria o save de agenda já gravada:
+    // `CalendarModel.setProperties` relê o doc com `parseDoc` e valida o MERGE
+    // de doc + input com este schema, então uma agenda com 120 (o default
+    // publicado) ou 480 passaria a recusar o save de QUALQUER campo — o nome da
+    // agenda, a cor, o horário — por causa de um campo de telemedicina que o
+    // usuário nem abriu. Quem aplica o teto é a LEITURA
+    // (`VIRTUAL_CARE_PLATFORM_MAX_DURATION_MINUTES` em `packages/model`), que
+    // clampa e registra; a tela usa `VIRTUAL_CARE_MAX_DURATION_MINUTES_MAX`.
     max_duration_minutes: z.number().int().min(15).max(480).nullable().optional(),
     end_warning_minutes: z.number().int().min(0).max(1440).nullable().optional(),
     // feat-160 R6 (D38): provider sugerido ao agendar telemedicina nesta agenda.

package/dist/types/evo-med/calendar/index.d.ts

@@ -172,9 +172,30 @@ export type VirtualCareRecordingMode = (typeof VirtualCareRecordingModeEnum)[key
 /** Limites de `recording.retention_days` (D32; D13 mantém 7 como default). */
 export declare const VIRTUAL_CARE_RETENTION_DAYS_MIN = 7;
 export declare const VIRTUAL_CARE_RETENTION_DAYS_MAX = 730;
-/** Limites de `max_duration_minutes`. */
+/**
+ * Limites de `max_duration_minutes`.
+ *
+ * O teto desceu de 480 (8 h) para **90 (1h30)** em 2026-09-25, por pedido do
+ * dono do produto: sem teto a consulta "fica em curso indefinidamente" e nós
+ * pagamos minuto de sala, minuto de gravação e depois o processamento da
+ * transcrição.
+ *
+ * Duas coisas que este par de constantes NÃO é:
+ *
+ *  - **não é a autoridade.** Quem garante o teto é o backend
+ *    (`VIRTUAL_CARE_PLATFORM_MAX_DURATION_MINUTES`, em
+ *    `packages/model/src/evo-telemedicine/virtual-care-policy.ts`), que clampa
+ *    na LEITURA da agenda. Tem de ser lá porque o que roda em produção é a
+ *    versão PUBLICADA deste pacote — um teto que só exista aqui não existe em
+ *    produção até o publish chegar ao deploy;
+ *  - **não é limite de escrita.** O `.max()` do zod continua em 480 de
+ *    propósito — ver o comentário em `zMedCalendarVirtualCareConfigSchema`.
+ *
+ * O uso legítimo daqui é a TELA: é este número que o editor da agenda usa como
+ * `max` do campo e para avisar que o valor gravado está fora da faixa.
+ */
 export declare const VIRTUAL_CARE_MAX_DURATION_MINUTES_MIN = 15;
-export declare const VIRTUAL_CARE_MAX_DURATION_MINUTES_MAX = 480;
+export declare const VIRTUAL_CARE_MAX_DURATION_MINUTES_MAX = 90;
 /** O que está GRAVADO no doc da agenda — tudo parcial (ausente = default). */
 export interface IMedCalendarVirtualCareConfig {
     /**
@@ -209,7 +230,15 @@ export interface IMedCalendarVirtualCareConfig {
     } | null;
     /** `true` = passar do fim previsto não encerra a consulta (comportamento atual). */
     allow_late_end?: boolean | null;
-    /** Teto absoluto; o sweep encerra ao exceder (`reason: max_duration`). 15..480. */
+    /**
+     * Teto absoluto; o sweep encerra ao exceder (`reason: max_duration`).
+     *
+     * Faixa da TELA: 15..90 (1h30, desde 2026-09-25). Doc gravado antes disso
+     * pode ter 120 (o default) ou 480, e continua salvável: o backend clampa na
+     * leitura e o zod não recusa. O default de
+     * `CALENDAR_VIRTUAL_CARE_DEFAULTS` segue 120 e também é clampado — o teto é
+     * da plataforma, não da agenda.
+     */
     max_duration_minutes?: number | null;
     /** Aviso ao médico no SPA quando faltar N min para o fim. 0 = sem aviso. */
     end_warning_minutes?: number | null;

package/dist/types/evo-med/calendar/index.js

@@ -94,9 +94,30 @@ exports.VirtualCareRecordingModeEnum = {
 /** Limites de `recording.retention_days` (D32; D13 mantém 7 como default). */
 exports.VIRTUAL_CARE_RETENTION_DAYS_MIN = 7;
 exports.VIRTUAL_CARE_RETENTION_DAYS_MAX = 730;
-/** Limites de `max_duration_minutes`. */
+/**
+ * Limites de `max_duration_minutes`.
+ *
+ * O teto desceu de 480 (8 h) para **90 (1h30)** em 2026-09-25, por pedido do
+ * dono do produto: sem teto a consulta "fica em curso indefinidamente" e nós
+ * pagamos minuto de sala, minuto de gravação e depois o processamento da
+ * transcrição.
+ *
+ * Duas coisas que este par de constantes NÃO é:
+ *
+ *  - **não é a autoridade.** Quem garante o teto é o backend
+ *    (`VIRTUAL_CARE_PLATFORM_MAX_DURATION_MINUTES`, em
+ *    `packages/model/src/evo-telemedicine/virtual-care-policy.ts`), que clampa
+ *    na LEITURA da agenda. Tem de ser lá porque o que roda em produção é a
+ *    versão PUBLICADA deste pacote — um teto que só exista aqui não existe em
+ *    produção até o publish chegar ao deploy;
+ *  - **não é limite de escrita.** O `.max()` do zod continua em 480 de
+ *    propósito — ver o comentário em `zMedCalendarVirtualCareConfigSchema`.
+ *
+ * O uso legítimo daqui é a TELA: é este número que o editor da agenda usa como
+ * `max` do campo e para avisar que o valor gravado está fora da faixa.
+ */
 exports.VIRTUAL_CARE_MAX_DURATION_MINUTES_MIN = 15;
-exports.VIRTUAL_CARE_MAX_DURATION_MINUTES_MAX = 480;
+exports.VIRTUAL_CARE_MAX_DURATION_MINUTES_MAX = 90;
 /**
  * Defaults da spec (plan §12 / D13 / D32). Agenda sem `virtual_care` vale
  * exatamente isto — é o que faz "sem migração de dado" ser verdade.

package/dist/types/evo-med/calendar/index.ts

@@ -213,9 +213,30 @@ export type VirtualCareRecordingMode =
 export const VIRTUAL_CARE_RETENTION_DAYS_MIN = 7;
 export const VIRTUAL_CARE_RETENTION_DAYS_MAX = 730;
 
-/** Limites de `max_duration_minutes`. */
+/**
+ * Limites de `max_duration_minutes`.
+ *
+ * O teto desceu de 480 (8 h) para **90 (1h30)** em 2026-09-25, por pedido do
+ * dono do produto: sem teto a consulta "fica em curso indefinidamente" e nós
+ * pagamos minuto de sala, minuto de gravação e depois o processamento da
+ * transcrição.
+ *
+ * Duas coisas que este par de constantes NÃO é:
+ *
+ *  - **não é a autoridade.** Quem garante o teto é o backend
+ *    (`VIRTUAL_CARE_PLATFORM_MAX_DURATION_MINUTES`, em
+ *    `packages/model/src/evo-telemedicine/virtual-care-policy.ts`), que clampa
+ *    na LEITURA da agenda. Tem de ser lá porque o que roda em produção é a
+ *    versão PUBLICADA deste pacote — um teto que só exista aqui não existe em
+ *    produção até o publish chegar ao deploy;
+ *  - **não é limite de escrita.** O `.max()` do zod continua em 480 de
+ *    propósito — ver o comentário em `zMedCalendarVirtualCareConfigSchema`.
+ *
+ * O uso legítimo daqui é a TELA: é este número que o editor da agenda usa como
+ * `max` do campo e para avisar que o valor gravado está fora da faixa.
+ */
 export const VIRTUAL_CARE_MAX_DURATION_MINUTES_MIN = 15;
-export const VIRTUAL_CARE_MAX_DURATION_MINUTES_MAX = 480;
+export const VIRTUAL_CARE_MAX_DURATION_MINUTES_MAX = 90;
 
 /** O que está GRAVADO no doc da agenda — tudo parcial (ausente = default). */
 export interface IMedCalendarVirtualCareConfig {
@@ -251,7 +272,15 @@ export interface IMedCalendarVirtualCareConfig {
   } | null;
   /** `true` = passar do fim previsto não encerra a consulta (comportamento atual). */
   allow_late_end?: boolean | null;
-  /** Teto absoluto; o sweep encerra ao exceder (`reason: max_duration`). 15..480. */
+  /**
+   * Teto absoluto; o sweep encerra ao exceder (`reason: max_duration`).
+   *
+   * Faixa da TELA: 15..90 (1h30, desde 2026-09-25). Doc gravado antes disso
+   * pode ter 120 (o default) ou 480, e continua salvável: o backend clampa na
+   * leitura e o zod não recusa. O default de
+   * `CALENDAR_VIRTUAL_CARE_DEFAULTS` segue 120 e também é clampado — o teto é
+   * da plataforma, não da agenda.
+   */
   max_duration_minutes?: number | null;
   /** Aviso ao médico no SPA quando faltar N min para o fim. 0 = sem aviso. */
   end_warning_minutes?: number | null;

package/dist/types/nex-vendas/journey.d.ts

@@ -39,6 +39,29 @@ export interface INexVendasJourneySignature {
     signed_at?: Date | null;
     last_error?: string | null;
 }
+/**
+ * Envelope substituído por correção de dados antes da assinatura (feat-200).
+ *
+ * `canceled_at` null com `cancel_error` preenchido = o cancelamento no provider
+ * falhou e o documento ficou órfão no cofre: é a lista de limpeza manual.
+ */
+export interface INexVendasJourneySignatureHistoryEntry {
+    envelope_id: string;
+    provider?: string | null;
+    requested_at?: Date | null;
+    canceled_at?: Date | null;
+    reason: 'customer_data_corrected' | (string & {});
+    cancel_error?: string | null;
+}
+/**
+ * Correção aplicada ao `customer_data` na janela antes da assinatura. Cada uma
+ * gera um envelope novo, e é o contador do teto por hora (feat-200 D3).
+ */
+export interface INexVendasJourneyCorrection {
+    at: Date;
+    /** Só os NOMES dos campos alterados (ex.: `email`, `company.zip`). */
+    fields: string[];
+}
 /**
  * PDF da proposta comercial já persistido no bucket, pronto para virar anexo do
  * envelope de assinatura (feat-136).
@@ -248,6 +271,16 @@ export interface INexVendasJourney extends IFireGlobalDoc {
     customer_id?: string | null;
     customer_data?: INexVendasJourneyCustomerData | null;
     signature?: INexVendasJourneySignature | null;
+    /** Envelopes substituídos por correção de dados (feat-200). */
+    signature_history?: INexVendasJourneySignatureHistoryEntry[] | null;
+    /** Correções de dados antes da assinatura (feat-200), com timestamp. */
+    corrections?: INexVendasJourneyCorrection[] | null;
+    /**
+     * `true` quando o cliente Nexus em `customer_id` foi CRIADO por esta jornada —
+     * só então a correção atualiza o cadastro. Ausente = pré-existente
+     * (LINK-ONLY) ou jornada anterior à feat-200.
+     */
+    customer_created_by_journey?: boolean | null;
     payment?: INexVendasJourneyPayment | null;
     /**
      * PDF da proposta pronto para anexar ao envelope (feat-136). Ausente = ainda
@@ -286,6 +319,28 @@ export interface INexVendasJourneyCustomerMasked {
     phone_masked: string | null;
     document_masked: string | null;
 }
+/**
+ * Parâmetros do embed de assinatura da D4Sign (iframe
+ * `https://secure.d4sign.com.br/embed/viewblob/{document_uuid}?email=…`), que o
+ * shop monta dentro da própria página em vez de abrir o `sign_url`.
+ *
+ * Só existe com `signature.status === 'pending'` e provider `d4sign`; nos demais
+ * casos a projeção devolve `embed: null`. Exceção deliberada à regra de mascarar
+ * dados da projeção pública: o uuid já sai no `sign_url`, o e-mail é o que o
+ * próprio lead digitou e o CPF é exigido pela D4Sign para identificar o
+ * signatário. Os campos têm de bater com o signatário cadastrado no envelope.
+ */
+export interface INexVendasJourneySignatureEmbed {
+    /** UUID do documento na D4Sign (`signature.envelope_id`). */
+    document_uuid: string;
+    /** E-mail do signatário cadastrado no envelope. */
+    signer_email: string;
+    signer_display_name: string | null;
+    /** CPF do signatário em dígitos (responsável no PJ, titular no PF), ou null. */
+    signer_documentation: string | null;
+    /** `key_signer` decodificado do signatário; parâmetro opcional do embed. */
+    signer_key_signer: string | null;
+}
 /** O que o endpoint sem auth expõe. Sem ids internos de customer/tenant/contrato. */
 export interface INexVendasJourneyPublic {
     short_code: string;
@@ -294,9 +349,18 @@ export interface INexVendasJourneyPublic {
     proposal: INexFinopsProposalPublic;
     data_submitted: boolean;
     customer_masked: INexVendasJourneyCustomerMasked | null;
+    /**
+     * `customer_data` COMPLETO, só na janela de correção (`dados_coletados` sem
+     * assinatura concluída); fora dela `null`. É o que o próprio lead digitou,
+     * devolvido a quem tem o `short_code`, para reabrir o formulário preenchido.
+     * Ausente em backend anterior à feat-200.
+     */
+    editable_customer_data?: INexVendasJourneyCustomerData | null;
     signature: {
         status: NexVendasJourneySignatureStatus;
         sign_url: string | null;
+        /** Ausente em backend anterior à feat-199; null fora de pending/d4sign. */
+        embed?: INexVendasJourneySignatureEmbed | null;
     };
     payment: INexVendasJourneyPaymentPublic;
     contract: {

package/dist/types/nex-vendas/journey.ts

@@ -93,6 +93,31 @@ export interface INexVendasJourneySignature {
   last_error?: string | null;
 }
 
+/**
+ * Envelope substituído por correção de dados antes da assinatura (feat-200).
+ *
+ * `canceled_at` null com `cancel_error` preenchido = o cancelamento no provider
+ * falhou e o documento ficou órfão no cofre: é a lista de limpeza manual.
+ */
+export interface INexVendasJourneySignatureHistoryEntry {
+  envelope_id: string;
+  provider?: string | null;
+  requested_at?: Date | null;
+  canceled_at?: Date | null;
+  reason: 'customer_data_corrected' | (string & {});
+  cancel_error?: string | null;
+}
+
+/**
+ * Correção aplicada ao `customer_data` na janela antes da assinatura. Cada uma
+ * gera um envelope novo, e é o contador do teto por hora (feat-200 D3).
+ */
+export interface INexVendasJourneyCorrection {
+  at: Date;
+  /** Só os NOMES dos campos alterados (ex.: `email`, `company.zip`). */
+  fields: string[];
+}
+
 // ── PDF da proposta (anexo do envelope) ──
 
 /**
@@ -346,6 +371,16 @@ export interface INexVendasJourney extends IFireGlobalDoc {
 
   customer_data?: INexVendasJourneyCustomerData | null;
   signature?: INexVendasJourneySignature | null;
+  /** Envelopes substituídos por correção de dados (feat-200). */
+  signature_history?: INexVendasJourneySignatureHistoryEntry[] | null;
+  /** Correções de dados antes da assinatura (feat-200), com timestamp. */
+  corrections?: INexVendasJourneyCorrection[] | null;
+  /**
+   * `true` quando o cliente Nexus em `customer_id` foi CRIADO por esta jornada —
+   * só então a correção atualiza o cadastro. Ausente = pré-existente
+   * (LINK-ONLY) ou jornada anterior à feat-200.
+   */
+  customer_created_by_journey?: boolean | null;
   payment?: INexVendasJourneyPayment | null;
 
   /**
@@ -394,6 +429,29 @@ export interface INexVendasJourneyCustomerMasked {
   document_masked: string | null;
 }
 
+/**
+ * Parâmetros do embed de assinatura da D4Sign (iframe
+ * `https://secure.d4sign.com.br/embed/viewblob/{document_uuid}?email=…`), que o
+ * shop monta dentro da própria página em vez de abrir o `sign_url`.
+ *
+ * Só existe com `signature.status === 'pending'` e provider `d4sign`; nos demais
+ * casos a projeção devolve `embed: null`. Exceção deliberada à regra de mascarar
+ * dados da projeção pública: o uuid já sai no `sign_url`, o e-mail é o que o
+ * próprio lead digitou e o CPF é exigido pela D4Sign para identificar o
+ * signatário. Os campos têm de bater com o signatário cadastrado no envelope.
+ */
+export interface INexVendasJourneySignatureEmbed {
+  /** UUID do documento na D4Sign (`signature.envelope_id`). */
+  document_uuid: string;
+  /** E-mail do signatário cadastrado no envelope. */
+  signer_email: string;
+  signer_display_name: string | null;
+  /** CPF do signatário em dígitos (responsável no PJ, titular no PF), ou null. */
+  signer_documentation: string | null;
+  /** `key_signer` decodificado do signatário; parâmetro opcional do embed. */
+  signer_key_signer: string | null;
+}
+
 /** O que o endpoint sem auth expõe. Sem ids internos de customer/tenant/contrato. */
 export interface INexVendasJourneyPublic {
   short_code: string;
@@ -402,9 +460,18 @@ export interface INexVendasJourneyPublic {
   proposal: INexFinopsProposalPublic;
   data_submitted: boolean;
   customer_masked: INexVendasJourneyCustomerMasked | null;
+  /**
+   * `customer_data` COMPLETO, só na janela de correção (`dados_coletados` sem
+   * assinatura concluída); fora dela `null`. É o que o próprio lead digitou,
+   * devolvido a quem tem o `short_code`, para reabrir o formulário preenchido.
+   * Ausente em backend anterior à feat-200.
+   */
+  editable_customer_data?: INexVendasJourneyCustomerData | null;
   signature: {
     status: NexVendasJourneySignatureStatus;
     sign_url: string | null;
+    /** Ausente em backend anterior à feat-199; null fora de pending/d4sign. */
+    embed?: INexVendasJourneySignatureEmbed | null;
   };
   payment: INexVendasJourneyPaymentPublic;
   contract: { status: NexFinopsContractStatus } | null;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "evo360-types",
-  "version": "1.3.608",
+  "version": "1.3.612",
   "description": "HREVO360 Shared Types",
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",