soloforge 1.1.45 → 1.1.47

package/templates/design//350/257/246/347/273/206/350/256/276/350/256/241.md

@@ -1,109 +0,0 @@
----
-id: ka-artifact_template-详细设计模版
-kind: artifact
-title: 详细设计
-sync_policy: copy_to_project
-status: active
-extra:
-  name: detail-design
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  type: artifact
-  domain: design
-  trigger_conditions:
-    - 复杂状态机（≥3 个状态）
-    - 多模块协调逻辑
-    - 并发/缓存/分布式锁场景
-  stage: design
-  owner_mechanism: mc-generic-artifact
----
-
-# 详细设计文档
-
-> **定位说明**：本文件为条件产物。核心产出为 design/01-数据库设计文档.md 和 design/02-API接口规格文档.md。
-> 当触发条件满足时本文件应生成；简单 CRUD 模块可跳过。
-> Gate 不强制检查本文件存在性，仅在"OOD 工作流触发合规"中判断是否需要 OOD 分析。
-
-## 1. 设计前提
-- 对接的架构设计文档：
-- 依赖的接口/模块：
-
-> **根本目标引用**：本产物的 `fundamental_need` 见需求分析文档 §1.3。若未声明，引用审查规则 FP-01。
-
-## 2. 数据结构（DDL/Model） [Always — 必填]
-
-### 2.1 表结构定义
-| 表名 | 字段名 | 类型 | 约束 | 注释 | 默认值 | 敏感级别 | 来源章节 |
-|------|--------|------|------|------|--------|----------|----------|
-| <!-- 表名 --> | <!-- 字段 --> | <!-- 类型 --> | <!-- 约束 --> | <!-- 注释 --> | <!-- 默认值 --> | <!-- 级别 --> | <!-- 章节 --> |
-
-敏感级别枚举：公开 / 内部 / 敏感 / 机密
-来源章节：引用架构设计文档中的对应章节编号
-
-### 2.2 实体关系
-| 父实体 | 子实体 | 关系类型 | 外键字段 | 级联行为 | 说明 |
-|--------|--------|----------|----------|----------|------|
-<!-- 按实际填写 -->
-关系类型枚举：一对一 / 一对多 / 多对多
-级联行为枚举：CASCADE / SET_NULL / RESTRICT / 无
-
-### 2.3 索引策略
-| 表名 | 索引名 | 索引类型 | 字段列表 | 查询场景 | 创建理由 |
-|------|--------|----------|----------|----------|----------|
-<!-- 按实际填写 -->
-索引类型枚举：PRIMARY / UNIQUE / INDEX / COMPOSITE / FULLTEXT
-
-## 3. 接口定义 [Always — 必填]
-
-### 3.1 内部接口（模块间调用）
-| 接口编号 | 方法签名 | 入参类型 | 出参类型 | 异常列表 | 幂等性 | 调用方 |
-|----------|----------|----------|----------|----------|--------|--------|
-<!-- 按实际填写 -->
-幂等性枚举：是（天然幂等） / 是（通过幂等键） / 否
-
-### 3.2 外部依赖接口 [Ask first — 如有外部依赖则必填]
-| 接口编号 | 来源服务 | 接口地址 | 调用方式 | 超时策略 | 降级策略 | 说明 |
-|----------|----------|----------|----------|----------|----------|------|
-<!-- 按实际填写 -->
-
-## 4. 核心逻辑 [Always — 必填]
-
-### 4.1 状态机定义
-| 状态 | 事件 | 守卫条件 | 目标状态 | 动作 | 副作用说明 |
-|------|------|----------|----------|------|------------|
-<!-- 按实际填写 -->
-
-### 4.2 异常处理策略
-| 异常类型 | 触发条件 | 处理方式 | 用户提示 | 日志级别 | 上报策略 |
-|----------|----------|----------|----------|----------|----------|
-<!-- 按实际填写 -->
-日志级别枚举：DEBUG / INFO / WARN / ERROR / FATAL
-上报策略枚举：忽略 / 记录日志 / 告警 / 阻断
-
-### 4.3 并发控制方案
-| 资源 | 并发场景 | 控制策略 | 锁粒度 | 超时策略 | 回退方案 |
-|------|----------|----------|--------|----------|----------|
-<!-- 按实际填写 -->
-控制策略枚举：乐观锁 / 悲观锁 / 分布式锁 / 幂等键 / 无需
-
-### 4.4 缓存方案 [Ask first — 如使用缓存则必填]
-| 缓存 key | 数据内容 | TTL | 失效策略 | 一致性保障 | 预估大小 |
-|----------|----------|-----|----------|------------|----------|
-<!-- 按实际填写 -->
-失效策略枚举：主动失效 / 被动过期 / 定时刷新 / 无
-
-## 5. 前后端适配矩阵
-| 前端页面/组件 | 后端接口 | 数据字段映射 | 交互行为 |
-|-------------|---------|------------|---------|
-|             |         |            |         |
-
-## 6. 菜单权限映射
-| 菜单路径 | 角色 | 权限标识 | 关联接口 |
-|---------|------|---------|---------|
-|         |      |         |         |

