feat(GOV-006): 建立环境配置与双部署基线

docs/governance/code-development-standards.md

@@ -82,7 +82,18 @@ count += 1;
 - 免费数据源失败时保留最后有效快照，并明确标记陈旧，禁止伪装实时数据。
 - AI 失败不得影响规则分析和基础行情展示。
 
-## 8. 前端规范
+## 8. 环境配置规范
+
+- 应用只接受 `development` 与 `production`，环境必须显式设置。生产启动不得回退到开发默认值、模拟数据、热更新或调试模式。
+- API、Scheduler、Worker 必须使用各自的配置 Schema，在进程启动时验证类型、格式、范围和条件必填项；配置错误立即退出。
+- 同一进程的开发与生产模板必须保持相同变量名。环境差异通过配置值、依赖注入和 Adapter 收敛，禁止在业务代码中散落 `APP_ENV` 分支。
+- 只有 `*.env.example` 可以提交；真实 `.env`、`*.env.local`、密码、Token 和 API Key 必须被 Git 忽略并由运行环境注入。
+- Web 只能使用公开的 `VITE_*` 变量。数据库、Redis、RabbitMQ、数据源和 AI 凭据禁止进入前端变量或构建产物。
+- MySQL、RabbitMQ、正式数据源与 AI 使用显式功能开关；关闭时连接变量可为空，开启后缺少任何必填值都必须拒绝启动。
+- Docker Compose 与源码部署必须复用同一变量契约，禁止为某种部署方式建立语义不同的别名。
+- 生产配置必须位于发布目录之外，切换应用版本不得覆盖配置；日志和诊断输出必须对配置值脱敏。
+
+## 9. 前端规范
 
 - 页面不得直接访问第三方行情源、Redis、RabbitMQ 或 AI 服务。
 - 全局服务器状态使用 TanStack Vue Query，本地界面偏好使用 Pinia或轻量组合式函数。
@@ -91,14 +102,14 @@ count += 1;
 - 图表必须标注单位、时间范围、数据日期和更新时间。
 - 所有核心交互覆盖加载、空、部分数据、错误和过期状态。
 
-## 9. 后端与任务规范
+## 10. 后端与任务规范
 
 - API、Scheduler和Worker作为独立进程维护，不在请求期间临时抓取全市场数据。
 - Scheduler只决定何时投递；RabbitMQ负责任务传输；Worker负责执行；MySQL负责事实记录；Redis负责当前快照和短期状态。
 - 消费者必须幂等，消息确认只能发生在持久化或可验证处理完成后。
 - 免费数据源通过 Adapter 统一为内部模型，上层不得依赖供应商原始字段。
 
-## 10. MySQL 5.7 兼容规范
+## 11. MySQL 5.7 兼容规范
 
 - 开发、测试、Docker 和生产环境必须使用明确的 MySQL 5.7 补丁版本，禁止使用 `latest`、MySQL 8.x 或其他数据库代替兼容性验证。
 - 创建数据库必须显式声明 `DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci`；建表与迁移脚本必须显式保持 `DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci`。
@@ -112,7 +123,7 @@ count += 1;
 - 每份迁移脚本必须能够从上一版本基线在 MySQL 5.7 正向执行；禁止用直接修改共享数据库表代替迁移脚本。
 - 代码 Review 必须检查服务端版本、字符集、排序规则、SQL/迁移兼容性、索引长度和字符串比较语义；任一不符合项按 Important 处理并阻断发布。
 
-## 11. 测试要求
+## 12. 测试要求
 
 - 功能和缺陷修复遵循测试先行：先看到测试因缺少行为而失败，再实现最小代码。
 - 纯规则和指标计算使用单元测试，期望值必须手工推导。
@@ -121,14 +132,14 @@ count += 1;
 - 关键页面使用 Playwright流程测试和视觉截图对比。
 - 合并前必须通过类型检查、测试、构建和适用的视觉验证。
 
-## 12. 安全要求
+## 13. 安全要求
 
 - 禁止提交 `.env`、API Key、密码、真实账号和生产数据。
 - AI 密钥、数据源凭证和支付凭证仅存在服务端密钥管理中。
 - SQL必须参数化；外部输入必须在边界处校验。
 - 日志和异常报告必须脱敏。
 
-## 13. 代码 Review 要求
+## 14. 代码 Review 要求
 
 开发者完成自测不等于 Review 完成。审查者必须从功能 PRD、设计和 Git diff 出发，检查：
 

docs/governance/development-workflow.md

@@ -23,14 +23,15 @@ released → superseded
 5. 比较可选方案，记录设计与关键决策。
 6. 更新 API、事件和数据结构契约。
 7. 编写测试计划和实施计划。
-8. 确保 Git 工作区基线可识别，执行：
+8. 明确功能需要的环境变量、功能开关和部署影响；同步更新开发/生产模板，禁止只修改本机真实 env。
+9. 确保 Git 工作区基线可识别，执行：
 
 ```bash
 npm run governance:start -- FEAT-MO-001 market-overview
 ```
 
-9. 运行 GitNexus 查询、上下文和影响分析，将结果写入 `gitnexus/impact-plan.md`。
-10. 高风险或关键路径变化必须先向用户说明影响，再进入开发。
+10. 运行 GitNexus 查询、上下文和影响分析，将结果写入 `gitnexus/impact-plan.md`。
+11. 高风险或关键路径变化必须先向用户说明影响，再进入开发。
 
 开发前必须至少回答：修改什么、为什么修改、影响谁、如何验证、失败后如何回退。
 
@@ -79,6 +80,7 @@ npm run governance:finish -- FEAT-MO-001 market-overview
 - 发布说明和回退方法可执行。
 - 中文提交已关联功能编号。
 - 当前分支和本次新建标签已推送到 `origin`，功能档案保存远程核对结果。
+- 配置契约变化已同步开发/生产模板和适用的 Compose、systemd、Nginx及部署文档。
 
 ## 7. 提交流程