# 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，主導自跑，先做）

```bash
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-settings`、`notify-smtp-config`、`evidence-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 等我指示。
```