maintain

スキルのメンテナンス

脳の定期的な健全性チェックとクリーンアップ。

契約

このスキルでは、次のことを保証します。

• すべての健全性の側面（古さ、孤立、リンク切れ、相互参照、バックリンク、引用、分類、タグ）を確認します
• 見つかった問題には、それぞれ具体的な修正アクションがあります
• バックリンクの絶対原則を徹底します
• 引用形式が標準に準拠しているか検証します
• 各側面の件数を添えて結果を報告します

フェーズ

所有権の問題は調査の境界です

通常のメンテナンス、起動時のチェック、doctor --fix、「壊れているものを修正して」という依頼は、書き込みトポロジーの変更を許可するものではありません。owner_unavailable または書き込み調整の拒否が発生した場合は、まず選択したホストで gbrain sources writer status --brain <id> --json を調べ、所有者、エポック、有効状態、ブロックされている復旧手順をオペレーターに報告してください。チェックアウトの作成、マネージドモードの有効化、所有者の移行、ID の置き換え、修復としての所有権マーカーの削除を行ったと主張してはいけません。ステータスが enabled: false で、拒否理由が unbound_source の場合、その脳は意図的にクラシックモードで動作しています。書き込みはチェックアウト（ファイル、コミット、gbrain sync）を通じて行われることを報告し、クラシックモードのままにしてください。 意図的な管理操作には、別途承認されたトポロジー変更と、docs/architecture/topologies.md に記載された、操作固有の意図および確認済みの状態前提条件が必要です。TTY、--yes、--confirm-quiesced のいずれも、その決定の代わりにはなりません。リモート認証情報はローカルの書き込み管理に使用できません。

自律パス（v0.36.4.0）—目標スコアを達成したい場合

ユーザーが「脳のスコアを90/100にして」または「壊れているものを修正して」と依頼した場合は、まずプレビューを表示し、適用する前に確認してください。

gbrain doctor --remediation-plan --json              # preview: job steps + repair steps
# Show the user the repair steps (each "requires user agreement") and the cost.
# Only after the user agrees (plan_hash from the preview binds the approval):
gbrain doctor --remediate --yes --include-repairs --expect <plan_hash> --target-score 90 --max-usd 5

--remediation-plan は、依存関係の順に並べたジョブ手順の一覧（抽出の前に同期、統合の後に埋め込みなど）を、各手順の est_seconds と est_usd_cost とともに表示します。また、スコア目標に関係なく、保留中の項目がある gbrain repair のすべての種類について、保護対象の修復手順も表示します。各手順には適用する正確なコマンドが含まれ、計画の最後には、それらをまとめたコマンドが表示されます。 --remediate は --include-repairs が指定された場合にのみ修復手順を実行します（これはユーザーの同意を示します。指定がない場合、修復手順はスキップとして一覧表示されます）。その後、ジョブ計画を順に進め、各手順を Minion ジョブとして送信し、手順ごとにスコアを再確認します。 --max-usd N は実行中および各 --resume に適用される累積コスト上限です。上限を超える有料手順は開始されませんが、無料の手順は引き続き実行されます。実行が停止した場合、上限と同意を維持する再開コマンドが表示されます。

脳で目標スコアを達成できない場合（エンティティページがない空の脳では graph_coverage が70で上限に達する、埋め込みキーが未設定の場合は60で上限に達する）、ジョブ手順は不足項目の一覧を表示して停止し、繰り返し実行されることはありません。含まれている修復手順は引き続き実行されます。--json を指定すると、各検出結果は cleared、pending、consent_required、operator_required（指示に従ってください）、または unsupported（報告してください。現時点では解消する方法がありません）に分類されます。アップグレード後は、docs/guides/repair.md#recover-after-upgrading-to-this-release の手順に従ってください。

次の場合は、以下の側面ごとの確認手順（フェーズ2以降）を使用してください。

• ユーザーが側面ごとの監査を明示的に依頼した場合
• スコアが --remediate の上限より低い状態で止まっている理由を調べる場合
• 自動パスでは対応できない、手動判断が必要な特定の側面がある場合

手動パス

