FR-161 一頁看完

1. 顧問訪談前請客戶準備的資料（網路架構、組織架構、資產盤點、政策文件與程序書）在系統裡有一頁事前準備資料，就是一個能上傳的地方：客戶把檔案丟進大類格子，可上傳新版、舊版留著，點名稱就能預覽。同名檔（去掉版次與日期後相同）上傳時會問要不要當新版。不做審閱、留言、通知。
2. 大類跟著公司、在「系統設定 ／ 事前準備資料大類」管：系統出貨四個起始值，增刪改名只影響這家公司；事前準備資料頁與程序書池只讀這份；沒有子項目、必填、截止日。
3. 檔案屬於公司，不屬於任何框架；入口掛在合規資源庫列表。顧問在資源庫「程序書池」tab 按「從事前準備資料選用」挑選引用，選了的才進這個資源庫（不多開 tab，只重新設計這一個），「移出」拿掉；已引用的跟著客戶的新版更新。第二個框架不用客戶從頭再傳，顧問挑一次即可。
4. 事前資料區永遠可更新；稽核開始那刻才給稽核輪一份鎖住的副本；被副本引用的檔不能刪只能標過時。
5. 像但不做：把事前資料做成專案任務（事前準備不屬於任何評估目標）；做成不綁資源庫的獨立模組（與資源庫幾乎一對一）；顧問審閱（決策者裁太複雜，等系統更完善再補）。

• 2026-10-23 決策者提出需求：顧問開會前請客戶上傳事前準備資料，顧問看過再訪談，訪談完才做 SSP。
• 2026-10-23 決策者裁：分類只到大類、可彈性增加，顧問只是進來看看；要另開介面，客戶不進 SSP 畫面。
• 2026-10-23 決策者裁：掛資源庫，但要考慮同一家公司未來導入其他框架也能引用；問 OSCAL 上放哪。首腦答：檔案存公司層、引用那刻才進 OSCAL back-matter／diagram；決策者追問「顧問要再挑一次就多一道工」，改為依分類預設全部帶入、只有反向排除。
• 2026-10-23 決策者看過「小美與老王」使用情境後說 OK，令寫討論稿與雛形。
• 2026-10-23 決策者裁 D2：四類都是附件，不分落點。D4 追問「導入期間會有人異動，應該持續更新，進稽核才鎖」，首腦確認與原意相同、改用白話重寫。D6 確認客戶與顧問都能刪，被稽核副本引用的才不能刪。
• 2026-10-23 決策者提出時效性問題（半年一年後資料更新要不要重傳），首腦提 D8「同一份資料上傳新版」，決策者接受。
• 2026-10-23 決策者裁不做顧問審閱：「太複雜了，可以有一個地方讓他們上傳就好；大多作業跟顧問綁，系統還不是很完善，慢慢再補」。原 D1／D3／D9 取消。
• 2026-10-23 決策者裁大類「跟著公司」（不是跟著系統）：「每個顧問的大類又會不同」。
• 2026-10-23 決策者看雛形問「by 公司怎麼只有一頁、哪間公司的」「SSP 附件怎麼沒照大類分」。首腦實查 DEV：資源庫與專案都帶 tenant_id，公司＝租戶、頂欄切換是既有機制；雛形補頁首公司名與頂欄租戶切換，附件區改照大類分段。
• 2026-10-23 決策者裁：「把原本的程序書那個 tab 重新設計就好，不要多一堆 tab 出來」；問大類在哪設定 → 首腦建議「系統設定」一頁，決策者 OK。雛形改成三頁：事前資料頁（無設定鈕）、程序書池 tab 重新設計、系統設定大類頁。
• 2026-10-23 決策者裁：大類設定頁用表格模式。首腦順手加「說明」欄（給客戶看的一句提示，選填），在雛形頁首列為待確認。
• 2026-10-23 決策者裁：事前資料頁頁首拿掉「目前整理：某資源庫」那行，原因是「會搞混」。決策者確認事前資料一間公司一份、不分框架，顧問管不同公司就是不同租戶。
• 2026-10-23 決策者裁：事前資料頁頁首的雛形註解、「顧問：」那行、「N 份資料」以及提示條全部拿掉。提示條拿掉後，「同一份資料要上傳新版」改成上傳時偵測同名檔並詢問。
• 2026-10-23 決策者裁：大類表格的「說明」欄與「下載全部（zip）」都留，令寫 design。首腦實查後定 D9：事前資料在每個可寫資源庫的程序書池各落一列（程序書池表加三欄，要動 jedi-compliance-audit），這樣既有的送審、存版、還原、複製資源庫四條複製路徑都會自動帶上。實查也發現兩個疑似既有缺口，都另開卡：FR-139 D19 稽核中鎖資源庫（CM-3047 盤點確認早已落地在 verify_module_frame_exists_by_uid(writable=True)，誤判來自 before_template_write 空掛點，已移除）；OSCAL back-matter 匯出是空的。
• 2026-10-23 決策者同意 D9，下令開卡。母卡 CM-3040、子卡 CM-3041～3048 一次建完。批次依「決策者何時看得到畫面」排：卡 4（畫面）排在卡 3（套件）之前。兩張既有缺口卡放最後一批。
• 2026-10-23 決策者裁：IT執行人員 自動拿「上傳」，不拿「管理大類」（DEV 實查 IT執行人員 沒有資源庫編輯權，照原規則傳不了）。已 append 到 CM-3041 卡尾，在派工前補上。
• 2026-10-23 決策者指出批次沒照依賴分（CM-3042 要等 CM-3041 卻同批）。首腦改照「同批可同時做、有先後放下一批、改同一個檔不同批」重排成五批；Notion Stage 欄位、母卡與各子卡卡尾都已補上。
• 2026-10-23 決策者看專案 1619 規劃頁（程序書管理被 13 份別家範例塞滿、且不能上傳）後改判 D6：改成顧問挑選引用，不再預設全部帶入。首腦說明專案頁不能上傳是 FR-139 原本就有的唯讀規則。開修正卡 CM-3050；同名比對放寬一併列在卡上待決策者裁。另：「事前資料」改名「事前準備資料」、檔案可預覽、點名稱開預覽、範例重做成虛構公司宏碩精密的完整文件。

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

需求與討論

設計

prototype/（3 份）

其他文件

交接與收口時間軸（handoff/，3 份）

由新到舊。每份是某一棒次交接當下的完整現況快照，看某個時間點「當時知道什麼」請從這裡進。

資產子資料夾（無文件，不建頁）：prototype/（2 個檔）

卡片內容（決策紀錄、驗收條件）以 Notion 為準，本頁只記座標。

相關需求：

• FR-139 — consultant-interview-ssp-fields-and-versions
• FR-147 — resource-library-task-guidance
• FR-160 — project-role-by-stage-and-feature