FR-089 交接日誌（LOG，append-only）

每棒追加一 block，既有 block 不改。發現舊 block 有誤 → 在新 block「推翻了什麼」欄更正。

---

本棒範圍：從「jedi-asset plugin.py 很亂」一句話起頭，長成三段 arc（FR-089／090／091）並派出第一波。

commits（主專案）：ceb455df FR-089/090 母卡登記＋資料夾、c4129183 plugin-anatomy 說明頁進站、7fad430c FR-091 登記。其餘 commit 由各 runner 產出，見 Notion 各卡回寫。

派出／收回：

• 收 Done：CM-1676（jedi-asset 整理 A～F）、1677（收尾修正＋ctx→runtime）、1678（RLS＋enum 小寫）、1683（空殼清理）、1684（port 歸位 infra/）、1686（iam 收斂＋開 identity port）、1687（補暱稱走 D8）。
• 派出在跑：CM-1689（接線收 core/plugins/）、1691～1695（FR-091 第一批五支）。
• 已開待派：CM-1696（DI 瘦身，排 18 支後）。

決策（全部決策者 2026-09-12 裁）：見 STATE §2 表。關鍵三條——全部統一、adapter 與填表同檔放 core/plugins/（改判 1684）、DI 瘦身排最後。

推翻了什麼：

• 首腦開 1686 時寫「root admin 守門搬 infra/iam/、role_app_service 整支刪」→ runner 實查 route 已在套件用註冊名取服務、update_role 差集要在 @transaction 內，改判 A 案留原地瘦身。首腦的錯，runner 對。
• 首腦開 1677 時寫「用 system_status 篩選守 override」→ runner 突變發現永遠綠（base 對 SAEnum 本就等號比對），改用 String 欄位守。首腦的錯。
• 首腦開 1687 時寫「七處補暱稱」→ 實為三套並存（helper 15 consumer／三支手寫複本／flow_engine），正解改 helper 內部；且 project_service:502 是第四份複本卡上沒列。
• 首腦開 1684 時判「adapter 放 infra/」→ 決策者裁「一檔看完」後改判放 core/plugins/（1689）。
• 首腦第一次盤 FR-080 時誤讀母卡為 Done → FR-080 首腦澄清仍在收口，收口範圍重切（發版等四項移入 89）。

教訓：

• 開卡的「怎麼修」若涉及 runtime 行為（守衛、突變），首腦先跑一次再寫進卡，否則 runner 會抓到假守衛。
• 驗守門類功能前先查「誰受保護」的定義，別憑帳號名猜（首腦誤停 blsadmin 一次，已復原）。
• 說明文件要照 doc-site-build 模式進站，不要在套件目錄手寫 HTML（做了一次又重做一次）。
• 中繼交接該在派出六張之前做，不是之後——本棒 context 已吃緊。

下一棒：STATE §3。

---

收回：CM-1692 jedi-notification Done（247 passed、守衛突變紅、harness smoke 含真 SMTP sink、主專案 6 import＋boundaries 90 passed，均以 PYTHONPATH 指工作樹跑）。

教訓（runner 抓到）：主專案 venv 裡 jedi-notification 是 Nexus wheel 0.0.11，pyproject.toml:199 path override 是註解掉的。在主專案跑的驗證若不強制 PYTHONPATH，驗的是舊 wheel，假綠。這條會影響第一批其餘四支與之後所有批次；已寫進 STATE §4 並 append 到四張在跑的卡。首腦驗收 SOP 加一步：先印 jedi_<pkg>.__file__。

runner 加分：發現 SMTP adapter 寄不出去時端點仍回 200（只有 data=false），把 harness smoke 改成起假 SMTP sink 斷言真的收到信。這是「壞了會靜默」的典型，值得其他有寄信的套件照抄。

---

收回：CM-1691 ai-bot、1692 notification、1693 integrity、1694 remote-agent、1695 ai-dashboard 全 Done。各支 pytest 綠（ai-bot 36／notification 247／integrity 105／remote-agent 110／ai-dashboard 62）、版面守衛突變全紅、主專案 import 全 OK、boundaries 90 passed（PYTHONPATH 指五支工作樹）。

教訓：

• 主專案 venv 有兩層假綠陷阱：Nexus wheel 遮工作樹（1692 抓到）＋ jedi-asset tests/ 被裝成頂層套件遮其他套件的 tests.xxx（首腦驗收抓到）。後者整理前就有。兩條都寫進 STATE §4，第二批卡的手測段固定帶。
• 三支 harness 沒 --smoke，只能 app.run() 綁 port，並行驗收時互撞。標準形狀該把 --smoke（test client）列為必備，SOP §6.1 要補。
• 並行 runner 用寬鬆 git add 會把別人的檔夾帶進自己的 commit（1692 的 87f3a86 夾了 1693 的 14 檔）。內容沒壞，但 git log 對不上卡。卡上「顯式 git add」要改成「只 add 自己套件目錄下的檔」。
• runner 1694 自己在 B 組留了 module-level 建路由表的 import 順序地雷、E 組自己抓到修掉，且發現一版「子行程 import」的守衛抓不到突變而換法。這種自我糾錯值得記。

推翻了什麼：無。

下一棒：等 1689；然後第二批。

---

收回：CM-1689 Done。core/plugins/ 11 檔、app_factory 695→450 行改迴圈、兩支守衛突變紅、boundaries 90 passed、BE 重啟零 Traceback、11 支插件各打一條真實端點全部掛載且守門生效。SOP §5 與 plugin-anatomy 改三步版並重 build。

runner 改判首腦設計：Plugin(build, register)+raw → 每檔 mount(app, container, host) 單一契約＋HostContext。理由：一半插件簽名對不上，逃生口若一半人要走主路徑就是錯的。首腦認同。

