FR-047 全站終驗(正確性+內容掃描)— 執行交接(2026-07-06)

項目 內容
緣由 量產 47 頁+拆分重整+wireframe+NAV 對齊產品選單全部完成後,user 下令:全站掃一遍正確性與內容 → 給修正建議 → 修正 OK 後做 skill 等收尾。這是「量產總驗收 gate」前的最後品管
branch main不切 branch;working tree 目前乾淨——除 FR-046 的本機 docx/zip 不要碰)
模型分配 主導/仲裁 = 本 session(Fable 或 Opus)逐頁掃描 = Sonnet subagent ×N 並行;機械驗證 = script 不用模型
接手前必讀 本檔全文 → .claude/skills/writing-feature-specs/SKILL.md(紅線與事實來源紀律的原典)
預估 1 個 session(掃描並行 ~30-60 分鐘 + 仲裁修正)

🧭 原始需求(WHY,先懂再動)

FR-047 spec 手冊(docs/specs/v1.8.0/,76 頁:67 內容頁+8 領域總覽+README)是給工程師的 living truth。量產期間多 session / 多 agent 並行產出,已知風險:agent 誤報與 schema drift(例:agent 說表叫 oscal.ssps 實際是 system_security_plans)、跨頁不一致(術語/數字/角色定義)、拆分重整後的引用殘影(hub↔︎子頁、退役頁)。本棒的任務是最後一次系統性品管:找出「spec 寫的 ≠ code/DB 實際」與「頁與頁互相矛盾」的地方,仲裁後修正,然後做收尾。

成敗關鍵不是掃得多,是仲裁得準——歷史上這類 audit 的 findings 有相當比例是誤報(見 §4 仲裁紀律的實際案例)。流程鐵則:掃描 agent 只報不改;每條 finding 主導開 code 復核後才准修

§0 冷接自檢(動手前先答)

  1. 事實來源三件套是哪三個?→ FE/BE code 實掃、scripts/deliverables/out/db_schema.json(表結構唯一真相)、out/routes.json(endpoint 唯一真相)
  2. 掃描 agent 可以修檔案嗎?→ 不行,只回報 findings;修正一律由主導仲裁後執行
  3. routes.json 有什麼已知 artifact?→ Flask-RESTful add_resource 多路徑註冊會產生雙路徑條目——spec 只寫其中一條不是錯(曾有 agent 因此誤判 FAIL)
  4. 可以 commit / push 嗎?→ 修正按批 commit(顯式 git add 檔名);push 永遠等 user

§1 機械驗證層(script,主導自跑,先做)

cd ~/Projects/Billows/Audit-Manager/compliance-manager-be

# 1. build 全綠(含 NAV 覆蓋安全網:有「⚠️ nav 未涵蓋」即 FAIL)
python3 scripts/deliverables/render_html.py "docs/specs/v1.8.0" 2>&1 | grep -vE "^✅" 

# 2. 敏感資訊 + 禁用語(應全為 0)
grep -rEln "192\.168\.|Billows@|password\s*=\s*[^<\s]" docs/specs/v1.8.0 --include="*.md" --include="*.svg" --include="*.dot" | grep -v html/
grep -rln "GRC 系統" docs/specs/v1.8.0 --include="*.md" | grep -v html/
grep -rlnE "質量|信息安全|服務器|數據庫" docs/specs/v1.8.0 --include="*.md" | grep -v html/   # 簡中殘留

# 3. 斷圖/引用資產未進版(python,兩者應為 0;注意 ../ 路徑要 normpath 再比對)
#    掃所有 md 的 ![](...):目標檔存在?git ls-files 有追蹤?

# 4. 粗體殘留(掃 build 出的 html main content、排除 pre/code 與 svg text,應為 0)

# 5. wireframe 覆蓋:67 內容頁每頁至少 1 處 "wireframe"(應 67/67)

# 6. 內部 .md 連結有效性:掃所有 [text](xxx.md#anchor),目標檔存在+(有 # 時)從 build 出的
#    html 反查 anchor id 存在(曾修過 slug 帶數字前綴、/→-- 的坑)

第 3/4/5/6 條的 python 檢查邏輯在前次協調 session 都寫過(tracker「協調收口」列有紀錄),照寫即可。全綠才進 §2;有紅先修機械層。

§2 逐頁內容核實層(Sonnet fan-out,只報不改)

分批(9 隻,一群一隻;大群可再拆)

Agent 範圍 頁數
1 project-management/ 全部 17
2 audit-execution/ 全部 8
3 evidence/ 全部 10
4 compliance-framework/ 全部 9
5 system-admin/(tenant/dept/user 群/role+menu/is/device/background) 10
6 system-admin/(smtp/notify/ldap/user-log/issue-integrate/tool-plugin)+auth/ 3 9
7 survey/ 4+collab/ 3 7
8 reporting/ 3+shared-components/ 1+README 5
9 跨頁一致性專職(見下) 全站橫切

每頁紅線 checklist(agent 1~8 的 prompt 核心)