package/templates/design//350/257/246/347/273/206/350/256/276/350/256/241/345/256/241/346/237/245.md

@@ -1,88 +0,0 @@
----
-id: 详细设计审查
-kind: guidance
-title: 详细设计审查
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 详细设计审查
-  - 设计审查
-  - DD-REV
-  - detail design review
-extra:
-  name: detail-design-review
-  type: constraint
-  scope:
-    - '*'
-  products:
-    - '*'
-  domain: design
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-command-router
----
-
-# 详细设计审查规则
-
-> **DD-REV vs CON-DD 职责划分**：
-> - **DD-REV** 检查**引用格式**（"每个模块是否有 ARCH-* 引用"）
-> - **CON-DD** 检查**覆盖完整性**（"架构文档中所有实体是否无遗漏"）
-> - 两者互补：DD-REV 确保引用正确，CON-DD 确保没有遗漏
-
-## 对照架构设计交叉验证
-
-### DD-REV-01: 模块引用格式
-  check_hint: 详细设计中的每个模块必须引用架构设计文档中的 ARCH-* 编号
-  severity: error
-  description: 禁止无 ARCH-* 引用的模块设计。每个模块必须在架构设计文档中有明确对应。
-  evidence: 模块定义行包含 [ARCH-XX] 引用标记。
-  check_focus: 引用格式——检查"是否有引用"，不检查覆盖完整性（覆盖由 CON-DD-01 负责）
-
-### DD-REV-02: 实体引用格式
-  check_hint: 数据库设计中每张表必须标注来源 ARCH-* 编号
-  severity: error
-  description: 数据库设计文档中的每张表必须标注来源 ARCH-* 编号。
-  evidence: 表定义行包含 [ARCH-XX] 引用标记。
-  check_focus: 引用格式——不检查实体是否遗漏（遗漏由 CON-DD-01 负责）
-
-### DD-REV-03: API 引用格式
-  check_hint: API 接口规格中的每个 endpoint 必须标注来源 ARCH-* 编号
-  severity: error
-  description: 每个 endpoint 必须引用架构设计中的模块定义。
-  evidence: endpoint 定义行包含 [ARCH-XX] 引用标记。
-
-### DD-REV-04: 无未定义扩展
-  check_hint: 详细设计不得引入架构文档未定义的新模块/层次/实体
-  severity: error
-  description: 所有新增模块必须先更新架构设计文档获得 ARCH-* 编号。发现未定义扩展时回退到 design 域（架构设计）重新评估。
-
-## 接口规格一致性
-
-### DD-REV-05: OpenAPI 同步
-  check_hint: openapi.yaml 必须与详细设计中的接口规格完全一致
-  severity: error
-  description: 路径、方法、参数、返回值逐一匹配。以详细设计为准同步 openapi。
-  evidence: 逐一比对结果记录（endpoint_id + 一致性状态）。
-
-### DD-REV-06: 字段级匹配
-  check_hint: 接口规格文档中每个字段必须在 openapi.yaml 中有对应定义
-  severity: error
-  description: 字段名、类型、约束、枚举值必须完全一致。允许 openapi 更详细但不允许不一致。
-  evidence: 字段级比对清单。
-
-## 字段级追溯
-
-### DD-REV-07: 数据库字段追溯
-  check_hint: 数据库设计文档中每个字段必须追溯到 REQ-* 或 ARCH-*
-  severity: error
-  description: 追踪链：表→ARCH-XX→REQ-XX。计算字段标注"系统生成"即可。
-  evidence: 数据库设计文档字段追溯表无空缺项（每个字段已追溯到 REQ-* 或 ARCH-*）。
-
-### DD-REV-08: API 参数追溯
-  check_hint: API 接口规格中每个参数必须追溯到业务流程中的使用场景
-  severity: warning
-  description: 每个参数标注调用场景。无法追溯的标注"预留"并附理由。
-  evidence: API 参数表无空缺项。

