m1nga/iteration-close

iteration-close — 蒸留、除去、引き継ぎ検証、ブートストラップのリハーサル、次への準備

永遠にイテレーションを続けるプロダクトは、静かに2つの負債を積み上げます。このスキルは、イテレーションの境界ごとにそれらを安全に（何も失わずに）しかし容赦なく（死んだものは残さずに）返済します。

• デッドファイルは残り続け、二重の真実を生みます—非推奨のツリーが何週間も放置され、ランブックは「まだビルドされていない」コンポーネントを出荷後も主張し続けます。
• チャットウィンドウにしか存在しない知識は、ウィンドウと共に消えます—動作するパイプライン全体がスクラッチパッドで消え、苦労して得た決定がセッションと共に失われます。教訓は残し、アーティファクトは捨ててください。

このスキルは汎用的です。任意のリポジトリで、そのリポジトリ自身の規約を読み取って動作し、規約がない場合は、仮定したりエラーにする代わりに最小限のものを作成します。「新しいウィンドウや新しいマシンで続行できる」というのは、テストされるまでは「希望」に過ぎません。最新状態にする（pull）ことは常に安全ですが、公開（push）は意図的な選択です。ユーザーが作業している言語で応答してください。

2つの実行方法

• フルクローズ（デフォルト）：5つのフェーズすべてを順番に実行します。イテレーション/スライスが完了し、ユーザーがそれを完全にクローズしたい場合に使用します。
• ** shed-only**（スタンドアロンクリーンアップ）：ユーザーが古い/死んだ/無効になったファイルのクリアのみを依頼した場合、Phase 2のみを実行します—完全な5アクションクローズを強制しないでください。前提条件は変わりません：ステップ0（オリエンテーション）、fail-closed拒否チェック、および削除インベントリにスコープされたPhase 1のスポットチェックを実行します—教訓や決定がチャットにしかないアイテムは、最初に追跡ファイルに蒸留されるか、インベントリから除外されます。明示的承諾ゲートや隔離ルールを含む、Phase 2のすべてのルールがそのまま適用されます。

ステップ0 — このリポジトリにオリエンテーションする（発見する、なければ作成を計画する）

存在するエントリドキュメント（CLAUDE.md / AGENTS.md / README / docs/のインデックス）を読み、6つのことを発見します。見つけたものを使用し、ない場合は今回のクローズで埋めるギャップとして記録します（各フェーズの説明に方法が記載されています）。存在しないパスを決して発明しないでください。

1. 教訓/決定記録 — このリポジトリはどこに決定を保存していますか？（CHANGELOG、docs/adr/、DECISIONS.md、またはリポジトリ固有のレジスタ）ない場合、Phase 1で単一のDECISIONS.mdを作成します。
2. 確認済みアップロードコマンド — 意図的なプッシュ手順（bin/sync、make deploy、文書化されたgit pushの規律）？ある場合、それがアップロードチャネルです。決して迂回しないでください。ない場合、Phase 3aではdiffstat + 確認後にプレーンなgit pushを使用します。
3. ブートストラップコマンド — フレッシュクローンはどのようにして生き生きと動作するようになりますか？（bin/bootstrap、bin/sync-setup、install.sh、make setup、パッケージマネージャーのインストール）ない場合、Phase 4で作成します。
4. テストコマンド — CI設定、package.jsonスクリプト、Makefile、または言語デフォルト（pytest / go test / cargo test / npm test）から。発見できない場合、リポジトリにはまだ実行可能なスイートがありません：以下の明示的な状態として扱います—決して「グリーン」と判断せず、正当にスイートがないリポジトリで拒否しないでください。
5. グラウンディング/ゲートスキル — プロダクトグラウンディングまたはビルド前ゲートスキル？ある場合、その「ビルド後」チェックリストがクローズ前ゲートです。（プロダクト固有のゲートはプロダクトリポジトリ内にあり、このスキルは汎用性を保ち、それらに従います。）
6. 宣言されたデータ/リカバリ/隔離ディレクトリ — エントリドキュメントが実際のデータ、リカバリ資料、または隔離ファイルを保持すると指定するディレクトリ。これらは以下の「アーカイブ状のディレクトリが存在してはならない」ルールのすべてから除外され、削除インベントリに決して現れてはなりません。

実行を拒否する（fail-closed）

イテレーション途中でクローズしないでください—皮膚も肉も失います。以下の場合に拒否します（両方の実行モードで）：ディレクトリがgitリポジトリでない（停止してその旨を伝える—git initの実行はユーザーの決定です）；テストスイートが存在し、実際にFAILINGである（スイートがないことはFAILINGではない—ステップ0.4を参照）；リポジトリに敵対的ゲートがあり、それがペンディングまたはCHANGES-REQUIREDである；または別のエージェント/レーンが、あなたが触れるパスに未コミットの中間スライス作業を持っている。何がブロックしているかを伝えて停止します。

