cgraphx 1.4.3 → 2.0.0

package/dist/.claude-template/skills/init-project-guides/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: init-project-guides
+disable-model-invocation: true
+description: 为项目初始化 docs/guides/ 规范文件模板。根据技术栈(Java/Go/TS/...)动态生成编码规范、接口规范、数据与模型规范、测试规范、Git 提交规范等速查文档。Use when 用户需要为项目建立开发规范文档体系,或新项目起步时需要规范文件骨架。
+---
+
+# init-project-guides
+
+## 定位
+
+为项目生成/补齐 `docs/guides/` 规范速查(5 个文件,一项开发活动 ↔ 一个文件):
+
+| 文件 | 内容 | 强制读点 |
+|---|---|---|
+| `coding-standards.md` | 风格/命名/目录/错误处理 | 所有动码任务 |
+| `interface-standards.md` | API 路径/参数/返回值/兼容 | 接口任务 · write-api |
+| `data-standards.md` | 模型层 + DDL 层 + ORM 映射 + **schema 变更约定** | schema 任务 |
+| `testing-standards.md` | 框架/单测集成边界/mock/fixture/覆盖 | 测试任务 |
+| `git-standards.md` | commit 消息规范 + 提交前检查点 | precommit-check 门禁 |
+
+两种模式:新项目起步立起步默认(文件内显式注明"待演进,有代码后重跑校准");已有项目从代码与 git 历史挖既有约定固化成文。**你只提发现和建议,决策归用户。**
+
+## 判别:什么算"项目规范"
+
+**规范 = 项目对默认做法的有意偏离或选定;无偏离即无规范。** 一条候选内容,两条测试都过才写:
+
+| 测试 | 问 | 不过 → 不写 |
+|---|---|---|
+| 必要性 | 删掉它,懂技术栈 + 有常识、没见过本项目的工程师会做出**不一样**的东西吗? | 不会 = 显而易见 |
+| 执行点 | 有没有 lint / 格式化 / 类型系统**已经在强制**它? | 有 = 工具的事,guide 不抢 |
+
+**三类必弃**(凑进去只会淹没真规范):技术栈事实(用了 ts/java)、通用工程常识(单一职责/复用/合理拆分/"命名要有意义")、工具已强制项(缩进/引号/camelCase——ESLint/Prettier 管)。
+
+**规范要写的是这类**:SQL 禁止 `ORDER BY` · commit 用 A 格式 · 接口路径加 `fix` 前缀 · 测试库 `xxx_test`/生产库 `xxx` · 金额一律 `decimal(12,2)` —— 推不出、没工具兜底,guide 是它唯一执行点。
+
+**宁缺毋滥**:一个文件 3 条真规范,好过 30 条里藏 3 条。guide 是强制读 + 会被 write-plan 结晶成契约、被审查执行 —— 噪音会被放大成"被强制的噪音"。整节挖不到项目特异内容 → 该节写一行"无特殊约定,遵循默认/lint",或整节省写,不得用通用最佳实践填充。
+
+## 流程
+
+1. **探测技术栈** —— 自动探测;探测不到问用户(新项目/空仓库是常态)。
+2. **探索** —— README、依赖清单(package.json/pom.xml/go.mod)、目录结构、git 历史(近 50-100 条 message 风格、已有 commitlint/hook)、测试基建、已有 docs/(先读避免重复)。新项目跳过探索,以用户输入 + 技术栈惯例为准。
+3. **逐文件生成 + 确认** —— 按 coding → interface → data → testing → git 顺序,**一次只处理一个文件**,每个文件三步:
+   - **报告发现**:挖到的项目现实(目录/命名/框架用法/测试基建/message 风格)**逐条过判别两测试,显而易见项(三类必弃)当场丢弃不进报告**;报告的都是真规范(偏离/选型/推不出的事实),**发现的约定与起步选型明确分开标注**
+   - **给草案 + 建议**:挖不到的、有分歧的,给有限选项 + 推荐理由(如"message 格式挖出两种风格,推荐 A——近 50 条占 80%"),不给开放式提问
+   - **用户拍板**:可改可补可否,**确认后才写入该文件**,再进下一个
+   
+   单文件补齐场景(如门禁中断要求补 testing-standards.md)走同一循环,只处理目标文件。
+4. **写入** —— 模板在 `templates/`:
+   - 栈模板 `templates/{java,go,typescript}.md`:coding / interface / data 模型层 / data DDL 层 / testing 各节
+   - `data-standards.md` 合并生成:统一 H1 `# 数据与模型规范`,模型层 / DDL 层两节标题降一级合并,缺数据库映射补 `## ORM 映射约定`,末尾**逐字追加** `templates/schema-convention.md` 的约定文本
+   - `git-standards.md` 按 `templates/git-standards.md` 生成(消息规范从历史挖 + 检查点种子按栈给默认、用户增删)
+
+## 生成原则
+
+- **有现实挖现实**:已有项目从代码/git 历史挖**偏离项 + 选型 + 推不出的事实**,固化成文,不发明新规矩。
+- **无现实立选型,不立常识**:新项目没有现实可挖 → 只记用户当场拍板的选型(commit 格式 / 包管理器 / 命名前缀 / 库名映射等),其余留白 + 文件内注明"待演进,有代码后重跑校准";不填通用最佳实践充数。
+- 建表注释必须指明关联表与字段(如 COMMENT '处理人工号,关联 users.staff_code')—— 这是推不出、无工具兜底的典型规范。
+- 不确定内容标【待确认】或留空,不猜。
+
+## 生成形态纪律(写出来的形态)
+
+判别管「选什么」,本节管「怎么写」。生成文件的主要消费者是按规范执行的 agent——模仿力极强,示范胜于讲解。
+
+- **规范形态 = 正例 + 来源标注**:能给示例的规范,给**一条完整正例**,用 `├─` 标注每个参数的来源(取自哪个系统 / 挖自哪段历史 / 拿不到时怎么办)。正例管「长什么样」,标注管「哪来的」,其余不展开。
+- **示例之外的散文只许三处**:参数来源、取值行为(拿不到 → 问用户)、覆盖默认值的禁令。背景、动机、「为什么这样好」一律砍掉。
+- **禁令只用来覆盖默认值**:禁令合法,仅当 agent / 技术栈常识的默认做法恰好相反——如「不加 Co-Authored-By 署名」(agent 默认加)、「SQL 禁 ORDER BY」(默认会写)、「禁无意义 id 关联」(默认建模习惯)。这类必须显式一句;默认不如此的,正例本身即规范,不需禁令。
+- **生成文件里不得出现反例画廊**:不列 `❌ 错误格式 1/2/3`——列出错误格式 = 当菜单展示一遍,负面示范反向污染;没教过的格式 agent 不会自造。「只认此格式」一句足够,不枚举废格式。
+
+## 红线(绝对不能做)
+
+1. ❌ **不一次性给全部文件** —— 逐文件确认,每个文件用户拍板后才写入。
+2. ❌ **不替用户决策** —— 不替用户定命名风格、选提交格式、划单测/集成边界;挖不到的问,有分歧的列选项,不许填个默认就往下走。
+3. ❌ **不覆盖已有文件** —— 同名文件先问用户覆盖或跳过。
+4. ❌ **不自动删用户文件** —— 检测到旧结构(`model-standards.md` / `ddl.md` / `project-background.md`)只提示:前两者并入 `data-standards.md` 后删,`project-background.md` 直接删(定位由 CLAUDE.md + 知识库承担)。
+5. ❌ **约定文本不转述** —— schema 变更约定逐字拷自 `templates/schema-convention.md`,不改写不省略。
+6. ❌ **不写显而易见项凑篇幅** —— 技术栈事实 / 通用工程常识 / lint·工具已强制项一律不写;整节无项目特异内容宁可留白(一行"无特殊约定"或不写),不得用通用最佳实践填充。
+7. ❌ **生成文件写反例画廊或示例外散文** —— 形态按「生成形态纪律」:正例 + 来源标注 + 覆盖默认的禁令,其余不写。
+
+## 知识库联动
+
+生成后建议用户运行 `/knowledge-write` 将规范沉淀到 `docs/knowledge/`。

