trash-truck

Trash Truck

サーフェスが存続すべきかどうかを問い直します。簡素化より削除を、最適化より簡素化を、自動化より最適化を優先します。十分な根拠に基づく「維持」「証拠不十分」、または変更なしという結論も、完全な作業です。

Invocation

/trash-truck OWNER/REPO mode:interactive
/trash-truck OWNER/REPO mode:interactive candidate:"<description>"
/trash-truck OWNER/REPO mode:scheduled
/trash-truck OWNER/REPO mode:scheduled persist:github

OWNER/REPO は必須です。candidate:"<description>" は任意で、対話モードでのみ有効です。説明全体を引用符で囲み、末尾の自由記述を候補の一部として扱わないでください。persist:github は任意で、スケジュールモードでのみ有効です。オーナーが設定したスケジュール、または現在のオーナーからの明示的なリクエストに基づく必要があります。これらの組み合わせが無効な場合、またはモードが指定されていないか不明な場合は、入力エラーとして停止してください。

調査を始める前にモードを確定してください。

状況	モード	許可される結果
ユーザーが存在し、mode:interactive が明示されている	対話型	探索調査または対象を指定したレビュー。推奨案を提示し、適格な retire または prune/simplify 候補に限り選択肢を提示します。承認済みマニフェストを最大1件実行します
スケジュールまたは自動化が persist:github なしでスキルを実行する	スケジュール	調査し、issue_persistence: not-requested と報告してから停止します
オーナーが許可したスケジュールが mode:scheduled persist:github を実行する	永続化を伴うスケジュール	調査し、条件を満たす場合は正規のレビュー用イシューを1件永続化してから停止します
対話型のオーナーがいるか不明（機械的なチェックではなく、呼び出し元エージェントの判断）	スケジュールのフェイルセーフ	報告のみとし、製品またはリポジトリの状態は変更しません

解析済みの入力を正規化し、続行する前に python3 <skill-dir>/scripts/rank_candidates.py mode <invocation-json> を実行してください。バリデーターでエラーが発生した場合は停止してください。

譲れない制約

• スケジュールモードでは、コードの編集、削除、廃止PRの作成、ジョブの無効化、スキーマやデータの変更、インフラストラクチャの変更、マージ、デプロイ、稼働中のスキルの同期を決して行いません。
• 対話型の調査では、オーナーが提示された候補の正確なフィンガープリントと廃止マニフェストを選択するまで、読み取り専用で行います。
• 選択は包括的な削除権限を与えるものではありません。スキーマ、データ、インフラストラクチャ、外部連携、マージ、デプロイ、その他オーナーの承認が必要な操作には、それぞれ個別の明示的な許可が必要です。
• GitHub イシュー、過去の意見、期限切れの承認、候補のスコアは証拠であり、実行権限ではありません。
• 利用できないテレメトリー、失敗したテレメトリー、古いテレメトリー、または環境が異なるテレメトリーを、使用量ゼロと解釈してはいけません。
• 結果を水増ししてはいけません。候補は0件から3件まで返してください。
• resolve_mode() はオーナーの有無を判定しません。渡された mode／candidate／ persist の文字列のみを検証します。「対話型のオーナーがいるか不明」というフェイルセーフは、 呼び出し元エージェントが判断して遵守すべき指示であり、機械的なチェックではありません。 補完的な制御は実際に機能します。実行には、正確な候補のフィンガープリントをオーナーが明示的に 選択すること（「更新と無効化」を参照）がさらに必要であり、スケジューラーがこれを捏造することはできません。

ワークフロー

1. リポジトリと権限の事前確認

1. 対象リポジトリの有効な指示、イシュー作成ポリシー、破壊的操作に関するルールを確認します。
2. リポジトリの識別情報、現在のリビジョン、デフォルトブランチ、作業ツリーの変更状況、および利用可能な読み取り専用の証拠収集手段を確認します。
3. スケジュールモードでは、persist:github が明示されていない限り、永続化は要求されていないものとして扱います。明示されている場合は、オーナーが設定した許可、リポジトリのポリシー、認証情報のスコープ、リポジトリ単位のシリアライズまたはアトミックロックをそれぞれ個別に確認します。
4. コマンド、作業者向け概要、証拠パケット、イシューの内容に秘密情報を含めないでください。

リポジトリを特定できない場合、または要求されたスコープがリポジトリのポリシーに違反する場合は、その阻害要因を示して停止してください。 指定された候補が複数の概念上のサーフェスを指す可能性がある場合は、フィンガープリントの作成や証拠の収集を行う前に、その境界をオーナーに確認してください。

2. 調査範囲を限定する

指定されたリポジトリから開始します。その設定、デプロイマニフェスト、ランタイム識別子、または正式なドキュメントで特定された直接的な運用上の依存関係のみをたどります。たとえば、次のものが該当します。

