Compare commits

13 Commits
96 changed files with 2197 additions and 27 deletions
+6 -4
View File
@@ -11,17 +11,19 @@
1. 修改生产代码前必须执行 `npm run governance:start -- <功能编号> <短名称>`,刷新 GitNexus,并完成开发前影响分析。
2. 修改完成后必须执行测试、构建、视觉验证和 `npm run governance:finish -- <功能编号> <短名称>`,再次刷新 GitNexus并保存前后对比。
3. 任何功能必须先有 `docs/features/<功能编号>-<短名称>/` 功能档案;没有需求、设计、计划和回退说明不得视为完成。
3. 任何功能必须先有 `docs/features/<功能编号>-<短名称>/` 功能档案;没有 PRD、需求、设计、计划和回退说明不得视为完成。
4. Git 提交必须使用中文 Conventional Commit,并带功能编号;禁止英文摘要和含糊提交信息。
5. 代码必须为关键业务逻辑、数据口径、异常恢复和架构取舍提供准确的中文注释;禁止无意义逐行注释。
6. 文件按稳定职责拆分,不以追求“原子化”为目的过度拆分。优先保证普通开发者能够连续阅读完整业务流程。
7. 不使用 GitHub。当前只使用本地 Git,远程仓库仅在用户安装 Gitea 后配置。
8. 禁止提交密钥、真实凭据、生产数据、`.env` 和 GitNexus 本地索引。
7. 不使用 GitHub。本项目唯一远程仓库为项目级配置的 Gitea `https://git.foximao.com/FoXiMao/a-share-analysis.git`;禁止修改 Git 全局配置或影响其他项目。
8. 禁止提交密钥、密码、访问令牌、生产数据、`.env` 和 GitNexus 本地索引;凭据不得写入远程 URL、文档、脚本或命令参数。
9. 开发完成后必须先通过代码 Review 和开发规范符合性 Review,再进入发布;Review 结论和问题处置必须写入功能档案。
10. 每次提交验证通过后必须立即推送当前分支到项目 Gitea;本次新建标签必须单独推送。推送失败时任务不得标记完成,禁止强推或自动覆盖未知远程提交。
<!-- gitnexus:start -->
# GitNexus — Code Intelligence
This project is indexed by GitNexus as **a-share-analysis** (171 symbols, 192 relationships, 0 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.
This project is indexed by GitNexus as **a-share-analysis** (528 symbols, 553 relationships, 0 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.
+21
View File
@@ -2,6 +2,27 @@
本项目采用语义化版本。功能级变化请从 `docs/features/` 按功能编号追溯。
## 0.0.4 - 2026-08-13
- 固定 MySQL 5.7.x、`utf8mb4` 和 `utf8mb4_general_ci` 技术基线。
- 增加 MySQL 8.x 禁用能力、迁移、索引、比较语义和 Review 规则。
- 新增数据库基线自动化契约测试。
## 0.0.3 - 2026-08-12
- 将当前分支推送设为每次提交后的强制步骤,新标签采用精确推送。
- 将远程同步成功加入完成定义,明确失败留痕、禁止强推和远程引用核对规则。
- GOV-004 取代 GOV-003 的“只接入、不主动推送”历史规则,但保留原档案用于追溯。
## 0.0.2 - 2026-08-12
- 配置仅作用于本项目的 Gitea 远程仓库和凭据隔离策略。
- 明确密码不入文档、不入配置、不入 Git 历史,以及推送需再次获得用户明确授权。
## 0.0.1 - 2026-08-12
- 增加 PRD 与开发后 Review 强制门禁。
## 0.0.0 - 2026-08-12
- 建立工程治理、GitNexus 门禁和功能档案体系。
+10 -1
View File
@@ -28,4 +28,13 @@ The first implementation slice is the market overview screen in `web/`.
npm run governance:start -- FEAT-MO-001 market-overview
```
当前只使用本地 Git。Gitea 安装完成后再按治理文档配置远程仓库。
## 项目仓库
- Gitea:<https://git.foximao.com/FoXiMao/a-share-analysis>
- 远程名:`origin`
- 配置范围:仅当前项目的 `.git/config`,不修改 Git 全局配置。
凭据不写入仓库、文档或远程 URL。首次需要认证时由 Git 调用 macOS Keychain
安全保存;详细规则见 [Git 与 Gitea 规范](docs/governance/version-control-and-gitea.md)。
验证通过的中文提交必须立即同步当前分支到 Gitea;本次创建的版本标签单独同步。远程同步失败时,开发任务保持未完成状态。
+1 -1
View File
@@ -1 +1 @@
0.0.0
0.0.4
+9 -1
View File
@@ -36,6 +36,14 @@ tools/ 可重复执行的治理和开发工具
- Redis保存最新快照、缓存、锁和限流状态。
- Vue前端只读后端 API,不直接接触外部数据源和密钥。
## 3. 当前实施顺序
## 3. 数据库技术基线
- 数据库服务端固定使用 MySQL 5.7.x,开发、测试和生产环境禁止使用 MySQL 8.x 代替兼容性验证。
- 数据库与表默认字符集固定为 `utf8mb4`,排序规则固定为 `utf8mb4_general_ci`。
- 数据库初始化、表结构、连接会话、ORM 配置和迁移脚本必须显式声明或验证该字符集与排序规则,不能依赖服务器默认值。
- 正式启用持久化前,必须在真实 MySQL 5.7 环境验证服务端版本、Schema/表排序规则、迁移和关键查询。
- 第一阶段市场概览只定义 MySQL Repository 接口并使用内存实现,不启动数据库、不建立生产连接;后续启用时不得改变前端 API 和核心分析契约。
## 4. 当前实施顺序
第一阶段先实现可交互的市场综合概览和稳定数据契约,再接入正式行情采集链路。用户、邀请、权限、会员和支付后置,不进入当前核心架构。
@@ -5,6 +5,7 @@ status: approved
owner: project
created_at: 2026-08-12
requirements: requirements.md
prd: prd.md
design: design.md
implementation_plan: implementation-plan.md
traceability_note: 开发尚未开始,GitNexus与QA证据将在开发门禁执行时创建
@@ -0,0 +1,94 @@
# 市场综合概览 PRD
- 功能编号:FEAT-MO-001
- PRD版本:0.1
- 状态:approved
- 日期:2026-08-12
## 背景与问题
现有概念稿能够展示指数、情绪、板块和资金数据,但更接近数据看板,用户难以快速回答“市场当前强弱、量能是否支持、行情由谁驱动、风险在哪里”。
## 目标用户与使用场景
主要用户为产品所有者,少量朋友可以使用同一只读工具。用户在盘中以分钟级数据观察全市场状态,在收盘后查看冻结的最终总结和历史交易日结果。
## 产品目标
- 用户进入市场概览后,优先看到一句市场定性以及驱动、风险两列摘要。
- 用户能够继续核对指数、市场宽度、量能、板块、情绪和资金证据。
- 用户能够在综合、短线和中长线视角间临时切换,并选择规则、AI、混合或对照分析。
- 所有实时性、数据日期和分析依据均明确可见。
## 非目标
- 不做自选股、持仓、笔记、交易计划、社区、荐股、跟单和公开组合。
- 本切片不接正式行情源、RabbitMQ、MySQL、Redis和付费 AI。
- 本切片不实现用户、邀请、会员、订阅和支付。
- ETF监控、两融数据、大盘云图和实时消息仍是独立一级模块。
## 用户流程
1. 用户进入“市场概览”。
2. 首先读取市场定性、驱动因素和风险信号。
3. 通过“查看依据”核对指标来源。
4. 向下查看指数、宽度、量能、板块、情绪和资金摘要。
5. 点击轻量分析状态入口,临时切换分析周期和分析引擎。
6. 点击指数或板块入口进入未来的详情页;首个切片只保留可识别入口。
## 功能需求
| 编号 | 优先级 | 需求 | 可观察结果 |
|---|---|---|---|
| FR-001 | P0 | 结论优先展示市场定性 | 首屏顶部出现一句结论、市场状态、量能状态和情绪状态 |
| FR-002 | P0 | 展示驱动与风险 | 结论下方并列显示至少三条驱动和三条风险证据 |
| FR-003 | P0 | 展示数据新鲜度 | 页面显示交易状态、数据更新时间和正常/延迟/不完整状态 |
| FR-004 | P0 | 提供分析偏好 | 可选择综合/短线/中长线和规则/AI/混合/对照,并在本地保存默认值 |
| FR-005 | P1 | 展示市场证据模块 | 指数、宽度、量能、板块、情绪和资金摘要可阅读 |
| FR-006 | P1 | 查看结论依据 | 点击入口后展示指标、数值、口径和更新时间 |
| FR-007 | P1 | 支持异常状态 | 加载、空、部分数据、过期和错误状态具有明确文案 |
## 数据与口径
首个切片使用确定性模拟快照。字段仍必须包含交易日期、快照时间、来源状态、完整性和单位,以便以后无结构变更地替换为后端 API。
A 股使用红涨绿跌。成交额统一展示为亿元,比例明确使用百分比。历史数据和低频资金数据必须显示实际数据日期,旧数据不得标记为实时。
## 状态与异常
- 交易中:显示分钟级更新时间。
- 午间休市或已收盘:显示对应市场状态。
- 数据延迟:保留最近有效值并标记延迟。
- 部分数据:只隐藏缺失指标,不让整页失败。
- AI不可用:规则分析继续可用,并标记降级。
## 权限、合规与安全
当前为只读访问,不提供交易指令。结论不得包含买入、卖出、目标价和仓位建议。付费 AI 密钥未来只保存在服务端。
## 成功指标
- 用户能够在 30 秒内说出市场定性、主要驱动和首要风险。
- 所有结论均能展开查看至少一项数据依据。
- 页面在目标桌面视口和窄窗口中不阻断核心内容。
## 验收标准
- Given 页面加载有效快照,When 用户进入市场概览,Then 结论、驱动、风险和更新时间在首屏可见。
- Given 用户打开分析状态入口,When 切换周期或引擎,Then 页面状态立即更新且可选择设为默认。
- Given 数据快照被标记为延迟,When 页面渲染,Then 最近有效值保留并明确显示延迟,不能显示“实时”。
- Given 用户点击查看依据,When 抽屉打开,Then 能看到指标名称、数值、口径和更新时间。
## 风险与依赖
- 免费数据源稳定性和商业授权需要在正式接入阶段重新评估。
- AI 分析必须受结构化数据和规则事实约束。
- 首个视觉版本用于验证信息层级,不作为最终设计冻结版本。
## 发布范围与回退触发条件
本次仅发布本地 Vue 3 首屏原型。核心交互不可用、结论依据不可追溯或窄屏遮挡核心信息时不得发布;出现回归时回退到上一个本地标签。
## 变更记录
- 0.1:建立首版 PRD,补充结论优先、分析偏好和异常状态。
@@ -5,6 +5,7 @@ status: released
owner: project
created_at: 2026-08-12
requirements: requirements.md
prd: prd.md
design: design.md
implementation_plan: implementation-plan.md
decisions:
@@ -13,6 +14,8 @@ decisions:
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
baseline_commit: 7cc2ba0
implementation_commit: efdfb33
release: v0.0.0
@@ -0,0 +1,26 @@
# 工程治理基线 PRD(追补)
- 功能编号:GOV-001
- PRD版本:0.1
- 状态:retrospective
- 日期:2026-08-12
## 背景与目标
该治理功能早于 PRD 强制门禁发布。本文件用于追补当时已经确认的产品目标:所有开发步骤可阅读、可比较、可追溯、可回退,并由 GitNexus在开发前后总结影响。
## 使用者
项目所有者、后续开发者和开发代理。
## 核心需求
- 分离代码开发规范和开发流程规范。
- 要求关键代码写有信息价值的中文注释。
- 禁止过度拆分代码。
- 使用中文提交。
- 不使用 GitHub,未来接入自建 Gitea。
## 验收结果
上述内容已在 `v0.0.0` 建立。GOV-002 将 PRD 和 Review补充为后续功能的强制门禁。
@@ -0,0 +1,8 @@
# 代码 Review(追补)
- reviewer_type:self
- 审查范围:GOV-001 治理脚本与测试
最终结论:passed
治理脚本具有功能编号、路径和必备材料的行为测试;开发前后命令使用参数数组调用外部进程,未拼接用户输入到 Shell。GOV-002 继续增加 PRD 和 Review材料校验。
@@ -0,0 +1,7 @@
# 开发规范符合性 Review(追补)
- reviewer_type:self
最终结论:passed
GOV-001 已满足当时生效的 GitNexus 双门禁、中文提交、关键中文注释、文档追溯和本地 Git 约束。PRD 与独立 Review要求从 GOV-002 起正式生效,本文件明确标记为追补材料,不伪装成发布前独立审查。
@@ -0,0 +1,5 @@
# 设计
PRD 与工程需求分离:PRD 定义产品问题、用户、范围和验收;`requirements.md`定义实现约束。Review 分为代码质量和规范符合性两条门禁,两者都必须给出明确状态。
为了适合个人项目,允许结构化自审,但必须诚实标记审查者类型;未来经用户授权可使用独立代理或人工审查。
@@ -0,0 +1,11 @@
# GitNexus 开发后基线
- 日期:2026-08-12
- 开发前基线提交:`40f3b2e`
- 已索引实现提交:`fb4383f`
- 图谱:300 个符号、325 条关系、5 个功能簇、0 条执行流程
- 状态:最新
新增 `getUnpassedReviewFiles` 符号只有 `finish.mjs` 一个直接生产依赖,受影响流程为 0,风险为低。
实现提交后再次执行变更检测,结果为 `No changes detected.`。
@@ -0,0 +1,26 @@
# GitNexus 开发前基线
- 功能编号:GOV-002
- 记录时间:2026年8月12日 GMT+8 18:20:46
- 分支:main
- 基线提交:40f3b2ef6f3b
## 工作区
```text
(干净)
```
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/12/2026, 6:19:51 PM
Indexed commit: 40f3b2e
Current commit: 40f3b2e
Status: ✅ up-to-date
```
## 后续人工分析
在修改代码前,将 GitNexus query、context、impact 的结论写入 `gitnexus/impact-plan.md`。高风险结果必须先获得用户确认。
@@ -0,0 +1,10 @@
# GitNexus 前后比较
| 项目 | 开发前 | 开发后 | 变化 |
|---|---:|---:|---:|
| 符号 | 171 | 300 | +129 |
| 关系 | 192 | 325 | +133 |
| 功能簇 | 4 | 5 | +1 |
| 执行流程 | 0 | 0 | 0 |
增长主要来自正式市场概览 PRD、PRD/Review规范、模板和 GOV-002 功能档案。实际暂存变更影响为低,没有计划外业务流程。
@@ -0,0 +1,10 @@
# 实际变更检测
```text
npx gitnexus detect-changes --repo a-share-analysis --scope staged
Changes: 38 files, 114 symbols
Affected processes: 0
Risk level: low
```
变更集中在 PRD、Review规范与模板、现有功能档案和治理完成门禁。没有业务页面、API、数据库、RabbitMQ消息或部署配置变化。
@@ -0,0 +1,8 @@
# GitNexus 开发前影响计划
- 目标符号:`getRequiredFeatureFiles`。
- 直接依赖:`tools/governance/finish.mjs`。
- 受影响流程:0。
- GitNexus风险:低。
预期影响是完成门禁新增三份必备材料,不改变开发前索引、业务代码、API、数据库或界面行为。
@@ -0,0 +1,9 @@
# 实施计划
1. 执行开发前 GitNexus 索引、查询和影响分析。
2. 先修改测试,让缺少 PRD 与 Review清单时失败。
3. 更新完成门禁清单使测试通过。
4. 新增 PRD、Review规范和模板。
5. 更新现有治理文档与市场概览功能档案。
6. 执行测试、GitNexus开发后分析和两类 Review。
7. 使用中文提交并建立本地补丁版本标签。
@@ -0,0 +1,17 @@
id: GOV-002
name: PRD 与 Review 门禁
slug: prd-review-gates
status: released
owner: project
created_at: 2026-08-12
prd: prd.md
requirements: requirements.md
design: design.md
implementation_plan: implementation-plan.md
gitnexus_before: gitnexus/before.md
gitnexus_after: gitnexus/after.md
gitnexus_comparison: gitnexus/comparison.md
code_review: review/code-review.md
standards_review: review/standards-review.md
implementation_commit: fb4383f
release: v0.0.1
@@ -0,0 +1,26 @@
# PRD 与 Review 门禁 PRD
- 功能编号:GOV-002
- PRD版本:0.1
- 状态:approved
- 日期:2026-08-12
## 问题
现有档案只有工程需求,没有独立 PRD;开发完成后也没有正式 Review环节,无法证明实现符合产品目标和开发规范。
## 目标
- 每个功能必须有可测试、可版本化的 PRD。
- 每个功能发布前必须完成代码 Review 和开发规范符合性 Review。
- 完成门禁自动检查三份材料存在且非空。
## 非目标
本功能不接入外部代码审查平台,不配置 Gitea远程,也不修改业务功能。
## 验收标准
- 完成门禁清单包含 `prd.md`、`review/code-review.md` 和 `review/standards-review.md`。
- 市场概览具有正式 PRD。
- 流程文档明确 Review 不通过时的回流路径。
@@ -0,0 +1,14 @@
# 测试结果
## 测试先行证据
1. 必备文件清单测试先因缺少 `prd.md` 和两类 Review失败。
2. 更新清单后,4 个原有测试通过。
3. 新增 Review状态测试先因 `getUnpassedReviewFiles` 不存在而失败。
4. 实现固定最终结论校验后,5 个测试通过。
## 门禁行为
`pending` Review执行 `npm run governance:finish -- GOV-002 prd-review-gates` 时退出码为 1,并准确列出两份未通过报告。
两份 Review 改为明确 `passed` 后,同一完成门禁执行成功。最终治理测试为 5 个通过、0 个失败。
@@ -0,0 +1,3 @@
# 视觉 QA
本功能不修改用户界面,视觉 QA 不适用。
@@ -0,0 +1,10 @@
# 发布说明
## v0.0.1
新增 PRD 事实来源与开发后双 Review 发布门禁,不改变业务功能。
- 实现提交:`fb4383f`。
- 功能档案强制包含 PRD、代码 Review 和规范符合性 Review。
- 完成门禁拒绝 `pending`、`blocked` 和 `changes_required` Review。
- 为市场综合概览补充正式 PRD。
@@ -0,0 +1,7 @@
# 工程需求
- 更新功能档案必备文件清单。
- 为新增清单先写失败测试并完成红—绿验证。
- 提供 PRD 与两类 Review 的规范和模板。
- 更新 AGENTS、开发流程、代码规范和追溯目录。
- 对 GOV-001明确追补状态,对 FEAT-MO-001补充正式 PRD。
@@ -0,0 +1,29 @@
# 代码 Review
- reviewer_type:self
- reviewer:Codex
- 基线提交:`40f3b2e`
- 实现提交:`fb4383f`
- 审查范围:治理必备文件清单、Review完成门禁、PRD与Review规范
- 日期:2026-08-12
## PRD 与设计符合性
实现覆盖 PRD 的三项验收:必备清单加入 PRD和两类Review;市场概览新增正式PRD;开发流程加入Review回流和发布门禁。
## 发现与处置
| 严重程度 | 发现 | 处置 |
|---|---|---|
| Important | 最初只检查 Review 文件非空,`pending` 报告也可能通过 | 新增 `getUnpassedReviewFiles`,要求两份报告都包含固定最终结论 `passed` |
| Important | 新门禁行为缺少回归测试 | 先写失败测试,确认缺少导出时失败,再实现并验证通过 |
| Minor | 当前是实现者自审,不具备独立审查视角 | 诚实标记 `reviewer_type: self`;未来用户授权多代理或有其他开发者时优先独立审查 |
## 验证
- 5 个治理测试通过。
- `pending` Review 的完成门禁以退出码 1 失败,并列出两份未通过报告。
- GitNexus 对新增 Review校验的上游影响为 1 个直接依赖、0 个流程,风险为低。
- 完整暂存区变更检测为 38 个文件、114 个符号、0 条流程,风险为低。
最终结论:passed
@@ -0,0 +1,23 @@
# 开发规范符合性 Review
- reviewer_type:self
- reviewer:Codex
- 实现提交:`fb4383f`
- 日期:2026-08-12
## 检查结果
- [x] 新增公共函数包含解释门禁原因的中文注释。
- [x] 校验逻辑保留在现有 `feature-record.mjs`,没有为单个判断过度拆分文件。
- [x] 命名明确区分必备文件和未通过 Review。
- [x] Review结论采用固定机器可读行,错误信息列出具体文件。
- [x] 新行为有测试先行的红—绿证据。
- [x] GitNexus开发前索引、查询、上下文和影响分析已经执行。
- [x] PRD、工程需求、设计、测试计划和回退说明一致。
- [x] 未配置 GitHub 或其他远程仓库。
## 不符合项与处置
没有未解决的 Critical 或 Important 不符合项。独立审查缺失属于个人项目当前限制,已经在代码 Review中透明记录。
最终结论:passed
@@ -0,0 +1,3 @@
# 回退说明
本功能只增加文档和完成门禁清单。若门禁实现异常,使用修复提交恢复;确需回退时检出 `v0.0.0` 可获得升级前治理基线。
@@ -0,0 +1,6 @@
# 测试计划
- 证明旧清单缺少三份材料时测试失败。
- 证明新清单精确包含 PRD 与两类 Review。
- 完成门禁在任一材料缺失或为空时失败。
- 文档占位符、脚本语法、中文提交和远程仓库状态通过检查。
@@ -0,0 +1,17 @@
# 设计
## 配置边界
Git 仓库级配置存放在本项目 `.git/config`,天然不被提交,也不会作用于同一台机器上的其他项目。远程 URL 只包含协议、主机、所有者与仓库名,不嵌入用户名密码。
## 凭据处理
选择 macOS 原生 `osxkeychain` 凭据助手,避免明文凭据。设置 `credential.useHttpPath=true`,使 `git.foximao.com` 下不同仓库可以按 URL 路径隔离凭据;项目账号作为非敏感标识保存在本地仓库配置和治理文档中。
## 授权边界
远程接入分为两种权限:只读检查属于本次配置验证;推送会改变外部状态,需要用户另行明确授权。因此本次只执行非交互 `ls-remote`,不推送 `main` 或标签。
## 文档边界
文档记录可复现配置,但只引用密码的安全管理规则,不记录密码本身。这样既满足项目可追溯性,也避免秘密随克隆、备份和历史版本扩散。
@@ -0,0 +1,10 @@
# GitNexus 开发后结果
- 执行:`npx gitnexus analyze`。
- 提交前工作区索引:349 个节点、375 条关系、5 个集群、0 条执行流程。
- 提交后最终索引:361 个节点、387 条关系、5 个集群、0 条执行流程。
- 最终增量分析:4 个已修改文件、0 个新增文件、0 个删除文件;其余 77 个文件行复用既有索引。
- 索引提交:`b69023e`。
- 状态:up-to-date。
本功能没有修改生产代码、函数调用关系或业务流程。新增节点主要来自 GOV-003 功能档案和版本控制文档标题。提交后再次分析用于把索引锚定到确定提交,而不是只保留工作区快照。
@@ -0,0 +1,26 @@
# GitNexus 开发前基线
- 功能编号:GOV-003
- 记录时间:2026年8月12日 GMT+8 18:28:00
- 分支:main
- 基线提交:7c7190998b6d
## 工作区
```text
(干净)
```
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/12/2026, 6:27:10 PM
Indexed commit: 7c71909
Current commit: 7c71909
Status: ✅ up-to-date
```
## 后续人工分析
在修改代码前,将 GitNexus query、context、impact 的结论写入 `gitnexus/impact-plan.md`。高风险结果必须先获得用户确认。
@@ -0,0 +1,10 @@
# GitNexus 前后对比
| 项目 | 开发前 | 开发后 | 变化 |
|---|---:|---:|---:|
| 节点 | 301 | 361 | +60 |
| 关系 | 326 | 387 | +61 |
| 集群 | 5 | 5 | 0 |
| 执行流程 | 0 | 0 | 0 |
节点和关系增长来自 Gitea 治理说明及完整功能档案;没有新增或改变业务执行流程。变更检测风险为低,与开发前影响预估一致。最终索引已锚定实现提交 `b69023e`。
@@ -0,0 +1,8 @@
# GitNexus 变更检测
- 命令:`npx gitnexus detect-changes --repo a-share-analysis --scope all`。
- 最终暂存区识别范围:24 个文件、51 个文档符号。
- 受影响流程:0。
- 风险等级:低。
初次对未暂存变化检测到 7 个既有文件、14 个符号;完整暂存后,GOV-003 新建档案也被纳入检测,最终扩大为 24 个文件、51 个符号。纯文本版本文件和 Changelog 另外通过 `git status`、`git diff --stat` 和完整必备文件门禁核对。
@@ -0,0 +1,8 @@
# GitNexus 开发前影响分析
- 查询主题:`Gitea local remote version control configuration`。
- 主要关联:`docs/governance/version-control-and-gitea.md`、`docs/index.md`、`VERSION`、`AGENTS.md` 和 `README.md`。
- 符号影响检查:`getRequiredFeatureFiles` 只有 1 个直接上游依赖 `finish.mjs`,不参与执行流程,风险为低。
- 实际变化以文档和 Git 仓库级配置为主,不修改生产代码、API、数据库或前端页面。
- 预计影响:版本控制入口说明、开发代理约束、版本号和 GOV-003 功能档案。
- 风险控制:不修改全局配置、不保存密码、不执行推送;修改后重新索引并执行变更检测。
@@ -0,0 +1,10 @@
# 实施计划
1. 执行开发前 GitNexus 更新、查询和影响分析。
2. 核对当前远程、本地配置和全局配置基线。
3. 添加 `origin`,使用 `--local` 设置凭据隔离和默认推送目标。
4. 通过非交互 `git ls-remote origin` 验证只读连通性。
5. 更新版本控制规范、代理约束、README、文档索引与版本记录。
6. 保存 PRD、设计、测试、GitNexus 前后对比和回退说明。
7. 执行治理测试、敏感信息检查、配置边界检查和双 Review。
8. 以中文提交封存,并建立本地 `v0.0.2` 标签;不推送。
@@ -0,0 +1,17 @@
id: GOV-003
name: 项目专用 Gitea 远程仓库
slug: gitea-local-remote
status: released
owner: project
created_at: 2026-08-12
prd: prd.md
requirements: requirements.md
design: design.md
implementation_plan: implementation-plan.md
gitnexus_before: gitnexus/before.md
gitnexus_after: gitnexus/after.md
gitnexus_comparison: gitnexus/comparison.md
code_review: review/code-review.md
standards_review: review/standards-review.md
implementation_commit: b69023e
release: v0.0.2
@@ -0,0 +1,37 @@
# 项目专用 Gitea 远程仓库 PRD
- 功能编号:GOV-003
- PRD 版本:0.1
- 状态:approved
- 日期:2026-08-12
## 问题
项目已有可追溯的本地 Git 基线,但尚未关联用户自建 Gitea。接入过程中必须避免把项目凭据扩散到其他仓库,或把密码写入可提交文件和 Git 历史。
## 目标
- 将当前项目的 `origin` 指向指定 Gitea 仓库。
- 所有 Git 设置只作用于当前项目,不修改全局配置。
- 使用系统钥匙串保存未来交互式认证产生的凭据,并按仓库路径隔离。
- 在治理文档中记录地址、账号、配置、验证和回退方法。
## 非目标
- 本次不向远程推送任何提交或标签。
- 不在项目内保存密码或访问令牌。
- 不配置 Gitea Actions、Webhook、分支保护或持续集成服务端规则。
- 不修改其他项目的 Git 配置。
## 用户流程
项目维护者可以从文档确认唯一远程地址和项目账号;代理和开发者使用项目级配置进行读取。首次获得明确推送授权后,维护者在交互式终端完成认证,凭据由 macOS Keychain 管理。
## 验收标准
- `git remote -v` 的 fetch/push 均为指定仓库。
- 项目级凭据助手为 `osxkeychain`,`credential.useHttpPath` 为 `true`。
- 全局凭据助手与默认推送目标保持修改前状态。
- 无密码进入文档、远程 URL、Git 配置或 Git 历史。
- `git ls-remote origin` 可以建立只读连接。
- PRD、设计、测试、Review 和回退档案完整。
@@ -0,0 +1,20 @@
# 测试结果
## 结果摘要
- `npm run test:governance`:5 个测试通过,0 个失败。
- `GIT_TERMINAL_PROMPT=0 git ls-remote origin`:退出码 0;远程是空仓库,返回引用为空。
- fetch 与 push URL:均精确匹配指定 Gitea 仓库。
- 项目级配置:`osxkeychain`、路径隔离、账号和默认推送目标全部匹配设计。
- 全局边界:全局 `credential.helper` 和 `remote.pushDefault` 仍未设置。
- 凭据模式扫描:未发现带用户名密码的 URL、密码赋值或令牌赋值。
- `git diff --check`:通过。
## 诊断与修正
1. 测试计划最初写成不存在的 `npm test`,执行时因缺少脚本失败;检查 `package.json` 后修正为项目实际提供的 `npm run test:governance`,复测通过。
2. GitNexus 变更检测最初未指定仓库;本机存在多个索引时工具拒绝猜测。增加 `--repo a-share-analysis` 后成功;最终暂存区结果为 24 个文件、51 个符号、0 条流程,风险为低。
## 完成门禁
双 Review 完成后执行 `npm run governance:finish -- GOV-003 gitea-local-remote`,退出码为 0。门禁确认完整功能档案和两份固定 `passed` Review 均已就绪。
@@ -0,0 +1,3 @@
# 视觉验证
本功能只修改 Git 仓库级配置和治理文档,不改变界面、样式或交互,因此视觉验证不适用。
@@ -0,0 +1,9 @@
# 发布说明
## v0.0.2
- 实现提交:`b69023e`。
- 为当前项目配置指定 Gitea `origin`,不影响其他项目。
- 使用 macOS Keychain 与仓库路径隔离策略管理未来认证凭据。
- 增加远程接入、授权边界、验证和回退文档。
- 本版本只建立远程连接,不推送本地提交或标签。
@@ -0,0 +1,9 @@
# 工程需求
- 远程名固定为 `origin`,地址固定为 `https://git.foximao.com/FoXiMao/a-share-analysis.git`。
- 使用 `git config --local` 写入凭据助手、路径隔离、账号和默认推送目标。
- 不调用 `git config --global`,验证前后全局相关配置一致。
- 不将密码传给 Shell 命令,也不把密码写入仓库文件或 `.git/config`。
- 使用非交互、只读的 `git ls-remote origin` 检查网络与仓库可达性。
- 未取得单独明确授权时,不运行 `git push`。
- 更新根目录入口、治理规范、文档索引、版本和完整功能档案。
@@ -0,0 +1,31 @@
# 配置与文档 Review
- reviewer_type:self
- reviewer:Codex
- 基线提交:`7c71909`
- 实现提交:`b69023e`
- 审查范围:项目级 Gitea 远程、凭据隔离、治理文档和回退方案
- 日期:2026-08-12
## PRD 与设计符合性
实现满足六项验收标准:远程 URL 正确;凭据设置仅位于 `.git/config`;全局配置未变化;密码没有进入文档、配置或历史;只读连通性成功;功能档案完整。
## 发现与处置
| 严重程度 | 发现 | 处置 |
|---|---|---|
| Important | 用户提供了密码,但写入文档或命令会形成长期泄露面 | 文档只保存基础地址、账号和仓库 URL;密码不落盘,由 Keychain 在未来交互认证时接管 |
| Important | 使用全局凭据配置会影响其他项目 | 全部使用 `git config --local`,并验证相关全局项保持未设置 |
| Minor | 初始测试计划引用了不存在的 `npm test` | 改用仓库实际的 `npm run test:governance` 并复测 5/5 通过 |
| Minor | GitNexus 多仓库环境无法自动选择索引 | 显式增加 `--repo a-share-analysis`,变更检测成功 |
## 验证
- 远程只读连接、fetch/push URL 和四项本地配置断言全部通过。
- 全局配置边界断言通过。
- 凭据模式扫描与 `git diff --check` 通过。
- GitNexus 最终暂存区检测 24 个文件、51 个符号、0 条流程,风险为低。
- 没有执行 `git push`,未改变 Gitea 远程仓库内容。
最终结论:passed
@@ -0,0 +1,24 @@
# 开发规范符合性 Review
- reviewer_type:self
- reviewer:Codex
- 实现提交:`b69023e`
- 日期:2026-08-12
## 检查结果
- [x] 开发前执行治理启动命令并保存 GitNexus 基线。
- [x] PRD、工程需求、设计、实施计划、测试计划和回退说明一致。
- [x] 修改仅涉及项目级 Git 配置和治理文档,没有过度拆分生产代码。
- [x] 基础地址、账号和仓库 URL 可追溯,密码和令牌未进入仓库。
- [x] Git 全局配置没有修改,不影响其他项目。
- [x] 未配置 GitHub,唯一远程为用户指定 Gitea。
- [x] 没有未经授权推送外部状态。
- [x] 治理测试、配置断言、敏感信息扫描和 GitNexus 变更检测通过。
- [x] 本功能无界面变化,视觉验证已合理标记为不适用。
## 不符合项与处置
没有未解决的 Critical 或 Important 不符合项。两项执行期错误均属于测试命令选择问题,已修正文档并以成功复测关闭。
最终结论:passed
@@ -0,0 +1,13 @@
# 回退说明
本功能的运行时影响仅限当前项目 `.git/config`。如需解除接入,在本项目根目录执行:
```bash
git remote remove origin
git config --local --unset credential.helper
git config --local --unset credential.useHttpPath
git config --local --unset credential.username
git config --local --unset remote.pushDefault
```
若 Keychain 已在后续交互式认证中保存凭据,再使用“钥匙串访问”按 `git.foximao.com` 删除对应项。文档和版本记录通过新的中文修复提交回退;不得改写已共享历史。本次未执行推送,因此远程不存在需要回滚的外部提交。
@@ -0,0 +1,9 @@
# 测试计划
- 检查 `origin` 的 fetch/push URL 精确匹配指定仓库。
- 检查四项 Git 配置来自 `--local` 作用域。
- 检查全局凭据助手和默认推送目标仍保持未设置。
- 使用 `GIT_TERMINAL_PROMPT=0 git ls-remote origin` 验证远程只读连通性。
- 搜索仓库文件、暂存区 diff 和远程 URL,确认不存在密码或凭据 URL。
- 运行 `npm run test:governance` 和 `npm run governance:finish -- GOV-003 gitea-local-remote`。
- 本功能不改变页面,视觉验证标记为不适用并说明原因。
@@ -0,0 +1,78 @@
# 提交后强制推送 Gitea 设计规格
- 功能编号:GOV-004
- 规格版本:0.1
- 状态:approved_for_review
- 日期:2026-08-12
## 背景与目标
本地提交如果没有同步到远程,无法实现跨设备备份、Gitea 审阅和可靠的版本追溯。本功能把推送从“需要逐次授权的可选动作”改成项目开发流程的固定完成条件。
目标是:每次本地提交在验证通过后立即同步当前分支;创建版本标签后同步该标签;任何推送失败都会阻止任务被报告为完成。
## 方案比较
### 方案 A:按变化精确推送(采用)
- 普通提交执行 `git push origin <当前分支>`。
- 创建新标签后执行 `git push origin <标签名>`。
- 优点:只同步本次明确产生的引用,行为可预测,不会意外发布其他本地标签。
- 代价:分支和标签需要分别执行推送。
### 方案 B:每次提交推送分支及全部标签
- 执行 `git push origin <当前分支> --tags`。
- 优点:命令较少。
- 缺点:可能把尚未准备发布的历史或实验标签一并推送,不采用。
### 方案 C:仅发布时批量推送
- 多个本地提交积累到版本发布时再统一同步。
- 优点:减少远程交互次数。
- 缺点:提交期间缺少远程备份,也不符合“提交后需要推送”的要求,不采用。
## 强制流程
1. 完成测试、构建、Review、GitNexus 变更检测和敏感信息检查。
2. 创建符合中文 Conventional Commit 的本地提交。
3. 获取当前分支名,执行 `git push origin <当前分支>`。
4. 如果本次创建了标签,再执行 `git push origin <标签名>`。
5. 使用 `git status -sb` 或远程引用检查,确认本地分支与远程分支一致。
6. 把提交 SHA、推送目标、推送结果和标签结果写入功能档案。
7. 只有分支及本次新建标签全部推送成功后,任务才可以标记完成。
## 失败处理
- 认证、网络、分支保护或服务器错误发生时,保留本地提交和标签,不删除、不改写历史。
- 将任务状态标为“推送失败/未完成”,记录失败命令、时间和不包含凭据的错误摘要。
- 修复原因后重复同一个精确推送命令;禁止使用 `--force`、`--force-with-lease` 或绕过保护规则。
- 远程出现未知提交导致非快进失败时,先获取并检查差异,不自动 rebase、merge 或覆盖远程。
- 密码和令牌继续由 macOS Keychain 管理,禁止写入文档、脚本、远程 URL、命令参数和 Git 历史。
## 配置与作用域
- 唯一允许的推送远程是当前项目 `.git/config` 中的 `origin`。
- 推送前必须验证 `origin` 仍为 `https://git.foximao.com/FoXiMao/a-share-analysis.git`。
- 禁止修改 Git 全局配置,禁止影响其他项目,禁止新增 GitHub 远程。
- 本规则适用于业务代码、治理文档、规格、Review 修正和版本封存等所有提交。
## 文档变更范围
- `AGENTS.md`:把提交后推送改为代理强制要求。
- `docs/governance/development-workflow.md`:把推送加入开发后流程和完成定义。
- `docs/governance/version-control-and-gitea.md`:记录标准命令、失败处理和验证方法。
- `README.md`:简述项目提交会同步到 Gitea。
- `docs/features/GOV-004-mandatory-gitea-push/`:保存 PRD、需求、实施计划、测试、Review、GitNexus 前后对比、发布和回退证据。
GOV-003 是当时“只接入、不推送”的历史决策记录,保持原文不变;GOV-004 作为后续决策明确取代其推送授权规则,保证历史可追溯。
## 验收标准
- 所有现行入口规范不再包含“默认不推送”或“逐次取得用户授权”的冲突要求。
- 规范明确普通提交推当前分支、新标签单独推送、失败不算完成、禁止强推。
- `main` 的本地历史同步到 `origin/main`。
- 已有版本标签 `v0.0.0`、`v0.0.1`、`v0.0.2` 同步到远程。
- GOV-004 的提交和后续封存标签也按相同规则同步。
- 全局 Git 配置保持不变,敏感信息扫描无发现。
- 治理测试、完成门禁和 GitNexus 前后检测通过。
@@ -0,0 +1,10 @@
# GitNexus 开发后结果
- 执行:`npx gitnexus analyze`。
- 开发后工作区索引:426 个节点、452 条关系、5 个集群、0 条执行流程。
- 实现提交后索引:432 个节点、458 条关系、5 个集群、0 条执行流程。
- 增量分析:6 个已修改文件、17 个新增文件、0 个删除文件;75 个未变化文件行复用既有索引。
- 最终索引提交:`2a16e9f`。
- 状态:up-to-date。
本功能没有修改生产代码、函数调用关系或业务执行流程。实现提交后再次分析,最终索引已锚定到确定提交。
@@ -0,0 +1,26 @@
# GitNexus 开发前基线
- 功能编号:GOV-004
- 记录时间:2026年8月12日 GMT+8 18:35:43
- 分支:main
- 基线提交:4b390d998909
## 工作区
```text
(干净)
```
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/12/2026, 6:34:06 PM
Indexed commit: 4b390d9
Current commit: 4b390d9
Status: ✅ up-to-date
```
## 后续人工分析
在修改代码前,将 GitNexus query、context、impact 的结论写入 `gitnexus/impact-plan.md`。高风险结果必须先获得用户确认。
@@ -0,0 +1,10 @@
# GitNexus 前后对比
| 项目 | 开发前 | 实现提交后 | 变化 |
|---|---:|---:|---:|
| 节点 | 361 | 432 | +71 |
| 关系 | 387 | 458 | +71 |
| 集群 | 5 | 5 | 0 |
| 执行流程 | 0 | 0 | 0 |
增长来自 GOV-004 的规格、实施计划、现行治理入口和追溯档案。执行流程保持为 0,符合开发前“只影响治理文档与远程同步流程”的预估。最终索引锚定实现提交 `2a16e9f`。
@@ -0,0 +1,9 @@
# GitNexus 变更检测
- 初次工作区命令:`npx gitnexus detect-changes --repo a-share-analysis --scope all`。
- 初次识别:7 个既有文件、16 个文档符号。
- 最终暂存区识别:21 个文件、44 个文档符号。
- 受影响流程:0。
- 风险等级:低。
完整暂存后使用 `--scope staged` 将 GOV-004 新建档案纳入检测;最终结果仍为 0 条受影响流程、低风险。
@@ -0,0 +1,9 @@
# GitNexus 开发前影响分析
- 查询主题:`mandatory push after commit Gitea workflow`。
- 主要关联:GOV-003 功能档案、`docs/governance/version-control-and-gitea.md`、`docs/governance/development-workflow.md`、`AGENTS.md`、`README.md` 和文档索引。
- 查询没有返回业务执行流程,说明变化不触及前端、后端、数据任务或运行时调用链。
- 本次不修改函数、类或方法,因此不存在需要符号级上游影响分析的生产代码目标。
- 预计影响:开发完成定义、远程同步授权规则、标签发布规则、版本号和治理档案。
- 风险:文档冲突可能让代理继续遵循旧规则;通过限定扫描现行治理入口并保留 GOV-003 为历史记录解决。
- 外部状态风险:推送改变 Gitea;用户已经明确授权,并要求此后把推送设为固定开发步骤。
@@ -0,0 +1,169 @@
# 提交后强制推送 Gitea 实施计划
> **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:** 将每次验证通过的本地提交和本次新增版本标签精确推送到项目专用 Gitea,并把推送成功设为任务完成条件。
**Architecture:** Git 仍使用当前项目 `.git/config` 中唯一的 `origin`,不增加脚本服务或全局配置。流程层通过现行治理文档、代理入口和 GOV-004 功能档案强制执行“验证—提交—推送—远程核对”,GOV-003 保持为历史决策,由 GOV-004 明确取代其推送规则。
**Tech Stack:** Git、Gitea、macOS Keychain、Markdown、GitNexus、Node.js 治理门禁。
## Global Constraints
- 远程固定为 `https://git.foximao.com/FoXiMao/a-share-analysis.git`,作用域仅限当前项目。
- 不修改 Git 全局配置,不新增 GitHub 远程。
- 普通提交只推送当前分支;新标签只推送本次创建的标签。
- 推送失败时任务不得标记完成,且禁止任何形式的强推。
- 密码和令牌不得进入文件、远程 URL、命令参数或 Git 历史。
- 每次提交必须使用中文 Conventional Commit,并在提交后立即推送。
---
### Task 1: 固化产品与工程规则
**Files:**
- Create: `docs/features/GOV-004-mandatory-gitea-push/prd.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/requirements.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/test-plan.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/gitnexus/impact-plan.md`
- Modify: `docs/features/GOV-004-mandatory-gitea-push/implementation-plan.md`
**Interfaces:**
- Consumes: 已确认的 `design.md` 和 GitNexus 开发前基线。
- Produces: 可由完成门禁和 Review 逐条验证的功能需求。
- [ ] **Step 1: 编写 PRD 与工程需求**
明确当前分支推送、新标签精确推送、失败阻断完成、禁止强推、凭据安全和现有历史标签同步六类验收项。
- [ ] **Step 2: 编写测试及影响计划**
列出治理测试、冲突文本扫描、远程 URL、远程分支 SHA、远程标签集合、全局配置边界和敏感信息扫描命令。
- [ ] **Step 3: 核对规格覆盖**
运行:
```bash
rg -n "当前分支|新标签|推送失败|禁止强推|Keychain|v0.0.0|v0.0.1|v0.0.2" docs/features/GOV-004-mandatory-gitea-push
```
预期:所有约束均能从设计、PRD、需求或测试计划定位。
### Task 2: 更新现行治理入口
**Files:**
- Modify: `AGENTS.md`
- Modify: `README.md`
- Modify: `docs/governance/development-workflow.md`
- Modify: `docs/governance/version-control-and-gitea.md`
- Modify: `docs/index.md`
- Modify: `CHANGELOG.md`
- Modify: `VERSION`
**Interfaces:**
- Consumes: Task 1 的验收要求。
- Produces: 对所有后续代理和开发者生效的强制推送规范。
- [ ] **Step 1: 更新代理入口和开发流程**
删除“推送需逐次授权”的现行条款,加入提交后立即推送、标签精确推送、失败阻断完成和禁止强推。
- [ ] **Step 2: 更新 Gitea 操作规范**
记录 `git push origin <当前分支>`、`git push origin <标签名>`、远程 SHA 验证、错误留痕和安全重试规则。
- [ ] **Step 3: 更新索引和版本记录**
新增 GOV-004 文档入口,将版本提升到 `0.0.3` 并记录规则变化。
- [ ] **Step 4: 验证不存在现行冲突**
运行:
```bash
rg -n "不得主动.*推送|只有用户明确要求.*推送|本地提交和标签完成后仍不得自动推送" AGENTS.md README.md docs/governance
```
预期:无匹配。GOV-003 历史档案允许保留旧规则。
### Task 3: 补齐验证、Review 与发布档案
**Files:**
- Create: `docs/features/GOV-004-mandatory-gitea-push/manifest.yaml`
- Create: `docs/features/GOV-004-mandatory-gitea-push/gitnexus/after.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/gitnexus/detected-changes.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/gitnexus/comparison.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/qa/test-results.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/qa/visual-qa.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/review/code-review.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/review/standards-review.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/release-notes.md`
- Create: `docs/features/GOV-004-mandatory-gitea-push/rollback.md`
**Interfaces:**
- Consumes: Task 2 的文档 diff 和远程同步结果。
- Produces: GOV-004 完成门禁所需的全部追溯文件。
- [ ] **Step 1: 执行本地验证**
运行:
```bash
npm run test:governance
git diff --check
npx gitnexus analyze
npx gitnexus detect-changes --repo a-share-analysis --scope all
```
预期:5 个治理测试通过、diff 无空白错误、GitNexus 状态最新且风险为低。
- [ ] **Step 2: 扫描敏感信息和全局配置边界**
对仓库文件与暂存 diff 扫描凭据 URL、密码和令牌赋值;确认全局 `credential.helper` 与 `remote.pushDefault` 未被本功能修改。
- [ ] **Step 3: 编写双 Review 和完成档案**
两份 Review 必须逐条对应 PRD,处理所有 Important 问题,并以固定行 `最终结论:passed` 结束。
- [ ] **Step 4: 运行完成门禁**
运行:
```bash
npm run governance:finish -- GOV-004 mandatory-gitea-push
```
预期:退出码为 0。
### Task 4: 提交、推送并核对远程
**Files:**
- Modify: `docs/features/GOV-004-mandatory-gitea-push/manifest.yaml`
- Modify: `docs/features/GOV-004-mandatory-gitea-push/qa/test-results.md`
- Modify: `docs/features/GOV-004-mandatory-gitea-push/release-notes.md`
**Interfaces:**
- Consumes: 通过 Task 3 完成门禁的暂存区。
- Produces: 与本地 `main` 和版本标签一致的 Gitea 远程引用。
- [ ] **Step 1: 创建中文实现提交并推送**
```bash
git commit -m "docs(GOV-004): 强制提交后同步 Gitea"
git push origin main
```
预期:`origin/main` 指向新提交。
- [ ] **Step 2: 同步既有标签**
分别推送 `v0.0.0`、`v0.0.1` 和 `v0.0.2`,不使用 `--tags`。
- [ ] **Step 3: 封存版本并推送**
回填实现提交,创建中文封存提交并推送;创建带注释 `v0.0.3` 标签,再单独推送该标签。
- [ ] **Step 4: 最终远程核对**
比较 `git rev-parse main` 与 `git ls-remote origin refs/heads/main`;逐一比较四个本地标签与远程 peeled tag 提交,确认工作区干净、GitNexus 索引最新。
@@ -0,0 +1,18 @@
id: GOV-004
name: 提交后强制推送 Gitea
slug: mandatory-gitea-push
status: released
owner: project
created_at: 2026-08-12
prd: prd.md
requirements: requirements.md
design: design.md
implementation_plan: implementation-plan.md
gitnexus_before: gitnexus/before.md
gitnexus_after: gitnexus/after.md
gitnexus_comparison: gitnexus/comparison.md
code_review: review/code-review.md
standards_review: review/standards-review.md
implementation_commit: 2a16e9f
release_commit: d1e54dc
release: v0.0.3
@@ -0,0 +1,44 @@
# 提交后强制推送 Gitea PRD
- 功能编号:GOV-004
- PRD 版本:0.1
- 状态:approved
- 日期:2026-08-12
## 问题
项目此前只要求保存本地提交,是否推送需要逐次确认。这会导致本地版本与 Gitea 长期不一致,使远程备份、跨设备读取、历史审阅和版本回退缺少可靠依据。
## 目标
- 每次验证通过的本地提交立即推送当前分支。
- 本次创建的新标签在分支推送成功后单独推送。
- 推送失败时任务保持未完成,并提供安全、可审计的重试路径。
- 让提交、远程分支、标签和功能档案保持可核对的一致关系。
## 非目标
- 不自动推送其他本地分支或非本次创建的标签。
- 不使用强推,不自动合并、rebase 或覆盖未知远程提交。
- 不新增 GitHub、CI、Webhook 或 Gitea 服务端配置。
- 不修改全局 Git 配置,不影响其他项目。
## 用户流程
开发者完成验证与 Review 后创建中文提交,随即把当前分支推送到项目 `origin`;若同时发布版本,则精确推送新标签。系统核对远程 SHA 并在功能档案中记录结果。任何环节失败都保留本地状态,解决原因后重试,不能对外宣称完成。
## 验收标准
- 现行规范明确普通提交只推当前分支,新标签只推本次创建的标签。
- 现行规范明确推送成功属于完成定义,失败必须留痕并阻断完成。
- 现行规范禁止 `--force`、`--force-with-lease`、自动覆盖或自动改写远程历史。
- `origin/main` 与最终本地 `main` SHA 一致。
- 既有 `v0.0.0`、`v0.0.1`、`v0.0.2` 以及新 `v0.0.3` 标签均能从远程读取并对应本地标签提交。
- 凭据继续由 macOS Keychain 管理,仓库和提交历史无密码或令牌。
- 全局 Git 配置保持不变,治理门禁和 GitNexus 变更检测通过。
## 风险
- 远程网络或认证故障会延迟任务完成,但不会破坏本地提交。
- 分支保护或远程出现未知提交时可能拒绝推送;必须停下检查,不得绕过保护。
- 将所有标签批量推送可能发布未批准标签,因此只允许精确推送指定标签。
@@ -0,0 +1,27 @@
# 测试结果
## 本地验证
- `npm run test:governance`:5 个测试通过,0 个失败。
- `git diff --check`:通过。
- 现行推送规则冲突扫描:无匹配。
- `origin` push URL:精确匹配项目 Gitea。
- 项目配置:Keychain、路径隔离、账号和默认推送目标均符合设计。
- 全局边界:全局 `credential.helper` 和 `remote.pushDefault` 保持未设置。
- 敏感信息扫描:未发现凭据 URL、密码赋值或令牌赋值。
- GitNexus:426 个节点、452 条关系、5 个集群、0 条流程;变更风险为低。
- GitNexus 最终暂存区:21 个文件、44 个符号、0 条流程,风险为低。
- `npm run governance:finish -- GOV-004 mandatory-gitea-push`:退出码 0,完整档案和双 Review 门禁通过。
## 诊断记录
初次冲突扫描命中新规范中的否定说明“不再逐次请求推送授权”。该文本并未要求逐次授权,但会让机器扫描误报,因此改写为“用户已授予本项目持续推送权限”;同一扫描复测无匹配。
## 远程同步
- 设计提交 `757d8ab` 已推送,首次建立 `origin/main`。
- 计划提交 `2d2502c` 已推送,并验证远程 `main` 与本地 SHA 一致。
- 实现提交 `2a16e9f` 已推送,远程 `main` SHA 与本地一致。
- 既有 `v0.0.0`、`v0.0.1`、`v0.0.2` 已分别精确推送;远程 peeled tag 提交与本地标签提交一致。
- `v0.0.3` 已在封存提交 `d1e54dc` 创建并精确推送;远程 peeled tag 提交与本地标签提交一致。
- 最终远程核对:`origin/main` 与本地 `main` 一致,四个版本标签全部存在且分别指向预期提交。
@@ -0,0 +1,3 @@
# 视觉验证
本功能只修改 Git/Gitea 流程与治理文档,不改变页面、样式、图表或交互,因此视觉验证不适用。
@@ -0,0 +1,11 @@
# 发布说明
## v0.0.3
- 实现提交:`2a16e9f`。
- 发布封存提交:`d1e54dc`;带注释标签 `v0.0.3` 已精确推送并核对。
- 把当前分支推送设为每次提交后的固定完成步骤。
- 本次创建的新标签采用精确推送,禁止用 `--tags` 批量发布其他标签。
- 推送失败将阻断任务完成,并禁止强推或自动覆盖未知远程历史。
- 增加远程 SHA 核对与功能档案留痕要求。
- GOV-004 取代 GOV-003 的旧推送授权规则,历史档案保持不变。
@@ -0,0 +1,13 @@
# 工程需求
- 提交前必须完成测试、构建或适用性说明、双 Review、GitNexus 变更检测及敏感信息检查。
- 提交信息必须使用中文 Conventional Commit 并包含功能编号。
- 提交后读取当前分支名,执行 `git push origin <当前分支>`。
- 创建新标签后执行 `git push origin <标签名>`,禁止使用 `--tags` 代替精确推送。
- 推送完成后比较本地分支 SHA 与 `git ls-remote origin refs/heads/<当前分支>`。
- 标签核对必须解析带注释标签指向的提交,而不是只比较标签对象 SHA。
- 推送失败时保留本地提交,记录不含凭据的错误摘要并阻断任务完成。
- 禁止 `--force`、`--force-with-lease`、自动 rebase、自动 merge 和覆盖未知远程引用。
- 唯一远程必须是本项目 `.git/config` 中的指定 `origin`,不得修改全局 Git 配置。
- 密码和令牌只能由系统 Keychain 管理,不得进入项目文件、Git URL、命令参数和 Git 历史。
- GOV-003 保留原始历史文本;现行推送规则以 GOV-004 和治理入口为准。
@@ -0,0 +1,35 @@
# 配置与文档 Review
- reviewer_type:self
- reviewer:Codex
- 基线提交:`4b390d9`
- 设计提交:`757d8ab`
- 计划提交:`2d2502c`
- 实现提交:`2a16e9f`
- 审查范围:强制推送流程、远程核对、失败处理、版本同步和功能档案
- 日期:2026-08-12
## PRD 与设计符合性
现行规范已经覆盖当前分支立即推送、新标签精确推送、失败阻断完成、禁止强推、远程 SHA 核对、Keychain 凭据边界和功能档案留痕。GOV-003 保持原文,GOV-004 明确取代其旧推送授权规则。
## 发现与处置
| 严重程度 | 发现 | 处置 |
|---|---|---|
| Important | 原 `AGENTS.md` 和开发流程仍要求逐次获得推送授权,与用户新要求冲突 | 现行入口统一改为持续授权和提交后强制推送,并增加冲突文本扫描 |
| Important | 批量 `--tags` 可能发布无关标签 | 明确只允许 `git push origin <本次标签名>`,并把禁止 `--tags` 写入规范 |
| Important | 推送失败后自动强推、合并或 rebase 可能破坏未知远程历史 | 明确失败阻断完成、先检查差异以及禁止强推和自动改写 |
| Minor | 新规范中的否定句触发冲突扫描误报 | 改为肯定式持续授权声明,复测无冲突匹配 |
## 验证
- 5 个治理测试通过,`git diff --check` 通过。
- 现行规则冲突扫描和敏感信息扫描通过。
- Git 配置仅位于当前项目,全局相关配置保持未设置。
- GitNexus 最终暂存区检测为 21 个文件、44 个符号、0 条流程、低风险。
- 设计和计划两次提交均已按新规则推送并核对远程 `main`。
实现提交和标签引用将在创建后按规范精确推送,不存在阻断提交的 Review 问题。
最终结论:passed
@@ -0,0 +1,25 @@
# 开发规范符合性 Review
- reviewer_type:self
- reviewer:Codex
- 实现提交:`2a16e9f`
- 日期:2026-08-12
## 检查结果
- [x] 用户批准设计规格后才进入实施。
- [x] 开发前运行治理启动、GitNexus 查询并保存基线。
- [x] PRD、工程需求、设计、计划、测试和回退说明一致。
- [x] GOV-003 历史原文未被篡改,后续决策通过 GOV-004 追溯。
- [x] 现行入口没有相互冲突的推送授权规则。
- [x] 未修改生产代码,没有不必要的代码拆分或依赖变化。
- [x] 未配置 GitHub,唯一远程仍为项目专用 Gitea。
- [x] 未修改 Git 全局配置,密码和令牌未进入仓库。
- [x] 治理测试、文档检查、GitNexus 和敏感信息扫描通过。
- [x] 界面没有变化,视觉验证合理标记为不适用。
## 不符合项与处置
没有未解决的 Critical 或 Important 不符合项。最终分支和标签同步属于提交后的发布步骤,将通过远程引用比较闭环。
最终结论:passed
@@ -0,0 +1,12 @@
# 回退说明
本功能已经把 `main` 同步到共享 Gitea,因此不得使用 reset、强推或删除共享提交回退。
如果强制推送规则需要撤销:
1. 创建新的治理功能编号并说明撤销原因。
2. 使用中文修复提交恢复治理入口文字,不修改 GOV-004 历史档案。
3. 通过完整测试、Review 和 GitNexus 门禁后正常推送修复提交。
4. 已共享的 `v0.0.3` 标签不得移动或删除;使用新的补丁版本表达修正。
认证或网络故障不需要回退本地提交。保留提交,修复连接后重试精确推送;禁止将密码写入诊断记录。
@@ -0,0 +1,13 @@
# 测试计划
- 运行 `npm run test:governance`,要求 5 个治理测试通过、0 个失败。
- 运行 `git diff --check`,要求无空白错误。
- 扫描 `AGENTS.md`、`README.md` 和 `docs/governance/`,要求不存在“默认不推送”或“逐次授权后才能推送”的现行冲突文本。
- 检查 `git remote get-url --push origin` 精确等于指定 Gitea 仓库。
- 比较 `git rev-parse main` 与远程 `refs/heads/main` SHA。
- 分别解析本地和远程 `v0.0.0`、`v0.0.1`、`v0.0.2`、`v0.0.3` 指向的提交并比较。
- 检查全局 `credential.helper` 和 `remote.pushDefault` 与 GOV-004 开始前一致。
- 扫描仓库文件和暂存区,要求没有凭据 URL、密码赋值或令牌赋值。
- 运行 `npx gitnexus analyze` 和指定仓库的 `detect-changes`,记录节点、关系、流程和风险。
- 运行 `npm run governance:finish -- GOV-004 mandatory-gitea-push`,要求退出码为 0。
- 本功能不修改页面,视觉验证标记不适用并说明原因。
@@ -0,0 +1,80 @@
# MySQL 5.7 字符集与兼容性基线设计规格
- 功能编号:GOV-005
- 规格版本:0.1
- 状态:approved_for_review
- 日期:2026-08-13
## 背景与目标
系统架构和开发规范已经选择 MySQL,但尚未固定服务端版本、字符集和排序规则。不同开发环境如果分别使用 MySQL 5.7、8.x 或不同排序规则,会造成迁移语法、索引行为、字符串比较和排序结果不一致。
本功能建立项目级数据库兼容性基线:所有正式实现固定使用 MySQL 5.7.x,字符集固定为 `utf8mb4`,排序规则固定为 `utf8mb4_general_ci`。虽然市场概览第一阶段只定义持久化接口、不启用 MySQL,该约束仍从数据模型设计开始生效。
## 约束方案
### 采用方案:全链路显式声明
数据库实例/Schema、连接会话、迁移脚本、表、需要覆盖默认值的文本列,以及 Docker、测试和 CI 环境都显式声明或验证版本和字符集规则。
采用原因:只设置服务器默认值无法防止迁移脚本、ORM 连接或外部工具创建出不同排序规则的对象。全链路显式声明能够在代码审查和自动测试中直接验证。
### 不采用:仅依赖服务器默认值
部署配置简单,但开发机、测试环境或后续迁移工具可能使用不同默认值,无法保证可复现,不采用。
### 不采用:允许 MySQL 8.x 向下兼容
在 8.x 开发、声称兼容 5.7,容易无意引入 CTE、窗口函数、函数索引和 8.x 行为差异。项目明确要求不使用 8.x,因此不采用。
## 技术基线
- 数据库服务端:MySQL `5.7.x`,部署镜像和测试环境必须固定到明确的 5.7 补丁版本;禁止 `latest`、`8` 或 `8.x`。
- 默认字符集:`utf8mb4`。
- 默认排序规则:`utf8mb4_general_ci`。
- 数据库创建语句必须包含 `DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci`。
- 表创建或迁移必须显式保持 `DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci`。
- ORM/数据库驱动连接配置必须设置 `charset=utf8mb4`,连接建立后验证会话排序规则为 `utf8mb4_general_ci`,不能假设服务器默认值正确。
- 文本列原则上继承表级规则;只有确实需要不同比较语义时才允许列级覆盖,并必须另建 ADR 获得批准。
## MySQL 5.7 兼容边界
代码、查询、迁移和测试不得使用仅在 MySQL 8.x 可用或行为不同的能力,包括但不限于:
- 公用表表达式 `WITH` 和递归 CTE。
- 窗口函数,例如 `ROW_NUMBER()`、`RANK()` 和 `OVER (...)`。
- 函数索引和不可见索引。
- `CHECK` 约束在 8.x 的强制执行语义;5.7 中业务约束必须由应用校验、普通索引或可验证的数据写入逻辑保证。
- `utf8mb4_0900_*` 排序规则。
- 依赖 MySQL 8.x 默认认证插件、保留字、数据字典或 JSON 增强能力的实现。
JSON 字段只有在需求能够由 MySQL 5.7 原生 JSON 能力稳定完成时才能使用;查询和索引设计必须有 5.7 实际测试证据。
## 排序规则语义
`utf8mb4_general_ci` 为不区分大小写的通用排序规则。业务代码不得把数据库字符串比较误认为大小写敏感;证券代码、外部事件 ID、幂等键等需要严格身份语义的字段,应通过规范化输入、二进制字段/排序规则或明确的唯一键设计解决,并在具体功能设计中说明。
索引长度必须按 MySQL 5.7、`utf8mb4` 最多四字节字符进行预算。迁移设计不得假设 MySQL 8.x 的默认索引能力;超长文本标识应使用长度受控字段、前缀索引或稳定摘要,并提供碰撞与唯一性处理说明。
## 配置落点
- `docs/architecture/system-architecture.md`:记录数据库技术基线、第一阶段接口边界和未来启用条件。
- `docs/governance/code-development-standards.md`:把版本、字符集、排序规则、禁用能力、迁移和 Review 检查设为强制规范。
- 后续 `deploy/`:MySQL 镜像固定 5.7 补丁版本,初始化参数显式声明字符集和排序规则。
- 后续 `server/`:ORM 与连接配置、迁移、Repository 实现按本规格验证。
- 后续测试:连接真实 MySQL 5.7 检查 `SELECT VERSION()`、数据库/表排序规则和查询兼容性。
## 实施范围
本功能只更新架构、开发规范、版本记录和 GOV-005 追溯档案,不创建数据库、不启动容器、不引入 ORM,也不启用市场概览的 MySQL Repository。正式部署配置和代码实现由后续业务功能按照本基线完成。
## 验收标准
- 系统架构明确 MySQL 5.7.x、`utf8mb4` 和 `utf8mb4_general_ci`。
- 开发规范明确数据库、表、连接、迁移、测试和 Review 的全链路要求。
- 开发规范明确禁止依赖 MySQL 8.x 专属能力和 `utf8mb4_0900_*` 排序规则。
- 文档说明 `utf8mb4_general_ci` 不区分大小写及对身份字段、唯一键和索引长度的影响。
- 市场概览第一阶段仍只定义 MySQL Repository 接口,不实际启用数据库。
- GOV-005 具备 PRD、需求、设计、实施计划、测试、GitNexus 前后对比、双 Review、发布和回退档案。
- 治理测试、文档一致性检查、敏感信息检查和 GitNexus 变更检测通过。
- 中文提交和 `v0.0.4` 标签均精确推送到 Gitea。
@@ -0,0 +1,9 @@
# GitNexus 开发后结果
- 执行:`npx gitnexus analyze`。
- 工作区索引:528 个节点、553 条关系、5 个集群、0 条执行流程。
- 增量分析:6 个已修改文件、18 个新增文件、0 个删除文件,并新增 1 个导入关系到可写集合。
- 最终索引提交:`91d9b9c`。
- 状态:up-to-date。
实现提交后再次分析,索引已锚定到确定提交。
@@ -0,0 +1,26 @@
# GitNexus 开发前基线
- 功能编号:GOV-005
- 记录时间:2026年8月13日 GMT+8 09:45:51
- 分支:main
- 基线提交:6aa9fed62158
## 工作区
```text
(干净)
```
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/12/2026, 6:45:56 PM
Indexed commit: 6aa9fed
Current commit: 6aa9fed
Status: ✅ up-to-date
```
## 后续人工分析
在修改代码前,将 GitNexus query、context、impact 的结论写入 `gitnexus/impact-plan.md`。高风险结果必须先获得用户确认。
@@ -0,0 +1,10 @@
# GitNexus 前后对比
| 项目 | 开发前 | 开发后工作区 | 变化 |
|---|---:|---:|---:|
| 节点 | 432 | 528 | +96 |
| 关系 | 458 | 553 | +95 |
| 集群 | 5 | 5 | 0 |
| 执行流程 | 0 | 0 | 0 |
增长来自数据库规范、契约测试与完整 GOV-005 档案;生产执行流程保持不变,符合影响预估。最终索引锚定实现提交 `91d9b9c`。
@@ -0,0 +1,8 @@
# GitNexus 变更检测
- 命令:`npx gitnexus detect-changes --repo a-share-analysis --scope staged`。
- 最终暂存区:23 个文件、45 个符号。
- 受影响流程:0。
- 风险等级:低。
识别范围包含系统架构、开发规范、GOV-005 档案、测试与文档索引;版本纯文本和 Changelog 通过 Git diff 另行核对。
@@ -0,0 +1,7 @@
# GitNexus 开发前影响分析
- 查询主题:`MySQL 5.7 utf8mb4 general ci compatibility architecture standards`。
- 主要关联:`docs/architecture/system-architecture.md`、`docs/governance/code-development-standards.md`、README、文档索引和治理 Review。
- 本次不修改既有函数、类或方法;新增测试文件不参与生产调用链,因此没有生产符号需要上游影响分析。
- GitNexus 查询没有识别业务执行流程,预计影响限于架构规范、治理测试和版本档案。
- 风险控制:测试先行锁定文字契约;不连接数据库、不创建部署配置、不声称已验证真实 MySQL 实例。
@@ -0,0 +1,102 @@
# MySQL 5.7 字符集与兼容性基线实施计划
> **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:** 将 MySQL 5.7.x、`utf8mb4`、`utf8mb4_general_ci` 和禁止 MySQL 8.x 专属能力写入系统架构与开发规范,并以自动化测试锁定。
**Architecture:** 约束以系统架构定义全局技术基线,以代码开发规范定义实现与 Review 门禁。新增独立 Node.js 静态契约测试读取这两份文档,防止后续删除版本、字符集、排序规则或兼容性要求。
**Tech Stack:** Markdown、Node.js 内置测试运行器、GitNexus、Git/Gitea。
## Global Constraints
- 数据库服务端固定 MySQL 5.7.x,禁止 MySQL 8.x。
- 字符集固定 `utf8mb4`,排序规则固定 `utf8mb4_general_ci`。
- 数据库、表、连接、迁移和测试环境必须显式声明或验证基线。
- 禁止依赖 CTE、窗口函数、函数索引、不可见索引和 `utf8mb4_0900_*`。
- 当前只建立规范,不创建数据库、容器、ORM 或生产连接。
---
### Task 1: 建立失败的数据库基线契约测试
**Files:**
- Create: `tools/governance/mysql-baseline.test.mjs`
- Modify: `package.json`
**Interfaces:**
- Consumes: `docs/architecture/system-architecture.md` 与 `docs/governance/code-development-standards.md`。
- Produces: `npm run test:mysql-baseline`,验证数据库基线的机器可读证据。
- [ ] **Step 1: 编写测试**
测试必须断言两份文档包含 `MySQL 5.7`、`utf8mb4`、`utf8mb4_general_ci`,并断言开发规范包含 MySQL 8.x 禁用能力、大小写语义、索引长度、迁移与 Review 要求。
- [ ] **Step 2: 验证测试因规范缺失而失败**
运行:`npm run test:mysql-baseline`
预期:失败原因明确指向系统架构或开发规范缺少 MySQL 基线文本。
### Task 2: 更新架构与开发规范
**Files:**
- Modify: `docs/architecture/system-architecture.md`
- Modify: `docs/governance/code-development-standards.md`
**Interfaces:**
- Consumes: Task 1 的断言。
- Produces: 所有后续数据库、ORM、迁移和部署功能必须遵守的规范。
- [ ] **Step 1: 更新系统架构**
增加数据库技术基线、第一阶段接口边界以及正式启用 MySQL 时的验证条件。
- [ ] **Step 2: 更新开发规范**
增加 Schema/表/连接/迁移显式配置、5.7 禁用能力、排序语义、索引预算和 Review 检查。
- [ ] **Step 3: 验证测试转绿**
运行:`npm run test:mysql-baseline && npm run test:governance`
预期:全部通过。
### Task 3: 完成追溯、Review 与发布
**Files:**
- Create: `docs/features/GOV-005-mysql57-charset-baseline/manifest.yaml`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/prd.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/requirements.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/test-plan.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/gitnexus/impact-plan.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/gitnexus/after.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/gitnexus/detected-changes.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/gitnexus/comparison.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/qa/test-results.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/qa/visual-qa.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/review/code-review.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/review/standards-review.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/release-notes.md`
- Create: `docs/features/GOV-005-mysql57-charset-baseline/rollback.md`
- Modify: `docs/index.md`
- Modify: `CHANGELOG.md`
- Modify: `VERSION`
**Interfaces:**
- Consumes: 通过测试的架构和规范。
- Produces: 可审查、可发布、可回退的 GOV-005 完整档案和 `v0.0.4`。
- [ ] **Step 1: 完成 GitNexus 分析和全部档案**
重新索引,检测完整暂存区,记录前后节点、关系、流程和风险。
- [ ] **Step 2: 完成双 Review 与门禁**
运行:`npm run governance:finish -- GOV-005 mysql57-charset-baseline`
预期:两份 Review 均为 `passed`,门禁退出码为 0。
- [ ] **Step 3: 中文提交、推送与标签**
提交规范变化并推送 `main`;封存验证结果后创建带注释 `v0.0.4`,精确推送该标签并核对远程引用。
@@ -0,0 +1,17 @@
id: GOV-005
name: MySQL 5.7 字符集与兼容性基线
slug: mysql57-charset-baseline
status: released
owner: project
created_at: 2026-08-13
prd: prd.md
requirements: requirements.md
design: design.md
implementation_plan: implementation-plan.md
gitnexus_before: gitnexus/before.md
gitnexus_after: gitnexus/after.md
gitnexus_comparison: gitnexus/comparison.md
code_review: review/code-review.md
standards_review: review/standards-review.md
implementation_commit: 91d9b9c
release: v0.0.4
@@ -0,0 +1,32 @@
# MySQL 5.7 字符集与兼容性基线 PRD
- 功能编号:GOV-005
- PRD 版本:0.1
- 状态:approved
- 日期:2026-08-13
## 问题
项目只写明使用 MySQL,没有固定版本、字符集和排序规则。开发或部署人员可能使用 MySQL 8.x 或不同默认排序规则,造成 SQL、迁移、索引和字符串比较行为不一致。
## 目标
- 固定 MySQL 5.7.x、`utf8mb4` 和 `utf8mb4_general_ci`。
- 在架构和开发规范中覆盖数据库、表、连接、迁移、测试与 Review。
- 禁止无意引入 MySQL 8.x 专属能力。
- 用自动化契约测试防止规范回退。
## 非目标
- 不安装或启动 MySQL。
- 不创建 Schema、表、迁移或 ORM 配置。
- 不连接开发或生产数据库。
- 不启用市场概览持久化。
## 验收标准
- 系统架构明确 MySQL 5.7.x、字符集和排序规则。
- 开发规范明确全链路显式配置、禁止能力、大小写语义和索引预算。
- 新契约测试在旧规范上失败,在新规范上通过。
- 原治理测试无回归。
- 双 Review 和完成门禁通过。
@@ -0,0 +1,16 @@
# 测试结果
## 测试先行证据
新增 `mysql-baseline.test.mjs` 后首次运行:2 个测试失败。架构测试明确因缺少 `MySQL 5.7` 失败,开发规范测试明确因缺少数据库基线失败,证明测试能够捕获目标缺陷。
补充架构和开发规范后复测:
- `npm run test:mysql-baseline`:2 个通过,0 个失败。
- `npm run test:governance`:5 个通过,0 个失败。
- `git diff --check`:通过。
- GitNexus 最终暂存区:23 个文件、45 个符号、0 条流程,风险为低。
## 适用性
本功能只建立设计与规范,没有 MySQL 实例、Schema 或连接,因此不执行数据库连通性测试。真实 MySQL 5.7 验证属于首次启用持久化的后续功能门禁。
@@ -0,0 +1,3 @@
# 视觉验证
本功能只修改架构、开发规范、治理测试和追溯文档,不改变任何页面或交互,因此视觉验证不适用。
@@ -0,0 +1,9 @@
# 发布说明
## v0.0.4
- 实现提交:`91d9b9c`。
- 固定 MySQL 5.7.x、`utf8mb4` 和 `utf8mb4_general_ci`。
- 增加 MySQL 8.x 禁用能力、排序语义、索引和迁移规范。
- 新增数据库基线契约测试。
- 第一阶段仍不启用 MySQL,只为后续 Repository 实现建立兼容基线。
@@ -0,0 +1,10 @@
# 工程需求
- 系统架构增加独立数据库技术基线章节。
- 开发规范固定 MySQL 5.7.x、`utf8mb4`、`utf8mb4_general_ci`。
- 禁止 CTE、窗口函数、函数索引、不可见索引和 `utf8mb4_0900_*`。
- 解释默认排序不区分大小写对身份字段和唯一键的影响。
- 规定 MySQL 5.7 下索引长度预算、JSON 使用边界和 `CHECK` 约束替代方案。
- 迁移必须从上一版本基线正向验证,禁止直接修改共享表代替迁移。
- 新增 Node.js 静态契约测试并加入 npm 脚本。
- 第一阶段只定义 Repository 接口,不启用 MySQL。
@@ -0,0 +1,30 @@
# 代码与规范 Review
- reviewer_type:self
- reviewer:Codex
- 基线提交:`6aa9fed`
- 设计提交:`0328f9e`
- 实现提交:`91d9b9c`
- 日期:2026-08-13
## PRD 与设计符合性
架构固定数据库服务端、字符集、排序规则和第一阶段接口边界;开发规范覆盖 Schema、表、连接、迁移、查询、索引、测试和 Review;自动化测试锁定关键文本。
## 发现与处置
| 严重程度 | 发现 | 处置 |
|---|---|---|
| Important | 只写 MySQL 无法防止开发环境使用 8.x | 架构和规范固定 5.7.x,并要求真实环境验证 |
| Important | 只依赖服务器默认字符集可能产生混合排序规则 | 要求数据库、表、连接与迁移显式声明或验证 |
| Important | `utf8mb4_general_ci` 不区分大小写,身份字段可能发生碰撞 | 规范要求输入标准化或经批准的二进制比较与唯一键 |
| Minor | 纯文档约束容易被后续编辑删除 | 新增静态契约测试并完成红绿验证 |
## 验证
- 数据库基线测试 2/2 通过。
- 治理测试 5/5 通过。
- GitNexus 最终暂存区检测为 23 个文件、45 个符号、0 条流程、低风险。
- 未连接或修改任何数据库。
最终结论:passed
@@ -0,0 +1,21 @@
# 开发规范符合性 Review
- reviewer_type:self
- reviewer:Codex
- 实现提交:`91d9b9c`
- 日期:2026-08-13
## 检查结果
- [x] 开发前运行治理启动和 GitNexus 查询。
- [x] 设计经用户确认后实施。
- [x] 新行为先有失败测试,再修改规范使其通过。
- [x] 变更集中在架构、开发规范和一个可连续阅读的测试文件。
- [x] 没有连接生产或开发数据库。
- [x] 没有新增依赖、秘密、环境配置或业务数据。
- [x] MySQL 5.7、字符集、排序规则和 8.x 禁用能力均可机器验证。
- [x] 无界面变化,视觉验证标记不适用。
没有未解决的 Critical 或 Important 不符合项。
最终结论:passed
@@ -0,0 +1,5 @@
# 回退说明
本功能没有连接或修改数据库,回退不涉及数据操作。规则发布后如需修正,使用新的治理功能编号和中文修复提交更新架构、规范与测试,不移动或删除共享版本标签。
回退到 `v0.0.3` 只能用于读取升级前文档;后续已经按 MySQL 5.7 基线创建的迁移或部署不得通过改写历史撤销。
@@ -0,0 +1,10 @@
# 测试计划
- 先运行新增数据库基线测试,证明旧架构与规范因缺少 MySQL 5.7 约束而失败。
- 更新文档后复测,要求数据库基线测试 2 个通过、0 个失败。
- 运行治理测试,要求 5 个通过、0 个失败。
- 运行 `git diff --check`。
- 扫描仓库和暂存区,确认没有凭据或生产配置。
- 执行 GitNexus 增量分析与最终暂存区变更检测。
- 执行 `npm run governance:finish -- GOV-005 mysql57-charset-baseline`。
- 本功能无界面变化,视觉验证不适用。
@@ -0,0 +1,177 @@
# 开发、生产环境与双部署方式设计规格
- 功能编号:GOV-006
- 规格版本:0.1
- 状态:approved_for_review
- 日期:2026-08-13
## 背景与目标
项目已经明确前后端和基础设施技术栈,但目前只有 `.gitignore` 排除 `.env`,没有正式的开发/生产配置契约、模板结构、加载优先级和部署边界。缺少这些规则会导致本地开发误用生产配置、生产回退到模拟数据、不同部署方式使用不同变量,以及密钥进入仓库或构建产物。
本功能建立统一的环境配置体系,并同时支持 Docker Compose 与 Ubuntu 源码生产部署。两种生产方式必须使用相同变量名、配置校验、进程边界和发布版本,不允许形成两套行为不同的应用。
## 环境模型
项目只定义两个应用运行环境:
- `development`:本地开发、热更新、确定性模拟数据和开发 Redis。
- `production`:线上运行,禁止热更新、调试端口、模拟数据和开发默认值回退。
测试运行使用测试工具自己的隔离配置,不把 `test` 作为可部署环境。应用启动必须显式获得环境值;生产环境缺少配置或出现非法组合时立即退出,不能静默使用开发默认值。
业务代码不得到处分支判断环境。环境差异在配置加载、依赖注入和基础设施 Adapter 边界收敛,纯业务计算保持一致。
## 仓库模板结构
仓库提交完整但不含秘密的模板:
```text
deploy/env/
├── development/
│ ├── api.env.example
│ ├── scheduler.env.example
│ ├── worker.env.example
│ └── web.env.example
└── production/
├── api.env.example
├── scheduler.env.example
├── worker.env.example
└── web.env.example
```
每个模板必须为每项变量写明用途、示例格式、是否必填、敏感性和启用条件。密码、Token 和 API Key 使用空值,不使用看似真实的占位凭据。
真实开发配置使用同目录或项目约定位置的 `*.env.local`,由 Git 忽略。真实生产配置永远不放在仓库、发布目录、镜像层或前端构建产物中。
## 配置契约与校验
API、Scheduler、Worker 使用独立 Schema 校验各自配置,遵守最小知情范围:
- API:HTTP 监听、Redis、当前快照、按需历史读取和 AI 调用配置。
- Scheduler:时区、交易日调度、Redis 分布式锁;RabbitMQ 未启用时使用服务内调度 Adapter。
- Worker:数据源、Redis、分析配置;未来启用时增加 MySQL、RabbitMQ 和 AI 变量。
- Web:只允许公开的 `VITE_*` 构建变量,例如 API 相对路径和应用标题。
功能开关控制条件必填:MySQL、RabbitMQ、正式数据源或 AI 未启用时,其连接变量可以为空;一旦开关启用,相关变量缺失、格式错误或不安全时必须拒绝启动。
前端构建环境变量会进入浏览器代码,任何数据库、Redis、RabbitMQ、数据源或 AI 凭据都不得使用 `VITE_*` 前缀。
## 本地开发方式
本地开发默认使用 Docker Compose 只启动 Redis。Web、API、Scheduler 和 Worker 直接从源码运行,使用热更新和开发配置,便于调试。
第一阶段不启动 MySQL 和 RabbitMQ:
- MySQL 只定义 Repository 接口并使用内存实现。
- RabbitMQ 只定义消息契约和发布接口,Scheduler 通过服务内 Adapter 调用任务。
- Redis 是第一阶段唯一实际启用的外部基础设施,用于当前快照、缓存、刷新锁和调度锁。
开发 Compose 文件不得加载生产配置,不得连接生产地址。开发服务名、网络和数据目录必须使用项目专用前缀,避免影响其他项目。
## Docker Compose 生产部署
生产 Compose 支持运行 Web/Nginx、API、Scheduler、Worker,以及按部署选择连接内部或外部 Redis、MySQL 5.7 和 RabbitMQ。第一阶段未启用的组件不应为了形式完整而启动。
要求:
- 镜像对应明确 Git 提交或版本标签,禁止使用浮动 `latest` 作为可回退版本。
- 使用外部指定的生产 env 文件加载同一配置契约,不把秘密写入 Compose YAML。
- 禁止源码挂载、热更新、调试端口和开发命令。
- 服务提供健康检查、日志边界、启动顺序和优雅停止。
- 数据目录使用明确宿主机路径或经确认的持久化方案,升级不得删除数据。
## Ubuntu 源码生产部署
正式支持平台:
- Ubuntu 22.04 LTS x86_64。
- Ubuntu 24.04 LTS x86_64。
服务器管理员预先提供并维护:
- Node.js 22 LTS。
- pnpm 10。
- Nginx。
- MySQL 5.7、Redis、RabbitMQ 或对应外部服务。
项目只验证版本和连通性,不修改软件源,不安装或升级 Node.js、pnpm、Nginx、MySQL、Redis 或 RabbitMQ。版本不符合要求时部署立即终止并给出明确错误。
依赖安装必须使用 `pnpm install --frozen-lockfile`。Web 构建为静态文件后由 Nginx 托管;API、Scheduler 和 Worker 运行编译后的 JavaScript,禁止在生产运行 TypeScript、Vite 开发服务器、Nest watch 或源码热更新。
## systemd 与生产配置位置
源码部署使用单个非登录系统用户 `a-share` 运行 API、Scheduler 和 Worker。第一阶段先降低部署复杂度,但仍把配置拆为独立文件,为以后按进程拆系统用户保留边界。
生产配置固定存放在发布目录之外:
```text
/etc/a-share-analysis/
├── api.env
├── scheduler.env
├── worker.env
└── web.env
```
systemd 单元通过 `EnvironmentFile=/etc/a-share-analysis/<进程>.env` 在启动时注入变量。切换 `/opt/a-share-analysis/current` 指向的应用版本不会覆盖配置。
API、Scheduler 和 Worker 分别只引用自己的 env 文件。第一阶段文件所有者为 `root:a-share`,包含秘密的文件权限为 `0640`;Web 配置只含公开构建变量,可由部署构建步骤读取。未来接入高价值数据源和 AI 密钥时,评估拆分独立系统用户和更细的文件组权限。
## 发布目录与进程边界
源码部署建议使用不可变版本目录:
```text
/opt/a-share-analysis/
├── releases/<版本或提交>/
└── current -> releases/<当前版本>/
```
更新时先在新目录安装、构建和校验,再原子切换 `current` 并重启服务。回退切回上一完整版本,不在旧目录上覆盖文件。
Nginx 托管当前版本 Web 静态产物并反向代理 API。API、Scheduler、Worker 为独立 systemd 服务;任一后台进程异常不得由 API 请求临时替代执行全市场采集任务。
## MySQL 兼容约束
两种部署方式和两个环境都受 GOV-005 约束:MySQL 固定 5.7.x,字符集 `utf8mb4`,排序规则 `utf8mb4_general_ci`。项目启动或迁移必须验证该条件,不得在开发环境使用 8.x 再假设向下兼容。
第一阶段 MySQL 未启用,因此配置模板保留功能开关和条件变量,但默认不连接数据库。
## 安全与防误用
- `.env`、`.env.*` 和 `*.env.local` 默认忽略,只允许提交 `*.env.example`。
- 模板、日志、错误和诊断输出不得包含真实秘密。
- 生产启动必须检查 `APP_ENV=production`,并拒绝模拟数据、开发 URL、调试模式和空的已启用服务凭据。
- 开发配置不得包含或连接生产主机;项目脚本禁止读取生产数据库进行开发验证。
- Docker Compose 与源码部署使用相同变量名称和 Schema,不用环境专属别名隐藏差异。
- Web 配置仅含公开值;所有付费 AI 和数据源密钥只存在服务端配置。
## 运维文档范围
两种生产部署方式都必须提供:
- 前置条件和版本检查。
- 初次部署、配置填充、构建和启动步骤。
- 健康检查、日志读取和进程状态检查。
- 使用确定版本的升级流程。
- 配置不变的应用回退流程。
- 数据服务备份职责声明和故障边界。
源码部署文档不提供基础设施安装脚本。Docker Compose 文档不能暗示其配置可以直接用于本地开发。
## 实施范围
GOV-006 建立环境规范、变量模板、开发 Redis Compose、生产部署骨架、systemd/Nginx 示例及验证脚本的设计与追溯基础。由于 Web、Server、Scheduler 和 Worker 尚未实现,当前可先提供结构完整的模板和部署规范;具体应用启动命令在相应项目脚手架落地后通过后续功能验证,不得伪造已可运行状态。
## 验收标准
- 仓库包含开发与生产环境下 API、Scheduler、Worker、Web 的八份无秘密模板。
- 本地开发仅通过 Compose 启动项目专用 Redis,应用从源码运行。
- 生产同时有 Docker Compose 和 Ubuntu 22.04/24.04 x86_64 源码部署规范。
- 源码部署明确管理员提供 Node.js 22 LTS、pnpm 10、Nginx 和基础设施,项目只验证不安装。
- 源码部署明确单个 `a-share` 用户、独立 EnvironmentFile 和发布目录边界。
- Docker Compose 与源码部署共用配置变量和校验规则。
- 生产环境无法回退到模拟数据、开发默认值、热更新或调试配置。
- MySQL 条件配置符合 GOV-005,第一阶段默认不启用 MySQL 和 RabbitMQ。
- 治理测试、模板静态检查、敏感信息检查、GitNexus 变更检测和双 Review 通过。
- 中文提交和对应版本标签精确推送到 Gitea。
@@ -0,0 +1,26 @@
# GitNexus 开发前基线
- 功能编号:GOV-006
- 记录时间:2026年8月13日 GMT+8 10:34:15
- 分支:main
- 基线提交:0328f9e3d27d
## 工作区
```text
M AGENTS.md
```
## GitNexus 状态
```text
Repository: /Users/citrons/Documents/Codex/2026-08-12/wo-x/a-share-analysis
Indexed: 8/13/2026, 10:34:14 AM
Indexed commit: 0328f9e
Current commit: 0328f9e
Status: ✅ up-to-date
```
## 后续人工分析
在修改代码前,将 GitNexus query、context、impact 的结论写入 `gitnexus/impact-plan.md`。高风险结果必须先获得用户确认。
+30 -3
View File
@@ -8,7 +8,7 @@
- 前端:Vue 3、Vite、TypeScript、Dart Sass、Naive UI。
- 后端:NestJS、TypeScript。
- 数据库:MySQL;缓存:Redis;消息队列:RabbitMQ。
- 数据库:MySQL 5.7.x,字符集 `utf8mb4`,排序规则 `utf8mb4_general_ci`;缓存:Redis;消息队列:RabbitMQ。
- 图表:Lightweight Charts负责K线和分时,ECharts负责热力图、分布和资金趋势。
- AI:由服务端调用兼容 OpenAI 格式的付费 API,密钥不得下发浏览器。
@@ -98,7 +98,21 @@ count += 1;
- 消费者必须幂等,消息确认只能发生在持久化或可验证处理完成后。
- 免费数据源通过 Adapter 统一为内部模型,上层不得依赖供应商原始字段。
## 10. 测试要求
## 10. MySQL 5.7 兼容规范
- 开发、测试、Docker 和生产环境必须使用明确的 MySQL 5.7 补丁版本,禁止使用 `latest`、MySQL 8.x 或其他数据库代替兼容性验证。
- 创建数据库必须显式声明 `DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci`;建表与迁移脚本必须显式保持 `DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci`。
- ORM 和数据库驱动必须声明 `utf8mb4`,连接建立后验证会话、数据库和表的排序规则为 `utf8mb4_general_ci`,不得依赖服务器默认值。
- 文本列默认继承表级规则。列级改变字符集或排序规则必须由具体功能设计解释,并通过 ADR 审批。
- 禁止使用 MySQL 8.x 专属或在 5.7 行为不同的公用表表达式、递归 CTE、窗口函数、函数索引、不可见索引、`utf8mb4_0900_*` 排序规则和 JSON 增强能力。
- 不得依赖 `CHECK` 约束在 MySQL 8.x 的强制执行语义;MySQL 5.7 下的业务约束必须由边界校验、普通索引或可测试的写入逻辑保证。
- `utf8mb4_general_ci` 不区分大小写。证券代码、外部事件 ID、幂等键等身份字段必须规范化输入,或显式采用经设计批准的二进制比较与唯一键,不能误把默认比较当成大小写敏感。
- 索引长度按 MySQL 5.7 和 `utf8mb4` 最多四字节字符预算;超长标识使用受控长度、前缀索引或稳定摘要时,必须说明唯一性和碰撞处理。
- JSON 字段只能使用 MySQL 5.7 已支持并经过真实环境验证的能力,查询和索引不得建立在 8.x 特性上。
- 每份迁移脚本必须能够从上一版本基线在 MySQL 5.7 正向执行;禁止用直接修改共享数据库表代替迁移脚本。
- 代码 Review 必须检查服务端版本、字符集、排序规则、SQL/迁移兼容性、索引长度和字符串比较语义;任一不符合项按 Important 处理并阻断发布。
## 11. 测试要求
- 功能和缺陷修复遵循测试先行:先看到测试因缺少行为而失败,再实现最小代码。
- 纯规则和指标计算使用单元测试,期望值必须手工推导。
@@ -107,9 +121,22 @@ count += 1;
- 关键页面使用 Playwright流程测试和视觉截图对比。
- 合并前必须通过类型检查、测试、构建和适用的视觉验证。
## 11. 安全要求
## 12. 安全要求
- 禁止提交 `.env`、API Key、密码、真实账号和生产数据。
- AI 密钥、数据源凭证和支付凭证仅存在服务端密钥管理中。
- SQL必须参数化;外部输入必须在边界处校验。
- 日志和异常报告必须脱敏。
## 13. 代码 Review 要求
开发者完成自测不等于 Review 完成。审查者必须从功能 PRD、设计和 Git diff 出发,检查:
- 业务行为是否真正满足验收标准,是否存在遗漏分支。
- 类型、数据口径、缓存、消息、事务和异常恢复是否正确。
- 是否引入安全、性能、并发、幂等或数据一致性风险。
- 测试是否能捕获真实回归,而非只验证 Mock 或实现细节。
- 中文注释是否解释关键原因、口径和限制,是否存在失真注释。
- 文件拆分是否便于常规阅读,是否出现过度抽象或巨型多职责文件。
Critical 和 Important 问题必须修复并复审。Minor 问题可以延期,但必须写明理由和后续功能编号。
+34 -11
View File
@@ -7,7 +7,7 @@
## 2. 功能状态
```text
proposed → designing → approved → developing → verifying → released
proposed → prd_review → designing → approved → developing → verifying → reviewing → released
↘ blocked
released → superseded
```
@@ -18,18 +18,19 @@ released → superseded
1. 分配功能编号和英文短名称。
2. 建立 `docs/features/<编号>-<短名称>/`。
3. 填写需求、范围、非目标和验收标准。
4. 比较可选方案,记录设计与关键决策。
5. 更新 API、事件和数据结构契约。
6. 编写测试计划和实施计划。
7. 确保 Git 工作区基线可识别,执行:
3. 编写 `prd.md`,明确用户问题、目标、范围、非目标、用户流程、指标、风险和验收标准。
4. PRD 审核通过后,将产品需求转换为可测试的工程需求。
5. 比较可选方案,记录设计与关键决策。
6. 更新 API、事件和数据结构契约。
7. 编写测试计划和实施计划。
8. 确保 Git 工作区基线可识别,执行:
```bash
npm run governance:start -- FEAT-MO-001 market-overview
```
8. 运行 GitNexus 查询、上下文和影响分析,将结果写入 `gitnexus/impact-plan.md`。
9. 高风险或关键路径变化必须先向用户说明影响,再进入开发。
9. 运行 GitNexus 查询、上下文和影响分析,将结果写入 `gitnexus/impact-plan.md`。
10. 高风险或关键路径变化必须先向用户说明影响,再进入开发。
开发前必须至少回答:修改什么、为什么修改、影响谁、如何验证、失败后如何回退。
@@ -54,9 +55,14 @@ npm run governance:finish -- FEAT-MO-001 market-overview
```
6. 填写 `gitnexus/after.md`、`detected-changes.md` 和 `comparison.md`。
7. 更新发布说明、回退说明、变更记录和版本号。
8. 使用中文 Conventional Commit提交。
9. 提交后执行 `npx gitnexus status`;若状态过期,再运行 `npx gitnexus analyze`。
7. 执行代码 Review,将问题、严重程度、修复提交和复审结论写入 `review/code-review.md`。
8. 逐条执行开发规范符合性 Review,将结果写入 `review/standards-review.md`。
9. 任一 Review 为 `changes_required` 时,返回开发阶段;修复后重跑相关测试、GitNexus开发后分析和 Review。
10. 两项 Review 均为 `passed` 后,更新发布说明、回退说明、变更记录和版本号。
11. 使用中文 Conventional Commit 提交。
12. 提交后立即将当前分支推送到项目专用 Gitea `origin`;如果本次创建了标签,再精确推送该标签。
13. 比较本地与远程分支 SHA,并将提交、推送目标和结果写入功能档案。推送失败时保留本地提交,任务状态保持未完成。
14. 提交后执行 `npx gitnexus status`;若状态过期,再运行 `npx gitnexus analyze`。
## 6. 完成定义
@@ -68,8 +74,11 @@ npm run governance:finish -- FEAT-MO-001 market-overview
- 测试和构建有最新成功证据。
- 视觉变化有同视口对比证据。
- GitNexus 开发前后报告和差异说明齐全。
- 代码 Review 结论为 `passed`,Critical 和 Important 问题已关闭。
- 开发规范符合性 Review 结论为 `passed`。
- 发布说明和回退方法可执行。
- 中文提交已关联功能编号。
- 当前分支和本次新建标签已推送到 `origin`,功能档案保存远程核对结果。
## 7. 提交流程
@@ -89,6 +98,20 @@ docs(GOV-001): 建立工程治理与追溯规范
一次提交应表达一个完整意图,但不为了追求小提交把同一功能切成无法独立理解的碎片。
提交后推送当前分支:
```bash
git push origin "$(git branch --show-current)"
```
如果本次创建了标签,只推送该标签:
```bash
git push origin <本次标签名>
```
禁止使用 `--force`、`--force-with-lease` 或 `--tags` 代替精确推送。推送失败时不得宣称任务完成;应记录不含凭据的错误摘要,排查后重试同一精确命令。
## 8. 发布与回退
- 使用语义化版本和带注释 Git Tag。
@@ -9,6 +9,7 @@
```text
docs/features/<编号>-<短名称>/
├── manifest.yaml
├── prd.md
├── requirements.md
├── design.md
├── implementation-plan.md
@@ -26,6 +27,9 @@ docs/features/<编号>-<短名称>/
├── qa/
│ ├── test-results.md
│ └── visual-qa.md
├── review/
│ ├── code-review.md
│ └── standards-review.md
├── release-notes.md
└── rollback.md
```
@@ -33,6 +37,8 @@ docs/features/<编号>-<短名称>/
## 3. 历史保留
- 已发布文档不删除、不覆盖历史结论;修订通过 Git 历史和文档版本说明保留。
- PRD 是产品目标和验收口径的正式来源;`requirements.md` 是从 PRD 派生的工程约束,二者不能相互替代。
- Review 文件必须记录审查范围、基线提交、审查提交、发现、处置和最终结论,禁止只写“看过了”。
- 重大方案变化新增 ADR,旧 ADR 标记被替代。
- 规则、提示词、API 和事件契约使用明确版本。
- 截图文件名包含页面、状态、视口和版本,例如 `market-overview-trading-1440x1200-v0.1.0.png`。
+34
View File
@@ -0,0 +1,34 @@
# PRD 编写规范
## 1. 定位
PRD 是每个业务功能的产品需求事实来源,回答“为谁解决什么问题、为什么做、做到什么程度算完成”。技术设计回答“如何实现”,不能替代 PRD。
治理、重构和纯技术任务也需要简化 PRD,用于说明使用者、治理问题、目标和完成标准。
## 2. 必备章节
每份 `prd.md` 至少包含:
1. 文档信息:功能编号、版本、状态、作者、日期。
2. 背景与问题:当前状态、具体问题和证据。
3. 目标用户与场景:谁在什么时点使用。
4. 产品目标:用户能够完成什么,产品改善什么。
5. 非目标:本期明确不解决什么。
6. 用户流程:入口、关键步骤、结果和异常路径。
7. 功能需求:编号、优先级、行为与可观察结果。
8. 数据与口径:来源、时效、单位、缺失和过期处理。
9. 状态与异常:加载、空、部分数据、错误和降级。
10. 权限与合规:访问边界、隐私、声明和安全限制。
11. 成功指标:可以观测和验证的产品指标。
12. 验收标准:使用 Given/When/Then 或等价可测试描述。
13. 风险与依赖:外部数据、技术、成本和上线依赖。
14. 发布范围:本次、后续和回退触发条件。
## 3. 编写规则
- 需求使用 `FR-001` 等稳定编号,测试和 Review引用该编号。
- 禁止用“体验更好”“速度较快”等不可验证表达。
- UI 布局不是需求本身;应先写用户需要识别和完成的行为。
- PRD 发生实质变化时更新版本和变更记录,并重新确认设计与测试影响。
- 已发布 PRD 不删除旧结论,废弃需求标记 `superseded` 并说明替代项。
+37
View File
@@ -0,0 +1,37 @@
# Review 审查规范
## 1. 两类 Review
### 代码 Review
以 PRD、设计、实施计划、Git diff和测试证据为输入,审查正确性、安全性、性能、数据一致性、契约兼容性和测试充分性。
### 开发规范符合性 Review
逐条检查代码开发规范和流程规范,包括中文注释、命名、文件拆分尺度、日志、错误处理、GitNexus前后门禁、中文提交、文档和回退材料。
## 2. 审查角色
- 优先由非实现者进行独立 Review。
- 个人项目没有独立审查者时,可以执行结构化自审,但必须在报告中标明 `reviewer_type: self`,不得伪称独立审查。
- 使用代理审查时,必须提供功能说明、PRD、设计、基线 SHA 和当前 SHA;只有用户明确授权多代理时才调用独立审查代理。
## 3. 严重程度
- Critical:可能导致数据错误、安全事故、核心功能不可用或不可恢复,必须修复。
- Important:会造成明显错误、回归、规范失效或重要测试缺口,必须修复。
- Minor:不阻塞当前功能,但应记录后续处理或接受理由。
## 4. 结论
Review 只能使用:
- `passed`:没有未解决的 Critical 或 Important,证据齐全。
- `changes_required`:存在必须修改的问题。
- `blocked`:缺少 PRD、代码、测试、环境或其他必要证据。
修复 Review 问题后必须记录修复提交和复审结论。代码变化会使旧的 GitNexus开发后报告失效时,必须重新更新图谱和影响报告。
## 5. 发布门禁
`review/code-review.md` 和 `review/standards-review.md` 均存在、非空且最终结论为 `passed` 后,功能才允许进入发布状态。
+94 -6
View File
@@ -2,7 +2,17 @@
## 1. 当前策略
当前只使用本地 Git,不配置 GitHub、不创建 GitHub Actions,也不向任何第三方远程仓库推送。用户安装 Gitea 后,再显式配置 `origin`。
本项目使用本地 Git 和用户自建 Gitea,不使用 GitHub,也不创建 GitHub Actions。
| 配置项 | 值 |
|---|---|
| Gitea 基础地址 | `https://git.foximao.com/` |
| 项目账号 | `FoXiMao` |
| 唯一远程仓库 | `https://git.foximao.com/FoXiMao/a-share-analysis.git` |
| 远程名 | `origin` |
| 配置作用域 | 当前项目 `.git/config` |
密码不属于项目文档。它不得出现在仓库文件、Git 历史、远程 URL、脚本或命令参数中;首次认证时由 Git 凭据助手请求,并交由 macOS Keychain 保存。
## 2. 分支与提交
@@ -18,18 +28,94 @@
git config core.hooksPath .githooks
```
## 3. Gitea 接入
## 3. Gitea 项目级接入
Gitea 安装并创建空仓库后,由用户确认地址,再执行:
在本项目根目录执行以下项目级配置:
```bash
git remote add origin https://git.foximao.com/FoXiMao/a-share-analysis.git
git config --local credential.helper osxkeychain
git config --local credential.useHttpPath true
git config --local credential.username FoXiMao
git config --local remote.pushDefault origin
```
`credential.useHttpPath=true` 让同一 Gitea 域名下不同仓库按路径区分凭据;所有设置使用 `--local`,只写入本项目不可提交的 `.git/config`。禁止使用 `git config --global` 配置本项目账号、凭据助手或默认推送目标。
只读连通性检查:
```bash
GIT_TERMINAL_PROMPT=0 git ls-remote origin
```
首次需要写权限时,在交互式终端推送并输入凭据:
```bash
git remote add origin <用户提供的Gitea仓库地址>
git push -u origin main
```
建议在 Gitea 中保护 `main`:禁止强推、要求状态检查通过、要求变更说明关联功能编号。未得到用户提供的地址和授权前,任何代理不得自行添加远程或推送。
首次认证完成后,凭据由 macOS Keychain 管理。GOV-004 起,用户已授予本项目持续推送权限,验证通过的提交必须立即推送。建议在 Gitea 中保护 `main`:禁止强推、要求状态检查通过、要求变更说明关联功能编号。
## 4. 版本与标签
## 4. 提交后强制推送
普通提交只推送当前分支:
```bash
git push origin "$(git branch --show-current)"
```
本次创建版本标签时,在分支推送成功后精确推送该标签:
```bash
git push origin <本次标签名>
```
不得使用 `git push --tags` 替代精确标签推送,避免发布其他未确认标签。不得使用 `--force` 或 `--force-with-lease`。
分支推送后核对远程 SHA:
```bash
current_branch="$(git branch --show-current)"
git rev-parse "$current_branch"
git ls-remote origin "refs/heads/$current_branch"
```
两条结果必须指向相同提交。带注释标签核对时,应比较标签最终指向的提交,而不是标签对象本身。
如果认证、网络、分支保护或非快进检查导致推送失败:
1. 保留本地提交和标签,不删除、不 amend、不重写历史。
2. 记录失败命令、时间和不包含凭据的错误摘要,将任务标记为未完成。
3. 先获取并审查远程差异;禁止自动 merge、rebase、强推或覆盖未知提交。
4. 解决原因后重试同一个精确推送命令,并重新核对远程引用。
提交 SHA、远程分支、推送结果和本次标签结果必须写入对应功能档案。
## 5. 配置检查与移除
检查当前项目和全局配置的边界:
```bash
git remote -v
git config --local --get credential.helper
git config --local --get credential.useHttpPath
git config --global --get-all credential.helper
git config --global --get remote.pushDefault
```
如需解除本项目 Gitea 接入,执行:
```bash
git remote remove origin
git config --local --unset credential.helper
git config --local --unset credential.useHttpPath
git config --local --unset credential.username
git config --local --unset remote.pushDefault
```
上述操作只影响本项目。Keychain 中已保存的凭据需要在“钥匙串访问”中按 `git.foximao.com` 单独删除。
## 6. 版本与标签
发布使用带注释标签,例如:
@@ -38,3 +124,5 @@ git tag -a v0.1.0 -m "发布市场综合概览 v0.1.0"
```
标签必须指向通过验证的提交。应用回退优先选择既有标签和不可变构建产物,而不是重新拼装旧版本。
本规范的强制推送规则由 GOV-004 建立,并取代 GOV-003 中“只接入、不主动推送”的历史规则;GOV-003 原文保留用于审计当时决策。
+6
View File
@@ -4,6 +4,8 @@
- [代码开发规范](governance/code-development-standards.md)
- [开发流程规范](governance/development-workflow.md)
- [PRD 编写规范](governance/prd-standard.md)
- [Review 审查规范](governance/review-standard.md)
- [文档与追溯规范](governance/documentation-traceability.md)
- [Git 与 Gitea 规范](governance/version-control-and-gitea.md)
@@ -23,5 +25,9 @@
- [GOV-001:工程治理基线](features/GOV-001-engineering-governance/manifest.yaml)
- [FEAT-MO-001:市场综合概览](features/FEAT-MO-001-market-overview/manifest.yaml)
- [GOV-002:PRD 与 Review 门禁](features/GOV-002-prd-review-gates/manifest.yaml)
- [GOV-003:项目专用 Gitea 远程仓库](features/GOV-003-gitea-local-remote/manifest.yaml)
- [GOV-004:提交后强制推送 Gitea](features/GOV-004-mandatory-gitea-push/manifest.yaml)
- [GOV-005:MySQL 5.7 字符集与兼容性基线](features/GOV-005-mysql57-charset-baseline/manifest.yaml)
功能档案是需求、设计、代码、测试、版本和回退之间的唯一正式关联入口。
+27
View File
@@ -0,0 +1,27 @@
# 代码 Review
- 功能编号:
- reviewer_type:self / independent
- reviewer:
- 基线提交:
- 审查提交:
- 日期:
## 审查范围
## PRD 与设计符合性
## 发现
| 严重程度 | 位置 | 问题 | 影响 | 处理 |
|---|---|---|---|---|
## 测试缺口
## 修复与复审
## 最终结论
最终结论:blocked
完成审查后,将上行值改为 `passed`、`changes_required` 或 `blocked`。门禁只接受独占一行的 `最终结论:passed`。
+37
View File
@@ -0,0 +1,37 @@
# <功能名称> PRD
- 功能编号:
- PRD版本:
- 状态:draft
- 日期:
## 背景与问题
## 目标用户与使用场景
## 产品目标
## 非目标
## 用户流程
## 功能需求
| 编号 | 优先级 | 需求 | 可观察结果 |
|---|---|---|---|
## 数据与口径
## 状态与异常
## 权限、合规与安全
## 成功指标
## 验收标准
## 风险与依赖
## 发布范围与回退触发条件
## 变更记录
+28
View File
@@ -0,0 +1,28 @@
# 开发规范符合性 Review
- 功能编号:
- reviewer_type:self / independent
- reviewer:
- 审查提交:
- 日期:
## 检查结果
- [ ] 必要中文注释准确且没有逐行废话注释。
- [ ] 文件按稳定职责拆分,适合连续阅读,没有过度碎片化。
- [ ] 命名、类型、单位和时间语义明确。
- [ ] 错误处理、日志、脱敏和降级符合规范。
- [ ] API、事件、规则和提示词按需版本化。
- [ ] 测试先行证据、构建和视觉验证齐全。
- [ ] GitNexus开发前后报告和实际变更检测齐全。
- [ ] PRD、设计、发布说明和回退说明一致。
- [ ] 提交使用中文 Conventional Commit并关联功能编号。
- [ ] 未使用 GitHub,未擅自配置或推送远程仓库。
## 不符合项与处置
## 最终结论
最终结论:blocked
完成审查后,将上行值改为 `passed`、`changes_required` 或 `blocked`。门禁只接受独占一行的 `最终结论:passed`。
+1
View File
@@ -5,6 +5,7 @@
"type": "module",
"scripts": {
"test:governance": "node --test tools/governance/feature-record.test.mjs",
"test:mysql-baseline": "node --test tools/governance/mysql-baseline.test.mjs",
"governance:start": "node tools/governance/start.mjs",
"governance:finish": "node tools/governance/finish.mjs"
}
+19
View File
@@ -4,6 +4,7 @@ const FEATURE_ID_PATTERN = /^(?:FEAT-[A-Z]{2,8}|GOV)-\d{3}$/;
const REQUIRED_FEATURE_FILES = Object.freeze([
'manifest.yaml',
'prd.md',
'requirements.md',
'design.md',
'implementation-plan.md',
@@ -15,10 +16,17 @@ const REQUIRED_FEATURE_FILES = Object.freeze([
'gitnexus/comparison.md',
'qa/test-results.md',
'qa/visual-qa.md',
'review/code-review.md',
'review/standards-review.md',
'release-notes.md',
'rollback.md',
]);
const REVIEW_FILES = Object.freeze([
'review/code-review.md',
'review/standards-review.md',
]);
/**
* 功能编号是需求、设计、代码提交、测试结果和发布记录之间的主关联键。
* 严格限制格式可以避免路径穿越、临时名称以及后续无法检索的模糊编号。
@@ -49,3 +57,14 @@ export function getFeatureDirectory(repositoryRoot, featureId, slug) {
export function getRequiredFeatureFiles() {
return [...REQUIRED_FEATURE_FILES];
}
/**
* Review 报告不能只靠“文件存在”通过门禁。这里要求报告使用固定的最终结论行,
* 避免 pending、blocked 或 changes_required 被一段其他说明文字意外判定为通过。
*/
export function getUnpassedReviewFiles(reviewReports) {
return REVIEW_FILES.filter((file) => {
const content = reviewReports.get(file) ?? '';
return !/^最终结论:passed$/m.test(content);
});
}
+21
View File
@@ -2,6 +2,7 @@ import assert from 'node:assert/strict';
import test from 'node:test';
import {
getUnpassedReviewFiles,
getFeatureDirectory,
getRequiredFeatureFiles,
validateFeatureId,
@@ -28,6 +29,7 @@ test('将功能编号和短名称解析到固定的功能档案目录', () => {
test('返回开发完成前必须存在的完整追溯文件清单', () => {
assert.deepEqual(getRequiredFeatureFiles(), [
'manifest.yaml',
'prd.md',
'requirements.md',
'design.md',
'implementation-plan.md',
@@ -39,7 +41,26 @@ test('返回开发完成前必须存在的完整追溯文件清单', () => {
'gitnexus/comparison.md',
'qa/test-results.md',
'qa/visual-qa.md',
'review/code-review.md',
'review/standards-review.md',
'release-notes.md',
'rollback.md',
]);
});
test('只有两份 Review 都明确通过时才允许发布', () => {
const reports = new Map([
['review/code-review.md', '# 代码 Review\n\n最终结论:passed\n'],
['review/standards-review.md', '# 规范 Review\n\n状态:pending\n'],
]);
assert.deepEqual(getUnpassedReviewFiles(reports), [
'review/standards-review.md',
]);
reports.set(
'review/standards-review.md',
'# 规范 Review\n\n最终结论:passed\n',
);
assert.deepEqual(getUnpassedReviewFiles(reports), []);
});
+15
View File
@@ -5,6 +5,7 @@ import path from 'node:path';
import {
getFeatureDirectory,
getRequiredFeatureFiles,
getUnpassedReviewFiles,
validateFeatureId,
} from './feature-record.mjs';
@@ -60,6 +61,20 @@ if (missingFiles.length > 0) {
throw new Error(`完成门禁未通过,缺少或为空:\n- ${missingFiles.join('\n- ')}`);
}
const reviewReports = new Map(
['review/code-review.md', 'review/standards-review.md'].map((relativeFile) => [
relativeFile,
readFileSync(path.join(featureDirectory, relativeFile), 'utf8'),
]),
);
const unpassedReviews = getUnpassedReviewFiles(reviewReports);
if (unpassedReviews.length > 0) {
throw new Error(
`完成门禁未通过,Review 最终结论不是 passed:\n- ${unpassedReviews.join('\n- ')}`,
);
}
process.stdout.write(
`基础门禁已通过。提交前仍须人工确认 GitNexus 影响报告、业务测试、视觉 QA 和回退说明。\n`,
);
+34
View File
@@ -0,0 +1,34 @@
import assert from 'node:assert/strict';
import { readFile } from 'node:fs/promises';
import test from 'node:test';
const architecturePath = new URL('../../docs/architecture/system-architecture.md', import.meta.url);
const standardsPath = new URL('../../docs/governance/code-development-standards.md', import.meta.url);
test('系统架构固定 MySQL 5.7 字符集与排序规则', async () => {
const architecture = await readFile(architecturePath, 'utf8');
assert.match(architecture, /MySQL 5\.7/);
assert.match(architecture, /utf8mb4/);
assert.match(architecture, /utf8mb4_general_ci/);
});
test('开发规范覆盖 MySQL 5.7 全链路兼容性要求', async () => {
const standards = await readFile(standardsPath, 'utf8');
for (const requiredText of [
'MySQL 5.7',
'utf8mb4',
'utf8mb4_general_ci',
'公用表表达式',
'窗口函数',
'函数索引',
'utf8mb4_0900_',
'不区分大小写',
'索引长度',
'迁移脚本',
'代码 Review',
]) {
assert.ok(standards.includes(requiredText), `开发规范缺少数据库基线:${requiredText}`);
}
});