anti-entropy-governance

アンチエントロピー

概要

タスクが単なる「コードの変更」ではなく、「エントロピーを増大させずに古い経路を安全に取り除く」ことである場合に、このスキルを使用します。

このスキルでは、次のいずれかを選択します。

• 内部コードの廃止には delete-first
• 実証された外部依存の境界には compat-exception
• 取り消せない状態、または分散先の利用者を把握できない外部コントラクトには confirmation-first

このスキルは、brainstorming、writing-plans、systematic-debugging、verification-before-completion に取って代わるものではありません。廃止、フォールバックの解消、重複する所有者の整理、削除の安全性を扱う、限定的なガバナンスの責任者です。

使用するタイミング

次のいずれかに該当する場合に使用します。

• 古いロジック、重複する所有者、古いフォールバックを廃止すべき場合
• 候補となる修正が「古い経路を削除する」か「別のフォールバックを追加する」かである場合
• 内部のキーワード／フレーズ／トリガーロジックを構造化ロジックに置き換える場合
• 新しい正規の所有者が存在し、古い所有者にも実際の動作が残っている可能性がある場合
• 整理、移行、非推奨化のタスクがスキーマ、永続化、信頼できる情報源、外部互換性の境界に関わる場合
• タスクによって、コードの廃止と稼働中のデータ削除が混同されるおそれがある場合

次の用途には使用しないでください。

• 廃止に関する判断を伴わない、追加のみの機能作業
• ごく小さな文言の修正
• 単純なステータス確認や読み取り専用の質疑応答
• 所有者の統合、フォールバックの整理、削除方法の選択を伴わない通常のバグ修正

自動組み込みの境界

このスキルは他のスキルから組み込まれるべきものです。新しいグローバルなホットパスのエントリにしてはいけません。

次のスキルからの組み込みを推奨します。

• 廃止や永続化のリスクを伴うアプローチの選択では brainstorming
• 古い経路を削除する計画や、スキーマ／移行／永続化に関わる計画では writing-plans
• フォールバックの追加や、削除と保持のどちらかが有力な修正案となる場合は systematic-debugging
• 整理／廃止／互換性／移行の完了処理では verification-before-completion

タスクが所有者の統合、フォールバックの削除、スキーマ／永続化／信頼できる情報源の境界に関わる場合は、自動的に読み込みます。自動読み込みが行うのは特定と助言のみです。破壊的な操作の実行には、対象を明示したユーザーの確認が引き続き必要です。

基本原則

内部の履歴を残すのではなく、内部のエントロピーを減らすことを基本とします。

廃止の対象は、担い手ではなく責任の範囲から決めます。まず、廃止すべき権限、または重複した権限を特定してください。同じ担い手に、別途根拠が示された正当な役割がある場合は、無効な責任だけを取り除き、その役割に限定した機能のみを残します。これは互換性の例外には該当しません。正当な責任がなくなった時点で、その担い手に delete-first を適用してください。利用者が不明であることだけを理由に、内部の担い手を残すべきではありません。

次のルールを適用します。

• 内部コードの廃止 → delete-first
• 外部互換性の境界 → アクティブな依存関係の根拠がある場合は compat-exception。分散が実証されている一方で利用者を把握できない場合は confirmation-first
• 永続状態、または取り消せない信頼できる情報源のオブジェクト → confirmation-first

不明であることだけでは、外部依存関係の証明にも、内部コードへの delete-first の適用を妨げる理由にもなりません。分散が実証された後は、利用者を把握できないことも削除が安全である証明にはなりません。読み取り専用で調査してください。編集前に、具体的な外部リスクを明示的に受け入れる、ユーザー自身が記述した対象を限定する許可を求めてください。十分な情報に基づく指示に、その許可がすでに含まれている場合もあります。それ以外の場合は、リスクを開示して対象を限定した確認を求めてください。

破壊的操作のルールへの言及、読み込み、説明は、破壊的な実行を許可するものではありません。ユーザーから対象を限定した明示的な確認がない場合は、次のことをしてはいけません。

• 取り消せない削除を実行する
• 破壊的なツール呼び出しを行う
• 次のアクションとして、実行可能な破壊的コマンドを提示する
• 広範な同意を削除の承認として解釈する

削除対象の分類

まず、削除対象を分類します。

• code-retirement

  • ソースコード
  • 内部トリガー
  • 重複した所有者
  • 古くなったフォールバック分岐
  • 互換性のためだけに残されているコード
  • 削除された内部動作に関連する不要なテストや設定