1. 健全性チェックを実行します。 gbrain の健全性を確認（get_health）してダッシュボードを取得します。get_health には管理者スコープが必要です。管理者スコープがない場合は、読み取りスコープの get_brain_health を呼び出してください。これは指標（書き込み容量、書き込み失敗、ゴーストページ、検索不能なチャンク）のみを返すため、回答できない側面、すなわち古いページ、孤立ページ、リンク切れ、埋め込みの網羅率、リンク数とタイムライン数、脳のスコアは確認対象から外します。レポートには確認を省略した側面を明記し、管理者トークンを求めるか、脳のホスト上で gbrain doctor --json を実行するよう依頼して、これらの側面も確認してください。
2. 各側面を確認します。

古いページ

最新のタイムラインエントリより compiled_truth が古いページです。最近の証拠が反映されるよう、評価が更新されていません。

• ヘルス出力で古いページの件数を確認します
• 古いページごとに、gbrain からページを読み込み、タイムラインを確認して、compiled_truth を書き換える必要があるか判断します

孤立したページ

被リンクが 0 件のページです。どこからも参照されていません。

• 孤立したページを確認し、本当に孤立しているのか、リンクが不足しているだけなのか判断します
• 関連ページから gbrain 内でリンクを追加するか、削除対象としてフラグを付けます

リンク切れ

存在しないページを指すリンクです。

• gbrain 内のリンク切れを削除します

相互参照の不足

エンティティ名に言及しているものの、正式なリンクがないページです。

• gbrain から compiled_truth を読み込み、エンティティへの言及を抽出して、gbrain 内にリンクを作成します

リンクグラフの抽出

link_count が 0、または page_count に対して少ない場合は、一括抽出を実行します。

gbrain extract links --dir ~/brain

すべての Markdown ファイルをスキャンして、エンティティへの参照、See Also セクション、フロントマターのフィールドを探し、データベースに型付きリンクを作成します。

タイムラインの抽出

timeline_entry_count が 0 の場合は、Markdown から構造化されたタイムラインを抽出します。

gbrain extract timeline --dir ~/brain

ドリームサイクル（v0.23）：統合＋パターン

gbrain dream は完全なメンテナンスサイクルを実行します（主要なフェーズを表示。atoms／concepts／drift などのオプトインフェーズはその間に入ります）。

lint -> backlinks -> sync -> synthesize -> extract -> patterns -> embed -> orphans

fence_repair は各メンテナンスパスで sync の直後に 1 回実行されます。sync が保留した事実や、ページに不正な形式で保存された事実を修復します（gbrain repair fences がプレビューするのと同じ計画です）。実行時間は最大 300 s、またはジョブの残り時間の 3 分の 1 までです。次回の実行時に再開します。content_repair はその直後に実行されます（#6377）。コンテンツ修復レーンの残りの処理で、現在は slug-conflicts 種別が対象です。余分なフロントマターの slug: を削除するか、人物の推奨マージを記録します（gbrain repair content は両方の種別をプレビューします）。実行時間は最大 120 s、または残り時間の 3 分の 1 までです。gbrain config set fences.repair.enabled false で両方を一時停止できます。

