¿Qué hace Generador de Acuerdos Marco?
Una plantilla maestra, una especificación pequeña por contraparte, un paso de compilación del borrador. El generador siempre etiqueta la salida como BORRADOR, incluidos los documentos generados apartir de una plantilla completada. Una conversión exitosa prueba la generación del artefacto, no la integridad legal, la autoridad para contratar ni la preparación para enviar o firmar. Un acuerdo ejecutado puede permitir que se agreguen oportunidades designadas 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, tarifa de referencia o captación, no elusión, servicios maestros) a muchas contrapartes con los mismos términos y algunos campos específicos de la parte.
- Los acuerdos se agregan con el tiempo y volver a redactar cada uno es el cuello de botella.
- Los documentos deben ser reproducibles a partir de una fuente controlada, diferenciales y libres de 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 plantilla Markdown única con campos {{MARCADOR_DE_POSICIÓN}}. Cada valor específico de la parte
es un marcador de posición; todo lo demás es texto fijo. Un esqueleto se encuentra en
references/master-template.example.md.
Reemplace sus oraciones genéricas con sus cláusulas aprobadas por el asesor legal.
Marcadores de posición que completa el script de referencia:
| Marcador de posición | Fuente |
|---|---|
{{DATE}} | spec.date, por defecto hoy |
{{CP_SHORT}} | spec.short |
{{CP_LEGAL}}, {{CP_JURIS}}, {{CP_ADDR}} | campos de spec, 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, representado 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 Procesamiento de Datos con fecha 2026-09-01"
}
Solo se requieren file, short y role para un borrador. Los campos de firma faltantes se representan
como líneas en blanco para revisión y finalización. Consulte
references/spec.example.json.
file debe ser un nombre de archivo portátil 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 o nombres de dispositivo reservados por Windows,
y puntos o espacios finales. Los nombres no válidos se rechazan sin
sanearlos o renombrarlos, antes de crear la salida o invocar pandoc.
Omita schedule o use [] para el marcador de posición "sin entradas al firmar". Un cronograma proporcionado
debe ser, por lo demás, una matriz densa de matrices 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.
Los nulos, booleanos, objetos, matrices de celdas anidadas, 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 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, siguen siendo compatibles.
Las celdas son texto sin formato, no Markdown ni HTML. El compilador codifica los caracteres de sintaxis para que las barras verticales literales, las barras invertidas, los acentos graves y el marcado permanezcan en sus campos originales. Cada CRLF, CR o LF independiente se convierte en un espacio; se conserva el texto alrededor de los saltos de línea. Otros espacios en blanco y puntuación literal se conservan en las celdas renderizadas. La especificación fuente no se modifica. Un cronograma válido ordinario conserva sus seis columnas; la entrada mal formada nunca se reemplaza silenciosamente con un cronograma vacío.
Tabla de roles
spec.role selecciona tres cadenas: la cláusula del acuerdo permanente, el título de la sección
de honorarios y la cláusula de apertura de honorarios.
| Rol | Quién paga | Forma de la cláusula |
|---|---|---|
| buyer | La contraparte paga en transacciones con partes introducidas | La contraparte nos nombra en base no exclusiva para buscar e introducir |
| supplier | La contraparte paga en transacciones con partes introducidas; cuando compramos como principal, contratamos según los términos del cronograma | La contraparte nos ofrece capacidad y a los compradores que presentamos |
| mutual | Quien cierra con la introducción del otro paga | Cada parte puede presentar; la parte que cierra paga |
Los roles desconocidos se rechazan en el momento de la compilación.
Compilación
Use solo plantillas y especificaciones revisadas por el operador. Las sustituciones de plantilla ordinarias fuera del Anexo A son capaces de usar marcado, no un desinfectante para documentos no confiables. Pandoc puede leer recursos locales o remotos referenciados; este generador no pone en cuarentena el acceso al sistema de archivos o red del convertidor. Revise esas referencias y ejecute la conversión en su propio entorno apropiadamente restringido. Las pruebas centradas usan un convertidor sintético y no certifican un diseño DOCX real o 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 de posición, renderiza la tabla del cronograma y escribe
out/<file> MASTER.md con un aviso obligatorio de BORRADOR. Por defecto (o con
--require-docx) requiere pandoc instalado para producir un artefacto .docx regular no vacío.
La falta de pandoc, una conversión fallida o una salida faltante/vacía
devuelve el código de salida 1. Cada sonda o conversión de pandoc tiene un límite de diez segundos.
Las banderas desconocidas, duplicadas o conflictivas devuelven el código de salida 2.
Use --markdown-only explícitamente para un borrador exitoso solo en Markdown. Este modo
nunca prueba o invoca pandoc, devuelve docxSkipped: true desde la biblioteca
y no proporciona DOCX para un flujo de trabajo de firma electrónica. Los llamadores de la biblioteca deben pasar
{ markdownOnly: true }; { pandoc: false } solo ahora falla el requisito de DOCX.
El resultado siempre informa documentStatus: 'draft'. El DOCX generado existente se
elimina al reconstruir su Markdown, y una 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 hay modo de copia de ejecución. El ejemplo contiene deliberadamente directrices de redacción
no resueltas entre corchetes; completar los tokens {{MARCADOR_DE_POSICIÓN}} 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 las partes, 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 DOCX exitosa no autoriza una
carga, envío o firma. Consulte el flujo de trabajo de aprobación de colocación de campos de firma electrónica.
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 colgante, se rechaza antes de escribir cualquiera de los artefactos, incluso cuando la conversión DOCX está deshabilitada. Los archivos regulares ordinarios se pueden reconstruir. Use un directorio de salida que controle; estas comprobaciones no proporcionan aislamiento contra cambios concurrentes hostiles en el sistema de archivos. Las rutas de artefactos 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; consulte la habilidad de colocación de campos de firma electrónica.
Flujo de trabajo de apéndice del 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 efectiva se encuentran dentro de la autoridad de notificación expresa del Anexo A del acuerdo. Los cambios en los términos permanentes, o las variaciones fuera de esa autoridad, requieren el procedimiento de enmienda 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 el 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, aspectos económicos de otras partes, rastros del sistema, errores sin procesar y avisos de presentación internos.
- Archive la notificación exacta para la aprobación del operador antes de enviarla; consulte el bucle de aprobación del operador. Mantenga silencio en el canal de la contraparte mientras falte la aprobación o la 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 efectiva y cualquier objeción según los requisitos reales del acuerdo ejecutado. Los plazos de ejemplo no son valores predeterminados. Mantenga el documento ejecutado inmutable; actualice el registro del cronograma 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 solamente: use estos términos y fechas únicamente cuando el acuerdo ejecutado lo 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 EU-West
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 se oponga dentro de los 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, EU-West)", "introductor", "6 meses", "estándar"]
]
Reconstruya, diferencie el Markdown del borrador y adjunte el borrador consolidado al registro interno junto con el documento ejecutado sin cambios y la evidencia de la notificación.
La contraparte completa sus propios datos al firmar
Para el borrador, omita legal, juris, addr, signer, title, email de la
especificación para representar líneas en blanco. Un flujo de trabajo de ejecución revisado por separado debe decidir
qué detalles pueden ser completados por la contraparte y verificar los campos reales;
el generador no crea ni aprueba un sobre de firma electrónica.