package/dist/.claude-template/skills/init-project-guides/templates/git-standards.md

@@ -0,0 +1,37 @@
+# git-standards.md 生成模板
+
+git-standards.md 是**提交门禁文件**(precommit-check hook 指向它),含两部分。门禁触发时 agent 自己跑 `git diff --cached` 对照逐项判断,命中报告用户,不替用户改代码。
+
+## 第一部分 · 提交消息规范
+
+从最近 50-100 条历史 message 挖风格,按 SKILL「生成形态纪律」生成——**一条带标注的正例 + 行为规则,不写反例画廊、不写散文解释**。形态照此(标注写实际来源):
+
+```
+## 提交格式(就这一种,照抄)
+CRM-req74442 单元测试 --2 @req74442
+├─ CRM-req74442   需求号,来自 <实际票据系统,如 Jira 需求单>;同一需求贯穿同一编号(含 @ 处)
+├─ 单元测试 --2    本步做了什么(中文);多步任务末尾 --序号
+└─ @req74442      编号收尾,便于 git log 按号追溯
+bug 同构:bug58017 <描述> @bug58017
+
+## 行为规则
+- 编号拿不到 → 停下来问用户,不提交无编号 commit,不许猜
+- <署名行决策:加 / 不加 co-author 署名——这是「没有」型规范,示例传不出「无」,必须显式一句(覆盖 agent 默认时尤其)>
+- <breaking change / schema 变更等正文标注——挖到才写,无则不写>
+```
+
+挖掘口径:标题格式(如 `CRM-req74181<描述>-client@req74181` 这类项目独有格式)**挖不出来就问用户,不得编造**;票据关联、语言、多步约定全部落进标注与行为规则,不单开段落解释;「历史风格已废」只写「只认上述格式」一句,不枚举废格式。
+
+**新项目(无历史)**:给常见模式选项让用户选(Conventional Commits `type(scope): subject` / 票据前缀式),或用户直接给团队规范,选定后仍按上述形态生成。
+
+## 第二部分 · 提交前检查点(项目自定义)
+
+按技术栈给默认检查点 + 用户确认增删;每项写"查什么 + 为什么危险"。通用种子:
+
+- 被注释掉的开关/注册项(写该项目实际语法:Spring `@Component`/`@Scheduled`/`@JmsListener` 等注解、前端组件注册、配置开关)——被注释 = 功能静默失效,高危
+- 被注释掉的业务调用(监听注册、定时任务、关键链路入口)
+- 未闭合逻辑(括号失衡、if/try/for 未配对)
+- 写死的魔法字符串/数字(密码、URL、ID、阈值)
+- 新增 TODO/FIXME/临时标记
+
+项目特有项由用户补充(历史事故点、团队红线)。

