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

CHANGELOG.md

@@ -4,6 +4,8 @@
 
 ## Unreleased
 
+- 新增安全、性能、GitNexus 跨模块影响和独立开发总结的可执行治理门禁。
+- 约定后端业务模块内按需分层，以及前端 Axios 统一封装、API 分域和 OpenAPI 类型契约。
 - 项目生产交付统一为 Ubuntu 源码部署，移除 Dockerfile、Compose、镜像校验和容器测试入口。
 - 本地 Redis、MySQL 5.7.42 与 RocketMQ 5.x 均作为外部服务，项目不再提供自动启动或容器兜底。
 - 新增源码发布门禁，校验 Web/Server 构建产物与 systemd、Nginx 配置一致性。

docs/architecture/system-architecture.md

@@ -7,7 +7,9 @@
 ```text
 web/        Vue 3 前端
 server/     NestJS API、Scheduler 与 Worker
-contracts/  HTTP 与 RocketMQ 版本化契约
+server/openapi/                 HTTP OpenAPI 产物
+server/libs/http-contracts/     后端 HTTP DTO
+server/libs/message-contracts/  后端 RocketMQ 版本化契约
 deploy/     MySQL、Redis、RocketMQ 5.x 和运行配置
 docs/       规范、架构、ADR 与功能档案
 tools/      可重复执行的治理和开发工具
@@ -38,7 +40,25 @@ tools/      可重复执行的治理和开发工具
 - Redis保存最新快照、缓存、锁和限流状态。
 - Vue前端只读后端 API，不直接接触外部数据源和密钥。
 
-## 3. 数据库技术基线
+## 3. 前后端模块边界
+
+后端以业务模块为一级目录，模块内部按实际职责建立 Controller、Service、DTO、Domain、Repository 和 Adapter。小模块不强制凑齐目录，禁止把全部 Controller/Service 堆入全局目录，也禁止无业务逻辑的透传层。领域规则只依赖项目端口，MySQL、Redis、RocketMQ、免费数据源和 AI Provider 由基础设施 Adapter 实现。
+
+前端 HTTP 数据流固定为：
+
+```text
+NestJS DTO 与 Swagger 元数据
+  → server/openapi/openapi.json
+  → openapi-typescript 生成 web/src/api/generated/schema.ts
+  → web/src/api/<业务域>/index.ts
+  → web/src/utils/request.ts（Axios）
+  → 功能 adapter / ViewModel
+  → 页面、组件和 Store
+```
+
+OpenAPI 负责描述本项目 HTTP 契约，Axios 负责浏览器实际请求。页面、组件、Store 和 Composable 不直接发 HTTP。兼容 OpenAI API 指未来后端 AI Provider 的外部协议，与前端请求库无关。
+
+## 4. 数据库技术基线
 
 - 数据库服务端固定使用 MySQL 5.7.42；开发、测试和生产环境禁止使用其他补丁版本或 MySQL 8.x 代替兼容性验证。
 - 数据库与表默认字符集固定为 `utf8mb4`，排序规则固定为 `utf8mb4_general_ci`。
@@ -46,11 +66,11 @@ tools/      可重复执行的治理和开发工具
 - 正式启用持久化前，必须在真实 MySQL 5.7 环境验证服务端版本、Schema/表排序规则、迁移和关键查询。
 - 第一阶段市场概览只定义 MySQL Repository 接口并使用内存实现，不启动数据库、不建立生产连接；后续启用时不得改变前端 API 和核心分析契约。
 
-## 4. 当前实施顺序
+## 5. 当前实施顺序
 
 第一阶段先实现可交互的市场综合概览和稳定数据契约，再接入正式行情采集链路。用户、邀请、权限、会员和支付后置，不进入当前核心架构。
 
-## 5. 环境与部署基线
+## 6. 环境与部署基线
 
 - 应用运行环境只定义 `development` 与 `production`；生产环境禁止模拟数据、热更新、调试端口和开发默认值回退。
 - API、Scheduler、Worker、Web 分别拥有开发和生产模板；同一进程跨环境使用相同变量名，通过启动 Schema 校验条件必填项。

docs/governance/code-development-standards.md

@@ -6,13 +6,13 @@
 
 ## 2. 技术基线
 
-- 前端：Vue 3、Vite、TypeScript、Dart Sass、Naive UI。
+- 前端：Vue 3、Vite、TypeScript、Dart Sass、Naive UI；浏览器 HTTP 请求统一使用 Axios，接口类型由 OpenAPI 生成。
 - 后端：NestJS、TypeScript。
 - 数据库：MySQL 5.7.42，字符集 `utf8mb4`，排序规则 `utf8mb4_general_ci`；缓存：Redis；消息队列：RocketMQ 5.x。
 - 图表：Lightweight Charts负责K线和分时，ECharts负责热力图、分布和资金趋势。
 - AI：由服务端调用兼容 OpenAI 格式的付费 API，密钥不得下发浏览器。
 
-依赖版本必须由锁文件固定。引入新依赖前应说明用途、替代方案、体积或运行成本以及退出方案。
+依赖版本必须由锁文件固定。引入新依赖前必须在功能设计中说明用途、现有替代方案、维护状态、许可证、安全风险、前端体积或服务端运行成本以及退出方案，验证通过后才能安装。
 
 ## 3. 文件组织与拆分尺度
 
@@ -32,6 +32,8 @@
 - 为尚未出现的复用场景提前抽象。
 - 为形式上的“分层”添加不产生业务价值的转发层。
 
+复用代码、工具类、Composable 或组件只有在真实重复已经出现、职责边界稳定且抽取确实能降低维护成本时才建立。名称相似、预计以后会用或单纯减少文件行数不构成抽取依据；Review 必须能说明抽取的现有调用方和所有权。
+
 Vue 页面可以包含与页面强绑定的小型展示逻辑；当子区域拥有独立状态、独立测试价值或被复用时再提取组件。NestJS 模块应让入口、服务和领域计算的调用关系容易跟读。
 
 ## 4. 命名与语言
@@ -98,6 +100,12 @@ count += 1;
 ## 9. 前端规范
 
 - 页面不得直接访问第三方行情源、Redis、RocketMQ 或 AI 服务。
+- `web/src/utils/request.ts` 是唯一 Axios 实例、拦截器、超时、取消和通用错误处理入口；其他文件不得创建 Axios 实例。
+- 所有业务接口按后端业务域放在 `web/src/api/<业务域>/index.ts`，API 文件统一调用 `@/utils/request`，不得绕过封装。
+- 页面、组件、Store 和 Composable 不得直接导入 Axios、调用浏览器 `fetch`、拼接业务 URL 或依赖 `AxiosResponse`。
+- 后端 OpenAPI 文档是本项目 HTTP 契约的机器可读描述，与兼容 OpenAI API 的 AI Provider 协议无关。前端保留 `openapi-typescript` 生成类型，实际请求由 Axios 发出。
+- API 函数优先使用生成的请求和响应类型，返回 DTO 或明确的业务结果；禁止用 `any` 取代已有契约，也不得把 Axios 类型扩散到功能层。
+- DTO 到 ViewModel 的转换放在对应功能的 adapter 中；页面不得直接绑定后端 DTO，以免传输字段变化扩散到展示层。
 - 全局服务器状态使用 TanStack Vue Query，本地界面偏好使用 Pinia或轻量组合式函数。
 - Sass token集中管理颜色、间距、圆角、字号和断点。
 - A 股默认红涨绿跌，但状态必须同时提供文字或形状，不能只依赖颜色。
@@ -106,6 +114,11 @@ count += 1;
 
 ## 10. 后端与任务规范
 
+- 后端以业务模块为一级目录，模块内部按实际职责建立 `controllers`、`services`、`dto`、`domain`、`repositories`、`adapters`、`types`、`utils`；小模块不强制凑齐全部目录。
+- Controller 只处理协议、边界参数和响应映射；Service 编排用例、事务与降级；Domain 保存纯业务规则和模型；Repository 描述持久化端口；Adapter 实现 MySQL、Redis、RocketMQ、外部数据源和 AI Provider 边界。
+- DTO、领域模型与数据库实体必须分离。领域层不得依赖 NestJS、TypeORM、Redis 或 RocketMQ SDK；基础设施实现依赖领域端口。
+- 禁止在应用级全局目录堆放所有 Controller 或 Service，禁止为目录外观创建空层或只做无意义转发的包装。跨模块代码只有在真实复用且所有者明确后才上移到 `server/libs`。
+- 分层参考 RuoYi 的职责清晰性和成熟 NestJS 模块实践，不照搬 Java 目录，也不以分层数量衡量架构质量。
 - API、Scheduler和Worker作为独立进程维护，不在请求期间临时抓取全市场数据。
 - Scheduler 只决定何时投递；MessageBusAdapter 负责隔离客户端；RocketMQ 负责任务传输；Worker 负责执行；MySQL 负责事实记录；Redis 负责当前快照和短期状态。
 - 消费者必须幂等，消息确认只能发生在持久化或可验证处理完成后。
@@ -152,14 +165,30 @@ count += 1;
 - AI 密钥、数据源凭证和支付凭证仅存在服务端密钥管理中。
 - SQL必须参数化；外部输入必须在边界处校验。
 - 日志和异常报告必须脱敏。
+- 每个功能和缺陷修复必须在设计中识别资产、数据、信任边界、攻击面、缓解措施和残余风险，在测试计划和 Review 中保存验证证据。
+- 按适用性检查认证与授权、输入校验、SQL/命令/模板注入、XSS、CSRF、CORS、SSRF、限流、凭据、敏感数据、日志、错误、依赖供应链、数据保留和滥用场景。
+- 外部数据源和 AI 还必须检查密钥隔离、上游不可信内容、提示词与事实边界、超时重试、成本控制和不可用降级。
+- 不适用项必须说明不适用于什么、为什么以及适用边界；空白、`无`、`不适用` 或 `N/A` 不能作为安全评估证据。
 
-## 14. 代码 Review 要求
+## 14. 性能要求
+
+- 每个功能必须说明延迟、吞吐、数据新鲜度或资源预算中适用的目标，并按风险选择验证强度。
+- 后端评估数据量与算法复杂度、MySQL 查询/索引/N+1、Redis 用途/TTL/一致性/击穿、API 载荷与分页、Scheduler/Worker 并发/幂等/背压，以及外部数据源和 AI 的超时/重试/批处理/成本。
+- 前端评估依赖与构建体积、渲染次数、长列表、图表数据量、交互响应和内存占用；不能只以开发环境主观感觉作为证据。
+- 高风险路径必须提供 benchmark、profile 或负载测试；低频治理逻辑等不适用场景必须写明无需负载测试的原因和边界。
+- 性能优化不得牺牲数据口径、安全、可观察性、异常恢复或 MySQL 5.7 兼容性；禁止无证据的预优化。
+
+## 15. 代码 Review 要求
 
 开发者完成自测不等于 Review 完成。审查者必须从功能 PRD、设计和 Git diff 出发，检查：
 
 - 业务行为是否真正满足验收标准，是否存在遗漏分支。
 - 类型、数据口径、缓存、消息、事务和异常恢复是否正确。
 - 是否引入安全、性能、并发、幂等或数据一致性风险。
+- 安全策略、性能目标和残余风险是否与实际实现一致，是否提供了风险相称的验证证据。
+- GitNexus 开发前影响是否覆盖其他功能、模块和同步修改，开发后实际影响是否与计划一致。
+- 前端是否遵守 Axios 单一封装和 API 分域，后端是否按业务模块内实际职责分层。
+- 复用抽取是否基于已出现的重复，新增依赖是否完成用途、安全、许可证、体积/成本和退出评估。
 - 测试是否能捕获真实回归，而非只验证 Mock 或实现细节。
 - 中文注释是否解释关键原因、口径和限制，是否存在失真注释。
 - 文件拆分是否便于常规阅读，是否出现过度抽象或巨型多职责文件。

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`。
 - 发布说明和回退方法可执行。