package/templates/design//350/260/203/350/257/225/346/226/271/346/263/225/350/256/272.md

@@ -1,43 +0,0 @@
----
-id: ka-pattern-debugging-methodology
-kind: knowledge
-title: 调试方法论
-sync_policy: copy_to_project
-status: active
-extra:
-  name: debugging-methodology
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  type: knowledge
-  domain: design
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-general-pattern
----
-
-## 决策规则
-- 一次只验证一个假设，一次只改一个变量，记录所有结果包括被否定的假设
-- 禁止从观察直接跳到修复，必须经过假设验证
-- 修复范围只覆盖确认的根因，禁止顺手改其他代码
-- 同一现象修复失败 3 次后停止猜测，重新审视假设，考虑是否为架构问题而非 Bug
-- 使用 RED-GREEN 回归验证：回退修复 → 确认失败 → 恢复修复 → 确认通过
-- 禁止通过删除断言、增加 sleep、降低覆盖率、增加 mock 来制造通过
-- 调试必须先复现问题（确定环境、数据、步骤），禁止在未复现的情况下猜测修改
-- 必须使用二分法定位问题范围（注释一半代码/回退一半提交），禁止全量排查
-- 线上问题排查必须优先查看日志和监控，禁止直接登录服务器修改代码
-- 修复后必须验证根因是否消除，而非只验证症状消失
-
-## 验收项
-- [AC-01] 调试过程有假设-验证记录
-- [AC-02] 修复范围仅限确认的根因
-- [AC-03] 3次失败后重新审视假设
-- [AC-04] 使用 RED-GREEN 回归验证
-- [AC-05] 先复现再排查
-- [AC-06] 使用二分法定位
-- [AC-07] 修复后验证根因消除

package/templates/design//350/277/201/347/247/273/350/257/204/344/274/260.md

@@ -1,67 +0,0 @@
----
-id: ka-artifact_template-迁移评估模版
-kind: artifact
-title: 迁移评估
-sync_policy: copy_to_project
-status: active
-extra:
-  name: migration-assessment
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  type: artifact
-  domain: design
-  stage: design
-  owner_mechanism: mc-generic-artifact
----
-
-# 迁移评估报告
-
-## 1. 迁移范围
-- 当前技术/版本：
-- 目标技术/版本：
-- 涉及模块数/代码量：
-- 依赖链影响范围：
-
-## 2. 兼容性分析
-| 变更项 | 当前 | 目标 | 兼容性 | 适配方案 |
-|--------|------|------|--------|---------|
-| API 变更 | | | | |
-| 配置变更 | | | | |
-| 行为差异 | | | | |
-| 依赖冲突 | | | | |
-
-## 3. 迁移路径
-- **推荐路径**：渐进式 / 一次性
-- **阶段划分**：
-| 阶段 | 内容 | 预计工时 | 回滚方案 |
-|------|------|---------|---------|
-| 1 | | | |
-| 2 | | | |
-
-## 4. 风险评估
-- 高风险点：
-- 兼容层需求（适配器/Shim/Feature Flag）：
-- 数据迁移需求：
-- 回滚方案：
-
-### AI 迁移特定风险
-- AI Agent 执行迁移时的一致性风险（多次执行结果是否一致）
-- AI Agent 对迁移工具链的可靠性依赖（Agent 是否正确调用 migration 工具）
-- AI Agent 在迁移失败时的回滚决策能力
-- 迁移前后 AI 验证覆盖的可靠性（是否仅依赖通过率）
-
-### 缓解措施
-- 迁移脚本须幂等（已有）→ AI 重复执行不出错
-- 迁移验证须 4 维可靠性指标（一致性/鲁棒性/可预测性/安全性）
-- 迁移回滚决策须经人工审批（control-plane）
-
-## 5. 资源与时间
-- 所需人力/技能：
-- 建议时间窗口：
-- 灰度策略：

package/templates/design//351/232/224/347/246/273/351/200/202/351/205/215/345/231/250/346/226/271/346/241/210.md

