evo360-types 1.3.610 → 1.3.614

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

@@ -38,6 +38,60 @@ export interface INexVendasJourneySignature {
     requested_at?: Date | null;
     signed_at?: Date | null;
     last_error?: string | null;
+    /**
+     * Consultas ao provider feitas pelo `POST /journeys/:code/signature/check`
+     * (feat-203), podadas a 1 h. É o contador do throttle por jornada (mínimo 90 s
+     * entre consultas, no máximo 5 por hora): a cota da D4Sign é 10 req/h na
+     * conta inteira. A re-checagem do webhook não entra aqui.
+     */
+    checks_at?: Date[] | null;
+}
+/**
+ * Por onde a assinatura foi confirmada no provider (feat-203). Vai em
+ * `data.via` do evento `contract_signed`: `webhook` é o POSTback da D4Sign,
+ * `check` é o "Verificar agora" do shop (caminho de destrave quando o webhook
+ * se perde).
+ */
+export type NexVendasJourneySignatureConfirmVia = 'webhook' | 'check';
+/**
+ * Resultado do `POST /journeys/:code/signature/check` (feat-203 D4):
+ *  - `signed`: o provider confirmou e ESTA chamada avançou a jornada;
+ *  - `already_signed`: já estava assinada (ou o webhook venceu a corrida);
+ *  - `pending`: o provider ainda não tem a assinatura;
+ *  - `not_confirmed`: o provider respondeu outro status (recusado, cancelado…);
+ *  - `not_applicable`: a jornada não está esperando assinatura — nada consultado;
+ *  - `provider_unavailable`: sem provider configurado ou a consulta falhou.
+ *
+ * O throttle NÃO é um outcome: sai como 429 `too_many_checks` com `retry_after_s`.
+ */
+export type NexVendasJourneySignatureCheckOutcome = 'signed' | 'already_signed' | 'pending' | 'not_confirmed' | 'not_applicable' | 'provider_unavailable';
+export interface INexVendasJourneySignatureCheckResult {
+    outcome: NexVendasJourneySignatureCheckOutcome;
+    /** Segundos até a próxima consulta ao provider ser aceita; ausente quando não se aplica. */
+    retry_after_s?: number | 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
@@ -202,6 +256,29 @@ export interface INexVendasJourneyNotification {
     sent_at: Date;
     error?: string | null;
 }
+/**
+ * Como o lead foi achado. `contact_index` = índice de contatos do chat pelo
+ * telefone (com e sem o 9º dígito); `phone` = telefone exato no lead;
+ * `algolia` = busca por dígitos no índice de leads; `email` = e-mail exato;
+ * `created` = nada casou e a jornada criou o lead.
+ */
+export type NexVendasJourneyLeadResolvedBy = 'contact_index' | 'phone' | 'algolia' | 'email' | 'created';
+/**
+ * Lead do CRM do tenant das notificações da jornada. É a âncora que as
+ * notificações levam em `externalLinks` (`crm_lead`): sem ela o hub-omni
+ * descarta o e-mail, que não cria contato sozinho.
+ *
+ * Re-resolução por correção de telefone/e-mail que devolve OUTRO lead
+ * sobrescreve este bloco e registra o evento `lead_relinked`; falha do
+ * resolvedor registra `lead_resolve_failed` e não bloqueia a jornada.
+ */
+export interface INexVendasJourneyLeadRef {
+    /** Tenant dono do lead — o do canal resolvido para as notificações. */
+    tenant: string;
+    lead_id: string;
+    resolved_by: NexVendasJourneyLeadResolvedBy;
+    resolved_at: Date;
+}
 /**
  * Slots que disparam efeito externo NÃO-idempotente e por isso precisam de
  * reserva transacional: criar o contrato, criar o envelope de assinatura,
@@ -246,8 +323,20 @@ export interface INexVendasJourney extends IFireGlobalDoc {
     contract_ref?: string | null;
     tenant_ref?: string | null;
     customer_id?: string | null;
+    /** Lead do CRM no tenant das notificações (feat-202). Ausente = ainda não resolvido. */
+    lead_ref?: INexVendasJourneyLeadRef | 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
@@ -316,6 +405,13 @@ 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;

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

@@ -91,6 +91,71 @@ export interface INexVendasJourneySignature {
   requested_at?: Date | null;
   signed_at?: Date | null;
   last_error?: string | null;
+  /**
+   * Consultas ao provider feitas pelo `POST /journeys/:code/signature/check`
+   * (feat-203), podadas a 1 h. É o contador do throttle por jornada (mínimo 90 s
+   * entre consultas, no máximo 5 por hora): a cota da D4Sign é 10 req/h na
+   * conta inteira. A re-checagem do webhook não entra aqui.
+   */
+  checks_at?: Date[] | null;
+}
+
+/**
+ * Por onde a assinatura foi confirmada no provider (feat-203). Vai em
+ * `data.via` do evento `contract_signed`: `webhook` é o POSTback da D4Sign,
+ * `check` é o "Verificar agora" do shop (caminho de destrave quando o webhook
+ * se perde).
+ */
+export type NexVendasJourneySignatureConfirmVia = 'webhook' | 'check';
+
+/**
+ * Resultado do `POST /journeys/:code/signature/check` (feat-203 D4):
+ *  - `signed`: o provider confirmou e ESTA chamada avançou a jornada;
+ *  - `already_signed`: já estava assinada (ou o webhook venceu a corrida);
+ *  - `pending`: o provider ainda não tem a assinatura;
+ *  - `not_confirmed`: o provider respondeu outro status (recusado, cancelado…);
+ *  - `not_applicable`: a jornada não está esperando assinatura — nada consultado;
+ *  - `provider_unavailable`: sem provider configurado ou a consulta falhou.
+ *
+ * O throttle NÃO é um outcome: sai como 429 `too_many_checks` com `retry_after_s`.
+ */
+export type NexVendasJourneySignatureCheckOutcome =
+  | 'signed'
+  | 'already_signed'
+  | 'pending'
+  | 'not_confirmed'
+  | 'not_applicable'
+  | 'provider_unavailable';
+
+export interface INexVendasJourneySignatureCheckResult {
+  outcome: NexVendasJourneySignatureCheckOutcome;
+  /** Segundos até a próxima consulta ao provider ser aceita; ausente quando não se aplica. */
+  retry_after_s?: number | 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) ──
@@ -291,6 +356,38 @@ export interface INexVendasJourneyNotification {
   error?: string | null;
 }
 
+// ── Lead do CRM (feat-202) ──
+
+/**
+ * Como o lead foi achado. `contact_index` = índice de contatos do chat pelo
+ * telefone (com e sem o 9º dígito); `phone` = telefone exato no lead;
+ * `algolia` = busca por dígitos no índice de leads; `email` = e-mail exato;
+ * `created` = nada casou e a jornada criou o lead.
+ */
+export type NexVendasJourneyLeadResolvedBy =
+  | 'contact_index'
+  | 'phone'
+  | 'algolia'
+  | 'email'
+  | 'created';
+
+/**
+ * Lead do CRM do tenant das notificações da jornada. É a âncora que as
+ * notificações levam em `externalLinks` (`crm_lead`): sem ela o hub-omni
+ * descarta o e-mail, que não cria contato sozinho.
+ *
+ * Re-resolução por correção de telefone/e-mail que devolve OUTRO lead
+ * sobrescreve este bloco e registra o evento `lead_relinked`; falha do
+ * resolvedor registra `lead_resolve_failed` e não bloqueia a jornada.
+ */
+export interface INexVendasJourneyLeadRef {
+  /** Tenant dono do lead — o do canal resolvido para as notificações. */
+  tenant: string;
+  lead_id: string;
+  resolved_by: NexVendasJourneyLeadResolvedBy;
+  resolved_at: Date;
+}
+
 // ── Reserva de efeito externo ──
 
 /**
@@ -343,9 +440,21 @@ export interface INexVendasJourney extends IFireGlobalDoc {
   contract_ref?: string | null;
   tenant_ref?: string | null;
   customer_id?: string | null;
+  /** Lead do CRM no tenant das notificações (feat-202). Ausente = ainda não resolvido. */
+  lead_ref?: INexVendasJourneyLeadRef | 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;
 
   /**
@@ -425,6 +534,13 @@ 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;

package/package.json

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