• contract-carrying code

  • スキーマ定義ファイル
  • マイグレーションファイル
  • パブリック API の契約コード
  • ホストのインストール／検出コード
  • 永続化の読み書きロジック

• live-state mutation surface

  • ライブデータベース、オブジェクトストア、キュー、その他の永続状態を変更するコードまたはコマンド

• derived-state

  • 再構築可能なキャッシュ
  • 生成されたインデックス
  • 一時的なエクスポート
  • 再計算可能なアーティファクト

• persistent-state

  • ライブデータベースのテーブル／カラム／行
  • 信頼できる情報源となるオブジェクトストレージのファイル
  • ユーザーレコード
  • 権限／ID／メンバーシップのレコード
  • 監査／課金／取り消し不能なビジネスレコード
  • 再構築できないキューまたはイベントの内容

分類ごとのデフォルトの進め方

• code-retirement -> delete-first
• contract-carrying code -> Core Principle に従って分類します。内部のみで使われるものの廃止には、高リスクの検証を伴う delete-first を使用します
• live-state mutation surface -> 調査して分類します。破壊的な実行が persistent-state に及ぶ場合は、引き続き確認が必要です
• derived-state -> まず再構築可能であることを確認し、その後に判断します
• persistent-state -> confirmation-first

重大な停止条件

対象が persistent-state またはその他の取り消し不能な信頼できる情報源である場合：

• 削除を自動で実行しないでください
• 次のアクションとして、実行可能な破壊的コマンドを出力しないでください
• 破壊的なツールを呼び出さないでください
• 一般的な同意を確認とみなさないでください
• 対象範囲を明示したユーザーの確認を求めてください
• 該当する場合は、バックアップ／ロールバック／移行に関する注記を求めてください

確認が必要な例：

• DROP TABLE
• DROP COLUMN
• TRUNCATE
• 実際のビジネスデータの一括削除
• 信頼できる情報源となるアップロード済みファイルの削除
• 権限、ID、監査、課金、メンバーシップのレコードの削除
• 再構築できないキューまたはイベントストリームの消去

データ破壊ガード

confirmation-first によって persistent-state または取り消し不能な信頼できる情報源が保護される場合は、通常の廃止フローを停止して、次を出力します。

Data Destruction Guard:
- Target Class:
- Exact Target(s):
- Environment:
- Why Irreversible:
- Backup / Rollback Note:
- Allowed Read-Only Next Steps:
- Blocked Destructive Steps:
- Confirmation Required: yes
- Status: awaiting scoped confirmation

対象範囲を明示した確認がある場合にのみ続行できます。「OK」「続けて」「よさそうです」などの大まかな同意では不十分です。対象範囲が少しでも変わった場合、以前の確認は無効となり、改めて確認が必要です。

エントロピー対策の宣言

削除の前に、次を示します。

Anti-Entropy Declaration:
- Deletion Class:
- Old Path/Object:
- Invalid Responsibility / Authority:
- Legitimate Capability Remaining on Carrier:
- New Canonical Owner:
- Expected Preserved Behavior:
- Expected Retired Behavior:
- External Boundary Touched: no | yes
- Source-of-Truth Data Risk: none | possible | confirmed
- User Confirmation Required: no | yes

外部依存が不明なコードでは、ユーザー自身の指示に具体的な外部リスクが記載され、そのリスクによって起こり得る破損が了承され、正確な廃止範囲が承認されている場合、またはリスクを開示した後にユーザーが対象範囲を明示して確認した場合を除き、User Confirmation Required を yes にします。一般的な削除依頼だけでは、この欄を満たしません。外部で使用されていることを単に認識しているだけの場合や、こちらがリスクを要約しただけの場合から、了承が得られたと推測しないでください。

User Confirmation Required: yes の場合、通常の delete-first フローを停止します。persistent-state または取り消し不能な対象は Data Destruction Guard に進みます。外部依存が不明なコードは、以下の Retirement Decision で保留します。

廃止の判断

次の経路から一つだけ選択します。

Retirement Decision:
- Path: delete-first | compat-exception | confirmation-first
- Why:
- Non-edits:

ルール：

• より強い境界によって阻まれない限り、内部での廃止には delete-first を選択します
• 外部依存が実証されている場合に限り、compat-exception を選択します
• 取り消し不能な対象、または利用者を特定できないことが実証されている配布対象には confirmation-first を選択します

