qa-quarto

敵対的 Quarto 対 Beamer QA ワークフロー

反復的な批評・修正ループを使って、Quarto の HTML スライドを Beamer の PDF ベンチマークと比較します。

基本方針： Beamer の PDF をゴールドスタンダードとします。Quarto への変換は、あらゆる面で同等以上でなければなりません。

---

ワークフロー

Phase 0: Pre-flight → Phase 1: Critic audit → Phase 2: Fixer → Phase 3: Re-audit → Loop until APPROVED or dry (2 consecutive dry rounds; fallback cap 5)

厳格なゲート（妥協不可）

ゲート	条件
はみ出し	コンテンツが切れていないこと
プロットの品質	インタラクティブチャートが静的プロット以上であること
コンテンツの同等性	スライド、数式、テキストに欠落がないこと
視覚的な回帰	すべての面で Quarto が Beamer 以上であること
スライドの中央揃え	コンテンツが中央に配置され、位置が跳ねないこと
表記の忠実性	数式がすべて Beamer の内容と一字一句同じであること

フェーズ 0：事前確認

1. Beamer（.tex/.pdf）ファイルと Quarto（.qmd/.html）ファイルを特定します
2. 新しさを確認します（QMD のほうが HTML より新しい場合は再レンダリングします）
3. 該当する場合は TikZ SVG を確認します
4. レンダリングを測定します："${SLIDE_QA_PYTHON:-python3}" scripts/slide-qa.py Quarto/[Lecture].html。ヘッドレス Chrome でスライド一式を読み込み、スライドごとのはみ出しをピクセル単位で記録した quality_reports/audits/slide-qa/[Lecture]/report.md と、スライドごとのスクリーンショットを出力します。終了コード 1 は問題が見つかったことを示します。問題には、はみ出し、コンテンツの切れ、画像の破損、ファイルの欠落または大文字・小文字の不一致があります。終了コード 2 は実行できなかったことを示します（通常は Playwright が見つからない場合です。その場合、スクリプトは一度だけ実行する venv のインストール手順と、設定する SLIDE_QA_PYTHON の行を出力します）。その旨を伝え、批評エージェントはソースの確認に切り替えます。

フェーズ 1：初回監査

quarto-critic エージェントを起動し、フェーズ 0 のはみ出しゲート用 slide-qa レポートのパスを渡して、Beamer と Quarto を包括的に比較します。レポートは quality_reports/[Lecture]_qa_critic_round1.md に保存します。

フェーズ 2：修正サイクル

承認されていない場合は、quarto-fixer エージェントを起動し、修正を適用して（重大 → 大 → 小）、再レンダリングして検証します。

フェーズ 3：再監査

修正後に再レンダリングされたものに対して scripts/slide-qa.py を再実行し、新しいレポートを critic に渡して修正を検証します。必要に応じてフェーズ 2 に戻ります。

反復回数の制限 — 解消までループ

これは orchestrator-protocol.md に定義された 解消までループ プリミティブです。critic は FINDING を返します（厳格なゲートの表は orchestration-schemas.md に従った重大項目の集約です）。ループは、固定回数ではなく、重大または大の新規指摘が 0 件のラウンドが 2 回連続した時点で収束します（id = sha1(file:line:locus) に基づいて重複を除外します）。

• フォールバック上限： 収束しないループは 5 ラウンドを上限とし、その後、残る問題をユーザーに報告してエスカレーションします。
• 2 回で警告： 同じゲートがラウンド N と N+2 で失敗した場合、再度修正するのではなく、ユーザーに通知します（summary-parity.md）。
• すべての厳格なゲートに合格し、重大または大の指摘が残っていない場合に限り、承認とします（小さな指摘はユーザー向けに一覧表示します）。

最終レポート

厳格なゲートの状態、反復の概要、残る問題を含むレポートを quality_reports/[Lecture]_qa_final.md に保存します。

指摘事項は単に書かれるのではなく、検証されます（v2.5）

このスキルのレビュアーは、 finding-schema.json の機械検証可能な契約に従って指摘事項を出力します。レポートは JSON の 配列 です。

レビューに時間をかける前に、ハーネスをスモークテストしてください — レビュアーを複数起動した後、有効なレポートを書き出せなければ、そのレビューはすべて無駄になります。

echo '[]' | python3 scripts/validate-findings.py

レビュアーエージェントは読み取り専用なので、ファイルの書き込みはこのスキルが行います。各レビュアーの最終回答について、説明文のレポートをそのレビュアー用のこのスキルのレポートパスに保存し、末尾のフェンス付き json ブロックをスクラッチファイルにコピーして、検証しながら ID を入力します。

python3 scripts/validate-findings.py --fill-ids block.json > <report>.json.tmp \
  && mv <report>.json.tmp <report>.json || rm -f <report>.json.tmp   # exit 0 required; a failed run keeps no file
python3 scripts/validate-findings.py --check-quotes <report>.json   # each quote must be the file's own text (orchestration-schemas.md §1)

json ブロックを返さなかったレビュアー、または検証に通らないブロックを返したレビュアーは、レビューを行っていません。バリデーターのエラーテキストを添えて一度だけ再度ディスパッチし、それでも対応できなければ、そのレンズは欠落として報告し、それなしで集約しないでください。

この契約で何が求められるのか、またその理由：

• rule — 違反した、文書化済みのルールまたは基準です。ルールを示さない指摘事項は意見であり、意見を理由にコミットを阻止することはできません。
• failing_case — 主張が成り立たなくなる具体的な設定、または欠落している正確な仮説です。「もっと明確にできる」 では検証に通りません。
• id = sha1("<file>:<line>:<locus>") — 決定性があるため、ラウンド間の重複排除が正確になり、二度警告するルールを目視ではなく検証可能な形で確認できます。
• mechanical — 結果を変え得ない修正（誤字、相互参照、書式、ラベル）に限り true にします。推定対象、仮定、仕様、推論手順、サンプル定義、報告文言には決して設定しないでください。これらは研究者に差し戻されます。

検証の前に、orchestration-schemas.md §7 の レンズごとの証拠要件 と 「該当しない」ためのフィルター を適用し、既知の誤検知が判定者に届かないようにしてください。検証パスは 反証を優先 し、各指摘事項の verdict を設定します（レビュアーは設定しません）。verdict: "confirmed" の指摘事項だけを採用し、根拠を示せないものは警告に格下げせず、除外します。