本卡屬 FR-114 資安修正（母卡 CM-2019），合回前的發版棒。決策者 2026-09-24 裁：發版在工作區做（掃描線還在讀主 checkout，主線合回等掃描結束）、只發套件不發產品本體、後端工作區建獨立 venv、188 全量 build 放行、四 repo fix/security-b1 已推 GitLab。本卡有不可逆步驟（推 Nexus），分四段，每段做完回寫、停下等首腦驗過再做下一段。

這一棒在做什麼（白話）

資安修正的程式改動分散在後端和 17 支內部套件（jedi-*）。後端已經用到套件的新功能，但後端的設定還指著舊版套件——開發期是靠「直接指向本機套件資料夾」繞過去的，這種設定不能交出去。所以要先把 17 支套件打成新版推上公司內部套件庫（Nexus），後端改成正式指向新版，確認後端在 DEV 起得來，最後在 188 打包機上完整打一次包，驗證三件只有完整打包才看得到的事。這不是對客戶的發版：產品本體版號、release note、安裝包都不動，等決策者總測過再說。

工作區（只在這些地方改，絕不碰主 checkout）

套件  /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security   branch fix/security-b1（HEAD f2d6e6a0）
BE    /Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/.claude/worktrees/wt-fix-security      branch fix/security-b1（HEAD fb6e03dd8）
四 repo 的 fix/security-b1 已推 origin（GitLab），188 拉得到。

🔴 主 checkout（compliance-manager-be 根目錄、jedi-python-package 根目錄）給資安掃描線讀，一個檔都不能動；主 checkout 的共用 venv（compliance-manager-be/.venv）也不能動——本機 8000 port 跑著用它的服務。

第一段：後端工作區建獨立 venv（可逆）

• 首腦核對：BE 工作區目前沒有自己的 .venv，poetry 設定 virtualenvs.in-project=true，poetry env info -p 從工作區跑會回主 checkout 的 .venv（共用）。共用 venv 裡有 12 個 .pth 指到套件工作區（jedi_ai_bot／ai_dashboard／common／compliance_audit／detection／file_upload／iam／issue／log／survey／system_core／task_platform）。
• 在 BE 工作區根目錄建自己的 venv：先 poetry env info -p 記下現況，再用與主 checkout 同一個 Python 版本（3.11）在工作區內建 .venv（例：python3.11 -m venv .venv 後 poetry env use .venv/bin/python），確認 poetry env info -p 改指工作區的 .venv 才往下。
• 這一段不 install——第三段改完 pin 再裝，避免裝兩次。
• 確認 .venv 在 .gitignore（git check-ignore .venv），不要被 add。
• 回寫：venv 路徑、Python 版本、poetry env info 前後對照。停下等首腦驗。

第二段：17 支套件 bump 版號＋抬依賴下限＋commit（可逆，未推）

首腦依「feature/review..HEAD 排除測試與 poetry.lock 後有沒有改程式」核過的 17 支與現行版號（全部等於 BE 主線 pin，代表這批改動都還沒發）：

jedi-common 1.2.0        jedi-iam 1.3.0           jedi-task-platform 1.1.1   jedi-file-upload 1.2.0
jedi-issue 1.2.0         jedi-survey 1.1.2        jedi-remote-agent 1.1.2    jedi-detection 1.1.0
jedi-log 1.2.0           jedi-ai-dashboard 1.2.0  jedi-integrity 1.1.0       jedi-bulletin 1.1.0
jedi-compliance-audit 1.1.3  jedi-asset 1.1.0     jedi-ai-bot 1.2.0          jedi-flow-engine 1.3.0
jedi-system-core 1.1.1

不發（只有 poetry.lock 入版控、程式沒變）：jedi-evidence-classification、jedi-license-runtime、jedi-notification、jedi-oscal-v2

• 版號一律 minor +1、patch 歸 0（例 1.2.0→1.3.0、1.1.2→1.2.0）。理由：這批有新功能介面（新守門、新 port、新回應欄位、jedi-common 拿掉 [ai] 選配），不是純 patch。只改各套件 pyproject.toml 的第一個 version = 行，別動 dependency 字串。
• 抬依賴下限（首腦 grep 查到三處，你要再全面 grep 一次補齊）：① jedi-survey 用到 jedi-task-platform 新的 participant/common/guard.py 守門（jedi_survey/app/common/task_survey_guard.py:24）→ survey 的 jedi-task-platform>= 抬到 task-platform 新版；② jedi-issue（app/feedback/service/feedback_service.py）與 jedi-log（api_log/common/utils/excel_util.py）用到 jedi-common 新的 jedi_common.utils.export_safety → 兩支的 jedi-common>= 抬到 common 新版。全面 grep 方法：對 17 支每支 git diff feature/review..HEAD 看新增的 from jedi_<別支> import，對到的被依賴方若也在 17 支內，下限就要抬。
• 每支 bump 後在該套件目錄 poetry build 一次確認打得出 wheel（不 publish），並跑該套件自己的 tests（帶 PYTHONPATH=<套件工作區>；已知 jedi-task-platform tests/participant 有 1 條 003-participant-rls.sql 既有失敗，與本批無關，其他失敗要回報）。
• 一個 commit 收齊 17 支 pyproject.toml（顯式 add 17 個檔），message 列 17 支舊→新版號與三處下限抬升。不 tag、不推。
• 回寫：17 支舊→新版號表、抬下限清單（含你 grep 多找到的）、build／測試結果、commit hash。停下等首腦驗——下一段不可逆。