主協議產生器 是做什麼的？
一個主模板、每個交易對手一份小型規格、一個草稿建置步驟。 產生器始終將輸出標示為草稿，包括從已完成的模板產生的文件。成功的轉換僅證明文件產生的技術可行性，不具法律完整性、簽約授權，也不代表可直接寄送或簽署。已簽署的協議可能允許透過通知指定特定機會；在使用 Schedule A 工作流程之前，必須先確認此授權已確立。
使用時機
- 您需要向許多交易對手發行一份框架協議（如保密協議、轉介或尋源費用協議、非規避協議、主服務協議），且條款相同，僅少數幾個交易對手特定欄位不同。
- 交易會隨著時間推移而增加，而對每筆交易重新起草文件已成為瓶頸。
- 文件必須可從有版本控制的原始檔重現、可進行差異比對，且不受手動編輯影響。
- 簽名欄位由自動化工具放置，需要穩定的頁面佈局。
運作方式
模板
一個使用 {{PLACEHOLDER}} 欄位的單一 Markdown 模板。每個交易對手特定的值都是一個預留位置；其餘皆為固定文字。範例骨架位於 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，其中包含強制性的草稿聲明。預設情況下（或使用 --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 通知授權範圍。對標準條款的更改，或超出該授權範圍的變更，需要適用的修訂程序；通知不能自行建立例外。
- 為已簽署協議授權的接收者和通知管道起草一份經核准的、針對特定交易對手並標明日期的通知。包含有用的業務內容：受保護的交易對手或批次、授權角色、商業條款和適用的費用。排除內部利潤率、談判策略、其他當事方的經濟效益、系統追蹤、原始錯誤和內部歸檔通知。
- 在發送之前，將確切的通知歸檔以供操作員核准；請參閱 operator-approval-loop。在獲得核准或參與授權之前，在與交易對手的管道中保持緘默。核准與授權寄件人實際送達通知的證據是兩回事。
- 根據已簽署協議的實際要求，記錄授權送達的證據、生效日期以及任何異議。範例期限並非預設值。保持已執行文件不可變更；更新受追蹤的 schedule 記錄，並為內部審查重建一個統整草稿檢視，並引用已執行版本和核准的通知。此重建不會取代已簽署的協議或證明其法律效力。
範例
通知文字
僅供說明用的草稿：僅在已簽署協議授權且操作員核准此特定接收者通知時，才使用這些條款和日期。
Schedule A notice, 2026-09-02
Agreement: Master Agreement dated 2026-08-14 between Us and Acme
Entry 2: Lot B, 8 nodes, region EU-West
Role: introducer
Terms: 6 month term, start no later than 2026-10-01
Fee: standard
This entry takes effect today unless you object within ten business days
with dated written evidence of a prior relationship with the counterparty.
將條目加入規格
"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 欄位，以呈現空白行。一個單獨審查的執行工作流程必須決定哪些詳細資料可以由交易對手填寫，並驗證實際欄位；此產生器不會建立或核准電子簽名信封。