Company Brainify

company-brainify — Personal → Team-Brain Sanitization

Convention: see conventions/brain-first.md — discovery runs through the brain's own retrieval, not filesystem guesswork. The grep pipelines below TRIAGE; gbrain query finds what keyword patterns miss.

Convention: see conventions/test-before-bulk.md — sanitize 3-5 files, read the output yourself, then ramp. A bad bulk sanitization pass is worse than none: it looks done and isn't.

Convention: see conventions/regex-discipline.md — "is this sensitive?" is a judgment call, so the model decides per file. The grep patterns are earned triage/verification tools, never the judge.

Convention: see _brain-filing-rules.md — edits stay in the page's existing directory; the deletion log files date-keyed under daily/.

The Problem

Personal brains accumulate everything — company knowledge, meeting notes, internal assessments, compensation details, management strategy, candid opinions about the people you work with. When you stand up a shared team brain from that personal brain (see docs/architecture/brains-and-sources.md for the team-mount topology), all of that has to go. The knowledge is valuable; the sensitive metadata is a liability.

Clean working-tree files alone are NOT enough: git history still carries every pre-sanitization version, and gbrain takes/facts carry evaluative claims outside the page prose. This skill handles all three surfaces — pages, takes/facts, and history.

When to Use

• Standing up a shared company brain from a founder/exec's personal brain
• Auditing an existing shared brain for sensitive content that shouldn't be there
• Onboarding new team members to a brain repo that must be verified clean first
• Periodic hygiene pass on a shared brain that re-accumulates sensitive data

What Gets Removed

Always strip (non-negotiable)

Always keep

Scan Scope — Wider Than people/

Sensitive content leaks far beyond people pages. The scan scope is:

• people/ — the primary surface (frontmatter fields, assessment sections)
• meetings/ — transcripts and minutes with candid assessments
• daily/ — daily notes referencing comp/performance/retention conversations
• companies/, projects/, analysis/ — cross-references to removed content
• Takes — evaluative claims in page takes fences (gbrain takes search)
• Facts — hot-memory facts (gbrain recall --grep)
• Back-links — after edits, gbrain check-backlinks check confirms no page still points at removed sections

A pass that only covers people/ will certify a brain that still leaks.

Procedure

All paths below are relative to the brain repo root:

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

Phase 1: Identify scope (retrieval-first)

1. Retrieval discovery — hybrid search catches judgment-shaped content that no keyword pattern will:

   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"
   

   Resolve every returned slug to its repo-relative file path and write the paths into /tmp/brainify-scope.txt (one per line). This file is the scope list; the structural pass below APPENDS to it — nothing later in the procedure may truncate it, or the retrieval-discovered pages silently drop out of scope.

2. Structural discovery — people files that belong to the company, plus keyword hits across the wider scan scope:

   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. Cross-reference against the company's public people page (website, LinkedIn) to catch files using different frontmatter conventions.

4. Count: wc -l /tmp/brainify-scope.txt

Phase 2: Triage sensitivity

Prioritize by hit density (portable grep -E; no \b — BSD and GNU disagree):

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

High-hit files need full judgment passes. Zero-hit files may only need frontmatter field removal — but they still get read (regex triages, the model judges).

Phase 3: Sanitize (STAGING COPY preferred; test first, then parallel)

Phase 3 is destructive: it strips content across many files, removes takes, and deletes fact rows. Two rules govern it.

Choose the target FIRST — copy, don't mutate the personal brain.

• Standing up a NEW team brain (default, preferred): sanitize a STAGING COPY of the scanned directories, never the personal brain in place. The founder's personal brain is SUPPOSED to keep comp, performance, and candid notes — stripping them from the personal working tree destroys valuable private data. Copy the Phase-1 scope into a durable staging dir and edit THAT; Phase 5 Step 0 exports from the staging copy. Blast radius: none on the personal brain.

  # 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
  

• Re-auditing an EXISTING shared brain: the shared brain IS the target, so edits are in place on the SHARED repo (cd into the shared repo, never the personal sync.repo_path). Fact-row removal + re-sync applies to the shared source's DB.

Fire the data-loss-gate confirmation card BEFORE the bulk destructive edits begin. Both targets are destructive (the copy path removes content from the tree destined for the team; the in-place path removes content from a live brain). Pre-filled for Phase 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)

Require a typed "yes"/"do it" per data-loss-gate; "ok"/"sure" are not consent.

Per test-before-bulk: do 3-5 files first, read the results, then ramp. For large sets (50+ files), batch into groups of 10-12 and spawn parallel subagents. Per file:

