data-loss-gate

データ損失ゲート — 破壊的操作前の確認

規約： conventions/brain-first.md を参照してください — 削除を提案する前に、実際の対象を調査してください：get_backlinks、 gbrain graph <slug>、対象ファイルに対する git log。以下の確認カードの質は、 その根拠となる調査の質に左右されます。

規約： _brain-filing-rules.md を参照してください — 確認後の削除ログファイルは、日付をキーとして daily/ の下に保存します。

これは何か

破壊的な操作の前に必ず発動し、ユーザーによる明示的な確認を求めるゲートです。エージェントは処理を止め、復元可能性カードを提示して、返答を待ちます。

適用範囲に関する注意： このゲートはルーティング規約です。破壊的な意図に一致した場合、ハーネスがその規約をコンテキストに反映し、適切に動作するエージェントがそれに従います。これは操作境界での強制ではありません。スキルが読み込まれなければ、gbrain ランタイムが削除を機械的に阻止することはありません。（操作境界でネイティブに確認を行うゲートは、登録済みの TODO です。実装されるまでは、この規約が防御線となります。）一部の CLI サーフェスには独自のフラグゲートがあります。たとえば gbrain sources remove には --confirm-destructive が必要です。ただし、このフラグで確認するのは、エージェントが確信しているかどうかです。このスキルは、ユーザーが確信しているかどうかを確認するためにあります。

発動するタイミング

次の操作を行う前：

シェル／ファイルシステムレベル：

• データを含むディレクトリに対する rm -rf
• 10 個を超えるファイルに対する rm／unlink
• 10 個を超えるファイルを変更する sed -i
• 管理対象ファイルに対する git rm
• ファイルの内容を一括で切り詰める、または削除する操作
• ファイルの内容を削って、より小さいバージョンで上書きする操作
• データファイルに触れる「クリーンアップ」や「空き容量の確保」と称する操作

ブレイン／データベースレベル（gbrain 固有）：

• 一括忘却 — 多数の事実に対して gbrain forget <fact-id> をスクリプト化またはループ処理で実行すること。1 件の忘却は慎重に行われ、冪等性のある操作です。一括忘却はデータ損失です。
• ページ一括削除 — gbrain delete <slug> をループで実行すること、または一連のスラッグに対して delete_page を一括実行するスクリプト。削除はパージされるまではソフト削除であり、gbrain restore <slug> で復元可能です。カードにその旨を記載したうえで、必ずゲートを通してください。一括削除を誤ると、一括で元に戻すには多大な手間がかかります。
• gbrain pages purge-deleted — ブレインのすべてのソースから、ソフト削除されたページを完全に削除します。これはソフト削除のセーフティネットが機能する最後の時点です。まず gbrain pages purge-deleted --dry-run --json をユーザーに提示してください。このコマンド自体も確認を求め（ターミナルがない場合は終了コード 3）、ユーザーの同意後にのみ --yes を付けて実行します。
• ソースの削除 — gbrain sources remove <id> はソースと、その中のすべてのページを削除します。--confirm-destructive フラグはカードの代わりにはなりません。
• マウントの削除 — gbrain mounts remove <id> が削除するのはローカル登録だけです（マウントされたブレインのデータベースは残ります。再追加すれば復旧できます）。ただし、処理の流れでマウント元のデータベースやファイルも削除する場合は、必ずゲートを通してください。その場合は、それらに対して完全なカードが適用されます。
• 生 SQL による切り詰め — どの経路（psql、マイグレーションスクリプト、エンジンの executeRaw 呼び出し）であっても、ブレインのデータベースに対する DROP TABLE、TRUNCATE、または限定的な WHERE 句のない DELETE。
• データベース行の一括削除、テーブル、コレクション、インデックスの削除。

すること

ステップ 1：実行前に停止する

