本卡屬 FR-114 資安修正（母卡 CM-2019），第 3 批「刪除沒人用的」卡 3-3，修 SUMMARY #116／#117（出自 M04-common）。中。SUMMARY 標「裁定刪除」，查無獨立內化工單；修法規格來自本批查證，計畫在 docs/features/FR-114-2609-security-fix-dispatch/batches/plan-b3.md「卡 N-3」段。
問題是什麼（白話）
#116：一支檔頭自己就寫明「不是產品程式碼」的開發用小工具，會跟著出貨套件裝到客戶機器上。#117：一個每次連線都會被設定、但全系統沒有任何地方讀它的開關，留著會讓後人誤以為「這裡已經有部門層級的檢查」而不去補真正需要的。兩件都查證過是零引用。
首腦核對：
- #116：jedi-jedi-common/jedi_common/utils/gen_comment.py（106 行），檔案自己的 docstring 就寫「不是產品程式碼」；零引用驗證涵蓋整個 monorepo（只有 3 個 hit，全是 README／pyproject／自己錯誤訊息裡的自我引用）、主專案（0）、FE（0）、測試專案（0）、License Center（0）；沒有宣告 console_scripts 進入點
- #117：jedi-jedi-common/jedi_common/session/database/db.py:185-187 的 app.can_manage_orgs RLS 設定碼，在 session_scope() 的「有身分」分支裡無條件執行，但全系統零讀者。對照「正確」的活手足寫法 set_can_read_all_orgs()（:81-86，有條件才呼叫，被 scripts/init/02-schema.sql 5 條 policy 讀取：:24730／:25072／:25174／:25700／:25944）
工作區
- 套件側：在 /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/jedi-common（branch fix/security-b1）改，只動自己這支套件的子目錄、只 git add 該子目錄下的檔。
在哪裡
jedi-jedi-common/jedi_common/utils/gen_comment.py 整支刪除（106 行，開發用小工具，檔頭自己寫明不是產品程式碼）
jedi-common/pyproject.toml:31 刪 ai = ["openai (>=2.8.0,<3.0.0)"] 這個 extra
jedi-common/pyproject.toml:29 刪對應的說明註解
jedi-common/README.md:66 更新，移除對 gen_comment 的說明
jedi-jedi-common/jedi_common/session/database/db.py:185-187 刪 app.can_manage_orgs 這段死開關（app.user_id :181-184 與 app.is_super_admin :196-199 是緊鄰的活線，絕對不要連著刪掉）
docs/claude/database-schema.md:1024 提到 can_manage_orgs 的文件，更新
docs/system-design/database/RLS_DESIGN.md 提到 can_manage_orgs 的文件，更新
docs/system-design/scripts/generate_db_schema_docx.py（约 :2069 附近） 🔴 這是程式碼不是文件，要真的改程式邏輯，不是改文字
docs/交付文件/v1.8.0/src/doc-03-database/07-rls.md 提到 can_manage_orgs 的文件，更新
怎麼修
- ① #116：刪除 gen_comment.py 整支檔案；pyproject.toml 移除 ai extra（:29-31）；更新 README.md:66 移除對它的說明。順手檢查 BE scripts/build/ 有沒有專門排除 gen_comment／openai 的打包邏輯（先查再寫——若查無此邏輯就只做套件側 3 項，不用另外改 BE build 腳本）。
- ② #117：刪除 db.py:185-187 這段 app.can_manage_orgs 設定碼。🔴 陷阱：緊鄰的 app.user_id（:181-184）與 app.is_super_admin（:196-199）是全系統 RLS 都依賴的活線，刪錯行會讓所有 RLS 查詢壞掉（症狀是全部查詢變空、或看到其他租戶資料）——動手前先用 Read 工具把 :175-205 這段完整讀一次，確認只刪 185-187 三行。
- ③ 更新 5 個提及 can_manage_orgs 的文件位置，其中 docs/system-design/scripts/generate_db_schema_docx.py 是程式碼（產生 DB schema DOCX 的腳本），要真的修邏輯讓它不再產出這個死欄位的說明，不是單純文字修改。docs/features/FR-080.../inventory/host.md:244（歷史紀錄）與任何 FR-085／資安掃描彙整檔案（掃描報告，屬歷史證據類）明確不動。
手測
- 本機：套件重新解析依賴（poetry update jedi-common 或等效指令）→ 期待乾淨解析，移除 gen_comment 與 ai extra 後不報錯
- DEV：BE 啟動（python main.py）並登入一次 → 期待正常（任何 DB 存取都經過 session_scope()，若登入後失敗或所有查詢都變空，代表刪錯行）
- DEV：打開兩個原本有資料的列表頁 → 期待資料正常顯示（驗證 RLS 沒被破壞；症狀是「全部變空」或「看到別的租戶資料」代表誤刪 app.user_id 或 app.is_super_admin）
- DEV：跑 pytest test/test_module_boundaries.py test/test_iam_wiring.py 通過
做完要回寫報告