FR-114.5C-8【驗證＋清理】密碼產生器少一碼——實際使用的那份已修好，查證並處理兩支零引用重複副本（SUMMARY #137，低／中）

本卡屬 FR-114 資安修正（母卡 CM-2019），第 5 批子集 C 卡 5C-8，查證並處理 SUMMARY #137（總表 §3.2-12）。低／中——實際使用中的那份已在 2026-09-16 修好，本卡是驗證＋清理零引用重複程式碼。計畫在 docs/features/FR-114-2609-security-fix-dispatch/batches/plan-b5C.md「卡 5C-8」段。

問題是什麼（白話）

密碼產生器原本設計要從 3 種固定字元類型（小寫、大寫、數字；第 4 種「標點符號」已被註解掉不用）各取一個字元當種子，再計算「還要補幾個隨機字元」湊到目標長度——但補幾個的計算公式還是照 4 種字元類型寫的，導致實際產生的密碼比設定值短一碼（例如設定要求 12 碼，實際只生出 11 碼），有時系統自動產生的密碼因此連自己訂的最短長度規則都過不了，錯誤訊息還會誤導成「使用者輸入有問題」，其實問題出在產生器本身。

⚠️ runner 開工前必讀（計畫作者已重新查證，與總表原始描述不同）：實際被使用的那一份——jedi-iam/jedi_iam/common/utils/common_util.py:67——已經修好，commit edc9118（「fix(iam): 帳號匯入改必填＋修密碼產生器少一碼（決策者 2026-09-16 指示）」），改成了 range(length - len(password))，同檔 :61-65 留有說明這個陷阱的註解。所以這件事在有呼叫者的路徑上已經不成立，還維持少一碼的是兩支零引用的重複副本：jedi-survey/jedi_survey/common/utils/common_util.py:23 與 jedi-log/jedi_api_log/api_log/common/utils/common_util.py:23（兩份都是逐字複製，連同一行被註解掉的標點符號程式碼都一樣），計畫作者已查證這兩份在各自套件內與主專案都零呼叫。已有前例：jedi-system-core 同名函式已在 CM-1699 因同樣「零引用」理由被刪除（jedi_system_core/common/utils/common_util.py:5 檔頭註解記錄此事）。

首腦核對：

jedi-iam/jedi_iam/common/utils/common_util.py:67 — 已修好：range(length - len(password))，commit edc9118
jedi-iam/jedi_iam/common/utils/common_util.py:61-65 — 說明此陷阱的既有註解
jedi-survey/jedi_survey/common/utils/common_util.py:23 — 零引用重複副本一，仍是少一碼的舊寫法
jedi-log/jedi_api_log/api_log/common/utils/common_util.py:23 — 零引用重複副本二，同樣仍是舊寫法（注意路徑多一層 jedi_api_log/）
jedi-system-jedi-system-core/jedi_system_core/common/utils/common_util.py:5 — 前例：CM-1699 已因零引用刪除同名函式

工作區

套件側：在 /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/<套件目錄>（branch fix/security-b1）改，只動自己那支套件的子目錄、只 git add 該子目錄下的檔。本卡對應 jedi-iam（僅查證，已修好不再動）＋ jedi-survey／jedi-log（處理零引用副本），worktree 建議 wt-fix-b5C-password-gen。

在哪裡

jedi-iam/jedi_iam/common/utils/common_util.py:51-71    已修好的版本，:67 是關鍵行，本卡只查證不再動
jedi-iam/jedi_iam/app/service/user_service.py:157    呼叫點一：generate_complex_password(12)
jedi-iam/jedi_iam/app/service/user_batch_import_service.py:102    呼叫點二：user_supplied_password or generate_complex_password(12)
jedi-survey/jedi_survey/common/utils/common_util.py:9-28    零引用重複副本一，:23 是 - 4 少一碼那行
jedi-log/jedi_api_log/api_log/common/utils/common_util.py:9-28    零引用重複副本二，:23 同樣少一碼（路徑含 jedi_api_log/ 這一層）
jedi-system-jedi-system-core/jedi_system_core/common/utils/common_util.py:5    前例：CM-1699 已刪除同名函式的檔頭說明
jedi-iam/tests/unittest/test_user_service.py:1095    jedi-iam 自己的測試有引用，不影響另兩支套件的零引用判斷

怎麼修

D-b5C-11（決策者已裁「刪除」，但需 runner 完成擴大查證後回報，不自行刪除——見下方）。

①（驗證） 打開 jedi-iam 的已修版本，實際跑一次產生 12 碼密碼，確認長度真的是 12（確認 edc9118 這個修復是真的生效）。
②（處理零引用重複副本） 決策者建議刪除這兩支重複副本，理由三點：原則十五「不留沒人用的東西——目前唯一無害的原因是沒人接，一旦有人接上就會憑空冒出一個有缺陷的入口」；jedi-system-core 同名函式已因同樣理由被刪除（CM-1699），做法要一致；留著＝「同一件事實有三份副本」，下次 jedi-iam 再被修一次，這兩支又會落後一次。🔴 但刪除需要決策者簽字放行——runner 先完成下面②的擴大零引用查證並回報，不要自行刪除。
③（擴大零引用查證，動手前必做） 計畫作者已對套件 monorepo（排除 .venv）與主專案 grep 過 generate_complex_password，jedi-survey／jedi-log 除了自己的定義行以外零命中。runner 動手前要再往外擴大查一輪，涵蓋 FE、agent repo、scripts/、以及各套件自己的 tests/（jedi-iam 的 tests/unittest/test_user_service.py:1095 確實有引用，但那是 iam 自己的測試，不影響另兩支套件是否零引用的判斷）。查完把結果（哪裡查了、命中幾筆）回寫本卡。
④ 刪除前也要確認這兩支套件的 __init__ 或對外 re-export 沒有公開曝露這個函式名稱。