• デプロイ済みのサービスとリビジョン；
• ジョブ、スケジュール、キュー、ワーカー；
• 対象範囲が直接所有するデータベース、バケット、トピック、インフラストラクチャ；
• 対象範囲が送信または受信する分析イベント、ログ、インテグレーション、外部コールバック；
• 直接参照されているリポジトリまたはパッケージ。

ベンダー全体のアカウント、無関係なリポジトリ、推移的な依存関係へ調査を広げないでください。candidate:<description> が指定されている場合は、その対象のみを調査し、無関係な調査結果は候補として挙げず、範囲外として記録してください。

3. 証拠を収集し、廃止を反証しようとする

証拠を収集する前に、references/candidate-packet.md を読んでください。

実際に存在する証拠の情報源を利用してください。ハーネスが対応している場合は、分離可能な情報源ごとに、独立した読み取り専用のワーカーを優先してください。

情報源	有用な証拠
コードと依存関係	参照、インポート、ルート、機能フラグ、生成されたクライアント、動的な検索、テスト、設定
GitHub と git	オープンおよびクローズ済みの issue、マージ済みおよび放棄された PR、コミット、blame、コードオーナー、非推奨化の決定、後継の作業
ランタイム	デプロイ済みのリビジョン、サービスの一覧、トラフィック、呼び出しログ、エラー、キューまたはジョブのアクティビティ
プロダクト分析	PostHog、Mixpanel、または同等のイベントとファネル。ID、分母、環境、十分な期間を含むもの
運用	CloudWatch または同等のログ、スケジュール、アラート、ランブック、インフラストラクチャの状態、インテグレーションの配信記録
関係者とオーナーシップ	判明している利用者、オーナーの確認、サポートまたはコンプライアンス上の義務、例外的または季節的な利用

各ワーカーには、範囲を限定した読み取り専用の質問を 1 つ割り当て、証拠エンベロープを返してもらいます。ワーカーは候補の順位付け、状態の変更、廃止の判断を行いません。1 人のキュレーターが、識別情報、環境、矛盾、鮮度、反復期間を突き合わせます。

あらゆる手掛かりについて、反証となる情報を積極的に探してください。コード上で参照が見つからないだけでは不十分です。受動的なインストールや読み込みと、実際の呼び出しを区別してください。検証済みの利用が確認された場合、その利用範囲の廃止は認められません。ただし、その利用を維持する、より限定的な簡素化は妥当な場合があります。

4. 候補パケットを作成して順位付けする

references/candidate-packet.md に記載された適格性、重要性、スコアリング、同点時の判定、承認に関するルールを使用してください。そこで説明されている方法で、裏付けのある手掛かりを正規化してから、同梱のバリデーターが利用可能な場合は python3 <skill-dir>/scripts/rank_candidates.py rank <candidate-json> を実行してください。実行できない場合は、同じ基準で手動評価し、順位付けが機械的に検証されていないことを明記してください。

候補の発見では、適格な候補をすべて順位付けし、上位 0～3 件のみを提示してください。対象が指定されている場合は、代替候補の一覧を作成せず、次のいずれかを返してください。

• retire — 証拠が、宣言された対象範囲全体の削除を支持している；
• prune/simplify — 対象範囲の一部が引き続き必要である；
• keep — 検証済みの利用または義務により、廃止できない；
• insufficient evidence — 安全な判断を裏付ける証拠が不足している。

適格な retire または prune/simplify の候補にはすべて、フィンガープリント、スコアの各要素、廃止を支持する証拠と反対する証拠、未解決の不足情報、判明しているオーナーと利用者、最後に検証された利用、廃止マニフェスト、除外項目、可逆性、オーナーによる承認条件を含めてください。keep または insufficient evidence の評価には、フィンガープリント、決定的な証拠、情報源の網羅状況、判明しているオーナーと利用者、不足情報を含めますが、廃止スコアや実行可能なマニフェストは含めません。

5. モードに応じて分岐する

スケジュール実行

references/canonical-issue.mdを読みます。事前確認の結果を正規化し、python3 <skill-dir>/scripts/rank_candidates.py persistence <persistence-json>を実行します。persist:githubがない場合は、not-requestedと報告してSTOPします。決定論的な判定で指示された場合に限り、返されたcreateまたはupdateを実行します。それ以外の場合は、not-neededまたはblockedの結果を報告してSTOPします。

1. 正規の廃止レビュー用イシューを最大1件にまとめます。
2. 実質的に変更された調査内容のみを記録します。
3. 保存したイシューまたはコメントを読み戻し、マーカーと内容を検証します。
4. 永続化の状態をverified、not-requested、not-needed、blocked、またはfailedとして報告します。
5. STOPします。

有力な候補を含め、候補があってもスケジュール実行を許可するものではありません。

対話型の候補探索

ランキングが空の場合は、変更なしと報告して、選択を求めずにSTOPします。それ以外の場合は、ランキング順に候補の詳細を提示し、オーナーに正確なフィンガープリントを1つ選ぶか、停止するよう求めてから、STOPして待機します。

対話型の対象指定