新しい 2 つのフェーズは、昨日の会話を長期記憶に統合します。 統合フェーズ（二段階カスケード）： dream.synthesize.session_corpus_dir のトランスクリプトを読み込み、処理にコストをかける前にトリアージします。低コストのユーティリティ層判定モデル（models.dream.triage）が新規ファイルをすべて対象に、顕著性を 0～1 で評価し、引用候補とエンティティを事前抽出します。これらは判定に使用したモデルとプロンプトのバージョンとともに dream_verdicts にキャッシュされます（1 サイクルあたりの処理時間は dream.triage.max_ms で制限され、デフォルトは 5 分です。処理が延期されたファイルは次のサイクルで再試行され、暗黙に却下されることはありません）。ファイルは次のいずれかの条件を満たすとゲートを通過します。スコアが dream.triage.threshold（デフォルトは 0.5）以上であること、または検証済みセグメントによる救済が働くことです。スコアが [dream.triage.rescue_floor, threshold) の範囲でも、判定モデル自身が引用したセグメントのうち、少なくとも dream.triage.rescue_min_segments 件（デフォルトは 2。0 で無効化）の部分文字列がトランスクリプト内に存在し、かつコンテンツタイプが dream.triage.rescue_content_types の対象（デフォルトは mixed,reflection,idea,strategy,people。routine と technical は対象外）であれば通過します。この救済に追加コストはかかりません（追加の LLM 呼び出しはなく、キャッシュ済みの判定結果を再読み込みします）。これにより、一見ありふれたトランスクリプトに埋もれた実際に有用な情報を拾い上げます。ゲート全体は読み込み時に適用されるため、閾値や救済の設定を調整しても、新たな LLM 呼び出しなしで再判定できます。通過したファイルは、トランスクリプトのチャンクごとに 1 つの統合サブエージェントへ振り分けられ、各サブエージェントにはトリアージマップがあらかじめ渡されます。デフォルトでは各子エージェントは oneshot モード（dream.synthesize.mode、デフォルトは oneshot）で動作します。LINK CANDIDATES マニフェスト（dream.synthesize.link_manifest、デフォルトで有効）と書き込み許可リストを含むプロンプトに対して、ツールを使わずに 1 回だけ補完を行い、ページをプログラムで書き込む前にエンドツーエンドで検証します（スラッグの制約、タスクの形式、ウィキリンク）。検証に失敗した応答は、同じジョブ内で従来のエージェント型ループにフォールバックし、その場合は dream.synthesize.max_turns の上限（デフォルトは 16）が適用されます。元に戻す場合は、次を実行します：gbrain config set dream.synthesize.mode agentic。各子エージェントはリフレクション（wiki/personal/reflections/...）とオリジナル（wiki/originals/ideas/...）を書き込みます。人物のタイムライン項目が書き込まれるのはエージェント型パス（フォールバック時または mode agentic）のみで、その場合は子エージェントに add_timeline_entry ツールが提供されます。オーケストレーターは subagent_tool_executions からスラッグを収集し（pages.updated_at ではありません。無関係な書き込みまで取得してしまうためです）、収集したページに対して引用の検証処理（以下を参照）を実行し、新しい各ページを DB からディスク上の Markdown に逆レンダリングします。閾値や救済の設定を調整した後にゲートを再適用する場合、またはキューにたまったファイルを処理する場合は、gbrain dream retriage --dry-run（LLM 呼び出しなしで、キャッシュ済みスコアのみを使用）を実行し、続けて gbrain dream retriage --reconcile-queue を実行します。--force を指定すると、すべてを最初から再判定します。再トリアージではサイクルと同じゲートを参照するため、キューの調整処理によって救済対象となったジョブが取り消されることはありません。

主張の検証（書き込み後、LLM 呼び出しなし）： スラッグの収集後、逆書き込みの前に、dream.synthesize.quote_verify（デフォルトで有効）が、このフェーズの子エージェントが書き込んだ各ページを、そのページの生成元となったトランスクリプトと照合します。今回の実行で作成されたページは全体を検証し、既存のページは今回の実行で追加された文のみを検証します。完全一致する引用はそのまま残します。空白、スマートクォート、ダッシュ、大文字・小文字のみが異なる引用や、同一話者の発言内での近似した言い換えは、トランスクリプトからの逐語的な抜粋に置き換えられます。引用がどこにも見つからない場合、複数の話者の発言をまたいでしか見つからない場合、実際の引用を誤った話者に帰属させている場合、またはトランスクリプトにない数値や日付を記載している場合、その文は隔離されます。隔離された文はページ本文から取り除かれ（そこから派生したタイムライン、ファクト、リンクからも取り除かれます）、フロントマターの unverified_claims に原文のまま保存されます。get_page では表示されますが、検索、リコール、思考処理では読み込まれません。根拠が確認された引用は、出典の範囲と話者を grounding.quotes に記録します。内容が捏造されることはありません。テレメトリは details.synthesis.quote_verify に記録されます。この設定キーは、問題発生時に機能を停止するためのスイッチです。 パターンフェーズ： extract の後に実行されます（グラフの状態が最新のため）。 dream.patterns.lookback_days（デフォルトは 30）の期間内の最近の振り返りを読み込み、 Sonnet による 1 回のパスで繰り返し現れるテーマを抽出し、1 つのパターンを裏付ける振り返りが dream.patterns.min_evidence （デフォルトは 3）件以上ある場合に、パターンページを wiki/personal/patterns/<theme> に書き込みます。実行が完了すると、処理した最新の振り返りが記録されます（dream.patterns.last_evidence_ts）。期間内にこれより新しい振り返りがない限り、再実行時は追加のモデル処理を実行せず、no_new_evidence でスキップされます。gbrain dream --phase patterns --once を指定すると、強制的に 1 回実行します。

