issue #125 補發取號收斂到 NumberingService 決策鏈

這頁保留補發取號的技術決策鏈。它解釋為什麼不能在申請單流程裡手刻補發號碼,並補上 #45 取號規則背後的實作風險。

最終結論

補發取號要走 NumberingService / CertificateReissueNumberingManager,不能各路徑自行 原號-N 或拆字串產號。原因有兩個:

  1. 手刻取號沒有 row lock,容易 race 重號。
  2. 禮儀原號本身可能含 -,用 Split('-') 會把根原號剝錯。

決策鏈

來源內容
#45補發號碼規則拍板:禮儀依有/無憑證分流,塔/蓮遺失補發取新號。
#125指出舊 GenerateNewAuthNoAsync 繞過 NumberingService,有 race 重號與根原號解析錯誤。
#125 後續補發取號收斂到 NumberingService.GenerateReissueAuthNoAsyncCertificateReissueNumberingManager
#238完成端整族收斂時補上交易一致性,避免 submit / complete 兩條路徑不一致。

現行 code 錨點

目的錨點
補發取號總入口CertificateReissueNumberingManager.ApplyReissueNumbersAsync
禮儀補發號碼產生NumberingService.GenerateReissueAuthNoAsync
根原號解析ReissueAuthNoFormatter.ComputeRoot
補發號格式化ReissueAuthNoFormatter.Build
完成端呼叫ApplicationActionService.CompleteAsync
submit 自動完成呼叫ApplicationCreateService.FinalizeApplicationAsync

驗證錨點

驗證結論
Verify-Issue45-ReissueNumbering.cs覆蓋禮儀有/無憑證分流與塔/蓮取新號。
#125 close 記錄補發取號已從手刻邏輯收斂到共用服務,並處理 root parsing 問題。

注意事項

  • #45 是業務規則,#125 是實作風險;兩頁要一起看。
  • 只看到 UI 有 voucherStatus 不代表取號正確,仍要確認完成端是否委派共用取號服務。
  • 任何新增補發流程都要先找 CertificateReissueNumberingManager,不要另寫取號 helper。