FR-069 STATE（living，只描述此刻）

最後更新：2026-09-01 晚（第四任首腦交棒——arc-review＋修復＋文件收官＋補發版全收，剩最終收官章與 merge）。本檔就地 Edit，不留歷史；歷程看 fr069-LOG.md；全案總帳看 2026-09-01-FR069-SUMMARY.md。

開發、review、修復、文件、發版全部完成。 新首腦接手後要處理的只有：

接手必讀順序：本檔（尤其上表與「190 現況」）→ 2026-09-01-FR069-SUMMARY.md（全案總帳 275 行，含 26 支套件終態表與教訓精選）→ docs/review/2026-09-01-fr069-review.md（review findings 與 §⓪ Resolution 逐條處置）→ 需要脈絡再翻 fr069-LOG.md（歷程，按時序，最後一個 block 是第四任）。 驗收基準：主專案守衛 python -m pytest test/test_module_boundaries.py test/test_error_code_uniqueness.py = 80 綠（必 python -m，直呼 pytest 假紅）；本機 8000/8002 跑 Nexus 正式版（無 path override，poetry install 即可）。

• arc-review 全案（5 agent 平行）：報告 docs/review/2026-09-01-fr069-review.md——1 Critical＋10 Important＋3 批 Minor；零套件反向 import、D5 凍結面機器 diff 零漂移；主題是「綠著的守衛不代表在守」（四條守衛掃舊名/掃描根縮水/假 docstring）。
• CM-1501 修復棒：13 條全處置（11 修/1 誤報/1 歸文件棒）；C-1 撞號（GRC_400105 一碼兩用）修成 GRC_400121 三 repo 同步；突變 15 發。I-8 半條煞車——問卷審核開關的平台側消費端根本未建，接線接了也沒人用，建議另開卡「問卷審核開關端到端接通」。
• CM-1502 文件收官（第一段）：CLAUDE.md＋docs/claude 死名同步／架構手冊終版（族譜 26 支終態＋四類清單＋readmodel 四規格落 infra/readmodel/README.md＋D6 六條）／SUMMARY 275 行／Postman 重產（637→609，減 28 支逐條核為刻意退役）／兩站重 build。
• CM-1503 補發版：四支 patch 上 Nexus——task-platform 0.1.1／survey 0.1.2／detection 0.0.2／compliance-audit 0.0.2；可拉性三層驗證（index／實抓 whl／解包 grep 確認 GRC_400121 真在產物內）；主專案 pin 跟上、守衛 80 綠、I-3 例外表已清空。
• 190 dev server 建置（見下節）。

形態＝nginx 服務 build 產物（非 vite dev server）＋BE 直跑源碼（不編譯）：

