1. 未検証・不正確な事実を plan → PR body に確定として記載し、ユーザー修正が必要になった
Problem: 業務プロジェクトの Go サービスへの機能追加 PR で、2件の事実誤りが承認済み plan と PR body に確定記述として persist した。(a) 検証・切り戻し手順に、プロジェクトが実際には使っていない監視 vendor を指す記述を入れた（git grep -il <vendor> は go.mod / go.sum と一部 logger 関連のみで実体は別 vendor だと1回の grep で裏取り可能だったが、plan 承認・PR body 複数版・pr-selfcheck 2 回を素通りしユーザーが訂正）。(b) キャンセル操作をスコープ外とする根拠を「別リポの過去 PR にあった別文脈の懸念」の誤適用として PR body に書いたが、ユーザーの質問「本当にそれが理由か」を受けて実際の理由（payload に targeting key が乗らない技術的制約）に書き直した。
Severity: high — base は medium（成果物の記述にユーザー訂正が2件必要、出荷されれば検証運用手順が存在しないツールを指す）。「未検証の主張を成果物に確定として書く」パターンは過去 retro #257-1 / #263-1 / #264-1 と cross-session recurring のため1段階引き上げ。
Scope: global（enforcement 修正）
Countermeasure: 統括ルールは AIRULES「事実と確信度の管理」の「容易に裏取りできる情報は一次情報源で確認する（特に手順・PR 構成等の提案を出す前）」だが、plan / PR body 起草時に enforcement がなく、pr-selfcheck の検査シグナルにも fact-grounding 項目が無いのが構造欠陥。claude/skills/git-workflow/pr-guidelines.md の PR Body Checklist 項目「Sources and references」に bullet を追加（pr-selfcheck は Step 3 でこの checklist をロードするため検出側にも自動で効く）:
- Operational sections (verification, rollout, rollback, monitoring)
may name an external tool or service only after confirming the
project actually uses it (repo dependencies / config via git grep,
project docs, or an explicit user statement). Rationale attributed
to a linked issue / PR must match what that source actually says.
Unverified vendor mentions or misattributed rationale are Must Fix.
2. PR body 初稿が length budget を大幅超過し「安全弁」テーマ別セクションを含み、checkpoint 通過後もユーザーの editorial pass が必要だった
Problem: 初稿 PR body は 59 行（guideline は ~30 行）+ 別リポ作業の運用手順セクション + go test 結果記録で、pr-selfcheck が Must Fix 3件を検出（checkpoint は機能）。修正後の 25 行版でも「安全弁」という性質別セクションが残り、ユーザーが「PR 本体長いし、安全弁っていう変なセクション作っても微妙」と構成の手直しを指示、追加の書き直しが発生した。
Severity: low — checkpoint と短い user editorial pass で解決し、出荷後も cosmetic（マージ後に本文構成が害を生むことはない）。
Scope: global
Countermeasure: claude/skills/git-workflow/pr-guidelines.md の Style rules は「Future work は末尾へ」を定めるが、性質別テーマセクションの禁止が無い。Style rules に1 bullet 追加:
- Organize sections by what a reviewer or operator needs (purpose,
key changes, prerequisites, verification). Do not create
property-themed sections ("safety valves", "performance notes");
fold each such point into the bullet for the change it qualifies.
3. AIRULES 禁止のコマンド置換 $(cat <<'EOF') が commit 時に素通りした
Problem: review 指摘対応の commit を git commit -m "$(cat <<'EOF' ... EOF)" で実行。AIRULES「シェルコマンド内でコマンド置換（$()、バッククォート）を使わない。複数行テキストはシングルクォートで渡し、本文にシングルクォートが含まれる場合のみ heredoc にフォールバック」に反する（メッセージ本文に ASCII シングルクォートは無く、-m '...' で足りた）。cd 連結には block hook が存在し実際に本セッションでも1回捕捉・即時修正させたのに対し、コマンド置換には enforcement が無い。
Severity: low — コミット自体は成功し実害なし。過去 retro に同パターンの報告は無し。
Scope: global
Countermeasure: 機械化。hookify rule を新規作成（/hookify で生成、global 配置: ~/.claude/hookify.command-substitution.local.md）。pattern: Bash tool の command が \$\( またはバッククォートにマッチしたら block し、メッセージ「AIRULES: コマンド置換禁止。複数行テキストはシングルクォートで渡す（本文にシングルクォートを含む場合のみ置換なし heredoc）。git commit は -m '...' または --file <path> を使う。」を返す。既存の cd-chain hook と同じ enforcement 層に揃える。
1. 未検証・不正確な事実を plan → PR body に確定として記載し、ユーザー修正が必要になった
Problem: 業務プロジェクトの Go サービスへの機能追加 PR で、2件の事実誤りが承認済み plan と PR body に確定記述として persist した。(a) 検証・切り戻し手順に、プロジェクトが実際には使っていない監視 vendor を指す記述を入れた（
git grep -il <vendor>は go.mod / go.sum と一部 logger 関連のみで実体は別 vendor だと1回の grep で裏取り可能だったが、plan 承認・PR body 複数版・pr-selfcheck 2 回を素通りしユーザーが訂正）。(b) キャンセル操作をスコープ外とする根拠を「別リポの過去 PR にあった別文脈の懸念」の誤適用として PR body に書いたが、ユーザーの質問「本当にそれが理由か」を受けて実際の理由（payload に targeting key が乗らない技術的制約）に書き直した。Severity: high — base は medium（成果物の記述にユーザー訂正が2件必要、出荷されれば検証運用手順が存在しないツールを指す）。「未検証の主張を成果物に確定として書く」パターンは過去 retro #257-1 / #263-1 / #264-1 と cross-session recurring のため1段階引き上げ。
Scope: global（enforcement 修正）
Countermeasure: 統括ルールは AIRULES「事実と確信度の管理」の「容易に裏取りできる情報は一次情報源で確認する（特に手順・PR 構成等の提案を出す前）」だが、plan / PR body 起草時に enforcement がなく、pr-selfcheck の検査シグナルにも fact-grounding 項目が無いのが構造欠陥。
claude/skills/git-workflow/pr-guidelines.mdの PR Body Checklist 項目「Sources and references」に bullet を追加（pr-selfcheck は Step 3 でこの checklist をロードするため検出側にも自動で効く）:2. PR body 初稿が length budget を大幅超過し「安全弁」テーマ別セクションを含み、checkpoint 通過後もユーザーの editorial pass が必要だった
Problem: 初稿 PR body は 59 行（guideline は ~30 行）+ 別リポ作業の運用手順セクション + go test 結果記録で、pr-selfcheck が Must Fix 3件を検出（checkpoint は機能）。修正後の 25 行版でも「安全弁」という性質別セクションが残り、ユーザーが「PR 本体長いし、安全弁っていう変なセクション作っても微妙」と構成の手直しを指示、追加の書き直しが発生した。
Severity: low — checkpoint と短い user editorial pass で解決し、出荷後も cosmetic（マージ後に本文構成が害を生むことはない）。
Scope: global
Countermeasure:
claude/skills/git-workflow/pr-guidelines.mdの Style rules は「Future work は末尾へ」を定めるが、性質別テーマセクションの禁止が無い。Style rules に1 bullet 追加:3. AIRULES 禁止のコマンド置換
$(cat <<'EOF')が commit 時に素通りしたProblem: review 指摘対応の commit を
git commit -m "$(cat <<'EOF' ... EOF)"で実行。AIRULES「シェルコマンド内でコマンド置換（$()、バッククォート）を使わない。複数行テキストはシングルクォートで渡し、本文にシングルクォートが含まれる場合のみ heredoc にフォールバック」に反する（メッセージ本文に ASCII シングルクォートは無く、-m '...'で足りた）。cd連結には block hook が存在し実際に本セッションでも1回捕捉・即時修正させたのに対し、コマンド置換には enforcement が無い。Severity: low — コミット自体は成功し実害なし。過去 retro に同パターンの報告は無し。
Scope: global
Countermeasure: 機械化。hookify rule を新規作成（
/hookifyで生成、global 配置:~/.claude/hookify.command-substitution.local.md）。pattern: Bash tool の command が\$\(またはバッククォートにマッチしたら block し、メッセージ「AIRULES: コマンド置換禁止。複数行テキストはシングルクォートで渡す（本文にシングルクォートを含む場合のみ置換なし heredoc）。git commit は-m '...'または--file <path>を使う。」を返す。既存の cd-chain hook と同じ enforcement 層に揃える。