Compare commits

...
85 Commits
Author SHA1 Message Date
FoXiMao 1f6ed00e6f docs(FEAT-MO-001): 完成评审与治理收口 2026-08-18 21:24:05 +08:00
FoXiMao c2fdfa625b fix(FEAT-MO-001): 校验相邻行情日期 2026-08-18 21:10:58 +08:00
FoXiMao ae2a7e08ed fix(FEAT-MO-001): 校验TDX交易日期语义 2026-08-18 20:48:20 +08:00
FoXiMao 7e4dcd9232 fix(FEAT-MO-001): 修复交易日对齐与延迟状态 2026-08-18 20:12:26 +08:00
FoXiMao 49f6be9c43 fix(FEAT-MO-001): 修复TDX数据完整性与状态展示 2026-08-18 19:30:34 +08:00
FoXiMao ff8ada8316 feat(FEAT-MO-001): 接入TDX市场宽度板块与成交额趋势 2026-08-18 17:37:36 +08:00
FoXiMao 82619489a9 feat(FEAT-MO-001): 完成TDX市场概览首屏 2026-08-18 15:28:35 +08:00
FoXiMao 27bc3c198f feat(FEAT-MO-001): 同步市场概览前端契约 2026-08-18 13:43:48 +08:00
FoXiMao 15a25002ce feat(FEAT-MO-001): 增加市场概览分模块接口 2026-08-18 13:31:24 +08:00
FoXiMao c2fa929936 feat(FEAT-MO-001): 增加TDX直连配置与客户端 2026-08-18 13:16:07 +08:00
FoXiMao 6eb34b5afe docs(FEAT-MO-001): 记录TDX开发前门禁 2026-08-18 13:05:32 +08:00
FoXiMao d283ee3196 docs(FEAT-MO-001): 制定TDX概览实施计划 2026-08-18 12:59:17 +08:00
FoXiMao 9a965fab14 docs(FEAT-MO-001): 确认TDX直连概览设计 2026-08-18 12:48:28 +08:00
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
284 changed files with 26475 additions and 403 deletions
+4
View File
@@ -3,6 +3,8 @@ node_modules/
dist/ dist/
coverage/ coverage/
*.tsbuildinfo *.tsbuildinfo
playwright-report/
test-results/
# 本地环境与密钥 # 本地环境与密钥
.env .env
@@ -28,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
}
+7 -2
View File
@@ -19,12 +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`,启用时主机必须是开发机回环地址;禁止连接、探测或读取生产数据库。MySQL 未启用时只允许生成可验证的 `not_applicable` 清单,禁止用空 SQL 冒充基线。`governance:start` 还必须确认基线已提交、已推送且远程标签一致。 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** (879 symbols, 1062 relationships, 23 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.
+33
View File
@@ -2,6 +2,39 @@
本项目采用语义化版本。功能级变化请从 `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 ## 0.0.6 - 2026-08-13
- 建立上一发布版本开发数据库 Schema 基线生成、规范化和自动校验工具。 - 建立上一发布版本开发数据库 Schema 基线生成、规范化和自动校验工具。
+6 -7
View File
@@ -9,19 +9,18 @@ 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):Compose 只启动 Redis,应用从源码运行。 - [本地开发环境](docs/deployment/local-development.md):使用开发机已有 Redis,应用全部从源码运行。
- [Docker Compose 生产部署](docs/deployment/docker-compose-production.md):当前为应用脚手架落地前的配置契约骨架。 - [Ubuntu 源码生产部署](docs/deployment/ubuntu-source-production.md):项目唯一生产部署方式,支持 Ubuntu 22.04/24.04 LTS x86_64。
- [Ubuntu 源码生产部署](docs/deployment/ubuntu-source-production.md):支持 Ubuntu 22.04/24.04 LTS x86_64。
无秘密环境模板位于 `deploy/env/`。生产配置不进入 Git 或发布目录;Node.js 22 LTS、pnpm 10、Nginx 和基础设施由服务器管理员提供。 无秘密环境模板位于 `deploy/env/`。生产配置不进入 Git 或发布目录;Node.js 22.x、pnpm 10.25.0、Nginx 和外部基础设施由服务器管理员提供。项目不安装、启动、停止或删除 Redis、MySQL 和 RocketMQ。
## 开发入口 ## 开发入口
@@ -38,7 +37,7 @@ npm run schema:verify
npm run governance:start -- FEAT-MO-001 market-overview npm run governance:start -- FEAT-MO-001 market-overview
``` ```
Schema 命令只允许处理固定开发库;当前 MySQL 未启用时会为上一发布版本生成可验证的不适用清单,不会连接数据库或创建空 SQL。完整规则见 [开发流程规范](docs/governance/development-workflow.md)。 Schema 命令只允许处理固定开发库;导出器使用 Node.js `mysql2`,本机无需安装 MySQL Server 或 CLI。当前 MySQL 未启用时会为上一发布版本生成可验证的不适用清单,不会连接数据库或创建空 SQL;启用但无对象时生成 format v3 `captured_empty` 清单。完整规则见 [开发流程规范](docs/governance/development-workflow.md)。
## 项目仓库 ## 项目仓库
+1 -1
View File
@@ -1 +1 @@
0.0.6 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.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"
}
-23
View File
@@ -1,23 +0,0 @@
name: a-share-analysis-development
services:
redis:
image: redis:7.2.5-alpine
container_name: a-share-analysis-dev-redis
command: ["redis-server", "--appendonly", "yes"]
ports:
- "127.0.0.1:6379:6379"
volumes:
- ../../.local/redis:/data
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 5s
timeout: 3s
retries: 10
restart: unless-stopped
networks:
- a-share-analysis-dev
networks:
a-share-analysis-dev:
name: a-share-analysis-dev
-30
View File
@@ -1,30 +0,0 @@
# 应用镜像和启动入口将在 Web/Server 脚手架落地后验证。本文件先固定生产配置边界。
name: a-share-analysis-production
services:
web:
image: ${A_SHARE_WEB_IMAGE:?必须提供不可变 Web 镜像引用}
env_file: ${A_SHARE_WEB_ENV_FILE:-/etc/a-share-analysis/web.env}
ports:
- "127.0.0.1:8080:80"
restart: unless-stopped
api:
image: ${A_SHARE_SERVER_IMAGE:?必须提供不可变 Server 镜像引用}
command: ["node", "dist/apps/api/main.js"]
env_file: ${A_SHARE_API_ENV_FILE:-/etc/a-share-analysis/api.env}
ports:
- "127.0.0.1:3000:3000"
restart: unless-stopped
scheduler:
image: ${A_SHARE_SERVER_IMAGE:?必须提供不可变 Server 镜像引用}
command: ["node", "dist/apps/scheduler/main.js"]
env_file: ${A_SHARE_SCHEDULER_ENV_FILE:-/etc/a-share-analysis/scheduler.env}
restart: unless-stopped
worker:
image: ${A_SHARE_SERVER_IMAGE:?必须提供不可变 Server 镜像引用}
command: ["node", "dist/apps/worker/main.js"]
env_file: ${A_SHARE_WORKER_ENV_FILE:-/etc/a-share-analysis/worker.env}
restart: unless-stopped
+3
View File
@@ -4,6 +4,8 @@ APP_ENV=development
API_HOST=127.0.0.1 API_HOST=127.0.0.1
API_PORT=3000 API_PORT=3000
LOG_LEVEL=debug LOG_LEVEL=debug
TDX_BASE_URL=http://127.0.0.1:17710
TDX_TIMEOUT_MS=5000
# 第一阶段实际启用的 Redis。 # 第一阶段实际启用的 Redis。
REDIS_HOST=127.0.0.1 REDIS_HOST=127.0.0.1
@@ -22,6 +24,7 @@ MYSQL_USERNAME=
MYSQL_PASSWORD= MYSQL_PASSWORD=
MYSQL_CHARSET=utf8mb4 MYSQL_CHARSET=utf8mb4
MYSQL_COLLATION=utf8mb4_general_ci MYSQL_COLLATION=utf8mb4_general_ci
MYSQL_TIMEZONE=+08:00
# 第一阶段关闭付费 AI;启用后 BASE_URL、API_KEY 和 MODEL 变为必填。 # 第一阶段关闭付费 AI;启用后 BASE_URL、API_KEY 和 MODEL 变为必填。
AI_ENABLED=false AI_ENABLED=false
+6 -5
View File
@@ -11,8 +11,9 @@ REDIS_PASSWORD=
REDIS_DATABASE=1 REDIS_DATABASE=1
REDIS_TLS=false REDIS_TLS=false
# 第一阶段关闭 RabbitMQ,任务通过服务内 Adapter 调用。 # 第一阶段关闭 RocketMQ,任务通过服务内 MessageBusAdapter 调用。
RABBITMQ_ENABLED=false ROCKETMQ_ENABLED=false
RABBITMQ_URL= ROCKETMQ_NAMESRV_ADDR=127.0.0.1:9876
RABBITMQ_EXCHANGE=a-share-analysis ROCKETMQ_ENDPOINT=127.0.0.1:8081
RABBITMQ_PREFETCH=10 ROCKETMQ_TOPIC_PREFIX=a-share-analysis
ROCKETMQ_SEND_TIMEOUT_MS=3000
+1 -1
View File
@@ -1,5 +1,5 @@
# VITE 变量会进入浏览器,只允许公开配置。 # VITE 变量会进入浏览器,只允许公开配置。
VITE_APP_ENV=development VITE_APP_ENV=development
VITE_APP_TITLE=A-Share Analysis VITE_APP_TITLE=A-Share Analysis
VITE_API_BASE_URL=http://127.0.0.1:3000/api VITE_API_BASE_URL=
VITE_ENABLE_DEVTOOLS=true VITE_ENABLE_DEVTOOLS=true
+7 -4
View File
@@ -21,11 +21,14 @@ MYSQL_USERNAME=
MYSQL_PASSWORD= MYSQL_PASSWORD=
MYSQL_CHARSET=utf8mb4 MYSQL_CHARSET=utf8mb4
MYSQL_COLLATION=utf8mb4_general_ci MYSQL_COLLATION=utf8mb4_general_ci
MYSQL_TIMEZONE=+08:00
RABBITMQ_ENABLED=false ROCKETMQ_ENABLED=false
RABBITMQ_URL= ROCKETMQ_NAMESRV_ADDR=127.0.0.1:9876
RABBITMQ_EXCHANGE=a-share-analysis ROCKETMQ_ENDPOINT=127.0.0.1:8081
RABBITMQ_PREFETCH=10 ROCKETMQ_TOPIC_PREFIX=a-share-analysis
ROCKETMQ_CONSUMER_GROUP=a-share-analysis-worker
ROCKETMQ_CONSUMER_CONCURRENCY=4
AI_ENABLED=false AI_ENABLED=false
AI_BASE_URL= AI_BASE_URL=
+3
View File
@@ -3,6 +3,8 @@ APP_ENV=production
API_HOST=127.0.0.1 API_HOST=127.0.0.1
API_PORT=3000 API_PORT=3000
LOG_LEVEL=info LOG_LEVEL=info
TDX_BASE_URL=http://127.0.0.1:17710
TDX_TIMEOUT_MS=5000
REDIS_HOST=127.0.0.1 REDIS_HOST=127.0.0.1
REDIS_PORT=6379 REDIS_PORT=6379
@@ -20,6 +22,7 @@ MYSQL_USERNAME=
MYSQL_PASSWORD= MYSQL_PASSWORD=
MYSQL_CHARSET=utf8mb4 MYSQL_CHARSET=utf8mb4
MYSQL_COLLATION=utf8mb4_general_ci MYSQL_COLLATION=utf8mb4_general_ci
MYSQL_TIMEZONE=+08:00
AI_ENABLED=false AI_ENABLED=false
AI_BASE_URL= AI_BASE_URL=
+5 -4
View File
@@ -10,7 +10,8 @@ REDIS_PASSWORD=
REDIS_DATABASE=1 REDIS_DATABASE=1
REDIS_TLS=false REDIS_TLS=false
RABBITMQ_ENABLED=false ROCKETMQ_ENABLED=false
RABBITMQ_URL= ROCKETMQ_NAMESRV_ADDR=
RABBITMQ_EXCHANGE=a-share-analysis ROCKETMQ_ENDPOINT=
RABBITMQ_PREFETCH=10 ROCKETMQ_TOPIC_PREFIX=a-share-analysis
ROCKETMQ_SEND_TIMEOUT_MS=3000
+1 -1
View File
@@ -1,5 +1,5 @@
# VITE 变量会进入浏览器,只允许公开配置。 # VITE 变量会进入浏览器,只允许公开配置。
VITE_APP_ENV=production VITE_APP_ENV=production
VITE_APP_TITLE=A-Share Analysis VITE_APP_TITLE=A-Share Analysis
VITE_API_BASE_URL=/api VITE_API_BASE_URL=
VITE_ENABLE_DEVTOOLS=false VITE_ENABLE_DEVTOOLS=false
+7 -4
View File
@@ -21,11 +21,14 @@ MYSQL_USERNAME=
MYSQL_PASSWORD= MYSQL_PASSWORD=
MYSQL_CHARSET=utf8mb4 MYSQL_CHARSET=utf8mb4
MYSQL_COLLATION=utf8mb4_general_ci MYSQL_COLLATION=utf8mb4_general_ci
MYSQL_TIMEZONE=+08:00
RABBITMQ_ENABLED=false ROCKETMQ_ENABLED=false
RABBITMQ_URL= ROCKETMQ_NAMESRV_ADDR=
RABBITMQ_EXCHANGE=a-share-analysis ROCKETMQ_ENDPOINT=
RABBITMQ_PREFETCH=10 ROCKETMQ_TOPIC_PREFIX=a-share-analysis
ROCKETMQ_CONSUMER_GROUP=a-share-analysis-worker
ROCKETMQ_CONSUMER_CONCURRENCY=4
AI_ENABLED=false AI_ENABLED=false
AI_BASE_URL= AI_BASE_URL=
+4 -1
View File
@@ -9,11 +9,14 @@ User=a-share
Group=a-share Group=a-share
WorkingDirectory=/opt/a-share-analysis/current WorkingDirectory=/opt/a-share-analysis/current
EnvironmentFile=/etc/a-share-analysis/api.env EnvironmentFile=/etc/a-share-analysis/api.env
ExecStart=/usr/bin/node server/dist/apps/api/main.js 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 Restart=on-failure
RestartSec=5 RestartSec=5
NoNewPrivileges=true NoNewPrivileges=true
PrivateTmp=true PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
[Install] [Install]
WantedBy=multi-user.target WantedBy=multi-user.target
@@ -9,11 +9,14 @@ User=a-share
Group=a-share Group=a-share
WorkingDirectory=/opt/a-share-analysis/current WorkingDirectory=/opt/a-share-analysis/current
EnvironmentFile=/etc/a-share-analysis/scheduler.env EnvironmentFile=/etc/a-share-analysis/scheduler.env
ExecStart=/usr/bin/node server/dist/apps/scheduler/main.js 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 Restart=on-failure
RestartSec=5 RestartSec=5
NoNewPrivileges=true NoNewPrivileges=true
PrivateTmp=true PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
[Install] [Install]
WantedBy=multi-user.target WantedBy=multi-user.target
@@ -9,11 +9,14 @@ User=a-share
Group=a-share Group=a-share
WorkingDirectory=/opt/a-share-analysis/current WorkingDirectory=/opt/a-share-analysis/current
EnvironmentFile=/etc/a-share-analysis/worker.env EnvironmentFile=/etc/a-share-analysis/worker.env
ExecStart=/usr/bin/node server/dist/apps/worker/main.js 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 Restart=on-failure
RestartSec=5 RestartSec=5
NoNewPrivileges=true NoNewPrivileges=true
PrivateTmp=true PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
[Install] [Install]
WantedBy=multi-user.target 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 客户端选定后补充契约测试。
+34 -12
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,29 +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. 当前实施顺序
第一阶段先实现可交互的市场综合概览和稳定数据契约,再接入正式行情采集链路。用户、邀请、权限、会员和支付后置,不进入当前核心架构。 第一阶段先实现可交互的市场综合概览和稳定数据契约,再接入正式行情采集链路。用户、邀请、权限、会员和支付后置,不进入当前核心架构。
## 5. 环境与部署基线 ## 6. 环境与部署基线
- 应用运行环境只定义 `development` 与 `production`;生产环境禁止模拟数据、热更新、调试端口和开发默认值回退。 - 应用运行环境只定义 `development` 与 `production`;生产环境禁止模拟数据、热更新、调试端口和开发默认值回退。
- API、Scheduler、Worker、Web 分别拥有开发和生产模板;同一进程跨环境使用相同变量名,通过启动 Schema 校验条件必填项。 - API、Scheduler、Worker、Web 分别拥有开发和生产模板;同一进程跨环境使用相同变量名,通过启动 Schema 校验条件必填项。
- 本地开发使用 Docker Compose 只启动 Redis,应用进程从源码运行;第一阶段 MySQL 与 RabbitMQ 保持关闭。 - 本地开发直接连接开发机已开机自启的 Redis `127.0.0.1:6379`,应用进程从源码运行;第一阶段 MySQL 与 RocketMQ 保持关闭,需要联调时连接开发者独立维护的外部服务。
- 生产同时支持 Docker Compose 和 Ubuntu 22.04/24.04 LTS x86_64 源码部署,两者共用配置契约和进程边界。 - 生产只支持 Ubuntu 22.04/24.04 LTS x86_64 源码部署,不提供容器运行、构建、测试或部署入口。
- 源码部署由管理员预装 Node.js 22 LTS、pnpm 10、Nginx 和基础设施;项目只验证,不安装或修改系统软件源。 - 源码部署由管理员预装 Node.js 22.x、pnpm 10.25.0、Nginx 和外部基础设施;项目只验证,不安装、启动、停止或删除系统服务。
- 源码部署使用不可变发布目录、`a-share` 用户和 systemd 独立进程配置;生产 env 存放在 `/etc/a-share-analysis/`,不随代码版本切换覆盖。 - 源码部署使用不可变发布目录、`a-share` 用户和 systemd 独立进程配置;生产 env 存放在 `/etc/a-share-analysis/`,不随代码版本切换覆盖。
@@ -1,18 +0,0 @@
# Docker Compose 生产部署
生产 Docker Compose 使用不可变应用镜像和外部 env 文件。当前 `production.yml.example` 是部署契约骨架,应用镜像、健康检查和实际启动命令必须在 Web/Server 脚手架完成后验证,未验证前不得用于线上部署。
## 配置边界
- 从 `deploy/env/production/` 准备四份真实配置,存放在服务器 `/etc/a-share-analysis/` 或其他受控目录。
- Compose 通过外部路径加载,不在 YAML、镜像和 Git 中保存秘密。
- 镜像引用必须包含版本或内容摘要,禁止浮动 `latest`。
- 第一阶段只依赖 Redis;MySQL 和 RabbitMQ 功能开关保持关闭。
## 发布与回退
部署前验证镜像对应已推送提交或标签、环境 Schema、健康检查和数据目录。升级只修改不可变镜像引用;失败时恢复上一完整镜像集合和未改变的外部配置。禁止删除 Redis、MySQL 或 RabbitMQ 数据目录作为应用回退手段。
## 验证
应用脚手架落地后必须补充 `docker compose config`、服务健康检查、日志读取、优雅停止和回退演练证据。本版本不声称生产 Compose 已可运行。
+33 -12
View File
@@ -1,21 +1,42 @@
# 本地开发环境 # 本地开发环境
本地开发使用 Docker Compose 只启动 Redis,Web、API、Scheduler 和 Worker 从源码运行并使用开发环境模板。第一阶段不启动 MySQL 和 RabbitMQ。 本地开发由开发机提供 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 也是外部服务,项目脚本不负责安装、启动、停止或删除任何基础设施。
## 配置 ## 首次准备
从 `deploy/env/development/` 中对应的 `*.env.example` 创建本机 `*.env.local`。真实文件被 Git 忽略,不得写入生产地址或真实密钥。
## Redis
```bash ```bash
docker compose -f deploy/compose/development.yml up -d node --version
docker compose -f deploy/compose/development.yml ps pnpm --version
docker compose -f deploy/compose/development.yml down redis-cli -h 127.0.0.1 -p 6379 ping
pnpm install --frozen-lockfile
pnpm check:runtime
``` ```
Redis 只绑定 `127.0.0.1:6379`,数据写入仓库忽略的 `.local/redis/`。不得把该 Compose 文件用于生产。 Redis 必须返回 `PONG`。如果不可达,应先修复开发机外部服务;测试和应用不会创建替代实例。
## 应用状态 把 `deploy/env/development/*.env.example` 复制为同目录的 `*.env.local`。四份 local 文件被 Git 忽略:Web 只能含 `VITE_` 公开变量;API、Scheduler、Worker 按最小权限分别读取自己的配置,不共享一份全能 env。
Web 和 Server 尚未完成脚手架,因此本版本只交付配置契约和 Redis 开发环境。后续脚手架必须使用 Node.js 22 LTS、pnpm 10 和这些模板,不能在本文档中假装应用已经可启动。 固定开发 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、多目标推送、补传队列和无人值守运维继续延期,实施时单独立项并重新进行安全、性能和合规评估。
+32 -17
View File
@@ -1,35 +1,50 @@
# Ubuntu 源码生产部署 # Ubuntu 源码生产部署
正式支持 Ubuntu 22.04 LTS 与 Ubuntu 24.04 LTS 的 x86_64。服务器管理员预先提供 Node.js 22 LTS、pnpm 10、Nginx,以及 MySQL 5.7、Redis、RabbitMQ 或相应外部服务;项目不负责安装或升级这些软件,也不修改系统软件源。 这是项目唯一生产部署方式,支持 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 ```bash
uname -m uname -m
node --version node --version
pnpm --version pnpm --version
nginx -v pnpm install --frozen-lockfile
pnpm verify:release
``` ```
架构必须为 `x86_64`,Node.js 必须为 22 LTS,pnpm 必须为 10.x。不满足要求时终止部署。 架构必须为 `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` 中原地覆盖文件,也禁止只发布部分进程产物。
- 发布目录:`/opt/a-share-analysis/releases/<版本或提交>/`。 ## 配置与 systemd
- 当前版本:`/opt/a-share-analysis/current` 符号链接。
- 生产配置:`/etc/a-share-analysis/api.env`、`scheduler.env`、`worker.env`、`web.env`。
- 运行用户:非登录系统用户 `a-share`。
真实配置从仓库生产模板生成,但不得放入发布目录。API、Scheduler、Worker 的 systemd 单元分别通过 `EnvironmentFile=` 读取自己的配置;包含秘密的文件建议为 `root:a-share 0640`。 生产配置放在 `/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/
```
使用 `pnpm install --frozen-lockfile` 安装锁定依赖,在新发布目录构建 Web 和 Server。Web 静态文件由 Nginx 托管,API、Scheduler、Worker 运行编译后的 JavaScript。禁止 Vite 开发服务器、watch、调试端口和生产运行 TypeScript。 当前工程尚无业务表迁移;后续新增迁移后必须在切换 `current` 前单独执行并记录结果。生产环境禁止 `synchronize: true`,开发流程也禁止用生产数据库做 Schema 基线或连接测试。
当前应用尚未脚手架化,仓库中的 systemd 与 Nginx 文件是路径和权限契约示例,不能冒充已经验证的线上启动文件。后续应用功能必须补充实际构建、启动和健康检查验证。 ## 检查与回退
## 升级、检查与回退 使用 `systemctl status`、`journalctl -u`、HTTP 健康端点和 Nginx 同源访问结果确认发布。任一验证失败时,把 `/opt/a-share-analysis/current` 原子切回上一完整发布目录,重启三个 systemd 服务并重复健康检查。
在新的不可变发布目录完成安装、构建和配置校验后,原子切换 `current`,依次重启 API、Scheduler、Worker 并检查 `systemctl status`、`journalctl` 和 HTTP 健康端点。失败时切回上一完整目录并重启服务;生产配置不随版本切换覆盖。 `/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 收发和公网接收验证,原因是采集器与公网部署已延期。市场概览页面另按业务功能执行视觉验证。
@@ -1,5 +1,33 @@
# 设计 # 设计
首屏顺序为:市场结论、驱动与风险、核心指数、市场宽度与量能、板块概览、情绪与资金摘要。分析偏好保存在浏览器本地,页面只显示轻量的当前状态入口。 首屏顺序为:市场结论、驱动与风险、核心指数、市场宽度与量能、板块概览、资金趋势。分析偏好保存在浏览器本地,页面显示轻量的当前状态入口。Vue 不直连 TDX,由 Nest API 按模块拆分接口并隔离失败。
## 数据可用性
- `summary` 和 `indices`:使用 TDX K 线真实响应,展示来源、快照时间和指数涨跌。
- `breadth`:使用 TDX 指数快照的 `UpHome`、`DownHome` 汇总上证、深证和北证市场宽度;未返回的 `unchanged` 明确为 `null`,不得用总数推算。
- `sectors`:使用 TDX 系统分类中的一级行业(`get_stock_list(market=16)`)和批量日行情,按涨跌幅排序后展示重点强弱板块。
- `funds`:模块名称和口径为“成交额趋势”,使用核心交易所指数日行情的 `Amount` 汇总当前与前一交易日成交额;这不是主力净流入。
- 交易日对齐:交易日期必须是有效 `YYYYMMDD` 公历日期;指数和一级行业只有在前一根日期有效且严格早于当前日期时才计算涨跌,随后只保留最新交易日截面。成交额还要求日期与金额数组等长且前一交易日早于当前交易日,再按最新有效日期对汇总,避免畸形日期、数组错位或旧市场覆盖新数据。市场宽度额外并行读取一个核心指数日线作为日期参考。
- 新鲜度:日行情交易日期与 `Asia/Shanghai` 当前日历日期不同即标记 `delayed`;宽度沿用参考指数日期。首版不引入交易日历依赖,休市日保守标延迟并展示实际日期。
- 主力净流入和盘中新闻不在本次 TDX 首屏主链路中,后续通过独立补充数据源适配器接入,并在响应中标记来源与数据质量。
- 页面不把缺失或权限不足的指标降级为模拟值;单个来源失败只影响对应模块。
## 运行边界
本功能只读调用 TDX。MySQL、Redis、RocketMQ 仍为已规划基础设施,但当前没有业务状态、缓存或异步任务需要它们,因此本切片不启用。
## 安全策略与评估
- TDX 地址在配置层固定为 `http://127.0.0.1:17710`,API 是唯一访问边界,Vue 不直连行情服务。
- 请求只允许固定方法和公开行情参数;客户端限制超时与 1 MiB 响应,异常脱敏,不记录原始载荷、凭据或网络地址。
- 本功能不提供交易写入、账户操作、用户输入拼接查询或 AI 密钥下发;MySQL/Redis/RocketMQ 未启用,不读取生产数据库。
- 已通过客户端、服务、HTTP/OpenAPI、边界和 E2E 测试;生产授权、长期断线恢复和公网安全仍需后续评估。
## 性能目标与评估
- 五个模块并行请求,单个 TDX 请求受配置超时保护,模块失败不阻断其他模块。
- 客户端限制响应大小,避免异常行情载荷占用过多内存;本切片不增加数据库、缓存或消息队列负载。
- 已完成构建、浏览器桌面/390px 移动端验证;未进行 7×24 采集、峰值并发和长期网络抖动压测。
ETF监控、两融数据、大盘云图和实时消息仍是独立一级菜单,不属于短线和中长线切换。 ETF监控、两融数据、大盘云图和实时消息仍是独立一级菜单,不属于短线和中长线切换。
@@ -0,0 +1,55 @@
# FEAT-MO-001 开发总结
## 原始开发需求
实现市场概览首屏:结论优先展示市场状态、驱动与风险,并支持综合、短线、中长线视角和规则、AI、混合、对照分析选择;用户可从指数和板块入口进入后续详细分析。
## 需求与范围变化
- 数据源从早期“确定性模拟快照”调整为 TDX 只读直连,Nest API 访问本机 `127.0.0.1:17710`,Vue 不直接访问 TDX。
- API 按摘要、指数、市场宽度、板块和资金拆分,避免把整个首屏塞入单个接口。
- 当前 TDX 桥接已确认 `get_market_snapshot`、`get_stock_list` 和批量 `get_market_data` 可用;市场宽度、一级行业板块和成交额趋势改为真实 TDX 映射。主力净流入字段虽存在但当前实测为零值,盘中新闻无官方行情接口,因此两者延期到补充源功能。
- MySQL、Redis、RocketMQ 和 AI 仍不进入本切片运行链路;它们保留为后续基础设施边界。
## 实际完成需求
- 新增 TDX 配置校验、超时/响应大小限制、错误脱敏的 Node 客户端。
- 新增市场概览 DTO、服务、控制器、OpenAPI 契约和前端 Axios API 文件。
- 完成结论、驱动与风险、核心指数、市场宽度、板块、资金趋势模块,以及加载/错误/不可用状态。
- 完成分析视角和分析引擎切换,本地保存用户偏好。
- 真实 TDX 指数和摘要已通过本机隧道冒烟;未用指数或离线样本伪造缺失指标。
- 真实 TDX 市场宽度、一级行业和成交额趋势已通过本机桥接冒烟;资金模块明确使用成交额口径,不宣称主力净流入。
## 修复缺陷
- 修正 PRD 和实施计划中仍描述“模拟数据”的旧表述。
- 避免单个 TDX 模块失败导致整页失败,改为五个模块并行、独立状态。
- 对未注册桥接方法返回结构化原因,避免前端显示“实时”或空白数据。
- 修复 Vue TypeScript 单文件组件未被 ESLint 正确解析的问题,并为 E2E 测试进程补齐必需的本机 TDX 配置边界。
- 隔离应用外壳单测中的真实 Axios 请求,消除 JSDOM 网络错误噪声,保持页面测试只验证外壳职责。
- 根据代码 Review 修复畸形 TDX 字段被折算为零、缺市场成交额误报三市、交易日错位跨日求和、空行业目录误报 `fresh`、前端隐藏 `partial/delayed` 警告和零变化使用上涨色等缺陷,并补齐对应回归测试。
- 根据二次 Review 继续修复涨跌家数接受非整数、成交额受市场定义顺序影响、指数/板块跨交易日混排和后端从不生成 `delayed` 的边界;宽度增加核心指数日期参考,不新增基础设施或第三方依赖。
- 根据第三轮独立 Review 修复 8 位畸形日期被误认为有效公历日期、成交额接受倒序日期对与日期/金额数组错位,以及服务测试依赖运行当天的问题。
- 根据第四轮独立 Review 修复指数/板块未校验前一根 K 线日期的问题;非法、重复或倒序的前一日期不再生成涨跌信号。
## 未完成与延期项
- 主力净流入的权限/数据质量验证、盘中新闻补充源、真实图表和口径仍延期。
- “查看依据”抽屉、指数/板块详情页、AI 请求和用户体系另立功能。
- 本地验证不代表生产 7×24 采集稳定性、商业授权或公网部署安全性。
## 关键提交
- `9a965fa`、`d283ee3`、`6eb34b5`、`c2fa929`、`15a2500`、`27bc3c1`、`8261948`、`ff8ada8`、`49f6be9`、`7e4dcd9`、`ae2a7e0`、`c2fdfa6`
## 验证证据
- GitNexus 已完成提交前重新索引;上一修复提交的最终 staged 检测映射 66 个符号、21 条概览执行流并标记 critical。风险来自本功能修改核心概览服务、TDX 映射和前端数据面板,已由定向单测、HTTP/OpenAPI、前端状态回归、构建、浏览器视觉验证和 E2E 覆盖;未发现额外业务模块调用方。第三轮修复前又用 MCP 对 `toTradeDate` 和 `mapTurnoverTrend` 执行符号级影响分析,直接调用方仅在市场概览映射与测试范围。
- API 冒烟:`/breadth`、`/sectors`、`/funds` 均返回 `source=tdx,status=fresh`;完整结果和耗时见 `tdx-smoke-report.md`。
- 家庭 LAN 隧道二次复验:五个市场概览接口均为 `fresh`,指数 3 项、板块 8 项、成交额覆盖 3 个市场且交易日期完整;只保存脱敏统计。
- 日期对齐与延迟状态修复后,后端 60/60、完整全仓门禁和家庭 LAN 五接口当日 `fresh` 复验通过;第三轮日期真实性与测试时钟修复后,后端增加至 63/63;第四轮相邻日期修复后,后端增加至 67/67。`c2fdfa6` 推送前后均执行完整 `pnpm verify`,契约、Lint、格式、类型、全部测试、构建和 E2E 均通过。
- 前端单测、typecheck、build、后端 TDX/映射/服务/HTTP/OpenAPI 测试通过。
- `pnpm verify:e2e`:4/4 通过(桌面和移动端各覆盖页面与健康契约)。
- 浏览器桌面与 390px 移动视口验证无横向溢出,视角与引擎切换可用。
- 五轮独立 Review 均已归档:前四轮发现的数据完整性、状态、日期真实性/顺序、测试时钟和前一根日期校验问题均已关闭;第五轮最终结论为 `Ready to merge: Yes`,无 Critical、Important 或 Minor 问题。
- 开发 Schema 按用户确认跳过,沿用 `v0.0.10 captured_empty` 追溯边界,不读取生产库。
@@ -0,0 +1,26 @@
# GitNexus 开发后基线
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis/.worktrees/feat-mo-001-tdx-overview
Indexed: 8/18/2026, 9:13:11 PM
Indexed commit: c2fdfa6
Current commit: c2fdfa6
Status: ✅ up-to-date
```
## Git 已跟踪变更摘要
```text
AGENTS.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
```
## Git 工作区摘要
```text
M AGENTS.md
```
业务代码基线 `c2fdfa6` 已提交并推送;上述唯一工作区差异是 GitNexus 自动维护的入口说明,未纳入功能提交。
@@ -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,16 @@
# GitNexus 前后对比
## 开发前
- 基线:`gitnexus/before.md`、`gitnexus/implementation-baseline.md`。
- 目标是把模拟首屏改为 TDX 只读概览,并拆分五个 HTTP 模块接口。
## 开发后
- CLI 已完成最终重新索引,保留 85 条执行流并识别本功能影响路径。
- 宽范围修复曾识别 21 条概览执行流并标记 critical;最终相邻日期修复收敛为 3 条候选映射执行流并标记 medium。核心路径均有单测、HTTP/OpenAPI、前端状态、构建、视觉和 E2E 验证。
- 未新增消息、数据库、Redis、Scheduler、Worker 或部署运行时依赖。
## 差异结论
直接影响集中于 TDX API、市场概览服务、前端 API/页面和测试夹具;生产数据边界、基础设施暂不启用边界和回退路径保持不变。
@@ -0,0 +1,19 @@
# GitNexus 开发后变更检测
## 检测命令
```text
npx gitnexus analyze
npx gitnexus detect-changes --repo "$PWD" --scope staged
```
## 结果
- 索引:已完成最终增量更新。
- 暂存文件:11 个文件、24 个符号;GitNexus 自动改写的 `AGENTS.md` 已明确排除。
- 影响执行流:3 条,CLI 风险:medium。
- 主要执行流:`Candidates → ToNumber`、`Candidates → ToTradeDate` 与 `Candidates → MapDirection`;本轮未修改服务状态策略或跨模块契约。
## 处置
本轮 medium 来自指数/板块相邻日期比较的局部映射变更,不是未知跨业务扩散。已用 TDX 映射/服务测试、类型检查和 `git diff --check` 验证;前一提交已覆盖 HTTP/OpenAPI、前端状态、构建、浏览器视觉和 4/4 E2E,未发现用户、消息、数据库、Redis、RocketMQ、Scheduler、Worker、认证或部署调用方。当前环境已使用 GitNexus MCP 与同版本 CLI 交叉确认,没有将工具限制误判为低风险。
@@ -0,0 +1,36 @@
# GitNexus 开发前影响计划
- 功能编号:FEAT-MO-001
- 基线提交:`c0a6f5560584`
- 当前阶段:TDX 直连首页实施,已完成开发前门禁和最小只读协议验证
- 当前总体风险:LOW(新增边界尚未落地);TDX 客户端、API、OpenAPI 和 Web 首屏实现后按符号补充
## 直接与间接影响
### TDX 双路径开发连接
- 正式行情来源确定为 TDX;家庭局域网和外部 Tailscale 只改变 Mac 到同一 Windows `sshd` 的网络路径。
- TDX Bridge 的稳定入口固定为 Mac 回环地址 `127.0.0.1:17710`,市场概览、规则分析、AI 分析和未来 HTTP 契约不得依赖家庭地址、Tailscale 地址或 TDX 原始字段。
- 当前仓库尚无 TDX Provider 或市场概览运行时符号;本次将新增 API 业务模块、TDX 客户端、OpenAPI 契约和 Web 首屏。新增符号的直接调用链将在实现后重新索引并执行变更检测。
- 首页业务设计确认后,必须对 `App.vue`、`createAppRouter`、后端模块装配、HTTP DTO 和新增市场概览符号分别执行 upstream impact。HIGH 或 CRITICAL 结果先告知用户再修改。
## 跨模块同步修改
- HTTP/OpenAPI:本次新增版本化市场概览 DTO 和五个只读路径,并重新生成 OpenAPI 契约。
- Web API 与 adapter:本次新增 `web/src/api/market-overview/index.ts`,页面只能经 Axios 封装和 ViewModel 消费数据。
- 消息契约、Redis、MySQL、Scheduler、Worker:本次首屏不启用业务链路,仅保留既有架构边界;正式采集、快照持久化、缓存和异步分发仍按独立功能立项。
- 配置部署:真实地址、用户名、密钥和控制套接字只保留在开发机,不进入仓库、环境模板或前端构建物。
- 测试:两种 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`。本功能不借该例外修改数据库结构、读取生产数据库或声称发布门禁通过。
@@ -0,0 +1,32 @@
# FEAT-MO-001 实施前门禁基线
- 功能编号:FEAT-MO-001
- 分支:`codex/feat-mo-001-tdx-overview`
- 基线提交:`d283ee319692d4550149c591d4fe7f522c0bc6b8`
- 记录时间:2026-08-18 13:04 CST
## Schema
- `pnpm schema:baseline`:通过,`v0.0.10 captured_empty`。
- `pnpm schema:verify`:通过,`v0.0.10 captured_empty`。
- 本次没有数据库结构变更,不读取生产数据库。
## GitNexus
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis/.worktrees/feat-mo-001-tdx-overview
Indexed commit: d283ee3
Current commit: d283ee3
Status: up-to-date
```
影响分析结果:
- `ApiModule` upstream:LOW,直接消费者为 API `main.ts` 和进程冒烟测试。
- `createAppRouter` upstream:LOW,无直接执行流消费者。
- `createRequestClient` upstream:LOW,直接使用方为 Web API 健康请求模块。
- `ApiModule.register` 复合名称未被 CLI 解析,已用 `ApiModule` 类上下文、`main.ts` 静态引用和 `register` 候选结果补齐证据;没有 HIGH/CRITICAL 结果。
## 工作区说明
主工作区已有用户修改的 `AGENTS.md`,本功能分支不将其纳入提交。功能代码只在本隔离工作区开发。
@@ -1,8 +1,11 @@
# 实施计划 # 实施计划
1. 初始化 Vue 3、Vite、TypeScript和 Dart Sass。 1. ~~初始化 Vue 3、Vite、TypeScript 和 Dart Sass。~~ 已完成。
2. 建立市场快照类型和确定性模拟数据。 2. ~~建立 TDX 配置、Node fetch 客户端、DTO、映射和五个模块接口。~~ 已完成。
3. 实现终端外壳、数据状态和结论区。 3. ~~实现终端外壳、分模块加载状态和结论区。~~ 已完成。
4. 实现指数、宽度、量能、板块、情绪与资金模块。 4. ~~实现指数、宽度、板块和资金模块;不可用指标使用结构化状态。~~ 已完成。
5. 实现分析偏好菜单和依据抽屉。 5. ~~实现分析偏好菜单和本地持久化。~~ 已完成;依据抽屉和详情页入口延期至独立功能。
6. 完成测试、构建、浏览器验证和视觉对比。 6. ~~完成单元测试、类型检查、构建、接口冒烟、浏览器桌面/移动端视觉验证。~~ 已完成。
7. ~~补齐 TDX 市场宽度、一级行业板块和成交额趋势映射。~~ 已确认官方接口和本机桥接可用;主力净流入与盘中新闻保留为补充源需求。
8. 更新 DTO、OpenAPI 类型和前端组件,使真实数据状态、单位和 `unchanged=null` 口径可见。
9. 完成 TDX 真实响应夹具、错误隔离、类型、构建和浏览器视觉验证;Review 后再收口功能档案。
@@ -1,12 +1,12 @@
id: FEAT-MO-001 id: FEAT-MO-001
name: 市场综合概览 name: 市场综合概览
slug: market-overview slug: market-overview
status: approved status: in_review
owner: project owner: project
created_at: 2026-08-12 created_at: 2026-08-12
requirements: requirements.md requirements: requirements.md
prd: prd.md prd: prd.md
design: design.md design: design.md
implementation_plan: implementation-plan.md implementation_plan: implementation-plan.md
traceability_note: 开发尚未开始,GitNexus与QA证据将在开发门禁执行时创建 traceability_note: 已完成 TDX 直连开发、GitNexus 前后分析、接口冒烟、桌面/移动端视觉验证、独立代码 Review 和规范 Review;开发完成门禁已通过,待合并发布
release: unreleased release: unreleased
@@ -23,7 +23,7 @@
## 非目标 ## 非目标
- 不做自选股、持仓、笔记、交易计划、社区、荐股、跟单和公开组合。 - 不做自选股、持仓、笔记、交易计划、社区、荐股、跟单和公开组合。
- 本切片不接正式行情源、RabbitMQ、MySQL、Redis和付费 AI。 - 本切片直接接入已验证的 TDX 只读桥接层;不接入 RocketMQ、MySQL、Redis 和付费 AI。
- 本切片不实现用户、邀请、会员、订阅和支付。 - 本切片不实现用户、邀请、会员、订阅和支付。
- ETF监控、两融数据、大盘云图和实时消息仍是独立一级模块。 - ETF监控、两融数据、大盘云图和实时消息仍是独立一级模块。
@@ -41,7 +41,7 @@
| 编号 | 优先级 | 需求 | 可观察结果 | | 编号 | 优先级 | 需求 | 可观察结果 |
|---|---|---|---| |---|---|---|---|
| FR-001 | P0 | 结论优先展示市场定性 | 首屏顶部出现一句结论、市场状态、量能状态和情绪状态 | | FR-001 | P0 | 结论优先展示市场定性 | 首屏顶部出现一句结论、市场状态、量能状态和情绪状态 |
| FR-002 | P0 | 展示驱动与风险 | 结论下方并列显示至少三条驱动和三条风险证据 | | FR-002 | P0 | 展示驱动与风险 | 结论下方并列显示已由 TDX 支持的驱动和风险证据;缺少口径时明确标记 |
| FR-003 | P0 | 展示数据新鲜度 | 页面显示交易状态、数据更新时间和正常/延迟/不完整状态 | | FR-003 | P0 | 展示数据新鲜度 | 页面显示交易状态、数据更新时间和正常/延迟/不完整状态 |
| FR-004 | P0 | 提供分析偏好 | 可选择综合/短线/中长线和规则/AI/混合/对照,并在本地保存默认值 | | FR-004 | P0 | 提供分析偏好 | 可选择综合/短线/中长线和规则/AI/混合/对照,并在本地保存默认值 |
| FR-005 | P1 | 展示市场证据模块 | 指数、宽度、量能、板块、情绪和资金摘要可阅读 | | FR-005 | P1 | 展示市场证据模块 | 指数、宽度、量能、板块、情绪和资金摘要可阅读 |
@@ -50,10 +50,16 @@
## 数据与口径 ## 数据与口径
首个切片使用确定性模拟快照。字段仍必须包含交易日期、快照时间、来源状态、完整性和单位,以便以后无结构变更地替换为后端 API。 首个切片由 Nest API 直接读取 TDX 只读桥接层。指数和摘要使用真实 TDX K 线映射;市场宽度使用三市场指数快照,板块使用一级行业目录与日行情,量能使用三市场指数成交额汇总。主力净流入和盘中新闻不在本切片 TDX 主链路中,必须保持明确的补充源边界,不得用指数或离线样本冒充。所有响应仍包含交易日期、快照时间、来源状态、完整性和单位。
A 股使用红涨绿跌。成交额统一展示为亿元,比例明确使用百分比。历史数据和低频资金数据必须显示实际数据日期,旧数据不得标记为实时。 A 股使用红涨绿跌。成交额统一展示为亿元,比例明确使用百分比。历史数据和低频资金数据必须显示实际数据日期,旧数据不得标记为实时。
TDX 交易日期必须通过真实公历日期校验。成交额当前/前一日金额必须与同索引日期对齐,且前一交易日严格早于当前交易日;不满足条件的市场不参与汇总,也不得抢占最新日期截面。
指数和板块涨跌幅必须同时具备有效且严格递增的相邻日期。前一根日期非法、重复或晚于当前日期时,指数只展示当前价而不生成涨跌信号,板块不进入强弱排序。
首个切片不引入交易日历依赖:指数、一级行业和成交额的最新交易日期与 `Asia/Shanghai` 当前日历日期不同即标记 `delayed`;市场宽度快照缺少日期字段,使用同批核心指数日线作为日期参考。周末和法定休市日会保守显示延迟并同时展示实际交易日期,后续接入权威交易日历后再细化“最新交易日”语义。
## 状态与异常 ## 状态与异常
- 交易中:显示分钟级更新时间。 - 交易中:显示分钟级更新时间。
@@ -77,7 +83,7 @@ A 股使用红涨绿跌。成交额统一展示为亿元,比例明确使用百
- Given 页面加载有效快照,When 用户进入市场概览,Then 结论、驱动、风险和更新时间在首屏可见。 - Given 页面加载有效快照,When 用户进入市场概览,Then 结论、驱动、风险和更新时间在首屏可见。
- Given 用户打开分析状态入口,When 切换周期或引擎,Then 页面状态立即更新且可选择设为默认。 - Given 用户打开分析状态入口,When 切换周期或引擎,Then 页面状态立即更新且可选择设为默认。
- Given 数据快照被标记为延迟,When 页面渲染,Then 最近有效值保留并明确显示延迟,不能显示“实时”。 - Given 数据快照被标记为延迟,When 页面渲染,Then 最近有效值保留并明确显示延迟,不能显示“实时”。
- Given 用户点击查看依据,When 抽屉打开,Then 能看到指标名称、数值、口径和更新时间。 - Given 用户看到查看依据入口,When 后续依据抽屉功能立项,Then 能看到指标名称、数值、口径和更新时间;本切片只保留入口。
## 风险与依赖 ## 风险与依赖
@@ -92,3 +98,5 @@ A 股使用红涨绿跌。成交额统一展示为亿元,比例明确使用百
## 变更记录 ## 变更记录
- 0.1:建立首版 PRD,补充结论优先、分析偏好和异常状态。 - 0.1:建立首版 PRD,补充结论优先、分析偏好和异常状态。
- 0.2:根据 TDX 实连验证修正数据源、可用性边界和未接入基础设施范围。
- 0.3:核对官方行情接口后确认市场宽度、一级行业板块和成交额趋势可由 TDX 直接提供;主力净流入与盘中新闻保留补充源边界。
@@ -0,0 +1,19 @@
# FEAT-MO-001 测试结果
## 自动化结果
- 前端 Vitest:8 个文件、20 个测试通过。
- 后端 Vitest:11 个文件、67 个测试通过;API 启动器 Node 测试 2/2 通过,Schema、治理、边界和部署门禁通过。
- `pnpm verify:e2e`:桌面/移动端页面和健康契约共 4 个测试通过。
- `pnpm typecheck`、`pnpm build`、`pnpm format:check`:通过。
- ESLint:0 error,保留 35 条 Vue 风格 warning,不阻断门禁。
## 手工结果
- `GET /api/v1/market-overview/indices` 和 `summary` 返回真实 TDX `fresh` 快照。
- TDX 隧道未监听时,五个模块均返回明确不可用状态,未伪造指标;切换到家庭 LAN 隧道后,`summary`、`indices`、`breadth`、`sectors`、`funds` 均返回 `source=tdx,status=fresh`。
- 家庭 LAN 真实冒烟中,指数返回 3 项、板块返回 8 项、成交额覆盖 3 个市场且交易日期完整;未保存真实价格或成交额数值。
- 修复日期对齐和延迟状态后再次通过家庭 LAN 真实冒烟,五个接口在当日数据下仍为 `fresh` 且无 warning。
- 第三轮 Review 修复后,非法月份/日期、倒序日期对和日期/金额数组错位均被映射层排除;服务测试统一冻结时钟,不依赖执行当天。
- 第四轮 Review 修复后,指数前一根非法、重复或倒序日期不再生成涨跌幅,板块对应记录不进入强弱排序。
- 桌面默认视口与 390px 移动视口无横向溢出;视角和引擎切换可用。
@@ -0,0 +1,20 @@
# FEAT-MO-001 视觉 QA
## 验证范围
- 桌面默认视口:顶部应用识别、结论区、驱动/风险、核心指数和不可用模块均可见。
- 移动视口:390×844,首屏按单列排列,标题、状态、指数和模块说明不遮挡。
## 结果
- 通过:2026-08-18 使用本地 API/Web 实际页面复验;桌面视口为 `1440×900`,移动视口为 `390×844`。
- 通过:桌面 `clientWidth=1440, scrollWidth=1440`,移动端 `clientWidth=390, scrollWidth=390`;移动端六个主要区块左右边界均位于 `14px~376px`,未发生页面级或区块级横向溢出。
- 通过:综合、短线、中长线切换和规则/AI/混合/对照选择有可见状态。
- 通过:实际切换到“综合”和“混合”后,按钮激活态和下拉选中项同步更新。
- 通过:家庭 LAN 隧道 `127.0.0.1:17710` 下完成真实 TDX 行情复验;摘要、3 个核心指数、市场宽度、8 个一级行业板块和 3 市成交额均显示 `source=tdx`、`status=fresh`,无模块警告。
- 通过:桌面与移动端浏览器控制台均无 `warning` 或 `error`;移动端仅有 Vite 开发服务器连接调试信息。
- 通过:真实行情移动端 `clientWidth=390, scrollWidth=390`,无页面级横向溢出、内部文字截断或控件重叠;长风险说明、指数数值、板块标签和成交额均完整展示。
## 残余项
依据抽屉、指数/板块详情页和真实图表尚未立项,不作为本次首屏视觉验收项。真实 TDX 接口值、交易日期和模块状态的逐项证据见 `tdx-smoke-report.md`;本次视觉复验使用同一家庭 LAN 隧道和真实接口响应,不使用离线样本伪装实时行情。
@@ -0,0 +1,17 @@
# FEAT-MO-001 发布说明
## 本次发布
- 新增 TDX 直连的市场概览首屏和五个模块 API。
- 支持综合、短线、中长线视角与规则、AI、混合、对照偏好选择。
- 市场宽度、一级行业强弱和成交额趋势接入真实 TDX 数据,并对空数据、部分数据、日期不一致和延迟状态显示明确边界。
- 指数和板块按最新交易日截面对齐,成交额按最新有效交易日期对汇总;后端根据上海当前日历日期实际生成 `delayed`,市场宽度使用同批核心指数日期参考。
- 拒绝非法公历日期、倒序交易日期以及日期/金额数组错位的 TDX 数据,避免异常市场抢占最新截面或产生时间倒置的成交额趋势。
- 指数和板块仅使用有效且严格递增的相邻 K 线日期计算涨跌,前一日期非法、重复或倒序时不生成市场强弱信号。
- 明确显示 TDX 来源、快照时间、交易日期、市场覆盖数和模块级错误。
## 明确不包含
- 不启用 MySQL、Redis、RocketMQ 或 AI 运行链路。
- 不包含用户体系、详情页、依据抽屉、交易操作和荐股能力。
- 不包含主力净流入、盘中新闻、真实图表和详情页;这些能力需另立补充数据源和功能需求。
@@ -2,4 +2,12 @@
首屏为“市场概览”模块中的综合概览,采用结论优先。市场概览内部通过轻量分析状态入口切换综合、短线和中长线视角,并支持规则、AI、混合与对照分析。 首屏为“市场概览”模块中的综合概览,采用结论优先。市场概览内部通过轻量分析状态入口切换综合、短线和中长线视角,并支持规则、AI、混合与对照分析。
当前切片仅开发 Vue 3 可交互首屏和本地模拟数据,不接用户体系和正式数据链路。 当前切片开发 Vue 3 可交互首屏,Nest API 通过 TDX 只读桥接层提供真实指数、市场宽度、板块和成交额趋势;主力净流入与盘中新闻不作为本次 TDX 主链路指标,不使用离线样本。不接用户体系,也不启用 MySQL、Redis、RocketMQ 或 AI 运行链路。
## 本次实际范围
- 已完成综合、短线、中长线视角切换,以及规则、AI、混合、对照偏好选择;偏好只保存于浏览器本地。
- 已完成按摘要、指数、宽度、板块、资金拆分的五个 HTTP 接口和前端 API 封装。
- 已完成 TDX 请求超时、响应大小限制、错误脱敏和模块级失败隔离。
- 已确认并接入 TDX 市场宽度、一级行业板块和成交额趋势;资金模块明确不等同于主力净流入,`unchanged` 无可靠总数时返回 `null`。
- 详情页和“查看依据”抽屉只保留入口,另立需求实现,不在本次发布范围内。
@@ -0,0 +1,86 @@
# 代码 Review
## 首轮独立 Review
- 对比基线:`8261948`
- 审查提交:`ff8ada8`
- 结论:`Ready to merge: No`
首轮发现及处置:
1. 畸形 `UpHome/DownHome` 被折算为零并误标 `fresh`:改为有限、非负且成对校验,无效市场整体排除并按有效市场数返回 `fresh/partial/unavailable`。
2. 成交额缺市场或交易日错位仍误标三市实时数据:只汇总非负金额和一致交易日,公开 `marketCount`、`tradeDate`、`previousTradeDate`,缺市场返回 `partial`。
3. 空板块目录误标 `fresh`:一级行业为空时直接返回 `unavailable`,且只保留存在相邻两日收盘价和有效涨跌幅的板块。
4. 前端隐藏 `partial/delayed` 警告:宽度、板块和成交额面板均展示非 `fresh` 状态提示,并展示板块与成交额真实交易日期。
5. PRD、发布说明和 Review 文档残留旧口径:已同步更正为真实 TDX 宽度、一级行业与成交额趋势口径,主力净流入和新闻仍明确延期。
6. 异常分支测试不足:新增畸形宽度、部分市场、错位交易日、空行业目录、额外字段隔离、前端状态提示和零变化中性色回归测试。
次要问题也已同步处理:OpenAPI `required + nullable` 定义、板块 DTO 额外 `price` 字段泄露、成交额零变化上涨色和新增映射中文口径注释。
## 范围
覆盖 TDX 客户端、市场概览后端模块、OpenAPI/前端契约、Axios API 封装、Vue 首屏组件和对应测试。
## 检查结果
- 通过:API 按模块拆分,前端请求集中在 `web/src/api/market-overview/index.ts`,Vue 不直连 TDX。
- 通过:真实指数和摘要字段经过 DTO/映射;桥接层未提供的方法返回结构化 `unavailable`,没有模拟数据冒充。
- 通过:模块并行加载且独立处理异常;TDX 请求有固定回环地址、超时、响应大小限制和错误脱敏。
- 通过:未将密码、令牌、行情原始载荷或生产数据写入代码、文档和日志。
- 通过:E2E 测试夹具显式声明回环 TDX 配置但不要求 TDX 可达,避免测试环境绕过正式配置校验。
## 安全与残余风险
- TDX 只读边界固定为回环地址,客户端限制超时和响应大小并脱敏异常;未接入交易、AI 密钥、数据库写入或生产数据。
- 残余风险是 TDX 桥接方法覆盖不全、市场数据授权和生产 7×24 稳定性尚未验证,已在需求和回退说明中标明。
## GitNexus 与同步修改
开发前已保存 GitNexus 影响计划。早期提交曾映射 11 条执行流并标记 high;`49f6be9` 修复提交的 staged 检测映射 20 个文件、67 个符号、16 条执行流并标记 critical。critical 来自市场概览核心服务、TDX 映射和前端数据面板,不是未知跨业务扩散;未发现数据库、Redis、RocketMQ、Scheduler、Worker、认证或部署调用方。当前环境未暴露 GitNexus MCP 变更检测工具,已使用同版本 CLI 和 worktree 绝对路径保留证据。
## 性能与资源影响
- 五个模块并行请求,单请求超时并限制 1 MiB 响应;市场宽度并行增加一次单指数、单日线日期参考请求,不引入 MySQL、Redis、RocketMQ 在线负载。
- 未进行 7×24、断线重连和生产压测;主力净流入、盘中新闻、权威交易日历及详情页仍待独立功能。
- ESLint 对 Vue 单文件组件仅保留 35 条既有风格 warning,无 error;格式、类型和构建门禁均通过。
## 二次独立 Review
- 审查范围:`ff8ada8..49f6be9`
- 结论:`Ready to merge: No`
- Critical:无。
- Important:宽度仍接受小数/十六进制等非计数值;成交额以首个市场日期为锚;板块跨交易日混排仍标 `fresh`;后端没有真实 `delayed` 路径。
- Minor:GitNexus 风险/执行流和 TDX 已接入范围存在旧口径。
上述问题已按 TDD 增加失败用例后修复:宽度只接受十进制非负安全整数;指数/板块只保留最新交易日;成交额选择最新有效日期对;四个后端日行情路径均具备 `delayed` 判定,宽度使用同批指数日期参考。修复后等待再次独立 Review。
## 第三轮独立 Review
- 审查范围:`49f6be9..7e4dcd9`
- 结论:`Ready to merge: No`
- Critical:无。
- Important:8 位数字日期未验证真实公历语义,成交额未强制前一交易日早于当前日且未验证日期/金额数组对齐;服务测试固定使用 `20260818` 行情却没有统一冻结系统时间,会在自然日期变化后失败。
- Minor:开发总结未包含 `7e4dcd9`,GitNexus 仍保留上一轮 16 条执行流口径。
处置:按 TDD 先得到 3 个预期失败,再增加真实公历日期、日期顺序和数组对齐校验;服务测试套件统一冻结上海日期,并由单个延迟用例显式切换。修复后后端 Vitest `63/63`、启动器 `2/2` 和类型检查通过,等待再次独立 Review。
## 第四轮独立 Review
- 审查范围:`49f6be9..ae2a7e0`
- 结论:`Ready to merge: No`
- Critical:无。
- Important:指数和板块只校验当前 K 线日期,前一根日期非法、重复或倒序时仍计算涨跌;最终治理材料仍处于 `pending`,尚未执行 `governance:finish`。
- Minor:无新增。
处置:按 TDD 先得到 4 个预期失败,再要求前一日期有效且严格早于当前日期;无可比前收盘时指数保留当前价但不生成涨跌,板块不进入强弱排序。后端 Vitest 增加至 `67/67`。治理状态保持 `pending` 是有意的门禁顺序:需本修复再次独立 Review 通过后,才能合法写入 `passed` 并运行 `governance:finish`。
## 第五轮最终独立 Review
- 审查范围:`ae2a7e0..c2fdfa6`
- 结论:`Ready to merge: Yes`
- Critical:无。
- Important:无;上一轮指数/板块前一根 K 线日期校验问题已关闭。
- Minor:无。
- 验证:指数非法、重复、倒序前一日期参数化用例和板块过滤用例齐全;后端 Vitest `67/67`、启动器 `2/2`、服务端类型检查与 `git diff --check` 均通过。安全、性能及 PRD/设计/测试/QA 口径一致。
最终结论:passed
@@ -0,0 +1,29 @@
# 开发规范符合性 Review
## 安全、性能与架构检查
- 已建立并更新 PRD、需求、设计、实施计划、测试计划、开发总结和 Review 文档。
- 已记录安全策略、性能目标、GitNexus 影响、验证证据、范围变化和残余风险。
- 后端按业务模块组织并使用 DTO/映射;前端请求通过统一 Axios 封装,业务 API 独立存放。
- 代码注释集中在配置边界、异常恢复和偏好存储等非显然逻辑,没有逐行噪声注释。
- 未启用 MySQL、Redis、RocketMQ;本切片没有伪造基础设施已接入,也没有触碰生产数据库。
- Git 提交和推送将在 Review 通过后按中文 Conventional Commit 执行;不修改 Git 全局配置。
## GitNexus 与开发总结检查
- 开发前影响计划、开发后索引、变更检测和风险处置已归档。
- 开发总结记录原始需求、范围变化、实际完成、修复缺陷、延期项、提交和验证证据。
- QA、发布说明和回退说明与本功能档案保持同一功能编号。
## 首轮问题同步检查
- 数据完整性、状态语义、OpenAPI nullable、DTO 输出边界和前端降级提示均已补齐回归测试。
- PRD、发布说明、测试计划和开发总结已同步实际口径,避免实现与文档分叉。
- 浏览器复验覆盖桌面与 `390×844` 移动视口;当前 TDX 隧道未监听时只确认结构化降级,历史真实行情冒烟证据保持独立。
- 二次独立 Review 发现的严格整数、日期对齐和真实 `delayed` 语义已按 TDD 修复;后端新增 9 个断言并完成家庭 LAN 当日行情复验。
- 新鲜度暂按上海当前日历日期保守判断,周末和法定休市日可能显示 `delayed`;该残余边界已同步 PRD、设计和测试计划,不伪装成交易日历已接入。
- 第三轮 Review 的日期真实性、先后顺序、数组对齐和测试时钟问题已按 TDD 修复;需求、设计、测试计划、测试结果、发布说明和开发总结已同步。
- 第四轮 Review 的前一根日期校验问题已按 TDD 修复;治理结论继续保持 `pending`,等待本次代码修复再次独立确认。
- 第五轮最终独立 Review 无 Critical、Important 或 Minor 问题并给出 `Ready to merge: Yes`;中文提交、Gitea 推送、GitNexus、完整门禁和视觉证据均已复核。
最终结论:passed
@@ -0,0 +1,17 @@
# FEAT-MO-001 回退说明
## 触发条件
- TDX 请求错误导致核心指数无法展示或页面加载阻断。
- 发现前端横向溢出、来源状态误标为实时,或不可用指标被伪造。
- 生产部署验证发现配置边界、权限或错误脱敏回归。
## 操作
1. 停止当前 API/Web systemd 服务,保留日志和失败快照摘要,不保存原始行情载荷。
2. 回退到上一个已推送的 Gitea 提交/标签,重新执行源码构建和 `pnpm verify:source`。
3. 恢复 TDX 桥接隧道后只做只读接口冒烟;确认通过前不得重新对外开放。
## 数据边界
本功能没有写入 MySQL、Redis 或 RocketMQ,也没有数据库迁移;回退不执行生产数据库操作。开发 Schema 继续遵循仅读取开发库的门禁。
@@ -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,34 @@
# FEAT-MO-001 TDX 只读冒烟报告
- 验证时间:2026-08-18 17:21 CST
- 网络场景:本机回环桥接(TDX 服务可达)
- 本机业务入口:`127.0.0.1:17710`
- API 入口:`127.0.0.1:3000/api/v1/market-overview`
- 请求方式:HTTP GET(业务 API)及桥接层 HTTP POST JSON
- 请求类型:市场宽度、一级行业板块、成交额趋势只读请求
- 原始载荷:未保存
## 结果
- 三条业务接口均返回 HTTP `200`,响应状态均为 `fresh`,`source` 均为 `tdx`。
- `/breadth`:成功汇总上证、深证和北证指数快照中的 `UpHome`、`DownHome`;`unchanged` 返回 `null`,未进行总数推算。
- `/sectors`:成功读取一级行业目录并批量获取日行情,按涨跌幅排序返回前 8 项。
- `/funds`:成功汇总三个交易所指数日行情 `Amount`,按万元转换为亿元并计算较前一交易日变化;该指标展示为“成交额趋势”,不宣称主力净流入。
- 端到端耗时:市场宽度约 `0.11s`,一级行业约 `0.27s`,成交额趋势约 `0.12s`(单次本机冒烟,不代表生产 SLA)。
- 未调用交易、账户、自选、写入接口;未保存真实行情原始载荷。
## 家庭 LAN 二次复验
- 验证时间:2026-08-18 19:35 CST。
- 先按开发手册切换到家庭 LAN SSH 别名,确认本机 `127.0.0.1:17710` 的监听者为本次 SSH 隧道;平台配置仍只使用回环地址。
- 桥接层最小只读 HTTP POST 成功,没有调用交易、账户、自选或写入方法。
- Nest API 的 `/summary`、`/indices`、`/breadth`、`/sectors`、`/funds` 均返回 HTTP `200`、`source=tdx`、`status=fresh` 且无 warning。
- `/indices` 返回 3 项,`/sectors` 返回 8 项;`/breadth` 返回有限且非负的涨跌家数;`/funds` 返回 `marketCount=3`,当前和上一交易日期均存在且不同。
- 本次只记录结构、状态、数量和日期完整性,不记录真实价格、成交额数值、家庭网络地址、SSH 用户或原始响应。
- 完成严格整数、最新交易日截面和后端 `delayed` 修复后再次复验:五个接口在当日行情下仍为 `fresh` 且无 warning,证明新增新鲜度判断未误伤当前日期数据。
## 脱敏与限制
- 报告不保存真实价格、成交量、家庭网络地址、Tailscale 地址、SSH 用户、密钥或完整响应。
- 本报告只证明当前开发机到 TDX 的只读接口和本次映射可达,不证明 7×24 生产采集、商业再分发授权、主力净流入口径或盘中新闻接口已经可用。
- 主力净流入和盘中新闻继续保留为补充数据源需求;后续接入必须单独记录来源、权限、口径和数据质量。
@@ -3,6 +3,36 @@
- 结论、驱动和风险在首屏可见。 - 结论、驱动和风险在首屏可见。
- 分析状态可以临时切换并保存默认值。 - 分析状态可以临时切换并保存默认值。
- 依据抽屉能够打开和关闭。 - 依据抽屉能够打开和关闭。
- 时间范围切换更新图表。 - 五个模块并行请求,一个模块失败不阻断其他模块。
- 真实 TDX 指数、市场宽度、一级行业板块和成交额趋势响应可映射;主力净流入与盘中新闻不以占位值伪造。
- 加载、部分数据、过期和错误状态具有明确文案。 - 加载、部分数据、过期和错误状态具有明确文案。
- 桌面和窄窗口不出现阻断核心内容的溢出。 - 桌面和窄窗口不出现阻断核心内容的溢出。
## 已执行证据
- 前端 Vitest、typecheck、build:通过。
- 后端 TDX 客户端、映射、服务、HTTP/OpenAPI 测试:通过。
- `curl` 冒烟:`/breadth`、`/sectors`、`/funds` 均返回 `source=tdx,status=fresh`;分别验证 `UpHome/DownHome` 汇总、一级行业排序和成交额单位转换。
- 异常映射:覆盖畸形涨跌家数字段(小数、指数、十六进制和超出安全整数)、当前及前一根非法公历日期、相邻日期重复/倒序、空一级行业目录、单根板块 K 线、指数/板块混合交易日、成交额缺市场/交易日倒序/日期金额数组错位/负数/首市场落后,以及三市完整性状态。
- 后端状态:覆盖指数、市场宽度、一级行业和成交额旧交易日期的真实 `delayed` 分支;休市日保守延迟属于已记录边界。
- 测试时钟:市场概览服务套件统一冻结到上海 `2026-08-18`,单个 `delayed` 用例显式切换目标日期并在用例后恢复,保证测试不会随自然日期变化。
- 前端状态:覆盖宽度、板块和成交额模块的 `partial`/`delayed` 警告、真实交易日期和成交额零变化中性色。
- 浏览器验证:桌面默认视口和 390px 移动视口无横向溢出;综合/短线切换和分析引擎选择可用。
## 安全、性能与残余风险
- 安全:TDX 地址固定为本机回环桥接端口;请求超时、响应 1 MiB 上限、错误脱敏;只读行情,不接受用户输入拼接请求。
- 性能:五个模块并行请求,单次 TDX 请求受超时保护;本切片不引入数据库、缓存或消息负载,未进行持续压测。
- 残余风险:主力净流入字段当前桥接实测为零值,需权限和口径专项验证;盘中新闻仍需补充源;详情页、依据抽屉和 AI 运行时需另立功能;市场数据授权和生产 7×24 稳定性未由本地冒烟证明。
## 安全验证
- 验证 TDX 只能使用回环地址和固定端口,错误响应不包含原始 URL、请求体或凭据。
- 验证前端只能通过统一 Axios API 文件访问后端,边界测试拒绝页面直连 Axios/fetch 和 Server 内部依赖。
- 验证 E2E 夹具使用无秘密的生产测试环境变量,不读取仓库内本地凭据或生产配置。
## 性能验证
- 验证五个模块并发加载、单模块失败隔离和请求超时行为。
- 验证响应体 1 MiB 上限和构建产物体积;浏览器桌面/移动端无横向溢出。
- 7×24 运行、峰值并发、TDX 断线重连和消息/缓存压力测试不适用于当前只读首屏,已列为后续采集与生产功能边界。
@@ -15,3 +15,4 @@ code_review: review/code-review.md
standards_review: review/standards-review.md standards_review: review/standards-review.md
implementation_commit: 9203fdd implementation_commit: 9203fdd
release: v0.0.5 release: v0.0.5
superseded_by: GOV-009/source-only-deployment-design.md
@@ -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` 的源码门禁。
@@ -0,0 +1,24 @@
id: GOV-009
name: 应用工程脚手架基线
slug: application-scaffold-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
development_summary: development-summary.md
gitnexus_before: gitnexus/before.md
gitnexus_impact: gitnexus/impact-plan.md
gitnexus_after: gitnexus/after.md
gitnexus_comparison: gitnexus/comparison.md
code_review: review/code-review.md
standards_review: review/standards-review.md
release: v0.0.8
architecture_confirmation: 2026-08-17
completion_gate: 已完成基于实际前后端架构的论证并获得用户确认
architecture_review: architecture-review.md
source_only_deployment_design: source-only-deployment-design.md
source_only_deployment_implementation_plan: source-only-deployment-implementation-plan.md
@@ -0,0 +1,61 @@
# 应用工程脚手架基线 PRD
- 功能编号:GOV-009
- PRD 版本:0.1
- 状态:approved
- 日期:2026-08-13
## 问题
项目已经完成工程治理、部署配置、MySQL 5.7、Redis 和 RocketMQ 5.x 的架构基线,但 `web/` 与 `server/` 仍只有占位文件,尚不能启动、构建或承载市场概览功能。现有 Schema 工具也没有读取项目约定的 `*.env.local`,并只允许回环主机,无法对已经确认的固定远程开发库执行版本化结构备份。
## 目标
- 建立可独立开发和部署的 Vue 3 Web 与 NestJS Server 工程。
- Server 在同一工程内提供 API、Scheduler、Worker 三个独立进程入口。
- 建立统一的 Node.js 22 LTS、pnpm 10、TypeScript、检查、测试和构建入口。
- HTTP 契约由 Server 的 DTO 与 OpenAPI 定义,Web 使用生成客户端,不共享后端源码。
- RocketMQ 消息契约只在 Server 内由 Scheduler 与 Worker共享。
- 本地进程加载现有 `deploy/env/development/*.env.local`,同时保持真实配置不进入 Git。
- Schema 工具只允许读取固定开发配置,支持经过白名单批准的远程开发库。
- 为 FEAT-MO-001 提供能够直接开始页面开发的工程底座。
## 用户价值
开发者可以用明确命令安装依赖、启动 Web/API/Scheduler/Worker、运行测试和构建,并能在不复制接口类型、不泄漏密钥、不误触生产数据库的前提下持续开发市场分析功能。
## 范围
- 根 pnpm workspace 与统一版本约束。
- Vue 3、Vite、TypeScript、Vue Router、Pinia、Naive UI、Dart Sass、Vitest 和 Playwright 基础工程。
- NestJS API、Scheduler、Worker 多应用工程及共享后端库边界。
- Server 配置解析、条件必填和启动失败策略。
- API 健康检查、OpenAPI 产物与 Web 客户端生成链路。
- Redis 与 MySQL 开发连接健康检查;RocketMQ 保持配置可选和默认关闭。
- Ubuntu 源码部署所需 Web/Server 产物与 systemd、Nginx 命令对齐,Docker 能力由后续确认的仅源码决策移除。
- Schema 开发配置路径、固定远程开发库白名单及空库基线处理。
## 非目标
- 不实现市场概览页面和业务指标。
- 不实现正式行情采集、AI 分析或付费功能。
- 不实现用户、邀请、权限、会员或订阅。
- 不把 HTTP DTO、数据库实体或消息事件做成前后端共享源码包。
- 不实现未经验证的 RocketMQ Node SDK;本功能只建立 Adapter 边界、配置校验和禁用态启动能力。
- 不创建、删除或修改生产基础设施与生产数据。
- 不管理本地或生产 Redis、MySQL、RocketMQ 的生命周期,不提供容器兜底。
## 验收标准
- Node.js 非 22.x 时安装或校验入口明确失败,pnpm 主版本固定为 10。
- 根命令可以分别启动、测试和构建 Web、API、Scheduler、Worker。
- 三个 Server 进程共享配置和后端库,但拥有独立入口与最小配置读取范围。
- Web 不导入 `server/` 源码;前端 API 类型来自提交或构建生成的 OpenAPI 客户端。
- RocketMQ 事件类型不进入 Web 构建产物。
- API 健康检查能够报告进程状态,并分别区分 Redis、MySQL 和禁用的 RocketMQ。
- 开发配置从 `*.env.local` 加载,真实值继续被 Git 忽略,生产模板不获得开发地址或密码。
- Schema 工具只接受 `development`、`a_share_analysis_dev`、MySQL 5.7、`utf8mb4_general_ci` 和固定主机白名单;其他远程主机立即拒绝。
- 空开发库可以生成可验证的 captured Schema 基线,不用空 SQL 冒充结构,也不退回 `not_applicable`。
- 单元测试、契约测试、构建、开发启动冒烟和适用的浏览器验证全部通过。
- 仓库不存在活动 Dockerfile、Compose 或 Docker 专用门禁;`pnpm verify:release` 只执行源码发布检查。
- 全部实施完成后必须基于真实代码和部署产物提交《实施架构复核》,向用户论证前后端职责、依赖方向、进程边界、替代方案和演进成本;获得用户再次确认前,GOV-009 不得标记完成或创建发布标签。
@@ -0,0 +1,93 @@
# 测试结果
- 日期:2026-08-13
- 实现提交:`95b8611bd9bbc282193591e472e2e19c617e5035`
- 状态:passed
## 测试先行证据
- 三进程配置 Token 缺失、Scheduler/Worker 启动后自行退出:RED;动态模块注入和生命周期锚点实现后 GREEN。
- 消息信封缺少追溯字段、MySQL 接受 5.7.41、真实空库 dump 被误判:RED;完整信封、5.7.42 固定和对象计数判空后 GREEN。
- `.vue` 越界导入未被发现、Vite 无 `/api` 代理:RED;SFC 脚本扫描和同源代理后 GREEN。
- 契约漂移验证模块不存在:RED;生成后限定路径 Git diff 与 Git 跟踪门禁后 3/3 GREEN。
- Vue 外部 `script src`、可变镜像标签和干净 checkout 生命周期用例依次 RED;禁止外部脚本、摘要校验与公开生产 fixture 实现后 GREEN。
- Playwright 访问真实健康接口时代理连接拒绝:RED;同时启动测试 API 并复用可用本机 Redis 后 GREEN。
## 完整验证
`pnpm verify`:passed。
- 运行时:Node.js 22.11.0、pnpm 10.25.0。
- 治理:5/5。
- MySQL 架构规范:2/2。
- 环境与部署契约:11/11。
- Schema 基线:28/28;`v0.0.7 (not_applicable)` 验证通过。
- 生成契约漂移:3/3;OpenAPI 与 Web 生成类型同步,未跟踪生成物会阻断。
- 工程边界:8/8,包含 Vue SFC 内联脚本,以及外部脚本单双引号、无引号和属性换序越界用例。
- 生产镜像引用:5/5;拒绝空值、`latest`、普通 tag 和裸摘要。
- Web Vitest:8/8。
- Server Vitest:30/30,包含 API/Scheduler/Worker 与两个真实子进程生命周期用例。
- Web、API、Scheduler、Worker 生产构建:passed。
- Playwright:桌面/移动共 4/4;页面外壳与 Web → Vite → Nest API 健康链路均通过。
- `git diff --check`、ESLint、Prettier、TypeScript:passed。
`pnpm verify:docker`:passed。
该结果是 2026-08-13 已完成的历史交付验证。按用户随后决定,Docker 不再作为日常开发必跑项;核心功能完成后再决定是否保留 Docker 部署,并仅在最终交付阶段按需重跑。
- Web 与 Server 多阶段镜像真实构建成功。
- Server 镜像以 `node` 非 root 用户运行。
- API、Scheduler、Worker 三个镜像入口存在;Scheduler/Worker 均在容器内持续运行,并在 `SIGTERM` 后退出码为 0。
- 隔离容器内 Redis/API/Web 启动,API 健康 200、Web 首页和 Nginx `/api` 代理通过。
- 临时容器、网络和验证镜像已清理。
## 本机与固定开发基础设施
- 本机 Redis `127.0.0.1:6379` 的 DB 0、1、2 分别执行只读 `PING`,三次均返回 `PONG`;未读取或修改业务键。
- 固定开发 MySQL 只读会话返回 `5.7.42-0ubuntu0.18.04.1`、库 `a_share_analysis_dev`、`utf8mb4`、`utf8mb4_general_ci`、会话时区 `+08:00`;Task 1 对象计数为 0。密码只通过临时进程环境传递,未输出或写入命令参数;未连接、探测或读取生产数据库。
- 本机 RocketMQ 只读 TCP 可达性复核:NameServer `127.0.0.1:9876`、Broker `127.0.0.1:10911`、Proxy `127.0.0.1:8081` 均可达。Node Adapter 仍保持禁用,没有创建 Topic、消费或发送消息。
## 仅源码部署调整(2026-08-13)
### RED
- `pnpm test:deployment` 因 `verify-source-deployment.mjs` 尚不存在而失败,证明新测试先于源码发布门禁实现。
- `pnpm test:environment-baseline` 因 Docker 活动文件和本地 Compose 指令仍存在而失败,证明政策测试能捕获待移除能力。
- `node --test server/tools/run-test-api.test.mjs` 因 `checkLocalRedis` 尚未导出而失败,证明外部 Redis 预检行为先有测试。
### GREEN
- 源码部署夹具:初始 5/5;最终 Review 加入任意新 Dockerfile/Compose 路径回归后为 6/6。
- 环境与部署契约:10/10;活动 Docker 入口不存在,本地外部 Redis和唯一 Ubuntu 源码部署规则通过。
- Redis 预检:2/2;OS 分配的本机 TCP 端口分别验证可达和不可达,不安装或启动外部服务。
- 本机 `redis-cli -h 127.0.0.1 -p 6379 ping` 返回 `PONG`。
- Server 原有 30 项 Vitest 与新增 2 项 Node 测试全部通过。
- Playwright 桌面与移动视口共 4/4,通过真实本机 Redis、API 健康接口和 Web 同源代理链路。
前述 `pnpm verify:docker` 及镜像验证内容是调整前的真实历史证据。2026-08-13 用户确认仅源码部署后,这些能力已被取代并从活动仓库删除,不再执行或作为发布依据。
### 最终源码发布验证
`pnpm verify:release`:passed。
- Node.js 22.11.0、pnpm 10.25.0 运行时检查通过。
- 环境 10/10、Schema 28/28、契约 3/3、工程边界 8/8、源码部署 6/6。
- Web 8/8;Server Vitest 30/30,Redis 预检 Node 测试 2/2。
- Web、API、Scheduler、Worker 生产构建通过。
- Playwright 桌面/移动共 4/4,通过现有本机 Redis 和真实 API 健康链路。
- `verify:source` 确认四类产物、三份 systemd 单元与 Nginx 配置一致;未调用 Docker。
应用内浏览器补充验证 1440×900 与 390×844:两种视口页面均非空,页面宽度等于视口宽度,无横向溢出、文字重叠或控制台 warning/error;DOM 中导航与“应用就绪”区域完整。
最终 Review 发现并修复两项 Important:systemd 模板曾以 `.service.example` 目标名安装,任意新路径的 Dockerfile/Compose 文件曾可绕过固定清单。两项均先增加失败测试,再修复至 GREEN。
## v0.0.8 发布封存验证(2026-08-17)
`npm run governance:finish -- GOV-009 application-scaffold-baseline`、`npm run governance:finish -- GOV-010 development-quality-architecture` 与 `pnpm verify:release` 均以退出码 0 完成。
- 运行时:Node.js 22.22.0、pnpm 10.25.0。
- 治理 10/10、MySQL 规范 2/2、环境 10/10、Schema 28/28、契约 3/3、边界 16/16、源码部署 6/6。
- Web Vitest 11/11;Server Vitest 30/30;Redis API 预检 2/2。
- Web、API、Scheduler、Worker 生产构建均通过;Web JS 163.91 kB、CSS 0.81 kB,未因发布文档变化增加运行时代码。
- Playwright 桌面/移动共 4/4;`verify:source` 确认四类构建产物、systemd 与 Nginx 配置一致。
- 验证只使用开发配置安全边界和现有本机 Redis;没有连接、探测或读取生产数据库,没有创建 RocketMQ Topic 或读写业务数据。
@@ -0,0 +1,21 @@
# 视觉 QA
- 日期:2026-08-13
- 浏览器:Playwright Chromium
- 状态:passed
## 桌面 1440 × 900
- 证据:`../screenshots/iterations/app-shell-ready-1440x900-3a8120a.png`
- SHA-256:`79b3ef53178c9d35fc10b75aac2d844d34c886d4e2faab69762922f4cda17802`
- 顶部品牌栏、应用标题和“工程基线已就绪”可见。
- `main` 可见,无水平溢出、控制台 warning/error 或页面异常。
## 移动 390 × 844
- 证据:`../screenshots/iterations/app-shell-ready-390x844-3a8120a.png`
- SHA-256:`12f56ae24d51c64b1e0dfc03a8a2e3538e5ce5a7a33c2863f9bff5d53efe3d1d`
- 品牌栏与正文在窄屏正常换行和留白,无水平溢出。
- 无控制台 warning/error 或页面异常。
当前画面仅证明工程外壳与响应式基线,不代表市场概览产品视觉已经完成;市场概览页面将在后续功能档案中单独设计、实现和验收。
@@ -0,0 +1,16 @@
# 发布说明
GOV-009 建立了可运行的应用工程基线:
- 根 pnpm workspace 编排独立的 Vue 3 Web 与 NestJS Server 工程。
- Server 提供 API、Scheduler、Worker 三个独立入口、最小权限配置和优雅关闭生命周期。
- HTTP 契约由 Server DTO/OpenAPI 单向生成 Web 客户端;RocketMQ 消息契约保持 Server 内部。
- Redis/MySQL 只读健康检查、TypeORM MySQL 5.7.42 基线和 RocketMQ 禁用 Adapter 已建立。
- 开发/生产模板、Ubuntu systemd/Nginx 与唯一源码部署路径已对齐。
- Schema 支持固定远程开发库与真实空库 `captured_empty`,历史清单保持不可变。
- 新增契约漂移、Vue SFC 边界、三进程生命周期、Playwright 真实 API 和源码发布门禁。
- 删除 Dockerfile、Compose、镜像校验和容器测试;Redis/MySQL/RocketMQ 统一为外部服务。
本功能已完成基于真实实现的架构论证,并于 2026-08-17 获得用户确认,随 `v0.0.8` 发布。确认范围包括前后端工程边界、Server 三进程、OpenAPI 单向契约、外部基础设施边界和 Ubuntu 仅源码部署路径。
2026-08-13 后续确认的仅源码部署决策已取代此前可选 Docker 交付结论。历史验证记录继续保留用于追溯,但仓库不再提供可执行 Docker 能力。
@@ -0,0 +1,60 @@
# 工程需求
## R1 运行时与包管理
- 仓库声明 Node.js `22.x` 和 pnpm `10.x`,不得由项目脚本安装或替换系统 Node。
- 使用根 `pnpm-workspace.yaml` 编排 `web` 与 `server`;两个工程保持独立 `package.json` 和独立构建产物。
- 锁文件必须提交,依赖版本不得使用无上限的 `latest`。
## R2 Web 工程
- 使用 Vue 3、Vite、TypeScript、Vue Router、Pinia、Naive UI 和 Dart Sass。
- 使用 Vitest 执行组件与状态测试,使用 Playwright 执行浏览器流程和视觉验证。
- Web 只读取 `VITE_` 前缀配置,不接触数据库、Redis、RocketMQ 或 AI 密钥。
- OpenAPI 生成代码与页面模型分层,页面不得直接绑定后端 DTO。
## R3 Server 工程
- 使用 NestJS 与 TypeScript,建立 `apps/api`、`apps/scheduler`、`apps/worker` 三个独立启动入口。
- 后端库按稳定职责划分为配置、HTTP 契约、消息契约、领域和基础设施;禁止按单个类过度拆分。
- API、Scheduler、Worker 分别校验自身所需配置,未使用的密钥不得成为必填项。
- 配置错误必须在进程启动阶段失败,错误日志不得输出密码或访问令牌。
## R4 契约边界
- HTTP DTO 与 OpenAPI 定义归 Server 所有,Web 通过 OpenAPI 生成自己的 TypeScript 客户端。
- Web 禁止直接引用 Server DTO、实体、领域模型或消息事件。
- RocketMQ 消息契约只在 Server 内部共享,并包含版本、事件类型、幂等键、发生时间和载荷。
- OpenAPI 生成漂移必须由自动化测试或 Git diff 检测发现。
## R5 数据与基础设施
- Redis 使用现有开发配置,API、Scheduler、Worker 使用独立逻辑库编号。
- MySQL 使用 Nest 官方集成的 TypeORM 与 `mysql2` 驱动,并显式配置 MySQL 5.7、`utf8mb4`、`utf8mb4_general_ci` 和 `+08:00` 会话时区。
- RocketMQ 默认关闭;未选定并验证 Node 客户端前,不得用虚假实现宣称消息收发可用。
- 所有健康检查必须是只读操作,不创建表、不写入业务数据。
## R6 Schema 基线
- 固定真实配置路径为 `deploy/env/development/api.env.local`,不存在时才允许读取无秘密模板并生成禁用态基线。
- 允许主机仅为回环地址或显式白名单 `112.192.20.11`;白名单不得通过命令参数或任意环境变量扩展。
- 仍固定 `APP_ENV=development`、`a_share_analysis_dev`、MySQL 5.7、`utf8mb4` 和 `utf8mb4_general_ci`。
- 空库 captured 基线必须用 format v2 结构化清单的 `object_counts` 明确记录零对象,并产生确定性校验值;不得创建伪造 SQL 文件。验证器必须继续兼容既有 format v1 历史清单且不得重写。
- Schema 工具不得读取生产 env、连接生产数据库或导出任何表数据。
## R7 部署与质量
- 项目只支持 Ubuntu 22.04/24.04 LTS x86_64 源码部署,不提供 Docker 运行、构建、测试或部署入口。
- Web、API、Scheduler、Worker 构建产物必须完整,源码部署的 systemd 命令必须与三个 Server 构建入口一致。
- 本地 Redis 和生产 Redis/MySQL/RocketMQ 均为外部系统服务,项目脚本不得安装、启动、停止或删除它们。
- `verify:release` 必须校验真实构建产物、systemd 最小权限和 Nginx Web/API 链路;Redis 不可达时 E2E 必须明确失败且不得提供容器兜底。
- 根级检查必须覆盖格式、静态检查、类型、单元测试、契约测试和构建。
- 所有关键配置边界、契约生成和启动失败行为必须有自动化测试。
- Server 使用 `@nestjs/swagger` 输出稳定的 `openapi.json`;Web 使用 `openapi-typescript` 与 `openapi-fetch` 生成类型安全客户端。
## R8 实施后架构复核
- 开发阶段允许按批准设计实施,但设计文档不能代替对实际代码结构的复核。
- 所有测试和 Review 通过后,必须新增 `architecture-review.md`,以实际文件、依赖图、进程入口、契约生成和部署产物为证据。
- 复核必须比较至少一个替代架构,解释当前方案的收益、限制、后续拆分条件和可能的技术债。
- 必须向用户展示并完成论证;用户确认前 manifest 保持 `reviewing`、版本保持 `unreleased`,不得创建 `v0.0.8` 标签。
@@ -0,0 +1,68 @@
# 代码 Review
- 审查范围:`c04184a6111da0cfad90d1a265dc3cd3a6d90a9c..95b8611bd9bbc282193591e472e2e19c617e5035`
- 审查方式:独立只读复审
- 日期:2026-08-13
## 发现与处置
第一轮发现三进程生命周期依赖本地 env、未跟踪生成契约可绕过漂移检查、Vue 外部脚本可绕过边界、生产镜像允许可变 tag,以及 Docker 未验证镜像内 Scheduler/Worker 生命周期。上述问题已在 `cb550e3` 完成整改并通过针对性测试。
最终复审进一步发现早期外部脚本正则不能识别合法的无引号 `src` 属性。GitNexus 单符号影响分析为 LOW,只有 `verifyProjectBoundaries` 一个直接调用者和一条边界检查流程。`95b8611` 改用固定版本 `@vue/compiler-sfc@3.5.41`,直接拒绝普通脚本或 setup 脚本的外部 `src`,测试覆盖双引号、单引号、无引号和属性换序,边界用例 8/8 通过。
## 最终证据
- `pnpm verify` 完整通过:静态检查、类型、全部测试、Web/Server 构建和 Playwright 4/4。
- 契约漂移 3/3、工程边界 8/8、镜像引用 5/5、Web 8/8、Server 30/30。
- Scheduler/Worker 的源码子进程生命周期使用公开 production fixture,可在干净 checkout 复现。
- HTTP 契约保持 Server DTO → OpenAPI → Web 单向发布;RocketMQ 消息契约只在 Server 内部。
- 未发现新的配置泄漏、安全、生命周期、错误处理或生产风险。
- Docker 是已验证过的历史可选交付能力;按用户决定不再作为后续日常门禁,最终开发完成后再决定是否保留。
Critical、Important、Minor 均无未关闭问题。
最终结论:passed
## 仅源码部署调整复审
- 审查范围:`cfcd7f13d9a6a35173d01bd8ca1458911190e70f..47d0e0d248eb9b21cbd12f1625d3bd0e9c266dc9` 及其后 Review 修复
- 审查重点:发布门禁绕过、子进程与信号、Redis 失败语义、systemd/Nginx 真实命令、历史证据和测试缺口
### 发现与处置
1. **Important:systemd 模板目标名不可执行。** 初版源码手册把 `*.service.example` 原样安装并以该名称重启,真实 systemd 单元名不正确。新增环境契约测试先 RED,随后改为分别安装成 `a-share-api.service`、`a-share-scheduler.service`、`a-share-worker.service`,并统一 verify/restart/status/journalctl 命令;环境 10/10 GREEN。
2. **Important:Docker 禁止清单可被新路径绕过。** 初版只阻断已删除的固定旧路径,`ops/Dockerfile` 或新 Compose YAML 会被放行。新增未列举路径测试先 RED,随后用递归活动资产扫描阻断任意 Dockerfile、`.dockerignore`、`docker-compose*.yml` 和 `compose/` YAML;部署测试 6/6 GREEN。
### 最终证据
- `pnpm verify:release` 完整通过,包含静态检查、类型、全部测试、四类构建、Playwright 4/4 和源码发布校验。
- Redis 不可达时只返回脱敏的固定本机服务提示;无安装、启动、停止或删除基础设施的分支。
- API 子进程只接收公开禁用态测试夹具,SIGINT/SIGTERM 只转发给该子进程。
- 源码门禁要求 Web 与三个 Server 入口、三份最小权限 systemd 单元和 Nginx Web/API 配置完整。
- 当前跟踪文件没有 Dockerfile、Compose、`.dockerignore` 或 Docker 专用脚本;历史文档事实仍可追溯。
Critical、Important、Minor 均无未关闭问题。
最终结论:passed
## v0.0.8 发布封存复核
- 复核日期:2026-08-17
- 本次变化只更新用户确认记录、功能状态、版本、发布说明与开发总结,没有修改运行时代码、数据库结构、消息契约或部署入口。
- `architecture-review.md` 记录的确认范围与实际实现一致;仅源码部署决策继续取代早期 Docker 方案,没有删除或伪造历史验证证据。
- 发布状态变化不会扩大生产权限,不读取生产配置或数据;回退继续采用新提交和更高补丁版本,禁止移动已推送标签。
- 完整验证与源码发布门禁在最终发布树上重新执行,结果写入本次发布记录。
## 安全与残余风险
配置、Schema、Redis/MySQL 健康检查、OpenAPI 边界和源码部署均保持最小权限与脱敏策略;本次封存不访问生产数据库、不写入外部基础设施。残余风险集中在尚未实现的 RocketMQ Node 客户端、TDX 采集和市场业务,必须在对应功能中重新 Review,不能沿用脚手架结论直接放行。
## 性能与资源影响
本次封存只有文档和版本元数据变化,没有增加线上进程、请求、数据库查询、缓存写入或消息负载。既有 Web 与三进程构建、生命周期和 Playwright 证据覆盖脚手架边界;行情刷新与分析吞吐不属于 GOV-009,后续需建立业务性能指标。
## GitNexus 与同步修改
发布封存不修改运行时符号。HTTP/OpenAPI、Web API、消息、数据库、Redis、API、Scheduler、Worker 和源码部署边界均无需代码同步;版本、manifest、CHANGELOG、开发总结、Review、发布说明和回退记录已同步更新。
最终结论:passed
@@ -0,0 +1,52 @@
# 开发规范符合性 Review
- 审查范围:`c04184a6111da0cfad90d1a265dc3cd3a6d90a9c..95b8611bd9bbc282193591e472e2e19c617e5035`
- 审查方式:独立只读复审
- 日期:2026-08-13
## 规范核对
- 所有 GOV-009 实现提交均为包含功能编号的中文 Conventional Commit,并在验证后及时推送 Gitea。
- GitNexus 前置、影响分析、开发后索引和前后对比完整;最终索引提交为 `95b8611`。
- 公共导出、契约字段、安全边界和架构取舍均有准确中文注释,未发现无意义逐行注释或过度拆分。
- MySQL 固定为 5.7.42、`utf8mb4`、`utf8mb4_general_ci` 和 `+08:00`;Schema 流程只允许固定开发库和白名单主机。
- Redis DB 0/1/2 均只读 `PING` 成功;RocketMQ NameServer/Broker/Proxy 均只读验证可达,未创建 Topic 或发送消息。
- 截图位于 `screenshots/iterations/`,文件名包含页面、状态、视口和实现版本,文档引用与 SHA-256 一致。
- 未发现密钥、真实 env、生产数据或 GitNexus 本地索引被 Git 跟踪。
- Docker 最新决定已统一记录为历史验证、可选交付、非日常必跑,不篡改此前真实验证记录。
- manifest 保持 `reviewing/unreleased`,本地与远端均不存在 `v0.0.8`。
Critical、Important、Minor 均无未关闭问题。
最终结论:passed
## 仅源码部署调整复审
- 实施计划、TDD RED/GREEN、GitNexus 前置影响、开发后 compare 和回退说明均已写入 GOV-009 档案。
- 新增关键函数包含外部基础设施所有权和安全边界中文注释,文件按“源码发布门禁”和“E2E 启动器”稳定职责组织,未过度拆分。
- MySQL 仍固定 5.7.42、`utf8mb4`、`utf8mb4_general_ci`、`+08:00`;本次没有连接、探测或读取生产数据库,也没有创建迁移或业务表。
- 本机 Redis 只执行 `PING` 与 TCP 可达性检查;RocketMQ 保持禁用,没有创建 Topic、生产或消费消息。
- 现行架构、开发规范、流程规范和部署手册只宣称 Ubuntu 源码部署;GOV-006 与早期 GOV-009 Docker 记录保留为历史并明确被取代。
- `47d0e0d` 为带 GOV-009 的中文 Conventional Commit,已推送项目专用 Gitea;最终 Review 修复和证据将在验证后以独立中文提交推送。
- manifest 保持 `reviewing/unreleased`,本地与远端均不存在 `v0.0.8`,等待用户完成总体架构确认。
Critical、Important、Minor 均无未关闭问题。
最终结论:passed
## v0.0.8 发布封存复核
- 用户于 2026-08-17 确认 GOV-009 实际架构,原有 `reviewing/unreleased` 描述作为确认前事实保留;manifest 和发布说明现已同步为 `released/v0.0.8`。
- 新增独立 `development-summary.md`,七个固定章节完整记录原始需求、范围变化、完成项、缺陷、延期、提交和验证证据。
- GOV-009 与 GOV-010 的状态、版本、CHANGELOG、Review 和回退口径一致;FEAT-DS-001 仍为未发布 PoC 前置档案,没有误报为已实现采集能力。
- 本次提交继续使用带 GOV-009 的中文 Conventional Commit,推送 `main` 后再单独精确推送 `v0.0.8`,不使用 GitHub、全局 Git 配置、强推或批量标签推送。
## 安全、性能与架构检查
安全边界覆盖开发库固定白名单、秘密隔离、最小权限配置、错误脱敏和外部基础设施只读检查;性能边界覆盖独立构建、三进程生命周期、无生产时治理开销和后续业务指标延期说明。实际架构与用户确认的 Vue 3、NestJS 三进程、OpenAPI 单向契约和 Ubuntu 仅源码部署一致。
## GitNexus 与开发总结检查
开发前影响、开发后检测、索引基线和前后对比文件完整;发布封存只影响文档与版本,不改变执行流。独立开发总结七个固定章节均有实质内容,并逐项说明 HTTP/OpenAPI、Web API、消息、数据库、Redis、API、Scheduler、Worker、部署、测试和文档的同步边界。
最终结论:passed
@@ -0,0 +1,18 @@
# 回退说明
GOV-009 没有创建业务表、执行迁移、写入生产数据库、创建 RocketMQ Topic 或发送消息。回退重点是应用代码与部署产物,不包含数据回滚。
## 代码回退
- 以中文 Conventional Commit 新建回退提交,按逆序撤销 GOV-009 提交;禁止 `reset --hard`、强推或改写 Gitea 历史。
- 若只回退 Review 整改,目标提交为 `3a8120a33aff3fc4e1f73059eed78d88d57d33a2`,必须同时恢复消息契约、三进程生命周期、契约漂移和部署门禁,禁止形成半套状态。
- 若整体移除脚手架,回到基线 `c04184a6111da0cfad90d1a265dc3cd3a6d90a9c` 的等价内容,并保留既有 `v0.0.7` Schema 历史目录。
## 部署回退
- 把 `/opt/a-share-analysis/current` 原子切回上一完整发布目录并重启 API、Scheduler、Worker 三个 systemd 服务。
- `/etc/a-share-analysis/*.env`、本地 `*.env.local`、Redis、MySQL 和 RocketMQ 数据不随应用回退覆盖或删除。
- 回退后重新执行健康检查、契约门禁和可用性验证。
- 外部基础设施和 `/etc/a-share-analysis/*.env` 不属于应用回退范围,禁止删除或覆盖。
`v0.0.8` 发布后不得删除、移动或覆盖已推送标签。需要回退时只能创建新的中文回退提交,验证并推送后再发布更高补丁版本;远程数据库、Redis、RocketMQ 和环境文件均不属于代码回退对象。
Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

