Generador de Acuerdos Marco
Una plantilla maestra, una especificación pequeña por contraparte, un paso de compilación de borrador. El generador siempre etiqueta la salida como BORRADOR, incluyendo los documentos generados a partir de una plantilla completa. Una conversión exitosa prueba la generación del artefacto, no la completitud legal, la autoridad para contratar ni la preparación para enviar o firmar. Un acuerdo ejecutado puede permitir que ciertas oportunidades designadas se añadan mediante notificación; esa autoridad debe establecerse antes de utilizar el flujo de trabajo del Anexo A.
Cuándo Usarlo
- Emite un acuerdo marco (NDA, honorarios por referidos o captación, no elusión, servicios maestros) a muchas contrapartes con los mismos términos y algunos campos específicos de cada parte.
- Las transacciones se agregan con el tiempo y rehacer cada una es el cuello de botella.
- Los documentos deben ser reproducibles a partir de una fuente rastreada, diferenciables y sin ediciones manuales.
- Los campos de firma se colocan mediante automatización y necesitan un diseño de página estable.
Cómo Funciona
Plantilla
Una única plantilla Markdown con campos {{MARCADOR}}. Cada valor específico de la contraparte es un marcador; todo lo demás es texto fijo. Un esqueleto vive en references/master-template.example.md. Reemplace sus oraciones genéricas con las cláusulas aprobadas por su asesoría legal.
Marcadores que el script de referencia completa:
| Marcador | Fuente |
|---|---|
{{DATE}} | spec.date, por defecto hoy |
{{CP_SHORT}} | spec.short |
{{CP_LEGAL}}, {{CP_JURIS}}, {{CP_ADDR}} | campos de la especificación, o una línea en blanco cuando la contraparte los completa al firmar |
{{ROLE_CLAUSE}}, {{FEE_TITLE}}, {{FEE_CLAUSE}} | seleccionados por spec.role de la tabla de roles |
{{SCHEDULE_ROWS}} | spec.schedule, o una fila de "sin entradas al firmar" |
{{SUPPLEMENT_CLAUSE}} | spec.supplement, renderizado con un separador final o vacío |
{{CP_SIGBLOCK}}, {{CP_SIGNER}}, {{CP_TITLE}}, {{CP_EMAIL}} | campos del bloque de firma, en blanco cuando se desconocen |
Especificación
Un archivo 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", "Lote A (16 nodos)", "introductor", "12 meses", "estándar"]],
"supplement": "el Anexo de Protección de Datos con fecha 2026-09-01"
}
Solo file, short y role son obligatorios para un borrador. Los campos de firma faltantes se renderizan como líneas en blanco para revisión y completado. Consulte references/spec.example.json.
file debe ser un nombre de archivo portable no vacío, como AcmeSupplier o Acme Supplier, sin componentes de directorio. El compilador rechaza cualquier separador de ruta, sintaxis de unidad/UNC, caracteres de control, puntuación reservada de Windows o nombres de dispositivo, y puntos o espacios finales. Los nombres inválidos se rechazan sin sanitizar ni renombrar, antes de crear la salida o invocar pandoc.
Omita schedule o use [] para el marcador de "sin entradas al firmar". Un schedule proporcionado debe ser, por lo demás, un array denso de arrays de seis celdas, en este orden: número, fecha, contraparte o lote protegido, rol, términos, tarifa. Cada celda debe ser una cadena Unicode válida o un número finito; se permiten cadenas vacías para espacios en blanco intencionales. Nulos, booleanos, objetos, arrays anidados de celdas, celdas faltantes y números no finitos se rechazan con un índice de fila/celda antes de cualquier escritura de artefacto o actividad de pandoc. Los pares suplentes UTF-16 no emparejados también se rechazan en lugar de reemplazarse durante la salida UTF-8; los caracteres suplementarios válidos, como emojis, permanecen compatibles.
Las celdas son texto plano, no Markdown ni HTML. El compilador codifica los caracteres de sintaxis para que las barras verticales literales, barras invertidas, acentos graves y marcado permanezcan en sus campos originales. Cada CRLF, CR solitario o LF se convierte en un espacio; el texto alrededor de los saltos de línea se conserva. Otros espacios en blanco y puntuación literal se preservan en las celdas renderizadas. La especificación fuente no se modifica. Un schedule válido ordinario conserva sus seis columnas; la entrada mal formada nunca se reemplaza silenciosamente con un schedule vacío.
Tabla de Roles
spec.role selecciona tres cadenas: la cláusula de acuerdo permanente, el título de la sección de tarifas y la apertura de la cláusula de tarifa.
| Rol | Quién paga | Forma de la cláusula |
|---|---|---|
| buyer | La contraparte paga en transacciones con partes introducidas | La contraparte nos designa en base no exclusiva para buscar e introducir |
| supplier | La contraparte paga en transacciones con partes introducidas; cuando compramos como principal contratamos en los términos del schedule | La contraparte ofrece capacidad a nosotros y a los compradores que introducimos |
| mutual | Quien cierra con la introducción de la otra paga | Cada parte puede introducir; la parte que cierra paga |
Los roles desconocidos se rechazan en el momento de la compilación.
Compilación
Utilice solo plantillas y especificaciones revisadas por un operador. Las sustituciones normales de plantillas fuera del Anexo A son capaces de manejar marcado, no son un sanitizador para documentos no confiables. Pandoc puede leer recursos locales o remotos referenciados; este generador no aísla el acceso al sistema de archivos o red del convertidor. Revise esas referencias y ejecute la conversión en su propio entorno adecuadamente restringido. Las pruebas enfocadas utilizan un convertidor sintético y no certifican el diseño real de DOCX ni el aislamiento.
node skills/master-agreement-generator/scripts/build-agreement.js \
skills/master-agreement-generator/references/master-template.example.md \
specs/AcmeSupplier.json \
out/
El script completa los marcadores, renderiza la tabla del schedule y escribe out/<file> MASTER.md con un aviso obligatorio de BORRADOR. De forma predeterminada (o con --require-docx) requiere pandoc instalado para producir un artefacto .docx regular no vacío. La falta de pandoc, la conversión fallida o la salida faltante/vacía devuelven el código de salida 1. Cada sonda o conversión de pandoc tiene un límite de diez segundos. Banderas desconocidas, duplicadas o en conflicto devuelven el código de salida 2.
Use --markdown-only explícitamente para un borrador Markdown exitoso. Este modo nunca sondea ni invoca pandoc, devuelve docxSkipped: true desde la biblioteca, y no proporciona DOCX para un flujo de trabajo de firma electrónica. Los llamantes de la biblioteca deben pasar { markdownOnly: true }; { pandoc: false } solo ahora falla el requisito de DOCX. El resultado siempre reporta documentStatus: 'draft'. El DOCX generado existente se elimina al reconstruir su Markdown, y la conversión fallida no deja un DOCX parcial, por lo que un artefacto anterior no puede hacerse pasar por la salida actual. Mantenga ambos archivos generados fuera del control de versiones; la plantilla y las especificaciones son la fuente.
No existe el modo de copia de ejecución. El ejemplo contiene deliberadamente directivas de redacción no resueltas entre corchetes; llenar los tokens {{MARCADOR}} no completa esas disposiciones legales. Antes de preparar un documento de ejecución, obtenga una revisión separada de las cláusulas completadas, los detalles de la parte, el firmante autorizado, los términos comerciales y la versión exacta del documento. Conserve el borrador y la copia de ejecución revisada como registros distintos. Incluso una conversión exitosa a DOCX no autoriza una carga, envío o firma. Vea el flujo de trabajo de aprobación de esign-field-placement.
Ambos destinos de salida deben ser hijos directos del directorio de salida resuelto. Un enlace simbólico existente en cualquiera de los destinos, incluido un enlace roto, se rechaza antes de escribir cualquiera de los artefactos, incluso cuando la conversión a DOCX está deshabilitada. Los archivos regulares ordinarios pueden reconstruirse. Use un directorio de salida que usted controle; estas comprobaciones no proporcionan aislamiento contra cambios hostiles concurrentes en el sistema de archivos. Las rutas de artefacto devueltas son absolutas.
Geometría de la Página de Firma
La plantilla finaliza el cuerpo con un salto de página OpenXML para que el bloque de firma solicite una página nueva en un renderizador DOCX compatible:
```{=openxml}
<w:p><w:r><w:br w:type="page"/></w:r></w:p>
```
La estructura de la página de firma (nuestro bloque, luego el bloque de la contraparte, cada uno con Por, Nombre, Cargo, Correo Electrónico, Fecha) es consistente, pero la paginación puede cambiar con el texto, las fuentes, el renderizador o el formato. Inspeccione el documento real revisado y su geometría de página antes de colocar campos; vea la habilidad esign-field-placement.
Flujo de Trabajo para Agregar al Anexo A
Use la autoridad real y los requisitos de notificación del acuerdo ejecutado:
- Revise la economía de la oportunidad y la estrategia de negociación en un canal interno de negociación/aprobación. Obtenga la aprobación del compromiso antes de enviar contenido contractual. Un canal compartido con la contraparte no es un canal interno.
- Confirme que la entrada propuesta, el rol, los términos, la tarifa y la fecha de vigencia se encuentren dentro de la autoridad expresa de notificación del Anexo A del acuerdo. Los cambios en los términos vigentes, o las variaciones fuera de esa autoridad, requieren el procedimiento de modificación aplicable; una notificación no puede crear su propia excepción.
- Redacte una notificación fechada aprobada y específica para la contraparte, para el destinatario y canal de notificación autorizados por el acuerdo ejecutado. Incluya contenido comercial útil: la contraparte o lote protegido, el rol autorizado, los términos comerciales y la tarifa aplicable. Excluya márgenes internos, estrategia de negociación, información económica de otras partes, rastros del sistema, errores sin procesar y avisos internos de archivo.
- Archive la notificación exacta para la aprobación del operador antes de enviarla; vea operator-approval-loop. Mantenga silencio en el canal de la contraparte mientras falte la aprobación o autoridad de participación. La aprobación es distinta de la evidencia de que un remitente autorizado realmente entregó la notificación.
- Registre la evidencia de entrega autorizada, la fecha de vigencia y cualquier objeción según los requisitos reales del acuerdo ejecutado. Los períodos de ejemplo no son valores predeterminados. Mantenga el documento ejecutado inmutable; actualice el registro de schedule rastreado y reconstruya una vista consolidada de borrador para revisión interna, con una referencia a la versión ejecutada y la notificación aprobada. Esta reconstrucción no reemplaza el acuerdo firmado ni prueba el efecto legal.
Ejemplos
Texto de Notificación
Borrador ilustrativo únicamente: use estos términos y fechas solo cuando el acuerdo ejecutado los autorice y el operador apruebe esta notificación exacta al destinatario.
Notificación del Anexo A, 2026-09-02
Acuerdo: Acuerdo Marco con fecha 2026-08-14 entre Nosotros y Acme
Entrada 2: Lote B, 8 nodos, región UE-Oeste
Rol: introductor
Términos: plazo de 6 meses, inicio a más tardar el 2026-10-01
Tarifa: estándar
Esta entrada surte efecto hoy a menos que usted objete dentro de diez días hábiles
con evidencia escrita fechada de una relación previa con la contraparte.
Agregar la Entrada a la Especificación
"schedule": [
["1", "2026-08-20", "Lote A (16 nodos)", "introductor", "12 meses", "estándar"],
["2", "2026-09-02", "Lote B (8 nodos, UE-Oeste)", "introductor", "6 meses", "estándar"]
]
Recompile, diferencie el Markdown del borrador y adjunte el borrador consolidado al registro interno junto con el documento ejecutado sin cambios y la evidencia de notificación.
La Contraparte Completa Sus Propios Detalles al Firmar
Para la redacción, omita legal, juris, addr, signer, title, email de la especificación para renderizar líneas en blanco. Un flujo de trabajo de ejecución revisado por separado debe decidir qué detalles puede completar la contraparte y verificar los campos reales; el generador no crea ni aprueba un sobre de firma electrónica.