規則變更佇列
這頁是 PM / SA 大包更新的 intake queue，不是業務規則權威頁。
用途：
- 把一次大包拆成可處理的規則條目。
- 每條標記目標權威頁、狀態、衝突與待驗事項。
- 條目處理完後促升到 concept；查規則仍從 規則權威去哪查 進 concept，不從這頁查。
⚠️ 新批次進來時的操作方式（append-only，仿
log.md）： 這頁設計成可以裝多個PM/SA 大包，不是只服務404014a6這一包。 下面每個## YYYY-MM-DD commit <hash>：<標題>是一個獨立批次區塊，各自有自己的 條目拆解表、狀態小結、關閉日期。新批次進來時，在檔案最後面新增一個新的## YYYY-MM-DD commit <hash>：...區塊，不要覆蓋、刪除、或改寫既有區塊—— 既有區塊即使全部closed也要留著，是「這包 PM 更新怎麼被消化」的稽核紀錄。 若日後批次多到這個檔案太長，才拆成sources/intake/<commit>.md個別檔案 +sources/intake/index.md索引，屆時把既有內容原封搬過去，不要用內容摘要取代原文。 每加一批新區塊，記得同步檢查 frontmatter 的updated與tags（例如目前的closed-archive只反映「所有既有批次都已關閉」，一旦新批次還在triage/conflict/pending-code，這個 tag 要拿掉或改成只標在對應批次區塊上）。
狀態定義
| 狀態 | 意義 |
|---|---|
triage | 已收進佇列，尚未對 code/wiki 驗證 |
covered | 既有 concept/code 已覆蓋，只需補來源或不處理 |
promote | 規則穩定，應併入目標 concept |
pending-code | 文件新增規則，但現行 code/schema/UI 未確認或疑似未實作 |
conflict | 和既有規則、issue、code 或同包文字互相矛盾 |
obsolete | 後續 PM/issue 已推翻，不促升 |
closed | 已促升或決定不處理，佇列留追溯 |
2026-07-05 commit 404014a6：管理費規則與業務邏輯說明
來源 commit：404014a6 feat(docs): 更新管理費規則與業務邏輯說明
這包主要新增 管理費規則彙整.md，並同步修改申請單、綜合查詢、權狀申購、持有人預填、通報、訂位與附錄。處理原則：先驗證現行 code/wiki，穩定規則再促升；衝突條目不得直接寫入 concept 當權威。
狀態：
closed（archive）——18 條全數完成分診，佇列本身的工作結束，留存供日後對照「這包 PM 更新怎麼被消化」。 關閉日期：2026-07-05 促升頁面：管理費定價與申請單帶入（01/02/03/04/06/07/11/12）、遷出流程（05/08）、晉塔流程（08/15/16）、異動完成後去哪裡查（17）、issue-0180-0273-0188-0193-0176-RBAC角色範圍決策（13）、管理費催繳通知（10，新建頁）——逐條促升細節見下表 未促升原因：3 條文件內部矛盾或與現行 code 行為不符（04/06/09），已開 PM 釋疑 issue；1 條確認為明確 code bug（14），已開工程 issue；1 條混合狀態（08，遷出端已併入 wiki、晉塔/安奉端缺口另開 issue）；2 條規則本身未定義完整、PM 未定案前工程無從排起（02/07）；1 條規則清楚但屬較大範圍功能缺口，先留紀錄待排工程（03）；1 條文件本身標待確認、待 PM 裁決分類（18）——逐條理由見下表⚠️ 「closed」＝這份佇列的分診工作結束，不等於業務問題本身已解決。04/06/08/09/14 這五條的後續追蹤已轉移到對應 GitHub issue（見下表連結），02/03/07/18 則是決定不開票、結論保留在本頁與對應 concept 頁——要看某條後續進度，照下表連結去對應 issue 或 concept 頁查，不要以為「closed」代表 PM 已經拍板。
條目拆解
| ID | 條目 | 目標權威頁 | 狀態 | 待處理 |
|---|---|---|---|---|
| PM-404014a6-01 | 合約別判定基準：民國 114/7/1 含以前為舊合約，之後為新合約一次性管理費 | 管理費定價與申請單帶入 | closed | 既有 wiki/code 已涵蓋：IsNewContract 邊界為嚴格 >（常數 ContractTypeCutoffDate=2025-07-01），西元/民國轉換一致；既有頁已涵蓋，無新增內容 |
| PM-404014a6-02 | 新合約一次性管理費：不分期、每位置收一次、納骨量上限、超出收規費 | 管理費定價與申請單帶入 | closed | 未促升，決定不開 issue：每位置一次/納骨量上限已物化（f_limit=-1），已促升進目標頁；「超出收規費」無對應欄位/邏輯，只在文件提及。2026-07-05 第二輪深挖確認：規費金額/物化時機/分期或一次性/退費規則文件都沒寫，PM 未定義前工程無從排起，結論留在目標頁「限制/落差」，之後 PM 補定義後再視情況開票 |
| PM-404014a6-03 | 舊合約分期管理費：20/40/50/永久、最多 3 期、到期日與永久轉換 | 管理費定價與申請單帶入 | closed | 未促升，決定不開 issue：定價欄位（FManagementFeePerPeriod 等）已在 specs 落地，已促升進目標頁；「40 年拆 20/20」「50 年滿 100 年轉永久」拆期/轉換邏輯未找到對應 code。2026-07-05 第二輪深挖確認：規則本身在 SA BR-2.11-02 寫得清楚，是 code 完全未實裝（前端 ApplicationsMgmtFeePanel.vue 分期邏輯不分年限值、無累計轉永久檢查），屬於真的功能缺口；結論記錄於目標頁，待排入工程計畫時再視情況開票 |
| PM-404014a6-04 | 短期管理費：從第 1 期或最後不可退期起算，半年一期，費率依權狀類型/樓層 | 管理費定價與申請單帶入 | closed | 已開 issue，追蹤轉移：現行 ShortTermFeePricingManager 費率完全來自 spec 欄位，無硬編碼；衝突僅存在文件本身兩套費率表（1000/1200/VIP 與 1000/1500/2000），已促升現況進目標頁，衝突留待 PM 裁決。後續進度見 issue #288（PM 釋疑，非工程 bug） |
| PM-404014a6-05 | 退費規則：非第一期、未使用、使用期間低於年限一半、短期管理費扣抵 | 管理費定價與申請單帶入 / 遷出流程 | closed | 已促升：半年限退費計算已由 ManagementFeeRefundManager 落地，對照 issue-0232-遷出退費半年限與短期扣抵 一致；已併入 遷出流程。短期扣抵仍是獨立子項，未逐一端到端驗證，留待後續 |
| PM-404014a6-06 | 一次性管理費不可退，但退貨作廢時一次性管理費亦退還 | 管理費定價與申請單帶入 | closed | 已開 issue，追蹤轉移：現行 code 一次性費一律不可退（f_limit=-1 → CheckIntrinsicRefundableAsync 回 false）；退貨作廢例外目前無對應邏輯，已促升現況進目標頁，例外邏輯留待 PM 裁決。後續進度見 issue #289（PM 釋疑，非工程 bug） |
| PM-404014a6-07 | 換位/換裝前需先退好管理費；換裝另需區分 1 換 2 / 2 換 1 | 申請單異動從建立到完成怎麼運作 | closed | 未促升，決定不開 issue：前置退費卡控（ModificationValidationManager.HasRefundableManagementFeeAsync）已實作，對照 issue-0264-0244-換裝管理費跟號與前置退費 一致，已促升進 管理費定價與申請單帶入；1 換 2 / 2 換 1 拆分邏輯未找到對應 code。2026-07-05 第二輪深挖確認：工程框架已就緒（SpecChangeApplicationManager 已支援張數 2↔1，#205 Task 5），缺的是費用規則本身未定義（新舊位置管理費怎麼分攤/補差價），PM 補定義後再視情況開票 |
| PM-404014a6-08 | 晉塔/安奉需檢查已繳管理費；遷出需已晉塔/已安奉且管理費已繳清或已退費 | 晉塔流程 / 遷出流程 | closed | 混合：遷出端已促升、晉塔/安奉端已開 issue：遷出前置 guard 已確認落地並補進 遷出流程：MoveoutApplicationManager.MaterializeMoveoutAsync 用 ProductUseStatusHelper.ComputeEffectiveStages() 綜合判定各期是否逾期。晉塔/安奉端確認缺口：ModificationValidationManager.ValidateProductStatusAsync 的 Enshrine 分支完全沒有管理費檢查，未寫入 晉塔流程 當權威（避免寫入不存在的檢查）。後續進度見 issue #296（PM 需先定義「已繳清」判斷標準） |
| PM-404014a6-09 | 轉讓時管理費隨受讓人移轉 | 申請單異動從建立到完成怎麼運作 | closed | 已開 issue，追蹤轉移，暫不寫入權威頁：現行轉讓完成端 ApplyTransferCompletionAsync 只搬移持有人資料（FCustFid/FUseName/FTranDate），management_fees.FTUseFid（綁安奉人）未隨轉讓移動，與文件「管理費隨受讓人移轉」矛盾，PM 裁決前不寫入 concept 權威頁。後續進度見 issue #290（PM 釋疑，非工程 bug） |
| PM-404014a6-10 | 催繳規則：依到期日區間與產品類型篩選、去重、匯出、截止日 12/31 | 管理費催繳通知 | closed | 已促升，新建頁：已完整實作（MaintenanceFeeNoticeQueryService + pages/query/maintenance-fee-notice.vue + SA 5.3.8_管理費催繳通知地址.md），無 code 缺口。已促升為新頁 管理費催繳通知，並登錄進 index／規則權威去哪查 |
| PM-404014a6-11 | 發票/收據規則：塔位、蓮位、禮儀的發票/收據分流；一次性管理費收據 | 管理費定價與申請單帶入 | closed | 已促升：已驗證：ItemVoucherManager 依 tb_modification_fee.f_invoice_type 全域分流（非 per-product），禮儀無一次性管理費機制；與 issue-0234-整單作廢與發票狀態解耦 正交無衝突。已併入 管理費定價與申請單帶入 |
| PM-404014a6-12 | 權狀申購一次性管理費：現況使用者先自行輸入，行政可改 | 管理費定價與申請單帶入 | closed | 既有 wiki/code 已涵蓋：已驗證與現行 CertificatePurchaseEditor.vue 一致（使用者輸入、行政透過 PURCHASE_SUBMITTED_ACCOUNTING 可改、非自動帶入）；既有頁已涵蓋，無新增內容 |
| PM-404014a6-13 | 持有人預填可見範圍：經銷商只能看本人建立；行政人員與管理員可看全部 | issue-0180-0273-0188-0193-0176-RBAC角色範圍決策 | closed | 已促升：已驗證與 273 一致：PurchasePrefillService.QueryPurchasePrefillsAsync + migration 169（f_resource_constraint='own_created'）。已補進 issue-0180 頁 |
| PM-404014a6-14 | 訂位：公司位、法會位、鎖定位不自動釋放 | 訂位流程 concept 待補 | closed | 已開 issue，追蹤轉移：⚠️ 發現真實缺口：ReservationExpiryReleaseService.IsGuardedPosition() 已排除公司位（FExchange）/法會位（FCereRsv），但未檢查鎖定位（FLock=='Y'），鎖定位到期後可能被誤自動釋放。這是明確 code bug，訂位流程 concept 待補頁時再一併促升。後續進度見 issue #287 |
| PM-404014a6-15 | 通報新增「當前位置(主位/暫厝)」欄位，完成通報依類型寫入 | 晉塔流程 / 異動完成後去哪裡查 | closed | 已促升：已完全實裝（非文件期望）：EnshrinementNotificationService.FinalizeEnshrinementAsync 依通報類型寫 enshrinements.f_type4。已併入兩個目標頁 |
| PM-404014a6-16 | 通報防呆 key 改為「位置＋使用者(使用編號)」，夫妻/家族位不可只用位置判斷 | 晉塔流程 | closed | 已促升：已完全實裝：NotificationItemMatrix.IsAllowed(ens.FType4, dto.NotifType) 讀 per-使用人 f_type4，前後端同一套矩陣。已併入 晉塔流程 |
| PM-404014a6-17 | 綜合查詢新增 currentLocation 顯示主位/暫厝，與使用狀態獨立 | 異動完成後去哪裡查 | closed | 已促升：已完全實裝：ComprehensiveQueryResultDto.CurrentPosition 讀 f_type4，與 IsEnshrined 讀不同欄位、互相獨立。已併入 異動完成後去哪裡查 |
| PM-404014a6-18 | 無塔位暫厝月費/押金是否算管理費仍待確認 | 暫厝流程 concept 待補 | closed | 未促升，決定不開 issue：已找到現行欄位：月費常數 TempStorageMonthlyFee=1000、押金 FGuarantee（預設 50000，可由 tb_system_config 覆寫），兩者皆為 tb_notowerused 獨立欄位，未歸入 management_fees。文件本身標待確認，仍待 PM 裁決分類，結論記錄於此，暫不促升為正式規則、也不開票 |
優先處理順序（2026-07-05 第一輪驗證已完成，見下方彙整）
- 先處理
conflict：PM-404014a6-04、PM-404014a6-06。 - 再驗高風險
pending-code：PM-404014a6-15、16、17。 - 管理費主線條目 PM-404014a6-01～08 驗完後，合併更新 管理費定價與申請單帶入，不要新開多篇管理費權威頁。
- 零散 RBAC/訂位/暫厝條目先留在佇列，等對應 concept 補齊或 issue 需要時再促升。
2026-07-05 第一輪驗證彙整
以 8 組 sonnet subagent 對照現行 mono-repo code 逐條驗證，結果：
closed（9 條）：01、05、10、11、12、13、15、16、17——已驗證穩定、對應內容已併入目標權威頁（或如 PM-10 新增 管理費催繳通知 頁）。conflict（3 條，維持不促升）：04、06、09——皆非「code 沒做」，而是文件本身矛盾或文件敘述與現行 code 實際行為不符，需 PM 裁決後才能定案，裁決前不得寫入 concept 當權威。pending-code（5 條，維持不促升）：02、03、07、08、14——找到部分已實作、部分待補的具體缺口，已逐條記錄在對應目標頁的「限制/落差」或本表「待處理」欄。triage（1 條，維持原狀）：18——文件本身標待確認，PM 未裁決分類前不促升。
⚠️ 本輪意外發現一個真實 code 缺口（非文件問題），已開 issue #287：
PM-404014a6-14 驗證時發現 ReservationExpiryReleaseService.IsGuardedPosition() 漏檢查「鎖定位」（FLock=='Y'），
只排除了公司位與法會位。這代表鎖定位的訂位到期後可能被自動釋放程式誤釋放。
2026-07-05 第二輪：conflict/pending-code 是否開 issue
對 conflict（04、06、09）與 pending-code（02、03、07、08）做第二輪更徹底的驗證，逐條判斷是否夠格開票：
- 04、06、09：確認是文件矛盾或文件與現行行為不符，開了「PM 釋疑」issue： #288（04）、 #289（06）、 #290（09）。
- 02、07：深挖後判定「規則本身未定義（金額/時機/收費規則），PM 未定案前工程無從排起」，決定不公開開票，結論保留在對應目標頁與本表。
- 03：深挖後判定規則清楚（SA BR-2.11-02）、code 完全未實作，屬於真的功能缺口；決定不公開開票（詳見待處理欄），待排入工程計畫時再視情況處理。
- 08：確認遷出端已落地、晉塔/安奉端有缺口，PM 需先定義判斷標準，開了 issue #296。
⚠️ 過程說明：曾一次把 02/07/03（拆兩張）都自動開成公開 issue（#292–#295）， 事後判斷這超出使用者原本要求的「深挖後再決定」（決定應該由使用者拍板，不是自動執行）， 已全部關閉並改成只記錄在 wiki。之後若要正式排工程或送 PM 裁決，再另外評估要不要開票。
不直接促升的原因
- 這包是文件更新，不等於現行 code 已完成。
- 同包已有明顯衝突文字。
currentLocation類條目可能改 DB/schema/API/UI，不是 wiki prose 可直接吸收。- 管理費規則已經有既有 issue/source/wiki 脈絡，必須避免新文件覆蓋已驗證結論。