撥款通知信的每個日期，都能指回合約

合約條文寫在常數旁邊

NOTICE_DAY（通知寄出日）與 PAY_MONTH_OFFSET（撥款落在結算月之後第幾個月）是把合約條文搬進程式的兩張表。寫入前，已把三份合約裡「明細通知寄出日」「發票開立期限」「撥款日」的條文逐字對過一遍，再把對應關係註解在表格旁。之後跟法務對條文時，讀註解就夠，不必回頭翻整份合約。

合約沒寫清楚的地方也記在同一處。「7 個工作日」是否包含通知當天，合約未明定，目前採隔日起算，並在註解中標明這是假設，不是定案。

順延邏輯與假日表

假日表是寫死在程式裡的一份日期清單（Set），涵蓋 2026–2027 兩年的政府公告國定假日與補假。銀行營業日的判斷同時看週末與假日表；撥款日從約定的 10 日起每次加一天，直到遇到營業日為止。

這張表沒有接任何行事曆 API，超出涵蓋年份之後撥款日就會算錯，程式碼中有註解直接點出這一點。順延演算法本身與資料來源無關，將來要換成從別處讀取假日時，替換的只有這個常數。

八封信共用一組版面函式

八封信的問候語、金額表格、發票資訊區塊與防詐提醒大量重複。若各自維護八個範本，改一次版面就得改八處，很容易漏掉其中一封。因此版面拆成一組基礎函式（段落、表格、列、提示框、按鈕），兩種信件函式只負責以不同順序把它們組起來。

README 明訂不手改產出的 HTML，因為重跑會被覆蓋，文案一律改產生器後重新執行。

產出檔案前的九條驗算

執行時，腳本會在產出檔案前以 Node 內建的 assert 跑九條驗算，涵蓋撥款日順延（含跨年進位與國慶日補假等邊界）、各方案的撥款月位移，以及發票開立期限的算式。九條全部通過才寫入檔案。

這組驗算沒有覆蓋率報告，它只做一件事：日期算式被改壞時當場失敗，而不是默默產出一個錯誤的日期。

預覽與列印，寄送留給人

產生器會把 logo 與字型編碼成文字（base64）後直接嵌入單一頁面的 index.html，斷網也能檢視；另外產出逐信一頁的列印版，交由無介面瀏覽器（不開視窗、在背景運作的瀏覽器）轉成 PDF。

寄送刻意不放在這支工具裡。信一寄出就是對外的付款承諾，中間保留一道人工檢視比較穩妥。

發票上傳：token 與三條規則

合作方沒有系統帳號，身分只靠每家一組的專屬 token。網頁與實際處理上傳的函式各自驗證一次 token，因為處理函式可以被直接呼叫，只驗網頁那一層等於沒驗。缺 token、token 錯誤、或查無當期資料，一律回覆同一句話，避免錯誤訊息被拿來試探其他合作方的 token。上傳的檔案只在單次請求的記憶體中驗證，不寫入雲端硬碟。

OCR 服務本身會給出「是否通過」的判斷，但那是為內部報帳設計的，與「合作方開出的發票是否正確」不是同一件事，所以不採用，改由三條規則判定：金額必須完全相符、統一編號須對得上公司、辨識信心度不得為「低」。任一條不過就退回，並說明原因。

限流卡在呼叫 OCR 之前。OCR 按次計費，而公開網址任何人都能打，所以以 token 為 key，六小時最多 20 次。這個計數的目的是擋住帳單，不是做稽核用的精確紀錄，因此允許它不是絕對精準。