推翻了什麼：首腦 ea34a17e docs commit 吞了 1689 runner staged 的 22 檔（③④⑤ 三組），git log 對不上卡；1692 同型吞了 1693 的 14 檔。根因是裸 git commit 提交整個 index。已寫進 STATE §4／§7。

教訓：

• 共用工作樹 + 並行 runner ⇒ git commit -- <路徑> 是硬規則，寫進下批卡與首腦 SOP。
• runner 用 grep build_* 找接線入口漏了被 route 直接 import 的函式，起 BE 才炸 ModuleNotFoundError；改 AST 掃全部 import 才抓齊。搬模組類的卡要寫「用 AST 掃 import，不用 grep 符號名」。
• 首腦驗收打端點要先從 FE api.js 或套件 routing 抓真實 URL，猜 URL 浪費三輪。

本棒 context 已滿，建議下一棒換 session 冷接。

---

本棒範圍：冷接 → 開 FR-091 第二批五張（CM-1697～1701）→ 給三張並行 prompt → 驗收 1697／1698／1699 收 Done → 開收尾卡 CM-1702 → 給 1700 與 1702 的 prompt，兩張派出。

commits（主專案）：bb463736 第二批開卡、README 第一批標 Done；之後三個 docs commit（前三張驗收 Done、開 1702、1700／1702 派出中）。套件側 commit 由 runner 產出（bulletin 6、file-upload 6、system-core 7），見各卡回寫。

派出／收回：

• 收 Done：CM-1697 bulletin、1698 file-upload、1699 system-core（首腦自跑：三支 pytest 159／173／225 全綠且 integration 真起容器、版面守衛突變紅、harness --smoke 過、boundaries 過、AST 掃 53 條 import 全通、BE 帶三支工作樹重啟零 Traceback、真實端點 401／200／暱稱）。
• 派出在跑：CM-1700（evidence-classification，含主專案側 G 組收進 core/plugins/）、CM-1702（收尾小卡）。
• 已開待派：CM-1701（license-runtime，等 1700 收回，同動 BE 兩檔）。

決策（首腦裁，無決策者新裁示）：

• 1700／1701 加 G 組把主專案接線順手收進 core/plugins/（STATE §4 早已預告，不另開卡）。
• 1702 三件併一張：asset／bulletin PKG_ROOT、主專案 file-upload URL 守衛改讀 FROZEN_URLS、第一批三支 harness --smoke。
• 兩個行為面既有缺陷（file-upload set_save_dir／delete_file 死分支、system-core get_system_menu_by_id 從來不能用）記母卡待決策者裁，本批不修。

推翻了什麼：

• 首腦開 1697 寫「既有 77 支、41 處註解」→ 實為 97 支、74 處（不影響做法）。開 1699 寫「config／menu 兩套內部寫法要統一」→ runner 實查兩半本就同套，真正差的是 route 命名／取 body／logger 三項。首腦盤點時只掃數字沒讀檔，數字型斷言照舊不準。
• 1697 runner 推翻卡上「entity 改 dataclass 照標準寫法」：查詢 entity 要容忍 FE 多送六個欄位，硬改 dataclass 會讓公告列表 500，保留容忍並加測試釘住。

教訓：

• 範例套件自己有缺陷，抄一支傳一支：jedi-asset 的 PKG_ROOT = Path(plugin.__file__).parent 在拆檔後失效，bulletin 照抄也中，1699 runner 用突變才抓到。開卡「照範例做」之前，範例本身要先被突變驗過一次。
• 驗收打端點前先看 route 方法：三條列表都是 POST 帶 RequestMetaSchema，GET 打回 405 差點誤判。
• 三張卡的驗收批次跑（pytest／突變／smoke／import 一次全部）比第 1 棒逐張快很多。
• 給 file-upload 這種 venv 是 wheel 的套件，prompt 裡把「帶與不帶 PYTHONPATH 各印一次 file 貼進回寫」寫死，runner 就真的貼了，驗收不用再猜。

下一棒：STATE §3。本棒 context 尚可，繼續驗 1700／1702。

---

收回：CM-1701 license-runtime、1712 issue、1713 log、1714 flow-engine、1716 survey 全 Done。1701／1716 含主專案 G 組（license 接線收進 core/plugins/license.py；survey 接線改走 D8 identity、IAuditNicknameEnricher 退役、順收 evidence-classification 三處死引用）。

開卡：第三批 CM-1712～1716（1703～1711 非本 arc）。改判 STATE §2 兩條：log 已有 IUserNameResolver port 不另開 identity；survey repo JOIN 早在 CM-1512 拔了，做的是三條補名路徑收成 D8 一條。flow-engine 與 compliance-audit 主專案接線共用 api/flow_control/__init__.py，收斂全交 1715 G 組。

推翻了什麼：

• 首腦開卡的數字型描述（測試支數、註解處數、login 級端點數、import 檔數）五張卡全被 runner 實查改掉，無一準確。開卡數字一律標「估計」，做法不受影響。
• 1716 卡上寫「既有 320 支全綠」→ 實況 48 紅 42 錯，一行沒改就紅。首腦沒跑 baseline 就寫。驗收時用 worktree 退到開工前 commit 實跑對照，失敗集合逐字相同才收。
• 首腦驗收打 /survey-folders 送 pager 回 500，差點當回歸；baseline 一樣炸，FE 只送 {is_delete:0}。打端點前看 FE 送什麼，不憑 RequestMetaSchema 慣例猜。

教訓：

• 開卡前要先跑一次該套件的 pytest 當 baseline 寫進卡，runner 才有對照；沒 baseline 的紅燈驗收成本高。
• 1713 runner 對 logger 九種取法分「刻意／隨手」並各自加守衛，這種「先分類再改」比一律改名穩，第三批以後 logger 多的套件開卡照這樣寫。
• 1714 多出 plugin/wiring.py 第六檔、1713 forwarding/plugin.py 不拆——標準形狀允許有理由的偏離，判準是「反悔條件有沒有寫進 README」。