1. Read the file completely
2. Remove all content matching the "Always strip" categories
3. Frontmatter: delete rating/comp field lines entirely
4. Sections: remove entire sections (assessment weaknesses, team dynamics, management strategy)
5. Takes and Facts fences: remove entire rows that reference sensitive categories — a take like "alice-example believes charlie-example is underperforming" reveals both the opinion and who holds it; remove the whole row, never just the attribution
6. Inline mentions: surgically edit sentences/paragraphs
7. Write the cleaned file back

Decision rule: use Edit for surgical removal when only a few sections need it. Use Write to rewrite the entire file only when sensitive content is deeply interwoven throughout.

Facts: forget is NOT removal. gbrain forget <fact-id> expires a fact — the row stays on the page's Facts fence struck through, and the DB still serves it via --include-expired. An expired fact is retained, not gone. For sanitization, sensitive fact rows must be ACTUALLY REMOVED: find them (gbrain recall --grep), then delete the row from the page's Facts fence (step 5), exactly like a sensitive take. On an in-place shared brain, the page edit must then be re-synced (gbrain sync re-imports the edited page) AND the facts index reconciled — sync's convergence contract covers page import only; downstream fact extraction is explicitly decoupled (src/commands/sync.ts, "CONVERGENCE CONTRACT"), so the DB keeps serving the deleted row until the extract-facts reconcile runs. Trigger it (gbrain sweep, or wait for the serve-resident sweep), then confirm with gbrain recall --grep that the row is actually gone. An edited page over an un-reconciled facts index still leaks through retrieval. forget alone can never certify a brain clean.

After edits: on the staging-copy path the fact rows are removed by editing the copied markdown directly (there is no live DB to re-sync yet — the team DB is built fresh when Phase 5 Step 0 turns the export into a source). On the in-place shared-brain path, run gbrain sync so the page content matches the markdown, then reconcile and verify the facts index as above. Either way, run gbrain check-backlinks check to catch pages still pointing at removed content.

Phase 4: Verify

Re-run the Phase 2 triage — the count of flagged files should drop to (near-)zero. Then targeted greps:

# 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

False positives (e.g. "carry the torch") are fine — manually confirm each remaining hit rather than tightening the pattern (regex-discipline).

Verify the tree that ships. On the staging-copy path, these greps run against the sanitized $STAGING tree (which Phase 5 Step 0 turns into the export) — the personal working tree is not what ships, so certifying it proves nothing. For an in-place shared-brain re-audit, the shared repo's tree is the shipped tree and this pass stands as-is.

Then the strongest check — the retrieval the team will actually use. Against the sanitized brain/source (scope with --source <team-source-id> when the shared source is mounted alongside personal content):

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

Every one of these must come back empty or with only keep-category content.

Phase 5: Commit and purge history — GATED

Clean files aren't enough if the repo has history: old commits still contain the sensitive versions.

Step 0 — preferred alternative (non-destructive). When standing up a NEW team repo, skip history rewriting entirely: the sanitized STAGING tree from Phase 3 becomes a fresh repo with fresh history. The personal repo keeps its full history AND its full working tree, untouched.

Export rule: nothing unscanned ships. Because Phase 3 copied ONLY the scanned directories into $STAGING, the staging tree contains nothing the sanitization pass didn't read — the include-only rule holds by construction. Never copy extra directories in: everything outside the scan scope (conversations/, originals/, sources/, inbox/) stays out. A whole-repo copy is the classic leak — it ships raw transcripts, originals, and inbox captures no pass ever read. To ship a new directory, add it to the scan scope first (Phases 1-4) so it lands in $STAGING sanitized.

# 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"
git remote add origin <TEAM_REPO_URL>
git push -u origin main

Only when a shared repo ALREADY exists with sensitive history in it do you need the purge below.

Step 1 — target the SHARED repo, commit the clean tree, then mirror-clone. The purge operates on the SHARED repo, NEVER on sync.repo_path (the personal brain) — Step 0's guarantee that the personal repo keeps full history depends on it. Clone the shared repo to a durable work dir, stay there for every step below, and assert the target is not the personal repo before touching anything.

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.
for d in people meetings daily companies projects analysis; do
  [ -d "$STAGING/$d" ] && rsync -a "$STAGING/$d/" "./$d/"   # or sanitize in place here
done
git add -A && git commit -m "Sanitize: strip sensitive content before history purge"

# 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; }

Verify the mirror exists and reads before presenting the card — it is the card's recoverability line.

Step 2 — STOP. Present the data-loss-gate confirmation card and wait. History rewrite + force-push is the most destructive operation in this skill: it permanently discards every prior version of the purged paths from the remote. Never run it without the card answered. Pre-filled for this operation:

⚠️ 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)