フルクローズでは、フェーズを順番に実行します。各フェーズには終了テストがあります。失敗した終了テストを通過して先に進まないでください。

Phase 1 — 蒸留（救出ゲート：教訓が保存される前に何も削除しない）

1. 今回のイテレーションでチャットで生まれた決定を、リポジトリの決定記録（ステップ0.1）にスイープします。それぞれにステータスとソースを付けます。リポジトリがまだどこにも決定を保存していない場合、記録の作成はこのフェーズの一部です—リポジトリルートに単一のDECISIONS.mdを作成するだけで十分です。 チャットウィンドウにしか存在しない決定は存在しません。蒸留された決定を追跡可能な保存先なしに放置しないでください。
2. 今回のイテレーションで発見された新しい不変条件/ルール → リポジトリの契約ファイル、またはそれがない場合は決定記録—理想的にはそれぞれテストとして。どちらも存在しない場合、決定記録を作成し、そこに配置します。アーティファクトを削除し、不変条件を保持します。
3. セッションのみの機能チェック：今回のイテレーションは、プロンプト、スクラッチパッド、または誰かの記憶にのみ存在するものに依存していましたか？それをリポジトリ（コード/スキル/ドキュメント）に昇格させるか、意図的な除外を記録します。それぞれを明示的に名前付けしてください—ここでパイプラインが死にます。
4. STRUCTUREが変更された場合、更新するか、存在せず構造が今や非自明である場合、短いアーキテクチャ/システムノートを作成して、現実を説明するようにします。リポジトリにあれば、ステータスボード（例：進捗ドキュメント）を最新にします。

終了テスト：リポジトリ内で今回のイテレーションの主要な決定と不変条件をgrepします—すべてが追跡ファイル内で見つけられること。チャットにしかないものがある場合 = Phase 1は完了していません。

Phase 2 — 除去（容赦ない削除；git履歴が唯一のアーカイブ）

1. 証拠付きの削除インベントリを1行ずつ構築します：パス | なぜ死んでいるか | 何がそれを置き換えるか。範囲：廃止されたモジュール/仕様、死んだ/空のディレクトリ、開発残骸（スクラッチファイル、mktempスタイルのジャンク、実際の形をしたストア内のテスト行）、完了した計画/TODOドキュメント、および古くなったドキュメント—ドキュメントとコードの矛盾パスを実行します。コードが矛盾することを主張するドキュメントは、ドキュメントがないより悪いです。各行をTRACKEDまたはUNTRACKEDとマークします（git ls-files --error-unmatch <パス>）。2つは異なる運命を持つためです（ルール3と4）。
2. 完全なインベントリをユーザーに提示し、削除する前に明示的な承諾を待ちます。 部分的な承認は問題ありません—承認された行に対してのみ行動します。エージェントは自分自身で元に戻せないボタンを押しません。「ユーザーがクリーンアップを依頼した」ということは、リストを構築する権限を与えるものであり、実行する権限を与えるものではありません。
3. 追跡ファイル：git rmのみ。_archive/ディレクトリは不可、.bakは不可、old-/legacy-リネームは不可、コメントアウトされた死体は不可。リカバリ = git履歴、1回のgit revertで戻せます—それがアーカイブです。削除前のチェックポイントコミットでそれを防弾にします。
4. 未追跡またはgitignoreされたファイル：決して直接rmしないでください—git履歴はコミットされなかったものを回復できません。これがデータ安全ラインです。 代わりに、リポジトリの宣言された隔離ディレクトリ（ステップ0.6）に移動します。宣言されていない場合、今すぐ作成します：リポジトリルートに.iteration-quarantine/、.gitignoreに追加、エントリドキュメントに1行で宣言します（「削除待ちの未追跡ファイル用隔離—ユーザーが手動で空にする」）。隔離の空化はユーザーの行為です—将来のクローズで、それ自身の明示的な承諾と共に提供します。決して黙って行いません。
5. プロダクトの実際のDATAを開発残骸として決して除去しないでください。 ユーザー/顧客の状態、保存されたセッション、ユーザーコンテンツの実際のアーカイブは、雑然と見えるかもしれませんが、プロダクトの魂です。ディレクトリがどちらでもあり得る場合、データとして扱い保持します。git rmの前に検証します。
6. 削除をテーマ別グループでコミットします。各メッセージはWHY + 何がそれを置き換えるかを述べます。
7. 削除後チェック（該当するものすべてが合格する必要があります）：リポジトリにテストスイートがある場合、それはグリーンです。削除された各モジュール/シンボルの未解決参照grepが空（削除されたファイルのインポートは起動時にクラッシュします—実際の傷です）。エントリドキュメントとスキルドキュメントは削除されたパスを参照していません。

