company-brainify

company-brainify — 個人用ブレインからチーム用ブレインへの機微情報の除去

規約： conventions/brain-first.md を参照してください — 情報の探索には、ファイルシステムを手当たり次第に探すのではなく、ブレイン独自の検索機能を使います。 以下の grep パイプラインはトリアージに使います。キーワードパターンで見つからない情報は gbrain query で検索します。

規約： conventions/test-before-bulk.md を参照してください — まず 3～5 個のファイルをサニタイズし、自分で出力を確認してから、対象を増やします。問題のある一括サニタイズは、 何もしないより悪い結果になります。完了したように見えても、実際には完了していないためです。

規約： conventions/regex-discipline.md を参照してください — 「これは機微情報か？」は判断を要するため、モデルがファイルごとに決定します。 grep パターンは、経験に基づくトリアージと検証のためのツールであり、判断基準ではありません。

規約： _brain-filing-rules.md を参照してください — 編集はページの既存のディレクトリ内で行います。削除ログファイルは 日付をキーとして daily/ の下に保存します。

問題

個人用ブレインには、会社の知識、会議メモ、社内評価、報酬の詳細、経営戦略、一緒に働く人々についての率直な意見など、あらゆる情報が蓄積されます。個人用ブレインからチーム共有ブレインを立ち上げる際は（チームマウントの構成については docs/architecture/brains-and-sources.md を参照）、これらをすべて取り除く必要があります。知識には価値がありますが、機微なメタデータはリスクになります。

作業ツリー内のファイルをきれいにするだけでは不十分です。Git の履歴にはサニタイズ前のすべてのバージョンが残り、gbrain のテイクやファクトにも、ページ本文以外に評価的な主張が含まれている可能性があります。このスキルでは、ページ、テイク／ファクト、履歴という 3 つすべてを処理します。

使用する場面

既存の会社リポジトリを編集せずに接続またはインデックス化することは、サニタイズではありません。「会社のブレインを接続する」または「既存の会社ブレインをインポートする」場合は、migrate（ホスト側）の会社向けワークフローを使ってください。信頼できるブレインホストで gbrain sources inspect <path> --profile company-brain を実行して開始し、保存先のプレビューと承認については docs/guides/company-brain-ingestion.md に従ってください。既存のリポジトリを検索可能にするためだけに、メタデータを削除したり履歴を消去したりしないでください。

• 創業者／経営幹部の個人用ブレインからチーム共有の会社ブレインを立ち上げる場合
• 共有ブレインに含めるべきでない機微情報がないか、既存の共有ブレインを監査する場合
• まずクリーンであることを確認する必要があるブレインリポジトリに、新しいチームメンバーを追加する場合
• 機微情報が再び蓄積される共有ブレインを、定期的に整理する場合

削除する情報

必ず削除する（必須）

カテゴリ	例
社内スコア／評価	score:、rating:、skill:、または業種固有の *_score: frontmatter フィールド、および人物に対するあらゆる数値評価
報酬	給与、株式、キャリー、ストックオプションの付与、報酬の変更、引き留めパッケージ
業績評価	従業員の強み／弱みについてのセクション、「リスクあり」のフラグ、業績不振への言及、「他人の仕事の穴埋め」に関する記述
退職／引き留め	退職を検討している人、残留するよう説得された人、退職の噂、引き留めに関する話し合い
経営戦略	特定の人の管理方法に関するセクション、「難しい話し合い」のメモ、担当範囲／役職の管理計画
社内の政治的な関係性	誰が誰を嫌っているか、誰が誰を不安に思っているか、対立関係、権力関係
個人を特定できる情報（PII）	電話番号、個人用メールアドレス、自宅住所、家族や医療に関する情報、個人的な法的問題、私生活に関する詳細
テイク／ファクト	上記のカテゴリ（業績、報酬、引き留め、弱点、経営上のリスク）に関するあらゆるテイクまたはファクト。ファクトの行はページの Facts フェンスから削除し、gbrain forget で期限切れにするだけにしてはいけません

常に残す

カテゴリ	例
職業上のプロフィール	氏名、役職、肩書き、仕事用メールアドレス、LinkedIn
取り組んでいること	現在のプロジェクト、製品開発、技術的な貢献
キャリアの歩み	前職の企業、学歴、職歴（公開情報）
仕事上の信条	テクノロジー、戦略、製品哲学に関する考え
業務のタイムライン	会議への出席、プロジェクトのマイルストーン、ローンチ（評価を含まない事実）
スキル／専門知識	技術的な能力、ドメイン知識

スキャン範囲 — people/ より広く

機密情報の漏えいは people/ ページ以外でも発生します。スキャン範囲は次のとおりです。

• people/ — 主な対象（フロントマターフィールド、評価セクション）
• meetings/ — 率直な評価を含む会議の記録や議事録
• daily/ — 報酬／業績／定着に関する会話に触れた日次メモ
• companies/、projects/、analysis/ — 削除対象の内容への相互参照
• Takes — ページの takes フェンス内にある評価的な主張（gbrain takes search）
• Facts — ホットメモリーの事実（gbrain recall --grep）
• バックリンク — 編集後に gbrain check-backlinks check を実行し、削除したセクションを参照するページが残っていないことを確認します