docs/governance/documentation-traceability.md

@@ -14,6 +14,7 @@ docs/features/<编号>-<短名称>/
 ├── design.md
 ├── implementation-plan.md
 ├── test-plan.md
+├── development-summary.md
 ├── gitnexus/
 │   ├── before.md
 │   ├── impact-plan.md
@@ -38,6 +39,9 @@ docs/features/<编号>-<短名称>/
 
 - 已发布文档不删除、不覆盖历史结论；修订通过 Git 历史和文档版本说明保留。
 - PRD 是产品目标和验收口径的正式来源；`requirements.md` 是从 PRD 派生的工程约束，二者不能相互替代。
+- `development-summary.md` 独立记录原始开发需求、范围变化、实际完成需求、修复缺陷、未完成与延期项、关键提交和验证证据，不得合并到 `release-notes.md`。
+- PRD 描述计划达到的目标，开发总结描述实际完成事实，发布说明面向版本使用者描述可用变化；三者内容必须可互相追溯但不能相互替代。
+- 设计、测试计划和 Review 必须分别保存安全、性能、GitNexus 跨模块影响和同步修改证据；不适用项必须写明原因与边界。
 - Review 文件必须记录审查范围、基线提交、审查提交、发现、处置和最终结论，禁止只写“看过了”。
 - 重大方案变化新增 ADR，旧 ADR 标记被替代。
 - 规则、提示词、API 和事件契约使用明确版本。