@@ -0,0 +1,78 @@
# 仅源码部署调整设计
- 功能编号:GOV-009
- 决策日期:2026-08-13
- 状态:已实施并通过 Review,等待总体架构确认
- 取代范围:GOV-006、GOV-009 中仍有效的 Docker 部署约定
## 结论
项目只支持源码部署,不再提供或维护任何 Docker 运行、构建、测试或部署能力。开发环境的 Redis 使用开发机已开机自启的 `127.0.0.1:6379`;生产环境的 Redis、MySQL 5.7.42 和 RocketMQ 均由服务器外部系统服务提供。应用只连接这些基础设施,不负责安装、启动、停止或删除它们。
Ubuntu 源码部署是唯一生产交付路径:固定提交在构建机完成依赖安装、测试和 Web/Server 构建,将不可变发布目录部署到服务器,再由 systemd 管理 API、Scheduler、Worker,Nginx 托管 Web 静态文件并代理 `/api/`。
## 调整范围
### 删除的 Docker 能力
- 删除 Web 与 Server Dockerfile、根 `.dockerignore` 和 Web 容器专用 Nginx 配置。
- 删除开发与生产 Compose 文件;本地 Redis 不再由仓库拉起。
- 删除生产 Compose 部署文档、Docker 构建验证器、不可变镜像校验器及对应测试。
- 删除根级 `check:images`、`verify:docker` 等 Docker 专用命令。
- API E2E 启动器不再在 Redis 不可达时创建临时容器;Redis 不可达必须直接失败并提示本机服务要求。
### 保留和加强的源码能力
- 保留 `deploy/env/development/` 与 `deploy/env/production/` 的四进程配置契约。
- 保留并验证 systemd API、Scheduler、Worker 服务文件和生产 Nginx 配置。
- 保留 Web、API、Scheduler、Worker 的独立构建产物。
- `verify:release` 只执行源码发布门禁,不调用 Docker。
- 本地开发文档先验证 `redis-cli -h 127.0.0.1 -p 6379 ping`,再从源码启动应用进程。
## 源码部署流程
1. 在已固定 Node.js 22.x 与 pnpm 10.25.0 的构建机检出确定提交。
2. 执行 `pnpm install --frozen-lockfile` 和根级源码发布验证。
3. 构建 Web dist 与 API、Scheduler、Worker 三个 Server dist 入口。
4. 将完整、只读的版本发布目录放入 `/opt/a-share-analysis/releases/<版本或提交>/`。
5. 将 `/opt/a-share-analysis/current` 原子切换到目标发布目录。
6. systemd 通过 `/etc/a-share-analysis/*.env` 分别向三个 Server 进程注入最小配置。
7. Nginx 从当前 Web dist 提供静态文件,并把 `/api/` 代理到 API 进程。
8. 验证 systemd 状态、API 健康接口、Web 首页和同源 API 代理。
## 源码发布门禁
自动验证必须覆盖以下真实行为:
- 仓库不存在 Dockerfile、Compose、`.dockerignore`、Docker 专用验证器和 Docker 命令。
- README、现行架构、治理规范和部署索引只宣称源码部署。
- Web、API、Scheduler、Worker 构建产物存在且入口与 systemd `ExecStart` 一致。
- Nginx 静态目录指向 Web dist,`/api/` 代理指向 API 端口。
- 三份 systemd 服务使用独立 `EnvironmentFile`、非 root 用户和明确工作目录。
- 本地开发要求外部 Redis 可达,不存在自动拉起或容器兜底路径。
- Redis、MySQL 和 RocketMQ 的密码或 Token 不进入仓库、命令参数或构建产物。
## 失败处理
- 本地 Redis 不可达时,API E2E 和本地启动应快速失败,错误明确说明需要启动本机 Redis 服务;不自动改变用户机器状态。
- 源码构建任一产物缺失时阻断发布,不允许发布部分进程。
- systemd 或 Nginx 验证失败时保持上一 `current` 目录,不覆盖外部 env 和基础设施数据。
- 数据库迁移出现后,迁移必须在切换 `current` 和重启服务前单独执行;继续禁止 TypeORM `synchronize: true`。
## 历史追溯
GOV-006 与 GOV-009 已发布或已封存材料中的 Docker 记录属于当时真实设计和验证事实,不删除、不改写为“从未支持”。当前设计通过新的决策文档、现行架构、治理规范和发布说明明确取代其 Docker 结论。Git 历史仍可直接比较决策前后的文件和门禁变化。
## 回退策略
本调整尚未发布版本标签。实施失败时使用中文回退提交恢复本调整前的仓库内容,禁止强推或移动既有标签。外部 Redis、MySQL、RocketMQ、`/etc/a-share-analysis/*.env` 和服务器发布目录不由代码回退删除或覆盖。
源码部署调整完成后,应用回退只允许把 `/opt/a-share-analysis/current` 切回上一完整发布目录并重启 systemd 服务;不再提供镜像回退方案。
## 验收标准
- 仓库和现行文档中不存在仍可执行或仍被宣称支持的 Docker 能力。
- 本地与生产基础设施均被定义为外部系统服务。
- 根级完整验证、源码发布门禁、双视口页面验证、代码 Review 和规范 Review 全部通过。
- GitNexus 开发后分析只出现预期的部署与测试门禁影响。
- 所有变更以中文 Conventional Commit 提交并推送 Gitea;用户确认架构前仍不创建 `v0.0.8`。
@@ -0,0 +1,526 @@
# Source-Only Deployment Implementation Plan
> **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:** Remove every active Docker dependency and make Ubuntu source deployment, external infrastructure, and local pre-existing Redis the only supported runtime path.
**Architecture:** The root workspace keeps one release gate that first runs the existing complete verification and then validates source artifacts against systemd and Nginx templates. Playwright's API launcher performs a read-only TCP preflight against the developer-managed Redis at `127.0.0.1:6379` and fails without starting infrastructure. Historical Docker evidence remains unchanged as history, while current architecture, governance, and GOV-009 decision records explicitly supersede it.
**Tech Stack:** Node.js 22.x, pnpm 10.25.0, Node test runner, Vue 3/Vite, NestJS, Playwright, Redis, MySQL 5.7.42, RocketMQ 5.x, Ubuntu 22.04/24.04 LTS, systemd, Nginx.
## Global Constraints
- Production supports Ubuntu source deployment only; Docker is absent from development, test, build, and production paths.
- Redis, MySQL 5.7.42, and RocketMQ 5.x are external services; project scripts never install, start, stop, or delete them.
- Local development and browser E2E use the existing Redis at `127.0.0.1:6379`; unavailability must fail fast without fallback.
- MySQL is fixed to 5.7.42 with `utf8mb4`, `utf8mb4_general_ci`, and `+08:00`; no production database may be connected, probed, or read.
- Node.js is fixed to 22.x and pnpm to 10.25.0; the repository does not install or replace system Node.js.
- Source releases use immutable `/opt/a-share-analysis/releases/<version-or-commit>/` directories and atomically switch `/opt/a-share-analysis/current`.
- API, Scheduler, and Worker use separate systemd units and separate `/etc/a-share-analysis/*.env` files under the non-root `a-share` account.
- Existing GOV-006 and GOV-009 records of past Docker decisions and successful validation remain truthful historical evidence; current records must state that the source-only decision supersedes them.
- No `v0.0.8` tag is created until the user separately confirms the implemented architecture.
- Every implementation commit uses Chinese Conventional Commit with `GOV-009`, passes GitNexus change detection, and is pushed immediately to the project Gitea remote.
---
## File Map
- `tools/deployment/verify-source-deployment.mjs`: source-release artifact and deployment-template verifier.
- `tools/deployment/verify-source-deployment.test.mjs`: verifier RED/GREEN coverage using isolated fixture directories.
- `tools/governance/environment-baseline.test.mjs`: active environment, documentation, systemd, Nginx, and no-Docker policy tests.
- `server/tools/run-test-api.mjs`: Playwright API launcher and external local Redis preflight.
- `server/tools/run-test-api.test.mjs`: launcher behavior tests proving unavailable Redis fails without Docker fallback.
- `package.json`: source-only test and release commands.
- `deploy/systemd/*.service.example`: API/Scheduler/Worker production process definitions, retained and verified.
- `deploy/nginx/a-share-analysis.conf.example`: source Web static hosting and `/api/` reverse proxy, retained and verified.
- `README.md`, `docs/index.md`, `docs/architecture/system-architecture.md`: current public architecture and deployment entry points.
- `docs/governance/code-development-standards.md`, `docs/governance/development-workflow.md`: mandatory source-only engineering and release rules.
- `docs/deployment/local-development.md`, `docs/deployment/ubuntu-source-production.md`: the only current development and production runbooks.
- `docs/features/GOV-009-application-scaffold-baseline/*.md`: requirements, PRD, design, test, release, rollback, architecture review, and traceability updates.
- `docs/features/GOV-006-environment-deployment-baseline/`: historical archive; only add a supersession pointer if a current-status statement would otherwise be ambiguous.
- `CHANGELOG.md`: unreleased policy change, preserving earlier Docker entries as history.
- `.dockerignore`, `web/Dockerfile`, `web/nginx.conf`, `server/Dockerfile`, `deploy/compose/*`, `docs/deployment/docker-compose-production.md`, `tools/deployment/verify-docker.mjs`, `tools/deployment/verify-image-references*`: remove obsolete active Docker artifacts.
---
### Task 1: Establish Source-Only Deployment Tests
**Files:**
- Create: `tools/deployment/verify-source-deployment.test.mjs`
- Modify: `tools/governance/environment-baseline.test.mjs`
- Modify: `package.json`
**Interfaces:**
- Consumes: repository paths and the existing `deploy/systemd/`, `deploy/nginx/`, `web/dist/`, and `server/dist/` conventions.
- Produces: root scripts `test:deployment` and `verify:source`; failing tests that define the source-only repository contract before implementation.
- [x] **Step 1: Add failing fixture tests for the source verifier**
Create tests that import the not-yet-existing module and define these exact behaviors:
```js
import assert from 'node:assert/strict';
import { mkdtemp, mkdir, writeFile } from 'node:fs/promises';
import { tmpdir } from 'node:os';
import path from 'node:path';
import test from 'node:test';
import { verifySourceDeployment } from './verify-source-deployment.mjs';
test('完整源码发布夹具通过', async () => {
const root = await createSourceReleaseFixture();
await assert.doesNotReject(() => verifySourceDeployment(root));
});
test('任一 Docker 活动文件会阻断源码发布', async () => {
const root = await createSourceReleaseFixture();
await writeFile(path.join(root, 'Dockerfile'), 'FROM node:22\n');
await assert.rejects(() => verifySourceDeployment(root), /禁止存在 Docker 活动文件.*Dockerfile/);
});
test('Server 构建入口缺失会阻断源码发布', async () => {
const root = await createSourceReleaseFixture({ omit: 'server/dist/apps/worker/main.js' });
await assert.rejects(() => verifySourceDeployment(root), /Worker 构建入口不存在/);
});
test('systemd 配置不是最小权限时会阻断源码发布', async () => {
const root = await createSourceReleaseFixture({ apiUser: 'root' });
await assert.rejects(() => verifySourceDeployment(root), /API systemd 必须使用 User=a-share/);
});
test('Nginx 未代理 API 或未指向 Web dist 时会阻断源码发布', async () => {
const root = await createSourceReleaseFixture({ invalidNginx: true });
await assert.rejects(() => verifySourceDeployment(root), /Nginx/);
});
```
The local `createSourceReleaseFixture` helper must create only the minimum paths needed by the verifier: four build outputs, three unit files with distinct `EnvironmentFile`, and one Nginx file. It must accept `omit`, `apiUser`, and `invalidNginx` options so each negative test changes one condition.
- [x] **Step 2: Replace Docker assertions in the environment baseline with source-only assertions**
Keep env-template and RocketMQ tests unchanged. Replace Compose/Docker tests with explicit active-path assertions:
```js
const forbiddenActivePaths = [
'.dockerignore',
'web/Dockerfile',
'web/nginx.conf',
'server/Dockerfile',
'deploy/compose/development.yml',
'deploy/compose/production.yml.example',
'docs/deployment/docker-compose-production.md',
'tools/deployment/verify-docker.mjs',
'tools/deployment/verify-image-references.mjs',
'tools/deployment/verify-image-references.test.mjs',
];
test('活动仓库不再包含 Docker 运行构建或部署入口', async () => {
for (const relativePath of forbiddenActivePaths) {
await assert.rejects(access(new URL(relativePath, repoRoot)), { code: 'ENOENT' });
}
});
```
Add focused checks that current docs describe external local Redis, Ubuntu 22.04/24.04, Node 22.x, pnpm 10.25.0, immutable releases, health checks, and rollback. Do not scan historical feature archives for the word Docker because those files are intentional evidence.
- [x] **Step 3: Point root deployment scripts at the not-yet-existing source verifier**
Change root scripts to the following contract:
```json
"test:deployment": "node --test tools/deployment/verify-source-deployment.test.mjs",
"verify:source": "node tools/deployment/verify-source-deployment.mjs",
"verify:release": "pnpm verify && pnpm verify:source"
```
Remove `check:images` and `verify:docker`.
- [x] **Step 4: Run RED tests and record expected failures**
Run:
```bash
pnpm test:deployment
pnpm test:environment-baseline
```
Expected: the deployment test fails because `verify-source-deployment.mjs` does not exist; the environment baseline fails while active Docker artifacts and current Docker documentation still exist. Record both failures in `docs/features/GOV-009-application-scaffold-baseline/qa/test-results.md` as the RED phase.
---
### Task 2: Implement the Source Release Verifier and Remove Docker Artifacts
**Files:**
- Create: `tools/deployment/verify-source-deployment.mjs`
- Delete: `.dockerignore`
- Delete: `web/Dockerfile`
- Delete: `web/nginx.conf`
- Delete: `server/Dockerfile`
- Delete: `deploy/compose/development.yml`
- Delete: `deploy/compose/production.yml.example`
- Delete: `docs/deployment/docker-compose-production.md`
- Delete: `tools/deployment/verify-docker.mjs`
- Delete: `tools/deployment/verify-image-references.mjs`
- Delete: `tools/deployment/verify-image-references.test.mjs`
**Interfaces:**
- Consumes: `verifySourceDeployment(repositoryRoot?: string | URL): Promise<void>` inputs and the existing build/deployment paths.
- Produces: an importable verifier plus the CLI command `pnpm verify:source`, which exits non-zero on incomplete or unsafe source releases.
- [x] **Step 1: Run GitNexus impact before modifying or deleting deployment symbols**
Run upstream impact for `assertImmutableImageReferences`, `docker`, and `verifyLongRunningProcess`, including tests. Report direct callers, affected processes, and risk to the user. If risk is HIGH or CRITICAL, stop before editing and ask for confirmation as required by `AGENTS.md`.
- [x] **Step 2: Implement the minimal source verifier**
Implement these exports in one readable file:
```js
export const FORBIDDEN_DOCKER_PATHS = Object.freeze([
'.dockerignore',
'Dockerfile',
'web/Dockerfile',
'web/nginx.conf',
'server/Dockerfile',
'deploy/compose/development.yml',
'deploy/compose/production.yml.example',
'tools/deployment/verify-docker.mjs',
'tools/deployment/verify-image-references.mjs',
]);
export async function verifySourceDeployment(repositoryRoot = defaultRepositoryRoot) {
await assertDockerArtifactsAbsent(repositoryRoot);
await assertBuildOutputsPresent(repositoryRoot);
await assertSystemdUnits(repositoryRoot);
await assertNginxConfig(repositoryRoot);
}
```
The implementation must:
- use `node:fs/promises` structured file APIs;
- reject every listed Docker path if it exists;
- require `web/dist/index.html` and `server/dist/apps/{api,scheduler,worker}/main.js`;
- parse each unit sufficiently to verify `User=a-share`, `Group=a-share`, `WorkingDirectory=/opt/a-share-analysis/current`, the process-specific `EnvironmentFile`, `ExecStartPre` env readability, and the exact built `ExecStart` entry;
- verify Nginx root `/opt/a-share-analysis/current/web/dist`, `location /api/`, and `proxy_pass http://127.0.0.1:3000`;
- produce errors that identify the missing or invalid file without printing env values;
- print `源码发布产物与 systemd/Nginx 配置验证通过` only in direct CLI mode.
- [x] **Step 3: Delete the obsolete Docker artifacts**
Delete only the paths listed in this task. Do not delete env templates, systemd units, the production Nginx template, or historical GOV-006/GOV-009 evidence.
- [x] **Step 4: Run GREEN deployment tests after creating build outputs**
Run:
```bash
pnpm build
pnpm test:deployment
pnpm test:environment-baseline
pnpm verify:source
```
Expected: all commands pass; `verify:source` confirms all four build outputs and the deployment templates.
- [x] **Step 5: Detect scope, commit, and push the executable deployment change**
Run GitNexus `detect_changes(scope: "all")`. Review that only deployment validation and environment-policy flows are affected, then run:
```bash
git add package.json tools/deployment tools/governance/environment-baseline.test.mjs deploy web/Dockerfile web/nginx.conf server/Dockerfile .dockerignore docs/deployment/docker-compose-production.md docs/features/GOV-009-application-scaffold-baseline/qa/test-results.md
git commit -m "refactor(GOV-009): 切换为仅源码部署门禁"
git push origin "$(git branch --show-current)"
```
---
### Task 3: Make Playwright Depend Only on Existing Local Redis
**Files:**
- Modify: `server/tools/run-test-api.mjs`
- Create: `server/tools/run-test-api.test.mjs`
- Modify: `server/package.json`
**Interfaces:**
- Consumes: TCP endpoint `127.0.0.1:6379` and the existing public production API fixture.
- Produces: `checkLocalRedis({ host, port, timeoutMs }): Promise<void>` and `runTestApi(): Promise<void>`; direct execution launches only the API process after Redis succeeds.
- [x] **Step 1: Run GitNexus upstream impact for launcher symbols**
Run impact for `forwardSignal` and the `run-test-api.mjs` file, including tests. Report the Playwright web-server dependency and any API health flows before editing. Stop for confirmation only if the graph reports HIGH or CRITICAL risk.
- [x] **Step 2: Write failing launcher tests**
Refactor-safe tests must verify behavior rather than depend on Docker availability:
```js
test('Redis 不可达时给出外部服务提示并拒绝启动', async () => {
await assert.rejects(
checkLocalRedis({ host: '127.0.0.1', port: unusedPort, timeoutMs: 100 }),
/本机 Redis.*127\.0\.0\.1.*6379.*启动后重试/,
);
});
test('Redis TCP 可达时预检通过', async () => {
const server = net.createServer();
// Bind to 127.0.0.1:0, call checkLocalRedis with the assigned port, then close.
});
test('API 测试启动器不包含 Docker 子进程路径', async () => {
const source = await readFile(new URL('./run-test-api.mjs', import.meta.url), 'utf8');
assert.doesNotMatch(source, /execFileSync|docker|Container/i);
});
```
Use an OS-assigned loopback port for deterministic tests. The user-facing failure message may state the fixed required Redis endpoint even when the injected test port differs.
- [x] **Step 3: Run the launcher RED test**
Run:
```bash
node --test server/tools/run-test-api.test.mjs
```
Expected: FAIL because `checkLocalRedis` and guarded direct-execution behavior do not yet exist.
- [x] **Step 4: Refactor the launcher without infrastructure fallback**
Remove `execFileSync`, container naming, dynamic Redis port publication, ownership flags, and cleanup. Export and use:
```js
export async function checkLocalRedis({
host = '127.0.0.1',
port = 6379,
timeoutMs = 500,
} = {}) { /* TCP connect or throw a sanitized Error */ }
export async function runTestApi() {
await checkLocalRedis();
const child = spawn(/* existing API command and public fixture */);
// Forward SIGINT/SIGTERM only to the child and preserve its exit result.
}
```
Guard execution with the existing `process.argv[1]` and `fileURLToPath(import.meta.url)` pattern so tests can import the functions without starting API. Keep `REDIS_PORT: '6379'`; never derive or override it from a container.
- [x] **Step 5: Include the new test in the Server test command**
Change the Server test script to run both Vitest and the Node launcher test:
```json
"test": "vitest run && node --test tools/run-test-api.test.mjs"
```
- [x] **Step 6: Run GREEN and real local Redis checks**
Run:
```bash
node --test server/tools/run-test-api.test.mjs
redis-cli -h 127.0.0.1 -p 6379 ping
pnpm --filter @a-share-analysis/server test
pnpm verify:e2e
```
Expected: unit tests pass, Redis prints `PONG`, and both Playwright viewports pass using the already-running local Redis. If Redis is unavailable, stop with the new explicit error; do not start or install it.
- [x] **Step 7: Detect scope, commit, and push the launcher change**
Run GitNexus `detect_changes(scope: "all")`, confirm the impact is limited to Playwright/API startup, then run:
```bash
git add server/package.json server/tools/run-test-api.mjs server/tools/run-test-api.test.mjs
git commit -m "fix(GOV-009): 移除测试 Redis 容器兜底"
git push origin "$(git branch --show-current)"
```
---
### Task 4: Align Current Architecture, Governance, and Traceability
**Files:**
- Modify: `README.md`
- Modify: `docs/index.md`
- Modify: `docs/architecture/system-architecture.md`
- Modify: `docs/governance/code-development-standards.md`
- Modify: `docs/governance/development-workflow.md`
- Modify: `docs/deployment/local-development.md`
- Modify: `docs/deployment/ubuntu-source-production.md`
- Modify: `CHANGELOG.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/manifest.yaml`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/prd.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/requirements.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/design.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/test-plan.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/release-notes.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/rollback.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/architecture-review.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/qa/test-results.md`
- Optional modify: `docs/features/GOV-006-environment-deployment-baseline/manifest.yaml`
**Interfaces:**
- Consumes: the confirmed `source-only-deployment-design.md` decision and actual Task 2/3 behavior.
- Produces: one unambiguous current deployment policy with intact historical evidence and a traceable GOV-009 record.
- [x] **Step 1: Update current public docs and architecture**
Make these statements exact and consistent:
- `deploy/` contains env, systemd, and Nginx source-deployment configuration, not a dual deployment entry.
- local setup runs `redis-cli -h 127.0.0.1 -p 6379 ping` before source processes and never starts Redis;
- Ubuntu source deployment is the sole production path;
- production prerequisites are Ubuntu 22.04/24.04 LTS x86_64, Node.js 22.x, pnpm 10.25.0, Nginx, and external MySQL 5.7.42/Redis/RocketMQ 5.x;
- release verification runs `pnpm verify:release` before an immutable release directory is activated;
- rollback only switches `/opt/a-share-analysis/current` to a prior complete release and restarts systemd services.
Remove the active Docker deployment link from `README.md` and `docs/index.md`.
- [x] **Step 2: Update mandatory engineering and workflow rules**
In code standards, replace the dual-deployment variable rule with:
```text
开发源码进程与 Ubuntu 生产源码部署复用同一变量契约;项目脚本不得安装、启动、停止或删除 Redis、MySQL、RocketMQ 等外部基础设施。
```
Replace `开发、测试、Docker 和生产环境` with `开发、测试和生产环境`. In workflow rules, require env/systemd/Nginx synchronization and immutable release-directory rollback; remove Compose/image language. State that `verify:release` is the source-release gate and that unavailable external infrastructure is a failed prerequisite, never a container fallback.
- [x] **Step 3: Update GOV-009 current records without falsifying history**
Revise PRD scope, R7, design configuration/deployment sections, automated test plan, current release notes, rollback, and architecture review to match actual source-only implementation. Add `source_only_deployment_implementation_plan` to `manifest.yaml`. Keep `status: reviewing`, `release: unreleased`, and the architecture confirmation completion gate.
In `qa/test-results.md`, preserve dated Docker validation as historical fact and add a later source-only section explaining it is superseded and no longer executable. Do not rewrite old commit results as if Docker was never tested.
If GOV-006's manifest presents its Docker approach as current, add only a dated `superseded_by` pointer to the GOV-009 source-only decision; do not rewrite its original PRD/design/test evidence.
- [x] **Step 4: Add the unreleased changelog decision**
At the top current section, record that the project removed Docker/Compose/image validation and now supports only Ubuntu source deployment with external infrastructure. Leave older entries about when Docker was added unchanged below it.
- [x] **Step 5: Run active-document policy tests and scan for contradictions**
Run:
```bash
pnpm test:environment-baseline
rg -n '双部署|同时支持 Docker|Compose 只|Docker Compose 生产|verify:docker|check:images' README.md docs/index.md docs/architecture docs/governance docs/deployment docs/features/GOV-009-application-scaffold-baseline package.json
```
Expected: tests pass. Search results may remain only in explicitly dated historical results or supersession explanations; no current instruction may expose a Docker command or claim Docker support.
- [x] **Step 6: Detect scope, commit, and push documentation alignment**
Run GitNexus `detect_changes(scope: "all")`, then:
```bash
git add README.md CHANGELOG.md docs
git commit -m "docs(GOV-009): 统一仅源码部署规范"
git push origin "$(git branch --show-current)"
```
---
### Task 5: Complete Verification, GitNexus, and Two Reviews
**Files:**
- Modify: `docs/features/GOV-009-application-scaffold-baseline/gitnexus/after.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/gitnexus/comparison.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/gitnexus/detected-changes.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/qa/test-results.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/review/code-review.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/review/standards-review.md`
- Modify: `docs/features/GOV-009-application-scaffold-baseline/source-only-deployment-design.md`
**Interfaces:**
- Consumes: the completed implementation, root verification scripts, GitNexus graph, and Review standards.
- Produces: final evidence for the deployment-policy adjustment while GOV-009 remains `reviewing/unreleased` pending user architecture confirmation.
- [x] **Step 1: Run focused tests and full source release verification**
Run without Docker:
```bash
pnpm test:deployment
pnpm test:environment-baseline
node --test server/tools/run-test-api.test.mjs
pnpm verify:release
```
Expected: all pass. `verify:release` must execute the full root verification, desktop/mobile Playwright checks, builds, and `verify:source`; it must not invoke Docker.
- [x] **Step 2: Perform visual verification at both configured viewports**
Use Playwright/browser screenshots at 1440x900 and 390x844. Confirm the page is nonblank, API health data renders, no content overlaps, and browser console/network contains no blocking error. Save screenshots under the existing ignored/output convention and record results, not binary artifacts, in `qa/test-results.md`.
- [x] **Step 3: Refresh GitNexus and record before/after evidence**
Run:
```bash
npx gitnexus analyze
npx gitnexus status
npm run governance:finish -- GOV-009 application-scaffold-baseline
```
Then use GitNexus `detect_changes(scope: "compare", base_ref: "cfcd7f13d9a6a35173d01bd8ca1458911190e70f")`. Record node/edge/flow counts, removed Docker verifier symbols, added source verifier symbols, and affected processes in the three GitNexus records. Do not commit `.gitnexus/`.
- [x] **Step 4: Conduct code Review**
Review for functional regressions, release-gate bypasses, unsafe process spawning, Redis failure semantics, missing build artifacts, and test gaps. Resolve every blocking finding, rerun affected checks, and finish `review/code-review.md` with the exact line:
```text
最终结论:passed
```
- [x] **Step 5: Conduct development-standards Review**
Review source-only policy consistency, Chinese comments for non-obvious logic, file responsibility, no secrets, MySQL 5.7 constraints, no production access, historical traceability, Chinese commits, Gitea push state, and the absence of a `v0.0.8` tag. Finish `review/standards-review.md` with the exact line:
```text
最终结论:passed
```
- [x] **Step 6: Re-run final verification after Review edits**
Run:
```bash
pnpm format:check
pnpm verify:release
git status --short
```
Expected: formatting and release verification pass. Only intended Review/evidence files remain uncommitted.
- [x] **Step 7: Detect final scope, commit, and push evidence**
Run GitNexus `detect_changes(scope: "all")`, verify no unexpected application flow changed, then:
```bash
git add docs/features/GOV-009-application-scaffold-baseline
git commit -m "docs(GOV-009): 封存仅源码部署复核证据"
git push origin "$(git branch --show-current)"
```
- [x] **Step 8: Confirm remote consistency without releasing**
Run:
```bash
git status --short --branch
git ls-remote --heads origin "$(git branch --show-current)"
git tag --list v0.0.8
```
Expected: worktree clean, local HEAD equals the remote branch SHA, and `v0.0.8` has no output. Present the implemented architecture and remaining GOV-009 completion gate to the user for the separately required confirmation.
---
## Self-Review Record
- Spec coverage: every confirmed deletion, external-service boundary, source gate, Ubuntu release rule, Redis failure behavior, historical evidence rule, Review requirement, and no-tag constraint maps to a task above.
- Placeholder scan: the plan contains no deferred implementation placeholders; code interfaces, commands, expected RED/GREEN results, and commit boundaries are explicit.
- Type and name consistency: `verifySourceDeployment`, `checkLocalRedis`, `runTestApi`, `test:deployment`, `verify:source`, and `verify:release` retain the same names across production, tests, and documentation tasks.
- Scope: this plan changes deployment policy and validation only; it does not add market features, user systems, infrastructure installation, database migrations, or RocketMQ message sending.

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