下一棒：派 1715；再開三張大卡。

---

本棒範圍：冷接 → 第二批五張開卡與驗收 → 收尾卡 1702 → 第三批五張開卡、四張驗收 → 三張大卡開卡 → 派出 1715、1725 → 交接。FR-091 從 5 Done 推到 14 Done。

commits（主專案）：全是 docs——bb463736 第二批開卡、2efa62ae 1702 驗收、01256f86 1701 驗收、932123d7／本棒最後一個 STATE/LOG 補記，以及第三批開卡、四張驗收、大卡開卡各一個。套件側 commit 全由 runner 產出（見各卡回寫）。

派出／收回：收 Done 11 張（1697～1702、1712～1714、1716、加 1700／1701 的 G 組）；在跑 1715、1725；已開待派 1726、1727。

決策（首腦裁，決策者未另裁）：

• 1700／1701／1715／1716／1726／1727 加 G 組把不在 CM-1689 11 支內的主專案接線順手收進 core/plugins/，不另開卡。
• log 不另開 identity（已有 IUserNameResolver）；survey 三條補名路徑收成 D8；task-platform 多子插件照 jedi-log 判例各自 plugin/、runner 先定形等令。
• 行為面既有缺陷一律記母卡待決策者裁，本 arc 不修（累計：file-upload set_save_dir／delete_file、system-core get_system_menu_by_id、jedi-iam get_tenant_by_uid 500、survey 資料夾暱稱 null、issue member 查無不一致；疑死碼 survey auth_required 零消費端、task_survey_ref_items 鏈；測試債 survey 48 紅 42 錯、主專案 test_license_cross_tenant_duplicate）。

推翻了什麼：

• STATE §2「log 開 identity port」「survey 拔 repo JOIN」兩條被實查改判（見第三批 block）。
• 首腦開卡的所有數字型描述（測試數、註解數、endpoint 數、import 檔數）沒有一張準。已改成「估計」並在大卡先跑 baseline 寫進卡。
• 首腦驗 survey-folders 送 pager 差點誤判回歸；打端點前要看 FE payload。

教訓（本棒新增，前面 block 已記的不重複）：

• 大卡開卡前先跑 baseline 寫進卡，runner 的紅燈才有對照——1716 沒有，驗收多花一輪 worktree 對照。
• notion_case.py get 輸出 pipe 進 awk 會被截成空，先重導到檔再讀。
• runner 對「標準形狀」的有理由偏離（1713 forwarding 不拆、1714 多一檔 wiring.py、1701 guards.py 不放 decorator）都應接受，判準是反悔條件有沒有寫進 README。
• 中繼交接該在派出兩張大卡之後、驗收之前做——這次抓對了時機，STATE 乾淨沒有半成品。

下一棒：STATE §3。本棒 context 尚可但接近臨界，建議下一棒換 session 冷接驗 1715／1725。

本棒範圍：冷接（自檢四題、pre-flight）→ 決策者追問「能力點（capability）是不是定義在套件內、怎麼檢查」→ 查明現況 → 拍板 → 開三卡 → 1726／1727／母卡 append → README 登記。1715／1725 仍在跑未回寫，未驗收任何卡。

commits（主專案）：e545e851 docs(FR-091) 能力點前置三卡開卡。套件側零 commit（本棒沒派 runner）。

開卡：CM-1728（asset 定形 CAPABILITIES 清單＋jedi-common Capability 型別，Opus／high，可派）、CM-1729（bulletin／system-core／notification 補清單，survey 23 處寫死字串收 config，Sonnet 5／medium，等 1728）、CM-1730（主專案守衛：Plugin 帶 capabilities、測試掃 PLUGINS 對 seed 檔，Sonnet 5／medium，19 支齊了才派）。1726 append detection 寫死字串收 config 段；1727 append「先列能力點表等裁」段；母卡 1690 append 裁示＋四卡對照表。

查明的事實（首腦核對）：

• 套件只宣告能力點「預設名字」（asset 六個 DEFAULT_*_CAPABILITY 常數進 PluginConfig），route 用 @capability_required(lambda rt: rt.config.xxx) 取名。判定全在主專案：core/plugins/_host.py:87-91 把 common.authz.require_capability 填進 adapters，實體在 jedi_iam.authz.capability（super_admin 旁路→查有效角色指派→flask.g 快取）。這是標準 ports and adapters，不動。
• 能力點列表 100% seed 在主專案 scripts/init/04-seed-core.sql（127 筆，gen_seed_sql.sh 從基線庫 pg_dump 產生），21 支套件的 migrations/ 都不 seed。同一件事寫三次（migration→基線庫→seed 檔），沒有守衛比對套件宣告與 seed。
• survey（23 處）與 detection（7 處）在 route 直接寫死字串，繞過 config；survey guards.py 檔頭有前一棒「capability 直接 import jedi_iam 不 port 化」的刻意決定，與 asset 形狀矛盾。
• role_capabilities 在 seed 檔是 (2, 135) 寫死整數對；06-admin.sql 已改用名字查 id；近期 migration 也是查 name 回 id。

決策（決策者裁）：

• 能力點跟著套件走（裝了才有、拔了就沒有）。前置先做：套件列清單、主專案守衛。
• migrate 自動補 row 是大 arc，另開 FR，因為要處理 Administrator 初始權限與寫死 id。
• survey／detection 都收成 config 形狀。
• config 不獨立成檔，留 contract.py（契約一處看完）。
• 不等全部：1728 現在派，前一批照排程，1730 最後收口。