@@ -1,44 +0,0 @@
----
-id: 隔离适配器方案
-kind: artifact
-title: 隔离适配器方案
-sync_policy: copy_to_project
-status: active
-extra:
-  name: isolation-adapter-plan
-  type: artifact
-  scope:
-    - '*'
-  domain: design
-  lifecycle_status: active
-  stage: design
-  owner_mechanism: mc-existing-system-artifact
----
-
-# 隔离适配器方案
-
-## 1. 隔离策略概述
-<!-- 新老接口共存的隔离策略说明 -->
-
-## 2. 接口适配层
-
-### 2.1 新老接口共存适配
-<!-- 新接口如何与老接口共存，路由规则 -->
-
-### 2.2 数据同步中间层
-<!-- 新老数据库表之间的数据同步方案 -->
-
-### 2.3 Feature Toggle 隔离
-| 开关名称 | 默认状态 | 金丝雀比例 | 观察时间 | 自动回滚阈值 | 回退目标 |
-|---------|---------|-----------|---------|------------|---------|
-| <!-- 功能名 --> | off | 10% | 30 分钟 | 错误率 >5% | 老逻辑 |
-
-### 2.4 API 语义差异
-| 老接口 | 新接口 | 语义差异 | 兼容策略 | 风险评估 |
-|--------|--------|---------|---------|---------|
-
-## 3. 隔离架构图
-<!-- 新老系统的隔离边界示意 -->
-
-## 4. 回退策略
-<!-- 如果隔离层出现问题，如何快速切回老逻辑 -->

package/templates/design//351/234/200/346/261/202/346/276/204/346/270/205.md

@@ -1,65 +0,0 @@
----
-id: ka-procedure-需求澄清流程
-kind: guidance
-title: 需求澄清
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 需求澄清
-  - design
-  - 需求梳理
-  - 理解需求
-  - 需求确认
-  - requirement
-  - 需求评审
-extra:
-  name: requirement-clarify
-  type: procedure
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.3.0
-  last_reviewed: '2026-06-04'
-  domain: design
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-command-router
----
-
-## 适用场景
-从原始需求中提取结构化事实、识别冲突和缺口、产出可追溯的需求基线。适用于编码前的需求理解阶段。
-
-## 步骤
-1. 提取需求事实：从需求文档/用户描述中提取功能点、页面交互、业务规则
-2. 分离事实与决策：需求事实和架构决策分列记录，禁止将 AI 推论伪装为需求事实
-3. 运行术语一致性检查：识别同一概念不同命名，统一术语
-4. 标记未确认项：无法确认的需求标记为「待确认」，禁止猜测或跳过
-4a. **头脑风暴触发**：若用户表达不确定（"你看着办"/"都行"/"不确定"），或需求本身有矛盾/遗漏：
-   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴.md）
-   → 若 fundamental_need 为空 → 先触发 FP-01（第一性原理推理规则）
-5. 标注冲突和越界项：明确来源和处理方式（冲突标注来源，越界标注排除原因）
-6. 定义用户角色（新增）：识别所有与系统交互的角色，明确每个角色的职责、关联功能、可见菜单和数据权限范围。角色名称必须在菜单权限（第 6 章）和功能点（第 2 章）中保持一致引用
-7. 绑定菜单权限：菜单需求必须关联角色、页面、操作权限（依赖步骤 6 的角色定义）
-8. 声明写操作的失败反馈：每个用户可见写操作必须有提示文案、重试建议、是否可恢复
-9. 启发非功能需求（新增）：对每个功能点追问性能、安全、可用性、兼容性、数据保留五个维度，每条 NFR 必须包含量化验收指标。若需求来源未提及 NFR，按项目默认 NFR 基线补齐
-10. 分析功能依赖（新增）：梳理功能点之间的前置依赖和关联关系，标注到功能点清单的"前置依赖"和"关联功能"列。依赖关系必须无循环
-11. 识别外部接口（新增）：梳理系统依赖的外部系统、第三方 API、消息队列等集成点。若系统无外部依赖，显式标注"本系统无外部接口依赖"
-12. 冻结需求基线：按需求 ID 冻结验收信号和重新打开条件（必须是人工确认点，Agent 不可自动冻结）
-
-## 检查点
-- [ ] 术语一致，无同义混用（对应步骤 3）
-- [ ] 每个来源项映射到唯一目标，无孤立页面交互
-- [ ] 用户角色在菜单权限和功能点中引用一致，无悬空角色（对应步骤 6）
-- [ ] 菜单需求绑定角色/权限，无悬空项（对应步骤 7）
-- [ ] 用户可见写操作有失败反馈、删除语义、审计要求（对应步骤 8）
-- [ ] 非功能需求包含量化验收指标，无"高性能""安全"等模糊表述（对应步骤 9）
-- [ ] 每条功能点有唯一编号（REQ-NNN）且在架构/切片产物中被引用（对应步骤 10）
-- [ ] 需求基线按 ID 冻结（对应步骤 12）
-
-## 注意事项
-- 禁止将 AI 推论冒充为需求事实
-- 原型缺失不阻塞需求分析
-- 未确认需求必须显式标记，禁止静默跳过

