diff --git a/doc/1270-SEONexus-Codex多版本协作交接总文档.md b/doc/1270-SEONexus-Codex多版本协作交接总文档.md index 82365ae..4eef53a 100644 --- a/doc/1270-SEONexus-Codex多版本协作交接总文档.md +++ b/doc/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,50 @@ su -s /bin/bash www -c 'git -C /www/wwwroot/diff-maccms/SEONexus log --oneline - 如果后续发现某条规则经常踩坑,就更新本文件,不要只留在聊天记录里。 +### 3. 项目本地持续分析文档 + +除了需要进入 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` + +边界规则: + +- 可以在每个独立项目里持续写自己的分析文档 +- 也允许每个独立项目优化“本项目私有层” +- 但不建议每个项目独立发明一套公共核心方案 + +也就是: + +- 项目私有观察可以分散记录 +- 公共核心方案仍应集中验证、集中沉淀、再回灌 + --- ## 特别注意事项 diff --git a/docs/1270-SEONexus-Codex多版本协作交接总文档.md b/docs/1270-SEONexus-Codex多版本协作交接总文档.md index 82365ae..052426b 100644 --- a/docs/1270-SEONexus-Codex多版本协作交接总文档.md +++ b/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` + +边界规则: + +- 可以在每个独立项目里持续写自己的分析文档 +- 也允许每个独立项目优化“本项目私有层” +- 但不建议每个项目独立发明一套公共核心方案 + +也就是: + +- 项目私有观察可以分散记录 +- 公共核心方案仍应集中验证、集中沉淀、再回灌 + --- ## 特别注意事项