people/ だけを対象に処理しても、情報が漏えいしたままの brain を適合と判断することになります。

手順

以下のパスはすべて brain リポジトリのルートからの相対パスです。

BRAIN="$(gbrain config get sync.repo_path)"
cd "$BRAIN"

フェーズ 1：対象範囲の特定（検索を優先）

1. 検索による検出 — ハイブリッド検索を使うと、キーワードパターンでは検出できない、判断に関わる内容も見つかります。

   gbrain query "compensation, equity, or salary discussions about team members" --limit 50
   gbrain query "performance concerns, underperformance, or who is struggling" --limit 50
   gbrain query "considering leaving, retention conversations, departure rumors" --limit 50
   gbrain takes search "performance" --limit 50
   gbrain recall --grep "salary"
   

   返された各スラッグをリポジトリルートからの相対ファイルパスに解決し、そのパスを /tmp/brainify-scope.txt に（1 行に 1 つずつ）書き込みます。このファイルが対象範囲の一覧です。以下の構造的なスキャンではこの一覧に追記します。手順の後半でこのファイルを切り詰めてはいけません。切り詰めると、検索で検出されたページが対象範囲からひそかに除外されます。

2. 構造的な検出 — その会社に属する people ファイルと、より広いスキャン範囲におけるキーワードのヒットです。

   grep -rli 'company: *"acme-example"' people/ --include="*.md" | sort >> /tmp/brainify-scope.txt
   grep -rli -E 'salary|equity|carry|retention|underperform|performance review|hard conversation' \
     meetings/ daily/ companies/ projects/ analysis/ --include="*.md" 2>/dev/null >> /tmp/brainify-scope.txt
   sort -u -o /tmp/brainify-scope.txt /tmp/brainify-scope.txt
   

3. 会社の公開されている people ページ（ウェブサイト、LinkedIn）と照合し、異なるフロントマター規約を使っているファイルを見つけます。

4. 件数を確認します：wc -l /tmp/brainify-scope.txt

フェーズ 2：機密性のトリアージ

ヒット数の多いファイルを優先します（移植性のある grep -E を使用。\b は使いません。BSD と GNU では挙動が異なります）。

while read -r f; do
  hits=$(grep -c -i -E 'carry|salary|equity|comp change|departure|considering leaving|retention|underperform|picking up slack|performance review|management risk|hard conversation|nervou|score: *[0-9]|firing|fired|pip|probation|weakness' "$f" 2>/dev/null || true)
  [ "${hits:-0}" -gt 0 ] && echo "$hits $f"
done < /tmp/brainify-scope.txt | sort -rn > /tmp/brainify-triage.txt

ヒット数の多いファイルは、判断に基づく精査が必要です。ヒット数がゼロのファイルはフロントマターフィールドの削除だけで済む場合がありますが、それでも内容を読みます（正規表現でトリアージし、モデルが判断します）。

フェーズ 3：サニタイズ（ステージングコピーを推奨。まずテストし、その後並列処理）

フェーズ 3 は破壊的な処理です。多数のファイルからコンテンツを削除し、テイクを取り除き、ファクトの行を削除します。これを実施する際は、次の 2 つのルールに従ってください。

最初に対象を選びます。個人用ブレインは変更せず、コピーを使ってください。

• 新しいチームブレインを立ち上げる場合（デフォルトかつ推奨）： スキャンしたディレクトリのステージングコピーをサニタイズし、個人用ブレインはそのままにします。個人用ブレインには報酬、パフォーマンス、率直なメモを残すことが想定されています。個人用の作業ツリーからこれらを削除すると、価値のある個人データが失われます。フェーズ 1 の対象範囲を永続的なステージングディレクトリにコピーし、そのコピーを編集してください。フェーズ 5 のステップ 0 では、ステージングコピーからエクスポートします。影響範囲：個人用ブレインには影響しません。

  # Durable staging dir (NOT /tmp — same reasoning as the mirror backup).
  STAGING="$HOME/.gbrain/backups/brainify-staging-$(date +%Y%m%d-%H%M%S)"
  mkdir -p "$STAGING" && chmod 700 "$STAGING"
  for d in people meetings daily companies projects analysis; do
    [ -d "$d" ] && rsync -a "$d/" "$STAGING/$d/"
  done
  cd "$STAGING"   # all edits below happen here, not in sync.repo_path
  

• 既存の共有ブレインを再監査する場合： 共有ブレイン自体が対象となるため、編集は共有リポジトリ内で行います（共有リポジトリに移動し、個人用の sync.repo_path には移動しないでください）。ファクトの行の削除と再同期は、共有ソースの DB に適用されます。

一括で破壊的な編集を始める前に、data-loss-gate の確認カードを表示してください。どちらの対象も破壊的です（コピーの経路ではチーム向けのツリーからコンテンツを削除し、直接編集する経路では稼働中のブレインからコンテンツを削除します）。フェーズ 3 用に事前入力された内容：

⚠️ DATA DELETION — Confirmation Required

What: strip sensitive content, remove takes, and delete fact rows across
      [N files] in [STAGING COPY at <path>  |  the SHARED brain in place]