package/templates/design//351/234/200/346/261/202/350/264/250/351/207/217/345/256/241/346/237/245.md

@@ -1,88 +0,0 @@
----
-id: ka-review-rule-需求质量审查规则
-kind: guidance
-title: 需求质量审查
-sync_policy: copy_to_project
-status: active
-triggers:
-  - design
-  - 需求审查
-  - requirement review
-extra:
-  name: requirement-quality-review
-  type: constraint
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  domain: design
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-command-router
----
-
-# 需求质量审查规则
-
-## REQ-01: 需求可测试性
-
-check_hint: 需求描述必须包含可量化的验收标准
-severity: warning
-scope: [backend, frontend]
-description: 每个需求点必须至少有一条可验证的验收标准，避免模糊表述（如"性能好"应改为"响应时间<200ms"）
-
-## REQ-02: 功能/非功能/约束三维度覆盖
-
-check_hint: 需求分析必须覆盖功能需求、非功能需求和约束条件
-severity: warning
-scope: [backend, frontend]
-description: 需求文档必须明确区分功能需求（做什么）、非功能需求（性能、安全、可用性等）和约束条件（技术栈、时间、资源等）。
-  非功能需求必须包含量化验收指标：性能需求必须有响应时间/并发数指标；安全需求必须有加密标准/认证方式；
-  可用性需求必须有可用率百分比；兼容性需求必须有具体浏览器/设备版本。
-  禁止出现"高性能""安全""稳定"等无量化指标的表述。
-
-## REQ-03: 需求无歧义表达
-
-check_hint: 需求描述不得使用模糊量词或条件
-severity: warning
-scope: [backend, frontend]
-description: 禁止使用"等"、"相关"、"适当的"、"必要时"等模糊表述；每个需求点必须有一个明确的动作和对象
-
-## REQ-04: 需求间无矛盾
-
-check_hint: 需求文档中不得存在相互矛盾的描述
-severity: warning
-scope: [backend, frontend]
-description: 检查需求间是否存在矛盾（如"支持离线使用"与"实时同步数据"），发现矛盾必须标注并请求澄清
-
-## REQ-05: 需求完整性
-
-check_hint: 每个功能需求必须包含触发条件、处理逻辑和预期结果
-severity: warning
-scope: [backend, frontend]
-description: 缺少触发条件、处理逻辑或预期结果的需求必须标注为"待补充"，不得留空
-
-## REQ-06: 用户角色一致性
-
-check_hint: 菜单权限和功能点引用的角色必须在用户角色章节中有定义
-severity: error
-scope: [backend, frontend]
-description: 第 6 章菜单权限的每个角色名称必须在第 9 章用户角色中存在对应条目；
-  第 2 章功能点的"关联角色"引用同样必须在第 9 章有定义。发现未定义角色引用应立即阻断。
-
-## REQ-07: 需求单一性
-
-check_hint: 每条功能点必须只描述一个用户操作或一个业务规则
-severity: warning
-scope: [backend, frontend]
-description: 禁止一条功能点包含多个"当...时"条件分支或多个"和"连接的独立操作。复合需求应拆分为多条，用前置依赖字段关联。
-
-## REQ-08: 需求可追溯
-
-check_hint: 每条功能点必须有唯一 REQ-NNN 编号
-severity: warning
-scope: [backend, frontend]
-description: 功能点编号格式为 REQ-NNN。每个 REQ-NNN 须在架构设计文档或切片计划验收范围中被引用，否则标注为"待追溯"。

package/templates/design//351/242/206/345/237/237/351/251/261/345/212/250/350/256/276/350/256/241.md