• FE：/opt/guidant-ai-fe（feature/FR-069）→ npm run build:ONPREM → 產物 rsync 到 /var/www/html/audit-manager/（既有站台已備份 audit-manager.bak.20260901-205511）。腳本在 190 的 /tmp/build_fe.sh＋/tmp/deploy_fe.sh（⚠️ 建議搬到 /home/jedi/ 免得被清）。
• BE：/opt/guidant-ai-be（feature/FR-069）＋.venv（symlink 到 /home/jedi/dev-be/.venv）；起法用 /tmp/start_be.sh（8000 api＋8002 socketio，用 setsid 脫離 ssh session——直接下 nohup 會連自己一起殺掉，踩過兩次）。
• 形態設定＝on-prem：DEPLOYMENT_MODE=host＋TURNSTILE_ENABLED=false（BE/FE 一對，只關一邊會壞）；FE bundle 實查 turnstile 已編譯成常數 false。
• nginx：/etc/nginx/sites-available/default（已備份）——443 self-signed、root 指 audit-manager、/api→8000、/socket.io→8002（本任修正，原設定錯指 8000，共編必不通）。
• DB：e2e 容器組 cm-e2e-postgres（25432）/redis（26379）/minio（29000）/mailpit；run DB＝guidant_ai_e2e，已補套 26 支 migration 全過（8/4 水位→FR-069 最新，順帶完成「帶舊資料升級」實地驗證）。⚠️ golden 庫未升級——clone-run-db.sh 重來會回舊 schema，要重跑那 26 支（清單與腳本在 190 /tmp/e2e-apply-list.txt＋/tmp/apply_migrations.sh）。
• AI 金鑰已補（三家）；MFA 關閉。
• ⚠️ git pull 拉不動：token 已依 user 指示拔除、remote 還原 SSH 形式，但 190 沒配 GitLab SSH key。下次更新前要配 key 或臨時給 token。
• ⚠️ 踩過的坑（重做 190 或建新機時會再撞）：①FE 的 GitLab 專案名是 audit-manager-system 不是 compliance-manager-fe（用後者 clone 會 404）；②190 原本沒有 Nexus 認證，憑證在 188 的 ~/.config/pypoetry/auth.toml（poetry config http-basic.nexus）；③Redis 埠在程式裡寫死 6379（config.py REDIS_URL），主機映射 26379 連不上——解法是 REDIS_HOST 填容器內網 IP；④ssh 內下 pkill python main.py 會連自己的 session 一起殺（連線中斷兩次），用 /tmp/start_be.sh 的 setsid 形式；⑤e2e compose 的 BE 環境樣板不含 AI 金鑰（e2e 不打真 AI），要另外補三家 key。

FR-069 模組化抽取：第一/二/2.5/第三階段＋發版（CM-1473）＋第四階段全收 ✅，user 手測全過、全卡 Done（2026-09-01）。第四階段最終帳：核心抽取（participant／evidence-classification／detection／ai-dashboard 新抽＋flow_control 分家四步＋問卷合併）＋兩包定名（jedi-task-platform／jedi-compliance-audit）＋申報制＋D-10 償債＋掃卡補洞四棒（1493 償債：發版依賴環已解／1494 查證：殭屍定讞／1496 SMTP 修復／1483 儀表板）。六項裁定全下（2026-09-01）：三包名定案／task-platform 0.1.0／退役低風險＋套件內死碼放行併發版前置／S4 併收官 e2e／associations 殭屍開 CM-1498。發版棒 CM-1499 ✅＋CM-1500 問卷共編修復（jedi-survey 0.1.1）✅ 皆收 Done。CM-1497 套件債清理＋CM-1498 associations 殭屍退役皆收 Done（2026-09-01 晚，user 手測 workflow-setup 存檔過）——1497 帳：三筆測試債歸零（notification 226 綠/log 75 綠/flow-engine 116 綠）＋D6 契約七支統一補＋issue 死碼 367 行裁決材料（A/B 留刪等 user 裁）；1498 帳：活鏈端點退役＋兩套殭屍清光（BE 294fbec1＋FE 8801f94；31f01cf2 是出包空殼以 294 為準）。收官串（user 2026-09-01 裁）：e2e 暫不做改「dev server 直跑功能驗證」（190 已備妥待部署形狀裁定，最後做）→ arc-review → 文件收官。已裁：jedi-issue GL/GH 整合碼留（對外已宣稱有此整合，屬產品承諾）。arc-review＋CM-1501 修復＋CM-1502 文件收官＋CM-1503 補發版四棒 2026-09-01 晚全收 Done（詳見本檔頂端「本任已完成事項」）。守衛現 80 綠（python -m pytest）；主專案本輪淨刪 38,000+ 行；套件終態 26 支（現役 25＋退役 10 已刪）。

未結 follow-up（皆不擋 merge）

⚠️ 本檔 2026-08-30 晚間曾被改回舊版（平行棒疑似還原），首腦已把累積現況補回——若與各卡回寫衝突，以 Notion 卡為準。