推翻了什麼：survey guards.py 檔頭「require_capability 不 port 化」的設計說明（CM-1716 前一棒留的）被本棒裁示推翻，由 CM-1729 改寫。

教訓（本棒新增）：

• 卡片 spec 內互相引用未建的卡號只能寫佔位符，建完立刻 append 補正（本棒三張＋三張 append 一次做完，沒漏）。
• notion_case.py append 參數是 --file，zsh 用 set -- $pair 拆字串不會拆，改用陣列。
• 決策者中途問「這是不是自己 DI」時，plugin/assembly.py 的 build_services() 是備用組裝路徑（宿主沒給 provider 才走），主專案實際走 DI container Factory；兩套並存是刻意的，回答要說清楚哪條是實際路徑。

決策者另交代（本棒起生效）：派工 prompt 從簡（model／effort 一行＋卡 URL＋工作目錄＋branch＋並行注意＋回寫不等令），細節全寫進卡片白話。

下一棒：STATE §3。1728 prompt 已交決策者。

同棒追記（2026-09-13 下午，版面殘留）

決策者打開 jedi-integrity 看到頂層 12 支業務檔平鋪問「是不是沒整理好」。首腦掃 21 支頂層：integrity 12 檔／iam 1 檔（security_policy.py）平鋪；五支開頂層 ports/（file-upload／issue／notification／oscal-v2／iam，iam 雙軌）；jedi-issue tests 在套件內。根因：FR-069 早期各支就近做的選擇，FR-091 前三批的卡與驗收 SOP 都沒列「頂層平鋪／ports 位置／tests 位置」為檢查項，runner 照卡做自然漏。處置：SOP §4.3 補三條規則；開 CM-1731（integrity 歸三層，Sonnet 5／medium）、CM-1732（三支 ports＋issue tests，Sonnet 5／medium），1725 append iam 兩處；驗收 SOP ③ 加三項；oscal-v2 無 plugin 仍待裁。commit：SOP＋README＋STATE 見本次 commit。教訓：定形範例（asset）本身沒有的問題，卡與 SOP 就不會提到——每批開卡前該對全部套件跑一次「與範例的目錄樹 diff」，不只看範例有的東西。

同棒追記二（2026-09-13 下午，能力點改 21 支全列＋api 四件）

• 決策者問 1728 是否涵蓋全部套件、指出 jedi-issue 沒有。首腦承認原判準錯：只給「route 有 capability_required 的套件」開卡，漏了能力點另一半用途——前端選單／頁面守門（ui_routes＋route_capabilities）。決策者裁 21 支全列、形式一致。開 CM-1734 兩段式（Opus／high）：第一段 134 筆歸屬表回寫等確認（seed 有 21 筆舊命名：report 沒有點會讓 Capability.__post_init__ 炸、cloud_integration／notify_config／flow_template／system_config 用底線，活廢待查），第二段補 12 支。1730 改「每支必帶、空 tuple 允許」。
• 決策者指出 api 也要統一。掃 21 支 api/：三處平鋪（license-runtime、remote-agent、log forwarding——1713 時首腦以偏離收，現在推翻）→ CM-1733；三支無 serializers 是 request 不走 schema 的設計缺口（ai-bot／evidence-classification／issue），1733 只盤點等裁。SOP §4.3 加 api 四件。
• 1715／1725 已回寫 修正待驗證；1728 runner 已 commit jedi 89db991。驗收照角色規則開新 session（十步實跑回報太長，不在首腦 context 跑）。
• 推翻了什麼：1713 驗收時接受的「forwarding 不拆」偏離；1729 卡文「detection 以外」的措辭仍對但涵蓋面要靠 1734 補齊。
• 教訓：判準要從「資料的用途」出發，不是從「程式碼有沒有呼叫」出發——能力點有兩個消費者（BE 守門、FE 選單），只 grep BE 就漏一半。

同棒追記三（2026-09-13，1734 歸屬表裁決）

runner 查出：seed 127 筆非 134（7 筆 cruise-project 只在 DEV）；20 筆綁停用頁面疑廢；首腦 grep 的 survey.create 2 處是 authz 文件範例非守門、漏了 cloud_integration 4 筆 11 處守門；「21 筆舊命名」是首腦用 DEV 數減算錯，實為 14。決策者四點裁：① report 不進套件清單不改型別；② flow_template.* 歸主專案（誰的 route 在守）；③ 主專案 39 筆要宣告但歸 FR-090 另開卡，1730 先豁免名單；④ 疑廢照列不刪。oscal-v2／common 走豁免不建目錄。教訓：首腦開卡引用的數字要標來源（DEV 庫 vs seed 檔），兩者不同步時差額會被誤讀成規律。

同棒追記四（2026-09-13，驗收棒回報 1715／1725）

驗收棒（新 session）十步實跑：1715 通過 Done——identity port／拆檔／dataclass／疆界守衛全有突變證明；打折處：FR-048 403 路徑因 DEV 孤兒 mapping 湊不出真實 AP 未複驗，採信 runner；順手查出 task-setup/tree 500 既有缺陷（CM-1492 時期）與 compliance-audit 缺 compose／integration tests，記 STATE §3 第 8 項。1725 不通過改需修正——A～F 六組全過品質好，但首腦追加段三項（security_policy 歸位、ports 雙軌收斂、get_tenant_by_uid 500→404）一項沒做；runner 補三項不重做。教訓：追加段 append 在卡尾，runner 開工時可能已讀過卡沒再回頭看——之後追加要求時同步在派工 prompt 點名「卡尾有首腦追加段必讀」，或乾脆等 runner 收工再開小卡。

同棒追記五（2026-09-13，1727／1729／1734 回報）