@@ -1,43 +0,0 @@
----
-id: ka-pattern-ddd-design
-kind: knowledge
-title: 领域驱动设计
-sync_policy: copy_to_project
-status: active
-extra:
-  name: ddd-design
-  scope:
-    - backend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  type: knowledge
-  domain: design
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-backend-pattern
----
-
-## 决策规则
-- 简单 CRUD 使用贫血模型，禁止在领域不复杂时强行使用充血模型
-- 不教条式应用 DDD，仅在领域真正复杂时采用充血领域模型
-- 一个模块/类应该只有一个变更原因（SRP），两个方法被不同需求修改即为 SRP 违反
-- 跨模块非强一致性流程应优先事件驱动架构，未采用事件驱动必须文档化原因
-- 高层模块必须依赖抽象而非具体实现（DIP），Service 依赖 Repository 接口而非具体 DAO
-- 写操作涉及金额、库存、状态流转等关键逻辑应考虑封装在领域服务中
-- 聚合根必须有明确的边界，聚合间通过 ID 引用而非对象嵌套
-- 领域事件必须由聚合根产生，跨聚合操作通过事件最终一致性
-- 值对象必须不可变（immutable），使用新的值对象表示变更
-- 仓储（Repository）只对聚合根提供存取，聚合内部实体不独立持久化
-- 领域服务只在跨聚合或需要外部资源时使用，单一聚合逻辑放在聚合根内
-
-## 验收项
-- [AC-01] CRUD 场景使用贫血模型
-- [AC-02] 跨模块交互有明确的依赖方向
-- [AC-03] Service 依赖接口而非具体实现
-- [AC-04] 事件驱动决策有文档记录
-- [AC-05] 聚合边界清晰，聚合间 ID 引用
-- [AC-06] 值对象不可变
-- [AC-07] 仓储仅对聚合根

package/templates/operate//345/217/221/345/270/203/350/257/264/346/230/216/345/256/241/346/237/245.md

@@ -1,60 +0,0 @@
----
-id: ka-rule-domain-operate-release-note-review
-kind: guidance
-title: 发布说明审查
-triggers:
-  - 发布说明
-  - changelog
-  - release note
-sync_policy: copy_to_project
-status: active
-extra:
-  updated_at: '2026-06-15'
-  lifecycle_status: active
-  name: release-note-review
-  scope:
-    - '*'
-  products:
-    - release_note
-  type: constraint
-  version: 1.0.0
-  last_reviewed: '2026-06-11'
-  domain:
-    - operate
-  verification_layer: L2
-  stage: operate
-  owner_mechanism: mc-domain-operate
----
-
-## 发布说明审查规则
-
-### 必须满足
-
-1. **发布说明必须存在**
-   - 必须包含版本号、发布日期、变更摘要
-   - 格式遵循项目既定的发布说明模版
-
-2. **破坏性变更必须明确标注**
-   - API 签名变更、数据库 schema 变更、配置格式变更等必须列为 Breaking Changes
-   - 每个破坏性变更必须附迁移指南
-
-3. **变更分类必须清晰**
-   - 新功能（Added）、修复（Fixed）、变更（Changed）、移除（Removed）、安全修复（Security）
-   - 不得将破坏性变更混在"Changed"中而不标注
-
-4. **影响范围必须说明**
-   - 受影响的用户群体（前端/后端/运维）
-   - 受影响的接口或模块列表
-
-5. **部署注意事项必须列出**
-   - 需要的数据库迁移
-   - 需要的配置变更
-   - 需要的依赖更新
-
-### 验收项
-
-- [AC-01] 发布说明文件存在且格式合规
-- [AC-02] 所有破坏性变更已标注并附迁移指南
-- [AC-03] 变更分类清晰无遗漏
-- [AC-04] 影响范围已说明
-- [AC-05] 部署注意事项已列出

package/templates/operate//350/277/220/347/273/264/350/201/232/345/220/210/346/243/200/346/237/245.md

@@ -1,22 +0,0 @@
----
-id: operate-aggregate-checks
-kind: guidance
-title: 运维聚合检查
-triggers:
-  - 运维
-  - 部署
-  - 监控
-  - 配置
-sync_policy: engine_only
-status: active
-extra:
-  type: constraint
-  scope:
-    - '*'
-  stage: operate
-  owner_mechanism: mc-stage-gate-engine
----
-
-# operate 阶段聚合检查
-
-收容无单一资产归属的 stage 级 check（如编译/测试/部署证据等）。