Per data-loss-gate: require a typed "yes" or "do it" — "ok", "sure", "go ahead" are not consent. If the user asks a question, answer and re-present the card. This gate is a routing convention, not a runtime enforcement — nothing in gbrain mechanically blocks git filter-repo — which is exactly why the agent following this skill must not skip it.

Step 3 — purge (only after the explicit typed yes). Requires git filter-repo (not bundled with git; install separately). Run this ONLY in the shared-repo work dir from Step 1 (cd "$WORK/shared"). NEVER run git filter-repo or git push --force in sync.repo_path — the personal brain's history must stay intact. The commands below reuse $WORK and $BACKUP_PATH from Step 1; they never recompute a date-stamped 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

Step 4 — log it (to the PERSONAL brain, NEVER the shared repo). Per data-loss-gate, append the deletion under ## Data Deletions — but write it to the PERSONAL brain's $PERSONAL/daily/notes/YYYY-MM-DD.md (or a local ops log), never into the shared repo. The log names the purged paths AND the backup location; in the shared repo those two facts would tell every team member exactly which paths held sensitive content and where the pre-sanitization backup lives — the audit trail becomes a treasure map. Record: timestamp, purged paths, commit counts, and $BACKUP_PATH as the recovery line.

After the force push:

• All existing clones must re-clone
• Hosting providers may cache unreachable commits for a time (on the order of months); for immediate removal use the provider's sensitive-data removal process. For private/internal repos, the SHA being unreachable from any ref is usually sufficient
• The sync cursor may reference a rewritten-away SHA; if the next gbrain sync errors or falls back to a full rescan, that is the cursor recovering — run gbrain doctor if it doesn't settle
• Backup retention: once the rewrite is verified good (team has re-cloned, sync settled, no missing content reported), keep the mirror-clone backup in ~/.gbrain/backups/ for a retention window (~30 days is a sane default), then delete it — it contains the pre-sanitization history and should not accumulate indefinitely: rm -rf ~/.gbrain/backups/shared-brain-history-backup-<date>.git (the glob must match the shared-brain-history-backup-* name the backup step created — a mismatched pattern deletes nothing and silently retains the pre-sanitization history forever)
• If the repo carries push hooks or auto-hardening wiring, re-verify remotes and hooks survived the rewrite before handing the repo to the team

Phase 6: Ongoing hygiene — periodic re-audit

Sensitive data re-accumulates through meeting-transcript ingestion (candid assessments), enrichment pipelines pulling internal data, and manual writes during candid conversations. One clean pass is a snapshot, not a state.

Recommendation: schedule a monthly re-audit (weekly for high-ingest brains) that re-runs Phases 1, 2, and 4 in report-only mode — scan and flag, no edits — and surfaces new hits for human review before they reach the shared repo. Wire it per conventions/cron-via-minions.md: the cron slot submits a background job (gbrain jobs submit), scheduling guidance in skills/cron-scheduler/SKILL.md, job-lane routing in skills/minion-orchestrator/SKILL.md. The report-only run writes its findings summary; a human (or a gated follow-up run) does the removal.

Scaling Notes

• < 20 files: process sequentially in one pass
• 20-50 files: 2-3 parallel subagents
• 50-150 files: 8-12 parallel subagents, batches of 10-15
• 150+ files: scripted pattern removal for the rote cases only (frontmatter fields, phone numbers — machine-emitted shapes, per regex-discipline) + subagents for everything needing judgment

Edge Cases

• Founders vs. employees: founder/exec pages often carry the most sensitive content (board dynamics, investor relationships, assessments of their own team). These need the most careful review.
• Meeting notes: meeting pages referencing employee performance need the same treatment as people pages — they are in scope, not an afterthought.
• Cross-references: after sanitizing people pages, check that no other page (meetings, companies, dailies) still references the removed content; gbrain check-backlinks check plus a grep for the removed section titles.
• Takes with attribution: a take like "the user believes charlie-example is underperforming" reveals both the opinion and who holds it. Remove the entire take, not just the attribution.
• Aliases and nicknames: grep for the person's short name and initials, not just the slug — candid content rarely uses full names.

Dedup (sharp boundaries)

• data-loss-gate — supplies the confirmation-card mechanics and the explicit-yes discipline; company-brainify is a specialized caller of it at BOTH destructive steps: Phase 3 (bulk strip
  • take/fact removal) and Phase 5 (history purge + force-push), each with a pre-filled card. A standalone "delete/purge/clean up X" intent routes to data-loss-gate; the personal→team sanitization WORKFLOW routes here.
• publish — outbound sharing of ONE page as encrypted self-contained HTML. company-brainify is whole-brain inbound team access. "Share this page" → publish; "share my brain with the team" → here.
• maintain — structural health (orphans, backlinks, stale pages). maintain checks whether the brain is HEALTHY; company-brainify checks whether it is SAFE TO SHARE. "Check brain health" routes to maintain.
• frontmatter-guard (host-side) — validates frontmatter SHAPE. company-brainify strips sensitive frontmatter FIELDS; run frontmatter-guard after a large pass to confirm what remains still parses.