• 1727 定形三點裁：migrations 走 jedi_task_platform/migrations/__init__.py 出實作、兩子插件委派（第三方案，避免 task 委派 participant 的怪方向又不建第三組 plugin）；_guarded() 不搬；ctx 不留 alias。participant 10 條註解死路徑 E 組刪。能力點兩半空 tuple 已由 1734 做，1727 只確認守衛。
• 1734 改需修正：14 個 commit 都在（21 支全有 CAPABILITIES），但卡上沒第二段回寫、且加 __all__ 沒同步凍結集合，HEAD 上 license-runtime／remote-agent／log 紅。教訓：「commit 了」不等於「回寫了」，runner 鐵律三步缺第二步等於首腦看不到；驗收棒 SOP ② git log 對卡 之外要加「HEAD 全量 pytest」，因為並行卡會把前一張的綠跑成紅。
• 1729 回寫完整（四支 commit＋survey 23 處守門走 port＋403 實打 GRC_403022＋主專案 api/survey/__init__.py 接線 0ac7022d），驗證等級中，開驗收 case。

同棒追記六（2026-09-13 傍晚，首腦自驗一輪）

決策者裁「驗收是首腦本職，不外派」——第 3 棒前段把 1715／1725 驗收外包給新 session 是角色理解錯誤（CLAUDE.md「執行外包」指產出，驗收抽查屬首腦本體）；之後一律自驗，context 撐不住就中繼交接。

• 1725 Done：補三項全實跑過（506 passed、兩突變紅、88 條 import 全過、404 實打）。
• 1729 退回：runner 回寫「survey 失敗集合與 baseline 逐字相同」不實——首腦 comm 對照 c29bad9 vs ~1 為 93 vs 90，新增 3 紅同一根因（_assert_wiring 把 capability_required 列必填但測試 fixture 沒給）。教訓：runner 說「逐字相同」要看它有沒有貼 diff 指令；沒貼一律自己 comm。
• 1731 退回：30b040e 用 git commit -- <路徑> 漏了 12 支未追蹤新檔，本機綠是假綠，checkout 即 ModuleNotFoundError（1734 runner 抽出還原實測）。教訓：驗收 SOP 加 ⓪ git status 看該卡有無 ??；「顯式 git add」規範的真正理由就在這。
• 1734：21 支清單齊、對 DB 0 不符、抓到 1731 壞 commit 是好功；但自己的凍結集合 10 支仍紅——它回報的「N passed」只跑了新測試檔。教訓：回報「測試綠」必須是該套件整個 tests/ 的 tail -1。
• 1727 B 組中，docstring 觸發主專案稽核詞守衛已提醒。1726／1732 待首腦驗。
• 裁：派 1730 前四支（issue／file-upload／flow-engine／ai-bot）改 path dep。

同棒追記七（2026-09-13 中午，1727／1729／1734 Done）

• 1734 Done：21 支 80 筆對 seed 零缺、凍結集合雙向守；issue vcs_integration 21 紅為既有（efa8f75~1 相同）記待辦。
• 1729 Done（退回一次後）：runner 這次真的開 worktree comm，90/90；自我檢討寫得對——上一棒是拿改動後的失敗集合比「記憶中的數字」，契約變嚴造成的新紅正好在盲區。
• 1727 Done：定形三裁全照做；task 接線與 compliance-audit 同形（core/plugins/task.py 組 adapters、attach 留 flow_control 共用 blueprint），首腦接受並確認 1715 已收同形；稽核詞守衛白名單隨檔案搬路徑屬維持原狀。runner 抓到 venv jedi-common 0.0.22 舊 wheel 讓 baseline 起不來，與 memory 舊坑同源。
• 教訓：並行時 runner 回報「與 baseline 相同」必看有沒有 comm 輸出；沒有就是沒比。

同棒追記八（2026-09-13 下午，並行六棒全收）

• 1726 Done：十步全過含 integration 真起容器、拔掉測試 35→0 條。首腦自驗踩坑：BSD sed 0,/pat/s// 是空替換、Nd 行號算錯，兩個突變「沒紅」其實沒改到檔，差點誤判守衛無牙齒；突變前必看 git diff --stat。
• 1731 Done（退回後）：乾淨 worktree 只指自身 PYTHONPATH 109 passed；runner 改用 worktree 不用 stash，對。
• 1732 Done：三支 ports 收斂、issue tests 搬根，file-upload 7 處深路徑 import 靠 shim 同物件。
• 決策者中途問「套件重構與權限是不是混在一起」：是，FR-091 現在三條線（結構／能力點宣告／版面殘留），動同一批套件所以並行互踩；但每條線終點明確，權限判定邏輯一行沒改，能力點線只是宣告名字。
• 盤面：23 卡 Done，只剩 1730。下一棒：四支改 path dep → 派 1730 → FR-091 收口。

同棒追記九（2026-09-13 傍晚，1730 Done）

能力點線收口：Plugin 帶 capabilities（Optional＝None 表「沒填」判紅，空 tuple 允許），五條守衛把 21 支 80 筆對 seed 127 筆分四類（套件 80／主專案 36／疑廢 11／待裁 report 1）零未歸類，四突變全紅。runner 兩處自主判斷都比卡好：api_log 一檔掛兩子插件合算；三支接線還在 api/ 的套件不純豁免而直讀清單進對照。順帶暴露 FR-090 漏網：ai-bot／ai-dashboard／remote-agent 接線從沒收進 core/plugins/，CM-1689 的 11 支沒涵蓋到，記 STATE 待辦。教訓：「豁免名單」本身要有守衛（第五條），否則新抽套件靜靜落在掃描外。

同棒追記十（2026-09-13 傍晚，1735 Done、全 arc push、開 PM 文件卡）

