專案進入一個值得慶祝的階段，並不代表系統可以立即寄出禮物。Linear 的事件可以提醒團隊檢查里程碑；贈禮資格、預算、收件人意願及地址仍須由適當的負責人確認。可靠的做法，是把事件轉成一筆可追溯的待審請求，核准後才交給贈禮執行端，最後以實際履約與費用資料結案。本文提供產品營運與整合工程團隊可實作、可測試的流程，並以兩個假設情境展示重送與撤銷的處置。
先定義值得審查的里程碑
一個專案移到「完成」狀態，可能只是內部整理；一張議題關閉，可能會在下一分鐘重新開啟。產品營運負責人應先寫明何種事件才會建立待審贈禮請求。例如專案達到事先命名的客戶上線里程碑、指定負責人完成驗收、且沒有仍在處理的封鎖事項。工程團隊負責讀取事件和當下的專案資料，不能自行決定誰有資格收禮。財務與政策負責人則定義金額上限、禁止對象、利益衝突與例外核准。若客戶或員工是收件人，適用的告知、同意、稅務與僱主政策須由組織自行判斷。
先用一頁決策表記下事件來源、里程碑識別碼、觸發條件、覆核者、預算、重複期間與撤銷條件。對每條條件附上一個可觀察的證據，例如 Linear 專案識別碼、狀態轉移、驗收紀錄及核准人。切勿以某個含糊的狀態名稱當成全域業務規則；不同團隊對「完成」的意義可能不同。若來源資料不足，將請求停在「待補證據」，而不是把缺少資訊解讀為同意或資格通過。
在試行階段，只選一個團隊、一種里程碑、一個預算範圍和一個負責核准的角色。產品營運先逐筆核對真實事件，工程師對照來源頁面和接收紀錄，財務確認成本科目及可用餘額。驗收的基準不是觸發了多少禮物，而是每筆請求都能解釋它從何而來、由誰作決定，以及若事件後來改變，誰處理後續。
決策表還要說明三個不同時間點各自的用途。事件發生時的狀態用來確認候選里程碑；核准時讀到的最新狀態用來避免批准已撤銷的事件；向外部提交前的狀態用來決定是否仍可執行。若三者不一致，不能只取最方便的一個值。請求應顯示原值、現值與查詢時間，交由負責人選擇暫停、補證據或重新核准。團隊也需決定工作區改名、專案合併、里程碑重設時如何保留舊識別碼，否則歷史對帳將失去錨點。
計畫負責人可以把無法清楚判定的事件視為「不符合自動處理條件」，但仍留在例外清單供人工檢查。這比默默忽略可靠：如果來源有合格事件而內部沒有請求，日後對帳應能看見差異。例外關閉時要記下誰認定它不適用、依哪一版規則，以及是否需要修訂規則。這些紀錄不代表每個事件都應收到禮物，而是讓遺漏與拒絕有不同、可說明的原因。
接收 Linear 事件，但不要把事件當命令
Linear 的網路掛鉤文件列出專案、專案更新與議題等事件類型。註冊與授權應依組織實際權限辦理；建立網路掛鉤可能需要管理權限或相應的授權範圍。接收端應使用公開可達的安全傳輸網址，快速驗證並持久化訊息後回應成功，再由背景處理程序執行業務檢查。若在網路要求內等待人工核准，逾時重送會放大重複處理風險。
接收時以原始要求內容驗證 Linear-Signature 的 HMAC-SHA256（以密鑰驗證訊息完整性的雜湊演算法）簽章，檢查 webhookTimestamp 是否處於可接受時間窗，並記錄 Linear-Delivery 的交付識別碼。這些名稱和驗證方式來自官方文件；實作時仍須以目前文件與收到的實際欄位為準。不得先重新格式化內容再計算簽章，也不要把簽章密鑰寫入事件紀錄。密鑰輪替時要有明確的過渡與失敗處理程序。簽章或時間檢查失敗的要求應拒絕，並只記錄不含敏感內容的診斷資訊。
一筆有效交付表示 Linear 曾送出一項變更通知，不代表贈禮條件已經成立。處理程序要確認來源工作區、專案、事件種類、狀態前後值與事件時間。更新事件可利用官方說明的 updatedFrom 判斷哪些欄位發生變動；仍應在必要時透過官方 GraphQL 介面（可指定所需欄位的查詢方式）讀取目前資料。資料讀取有速率與複雜度限制，需依 Linear 的限制文件設計排隊、退避及快取。當通知與目前狀態相衝突，先標記待覆核，不要自動補送。
把原始交付和後續的業務決策分成兩種紀錄。前者回答「接收了哪個通知，驗證結果如何」；後者回答「哪項里程碑、哪種資格、誰核准、是否已向贈禮端提交」。前者可因重送而出現多次，後者在同一規則及同一對象下應只有一個有效執行路徑。這一層分隔讓工程師能安全地重放接收作業，而不會把每一次重放都變成新禮物。
接收端也要限制接受的來源及事件類別，不能只因簽章有效就讓所有專案進入同一贈禮計畫。不同工作區的密鑰、規則與隊列要分開管理。若密鑰需要輪替，先確認舊密鑰與新密鑰各自允許的時間窗，再安排切換及監控；不要在失敗時關閉簽章檢查來維持表面的可用率。為了除錯保存的原始訊息也要受權限及保存期限限制。工程師需要能找回交付識別碼和驗證結果，不需要在一般警報中顯示完整個資。
建立穩定的防重鍵與狀態機
不要只依交付識別碼防重。官方文件說明失敗後可能重試，同一里程碑也可能由多種變更事件碰巧觸發。交付識別碼適合找出同一次傳送的重複；業務防重鍵則應由組織、專案、里程碑定義、贈禮計畫版本與合資格對象的內部識別碼組成。不能把姓名或電郵原文放進防重鍵。若政策允許同一里程碑在新的計畫週期再送一次，週期也必須成為鍵的一部分，且需經明確批准。
在資料庫對業務防重鍵設唯一約束，交易式建立待審紀錄。收到事件時先搜尋既有鍵：已在待審中的請求更新證據，不新增另一筆；已核准或已送出的請求保留原結果，將新事件標為後續變更；被拒絕的請求若要重開，應由有權負責人明確建立新決策版本。這是建議的系統設計，不是宣稱 Linear 或任何贈禮服務自動提供該約束。
唯一鍵的設計要通過「不同人不得合併、同一人不得重複」兩類邊界測試。若同一專案同時有兩個合法收禮對象，鍵必須區分對象；若同一人有多個來源事件指向同一項認可，鍵又必須聚合為一筆。受領資格改變時，不可直接用新的電子郵件產生第二個身份。由有權的資料管理員處理身份合併或拆分，留下前後識別碼、原因及對已送出請求的影響。這部分通常比單純比較交付識別碼更接近實際防重的難點。
狀態可採用「已接收、待驗證、待審、已拒絕、已核准、提交中、提交結果待查、已受理、履約中、已結案、待處理例外」。每次轉移都要保留時間、操作者、原因、來源證據和對外請求識別碼。付款或履約已發生後，不應把紀錄倒退成「從未送出」。若外部呼叫逾時，進入「提交結果待查」，先向既有服務與紀錄核對原請求結果，不能換識別碼再送一次。
| 觀察到的情況 | 系統動作 | 人工決策及驗收證據 |
|---|---|---|
| 首次收到有效里程碑事件 | 保存交付、查詢目前專案，建立唯一待審鍵 | 產品營運確認業務意義；來源與規則版本可追查 |
| 相同交付重送 | 記錄重送次數，回傳既有請求，不新增贈禮 | 工程師能指出既有鍵與原核准紀錄 |
| 核准後對外提交逾時 | 保留原外部識別碼，暫停新提交並查原結果 | 營運人員核對受理、邀請或訂單證據後解鎖 |
| 專案里程碑撤銷 | 保留歷史並建立待處置變更 | 政策負責人決定取消、保留或例外結案 |
審核要看到資格、預算與資料邊界
審核畫面應顯示專案里程碑與來源連結、計畫和規則版本、收禮對象的最小識別資訊、擬用預算、是否曾在同一週期收過禮、收件人資料取得路徑，以及適用例外。核准人不應只能按「同意」；他也需要拒絕、要求補證據、變更預算或轉交合適的政策負責人。所有更動記錄理由。若收件人對象涉及員工、客戶或公務部門，組織自己的政策與專業意見優先於工具預設值。
一個常見選擇是「事件立即寄出」與「事件只開立待審請求」。前者看似快速，但當專案狀態回復、預算不足或收件人拒絕時，逆轉成本很高。後者增加一次人工決策，卻能把錯誤留在可取消階段。若團隊有經政策核准的低風險自動額度，仍應明確列出自動核准的範圍、例外和事後抽查；不能把所有新類型里程碑默認放行。
資料最小化是流程設計的一部分。Linear 專案資料通常不應成為收件人地址簿。先在內部系統保留對象識別碼，待審核通過並確定適用的告知與同意方式後，再透過核准的安全流程取得配送所需資料。限制有權查閱的人員、保存期限及刪除或更正程序。可參照 Giftpack 的繁體中文收件人資料營運指南，再由組織的隱私和法務團隊確認實際做法。
選擇交付方式：手動交接或已驗證的介面
Giftpack 的開發者文件描述企業活動與收禮人流程，也區分市集訂單與收件人流程，並要求伺服器端保護介面密鑰。這些文件並未因此證明存在即用的 Linear 原生連接器。產品負責人應先與 Giftpack 確認可使用的方案、權限、實際端點、欄位、生命週期、錯誤回覆及合約範圍。介面細節可能變動；在完成沙盒測試與雙方批准前，別把推測的請求格式放進正式系統。
若沒有經驗證的介面權限，可使用受控手動交接：審核通過後，營運人員從內部待審台帳取出單一核准項目，透過已授權的 Giftpack 工作流程建立對應活動或邀請，將回傳的識別碼與可稽核證據寫回原請求。另一名負責人確認是否確實受理與是否重複。台帳不得以共享公開試算表任意存放個資。手動流程速度較慢，但在低量試行時能先測試政策與例外，不需要假裝整合已上線。
手動交接也需要清楚的交班規則。取出一筆待處理項目時，應記下處理人與暫時鎖定的時間；如果處理人離職、休假或頁面關閉，由另一名授權者先查是否已在外部建立，而不是直接領取並再送一次。外部平台若只提供人工檢索，應保留查詢條件與截取的受理證據，並建立爭議處理路徑。把人工步驟寫入流程圖，才能公平比較日後改用介面的維護成本。
若可使用已驗證的正式介面，工程師仍要區分「送出請求」、「服務受理」、「收件人接受或選擇」、「出貨」、「完成或退回」。對外傳輸使用服務端密鑰與最小權限，不在瀏覽器或 Linear 描述欄中保存。記錄外部請求識別碼、內部防重鍵、實際回覆與後續狀態；遇到未知回覆先查原結果。不同產品流程對收件人資料、計費與後續事件的要求不同，必須按實際文件及核准方案映射，不可把活動和市集訂單混為一談。
比較選項時用相同的問題：是否支援必要國家與收件人選擇，是否能記錄核准與成本，是否有適當資料處理安排，異常時如何查單與取消，團隊是否負擔得起維運。小規模單一地區可先選手動授權供應商；跨團隊多地區且需要受控收件人選擇時，可評估 Giftpack；現有採購或庫存系統若已通過控制要求，也可能更合適。此處沒有供應商分數或預設排名，採購決策需要實際條款與試行證據。
假設情境一：重送與第二次狀態變更
假設案例。 一個產品團隊在週五將客戶上線專案移到指定里程碑，Linear 傳送第一筆更新。接收端驗證簽章、時間與工作區後建立待審鍵，產品營運確認交付條件，財務核准單筆預算。當接收端第一次未及時回應時，來源可能重試；稍後專案標籤也變更，形成第二筆更新。官方網路掛鉤文件有重試行為的說明，但這裡的客戶和時間安排只是測試情境。
工程師以交付識別碼辨認第一次重送，以業務防重鍵辨認第二種事件對同一里程碑的觸發。兩筆交付都進入稽核紀錄，只有原待審請求可走向核准。若標籤變更不影響資格，附在原請求的證據歷史；若它改變對象或預算，轉交審核人重新評估，不直接覆蓋原核准。測試者重播相同原始訊息，並模擬不同交付識別碼但相同業務鍵的更新。驗收時，來源交付數可以大於一，核准請求及外部贈禮執行數仍各只有一。
替代做法是完全以事件識別碼當唯一鍵。這能擋下同一交付的重送，卻不能阻止另一種事件讓相同里程碑再送一次。另一個替代做法是在核准前禁止重播；它會掩蓋接收故障，讓漏處理事件難以補救。較穩妥的取捨是保留可重播的接收紀錄，在業務層用唯一鍵與狀態轉移擋住重複執行。
若外部提交呼叫逾時，操作人員應看到「結果待查」，利用原請求識別碼核對 Giftpack 或手動台帳的受理證據。沒有證據證明未受理時，不得產生新的請求識別碼盲目重送。驗收資料包應包含來源事件、簽章驗證結果、唯一鍵、審核者與預算、外部受理識別碼，以及重送測試的結果。這能檢查系統設計，不能充作真實客戶成效。
假設情境二：里程碑撤銷與已寄出的邀請
假設案例。 一個合作專案完成初步驗收，營運團隊已審核贈禮邀請；隔天發現產品上線條件未達標，專案狀態被移回進行中。工程師收到新的 Linear 更新，確認它確實改變相關狀態，並把原請求標記為「後續變更待處置」。不能刪掉第一筆事件或原核准，也不能假定把 Linear 狀態倒轉會自動取消已寄出的邀請。
若尚未對外提交，政策負責人可暫停或取消，保留核准與取消理由；財務釋回預留預算。若邀請已送出，營運人員先查服務端是否支援相應的取消或失效流程、收件人是否已選擇、當地是否有其他義務，再由有權者決定。若禮物已履約，應以實際費用、客服處理及適用政策結案，不能在系統上改寫成「從未發生」。收件人的溝通內容須經組織批准，避免把內部專案失誤轉嫁給收件人。
替代做法是讓來源狀態完全主導外部贈禮，凡是回退就自動取消。這在尚未送出時或許可行，但已寄邀請和已履約是不同的不可逆程度。另一種做法是忽略後續變更，則可能留下不合資格的費用。驗收測試應覆蓋三個分支：未提交、已受理未履約、已履約；每個分支均有負責人、外部狀態、財務處置與收件人通知決策。這些都是設計驗收情境，並非已發生的客戶故事。
故障處理與逐筆對帳
把技術重試與業務再決策分開。簽章失敗、時間過舊或來源工作區不符，不能排進贈禮待審隊列。暫時無法讀取 Linear 現況時，保留有效交付並依官方速率限制與回應資訊退避重試；超過預定時限由工程值班人員檢查。待審超時由計畫負責人處理；預算不足由財務決定是否停止或修訂。外部贈禮服務回覆未知時，凍結新提交並查原識別碼，不把網路錯誤誤認為確定失敗。
每日至少按試行節奏對照四份資料：Linear 符合規則的來源事件、內部待審與核准台帳、贈禮端受理及履約紀錄、財務實際費用。找出來源有事件但沒有待審請求、已核准卻沒有受理回覆、外部有兩筆相同業務鍵、履約完成但費用未入帳，或請求已拒絕卻發生寄送。每一個差異有唯一負責人、處置期限和關閉證據。財務對帳不能只比預算總額，也要確認取消、退回、運費及匯率等實際項目；費用定義取決於合約與市場，別杜撰標準金額。
對帳時要注意「尚在等待」與「確實遺漏」的差別。事件剛發生但尚未到審核時限，或已受理但物流尚未更新，可能只是正常的時間差。為每種狀態設定組織自己的預期時限，超過時限才升級；不要把所有未完成狀態都算成錯誤。相反地，已拒絕但仍有外部寄送的差異應立即隔離，因為它可能涉及不適當支出或資訊分享。營運與財務要共同確認關閉證據，而不是單靠一個完成核取方塊。
若差異連續出現，先找根因：來源規則改版沒有同步、業務鍵設計漏掉對象、外部提交結果沒有保存、或核准角色映射錯誤。修正後只重跑受影響的狀態轉移測試，並針對已發生的外部執行另作處置。把原事件從紀錄中刪掉，無法修復實際費用或送達的禮物。這種差異處理紀錄也能幫助下一輪評估是否擴大自動化，而非只看發送速度。
保留操作日誌，但限制其內容。簽章密鑰、完整地址、私人訊息及敏感客戶資料不應出現在一般日誌。以識別碼連到受權系統；需要調查時按權限查閱。設定適當保存和刪除規則，並記錄政策版本。可以延伸閱讀 企業送禮自動化指南的控制鏈，以及 整合架構指南的系統責任分工；本文的差異在於 Linear 專案事件和重送情境。
試行檢查表與上線門檻
試行前，產品營運簽核里程碑定義和收禮對象，財務核定預算及帳務科目，隱私與法務負責人確認資料流，工程團隊建立網路掛鉤、簽章驗證、防重鍵與追蹤紀錄，營運人員確認實際交接方式。若選用應用程式介面（API），先取得對應權限並在核准環境驗證端點與狀態；若先用手動交接，明確指定雙人查重及回填責任。不要因為文件提到某種介面，就假設組織已取得使用權。
逐項重播與驗收檢查
先送一筆有效來源事件，再送相同交付的重送，接著送不同交付但相同里程碑的更新。檢查只有一個業務請求。測試錯誤簽章、過期時間與錯誤工作區都不會建立待審項目。以尚未核准、已核准未提交、提交結果未知、已受理與已履約五個階段分別模擬撤銷。每次測試核對原識別碼、責任人、預算處置與外部證據；任何未知結果都不得自動改用新識別碼重送。最後讓非開發者從來源事件追到核准、寄送與費用，並從一筆費用反向找到來源。
上線門檻是可證明「不重複、不越權、可取消、可對帳」。測試期間出現雙重贈禮、未經批准寄送、密鑰外洩、收件人資料混入一般日誌，或外部結果未知仍自動重送，都應停止擴大試行，修正原因並重新驗證受影響路徑。每個例外保留責任人與處理期限。上線後按週檢視命中規則的事件、核准率、拒絕與撤銷、重送、外部未知結果與帳務差異；這些指標是營運監控，不是宣稱送禮會提高某種商業成果。
試行的負責人應在每週檢討時抽一筆順利結案與一筆例外，要求非開發團隊成員沿著識別碼還原完整經過。若只能由寫程式的人在資料庫裡拼湊，操作流程仍不夠成熟。核准人應能看懂來源與預算；客服應能把收件人的問題轉到有權處理的人；財務應能將費用連回核准。當這三者都能在其權限內完成查證，才適合擴大團隊與里程碑類型。
擴大前也要重新評估事件量與排隊容量。增加專案數可能讓來源讀取碰到限制，增加市場會讓地址取得、履約時間與費用項目更複雜。不要把單一地區的測試結論直接套到所有市場。每新增一種受領對象或贈禮計畫，就重新檢查防重鍵、核准角色和保存期限；只改一個觸發條件而不更新相關控制，最容易讓表面上正常的自動化留下無法對帳的例外。
結論：先讓決策可追，再擴大自動化
試行結束時，未結例外要有可移交的狀態，而不是只寫「稍後處理」。每筆例外記下內外部識別碼、最後確認的狀態、證據、下一次查詢時間與接手人。外部結果未知時禁止改用新編號提交的限制，也應明確交給輪班同事。這份交班能說明技術事件已修復，卻可能仍有費用或收件人問題待結案。處理權限轉移後，原始紀錄與核准歷史都要保留，讓新負責人不必依賴前任同事的記憶。
人工審核在低量試行時需要時間，但它讓資格和資料分享仍可在寄送前修正。若組織準備自動化下一段流程，應先量測待審時間、人工查重成本、例外率和結果不明的處理時間，並確認政策規則已有穩定版本。節省點擊次數不足以證明值得取消審核；相反，若某一步的判斷條件清楚且紀錄完整，自動化可以降低重複作業。逐步擴大時，每個新增國家、收件人類型和贈禮計畫都重新檢查責任、費用與資料邊界。
Linear 適合提供專案變更訊號；是否贈禮、贈送對象、可用預算、收件人資料與撤銷方式，應由組織的政策和有權人員決定。把網路掛鉤交付、業務防重、審核、對外提交及帳務對照分層，團隊才能在重送和狀態回退時說清楚發生了什麼。先用一種里程碑完成可重播的試行，再考慮更多團隊和國家。
若組織已核准計畫並驗證服務範圍，Giftpack可作為收件人選擇及跨地區履約的評估選項；企業仍自行負責資格、預算、隱私、稅務與僱主政策。