qa

stardust:qa — 読み取り専用サイト QA スイープ

ライブ URL を 1 つ入力すると、証拠に基づく調査結果レポートが 1 つ出力されます。このスキルは一切編集しません。サイトコンテンツ、DA ドキュメント、リポジトリコードのいずれも対象外です。書き込むのは stardust/qa/ 配下のレポート成果物のみです。調査結果の修正をユーザーが希望する場合は、このスキルの範囲外で、別途明示的にフォローアップします。

qa は rollout のデプロイ後の配信確認に相当します。rollout が「すべてのページは公開されたか？」を確認するのに対し、qa は「公開されたものはすべて実際に正しいか？」を、デプロイで気づかれないまま壊れる可能性のある 3 つのレイヤーすべてで確認します。

1. 配信 — パイプラインが提供するもの（.plain.html、完全な HTML、シート、サイトマップ）
2. レンダリング — ブロックの装飾後にブラウザーに表示されるもの（およびその動作。自動再生動画がポスター画像しか表示しない場合も、レンダリングの不具合です）
3. リグレッション — 前回承認された状態から変更されたもの（ビジュアルベースライン）

上位レイヤーのチェックが成功しても、下位レイヤーが正しいとは限りません。公開時の 200 応答 ≠ 配信済み、配信された HTML ≠ 正しくレンダリング済みです。

セットアップ

1. まだこのセッションで実行していない場合は、マスタースキルのセットアップ（skills/stardust/SKILL.md § Setup）を実行します。qa は単独でも動作し、ライブのベース URL だけが必要です。
2. ベース URL（*.aem.live ホストまたは本番ドメイン）を特定します。ユーザーから提示されていない場合は、stardust/rollout/rollout.json（site.liveHost）を確認するか、ユーザーに尋ねます。
3. インベントリソース（スイープ対象のページ）を特定します。次のいずれかをマージして使用します。stardust/template-map.json（コンフォーマンス確認用のテンプレート割り当ても提供します。scripts/from-knowledge.mjs が仕様からこれを書き込み、ソースに元から存在する 404 の許可リストエントリーも含めます）、パスファイル、ライブの sitemap.xml（常に取得します。整合性の不一致は調査結果になるため、誤ったサイトマップによってカバレッジが知らないうちに縮小されることはありません）。
4. より詳細なチェックを行うための任意の入力：
   • --scrape stardust/scrape — 抽出時のキャプチャとの逐語的な忠実性
   • --expected-blocks <json> — テンプレートごとのブロック要件を明示的に指定
   • --parity <json> — リプレイする動的パリティファイル（デフォルトは stardust/dynamics/parity.json。ファイルがない場合、dynamics チェックは parity-missing を報告します）
   • --auth-header "token …" / --token-env SITE_TOKEN — 保護されたオリジン向け。シークレットはベースオリジンにのみ送信されます （指定しない場合は、フリートの合意から導出されます）
   • --blocks-dir <dir> — サイトの blocks/ チェックアウト。これにより、 editability チェックで @ew-exempt JSDoc タグを考慮できます （指定しない場合、インデックス駆動のブロックには --ew-exempt a,b を渡します）
5. ブラウザーチェックには、プロジェクトから解決可能な playwright（node_modules/playwright）が必要です。 見つからない場合は、配信レイヤーのチェックのみを実行し（--checks routing,content,templates,metadata,links）、スキップしたチェックをユーザーに伝えます。
6. スイープの開始時と終了時に、reference/run-status.md（マスタースキル）に従って、 stardust/status.jsonl にフェーズ遷移行を追記します。

手順

フェーズ 1 — 決定論的なスイープ

node <plugin>/skills/qa/scripts/qa.mjs \
  --base https://main--<site>--<org>.aem.live \
  --template-map stardust/template-map.json \
  --scrape stardust/scrape

stardust/qa/inventory.json、report.json、report.html、および stardust/qa/shots/ 以下のスクリーンショットを書き出します。また、（初回実行時は） stardust/qa/baselines/ 以下にビジュアルのベースラインを書き出します。終了コード 0 はアクティブなエラーなし、1 はアクティブなエラーあり、 2 はインフラストラクチャの障害を示します。reference/checks.md には、すべてのチェックとその検出結果 ID、 重大度の根拠が記載されています。便利な実行オプション：--checks <subset>、 --max-pages <n>（スモークテスト実行）、--fail-on warn（厳格なゲート）。ai-readability チェックは、 ページごとに Adobe の AI Content Visibility Checker（配信された単語数 ÷ レンダリングされた単語数）を再現し、 ブロックごとに差分の原因を特定します（deploy/reference/ai-readability.md）。