終了テスト：git statusがクリーン、アーカイブ状のディレクトリが存在しない—ただし、エントリドキュメントがデータ、リカバリ、または隔離として宣言するディレクトリ（ステップ0.6）を除く—未解決grepが空、テストスイートが存在する場合はグリーン。

Phase 3 — 2つの準備チャネル（異なるニーズ；個別に検証）

アップロードと続行可能性は同じ問題ではありません。それらを混同すると、リポジトリが「クラウドにプッシュ」されながら、実際の状態がまだチャットログに残るという事態が起こります。それぞれを個別に検証します。

3a. 確認済みクラウドアップロード（転送問題）

1. 追跡ファイルのみに対してシークレットスキャン（sk-ant / ghp_ / gho_ / github_pat / AKIA / xox[baprs] / consumer_secret / access_token / Bearer / BEGIN PRIVATE KEY / .env形式）。ヒット → 停止、スクラブ、再スキャン。
2. git remoteを確認。リモートがない場合、アップロードにはユーザーが提供するリモートが必要です—リモートの追加は設定変更であるため、ユーザーに確認するか、「リモートなし—公開延期」と記録して、ベアgitコマンドでエラーにする代わりに3bにスキップします。
3. リモートがある場合：git log @{u}..HEAD --oneline + diffstatを表示（上流がない場合は「すべてのローカルコミット」にフォールバック）—このマシンから出ていくものを正確に表示します。
4. リポジトリの確認済みアップロードコマンド（ステップ0.2）を介して、ユーザーが確認した後にアップロードします。リポジトリにない場合、diffstatと承諾後にgit push。決して自動プッシュしないでください。

3b. ゼロコンテキスト引き継ぎ（知識完全性問題）—コールドスタートプローブ

1. 純粋にコンテキストフリーの読者をリポジトリに一人招待します—Claude Codeでは、フレッシュなサブエージェントを生成（Taskツール）；Codexでは、新しいcodex execまたは事前コンテキストのない新しいセッションを実行；任意のベアハーネスでは、新しいセッションを開き、リポジトリパスと質問のみを貼り付け、この会話は決して貼り付けません。リポジトリパスのみを与えて：「このリポジトリをエントリドキュメントからコールドで読んでください。次に答えてください：(1) このプロダクトは何ですか、一文で；(2) 作業の現状はどうですか（完了/次）；(3) 次に何をしますか、なぜですか；(4) ここで絶対にしてはいけないことを3つ挙げてください。」
2. その答えをリポジトリの正規ドキュメントに対して評価します。リポジトリにエントリ/正規ドキュメントがまったくない場合、最小限のもの（プロダクトを一文で、現在の状態（完了/次）、3つの絶対禁止事項）を作成することがこのクローズの一部です—それはプローブが評価するアーティファクトです。何もない状態でプローブを実行しないでください。
3. すべての間違ったまたは欠落した答えは、引き継ぎドキュメントのバグであり、プローブのせいではありません。ドキュメントを修正（または作成）し、新しいフレッシュな読者で再実行します。コールドリーダーが4/4になるまでループします。最大3ラウンド—それでも失敗する場合、残りのギャップをリストし、決定をユーザーに委ねます。

終了テスト：プローブが4/4をパス。その場合のみ、「新しいウィンドウ/マシンで続行できる」はテストされた事実です。

Phase 4 — ワンコマンドブートストラップ（仮定ではなくリハーサル済み）

1. リポジトリのブートストラップ（ステップ0.3）が存在し、最新であることを確認します—冪等で、再実行しても安全：ツールチェーンバージョンを検証；同期/設定を配線；依存関係をインストール；テストスイートが存在すれば実行；現在のステータスと欠落しているローカルシークレットの名前（値ではなく、例：「config.local.jsonがありません—ライブ公開にのみ必要」）を出力；失敗時は1行の理由で非ゼロ終了。まだブートストラップがない場合、今回のイテレーションで作成するのが適切です。
2. リハーサルします：リポジトリをスクラッチディレクトリにクローンし（オリジンURLから、またはリモートがない場合はローカルリポジトリパスから）、そこでブートストラップを実行します。ゼロの手動ステップでグリーンに終了する必要があります。リハーサルクローンは削除します。
3. 新しいマシンでのストーリーは1行で、このリハーサル後に真実である必要があります：git clone <origin-url> <dir> && cd <dir> && <bootstrap command>。リモートがまだ存在しない場合、ユーザーが設定するまでこの行はまだ真実ではないことに注意してください—あたかも機能するかのように公開しないでください。

終了テスト：リハーサルクローンが手を触れずにグリーンでブートストラップされる。

Phase 5 — クローズ＋シード（継続性）

1. イテレーションにタグを付けます：git tag iter-<N>-<slug>（注釈付き、1行サマリー）。N = 1 + 既存のiter-*タグの数（`git tag --list