evo360-types 1.3.516 → 1.3.520

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

@@ -39,6 +39,23 @@ export interface INexVendasJourneySignature {
     signed_at?: Date | null;
     last_error?: string | null;
 }
+/**
+ * PDF da proposta comercial já persistido no bucket, pronto para virar anexo do
+ * envelope de assinatura (feat-136).
+ *
+ * `sha256` é o hash do HTML **sanitizado** que originou o PDF, não do PDF: é o
+ * que permite detectar que o vendedor editou a proposta depois da geração e
+ * regerar em vez de anexar um documento obsoleto. `storage_path` é o objeto
+ * determinístico derivado desse mesmo hash.
+ */
+export interface INexVendasJourneyProposalPdf {
+    /** Caminho do objeto no bucket, sem o `gs://` e sem o nome do bucket. */
+    storage_path: string;
+    /** SHA-256 hex do HTML SANITIZADO que gerou o PDF. */
+    sha256: string;
+    size_bytes: number;
+    generated_at: Date;
+}
 export interface INexVendasJourneyCompany {
     legal_name?: string | null;
     trade_name?: string | null;
@@ -57,6 +74,15 @@ export interface INexVendasJourneyCustomerData {
     email: string;
     phone: string;
     company?: INexVendasJourneyCompany | null;
+    /**
+     * CPF de quem assina o contrato (variável `RESPONSAVEL_CPF`), só dígitos.
+     *
+     * Existe separado de `company.document_number` porque no cadastro PJ aquele
+     * campo é o CNPJ e o contrato imprime o CPF do representante legal abaixo do
+     * nome, na região da assinatura. No cadastro PF os dois coincidem — o form
+     * replica o documento aqui em vez de perguntar duas vezes.
+     */
+    responsible_cpf?: string | null;
 }
 /**
  * Métodos que o passo `g` oferece. Espelha `NexFinopsProposalPaymentMethod`: a
@@ -178,15 +204,20 @@ export interface INexVendasJourneyNotification {
 }
 /**
  * Slots que disparam efeito externo NÃO-idempotente e por isso precisam de
- * reserva transacional: criar o contrato, criar o envelope de assinatura e
- * (feat-131) criar o artefato de pagamento.
+ * reserva transacional: criar o contrato, criar o envelope de assinatura,
+ * (feat-131) criar o artefato de pagamento e (feat-136) renderizar o PDF da
+ * proposta.
+ *
+ * `payment` difere dos outros num ponto: contrato e envelope são efeito ÚNICO
+ * por jornada, enquanto o artefato de pagamento pode legitimamente ser recriado
+ * quando o cliente troca de método. Por isso o slot de pagamento é um mutex
+ * puro — não tem valor "definitivo" que o torne `already_done`.
  *
- * `payment` difere dos outros dois num ponto: contrato e envelope são efeito
- * ÚNICO por jornada, enquanto o artefato de pagamento pode legitimamente ser
- * recriado quando o cliente troca de método. Por isso o slot de pagamento é um
- * mutex puro — não tem valor "definitivo" que o torne `already_done`.
+ * `proposal_pdf` também é mutex puro, por motivo diferente: o PDF é reemitido
+ * quando o vendedor edita o `html_content`, e o "já feito" é decidido por
+ * comparação de hash antes do claim, não pela presença do campo.
  */
-export type NexVendasJourneySlot = 'contract' | 'signature' | 'payment';
+export type NexVendasJourneySlot = 'contract' | 'signature' | 'payment' | 'proposal_pdf';
 /**
  * Marca de reserva de um slot, gravada e liberada dentro de transaction.
  *
@@ -218,6 +249,12 @@ export interface INexVendasJourney extends IFireGlobalDoc {
     customer_data?: INexVendasJourneyCustomerData | null;
     signature?: INexVendasJourneySignature | null;
     payment?: INexVendasJourneyPayment | null;
+    /**
+     * PDF da proposta pronto para anexar ao envelope (feat-136). Ausente = ainda
+     * não gerado, ou proposta sem `html_content` — nos dois casos o envelope sai
+     * sem anexo.
+     */
+    proposal_pdf?: INexVendasJourneyProposalPdf | null;
     /**
      * Espelho PLANO de todo id externo de pagamento que a jornada já produziu —
      * checkout, cobrança, assinatura e link, **inclusive os superseded**.

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

@@ -93,6 +93,26 @@ export interface INexVendasJourneySignature {
   last_error?: string | null;
 }
 
+// ── PDF da proposta (anexo do envelope) ──
+
+/**
+ * PDF da proposta comercial já persistido no bucket, pronto para virar anexo do
+ * envelope de assinatura (feat-136).
+ *
+ * `sha256` é o hash do HTML **sanitizado** que originou o PDF, não do PDF: é o
+ * que permite detectar que o vendedor editou a proposta depois da geração e
+ * regerar em vez de anexar um documento obsoleto. `storage_path` é o objeto
+ * determinístico derivado desse mesmo hash.
+ */
+export interface INexVendasJourneyProposalPdf {
+  /** Caminho do objeto no bucket, sem o `gs://` e sem o nome do bucket. */
+  storage_path: string;
+  /** SHA-256 hex do HTML SANITIZADO que gerou o PDF. */
+  sha256: string;
+  size_bytes: number;
+  generated_at: Date;
+}
+
 // ── Dados de identificação coletados ──
 
 export interface INexVendasJourneyCompany {
@@ -114,6 +134,15 @@ export interface INexVendasJourneyCustomerData {
   email: string;
   phone: string;
   company?: INexVendasJourneyCompany | null;
+  /**
+   * CPF de quem assina o contrato (variável `RESPONSAVEL_CPF`), só dígitos.
+   *
+   * Existe separado de `company.document_number` porque no cadastro PJ aquele
+   * campo é o CNPJ e o contrato imprime o CPF do representante legal abaixo do
+   * nome, na região da assinatura. No cadastro PF os dois coincidem — o form
+   * replica o documento aqui em vez de perguntar duas vezes.
+   */
+  responsible_cpf?: string | null;
 }
 
 // ── Pagamento (feat-131) ──
@@ -266,15 +295,20 @@ export interface INexVendasJourneyNotification {
 
 /**
  * Slots que disparam efeito externo NÃO-idempotente e por isso precisam de
- * reserva transacional: criar o contrato, criar o envelope de assinatura e
- * (feat-131) criar o artefato de pagamento.
+ * reserva transacional: criar o contrato, criar o envelope de assinatura,
+ * (feat-131) criar o artefato de pagamento e (feat-136) renderizar o PDF da
+ * proposta.
+ *
+ * `payment` difere dos outros num ponto: contrato e envelope são efeito ÚNICO
+ * por jornada, enquanto o artefato de pagamento pode legitimamente ser recriado
+ * quando o cliente troca de método. Por isso o slot de pagamento é um mutex
+ * puro — não tem valor "definitivo" que o torne `already_done`.
  *
- * `payment` difere dos outros dois num ponto: contrato e envelope são efeito
- * ÚNICO por jornada, enquanto o artefato de pagamento pode legitimamente ser
- * recriado quando o cliente troca de método. Por isso o slot de pagamento é um
- * mutex puro — não tem valor "definitivo" que o torne `already_done`.
+ * `proposal_pdf` também é mutex puro, por motivo diferente: o PDF é reemitido
+ * quando o vendedor edita o `html_content`, e o "já feito" é decidido por
+ * comparação de hash antes do claim, não pela presença do campo.
  */
-export type NexVendasJourneySlot = 'contract' | 'signature' | 'payment';
+export type NexVendasJourneySlot = 'contract' | 'signature' | 'payment' | 'proposal_pdf';
 
 /**
  * Marca de reserva de um slot, gravada e liberada dentro de transaction.
@@ -314,6 +348,13 @@ export interface INexVendasJourney extends IFireGlobalDoc {
   signature?: INexVendasJourneySignature | null;
   payment?: INexVendasJourneyPayment | null;
 
+  /**
+   * PDF da proposta pronto para anexar ao envelope (feat-136). Ausente = ainda
+   * não gerado, ou proposta sem `html_content` — nos dois casos o envelope sai
+   * sem anexo.
+   */
+  proposal_pdf?: INexVendasJourneyProposalPdf | null;
+
   /**
    * Espelho PLANO de todo id externo de pagamento que a jornada já produziu —
    * checkout, cobrança, assinatura e link, **inclusive os superseded**.

package/package.json

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