package/dist/.claude-template/skills/init-project-guides/templates/go.md

@@ -0,0 +1,160 @@
+# Go 项目规范模板
+
+> 本目录包含 init-project-guides skill 的 Go 技术栈模板片段。
+
+> **填法(每个 `{{占位}}` 节都适用)**:只写**项目特异约定** —— 过 SKILL「判别」两条测试(必要性:删掉它工程师会不会做不一样;执行点:lint/工具是否已强制)。三类不写:技术栈事实、通用常识(单一职责/复用/合理拆分)、工具已强制项(gofmt 管的缩进/格式、命名大小写)。挖不到项目特异内容 → 该节写一行"无特殊约定,遵循默认/lint"或整节省写,**不得用通用最佳实践凑数**。标题带 `(偏离项)` 的节只写偏离默认之处,默认如此的不写。**形态**:每节优先给一条带 `├─` 来源标注的正例,禁令只写覆盖默认值的——按 SKILL「生成形态纪律」,不写反例画廊。
+
+---
+
+## coding-standards.md 模板
+
+```markdown
+# 编码规范
+
+> 技术栈(取向一行,非规范):{{tech_stack}}
+
+## 目录结构(偏离项)
+
+{{directory_structure}}
+
+## 包命名(偏离项)
+
+{{package_naming}}
+
+## 命名约定(偏离项)
+
+{{naming_conventions}}
+
+## 错误处理(偏离项)
+
+{{error_handling}}
+
+## Context 传递(偏离项)
+
+{{context_passing}}
+
+## 项目硬约束(仅项目特有)
+
+{{coding_red_lines}}
+```
+
+> `项目硬约束` 只写项目明令的硬红线(如"单文件超 N 行必须拆分"若项目确实这么定、某类写法明令禁止)。单一职责 / 复用 / 合理拆分 / 策略模式 这类通用常识**不写**——那不是项目规范。
+
+---
+
+## interface-standards.md 模板
+
+```markdown
+# 接口设计规范
+
+## HTTP 接口设计(路径/前缀)
+
+{{http_api_design}}
+
+## 参数校验(偏离项)
+
+{{parameter_validation}}
+
+## 返回值规范(偏离项)
+
+{{response_conventions}}
+
+## 中间件
+
+{{middleware_conventions}}
+```
+
+> 接口规范是项目约定密集区:路径前缀(如 `/fix`)、统一返回包形态、错误码形态 这类**推不出的**才写;RESTful、参数要校验 这类常识不写。
+
+---
+
+## data-standards.md 模板 · 模型层
+
+```markdown
+# 模型规范
+
+## Struct 定义(偏离项)
+
+{{struct_rules}}
+
+## 数据库映射
+
+{{orm_mapping}}
+
+## 通用字段
+
+{{common_fields}}
+
+## 关联关系
+
+{{relationship_rules}}
+```
+
+> **关联关系标注(示范形态,按项目实际约定填)**:关系通常不靠 `FOREIGN KEY` 约束表达,而在字段注释里标「关联 <表>.<业务字段>」:
+>
+> ```sql
+> COMMENT ON COLUMN work_order.assignee_staff IS '处理人工号,关联 users.staff_code';  -- PostgreSQL
+> `assignee_staff` varchar(32) COMMENT '处理人工号,关联 users.staff_code'             -- MySQL
+> ```
+>
+> 注释写清「什么业务含义 · 关联哪张表的业务字段」;项目用业务字段关联的,**禁无意义自增 id 关联**(覆盖默认建模习惯,一句规则即可,不必列反例)。加不加 FK、用不用业务字段本身是项目选型——挖到项目怎么定就怎么写,别照抄示例。
+
+---
+
+## data-standards.md 模板 · DDL 层
+
+```markdown
+# DDL 编写规范
+
+## 基本规则(项目特有)
+
+{{ddl_basic_rules}}
+
+## 表命名约定
+
+{{table_naming}}
+
+## 字段类型选择
+
+{{field_type_mapping}}
+
+## 迁移工具
+
+{{migration_tools}}
+```
+
+> DDL 是项目约定密集区:表名前缀、`decimal(12,2)` 这类类型锁定、"禁止 `ORDER BY`" 这类禁令、测试库/生产库名映射 才写;主键 bigint、utf8mb4 这类栈默认不写。
+
+---
+
+## testing-standards.md 模板
+
+```markdown
+# 测试规范
+
+## 技术栈与框架
+
+{{test_frameworks}}
+
+## 目录与命名(偏离项)
+
+{{test_directory_naming}}
+
+## 单测 / 集成边界
+
+{{unit_vs_integration}}
+
+## Mock 政策
+
+{{mock_policy}}
+
+## Fixture 组织
+
+{{fixture_organization}}
+
+## 覆盖预期(项目门槛,无则不写)
+
+{{coverage_expectations}}
+```
+
+> 单测/集成边界、Mock 政策是**选型锁定**(多个合理做法里项目选了哪个),属规范;覆盖率无项目硬性门槛就别凑"80%"这种通用数字。

