主协议生成器 是做什么的？
一份主模板、每份交易对手一份小规范、一个草稿构建步骤。 生成器始终将输出标记为 DRAFT，包括从已完成的模板生成的文档。 成功的转换证明了构件生成，而非法律完整性、签约授权或准备发送或签署就绪。 已签署的协议可能允许通过通知添加指定机会；必须在使用 Schedule A 工作流之前确立该授权。
何时使用
- 您向许多交易对手发布一份框架协议（如保密协议、转介或采购费协议、非规避协议、主服务协议），条款相同，仅少数特定于对方的字段不同。
- 交易随时间追加，而每次重新签约成为瓶颈。
- 文档必须可从追踪的源文件重现、可比较差异，且无人工编辑。
- 签名域由自动化放置，需要稳定的页面布局。
工作原理
模板
一个 Markdown 模板，其中包含 {{PLACEHOLDER}} 字段。每个特定于对方的字段都是一个占位符；其余所有内容均为固定文本。参考模板骨架位于 references/master-template.example.md。请将其中的通用句子替换为您法律顾问批准的条款。
参考脚本填充的占位符：
| 占位符 | 来源 |
|---|---|
{{DATE}} | spec.date，默认为今天 |
{{CP_SHORT}} | spec.short |
{{CP_LEGAL}}、{{CP_JURIS}}、{{CP_ADDR}} | 规范字段，或当对方在签署时自行填写时显示为空白行 |
{{ROLE_CLAUSE}}、{{FEE_TITLE}}、{{FEE_CLAUSE}} | 根据 spec.role 从角色表中选择 |
{{SCHEDULE_ROWS}} | spec.schedule，或仅含一行的“签署时无条目”行 |
{{SUPPLEMENT_CLAUSE}} | spec.supplement，在渲染时尾部附带分隔符或为空 |
{{CP_SIGBLOCK}}、{{CP_SIGNER}}、{{CP_TITLE}}、{{CP_EMAIL}} | 签名块字段，未知时显示空白 |
规范
每份交易对手对应一个 JSON 文件：
{
"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"
}
对于草稿，仅 file、short 和 role 为必填项。缺失的签名域在审阅和完成时渲染为空白行。参见 references/spec.example.json。
file 必须是一个非空的便携式文件名，例如 AcmeSupplier 或 Acme Supplier，不含目录组件。构建器会拒绝路径分隔符、驱动器/UNC 语法、控制字符、Windows 保留标点或设备名称以及尾随点或空格。无效名称在创建输出或调用 pandoc 之前被拒绝，不会进行清理或重命名。
省略 schedule 或使用 [] 表示“签署时无条目”占位符。提供的 schedule 必须是一个由六个单元格数组组成的密集数组，顺序为：编号、日期、受保护的交易对方或批次、角色、条款、费用。每个单元格必须是有效的 Unicode 字符串或有限数字；允许空字符串表示有意留空。Null、布尔值、对象、嵌套单元格数组、缺失单元格和非有限数字将在写入任何构件或 pandoc 活动之前被拒绝，并附带行/单元格索引。未配对的 UTF-16 代理项也会被拒绝，而不会在 UTF-8 输出期间被替换；支持的补充字符（如表情符号）仍受支持。
单元格是纯文本，而非 Markdown 或 HTML。构建器对语法字符进行编码，使文字管道符、反斜杠、反引号和标记保留在其原始字段中。每个 CRLF、裸 CR 或 LF 变为一个空格；换行符周围的文本得以保留。其他空白字符和文字标点符号在渲染的单元格中保持不变。源规范不会被修改。一个普通的有效 schedule 会保留其六列；格式错误的输入永远不会被静默替换为空 schedule。
角色表
spec.role 选择三个字符串：常设安排条款、费用章节标题和费用条款开头。
| 角色 | 谁支付 | 条款形式 |
|---|---|---|
| buyer | 交易对方在与其介绍的交易对手方发生的交易中支付 | 交易对方指定我们作为非独家代理来寻找和介绍 |
| supplier | 交易对方在与其介绍的交易对手方发生的交易中支付；当我们作为委托人购买时，我们按 schedule 条款签约 | 交易对方向我们以及我们介绍的买方提供产能 |
| mutual | 谁与对方介绍达成的交易，谁支付 | 任一方均可介绍；达成交易的一方支付 |
未知角色在构建时被拒绝。
构建
仅使用经操作员审核的模板和规范。Schedule A 之外的常规模板替换具有标记能力，并非用于不可信文档的清理器。Pandoc 可以读取引用的本地或远程资源；此生成器不沙箱化转换器的文件系统或网络访问。请审核那些引用并在您自己适当受限的环境中运行转换。专注的测试使用合成的转换器，并不认证真实的 DOCX 布局或隔离性。
node skills/master-agreement-generator/scripts/build-agreement.js \
skills/master-agreement-generator/references/master-template.example.md \
specs/AcmeSupplier.json \
out/
脚本填充占位符，渲染 schedule 表格，并写入 out/<file> MASTER.md 及强制的 DRAFT 通知。默认情况下（或使用 --require-docx）需要安装 pandoc 以生成非空的常规 .docx 构件。pandoc 缺失、转换失败或输出缺失/为空时返回退出码 1。每次 pandoc 探测或转换的时限为十秒。未知、重复或冲突的标志返回退出码 2。
明确使用 --markdown-only 以获得成功的纯 Markdown 草稿。此模式从不探测或调用 pandoc，从库返回 docxSkipped: true，且不为电子签名工作流提供 DOCX。库调用者必须传递 { markdownOnly: true }；仅传递 { pandoc: false } 现在会因 DOCX 要求而失败。结果始终报告 documentStatus: 'draft'。在重新构建其 Markdown 时，现有的生成 DOCX 会被移除；失败的转换不会留下部分 DOCX，因此较早的构件无法冒充为当前输出。将这两个生成文件保留在版本控制之外；模板和规范是源文件。
不存在执行副本模式。示例中故意包含未解决的括号起草指令；填充 {{PLACEHOLDER}} 标记并不完成那些法律条款。在准备执行文档之前，请单独审核已完成的条款、对方详情、授权签署人、商业条款以及准确的文档版本。将草稿和审核后的执行副本作为不同的记录保存。即使是成功的 DOCX 转换也不授权上传、发送或签署。请参考电子签名域放置审批工作流。
两个输出目的地必须是已解析的输出目录的直接子节点。任一路径上的现有符号链接（包括悬挂链接）在写入任一构件之前（即使禁用 DOCX 转换时）都会被拒绝。常规文件可以被重建。使用您控制的输出目录；这些检查不提供针对并发恶意文件系统更改的隔离。返回的构件路径为绝对路径。
签名页面几何布局
模板以 OpenXML 分页符结束正文，以便签名块在兼容的 DOCX 渲染器中请求一页新页面：
```{=openxml}
<w:p><w:r><w:br w:type="page"/></w:r></w:p>
```
签名页面结构（我方块，然后对方块，每个包含 By、Name、Title、Email、Date）是一致的，但分页可能因文本、字体、渲染器或格式而变化。在放置域之前检查实际审核过的文档及其页面几何布局；请参考电子签名域放置技能。
Schedule A 追加工作流
使用已签署协议的实际授权和通知要求：
- 在 内部 谈判/批准渠道中审核机会经济性和谈判策略。在发送合同内容之前获得承诺批准。共享的交易对方渠道不是内部渠道。
- 确认提议的条目、角色、条款、费用和生效日期是否在协议明确的 Schedule A 通知授权范围内。对常设条款的更改或超出该授权的变通需要适用的修订程序；通知不能创建其自身的例外。
- 为已签署协议授权的收件人和通知渠道起草一份经批准的、针对特定交易对方并注明日期的通知。包含有用的商业内容：受保护的交易对手方或批次、授权角色、商业条款和适用费用。排除内部利润率、谈判策略、其他交易方的经济信息、系统追踪、原始错误和内部备案通知。
- 在发送之前，将确切的通知文件提交给操作员批准；请参考操作员审批循环。在获得批准或参与授权之前，保持交易对方渠道的沉默。批准不同于授权发送方实际送达了通知的证据。
- 记录授权送达证据、生效日期以及根据已签署协议实际要求提出的任何异议。示例期限并非默认值。保持已签署文档不变；更新追踪的 schedule 记录并重建一份用于内部审核的 草稿综合视图，其中引用已签署版本和已批准的通知。此重建不取代已签署协议或证明法律效力。
示例
通知文本
仅为说明性草稿：仅在已签署协议授权且操作员批准此确切收件人通知时，才使用这些条款和日期。
Schedule A 通知，2026-09-02
协议：我方与 Acme 于 2026-08-14 签署的主协议
条目 2：Lot B，8 节点，区域 EU-West
角色：introducer
条款：6 个月期限，最晚于 2026-10-01 开始
费用：standard
此条目自今日起生效，除非您在十个工作日内提出异议，并提供与交易对手方存在先前关系的书面证据。
向规范中添加条目
"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"]
]
重新构建，对草稿 Markdown 进行差异比较，并将综合草稿附加到内部记录中，同时附上未更改的已签署文档和通知证据。
交易对方在签署时自行填写其详细信息
在起草时，从规范中省略 legal、juris、addr、signer、title、email，以渲染为空白行。独立的已审核执行工作流必须决定哪些详细信息可由交易对方填写，并验证实际字段；生成器不会创建或批准电子签名信封。