Count: [N files edited; T takes removed; F fact rows removed]
Location: [staging path OR shared repo path] — NOT the personal sync.repo_path
          on the staging path

Why: preparing a sanitized tree for team access

Recoverable?
- [x] Personal brain untouched (staging-copy path) — re-copy to redo
- [ ] In-place shared-brain path: edits overwrite the live tree; git history is
      the recovery line until Phase 5 purges it

Proceed? (yes/no)

data-loss-gate に従い、「yes」または「do it」と明示的に入力してもらってください。「ok」や「sure」は同意にあたりません。

一括処理の前にテストするため、まず 3～5 個のファイルで作業し、結果を確認してから規模を拡大します。対象が多い場合（50 個以上のファイル）は、10～12 個ずつのグループに分け、並列サブエージェントを起動します。ファイルごとに次の手順を実施します。

1. ファイル全体を読みます
2. 「必ず削除する」カテゴリに該当するコンテンツをすべて削除します
3. フロントマター：評価／報酬のフィールド行を丸ごと削除します
4. セクション：評価上の弱点、チーム内の関係、マネジメント戦略などのセクションを丸ごと削除します
5. Takes と Facts のフェンス：機密カテゴリに関係する行を丸ごと削除します。たとえば、「alice-example は charlie-example のパフォーマンスが期待を下回っていると考えている」というテイクは、意見の内容と、その意見を持つ人物の両方を明らかにします。帰属先だけを削除するのではなく、行全体を削除してください
6. 文中の言及：文や段落を慎重に編集します
7. クリーニングしたファイルを書き戻します

判断基準： 数か所のセクションを慎重に削除する場合は Edit を使います。機密コンテンツが全体に深く入り込んでいる場合に限り、ファイル全体を書き直すために Write を使います。

Facts：forget は削除ではありません。 gbrain forget <fact-id> はファクトを失効させますが、その行はページの Facts フェンスに取り消し線付きで残り、DB は引き続き --include-expired 経由で提供します。失効したファクトは保持されており、消えたわけではありません。サニタイズでは、機密ファクトの行を実際に削除する必要があります。該当する行を検索し（gbrain recall --grep）、機密テイクと同様に、ページの Facts フェンスから行を削除します（ステップ 5）。直接編集する共有ブレインでは、ページ編集後に再同期する必要があります（gbrain sync は編集済みページを再インポートします）。さらに、ファクトインデックスの整合性を取り直す必要があります。sync の収束契約が対象とするのはページのインポートのみであり、後続のファクト抽出は明示的に分離されています（src/commands/sync.ts、「CONVERGENCE CONTRACT」）。そのため、extract-facts による整合性の再調整が行われるまで、DB は削除した行を提供し続けます。これを実行するには（gbrain sweep を実行するか、常駐サーバーの sweep を待ち）、gbrain recall --grep で行が実際に削除されたことを確認します。ファクトインデックスの整合性を取り直していない状態では、ページを編集しても検索時に漏えいします。forget だけでブレインがクリーンになったと証明することはできません。

編集後の処理：ステージングコピーの経路では、コピーした Markdown を直接編集してファクトの行を削除します（まだ再同期する稼働中の DB はありません。チーム DB は、フェーズ 5 のステップ 0 でエクスポートをソースに変換する際に新規作成されます）。共有ブレインを直接編集する経路では、gbrain sync を実行してページの内容を Markdown と一致させた後、上記のとおりファクトインデックスの整合性を取り直して確認します。どちらの場合も、削除したコンテンツをまだ参照しているページを見つけるために gbrain check-backlinks check を実行します。

Phase 4: 検証

Phase 2 のトリアージを再実行します。フラグが付いたファイルの数が、ほぼゼロまで減っているはずです。続いて、対象を絞った grep を実行します。

# Rating fields remaining in frontmatter
grep -rn -E '^[a-z_]*(score|rating|skill)[a-z_]*: *[0-9]' people/ --include="*.md"

# Phone numbers
grep -rn -E '\+1[0-9]{10}|\([0-9]{3}\) [0-9]{3}-[0-9]{4}' people/ --include="*.md"

# Comp keywords (full scan scope, not just people/)
grep -rin -E 'carry|comp change|equity|salary' people/ meetings/ daily/ companies/ projects/ analysis/ --include="*.md" 2>/dev/null

# Management/performance
grep -rin -E 'considering leaving|departure rumor|underperform|picking up slack|hard conversation' people/ meetings/ daily/ companies/ projects/ analysis/ --include="*.md" 2>/dev/null

誤検出（例：「carry the torch」）は問題ありません。パターンを厳しくするのではなく、残ったヒットを一つずつ手動で確認してください（正規表現の規律）。

実際に出荷するツリーを検証します。 ステージングコピーを使う場合、これらの grep はサニタイズ済みの $STAGING ツリーに対して実行します（Phase 5 Step 0 でこれがエクスポートになります）。実際に出荷するのは個人用の作業ツリーではないため、それを認定しても意味がありません。共有ブレインをその場で再監査する場合は、共有リポジトリのツリーが出荷対象なので、この手順をそのまま実施します。