package/dist/.claude-template/skills/init-project-guides/templates/java.md

@@ -0,0 +1,173 @@
+# Java 项目规范模板
+
+> 本目录包含 init-project-guides skill 的 Java 技术栈模板片段。
+> 这些片段会被动态填充到生成的规范文件中。
+
+> **填法(每个 `{{占位}}` 节都适用)**:只写**项目特异约定** —— 过 SKILL「判别」两条测试(必要性:删掉它工程师会不会做不一样;执行点:lint/工具是否已强制)。三类不写:技术栈事实、通用常识(单一职责/复用/合理拆分)、工具已强制项(缩进/命名大小写)。挖不到项目特异内容 → 该节写一行"无特殊约定,遵循默认/lint"或整节省写,**不得用通用最佳实践凑数**。标题带 `(偏离项)` 的节只写偏离默认之处,默认如此的不写。**形态**:每节优先给一条带 `├─` 来源标注的正例,禁令只写覆盖默认值的——按 SKILL「生成形态纪律」,不写反例画廊。
+
+---
+
+## coding-standards.md 模板
+
+```markdown
+# 编码规范
+
+> 技术栈(取向一行,非规范):{{tech_stack}}
+
+## 目录结构(偏离项)
+
+{{directory_structure}}
+
+## 命名约定(偏离项)
+
+{{naming_conventions}}
+
+## 注释规范(偏离项)
+
+{{comment_conventions}}
+
+## 常量管理(偏离项)
+
+{{constant_management}}
+
+## 错误处理(偏离项)
+
+{{error_handling}}
+
+## 项目硬约束(仅项目特有)
+
+{{coding_red_lines}}
+```
+
+> `项目硬约束` 只写项目明令的硬红线(如"单文件超 N 行必须拆分"若项目确实这么定、某类写法明令禁止)。单一职责 / 复用 / 合理拆分 / 策略模式 这类通用常识**不写**——那不是项目规范。
+
+---
+
+## interface-standards.md 模板
+
+```markdown
+# 接口设计规范
+
+## 接口路径规范(前缀/版本)
+
+{{api_path_conventions}}
+
+## 服务命名约定
+
+{{service_naming}}
+
+## 参数与返回值(偏离项)
+
+{{parameter_return_conventions}}
+
+## 兼容性规则
+
+{{compatibility_rules}}
+
+## 调用模式
+
+{{call_patterns}}
+```
+
+> 接口规范是项目约定密集区:路径前缀(如 `/fix`)、服务命名、统一返回包形态、兼容性红线 这类**推不出的**才写;RESTful、参数要校验 这类常识不写。
+
+---
+
+## data-standards.md 模板 · 模型层
+
+```markdown
+# 模型规范
+
+## 实体规则(偏离项)
+
+{{entity_rules}}
+
+## 通用字段
+
+{{common_fields}}
+
+## 主键约定
+
+{{primary_key_conventions}}
+
+## 字段注释
+
+{{field_comment_rules}}
+
+## 关联关系
+
+{{relationship_rules}}
+```
+
+> **关联关系标注(示范形态,按项目实际约定填)**:关系通常不靠 `FOREIGN KEY` 约束表达,而在字段注释里标「关联 <表>.<业务字段>」:
+>
+> ```sql
+> COMMENT ON COLUMN work_order.assignee_staff IS '处理人工号,关联 users.staff_code';  -- PostgreSQL
+> `assignee_staff` varchar(32) COMMENT '处理人工号,关联 users.staff_code'             -- MySQL
+> ```
+>
+> 注释写清「什么业务含义 · 关联哪张表的业务字段」;项目用业务字段关联的,**禁无意义自增 id 关联**(覆盖默认建模习惯,一句规则即可,不必列反例)。加不加 FK、用不用业务字段本身是项目选型——挖到项目怎么定就怎么写,别照抄示例。
+
+---
+
+## data-standards.md 模板 · DDL 层
+
+```markdown
+# DDL 编写规范
+
+## 基本规则(项目特有)
+
+{{ddl_basic_rules}}
+
+## 表命名约定
+
+{{table_naming}}
+
+## 字段类型选择
+
+{{field_type_mapping}}
+
+## 索引规范
+
+{{index_conventions}}
+
+## 迁移工具
+
+{{migration_tools}}
+```
+
+> DDL 是项目约定密集区:表名前缀、`decimal(12,2)` 这类类型锁定、"禁止 `ORDER BY`" 这类禁令、测试库/生产库名映射 才写;主键 bigint、utf8mb4 这类栈默认不写。
+
+---
+
+## testing-standards.md 模板
+
+```markdown
+# 测试规范
+
+## 技术栈与框架
+
+{{test_frameworks}}
+
+## 目录与命名(偏离项)
+
+{{test_directory_naming}}
+
+## 单测 / 集成边界
+
+{{unit_vs_integration}}
+
+## Mock 政策
+
+{{mock_policy}}
+
+## Fixture 组织
+
+{{fixture_organization}}
+
+## 覆盖预期(项目门槛,无则不写)
+
+{{coverage_expectations}}
+```
+
+> 单测/集成边界、Mock 政策是**选型锁定**(多个合理做法里项目选了哪个),属规范;覆盖率无项目硬性门槛就别凑"80%"这种通用数字。