• 九支套件全部正式版：五支新套件 jedi-ai-bot / jedi-integrity / jedi-log-forwarding / jedi-remote-agent / jedi-license-runtime 皆 ==0.0.1；jedi-common 0.0.33（.11 JSONB 查詢＋身分脈絡包＋SessionMixin 正名）、jedi-auth 0.1.35（P8 authz 主體域）、jedi-project 0.0.9（.12 projects 四欄）。主專案 pin 至 commit 0f8c1b93，零本地路徑依賴（1455 開發期 path override 除外，見下）。
• jedi-department／jedi-resource-store 已標 deprecated（monorepo d765191：README 警示＋pyproject [DEPRECATED]；目錄保留觀察期）。🔴 重要交接事項：主專案 pyproject/poetry.lock 的改動持續留在 working tree 未 commit，現已累積三批：①.10 resource-store 拔 pin；②.13～.15 的 jedi-iam/auth/login/mfa/captcha dev path override（照規矩不入版控）；③3.1（CM-1467）拔掉四支舊套件 pin 與四支 path override，只留 jedi-iam 一行。三批同檔拆不開，全部託付發版棒還原 pin 時一併入版（.18 曾託付但發版擱置故未執行）。退役事實已由 docs commit 29e124bd 與母卡記錄。
• Postman 全站 API collection 已交付（commit 38e8734a）：637 支請求／21 資料夾，產生器 scripts/gen_postman_collection.py 是唯一真相（重跑 diff 空＝與路由表零落差）；掃出 62 支裸路徑死端點（雙路徑註冊缺 handler、FE 零裸打、線上零影響）→ 裁決開追蹤卡 CM-1461，隨 2.5/第三階段各棒動到該模組 route 時順手拔（拔前確認 e2e/agent 無呼叫）。
• project_extensions 收斂（.12）：四欄已收回主表、雙寫中、舊表未 drop（安全網，drop＋P-like 驗證等 user 令，往後排）。migration 只套 DEV（STG 實查未動）。
• 🔴 jedi-iam 已是「完全體」插件（3.1／CM-1467）：route 也在套件內——register(mount_api=True) 掛出 39 條身分 API，主專案 api/auth/ 已刪除、REGISTERED_APPS 的 "auth" 已拔。身分 API 的存在與否由 core/app_factory.py 的 register_identity(..., mount_api=True) 一行決定（拔掉測試實證：註解那行 → 16 支端點全 404、其餘模組無感）。
• 🔴 主專案已零引用四支舊套件名：jedi_auth／jedi_login／jedi_mfa／jedi_captcha 的 import 全改 jedi_iam.*（80 檔），pyproject 四支 pin 與四支 dev path override 已拔（留 working tree 未 commit，見下）。守衛測試 test_no_import_of_retired_identity_package_names_in_main_project 焊死舊名不得復活。轉發殼在 monorepo 仍在（過渡），3.6（CM-1472）退役執行。
• 後端：開發機 8000（api）與 8002（socketio）皆已重啟且乾淨（CM-1500 收口時實測，無 traceback）。DB 必須指 guidant_ai_dev（唯一套過最新 migration 的庫）。
• ✅ path override 已全數清空、八支套件皆吃 Nexus 正式版（CM-1499 發版棒還原 pin；CM-1500 再把 jedi-survey 推到 0.1.1）。實查確認：pyproject 無任何 active path 行、venv 內無 editable jedi 套件（無 direct_url.json）。拉 feature/FR-069 分支不再需要 pip install -e，poetry install 即可起 BE（先前的六支 editable 需求已失效）。

狀態：✅ Done（2026-08-31，Notion 已回寫「修正待驗證」等 user 驗）。 commit：monorepo e614c34＋d6b0dfa／主專案 e483ba17＋d1a141c2，兩 repo 已 push feature/FR-069。