docs/governance/prd-standard.md

@@ -24,6 +24,10 @@ PRD 是每个业务功能的产品需求事实来源，回答“为谁解决什
 12. 验收标准：使用 Given/When/Then 或等价可测试描述。
 13. 风险与依赖：外部数据、技术、成本和上线依赖。
 14. 发布范围：本次、后续和回退触发条件。
+15. 安全需求与信任边界：资产、数据、访问边界、滥用场景和残余风险。
+16. 性能目标与容量假设：延迟、吞吐、新鲜度、数据量或资源预算中的适用目标。
+17. 关联模块与同步修改：可能影响的功能、契约、数据、缓存、进程、部署、测试和文档。
+18. 新增依赖评估：用途、替代、安全、许可证、体积或运行成本、维护和退出方式。
 
 ## 3. 编写规则
 
@@ -31,4 +35,5 @@ PRD 是每个业务功能的产品需求事实来源，回答“为谁解决什
 - 禁止用“体验更好”“速度较快”等不可验证表达。
 - UI 布局不是需求本身；应先写用户需要识别和完成的行为。
 - PRD 发生实质变化时更新版本和变更记录，并重新确认设计与测试影响。
+- 缺陷修复也必须说明用户可观察问题、受影响范围、同步修改和安全性能边界，不能只记录代码位置。
 - 已发布 PRD 不删除旧结论，废弃需求标记 `superseded` 并说明替代项。