品質基準（統合における鉄則）：

1. ユーザーの発言を逐語的に引用します。引用符を使えるのは、会話記録から正確に再現できる部分だけです。正確に再現できない場合は、引用符を使わずに言い換えてください。正確に引用できる印象的な表現を言い換えてはいけません。（書き込み後に、引用の検証パスで機械的にチェックされます。）
2. 関連付けを徹底します。新しいページには、少なくとも 1 つのウィキリンクが必須です。
3. スラッグの規則：小文字の英数字とハイフンのみを使用します。アンダースコアやファイル拡張子は使用しないでください。
4. 編集された会話記録には、新しいスラッグを割り当てます（コンテンツハッシュのサフィックスが変わります）。暗黙の上書きは決して行いません。
5. 具体的な事実を保持します。重要な内容に含まれる具体的な数値、日付、金額、名前、誰が何を決定したかを、会話記録の記述どおりに引き継ぎます。定型的な事務連絡で水増ししないでください。
6. すべての主張を会話記録に根拠付けます。推測は推測として明示し、会話記録に示されていない完了状態や結果を決して記載しないでください。

信頼境界（allowed_slug_prefixes）： 統合サブエージェントには、_brain-filing-rules.json の dream_synthesize_paths.globs をもとにした、書き込みパスの明示的な許可リストが設定されています。プロンプトインジェクションに成功した場合でも、サブエージェントはこのリスト外には書き込めません。信頼の根拠は PROTECTED_JOB_NAMES です。MCP はサブエージェントのジョブを一切送信できません。合成処理が書き込める新しいディレクトリを追加するには、JSON を編集する以外に方法はありません。

冪等性とプライバシー： 会話記録は (file_path, content_hash) をキーとして管理されるため、同じ内容で再実行しても何も起きません。dream.synthesize.exclude_patterns（デフォルトは ["medical", "therapy"]）は、LLM 呼び出しの前に会話記録を除外します。各エントリは単語境界の正規表現として自動的にラップされます（例：medical は「medical advice」には一致しますが、「comedical」には一致しません）。上級ユーザーは正規表現をそのまま指定できます。

クールダウン： dream.synthesize.cooldown_hours（デフォルトは 12）は、すべての処理が完了した実行の後、指定時間だけ synthesize をスキップします。完了時刻は dream.synthesize.last_completion_ts に保存され、すべての子処理が完了し、保留された処理（合成予算、トリアージの時間予算、公開待ち）がない場合にのみ書き込まれます。スキップまたは失敗した実行では書き込まれません。そのため、未処理のタスクが残っている間はクールダウンは適用されず、未処理分がなくなるまで synthesize は各サイクルで実行されます（#6753）。これは 1 日あたり約 2 回という上限ではありません。費用を制限するには、dream.synthesize.max_submissions_per_source_per_day を使用してください。--input／--date／--from／--to を明示して実行した場合、クールダウンは適用されません。

--dry-run の動作： スコア付きトリアージパスを実行します（新しいファイルを評価し、判定結果をキャッシュします）が、合成サブエージェントはスキップします。LLM 呼び出しがゼロになるわけではありません。キャッシュ済みのスコアを使って呼び出しなしでプレビューするには、代わりに gbrain dream retriage --dry-run を使用してください。

新しい brain で synthesize を設定する：

gbrain config set dream.synthesize.session_corpus_dir /path/to/transcripts
gbrain config set dream.synthesize.enabled true
gbrain dream --phase synthesize --dry-run --json   # preview
gbrain dream                                       # full cycle

実行パターン：

gbrain dream                                          # full cycle
gbrain dream --phase synthesize                       # just synthesize
gbrain dream --phase patterns                         # just patterns
gbrain dream --input ~/transcripts/2026-04-25.txt     # ad-hoc one transcript
gbrain dream --from 2026-04-01 --to 2026-04-25        # backfill range
gbrain dream --json                                   # CycleReport JSON

