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 前回の監査からの差分）。トップレベルまたは sitemap.error に error キーがある場合は、その旨を伝えて停止します。ダウンしているサイトはオーナーの問題であり、バックログアイテムではありません。truncated: true の場合は、クロールが --max に達したことと、まだキューにあるパスを伝えます。

続けて node $P/scripts/sitecheck.js --root . も実行します。これはライブHTMLでは隠されているソース（Bladeの引数、ルート、フレーム）を認識し、両方を合わせて全体像を把握します。

2. トリアージ

3つのバケットに分類します。この順序で:

1. fix アイテム — インベントリエントリがガイド、記事、ツールの種類の file を持つページに対する severity: fix の発見事項（コード title、description、canonical、alt、link、sitemap）。ページごとに1アイテム、analysis §1c とまったく同じ形式で、2点の違いがあります: - evidence: audit <日付>: <n> findings と、各 fixes: 行が (audit <日付>) で終わること。これにより 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 <日付>: <n> findings
   - status: open
   - fixes:
     link: internal link /old-path redirects to /new-path: link the final URL (audit <日付>)
     description: no meta description (audit <日付>)
   

   すでにオープン/クレーム済み/レビュー中の fix アイテムがあるページ → 新しい fixes: 行をそれに追加します（コードと to が同じ行はスキップ）。オープンな refresh アイテムが所有するページ → owned by B-nnn となり、fix アイテムは作成されません。sitecheck も報告する（同じページ、同じコード）発見事項は、監査からのものとして1回だけリストされ、(audit <日付>) タグが付きます。
2. link アイテム — 記事ページの orphan 発見事項: クラスターごとに1つの link アイテム（$P/skills/analysis/SKILL.md §1c 形式、- links: 行 /hub → /orphan (orphan, audit <日付>)）。オープンな 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 は修正ではなくリフレッシュのシグナルです。その旨を伝えて analysis に委ねます。

--no-items → バケット3のみ、作成される予定だったアイテム数をカウントして表示します。

3. コミット

--dry-run でない場合: git add seo/data/crawl/<日付>.json seo/backlog.md を実行し、seo: audit <日付> — <ページ数> pages, <発見事項数> findings, <k> fix items, <m> link items というメッセージでデフォルトブランチにコミットします（計画ファイルは直接コミット）。ブランチに上流がある場合はプッシュします。PRは作成しません。

4. レポート（最大15行）

• audit <日付>: <ページ数> pages crawled (<html> html, <truncated?>)、<発見事項数> findings (<修正可能数> fixable)。サイトマップ <count> URL、<missing> 欠落または失敗
• コード別の発見事項、1行、カウント
• <前回> との差分: <新規数> 新規、<解決数> 解決（新規が5件以下の場合は名前を表示）
• アイテム: fix ID（パス付き）。link ID（クラスター付き）。owned by / already open の注記
• オーナーリスト: 最大8行、最も深刻なものから順（ナビゲーション内の5xxやリダイレクトチェーンは、長いディスクリプションより先）
• CWVテーブル（--cwv の場合）: パス、LCP、CLS、INP、perf、source
• 次のアクション: fix は金曜日にアイテムを実行します（または /seo-agent:fix を今すぐ実行）。次の監査は3ヶ月後

ハードルール

• サイトに対して読み取り専用: seo-agent-audit ユーザーエージェントで GET/HEAD、1つのオリジン、--max ページ、--delay リクエスト間隔。フォームを送信したり、ログインしたり、別のホストをクロールしたりしないでください。
• 記事、レイアウト、サイトマップを編集しない。PRを作成しない。seo/data/crawl/ と seo/backlog.md のみに書き込みます。
• バックログアイテムは、fix スキルが編集してもよい記事ページのみ。その他はすべてオーナーの責任です。
• 決定論的: 発見事項は crawl.js から来ます。HTMLを目視で読み取って発見事項を追加することはありません。
• thin は決して fix アイテムになりません。