O que Gerador de Contratos-Mestre faz?
Um modelo mestre, uma especificação pequena por contraparte, uma etapa de compilação de rascunho. O gerador sempre rotula a saída como DRAFT, 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 legal, autoridade para contratar ou prontidão para enviar ou assinar. Um contrato assinado 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-quadro (NDA, taxa de referência ou de sourcing, não-circunvenção, serviços master) para muitas contrapartes com os mesmos termos e alguns campos específicos da parte.
- Os negócios são adicionados ao longo do tempo e a re-elaboração de cada um é o gargalo.
- Os documentos devem ser reproduzíveis a partir de fonte rastreada, passíveis de diff e livres de edições manuais.
- Os campos de assinatura são colocados por automação e precisam de um layout de página estável.
Como Funciona
Template
Um único modelo Markdown com campos {{PLACEHOLDER}}. Cada valor específico da parte é um placeholder; todo o resto é texto fixo. Um esqueleto está em references/master-template.example.md. Substitua suas sentenças genéricas por cláusulas aprovadas pelo seu jurídico.
Placeholders que o script de referência preenche:
| Placeholder | Fonte |
|---|---|
{{DATE}} | spec.date, padrão hoje |
{{CP_SHORT}} | spec.short |
{{CP_LEGAL}}, {{CP_JURIS}}, {{CP_ADDR}} | campos da spec, ou uma linha em branco quando a contraparte os preenche na assinatura |
{{ROLE_CLAUSE}}, {{FEE_TITLE}}, {{FEE_CLAUSE}} | selecionado por spec.role 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 |
Spec
Um arquivo JSON por contraparte:
{
"file": "AcmeSupplier",
"short": "Acme",
"role": "supplier",
"legal": "Acme Compute Ltd",
"juris": "England and Wales company",
"addr": "1 Example Street, London",
"signer": "A. Person",
"title": "Director",
"email": "[email protected]",
"schedule": [["1", "2026-09-01", "Lot A (16 nodes)", "introducer", "12 months", "standard"]],
"supplement": "the Data Processing Addendum dated 2026-09-01"
}
Apenas file, short e role são obrigatórios para um rascunho. Campos de assinatura ausentes são renderizados como linhas em branco para revisão e conclusão. Veja references/spec.example.json.
file deve ser um nome de arquivo portátil 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 ou nomes de dispositivos reservados do Windows, 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 pandoc.
Omita schedule ou use [] para o placeholder "sem entradas na assinatura". Um cronograma fornecido deve ser, caso contrário, uma matriz densa de matrizes 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 em branco intencionais. Nulos, booleanos, objetos, matrizes 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 escrita de artefato ou atividade do pandoc. Pares substitutos 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, crases e marcação permaneçam em seus campos originais. Cada CRLF, CR ou LF solto torna-se um espaço; o texto ao redor das quebras de linha é retido. Outros espaços em branco e pontuação literal são preservados nas células renderizadas. A spec de origem não é modificada. Um cronograma válido comum mantém suas seis colunas; uma 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 taxas e a abertura da cláusula de taxas.
| 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 introduzir |
| supplier | A contraparte paga nas transações com partes introduzidas; quando compramos como principal, contratamos nos termos do cronograma | A contraparte oferece capacidade a nós e a compradores que introduzimos |
| mutual | Quem fecha com a introdução do outro paga | Cada parte pode introduzir; a parte que fecha paga |
Funções desconhecidas são rejeitadas no momento da compilação.
Compilação
Use apenas templates e specs revisados pelo operador. Substituições comuns de template fora do Anexo A são capazes de marcação, 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 acesso ao sistema de arquivos ou rede do conversor. Revise essas referências e execute a conversão em seu próprio ambiente adequadamente restrito. Os testes focados usam um conversor sintético e não certificam o layout DOCX real 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 placeholders, renderiza a tabela do cronograma e escreve out/<file> MASTER.md com um aviso obrigatório de DRAFT. Por padrão (ou com --require-docx) ele requer pandoc instalado para produzir um artefato .docx regular 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 Markdown bem-sucedido. Este modo nunca testa ou invoca 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 falha não deixa DOCX parcial, então um artefato anterior não pode se passar pela saída atual. Mantenha ambos os arquivos gerados fora do controle de versão; o template e as specs são a fonte.
Não há modo de cópia de execução. O exemplo contém deliberadamente diretivas de redação entre colchetes não resolvidas; preencher tokens {{PLACEHOLDER}} não completa essas disposições legais. Antes de preparar um documento de execução, obtenha revisão separada das cláusulas concluídas, detalhes das partes, signatário autorizado, termos comerciais e 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 quebrado, é 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 dos artefatos retornados são absolutos.
Geometria da página de assinatura
O template 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 a 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 contrato assinado:
- 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 de contraparte compartilhado não é um canal interno.
- 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 contrato. 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.
- Redija uma notificação datada aprovada e específica da contraparte para o destinatário e canal de notificação autorizados pelo contrato assinado. 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, economia de outras partes, rastros de sistema, erros brutos e avisos de arquivamento interno.
- Arquive a notificação exata para aprovação do operador antes de enviar; veja o loop de aprovação do operador. Preserve silêncio no canal da contraparte enquanto a aprovação ou autoridade de participação estiver ausente. Aprovação é distinta de evidência de que um remetente autorizado realmente entregou a notificação.
- Registre a evidência de entrega autorizada, data de vigência e qualquer objeção sob os requisitos reais do contrato assinado. Períodos de exemplo não são padrões. Mantenha o documento assinado 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 assinada e notificação aprovada. Esta reconstrução não substitui o contrato assinado nem prova efeito legal.
Exemplos
Texto de notificação
Apenas rascunho ilustrativo: use estes termos e datas somente quando o contrato assinado os autorizar e o operador aprovar esta notificação exata ao destinatário.
Notificação do Anexo A, 2026-09-02
Contrato: Contrato-Mestre datado de 2026-08-14 entre Nós e Acme
Entrada 2: Lote B, 8 nós, região UE-Oeste
Função: introducer
Termos: prazo de 6 meses, início até 2026-10-01
Taxa: standard
Esta entrada entra em vigor hoje, a menos que você objete em até dez dias úteis
com prova escrita datada de um relacionamento anterior com a contraparte.
Adicionando a entrada à spec
"schedule": [
["1", "2026-08-20", "Lot A (16 nodes)", "introducer", "12 months", "standard"],
["2", "2026-09-02", "Lot B (8 nodes, EU-West)", "introducer", "6 months", "standard"]
]
Recompile, faça diff do rascunho Markdown e anexe o rascunho consolidado ao registro interno junto com o documento assinado 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 spec para renderizar linhas em branco. Um fluxo de trabalho de execução revisado separadamente deve decidir quais detalhes podem ser preenchidos pela contraparte e verificar os campos reais; o gerador não cria ou aprova um envelope de assinatura eletrônica.