feat: 添加项目完整链路说明和开发规范文档

docs/仓库协作者AI分析PR与合并标准流程.md

@@ -4,6 +4,12 @@
 
 本文件用于给仓库协作者自己电脑上的 AI 一个固定、完整、可重复执行的 PR 处理流程。
 
+执行本流程时，AI 必须同时把下面三份根目录文档作为审查依据一起阅读：
+
+- [项目文件结构说明.md](c:/Users/projectf/Downloads/codex注册扩展/项目文件结构说明.md)
+- [项目完整链路说明.md](c:/Users/projectf/Downloads/codex注册扩展/项目完整链路说明.md)
+- [项目开发规范（AI协作）.md](c:/Users/projectf/Downloads/codex注册扩展/项目开发规范（AI协作）.md)
+
 下次只要告诉 AI：
 
 - 本仓库根目录
@@ -28,6 +34,14 @@
 12. 如果流程执行过程中，PR 的实时目标分支被别人改掉，或者不再是 `dev`，AI 必须停止当前合并流程，重新拉取信息后再决定下一步。
 13. 进入“阶段 2：分析与审查”时，AI 必须先给当前 PR 添加 `审查中` 标签，并在开始正式审查前确认该标签已经在线上生效。
 14. 审查结束后，AI 必须根据实际结论把 PR 标签从 `审查中` 切换为 `完成` 或 `等待修改`，并同时把受理人设置为自己；在确认线上状态已更新前，不允许声称审查已完成。
+15. 审查时必须检查该 PR 是否遵守 [项目开发规范（AI协作）.md](c:/Users/projectf/Downloads/codex注册扩展/项目开发规范（AI协作）.md)，不能只检查功能是否可用。
+16. 如果 PR 功能本身没问题，但明显违反开发规范，例如：
+   - 把大段逻辑重新堆回主文件
+   - 没补测试或破坏测试边界
+   - 没同步文档
+   - 破坏共享步骤定义/注册表
+   - 引入可见乱码
+   则也必须判定为“需要修改后再继续”，不能直接给出可合并结论。
 
 ## 输入要求
 
@@ -127,6 +141,7 @@ gh pr edit <PR_NUMBER> --add-label "审查中" --repo <OWNER/REPO>
    - 这些改动是否合理
    - 是否存在 bug / 风险 / 逻辑冲突
    - PR 当前是否可直接合并，例如 `mergeable`、`mergeStateStatus`
+   - 是否遵守项目开发规范
 6. 如果发现问题，结论必须按严重级别排序，优先写真正会影响功能、合并或后续维护的问题。
 7. 如果没有发现明确问题，也要说明剩余风险，例如：
    - 未运行测试
@@ -136,6 +151,12 @@ gh pr edit <PR_NUMBER> --add-label "审查中" --repo <OWNER/REPO>
    - PR 仍然是打开状态
    - PR 不是 draft
    - `baseRefName` 仍然是 `dev`
+9. 审查输出中必须单独包含一节“开发规范符合性检查”，至少明确说明：
+   - 是否违反 [项目开发规范（AI协作）.md](c:/Users/projectf/Downloads/codex注册扩展/项目开发规范（AI协作）.md)
+   - 是否需要补测试
+   - 是否需要补文档
+   - 是否发现可见乱码或编码异常
+   - 是否存在把逻辑重新堆回主文件的情况
 
 ## 分析后评论规则
 
@@ -144,7 +165,7 @@ gh pr edit <PR_NUMBER> --add-label "审查中" --repo <OWNER/REPO>
 如果发现需要作者或维护者注意的问题，AI 必须自动发 PR 评论，并且评论格式必须固定如下：
 
 ```text
-（自动回复）AI分析结果（不一定完全正确，请仓库协作者确认无问题后再继续）：
+（自动回复）AI分析结果（不一定完全正确，请进行确认，若无问题后请评论回复）：
 
 <这里写正式评论内容>
 ```
@@ -160,6 +181,12 @@ gh pr edit <PR_NUMBER> --add-label "审查中" --repo <OWNER/REPO>
 7. 如果结论是“当前不能通过审查”，AI 必须明确写出“需要修改后再继续”，不能只写模糊提醒。
 8. 如果当前环境支持正式 PR review，且问题足以阻止合并，优先使用带“要求更改（Request changes）”语义的审查，而不是只留普通闲聊式评论。
 9. 行级评论是对总评论的补充，不得用零散行级评论替代总评论结论。
+10. 如果问题属于“开发规范不符合”，总评论中必须明确写出违反的是哪类规范，例如：
+   - 模块边界不符合
+   - 测试缺失
+   - 文档未同步
+   - 出现乱码
+   - 共享步骤定义未同步
 
 ### 没问题时
 
@@ -252,6 +279,10 @@ git merge --no-ff --no-commit origin/dev
 6. 要重新拉取一次实时 PR 元数据，确认该 PR 的 `baseRefName` 仍然是 `dev`；如果不是，停止后续合并并先反馈用户。
 7. 要确认 PR 当前已经回到可继续处理的状态，例如不再是 `draft`，且 `mergeable` / `mergeStateStatus` 没有出现新的阻塞。
 8. 默认不编译测试，最后提醒用户自行测试。
+9. 如果本地代修过程中涉及结构调整、功能链路变化或开发边界变化，必须同时检查并在必要时更新：
+   - [项目文件结构说明.md](c:/Users/projectf/Downloads/codex注册扩展/项目文件结构说明.md)
+   - [项目完整链路说明.md](c:/Users/projectf/Downloads/codex注册扩展/项目完整链路说明.md)
+   - [项目开发规范（AI协作）.md](c:/Users/projectf/Downloads/codex注册扩展/项目开发规范（AI协作）.md)
 
 ## 合并提交信息规则