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

docs/governance/development-workflow.md

@@ -24,18 +24,20 @@ released → superseded
 6. 编写 `prd.md`，明确用户问题、目标、范围、非目标、用户流程、指标、风险和验收标准。
 7. PRD 审核通过后，将产品需求转换为可测试的工程需求。
 8. 比较可选方案，记录设计与关键决策。
-9. 更新 API、事件和数据结构契约。
-10. 编写测试计划和实施计划。
-11. 明确功能需要的环境变量、功能开关和部署影响；同步更新开发/生产模板，禁止只修改本机真实 env。
-12. 确保 Git 工作区基线可识别，执行：
+9. 在设计中完成安全策略与评估、性能目标与评估；不适用项必须写明原因和边界。
+10. 更新 API、事件和数据结构契约，并评估新增依赖的替代、安全、许可证、体积或运行成本及退出方案。
+11. 编写测试计划和实施计划，明确安全验证、性能验证和风险相称的测试强度。
+12. 明确功能需要的环境变量、功能开关和部署影响；同步更新开发/生产模板，禁止只修改本机真实 env。
+13. 确保 Git 工作区基线可识别，执行：
 
 ```bash
 npm run governance:start -- FEAT-MO-001 market-overview
 ```
 
-13. `governance:start` 会只读复核上一发布版本 Schema 基线；缺失、失效或版本不一致时立即阻断，不会代为生成。
-14. 运行 GitNexus 查询、上下文和影响分析，将结果写入 `gitnexus/impact-plan.md`。
-15. 高风险或关键路径变化必须先向用户说明影响，再进入开发。
+14. `governance:start` 会只读复核上一发布版本 Schema 基线；缺失、失效或版本不一致时立即阻断，不会代为生成，并为后续功能建立 `gitnexus/impact-plan.md` 骨架。
+15. 功能开发和缺陷修复都必须运行 GitNexus query、context 和 upstream impact，将直接/间接消费者、执行流、风险与工具限制写入 `gitnexus/impact-plan.md`。
+16. 必须逐项判断 HTTP/OpenAPI、Web API 与 adapter、消息契约、数据库迁移与 Schema、Redis、API、Scheduler、Worker、配置部署、测试和文档是否需要同步修改。
+17. HIGH 或 CRITICAL 风险及关键路径变化必须先向用户说明影响并取得确认，再进入开发；`partial` 或工具不可用不能解释为无影响，必须用静态引用和 Git diff 交叉验证。
 
 开发前必须至少回答：修改什么、为什么修改、影响谁、如何验证、失败后如何回退。
 
@@ -44,6 +46,8 @@ npm run governance:start -- FEAT-MO-001 market-overview
 - 使用短期功能分支；当前仓库基线建立阶段经用户明确确认后可直接在 `main` 工作。
 - 每个可观察行为先写失败测试，再实现最小代码并重构。
 - 需求或设计发生变化时，先更新功能档案并记录原因，再改代码。
+- 代码持续检查安全边界与性能目标；出现新的攻击面、容量假设或依赖时，先回写设计和测试计划。
+- 只有真实重复已经出现且职责稳定时才抽取工具、组件或共享库，禁止按预期未来需求提前抽象。
 - 每个阶段保存必要截图和测试结果，禁止只在聊天中保留决定。
 - 发现缺陷时先记录复现步骤和失败测试，禁止无证据猜测式修复。
 
@@ -53,21 +57,22 @@ npm run governance:start -- FEAT-MO-001 market-overview
 2. 对界面变化保存参考图、实现图和同视口对比结果。
 3. 查看 Git diff，确认没有计划外文件和密钥。
 4. 执行 GitNexus 变更检测；若 MCP 工具不可用，记录限制并至少保存 Git diff 与重新索引结果。
-5. 再次运行：
+5. 填写 `gitnexus/after.md`、`detected-changes.md` 和 `comparison.md`。
+6. 填写独立 `development-summary.md`，明确原始需求、范围变化、实际完成、修复缺陷、未完成项、关键提交和验证证据；不得合并到发布说明。
+7. 执行代码 Review，将安全与残余风险、性能与资源影响、GitNexus 同步修改、问题严重程度、修复提交和复审结论写入 `review/code-review.md`。
+8. 逐条执行开发规范符合性 Review，检查前后端架构、抽象依据、依赖评估和开发总结，将结果写入 `review/standards-review.md`。
+9. 任一 Review 为 `changes_required` 时，返回开发阶段；修复后重跑相关测试、GitNexus开发后分析和 Review。
+10. 两项 Review 均为 `passed` 且全部证据文件齐全后，运行：
 
 ```bash
 npm run governance:finish -- FEAT-MO-001 market-overview
 ```
 
-6. 填写 `gitnexus/after.md`、`detected-changes.md` 和 `comparison.md`。
-7. 执行代码 Review，将问题、严重程度、修复提交和复审结论写入 `review/code-review.md`。
-8. 逐条执行开发规范符合性 Review，将结果写入 `review/standards-review.md`。
-9. 任一 Review 为 `changes_required` 时，返回开发阶段；修复后重跑相关测试、GitNexus开发后分析和 Review。
-10. 两项 Review 均为 `passed` 后，更新发布说明、回退说明、变更记录和版本号。
-11. 使用中文 Conventional Commit 提交。
-12. 提交后立即将当前分支推送到项目专用 Gitea `origin`；如果本次创建了标签，再精确推送该标签。
-13. 比较本地与远程分支 SHA，并将提交、推送目标和结果写入功能档案。推送失败时保留本地提交，任务状态保持未完成。
-14. 提交后执行 `npx gitnexus status`；若状态过期，再运行 `npx gitnexus analyze`。
+11. 完成门禁通过后，更新发布说明、回退说明、变更记录和版本号。
+12. 使用中文 Conventional Commit 提交。
+13. 提交后立即将当前分支推送到项目专用 Gitea `origin`；如果本次创建了标签，再精确推送该标签。
+14. 比较本地与远程分支 SHA，并将提交、推送目标和结果写入功能档案。推送失败时保留本地提交，任务状态保持未完成。
+15. 提交后执行 `npx gitnexus status`；若状态过期，再运行 `npx gitnexus analyze`。
 
 ## 6. 完成定义
 
@@ -79,6 +84,10 @@ npm run governance:finish -- FEAT-MO-001 market-overview
 - 测试和构建有最新成功证据。
 - 视觉变化有同视口对比证据。
 - GitNexus 开发前后报告和差异说明齐全。
+- 开发总结明确记录原始需求、范围变化、完成需求、修复缺陷、延期项、提交和验证证据。
+- 安全策略、性能目标、验证证据和残余风险完整；不适用项有原因及边界。
+- GitNexus 已评估其他功能和模块的影响，同步修改清单与实际变更一致。
+- 前端 Axios/API 分域和后端业务模块内按需分层符合开发规范。
 - 代码 Review 结论为 `passed`，Critical 和 Important 问题已关闭。
 - 开发规范符合性 Review 结论为 `passed`。
 - 发布说明和回退方法可执行。