Contract

This skill guarantees:

• Both destructive steps fire the data-loss-gate confirmation card and wait for an explicit typed "yes"/"do it" BEFORE running: Phase 3 (bulk strip + take/ fact removal) and Phase 5 (history purge + force-push). This is a routing convention the agent must follow — nothing in the runtime mechanically blocks a skipped gate, which is why skipping it is the cardinal violation of this skill.
• Phase 3 defaults to sanitizing a STAGING COPY of the scanned scope, leaving the personal brain's working tree untouched; in-place edits are reserved for re-auditing an existing shared brain.
• The Phase 5 history purge (Steps 3+) runs only on the SHARED repo cloned to a work dir — never sync.repo_path — after (a) a mirror-clone backup exists and is verified, and (b) a restore-completeness check passes before the force-push. The personal brain's history is never rewritten.
• The deletion log is written to the PERSONAL brain (daily/) or a local ops log, never into the shared repo.
• The scan covers the full scope (people, meetings, dailies, companies, projects, analysis, takes, facts, back-links), never people/ alone.
• Nothing unscanned ships: the fresh-export path includes ONLY directories covered by the sanitization scan; everything else is excluded by default, and the Phase 4 verification greps run against the exported tree before the first push.
• Sensitive fact rows are deleted from the page's Facts fence, re-synced, and the facts index reconciled (extract-facts sweep) with the removal verified via gbrain recall --grep, never merely expired — gbrain forget retains the row (struck through, served via --include-expired) and can never certify clean.
• The history-purge filter list and its restore manifest both derive from the COMPLETE set of sanitized paths, never a subset.
• Every strip decision is a per-file model judgment grounded in a full read; grep output is triage and verification only.
• A verification pass (Phase 4 greps + retrieval checks) runs before any commit is pushed to the shared repo.
• Confirmed purges are logged to daily/notes/YYYY-MM-DD.md under ## Data Deletions with the backup path as the recovery line.
• Routing matches the canonical triggers in the frontmatter.
• Output written under the directories listed in writes_to: (edits in place, plus the daily/ deletion log).
• Privacy contract preserved: no real names, no fork-specific filesystem path literals, no upstream-fork references.

The full behavior contract is documented in the body sections above; this section exists for the conformance test.

Output Format

Three artifacts:

1. The sanitization report (every run, including report-only re-audits):

## 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. The confirmation card (Phases 3 and 5) — the pre-filled fenced card, presented before the bulk destructive edits (Phase 3) and before any history rewrite (Phase 5); the turn stops until the user answers.
3. The deletion log entry (post-purge only) — appended to the PERSONAL brain's daily/notes/YYYY-MM-DD.md (never the shared repo) per data-loss-gate Step 4.

Anti-Patterns

• ❌ Scanning only people/ — meetings, dailies, and cross-references leak the same content
• ❌ Sanitizing working-tree files and calling it done — history still carries every sensitive version
• ❌ Exporting the whole repo into the team brain — the export ships ONLY scanned directories; nothing unscanned ships
• ❌ Using gbrain forget as sanitization — forget expires (struck-through row retained, served via --include-expired); delete the fence row and re-sync instead
• ❌ Purging history for a subset of the sanitized paths — the filter list derives from the complete scan scope, not just people/ + meetings/
• ❌ Running git filter-repo / force-push without the mirror-clone backup and the typed confirmation — the card comes BEFORE the rewrite, always
• ❌ Running git filter-repo / force-push in sync.repo_path — the purge targets the SHARED repo cloned to a work dir; the personal brain's history is never rewritten
• ❌ Stripping the personal brain in place when standing up a NEW team brain — sanitize a staging copy; the founder's private comp/performance notes stay
• ❌ Bulk-editing files and removing takes/facts without the Phase 3 data-loss-gate card — destructive edits are gated too, not just the purge
• ❌ Writing the deletion log into the shared repo — it names the sensitive paths and the backup location; log it to the PERSONAL brain
• ❌ Treating grep as the sensitivity judge — patterns triage, the model reads and decides (regex-discipline)
• ❌ Removing the attribution but keeping the take — the claim itself is the leak; remove the whole row
• ❌ Bulk-editing 150 files without a 3-5 file test first (test-before-bulk)
• ❌ Tightening grep patterns to eliminate false positives — confirm the hits manually instead; a "clean" scan from an over-fitted pattern is a false certificate
• ❌ One clean pass with no re-audit — ingestion and enrichment re-accumulate sensitive content; schedule Phase 6