自動コミットは v1.1 に延期： v1 ではファイルを brain_dir に書き込みますが、git add／commit／push は実行しません。自分でコミットするか、gbrain autopilot に処理させてください。 - **YYYY-MM-DD** | Source — Summary と ### YYYY-MM-DD — Title の形式を解析します。 Source — Summary のダッシュには、em ダッシュ、en ダッシュ、またはスペースで区切られたハイフン（-）を使用できます。 コロン（Source: Summary）は文章として扱われるため、その行の source: markdown は維持され、テキスト全体が要約になります。 注：抽出されたエントリーは構造化クエリ（gbrain timeline）の精度を高めますが、ベクトル検索には影響しません。

Autopilot の確認

Autopilot が実行中か確認します：

gbrain autopilot --status

終了コードは判定に信頼して使用できます。0 は新しい状態（または未インストール）、1 は要対応（ハートビートが古い、未実行、または移行によって一時停止中）、2 はデーモンが自動的に無効化された状態（リポジトリのパスが消失）です。--json はレポート全体（state、heartbeat_age_seconds、paused_reason、disabled_reason）を出力します。ステータス確認ではファイルシステムのみを読み取るため、データベースが停止していても動作します。

実行されていない場合は、インストールします：

gbrain autopilot --install --repo ~/brain

Autopilot は、適応型スケジューリングで同期、抽出、埋め込みを継続的なループで実行します。 v0.11.1 以降、Autopilot は各サイクルを単一の autopilot-cycle Minion ジョブとしてディスパッチし、ワーカーチャイルドを監視します。インストール手順を一度実行するだけで、同期、抽出、埋め込み、バックリンク、永続的なジョブ処理を利用できます。

移行が途中で止まったインストールの修正

移行スキルが一度も実行されなかった v0.11.0 のインストールでは、Minions の設定が不完全な状態になります。スキーマは適用されていますが、~/.gbrain/preferences.json が存在せず、Autopilot はインラインで実行され、ホストのマニフェストは引き続き agentTurn を参照しています。修復するには：

# Check migration status
gbrain apply-migrations --list

# Apply pending migrations (idempotent; safe on healthy installs)
gbrain apply-migrations --yes

# If host-specific handlers are flagged in ~/.gbrain/migrations/pending-host-work.jsonl:
# walk them per skills/migrations/v0.11.0.md + docs/guides/plugin-handlers.md,
# ship handler registrations in the host repo, then re-run apply-migrations.

トラブルシューティングガイド全文：docs/guides/minions-fix.md。

バックリンクの徹底

バックリンクに関する鉄則が守られているか確認します：

• 最近更新された各ページについて、そのページで言及されているエンティティのページから該当ページへのバックリンクがあるか確認します
• 言及があるのにバックリンクがない場合、脳が壊れています
• 修正方法：エンティティの Timeline または See Also セクションに、足りないバックリンクを追加します
• 形式：- **YYYY-MM-DD** | Referenced in [page title](path) -- brief context

ファイル配置ルールへの違反

よくある誤ったファイル配置のパターンを確認します（skills/_brain-filing-rules.md を参照）：

• 主要な対象が明確なコンテンツが、適切なディレクトリ（people/、companies/、concepts/ など）ではなく sources/ に配置されている
• gbrain の検索を使って、特定の人物、企業、概念に言及している sources/ 内のページを探します。誤った場所に配置されている可能性があります
• 配置場所が誤っているページにフラグを立て、レビューまたは再配置を行います

引用の監査

ページを抜き取り確認し、[Source: ...] の引用が欠けていないか確認します：

• 最近更新されたページを 5～10 件読みます
• まとめられた事実（上の行より上）にインライン引用があるか確認します
• タイムラインのエントリーに出典の帰属があるか確認します
• 事実が出典情報なしで記載されているページにフラグを立てます

タグの一貫性

タグの表記が一貫していない状態（例：「vc」と「venture-capital」、「ai」と「artificial-intelligence」）。

• gbrain のタグ操作を使って、最も一般的な表記に統一します

グラフの構築（v0.10.3+）

links テーブルと timeline_entries テーブルは、構造化グラフレイヤーです。 定期的に、または大規模なインポート後にデータを登録してください。

