Gerador de Acordo-Mestre

O que Gerador de Acordo-Mestre faz?

Um modelo mestre, uma pequena especificação por contraparte, uma etapa de criação de rascunho. O gerador sempre rotula a saída como RASCUNHO, incluindo documentos gerados a partir de um modelo concluído. Uma conversão bem-sucedida comprova a geração do artefato, não a completude jurídica, autoridade para contratar ou prontidão para envio ou assinatura. Um acordo executado pode permitir que oportunidades designadas sejam adicionadas por notificação; essa autoridade deve ser estabelecida antes de usar o fluxo de trabalho do Anexo A.

Quando Usar

• Você emite um acordo genérico (NDA, taxa de referência ou captação, não-cerceamento, serviços mestre) para muitas contrapartes com os mesmos termos e alguns campos específicos da parte.
• Negócios são adicionados ao longo do tempo e redigir cada um é o gargalo.
• Os documentos devem ser reproduzíveis a partir de origem rastreada, diferenciáveis por diff e livres de edições manuais.
• Os campos de assinatura são inseridos por automação e precisam de um layout de página estável.

Como Funciona

Modelo

Um único modelo Markdown com campos {{PLACEHOLDER}}. Cada valor específico da parte é um placeholder; todo o restante é texto fixo. Um esqueleto está disponível em references/master-template.example.md. Substitua suas sentenças genéricas pelas cláusulas aprovadas pelo seu jurídico.

Placeholders preenchidos pelo script de referência:

Placeholder	Origem
{{DATE}}	spec.date, padrão data atual
{{CP_SHORT}}	spec.short
{{CP_LEGAL}}, {{CP_JURIS}}, {{CP_ADDR}}	campos da spec, ou uma linha em branco quando a contraparte os completa na assinatura
{{ROLE_CLAUSE}}, {{FEE_TITLE}}, {{FEE_CLAUSE}}	selecionados por spec.role a partir da tabela de funções
{{SCHEDULE_ROWS}}	spec.schedule, ou uma linha "sem entradas na assinatura"
{{SUPPLEMENT_CLAUSE}}	spec.supplement, renderizado com um separador final ou vazio
{{CP_SIGBLOCK}}, {{CP_SIGNER}}, {{CP_TITLE}}, {{CP_EMAIL}}	campos do bloco de assinatura, em branco quando desconhecidos

Especificação

Um arquivo JSON por contraparte:

{
  "file": "AcmeSupplier",
  "short": "Acme",
  "role": "supplier",
  "legal": "Acme Compute Ltd",
  "juris": "empresa da Inglaterra e País de Gales",
  "addr": "1 Example Street, London",
  "signer": "A. Person",
  "title": "Director",
  "email": "[email protected]",
  "schedule": [["1", "2026-09-01", "Lote A (16 nodos)", "introducer", "12 meses", "padrão"]],
  "supplement": "o Adendo de Processamento de Dados datado de 2026-09-01"
}

Apenas file, short e role são obrigatórios para um rascunho. Campos de assinatura ausentes renderizam como linhas em branco para revisão e conclusão. Veja references/spec.example.json.

file deve ser um nome de arquivo portável não vazio, como AcmeSupplier ou Acme Supplier, sem componentes de diretório. O construtor rejeita qualquer separador de caminho, sintaxe de drive/UNC, caracteres de controle, pontuação reservada do Windows ou nomes de dispositivo, e pontos ou espaços finais. Nomes inválidos são rejeitados sem sanitização ou renomeação, antes de criar saída ou invocar o pandoc.

Omita schedule ou use [] para o placeholder "sem entradas na assinatura". Um cronograma fornecido deve, caso contrário, ser um array denso de arrays de seis células, nesta ordem: número, data, contraparte ou lote protegido, função, termos, taxa. Cada célula deve ser uma string Unicode válida ou número finito; strings vazias são permitidas para espaços intencionais. Valores nulos, booleanos, objetos, arrays de células aninhadas, células ausentes e números não finitos são rejeitados com um índice de linha/célula antes de qualquer gravação de artefato ou atividade do pandoc. Sobressalentes UTF-16 não pareados também são rejeitados, em vez de substituídos durante a saída UTF-8; caracteres suplementares válidos, como emoji, permanecem suportados.