docs/governance/review-standard.md

@@ -4,11 +4,11 @@
 
 ### 代码 Review
 
-以 PRD、设计、实施计划、Git diff和测试证据为输入，审查正确性、安全性、性能、数据一致性、契约兼容性和测试充分性。
+以 PRD、设计、实施计划、Git diff、开发总结和测试证据为输入，审查正确性、安全性、性能、数据一致性、契约兼容性和测试充分性。必须单独记录安全与残余风险、性能与资源影响，以及 GitNexus 实际变化是否符合跨模块同步计划。
 
 ### 开发规范符合性 Review
 
-逐条检查代码开发规范和流程规范，包括中文注释、命名、文件拆分尺度、日志、错误处理、GitNexus前后门禁、中文提交、文档和回退材料。
+逐条检查代码开发规范和流程规范，包括中文注释、命名、文件拆分尺度、真实重复后的抽象依据、前端 Axios/API 分域、后端业务模块内按需分层、依赖评估、日志、错误处理、GitNexus前后门禁、开发总结、中文提交、文档和回退材料。
 
 ## 2. 审查角色
 
@@ -32,6 +32,8 @@ Review 只能使用：
 
 修复 Review 问题后必须记录修复提交和复审结论。代码变化会使旧的 GitNexus开发后报告失效时，必须重新更新图谱和影响报告。
 
