FR-155 LOG

• commits bd122bb10、59085c4b4、74102a669。D1–D10 照建議拍板；D10 改判流程編輯器併入第一版。
• 教訓：design 寫「my_capabilities 已套 D5 回退」但 T-3.4 實作成精確版，到 T-4.2 才發現；設計時應把「哪個 API 回哪一層」寫成表。

• BE ws-CM-2977 14 commits；FE 8 commits；套件 5 commits。全部 驗收通過待確認。
• CM-2987 等決策者裁範圍被工作坊重派空轉 8 輪；教訓：卡上「等裁示」要同時把狀態留在 修正待驗證 並在母卡標「暫停派工」，或決策者先裁再開第 4 批。
• CM-2988 第一輪把 main_role 驗證掛在專案實例存檔，造成既有專案流程設定存檔 400；第二輪改成舊四值換算後再驗、設計器存檔才嚴擋。
• T-1.2 待裁 17 項，T-3.x 已依建議做掉 7、8、11、12、13、14；未裁的見 STATE §2。
• D5「控制項層單獨降級」實際不存在：四張子層參與者表 0 列、寫入 API 已退役；T-4.2 改成刪掉前端永遠不成立的判斷。

• 核對：11 張卡號 grep 三 repo commit 全對上；DEV DB 狀態實查（15 能力點、兩租戶四角色、19 列回填、六站能力點名）；ws-CM-2977 未合回。
• 寫 STATE／LOG 雙檔（本 arc 首次）。

• 決策者 11 項全照建議裁（STATE §2）。R3 曾被誤讀為「改成能力點」，實際是「下拉列幾個」，口頭澄清後裁只列三個。
• 收口五張 CM-3010～3014（第 5 批三張、第 6 批兩張）；合回排第一張（T-5.0），因 BE 裁示落地要在合回後的 feature/FR-139 做。
• 教訓：等裁示的卡要在母卡標「暫停派工」，寫進收口卡共同紀律。

• 工作坊跑完 CM-3010～3014，全部驗收通過待確認，但 CM-3011～3014 的後端成果疊在 ws-CM-2977 上沒再合回（CM-3010 只合了前 11 張）。決策者授權首腦接手。
• 合回 74bb09f76：9 支衝突。守門取決策者裁 R7；manifest 兩邊全留；七支產物檔先取 FR-155 側再重產。重產 f90e601d2。
• 抓到 99-stamp 會誤蓋 FR-156 三支（基線庫未套）——手動拿掉，記 STATE §4。
• 教訓①：gen_stamp_sql.sh 抄 manifest 不查庫，merge 後重產前要先核對基線庫。教訓②：工作坊「合回」卡做完後若同 ws 上再疊卡，最後要再合一次，母卡應加一張「最終合回」卡或由首腦收。教訓③：先 push 再查 merge 狀態是錯序，這次 push 時收口後端其實還沒合回。

• 決策者授權 push 與發版。先發四套件 1.7.0／1.4.0／1.4.0／1.3.0、BE pin 切回 Nexus（536752fa3）、三 repo push。
• 決策者指出：T-6.2 審查報告的重要級應先修再發版。I1～I6 全修（BE 2fa3f9467、jedi-iam 1.7.1 e104a8b3、FE 1b4c08fb），jedi-iam 再發 1.7.1，三 repo 再 push。I7、I8 裁不修。
• 教訓：審查報告列「請首腦判」的重要級，首腦應在發版前就給建議並修完，不是發完再列給決策者。順序是「審查 → 修 → 發版 → push」。