次に、最も確実な確認を行います。チームが実際に使う検索です。サニタイズ済みのブレイン／ソースに対して実行します（共有ソースが個人コンテンツと並んでマウントされている場合は、--source <team-source-id> で対象を指定します）。

gbrain query "what is alice-example's compensation" --limit 10
gbrain query "who is underperforming or at risk of leaving" --limit 10
gbrain takes search "weakness" --limit 20

これらはすべて、結果が空であるか、残すカテゴリのコンテンツのみでなければなりません。

Phase 5: コミットと履歴の完全削除 — 要承認

リポジトリに履歴がある場合、ファイルをクリーンにするだけでは不十分です。過去のコミットには、機密情報を含むバージョンが残っています。

Step 0 — 推奨される代替手段（非破壊的）。 新しいチームリポジトリを立ち上げる場合は、履歴の書き換えを一切行わず、Phase 3 でサニタイズした $STAGING ツリーを新しい履歴を持つ新規リポジトリにします。個人用リポジトリは、完全な履歴と完全な作業ツリーをそのまま保持します。

エクスポートのルール：スキャンしていないものは出荷しません。 Phase 3 ではスキャン済みのディレクトリのみを $STAGING にコピーしているため、ステージングツリーにはサニタイズ処理で読み取っていないものは含まれません。つまり、対象のみを含めるルールは構造上守られます。余分なディレクトリを決してコピーしないでください。スキャン対象外のすべて（conversations/、originals/、sources/、inbox/）は除外したままにします。リポジトリ全体のコピーは典型的な情報漏えいです。どの処理でも読み取っていない生の文字起こし、原本、受信トレイのキャプチャが出荷されます。新しいディレクトリを出荷するには、まずスキャン対象に追加し（Phases 1-4）、サニタイズ済みの状態で $STAGING に格納されるようにします。

# The sanitized staging tree IS the export.
cd "$STAGING"

# Re-run the Phase 4 verification greps + retrieval checks INSIDE $STAGING —
# the staging tree is what ships, and it is the tree that must certify clean.
# ... Phase 4 greps against $STAGING ...

git init -b main
git add -A && git commit -m "Initial import — sanitized team brain"  # gbrain-allow-shared-tree-git: first commit of a fresh single-writer export repo
git remote add origin <TEAM_REPO_URL>
gbrain git commit-push --push-only

$STAGING は今回の実行だけが書き込む新規リポジトリなので、最初のコミットには通常の git を使います。プッシュには gbrain git commit-push --push-only を使います。これは origin/main にプッシュし、プッシュに失敗した場合はエラーを明示して停止します。終了コードが 0 以外の場合は停止し、エラーの内容をユーザーに伝えます。通常は git_push_unavailable（チームリポジトリの URL と認証情報を確認してから再実行してください）か、すでにコミットがあるチームリポジトリ（このエクスポートには空のリポジトリが必要です。先に進む前にユーザーに確認してください）です。決して force-push しないでください。

機密情報を含む履歴がすでにある共有リポジトリに限り、以下の完全削除手順が必要です。

Step 1 — 共有リポジトリを対象にし、クリーンなツリーをコミットしてから、ミラークローンします。 完全削除の対象は共有リポジトリであり、sync.repo_path（個人用ブレイン）では決してありません。Step 0 で個人用リポジトリの完全な履歴を保持できるのは、このルールによるものです。共有リポジトリを永続的な作業ディレクトリにクローンし、以下のすべての手順をそのディレクトリ内で実行します。何かを変更する前に、対象が個人用リポジトリではないことを確認してください。

PERSONAL="$(gbrain config get sync.repo_path)"
mkdir -p "$HOME/.gbrain/backups" && chmod 700 "$HOME/.gbrain/backups"
WORK="$HOME/.gbrain/backups/brainify-purge-$(date +%Y%m%d-%H%M%S)"
git clone <SHARED_REPO_URL> "$WORK/shared"
cd "$WORK/shared"
[ "$(git rev-parse --show-toplevel)" != "$PERSONAL" ] \
  || { echo "target IS sync.repo_path (personal brain) — ABORT"; exit 1; }

# Apply the sanitized tree, then COMMIT it BEFORE the mirror clone. A mirror
# captures COMMITTED state only; if the clean tree lives only in volatile
# staging during the rewrite window, a crash loses the sanitization work.
# Committing makes the clean state durable and recoverable; pushing it means
# the remote stops serving the sensitive current versions even if the purge
# below is declined. Only the sanitized directories are committed. On a
# non-zero exit stop: retry once on commit_lock_busy; on integrate_conflict
# someone changed the shared repo meanwhile, so ask the user before going on.
for d in people meetings daily companies projects analysis; do
  [ -d "$STAGING/$d" ] && rsync -a "$STAGING/$d/" "./$d/"   # or sanitize in place here
done
SANITIZED=""
for d in people meetings daily companies projects analysis; do [ -d "$d" ] && SANITIZED="$SANITIZED $d"; done
gbrain git commit-push -m "Sanitize: strip sensitive content before history purge" -- $SANITIZED

