docs add storage analysis rules for project-local notes

docs/1270-SEONexus-Codex多版本协作交接总文档.md

@@ -274,6 +274,53 @@ su -s /bin/bash www -c 'git -C /www/wwwroot/diff-maccms/SEONexus log --oneline -
 
 所以这不是代码问题，也不是远端仓库问题，而是当前机器上的 Git 身份边界。
 
+### 5.1 仓库 ownership 也必须保持 `www:www`
+
+除了 `git push` 只能使用 `www`，当前机器上还要额外遵守一条：
+
+- `SEONexus` 仓库目录本身也必须保持 `www:www`
+
+尤其不能让下面这些路径长期混入 `root:root`：
+
+- `.git`
+- `.git/index`
+- `.git/objects/*`
+- `docs/`
+- 其它会被 `git pull` / `git checkout` 自动写入的目录
+
+已经验证过的真实故障现象包括：
+
+- `error: insufficient permission for adding an object to repository database .git/objects`
+- `fatal: failed to write object`
+- `fatal: unpack-objects failed`
+- `error: unable to create file docs/...: Permission denied`
+
+这类问题的根因不是远端仓库异常，而是：
+
+- 前面曾用 `root` 对仓库做过 `commit`、写文件或目录创建
+- 导致 `www` 后续执行 `pull` / `push` / `stash` 时权限链断掉
+
+因此后续建议固定为：
+
+- 与 Git 直接相关的操作优先都用 `www`
+- `root` 只做日志排查、系统命令、权限修复
+- 不要再用 `root` 在仓库里直接 `commit`、`pull`、`push`
+
+如果已经出现 ownership 混乱，优先修复命令为：
+
+```bash
+chown -R www:www /www/wwwroot/diff-maccms/SEONexus
+```
+
+如果只是 `.git` 或仓库内同步文档目录出错，也至少要修：
+
+```bash
+chown -R www:www /www/wwwroot/diff-maccms/SEONexus/.git
+chown -R www:www /www/wwwroot/diff-maccms/SEONexus/docs
+```
+
+这条规则和“只能 `www` 推送”应视为同一组约束，不能只做一半。
+
 ### 6. `SEONexus` 与 `SEONexusAdmin` 是同机双仓协作
 
 当前机器上：
@@ -474,6 +521,79 @@ su -s /bin/bash www -c 'git -C /www/wwwroot/diff-maccms/SEONexus log --oneline -
 
 如果后续发现某条规则经常踩坑，就更新本文件，不要只留在聊天记录里。
 
+### 3. 单次线上事件排障文档
+
+这类文档适合记录：
+
+- 某一次正式服报错的完整排查过程
+- 问题阶段
+- 根因
+- 线上改动
+- 验证结果
+- 下一位 Codex 的接手建议
+
+当前已沉淀样例：
+
+- [2026-04-16-admin2-spider-workbench-production-fix.md](/www/wwwroot/diff-maccms/SEONexus/docs/2026-04-16-admin2-spider-workbench-production-fix.md)
+
+使用原则：
+
+- `1269` 这类文档负责阶段执行
+- `1270` 这类文档负责长期协作规则
+- `2026-xx-xx-...production-fix` 这类文档负责单次线上事件闭环
+
+这样后续主 Codex 接手时：
+
+- 先看长期规则
+- 再看当前阶段执行文档
+- 最后看最近一次线上事件文档
+
+就不会只靠聊天记录反推上下文。
+
+### 4. 项目本地持续分析文档
+
+除了需要进入 Git 的正式文档外，每个项目还允许保留一套“只服务当前项目持续优化”的本地分析文档。
+
+这类文档推荐放在项目自己的：
+
+- `code/storage/_analysis/`
+
+使用原因：
+
+- 每个项目都有自己的蜘蛛日志来源、观察窗口和异常轨迹
+- 这类分析如果完全不记录，后续优化容易断档
+- 但如果全部提交进 Git，又会把大量过程性观察和未确认判断写进正式历史
+
+因此这类文档的定位是：
+
+- 允许持续记录
+- 默认不提交
+- 以项目私有观察为主
+- 适合记录尚在观察期的中间结论
+
+推荐最少按两层组织：
+
+- `code/storage/_analysis/sources/`
+- `code/storage/_analysis/domains/`
+
+例如：
+
+- `code/storage/_analysis/sources/baiduspider.md`
+- `code/storage/_analysis/sources/sogou.md`
+- `code/storage/_analysis/domains/sjzyunyang.com.md`
+- `code/storage/_analysis/domains/jingxifa.com.md`
+
+边界规则：
+
+- 可以在每个独立项目里持续写自己的分析文档
+- 也允许每个独立项目优化“本项目私有层”
+- 但不建议每个项目独立发明一套公共核心方案
+
+也就是：
+
+- 项目私有观察可以分散记录
+- 公共核心方案仍应集中验证、集中沉淀、再回灌
+
 ---
 
 ## 特别注意事项