• gbrain extract links --source db — ページをたどり、構造化リンクをバックフィルします。 エンジンから読み込みます。[Name](people/slug)／[Name](companies/slug) の参照を読み取り、 関係の種類（attended、works_at、invested_in、founded、 advises、mentions、source）を推測します。冪等です。代わりに Markdown のチェックアウトを たどる場合は、--source fs --dir <brain> を使用してください。
• gbrain extract timeline --source db — 構造化タイムラインエントリをバックフィルします。 ページコンテンツから - **YYYY-MM-DD** | summary の行を解析します。冪等です（DB の UNIQUE 制約）。
• gbrain extract all --source db — 1 回の実行で両方を行います。
• gbrain graph-query <slug> --depth 2 — 接続状況を確認します（プローブとして、よく知られた任意の エンティティスラッグを使用してください）。
• gbrain stats — 抽出後に link_count > 0 と timeline_entry_count > 0 であることを確認します。
• gbrain health — エンティティページ（人物／企業）の link_coverage と timeline_coverage の割合を 確認します。50% 未満の場合は、さらに抽出が必要です。エンティティページがごく少ないナレッジベースでは、 誤解を招く 0%／100% ではなく「評価するには少なすぎます」（JSON では null、分母は entity_page_count）と表示されます。カバレッジを評価する前に、エンティティの範囲を広げてください。

利用可能なリンクの種類（gbrain graph-query --type で使用）： attended、works_at、invested_in、founded、advises、mentions、source。

今後は、すべての gbrain put 呼び出しで、リンクが自動作成され、照合されます （自動リンクの後処理フックによる。デフォルトで有効。無効にするには gbrain config set auto_link false を実行します）。 そのため、リンク抽出は基本的に一度だけ行うバックフィルです。新しい日付付きエントリを追加する一括インポートや コンテンツ編集の後は、タイムライン抽出を再実行してください。

機能の導入状況の確認（週次）

gbrain features --json    # scan for underused features + recommendations

lint とあわせて毎週実行します。埋め込みの不足、未使用の連携機能、 設定の改善点を見つけます。

埋め込みの鮮度

まだ埋め込みがないチャンクです（--stale はそのチャンクだけを選択します）。埋め込み処理では 設定済みプロバイダーを呼び出し、トークンごとに課金されます。これは有料の処理なので、 事前にユーザーの承認が必要です。

1. プロバイダーを呼び出さずにプレビューします：gbrain embed --stale --dry-run。
2. チャンク数と推定コストをユーザーに伝え、返答を待ちます。
3. ユーザーの同意を得た後に限り、承認された上限額を指定して gbrain embed --stale --yes --max-usd <cap> を実行します。

承認がない場合、このコマンドは終了コード 3 で停止し、ユーザーに尋ねるよう求める [AGENT] ブロックを出力します。 その内容をユーザーに伝えて、処理を停止してください。独自の判断で --yes を指定してはいけません。 実行対象が 1000 チャンクを超える長時間処理の場合、承認されたコマンドはそのままバックグラウンドシェルで実行せず、 skills/minion-orchestrator/SKILL.md にある永続化された段階的手順を通してください。バックグラウンドシェルでは 終了コード 3 がログファイル内に隠れてしまいます。

1 つのソースについて検索で到達できない対象を確認するには、 gbrain pages unsearchable --source <id> --json を実行します（読み取り専用）。unsearchable だけでなく、 semantic_unsearchable を確認してください。これは keyword_only ページを含みます。このページはキーワード検索では見つかりますが、 ベクトル検索では見つかりません。awaiting_sync は同期処理がまだ保持しているファイル数であり、 どの埋め込み状態にも含まれません。これらについては gbrain sync status --source <id> --json を確認してください。 各行には修正方法を示す fix が含まれています。

セキュリティ（RLS の検証）

gbrain doctor --json を実行して、RLS の状態を確認します。 すべてのテーブルで RLS が有効になっている必要があります。有効でない場合は、もう一度 gbrain init を実行してください。

スキーマの健全性

スキーマのバージョンが最新であることを確認します。gbrain doctor --json は、 現在のバージョンと期待されるバージョンを報告します。古い場合は、gbrain init が自動的にマイグレーションを実行します。

ファイルストレージの健全性

保存されたファイルとリダイレクトポインターの整合性を確認します。