# Mirror-clone backup = the recoverability line on the card. Capture the path
# in a variable NOW and reuse it verbatim at purge time — a run crossing
# midnight must NOT recompute $(date) and false-abort on a mismatched name.
BACKUP_PATH="$HOME/.gbrain/backups/shared-brain-history-backup-$(date +%Y%m%d-%H%M%S).git"
git clone --mirror "$WORK/shared" "$BACKUP_PATH"
git -C "$BACKUP_PATH" log -1 >/dev/null || { echo "backup unreadable — ABORT"; exit 1; }

カードを提示する前に、ミラーが存在し、読み取れることを確認してください。これはカードに記載する復旧可能性の根拠です。

Step 2 — 停止します。data-loss-gate の確認カードを提示し、回答を待ちます。 履歴の書き換えと force-push は、このスキルで最も破壊的な操作です。リモートから、完全削除対象のパスに関する過去のすべてのバージョンが永久に失われます。カードへの回答を得る前に、決して実行しないでください。この操作用の記入済みカードは以下のとおりです。

⚠️ DATA DELETION — Confirmation Required

What: rewrite git history to remove all prior versions of [purged paths]
      from the SHARED repo, then force-push to [remote/branch]
Count: [N commits rewritten; M files with history purged]
Size: [repo size before → expected after]
Location: [SHARED repo work dir; remote URL; branch]
Target check: this is the SHARED repo, verified ≠ personal sync.repo_path
      ($PERSONAL) — the personal brain's history is never rewritten

Why: prior commits contain pre-sanitization versions of pages that were
     just cleaned — team access to the repo means team access to history

Recoverable?
- [x] Mirror-clone backup at $BACKUP_PATH
      (verified: exists, `git -C "$BACKUP_PATH" log` works)
- [ ] NOT recoverable from the rewritten remote — old SHAs become unreachable

What we'd lose:
- all pre-sanitization history for the purged paths (edit trail, blame,
  old versions)
- every existing clone breaks — all collaborators must re-clone

Alternative to deletion:
- fresh-history export to a NEW team repo (Step 0) — personal repo untouched

Proceed? (yes/no)

data-loss-gate の規定に従い、入力された 「yes」 または 「do it」 が必要です。「ok」、「sure」、「go ahead」は同意ではありません。ユーザーが質問した場合は回答して、カードを再提示してください。このゲートはルーティング上の規約であり、実行時に強制されるものではありません。gbrain が git filter-repo を機械的にブロックすることはありません。だからこそ、このスキルに従うエージェントはゲートを省略してはなりません。 ステップ 3 — パージ（明示的に yes と入力した場合のみ）。 git filter-repo が必要です（git には同梱されていません。別途インストールしてください）。以下のコマンドは、ステップ 1 の共有リポジトリ作業ディレクトリでのみ実行してください（cd "$WORK/shared"）。sync.repo_path では git filter-repo も git push --force も絶対に実行しないでください。個人用 brain の履歴はそのまま維持する必要があります。 以下のコマンドではステップ 1 の $WORK と $BACKUP_PATH を再利用し、日付入りのパスを再計算することはありません。

cd "$WORK/shared"
[ "$(git rev-parse --show-toplevel)" != "$PERSONAL" ] \
  || { echo "target IS sync.repo_path — ABORT, do not filter-repo"; exit 1; }

# The purge list derives from the COMPLETE set of sanitized paths — the same
# directories Phases 1-4 scanned. A filter list narrower than the scan
# (people/ + meetings/ only) leaves pre-sanitization history alive for every
# other scanned directory. The restore carrier below MUST match this same
# list — backed-up set, filtered set, and re-added set are identical.
PURGE_DIRS="people meetings daily companies projects analysis"

# Back up the clean working tree of every purged path to a DURABLE carrier
# (under $WORK in ~/.gbrain/backups — never /tmp, which can vanish mid-rewrite).
CLEAN="$WORK/clean"
mkdir -p "$CLEAN"
for d in $PURGE_DIRS; do
  [ -d "$d" ] || continue
  mkdir -p "$CLEAN/$d" && cp -r "$d/." "$CLEAN/$d/"
done

# Rewrite history: one --path per purged directory, derived from $PURGE_DIRS
rm -rf .git/filter-repo
git filter-repo --invert-paths $(for d in $PURGE_DIRS; do printf -- '--path %s/ ' "$d"; done) --force

# Restore clean files and re-commit as a single new commit — same $PURGE_DIRS
for d in $PURGE_DIRS; do
  [ -d "$CLEAN/$d" ] || continue
  mkdir -p "$d" && cp -r "$CLEAN/$d/." "$d/"
done
git remote add origin <SHARED_REPO_URL>   # filter-repo removes remotes
for d in $PURGE_DIRS; do [ -d "$d" ] && git add "$d/"; done
git commit -m "Re-add sanitized directories"

# VERIFY RESTORE COMPLETENESS before the irreversible push — a partial restore
# would ship a smaller tree than was sanitized. Compare file counts (and, for
# extra safety, checksums) between the carrier and the restored tree.
before=$(find "$CLEAN" -type f | wc -l | tr -d ' ')
after=$(for d in $PURGE_DIRS; do [ -d "$d" ] && find "$d" -type f; done | wc -l | tr -d ' ')
[ "$before" = "$after" ] \
  || { echo "restore incomplete ($before → $after files) — ABORT, do not force-push"; exit 1; }