package/dist/.claude-template/skills/init-project-guides/templates/schema-convention.md

@@ -0,0 +1,11 @@
+# Schema 变更约定(约定文本)
+
+> init-project-guides 生成 data-standards.md 时,将下文**逐字拷入**「## Schema 变更约定」节(`<工程>` 替换为项目实际工程名;单工程项目去掉工程分层表述)。不得改写、概括或省略。
+
+## Schema 变更约定
+
+- **全量(最终态,写透)**:`docs/schema-knowledge/<工程>/ddl/<表名>.sql` 一表一文件、表名命名,始终是该表的最终 CREATE TABLE——模型一变就直接改成最终版,不保留历史;新表登记 INDEX.md。基线与周期校准由 `/export-table-ddl` 负责。
+- **增量(流水,只增不改)**:需求变更脚本落在 `docs/features/<feature-id>/sql/[<工程>/]`(多工程加一层工程目录,单工程平铺),一次动作一个文件,命名 `<两位序号>-<动作名>.sql`(如 `01-新建用户表.sql`、`02-用户表新增手机号字段.sql`);执行顺序即序号顺序;开发期模型反复 → 追加新文件,不回头改旧的。DML(初始化/订正数据)同目录同命名。
+- 改造既有功能:全量直接改到最终,需求内只记增量;全新功能:建表语句同样进需求 sql/(它是一条增量动作),全量正常维护到最终。
+- 发版增量集合 = 上次发版以来各需求 `sql/` 的汇集,按需求目录日期 + 文件序号执行。
+- **交付自检**:全量终态 = 增量动作依次执行的结果;不一致 = 漏维护,视为交付未完成。

