dilab/audit

audit — 季度爬取

analysis 檢視儲存庫；audit 檢視訪客和爬蟲所見的內容：即時的 HTML、真實的狀態碼、重新導向、以及實際提供的網站地圖。它所發現的一切，若非轉化為待辦事項（由 fix 技能機械化地執行），就是歸入擁有者清單中那些不該由技能觸碰的事項（導覽列、版面配置、定價與法律頁面、主機託管）。它從不編輯文章，也從不發起 PR。

腳本：${CLAUDE_PLUGIN_ROOT}/scripts/{crawl,inventory,sitecheck}.js。設定 P=${CLAUDE_PLUGIN_ROOT}。

參數：--origin <url>（預設：來自 seo/brand.json 的 https://<domain>，否則為「Preview」行的主機）、--max <n> 頁面（500）、--external <n> 要檢查的外部連結（200）、--cwv（向 PageSpeed Insights 請求首頁和群集中心頁面；需要可連線至 googleapis.com，PAGESPEED_API_KEY 可選）、--no-items（僅供報告，不寫入待辦事項）、--dry-run（爬取並報告，但不提交任何內容）。

0. 前置條件

產品儲存庫根目錄；git status --porcelain 為空；位於預設分支；存在 seo/strategy.md 和 ## SEO agent 區塊。先執行 node $P/scripts/inventory.js --root .，以便爬取時能將路徑對應到檔案和類型。不需要 gh。

1. 爬取

PREV=$(ls seo/data/crawl/*.json 2>/dev/null | sort | tail -1)
node $P/scripts/crawl.js --root . --origin <origin> --max <n> --external <n> [--cwv] --save seo/data/crawl ${PREV:+--diff $PREV} --quiet

讀取 JSON：summary（頁面數、依代碼分類的發現結果、truncated）、findings[]（code、severity fix|report、path、file、msg、to）、sitemap（count、error、missing）、external[]、cwv[]、diff（與前次審計相比的 new、resolved）。頂層的 error 鍵或 sitemap.error → 回報並停止；網站若已關閉，這是擁有者的問題，而非待辦事項。truncated: true → 表示爬取已達到 --max 限制，並列出仍在佇列中的路徑。

然後也執行 node $P/scripts/sitecheck.js --root .：它會檢視原始碼（Blade 參數、路由、框架），這些是即時 HTML 所隱藏的資訊，兩者結合才能看到全貌。

2. 分類

三個類別，按以下順序：

1. fix 項目 — severity: fix 的發現結果（代碼為 title、description、canonical、alt、link、sitemap），且頁面的庫存項目中有 file 且類型為 guide、article 或 tool。每個頁面一個項目，格式與 analysis §1c 完全一致，但有兩點不同：- evidence: audit <date>: <n> findings 且每行 fixes: 結尾加上 (audit <date>)，這樣 fix 就知道要與即時網站確認而非 sitecheck：

   ### [B-nnn] fix: <path>
   - type: fix
   - target: <path>
   - score: <n> (potential <p> × ease 10 × fit <f>)      ← potential 為 3，或來自最新 seo/data/gsc 快照的頁面 gsc_potential；fit 來自群集優先級
   - evidence: audit <date>: <n> findings
   - status: open
   - fixes:
     link: internal link /old-path redirects to /new-path: link the final URL (audit <date>)
     description: no meta description (audit <date>)
   

   若頁面上已有狀態為 open/claimed/in-review 的 fix 項目 → 將新的 fixes: 行追加到該項目（若某行的代碼加上 to 已存在則跳過）。若頁面屬於某個狀態為 open 的 refresh 項目 → owned by B-nnn，不建立 fix 項目。若 sitecheck 也回報了相同的發現結果（相同頁面、相同代碼），則僅從審計中列出一次，並帶有 (audit <date>) 標記。
2. link 項目 — 文章頁面上的 orphan 發現結果：每個群集一個 link 項目（$P/skills/analysis/SKILL.md §1c 格式，- links: 行 /hub → /orphan (orphan, audit <date>)）；若某群集已有狀態為 open 的 link 項目，則將配對追加到該項目。若孤兒頁面沒有所屬群集（無對應的中心頁面），則歸入擁有者清單。
3. 擁有者清單 — 其他所有項目：broken-external、redirect-chain、duplicate-title/duplicate-description、noindex-in-sitemap、sitemap-404、thin、h1、mixed-content、slow、server-error，所有非文章頁面（首頁、定價、法律、版面配置）上的發現結果、sitemap.missing 以及 CWV 列。依代碼分組，最嚴重的優先，每種代碼最多 3 個範例路徑；若庫存已知，則標註檔案名稱。文章上的 thin 是重新整理訊號，而非 fix：請如此說明，交由 analysis 處理。

若使用 --no-items → 僅輸出類別 3，並統計原本會建立的項目數量。

3. 提交

除非使用 --dry-run：執行 git add seo/data/crawl/<date>.json seo/backlog.md 並提交 seo: audit <date> — <pages> pages, <findings> findings, <k> fix items, <m> link items 到預設分支（規劃檔案直接提交）；若分支有遠端追蹤則推送。不建立 PR。

4. 報告（不超過 15 行）

• audit <date>: <pages> pages crawled (<html> html, <truncated?>), <findings> findings (<fixable> fixable)；網站地圖 <count> 個 URL，<missing> 個遺失或失敗
• 依代碼分類的發現結果，一行一種，附上計數
• 與 <previous> 的差異：<new> 個新增、<resolved> 個已解決（若新增項目 ≤ 5 個則列出名稱）
• 項目：fix 的 ID 與路徑；link 的 ID 與群集；owned by / already open 的備註
• 擁有者清單：不超過 8 行，最嚴重的優先（導覽中的 5xx 錯誤或重新導向鏈比冗長的描述更優先）
• 使用 --cwv 時的 CWV 表格：路徑、LCP、CLS、INP、效能、來源
• 下一步：fix 會在星期五（或立即使用 /seo-agent:fix）執行項目；下一次審計將在 3 個月後進行

嚴格規則

• 對網站僅讀取：使用 seo-agent-audit 使用者代理進行 GET/HEAD，單一來源，--max 個頁面，請求間 --delay；絕不提交表單，絕不登入，絕不爬取其他主機
• 絕不編輯文章、版面配置或網站地圖；絕不發起 PR；僅寫入 seo/data/crawl/ 和 seo/backlog.md
• 待辦事項僅限於 fix 技能可以編輯的文章頁面；其他所有事項歸屬於擁有者
• 結果確定性：發現結果來自 crawl.js；絕不透過人工閱讀 HTML 來添加任何發現
• thin 永遠不是 fix 項目