六件工作全數勾銷：①route 上移（39 條進套件，api/auth/ 刪除，URL 機械比對集合相等）； ②內部結構重整（頂層兩套 common 合一、mfa/common 併回頂層、entity→entities）； ③四殼退役（80 檔改名＋拔 pin＋死名守衛）；④D16 port 化（10 處自建 RepoImpl 收進 AuthRepositories）；⑤GoogleAuthAdapter stub TypeError 修掉（已復現舊行為確認）； ⑥README 架構節＋README.html。隨棒：CM-1461 身分 13 支死路徑照 .18 正解拆 Create Route 類（500→405，POST 仍活），已回該卡勾銷；依賴衛生順掃。

追加改名（user 2026-08-31 指示「以前叫 identity 的換成 iam」）：blueprint 名 identity→iam（.13 建骨架時的殘留，.G 漏改；對外 URL 零影響，三 repo 對 identity.* endpoint 引用皆為 0）；common/identity.py→common/iam_ports.py、 core/identity_wiring.py→core/iam_wiring.py、對應測試檔。刻意不改： JWT_IDENTITY_CLAIM／user_identity 欄位／get_jwt_identity()／resolve_identity() ／Accept-Encoding: identity／Identity* 四個公開型別——那些是領域概念或對外契約， 不是舊套件名。

📌 照抄要點（3.2–3.6 十一支的範本，派工 prompt 請帶這段）

1. route 取 service 用 ctx().service("name")，不要 @inject——Provide[Containers.x.y] 要在 import 期寫死具體 container 路徑＝套件反依賴主專案。改由 register() 把 provider 名冊放進 app.extensions，route 在 request 期取。 🔴 存 provider 不存實例——主專案 service 多為每 request 建新的（內含 session-bound repo），存實例會讓第一個 request 建的物件用到天荒地老，平常看不出、併發才爆。
2. 認證與能力點一律 port 化，且刻意不給預設值；缺接線要拒絕掛載不是跳過—— 跳過的後果是端點全變公開，而服務照常起得來、健康檢查照樣綠燈。
3. 什麼留套件、什麼回宿主：問「換一個產品，這段還會一樣嗎」。一樣→留（流程順序、 資料模型組樹、欄位正規化）；不一樣→走 hook 回宿主（商務授權旗標、選單過濾、政策值 從哪讀、審計欄位 nickname、原廠帳號保護）。
4. register 掛 route 的形狀：create_blueprint() 內 _assert_api_wiring(adapters) → 建 context → record_once 寫 app.extensions → mount_routes(bp)。 URL 對照表就是 api/__init__.py::mount_routes()，它是唯一真相。
5. 對外契約凍結，用機械比對證明：URL／error code 字串／能力點名一字不動，用 集合比對（不是比數量——數量對但拼錯一條的症狀是該 API 憑空消失 404，route 表看不出）。
6. 死路徑順手拔（CM-1461 型）：先實打確認裸路徑 POST 是否活著。活的就拆獨立 Create Route 類（不是整條拔），死 verb 自然 405，呼叫端零改動。
7. harness 要真的能打：補殼後不能只證明「register() 掛得上」，要實打一支端點走通。 3.1 踩出四道宿主前提，有 route＋有 DB 表的套件大概率同樣要踩： init_db(DB_URL)／PROPAGATE_EXCEPTIONS=True（否則 flask-restful 吃掉所有例外， error handler 註冊成功卻不生效）／JWT_IDENTITY_CLAIM／column_property 用的 DB 函式。
8. blueprint 名別再叫舊套件名——改名時記得掃「寫死 endpoint 前綴」的地方（3.1 有 兩處），那種寫死壞掉的方式是靜默匹配到 0 條而不是報錯。

待 user 裁的一件

authz/ 是否改名（②的未竟項）：實查後建議維持不改，理由（docs 內 2824 處提及、 改名解不掉真正的門檻是六個軸的分界、common/authz/ 是 FR-048 收斂後的唯一 import 面 改名期間必然出現新舊並存空窗）與候選比較（access/ 與 IAM 的 Access 撞名反而更糟） 已完整回寫 CM-1467。本棒已做零風險償還：在 authz/__init__.py 與 README 補上 「authz = authorization，與 authn 相對」。若仍要改，建議 authorization/、整批原子改、 另開卡單獨做（混進大搬遷會讓機械比對失去意義）。

