init: 项目初始提交 - NeoZQYY Monorepo 完整代码

This commit is contained in:
Neo
2026-02-15 14:58:14 +08:00
commit ded6dfb9d8
769 changed files with 182616 additions and 0 deletions

View File

@@ -0,0 +1,41 @@
---
name: bd-manual-db-docs
description: 当 PostgreSQL schema/表结构发生变化时,用于将变更以审计友好的方式落盘到 docs/database/(含变更原因、影响、回滚与验证 SQL
---
# 目的
保证数据库结构变化可追溯、可审计、可回滚,并与 ETL/后端/小程序字段映射保持一致。
# 触发条件
- 迁移脚本/DDL 修改(新增/删除/改表、字段、类型、默认值、非空、约束、索引、外键)
- ORM/Schema 定义变更导致实际 DB 结构变化
- 手工执行 DDL需用 manualTrigger hook 或本 Skill 补齐文档)
# 输出要求(必须全部满足)
所有输出必须落盘到:`docs/database/`
至少包含:
1) Schema Change Log变更日志条目
2) Table Structure Doc涉及表的结构文档更新
3) Rollback & Verification回滚要点 + 至少 3 条验证 SQL
4) 溯源:日期 + Prompt-ID/Prompt 摘录 + Direct cause必要性 + 方案简介)
# 工作流
## 1) 识别结构性变化
- 列出新增/修改/删除的对象schema/table/column/index/constraint/fk
- 明确变更前后差异before/after
## 2) 更新变更日志Schema Change Log
- 在对应 schema 目录下追加一条变更记录(模板见 assets/schema-changelog-template.md
## 3) 更新表结构文档Table Structure Doc
- 每张受影响的表都要更新(模板见 assets/table-structure-template.md
- 同步字段含义/口径说明,尤其是金额类字段:精度、币种、舍入
## 4) 回滚与验证
- 写清楚 DDL 回滚路径(必要时提供反向迁移)
- 写至少 3 条验证 SQL含约束/索引/关键字段检查)
# 模板
- `assets/schema-changelog-template.md`
- `assets/table-structure-template.md`

View File

@@ -0,0 +1,27 @@
# Schema 变更日志Schema Change Log
- 日期Asia/ShanghaiYYYY-MM-DD
- Prompt-ID
- 原始原因Prompt 摘录/原文):
- 直接原因(必要性 + 方案简介):
- 影响的 Schema
- 变更摘要(一句话):
## 变更明细
- 新增:
- 修改:
- 删除:
## 影响范围
- ETL
- 后端 API
- 小程序:
## 回滚要点
- DDL 回滚:
- 数据回填/迁移注意事项:
## 验证 SQL至少 3 条)
1)
2)
3)

View File

@@ -0,0 +1,22 @@
# <schema>.<table>
## 表用途Purpose
- 该表代表什么业务对象/过程
## 字段Columns
| 字段名 | 类型 | 可空 | 默认值 | 约束/键 | 说明(含口径) |
|---|---|---:|---|---|---|
> 金额类字段必须注明:币种、精度、舍入/截断规则、是否允许负数。
## 索引Indexes
- 索引名 / 字段 / 是否唯一 / 备注
## 约束与外键Constraints & FKs
- 约束名 / 定义 / 备注
## 数据不变量Invariants
- 例如:状态机枚举范围、唯一性、跨字段一致性约束(如有)
## 变更历史Change History
- YYYY-MM-DD | Prompt-ID | 直接原因 | 变更摘要

View File

@@ -0,0 +1,37 @@
---
name: change-annotation-audit
description: 对每次修改强制生成审计记录docs/audit/changes/...),并在每个被改文件写 AI_CHANGELOG、在逻辑变更处写 CHANGE 标记注释包含日期、Prompt 与直接原因)。
---
# 目的
把“为什么改、怎么改、怎么验”固化到可审计产物中,满足资金相关项目的严谨性要求。
# 触发条件
- 任何对代码或文档的实质修改(非纯格式化)
- 特别是逻辑改动、资金口径改动、接口契约改动、DB 结构改动
# 必须产物(缺一不可)
1) `docs/audit/changes/<YYYY-MM-DD>__<slug>.md`
2) 每个被修改文件内的 `AI_CHANGELOG` 条目
3) 每个逻辑变更附近的 `CHANGE` 标记注释
# 工作流
## 1) Prompt 溯源
- 确认本次修改有 Prompt-ID来自 prompt_log.md
- 若没有,先补写 Prompt-ID再继续
## 2) 写审计记录Per-change
使用模板:`assets/audit-record-template.md`
- 必须写原始原因Prompt、直接原因、改动方案简介、文件清单、风险/回滚/验证
## 3) 写文件内 AI_CHANGELOGPer-file
- 对每个修改的文件追加一条 AI_CHANGELOG
- 选择适合语言/文件类型的注释风格(模板见 assets/file-changelog-templates.md
## 4) 写 CHANGE 标记Block-level
- 对每处逻辑变更,必须在附近写 CHANGE 标记
- 必须包含intent、assumptions、边界条件金额/舍入/精度)、验证提示
# 模板
- `assets/audit-record-template.md`
- `assets/file-changelog-templates.md`

