工作区迁移（原 ~/工作室 → ~/xingtu，1.6G 完整）已验证；元宝卡片解析器完成三轮迭代并通过真实链接端到端验证；快手调研、账号收敛、短视频规划三份报告已出。
提交身份目前是三套并存的：全局配置是 Justin Li + noreply，但已推送的 32 个 commit 全部是 xingtu1996 <xingtu@**.com>，而规划文档里记的却是"1 个公司邮箱"——三个说法对不上。这正是你最在意的"提交 a 又提交 b，其实是 1 个人"的问题源头，越晚改，历史越难洗。
err_code 识别），并用真实链接完成端到端验证——确认微信外抓取会被服务端拒绝，工具"不绕过限制"的边界成立。~/工作室 全部迁入 ~/xingtu（含 26 个 skills，软链已重建），1.6G 完整、3 个 git 仓无损。残留 .workbuddy_根目录备份/、tools_工作室根/ 等冲突副本待清理。git init -b main 完成，但均只有骨架（README + LICENSE + .gitignore），资产内容为空。| 层级 | 内容 | 处理方式 |
|---|---|---|
| 公开层 | xingtu1996.github.io（Pages 名片） xingtu-site（个人站） xingtu-vault（知识库） + 开源矩阵 11 仓 |
先私有 → 逐仓审阅 → 转公开。vault 需先审隐私再定是否公开。 |
| 私有层 | research（186M）· tools（190M）· outputs（112M）· 素材库 · specs · feishu_bot · workflows/rules/publish | 候选分 4–5 个主题私有仓：-content / -research / -specs / -bot / -toolbox；或合并为 1–2 个 monorepo。 |
| 排除层 | .idea/ .trash/ .backups/(180M) xingtu_backup_20260819/(354M) usage-logs-*.xlsx 等 |
永不进 git，写进 .gitignore。 |
| 🔴 最高敏感 | data/wechat_decrypted/(427M) · specs/微信数据库密钥_20260827.json · research/wechat_decrypt.py · 各类 API Key / token 配置 |
禁止进任何仓，包括私有仓。这是 SAF-006 红线。 |
规划文档写的是"xingtu-site 有 1 个公司邮箱 commit"。我逐仓核对实际历史，不是这样：
32 个 commit 全部使用 163 个人邮箱，零个 noreply。而当前全局配置却是 Justin Li <274853659+xingtu1996@users.noreply.github.com>。
xingtu@**.com 未在你的 GitHub 账号里验证绑定 → 这 32 个 commit 在 GitHub 上显示为灰色无头像的独立用户，不归入 xingtu1996。Justin Li + noreply，历史是 xingtu1996 → 同一个人被切成两个贡献者，贡献图直接裂开。某公司域名 的 commit——规划文档那条记录有误，好消息是身份泄露风险不存在，坏消息是身份分裂问题比预想的大。| 配置项 | 推荐值 | 说明 |
|---|---|---|
| user.name | xingtu1996（推荐）备选 Justin Li / XingTu | 与账号、品牌一致，不暴露真名。建议与历史 name 保持一致以减少改动量。 |
| user.email | 274853659+xingtu1996@users.noreply.github.com | GitHub 官方 noreply，自动归并到账号，且永不泄露真实邮箱。全局已配，保持不变即可。 |
我查了 GitHub 实况，xingtu1996 名下仍然只有 4 个旧仓，11 个新仓全部为 0 commit、无远程。规划里的定时任务 ID 11623840044290 在当前环境不存在（它应该在豆包会话里建的，不会在这里触发）。
影响：发布链路上游是空的，harness 用 submodule 聚合的 8 个资产仓目前也全是空壳——先发等于发 11 个空仓库，反而扣分。
见 §2.2。这是唯一有"时间成本"的问题——每多推一个 commit，后续 filter-repo 重写的范围就更大。建议在任何新发布动作之前先定死身份。
github.cn-pgcloud.com → 账号 li-jc-1，token 已失效，但仍标记为 active 且排在第一位github.com → 账号 xingtu1996，✅ 有效（SSH 协议）好消息：publish.sh 里已经用 HOST 变量锁死了 github.com，脚本本身是安全的。风险在于手工执行 gh repo create 时不带 --hostname github.com，会打向失效的那个 host 并报错。建议：要么清理掉失效 host，要么全局设 GH_HOST=github.com。
现场核实：~ 的 git rev-parse --show-toplevel 返回家目录本身，已 tracked
170 个文件，而 git check-ignore xingtu 无任何输出 = 未被忽略。
风险场景：哪天在家目录随手敲一个 git add -A，整个 xingtu 工作区（含 427M 微信解密数据、密钥文件）会被卷进这个仓。这是一颗哑弹，现在不响，但迟早响。
我在核对时抓到：xingtu-ai-engineering/README.md 的最后修改时间是 13:04，LICENSE 是 13:03——就在几分钟前。说明豆包那边（或另一个会话）正在同步推进主线 B。
该仓当前状态：6 个分类目录各 1 个占位文件（共 28 文件），75 个源文件的实质内容还没有复制过来，脱敏尚未真正开始（敏感词扫描 0 命中，因为还没内容）。
建议：明确指定一个会话主导文件写入，否则两份产出会互相覆盖。
《工作空间 Git 全纳管规划》§2.1 把 xingtu-site 和 xingtu-vault 都标注为"公开"。GitHub 实况是两者都是 PRIVATE，目前只有 xingtu1996.github.io 是 PUBLIC。
对照之下，项目长期记忆（MEMORY.md §12.1）记的"site 私有 / vault 私有 / github.io 公开 / docs 私有"与实际完全一致，是准的。错的只是这份新 spec。
这条会误导"要不要转公开"的决策链，建议修正 spec；记忆文件无需改动。
xingtu1996，全局是 Justin Li。选 xingtu1996 则历史 name 无需改动，只需改邮箱。xingtu@**.com 统一改写为 noreply 邮箱，然后 force push。3 个仓都是个人仓、无协作者，风险低。建议做，且尽早做。今天真正的瓶颈不是"要不要纳管"，而是"用什么身份纳管"。纳管是体力活，随时能补；身份一旦散出去，GitHub 贡献图和账号归属就裂了，且随时间放大。建议今晚只做 Step 1，其余明天再说。