• ✅ 套件改名 jedi-identity → jedi-iam 已執行完畢（CM-1464，2026-08-30）：全名 Identity and Access Management（PM 定調，推翻 D9 原命名段）。monorepo 目錄／package／pyproject dist 名、三支轉發殼的轉發目標、主專案 96 處 import、pyproject path override、守衛測試、design.md §3 D9・§7 2.5 節・§8 狀態表、boundary-map／roadmap／phase2 全部改完（monorepo e3d3aec）。jedi_identity 不留轉發殼——未上 Nexus、無外部消費者，守衛測試已焊死舊名不得復活；被合併的四支舊名（auth／login／mfa／captcha）維持轉發殼到第三階段。.18 的發版清單以 jedi-iam 為準；新開的棒一律直接寫 jedi_iam。

背景：user 質疑「收 Done 的卡裡有沒有沒人接的遺留」，首腦把 P4（CM-1474–1492）＋P3（CM-1467–1473）共 24 張卡全文重讀盤點。結論：多數遺留有被接住（如 1475③→P12 步驟 0、1489 漏項→1491），但抓到懸案，已開五張新卡：

CM-1484 排序更新：改排 1493 之後（同型手術照抄先例）。原卡（1482/1489/1490/1484/1469/1470/1471）已 append 指向。 P3 掃卡另兩項裁定：authz/ 命名 user 拍板不改（維持 authz，CM-1467 待裁項結案）；SMTP 測試功能不搬套件（TestMailService 屬產品設定知識，CM-1496 卡上有裁定全文）。 P3 記帳（不開卡）：Nexus 四支舊殼（auth/login/mfa/captcha 舊版）下架/yank 等 user 令；CM-1461 剩 bulletin/device/system-config 9 支未拔（route 未上移），收官前盤總帳。

綠色記帳（時機未到不開卡）：四張 hi_* 歷史表 0 筆留另議（1486）／flow_template API 欄位併 FE 拿掉（1474）／兩套件 harness 待型別償還後補（1489/1492 誠實聲明）／存量紅燈一批（8 紅 guard 未接線＋AI dashboard 舊測試 metadata_builder 不存在）——收官 e2e 會撞到，先記。

⚠️ 待 user 確認：CM-1481（AI 分類）與 CM-1489（detection）收 Done 在本任接手前，兩卡手測清單都聲明「端到端未跑」（分類要 AI 錢／檢測要 agent 實掃）——user 是否實際手測過待確認，未測過則實質是「修正待驗證」。

0. Postman collection 重產（2026-09-01 發現）：docs/reference/postman/ 是第四階段搬遷前產的已過期（分類/auth 標記與現況差 7,800 行）——收官時重跑 gen_postman_collection.py 入版。

1. readmodel 整理（user 2026-09-01 記帳）：①按功能語境分子資料夾（tasks/audit/oscal/detection）＋每支檔頭標「拼了哪些疆界」；②四條規格入資料夾 README（只讀鐵則/層次紀律 route→app query service→infra readmodel/出口必 DTO 不泄 ORM row/port 化注入）——聚合查詢仍屬 DDD＋六邊形（CQRS 讀側），不是豁免區；③逐支核 DTO 出口。等在途檔落定（CM-1491/D-2 聚合半）再動。

2. 套件族譜對照表終版：路線圖「套件族譜」節（a71ab166 已有活版本）在 CM-1492/1482 收口後把進行中段搬進已完成，定名後為終態。

3. 「主專案剩什麼」四類清單落架構手冊（櫃檯/接線盤/組裝/業務加工——口頭版已給 user，2026-09-01）。

4. 可選：跨 schema SQL 提示型守衛（掃 infra/ 各模組目錄 SQL 字串含跨 schema 表名——已知盲區的不完美緩解）。