破壊的なコマンドを実行してはいけません。まず実際の対象を調査し （バックリンク、グラフのエッジ、Git の履歴、ファイルの内容など、カードの根拠となるものを確認して）、 そのうえで次をユーザーに提示します：

ステップ 2：確認カード

⚠️ DATA DELETION — Confirmation Required

What: [exactly what will be deleted/modified]
Count: [number of files/rows/pages/facts affected]
Size: [how much data will be removed]
Location: [exact paths, slugs, or source/mount ids]

Why: [the reason for the deletion]

Recoverable?
- [ ] Backed up to a remote (git remote, database backup, object storage)
- [ ] In git history (can git checkout)
- [ ] Soft-deleted in the brain (restorable via `gbrain restore` until purged)
- [ ] Re-fetchable from an upstream source (which one, how long)
- [ ] NOT recoverable — permanent data loss

What we'd lose:
- [specific data/capability that would be gone]
- [any downstream systems that depend on this data]

Alternative to deletion:
- [compress instead of delete?]
- [move to cold storage?]
- [archive to a remote backup?]
- [soft-delete and defer the purge?]

Proceed? (yes/no)

ステップ 3：「yes」という明示的な返答を待つ

• 「ok」「sure」「go ahead」では進めないでください。「yes」または「do it」を必須とします
• ユーザーが「wait」と言ったり、質問したりした場合は、回答してカードを再提示してください
• ユーザーが「no」と言った場合は、すぐに停止して代替案を提案してください

ゲートの提示とターンの停止の仕組みについては、 ask-user の選択ゲートパターンを使用してください。このスキルでは カードの内容と「yes」を明示的に求める厳格さを定め、ask-user では 停止して待つ手順を定めています。

ステップ 4：ログを記録して実行する

確認後：

1. 削除した内容を daily/notes/YYYY-MM-DD.md の ## Data Deletions の下に記録します
2. タイムスタンプ、対象、件数、サイズ、復元方法を記載します
3. 削除規模が大きい場合（1GB 超または 1000 件超のファイル／ページ）は、分割して進め、進捗を報告します

例外のないクラス

デフォルトで破棄可能なデータのカテゴリはありません。古いログ、git stash のエントリ、ビルド成果物、キャッシュなどは、いずれも過去に何かの信頼できる情報源となったことがあります。破棄可能かどうかは、カテゴリの性質ではなく、対象を調査して確認する属性です（バックリンク、git status、依存関係、再取得の可否とそのコストなど）。調査によって対象が一時的なもので、再生成可能だと実際に確認できた場合は、カードの記入はすぐに終わり、ユーザーからの「yes」もすぐに得られます。ゲートを機能させるためのコストです。

このルールがある理由

かつて、下流のエージェントがディスク容量を空けるために、脳のデータディレクトリにあった数 GB の生ソースファイルのキャッシュを削除しました。ファイルは「ただのキャッシュ」に見えましたが、計画中の機能で使うソースデータでした。そのデータは上流のソースから再取得できましたが、それでも削除は誤りでした。理由は次のとおりです。

1. 利用が計画されていた作業を破壊した
2. データ所有者の同意なしに実行された
3. 「クリーンアップ」という表現によって、安全でないのに安全だと思わせた

ルール：データであり、大量にある場合は、まず必ず確認してください。

失敗した場合

gbrain のエラー code、終了コード、[AGENT] ブロックまたは通知ブロックについては、agent operator protocol に従ってください。このスキルに固有の注意事項：

• 破壊的なコマンドが終了コード 3（confirmation_required）で終了する、または --confirm-destructive を求める場合：このフラグが示すのはエージェントが確信していることだけであり、ユーザーの同意ではありません。復元可能性カードを提示し、ユーザーの明示的な yes を待ってください。
• gbrain pages purge-deleted はソフト削除されたページを完全に削除するため、その後は gbrain restore で復元できません。その旨をカードに記載してください。物理的な消去や、確認できない復元を約束してはいけません。
• 削除または忘却の処理が write_pending（終了コード 10）を返した場合は、削除ログの記録前にレシートをポーリングしてください。