# Optional stronger check: diff -r "$CLEAN/<d>" "<d>" for each purged dir.

# RE-VERIFY the backup immediately before the irreversible step — card-time
# verification is not enough; time has passed and the rewrite could have gone
# sideways. Reuse $BACKUP_PATH (do NOT recompute $(date)); abort if unreadable.
git -C "$BACKUP_PATH" log -1 >/dev/null \
  || { echo "backup missing/unreadable — ABORT, do not force-push"; exit 1; }

git push --force origin main  # gbrain-allow-shared-tree-git: the confirmed history purge of a private single-writer clone (data-loss-gate answered)

ステップ 4 — ログを記録する（個人用 brain に記録し、共有リポジトリには絶対に記録しない）。 data-loss-gate に従い、削除内容を ## Data Deletions の下に追記します。ただし、記録先は個人用 brain の $PERSONAL/daily/notes/YYYY-MM-DD.md（またはローカルの運用ログ）とし、共有リポジトリには絶対に記録しないでください。ログには、パージしたパスとバックアップの保存先を記載します。共有リポジトリにこの 2 つの情報を記録すると、機密情報が含まれていたパスと、サニタイズ前のバックアップの場所がチームメンバー全員に明らかになり、監査証跡が宝の地図になってしまいます。記録する項目：タイムスタンプ、パージしたパス、コミット数、復旧用の情報としての $BACKUP_PATH。

強制プッシュ後：

• 既存のクローンはすべて再クローンする必要があります
• ホスティングプロバイダーは、到達不能なコミットをしばらく（数か月程度）キャッシュする場合があります。すぐに削除するには、プロバイダーの機密データ削除手順を利用してください。プライベート／内部リポジトリでは、どの ref からも SHA に到達できなければ、通常は十分です
• 同期カーソルが書き換えによって消えた SHA を参照している可能性があります。次の gbrain sync がエラーになったり、全体を再スキャンしたりする場合は、カーソルが復旧中です。状態が落ち着かない場合は gbrain doctor を実行してください
• バックアップの保持期間： 書き換えが正常に完了したことを確認したら（チームが再クローンし、同期が落ち着き、コンテンツの欠落が報告されていないこと）、ミラークローンのバックアップを ~/.gbrain/backups/ に一定期間（約 30 日が妥当な既定値です）保持してから削除してください。バックアップにはサニタイズ前の履歴が含まれるため、無期限に蓄積しないようにしてください： rm -rf ~/.gbrain/backups/shared-brain-history-backup-<date>.git （glob はバックアップ手順で作成した shared-brain-history-backup-* という名前に一致する必要があります。パターンが一致しないと何も削除されず、サニタイズ前の履歴がそのまま残っていることに気づかない場合があります）
• リポジトリにプッシュフックや自動ハードニングの設定がある場合は、書き換え後もリモートとフックが維持されていることを再確認してからチームに引き渡してください

リポジトリをチームに引き渡す — 先に共有設定を行ってください。 チーム用リポジトリの作成にどの方法（ステップ 0 の新規履歴エクスポート、またはパージ後の強制プッシュ）を使った場合でも、引き渡し前に公開する brain の対象者を設定します： gbrain config set brain.audience shared — チーム用 brain に対して実行し、個人用 brain には実行しないでください。この設定により、会社／チーム用の brain であることが示されるため、個人用 brain に表示される書き込み時の同意確認が表示されなくなります。チームメンバーがこの設定を行う前に、共有 brain に対して gbrain init を実行する場合（たとえば、新しいクローンで独自のエンジンを初期化する場合）、その 1 回のコマンドの前に GBRAIN_NO_ONBOARD_NUDGE=1 を付けてください。新規の未設定 brain は個人用と判定され、初期化時の確認は一度しか表示されないため、その場で表示させると不適切な質問が出るうえ、確認済みの印も消費されてしまいます。

フェーズ 6：継続的な衛生管理 — 定期的な再監査

会議の文字起こしの取り込み（率直な評価）、内部データを取得するエンリッチメントパイプライン、率直な会話中の手動書き込みによって、機密データは再び蓄積されます。1 回のクリーンアップで確認できるのはその時点の状態にすぎません。

推奨事項： 月 1 回（取り込み量の多い brain では週 1 回）の再監査を予定し、フェーズ 1、2、4 をレポートのみのモードで再実行します。スキャンして問題を報告するだけで、編集は行いません。共有リポジトリに到達する前に、新たに検出された項目を人が確認できるようにします。 conventions/cron-via-minions.md に従って設定します。cron のスロットからバックグラウンドジョブ（gbrain jobs submit）を送信します。スケジュール設定のガイダンスは skills/cron-scheduler/SKILL.md、ジョブレーンのルーティングは skills/minion-orchestrator/SKILL.md にあります。レポートのみの実行では検出結果の概要が出力されます。削除は人（またはゲート付きの後続実行）が行います。

スケーリングに関する注意事項