retireまたはprune/simplifyの場合は、判定と正確なマニフェストを提示し、そのフィンガープリントと対象範囲について実行するかどうかを尋ねてから、STOPして待機します。keepまたはinsufficient evidenceの場合は、評価を提示し、実行する選択肢は示さずにSTOPします。

6. 実行前の再確認

選択後、適格性またはスコアリングを実質的に裏付けた、変化しやすい情報源をすべて更新します。引き続き新しい状態にある安定した証拠は再利用します。表示済みおよび更新済みの候補パケットに対して、python3 <skill-dir>/scripts/rank_candidates.py approval <approval-json>を実行します。バリデーターを利用できない場合、エラーが発生した場合、またはvalid: falseが返された場合は、実行しません。

次のいずれかが発生した場合は選択を無効にし、候補を再提示します。

• 検証済みの肯定的な使用実績が見つかった。
• 対象またはデプロイ済みのリビジョンが実質的に変更された。
• 信頼度が適格性の基準を下回った。
• 廃止の根拠に用いた情報源が古くなった、取得に失敗した、または対象環境と異なっていた。
• 廃止マニフェストまたは不可逆的な影響範囲が拡大した。
• 新たなオーナー承認ゲートが判明した。

更新後の結果は、keep、insufficient evidence、または変更なしとなる場合があります。

7. 承認済みのスライスを1つ実行する

選択した候補を最大1つ実行します。対象リポジトリで通常行われている実装、テスト、レビュー、リリースのワークフローに従ってください。

対象に含まれるすべての領域（コード、テスト、ドキュメント、設定、ジョブ、連携、スキーマ、データ、インフラストラクチャ）から、承認されたスライス全体を削除してください。除外された領域や、別途承認が必要な領域には触れないでください。完全な廃止が安全ではないものの、承認された小規模な簡素化に価値がある場合は、最適化や自動化よりもそちらを優先してください。

編集前に、クリーンなベースラインと、スライスの範囲外の動作を保護する特性評価または使用状況の証拠を記録してください。編集後は、次の点を検証してください。

• 静的な利用側と動的なエントリーポイントが、廃止対象の領域に依存していないこと。
• 意味のあるチェックにより、対象リポジトリの検証要件に沿って、影響を受ける動作と存続する利用側が保護されていること。許可されている場合は対象を絞ったテスト／ビルドを実行し、必須の広範な／全体、依存関係、マイグレーション、変換、統合、リリースのゲートを維持すること。影響が不明、または意味のあるカバレッジが不足している場合は、より広範なチェックを実施するか、明示的なギャップとして記録してください。合格したと推定してはいけません。
• 設定、ジョブ、連携、ドキュメント、アラートが新しい状態と整合していること。
• 該当する場合、マイグレーション、データ、ロールバックの態勢が安全であること。
• デプロイが別途承認されている場合、正確なデプロイ済みリビジョンとデプロイ後の証拠を確認すること。

選択した範囲とその根拠、正確なコマンド、結果、テスト件数、環境、リビジョンを記録してください。ツールの不足、コマンドの失敗、テスト件数ゼロは合格ではありません。独立した受け入れチェックでは、承認済みマニフェストと存続する動作を確認します。変更、失敗、未解決の懸念により必要と判断した場合はチェックを繰り返してください。自動的に全スイートを再実行する必要はありません。設定済みのワークフローとリポジトリのポリシーを確認せずに、CI が完全なゲートを提供すると想定してはいけません。

未オープンまたはマージ済みの PR は、ソース上で廃止が提案された、または反映されたことを示します。デプロイ済みリビジョンとデプロイ後の証拠によってマニフェスト全体の削除が確認されるまでは、本番環境の対象を retired とマークしてはいけません。

出力

必ず次の内容を報告してください。

• モード、リポジトリ、候補の範囲、リポジトリのリビジョン、判明している場合はデプロイ済みリビジョン。
• 証拠のカバレッジ、失敗、見落とし、十分な再発確認期間。
• ランク付けした候補（0～3件）または指定対象の判定。
• 選択したフィンガープリントと承認済みマニフェスト（該当する場合）。
• 実施した変更の正確な内容と、通過していない個別のゲート。
• 検証結果と最終的な候補の状態。
• 正規の課題 URL と読み戻し結果。永続化の許可が与えられていない場合は not-requested、永続的な書き込みが不要な場合は not-needed、永続化が阻止された場合はその理由。

重要なルール

1. 整理ではなく、必要性を調査してください。
2. 実際の使用状況と運用上の義務は、静的な不在より優先されます。
3. テレメトリがない場合は不明であり、ゼロではありません。
4. スケジュール実行は、課題への書き込みが許可されていても、報告のみです。
5. 選択は1つのフィンガープリントとマニフェストに結び付けられます。
6. 証拠または影響範囲が変わった場合、選択は無効になります。
7. 1回の実行で廃止できる候補は最大1つです。
8. PR は本番環境での廃止ではありません。
9. 候補が3件未満であることや、変更がないことは健全な結果です。