本卡屬 FR-114 資安修正（母卡 CM-2019），第 5 批子集 B 卡 5B-2，修 SUMMARY #79／#80／#81（出自 M03-5／M03-6／M03-7）。中。修法規格來自內化卡 CM-1993，計畫在 docs/features/FR-114-2609-security-fix-dispatch/batches/plan-b5B.md「卡 5-B2」段。
#79：弱點掃描「工具設定」頁的「測試連線」按鈕，要連到哪台主機是呼叫者在請求裡直接指定的——客戶內網裡的代理程式因此變成只要登入就能用的任意連線跳板，回應訊息的差異（連得上／連不上／逾時）還能拿來一台一台探測客戶內網有哪些機器開著哪些服務。
#80：掃描基準版本列表上的「手動重新解析」，每收一次請求就開一條背景工作，把最大 50MB 的檔整包讀進記憶體、再開一支最長 15 分鐘的外部程式，沒有同時執行上限、也不檢查這一版是不是已經在跑——連打幾百次就是幾百條同時存在，同一台機器上所有客戶一起變慢。
#81：某張稽核任務上換掃描工具，攻擊者先綁一支不設台數上限的工具、把掃描範圍填成一個超大網段；再送第二次更新只換工具、不帶範圍——守門只檢查「這次有送的值」，底層是「沒送＝不要動舊值」，於是舊的超大範圍原封不動跟到新工具底下。按下執行時系統把網段逐台展開，一個大網段展開是 1,677 萬台，記憶體瞬間吃爆、服務當掉。
首腦核對：
/Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/<套件目錄>（branch fix/security-b1）改，只動自己那支套件的子目錄、只 git add 該子目錄下的檔。 本卡對應 jedi-detection，worktree 建議 wt-fix-b5-detection-limits。與 5B-1 同套件但動的檔案零重疊，可平行，各自顯式 git add。jedi-detection/jedi_detection/app/service/detection_tool_service.py:224 測試連線目標主機由呼叫者自己指定，#79 核心
jedi-detection/jedi_detection/app/service/detection_profile_extraction_service.py:97 STATUS_RUNNING="running" 既有狀態常數，#80 要用它不要另立
jedi-detection/jedi_detection/app/service/detection_profile_extraction_service.py:178 retry()，重抽入口
jedi-detection/jedi_detection/app/service/detection_profile_extraction_service.py:180-182 docstring，解釋「先壓回 pending 再排」的原因（前端輪詢觀感）
jedi-detection/jedi_detection/app/service/detection_profile_extraction_service.py:184-195 docstring，解釋既有的 SYSTEM scope 守門
jedi-detection/jedi_detection/app/service/detection_profile_extraction_service.py:198-199 既有守門，不要動：if version.scope=="SYSTEM" and not viewer_is_platform_admin(): raise ForbiddenError
jedi-detection/jedi_detection/app/service/detection_profile_extraction_service.py:202-203 self._write_status(PENDING) 緊接 self.schedule(...)，新判斷必須放在這之前
jedi-detection/jedi_detection/app/service/detection_profile_extraction_service.py:357 _mark_pending_for_outdated_source()，來源檔變更時的自動重抽路徑，需查會不會也排背景工作
jedi-detection/jedi_detection/app/service/detection_profile_extraction_service.py:433 _prepare()
jedi-detection/jedi_detection/app/service/detection_profile_extraction_service.py:463 running 狀態寫入點
jedi-detection/jedi_detection/app/service/detection_profile_extraction_service.py:472 running 狀態寫入點
jedi-detection/jedi_detection/app/service/detection_job_binding_handler.py:201-204 第一個入口，#81
jedi-detection/jedi_detection/app/service/detection_job_binding_handler.py:331-333 第二個入口（兩入口對稱，都要補）
jedi-detection/jedi_detection/app/service/detection_orchestration_service.py:519 _expand_scan_target_fields() 起點
jedi-detection/jedi_detection/app/service/detection_orchestration_service.py:533-536 docstring，明文記載「這裡刻意不擋」，改動時要一併更新這段文字
jedi-detection/jedi_detection/app/service/detection_orchestration_service.py:555 expand_spec() 呼叫點，全套件唯一呼叫點
jedi-detection/jedi_detection/common/scan_target_spec.py:16,177,224 expand_spec 定義與註解（唯讀參考）
jedi-common/jedi_common/.../base_repository_impl.py:424 「沒送不覆蓋」共用語意，只讀理解不要改這支
STATUS_RUNNING 常數，:97／:463／:472）＋ 總量上限。關鍵順序：新判斷要放在 :202（壓回 pending）之前，否則永遠看到 pending、擋不到任何東西。新判斷也要放在 :198-199 既有守門之後（先判「你能不能重抽」再判「現在能不能再排一條」），回應照既有的 raise 形狀，不要靜默 return。被拒絕時前端要看得懂「這一版正在解析中」，不要退回「按了沒反應」的觀感問題；若查到要動 FE，回寫、不自己跨 repo 改（D-b5B-2 已裁定）。另外要查一次 _mark_pending_for_outdated_source()（:357）會不會也排背景工作，查到會就一併擋、查到不會在 commit message 寫「已確認此路徑不排工作」。detection_job_binding_handler.py:201-204 與 :331-333）都要補，這是兩入口對稱的典型形狀。展開網段前再加一道很寬鬆的總數上限當保險（例如 65,536 台），純粹擋離譜值；改這段時要一併更新 _expand_scan_target_fields() 的 docstring（:533-536），否則下一個人讀到「這裡不擋」會誤以為新加的上限是誤加而拿掉。