Compare commits

..
Author SHA1 Message Date
FoXiMao b49e7b8b08 docs(GOV-012): 完成发布后基线追溯记录 2026-08-18 03:10:29 +08:00
FoXiMao 11edeb0111 chore(GOV-012): 封存 v0.0.10 开发库 Schema 基线 2026-08-18 03:08:38 +08:00
FoXiMao 16bde94df6 chore(GOV-012): 发布 v0.0.10 元数据 2026-08-18 03:06:48 +08:00
FoXiMao 58026aead3 docs(GOV-012): 完成功能质量与发布追溯档案 2026-08-18 03:04:59 +08:00
FoXiMao f1c412b6a3 docs(GOV-012): 更新纯 Node Schema 基线规范 2026-08-18 03:00:47 +08:00
FoXiMao afd186c8a4 fix(GOV-012): 兼容 MySQL 5.7 视图目录并封存 v0.0.9 基线 2026-08-18 02:57:40 +08:00
FoXiMao 874796ab65 fix(GOV-012): 修复 Schema 定义安全与错误语义 2026-08-18 02:46:50 +08:00
FoXiMao 3d12c83621 fix(GOV-012): 修复目录元数据校验与查询错误脱敏 2026-08-18 02:34:14 +08:00
FoXiMao c11de09fa7 feat(GOV-012): 升级 Schema 基线 format v3 2026-08-18 02:24:54 +08:00
FoXiMao dc8ad7d4b6 feat(GOV-012): 实现完整 SHOW CREATE 结构导出 2026-08-18 02:02:41 +08:00
FoXiMao 7e9d9065bb feat(GOV-012): 实现 Schema 对象目录与视图排序 2026-08-18 01:54:50 +08:00
FoXiMao 54fd92837a docs(GOV-012): 更新安全契约 GitNexus 基线 2026-08-18 01:49:16 +08:00
FoXiMao 8e954a3f5f fix(GOV-012): 拒绝 MariaDB 伪装版本 2026-08-18 01:44:25 +08:00
FoXiMao 06466f388e feat(GOV-012): 建立纯 Node 导出器安全契约 2026-08-18 01:21:29 +08:00
FoXiMao 235163cb61 chore(GOV-012): 忽略 SDD 过程账本 2026-08-18 01:11:41 +08:00
FoXiMao cb2e22c13d chore(GOV-012): 忽略本地功能工作区 2026-08-18 01:10:46 +08:00
FoXiMao 97535b8b3f docs(GOV-012): 更新实施计划 GitNexus 基线 2026-08-18 01:08:00 +08:00
FoXiMao 190fba7a0b docs(GOV-012): 完成纯 Node Schema 导出器实施计划 2026-08-18 01:07:14 +08:00
FoXiMao 0f81677b35 docs(GOV-012): 更新设计阶段 GitNexus 基线 2026-08-18 00:47:16 +08:00
FoXiMao c605935403 docs(GOV-012): 确认纯 Node Schema 导出器设计 2026-08-18 00:46:03 +08:00
FoXiMao 3555b7c222 docs(FEAT-MO-001): 更新 TDX 接入后的 GitNexus 基线 2026-08-18 00:34:08 +08:00
FoXiMao 998c9276d5 docs(FEAT-MO-001): 记录 TDX 双场景开发接入 2026-08-18 00:32:04 +08:00
FoXiMao c0a6f55605 docs(GOV-011): 更新最终 GitNexus 基线 2026-08-17 18:00:49 +08:00
FoXiMao 405b9858f0 docs(GOV-011): 回填 v0.0.9 发布追溯 2026-08-17 18:00:11 +08:00
FoXiMao 88e2fdffc8 chore(GOV-011): 发布 v0.0.9 系列版本约束 2026-08-17 17:58:02 +08:00
FoXiMao 7478a96bdc docs(GOV-011): 完成系列版本验证与审查 2026-08-17 17:50:58 +08:00
FoXiMao cce77aa884 docs(GOV-011): 统一运行时系列版本口径 2026-08-17 17:36:44 +08:00
FoXiMao dc8da80809 fix(GOV-011): 支持 MySQL 5.7 系列健康检查 2026-08-17 17:31:10 +08:00
FoXiMao 54499f0678 fix(GOV-011): 放宽 MySQL 服务端为完整 5.7 系列 2026-08-17 17:28:48 +08:00
FoXiMao c8277ef25a test(GOV-011): 补充 Node 22 系列边界验证 2026-08-17 17:23:29 +08:00
FoXiMao 426870b704 docs(GOV-011): 制定运行时系列版本实施计划 2026-08-17 17:19:38 +08:00
FoXiMao fcfef2d524 docs(GOV-011): 确认系列版本约束设计 2026-08-17 17:01:39 +08:00
FoXiMao 9e85809096 docs(GOV-009): 封存 GOV-009 与 GOV-010 架构基线 2026-08-17 16:27:37 +08:00
FoXiMao 4971077d3b docs(FEAT-DS-001): 更新操作手册后的 GitNexus 基线 2026-08-17 12:25:56 +08:00
FoXiMao 81e5d331ca docs(FEAT-DS-001): 新增 Tailscale TDX 开发操作手册 2026-08-17 12:25:13 +08:00
FoXiMao 4f5588ffcb docs(FEAT-DS-001): 更新规划后的 GitNexus 基线 2026-08-14 03:06:07 +08:00
FoXiMao 551fe5e5e7 docs(FEAT-DS-001): 记录采集器后置与本地数据源方案 2026-08-14 03:05:23 +08:00
FoXiMao a398bc418d docs(GOV-010): 更新最终 GitNexus 基线 2026-08-14 00:01:15 +08:00
FoXiMao 38b731a334 docs(GOV-010): 完善最终验证追踪 2026-08-13 23:58:11 +08:00
FoXiMao f178fb4044 feat(GOV-010): 完成开发质量与架构治理 2026-08-13 23:56:21 +08:00
FoXiMao 61f85e5fa4 docs(GOV-010): 记录开发需求与完成结果 2026-08-13 23:35:50 +08:00
FoXiMao e992edccce fix(GOV-010): 修复 Swagger 传递依赖漏洞 2026-08-13 23:32:46 +08:00
FoXiMao d2c18634ed feat(GOV-010): 建立前端 API 分域边界 2026-08-13 23:14:22 +08:00
FoXiMao 4105336cb2 refactor(GOV-010): 统一封装前端 Axios 请求 2026-08-13 23:02:36 +08:00
FoXiMao 3a22fdeef3 docs(GOV-010): 完善安全性能与架构规范 2026-08-13 22:54:32 +08:00
FoXiMao e12c57222b feat(GOV-010): 强制校验开发质量证据 2026-08-13 22:47:51 +08:00
FoXiMao a8dcd0601b docs(GOV-010): 制定开发质量治理实施计划 2026-08-13 22:37:35 +08:00
FoXiMao 1c1b15e709 docs(GOV-010): 确认开发质量与架构规范设计 2026-08-13 22:20:54 +08:00
FoXiMao bbda26fa41 docs(GOV-009): 更新最终 GitNexus 索引统计 2026-08-13 21:35:45 +08:00
FoXiMao c75665446b fix(GOV-009): 完成仅源码部署最终复审 2026-08-13 21:33:38 +08:00
FoXiMao 47d0e0d248 refactor(GOV-009): 彻底切换为仅源码部署 2026-08-13 21:12:12 +08:00
FoXiMao ab48f06150 docs(GOV-009): 制定仅源码部署实施计划 2026-08-13 20:55:31 +08:00
FoXiMao cfcd7f13d9 docs(GOV-009): 确认仅源码部署设计 2026-08-13 20:46:58 +08:00
FoXiMao f50268b70f docs(GOV-009): 封存脚手架复核材料 2026-08-13 19:55:45 +08:00
FoXiMao 95b8611bd9 fix(GOV-009): 封堵外部脚本边界绕过 2026-08-13 19:49:42 +08:00
FoXiMao cb550e3d5c fix(GOV-009): 完成最终复审整改 2026-08-13 18:51:14 +08:00
FoXiMao 3a8120a33a fix(GOV-009): 完成脚手架审查整改 2026-08-13 18:30:57 +08:00
FoXiMao dcdf634457 fix(GOV-009): 消除前端运行时模板警告 2026-08-13 18:03:35 +08:00
FoXiMao c771a98d4d build(GOV-009): 对齐应用部署与运行入口 2026-08-13 17:56:37 +08:00
FoXiMao 4665336a63 feat(GOV-009): 建立前端 OpenAPI 客户端边界 2026-08-13 17:36:55 +08:00
FoXiMao 420aa22342 feat(GOV-009): 建立后端契约与健康检查 2026-08-13 17:26:51 +08:00
FoXiMao 3fc703de0b feat(GOV-009): 建立 NestJS 三进程基线 2026-08-13 16:59:09 +08:00
FoXiMao 28d54186ad feat(GOV-009): 建立 Vue 前端工程基线 2026-08-13 16:42:25 +08:00
FoXiMao 258a2d21f6 build(GOV-009): 建立 Node 与工作区基线 2026-08-13 15:54:07 +08:00
FoXiMao b3d8e29f52 feat(GOV-009): 支持固定开发库结构基线 2026-08-13 15:43:06 +08:00
FoXiMao c5a6e6a2c0 docs(GOV-009): 更新 GitNexus 图谱统计 2026-08-13 15:26:58 +08:00
FoXiMao 2e4cffeff1 docs(GOV-009): 细化应用脚手架实施计划 2026-08-13 15:25:38 +08:00
FoXiMao c04184a611 docs(GOV-009): 明确应用脚手架设计边界 2026-08-13 15:07:36 +08:00
FoXiMao 19cc5f948d docs(GOV-009): 封存 v0.0.7 开发库基线 2026-08-13 14:56:14 +08:00
FoXiMao 7dc04a2671 docs(GOV-008): 封存 RocketMQ 架构验证结果 2026-08-13 14:24:34 +08:00
FoXiMao f5994ad77e feat(GOV-008): 采用 RocketMQ 消息队列架构 2026-08-13 14:22:50 +08:00
FoXiMao 3cc00de8f6 docs(GOV-008): 封存 v0.0.6 开发库基线 2026-08-13 13:59:02 +08:00
FoXiMao 70f020f87c docs(GOV-007): 封存开发库 Schema 门禁验证结果 2026-08-13 13:16:59 +08:00
FoXiMao d827bfadb1 fix(GOV-007): 收紧 Schema 基线安全门禁 2026-08-13 13:12:58 +08:00
FoXiMao da056681b6 feat(GOV-007): 建立开发库 Schema 基线门禁 2026-08-13 12:50:37 +08:00
FoXiMao 2c502ebbec docs(GOV-007): 封存 v0.0.5 开发库基线 2026-08-13 11:59:56 +08:00
FoXiMao e552b979b6 docs(GOV-007): 明确开发库 Schema 版本门禁设计 2026-08-13 11:00:37 +08:00
FoXiMao 0a69aa1d43 docs(GOV-006): 封存环境与部署验证结果 2026-08-13 10:57:47 +08:00
FoXiMao 9203fdd0c2 feat(GOV-006): 建立环境配置与双部署基线 2026-08-13 10:54:55 +08:00
273 changed files with 24127 additions and 72 deletions
+8
View File
@@ -3,12 +3,18 @@ node_modules/
dist/ dist/
coverage/ coverage/
*.tsbuildinfo *.tsbuildinfo
playwright-report/
test-results/
# 本地环境与密钥 # 本地环境与密钥
.env .env
.env.* .env.*
!.env.example !.env.example
*.env
*.env.*
!*.env.example
*.local *.local
.local/
# 编辑器与操作系统 # 编辑器与操作系统
.DS_Store .DS_Store
@@ -24,3 +30,5 @@ CLAUDE.md
*.log *.log
tmp/ tmp/
work/ work/
.worktrees/
.superpowers/
+4
View File
@@ -0,0 +1,4 @@
engine-strict=true
save-exact=true
strict-peer-dependencies=true
only-built-dependencies[]=esbuild
+11
View File
@@ -0,0 +1,11 @@
# 自动生成或不可变发布产物
AGENTS.md
pnpm-lock.yaml
database/schema-baselines/
# 历史功能档案与人类维护文档不由代码格式器改写,追溯内容保持原样。
docs/
# 已有治理脚本保留原历史格式;其行为由专项测试门禁覆盖。
tools/database/
tools/governance/
+6
View File
@@ -0,0 +1,6 @@
{
"singleQuote": true,
"trailingComma": "all",
"printWidth": 100,
"semi": true
}
+8 -2
View File
@@ -9,7 +9,7 @@
## 强制要求 ## 强制要求
1. 修改生产代码前必须执行 `npm run governance:start -- <功能编号> <短名称>`,刷新 GitNexus,并完成开发前影响分析。 1. 开发下一版本前必须先执行 `npm run schema:baseline` 和 `npm run schema:verify`,将上一已发布版本的开发库 Schema 基线用中文提交推送 Gitea;随后才能执行 `npm run governance:start -- <功能编号> <短名称>`,刷新 GitNexus 并完成开发前影响分析。
2. 修改完成后必须执行测试、构建、视觉验证和 `npm run governance:finish -- <功能编号> <短名称>`,再次刷新 GitNexus并保存前后对比。 2. 修改完成后必须执行测试、构建、视觉验证和 `npm run governance:finish -- <功能编号> <短名称>`,再次刷新 GitNexus并保存前后对比。
3. 任何功能必须先有 `docs/features/<功能编号>-<短名称>/` 功能档案;没有 PRD、需求、设计、计划和回退说明不得视为完成。 3. 任何功能必须先有 `docs/features/<功能编号>-<短名称>/` 功能档案;没有 PRD、需求、设计、计划和回退说明不得视为完成。
4. Git 提交必须使用中文 Conventional Commit,并带功能编号;禁止英文摘要和含糊提交信息。 4. Git 提交必须使用中文 Conventional Commit,并带功能编号;禁止英文摘要和含糊提交信息。
@@ -19,11 +19,17 @@
8. 禁止提交密钥、密码、访问令牌、生产数据、`.env` 和 GitNexus 本地索引;凭据不得写入远程 URL、文档、脚本或命令参数。 8. 禁止提交密钥、密码、访问令牌、生产数据、`.env` 和 GitNexus 本地索引;凭据不得写入远程 URL、文档、脚本或命令参数。
9. 开发完成后必须先通过代码 Review 和开发规范符合性 Review,再进入发布;Review 结论和问题处置必须写入功能档案。 9. 开发完成后必须先通过代码 Review 和开发规范符合性 Review,再进入发布;Review 结论和问题处置必须写入功能档案。
10. 每次提交验证通过后必须立即推送当前分支到项目 Gitea;本次新建标签必须单独推送。推送失败时任务不得标记完成,禁止强推或自动覆盖未知远程提交。 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:start -->
# GitNexus — Code Intelligence # GitNexus — Code Intelligence
This project is indexed by GitNexus as **a-share-analysis** (528 symbols, 553 relationships, 0 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely. This project is indexed by GitNexus as **a-share-analysis** (2432 symbols, 3283 relationships, 63 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.
> If any GitNexus tool warns the index is stale, run `npx gitnexus analyze` in terminal first. > If any GitNexus tool warns the index is stale, run `npx gitnexus analyze` in terminal first.
+46
View File
@@ -2,6 +2,52 @@
本项目采用语义化版本。功能级变化请从 `docs/features/` 按功能编号追溯。 本项目采用语义化版本。功能级变化请从 `docs/features/` 按功能编号追溯。
## Unreleased
## 0.0.10 - 2026-08-18
- 使用 Node.js 22.x 与 mysql2 直接读取 MySQL 5.7.x 元数据和 `SHOW CREATE`,移除 Schema 基线对本机 MySQL CLI 的依赖。
- 新增 format v3 exporter/driver 元数据,永久只读兼容 format v1/v2。
- 增加对象目录、视图依赖排序、并发漂移检测、错误脱敏、超时和定义大小保护。
- 恢复版本开发门禁并封存 `v0.0.9` development `captured_empty` Schema 基线。
## 0.0.9 - 2026-08-17
- Node.js 运行时约束明确为完整 22.x,不绑定 minor 或 patch。
- MySQL 客户端、mysqldump、服务端和健康检查统一接受完整 5.7.x,不设置最低补丁版本。
- MySQL 健康详情改为展示服务端实际三段版本,字符集、排序规则、库名和东八区时区继续严格校验。
- 系统架构、开发规范、本地开发和 Ubuntu 源码部署手册统一采用系列版本口径,历史版本证据保持原样。
- 用户确认开发库为空并授权 GOV-011 一次性跳过 v0.0.8 Schema 基线;仓库未伪造基线或增加通用绕过开关。
## 0.0.8 - 2026-08-17
- 新增安全、性能、GitNexus 跨模块影响和独立开发总结的可执行治理门禁。
- 约定后端业务模块内按需分层,以及前端 Axios 统一封装、API 分域和 OpenAPI 类型契约。
- 项目生产交付统一为 Ubuntu 源码部署,移除 Dockerfile、Compose、镜像校验和容器测试入口。
- 本地 Redis、MySQL 5.7.42 与 RocketMQ 5.x 均作为外部服务,项目不再提供自动启动或容器兜底。
- 新增源码发布门禁,校验 Web/Server 构建产物与 systemd、Nginx 配置一致性。
- 完成 Vue 3 Web、NestJS API/Scheduler/Worker、OpenAPI 单向契约和最小权限配置的工程基线确认。
- 补充 Tailscale 访问 Windows TDX 的开发操作文档和采集 PoC 前置档案;本版本不实现常驻采集程序。
## 0.0.7 - 2026-08-13
- 将项目唯一消息队列技术基线由 RabbitMQ 调整为 RocketMQ 5.x。
- 建立 MessageBusAdapter、Topic/Group、重试、死信和顺序消息约束。
- 更新 Scheduler/Worker 环境模板和双部署文档,并记录本机 NameServer 分层连接验证。
## 0.0.6 - 2026-08-13
- 建立上一发布版本开发数据库 Schema 基线生成、规范化和自动校验工具。
- 固定只读开发库安全边界、完整 MySQL 5.7 对象范围和禁止覆盖规则。
- 为 MySQL 未启用状态建立可验证的不适用记录,并接入治理前后门禁。
## 0.0.5 - 2026-08-13
- 建立开发与生产环境配置契约及八份无秘密模板。
- 增加仅运行 Redis 的本地开发 Compose。
- 建立 Docker Compose 与 Ubuntu 源码生产部署边界、systemd 和 Nginx 示例。
- 增加环境配置自动化契约测试。
## 0.0.4 - 2026-08-13 ## 0.0.4 - 2026-08-13
- 固定 MySQL 5.7.x、`utf8mb4` 和 `utf8mb4_general_ci` 技术基线。 - 固定 MySQL 5.7.x、`utf8mb4` 和 `utf8mb4_general_ci` 技术基线。
+13 -2
View File
@@ -9,12 +9,19 @@ A read-only A-share market overview and analysis tool.
## Projects ## Projects
- `web/`: Vue 3 market terminal frontend. - `web/`: Vue 3 market terminal frontend.
- `server/`: NestJS API, scheduler, and workers. Added in a later module. - `server/`: NestJS API、Scheduler 与 Worker 三个独立进程。
- `deploy/`: MySQL, Redis, and RabbitMQ deployment configuration. Added with the backend module. - `deploy/`: MySQL 5.7、Redis、RocketMQ 5.x 的配置契约,以及 systemd/Nginx 源码部署模板。
- `docs/`: Product and implementation specifications. - `docs/`: Product and implementation specifications.
The first implementation slice is the market overview screen in `web/`. The first implementation slice is the market overview screen in `web/`.
## 环境与部署
- [本地开发环境](docs/deployment/local-development.md):使用开发机已有 Redis,应用全部从源码运行。
- [Ubuntu 源码生产部署](docs/deployment/ubuntu-source-production.md):项目唯一生产部署方式,支持 Ubuntu 22.04/24.04 LTS x86_64。
无秘密环境模板位于 `deploy/env/`。生产配置不进入 Git 或发布目录;Node.js 22.x、pnpm 10.25.0、Nginx 和外部基础设施由服务器管理员提供。项目不安装、启动、停止或删除 Redis、MySQL 和 RocketMQ。
## 开发入口 ## 开发入口
- [文档索引](docs/index.md) - [文档索引](docs/index.md)
@@ -25,9 +32,13 @@ The first implementation slice is the market overview screen in `web/`.
开始任何模块前,先阅读根目录 `AGENTS.md`,然后运行: 开始任何模块前,先阅读根目录 `AGENTS.md`,然后运行:
```bash ```bash
npm run schema:baseline
npm run schema:verify
npm run governance:start -- FEAT-MO-001 market-overview npm run governance:start -- FEAT-MO-001 market-overview
``` ```
Schema 命令只允许处理固定开发库;导出器使用 Node.js `mysql2`,本机无需安装 MySQL Server 或 CLI。当前 MySQL 未启用时会为上一发布版本生成可验证的不适用清单,不会连接数据库或创建空 SQL;启用但无对象时生成 format v3 `captured_empty` 清单。完整规则见 [开发流程规范](docs/governance/development-workflow.md)。
## 项目仓库 ## 项目仓库
- Gitea:<https://git.foximao.com/FoXiMao/a-share-analysis> - Gitea:<https://git.foximao.com/FoXiMao/a-share-analysis>
+1 -1
View File
@@ -1 +1 @@
0.0.4 0.0.10
@@ -0,0 +1,33 @@
{
"format_version": 3,
"status": "captured_empty",
"application_version": "v0.0.10",
"git_commit": "16bde94df68263672fa12e2823afe024c741f84e",
"source_environment": "development",
"database_name": "a_share_analysis_dev",
"charset": "utf8mb4",
"collation": "utf8mb4_general_ci",
"generated_at": "2026-08-17T19:07:54.864Z",
"generator": "schema-baseline/3.0.0",
"reason": "none",
"schema_sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"objects": {
"tables": false,
"views": false,
"triggers": false,
"routines": false,
"events": false
},
"object_counts": {
"tables": 0,
"views": 0,
"triggers": 0,
"routines": 0,
"events": 0
},
"exporter_name": "mysql2-show-create",
"exporter_version": "1.0.0",
"database_driver": "mysql2",
"database_driver_version": "3.23.3",
"mysql_server_version": "5.7.42-0ubuntu0.18.04.1"
}
@@ -0,0 +1,24 @@
{
"format_version": 1,
"status": "not_applicable",
"application_version": "v0.0.5",
"git_commit": "0a69aa1d43f40093c6482f48a13d9d222f6faec5",
"source_environment": "development",
"database_name": "a_share_analysis_dev",
"mysql_client_version": "not_enabled",
"mysqldump_client_version": "not_enabled",
"mysql_server_version": "not_enabled",
"charset": "utf8mb4",
"collation": "utf8mb4_general_ci",
"generated_at": "2026-08-13T03:15:28.832Z",
"generator": "schema-baseline/1.0.0",
"reason": "mysql_disabled",
"schema_sha256": "not_applicable",
"objects": {
"tables": false,
"views": false,
"triggers": false,
"routines": false,
"events": false
}
}
@@ -0,0 +1,24 @@
{
"format_version": 1,
"status": "not_applicable",
"application_version": "v0.0.6",
"git_commit": "70f020f87c0cf9e19512581d798a3491c9aae5f6",
"source_environment": "development",
"database_name": "a_share_analysis_dev",
"mysql_client_version": "not_enabled",
"mysqldump_client_version": "not_enabled",
"mysql_server_version": "not_enabled",
"charset": "utf8mb4",
"collation": "utf8mb4_general_ci",
"generated_at": "2026-08-13T05:58:53.506Z",
"generator": "schema-baseline/1.0.0",
"reason": "mysql_disabled",
"schema_sha256": "not_applicable",
"objects": {
"tables": false,
"views": false,
"triggers": false,
"routines": false,
"events": false
}
}
@@ -0,0 +1,24 @@
{
"format_version": 1,
"status": "not_applicable",
"application_version": "v0.0.7",
"git_commit": "7dc04a267199fb3a11c2ac43c2914ae5e1460cb9",
"source_environment": "development",
"database_name": "a_share_analysis_dev",
"mysql_client_version": "not_enabled",
"mysqldump_client_version": "not_enabled",
"mysql_server_version": "not_enabled",
"charset": "utf8mb4",
"collation": "utf8mb4_general_ci",
"generated_at": "2026-08-13T06:55:43.710Z",
"generator": "schema-baseline/1.0.0",
"reason": "mysql_disabled",
"schema_sha256": "not_applicable",
"objects": {
"tables": false,
"views": false,
"triggers": false,
"routines": false,
"events": false
}
}
@@ -0,0 +1,33 @@
{
"format_version": 3,
"status": "captured_empty",
"application_version": "v0.0.9",
"git_commit": "88e2fdffc8c71dd682405c148a81953a8dcee9d6",
"source_environment": "development",
"database_name": "a_share_analysis_dev",
"charset": "utf8mb4",
"collation": "utf8mb4_general_ci",
"generated_at": "2026-08-17T18:56:33.473Z",
"generator": "schema-baseline/3.0.0",
"reason": "none",
"schema_sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"objects": {
"tables": false,
"views": false,
"triggers": false,
"routines": false,
"events": false
},
"object_counts": {
"tables": 0,
"views": 0,
"triggers": 0,
"routines": 0,
"events": 0
},
"exporter_name": "mysql2-show-create",
"exporter_version": "1.0.0",
"database_driver": "mysql2",
"database_driver_version": "3.23.3",
"mysql_server_version": "5.7.42-0ubuntu0.18.04.1"
}
+32
View File
@@ -0,0 +1,32 @@
# 运行环境;本地源码运行固定为 development。
APP_ENV=development
# API 只监听本机,避免开发服务暴露到局域网。
API_HOST=127.0.0.1
API_PORT=3000
LOG_LEVEL=debug
# 第一阶段实际启用的 Redis。
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_USERNAME=
REDIS_PASSWORD=
REDIS_DATABASE=0
REDIS_TLS=false
# 第一阶段关闭 MySQL;启用后下列连接变量变为必填。
MYSQL_ENABLED=false
MYSQL_HOST=127.0.0.1
MYSQL_PORT=3306
MYSQL_DATABASE=a_share_analysis_dev
MYSQL_USERNAME=
MYSQL_PASSWORD=
MYSQL_CHARSET=utf8mb4
MYSQL_COLLATION=utf8mb4_general_ci
MYSQL_TIMEZONE=+08:00
# 第一阶段关闭付费 AI;启用后 BASE_URL、API_KEY 和 MODEL 变为必填。
AI_ENABLED=false
AI_BASE_URL=
AI_API_KEY=
AI_MODEL=
AI_TIMEOUT_MS=30000
+19
View File
@@ -0,0 +1,19 @@
# Scheduler 只负责触发时间和调度锁。
APP_ENV=development
LOG_LEVEL=debug
SCHEDULER_TIMEZONE=Asia/Shanghai
SCHEDULER_ENABLED=true
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_USERNAME=
REDIS_PASSWORD=
REDIS_DATABASE=1
REDIS_TLS=false
# 第一阶段关闭 RocketMQ,任务通过服务内 MessageBusAdapter 调用。
ROCKETMQ_ENABLED=false
ROCKETMQ_NAMESRV_ADDR=127.0.0.1:9876
ROCKETMQ_ENDPOINT=127.0.0.1:8081
ROCKETMQ_TOPIC_PREFIX=a-share-analysis
ROCKETMQ_SEND_TIMEOUT_MS=3000
+5
View File
@@ -0,0 +1,5 @@
# VITE 变量会进入浏览器,只允许公开配置。
VITE_APP_ENV=development
VITE_APP_TITLE=A-Share Analysis
VITE_API_BASE_URL=
VITE_ENABLE_DEVTOOLS=true
+37
View File
@@ -0,0 +1,37 @@
# 开发环境使用确定性模拟行情,不访问生产数据源。
APP_ENV=development
LOG_LEVEL=debug
MARKET_DATA_MODE=mock
MARKET_DATA_PROVIDER=deterministic-fixture
MARKET_DATA_BASE_URL=
MARKET_DATA_API_KEY=
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_USERNAME=
REDIS_PASSWORD=
REDIS_DATABASE=2
REDIS_TLS=false
MYSQL_ENABLED=false
MYSQL_HOST=127.0.0.1
MYSQL_PORT=3306
MYSQL_DATABASE=a_share_analysis_dev
MYSQL_USERNAME=
MYSQL_PASSWORD=
MYSQL_CHARSET=utf8mb4
MYSQL_COLLATION=utf8mb4_general_ci
MYSQL_TIMEZONE=+08:00
ROCKETMQ_ENABLED=false
ROCKETMQ_NAMESRV_ADDR=127.0.0.1:9876
ROCKETMQ_ENDPOINT=127.0.0.1:8081
ROCKETMQ_TOPIC_PREFIX=a-share-analysis
ROCKETMQ_CONSUMER_GROUP=a-share-analysis-worker
ROCKETMQ_CONSUMER_CONCURRENCY=4
AI_ENABLED=false
AI_BASE_URL=
AI_API_KEY=
AI_MODEL=
AI_TIMEOUT_MS=30000
+29
View File
@@ -0,0 +1,29 @@
# 生产进程必须显式使用 production,禁止回退开发默认值。
APP_ENV=production
API_HOST=127.0.0.1
API_PORT=3000
LOG_LEVEL=info
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_USERNAME=
REDIS_PASSWORD=
REDIS_DATABASE=0
REDIS_TLS=false
# 第一阶段关闭;启用后必须填写真实生产连接,但不得提交本文件副本。
MYSQL_ENABLED=false
MYSQL_HOST=127.0.0.1
MYSQL_PORT=3306
MYSQL_DATABASE=a_share_analysis
MYSQL_USERNAME=
MYSQL_PASSWORD=
MYSQL_CHARSET=utf8mb4
MYSQL_COLLATION=utf8mb4_general_ci
MYSQL_TIMEZONE=+08:00
AI_ENABLED=false
AI_BASE_URL=
AI_API_KEY=
AI_MODEL=
AI_TIMEOUT_MS=30000
+17
View File
@@ -0,0 +1,17 @@
APP_ENV=production
LOG_LEVEL=info
SCHEDULER_TIMEZONE=Asia/Shanghai
SCHEDULER_ENABLED=true
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_USERNAME=
REDIS_PASSWORD=
REDIS_DATABASE=1
REDIS_TLS=false
ROCKETMQ_ENABLED=false
ROCKETMQ_NAMESRV_ADDR=
ROCKETMQ_ENDPOINT=
ROCKETMQ_TOPIC_PREFIX=a-share-analysis
ROCKETMQ_SEND_TIMEOUT_MS=3000
+5
View File
@@ -0,0 +1,5 @@
# VITE 变量会进入浏览器,只允许公开配置。
VITE_APP_ENV=production
VITE_APP_TITLE=A-Share Analysis
VITE_API_BASE_URL=
VITE_ENABLE_DEVTOOLS=false
+37
View File
@@ -0,0 +1,37 @@
# 生产环境必须使用 live,启动校验拒绝 mock。
APP_ENV=production
LOG_LEVEL=info
MARKET_DATA_MODE=live
MARKET_DATA_PROVIDER=
MARKET_DATA_BASE_URL=
MARKET_DATA_API_KEY=
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_USERNAME=
REDIS_PASSWORD=
REDIS_DATABASE=2
REDIS_TLS=false
MYSQL_ENABLED=false
MYSQL_HOST=127.0.0.1
MYSQL_PORT=3306
MYSQL_DATABASE=a_share_analysis
MYSQL_USERNAME=
MYSQL_PASSWORD=
MYSQL_CHARSET=utf8mb4
MYSQL_COLLATION=utf8mb4_general_ci
MYSQL_TIMEZONE=+08:00
ROCKETMQ_ENABLED=false
ROCKETMQ_NAMESRV_ADDR=
ROCKETMQ_ENDPOINT=
ROCKETMQ_TOPIC_PREFIX=a-share-analysis
ROCKETMQ_CONSUMER_GROUP=a-share-analysis-worker
ROCKETMQ_CONSUMER_CONCURRENCY=4
AI_ENABLED=false
AI_BASE_URL=
AI_API_KEY=
AI_MODEL=
AI_TIMEOUT_MS=30000
@@ -0,0 +1,20 @@
server {
listen 80;
server_name _;
root /opt/a-share-analysis/current/web/dist;
index index.html;
location /api/ {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location / {
try_files $uri $uri/ /index.html;
}
}
@@ -0,0 +1,22 @@
[Unit]
Description=A Share Analysis API
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=a-share
Group=a-share
WorkingDirectory=/opt/a-share-analysis/current
EnvironmentFile=/etc/a-share-analysis/api.env
ExecStart=/usr/bin/node /opt/a-share-analysis/current/server/dist/apps/api/main.js
ExecStartPre=/usr/bin/test -r /etc/a-share-analysis/api.env
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
[Install]
WantedBy=multi-user.target
@@ -0,0 +1,22 @@
[Unit]
Description=A Share Analysis Scheduler
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=a-share
Group=a-share
WorkingDirectory=/opt/a-share-analysis/current
EnvironmentFile=/etc/a-share-analysis/scheduler.env
ExecStart=/usr/bin/node /opt/a-share-analysis/current/server/dist/apps/scheduler/main.js
ExecStartPre=/usr/bin/test -r /etc/a-share-analysis/scheduler.env
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
[Install]
WantedBy=multi-user.target
@@ -0,0 +1,22 @@
[Unit]
Description=A Share Analysis Worker
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=a-share
Group=a-share
WorkingDirectory=/opt/a-share-analysis/current
EnvironmentFile=/etc/a-share-analysis/worker.env
ExecStart=/usr/bin/node /opt/a-share-analysis/current/server/dist/apps/worker/main.js
ExecStartPre=/usr/bin/test -r /etc/a-share-analysis/worker.env
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
[Install]
WantedBy=multi-user.target
+31
View File
@@ -0,0 +1,31 @@
# ADR-0003:采用 RocketMQ 5.x 作为唯一消息队列
- 状态:accepted
- 日期:2026-08-13
- 关联功能:GOV-008
## 背景
项目此前在架构和环境模板中约定 RabbitMQ,但尚未实现消息客户端、Topic 或业务消费流程。产品需要分钟级盘中分析、定时采集、指标计算、AI 分析和失败重试,决定在实现前统一切换到 RocketMQ。
## 决策
- 项目唯一消息队列为 RocketMQ 5.x,不维护 RabbitMQ 双栈。
- Scheduler 和 Worker 只依赖项目级 `MessageBusAdapter` 与版本化事件契约。
- Node.js 客户端优先通过 RocketMQ 5.x Proxy 接入;若改用直接 NameServer/Broker 客户端,必须通过兼容性和可靠性验证。
- Topic、Tag、Producer Group、Consumer Group、顺序键、重试与死信语义必须在功能设计中明确。
- 本地和生产基础设施独立于应用发布;NameServer、Broker、Proxy 不随应用版本自动创建或删除。
## 原因
RocketMQ 对定时/延迟任务、重试、死信、顺序消息和后续任务规模扩展更符合预期。Adapter 边界用于控制 Node 客户端成熟度和接入协议变化带来的风险。
## 代价
- 本地和生产运维复杂度高于单节点 RabbitMQ,需要区分 NameServer、Broker 和 Proxy。
- Node.js 生态需要在 Server 脚手架阶段单独验证,不能仅凭 NameServer 端口可达决定客户端可用。
- 所有消费者必须按至少一次投递设计幂等和受控重放。
## 验证
GOV-008 只验证配置、文档契约和本机 NameServer 状态。真实 Topic 生产/消费必须在 Broker/Proxy 可用且 Server 客户端选定后补充契约测试。
+39 -8
View File
@@ -7,8 +7,10 @@
```text ```text
web/ Vue 3 前端 web/ Vue 3 前端
server/ NestJS API、Scheduler 与 Worker server/ NestJS API、Scheduler 与 Worker
contracts/ HTTP 与 RabbitMQ 版本化契约 server/openapi/ HTTP OpenAPI 产物
deploy/ MySQL、Redis、RabbitMQ 和运行配置 server/libs/http-contracts/ 后端 HTTP DTO
server/libs/message-contracts/ 后端 RocketMQ 版本化契约
deploy/ MySQL、Redis、RocketMQ 5.x 和运行配置
docs/ 规范、架构、ADR 与功能档案 docs/ 规范、架构、ADR 与功能档案
tools/ 可重复执行的治理和开发工具 tools/ 可重复执行的治理和开发工具
``` ```
@@ -20,7 +22,8 @@ tools/ 可重复执行的治理和开发工具
```text ```text
免费数据源 免费数据源
→ Scheduler 定时投递 → Scheduler 定时投递
→ RabbitMQ → MessageBusAdapter
→ RocketMQ 5.x
→ 行情采集 Worker → 行情采集 Worker
→ 指标计算 Worker → 指标计算 Worker
→ 规则 / AI / 混合分析 → 规则 / AI / 混合分析
@@ -30,20 +33,48 @@ tools/ 可重复执行的治理和开发工具
``` ```
- Scheduler只负责触发时间。 - Scheduler只负责触发时间。
- RabbitMQ只负责任务传递、确认、重试和死信。 - MessageBusAdapter 隔离业务与 RocketMQ 客户端,禁止业务模块直接依赖 SDK。
- RocketMQ 只负责任务传递、确认、重试、延迟消息和死信;重复投递由 Worker 幂等处理。
- Worker负责采集、标准化、计算和分析。 - Worker负责采集、标准化、计算和分析。
- MySQL保存可追溯事实与历史报告。 - MySQL保存可追溯事实与历史报告。
- Redis保存最新快照、缓存、锁和限流状态。 - Redis保存最新快照、缓存、锁和限流状态。
- Vue前端只读后端 API,不直接接触外部数据源和密钥。 - Vue前端只读后端 API,不直接接触外部数据源和密钥。
## 3. 数据库技术基线 ## 3. 前后端模块边界
- 数据库服务端固定使用 MySQL 5.7.x,开发、测试和生产环境禁止使用 MySQL 8.x 代替兼容性验证。 后端以业务模块为一级目录,模块内部按实际职责建立 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.x;开发、测试和生产环境禁止使用 MySQL 5.6.x、8.x、MariaDB 或其他数据库代替兼容性验证,但不锁定 5.7 系列内的补丁版本。
- 数据库与表默认字符集固定为 `utf8mb4`,排序规则固定为 `utf8mb4_general_ci`。 - 数据库与表默认字符集固定为 `utf8mb4`,排序规则固定为 `utf8mb4_general_ci`。
- 数据库初始化、表结构、连接会话、ORM 配置和迁移脚本必须显式声明或验证该字符集与排序规则,不能依赖服务器默认值。 - 数据库初始化、表结构、连接会话、ORM 配置和迁移脚本必须显式声明或验证该字符集与排序规则,不能依赖服务器默认值。
- 正式启用持久化前,必须在真实 MySQL 5.7 环境验证服务端版本、Schema/表排序规则、迁移和关键查询。 - 正式启用持久化前,必须在真实 MySQL 5.7.x 环境验证服务端版本、Schema/表排序规则、迁移和关键查询。
- 第一阶段市场概览只定义 MySQL Repository 接口并使用内存实现,不启动数据库、不建立生产连接;后续启用时不得改变前端 API 和核心分析契约。 - 第一阶段市场概览只定义 MySQL Repository 接口并使用内存实现,不启动数据库、不建立生产连接;后续启用时不得改变前端 API 和核心分析契约。
## 4. 当前实施顺序 ## 5. 当前实施顺序
第一阶段先实现可交互的市场综合概览和稳定数据契约,再接入正式行情采集链路。用户、邀请、权限、会员和支付后置,不进入当前核心架构。 第一阶段先实现可交互的市场综合概览和稳定数据契约,再接入正式行情采集链路。用户、邀请、权限、会员和支付后置,不进入当前核心架构。
## 6. 环境与部署基线
- 应用运行环境只定义 `development` 与 `production`;生产环境禁止模拟数据、热更新、调试端口和开发默认值回退。
- API、Scheduler、Worker、Web 分别拥有开发和生产模板;同一进程跨环境使用相同变量名,通过启动 Schema 校验条件必填项。
- 本地开发直接连接开发机已开机自启的 Redis `127.0.0.1:6379`,应用进程从源码运行;第一阶段 MySQL 与 RocketMQ 保持关闭,需要联调时连接开发者独立维护的外部服务。
- 生产只支持 Ubuntu 22.04/24.04 LTS x86_64 源码部署,不提供容器运行、构建、测试或部署入口。
- 源码部署由管理员预装 Node.js 22.x、pnpm 10.25.0、Nginx 和外部基础设施;项目只验证,不安装、启动、停止或删除系统服务。
- 源码部署使用不可变发布目录、`a-share` 用户和 systemd 独立进程配置;生产 env 存放在 `/etc/a-share-analysis/`,不随代码版本切换覆盖。
+42
View File
@@ -0,0 +1,42 @@
# 本地开发环境
本地开发由开发机提供 Node.js 22.x、pnpm 10.25.0 和已开机自启的 Redis `127.0.0.1:6379`。Web、API、Scheduler 与 Worker 全部从源码启动;MySQL 5.7.x 和 RocketMQ 5.x 也是外部服务,项目脚本不负责安装、启动、停止或删除任何基础设施。
## 首次准备
```bash
node --version
pnpm --version
redis-cli -h 127.0.0.1 -p 6379 ping
pnpm install --frozen-lockfile
pnpm check:runtime
```
Redis 必须返回 `PONG`。如果不可达,应先修复开发机外部服务;测试和应用不会创建替代实例。
把 `deploy/env/development/*.env.example` 复制为同目录的 `*.env.local`。四份 local 文件被 Git 忽略:Web 只能含 `VITE_` 公开变量;API、Scheduler、Worker 按最小权限分别读取自己的配置,不共享一份全能 env。
固定开发 MySQL 只允许 `a_share_analysis_dev`,主机必须是回环地址或代码内白名单 `112.192.20.11`,服务端必须属于 MySQL 5.7.x 且不限制系列内补丁版本,字符集为 `utf8mb4`、排序规则为 `utf8mb4_general_ci`、会话时区为 `+08:00`。Schema 工具和开发检查禁止连接、探测或读取生产库。
## 启动顺序
建议分别打开四个终端,依次运行:
```bash
pnpm --filter @a-share-analysis/server dev:api
pnpm --filter @a-share-analysis/server dev:scheduler
pnpm --filter @a-share-analysis/server dev:worker
pnpm --filter @a-share-analysis/web dev
```
API 健康端点是 `http://127.0.0.1:3000/api/v1/health`,Web 是 `http://127.0.0.1:5173/`。Scheduler 与 Worker 在 GOV-009 中保持 `ROCKETMQ_ENABLED=false`;没有经过验证的 Node RocketMQ 客户端时,启用配置会直接失败,不使用内存队列伪降级。
## 日常验证与停止
```bash
pnpm check:contracts
pnpm verify
pnpm verify:release
```
应用进程通过各自终端或信号正常停止,外部 Redis/MySQL/RocketMQ 生命周期不由项目管理。RocketMQ 的 TCP 端口可达不等于生产消费链路通过,完整联调仍需验证 Topic 路由和实际生产/消费。
@@ -0,0 +1,441 @@
# Tailscale + SSH 隧道访问 TDX 开发手册
## 1. 用途与适用边界
本手册用于 Mac 本地开发期间,访问家中 Windows 上仅监听回环地址的 TDX HTTP 接口。TDX 是市场概览的正式行情来源;SSH 隧道负责把家庭局域网和外部 Tailscale 两种开发位置统一成同一个 Mac 回环入口。该链路不是生产采集、数据上报或公网部署方案。
```text
Mac 本地程序 / TDX Bridge
-> 127.0.0.1:17710
-> SSH 本地端口转发
-> 家庭局域网或 Tailscale 私有网络
-> 同一台 Windows OpenSSH
-> Windows 127.0.0.1:17709
-> TDX
```
两个场景只切换 SSH 目标别名,TDX Bridge 和上层业务始终访问 `http://127.0.0.1:17710/`。离线样本只允许作为显式开发和自动化测试回退,并必须标记为离线数据;不得伪装为实时 TDX。Windows 离线不得阻塞普通测试或构建。
## 2. 安全边界
- 不在路由器上开放或转发 SSH、RDP、`17709`、`17710` 等端口。
- TDX 继续只监听 Windows `127.0.0.1:17709`,不得改为 `0.0.0.0`。
- SSH 使用独立 Ed25519 密钥,不在脚本、仓库、文档或远程 URL 中保存密码和私钥。
- Mac 转发端口只绑定 `127.0.0.1:17710`,不得绑定局域网或所有网卡。
- 真实返回只用于只读验证。日志和测试报告必须脱敏,不保存家庭网络信息、登录信息或无关原始载荷。
- 开发隧道不连接生产数据库、不承担生产采集,也不证明数据源具备商业展示或再分发授权。
文档中的值均为占位符:
- `<WINDOWS_TAILSCALE_HOST>`:Windows 的 Tailscale MagicDNS 名称或 Tailscale IP。
- `<WINDOWS_SSH_USER>`:用于 SSH 登录的 Windows 用户。
- `<MAC_TAILSCALE_IP>`:Mac 的 Tailscale IP,仅在收紧防火墙来源时使用。
## 3. 首次建立 Tailscale 网络
### 3.1 Mac
1. 从 Tailscale 官方渠道安装客户端。
2. 登录项目使用的同一个 Tailnet。
3. 确认菜单栏中的 Tailscale 状态为已连接。
4. 在终端检查本机和节点列表:
```bash
tailscale ip -4
tailscale status
```
### 3.2 Windows
1. 从 Tailscale 官方渠道安装客户端。
2. 登录与 Mac 相同的 Tailnet。
3. 确认 Windows 节点在 Tailscale 管理后台和 Mac 的 `tailscale status` 中均为在线。
4. 在 Windows PowerShell 中检查地址和状态:
```powershell
tailscale ip -4
tailscale status
```
### 3.3 私网连通验证
在 Mac 执行:
```bash
tailscale ping <WINDOWS_TAILSCALE_HOST>
```
只有 Tailscale ping 成功后再排查 SSH。不要用公网 IP 替换占位符,也不要为排障临时开放路由器端口。
## 4. 配置 Windows OpenSSH Server
以下命令在 Windows 管理员 PowerShell 中执行。
### 4.1 安装并启动服务
```powershell
Get-WindowsCapability -Online | Where-Object Name -Like 'OpenSSH.Server*'
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic
Get-Service sshd
```
如果 OpenSSH Server 已安装,`Add-WindowsCapability` 可以跳过。`Get-Service sshd` 应显示服务正在运行且启动类型为自动。
检查端口监听:
```powershell
Get-NetTCPConnection -LocalPort 22 -State Listen
```
### 4.2 确认防火墙规则
OpenSSH 安装通常会创建入站规则。先检查,不要重复创建同名规则:
```powershell
Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue
```
首次联调可以保留系统创建的 SSH 规则;链路确认后按第 11 节限制为 Tailscale 来源。不得新增公网端口映射。
## 5. 配置 SSH 密钥登录
### 5.1 在 Mac 生成项目专用密钥
```bash
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/tdx_windows -C "tdx-windows-development"
chmod 600 ~/.ssh/tdx_windows
chmod 644 ~/.ssh/tdx_windows.pub
pbcopy < ~/.ssh/tdx_windows.pub
```
私钥 `~/.ssh/tdx_windows` 只保留在 Mac,不发送给 Windows,也不提交仓库。建议为私钥设置口令,并由 macOS 钥匙串或 `ssh-agent` 管理。
### 5.2 Windows 管理员账户
Windows OpenSSH 默认从 `C:\ProgramData\ssh\administrators_authorized_keys` 读取管理员公钥。必须先创建文件,再设置 ACL;否则 `icacls` 会报“系统找不到指定的文件”。
在管理员 PowerShell 中执行,按提示粘贴刚复制的单行公钥:
```powershell
$authorizedKeys = "$env:ProgramData\ssh\administrators_authorized_keys"
New-Item -ItemType Directory -Force -Path (Split-Path $authorizedKeys)
if (-not (Test-Path $authorizedKeys)) {
New-Item -ItemType File -Path $authorizedKeys
}
$publicKey = Read-Host '粘贴 Mac 的单行 SSH 公钥'
if (-not (Get-Content $authorizedKeys | Where-Object { $_ -eq $publicKey })) {
Add-Content -Path $authorizedKeys -Value $publicKey -Encoding ascii
}
icacls $authorizedKeys /inheritance:r
icacls $authorizedKeys /grant "*S-1-5-18:F" "*S-1-5-32-544:F"
Restart-Service sshd
```
`S-1-5-18` 是 SYSTEM,`S-1-5-32-544` 是本地 Administrators 组。使用 SID 可以避免中文 Windows 的组名本地化问题。
### 5.3 Windows 非管理员账户
非管理员账户使用用户目录下的 `authorized_keys`。在该登录用户自己的 PowerShell 中执行:
```powershell
$sshDirectory = "$env:USERPROFILE\.ssh"
$authorizedKeys = "$sshDirectory\authorized_keys"
New-Item -ItemType Directory -Force -Path $sshDirectory
if (-not (Test-Path $authorizedKeys)) {
New-Item -ItemType File -Path $authorizedKeys
}
$publicKey = Read-Host '粘贴 Mac 的单行 SSH 公钥'
if (-not (Get-Content $authorizedKeys | Where-Object { $_ -eq $publicKey })) {
Add-Content -Path $authorizedKeys -Value $publicKey -Encoding ascii
}
icacls $authorizedKeys /inheritance:r
icacls $authorizedKeys /grant "$($env:USERNAME):F"
Restart-Service sshd
```
管理员和非管理员两种方式只选与实际账户匹配的一种。若修改了 `C:\ProgramData\ssh\sshd_config`,先执行 `sshd -t` 校验,再重启服务。
## 6. 配置 Mac SSH 双场景别名
家庭局域网和外部 Tailscale 连接同一台 Windows、同一个账户和同一个 `sshd`,复用同一把项目专用密钥,不创建第二把 SSH 密钥。编辑 Mac 的 `~/.ssh/config`,加入:
```sshconfig
Host tdx-windows-lan tdx-windows-tailnet
User <WINDOWS_SSH_USER>
IdentityFile ~/.ssh/tdx_windows
IdentitiesOnly yes
UseKeychain yes
AddKeysToAgent yes
ServerAliveInterval 30
ServerAliveCountMax 3
ExitOnForwardFailure yes
LocalForward 127.0.0.1:17710 127.0.0.1:17709
Host tdx-windows-lan
HostName <WINDOWS_LAN_HOST>
Host tdx-windows-tailnet
HostName <WINDOWS_TAILSCALE_HOST>
```
真实局域网地址、Tailscale 地址和用户名只保存在本机 SSH 配置,不写入仓库。开发代理需要核对当前配置时使用:
```bash
ssh -G tdx-windows-lan | awk '/^(hostname|user|identityfile|localforward) / {print}'
ssh -G tdx-windows-tailnet | awk '/^(hostname|user|identityfile|localforward) / {print}'
```
然后修正权限:
```bash
chmod 700 ~/.ssh
chmod 600 ~/.ssh/config ~/.ssh/tdx_windows
```
首次连接先验证密钥登录:
先在 Windows 管理员 PowerShell 查看主机公钥指纹:
```powershell
ssh-keygen -lf "$env:ProgramData\ssh\ssh_host_ed25519_key.pub"
```
再在 Mac 连接,并确认首次连接提示的 Ed25519 指纹与 Windows 输出一致:
```bash
ssh -v tdx-windows-tailnet
```
预期可以直接登录,或只要求输入私钥口令。若仍要求 Windows 账户密码,重点检查公钥文件位置、ACL、登录账户是否属于 Administrators,以及 SSH 调试输出中实际使用的密钥。
## 7. 两种场景的选择、启动和停止
### 7.1 选择规则
| 当前场景 | 使用别名 | 前置条件 |
|---|---|---|
| Mac 与 Windows 位于已配置的家庭局域网 | `tdx-windows-lan` | Windows 在线、TDX 已登录、家庭 LAN 的 SSH 22 可达 |
| Mac 在外部网络,或家庭 LAN SSH 不可达 | `tdx-windows-tailnet` | Mac 与 Windows 的 Tailscale 均在线,Tailnet ping 成功 |
两种隧道不能同时启动,因为都会独占 Mac `127.0.0.1:17710`。在家庭网络内优先使用 LAN;若 LAN 前置检查失败,不修改 TDX 监听地址,改用 Tailscale。
### 7.2 家庭局域网模式
前置检查:
```bash
ssh -o BatchMode=yes -o ClearAllForwardings=yes -T tdx-windows-lan exit
```
仓库文档不保存真实地址,家庭路径直接通过 SSH 别名验证。首次连接必须核对局域网地址与已信任的 Tailscale 地址返回相同 Windows 主机密钥指纹。
后台启动和检查:
```bash
ssh -fN -M -S ~/.ssh/tdx-windows-lan-control tdx-windows-lan
ssh -S ~/.ssh/tdx-windows-lan-control -O check tdx-windows-lan
```
停止:
```bash
ssh -S ~/.ssh/tdx-windows-lan-control -O exit tdx-windows-lan
```
Windows 的家庭 SSH 防火墙规则应使用项目专用名称 `A-Share-TDX-SSH-LAN`,只允许家庭子网访问 TCP 22。系统原有的全范围 OpenSSH 入站规则保持禁用,不为 TDX 开放 `17709`。
### 7.3 外部 Tailscale 模式
前置检查:
```bash
tailscale up
tailscale ping <WINDOWS_TAILSCALE_HOST>
```
后台启动和检查:
```bash
ssh -fN -M -S ~/.ssh/tdx-windows-tailnet-control tdx-windows-tailnet
ssh -S ~/.ssh/tdx-windows-tailnet-control -O check tdx-windows-tailnet
```
停止:
```bash
ssh -S ~/.ssh/tdx-windows-tailnet-control -O exit tdx-windows-tailnet
```
如果控制套接字残留但进程已不存在,先确认 `17710` 没有监听,再删除对应场景的单个控制套接字。不要用宽泛的 `pkill ssh`,以免终止其他 SSH 会话。
## 8. 验证 TDX 链路
### 8.1 Windows 本机验证
先确认 TDX 客户端已启动、已登录,接口监听 `127.0.0.1:17709`:
```powershell
Get-NetTCPConnection -LocalAddress 127.0.0.1 -LocalPort 17709 -State Listen
```
端口没有监听时,应先恢复 TDX 客户端;SSH 和 Tailscale 无法替代 TDX 服务本身。
### 8.2 Mac 端口验证
隧道启动后在 Mac 执行:
```bash
nc -vz 127.0.0.1 17710
lsof -nP -iTCP:17710 -sTCP:LISTEN
```
`17710` 的监听进程应为本次 SSH 隧道,不应是其他应用。
### 8.3 只读 HTTP 冒烟
```bash
curl --fail-with-body --silent --show-error \
--connect-timeout 3 \
--max-time 10 \
-H 'Content-Type: application/json' \
-X POST 'http://127.0.0.1:17710/' \
--data '{"id":1,"method":"get_market_data","params":{"stock_list":["600519.SH"],"count":5,"dividend_type":"none","period":"1d"}}'
```
链路验收条件:HTTP 返回成功,且 TDX 业务响应中的错误码表示成功。只验证少量公开行情,不调用交易、账户、自选、写入或大批量接口。
## 9. 外网场景验证
在真正离开家庭网络前,使用 Mac 手机热点或其他外部网络完成一次演练:
1. 确认 Windows 保持开机、联网,Tailscale 和 `sshd` 在线,TDX 已启动并登录。
2. Mac 切换到外部网络后重新连接 Tailscale。
3. 执行 `tailscale ping <WINDOWS_TAILSCALE_HOST>`。
4. 执行 `ssh -N tdx-windows-tailnet` 并保持终端运行。
5. 依次执行 `nc` 和只读 `curl` 冒烟。
6. 停止隧道,确认 `127.0.0.1:17710` 不再监听。
如果外网演练失败,开发和自动化测试可显式切换到离线样本,并明确标记数据来源。不要临时开放公网 SSH、RDP 或 TDX 端口。
## 10. Windows 无人值守准备
当前链路是开发辅助,不承诺生产级 7x24 可用性。为了减少外出后无法联调的概率,可在 Windows 上做以下准备:
- 将虚拟机配置为宿主机启动后自动启动,并确认异常关机后的恢复策略。
- 保持 Tailscale 与 `sshd` 服务自动启动,重启后通过另一台 Tailnet 设备验证在线状态。
- 接通电源时禁用自动睡眠:
```powershell
powercfg /change standby-timeout-ac 0
```
- 明确 TDX 是否需要交互式桌面登录、验证码或人工确认。需要人工登录时,不得把它描述为无人值守服务。
- 安排 Windows 更新和虚拟机重启窗口;更新后重新验证 Tailscale、SSH、TDX 监听和只读请求。
- 不为自动启动把 Windows 密码、TDX 凭据或 SSH 私钥写入仓库和普通脚本。
## 11. 收紧访问范围
链路验证通过后,在 Tailscale 管理后台将访问规则限制为指定开发身份或 Mac 到 Windows SSH 端口。具体策略应以当前 Tailnet 的身份和标签设计为准,不在仓库保存真实账户和地址。
还可在 Windows 中新增一条仅允许 Mac Tailscale IP 访问 SSH 的规则。先确认 Tailscale 网卡名称,再创建规则:
```powershell
Get-NetAdapter | Where-Object InterfaceDescription -Match 'Tailscale'
New-NetFirewallRule `
-DisplayName 'OpenSSH Server - Tailscale Mac Only' `
-Direction Inbound `
-Action Allow `
-Protocol TCP `
-LocalPort 22 `
-RemoteAddress '<MAC_TAILSCALE_IP>' `
-InterfaceAlias 'Tailscale'
```
新规则必须在外网场景实测通过后,才能禁用范围更宽的旧 SSH 规则。若实际网卡别名不是 `Tailscale`,使用 `Get-NetAdapter` 显示的名称,不凭猜测修改。
## 12. 故障排查
### Tailscale ping 不通
- 检查两端是否登录同一个 Tailnet、节点是否过期、Windows 是否睡眠或断网。
- 检查 Tailnet ACL 或设备审批状态。
- 不要先排查 TDX;此时底层私网尚未连通。
### SSH 连接超时或拒绝
- Windows 执行 `Get-Service sshd` 和 `Get-NetTCPConnection -LocalPort 22 -State Listen`。
- 检查 Windows 防火墙和 Tailscale 访问规则。
- Mac 执行 `ssh -vvv tdx-windows-tailnet`,确认目标是 Tailscale 地址而非家庭公网地址。
### SSH 仍要求 Windows 密码
- 确认 `IdentityFile` 指向 `~/.ssh/tdx_windows`,并检查 `ssh -vvv` 是否提供了该密钥。
- 管理员账户确认文件是 `C:\ProgramData\ssh\administrators_authorized_keys`;非管理员账户确认文件是用户目录下的 `.ssh\authorized_keys`。
- 确认公钥为完整单行文本,文件已先创建,ACL 没有继承无关权限。
- 执行 `sshd -t` 检查配置,再执行 `Restart-Service sshd`。
### Mac 的 `17710` 无法监听
- 查看 SSH 前台错误;`ExitOnForwardFailure yes` 会在端口冲突或转发失败时直接退出。
- 执行 `lsof -nP -iTCP:17710 -sTCP:LISTEN` 查找占用者。
- 不要把本地端口改成 `0.0.0.0`;需要换端口时同步修改本机开发配置,并保持回环绑定。
### 端口可连但 HTTP 失败
- 在 Windows 本机确认 TDX `127.0.0.1:17709` 正在监听。
- 确认 TDX 客户端已登录且当前版本仍支持目标方法。
- 使用最小只读请求检查 HTTP 状态、TDX 错误码和响应时间,不把协议错误误判为网络错误。
### 外出后 Windows 不在线
- 无法远程唤醒或恢复交互式 TDX 登录时,显式切回离线样本继续开发,并保持非实时标记。
- 不通过新增公网暴露、共享密码或关闭防火墙绕过问题。
- 待公网部署需求明确后,另立功能实现生产级采集器、心跳、补传和远程运维。
## 13. 日常操作速查
### 13.1 在家开发
```bash
ssh -o BatchMode=yes -o ClearAllForwardings=yes -T tdx-windows-lan exit
ssh -fN -M -S ~/.ssh/tdx-windows-lan-control tdx-windows-lan
ssh -S ~/.ssh/tdx-windows-lan-control -O check tdx-windows-lan
nc -vz 127.0.0.1 17710
```
结束家庭局域网联调:
```bash
ssh -S ~/.ssh/tdx-windows-lan-control -O exit tdx-windows-lan
lsof -nP -iTCP:17710 -sTCP:LISTEN
```
### 13.2 在外开发
```bash
tailscale up
tailscale ping <WINDOWS_TAILSCALE_HOST>
ssh -fN -M -S ~/.ssh/tdx-windows-tailnet-control tdx-windows-tailnet
ssh -S ~/.ssh/tdx-windows-tailnet-control -O check tdx-windows-tailnet
nc -vz 127.0.0.1 17710
```
结束外部联调:
```bash
ssh -S ~/.ssh/tdx-windows-tailnet-control -O exit tdx-windows-tailnet
lsof -nP -iTCP:17710 -sTCP:LISTEN
```
最后一条命令无输出表示本地转发已经停止。切换场景时必须先停止当前隧道,再启动另一场景;不得通过更换 TDX Bridge 地址绕过端口冲突。
## 14. 后续 Provider 接入约束
- 平台配置只能引用 Mac 回环地址 `127.0.0.1:17710`,不得保存家庭网络或 Tailscale 地址。
- TDX 是正式行情来源;离线样本只作为显式开发和测试回退,必须展示来源与陈旧状态,生产环境禁止启用。
- Provider 必须限制请求超时、响应体大小、股票数量和并发,并输出来源、采集时间、交易日期、协议版本、追踪 ID 和陈旧状态。
- TDX 原始字段仅在 Adapter 内转换,上层市场概览、规则分析和 AI 分析只依赖版本化内部契约。
- 隧道中断必须返回明确的不可用或陈旧状态,不能把离线样本伪装成实时行情。
- Windows 采集器、公网接收 API、多目标推送、补传队列和无人值守运维继续延期,实施时单独立项并重新进行安全、性能和合规评估。
@@ -0,0 +1,50 @@
# Ubuntu 源码生产部署
这是项目唯一生产部署方式,支持 Ubuntu 22.04 LTS 与 Ubuntu 24.04 LTS x86_64。服务器管理员预先提供 Node.js 22.x、pnpm 10.25.0、Nginx,以及外部 MySQL 5.7.x、Redis、RocketMQ 5.x;项目不负责安装、升级、启动、停止、删除或修改这些系统软件与服务。
## 构建发布目录
在固定提交的干净工作区执行:
```bash
uname -m
node --version
pnpm --version
pnpm install --frozen-lockfile
pnpm verify:release
```
架构必须为 `x86_64`,Node.js 必须为 22.x,pnpm 必须为 10.25.0。发布门禁会完成测试、Web/Server 构建、双视口浏览器检查,并核对 Web、API、Scheduler、Worker 产物与 systemd/Nginx 模板。
每次发布使用 `/opt/a-share-analysis/releases/<版本或提交>/` 新目录。完整传输并验证目录后,再把 `/opt/a-share-analysis/current` 原子切换到目标目录;禁止在 `current` 中原地覆盖文件,也禁止只发布部分进程产物。
## 配置与 systemd
生产配置放在 `/etc/a-share-analysis/api.env`、`scheduler.env`、`worker.env`,建议权限 `root:a-share 0640`;Web 的 `VITE_` 公开变量在构建前注入。三个 systemd 单元通过各自的 `EnvironmentFile=` 只读取本进程需要的键,运行用户为非登录系统用户 `a-share`。
```bash
sudo install -m 0644 deploy/systemd/a-share-api.service.example /etc/systemd/system/a-share-api.service
sudo install -m 0644 deploy/systemd/a-share-scheduler.service.example /etc/systemd/system/a-share-scheduler.service
sudo install -m 0644 deploy/systemd/a-share-worker.service.example /etc/systemd/system/a-share-worker.service
sudo install -m 0644 deploy/nginx/a-share-analysis.conf.example /etc/nginx/conf.d/a-share-analysis.conf
sudo systemd-analyze verify /etc/systemd/system/a-share-api.service
sudo systemd-analyze verify /etc/systemd/system/a-share-scheduler.service
sudo systemd-analyze verify /etc/systemd/system/a-share-worker.service
sudo nginx -t
sudo systemctl daemon-reload
sudo systemctl restart a-share-api.service
sudo systemctl restart a-share-scheduler.service
sudo systemctl restart a-share-worker.service
sudo systemctl status a-share-api.service a-share-scheduler.service a-share-worker.service
sudo journalctl -u a-share-api.service -u a-share-scheduler.service -u a-share-worker.service --since '5 minutes ago'
curl --fail http://127.0.0.1:3000/api/v1/health
curl --fail http://127.0.0.1/
```
当前工程尚无业务表迁移;后续新增迁移后必须在切换 `current` 前单独执行并记录结果。生产环境禁止 `synchronize: true`,开发流程也禁止用生产数据库做 Schema 基线或连接测试。
## 检查与回退
使用 `systemctl status`、`journalctl -u`、HTTP 健康端点和 Nginx 同源访问结果确认发布。任一验证失败时,把 `/opt/a-share-analysis/current` 原子切回上一完整发布目录,重启三个 systemd 服务并重复健康检查。
`/etc/a-share-analysis/*.env` 和外部 Redis、MySQL、RocketMQ 数据不随应用目录切换而覆盖或删除。RocketMQ 的 NameServer、Broker、Proxy 与 CommitLog 由运维独立维护。
@@ -0,0 +1,55 @@
# 数据源接入架构与 TDX PoC 规划
## 方案结论
当前采用“平台先行、采集器后置”。Mac 本地开发以固定样本回放为默认 Provider;需要验证真实字段时,通过 Tailscale + SSH 隧道访问家中 Windows 的 TDX `127.0.0.1:17709`。不在当前阶段实现 Windows 常驻采集程序、GUI 或公网推送。
```text
固定样本 / Mac TDX 隧道
↓
DataProvider 端口
↓
标准化市场事件 → 市场概览业务
未来公网模式:采集器 → 多目标隔离推送 → 平台接收 API
```
## 方案比较
- 本地样本回放(当前采用):不引入 Windows/公网依赖,测试稳定可重复,适合先开发市场概览;缺点是不能代表实时数据质量。
- Mac 通过 Tailscale SSH 隧道调用 TDX(当前联调):可以验证真实字段,但依赖家中 Windows 在线和人工维护。
- Windows 常驻采集器(延期):未来可选 Node、Python、Go、Rust、Electron、Tauri 或系统服务,必须按部署规模、资源、自动更新和安全能力重新评估。
## 当前组件边界
当前只新增/维护平台侧 Provider 端口和固定样本。样本 Provider 与真实 TDX Provider 使用同一标准化契约,市场概览不感知来源差异。未来采集器应作为独立项目或 workspace,不反向污染 NestJS 业务模块;公网接收 API、目标队列、签名握手和 GUI 另立功能档案。
## Provider 与事件模型
Provider 生成不可变标准化事件,包含 `eventId`、`source`、`capturedAt`、`tradeDate`、`schemaVersion`、`traceId` 和数据新鲜度。TDX 原始字段只能存在于 Adapter 内,规则分析、AI 分析、API 和页面只依赖内部模型。
## 安全策略与评估
- Mac 本地样本和 TDX 隧道均不接触生产配置、生产数据库或公网接收 API。
- 真实 TDX 只读调用使用 SSH 密钥隧道,`17709`、SSH 和 RDP 不做公网端口映射。
- 样本删除凭据、家庭地址和无关原始字段;日志只保存统一错误分类和性能摘要。
- 未来采集器的密钥存储、目标认证、IPC 和自动更新不在当前方案中预设,必须重新安全评估。
- 数据再分发许可属于外部合规风险。PoC 只用于个人开发验证,不宣称获得商业展示或再分发授权。
## 性能目标与评估
- 固定样本回放必须确定性、可重复且不访问网络;Provider 标准化耗时纳入单元测试与基准记录。
- 真实 TDX 请求目标超时 5 秒并记录响应耗时和字段完整性。
- 公网上传并发、队列容量、心跳周期和 GUI 资源目标延期到采集器立项,不在当前阶段作容量承诺。
## 失败恢复
TDX 请求失败返回统一错误分类和陈旧状态;本地平台可切回固定样本继续开发,不能把样本伪装为实时行情。上传重试、补传、熔断和备用免费源切换属于后续公网功能。
## 测试边界
单元测试使用固定 TDX 响应验证 Provider、标准化和错误映射;通过 Tailscale SSH 隧道做真实只读冒烟。Electron/Tauri 安装、托盘、开机启动、操作系统密钥存储、目标队列和公网接收测试延期,不能在当前阶段宣称通过。
## 依赖与退出方案
当前不新增 Electron、Python、Go、Rust 或其他采集器运行时依赖。未来采集器实现前重新比较语言、部署形态、许可证、资源、自动更新和安全边界;只要遵循 Provider/上传契约,采集器可替换而不改市场概览。
@@ -0,0 +1,26 @@
# GitNexus 开发前基线
- 功能编号:FEAT-DS-001
- 记录时间:2026年8月14日 GMT+8 02:38:03
- 分支:main
- 基线提交:a398bc418d39
## 工作区
```text
?? docs/features/FEAT-DS-001-tdx-ingestion-poc/
```
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/14/2026, 2:38:02 AM
Indexed commit: a398bc4
Current commit: a398bc4
Status: ✅ up-to-date
```
## 后续人工分析
在修改代码前,将 GitNexus query、context、impact 的结论写入 `gitnexus/impact-plan.md`。高风险结果必须先获得用户确认。
@@ -0,0 +1,24 @@
# GitNexus 开发前影响计划
- 功能编号:FEAT-DS-001
- 总体风险:LOW(当前仅规划 Provider 边界和本地联调,不新增桌面应用或公网入口)
## 直接与间接影响
- `gitnexus query --repo a-share-analysis "market data ingestion TDX adapter scheduler worker"` 未找到现成行情 Provider,相关现有流程集中在 Scheduler/Worker 启动和运行时配置。
- `gitnexus query --repo a-share-analysis "configuration HTTP API health Redis MySQL RocketMQ"` 表明 API 当前只有健康检查流程,新增接收模块不会修改 `HealthService`。
- 对名称 `health` 的 upstream impact 命中 Web API 目录且风险为 LOW、无上游消费者;由于名称存在歧义,结论仅作为辅助证据,不解释为对 API 全局无影响。
- 当前不新增 `desktop/tdx-agent` 或 `MarketIngestModule`,不会修改现有 Web、API、Scheduler 或 Worker 符号。
- 直接消费者是后续市场概览 Service;未来采集器、RocketMQ Worker、Redis 快照和 MySQL 历史属于延期功能,必须重新执行影响分析。
## 跨模块同步修改
- HTTP/OpenAPI:当前不新增公网握手或上报 DTO;Provider 内部契约不得泄漏到 Web。
- Web API:主平台 Vue 不修改;不存在 Electron renderer。
- 消息契约:本 PoC 不启用 RocketMQ,也不预留伪接收实现。
- 数据库与 Redis:不新增 Schema,不读取生产库;PoC 接收仅做受控确认。
- API:后续 Provider 如进入 API,再对 `ApiModule.register`、OpenAPI 和运行时配置执行影响分析。
- Scheduler/Worker:本 PoC 不修改;后续正式排队功能另立功能档案和影响分析。
- 配置部署:当前不新增 Windows 或公网配置,不改变主平台源码部署政策。
- 测试:使用固定样本和 TDX 隧道冒烟;采集器打包和 Windows 无人值守测试延期。
- 文档:记录延期原因、Provider 边界、安全、性能和未来重新立项条件。
@@ -0,0 +1,17 @@
# 数据源接入架构与 TDX PoC 规划
## 当前计划(不实现采集器)
1. 建立与运行时无关的 `DataProvider`、市场事件和数据新鲜度契约。
2. 用固定样本 Provider 支撑市场概览的规则、AI、混合和对照分析开发。
3. 按 [Tailscale + SSH 隧道访问 TDX 开发手册](../../deployment/tailscale-tdx-development.md) 执行真实 TDX 只读请求,保存脱敏字段报告。
4. 对 TDX 字段缺失、协议错误和陈旧数据做 Provider 层降级,不连接生产数据。
5. 暂不新增 Windows 应用、Electron/Tauri、目标推送、补传队列、公网接收 API、RocketMQ 事件或数据库表。
6. 待公网部署需求确定后,另立采集器功能档案,重新评估 Node、Python、Go、Rust 或系统服务方案。
## 后置功能必须覆盖
- 单次采集、多目标隔离推送。
- production/development 独立地址、密钥、队列、状态和启停;两者地址均可修改。
- production 未配置或停止为正常状态;停止时不删除队列、不转投 development。
- HTTPS/HMAC、重放防护、握手身份、限流、补传、熔断、心跳、无人值守运行和系统更新。
@@ -0,0 +1,12 @@
id: FEAT-DS-001
name: 数据源接入架构与 TDX PoC 规划
slug: tdx-ingestion-poc
status: deferred
owner: project
created_at: 2026-08-14
requirements: requirements.md
prd: prd.md
design: design.md
implementation_plan: implementation-plan.md
traceability_note: 当前只完成数据源边界和本地联调规划;操作步骤见 ../../deployment/tailscale-tdx-development.md;Windows 采集器与公网接入延期到公网部署需求确认后单独立项。
release: unreleased
@@ -0,0 +1,37 @@
# TDX 数据接入 PoC PRD
## 用户问题
TDX 客户端运行在家中 Windows 虚拟机,并且接口只监听 Windows 本机 `127.0.0.1:17709`。公网平台和人在外面的开发设备都不能直接访问该端口,需要验证一套不暴露 TDX、可 7×24 小时运行的数据上报链路。
## 目标
在不提前引入公网部署和 Windows 常驻程序的前提下,先确定 TDX 数据源边界、标准化 Provider 契约和 Mac 本地联调方式。Windows 采集器、托盘 GUI、目标推送和公网接收入口延期,避免在生产部署形态尚未确定时锁定技术栈。
## 范围
- Mac 本地开发使用固定样本回放作为默认数据源,并保留通过 Tailscale SSH 隧道调用家中 Windows TDX 的人工联调方式。
- 只定义与运行时无关的 `DataProvider`、标准化事件和数据新鲜度字段,不实现 Windows 常驻采集程序。
- 记录未来公网模式的单次采集、多目标隔离推送、地址可变和目标启停原则,但不在本功能实现。
- 只读验证指数、单股 K 线、快照、分时和板块接口中实际可用的字段。
- 通过 Tailscale + SSH 隧道从外部 Mac 远程验证家中 Windows TDX;验证结果只用于 Provider 契约,不写入生产链路。
## 非目标
- 不在本功能中开发 Windows 采集应用、Electron/Tauri GUI、开发/生产接收 API、目标队列或公网推送。
- 不在本功能中开发市场概览页面、AI 分析、正式 Worker 消费或生产接入。
- 不开放 TDX `17709`、SSH 或 RDP 到公网。
- 不写入自选、交易、账户或 TDX 状态。
- 不把通达信数据授权问题解释为已解决;商业展示和再分发授权仍需单独确认。
## 成功指标
- 固定样本能够覆盖 Provider 的 K 线、快照、分时、板块和错误映射测试。
- 通过 SSH 隧道完成至少一次真实 TDX 只读请求,并保存脱敏字段报告。
- Provider 契约不依赖 Node、Electron、Python 或具体传输方式;未来采集器可独立替换。
## 风险
- TDX 客户端协议和返回字段可能变化;代理必须保留原始字段版本和来源标识。
- 未来公网部署会增加采集节点、推送认证和再分发风险;延期期间不把这些风险误标为已解决。
- 行情数据的展示、再分发和商业使用权利不由代码许可证自动授予。
@@ -0,0 +1,28 @@
# 数据源接入架构与 TDX PoC 工程需求
## 当前阶段 Provider 边界
- Provider 暴露与采集器语言和传输方式无关的只读接口,统一返回 `source`、`capturedAt`、`tradeDate`、`schemaVersion`、`traceId` 和数据新鲜度。
- 默认开发 Provider 使用仓库内固定样本,不连接生产数据源;真实 TDX Provider 只通过显式本地配置和 Tailscale SSH 隧道联调。
- TDX Provider 限制回环地址、请求超时、响应体大小、股票列表和并发;不得把家庭地址或凭据写入代码。
- Provider 原始响应映射为版本化内部载荷,上层分析不得依赖 TDX 原始字段名称。
## 当前运行与环境
- 平台仅在 Mac 本地源码运行,不要求安装 Windows 采集程序。
- 固定样本支持离线、确定性和可重复测试;真实 TDX 联调依赖家中 Windows 在线,但不能成为日常测试门禁。
- 当前不新增 Electron、Tauri、Python 服务、Go/Rust 程序、公网接收 API、文件补传队列或目标密钥。
- SSH 私钥、TDX 地址、家庭网络信息和开发数据库凭据不得进入仓库、日志、样本或前端构建物。
## 延期的公网采集原则
- 采集器语言、GUI 壳和打包方式不预设为 Node/Electron,待公网部署需求确认后比较 Node、Python、Go、Rust 和系统服务方案。
- 未来采集器只采集一次,production/development 使用独立地址、节点 ID、密钥、队列、上传器、心跳和启停状态。
- production 与 development 地址均可修改且独立测试;任一目标故障或重配不得影响另一目标。
- production 未配置或停止属于正常状态;停止时不删除已有队列、不转投 development。
- 公网模式必须重新设计 HTTPS/HMAC、重放防护、身份握手、限流、补传、熔断、无人值守运行和操作系统密钥存储。
## 可观测性
- Provider 结果标记来源、采集时间、数据时间、陈旧状态和统一错误分类。
- 真实联调报告必须脱敏,不保存完整家庭地址、SSH 信息、供应商凭据或未筛选的原始载荷。
@@ -0,0 +1,23 @@
# 数据源接入架构与 TDX PoC 测试计划
## 当前阶段功能验证
- 固定样本验证 K 线、快照、分时和板块 Provider 载荷映射。
- 通过 Tailscale SSH 隧道验证真实 TDX 只读请求,并保存脱敏字段报告。
- 验证 Provider 在 TDX 错误、超时、空结果和陈旧数据下返回统一错误分类。
- 验证市场概览只依赖内部模型,不直接读取 TDX 原始字段。
## 安全验证
- SSH 私钥、TDX 地址、家庭网络信息和开发数据库凭据不进入仓库、样本、日志或前端构建物。
- TDX 只通过 SSH 隧道访问,`17709` 不开放公网。
- 固定样本不包含供应商凭据和不必要的完整原始载荷。
## 性能验证
- 固定样本下测量 Provider 标准化耗时,确保回放不依赖外部网络。
- 真实 TDX 请求记录响应耗时和字段完整性;不对未来采集器的上传、队列和 GUI 资源作结论。
## 不适用项与边界
不做 Electron/Tauri 窗口、托盘、安装包、生产数据库迁移、RocketMQ 收发和公网接收验证,原因是采集器与公网部署已延期。市场概览页面另按业务功能执行视觉验证。
@@ -0,0 +1,31 @@
# GitNexus 开发前基线
- 功能编号:FEAT-MO-001
- 记录时间:2026年08月18日 00:26:46 CST
- 分支:main
- 基线提交:`c0a6f5560584`
- 创建方式:用户授权跳过 `v0.0.9` Schema 备份后,按 `governance:start` 输出结构手工留痕
## 工作区
```text
(干净)
```
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/17/2026, 6:03:13 PM
Indexed commit: c0a6f55
Current commit: c0a6f55
Status: up-to-date
```
## Schema 门禁例外
失败证据、用户决定、禁止伪造边界和残余风险见 `../schema-baseline-waiver.md`。本记录不表示 `governance:start` 自动门禁通过。
## 后续人工分析
首页设计确认后,在修改任何函数、类或方法前继续执行 GitNexus query、context 和 upstream impact,并将直接、间接、跨模块消费者及高风险处置补充到 `impact-plan.md`。
@@ -0,0 +1,36 @@
# GitNexus 开发前影响计划
- 功能编号:FEAT-MO-001
- 基线提交:`c0a6f5560584`
- 当前阶段:TDX 开发连接设计与首页方案确认
- 当前总体风险:LOW(仅本机 SSH 配置和操作文档);首页业务代码风险待设计确认后按符号补充
## 直接与间接影响
### TDX 双路径开发连接
- 正式行情来源确定为 TDX;家庭局域网和外部 Tailscale 只改变 Mac 到同一 Windows `sshd` 的网络路径。
- TDX Bridge 的稳定入口固定为 Mac 回环地址 `127.0.0.1:17710`,市场概览、规则分析、AI 分析和未来 HTTP 契约不得依赖家庭地址、Tailscale 地址或 TDX 原始字段。
- 当前仓库没有 TDX Provider 或市场概览运行时符号,本阶段只更新操作文档;GitNexus 未识别可执行调用链影响。
- 首页业务设计确认后,必须对 `App.vue`、`createAppRouter`、后端模块装配、HTTP DTO 和新增市场概览符号分别执行 upstream impact。HIGH 或 CRITICAL 结果先告知用户再修改。
## 跨模块同步修改
- HTTP/OpenAPI:当前连接文档不修改;首页正式接入时需要版本化市场概览 DTO 与 OpenAPI 契约。
- Web API 与 adapter:当前不修改;未来页面只能经 `web/src/api/<业务域>/index.ts`、Axios 封装和 ViewModel 消费数据。
- 消息契约、Redis、MySQL、Scheduler、Worker:当前不启用。正式采集链路仍按独立功能立项,不能由 API 请求临时抓取全市场数据。
- 配置部署:真实地址、用户名、密钥和控制套接字只保留在开发机,不进入仓库、环境模板或前端构建物。
- 测试:两种 SSH 路径均需验证到同一 Mac 回环端点;离线样本只作显式开发回退,不得标记为实时 TDX。
- 文档:同步更新 Tailscale/SSH 开发手册,明确家庭局域网与外部 Tailscale 的选择、启动、停止、切换和验证方法。
## 安全、性能与回退
- Windows 的 TDX 继续只监听 `127.0.0.1:17709`,禁止改为局域网或公网监听。
- 家庭 SSH 入站规则只允许家庭子网访问 TCP 22;系统原有全范围 OpenSSH 规则保持禁用。
- 两条 SSH 路径复用同一项目专用 Ed25519 密钥;局域网主机密钥必须与已验证的 Tailscale 主机密钥指纹一致。
- 家庭 LAN 与当前 Tailscale 直连延迟均足以满足开发期分钟级行情;首页不得承诺秒级刷新。
- 回退时停止对应 SSH 控制连接、删除本机 TDX 别名,并删除 Windows 项目专用防火墙规则;不得删除通用 SSH 密钥、Tailscale 账户或 TDX 数据。
## Schema 例外风险
`v0.0.9` Schema 基线缺失会阻断严格自动治理门禁,风险见 `../schema-baseline-waiver.md`。本功能不借该例外修改数据库结构、读取生产数据库或声称发布门禁通过。
@@ -23,7 +23,7 @@
## 非目标 ## 非目标
- 不做自选股、持仓、笔记、交易计划、社区、荐股、跟单和公开组合。 - 不做自选股、持仓、笔记、交易计划、社区、荐股、跟单和公开组合。
- 本切片不接正式行情源、RabbitMQ、MySQL、Redis和付费 AI。 - 本切片不接正式行情源、RocketMQ、MySQL、Redis和付费 AI。
- 本切片不实现用户、邀请、会员、订阅和支付。 - 本切片不实现用户、邀请、会员、订阅和支付。
- ETF监控、两融数据、大盘云图和实时消息仍是独立一级模块。 - ETF监控、两融数据、大盘云图和实时消息仍是独立一级模块。
@@ -0,0 +1,23 @@
# v0.0.9 Schema 基线一次性例外
- 功能编号:FEAT-MO-001
- 日期:2026-08-18
- 适用范围:仅 FEAT-MO-001 开发启动
## 事实记录
按常规流程执行 `npm run schema:baseline` 时,本机因不存在 MySQL 5.7.x 的 `mysql` 与 `mysqldump` 客户端,在执行 `mysql --version` 前以 `spawnSync mysql ENOENT` 失败。失败发生在客户端前置检查阶段,未连接开发数据库,也未生成基线目录或半成品。
用户确认本次继续跳过数据库备份。该决定只适用于从已发布版本 `v0.0.9` 启动 FEAT-MO-001,不继承 GOV-011 对 `v0.0.8` 的一次性例外,也不建立通用跳过能力。
## 处理决定
- 不伪造 `not_applicable`、`captured_empty`、空 SQL、客户端版本、服务端版本或校验摘要。
- 不修改 Schema 工具或 `governance:start` 增加跳过参数。
- 手工保存与 `governance:start` 同等结构的 GitNexus 开发前基线和影响计划。
- FEAT-MO-001 不得因此连接、探测或读取生产数据库。
- 后续功能需要 Schema 基线时,仍必须提供可验证的 MySQL 5.7.x 客户端,或再次获得用户针对该版本的明确授权。
## 风险与接受
缺少 `v0.0.9` Schema 基线意味着仓库不能证明该发布版本对应的开发库结构,也会使依赖严格 Schema 证据的自动治理门禁无法通过。用户接受本次追溯风险;该例外不表示数据库门禁、发布门禁或未来数据库变更已经通过。
@@ -0,0 +1,9 @@
# GitNexus 开发后结果
- 执行:`npx gitnexus analyze`。
- 工作区索引:620 个节点、651 条关系、7 个集群、0 条执行流程。
- 增量分析:7 个已修改文件、25 个新增文件、0 个删除文件。
- 最终索引提交:`9203fdd`。
- 状态:up-to-date。
实现提交后再次分析,索引已锚定最终提交。
@@ -0,0 +1,10 @@
# GitNexus 前后对比
| 项目 | 开发前 | 开发后工作区 | 变化 |
|---|---:|---:|---:|
| 节点 | 452 | 620 | +168 |
| 关系 | 477 | 651 | +174 |
| 集群 | 5 | 7 | +2 |
| 执行流程 | 0 | 0 | 0 |
新增集群来自环境模板与部署文档边界;没有生产执行流程变化,符合影响预估。最终索引锚定实现提交 `9203fdd`。
@@ -0,0 +1,8 @@
# GitNexus 变更检测
- 命令:`npx gitnexus detect-changes --repo a-share-analysis --scope staged`。
- 最终暂存区:43 个文件、77 个符号。
- 受影响流程:0。
- 风险等级:低。
范围包含配置模板、Compose、systemd、Nginx、部署文档、现行治理入口、契约测试和 GOV-006 档案。
@@ -0,0 +1,7 @@
# GitNexus 开发前影响分析
- 查询主题:`development production environment templates Docker Compose Ubuntu source deployment systemd`。
- 关联范围:README、开发流程、开发规范、系统架构、GOV-005 和部署目录。
- 本次新增配置、文档和静态测试,不修改既有生产函数、类或方法,无生产符号上游影响目标。
- GitNexus 未识别业务执行流程;预计影响限于配置契约、部署边界和治理测试。
- 风险控制:不提交真实秘密,不运行应用部署,不连接任何生产服务,明确示例骨架的未验证状态。
@@ -0,0 +1,129 @@
# 开发、生产环境与双部署方式实施计划
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** 建立可机器验证的开发/生产环境变量契约、本地 Redis Compose,以及 Docker Compose 与 Ubuntu 源码生产部署规范和配置骨架。
**Architecture:** 八份 env 模板按进程和环境分离,但同一进程在 development/production 使用相同变量名。静态契约测试负责检查模板完整性、敏感值为空、Web 仅暴露 `VITE_*`、生产安全默认值和部署文件边界;当前应用尚未实现,不伪造可运行的应用镜像或启动命令。
**Tech Stack:** dotenv 模板、Docker Compose、Redis、systemd、Nginx、Node.js 内置测试运行器、Markdown、GitNexus。
## Global Constraints
- 环境仅定义 `development` 与 `production`,生产禁止模拟数据、热更新和开发默认值回退。
- 仓库提交八份 `*.env.example`,不提交任何真实 `.env` 或凭据。
- 本地 Compose 只启动 Redis;Web/API/Scheduler/Worker 从源码运行。
- 生产支持 Docker Compose 和 Ubuntu 22.04/24.04 x86_64 源码部署。
- Node.js 22 LTS、pnpm 10、Nginx 和基础设施由管理员提供,项目只验证不安装。
- 源码部署使用 `a-share` 用户和 `/etc/a-share-analysis/*.env`。
- MySQL 与 RabbitMQ 第一阶段默认关闭;MySQL 条件配置遵守 GOV-005。
---
### Task 1: 建立失败的环境配置契约测试
**Files:**
- Create: `tools/governance/environment-baseline.test.mjs`
- Modify: `package.json`
**Interfaces:**
- Consumes: `deploy/env/`、`deploy/compose/`、`deploy/systemd/`、`deploy/nginx/` 和 `docs/deployment/`。
- Produces: `npm run test:environment-baseline`。
- [ ] **Step 1: 编写模板和部署边界测试**
测试八份模板存在、同一进程两环境键集合相同、敏感键为空、Web 仅含 `VITE_*`、生产安全开关正确、本地 Compose 仅定义 Redis,并检查 systemd/Nginx 与两份生产部署文档。
- [ ] **Step 2: 验证测试因文件缺失而失败**
运行:`npm run test:environment-baseline`
预期:失败明确指出第一份缺少的环境模板或部署文件。
### Task 2: 实现统一环境模板
**Files:**
- Create: `deploy/env/development/api.env.example`
- Create: `deploy/env/development/scheduler.env.example`
- Create: `deploy/env/development/worker.env.example`
- Create: `deploy/env/development/web.env.example`
- Create: `deploy/env/production/api.env.example`
- Create: `deploy/env/production/scheduler.env.example`
- Create: `deploy/env/production/worker.env.example`
- Create: `deploy/env/production/web.env.example`
- Modify: `.gitignore`
**Interfaces:**
- Consumes: GOV-006 设计中的变量作用域。
- Produces: 后续 NestJS Schema 和部署方式共同使用的变量名契约。
- [ ] **Step 1: 编写四类进程模板**
每项变量附中文说明;敏感变量保持空值;MySQL/RabbitMQ/AI 由功能开关控制条件必填;生产值拒绝模拟数据和调试模式。
- [ ] **Step 2: 加固忽略规则**
只允许提交 `*.env.example`,忽略 `*.env.local`、真实 env 和本地运行目录。
### Task 3: 实现本地 Redis 与生产部署骨架
**Files:**
- Create: `deploy/compose/development.yml`
- Create: `deploy/compose/production.yml.example`
- Create: `deploy/systemd/a-share-api.service.example`
- Create: `deploy/systemd/a-share-scheduler.service.example`
- Create: `deploy/systemd/a-share-worker.service.example`
- Create: `deploy/nginx/a-share-analysis.conf.example`
- Create: `docs/deployment/local-development.md`
- Create: `docs/deployment/docker-compose-production.md`
- Create: `docs/deployment/ubuntu-source-production.md`
**Interfaces:**
- Consumes: Task 2 的模板键集合。
- Produces: 本地 Redis 启动入口、生产 Compose 配置边界、systemd EnvironmentFile 和 Nginx 代理示例。
- [ ] **Step 1: 配置本地 Redis Compose**
固定 Redis 镜像补丁版本,只暴露本机端口,使用项目专用容器名、网络、健康检查和仓库外本地数据目录;不得定义其他服务。
- [ ] **Step 2: 配置生产部署骨架**
生产 Compose 只表达应用服务的配置契约和不可变镜像要求;systemd 使用独立 EnvironmentFile,Nginx 托管静态文件并代理 `/api/`。
- [ ] **Step 3: 编写开发与双生产部署文档**
明确当前应用尚未脚手架化,文档只验证配置与部署边界;列出管理员前置条件、版本检查、健康检查、升级和回退规则。
- [ ] **Step 4: 验证测试转绿**
运行:`npm run test:environment-baseline && npm run test:mysql-baseline && npm run test:governance`
预期:全部通过。Docker 可用时额外运行 `docker compose -f deploy/compose/development.yml config`。
### Task 4: 完成现行规范、追溯与发布
**Files:**
- Modify: `docs/architecture/system-architecture.md`
- Modify: `docs/governance/code-development-standards.md`
- Modify: `docs/governance/development-workflow.md`
- Modify: `README.md`
- Modify: `docs/index.md`
- Modify: `CHANGELOG.md`
- Modify: `VERSION`
- Create: GOV-006 除现有 `design.md`、`implementation-plan.md`、`gitnexus/before.md` 外的全部必备档案。
**Interfaces:**
- Consumes: 通过契约测试的配置与部署文件。
- Produces: 可审查、可发布、可回退的 GOV-006 完整档案和 `v0.0.5`。
- [ ] **Step 1: 更新架构和开发规范**
记录环境模型、配置校验、两种部署方式、平台范围、管理员职责和生产防误用要求。
- [ ] **Step 2: 执行 GitNexus、测试和双 Review**
检测完整暂存区并运行 `npm run governance:finish -- GOV-006 environment-deployment-baseline`。
- [ ] **Step 3: 中文提交、推送与发布**
提交并推送 `main`;封存后创建带注释 `v0.0.5`,精确推送并核对分支与标签。
@@ -0,0 +1,18 @@
id: GOV-006
name: 开发、生产环境与双部署方式
slug: environment-deployment-baseline
status: released
owner: project
created_at: 2026-08-13
prd: prd.md
requirements: requirements.md
design: design.md
implementation_plan: implementation-plan.md
gitnexus_before: gitnexus/before.md
gitnexus_after: gitnexus/after.md
gitnexus_comparison: gitnexus/comparison.md
code_review: review/code-review.md
standards_review: review/standards-review.md
implementation_commit: 9203fdd
release: v0.0.5
superseded_by: GOV-009/source-only-deployment-design.md
@@ -0,0 +1,31 @@
# 开发、生产环境与双部署方式 PRD
- 功能编号:GOV-006
- PRD 版本:0.1
- 状态:approved
- 日期:2026-08-13
## 问题
项目缺少开发/生产配置契约和部署边界,存在真实配置入库、生产误用模拟数据及两种部署方式行为漂移的风险。
## 目标
- 提供开发和生产的四类进程无秘密模板。
- 本地只用 Compose 启动 Redis,应用从源码运行。
- 同时规范 Docker Compose 与 Ubuntu 源码生产部署。
- 生产配置严格校验且不随发布版本覆盖。
## 非目标
- 不安装服务器运行时或基础设施。
- 不声称尚未实现的应用镜像、进程和健康端点已经可运行。
- 不启用 MySQL、RabbitMQ、正式数据源或 AI。
## 验收标准
- 八份模板完整、跨环境键一致且无敏感值。
- Web 模板只含公开 `VITE_*` 变量。
- 开发 Compose 仅定义 Redis并可通过配置解析。
- systemd、Nginx 和三份部署文档满足已确认平台与路径边界。
- 环境契约测试完成红绿验证,双 Review 和治理门禁通过。
@@ -0,0 +1,16 @@
# 测试结果
## 测试先行证据
新增环境基线测试后首次运行 6 个测试全部失败,分别指出八份模板、开发 Compose、systemd/Nginx 示例和部署文档不存在。
补齐最小实现后:
- 环境基线测试:6 个通过,0 个失败。
- MySQL 基线测试:2 个通过,0 个失败。
- 治理测试:5 个通过,0 个失败。
- `docker compose -f deploy/compose/development.yml config`:通过,仅包含 Redis。
- `git diff --check`:通过。
- GitNexus 最终暂存区:43 个文件、77 个符号、0 条流程,风险为低。
生产 Compose 和源码部署当前属于配置契约骨架,应用尚未脚手架化,因此没有伪造生产启动或健康检查成功证据。
@@ -0,0 +1,3 @@
# 视觉验证
本功能没有页面或交互变化,视觉验证不适用。
@@ -0,0 +1,9 @@
# 发布说明
## v0.0.5
- 实现提交:`9203fdd`。
- 新增八份开发/生产无秘密环境模板。
- 新增只启动 Redis 的本地开发 Compose。
- 新增生产 Compose 契约骨架、systemd/Nginx 示例和 Ubuntu 源码部署规范。
- 新增环境配置自动化契约测试。
@@ -0,0 +1,10 @@
# 工程需求
- 环境只定义 `development` 与 `production`。
- API、Scheduler、Worker、Web 分别提供开发/生产模板,同进程键集合一致。
- 敏感变量保持空值,真实配置被 Git 忽略。
- 生产 Worker 固定 `MARKET_DATA_MODE=live`,第一阶段关闭 MySQL 与 RabbitMQ。
- 本地 Compose 固定 Redis 补丁版本、仅绑定本机并提供健康检查。
- Ubuntu 源码部署支持 22.04/24.04 LTS x86_64、Node.js 22 LTS、pnpm 10。
- systemd 使用 `a-share` 用户及独立 `EnvironmentFile`;Nginx 托管静态文件并代理 API。
- 生产 Compose 使用不可变镜像和外部 env,不承诺当前骨架可直接上线。
@@ -0,0 +1,27 @@
# 配置与文档 Review
- reviewer_type:self
- reviewer:Codex
- 基线提交:`0328f9e`
- 设计提交:`fa1df71`
- 实现提交:`9203fdd`
- 日期:2026-08-13
## 审查结论
八份模板保持跨环境键一致,敏感值为空,Web 只含公开变量;开发 Compose 只启动 Redis;生产部署示例明确为未验证骨架。现行架构和规范覆盖启动校验、防误用与管理员职责。
## 发现与处置
| 严重程度 | 发现 | 处置 |
|---|---|---|
| Important | 两种部署方式可能形成不同变量协议 | 强制复用同一模板键并用自动测试比较 |
| Important | 示例容易被误认为可直接上线 | Compose 和文档显式标记需在应用脚手架后验证 |
| Important | 前端变量可能泄露服务端秘密 | 测试要求 Web 模板每个键都以 `VITE_` 开头且只含公开值 |
| Minor | 本地 Redis 数据可能进入仓库 | 使用 `.local/redis` 并加固忽略规则 |
- 环境契约测试 6/6、MySQL 基线 2/2、治理测试 5/5 通过。
- Docker Compose 配置解析成功且只包含 Redis。
- GitNexus 最终暂存区检测为 43 个文件、77 个符号、0 条流程、低风险。
最终结论:passed
@@ -0,0 +1,21 @@
# 开发规范符合性 Review
- reviewer_type:self
- reviewer:Codex
- 实现提交:`9203fdd`
- 日期:2026-08-13
## 检查结果
- [x] 设计经用户确认后实施。
- [x] 环境契约先有 6 个失败测试,再补实现使其通过。
- [x] 模板无真实秘密,真实 env 与本地数据被忽略。
- [x] 不连接或探测生产服务,不安装服务器软件。
- [x] MySQL 变量符合 GOV-005,第一阶段默认关闭。
- [x] Docker Compose 与源码部署共享变量契约。
- [x] 未把尚未实现的应用描述为已可部署。
- [x] 无界面变化,视觉验证合理标记不适用。
没有未解决的 Critical 或 Important 不符合项。
最终结论:passed
@@ -0,0 +1,5 @@
# 回退说明
本功能没有部署应用或连接生产服务。若配置规范需要修正,使用新的中文修复提交更新模板、文档和测试,不移动共享标签。
开发 Redis 数据位于被忽略的 `.local/redis/`,版本回退不得自动删除该目录。生产真实 env 位于仓库外,不随应用版本切换覆盖。
@@ -0,0 +1,8 @@
# 测试计划
- 先运行环境基线测试,证明六类行为因模板和部署文件缺失而失败。
- 实现后要求环境测试 6/6、MySQL 基线 2/2、治理测试 5/5 通过。
- 运行 Docker Compose 配置解析,确认只有 Redis。
- 运行 `git diff --check`、敏感信息扫描和 GitNexus 最终暂存区检测。
- 运行 `npm run governance:finish -- GOV-006 environment-deployment-baseline`。
- 本功能无页面变化,视觉验证不适用。
@@ -0,0 +1,143 @@
# 开发数据库 Schema 基线与版本门禁设计规格
- 功能编号:GOV-007
- 规格版本:0.1
- 状态:approved_for_review
- 日期:2026-08-13
## 背景与目标
数据库正式启用后,每个新应用版本开始开发前都需要一份可审计的结构起点。只保存迁移脚本不能证明开发数据库在版本开始时的真实结构,也无法发现手工改表造成的漂移。
本功能建立强制门禁:开始开发下一个语义化版本前,从开发环境数据库导出当前已发布版本的完整 Schema,规范化、校验并纳入 Git。开发流程和脚本禁止连接、读取或探测生产数据库。
## 版本与命名
基线按“被备份的当前已发布版本”命名,而不是即将开发的版本。例如开始开发 `v0.0.6` 前,封存 `v0.0.5` 状态:
```text
database/schema-baselines/v0.0.5/
├── schema.sql
├── manifest.yaml
└── checksum.sha256
```
每个应用版本开始前都生成一次。即使 Schema 未变化,也生成新版本目录,以相同内容校验值证明没有结构漂移。
## 唯一允许的数据来源
- 只允许读取开发环境数据库。
- 加载开发专用本地配置,要求 `APP_ENV=development`。
- 数据库名固定为 `a_share_analysis_dev`;名称不匹配立即终止。
- 启用真实导出时主机必须为 `127.0.0.1`、`localhost` 或 `::1`;远程开发库必须先通过运维建立本地 SSH 隧道,脚本不接受任意远程目标。
- 禁止通过命令参数覆盖环境类型、数据库名或传入任意 env 文件路径。
- 禁止连接、读取、探测或导出生产数据库;生产备份属于独立运维流程,不进入开发门禁。
- 推荐使用只拥有开发库结构读取和例程查看权限的专用账号,不授予生产访问能力。
即使主机名看似本地,脚本也必须验证环境和数据库名;不能只依赖地址白名单判断安全。
## 导出范围
使用 MySQL 5.7 客户端 `mysqldump`,仅导出结构,不包含任何表数据。基线必须完整包含:
- 数据库表、列、主键、索引、外键与表选项。
- 视图。
- 触发器。
- 存储过程和函数。
- Event Scheduler 事件。
导出命令必须使用 `--no-data --routines --triggers --events`,并使用符合 MySQL 5.7 的选项。执行元数据查询的 `mysql` 客户端和执行导出的 `mysqldump` 客户端必须分别验证为 5.7.x。账号凭据通过开发 env 或受控客户端配置提供,禁止出现在命令参数、日志或清单中。
## 规范化
原始 `mysqldump` 输出经过确定性规范化后才能进入 Git:
- 删除导出时间、完成时间、客户端路径等不稳定注释。
- 删除或规范化环境绑定的 `DEFINER`,避免恢复时绑定个人账号。
- 删除由数据增长产生的 `AUTO_INCREMENT=<当前值>`,保留列的自增属性。
- 统一换行符与文件末尾换行。
- 禁止把主机、端口、账号、密码或客户端配置路径写入 SQL。
- 不改变表、视图、触发器、例程和事件的业务定义。
规范化工具必须通过固定输入/输出测试证明不会误删业务 SQL。
## 校验与清单
`manifest.yaml` 至少记录:
- `application_version`:被备份的已发布版本。
- `git_commit`:该版本标签最终指向的提交。
- `source_environment: development`。
- `database_name: a_share_analysis_dev`。
- MySQL 客户端和服务端精确版本。
- `charset: utf8mb4`。
- `collation: utf8mb4_general_ci`。
- 生成时间与生成工具版本。
- 是否包含表、视图、触发器、例程和事件。
- 规范化 SQL 的 SHA-256。
`checksum.sha256` 使用标准格式记录 `schema.sql` 校验值。流程必须重新计算并验证清单、校验文件和实际 SQL 三者一致。
## 强制阻断条件
出现以下任一情况,不允许进入下一版本开发:
- 当前已发布版本没有 Schema 基线,且数据库已启用。
- `APP_ENV` 不是 `development`。
- 数据库名不是 `a_share_analysis_dev`。
- 检测到生产配置文件、生产环境标识或禁止的连接目标。
- MySQL 客户端或服务端不是 5.7.x。
- 字符集或排序规则不是 `utf8mb4` / `utf8mb4_general_ci`。
- 导出缺少视图、触发器、存储过程/函数或事件的范围声明。
- SQL 包含 `DEFINER`、不稳定导出注释、当前 AUTO_INCREMENT 值或疑似凭据。
- 校验值不一致、目标版本目录已存在且内容不同,或 Git 工作区存在无法解释的 Schema 改动。
禁止覆盖既有版本基线。需要修正时新增带原因的治理记录和修复提交,不静默重写已发布事实。`schema:verify` 是本地内容校验;`governance:start` 还要求基线文件已被 Git 跟踪、工作区无改动、当前分支已推送以及远程发布标签仍指向清单提交。
## 首次启用与未启用状态
当前 MySQL 尚未启用,因此在开发新版本前允许记录结构备份“不适用”,但必须能证明功能开关为关闭,且不得创建伪造的空 `schema.sql` 冒充数据库基线。
首次启用 MySQL 的版本必须:
1. 通过迁移创建开发库初始结构。
2. 在 MySQL 5.7 开发环境验证字符集与排序规则。
3. 发布时建立首份真实 Schema 基线。
4. 后续每个版本开始前严格执行本门禁。
## 开发流程位置
下一版本开发前顺序为:
1. 确认当前已发布版本和标签提交。
2. 判断 MySQL 功能开关;未启用则保存可验证的不适用记录。
3. 已启用时从开发数据库导出、规范化并校验完整 Schema。
4. 将当前发布版本基线作为独立中文提交推送 Gitea。
5. 确认工作区干净和远程同步成功。
6. 再创建下一版本 PRD、设计与功能档案,执行 GitNexus 开发前分析。
数据库迁移必须从上一基线在 MySQL 5.7 开发环境正向执行验证。禁止直接修改共享开发表代替迁移脚本。
## 安全边界
- Schema 基线只含结构,不含业务数据、账号数据或生产数据。
- 导出脚本不得回显秘密,也不得接受密码命令行参数。
- 开发工具和代理无权使用生产 env 或生产数据库验证功能。
- 基线提交前扫描疑似凭据、生产主机、`DEFINER` 和数据 INSERT。
- Schema 基线进入 Git 后视为公开给仓库使用者,任何敏感对象名称或注释都应在数据库设计阶段避免。
## 实施范围
GOV-007 将实现数据库目录规范、开发 env 模板扩展、确定性 SQL 规范化工具、导出/校验脚本、自动化测试、开发流程门禁和完整追溯档案。由于当前 MySQL 未启用,本功能只验证阻断逻辑、规范化固定样本和“不适用”路径,不连接任何数据库。
## 验收标准
- 开发流程明确每个应用版本开始前建立上一已发布版本的开发库 Schema 基线。
- 脚本只接受 `development` 和固定开发库名,无法通过普通参数切换到生产配置。
- 导出范围包含表、视图、触发器、存储过程/函数和事件且不含数据。
- 规范化稳定移除时间注释、`DEFINER` 和当前 AUTO_INCREMENT 值,但保留业务 SQL。
- 清单和 SHA-256 格式可自动校验。
- MySQL 5.7、`utf8mb4`、`utf8mb4_general_ci` 不符合时阻断。
- 当前未启用 MySQL 时使用可验证“不适用”记录,不伪造空 Schema。
- 自动化测试、治理门禁、GitNexus 和双 Review 通过。
- 中文提交和对应版本标签精确推送 Gitea。
@@ -0,0 +1,30 @@
# GitNexus 开发后基线
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/13/2026, 1:13:21 PM
Indexed commit: d827bfa
Current commit: d827bfa
Status: ✅ up-to-date
```
## 最终实现
```text
d827bfadb1fc0a7d768eefbf87b46ba26ac612d6
fix(GOV-007): 收紧 Schema 基线安全门禁
```
该提交已推送到 `origin/main`,实时远程查询结果与本地提交一致。
## 实现范围摘要
```text
30 files changed, 1835 insertions(+), 18 deletions(-)
```
最终索引为 879 节点、1062 关系、23 条流程。新增流程集中在 Schema
生成、校验、N/A 运行时一致性和发布门禁,不包含市场业务、HTTP、RabbitMQ
或生产数据库流程。
@@ -0,0 +1,26 @@
# GitNexus 开发前基线
- 功能编号:GOV-007
- 记录时间:2026年8月13日 GMT+8 10:58:35
- 分支:main
- 基线提交:0a69aa1d43f4
## 工作区
```text
(干净)
```
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/13/2026, 10:58:34 AM
Indexed commit: 0a69aa1
Current commit: 0a69aa1
Status: ✅ up-to-date
```
## 后续人工分析
在修改代码前,将 GitNexus query、context、impact 的结论写入 `gitnexus/impact-plan.md`。高风险结果必须先获得用户确认。
@@ -0,0 +1,18 @@
# GitNexus 前后对比
## 开发前
- 基线提交:`e552b979b61342b9e3a47d463f0b9a821b0ad95d`
- 索引:641 节点、671 关系、0 流程。
- 影响:现有治理档案函数总体 LOW,无数据库 Schema 执行流。
## 开发后
- N/A 基线提交:`2c502ebbec25e45ac2980c08ed288ace194b7a04`,已独立推送。
- 最终实现提交:`d827bfadb1fc0a7d768eefbf87b46ba26ac612d6`,已推送 `origin/main`。
- 索引:879 节点、1062 关系、23 条流程,状态 up-to-date。
- 最终修复变更检测为 HIGH,涉及 13 条 Schema 生成、验证与治理门禁流程。
## 结论
新增关系和流程全部来自 GOV-007 Schema 安全门禁及其测试,没有引入市场业务、HTTP、RabbitMQ 或页面流程。风险提升是因为 `schema:verify` 和 `governance:start` 属于关键开发路径;对应流程已用红绿测试、23 项 Schema 回归、远程实测和独立终审覆盖。
@@ -0,0 +1,25 @@
# GitNexus 暂存区变更检测
- 检测日期:2026-08-13
- 检测范围:最终实现提交前的 unstaged 修复
- 变更文件:3
- 变更符号:17
- 受影响流程:13
- GitNexus 风险:high(已按关键门禁完成专项验证)
## 受影响流程
变更集中在数据库 Schema 治理模块:
- Schema 生成、规范化与敏感/数据写入扫描。
- 清单、SHA-256 与目录文件集合验证。
- MySQL 5.7 双客户端、服务端和字符规则验证。
- 当前发布版本本地校验。
- N/A 基线与当前固定开发环境开关的一致性校验。
- 顶层数据修改/装载、疑似凭据、连接串和生产主机扫描。
- 已提交、已推送、远程分支和远程标签严格校验。
- CLI 生成/验证和 `governance:start` 入口。
## 风险解释
GitNexus 的 HIGH 结论来自安全扫描和 N/A 校验位于 13 条生成、验证及治理门禁流程,而非发现市场业务、生产数据库或跨服务回归。该风险已用 23 项 Schema 行为测试、既有 13 项治理回归测试、真实 Gitea `ls-remote` 校验和独立最终 Review 覆盖。最终 Review 无未关闭问题。
@@ -0,0 +1,32 @@
# GitNexus 开发前影响分析
- 分析日期:2026-08-13
- 基线提交:`e552b979b61342b9e3a47d463f0b9a821b0ad95d`
- 索引状态:up-to-date
## 查询范围
围绕 `governance start development gate feature record database schema baseline` 查询现有治理入口。GitNexus 未识别出业务执行流,相关定义集中在:
- `tools/governance/start.mjs`
- `tools/governance/finish.mjs`
- `tools/governance/feature-record.mjs`
- `tools/governance/feature-record.test.mjs`
- `package.json`
- 治理规范和 GOV-007 设计档案
## 符号影响
- `getFeatureDirectory`:LOW;3 个直接依赖,分别是 start、finish 和治理测试;0 个执行流、0 个跨模块影响。
- `validateFeatureId`:LOW;GitNexus 没有发现上游执行流,实际文本导入由 start、finish 和测试覆盖。
- `getRequiredFeatureFiles`:LOW;没有识别到执行流,完成门禁由现有自动化测试保护。
## 实施边界
本功能不修改上述已有公共函数语义。Schema 逻辑新增为独立模块,只让 `start.mjs` 调用一个只读的“当前已发布版本基线有效”入口。生成、规范化和写入由独立命令负责,因此不会让一般功能档案解析承担数据库职责。
## 风险结论
总体风险:LOW。
没有 HIGH 或 CRITICAL 结果,不需要额外中止确认。主要回归面是治理开始命令可能因缺少上一版本基线被有意阻断;通过 N/A 与真实 Schema 两类测试、既有治理回归测试和命令级验证覆盖。
@@ -0,0 +1,124 @@
# GOV-007 开发数据库 Schema 基线与版本门禁实施计划
> **执行要求:** 按测试驱动方式逐项实施;每个行为先观察失败,再写最小实现。实施期间不得连接、探测或读取任何数据库,真实导出入口仅通过固定样本和依赖注入验证。
**目标:** 建立只允许读取固定开发库、可确定性规范化和校验完整 MySQL 5.7 Schema,并在下一版本开发前强制验证上一已发布版本基线的治理门禁。
**架构:** `tools/database/schema-baseline.mjs` 集中维护安全配置、命令构造、SQL 规范化、产物生成及校验,避免将一条连续的安全流程过度拆分。`governance:start` 只调用“当前已发布版本基线是否存在且有效”的纯门禁,不负责静默生成或覆盖产物;生成基线必须先由独立命令完成、提交并推送。
**技术栈:** Node.js 22 LTS、Node 内置测试运行器、MySQL 5.7 `mysql`/`mysqldump` 客户端、SHA-256、GitNexus、Git/Gitea。
## 全局约束
- 数据来源只能是 `APP_ENV=development`、数据库 `a_share_analysis_dev`。
- MySQL 客户端与服务端只能是 5.7.x,字符集固定 `utf8mb4`,排序规则固定 `utf8mb4_general_ci`。
- 导出必须包含 `--no-data --routines --triggers --events`,密码不得出现在参数、日志、SQL 或清单中。
- 不接受环境类型、数据库名或 env 路径的命令行覆盖。
- 当前 MySQL 未启用,不运行真实数据库命令,只生成可验证的 `not_applicable` 清单,且不创建空 `schema.sql`。
- 已存在版本目录不得静默覆盖;真实 Schema 只含结构,不含任何数据。
- 修改关键符号前执行 GitNexus impact,提交前执行 GitNexus detect-changes。
---
### 任务 1:锁定安全边界和可观察契约
**文件:**
- 新建:`tools/database/schema-baseline.test.mjs`
- 新建:`tools/database/fixtures/mysql57-schema-input.sql`
- 新建:`tools/database/fixtures/mysql57-schema-expected.sql`
- 新建:`docs/features/GOV-007-development-schema-baseline/test-plan.md`
**接口:**
- 消费:设计规格中固定的环境、版本、Schema 范围和禁止覆盖规则。
- 产出:后续实现必须满足的公开函数行为和固定 SQL 输入/输出。
- [x] 编写配置测试,分别证明非 `development`、非 `a_share_analysis_dev`、非 MySQL 5.7、错误字符集和错误排序规则被拒绝。
- [x] 运行 `node --test tools/database/schema-baseline.test.mjs`,确认因实现模块不存在而失败。
- [x] 编写命令构造测试,手工断言参数包含 `--no-data`、`--routines`、`--triggers`、`--events`,且密码字符串不出现在参数中。
- [x] 编写固定 SQL 样本测试,手工断言时间注释、`DEFINER` 和表级当前自增值被删除,列级 `AUTO_INCREMENT` 以及表、视图、触发器、例程和事件定义完整保留。
- [x] 编写产物测试,证明清单和校验文件的 SHA-256 与 SQL 一致、不同内容的既有目录被拒绝、未启用 MySQL 时只有 `manifest.yaml` 而没有 `schema.sql`。
### 任务 2:实现纯函数和文件产物
**文件:**
- 新建:`tools/database/schema-baseline.mjs`
- 修改:`package.json`
**接口:**
- 产出:`assertSafeDevelopmentConfiguration(config)`、`assertMysql57Metadata(metadata)`、`buildMysqldumpArguments(config)`、`normalizeSchemaSql(sql)`、`buildCapturedArtifacts(metadata, sql)`、`buildNotApplicableArtifacts(metadata)`、`persistBaselineArtifacts(target, artifacts)`、`verifyBaselineDirectory(target, expectedRelease)`。
- [x] 实现最小配置与元数据校验,使安全边界测试通过。
- [x] 实现参数数组构造;连接密码只允许由子进程环境传递,不进入参数。
- [x] 实现确定性 SQL 规范化和敏感内容扫描,使固定样本逐字节匹配期望文件。
- [x] 实现 SHA-256、平面可审计清单、标准 checksum 文件和目录校验。
- [x] 采用同目录临时目录加原子改名写入;目标已存在时仅允许逐字节相同内容复用,其他情况报错。
- [x] 运行 Schema 测试,确认所有测试转绿;再运行既有治理、MySQL 与环境基线测试,确认没有回归。
### 任务 3:实现真实入口但不连接数据库
**文件:**
- 修改:`tools/database/schema-baseline.mjs`
- 修改:`package.json`
- 修改:`deploy/env/development/api.env.example`(仅在契约字段缺失时修改)
**接口:**
- 消费:固定路径 `deploy/env/development/api.env`;文件不存在且仓库模板明确 `MYSQL_ENABLED=false` 时允许生成不适用记录。
- 产出:`npm run schema:baseline` 与 `npm run schema:verify`,版本自动从最近语义化版本标签解析。
- [x] 测试命令行拒绝额外参数,证明不能传入 production env、数据库名或任意 env 路径。
- [x] 测试未启用 MySQL 的入口不会调用数据库执行器,并为最近发布标签创建可验证不适用记录。
- [x] 测试启用分支只构造固定 `mysql`/`mysqldump` 参数,并在客户端/服务端版本或数据库字符规则不符时阻断。
- [x] 实现固定配置加载、最近标签与标签提交解析、回环主机检查、mysql/mysqldump 双客户端和服务端元数据检查、真实导出执行路径;本次验证不调用该路径。
- [x] 运行 `npm run schema:baseline` 为 `v0.0.5` 生成 `not_applicable` 清单,并运行 `npm run schema:verify` 验证;确认不存在 `schema.sql`。
### 任务 4:接入版本开发前门禁与治理规范
**文件:**
- 修改:`tools/governance/start.mjs`
- 修改:`tools/governance/feature-record.test.mjs` 或新增对应集成测试。
- 修改:`AGENTS.md`
- 修改:`docs/governance/development-workflow.md`
- 修改:`docs/governance/code-development-standards.md`
- 修改:`README.md`
- 修改:`docs/index.md`
**接口:**
- 消费:`assertCurrentReleasedBaselinePublished(repositoryRoot)`。
- 产出:治理开始命令只有在上一已发布版本 Schema 基线有效时才继续 GitNexus 开发前流程。
- [x] 先写失败测试:基线缺失或失效时 `governance:start` 的前置检查拒绝继续,有效 N/A 或真实基线时允许继续。
- [x] 在 `start.mjs` 刷新 GitNexus 之前调用严格发布验证,检查 Git 跟踪、工作区、origin 分支和远程标签;不自动生成、不覆盖基线。
- [x] 文档明确顺序为“生成并验证基线 → 中文提交 → 推送 Gitea → 治理开始”,以及首次启用 MySQL 时必须从真实开发库导出。
- [x] 代码规范增加 Schema 仅结构、MySQL 5.7 完整对象范围、确定性规范化、禁止生产数据库和禁止直接改共享表的规则。
### 任务 5:验证、Review 与发布
**文件:**
- 新建或更新:GOV-007 完整功能档案。
- 修改:`VERSION`、`CHANGELOG.md`、`docs/index.md`。
**接口:**
- 产出:可追溯的 `v0.0.6` 治理版本。
- [x] 执行 Schema、治理、MySQL、环境测试,执行 `git diff --check`、敏感信息扫描和适用构建检查。
- [x] 执行 `npx gitnexus analyze` 与变更检测,保存开发前后差异和风险结论。
- [x] 完成代码 Review 与开发规范符合性 Review;两份报告必须包含独立一行 `最终结论:passed`。
- [x] 执行 `npm run governance:finish -- GOV-007 development-schema-baseline` 并保存证据。
- [x] 使用中文 Conventional Commit 提交并立即推送 `origin/main`,回填实现提交和远程 SHA。
- [x] 封存最终验证结果,提交并推送;创建带注释标签 `v0.0.6` 并只精确推送该标签。
## 计划自审
- 设计中的安全配置、完整对象范围、规范化、清单校验、禁止覆盖、未启用路径、治理门禁、双 Review 和发布要求均有对应任务。
- 所有实现接口在任务 2 明确定义,任务 3、4 只消费这些接口,没有命名漂移。
- 计划不包含待定项;真实数据库路径可实现但本次只以依赖注入和固定样本验证,符合禁止连接数据库的范围。
@@ -0,0 +1,18 @@
id: GOV-007
name: 开发数据库 Schema 基线与版本门禁
slug: development-schema-baseline
status: released
owner: project
created_at: 2026-08-13
prd: prd.md
requirements: requirements.md
design: design.md
implementation_plan: implementation-plan.md
test_plan: test-plan.md
gitnexus_before: gitnexus/before.md
gitnexus_after: gitnexus/after.md
gitnexus_comparison: gitnexus/comparison.md
code_review: review/code-review.md
standards_review: review/standards-review.md
implementation_commit: d827bfadb1fc0a7d768eefbf87b46ba26ac612d6
release: v0.0.6
@@ -0,0 +1,50 @@
# 开发数据库 Schema 基线与版本门禁 PRD
- 功能编号:GOV-007
- PRD 版本:0.1
- 状态:approved
- 日期:2026-08-13
## 问题
数据库迁移文件只能表达预期变化,不能证明每个版本开始前开发数据库的实际结构,也无法发现手工改表、对象遗漏或环境误连。当前 MySQL 尚未启用,还需要一种不伪造空 Schema 的可审计状态。
## 目标
- 每个新应用版本开发前,封存上一已发布版本的开发库完整 Schema。
- 将环境、数据库名、MySQL 版本、字符集、排序规则和对象范围设置为强制门禁。
- 生成确定性、可校验、可版本控制且不含数据或凭据的产物。
- MySQL 未启用时生成可验证的不适用记录。
- 在 `governance:start` 前阻断缺失或失效的上一版本基线。
## 用户流程
1. 开发者确认上一已发布语义化版本。
2. 执行 `npm run schema:baseline` 生成或幂等验证对应目录。
3. 执行 `npm run schema:verify` 复核清单、版本、提交和校验值。
4. 将基线用中文提交推送项目 Gitea。
5. 执行 `governance:start` 开始下一版本功能。
## 非目标
- 不备份任何业务数据、用户数据或生产数据。
- 不连接、探测、读取或验证生产数据库。
- 不替代生产运维备份、数据库恢复演练或迁移框架。
- 本版本不启动 MySQL,也不对真实数据库执行命令。
## 风险
- `DEFINER`、导出时间和当前自增值会造成不可移植或无意义差异。
- 参数可覆盖 env 或数据库名会扩大到生产资源的误操作范围。
- 空 SQL 或可篡改的 N/A 清单会让门禁形式化而不可信。
- 既有版本目录被覆盖会破坏发布历史。
## 验收标准
- 开发库、MySQL 5.7 和字符规则不符合时全部阻断。
- 导出参数明确只含结构并覆盖表、视图、触发器、例程和事件。
- 规范化固定样本精确保留业务对象和列自增属性。
- 真实基线三方 SHA-256 一致;N/A 基线只有清单。
- 版本、标签提交、对象范围、状态和文件集合都能自动校验。
- 既有不同内容禁止覆盖,命令行不能切换 production env 或数据库。
- 治理流程、双 Review、GitNexus、中文提交和 Gitea 推送完成。
@@ -0,0 +1,33 @@
# 测试结果
- 日期:2026-08-13
- 环境:本地开发仓库;未启动 MySQL,未连接任何数据库。
## 最新结果
- Schema 基线测试:23/23 passed。
- 治理测试:5/5 passed。
- MySQL 兼容基线:2/2 passed。
- 环境与部署基线:6/6 passed。
- `npm run schema:verify`:`v0.0.5 (not_applicable)` passed。
- 严格 `governance:start` smoke:基线未提交时按预期阻断;独立提交并推送后通过。
- `git ls-remote origin refs/heads/main` 与 `refs/tags/v0.0.5^{}`:远程 SHA 均按实时查询核对通过。
- `git diff --check`:passed。
- Node 语法检查:passed。
- `npm run governance:finish -- GOV-007 development-schema-baseline`:passed。
- 最终实现提交:`d827bfadb1fc0a7d768eefbf87b46ba26ac612d6`。
- `git ls-remote origin refs/heads/main`:与最终实现提交一致。
## 测试先行留痕
首次测试因模块不存在以 `ERR_MODULE_NOT_FOUND` 失败。实现期间失败测试先后捕获:MySQL 密码条件必填、标签提交核对、清单篡改、标准 5.7 视图 DEFINER、例程字符串误改、顶层/例程 DML 区分、双客户端版本、未跟踪基线、陈旧 tracking ref、普通与可执行注释 DML 绕过、N/A 与当前开关不一致、顶层数据修改/装载及敏感内容漏检。每项均在实现修复后转绿。
## 未执行项
当前 MySQL 功能开关为关闭,本功能范围明确禁止连接数据库,因此未执行真实 MySQL 5.7 导出。首次启用 MySQL 的版本必须在固定开发库补做真实集成验证。
## 人工完成项
- GitNexus HIGH 风险已核对,13 条受影响流程均属于 Schema 生成、验证和治理门禁。
- 视觉 QA 不适用,原因已单独留痕。
- 回退说明已核对;本版本未执行生产发布或数据库变更。
@@ -0,0 +1,5 @@
# 视觉 QA
本功能没有页面、组件、样式、图表或浏览器交互变化,视觉 QA 不适用。
结论:not_applicable
@@ -0,0 +1,13 @@
# 发布说明
## v0.0.6
- 实现开发数据库 Schema 基线生成与只读验证命令。
- 固定 MySQL 5.7、`a_share_analysis_dev`、`utf8mb4` 和 `utf8mb4_general_ci` 安全边界。
- 增加完整对象导出参数、确定性 SQL 规范化、SHA-256 三方校验和禁止覆盖机制。
- 为 MySQL 未启用状态建立不伪造空 SQL 的 `not_applicable` 基线。
- 将上一发布版本 Schema 基线验证接入开发前和开发后治理门禁。
- `governance:start` 仅接受已提交、已推送且远程标签一致的基线;真实导出限制在本机回环地址并分别校验 `mysql` 与 `mysqldump` 客户端版本。
- N/A 基线会实时核对当前开发环境 MySQL 开关;启用后必须改用真实 captured 基线。
- 扩展顶层数据操作、疑似凭据、数据库 URI、生产主机和导出噪声阻断。
- 最终实现提交:`d827bfadb1fc0a7d768eefbf87b46ba26ac612d6`。
@@ -0,0 +1,33 @@
# 工程需求
## 安全配置
- `APP_ENV` 必须为 `development`,`MYSQL_DATABASE` 必须为 `a_share_analysis_dev`。
- 字符集固定 `utf8mb4`,排序规则固定 `utf8mb4_general_ci`。
- 启用 MySQL 后 host、port、username、password 均为必填;密码只通过子进程环境传递。
- 启用 MySQL 时主机只能是本机回环地址;远程开发库必须先由运维建立本地 SSH 隧道,脚本不接受任意远程目标。
- 命令行不接受 env 文件、环境类型、数据库名或其他覆盖参数。
## 数据库与导出
- 客户端和服务端版本必须匹配 MySQL 5.7.x。
- 执行元数据查询的 `mysql` 客户端和执行导出的 `mysqldump` 客户端都必须分别验证为 5.7.x。
- `mysqldump` 使用 `--no-data --routines --triggers --events`,不得输出 INSERT 或 REPLACE。
- 完整对象范围为表、索引、外键、视图、触发器、存储过程、函数和事件。
- 规范化删除不稳定注释、环境 `DEFINER` 和表选项当前自增值,保留列自增属性。
## 产物与校验
- 目录固定为 `database/schema-baselines/<已发布版本>/`。
- 真实基线包含 `schema.sql`、`manifest.yaml`、`checksum.sha256`。
- `manifest.yaml` 使用 JSON 兼容 YAML 的结构化格式,可由标准 JSON 解析器读取。
- 清单记录版本、标签提交、来源环境、库名、版本、字符规则、对象范围、生成器和 SHA-256。
- 目录采用同父目录临时写入后原子改名;既有目录只允许逐字节相同的幂等重跑。
- MySQL 未启用时只生成 `manifest.yaml`,状态为 `not_applicable`,原因是 `mysql_disabled`,所有对象均为未捕获。
## 流程
- `governance:start` 在写入功能档案或刷新 GitNexus 前只读验证上一发布版本基线。
- `governance:start` 还要求基线文件已被 Git 跟踪、无未提交改动、当前分支已推送且远程发布标签提交一致;`schema:verify` 只负责本地内容校验。
- `governance:finish` 运行全部既有治理测试、Schema 测试和基线验证。
- 本版本实际产物为 `v0.0.5` 的 N/A 清单,不连接任何数据库。
@@ -0,0 +1,27 @@
# 代码 Review
## 第一轮
结论:changes_required。发现 5 个 Important 和 2 个 Minor:未提交基线可绕过门禁、远程生产主机可被误连、标准 MySQL 5.7 视图 DEFINER 不兼容、顶层 DML 扫描绕过/例程误拒、未校验 mysql 客户端、N/A 清单字段不严和缺少严格门禁测试。
处置:全部补失败测试并修复。增加回环主机、双客户端、结构化清单、Git 跟踪与远程同步验证。
## 第二轮
结论:changes_required。发现普通/版本注释可绕过顶层 DML 扫描,远程分支校验依赖可能陈旧的 tracking ref。
处置:按真实分隔符解析顶层语句,剥离前置普通注释但扫描 MySQL 可执行注释;远程分支改为实时 `git ls-remote origin refs/heads/<branch>`,并增加回归测试。
## 最终复审
- 普通注释、版本 SET 注释、MySQL 可执行注释中的顶层 INSERT/REPLACE 均被拒绝。
- 顶层 UPDATE、DELETE、TRUNCATE、LOAD DATA/XML 均被拒绝,例程内部合法 DML 保留。
- MySQL dump 残留头、疑似密码/Token/Secret、数据库 URI 和生产主机注释均被拒绝。
- N/A 基线每次重读固定开发环境配置,MySQL 启用后旧 N/A 清单立即失效。
- 例程内合法 DML 保留,标准 MySQL 5.7 视图 DEFINER 输出可规范化。
- 远程分支使用实时 `git ls-remote`,远程标签提交与清单提交核对。
- 23 项 Schema 测试、治理/数据库/环境回归测试均通过。
问题处置:多轮 Review 的所有 Critical/Important/Minor 问题均已关闭并有回归测试;独立终审无新增问题,未保留延期问题。
最终结论:passed
@@ -0,0 +1,20 @@
# 开发规范符合性 Review
## 检查范围
- PRD、需求、确认设计、实施计划、测试计划、GitNexus 前后报告齐全。
- 关键安全边界、规范化取舍、原子写入和远程门禁有中文原因注释。
- 主要业务流程集中在一个可连续阅读的模块,没有过度拆分。
- 测试遵循先失败后实现,固定样本和期望值独立维护。
- MySQL 5.7、`utf8mb4`、`utf8mb4_general_ci` 和开发库限制符合规范。
- 未写入密码、Token、真实 env、生产地址或生产数据。
- `v0.0.5` N/A 基线已作为独立中文提交推送 Gitea。
- 视觉变化不适用,已记录原因。
## 复审结果
- 最终代码复审已通过,Critical/Important/Minor 均为零;历史问题全部关闭并有测试证据。
- `governance:finish` 将在发布前重新执行全部治理、Schema 和 GitNexus 门禁。
- 最终实现提交 `d827bfadb1fc0a7d768eefbf87b46ba26ac612d6` 已推送 Gitea;封存提交和 `v0.0.6` 标签按发布步骤执行。
最终结论:passed
@@ -0,0 +1,12 @@
# 回退说明
本功能没有连接数据库、执行迁移或修改任何开发/生产数据。回退应用代码时可以恢复上一提交中的治理脚本和文档,但不得删除或改写已经随版本发布的 `database/schema-baselines/` 历史事实。
若工具实现存在缺陷,使用新的中文修复提交:
1. 保留原版本基线目录和 Git 历史。
2. 在新的治理档案中记录错误原因、影响范围和修复策略。
3. 对尚未发布的错误产物可在审查后修正;已发布产物通过追加更正记录处理,不移动共享标签。
4. 首次启用 MySQL 后,任何修复都只允许读取开发库,生产数据库仍属于禁止范围。
N/A 清单没有 Schema 或数据可恢复。`v0.0.5` 目录证明当时 MySQL 功能开关关闭,不能在未来启用 MySQL 后追溯改写为真实 Schema。
@@ -0,0 +1,32 @@
# 测试计划
## 测试先行证据
- 首次执行 `node --test tools/database/schema-baseline.test.mjs` 因生产模块不存在而失败,错误为 `ERR_MODULE_NOT_FOUND`。
- 首轮实现后固定样本和清单嵌套字段测试暴露规范化与解析缺口,修正后转绿。
- 安全自审再以失败测试发现密码未设为条件必填、标签提交未核对、真实清单版本可篡改和 N/A 对象范围可伪造,均已实现对应阻断。
## 自动化范围
- 配置:环境、库名、字符集、排序规则、启用后的必填凭据。
- 版本:MySQL 客户端、服务端和发布标签提交。
- 命令:完整结构参数、密码不进参数、额外参数拒绝。
- SQL:时间注释、`DEFINER`、表级自增值、列自增属性和五类对象。
- 产物:SHA-256、精确文件集合、禁止覆盖、篡改检测、空 SQL 拒绝。
- N/A:零数据库调用、只有清单、明确关闭版本和对象范围。
- 回归:治理测试、MySQL 基线测试、环境基线测试、Schema 验证。
- 严格发布门禁:未跟踪基线、未提交改动、未推送分支或远程标签不一致均阻断;本地 `schema:verify` 与发布前 `governance:start` 的职责分别验证。
## 最终命令
```bash
npm run test:governance
npm run test:mysql-baseline
npm run test:environment-baseline
npm run test:schema-baseline
npm run schema:verify
npm run governance:finish -- GOV-007 development-schema-baseline
git diff --check
```
本功能无 Web 页面、CSS 或图表变化,视觉 QA 记录为不适用。
@@ -0,0 +1,45 @@
# RocketMQ 消息队列架构调整设计
- 功能编号:GOV-008
- 设计版本:0.1
- 状态:approved
- 日期:2026-08-13
## 架构
```text
Scheduler
-> MessageBusAdapter.publish()
-> RocketMQ 5.x Proxy 或受支持客户端
-> NameServer / Broker
-> MessageBusAdapter.consume()
-> Worker
-> Redis 当前状态 + MySQL 事实记录
```
`MessageBusAdapter` 是稳定边界。业务消息、Topic 和 Group 不引用 RocketMQ SDK 类型,未来客户端实现变化不要求重写调度与分析逻辑。项目只维护 RocketMQ 一套实现,不同时维护 RabbitMQ 兼容层。
## 接入模式
推荐 Node.js 通过 RocketMQ 5.x Proxy 接入,以降低对旧 Remoting 客户端实现的依赖。若后续选定的 Node 客户端直接连接 NameServer/Broker,必须先验证客户端维护状态、RocketMQ 5.3.2 兼容性、重试语义和优雅关闭,再通过 Adapter 接入。
`ROCKETMQ_NAMESRV_ADDR` 用于基础设施发现和诊断,`ROCKETMQ_ENDPOINT` 是应用客户端实际接入地址。两者不得混为同一项:只有 NameServer 端口可达时,不能完成生产或消费。
## Topic 与 Group
- Topic 前缀固定为 `a-share-analysis`,实际 Topic 按业务域追加,例如行情采集或指标计算。
- Tag 使用稳定事件类型,不用临时任务 ID。
- RocketMQ 5.x Proxy Producer 不配置 Producer Group;Worker 按独立消费语义使用 Consumer Group。
- 环境隔离通过受控前缀或独立集群完成,禁止开发消费者读取生产 Topic。
## 可靠性
RocketMQ 提供至少一次投递语义,Worker 必须幂等。消息处理完成并形成可验证结果后才能确认;可重试错误返回重试,永久错误记录原因后进入死信。顺序消息只在明确消息组键内保证,不假设跨证券或跨交易日全局顺序。
最大投递次数是 Consumer Group 的服务端重试策略,由 RocketMQ 运维配置和发布检查负责。应用客户端只声明 Consumer Group、并发与处理结果,不能用一个不会被官方 Node SDK读取的 env 字段假装控制死信边界。
## 本地状态
2026-08-13 首次检查到 `apache/rocketmq:5.3.2` 的 `rmqnamesrv` 容器曾运行并映射 `9876:9876`,日志为 NameServer boot success;随后串行复核发现该容器已以 137 退出且未配置自动重启,`OOMKilled=false`。
宿主机 `9876` 实际由 `/usr/local/rocketmq` 的原生 NameServer 监听,同时存在 `mqbroker --enable-proxy`。只读 `mqadmin` 验证结果:`broker-a` 已注册,版本 `V5_3_2`、`brokerActive=true`,Broker 地址 `192.168.2.37:10911`;本机 `10911`、Proxy `8081` 和 NameServer `9876` 均可达,Topic 列表可读取。当前可确认 RocketMQ 基础设施和管理链路连通,但尚未通过项目 Node 客户端执行消息收发。
@@ -0,0 +1,22 @@
# GitNexus 开发后基线
## 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/13/2026, 2:23:20 PM
Indexed commit: f5994ad
Current commit: f5994ad
Status: ✅ up-to-date
```
## 图谱规模
- 958 个节点。
- 1141 条关系。
- 13 个聚类。
- 23 条流程。
本次新增内容以文档、环境模板和契约测试为主,没有新增 MQ 运行时代码或执行流。
最终实现提交 `f5994ad77ec980175f671475e82c72d9d7e6f979` 已推送 `origin/main`,实时远程 SHA 核对一致。
@@ -0,0 +1,26 @@
# GitNexus 开发前基线
- 功能编号:GOV-008
- 记录时间:2026年8月13日 GMT+8 13:59:16
- 分支:main
- 基线提交:3cc00de8f65e
## 工作区
```text
(干净)
```
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/13/2026, 1:59:15 PM
Indexed commit: 3cc00de
Current commit: 3cc00de
Status: ✅ up-to-date
```
## 后续人工分析
在修改代码前,将 GitNexus query、context、impact 的结论写入 `gitnexus/impact-plan.md`。高风险结果必须先获得用户确认。
@@ -0,0 +1,14 @@
# GitNexus 前后对比
## 开发前
- 基线提交:`3cc00de`
- RabbitMQ 仅存在于文档、模板和契约测试,没有运行时代码或执行流。
## 开发后
- 当前活动架构统一为 RocketMQ 5.x。
- 新增 MessageBusAdapter、Topic/Tag/Group、重试、死信、幂等和顺序键约束。
- GitNexus 变更检测为 LOW,0 条执行流受影响。
结论:调整发生在实现客户端之前,避免了双栈迁移;后续真实风险集中在 Node 客户端与 RocketMQ 5.3.2 的契约验证。
@@ -0,0 +1,10 @@
# GitNexus 变更检测
- 检测日期:2026-08-13
- 范围:unstaged
- 变更文件:16 个已跟踪文件,另含 GOV-008 功能档案与 ADR 新文件。
- 变更符号:35
- 受影响流程:0
- 风险:LOW
变更集中在当前架构、环境模板、部署说明、代码规范和环境契约测试。GitNexus 未发现市场业务、数据库、HTTP 或消息运行流程受影响,因为 Server 和 MQ 客户端尚未实现。
@@ -0,0 +1,13 @@
# GitNexus 开发前影响分析
- 分析日期:2026-08-13
- 基线提交:`3cc00de`
- 索引状态:up-to-date
查询 RabbitMQ、消息队列、Scheduler、Worker 和部署配置。当前仓库没有 Server 生产代码或 MQ 执行流,影响集中在系统架构、代码开发规范、环境模板、部署文档和环境契约测试。
- `environment-baseline.test.mjs`:LOW,无上游调用方或业务流程。
- `system-architecture.md`:LOW,直接引用方为 README 与文档索引。
- `code-development-standards.md`:LOW,直接引用方为 README 与文档索引。
结论:不影响市场业务、数据库或 HTTP 运行流程。主要风险是环境键漂移和把 NameServer 可达误判为消息链路可用,分别由契约测试和分层连接证据控制。
@@ -0,0 +1,13 @@
# GOV-008 实施计划
- [x] 封存并推送 `v0.0.6` 开发库 N/A Schema 基线。
- [x] 执行 `governance:start` 与 GitNexus 开发前探索和影响分析。
- [x] 先修改环境契约测试,确认旧 RabbitMQ 配置使测试失败。
- [x] 将 Scheduler/Worker 开发和生产模板改为 `ROCKETMQ_*`。
- [x] 更新系统架构、代码开发规范、部署文档和未发布市场概览 PRD。
- [x] 补齐 GOV-008 功能档案和本机连接验证证据。
- [x] 运行治理、MySQL、环境、Schema 测试和配置/文档检查。
- [x] 执行 GitNexus 变更检测、代码 Review 与规范 Review。
- [x] 执行 `governance:finish`,中文提交并推送 Gitea。
本版本不实现客户端、不创建 Broker/Proxy、不发送测试消息。后续 Server 脚手架功能负责选型 Node 客户端并完成真实 Topic 收发契约测试。
@@ -0,0 +1,18 @@
id: GOV-008
name: RocketMQ 消息队列架构调整
slug: rocketmq-adoption
status: released
owner: project
created_at: 2026-08-13
prd: prd.md
requirements: requirements.md
design: design.md
implementation_plan: implementation-plan.md
test_plan: test-plan.md
gitnexus_before: gitnexus/before.md
gitnexus_after: gitnexus/after.md
gitnexus_comparison: gitnexus/comparison.md
code_review: review/code-review.md
standards_review: review/standards-review.md
implementation_commit: f5994ad77ec980175f671475e82c72d9d7e6f979
release: v0.0.7
@@ -0,0 +1,33 @@
# RocketMQ 消息队列架构调整 PRD
- 功能编号:GOV-008
- PRD 版本:0.1
- 状态:approved
- 日期:2026-08-13
## 问题
项目早期约定 RabbitMQ,但尚未实现消息客户端或业务消息链路。现决定统一采用 RocketMQ,并需要在服务脚手架落地前同步架构、环境契约和部署边界,避免后续同时维护两套消息模型。
## 目标
- 项目唯一消息队列调整为 RocketMQ 5.x。
- Scheduler 和 Worker 通过 `MessageBusAdapter` 使用版本化消息契约。
- 配置明确区分 NameServer、Broker/Proxy Endpoint、Topic 和 Group。
- 保留本地默认关闭策略,同时允许连接独立运行的本机 RocketMQ。
- 检查当前本机 Docker RocketMQ 的实际连通状态,不夸大验证范围。
## 非目标
- 本版本不实现 Server、Scheduler、Worker 或 RocketMQ Node 客户端。
- 不替用户创建、删除或重启 Docker 或本机 RocketMQ 进程。
- 不连接生产 RocketMQ,不创建生产 Topic 或 Group。
- NameServer 可达时不宣称消息生产和消费已经可用。
## 验收标准
- 当前架构、开发规范、部署说明和环境模板只采用 RocketMQ。
- Scheduler 与 Worker 开发/生产模板键集合分别一致,且无 RabbitMQ 变量。
- 文档定义重复投递、幂等、重试、死信和顺序消息边界。
- 本机 NameServer 的版本、端口和启动状态有可复核证据。
- 诊断必须区分 Docker 容器与本机原生进程,并报告 NameServer、Broker、Proxy 的真实状态。
@@ -0,0 +1,19 @@
# 测试结果
- 日期:2026-08-13
- 状态:passed
测试先行阶段,环境契约测试按预期因缺少 `ROCKETMQ_*` 和活动文档仍包含 RabbitMQ 而失败。实现后结果:
- 治理测试:5/5 passed。
- MySQL 5.7 基线测试:2/2 passed。
- 环境与部署契约测试:7/7 passed。
- Schema 基线测试:23/23 passed。
- `npm run schema:verify`:`v0.0.6 (not_applicable)` passed。
- `git diff --check` 与 Node 语法检查:passed。
- 活动架构、部署、治理规范与环境模板 RabbitMQ 残留扫描:passed。
- `npm run governance:finish -- GOV-008 rocketmq-adoption`:passed。
- 独立代码 Review 与开发规范 Review:passed。
- 最终实现提交:`f5994ad77ec980175f671475e82c72d9d7e6f979`,已推送 `origin/main`。
本机诊断确认:Docker `rmqnamesrv` 容器曾启动成功但现已以 137 退出,且非 OOM;宿主机原生 RocketMQ 5.3.2 正在运行 NameServer、`broker-a` 和 Proxy。`9876`、`10911`、`8081` 可达,`mqadmin` 可读取集群、Topic 和 Broker 状态。项目 Node 客户端尚未实现,因此未创建 Topic 或写入测试消息。
@@ -0,0 +1,5 @@
# 视觉 QA
本功能没有页面、组件、样式或浏览器交互变化,视觉 QA 不适用。
结论:not_applicable
@@ -0,0 +1,7 @@
# 发布说明
- 项目消息队列技术基线由 RabbitMQ 调整为 RocketMQ 5.x。
- Scheduler 和 Worker 配置切换为 `ROCKETMQ_*`,并明确 Topic、Group、重试和接入地址。
- 增加 `MessageBusAdapter` 边界,避免业务绑定具体客户端。
- 本机原生 RocketMQ 5.3.2 NameServer、Broker 和 Proxy 已验证可达,Broker 已注册且状态正常;Docker `rmqnamesrv` 容器已退出,项目消息收发待 Node 客户端落地后验证。
- 最终实现提交:`f5994ad77ec980175f671475e82c72d9d7e6f979`。
@@ -0,0 +1,29 @@
# 工程需求
## 技术基线
- MQ 固定为 RocketMQ 5.x,当前本机镜像版本为 `apache/rocketmq:5.3.2`。
- 业务模块只依赖 `MessageBusAdapter` 与版本化事件,不直接引用客户端 SDK 类型。
- Scheduler 只发布任务,Worker 只消费执行;重复投递由幂等键和业务唯一约束处理。
## 配置契约
- Scheduler 使用 `ROCKETMQ_ENABLED`、`ROCKETMQ_NAMESRV_ADDR`、`ROCKETMQ_ENDPOINT`、`ROCKETMQ_TOPIC_PREFIX` 和发送超时。RocketMQ 5.x Proxy 官方 Node Producer 不要求 Producer Group,禁止把旧 Remoting 参数混入配置。
- Worker 使用相同的基础连接字段,并增加 `ROCKETMQ_CONSUMER_GROUP` 和客户端消费并发。
- 开发和生产模板的同一进程必须保持相同键集合;生产连接地址留空且不得提交真实值。
- `ROCKETMQ_ENABLED=false` 时不建立连接;启用后 Endpoint、Topic 和对应 Group 必须通过启动配置 Schema 校验。
## 消息语义
- 事件必须包含 `eventId`、`eventType`、`schemaVersion`、`occurredAt`、`tradeDate`、`traceId` 和 `idempotencyKey`。
- Topic 表达稳定业务域,Tag 表达事件类型,Consumer Group 表达独立消费进度。
- 需要顺序处理时必须声明消息组键;普通消息不保证全局顺序。
- 超过最大消费次数后进入死信,必须支持查询、告警和受控重放。
- 最大投递次数属于 RocketMQ 服务端 Consumer Group 重试策略,由运维配置并纳入部署验收,不作为官方 Node PushConsumer 的客户端环境变量。
## 本机验证
- 检查容器、镜像、端口映射和 NameServer 启动日志。
- 使用 TCP 探针验证 `127.0.0.1:9876`。
- 检查 Docker 容器和本机原生进程,避免把相同端口的其他监听者误判为目标容器。
- 通过 `mqadmin clusterList`、`topicList`、`brokerStatus` 确认 Broker 注册、版本和管理链路;不擅自创建 Topic 或写入测试消息。
@@ -0,0 +1,22 @@
# 代码 Review
## 第一轮
结论:changes_required。发现 2 个 Important:配置混入旧 Remoting Producer Group 和无效的客户端最大重试字段;RabbitMQ 残留断言只覆盖生产 Worker。
## 处置
- 删除 `ROCKETMQ_PRODUCER_GROUP` 和 `ROCKETMQ_MAX_RECONSUME_TIMES`。
- 明确最大投递次数属于服务端 Consumer Group 运维策略。
- 扩展测试覆盖 Scheduler/Worker 的开发与生产四份模板,同时核对开发和生产连接地址边界。
## 最终复审
- 四份 Scheduler/Worker 模板均移除旧 RabbitMQ 字段、旧 Remoting Producer Group 和无效的客户端最大重试字段。
- 开发模板统一使用 `127.0.0.1:9876` 和 `127.0.0.1:8081` 且保持关闭;生产连接地址保持空值。
- 最大投递次数归属服务端 Consumer Group 运维策略,文档和配置语义一致。
- 环境 7/7、治理 5/5、MySQL 2/2、Schema 23/23 及 Schema 验证通过。
Critical、Important、Minor 均无未关闭项。
最终结论:passed
@@ -0,0 +1,12 @@
# 开发规范符合性 Review
## 检查结果
- PRD、需求、设计、实施计划、测试计划、回退和 GitNexus 档案齐全。
- 技术基线统一为 RocketMQ 5.x,历史档案保留原版本事实。
- 配置模板无秘密,开发与生产同进程键集合一致,生产连接地址为空。
- Node.js 接入边界明确采用 MessageBusAdapter,未提前绑定未经验证的 SDK 参数。
- 本机诊断只读执行,未创建 Topic、未发送消息、未修改或重启用户进程。
- 测试先行、GitNexus 影响分析和独立复审证据齐全。
最终结论:passed
@@ -0,0 +1,7 @@
# 回退说明
本功能只修改架构约定、无秘密环境模板、文档和契约测试,没有启动、停止或修改用户的 Docker 容器,也没有连接生产服务。
若后续 RocketMQ 客户端验证失败,使用新的治理功能和中文提交调整 Adapter 实现或接入方式;不得在业务代码中临时绕过 Adapter。回退文档配置时可以恢复上一已发布提交,但必须同步恢复开发/生产模板和契约测试,禁止形成一半 RabbitMQ、一半 RocketMQ 的混合状态。
本机 `rmqnamesrv` 容器及其 Docker 网络属于用户环境,不由仓库回退操作管理。
@@ -0,0 +1,19 @@
# 测试计划
## 自动化
- 开发和生产同进程环境键一致。
- 生产模板禁止模拟数据并保持 MySQL 5.7 与 RocketMQ 开关契约。
- 活动架构和部署文档包含 RocketMQ 且不再包含 RabbitMQ。
- 本地 Compose 仍只启动 Redis,不隐式增加 RocketMQ 生命周期。
- 治理、MySQL 5.7、Schema 基线回归测试全部通过。
## 本机诊断
- `docker ps` 与本机进程检查 NameServer、Broker、Proxy,定位端口真实监听者。
- `docker inspect rmqnamesrv` 核对镜像与端口映射。
- `docker logs rmqnamesrv` 核对启动成功日志。
- `nc` 检查 `9876`、`10911` 和 `8081` TCP 可达。
- `mqadmin clusterList`、`topicList`、`brokerStatus` 检查 Broker 注册、Topic 路由与运行状态。
基础设施管理链路已验证。由于项目 Server 与 Node 客户端尚未实现,本版本不创建测试 Topic,也不执行项目消息生产和消费,并将此限制记录为未执行项。
@@ -0,0 +1,61 @@
# 前后端项目架构复核与论证
- 复核基线:`95b8611bd9bbc282193591e472e2e19c617e5035`
- 状态:实现已验证,用户于 2026-08-17 确认当前架构
## 实际落地结构
```text
repository
├── web/ Vue 3 独立工程
│ └── src/
│ ├── app/ 应用装配、路由和根视图
│ ├── api/generated/ OpenAPI 自动生成类型
│ ├── api/adapters/ 面向页面的稳定数据适配
│ └── styles/ Sass 全局样式与后续 token 入口
├── server/ NestJS 独立工程
│ ├── apps/api/ HTTP 与 OpenAPI 入口
│ ├── apps/scheduler/ 只负责任务触发的无 HTTP 进程
│ ├── apps/worker/ 任务执行的无 HTTP 进程
│ └── libs/
│ ├── config/ 三进程最小权限配置契约
│ ├── http-contracts/ Server DTO
│ ├── message-contracts/ Server 内部 RocketMQ 信封
│ └── infrastructure/ Redis、MySQL、消息与生命周期适配
├── deploy/ systemd、Nginx、env 源码部署模板
└── tools/ 治理、Schema、契约、边界和部署验证
```
## 为什么当前拆分合适
1. **前后端工程分开,但仓库不割裂。** Web 和 Server 有各自 package、构建与类型检查,责任清楚;根 workspace 只做质量编排。个人开发阶段仍能一次安装和验证,避免维护多个仓库与跨仓库版本同步。
2. **不建立根共享 contracts 包。** HTTP 只有一个事实源:Server DTO 生成 OpenAPI,Web 再生成自己的类型。Web 无法直接引用 Server 源码,`.vue` 和 TypeScript 都有自动边界检查。这样比手工同步两份类型或共享内部类更明确。
3. **一个 Server 工程、三个进程入口。** API、Scheduler、Worker 使用相同基础设施与消息契约,但启动、配置和部署彼此独立。当前规模下没有必要拆成三个仓库或三个重复 Nest 工程;未来可独立扩容进程而不复制公共代码。
4. **配置是进程级最小权限。** API 不读取任务消费配置,Scheduler 不读取 MySQL/AI 密钥,Worker 不读取 API 端口。配置先校验和冻结,再通过动态模块注入,测试与生产使用同一装配路径。
5. **基础设施通过 Adapter 隔离。** 业务代码将依赖 MessageBus、Repository 和数据源端口;RocketMQ 客户端尚未验证时明确禁用,避免以临时内存队列形成错误语义。
6. **生产只有一条源码路径。** Ubuntu 源码部署直接使用 Web dist 与三个 Server dist 入口,由 systemd 和 Nginx 管理;源码发布门禁验证这些路径一致,避免维护第二套构建和运行语义。
## 适合下一阶段的扩展方式
- Web 市场概览应建立一个可连续阅读的 `features/market-overview/` 业务目录,内部按页面、数据适配和状态拆分;短线与中长线作为市场概览下的模式,不拆成两个独立应用。
- Server 在 API/Scheduler/Worker 各入口内注册同一市场概览业务能力的不同适配面;共享领域模型和规则计算放入稳定业务库,HTTP DTO、消息 DTO 与数据库实体继续分离。
- 用户体系、订阅和权限暂不加入当前业务模型;未来通过独立功能档案增加,不让其反向污染市场概览核心。
- 当某个业务域出现独立发布节奏、团队所有权或明显扩容边界时,再论证拆包或拆服务;当前提前微服务化只会增加契约、部署和运维成本。
## 已知限制
- 当前 Web 只是工程外壳,没有市场概览 UI、行情图表和分析工作台。
- RocketMQ 只有契约和禁用 Adapter,尚未选择并验证 Node 客户端。
- TypeORM 已固定安全选项,但尚无业务实体和迁移。
- 用户体系和订阅能力按用户决定后置,不在 GOV-009 范围。
- 仅源码部署调整已实现;历史 Docker 验证只作为决策追溯,不再代表当前可用能力。
## 复核结论
现有架构适合“先做市场概览、个人使用为主、未来可扩展订阅”的阶段:边界清晰、运行方式简单、契约可自动校验,也保留 API/Scheduler/Worker 独立扩容路径。它不是不可变终局;完成市场概览真实业务后,仍应根据模块依赖和运行数据再次复核,而不是凭脚手架预判过度拆分。
## 架构确认记录
用户已于 2026-08-17 完成最终确认,同意以本文描述的实际结构作为当前业务开发基线:Vue 3 与 NestJS 工程分离维护,Server 保持 API、Scheduler、Worker 三进程,HTTP 契约沿 Server DTO → OpenAPI → Web 类型单向发布,生产交付仅支持 Ubuntu 源码部署。该确认满足 GOV-009 的最终完成门禁,GOV-009 与 GOV-010 一并归入 `v0.0.8`。
确认不代表架构永久冻结。市场概览全部业务完成后,仍需依据实际模块依赖、运行负载和维护成本再次论证;在此之前不得仅凭预期拆分微服务或共享契约包。
@@ -0,0 +1,113 @@
# 应用工程脚手架基线设计
- 功能编号:GOV-009
- 设计版本:0.1
- 状态:review
- 日期:2026-08-13
## 总体结构
```text
repository
├── web/ Vue 3 独立前端工程
│ ├── src/api/generated/ OpenAPI 生成的类型与客户端
│ ├── src/api/adapters/ DTO 到页面模型的转换
│ ├── src/app/ 路由、状态和应用外壳
│ └── tests/ 组件与浏览器测试
├── server/ NestJS 独立后端工程
│ ├── apps/api/ HTTP 与 OpenAPI 入口
│ ├── apps/scheduler/ 定时触发入口
│ ├── apps/worker/ 任务执行入口
│ └── libs/
│ ├── config/ 进程级配置解析与脱敏
│ ├── http-contracts/ DTO 与 OpenAPI 模型
│ ├── message-contracts/ Server 内部 RocketMQ 事件
│ ├── domain/ 后端业务模型与端口
│ └── infrastructure/ Redis、MySQL、消息适配器
├── deploy/ 环境和部署契约
└── tools/ 治理、Schema 与生成校验
```
根目录只负责编排命令和版本约束,不承载业务运行代码。Web 与 Server 各自拥有依赖、TypeScript 配置和构建产物,可以独立部署;pnpm workspace 只用于一致安装和根命令调度。
## 契约方向
```text
Server DTO + Controller metadata
│
▼
openapi.json
│
▼
Web generated client ──> Web adapter ──> Page model
Scheduler ──> Server message contract ──> Worker
```
HTTP 契约由 Server 单向发布,Web 不导入任何 Server TypeScript 源码。生成客户端只负责传输类型和请求,页面通过 adapter 转换为适合展示的模型,避免后端字段调整直接渗透整个界面。
Server 使用 `@nestjs/swagger` 从 DTO 和 Controller 元数据生成 `openapi.json`;Web 使用 `openapi-typescript` 生成类型,并由 `openapi-fetch` 提供轻量请求客户端。生成过程固定输入与输出路径,检查命令重新生成后要求 Git 无差异,从而发现契约漂移。
RocketMQ 消息契约属于 Server 的进程间协议,只由 Scheduler 与 Worker 使用。数据库实体不会作为 HTTP DTO 或消息载荷直接暴露,避免持久化结构成为跨边界契约。
## Server 进程边界
- API 读取 API、Redis、MySQL 和可选 AI 配置,提供 HTTP 与 OpenAPI。
- Scheduler 读取调度、Redis 和可选 RocketMQ 发送配置,只负责触发任务。
- Worker 读取数据源、Redis、MySQL、可选 RocketMQ 消费和可选 AI 配置,负责执行任务。
- 三个入口复用配置解析和基础设施 adapter,但分别建立 Nest 应用上下文,互不隐式启动。
初始版本的 RocketMQ adapter 只定义接口和明确的 disabled 行为。项目不会选择名称可疑、维护状态不明或不兼容 RocketMQ 5.x Proxy 的 npm 包;真实收发将在客户端验证功能中通过测试 Topic 完成后启用。
## 配置加载
本地启动固定读取 `deploy/env/development/<process>.env.local`;生产运行只依靠 systemd `EnvironmentFile` 注入,不从源码目录寻找生产 env。配置解析采用白名单 Schema,未知键可以保留给其他进程,但当前进程只解析最小集合。
敏感值只用于建立连接,错误对象和日志使用键名而不输出实际值。Web 构建只加载 `web.env.local` 中的 `VITE_` 变量。
## 数据库基线
Schema 工具优先读取 `api.env.local`,不存在时才退回 `api.env.example`。开发数据库主机允许回环地址和代码内固定白名单 `112.192.20.11`,不能由命令行临时追加。其余环境、库名、版本、字符集和排序规则继续严格校验。
当前远程开发库为空。空库仍然是“已启用且已检查”的事实,不应标记为 MySQL 未启用。生成器将保存 format v2 的 `captured_empty` 结构化清单,其中 `object_counts` 全部为零、客户端和服务端版本真实可验证,并对规范化的空结构计算确定性摘要;不创建空 `schema.sql`。验证器继续只读兼容既有 format v1 清单,禁止借格式升级重写历史目录。首次迁移产生对象后,下一发布版本开始生成完整 captured 基线。
Server 数据访问使用 Nest 官方 `@nestjs/typeorm` 集成、TypeORM 和 `mysql2` 驱动。迁移是结构变更的唯一入口,应用启动禁止 `synchronize: true`;Repository 只能通过领域端口进入业务逻辑,不能把 TypeORM 实体直接暴露为 HTTP 或消息契约。
## 错误处理
- Node/pnpm 版本错误在安装或根校验命令开始时失败。
- 必填配置缺失、MySQL 版本错误或字符规则错误时,相应 Server 进程拒绝启动。
- Redis/MySQL 健康检查失败返回不可用状态,但不泄漏目标密码。
- RocketMQ 关闭时报告 disabled;打开但无已验证 adapter 时启动失败,禁止静默退回内存队列。
- OpenAPI 生成文件与 Server 定义不一致时 CI/本地检查失败。
## 测试策略
- 配置 Schema、消息信封、Schema 主机白名单和空库产物使用 Node/Vitest 单元测试。
- API 使用 Nest 测试工具验证健康检查和 OpenAPI。
- Web 使用 Vitest 验证启动外壳和生成客户端边界。
- Playwright 验证 Web 能启动、路由可访问且无阻断错误;GOV-009 不进行业务页面视觉设计。
- 使用真实 Redis 和固定开发 MySQL 执行只读冒烟;RocketMQ 只验证禁用态和既有管理链路,不宣称 Node 消息收发通过。
- Web 与三个 Server 入口执行真实构建验证;源码发布门禁同时核对 systemd 和 Nginx 模板。
- E2E 在启动 API 前只读检查现有本机 Redis;不可达时明确失败,不启动替代基础设施。
## 安全策略与评估
- 配置按 API、Scheduler、Worker 最小权限拆分,生产只由 systemd `EnvironmentFile` 注入;Web 只允许公开的 `VITE_` 变量进入构建产物。
- Schema 工具硬编码开发环境、固定库名和主机白名单,密码只通过子进程环境传递;本功能禁止连接、探测或读取生产数据库。
- Redis/MySQL 健康检查和启动错误只返回脱敏状态;RocketMQ 未验证时明确禁用,不以进程内队列伪降级。
- OpenAPI 契约、Web/Server 源码边界和消息契约隔离由自动门禁验证。残余风险是 RocketMQ Node 客户端和真实行情数据源尚未接入,必须在各自功能中重新做依赖与安全评估。
## 性能目标与评估
- 脚手架目标是保持 Web 和三个 Server 进程可独立构建、启动和扩容;根 workspace 只编排质量命令,不进入生产运行时。
- 健康检查只执行有限的 Redis/MySQL 只读操作,禁止自动重试风暴;Scheduler 与 Worker 采用独立进程,避免任务执行阻塞 HTTP API。
- OpenAPI 和边界扫描只在开发、测试和发布阶段运行,不增加线上请求路径开销。当前尚无行情吞吐、数据库查询或消息积压业务,因此不伪造业务性能指标;后续功能必须按刷新周期、数据量和延迟重新设定基线。
## 回退原则
GOV-009 不迁移业务数据。回退时恢复上一 Git 标签即可移除脚手架;本地 `*.env.local` 和基础设施数据不随 Git 回退。若 Schema 工具变化失败,恢复旧工具后仍保留已发布基线,禁止改写历史目录。
## 实施后架构论证门禁
本文档描述的是实施前目标架构。完成代码、测试、构建和 Review 后,必须根据 GitNexus 实际依赖图、Web/Server 目录、三个 Server 进程、OpenAPI 生成链路和源码部署产物另写 `architecture-review.md`。复核需要说明实际实现与目标的偏差、当前选择优于替代方案的理由、何时应拆分或调整。用户再次确认前不发布 `v0.0.8`,也不把本功能视为彻底完成。
@@ -0,0 +1,56 @@
# GOV-009 应用工程脚手架基线开发总结
- 功能编号:GOV-009
- 发布版本:`v0.0.8`
- 架构确认日期:2026-08-17
## 原始开发需求
用户要求先搭建可支持 A 股市场概览业务的前后端基础:前端采用 Vue 3 与 Dart Sass,后端以独立 NestJS 工程维护,MySQL 固定 5.7、`utf8mb4_general_ci` 与东八区,Redis 作为缓存,RocketMQ 负责异步任务,API、Scheduler、Worker 分进程运行。工程需要开发/生产配置隔离、源码部署、OpenAPI 契约、完整治理留痕,并在全部实施后基于真实结构再次向用户论证。
## 需求与范围变化
- 消息队列从早期 RabbitMQ 方案调整为 RocketMQ 5.x,业务只依赖 `MessageBusAdapter`,未验证 Node 客户端前保持明确禁用。
- 部署从“Docker Compose 与源码并存”逐步收敛为“只支持 Ubuntu 源码部署”,Dockerfile、Compose、镜像门禁和容器兜底全部移除;历史验证事实不改写。
- 前后端不建立根共享 TypeScript 契约包。Server DTO 生成 OpenAPI,Web 生成自己的类型;RocketMQ 消息契约只属于 Server。
- 用户体系、会员订阅、市场概览 UI、行情采集和 AI Provider 均不属于本功能范围,后续以独立功能档案实施。
## 实际完成需求
| 范围 | 状态 | 实际结果 |
|---|---|---|
| Web 工程 | 已完成 | 建立 Vue 3、Vite、Pinia、Vue Router、Element Plus、Dart Sass、Vitest 与 Playwright 基线。 |
| Server 工程 | 已完成 | 建立 NestJS API、Scheduler、Worker 三入口及独立配置、生命周期和构建产物。 |
| 契约边界 | 已完成 | Server DTO → OpenAPI → Web 类型单向生成;Web/Server 源码越界和契约漂移由自动门禁阻断。 |
| 基础设施边界 | 已完成 | 固定 MySQL 5.7.42、Redis 只读健康检查、RocketMQ Adapter/消息信封和禁用语义,不自动管理外部服务。 |
| 环境与部署 | 已完成 | 开发/生产模板按进程最小权限拆分,生产仅支持 Ubuntu、systemd、Nginx 的源码部署。 |
| 质量治理 | 已完成 | 建立运行时、Schema、契约、边界、部署、测试、构建、视觉与 GitNexus 验证链路。 |
| 架构复核 | 已完成 | 依据真实目录和运行入口完成论证,用户于 2026-08-17 确认当前架构基线。 |
## 修复缺陷
实施与 Review 阶段修复了配置注入和三进程生命周期、未跟踪生成契约绕过、Vue 外部脚本越界、Vite 运行时模板警告、源码门禁 Docker 路径绕过、systemd 单元安装名称错误以及 Redis 测试兜底改变外部服务所有权等问题。所有处置均保留在实施计划、QA 和两份 Review 中;当前无未关闭的 Critical 或 Important 问题。
## 未完成与延期项
- 市场概览、短线/中长线模式、行情图表、规则/AI/混合/对照分析尚未实现,归入业务功能开发。
- TDX 常驻采集代理与 RocketMQ Node 客户端尚未落地;当前仅保留接口边界、禁用 Adapter、Tailscale 操作文档和 PoC 前置档案。
- 用户、邀请制、权限、会员和订阅按用户决定后置,不预埋业务实现。
- 完成市场概览真实业务后,需要依据模块依赖、负载与维护成本再次进行架构复核;当前确认不等于永久冻结。
## 关键提交
| 阶段 | 代表提交 | 说明 |
|---|---|---|
| 工程与契约基线 | `b3d8e29` 至 `95b8611` | Schema、workspace、Web、Server 三进程、OpenAPI、边界与 Review 整改。 |
| 仅源码部署 | `cfcd7f1` 至 `c756654` | 确认设计、移除 Docker、修复发布门禁并完成复审。 |
| GitNexus 封存 | `bbda26f` | 更新 GOV-009 最终索引统计。 |
上述提交均使用包含 GOV-009 的中文 Conventional Commit 并已推送项目专用 Gitea。发布封存提交和 `v0.0.8` 标签在本次收尾中分别推送并核对。
## 验证证据
- `qa/test-results.md` 保存运行时、治理、MySQL 5.7、环境、Schema、契约、边界、部署、Web、Server、构建、Playwright、安全扫描和格式证据。
- `qa/visual-qa.md` 与 `screenshots/iterations/` 保存桌面和移动应用外壳证据;GOV-009 不评价尚未实现的市场概览视觉质量。
- `gitnexus/before.md`、`impact-plan.md`、`detected-changes.md`、`after.md` 和 `comparison.md` 保存开发前后影响与实际执行流对比。
- 两份 Review 最终结论均为 `passed`;当前版本没有业务迁移,不访问生产数据库,不创建 RocketMQ Topic,也不写入 Redis 或 MySQL 业务数据。
@@ -0,0 +1,19 @@
# GitNexus 开发后基线
- 记录时间:2026-08-13 GMT+8
- 分支:`main`
- 仅源码实现提交:`47d0e0d248eb9b21cbd12f1625d3bd0e9c266dc9`
- 远端:`origin/main` 已核对为同一 SHA;最终 Review 证据提交将在验证后同步
```text
Repository: a-share-analysis
Indexed commit: 47d0e0d
Current commit: 47d0e0d
Status: up-to-date
Nodes: 1606
Relationships: 2253
Clusters: 48
Execution flows: 50
```
图谱已包含 Web、API、Scheduler、Worker、配置加载、健康检查、OpenAPI、消息信封、Schema、外部 Redis 预检、源码产物/systemd/Nginx 发布验证和治理门禁。旧 Docker 验证符号已删除,GitNexus 本地索引未提交仓库。
@@ -0,0 +1,26 @@
# GitNexus 开发前基线
- 功能编号:GOV-009
- 记录时间:2026年8月13日 GMT+8 15:14:35
- 分支:main
- 基线提交:c04184a6111d
## 工作区
```text
(干净)
```
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/13/2026, 3:14:35 PM
Indexed commit: c04184a
Current commit: c04184a
Status: ✅ up-to-date
```
## 后续人工分析
在修改代码前,将 GitNexus query、context、impact 的结论写入 `gitnexus/impact-plan.md`。高风险结果必须先获得用户确认。
@@ -0,0 +1,31 @@
# GitNexus 前后对比
| 项目 | 开发前 `c04184a6` | 开发后 `95b8611` | 变化 |
| --- | ---: | ---: | ---: |
| 符号 | 958 | 1568 | +610 |
| 关系 | 1141 | 2190 | +1049 |
| 执行流程 | 23 | 47 | +24 |
开发前仓库以治理文档、环境模板和 Schema 工具为主,Web/Server 仍无可运行应用。开发后形成以下新边界:
- Vue 3 Web 可启动、测试、构建,并通过生成的 OpenAPI 类型访问 API。
- NestJS API、Scheduler、Worker 为独立入口和独立配置容器。
- Scheduler/Worker 具备可验证的持续运行与 SIGTERM 优雅关闭生命周期。
- HTTP 契约由 Server DTO 单向发布;RocketMQ 消息信封只存在于 Server。
- Docker Compose 与 Ubuntu 源码部署共用同一配置语义和构建产物。
- Schema 空库、MySQL 5.7.42、契约漂移和 `.vue` 工程边界均有自动门禁。
新增关系数量符合“从占位目录建立应用基线”的预期。后续市场概览功能应在这些边界内增加业务模块,不应把 Web 与 Server 重新耦合。
## 仅源码部署调整对比
| 项目 | 调整设计提交 `cfcd7f1` | 实现与 Review 后 | 变化 |
| --- | ---: | ---: | ---: |
| 符号 | 1589 | 1606 | +17 |
| 关系 | 2211 | 2253 | +42 |
| 执行流程 | 47 | 50 | +3 |
- 删除 Docker 构建、镜像引用和容器生命周期校验符号,新增源码发布校验流程。
- 新增 `checkLocalRedis` 与 `runTestApi`,Playwright 只依赖现有本机 Redis,不拥有基础设施生命周期。
- `verifySourceDeployment` 校验 Web、API、Scheduler、Worker 产物以及 systemd/Nginx;递归阻断任意活动 Dockerfile、`.dockerignore` 和 Compose YAML。
- GitNexus compare 检测风险为 MEDIUM,98 个变更符号、3 个受影响符号,影响集中在部署门禁与 E2E 启动链;未影响业务 API、市场模块、生产数据库或 RocketMQ 消息发送。
@@ -0,0 +1,34 @@
# GitNexus 变更检测
- 对比基线:`c04184a6111da0cfad90d1a265dc3cd3a6d90a9c`
- 实现提交:`95b8611bd9bbc282193591e472e2e19c617e5035`
- 检测命令:`npx gitnexus detect-changes --scope compare --base-ref c04184a6 --repo a-share-analysis`
- 变更范围:110 个文件、452 个符号、45 条执行流程
- 风险:CRITICAL
CRITICAL 来自一次建立完整 Web、API、Scheduler、Worker、契约生成、Schema 和部署验证链路,而不是单个未受控函数。主要流程为三进程配置加载、Schema 生成/验证、OpenAPI 发布、Web 客户端边界和 Docker/源码部署。
Review 整改前对具体符号分别执行上游影响分析:三进程 bootstrap、动态模块、消息信封、空库捕获和 MySQL 健康检查大多为 LOW;`assertMysql57Metadata` 因位于 Schema 发布门禁核心为 CRITICAL。该变更只把服务端补丁版本固定到 5.7.42,历史 `v0.0.7` 清单回归和 `schema:verify` 均通过。
最终代码复审补充发现无引号 Vue 外部 `script src` 可绕过早期正则门禁;影响分析为 LOW,只有 1 个直接调用者和 1 条边界检查流程。`95b8611` 改用 Vue 3.5.41 官方 SFC 解析器,并以单双引号、无引号和属性换序用例验证,未扩大应用运行影响面。
检测范围与开发前影响计划一致,未出现用户体系、生产数据库、外部消息写入或其他项目流程。
## 仅源码部署调整
- 对比基线:`cfcd7f13d9a6a35173d01bd8ca1458911190e70f`
- 实现提交:`47d0e0d248eb9b21cbd12f1625d3bd0e9c266dc9`
- 变更范围:27 个已索引文件、98 个变更符号、3 个受影响符号
- 风险:MEDIUM
开发前对 `assertImmutableImageReferences`、旧 Docker 辅助函数和 `forwardSignal` 的上游影响均为 LOW,0 条业务执行流受影响。最终 compare 的 MEDIUM 来自部署门禁整体替换:旧 Docker 验证删除,源码发布与 Redis 预检新增,并非应用业务依赖扩散。
Review 中 `verifySourceDeployment` 和 `assertDockerArtifactsAbsent` 的影响分析均为 LOW;后者只影响 1 条源码部署校验流程。递归活动资产扫描与 systemd 正式目标名测试完成后,部署 6/6、环境 10/10 和完整 `verify:release` 通过。
## v0.0.8 发布封存检测
- 检测日期:2026-08-17
- 检测命令:`npx gitnexus detect-changes --repo a-share-analysis`
- 结果:22 个已索引文档/版本文件、55 个文档符号、0 条受影响执行流,风险 LOW。
本次变化只封存用户确认、版本状态、独立开发总结、安全/性能证据和 Review,不修改运行时代码。逐项核对确认 HTTP/OpenAPI、Web API、消息、数据库、Redis、API、Scheduler、Worker 与源码部署无需代码同步;CHANGELOG、manifest、发布说明和回退说明已同步。
@@ -0,0 +1,63 @@
# GitNexus 开发前影响分析
- 功能编号:GOV-009
- 基线提交:`c04184a6111da0cfad90d1a265dc3cd3a6d90a9c`
- 分析日期:2026-08-13
## 查询范围
本功能会新增 Web、Server 和构建入口;这些文件在基线图谱中尚无符号,无法产生既有调用方。对已有代码的修改集中在 `tools/database/schema-baseline.mjs`、根工程编排、环境模板和部署配置,因此对 Schema 关键符号执行上游影响分析,并查询现有 Vue/NestJS 执行流。
## 结果
### `assertSafeDevelopmentConfiguration`
- 风险:**CRITICAL**。
- 直接影响:4 个调用方。
- 间接影响:9 个符号、5 组执行流程。
- 直接调用方:`buildMysqldumpArguments`、`runBaselineGeneration`、`assertNotApplicableMatchesDevelopmentConfiguration` 和 Schema 测试。
- 关键下游:`assertCurrentReleasedBaseline`、`assertCurrentReleasedBaselinePublished`、`runCommandLine` 与 `governance:start`。
### `resolveFixedDevelopmentEnv`
- 风险:**HIGH**。
- 直接影响:2 个调用方。
- 间接影响:7 个符号、3 组执行流程。
- 关键下游:Schema 生成、当前发布基线校验和下一功能开发前门禁。
### `buildCapturedArtifacts`
- 风险:LOW。
- 直接影响:Schema 测试;现有运行流程没有额外上游调用。
### 新增工程
GitNexus 查询未找到 Vue、NestJS、API、Scheduler 或 Worker 的既有运行符号,证明当前只有文档和治理工具。新增工程不会破坏已有应用调用方,但会建立新的构建、配置、HTTP 和进程启动流程,开发后必须重新索引并逐项核对。
## 直接与间接影响
- `assertSafeDevelopmentConfiguration` 为 CRITICAL:4 个直接调用方、9 个间接符号和 5 组流程,影响 Schema 生成、已发布基线校验与 `governance:start`。
- `resolveFixedDevelopmentEnv` 为 HIGH:2 个直接调用方、7 个间接符号和 3 组流程,影响开发配置解析和当前发布基线验证。
- 新增 Web、API、Scheduler、Worker 在开发前没有既有调用方,但会新增构建、启动、OpenAPI、生命周期和部署流程;开发后必须用 detect-changes 与 compare 核对实际边界。
## 跨模块同步修改
- HTTP/OpenAPI:新增 Server DTO、OpenAPI 输出、Web 生成类型和漂移门禁;Web 不直接依赖 Server 源码。
- Web API:建立生成契约与 adapter 边界;后续 GOV-010 再统一为 Axios request 与业务域 API。
- 消息:建立 RocketMQ 信封和禁用 Adapter,不创建 Topic 或启用真实收发。
- 数据库与 Redis:同步 MySQL 5.7.42、字符规则、开发 Schema 安全边界和只读健康检查,不实施业务迁移或缓存写入。
- API/Scheduler/Worker:同步三进程入口、最小配置、持续运行和优雅退出验证。
- 部署、测试与文档:同步环境模板、systemd/Nginx、源码发布门禁、Playwright、Review、回退和架构复核;早期 Docker 方案后来由仅源码部署设计取代。
## 风险控制
1. Schema 变更先写失败测试,覆盖固定远程白名单、未知远程拒绝、`api.env.local` 优先级、历史 N/A 基线验证和空库 captured 状态。
2. 已发布的 `v0.0.7` N/A 清单保持不可变;配置启用不得静默重写历史。GOV-009 不创建数据库对象,`v0.0.8` 发布后、下一功能开始前首次捕获空库或真实结构。
3. `governance:start` 的严格远程分支、标签和已提交基线校验必须继续通过现有测试。
4. Schema 密码只通过子进程环境传递;固定白名单写在代码中,不接受命令参数、动态 env 白名单或通配地址。
5. 新增 Server 进程分别测试配置最小权限、启动和关闭;Web 通过边界测试禁止导入 Server 源码。
6. 每个阶段运行全量 Schema 与治理回归;提交前运行 GitNexus `detect_changes`,若风险超出本报告则停止并重新确认。
## 回退
Schema 阶段可以独立回退到 GOV-009 开始提交,已发布基线目录不变。应用脚手架不执行业务迁移,回退对应提交即可移除 Web/Server 构建产物;本地 `*.env.local`、Redis 数据和远程开发库不随 Git 操作修改。
@@ -0,0 +1,643 @@
# GOV-009 应用工程脚手架基线实施计划
> **For agentic workers:** REQUIRED SUB-SKILL: Use `superpowers:subagent-driven-development` (recommended) or `superpowers:executing-plans` to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** 建立可启动、测试、构建和独立部署的 Vue 3 Web 与 NestJS API/Scheduler/Worker 工程,并修正开发 Schema 的本地配置、固定远程白名单和空库基线能力。
**Architecture:** 根 pnpm workspace 只编排 `web` 与 `server`。HTTP 契约由 Server 的 DTO 和 OpenAPI 单向发布,Web 生成自己的客户端;RocketMQ 消息契约只在 Server 内共享。Schema 安全门禁继续固定开发环境与数据库,只增加代码内固定远程主机和 `captured_empty` 状态。
**Tech Stack:** Node.js 22.x、pnpm 10.25.0、TypeScript 5.9.3、Vue 3.5.41、Vite 6.4.3、Naive UI 2.44.1、Dart Sass 1.102.0、Vitest 3.2.7、Playwright 1.62.1、NestJS 11.1.29、TypeORM 0.3.31、mysql2 3.23.3、ioredis 5.11.1、MySQL 5.7、Redis、RocketMQ 5.x。
## Global Constraints
- 本机当前 Node.js 是 `20.20.2`,不得用于正式安装或验收;源码运行前由开发机提供 Node 22,项目不安装 Node。实施期间可使用 `node:22.22.0-bookworm-slim` 执行安装、测试和构建。
- pnpm 固定 `10.25.0`,根 `package.json` 写入精确 `packageManager`,依赖提交精确版本及 `pnpm-lock.yaml`,禁止 `latest`。
- 所有关键业务边界、配置安全、异常恢复和架构取舍使用准确中文注释,不做逐行翻译式注释。
- Web 不得导入 `server/`;RocketMQ 消息契约不得进入 Web;数据库实体不得作为 HTTP DTO。
- MySQL 只允许 5.7.x、`a_share_analysis_dev`、`utf8mb4`、`utf8mb4_general_ci` 和 `+08:00` 会话时区,禁止 `synchronize: true`。
- Schema 只读取开发配置,只允许回环地址或固定白名单 `112.192.20.11`,不得接触生产环境。
- RocketMQ 在 GOV-009 中保持默认关闭;打开但没有已验证客户端时必须失败,不提供内存队列伪降级。
- 每个行为遵循 RED-GREEN-REFACTOR:先运行并确认测试因行为缺失而失败,再写最小实现;测试断言真实结果,不断言 Mock 自身。
- 每个提交使用中文 Conventional Commit 并带 `GOV-009`,验证后立即精确推送当前分支到 Gitea。
---
### Task 1: 修正 Schema 开发配置与空库基线
**Files:**
- Modify: `tools/database/schema-baseline.mjs`
- Modify: `tools/database/schema-baseline.test.mjs`
- Modify: `docs/governance/development-workflow.md`
- Modify: `docs/governance/code-development-standards.md`
- Modify: `docs/deployment/local-development.md`
**Interfaces:**
- Produces: `resolveFixedDevelopmentEnv(repositoryRoot): string`,优先返回 `deploy/env/development/api.env.local`,缺失时退回模板。
- Produces: `assertSafeDevelopmentConfiguration(config): Readonly<SchemaConfig>`,只接受回环地址或 `112.192.20.11`。
- Produces: `buildCapturedEmptyArtifacts(metadata): BaselineArtifacts`,状态为 `captured_empty`、format v2,只保存结构化清单、`object_counts` 和空结构 SHA-256,不创建 `schema.sql`。
- Preserves: `assertCurrentReleasedBaselinePublished(repositoryRoot)` 的已提交、已推送和远程标签严格门禁。
- [ ] **Step 1: 写入配置路径和主机白名单失败测试**
在 `schema-baseline.test.mjs` 增加行为测试:临时目录同时存在 `api.env.local` 与模板时必须选择 local;`112.192.20.11` 被接受;`112.192.20.12`、域名和空主机被拒绝。期望值直接使用固定路径和错误类型,不复用实现常量。
```js
assert.equal(
resolveFixedDevelopmentEnv(repositoryRoot),
path.join(repositoryRoot, 'deploy/env/development/api.env.local'),
);
assert.doesNotThrow(() =>
assertSafeDevelopmentConfiguration({
...validConfig,
MYSQL_HOST: '112.192.20.11',
}),
);
assert.throws(
() => assertSafeDevelopmentConfiguration({ ...validConfig, MYSQL_HOST: '112.192.20.12' }),
/固定开发数据库主机白名单/,
);
```
- [ ] **Step 2: 运行测试并确认 RED**
Run: `node --test --test-name-pattern='配置路径|远程开发库白名单' tools/database/schema-baseline.test.mjs`
Expected: FAIL,原因分别为 `api.env.local` 未被选择、固定远程地址仍被拒绝。
- [ ] **Step 3: 实现固定配置解析与白名单**
在代码内使用不可变集合,不读取动态白名单变量:
```js
const DEVELOPMENT_HOSTS = new Set(['127.0.0.1', 'localhost', '::1', '112.192.20.11']);
export function resolveFixedDevelopmentEnv(repositoryRoot) {
const localEnv = path.join(repositoryRoot, 'deploy', 'env', 'development', 'api.env.local');
if (existsSync(localEnv)) return localEnv;
return path.join(repositoryRoot, 'deploy', 'env', 'development', 'api.env.example');
}
```
错误文案只输出主机,不输出用户名或密码。导出 `resolveFixedDevelopmentEnv` 供真实行为测试调用。
- [ ] **Step 4: 写入空库 captured 失败测试**
模拟 metadata 查询返回合法 MySQL 5.7 元数据,`mysqldump` 返回空结构;断言结果为 `captured_empty`、format v2、文件集合只有 `manifest.yaml`、`object_counts` 全为零、摘要为 SHA-256 空串,且没有 `schema.sql`。另加 fixture 回归测试证明既有 format v1 的 `not_applicable` 与 captured 清单仍可验证,并且当前运行配置改变不会静默重写历史。
- [ ] **Step 5: 运行测试并确认 RED**
Run: `node --test --test-name-pattern='空库|历史不适用基线' tools/database/schema-baseline.test.mjs`
Expected: FAIL,现有实现以“真实 Schema SQL 不能为空”拒绝空库,并重新读取当前配置否定历史 N/A 清单。
- [ ] **Step 6: 实现 `captured_empty` 和不可变历史语义**
`buildCapturedArtifacts` 在规范化 SQL 为空时调用:
```js
export function buildCapturedEmptyArtifacts(metadata) {
assertMysql57Metadata(metadata);
return Object.freeze({
status: 'captured_empty',
files: Object.freeze({
'manifest.yaml': buildManifest({
...metadata,
status: 'captured_empty',
captured: false,
schemaSha256: sha256(''),
}),
}),
});
}
```
新生成的 format v2 Manifest 增加 `object_counts`,空库固定为零;普通 captured 从导出 SQL 解析并记录非负计数。既有 format v1 的 `objects` 布尔结构保持只读兼容,验证器按格式版本与状态校验精确文件集合。已发布 N/A 清单只验证生成事实,不在 `schema:verify` 阶段用当前 env 改写历史;下一版本生成时才读取当前 local 配置。
- [ ] **Step 7: 验证真实固定开发库**
先运行只读元数据查询确认目标仍为空,再使用项目支持的 MySQL 5.7 原生客户端或 Docker 客户端执行一次临时目录生成测试;不得覆盖 `database/schema-baselines/v0.0.7/`。
Expected: 服务端 `5.7.42`、数据库 `a_share_analysis_dev`、字符集 `utf8mb4`、排序规则 `utf8mb4_general_ci`、对象计数 0。
- [ ] **Step 8: 全量 Schema 回归、影响检测、提交和推送**
Run:
```bash
npm run test:schema-baseline
npm run schema:verify
npm run test:governance
git diff --check
```
Expected: 全部 PASS,`v0.0.7` 清单逐字节不变。运行 GitNexus `detect_changes`,风险只能落在本报告列出的 Schema/governance 流程。
Commit: `feat(GOV-009): 支持固定开发库结构基线`
Push: `git push origin "$(git branch --show-current)"`
---
### Task 2: 建立 Node 22 与 pnpm workspace 质量基线
**Files:**
- Modify: `package.json`
- Create: `pnpm-workspace.yaml`
- Create: `pnpm-lock.yaml`
- Create: `.npmrc`
- Create: `eslint.config.mjs`
- Create: `.prettierrc.json`
- Create: `tools/runtime/verify-runtime.mjs`
- Create: `tools/runtime/verify-runtime.test.mjs`
**Interfaces:**
- Produces: `assertSupportedRuntime({ nodeVersion, pnpmVersion })`。
- Produces root scripts: `check:runtime`, `lint`, `format:check`, `typecheck`, `test`, `build`, `verify`。
- [ ] **Step 1: 写运行时门禁失败测试**
覆盖 Node `22.0.0` 与 pnpm `10.25.0` 通过,Node 20/24、pnpm 9/11 拒绝;错误消息包含实际版本,不执行安装。
- [ ] **Step 2: 运行并确认 RED**
Run: `node --test tools/runtime/verify-runtime.test.mjs`
Expected: FAIL with `ERR_MODULE_NOT_FOUND`。
- [ ] **Step 3: 实现运行时门禁和 workspace**
```js
export function assertSupportedRuntime({ nodeVersion, pnpmVersion }) {
if (Number(nodeVersion.split('.')[0]) !== 22) {
throw new Error(`Node.js 必须为 22.x,实际 ${nodeVersion}`);
}
if (Number(pnpmVersion.split('.')[0]) !== 10) {
throw new Error(`pnpm 必须为 10.x,实际 ${pnpmVersion}`);
}
}
```
`pnpm-workspace.yaml` 只包含:
```yaml
packages:
- web
- server
```
根 `package.json` 写入 `engines.node: 22.x`、`packageManager: pnpm@10.25.0`,根脚本通过 `pnpm --filter` 编排两个工程,不创建业务依赖。
- [ ] **Step 4: 在 Node 22 容器安装精确依赖并生成锁文件**
Run: `docker run --rm --user "$(id -u):$(id -g)" -e COREPACK_HOME=/tmp/corepack -v "$PWD:/workspace" -w /workspace node:22.22.0-bookworm-slim sh -lc 'corepack pnpm install --lockfile-only'`
Expected: 生成单一 `pnpm-lock.yaml`,无 `latest`,宿主项目文件归当前用户可读写。
- [ ] **Step 5: 验证、提交和推送**
Run: Node 22 容器中的 `corepack pnpm check:runtime`、运行时单测、`git diff --check`。
Commit: `build(GOV-009): 建立 Node 与工作区基线`
Push current branch and verify local/remote SHA equality.
---
### Task 3: 建立 Vue 3 Web 工程
**Files:**
- Delete: `web/.gitkeep`
- Create: `web/package.json`
- Create: `web/tsconfig.json`
- Create: `web/tsconfig.node.json`
- Create: `web/vite.config.ts`
- Create: `web/vitest.config.ts`
- Create: `web/playwright.config.ts`
- Create: `web/index.html`
- Create: `web/src/main.ts`
- Create: `web/src/app/App.vue`
- Create: `web/src/app/router.ts`
- Create: `web/src/app/providers.ts`
- Create: `web/src/styles/index.scss`
- Create: `web/src/env.d.ts`
- Create: `web/src/app/App.test.ts`
- Create: `web/tests/smoke.spec.ts`
**Interfaces:**
- Produces: `createAppRouter()` 和 `installAppProviders(app)`。
- Consumes: only `VITE_APP_ENV`, `VITE_API_BASE_URL`, `VITE_APP_TITLE` from `web.env.local`。
- Preserves: FEAT-MO-001 将在 `src/features/market-overview/` 添加首屏,不需要重构应用入口。
- [ ] **Step 1: 写 Web 应用外壳失败测试**
使用真实 Pinia、Router 和 Naive UI provider 挂载 `App.vue`,断言应用标题和主内容区域可访问;禁止 mock 子组件。
- [ ] **Step 2: 运行并确认 RED**
Run: `pnpm --filter @a-share-analysis/web test --run`
Expected: FAIL,因为 Web 包和应用入口尚不存在。
- [ ] **Step 3: 创建精确依赖和最小应用外壳**
Web dependencies 精确锁定 Vue 3.5.41、Vue Router 4.6.4、Pinia 3.0.4、Naive UI 2.44.1;dev dependencies 锁定 Vite 6.4.3、plugin-vue 5.2.4、TypeScript 5.9.3、vue-tsc 3.3.9、Sass 1.102.0、Vitest 3.2.7、Vue Test Utils 2.4.11、jsdom 26.1.0、Playwright 1.62.1。该组合兼容开发机 Node 22.11;Vite 7 要求 Node 22.12+,不在本基线采用。
`main.ts` 固定从项目外部加载开发 env:
```ts
const app = createApp(App);
installAppProviders(app);
app.mount('#app');
```
Vite `envDir` 指向 `../deploy/env/development`,开发模式通过 `--mode web` 加载 `web.env.local`;生产构建只接受部署注入的 `VITE_` 值。样式仅建立字体、颜色 token、页面高度和可访问焦点基线,不提前设计市场概览。
- [ ] **Step 4: 运行单测、类型和构建**
Run:
```bash
pnpm --filter @a-share-analysis/web test --run
pnpm --filter @a-share-analysis/web typecheck
pnpm --filter @a-share-analysis/web build
```
Expected: PASS,`web/dist` 不包含 `MYSQL_`、`REDIS_`、`ROCKETMQ_`、密码或 Server 消息字段。
- [ ] **Step 5: 写 Playwright 冒烟测试并确认 RED/GREEN**
测试访问 `/`,验证 `main` 存在、无页面错误和水平溢出,视口覆盖 `1440x900` 与 `390x844`。先在未配置 webServer 时确认失败,再配置 Vite webServer 并通过。
- [ ] **Step 6: 提交和推送**
Commit: `feat(GOV-009): 建立 Vue 前端工程基线`
Push current branch and verify remote SHA.
---
### Task 4: 建立 NestJS 三进程与最小权限配置
**Files:**
- Delete: `server/.gitkeep`
- Create: `server/package.json`
- Create: `server/nest-cli.json`
- Create: `server/tsconfig.json`
- Create: `server/tsconfig.build.json`
- Create: `server/apps/api/src/main.ts`
- Create: `server/apps/api/src/api.module.ts`
- Create: `server/apps/scheduler/src/main.ts`
- Create: `server/apps/scheduler/src/scheduler.module.ts`
- Create: `server/apps/worker/src/main.ts`
- Create: `server/apps/worker/src/worker.module.ts`
- Create: `server/libs/config/src/runtime-config.ts`
- Create: `server/libs/config/src/runtime-config.test.ts`
- Create: `server/libs/config/src/load-process-env.ts`
- Create: `server/test/process-smoke.test.ts`
**Interfaces:**
- Produces: `loadApiConfig`, `loadSchedulerConfig`, `loadWorkerConfig`,返回冻结且不含未知字段的配置。
- Produces: `bootstrapApi`, `bootstrapScheduler`, `bootstrapWorker`,支持依赖注入端口和优雅关闭。
- Consumes: `deploy/env/development/<process>.env.local` only in development; production only consumes `process.env` injected by Compose/systemd.
- [ ] **Step 1: 写进程配置失败测试**
分别证明 API 不要求 Scheduler/Worker 变量、Scheduler 不读取 MySQL 密码、Worker 不要求 API 端口;MySQL 启用时缺少时区或密码失败;日志序列化不包含敏感值。
- [ ] **Step 2: 运行并确认 RED**
Run: `pnpm --filter @a-share-analysis/server test -- runtime-config.test.ts`
Expected: FAIL,因为配置模块不存在。
- [ ] **Step 3: 实现进程级配置**
使用纯函数解析、显式条件必填和对象冻结。公共字段保持在同一文件连续阅读,避免每个变量一个文件。MySQL 配置接口固定:
```ts
export interface MysqlRuntimeConfig {
enabled: boolean;
host: string;
port: number;
database: 'a_share_analysis_dev' | string;
username: string;
password: string;
charset: 'utf8mb4';
collation: 'utf8mb4_general_ci';
timezone: '+08:00';
}
```
生产配置不从仓库路径加载;开发入口根据自身 `import.meta.url` 定位唯一 local 文件,不接受用户传入 env 路径。
- [ ] **Step 4: 写三进程启动关闭失败测试**
测试调用三个 bootstrap 函数,使用真实 Nest application/context 和只在基础设施端口注入的轻量 fake;断言 API 监听给定端口,Scheduler/Worker 不打开 HTTP 端口,三者收到关闭信号后释放资源。
- [ ] **Step 5: 运行并确认 RED 后实现入口**
API 使用 `NestFactory.create`;Scheduler/Worker 使用 `NestFactory.createApplicationContext`。所有进程启用 shutdown hooks,启动日志只记录进程名、环境和非敏感端口。
- [ ] **Step 6: 验证构建产物路径**
Run:
```bash
pnpm --filter @a-share-analysis/server test
pnpm --filter @a-share-analysis/server typecheck
pnpm --filter @a-share-analysis/server build
test -f server/dist/apps/api/main.js
test -f server/dist/apps/scheduler/main.js
test -f server/dist/apps/worker/main.js
```
Expected: 与现有 systemd/Compose 命令完全一致。
- [ ] **Step 7: 提交和推送**
Commit: `feat(GOV-009): 建立 NestJS 三进程基线`
---
### Task 5: 建立后端契约、基础设施与 API 健康检查
**Files:**
- Create: `server/libs/http-contracts/src/health.dto.ts`
- Create: `server/libs/message-contracts/src/message-envelope.ts`
- Create: `server/libs/message-contracts/src/message-envelope.test.ts`
- Create: `server/libs/infrastructure/src/message-bus.adapter.ts`
- Create: `server/libs/infrastructure/src/disabled-message-bus.adapter.ts`
- Create: `server/libs/infrastructure/src/redis-health.client.ts`
- Create: `server/libs/infrastructure/src/mysql-health.client.ts`
- Create: `server/libs/infrastructure/src/typeorm-options.ts`
- Create: `server/apps/api/src/health.controller.ts`
- Create: `server/apps/api/src/health.service.ts`
- Create: `server/apps/api/test/health.e2e-spec.ts`
- Create: `server/tools/export-openapi.ts`
- Create: `server/openapi/openapi.json`
- Modify: `deploy/env/development/api.env.example`
- Modify: `deploy/env/development/worker.env.example`
- Modify: `deploy/env/production/api.env.example`
- Modify: `deploy/env/production/worker.env.example`
- Modify ignored local API/Worker env files to retain `MYSQL_TIMEZONE=+08:00` without staging them.
**Interfaces:**
- Produces: `GET /api/v1/health -> HealthResponseDto`。
- Produces: `MessageEnvelope<TPayload>` with `version`, `eventType`, `idempotencyKey`, `occurredAt`, `payload`。
- Produces: `MessageBusAdapter.publish/subscribe/close`,disabled adapter rejects publish/subscribe with a typed error。
- Produces: TypeORM options with `synchronize: false`, MySQL 5.7 charset/collation/timezone.
- [ ] **Step 1: 写消息契约与禁用 adapter 失败测试**
覆盖有效信封、缺失幂等键、非法时间、未知版本;disabled adapter 的发布/订阅必须拒绝且不缓存消息。
- [ ] **Step 2: RED 后实现 Server 内部契约**
```ts
export interface MessageEnvelope<TPayload> {
version: 1;
eventType: string;
idempotencyKey: string;
occurredAt: string;
payload: TPayload;
}
```
验证函数返回规范化冻结对象;Web 无路径别名能够解析此目录。
- [ ] **Step 3: 写健康检查 E2E 失败测试**
启动真实 Nest API,注入确定性的 Redis/MySQL health ports,调用 `/api/v1/health`,断言 HTTP 200、进程状态、Redis/MySQL 分项和 RocketMQ `disabled`;依赖失败时 HTTP 503 且错误体不包含凭据。
- [ ] **Step 4: RED 后实现只读健康客户端**
Redis 只执行 `PING`;MySQL 使用 `SELECT VERSION(), DATABASE(), @@character_set_database, @@collation_database, @@session.time_zone`,连接建立时设置 `+08:00`。TypeORM options 明确:
```ts
{
type: 'mysql',
connectorPackage: 'mysql2',
charset: 'utf8mb4',
timezone: '+08:00',
synchronize: false,
migrationsRun: false,
}
```
如果 TypeORM 实际类型不支持 `connectorPackage`,删除该字段并通过安装的 `mysql2` 驱动解析;不得用类型断言掩盖错误。
- [ ] **Step 5: 写 OpenAPI 导出失败测试并实现**
导出命令从真实 Controller/DTO 生成排序稳定的 `server/openapi/openapi.json`。测试解析 JSON,断言 `/api/v1/health` 与 `HealthResponseDto` 存在;再次生成后 `git diff --exit-code -- server/openapi/openapi.json` 必须通过。
- [ ] **Step 6: 更新环境模板并运行契约测试**
四份 MySQL 模板增加 `MYSQL_TIMEZONE=+08:00`,开发/生产同进程键集合继续一致,生产密码保持空值。
Run: Server tests, `npm run test:environment-baseline`, typecheck, OpenAPI drift check.
- [ ] **Step 7: 使用真实开发基础设施只读冒烟**
Redis DB 0/1/2 分别 PING;API/Worker MySQL 连接验证版本、库名、字符集、排序规则和时区。RocketMQ 只检查既有 NameServer/Broker/Proxy 管理链路,Node adapter 保持 disabled。
- [ ] **Step 8: 提交和推送**
Commit: `feat(GOV-009): 建立后端契约与健康检查`
---
### Task 6: 生成 Web OpenAPI 客户端并强制边界
**Files:**
- Create: `web/src/api/generated/schema.ts`
- Create: `web/src/api/client.ts`
- Create: `web/src/api/adapters/health.adapter.ts`
- Create: `web/src/api/adapters/health.adapter.test.ts`
- Create: `tools/boundaries/verify-project-boundaries.mjs`
- Create: `tools/boundaries/verify-project-boundaries.test.mjs`
- Modify: `web/package.json`
- Modify: root `package.json`
**Interfaces:**
- Consumes: `server/openapi/openapi.json` as the only cross-project contract artifact.
- Produces: `createApiClient(baseUrl)` using `openapi-fetch` and generated `paths` type.
- Produces: `toHealthViewModel(dto): HealthViewModel`,页面模型不暴露后端枚举细节。
- [ ] **Step 1: 写项目边界失败测试**
在临时 fixture 中创建 Web 对 `server/libs` 的 import 和消息字段,运行真实边界检查器并断言失败;合法的 `web/src/api/generated/schema.ts` 通过。检查器解析 TypeScript import/export specifier,不用简单 grep 代替模块边界。
- [ ] **Step 2: RED 后实现边界检查器**
检查 Web 源文件的静态 import、动态 import 和路径别名,拒绝解析到仓库 `server/`;检查生成 OpenAPI schema 不包含 `MessageEnvelope` 或 `message-contracts`。
- [ ] **Step 3: 生成 Web 客户端**
Run: `openapi-typescript ../server/openapi/openapi.json -o src/api/generated/schema.ts`
`client.ts` 只包装 base URL 和错误归一化;健康 adapter 使用手写页面模型和显式映射,不把生成 DTO 传入 Vue 组件。
- [ ] **Step 4: 写 adapter 失败测试并实现**
使用手写完整 DTO fixture,断言 healthy/degraded/unavailable 映射和未知依赖状态拒绝。先运行确认函数缺失失败,再实现最小映射。
- [ ] **Step 5: 运行边界、生成漂移、Web 测试和构建**
Run root `check:contracts` twice; second run must leave clean diff. Scan `web/dist` for Server env keys, message fields and secrets; expected no match.
- [ ] **Step 6: 提交和推送**
Commit: `feat(GOV-009): 建立前端 OpenAPI 客户端边界`
---
### Task 7: 对齐 Docker、Compose、systemd 与源码开发命令
**Files:**
- Create: `web/Dockerfile`
- Create: `web/nginx.conf`
- Create: `server/Dockerfile`
- Modify: `deploy/compose/production.yml.example`
- Modify: `deploy/nginx/a-share-analysis.conf.example`
- Modify: `deploy/systemd/a-share-api.service.example`
- Modify: `deploy/systemd/a-share-scheduler.service.example`
- Modify: `deploy/systemd/a-share-worker.service.example`
- Modify: `docs/deployment/local-development.md`
- Modify: `docs/deployment/docker-compose-production.md`
- Modify: `docs/deployment/ubuntu-source-production.md`
- Modify: `README.md`
- Modify: `tools/governance/environment-baseline.test.mjs`
**Interfaces:**
- Produces immutable Web image serving `/` and proxying `/api/` according to deployment contract.
- Produces one Server image with commands `dist/apps/api/main.js`, `dist/apps/scheduler/main.js`, `dist/apps/worker/main.js`.
- [ ] **Step 1: 扩展部署行为测试并确认 RED**
使用 `docker build` 和 `docker compose config` 作为真实行为测试;验证镜像入口文件存在、非 root 运行、生产 Compose 必填不可变镜像、systemd ExecStart 对应真实 dist 文件。不要只断言文档文本。
- [ ] **Step 2: 实现多阶段 Dockerfile**
Builder 使用固定 Node 22.22.0 与 pnpm 10.25.0;Server runtime 只复制生产依赖和 dist,使用非 root 用户;Web runtime 使用固定 Nginx 镜像并复制 dist。镜像层不得复制 `deploy/env/development/*.local`。
- [ ] **Step 3: 更新双部署说明**
本地命令明确 Node 22 前置、`pnpm install --frozen-lockfile`、四进程启动顺序和 env 路径;生产说明分别给出 Compose 与 Ubuntu/systemd 的构建、迁移、启动、健康检查和回退命令。不得记录真实开发密码或远程库账号。
- [ ] **Step 4: 构建并启动容器冒烟**
Build Web/Server images with local-only tags. 使用临时生产 env(无真实生产密钥)验证配置缺失会失败;使用开发只读配置只启动 API 健康检查,不启动 Scheduler/Worker 的 RocketMQ 消费。
- [ ] **Step 5: 提交和推送**
Commit: `build(GOV-009): 对齐应用部署与运行入口`
---
### Task 8: 完成全量验证、Review 与发布留痕
**Files:**
- Update: `docs/features/GOV-009-application-scaffold-baseline/manifest.yaml`
- Create: `docs/features/GOV-009-application-scaffold-baseline/gitnexus/detected-changes.md`
- Create: `docs/features/GOV-009-application-scaffold-baseline/gitnexus/after.md`
- Create: `docs/features/GOV-009-application-scaffold-baseline/gitnexus/comparison.md`
- Create: `docs/features/GOV-009-application-scaffold-baseline/qa/test-results.md`
- Create: `docs/features/GOV-009-application-scaffold-baseline/qa/visual-qa.md`
- Create: `docs/features/GOV-009-application-scaffold-baseline/review/code-review.md`
- Create: `docs/features/GOV-009-application-scaffold-baseline/review/standards-review.md`
- Create: `docs/features/GOV-009-application-scaffold-baseline/release-notes.md`
- Create: `docs/features/GOV-009-application-scaffold-baseline/rollback.md`
- Create: `docs/features/GOV-009-application-scaffold-baseline/architecture-review.md`
- Modify: `VERSION`
- Modify: `CHANGELOG.md`
**Interfaces:**
- Produces: reproducible evidence for tests, builds, browser screenshots, GitNexus changes, reviews, release and rollback.
- [ ] **Step 1: 在固定 Node 22 环境运行完整验证**
Run root `pnpm verify`, all four governance suites, `schema:verify`, Web Playwright at desktop/mobile, both Docker builds, development and production Compose validation, secret scan and `git diff --check`.
Expected: zero failures and zero unexpected warnings. Save exact commands, versions and result counts in `qa/test-results.md`.
- [ ] **Step 2: 保存视觉证据**
启动 Web/API 本地服务,Playwright 保存 `1440x900` 与 `390x844` 截图;检查无空白画面、溢出、重叠和控制台错误。GOV-009 只验证应用外壳,不评价市场概览视觉质量。
- [ ] **Step 3: 执行 GitNexus 变更检测和结束门禁**
Run GitNexus `detect_changes`,核对新增 API、Scheduler、Worker、OpenAPI 和 Web 流程,记录与开发前 23 条流程的差异。运行 `npm run governance:finish -- GOV-009 application-scaffold-baseline`。
- [ ] **Step 4: 独立代码与规范 Review**
代码 Review 检查配置泄漏、MySQL 5.7、进程生命周期、契约方向、Docker 产物和真实测试。规范 Review 逐条核对中文注释、文件拆分、中文提交、GitNexus 和文档追溯。两份报告必须包含精确行:
```text
最终结论:passed
```
- [ ] **Step 5: 更新版本、发布说明和回退**
将版本提升到 `0.0.8`,说明工程能力而不声称市场概览已实现。回退说明不得删除远程数据库或 Redis 数据,只回退应用代码和镜像。
- [ ] **Step 6: 基于实际实现完成架构复核并向用户论证**
`architecture-review.md` 必须引用真实文件和 GitNexus 流程,说明 Web 分层、Server 三进程、HTTP 与消息契约方向、基础设施边界、部署产物、替代方案、已知限制和后续调整触发条件。将 manifest 保持 `reviewing` 和 `unreleased`,提交并推送复核材料,然后向用户展示论证;未获得用户再次确认时在此停止,不创建标签。
- [ ] **Step 7: 用户确认后执行最终提交、推送与标签**
Commit: `docs(GOV-009): 封存应用脚手架验证结果`
Push current branch, compare local and remote SHA, create annotated tag `v0.0.8`, then run `git push origin v0.0.8`。禁止 `--tags` 和任何 force 选项。
- [ ] **Step 8: 刷新 GitNexus 并确认干净状态**
Run `npx gitnexus status`; stale 时运行 analyze。最终要求工作区干净、`main` 与 `origin/main` 一致、远程 `v0.0.8^{}` 指向本地标签提交。
---
## 实际执行记录
### 已完成任务与远端提交
| Task | RED / GREEN 与验证摘要 | 提交 | 推送证据 |
| --- | --- | --- | --- |
| 1 Schema | 配置路径、固定远程白名单、历史 N/A 与空库用例先失败;实现后 Schema 27/27、治理 5/5、环境 7/7 | `b3d8e29` | 15:43:07 `origin/main update by push` |
| 2 Workspace | 运行时模块缺失先失败;Node 22/pnpm 10 门禁与 frozen install 后通过 | `258a2d2` | 15:54:08 推送 |
| 3 Web | App 缺失、模板 `import.meta.env` 与路由警告依次复现;Vitest、类型、构建、双视口 Playwright 后通过 | `28d5418`、`dcdf634` | 16:43:48、18:03:38 推送 |
| 4 三进程 | 配置条件与启动入口先失败;三个 Nest 入口和独立配置 Schema 后通过 | `3fc703d` | 16:59:12 推送 |
| 5 后端契约 | 消息、健康接口和 OpenAPI 先失败;Server 契约与只读客户端后通过 | `420aa22` | 17:26:53 推送 |
| 6 Web 契约 | Web 越界导入与 adapter 行为先失败;OpenAPI 生成客户端和边界门禁后通过 | `4665336` | 17:36:58 推送 |
| 7 部署 | Docker/systemd 产物断言先失败;双镜像、三入口和双部署文档后通过 | `c771a98` | 17:56:39 推送 |
| 8 Review 整改 | 生命周期、配置注入、消息字段、5.7.42、空库、SFC、漂移、代理与 Docker 集成均有 RED/GREEN;最终补齐未跟踪契约、Vue 官方 SFC 解析、镜像摘要和容器生命周期门禁;`pnpm verify` 通过,Docker 留存历史验证 | `3a8120a`、`cb550e3`、`95b8611` | 18:31:10、18:51:16、19:49:46 推送 |
上述推送时间来自项目级 `origin/main` reflog;所有阶段均在提交后 1–83 秒内推送。提交摘要全部为包含 `GOV-009` 的中文 Conventional Commit。
### 计划状态
- Task 1–7:已实现、验证、提交并推送;原始步骤复选框保留为开发前计划,不反向改写预期命令和 RED 描述。
- Task 8 Step 1–3、5:已完成全量验证、视觉证据、GitNexus 检测与发布/回退材料。
- Task 8 Step 4:代码 Review 追加发现无引号外部脚本绕过,已用 Vue 官方 SFC 解析器整改;代码 Review 与规范 Review 最终结论均为 `passed`。
- Task 8 Step 6:架构复核文档已生成并完成论证;用户于 2026-08-17 确认以仅源码部署后的实际架构作为业务开发基线。
- Task 8 Step 7:用户确认后进入发布封存;最终档案提交、`main` 推送及 `v0.0.8` 精确标签推送由本次收尾执行并记录。
- Task 8 Step 8:开发后图谱已在各实施阶段刷新;本次最终档案提交后再次刷新并核对本地、远端分支与标签。
### Docker 后续执行口径
用户于 2026-08-13 最终决定彻底移除 Docker 依赖,项目生产交付只支持 Ubuntu 源码部署。早期 Docker/Compose 验证记录作为当时真实事实保留在历史档案,但现行仓库已删除可执行 Docker 资产;后续发布统一执行 `pnpm verify:release` 的源码门禁。

Some files were not shown because too many files have changed in this diff Show More