5. 終局備忘（不排程）：主專案 DDD 四層縮成產品定義層後，目錄語意重新表述。

• 分支 push 已委任（memory feedback_fr069_push_delegated_branch_only）：僅限 BE 與 jedi monorepo 兩 repo 的 feature/FR-069，收口後順手推不必請示；合併回 main 仍 user 本人；arc 收口後委任失效。

• D5 grc→flow_control（error code 字串值與 API path 不動）。
• D6 插件契約：自帶 api／container／migration 隨包／register(app, adapters, config, schema_extensions, mount_api)；拔掉測試。
• D7 harness＋接入 README 標配；形態分流準則。
• D8 全路線解凍、四階段結構；身分脈絡名冊標準件。
• D9 身分族合併 jedi-iam（auth＋login＋mfa＋captcha 降級＋主專案身分中介層）；notification 獨立、agent 機器身分不併；順手清四髒。前置已確認：jedi-* 僅 Guidant AI 消費。
• D10 問卷疆界合併成立（跨邊界 FK 鐵證）；D11 device 不併檢測；D12 OSCAL 三角改寫（開工前查證依賴方向）；D13 三支退役＋user 追加 department/resource-store 即刻標記；D14 bulletin 維持獨立套件；D15 ext 裁決三件（.12 改打 project_extensions／孤兒表另案 CM-1450／JSONB 定位改預防性建設）；D16 基礎依賴 port 化通則（四張標準 port；唯一例外 jedi-common）。

• CLAUDE.md「Response Format」段寫信封鍵是 code，實際是 status（P7 驗收確認文件從頭錯）。

背景：實測驗證吃掉每棒 6 成以上時間，多為重複與儀式。判準沿用既有原則——「壞了會不會靜默」：會靜默的驗證是保命錢不砍，會大聲叫的靠測試扛、不手驗。

1. 突變驗證只做「安靜壞」的（安全降級/漏接 port/授權放行類）；結構守衛類（殼檔數/警告訊息等,壞了測試本來就紅）不做突變。
2. 行為驗證表只驗本棒動到的路徑，上游棒驗過且本棒未碰的不重驗（regression 由守衛測試扛）；上限 8 列，超過要在回寫說明理由。
3. 不跑全量 pytest——只跑動到模組的既有 test 檔＋守衛測試（本來就是 CLAUDE.md 測試政策）。
4. 同型棒信任遞減：同型第二支起驗證項對半（例：第三階段補殼首棒全額，之後每支輕驗）。地板不再往下：守衛全綠＋拔掉測試＋該模組 2–3 條 API 實打，每棒必做。
5. 首腦驗收改抽查：runner 已貼實際回應碼的，首腦抽 2–3 條關鍵路徑核對，不重打全鏈。
6. 不砍的保命錢：守衛 grep、機械 diff 比對、「該擋的擋」核心 2–3 條（401/403）、RLS 抽查——全屬無聲失敗類或成本極低。
7. runner 側落地方式＝派工 prompt 固定尾註（runner 不讀本檔）；本段為 canonical，prompt 與此不一致以本段為準。

1. 套件結構五層齊備（api/app/domain/infra/plugin＋harness/＋tests/＋README）。
2. 守衛：套件源碼 grep 主專案 import＝0（^\s*(from|import)\s+(app|domain|infra|api|common|config|di_containers|core)\.）。
3. 套件測試離開主專案獨立跑全綠。
4. register() 四插槽簽名與 P1 範本一致。
5. 拔掉測試證據（卡片回寫要有：註解註冊行→BE 起得來→該模組路由 404→其餘無感→還原恢復）。
6. 接入 README 含 quickstart；migration 隨包照 SOP §4.2。
7. 主專案 pytest test/test_module_boundaries.py 全綠（現 49）；卡片白話回寫＋commit hash。
8. 身分類棒次加驗：權限行為實測（該擋的 403/401、該過的 200）貼實際回應碼；驗證/密碼/token 邏輯零行為改動。