• ファイル数が20未満： 1回のパスで逐次処理します
• ファイル数が20～50： サブエージェントを2～3個並行して実行します
• ファイル数が50～150： サブエージェントを8～12個並行して実行し、10～15個単位でバッチ処理します
• ファイル数が150以上： 定型的なケースに限り、スクリプトでパターンを削除します （frontmatterのフィールド、電話番号など、正規表現の規律に従った機械生成形式）＋ 判断が必要なすべての作業にはサブエージェントを使用します

エッジケース

• 創業者と従業員： 創業者や経営幹部のページには、最も機微な内容（取締役会の動向、投資家との関係、自身のチームに対する評価）が記載されていることがよくあります。最も慎重に確認する必要があります。
• 会議メモ： 従業員のパフォーマンスに言及する会議ページも、人物ページと同様に扱う必要があります。対象範囲に含まれており、後回しにするものではありません。
• 相互参照： 人物ページのサニタイズ後、他のページ（会議、企業、日次記録）に削除した内容への参照が残っていないことを確認します。gbrain check-backlinks check に加えて、削除したセクションのタイトルを grep で検索します。
• 出典付きの意見： 「ユーザーはcharlie-exampleのパフォーマンスが低いと考えている」という意見は、意見の内容だけでなく、誰がそう考えているかも明らかにします。出典だけでなく、意見全体を削除してください。
• 別名とニックネーム： スラッグだけでなく、その人物の短縮名やイニシャルも grep で検索してください。率直な内容では、フルネームが使われることはほとんどありません。

重複の整理（明確な境界）

• data-loss-gate — 確認カードの仕組みと明示的な「はい」の確認手順を提供します。company-brainifyは、その両方の破壊的な手順、Phase 3（一括削除＋意見／事実の削除）とPhase 5（履歴の消去＋強制プッシュ）で、事前入力済みのカードを使う専用の呼び出し元です。単独の「Xを削除／消去／片付ける」という意図はdata-loss-gateに振り分けます。個人用からチーム用へのサニタイズWORKFLOWはこちらに振り分けます。
• publish — 暗号化された自己完結型HTMLとして、1つのページを外部と共有します。company-brainifyは、脳全体へのチームアクセスを対象とします。「このページを共有して」→ publish、「自分の脳をチームと共有して」→ こちら。
• maintain — 孤立ページ、バックリンク、古いページなど、構造上の健全性を扱います。maintainは脳の健全性を確認し、company-brainifyは共有しても安全かを確認します。「脳の健全性を確認して」はmaintainに振り分けます。
• frontmatter-guard（ホスト側） — frontmatterの形式を検証します。company-brainifyは機微なfrontmatterのフィールドを削除します。大規模な処理の後にfrontmatter-guardを実行し、残った内容が引き続き解析できることを確認します。

コントラクト

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

• どちらの破壊的な手順も、実行前に data-loss-gate の確認カードを表示し、明示的に「yes」または「do it」と入力されるまで待機します。対象となるのは、Phase 3（一括削除＋テイク／ファクトの削除）と Phase 5（履歴の消去＋強制プッシュ）です。これはエージェントが従うべきルーティング上の規約です。実行環境がゲートの省略を機械的に阻止するわけではないため、ゲートの省略はこのスキルに対する最重大の違反です。
• Phase 3 では、既定でスキャンした範囲のステージングコピーをサニタイズし、個人用ブレインの作業ツリーには手を加えません。インプレース編集は、既存の共有ブレインを再監査する場合に限ります。
• Phase 5 の履歴消去（Step 3 以降）は、(a) ミラークローンのバックアップが存在し、検証済みであり、(b) 強制プッシュ前の復元完全性チェックに合格した後に限り、作業ディレクトリにクローンした共有リポジトリでのみ実行します。sync.repo_path では決して実行しません。個人用ブレインの履歴は書き換えません。
• 削除ログは個人用ブレイン（daily/）またはローカルの運用ログに記録し、共有リポジトリには記録しません。
• スキャン範囲には、people、meetings、dailies、companies、projects、analysis、takes、facts、back-links をすべて含め、people/ だけに限定しません。
• 未スキャンのものは一切公開しません。新規エクスポートのパスには、サニタイズスキャンの対象となったディレクトリのみを含め、それ以外はすべて既定で除外します。最初のプッシュ前に、エクスポートしたツリーを対象に Phase 4 の検証用 grep を実行します。
• 機密性の高いファクトの行は、ページの Facts フェンスから削除して再同期し、ファクトのインデックスを照合します（extract-facts の全件スイープ）。削除は gbrain recall --grep で検証し、単に期限切れにしただけでは不十分です。gbrain forget は行を取り消し線付きで保持し（--include-expired で取得可能）、クリーンであることの証明には決してなりません。
• 履歴消去のフィルターリストと復元マニフェストは、どちらもサニタイズしたパスの完全な集合を基に作成し、部分集合は使いません。
• 各削除の判断は、ファイル全体を読んだうえでモデルがファイルごとに行います。grep の出力はトリアージと検証にのみ使用します。
• 共有リポジトリにコミットをプッシュする前に、必ず検証を行います（Phase 4 の grep＋検索チェック）。
• 確認済みの消去は、バックアップパスを復旧情報として daily/notes/YYYY-MM-DD.md の ## Data Deletions に記録します。
• ブレイン化したブレインには、引き渡し時に brain.audience=shared を設定し、アンビエント書き戻しの有効化を促しません。この同意の確認は個人用ブレインに限ります。
• ルーティングは frontmatter の標準トリガーに一致します。
• writes_to: に記載されたディレクトリに出力を書き込みます（インプレース編集と daily/ の削除ログを含みます）。
• プライバシーに関する契約を維持します。実名、フォーク固有のファイルシステムパスのリテラル、上流フォークへの言及は含めません。