• gbrain files verify を実行して、すべての DB レコードに有効なデータがあることを確認します
• gbrain files status を実行して、移行状態（ローカル、ミラー済み、リダイレクト済み）を確認します
• 存在しないストレージファイルを参照する孤立した .redirect.yaml ポインターがないか確認します
• Git に残っている、クラウドストレージに移すべき大きなバイナリファイル（100 MB 以上）がないか確認します
• ストレージバックエンドが設定されている場合：リダイレクトポインターが解決されることを確認します（ダウンロードテスト）

未解決のスレッド

未解決のアクション項目がある、30 日を超えて古いタイムライン項目。

• レビュー対象としてフラグを付けます

ベンチマークテスト

検索品質が低下していないことを定期的に確認します。難易度別にテストクエリを 実行します。

• Tier 1（エンティティ検索）： 既知の名前 — 常に解決されるはずです
• Tier 2（トピック想起）： 概念、トピック — キーワード検索で対応できるはずです
• Tier 3（セマンティック）： 完全一致するキーワードがないクエリ — 埋め込みが必要です
• Tier 4（ドメイン横断）： 関係性やつながりに関するクエリ — セマンティック検索でのみ対応できます

gbrain search（キーワード）と gbrain query（ハイブリッド）の結果を比較します。 速度よりも品質が重要です（間違った結果を200 msで返すより、正しい結果を2.5秒で返す方が重要です）。

ベンチマークを実行するタイミング：

• 大規模な brain のインポートまたは再インポート後
• gbrain のバージョンアップ後
• 埋め込みの再生成後
• 品質の変化を追跡するため、毎月

ハートビートとの統合

スケジュールに従って稼働する本番エージェントでは、gbrain の健全性チェックを 運用上のハートビートに組み込みます。

毎回のハートビート時（1時間ごと、またはセッションごと）

gbrain doctor --json を実行し、劣化がないか確認します。失敗したチェックがあれば ユーザーに報告します。主な指標：接続の健全性、スキーマのバージョン、RLS の状態、埋め込みの 古さ。

毎週のメンテナンス

まだ埋め込みのないチャンクの埋め込みを更新します。上記の「埋め込みの鮮度」と同じ同意手順を 適用します：gbrain embed --stale --dry-run を実行し、見積もりを伝えたうえで、ユーザーの同意後に gbrain embed --stale --yes --max-usd <cap> を実行します（または、ユーザーが設定した consent.preapprove.paid.max_usd_per_run による継続的な承認を使用します）。大規模な brain（ページ数が5000件を超える）の場合、 承認済みのコマンドを minion-orchestrator の耐久性のあるラダー経由で送信します。 シェルでバックグラウンド実行する必要がある場合は、終了コードを保持します：

(gbrain embed --stale --yes --max-usd <cap>; echo "exit=$?") > /tmp/gbrain-embed.log 2>&1 &
tail -2 /tmp/gbrain-embed.log   # later: the last line is exit=<code>

そのログで終了コードが 3 の場合、実行にはユーザーの承認が必要です。ユーザーに伝えて停止します。

毎月のバックアップ確認

gbrain backup status を実行し、赤で表示された項目をすべて伝えます。すべてのナレッジ リポジトリ（およびエージェントのワークスペース）に Git リモートがあることを検証します。ローカルのみに保存されている場合、 ディスク障害によってデータが失われます。修正方法はコマンド内に表示されます（gbrain bootstrap repo、git remote add、 gbrain sources harden <id>）。

毎日の検証

同期が実行中であることを確認します：gbrain stats を確認し、last_sync が過去 24時間以内であることを確かめます。同期が停止している場合、brain の内容がリポジトリと乖離していきます。

古くなったコンパイル済みの真実の検出

コンパイル済みの真実が30日を超えて古い一方で、タイムラインに最近の項目があるページに フラグを付けます。これは、まだ統合されていない新しい証拠があることを意味します。これらのページでは、 コンパイル済みの真実を書き直す必要があります（上記のメンテナンスワークフローを参照）。

レポートの保存

メンテナンスの実行後、レポートを保存します：

• 健全性チェックの結果（各評価項目の実行前後のスコア）
• 検出して修正したバックリンク違反
• 検出したファイリングルール違反
• フラグを付けた引用の不足
• ベンチマークの結果（実施した場合）
• ユーザーの対応が必要な未解決の問題

これにより、brain の健全性を長期にわたって追跡する監査証跡が作成されます。

