docs sync collaboration guides into repository docs

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

@@ -274,6 +274,79 @@ su -s /bin/bash www -c 'git -C /www/wwwroot/diff-maccms/SEONexus log --oneline -
 
 所以这不是代码问题，也不是远端仓库问题，而是当前机器上的 Git 身份边界。
 
+### 6. `SEONexus` 与 `SEONexusAdmin` 是同机双仓协作
+
+当前机器上：
+
+- `SEONexus`
+- `SEONexusAdmin`
+
+都位于同一台机器的 `/www/wwwroot/` 下。
+
+这意味着：
+
+- 它们适合联合排查
+- 但仍然是两个独立仓库
+- 不能因为同机就默认一起改
+
+推荐理解方式：
+
+- `SEONexus` 主要负责后端接口、路由、helper、model、日志、返回结构
+- `SEONexusAdmin` 主要负责前端页面、接口调用、参数、token/header、错误展示
+- Nginx / 域名 / 反代 / CORS / 登录态链路属于同机环境层
+
+因此遇到后台报错时：
+
+- 可以跨仓一起查
+- 但修复时先判断主战场
+- 一轮优先只改一个主仓
+
+例如：
+
+- 如果是接口 500、类缺失、helper 丢失、路由没挂，主战场通常是 `SEONexus`
+- 如果是 axios 参数、header、token、前端展示层误报，主战场通常是 `SEONexusAdmin`
+- 如果是跨域、代理、cookie、header 丢失，主战场通常是 Nginx / 反代配置
+
+这条规则的核心不是“分开”，而是：
+
+- 同机便于联查
+- 分仓便于控边界
+
+### 7. 不建议现在把所有项目硬并成一个 Git 仓库
+
+当前更适合的结构是：
+
+- 多个独立 Git 仓库
+- 通过仓库内 `doc/` 文档同步协作规则
+- 通过明确边界控制多 Codex 并行协作
+
+不建议现在把所有项目直接并成一个大仓，原因包括：
+
+- `SEONexus`、`SEONexusAdmin`、node 工具链、蜘蛛代理脚本、历史参考目录，生命周期并不一致
+- 不同项目的提交节奏不同，强行并仓后日志会很乱
+- 后续回滚、比对、定向发布会更重
+- 正式服未必需要开发机当前的总目录结构
+- 现在真正需要同步的是规则和关键文档，不是把所有杂项目录绑成一个提交历史
+
+当前阶段更推荐：
+
+- 业务主仓继续独立维护
+- 关键协作文档同步到主仓的 `doc/`
+- 需要跨仓排查时，通过文档说明目录关系和排查顺序
+
+只有在未来满足以下条件时，才考虑是否要做 monorepo：
+
+- 多个仓长期高度耦合
+- 发布必须严格同版本号
+- CI/CD 也准备统一
+- 权限、分支策略、回滚策略都已经设计清楚
+
+在当前阶段，最稳的结论是：
+
+- 不要把所有项目硬归成一个 Git
+- 先把“协作规则归一、文档入口归一、推送口径归一”做好
+- 这样收益更大，风险更小
+
 ---
 
 ## 工作顺序标准流程