• 1735 Done：oscal-v2 輕量版＋common 註解 logger；runner 又用 git stash 驗既有紅（連 1727 兩張）。SOP 措辭要改：把「開 worktree 到開工前 commit」寫成驗既有紅的唯一方法放最前面，不是「禁 stash」放尾巴——禁令擋不住手順，替代方法才擋得住。
• 順手清空主專案 test_jedi_package_logger_names.py 的 PENDING_RELEASE（三支已納管），9fff7772。
• 決策者授權 push：BE 84ea07ef..9fff7772（104）、jedi da25a8d..c26a313（172），只推 feature/FR-075。
• 開 CM-1736：PM 要看「插件怎麼納入主專案」白話版——anatomy 是工程師版且停在 09-12，另寫 for-pm.md（一個比喻貫穿、零術語、三個數字）＋anatomy 補 09-13 後更新。
• 本棒總結：從冷接到 25 卡全收，驗收 12 張、退回 3 張後補過；三條線（結構／能力點／版面）全部收口。角色教訓：驗收是首腦本職不外派；並行時 HEAD 顏色不代表單卡成果，全在該卡 commit 的 worktree 驗；突變前看 diff；runner 回報「與 baseline 相同」要看 comm 輸出。

同棒追記十一（2026-09-13，決策者裁文件寫法）

決策者看 plugin-anatomy 說「文件不要帶歷史資料，一堆演進看不出最後變怎樣」。裁：說明文件只寫現況，歷史去 git log 與 LOG——與 CLAUDE.md 註解規範同精神套到 docs。CM-1736 範圍改為 anatomy 重寫成純現況（刪「這次整理做了什麼」整節、刪所有「原本／改判／第 N 棒」句），驗收 grep 歷史關鍵字出現即退回。此規則應進 docs/claude/docs-conventions.md（下一棒順手）：docs/features/<FR>/ 的說明類文件（design／anatomy／README 結論段）只描述現況，沿革一律進 LOG／commit。

本棒範圍：冷接 → 決策者追問能力點機制 → 開能力點三卡＋版面三卡＋普查卡＋oscal／common 卡＋PM 文件卡（1728～1736 共 9 張）→ 驗收 12 張（1715／1725／1726／1727／1728／1729／1730／1731／1732／1733／1734／1735）、退回 3 張後補過 → FR-091 25 卡全 Done → 決策者授權 push 兩 repo → 三份 README 同步現況 → 交接。1736 已回寫未驗。

commits（主專案，全 docs 除兩支）：e545e851／7d48f010／f88feed1／a8a42514／fb8ef624／244711c6／f3833c04／a7b9e157／3b8e1b12／47a77ac0／5de8c801／4d365c22／640e62f9／fc52124d／8fb5668f／7b2c58a2／7eac645b／adea9323／4d9e048d／b788bf33／8cc99ffb／8fc8c1c1；非 docs：9fff7772（PENDING_RELEASE 清空）。runner 側：0ac7022d（survey 接線）、a436c1c3（detection G）、3bbb3daf（task G）、96775277（compliance-audit G）、902927c9（license 測試路徑）、ec8ee592（1730 守衛）、13b4c817／c2f90adf（1736 文件）。套件側 60＋commit 見各卡。

決策（決策者裁）：能力點跟著套件走、21 支全列形式一致、migrate 自動補 row 另開 FR；survey／detection 收 config；config 留 contract.py；report 不進套件清單；flow_template.* 歸主專案；主專案 39 筆歸 FR-090；疑廢照列不刪；oscal-v2 輕量版、common 只註解 logger；驗收是首腦本職不外派；push 授權（僅此次、僅 feature/FR-075）；說明文件只寫現況、歷史進 LOG；PM 頁術語可用但要白話定義。

推翻了什麼：第 2 棒收的「forwarding 不拆」偏離（1733 收回）；survey guards.py「capability 不 port 化」設計說明（1729 改寫）；首腦自己開卡時的 is 比對測試（interning 無牙齒，改 AST）；首腦「只給 route 有守門的套件列清單」判準（漏 FE 選單那半）；首腦前段把驗收外派給新 session（角色錯）；1713 時接受的 jedi-log 白名單路徑寫法沒錯，1727 同理接受。

教訓（本棒新增）：

• 並行六棒同 monorepo 是新現象：HEAD 顏色不代表單卡成果、commit -- 路徑 漏未追蹤檔、runner「與 baseline 相同」靠記憶、驗既有紅伸手 stash——四件全在這棒第一次撞到，驗收 SOP 補 ⓪ 與 ④，派工尾註要固定加 runner 側四條。
• 首腦自驗也會假綠：BSD sed 空替換與行號錯讓突變沒改到檔，差點誤判 1726 守衛無牙齒。突變前看 git diff --stat。
• 判準要從資料用途出發不從程式碼呼叫出發（能力點兩個消費者）。
• 首腦引用數字要標來源（DEV 134 vs seed 127），差額會被誤讀成規律。
• 追加要求 append 卡尾，runner 開工後不會回頭看——派工 prompt 要點名，或等收工開小卡。
• Notion 沒有「需修正」狀態，退回改 In progress＋append 缺項段。
• 決策者中途問「是不是混在一起了」是對的：三條線動同一批套件，事前該講清楚「這波有三條線、互踩怎麼辦」。

下一棒：STATE §3。1736 待驗 → arc-review → 收口裁決。本棒 context 已到臨界，建議換 session 冷接。

同棒追記十二（2026-09-13 晚，DEV DB 搬本機）

決策者裁：DEV 太慢（188 遠端每查一趟），把 guidant_ai_dev pg_dump 拉回本機 localhost:5432，以後 DEV 就是本機；188 那份退為快照。已派小弟做（純環境操作不開卡）。memory project_dev_db_moved_to_local 已寫；CLAUDE.md「DB 環境清單」DEV 列與 sql-migration-conventions.md 等本機跑起來確認後由下一棒改。STATE §6 環境座標的 DEV DB 那列同步。

