產出落點：docs/security-report/M<NN>-<slug>.md（只寫 md，不要自己 build） 範本：docs/security-report/M01-remote-agent.md —— 動筆前先完整讀過這份 讀者：PM 與老闆（不懂程式），以及稽核方。不是工程師。
| 是 | 不是 |
|---|---|
| 決策者消化過、要拿去對客戶／老闆講的版本 | 原始技術報告的翻版 |
| 會被當成稽核證據（證明「我們確實檢視過」） | 內部施工紀錄 |
| 講「出事會怎樣、誰受影響、怎麼修」 | 講「程式碼哪裡寫錯」 |
原始技術報告保留在需求中心不動，不要改那邊任何檔案。
---
title: <中文模組名>
eyebrow: Guidant AI 資安檢視 · 模組報告
h1: <中文模組名>（<模組代號>）
lede: <一兩句：這塊做什麼＋這塊最值得知道的一件事>
---三到六句。讀者可能完全不知道這是什麼東西，要從「客戶會用到什麼功能」講起，不要從技術架構講。
如果這塊有「為什麼它是敏感目標」的理由（例如手上握有密碼、是所有功能的地基），用 ::: grid2 兩張卡並排：左邊「它平常在做什麼」、右邊「為什麼它是敏感目標」。沒有這種理由就不要硬湊。
開頭一行：
**檢視期間**：YYYY-MM-DD ～ YYYY-MM-DD｜**範圍**：N 個檔案（若有細分就註明）｜**共 N 輪**接一段引言，指向原始報告：
> **原始技術報告**放在需求中心的 [FR-0NN 站](https://guidantai-feature-doc.jedicotech.com/<資料夾名>/)，檔名見下表最後一欄。那裡有每一輪的完整技術細節、檔案清單與逐條推理，供需要深究或稽核抽查時查閱。然後一張表：
| 輪次 | 查什麼 | 檔數 | 覆核投票 | 結果 | 原始報告檔名 |
只要有任何一輪的覆核沒跑完整，就要加一個 ::: {.callout .warn} 說明：為什麼沒跑成、我們怎麼補的。不准隱瞞——誠實交代在稽核場合是加分的。
零發現的模組，這一段更重要——那頁的全部價值就在於證明「有查」。
排序：先按風險（最嚴重→高→中→低），同風險的把同一分類排在一起。
表頭固定：
| # | 問題 | 風險 | 分類 | 出事會怎樣（誰受影響） | 怎麼修 | 狀態 |
欄位規則：
🔴 **最嚴重** / 🟠 高 / 🟡 中 / ⚪ 低⬜ **未修**（有工單就附卡號）/ ✅ 已修（要寫怎麼修好的）/ ⚠️ 部分修（要寫改了什麼、還剩什麼）
docs/features/security-scan-consolidated/README.md §3 為準。那裡標了兩次複查結果（2026-09-16、2026-09-20），有 ✅ 已修 / ⚠️ 部分修 的就照抄⬜ **未修**，不要自己判斷若有「範圍外順手撈到」的發現，另起一張小表，並註明它們不屬於這塊。
每條一個 ## 或 ### 段落。只有最嚴重／高風險的需要完整展開，中低風險的一小段講完即可。
完整展開包含：
要決策者拍板的事項用 ::: {.callout .decided} 框出來，並把選項的優缺點做成表。
一個 ::: {.callout}（依嚴重度選 crit/warn/ok），內容：
後面接一張統計表：檢視輪數、通過的發現數、最嚴重幾條、已修幾條、已開工單幾張。
最後固定加：
---
| 你想知道 | 看哪裡 |
|---|---|
| 我們用什麼方法查、結果有多可信 | [檢視方法與工具](GUIDE-01-method-and-tools.html) |
| 其他模組的檢視結果 | [回總報告首頁](index.html) || 分類 | 什麼情況用 |
|---|---|
| 身分驗證缺失 | 根本不檢查對方是誰 |
| 只驗登入、不檢查歸屬 | 知道你是誰，但不問「這筆資料是你的嗎」 |
| 客戶資料沒隔開 | A 客戶看得到 B 客戶的東西 |
| 密碼外流 | 憑證已經在外面了（寫死、進版控、公開網站） |
| 敏感內容寫進日誌 | 密碼原文落在紀錄檔 |
| 回應夾帶不該送的欄位 | 多送了內部欄位出去 |
| 外部送什麼就收什麼 | 不驗輸入 |
| 防竄改機制被削弱 | 專用於 jedi-integrity 那塊 |
| 資源耗盡 | 一個人就能讓系統對所有人停擺 |
| 要先做產品決策 | 不是技術問題，是規則沒定 |
（實際十項，分類名照抄，不要改字。）
「白話」不是把句子講得口語，是讀者完全不需要技術背景就能懂。
| 不可以寫 | 要改成 |
|---|---|
| API / 端點 / route | 功能、入口、管道 |
| token / credential | 通行證、帳號密碼、金鑰 |
| RLS / tenant isolation | 客戶資料隔離 |
| middleware / decorator | （改講它做的事，例如「把關的那道檢查」） |
| repository / service 層 | （不要提分層，改講「負責取資料的那段程式」） |
| CVE / CVSS | （不要用，改講嚴重程度） |
| 研究員 / 檢查員 / 候選 / 驗證章 | 這些是方法章的術語，模組頁不要再提，直接講結果 |
| TLS 憑證驗證被停用 | 連線時沒有確認對方是不是真的那個網站 |
檔名與行號可以留（這是對內版，而且稽核要追得到），但不要讓它們出現在「出事會怎樣」那欄。
禁止的說法：
| 要什麼 | 去哪裡找 |
|---|---|
| 這塊做什麼、主要發現摘要 | docs/features/security-scan-consolidated/README.md §0.5 的「已掃完」表 |
| 每一輪查什麼、票數、結果 | 同檔 §1「逐輪掃描進度」，找對應 FR 的那幾列 |
| 每條問題的完整描述、風險、修法 | 同檔 §3.1（資安類）與 §3.2（非資安但真 bug），用 FR 編號搜 |
| 問題的目前狀態（已修／部分修） | 同上，§3 開頭有兩次複查結果，條目上直接標了 |
| 該模組的檢視期間、輪次細節 | docs/features/<該 FR 資料夾>/README.md 與 SUMMARY.md（若有） |
§3.2 的非資安項目也要收進來——它們不是資安問題但確實是 bug，分類用「要先做產品決策」或在表下另起一小節說明。
docs/security-report/M<NN>-<slug>.md 一個檔，不要碰別的render_index.py），統籌者統一做