發版流程（user 明令後）：套件 poetry publish --build -r nexus → 主專案 pin ==版號＋path 行註解回去 → poetry update（禁 poetry lock）→ symlink 驗證 → 煙測（守衛＋重啟後端＋實打一支 API＋log 無 ERROR）→ commit（只收 pyproject.toml＋poetry.lock）→ Notion 補發版紀錄。後端切正式版必重啟。semver：加新無破壞＝patch/minor；jedi-auth 依賴 jedi-common，發版順序 common 先。

• 平行棒同時改 config/app_modules.py／pyproject.toml：commit 前 git status，只顯式 add 自己的檔，禁 -am／git add -A；絕不跑整樹還原。同檔混有平行棒不可入版的改動時：docs 先行記錄事實、檔案改動託付後棒入版（退役棒先例）。
• 驗收「文件 vs 實況不符」先比對變更前後原始碼再下結論；「看似重複的殘留」先查繼承鏈（見 LOG 教訓）。
• 改主體域守門行為改 jedi_iam.authz 套件（3.1 起主專案已零引用 jedi_auth，守衛測試焊死），不在 common/authz/ shim 補邏輯（守衛測試會擋）。
• 🔴 身分 route 已不在主專案——要改帳號／角色／租戶／部門／登入／MFA 的端點行為，改 jedi-iam/jedi_iam/api/routes/，不是 api/auth/（該目錄已刪）。URL 對照表在 jedi_iam/api/__init__.py::mount_routes()。
• 🔴 宿主接線檔命名：common/iam_ports.py（套件要的疆界外服務：通知／設定／OTP 文案）vs core/iam_wiring.py（route 層的 service 名冊、認證 decorator、產品 hook）。要加新的 service／hook 改後者，且它放 core/ 是刻意的——它 import app/ 與 infra/，放 common/ 會被反向 import 守衛擋下。
• 看 log 分辨平行棒：錯誤請求的 Host: 埠——8000 是主開發服務，其他埠（如 8010）是平行棒臨時服務，錯誤不要誤判為主線 bug。
• BE 連的庫必須是套過最新 migration 的（目前僅 guidant_ai_dev）；基線庫補套走 P-like 驗證那條路，不手動補。

讀本檔＋design.md §3 決策表（D1–D16）＋§8 依賴圖即可接手。驗收照上方 SOP；發版照上方流程；派工 prompt 慣例見 LOG 各棒記錄（薄 prompt＋卡號＋該卡會踩的鐵則＋runner 鐵律尾註）。

此刻的下一步（2026-09-01，CM-1499 發版棒 ＋ CM-1500 共編修復皆已收 Done）：

1. 收官串：CM-1497 套件債清理（新增待辦：D6 契約 library 模式不寫 runtime context，七支同款缺口統一補齊——見下）＋CM-1498（associations 殭屍）→ e2e 回歸（含 S4 恆偽分支退役）→ arc-review → 文件收官（「收官棒待辦累積」節）。
2. user 手上的待裁：三包名字最後確認（發版前是免費改名窗口）。CM-1450 已查實由 CM-1474 執行完畢，不再等令。

CM-1497 新增待辦（CM-1500 帶出，2026-09-01）：插件 register(..., mount_api=False) （D6「當 library 用」逃生門）只做 configure、不寫 app.extensions，而寫入綁在 create_blueprint(s)() 的 record_once 上、只有 blueprint 真被掛上才觸發 → 「不掛路由」與「拿得到 ctx()」成了綁死的二選一，宿主端補不出來。 jedi-survey 已於 0.1.1 單獨修好（user 裁 A 案）；其餘七支仍有同款缺口 （iam／file-upload／detection／notification／system-menu／issue／log），現無 socket 模式使用場景故不發作，裁定併 CM-1497 當 D6 契約統一補齊。修法照抄 monorepo 28e8be3 （約 4 行＋兩條契約測試），語意須與 record_once 一致＝無條件覆寫、最後一次贏。