動作に関する契約の全容は、上記の本文セクションに記載されています。このセクションは適合性テストのためのものです。

出力形式

成果物は 3 つです。

1. サニタイズレポート（レポートのみの再監査を含む、すべての実行で作成）：

## Brainify Report — YYYY-MM-DD

- Scope: [N files scanned across people/, meetings/, daily/, ...]
- Flagged: [M files with hits] (triage list attached)
- Edited: [K files sanitized; T takes removed; F fact rows removed + re-synced + facts index reconciled]
- Verification: [grep residuals: 0 confirmed-sensitive; retrieval checks: clean]
- History: [not purged | fresh-export | purged after confirmed gate — backup at <path>]
- Next re-audit: [date / cron slot]

2. 確認カード（Phase 3 と Phase 5） — 事前入力済みのフェンス付きカードです。一括破壊的編集（Phase 3）の前、および履歴を書き換える処理（Phase 5）の前に提示します。ユーザーの回答があるまで、そのターンを停止します。
3. 削除ログのエントリ（消去後のみ） — data-loss-gate Step 4 に従い、個人用ブレインの daily/notes/YYYY-MM-DD.md に追記します（共有リポジトリには決して記録しません）。

失敗した場合

gbrain のエラー code、終了コード、[AGENT] ブロック、通知ブロックについては、エージェントオペレータープロトコルに従ってください。このスキル固有の事項は次のとおりです。

• 一括編集による秘匿化や削除には、データ損失ゲートカードが必要です。CLI が 3 で終了するか、確認を求めた場合は停止し、まず復元可能性カードをユーザーに提示してください。
• retrieval-first のスコープスキャンが、縮退通知とともに空になる場合があります。キーワードのみの検索では、機密性の高いページを過少に検出します。構造的な確認を続け、スキャンがキーワードのみだったことをユーザーに伝えてください。
• forget / put_page が write_pending（終了コード 10）を返した場合は、gbrain write-request <request_id> をポーリングしてください。レシートが確定するまで、ページの秘匿化が完了したと報告してはいけません。

アンチパターン

• ❌ people/ のみをスキャンする — ミーティング、日報、相互参照にも同じ内容が漏れています
• ❌ ワーキングツリーのファイルを秘匿化して完了とする — 履歴には機密情報を含むすべてのバージョンが残っています
• ❌ リポジトリ全体をチームブレインにエクスポートする — エクスポートされるのはスキャン済みのディレクトリのみで、未スキャンのものはエクスポートされません
• ❌ gbrain forget を秘匿化として使う — forget は期限切れにするだけです（取り消し線付きの行は保持され、--include-expired で提供されます）。フェンス行を削除して、再同期してください
• ❌ 秘匿化したパスの一部だけを対象に履歴を消去する — フィルターリストは people/ と meetings/ だけではなく、完全なスキャン範囲から導き出されます
• ❌ ミラークローンのバックアップと型付き確認なしで git filter-repo / force-push を実行する — カードは必ず書き換えの前に提示します
• ❌ sync.repo_path で git filter-repo / force-push を実行する — 消去対象は作業ディレクトリにクローンされた共有リポジトリです。個人ブレインの履歴は書き換えられません
• ❌ 新しいチームブレインを立ち上げる際に、個人ブレインをその場で削る — ステージング用コピーを秘匿化してください。創設者の非公開の報酬・業績メモはそのまま残します
• ❌ Phase 3 のデータ損失ゲートカードなしでファイルを一括編集し、見解や事実を削除する — 破壊的な編集にもゲートが必要です。消去だけではありません
• ❌ 削除ログを共有リポジトリに書き込む — 機密パスとバックアップの場所が記載されるため、個人ブレインに記録してください
• ❌ grep を機密性の判定役として扱う — パターンはトリアージに使い、モデルが読み取って判断します（正規表現の適切な運用）
• ❌ 出典表示だけを削除して見解を残す — 漏えいするのは主張そのものです。行全体を削除してください
• ❌ 最初に 3～5 ファイルでテストせずに、150 ファイルを一括編集する（大量処理の前にテスト）
• ❌ 誤検知をなくすために grep のパターンを絞り込む — 代わりに該当箇所を手動で確認してください。過剰適合したパターンによる「問題なし」のスキャン結果は、誤った証明になります
• ❌ 再監査を行わず、問題のない状態になった時点で一度だけ確認する — 取り込みとエンリッチメントによって機密情報が再び蓄積されます。Phase 6 を予定してください