As células são texto simples, não Markdown ou HTML. O construtor codifica caracteres de sintaxe para que pipes literais, barras invertidas, acentos graves e markup permaneçam em seus campos originais. Cada CRLF, CR ou LF solto se torna um espaço; o texto ao redor das quebras de linha é mantido. Outros espaços em branco e pontuação literal são preservados nas células renderizadas. A especificação fonte não é modificada. Um cronograma válido comum mantém suas seis colunas; entrada malformada nunca é substituída silenciosamente por um cronograma vazio.

Tabela de Funções

spec.role seleciona três strings: a cláusula de acordo permanente, o título da seção de taxa e a abertura da cláusula de taxa.

Função	Quem paga	Forma da cláusula
buyer	A contraparte paga nas transações com partes introduzidas	A contraparte nos nomeia em base não exclusiva para originar e apresentar
supplier	A contraparte paga nas transações com partes introduzidas; quando compramos como principal contratamos nos termos do cronograma	A contraparte oferece capacidade para nós e para os compradores que apresentamos
mutual	Quem fecha com a introdução do outro paga	Cada parte pode apresentar; a parte que fecha paga

Funções desconhecidas são rejeitadas no momento da montagem.

Construção

Use apenas modelos e especificações revisados pelo operador. Substituições ordinárias de modelo fora do Anexo A são capazes de markup, não são um sanitizador para documentos não confiáveis. Pandoc pode ler recursos locais ou remotos referenciados; este gerador não isola o sistema de arquivos ou acesso de rede do conversor. Revise essas referências e execute a conversão em seu próprio ambiente devidamente restrito. Os testes focados usam um conversor sintético e não certificam o layout real do DOCX ou o isolamento.

node skills/master-agreement-generator/scripts/build-agreement.js \
  skills/master-agreement-generator/references/master-template.example.md \
  specs/AcmeSupplier.json \
  out/

O script preenche os placeholders, renderiza a tabela do cronograma e escreve out/<file> MASTER.md com um aviso obrigatório de RASCUNHO. Por padrão (ou com --require-docx) ele exige o pandoc instalado para produzir um artefato .docx regular e não vazio. Pandoc ausente, conversão falha ou saída ausente/vazia retorna código de saída 1. Cada teste ou conversão do pandoc é limitado a dez segundos. Flags desconhecidas, duplicadas ou conflitantes retornam código de saída 2.

Use --markdown-only explicitamente para um rascunho bem-sucedido apenas em Markdown. Esse modo nunca testa ou invoca o pandoc, retorna docxSkipped: true da biblioteca e não fornece DOCX para um fluxo de trabalho de assinatura eletrônica. Chamadores da biblioteca devem passar { markdownOnly: true }; { pandoc: false } sozinho agora falha no requisito DOCX. O resultado sempre relata documentStatus: 'draft'. O DOCX gerado existente é removido ao reconstruir seu Markdown, e a conversão falhada não deixa DOCX parcial, portanto um artefato anterior não pode se passar pela saída atual. Mantenha ambos os arquivos gerados fora do controle de versão; o modelo e as especificações são fonte.

Não há modo de cópia de execução. O exemplo contém deliberadamente diretivas de redação não resolvidas entre colchetes; preencher os tokens {{PLACEHOLDER}} não completa essas disposições legais. Antes de preparar um documento de execução, obtenha revisão separada das cláusulas completadas, detalhes da parte, signatário autorizado, termos comerciais e a versão exata do documento. Preserve o rascunho e a cópia de execução revisada como registros distintos. Mesmo uma conversão DOCX bem-sucedida não autoriza upload, envio ou assinatura. Veja o fluxo de trabalho de aprovação de posicionamento de campo de assinatura eletrônica.

Ambos os destinos de saída devem ser filhos diretos do diretório de saída resolvido. Um link simbólico existente em qualquer destino, incluindo um link pendente, é rejeitado antes que qualquer artefato seja escrito, mesmo quando a conversão DOCX está desabilitada. Arquivos regulares comuns podem ser reconstruídos. Use um diretório de saída que você controla; essas verificações não fornecem isolamento contra alterações concorrentes hostis no sistema de arquivos. Os caminhos de artefato retornados são absolutos.