アンチパターン

• ❌ 「これはただのキャッシュファイルです」 — キャッシュファイルが信頼できる情報源の場合もあります
• ❌ 「API から再取得できます」 — 再取得には時間と費用がかかり、同一のデータが得られるとは限りません
• ❌ 「gitignore 対象なので問題ありません」 — gitignore 対象であることは、重要でないことを意味しません
• ❌ 「ディスクがいっぱいなので、今すぐ容量を空ける必要があります」 — 切迫した状況でも、まず確認してください
• ❌ 「先にクリーンアップして、後でユーザーに伝えます」 — 削除前に確認を得る必要があります
• ❌ 「ソフト削除にすぎません」 — 誤った一括削除を元に戻すには、依然として大きな手間がかかります。また、パージすると恒久的な削除になります
• ❌ 「コマンドにはすでに --confirm-destructive が付いています」 — このフラグが確認するのはエージェントの意図であり、ユーザーの同意ではありません
• ❌ 代替案を列挙せず、削除だけを唯一の選択肢として提示する

重複（明確な境界）

• conventions/test-before-bulk.md — 書き込み側の姉妹スキルです。test-before-bulk は大量の WRITE の品質を担保します（170 件を実行する前に 3～5 件をテストします）。data-loss-gate は大量の DESTRUCTION を担保します（一括削除の前に確認します）。ページをその場で書き換えるフローには、両方が必要です。新しいコンテンツには test-before-bulk、書き換えで失われる内容には data-loss-gate を使います。
• ask-user — 確認の仕組み（選択肢を 2～4 個提示する、回避策を設ける、そのターンを停止する、回答を処理する）です。data-loss-gate は、破壊的操作カードと厳格な明示的な「はい」のルール（「ok」は同意ではありません）を提供する、用途を特化した呼び出し元です。破壊的でない判断ゲートでは、ask-user に振り分けてください。
• maintain — 脳の健全性チェックと定期的なクリーンアップ（孤立項目、バックリンク、古くなった項目の検出）を行います。maintain はクリーンアップ候補を見つけます。候補への対応が一括削除に及ぶ場合は、実行前に data-loss-gate が作動します。「脳の健全性をチェックする」は、ここではなく maintain に振り分けてください。

契約

このスキルでは、次のことが保証されます。

• 対象範囲（「When This Fires」のリスト）に含まれる破壊的操作は、確認カードが提示され、ユーザーが明示的に「yes」または「do it」と回答するまで実行されません。
• カードには、復旧可能性のチェックリスト、失われるもの、削除以外の代替案が少なくとも 1 つ必ず含まれます。
• 確認済みの削除は、タイムスタンプ、対象範囲、復旧方法とともに daily/notes/YYYY-MM-DD.md の ## Data Deletions の下に記録されます。
• 振り分けは frontmatter の正式なトリガーに一致します。
• 出力は writes_to: に記載されたディレクトリの下に書き込まれます。
• プライバシーに関する契約が維持されます。実名、フォーク固有のファイルシステムパスのリテラル、上流フォークへの言及は含めません。

完全な動作契約は上記の本文セクションに記載されています。このセクションは適合性テストのために設けられています。

出力形式

成果物は 2 つです。

1. 確認カード（実行前） — Step 2 の正確なフェンス付きブロックを、ask-user の停止して応答を待つパターンで提示します。カードの提示後にターンを終了し、ユーザーの回答があるまでツールを呼び出しません。
2. 削除ログのエントリ（実行後、明示的に「yes」と回答された場合のみ） — daily/notes/YYYY-MM-DD.md に追記します。

## Data Deletions

- **[HH:MM]** [what was deleted] — [count], [size]. Reason: [why].
  Recovery: [backup/git/restore path, or "none — permanent"].