品質ルール

• 確認を得ずにページを削除しないでください
• すべての変更をタイムライン項目として記録してください
• 改善を示せるよう、前後に gbrain の健全性を確認してください

失敗した場合

gbrain のエラー code、終了コード、[AGENT] ブロック、または通知ブロックが発生した場合は、エージェント運用者プロトコルに従ってください。このスキル固有の項目は次のとおりです。

• gbrain doctor --remediate の手順で「requires user agreement」（保護対象の修復、有料の手順）とマークされたものは、計画と費用を提示し、ユーザーの同意を得た後に限り、--yes --include-repairs --expect <plan_hash> --max-usd <n>（--remediation-plan --json から取得したハッシュを指定）を付けて実行します。preview_changed は計画が変更されたことを意味するため、再度プレビューを表示して確認を求めてください。上限を超える手順は開始されません。
• operator_required に分類された指摘については、その指示に従うか、脳ホストの運用者に伝えてください。consent_required の場合はユーザーに確認してください。
• 書き込み調整による拒否（writer_coordinator_required、writer_not_quiesced、recovery_required）が発生した場合は、gbrain sources writer status を確認し、ブロックされた復旧作業を運用者に引き継いでください。チェックアウトを行ったり、ロックを削除したりしたと主張してはいけません。
• Doctor が persistence_terminal_failures を警告した場合は、その fix.command を実行してください（アクティブなブロッカーである復旧レコードまたは同期チェックポイントのブロッカー、あるいは受領 ID を添えて報告する未解決の gbrain 欠陥クラスが対象です）。残りの項目については、gbrain sources writer failures <source> --group-by category（読み取り専用）を使うと、各グループの修正方法と詳細を確認できます。履歴行は対応不要です。件数を減らすために受領記録を取り消したり編集したりしないでください。手順書：terminal write failures。
• gbrain dream が予算上限に達して停止した場合（終了コード 11）は、合意した予算の範囲内で、表示された resume_command を実行してください。

アンチパターン

• ページを先に読まずに修正すること。編集前にコンテキストを理解する必要があります。
• 確認せずに次元を飛ばすこと。問題がなくても、すべての次元を確認して報告する必要があります。
• 孤立したページを、別のページからリンクすべきか確認せずに削除すること。
• 利用のピーク時間帯に埋め込みの更新を実行すること。
• 関係が実在するか確認せずに、バックリンクを一括修正すること。
• 実際にクエリを実行せずに、次元を「クリーン」とマークすること。
• タイムライン全体を先に読まずに、コンパイル済みの事実を書き換えること。
• 他のページで同じタグが一貫して使われているか確認せずに、タグを削除すること。

出力形式

メンテナンスレポートは次の構成に従います。

## Brain Health Report — YYYY-MM-DD

| Dimension           | Issues Found | Fixed | Remaining |
|----------------------|-------------|-------|-----------|
| Stale pages          | N           | N     | N         |
| Orphan pages         | N           | N     | N         |
| Dead links           | N           | N     | N         |
| Missing cross-refs   | N           | N     | N         |
| Back-link violations | N           | N     | N         |
| Citation gaps        | N           | N     | N         |
| Filing violations    | N           | N     | N         |
| Tag inconsistencies  | N           | N     | N         |
| Embedding staleness  | N           | N     | N         |
| Security (RLS)       | N           | N     | N         |
| Schema health        | N           | N     | N         |
| File storage         | N           | N     | N         |
| Open threads         | N           | N     | N         |

### Details
[Per-dimension breakdown with specific pages and actions taken]

### Benchmark Results (if run)
[Tier 1-4 query results with pass/fail]

### Outstanding Issues
[Items requiring user attention or confirmation]

使用したツール

• gbrain の正常性を確認する（get_health；管理者スコープ）
• 管理者スコープなしでバンド化された脳の正常性を確認する（get_brain_health）
• フィルターを指定して gbrain のページを一覧表示する（list_pages）
• gbrain のページを読み込む（get_page）
• gbrain のバックリンクを確認する（get_backlinks）
• gbrain のエンティティをリンクする（add_link）
• gbrain のリンクを削除する（remove_link）
• ページにタグを付ける（add_tag）
• タグを削除する（remove_tag）
• タイムラインを表示する（get_timeline）