本棒範圍：冷接（自檢六題、pre-flight 全綠；發現 STATE「BE 文件 commit 未推」已過時，實際兩 repo 無領先）→ 決策者問 PM 頁「三個零件裝法還是舊式」是什麼 → 實查 core/plugins/ 17 檔、config/app_modules.py 三個字串、三支 api/<mod>/__init__.py 確認屬實 → 決策者裁「要」→ 開 FR-090 第 7 棒 CM-1737 並登記母卡／README／STATE。1736 尚未驗。

commits（主專案）：本 block 所在 commit（FR-090 README、STATE、LOG）。

開卡：CM-1737（三支接線收進 core/plugins/，Sonnet 5／medium）。卡上首腦核對過的事實：RedisChatHistoryStore 與 infra/remote_agent/adapter/lazy.py 三個 Lazy 代理都只有接線一個 caller 可整支搬；infra/remote_agent/ 另三支 adapter 是 DI 注入留原地；remote_agent_container 10 處反向依賴、ai_dashboard_container 保留不動 DI；三支 register() 都是標準簽名；對外 URL 1＋2＋14＋主專案自掛 1 條共 18；socketio 模式會跑 PLUGINS 迴圈，照 detection／license 先例不加條件。

關鍵決定：remote-agent 留主專案的 binary 端點 /agents/files/<uid> 必須走 mount_api=False 逃生門（先拿 bp、add_resource、再 register_blueprint）——本專案 Flask 3.1.3，register_blueprint 之後再加 rule 會被 _check_setup_finished 拋錯，不能先 mount_api=True 再掛。與現行 api/remote_agent/__init__.py 做法等價。

推翻了什麼：無。

教訓：PM 頁的「還沒做的事」是拿來對照的好清單——決策者一句「為什麼還有三個」就把 STATE §3 (c) 排隊的卡逼成了實卡。

下一棒：派 CM-1737（等決策者發令）；驗 1736；arc-review。

同棒追記（2026-09-13 晚，1736／1737 收 Done、RLS 舊資料清除）

• CM-1736 Done：決策者親看 for-pm／anatomy 收 Done，首腦未再跑 grep 驗（決策者已裁）。
• CM-1737 Done：runner 一次做滿，回寫含 18 條實打表、三突變、乾淨 worktree 全量。首腦十步自驗全過；唯一插曲是首腦樹上 __pycache__ 殘骸讓 test_converged_plugin_adapters_do_not_return_to_infra 假紅（rm -rf 後綠），記 STATE §4 小卡候選。主專案側 21 支同形。
• 決策者問 RLS 進度（不在本 arc）：首腦查 FR-087 現況——13 張表隔離仍全關、無修正 commit。追查報告 §5.2 的 191 筆「無主」workflow_templates：不是公版，是 5 個測試專案（blsadmin 4 個 07-27～30、jediadmin 1 個 08-09，皆 tenant_id NULL，因建立當下 context 無租戶）帶出的副本；module_frames 指向的母範本全在 102，公版住租戶 1 的 59 筆。STG／POC 皆 0 筆。決策者裁刪，首腦單 transaction 刪本機 DEV：專案 5／輪次 5／流程執行 132／任務執行 132／範本 191／證據 56／控制項對應 127／翻譯 127／指派 23／成員 6。順帶發現 project_audit_rounds 17 筆孤兒（指向 06-15 已刪專案，無 FK），未動。FR-087 報告兩處要更正：① 191 筆已不存在；② 該表「含公版可讀規則」寫錯，四條規則全是租戶比對、無 super_admin 旁路，開 RLS 後租戶 1 的 59 筆公版子租戶看不到，與問卷平台旗標同題待裁。RLS 修正卡仍未開，決策者裁先走 FR-089 收口順序。
• FR-092 撞擊面：12 張修正卡皆未派；只有 CM-1706 動 app_modules.py 與 1737 同檔，現 1737 已收可放。建議 1737 → arc-review → 再放 FR-092 純刪卡，避免 review 範圍混入。
• 決策：套件都收在 core/plugins/ 後往下走（arc-review）。

同棒追記二（2026-09-13 晚，開 arc review CM-1738）

決策者裁「開吧」。開 CM-1738（Opus／high，五 agent 平行只讀不修），範圍 BE 84ea07ef..0422c5d6（118 commit）＋jedi da25a8d..c26a313（172 commit）。卡上首腦點名九題，最重的一題是「21 支由 8 個 runner 平行做，名字一樣、行為一不一樣」——抽 iam／detection／survey 三支並排看 contract／guards／init。另要求 harness 抽五支實跑、守衛列出有牙齒／沒牙齒、能力點三層（套件宣告／Plugin 引用／seed／DEV）對照。FR-089 母卡 append、README 進度表加收口列。

同棒追記三（2026-09-13 晚，1738 收、開六張修正卡）

runner 產出報告但 session 結束未 commit 未回寫，首腦接手：commit 9b29a70d、回寫、Done。首腦復核兩 Critical 屬實（C1 本機 DEV 三端點 500＋log NameError；C2 四個測試檔 find 零命中）。決策者裁「開吧」→ 一次建六張 CM-1739～1744。拆法：C1＋C2 一張（同 Critical 且都在 system-core／detection／iam）、I-6 與 I-4 分開但序列（同批 core/plugins 檔）、I-1＋I-2 一張（都是補暱稱鏈）、I-3 一張、守衛清單一張。I-5／M／註解不開，等發版前順手。教訓：runner 報告寫完就掛，收工三步缺兩步——arc-review 這種長棒要在派工 prompt 提醒「報告落檔後先 commit 再繼續寫回寫」。

同棒追記四（2026-09-13 晚，1740／1743 收 Done）

