用 FR-158 剛做好的 SEMI E187 框架，在 DEV 做一組可以拿去 demo 的完整資料：一間虛構的半導體設備商、它要送驗的一個設備型號、顧問跟它談好的導入方式、一份填好的 SSP、照 Excel「查核文件準備清單」寫出來的程序書與技術文件、每條查核步驟的現況說明，以及上傳到專案任務裡的證據（文件、截圖、圖片、日誌）。
做法照 FR-138 CRA 自評那套已經跑通的流程：下載框架版本的空白 SSP 樣板 → 用腳本填好 → 「從 Excel 建立」一次建出資源庫 → 匯入後填設備型號表單 → 起專案 → 逐任務上傳證據與評論。專案停在規劃階段，不啟動稽核、不產系統缺失與結案報告（決策者 2026-10-22 裁：做到產證據為止）。
SEMI E187 查的是「設備型號」，送驗的是設備製造商，不是晶圓廠。 規範 1.3.3 定義申請者是「對設備具設計或出場設定控制權之設備製造商、代理商」，第 4 章查的是設備編碼規則與出場品管，晶圓廠拿不出這些東西。建庫預設也是照「設備商自評、送驗前準備」做的（FR-158 D4）。
所以「晶圓廠有幾台設備要過 SEMI」實務上是這樣運作：晶圓廠在採購規格裡要求設備商提出 E187 驗證，設備商準備文件送檢測實驗室。
我的建議（情境 A）：虛構一家台灣本土半導體設備製造商，它的電漿蝕刻機要賣進晶圓廠，晶圓廠採購要求 E187 驗證，所以請顧問導入。這跟規範和建庫預設完全對得上，demo 時每一條都說得通。
另一個選項（情境 B）：照字面做晶圓廠。晶圓廠把每台進廠設備當受評標的，自己做進廠查核。問題是第 4 章三條（編碼規則、出場品管）晶圓廠只能記「向設備商索取」，5.5 弱點掃描、5.8 系統強化說明也都是設備商的文件，demo 起來會變成「晶圓廠一直在跟供應商要東西」，而且跟系統建庫預設的角色不一致。
請決策者選 A 或 B。以下內容以 A 寫。
| 項目 | 內容 |
|---|---|
| 公司 | 鈞拓精密設備股份有限公司（JunTuo Precision Equipment，虛構） |
| 地址 | 新竹科學園區研發三路 18 號 |
| 規模 | 員工約 420 人；做蝕刻與沉積設備，客戶是台灣與日本的 12 吋晶圓廠 |
| 為什麼導入 | 主要客戶（虛構「晶辰半導體」）2026 年新採購規格要求：2027-Q1 起進廠設備須取得 SEMI E187 驗證 |
| 顧問 | 虛構「恆鑑資安顧問」，兩人小組 |
| 檢測實驗室 | 虛構「台灣設備資安檢測實驗室（ISO/IEC 17025）」 |
| 項目 | 內容 |
|---|---|
| 型號 | JT-EP700 |
| 設備 | 12 吋電漿蝕刻機（Plasma Etcher），四腔體 |
| 內部運算節點 | 機台主控電腦（Windows 10 IoT Enterprise LTSC 2021，EOL 2032-01）、腔體製程控制器（嵌入式 PLC）、HMI 觸控面板 |
| 聯網 | 有：SECS/GEM（HSMS，TCP 5000）連工廠主機、遠端維護 SSH（預設關閉、維護時開）、時間同步 |
| API | 無；對外只走 SECS/GEM。示範 5.10.2「不支援 API，於查核文件中記錄」那條路 |
| 型號編碼 | JT-EP700-<腔體數>-<射頻規格>；主型號 EP700 決定資安功能，次型號（腔體數、射頻規格）不影響 → 4.2 以主型號送驗 |
一個型號一份查核，系統上就是一個資源庫、一個專案，受評標的就是 JT-EP700。
預計查核結果（刻意做出有符合、有不符合，demo 才有缺失可看）：
| SSP 分頁 | 內容 |
|---|---|
| 基本資料／受評標的 | 鈞拓、JT-EP700；建庫表單：設備型號、申請者、作業系統與版本、EOL、LTS、聯網、對外介面、API、查核基準日、檢測實驗室 |
| 負責單位 | 研發處、品保處、資訊安全室、製造處、恆鑑資安顧問、檢測實驗室 |
| 責任人員 | 約 8 人（虛構姓名，含申請者窗口、研發主管、品保主管、資安工程師、顧問兩人） |
| 設備資產 | JT-EP700 內部三個運算節點：機台主控電腦、腔體製程控制器、HMI 觸控面板 |
| 系統資產 | 機台主控軟體 JT-EtchCtrl v4.2、製程配方管理、SECS/GEM 模組、HMI 程式 |
| 系統依賴元件 | Windows 10 IoT LTSC 2021、.NET 6、OpenSSH、OpenSSL、Microsoft Defender、SQL Server Express |
| 適用控制項 | 15 條控制項的狀態與現況、31 個 AO 的狀態／現況／缺失／建議、每個 AO 一個任務（名稱、描述、指南） |
| # | 文件（Excel 清單） | 怎麼產 | 格式 |
|---|---|---|---|
| 1 | 設備編碼規則 | 新寫：鈞拓型號命名規則（主型號／次型號／哪一層變動影響資安功能） | docx 程序書 |
| 2 | 設備出場品管作業相關文件 | 新寫：出場品管程序＋資安出場檢查表（帳號、網路、強化、日誌四類） | docx 程序書＋xlsx 檢查表 |
| 3 | 設備規格文件 | 新寫：JT-EP700 規格書（硬體、OS、軟體版本、聯網功能） | docx（含架構圖 png） |
| 4 | LTS 證明文件 | 清單標○（如需）；Windows 10 IoT LTSC 2021 EOL 2032-01，距基準日超過 12 個月，5.1.3 即符合，不需要 | — |
| 5 | 安全性更新程序 | 新寫：作業系統安全性更新程序（相容性、相依性、效能、副作用四段，對 5.2 Note1） | docx 程序書 |
| 6 | 設備操作手冊 | 新寫：操作手冊節錄（聯網功能章、遠端維護章） | docx |
| 7 | 設備安全指南或使用者文件 | 新寫：JT-EP700 Security Guide（網路組態、反惡意軟體、強化、帳號、日誌各章，對 5.4／5.7～5.12） | docx |
| 8 | 設備弱點掃描報告 | 模擬：弱點掃描報告（工具與版本、範圍、日期、CVSS 分級、高風險一筆＋緩解） | |
| 9 | 弱點管理機制說明 | 新寫：弱點管理程序（分級、修補時限、緩解簽核） | docx 程序書 |
| 10 | 惡意軟體掃描報告 | 模擬：Defender 全機掃描報告（版本、病毒碼日期、結果 0 偵測） | |
| 11 | 惡意軟體掃描管理機制說明 | 新寫：惡意軟體防護程序 | docx 程序書 |
| 12 | API 相關技術文件 | 清單標○（如需）；JT-EP700 無 API，不需要，在 5.10.2 現況記「不支援」 | — |
| 13 | 設備 LOG 紀錄檔 | 模擬：Windows 事件記錄匯出（4624 登入、4720 建帳號、4719 稽核原則變更、7031 服務錯誤）＋設備軟體 log | csv／txt |
另外用 FR-158 已有的「系統強化說明範本」填成 JT-EP700 版（對 5.8），以及兩張截圖型證據（帳號管理畫面、防火牆規則畫面），用程式繪製的畫面，不拿任何真實系統截圖。
程序書格式照 FR-138 docs/01～05-*.docx：封面、文件管制表、核准欄、各節「依據」。畫面與文件上不標「示範」「虛構」字樣（決策者 2026-10-22 裁：demo 時很突兀）；虛構這件事只記在本資料夾 README 與 Notion 卡。
| 批 | 卡 | 做什麼 | 改哪 | Model／Effort |
|---|---|---|---|---|
| 1 | A 情境與 SSP 內容 | 寫情境設定檔（公司、設備、人員、時程、分工）＋15 條／31 AO 的狀態、現況、缺失、建議、任務三欄；下載框架版本空白樣板、填 Excel、從 Excel 建立（一次建庫）、填設備型號表單、起專案 | docs/features/FR-159-…/tools/semi-ssp-excel/（照 FR-138 ga-ssp-excel 形狀）；DEV 資料 |
opus／high |
| 1 | B 程序書與技術文件 | 5.2 表的 13 項＋強化說明，docx／pdf／xlsx／csv／png | docs/features/FR-159-…/demo-docs/、產生腳本 |
opus／high |
| 2 | C 上傳證據與評論 | 依 A 的任務對照把 B 的檔逐任務上傳（evidence_type 大寫 FILE、上傳後 DB 核 file_id）、寫評論；不符合項寫在評論判定段，不開系統缺失 |
DEV 資料；上傳腳本放 tools/ |
sonnet／medium |
| 3 | D 收尾驗收與 demo 腳本 | 實際登入走一次 demo 路線、截圖、寫一頁 demo 導覽（先看哪裡、講什麼） | docs/features/FR-159-…/demo-guide.md |
sonnet／medium |
A 與 B 可同時做：A 只寫 SSP 內容與 DEV 資料，B 只產文件。C 要等 A 的專案與任務建好、B 的檔案齊了才能上傳。
全部照首腦建議（決策者 2026-10-22 裁）：
卡片：母卡 CM-3021；第 1 批 CM-3022（A SSP 與 DEV 建庫）、CM-3023（B 文件）；第 2 批 CM-3024（C 上傳）；第 3 批 CM-3025（D 走查與導覽）。