docs(GOV-010): 完善安全性能与架构规范

AGENTS.md

@@ -20,6 +20,11 @@
 9. 开发完成后必须先通过代码 Review 和开发规范符合性 Review，再进入发布；Review 结论和问题处置必须写入功能档案。
 10. 每次提交验证通过后必须立即推送当前分支到项目 Gitea；本次新建标签必须单独推送。推送失败时任务不得标记完成，禁止强推或自动覆盖未知远程提交。
 11. Schema 基线只能读取 `APP_ENV=development` 的 `a_share_analysis_dev`，启用时主机必须命中代码内固定开发白名单（开发机回环地址或 `112.192.20.11`）；禁止连接、探测或读取生产数据库。MySQL 未启用时只允许生成可验证的 `not_applicable` 清单，启用但无对象时生成 `captured_empty` 清单，禁止用空 SQL 冒充基线。`governance:start` 还必须确认基线已提交、已推送且远程标签一致。
+12. 功能和缺陷修复开发前必须用 GitNexus 评估直接、间接及跨模块影响，并逐项判断 HTTP/OpenAPI、Web API、消息、数据库、Redis、API、Scheduler、Worker、部署、测试和文档是否同步修改；`partial` 结果不得视为无影响。
+13. 设计、测试计划和 Review 必须包含安全策略、性能目标、验证证据及残余风险；不适用项必须写明原因与边界。
+14. 每个未发布功能必须有独立 `development-summary.md`，明确原始需求、范围变化、实际完成、修复缺陷、延期项、关键提交和验证证据，不得合并到发布说明。
+15. 后端以业务模块为一级目录并在模块内按需分层，小模块不凑目录；前端统一由 `web/src/utils/request.ts` 封装 Axios，业务请求只能位于 `web/src/api/<业务域>/index.ts`，OpenAPI 类型继续作为契约来源。
+16. 复用代码只有在真实重复和稳定职责出现后才能抽取；新增依赖必须先评估用途、替代、安全、许可证、体积或运行成本、维护和退出方案。
 
 <!-- gitnexus:start -->
 # GitNexus — Code Intelligence