editability チェックは、デプロイ後の Experience Workspace 編集可能性ゲート（deploy SKILL.md § 8、EW1–EW10）です。ページごとに、配信されたドキュメント上で da.live キャンバスの計測処理を再現し、ライブページに装飾を適用させてから、作成者が記述したテキストのうち、 エディターインデックスが残っているものを数えます。editability/dead-text（エラー）は、ブロックが作成者の記述したテキストを再構築したため、 作成者がキャンバス上でクリックできないことを示します。editability/duplicated-index （警告）は、表示用の複製にインデックスが残っていることを示します。 @ew-exempt が宣言されたブロック内（または --ew-exempt に指定された）のデッドテキストは、エラーではなく情報として扱われます。

サイトでの初回実行では、visual/baseline-created の情報検出結果が多数出ることが予想されます。 これはベースラインが確立されていることを示すもので、欠陥ではありません。ベースラインは スクリーンショットであり、ローカルに保存されます（stardust/.gitignore は qa/baselines/ と qa/shots/ を除外します。master skill § Artifacts）。以降の実行では、 同じマシン上のベースラインと差分を比較します。新しくクローンした場合は、初回のスイープで再確立されます。 qa/allowlist.json は、判断を記録した追跡対象のファイルです。

フェーズ 2 — 判断が必要なフラグのトリアージ（LLM による判断、読み取り専用のまま）

決定論的なスイープでは、2 種類の検出結果に トリアージが必要 の印が付きます。report.json を読み、 それらだけを判断してください。

• content/verbatim-below-threshold — evidence.missingNodes をライブページと スクレイプのキャプチャで確認します。コンテンツが実際に失われた、または破損した（欠陥）のか、 許容できる変換なのか（許可リスト候補）を判断します。
• visual/visual-diff — evidence.baseline と evidence.current を並べて開きます （PNG 画像なので、表示してください）。実際のレイアウト／スタイルのリグレッションなのか、 カルーセルの表示フレーム、フォントの読み込み、ライブ埋め込みなどによる無害な動的変化なのかを判断します。 変更箇所の特定には bands の証拠を使用します。

各判定について、ユーザーへの要約で 検出結果に注釈を付けて 記録してください （欠陥か非欠陥か、およびその理由）。report.json のスコアを編集したり、何かを修正したりしないでください。

フェーズ 3 — ユーザーへの報告

重大度別の合計を要約し、確認済みの欠陥（ページパスと証拠を一行で示すもの）を最初に、 次にトリアージで対象外としたフラグとその根拠を、その後に注目すべき警告を示します。 stardust/qa/report.html を案内してください。修正を推奨しますが、適用はしないでください。

許可リストのワークフロー（文書化された非欠陥）

stardust/qa/allowlist.json（スキーマは schemas/qa-allowlist.schema.json）を使うと、 既知の非欠陥が以降の実行結果を埋め尽くすのを防げます。たとえば、プレースホルダーの文言を含んだまま公開されているソースページや、 クライアントの認証情報を意図的に待機しているフォームのエンドポイントなどです。エントリーは check/id/path/messagePattern で照合され、理由を必ず記載する必要があります。許可リストに登録された検出結果もレポートには残り、グレー表示されるため、証拠が削除されることはありません。

ユーザーがそのフラグを非欠陥と確認した場合（または、プロジェクトの記録ですでに非欠陥と文書化されている場合）に限り、エントリーを追加してください。実行結果をグリーンにするために許可リストへ追加してはなりません。

読み取り専用の規約

• stardust/qa/ 以下（および status.jsonl の台帳行）にのみ書き込みます。
• デプロイ／公開 API を呼び出さず、DA に PUT せず、ブロック、スタイル、コンテンツを編集しません。スイープで見つかった「簡単な」修正であっても同様です。
• 失敗は正直に報告します。クラッシュしたチェックは、レポートに <check>/check-crashed（エラー）として表示され、黙って除外されることはありません。

スケジュール設定／CI

ランナーはプラグインランタイムに依存しない通常の Node なので、同じコマンドを GitHub Action や cron から実行してドリフトを監視できます。--fail-on でゲートを設定します。playwright を使わない CI では、--checks をデリバリーレイヤーのサブセットに固定してください。