+安全或性能不适用时，Review 必须核对理由、边界和实际 diff；无解释的 `无`、`不适用` 或 `N/A` 视为证据缺失。GitNexus 返回 `partial` 或无符号结果时，Review 必须核对静态引用、调用方和 Git diff，不能直接判定无影响。
+
 ## 5. 发布门禁
 
 `review/code-review.md` 和 `review/standards-review.md` 均存在、非空且最终结论为 `passed` 后，功能才允许进入发布状态。

docs/templates/code-review-template.md

@@ -18,6 +18,12 @@
 
 ## 测试缺口
 
+## 安全与残余风险
+
+## 性能与资源影响
+
+## GitNexus 与同步修改
+
 ## 修复与复审
 
 ## 最终结论

docs/templates/development-summary-template.md

@@ -0,0 +1,33 @@
+# <功能名称>开发总结
+
+- 功能编号：
+- 总结版本：
+- 日期：
+
+## 原始开发需求
+
+记录用户确认的原始需求及对应 PRD/工程需求编号。
+
+## 需求与范围变化
+
+记录开发期间新增、调整或取消的范围及确认依据。没有变化时也要说明判断依据，禁止只写“无”。
+
+## 实际完成需求
+
+逐条记录实际完成的需求、可观察结果和对应实现位置。
+
+## 修复缺陷
+
+记录本次修复的缺陷、复现证据和回归测试。没有修复既有缺陷时要说明本次变化的性质，禁止只写 `N/A`。
+
+## 未完成与延期项
+
+记录未完成项、延期原因、影响和后续功能编号。全部完成时也要说明验收依据。
+
+## 关键提交
+
+记录中文提交 SHA、摘要和远程推送核对结果。
+
+## 验证证据
+
+记录测试、构建、视觉验证、安全、性能、GitNexus 和 Review 证据路径。

docs/templates/prd-template.md

@@ -26,6 +26,14 @@
 
 ## 权限、合规与安全
 
+## 安全需求与信任边界
+
+## 性能目标与容量假设
+
+## 关联模块与同步修改
+
+## 新增依赖评估
+
 ## 成功指标
 
 ## 验收标准

docs/templates/standards-review-template.md

@@ -12,15 +12,24 @@
 - [ ] 文件按稳定职责拆分，适合连续阅读，没有过度碎片化。
 - [ ] 命名、类型、单位和时间语义明确。
 - [ ] 错误处理、日志、脱敏和降级符合规范。
+- [ ] 安全策略、性能目标、验证证据和残余风险完整。
+- [ ] 前端 Axios/API 分域与后端业务模块内按需分层符合规范。
+- [ ] 复用抽取基于真实重复，新增依赖已完成用途、安全、许可证、成本和退出评估。
 - [ ] API、事件、规则和提示词按需版本化。
 - [ ] 测试先行证据、构建和视觉验证齐全。
 - [ ] GitNexus开发前后报告和实际变更检测齐全。
+- [ ] GitNexus 已评估其他功能、模块和所需同步修改，实际变化符合计划。
+- [ ] 独立开发总结完整记录需求、范围变化、完成项、缺陷、延期项、提交和验证证据。
 - [ ] PRD、设计、发布说明和回退说明一致。
 - [ ] 提交使用中文 Conventional Commit并关联功能编号。
 - [ ] 未使用 GitHub，未擅自配置或推送远程仓库。
 
 ## 不符合项与处置
 
+## 安全、性能与架构检查
+
+## GitNexus 与开发总结检查
+
 ## 最终结论
 
 最终结论：blocked