Geometria da página de assinatura

O modelo termina o corpo com uma quebra de página OpenXML para que o bloco de assinatura solicite uma página nova em um renderizador DOCX compatível:

```{=openxml}
<w:p><w:r><w:br w:type="page"/></w:r></w:p>
```

A estrutura da página de assinatura (nosso bloco, depois o bloco da contraparte, cada um com Por, Nome, Cargo, Email, Data) é consistente, mas a paginação pode mudar com texto, fontes, renderizador ou formato. Inspecione o documento real revisado e sua geometria de página antes de colocar campos; veja o skill de posicionamento de campo de assinatura eletrônica.

Fluxo de trabalho de apêndice do Anexo A

Use a autoridade real e os requisitos de notificação do acordo executado:

1. Revise a economia da oportunidade e a estratégia de negociação em um canal interno de negociação/aprovação. Obtenha aprovação de compromisso antes de enviar conteúdo contratual. Um canal compartilhado com a contraparte não é um canal interno.
2. Confirme se a entrada proposta, função, termos, taxa e data de vigência estão dentro da autoridade expressa de notificação do Anexo A do acordo. Alterações nos termos permanentes, ou variações fora dessa autoridade, exigem o procedimento de emenda aplicável; uma notificação não pode criar sua própria exceção.
3. Redija uma notificação datada, aprovada e específica para a contraparte, para o destinatário e canal de notificação autorizados pelo acordo executado. Inclua conteúdo comercial útil: a contraparte ou lote protegido, função autorizada, termos comerciais e taxa aplicável. Exclua margens internas, estratégia de negociação, informações econômicas de outras partes, rastros de sistema, erros brutos e avisos de arquivamento interno.
4. Arquivar a notificação exata para aprovação do operador antes de enviar; veja operator-approval-loop. Mantenha silêncio no canal da contraparte enquanto aprovação ou autoridade de participação estiver ausente. Aprovação é distinta de evidência de que um remetente autorizado de fato entregou a notificação.
5. Registre a evidência de entrega autorizada, data de vigência e qualquer objeção de acordo com os requisitos reais do acordo executado. Períodos de exemplo não são padrões. Mantenha o documento executado imutável; atualize o registro de cronograma rastreado e reconstrua uma visão consolidada de rascunho para revisão interna, com referência à versão executada e à notificação aprovada. Esta reconstrução não substitui o acordo assinado nem comprova efeito legal.

Exemplos

Texto da notificação

Rascunho ilustrativo apenas: use estes termos e datas exclusivamente quando o acordo executado os autorizar e o operador aprovar esta notificação exata ao destinatário.

Notificação do Anexo A, 2026-09-02
Acordo: Acordo Mestre datado de 2026-08-14 entre Nós e Acme
Entrada 2: Lote B, 8 nodos, região UE-Oeste
Função: introducer
Termos: prazo de 6 meses, início até 2026-10-01
Taxa: padrão
Esta entrada entra em vigor hoje, a menos que você objete em até dez dias úteis
com evidência escrita datada de um relacionamento anterior com a contraparte.

Adicionando a entrada à especificação

"schedule": [
  ["1", "2026-08-20", "Lote A (16 nodos)", "introducer", "12 meses", "padrão"],
  ["2", "2026-09-02", "Lote B (8 nodos, UE-Oeste)", "introducer", "6 meses", "padrão"]
]

Reconstrua, diferencie o Markdown do rascunho e anexe o rascunho consolidado ao registro interno junto com o documento executado inalterado e a evidência da notificação.

Contraparte preenche seus próprios detalhes na assinatura

Para rascunho, omita legal, juris, addr, signer, title, email da especificação para renderizar linhas em branco. Um fluxo de trabalho de execução revisado separadamente deve decidir quais detalhes podem ser completados pela contraparte e verificar os campos reais; o gerador não cria ou aprova um envelope de assinatura eletrônica.