同一 runner 連做兩張：77ccfae6（1740，13 adapter 加 ABC 繼承）＋83d741c8（1743，_di／_lazy 收 _host.py）。首腦驗：13 個 __mro__ 全對、abstract 空集合、突變 TypeError；乾淨 worktree 100 passed；BE 重啟六支端點零 500。抓到一處紀律問題：77ccfae6 單獨 checkout import 不起來——runner 把 1743 的 consumer 改動（compliance_audit.py 改 import lazy）夾進 1740 的 commit，而 lazy() 下一個 commit 才進 _host.py。runner 回寫「100 passed」是工作樹兩張都改完的數字。並行分支不 rebase，兩 commit 視為一組收下。教訓：同 runner 連做兩張要在派工 prompt 寫「每張 commit 後 git stash -u && pytest && git stash pop 或開 worktree 驗該 commit 自足」；驗收 SOP ④「在該卡 commit 的 worktree 跑」正是抓這個，這次抓到了。順帶：1741 runner 未 commit 的新守衛在 HEAD 工作樹上把 core/plugins/participant.py:79,87 判成補暱稱複本（實為 user-directory port 實作），留給 1741 判白名單。

同棒追記五（2026-09-13 晚，1739／1742 收 Done、1741 半張退回 In progress）

• 1739 Done：C1 三行改對、21 支重掃零殘留、BE 重啟三端點 500→403、突變紅；六支全綠、survey 48 紅與基線 c26a313 相同。C2 四檔 git log --all 零命中＝從沒寫過，BE 補真測試 2de451e8。
• 1742 Done：搬檔正確、iam 506 passed、新守衛突變紅、白名單 18 列（runner 報 19）。
• 1741 半張：I-1 jedi b077ed8 通過（六份收一、五支綠、三支列表暱稱補得到）；I-2 BE 側未做完未回寫——複本未收、FE fallback 未查、participant 白名單未加。改 In progress，卡尾寫六步接手清單。
• 並行同檔事故（第三次）：1742 裸 git add test/test_module_boundaries.py 把 1741 未 commit 的守衛 hunk 吞進 c1fa594c；工作樹上還剩 1744 的三條版面守衛 hunk。commit -- 路徑 對同檔不同 hunk 無效。教訓：三張卡動同一個守衛檔時，派工 prompt 要寫 git add -p 只加自己的 hunk，或首腦開卡時就把守衛拆檔（test/boundaries/test_<topic>.py）避開同檔。
• survey 48 failed 42 errors 是 arc 基線就有（review 已記四支既有紅），三個 runner 各自撞到各自解釋一次；下次開卡直接在紀律段寫明「survey 既有紅，不用查」。

同棒追記六（2026-09-13 晚，1741／1744 收 Done，六張修正卡全收）

• 1741 Done：I-2 補齊——BE 7b5091fe 收裸 SQL 複本走 canonical＋DI 注入 identity＋_row_to_dto 佔位改 None（runner 自抓）；FE 6b7b0f2 兩欄補退路（A 案：B 案會把「同欄兩語意」寫進契約，runner 判斷對）。首腦突變塞回裸 SQL 守衛紅；資源庫列表暱稱補到。首腦失誤記錄：runner 上一棒早已把 FE 查證與選案 append 在卡上，首腦盤點時沒讀到卡尾就判「未查證」——讀卡要讀到底。
• 1744 Done：五突變全實跑（pycache 不紅／x.py 紅；三條版面守衛各紅）；白名單兩列理由改正屬實。順帶暴露 ProjectRoleGuardAdapter 兩份同名不同實作，記 STATE 待辦。
• 六張全收，FR-089 品質關過。 乾淨 worktree HEAD 守衛族 141 passed，BE 重啟零 Traceback。
• 本輪並行紀律總結：三次同檔 hunk 混入（1740→1743 連做、1742 吞 1741、1744 hunk 留樹）。根因是三張卡都動 test_module_boundaries.py 這一個 1,600 行的守衛檔。下次開卡前先拆檔（test/boundaries/test_<topic>.py），比事後要求 git add -p 可靠。
• 下一步：決策者裁 §3 第 3 項——(a) 發版（pin 還原＋推 Nexus＋jedi-common 下限＋SPEC＋release note）、(b) CM-1696 DI 瘦身規則、(c) FR-090 36 筆能力點申報處、(d) migrate FR；以及 FR-092 12 張純刪卡、RLS 修正卡的排序。

同棒追記七（2026-09-13 深夜，發版 (a)：21 支推 Nexus、pin 還原、pyproject 整理）

• 決策者裁：版號都從 1.0.0 起算，有 2.x 的（oscal-v2）例外 → 20 支 1.0.0、oscal-v2 2.3.0；套件間下限全提到新版（jedi-common 新 export fill_user_names 是硬理由）；七支 description 拿掉內部代號。jedi 2837fea。
• 決策者裁 pyproject.toml 太多無效註解，收進 git 說明：BE 290→161 行（註解 170→42），21 支套件 pyproject 施工日誌全收；移掉的內容逐項寫進 commit message（BE e0496645、jedi 2837fea）。
• publish：先發 jedi-common 驗認證，再批 20 支，Nexus 21/21 可見。BE 清掉 42 個 editable dist-info／symlink 後 poetry update 21 支，逐支 realpath 全指 site-packages；守衛族 141 passed；api／socketio 兩模式零 Traceback；十一條端點實打全 200／合法碼、暱稱補得到。poetry.lock 是受版控的（memory 舊記載「gitignored」已過時），退役六支自 lock 消失，另 commit。
• 本機 DEV BE 以 Nexus wheel 起在 8000，決策者驗中。
• 下一步：version-bump skill——BE 1.19.0→1.20.0、FE package.json 對齊、release note v1.20.0（含「切子租戶暫不對外」註記）、spec 快照。等驗完發令。