對認領的每一頁:

  1. §6 endpoint 逐條對 out/routes.json:method+path 存在?(注意 §0 自檢 3 的雙路徑 artifact——routes 有而 spec 無的,先確認不是同 Resource 的別名路徑再報)
  2. §9 表名/欄位抽 3 表對 out/db_schema.json:schema 前綴(compliance/oscal/public/survey)、欄名、型別
  3. error code 抽 3 個開檔驗common/code/*_error_code.py 或 jedi-* 套件內(EC_/AUTH_/LOGIN_/SURVEY_ 前綴各有家)
  4. §1.1 功能總覽抽 3 項對 FE:宣稱的 UI 元素/元件檔存在?(~/Projects/Billows/Audit-Manager/compliance-manager-fe/src/
  5. 內部連結與引用:hub↔︎子頁互指正確、姊妹頁交叉連結、_overview §N 引用的節真的在講那件事
  6. wireframe 與內文一致:圖上標的 API 在該頁 §6 有;圖上區塊與 §1.1 對得上
  7. 用語:產品名 Guidant AI、禁晶晶體(動詞英文)、正式技術文件體
  8. §12 坑寫的是事實不是推測(標「待確認」的除外)

Findings 回報格式(強制,每條一列)

| 頁面 | 節 | 嚴重度(A事實錯誤/B不一致/C風格) | spec 宣稱 | 實際(含證據路徑:行號) | 建議修法 |

agent 鐵則(寫進每個 dispatch prompt):只讀不寫;不 spawn 子代理;不跑 render_html;查無不代表錯——找不到證據就標「待仲裁」而非 FAIL;每頁最多花 10 分鐘,超過就記「本頁未完成核實」。

Agent 9(跨頁一致性,可用 Opus)

  • 角色定義只准在 _overview 一份,各頁只速覽+引用——抓「頁內自建定義」
  • 跨頁數字一致:模組數、表數(161)、endpoint 數(563)、七態狀態機、5 種實作狀態等在不同頁的說法
  • hub 的 §1.1「詳述」欄連結指到的子頁真的涵蓋該功能
  • 退役頁殘影:project-settingsnotify-smtp-configevidence-classification-reports 不應再被任何頁引用
  • README 首頁是否純讀者側(禁生產 meta:wave/量產/待補字眼)

§3 仲裁與修正(主導)

  1. 收齊 findings → 逐條開 code/dump 復核,標 CONFIRMED / 誤報 / 待 user 決策
  2. 已知誤報模式(歷史實例,先套再判):routes.json 雙路徑 artifact;docs/system-design/*/tbls/ 文件 drift(以 db_schema.json 為準,不是 spec 錯);死碼 error code(如 SURVEY_409003)被當成「spec 漏寫行為」;FE 死檔(UserForm.vue,live 是 UserMTRBACForm)
  3. CONFIRMED 的修正按功能群批次 commit(顯式 add);安全類發現只記錄進該頁 §12、不修 code(修 code 是另開 FR 的事)
  4. 全修完重跑 §1 機械層全綠

§4 收尾(修正 OK 後做;user 已預先授權「OK 的話更新 skill 等」)

  1. writing-feature-specs skill 更新
    • SKILL.md 補「NAV 登記規範」:群=產品選單群(public.ui_routes)、樹=畫面容器關係(NAV 遞迴巢狀)、跨群 重複掛、檔案路徑與 NAV 解耦(新頁 = 檔案進功能群資料夾 + NAV_STRUCTURE 掛對位置)
    • 8 步流程的 build 驗證步補:「build 會清 html/ 重產;側欄收合為內建行為」
    • 若本次終驗抓到系統性錯誤模式(如某類 schema drift),濃縮成紅旗加進「紅旗」節
  2. tracker:終驗結果一列(findings 總數/CONFIRMED 數/修正 commits)+「量產總驗收」gate 列改成「終驗完成,等 user 驗收」
  3. memory:若有跨 session 可複用的教訓(誤報模式、audit 方法論)寫 feedback_*.md+MEMORY.md 索引
  4. :POC rsync 部署、對話歸檔、Notion 等其他收尾動作等 user 明確下令

§5 不在本棒 scope(別順手做)

  • 43 頁 §5 截圖待補(需 STG+playwright 批拍,另排)
  • 章節連結化 ~1,004 處+§6 API 格式一致化(user 拍板定版時一次處理)
  • 安全 findings 修 code(只記錄)
  • FR-046 交付文件(已 CLOSED)
  • push(等 user)

§6 給 fresh session 的啟動 prompt(user 複製貼)

請執行 FR-047 全站終驗。先讀
docs/features/FR-047-2607-feature-spec-handbook/handoff/2026-07-06-final-audit-handoff.md
全文,答完 §0 冷接自檢再動手。流程:§1 機械驗證(script 自跑)→ §2 Sonnet ×9 並行逐頁核實
(agent 只報不改,findings 表格格式回報)→ §3 逐條仲裁(先套已知誤報模式)→ CONFIRMED 修正
按群 commit → §4 收尾(skill 更新+tracker;其餘等我下令)。
不切 branch、顯式 git add、push 等我指示。