View File

@@ -0,0 +1,19 @@
# 变更审计记录Change Audit Record
- 日期/时间Asia/Shanghai
- Prompt-ID
- 原始原因Prompt 原文或 ≤5 行摘录):
- 直接原因(必要性 + 修改方案简介):
## 变更范围Changed
- 模块/接口/表/关键文件:
## 风险与回滚Risk & Rollback
- 风险点:
- 回滚要点:
## 验证Verification
- 至少 1 条可执行验证方式(测试/SQL/联调):
## 文件清单Files changed
- ...

View File

@@ -0,0 +1,48 @@
# 文件内 AI_CHANGELOG 与 CHANGE 标记模板
## 通用 AI_CHANGELOG建议放在文件头部或“变更记录”小节
- 2026-02-13 | Prompt: P20260213-101530摘录...| Direct cause... | Summary... | Verify...
---
## Markdown / 文档(放在文档末尾或“变更记录”小节)
### AI_CHANGELOG
- YYYY-MM-DD | Prompt: P...(摘录:...| Direct cause... | Summary... | Verify...
---
## JS/TS块注释
/*
AI_CHANGELOG
- YYYY-MM-DD | Prompt: P...(摘录:...| Direct cause... | Summary... | Verify...
*/
// [CHANGE P...] intent: ...
// assumptions: ...
// edge cases / money semantics: ...
// verify: ...
---
## Pythondocstring/块注释)
"""
AI_CHANGELOG
- YYYY-MM-DD | Prompt: P...(摘录:...| Direct cause... | Summary... | Verify...
"""
# [CHANGE P...] intent: ...
# assumptions: ...
# edge cases / money semantics: ...
# verify: ...
---
## SQL块注释 + 行注释)
/*
AI_CHANGELOG
- YYYY-MM-DD | Prompt: P...(摘录:...| Direct cause... | Summary... | Verify...
*/
-- [CHANGE P...] intent: ...
-- assumptions: ...
-- money semantics: precision/rounding/currency ...
-- verify: ...

View File

@@ -0,0 +1,38 @@
---
name: steering-readme-maintainer
description: 当发生业务/ETL/API/鉴权/小程序交互等逻辑改动时,用于执行变更影响审查并同步更新 product/tech/structure/README 与审计记录。
---
# 目的
将“逻辑改动→文档同步→审计留痕”流程标准化,减少漏更与口径漂移风险(资金相关场景优先保证可追溯与可复算)。
# 触发条件(何时调用本 Skill
- 修改了业务规则/计算口径/资金处理(精度、舍入、阈值等)
- 修改了 ETL/SQL 清洗聚合映射逻辑
- 修改了 API 行为(返回结构、错误码、鉴权/权限)
- 修改了小程序关键交互流程(校验、状态机、关键字段)
# 工作流(必须按顺序执行)
## 1) 分类:是否属于“逻辑改动”
- 若不是逻辑改动:写明“无逻辑改动”,并说明为何(例如仅格式化/拼写修正/注释调整)。
- 若是逻辑改动:进入下一步。
## 2) Steering 与 README 同步(逐项评估)
- `.kiro/steering/product.md`:业务定义/口径/资金规则是否变化?
- `.kiro/steering/tech.md`:技术栈/运行方式/依赖/部署假设是否变化?
- `.kiro/steering/structure-lite.md摘要/ .kiro/steering/structure.md仅在目录树/边界变化时)`:目录/模块边界/职责是否变化?
- `README.md`:运行方式、配置、环境变量、接口契约、联调步骤是否变化?
> 规则:如果“对读者理解系统行为”有帮助,就应更新;不要为了追求“少改文档”而拒绝同步。
## 3) 输出审计友好摘要(对话回复/审计记录都需要)
- Changed改了哪些模块/接口/表/关键文件
- Why原始原因Prompt-ID + 摘录)与直接原因(必要性 + 方案简介)
- Risk风险点与回归范围
- Verify建议的验证步骤测试/SQL/联调)
## 4) 联动硬规则检查
- 如果涉及 DB schema/表结构变化:必须同步更新 `docs/database/`(见 skill `bd-manual-db-docs`)。
# 资产(可复制模板/清单)
见:`assets/steering-update-checklist.md`

View File

@@ -0,0 +1,23 @@
# Steering & README 同步清单(逻辑改动必查)
## product.md产品/口径)
- 业务定义/指标口径/字段含义是否改变?
- 涉及金额的精度/舍入/阈值规则是否改变?
- 角色/权限模型是否改变?
## tech.md技术/运行)
- 新增/变更依赖(框架、库、驱动)?
- 配置项/环境变量/端口/服务启动方式是否改变?
- 数据访问边界ETL 库 vs 业务库)是否改变?
- 性能/一致性/幂等/重试策略是否改变?
## structure.md结构/职责)
- 新增目录/模块?
- 模块职责或边界是否重新划分?
- 新增集成点(队列、定时任务、外部系统)?
## README.md使用/联调)
- 本地启动步骤是否改变?
- 新增/变更配置项(.env 等)?
- API 契约是否变化(路径、参数、返回、错误码)?
- 小程序联调步骤是否变化?