package/dist/.claude-template/skills/init-project-guides/templates/typescript.md

@@ -0,0 +1,156 @@
+# TypeScript 项目规范模板
+
+> 本目录包含 init-project-guides skill 的 TypeScript 技术栈模板片段。
+
+> **填法(每个 `{{占位}}` 节都适用)**:只写**项目特异约定** —— 过 SKILL「判别」两条测试(必要性:删掉它工程师会不会做不一样;执行点:lint/工具是否已强制)。三类不写:技术栈事实、通用常识(单一职责/复用/合理拆分)、工具已强制项(缩进/引号/命名大小写)。挖不到项目特异内容 → 该节写一行"无特殊约定,遵循默认/lint"或整节省写,**不得用通用最佳实践凑数**。标题带 `(偏离项)` 的节只写偏离默认之处,默认如此的(如 TS 用 camelCase)不写。**形态**:每节优先给一条带 `├─` 来源标注的正例,禁令只写覆盖默认值的——按 SKILL「生成形态纪律」,不写反例画廊。
+
+---
+
+## coding-standards.md 模板
+
+```markdown
+# 编码规范
+
+> 技术栈(取向一行,非规范):{{tech_stack}}
+
+## 目录结构(偏离项)
+
+{{directory_structure}}
+
+## 类型安全(偏离项)
+
+{{type_safety}}
+
+## 命名约定(偏离项)
+
+{{naming_conventions}}
+
+## 注释规范(偏离项)
+
+{{comment_conventions}}
+
+## 项目硬约束(仅项目特有)
+
+{{coding_red_lines}}
+```
+
+> `项目硬约束` 只写项目明令的硬红线(如"单文件超 N 行必须拆分"若项目确实这么定、某类写法明令禁止)。单一职责 / 复用 / 合理拆分 / 策略模式 这类通用常识**不写**——那不是项目规范。
+
+---
+
+## interface-standards.md 模板
+
+```markdown
+# 接口设计规范
+
+## API 设计(路径/版本/前缀)
+
+{{api_design}}
+
+## 参数校验(偏离项)
+
+{{parameter_validation}}
+
+## 返回值规范(偏离项)
+
+{{response_conventions}}
+
+## 错误处理(错误码形态)
+
+{{error_handling}}
+```
+
+> 接口规范是项目约定密集区:路径前缀(如 `/fix`)、版本约定、统一返回包形态、错误码位数/分段 这类**推不出的**才写;RESTful、参数要校验 这类常识不写。
+
+---
+
+## data-standards.md 模板 · 模型层
+
+```markdown
+# 模型规范
+
+## Interface/Type 定义(偏离项)
+
+{{interface_type_rules}}
+
+## 数据库映射
+
+{{orm_mapping}}
+
+## 通用字段
+
+{{common_fields}}
+
+## 关联关系
+
+{{relationship_rules}}
+```
+
+> **关联关系标注(示范形态,按项目实际约定填)**:关系通常不靠 `FOREIGN KEY` 约束表达,而在字段注释里标「关联 <表>.<业务字段>」:
+>
+> ```sql
+> COMMENT ON COLUMN work_order.assignee_staff IS '处理人工号,关联 users.staff_code';  -- PostgreSQL
+> `assignee_staff` varchar(32) COMMENT '处理人工号,关联 users.staff_code'             -- MySQL
+> ```
+>
+> 注释写清「什么业务含义 · 关联哪张表的业务字段」;项目用业务字段关联的,**禁无意义自增 id 关联**(覆盖默认建模习惯,一句规则即可,不必列反例)。加不加 FK、用不用业务字段本身是项目选型——挖到项目怎么定就怎么写,别照抄示例。
+
+---
+
+## data-standards.md 模板 · DDL 层
+
+```markdown
+# DDL 编写规范
+
+## 基本规则(项目特有)
+
+{{ddl_basic_rules}}
+
+## 表命名约定
+
+{{table_naming}}
+
+## 字段类型选择
+
+{{field_type_mapping}}
+
+## 迁移工具
+
+{{migration_tools}}
+```
+
+> DDL 是项目约定密集区:表名前缀、`decimal(12,2)` 这类类型锁定、"禁止 `ORDER BY`" 这类禁令、测试库/生产库名映射 才写;主键 bigint、utf8mb4 这类栈默认不写。
+
+---
+
+## testing-standards.md 模板
+
+```markdown
+# 测试规范
+
+## 技术栈与框架
+
+{{test_frameworks}}
+
+## 目录与命名(偏离项)
+
+{{test_directory_naming}}
+
+## 单测 / 集成边界
+
+{{unit_vs_integration}}
+
+## Mock 政策
+
+{{mock_policy}}
+
+## Fixture 组织
+
+{{fixture_organization}}
+
+## 覆盖预期(项目门槛,无则不写)
+
+{{coverage_expectations}}
+```
+
+> 单测/集成边界、Mock 政策是**选型锁定**(多个合理做法里项目选了哪个),属规范;覆盖率无项目硬性门槛就别凑"80%"这种通用数字。