Path = confirmation-first の場合、対象範囲を明示した確認が得られるまでは、破壊的な実行を行ってはいけません。外部依存が不明なコードについては、以前の一般的な削除指示は確認とみなされません。情報に基づいた、対象範囲を明示したユーザーの指示によって、リスクを開示する前に確認が成立する場合があります。それ以外の場合は、リスクを開示し、編集する前に正確な廃止範囲についてユーザーに直接確認してください。確認が必要だと述べるだけにしたり、必要な言葉を引用したりしないでください。

検証計画

「テストがすべて成功した」ことだけで検証してはいけません。古いロジックが実際に取り除かれ、新しいオーナーが実際にその動作を担っていることを確認してください。

Verification Plan:
- Main-path check:
- Lingering-reference check:
- Negative check:
- Boundary check:

意味：

• Main-path check：新しい正規のオーナーが、意図した動作を引き続き満たしている
• Lingering-reference check：廃止した責務が有効なまま残っていない。担い手が削除された場合、メインパスから古い経路が参照されなくなっている
• Negative check：廃止したトリガー／経路が実際に動作しなくなっている
• Boundary check：ホスト／API／スキーマ／永続化の境界を誤って壊していない

ギャップの分類

削除後にギャップが見つかった場合は、修復する前に分類してください。

• expected-retirement
• missing-owner-logic
• stale-internal-consumer
• baseline-gap
• external-compat
• persistent-state-risk

persistent-state-risk は通常の修復分岐ではなく、作業停止の条件です。

ギャップの解消

修復の順序：

• expected-retirement
  • テスト、ドキュメント、または呼び出し元の期待値を更新する
• missing-owner-logic
  • 新しい正規のオーナーを修正する
• stale-internal-consumer
  • 内部コンシューマーを移行する
• baseline-gap
  • まず要件／仕様／ベースラインを修正する
• external-compat
  • 有効な外部依存の証拠がある場合に限り、互換性を維持する
• persistent-state-risk
  • 作業を停止し、ユーザーに確認を求める

この契約を使用してください：

Gap Closure:
- Gap Found:
- Gap Type:
- Repair Action:
- Reintroduced Compat: no | yes
- If yes, External Dependency Evidence:
- Retirement Trigger:

Gap Type = persistent-state-risk の場合は、作業を停止し、確認ゲートに戻ってください。破壊的な修復を独断で行ってはいけません。

互換性例外ゲート

以下の条件をすべて満たす場合に限り、維持が許可されます。

• 外部境界に影響がある
• 現在有効な依存関係の証拠がある
• 削除すると公開済みまたは文書化された契約に違反する
• 現在のスライスではオーナーの修復またはコンシューマーの移行を完了できない
• 観測メトリクスがある
• 廃止トリガーがある

これらを満たさない場合は、互換性を維持してはいけません。

完了の意味

完了の主張は、実際の結果を反映しなければなりません。

• 内部では廃止したものの、古い互換性を維持している場合 → クリーンな廃止ではなく、bounded mitigation または deferred debt
• 十分な証拠を伴って外部互換性を維持した場合 → bounded compatibility exception
• スコープを明示した確認なしに永続状態を削除した場合 → 未完了

よくある間違い

以下のことをしてはいけません。

• 依存関係が不明であることを、依存関係の証拠として扱う
• 証明された外部境界があるにもかかわらず、有効な依存関係の証拠がないことを、削除しても安全である証拠として扱う
• 「安全のため」として両方のオーナーを有効なままにする
• ギャップが新しいオーナー側で解決すべきものか確認する前に、フォールバックを追加する
• 移行ファイルの削除と、稼働中のデータベースの削除を混同する
• 信頼できる情報源のデータのクリーンアップを、通常のコードの廃止として扱う
• 古いロジックがメインパスの動作を依然として担っているのに、タスクを「クリーンアップ済み」と呼ぶ
• ある担い手の権限が無効だったというだけで、その担い手に証拠で裏付けられた別の正当な役割が残っているにもかかわらず、担い手を削除する
• 警告やガードカードを、破壊的な変更の許可として扱う

最小限の報告形式

この形式は、アンチエントロピーのワークフローにおける判断材料であり、別個の最終完了報告ではありません。アンチエントロピーが完了したタスクに実質的な影響を与えた場合、維持／廃止した動作、削除の分類、維持した境界、検証計画、残存リスクを、verification-before-completion の統合 Aegis 影響／安全性レシートに反映してください。

Aegis Visibility:
Anti-Entropy Declaration:
Retirement Decision:
Verification Plan:
Gap Closure:

既定では簡潔な形式を使用してください。タスクのリスクに応じて必要な場合にのみ詳述してください。