dev-loop: プラグインの配布を起こすマージを、不在の周でマージしてよい反映に入れるかを決める #489

何が起きているか（2026-10-28・cruise #474）

#476（PR #488）で、.claude/dev-loop.md に マージの反映: ドキュメントのみ を宣言できるようになった。宣言が照合を通れば、不在の周でも マージ = 関門を通ればマージ の線が効く。

ただしこのリポジトリでは使えない:

• dev-loop: マージがドキュメントのサイトの再デプロイしか起こさないリポジトリでも、不在の線「マージ = 関門を通ればマージ」が効かない #476 の計画（docs/plans/issue-476.md）で、このリポジトリには宣言を置かないと決めた。main へのマージは GitHub Pages の再デプロイに加えて、プラグインの新しい版を利用者のクライアントに配る（.claude-plugin/marketplace.json・各 plugin.json）
• references/absent-lines.md の「マージが起こす反映の宣言」は、利用者が取りに来る配布物（パッケージ・プラグインのカタログ・コンテナの像）の更新を宣言の外とし、照合で「既定ブランチそのものが配布元になっていないか」を見る
• spec-loop: 残課題を cruise で回す（親 Issue） #474 の PR はどれもプラグインの版を上げる——宣言を置いても照合を通らない

その結果、このリポジトリで不在の cruise を回すと、各周が PR を作って止まり、依存する Issue は始まらない。#474 では PR が 5 本（#479・#481・#483・#485・#486）溜まり、そのうち 3 本は spec-loop の版の行で衝突している。#441・#276・#291 は依存先のマージ待ちで始まらない。

#476 の計画は、これを「プラグインの配布を反映としてどう扱うか（このリポジトリで不在の cruise をマージまで進めたいなら要る）——この周の外」として残している。この Issue はその受け皿である。

決めること

1. プラグインの配布を、不在の周がマージしてよい反映に入れるか。
   • 入れる根拠になりうる点: 次のマージ（revert して版を上げる）で戻せる。データを持たない。
   • 入れない根拠になりうる点: 利用者のクライアントの状態を変える（plugin update や autoUpdate で取りに来た版が残る）。revert だけでは、取った利用者のキャッシュ・installed_plugins.json は戻らない（CLAUDE.md の「キャッシュに在ることは、読み込まれることではない」）
2. 入れるなら、宣言の値（例: マージの反映: ドキュメントとプラグインの配布）と、照合で何を確かめるか（配布元がこのリポジトリのカタログだけか、版を上げる以外の配布の変更が無いか など）
3. 入れないなら、このリポジトリで依存のある Issue を回すときの代わりの形——居る cruise（マージのたびに承認）を案内するだけでよいか

受入基準（案）

• 決めた結論が references/absent-lines.md に、照合の手順とともに書かれている
• 入れる場合: このリポジトリで宣言を置き、不在の cruise が関門を通った PR をマージして依存先の周を始めることを、1 回は実際の cruise で確かめる
• 入れない場合: cruise の起動時の確認が、このリポジトリでは マージ の線が効かない理由として「プラグインの配布」を名指しする

元の周: cruise #474（2026-10-28）。関係: #476・#484