用途：把创始人或高管的个人 brain 转成可供团队使用的共享 brain，或审计已有共享 brain 是否残留敏感内容。
主要能力：
- 按约定先做检索式发现再结构式发现：使用 gbrain query、gbrain takes search、gbrain recall --grep 加上 grep 三分类，生成 /tmp/brainify-scope.txt 范围清单。
- 覆盖 people/、meetings/、daily/、companies/、projects/、analysis/ 等目录，而不止 people/。
- 明确剥离清单包括内部评分（score:、rating:、skill: 等 frontmatter）、薪酬（薪资、股权、carry、期权、留任包）、绩效评估、离职留任、管理策略、内部政治与个人 PII；保留职业身份、在建项目、职业轨迹、专业观点、工作时间和技能。
- 处理三类泄漏面：页面正文、takes/facts、git 历史。强调 gbrain forget 只是过期而非删除，敏感 fact 行必须从页面 Facts fence 中真正删掉，必要时在共享 brain 上运行 gbrain sync 并触发 fact 重建后再用 gbrain recall --grep 确认。
使用方式：
- 所有路径相对 brain repo 根目录，先执行 BRAIN="$(gbrain config get sync.repo_path)" 与 cd "$BRAIN"。
- 新建团队 brain 时优先对扫描目录的暂存副本脱敏，而非在原地个人 brain 上操作，例如 STAGING="$HOME/.gbrain/backups/brainify-staging-$(date +%Y%m%d-%H%M%S)"，用 rsync 复制到暂存目录再编辑。
- 按 test-before-bulk 先清理 3-5 个文件并人工阅读输出，再分批放大；大批量可每 10-12 个文件并行处理。
- 批量破坏性编辑前触发 data-loss-gate 确认卡，并要求输入明确的 yes/do it。
- Phase 4 用 triage 重跑和针对性 grep（评分字段、电话、薪酬关键词、管理与绩效关键词）验证，再用 gbrain query 与 gbrain takes search 对最终交付的树做检索验证。
- Phase 5 首选非破坏性方案：把暂存树作为全新仓库 git init、提交并推送，个人仓库历史与工作树保持不动；仅当共享仓库已存在敏感历史时才进行镜像备份与历史重写。
适用场景：
- 从创始人/高管个人 brain 建立共享公司 brain。
- 审计既有共享 brain 的敏感内容。
- 新成员加入前对 brain 仓库做清洁认证。
- 对重新累积敏感数据的共享 brain 做定期清洁。
限制与注意事项：
- 敏感判断由模型逐文件做出，grep 只用于分诊与验证，剩余命中需人工确认，不通过收紧正则来消除误报。
- 仅清理工作树不够，git 历史与 takes/facts 仍是泄漏面；未重建 facts 索引的页面编辑仍可能通过检索泄漏。
- 导出时只发布扫描过的目录，不得复制 conversations/、originals/、sources/、inbox/ 等未扫描目录；新目录须先纳入扫描范围。
- 官方资料未提供收费、价格、平台支持范围与效果保证等信息。