soloforge 1.1.42 → 1.1.44

package/templates/patterns//347/206/224/346/226/255/351/231/215/347/272/247/350/247/204/350/214/203.md

@@ -1,45 +0,0 @@
----
-name: circuit-breaker
-scope:
-  - backend
-products:
-  - '*'
-id: ka-pattern-circuit-breaker
-lifecycle_status: active
-owner_mechanism_id: mc-backend-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["编码与单元测试", "联调验证"]
-triggers: ["服务降级","熔断","限流","降级","级联故障","服务雪崩","Sentinel","Hystrix","Resilience4j","服务保护","容错"]
----
-
-## 决策规则
-- 外部依赖（第三方 API、中间件、其他微服务）必须配置超时时间，禁止无限等待
-- 核心链路的外部调用必须配置熔断器：失败率阈值（建议 50%）、熔断时长（建议 30s）、半开探测数（建议 5）
-- 熔断触发后必须有降级策略：返回缓存数据/默认值/友好提示，禁止直接抛异常给用户
-- 接口必须有限流保护（令牌桶/漏桶），防止突发流量击穿服务
-- 降级方案必须提前定义：降级行为、用户提示文案、数据一致性保障、恢复条件
-- 重试必须满足幂等性，重试间隔必须使用指数退避（initial 100ms, multiplier 2, max 3 次）
-- 线程池隔离：不同外部依赖使用独立线程池，防止一个慢服务拖垮所有请求
-- 必须有服务健康检查端点（/actuator/health），包含依赖组件状态（DB/Redis/MQ）
-- 熔断器必须配置 half-open 状态的探测请求量（如允许 5 个请求通过测试），成功后才恢复
-- 降级 fallback 必须返回有意义的默认值或缓存数据，禁止返回 null 或空对象
-- 熔断/降级事件必须触发监控告警，不能静默降级
-- 外部调用必须设置独立的超时时间（不依赖全局超时），与熔断器配合使用
-- 熔断器状态变化必须有日志记录（closed → open → half-open → closed）
-
-## 验收项
-- [AC-01] 外部调用有超时和熔断配置
-- [AC-02] 熔断后有降级策略和用户提示
-- [AC-03] 重试有指数退避和幂等保障
-- [AC-04] 有限流保护
-- [AC-05] 健康检查端点包含依赖状态
-- [AC-06] half-open 探测机制配置
-- [AC-07] fallback 返回有意义的值
-- [AC-08] 熔断事件有监控告警
-- [AC-09] 外部调用有独立超时

package/templates/patterns//347/212/266/346/200/201/346/265/201/350/275/254/350/247/204/350/214/203.md

@@ -1,41 +0,0 @@
----
-name: state-transition
-scope:
-  - backend
-products:
-  - '*'
-id: ka-pattern-state-transition
-lifecycle_status: active
-owner_mechanism_id: mc-backend-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["编码与单元测试"]
-triggers: ["状态机","状态流转","状态变更","状态转换","审批流","工单状态","订单状态","流程引擎"]
----
-
-## 决策规则
-- 仅列出状态列表不够，每个状态转换必须定义：触发条件、守卫条件、失败/回滚动作
-- 金额、库存、配额、计数器等并发敏感节点默认需要并发控制
-- 并发敏感操作必须显式声明：并发控制方式（乐观锁/悲观锁/幂等键/去重表）、重试策略、重复提交处理、用户可见失败反馈
-- 跨模块或跨服务状态变更必须显式声明最终一致性和补偿策略
-- 集成测试必须覆盖：至少一次成功转换、一次守卫失败、一次失败恢复或升级路径
-- 状态流转必须通过状态机框架（如 Spring Statemachine）或显式流转表校验，禁止硬编码 if-else
-- 每次状态变更必须记录流转日志（原状态→新状态、操作人、时间、原因）
-- 并发状态变更必须使用乐观锁或分布式锁，防止状态覆盖
-- 状态流转失败必须返回明确的错误原因，告知用户当前状态和允许的下一步操作
-- 状态定义必须包含初始状态和终态，禁止出现无法流转的"悬挂状态"
-
-## 验收项
-- [AC-01] 状态转换有触发条件、守卫条件、回滚动作
-- [AC-02] 并发敏感操作有显式并发控制声明
-- [AC-03] 跨服务状态变更有补偿策略
-- [AC-04] 集成测试覆盖成功和失败路径
-- [AC-05] 状态机校验（非硬编码）
-- [AC-06] 状态变更审计日志
-- [AC-07] 并发状态变更防护
-- [AC-08] 无悬挂状态

package/templates/patterns//347/272/246/346/235/237/345/256/236/347/216/260/350/247/204/350/214/203.md

@@ -1,45 +0,0 @@
----
-name: constrained-implementation
-scope:
-  - backend
-  - frontend
-products:
-  - '*'
-id: ka-pattern-constrained-implementation
-lifecycle_status: active
-owner_mechanism_id: mc-general-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["编码与单元测试"]
-triggers: ["编码实现","写代码","修改代码","代码变更","实现","编码","coding","代码修改","修bug","修代码"]
----
-
-## 决策规则
-- 必须在修改代码前定位根因，解释根因、修改边界和验证方式后再编码
-- 只修改任务卡/补丁计划/白名单明确范围内的文件
-- 禁止补丁叠补丁或试错式堆叠修复
-- 禁止删除断言、放宽测试、增加 sleep、让测试适应错误行为
-- 禁止顺手重构或范围外的"清理"
-- 每个代码变更必须追溯到任务卡、补丁计划或阻塞性缺陷
-- 范围超出白名单或需要变更接口/DDL/权限/菜单时，立即上报而非自行决定
-- 必须完成本地验证并产出结构化证据后再结束
-- 唯一约束必须同时在数据库和应用层校验，防止并发场景下的重复数据
-- 外键约束在微服务架构中不建议使用物理外键，应通过应用层保证数据一致性
-- 乐观锁必须使用 version 字段而非 update_time（后者可能因精度问题失效）
-- 软删除数据必须排除在唯一约束之外（如添加 is_deleted 条件索引）
-- 数据库约束的校验失败必须返回用户友好的错误消息，而非数据库原始报错
-
-## 验收项
-- [AC-01] 变更范围与白名单完全匹配
-- [AC-02] 根因已确认再编码（非先改再试）
-- [AC-03] 无顺手重构或范围外变更
-- [AC-04] 本地验证执行完毕有结果
-- [AC-05] 超范围变更已上报
-- [AC-06] 唯一约束双层校验
-- [AC-07] 乐观锁用 version 字段
-- [AC-08] 软删除与唯一约束兼容

package/templates/patterns//347/274/223/345/255/230/347/255/226/347/225/245/350/247/204/350/214/203.md

@@ -1,43 +0,0 @@
----
-name: caching
-scope:
-  - backend
-products:
-  - '*'
-id: ka-pattern-caching
-lifecycle_status: active
-owner_mechanism_id: mc-backend-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["联调验证"]
-triggers: ["缓存策略","缓存","cache","Redis","热点数据","查询优化","缓存穿透","缓存雪崩","@Cacheable","缓存一致性"]
----
-
-## 决策规则
-- 所有缓存必须设置 TTL，禁止永久缓存
-- 热点数据 TTL 必须加随机偏移防止雪崩
-- 缓存 key 格式必须统一：模块:业务:id
-- 查询不存在的数据必须缓存空值或使用布隆过滤器防止穿透
-- 写操作必须同步更新或失效缓存，保证一致性
-- 缓存重建必须使用分布式锁或 singleflight 模式，防止缓存击穿导致 DB 过载
-- 缓存值禁止存储大对象（建议 ≤ 1MB），大对象应只缓存 key 引用
-- 缓存操作必须设置超时时间，防止 Redis 阻塞拖垮业务线程
-- 禁止缓存中存储敏感信息（密码、token、身份证号），或必须加密后存储
-- 缓存命中率必须纳入监控，命中率低于阈值时触发告警
-- 本地缓存（Caffeine/Guava）与分布式缓存的数据一致性策略必须明确
-
-## 验收项
-- [AC-01] 所有缓存 key 有 TTL
-- [AC-02] 热点数据 TTL 加随机偏移
-- [AC-03] 缓存 key 格式统一
-- [AC-04] 有穿透/雪崩防护措施
-- [AC-05] 缓存重建有分布式锁保护
-- [AC-06] 缓存值不超过 1MB
-- [AC-07] 缓存操作有超时设置
-- [AC-08] 缓存中无明文敏感信息
-- [AC-09] 缓存命中率有监控告警

package/templates/patterns//347/274/226/347/240/201/350/264/250/351/207/217/350/247/204/350/214/203.md

@@ -1,44 +0,0 @@
----
-name: coding-quality
-scope:
-  - backend
-  - frontend
-products:
-  - '*'
-id: ka-pattern-coding-quality
-lifecycle_status: active
-owner_mechanism_id: mc-general-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["编码与单元测试"]
-triggers: ["编码质量","代码规范","代码评审","代码质量","重构","over-engineering","过度设计","代码异味"]
----
-
-## 决策规则
-- 50 行能解决的问题禁止写 200 行；禁止为单次使用场景过度设计
-- 每行代码变更必须可追溯到任务卡片中的显式需求，禁止"顺手"重构相邻代码
-- 实现记录必须显式声明业务入口集成状态（菜单/路由/权限）
-- Bug 修复必须针对根因，禁止在破损代码上叠加 workaround
-- 方法必须按业务步骤拆分为单一职责的私有方法
-- 新增/修改类必须文档化业务职责、边界和关键协作者
-- 仅在"非显而易见"的关键行添加注释说明 why，禁止对简单赋值加噪声注释
-- 方法长度不超过 80 行，超过时拆分为子方法
-- 方法参数不超过 5 个，超过时封装为请求对象
-- 单个类职责单一（SRP），超过 500 行的类应考虑拆分
-- 条件嵌套不超过 3 层，超过时使用卫语句、策略模式或 Optional 链重构
-- 禁止使用魔法数字，必须提取为命名常量或枚举
-
-## 验收项
-- [AC-01] 代码变更可追溯到任务需求
-- [AC-02] 业务入口集成状态已声明
-- [AC-03] Bug 修复针对根因而非 workaround
-- [AC-04] 无过度设计（50行能解决的不写200行）
-- [AC-05] 方法不超过 80 行
-- [AC-06] 参数不超过 5 个
-- [AC-07] 嵌套不超过 3 层
-- [AC-08] 无魔法数字

package/templates/patterns//347/274/272/351/231/267/347/256/241/347/220/206/350/247/204/350/214/203.md

@@ -1,43 +0,0 @@
----
-name: defect-management
-scope:
-  - backend
-  - frontend
-products:
-  - '*'
-id: ka-pattern-defect-management
-lifecycle_status: active
-owner_mechanism_id: mc-general-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["编码与单元测试", "联调验证"]
-triggers: ["缺陷管理","Bug修复","缺陷闭环","回归测试","缺陷预防","缺陷归因","质量改进"]
----
-
-## 决策规则
-- 每个缺陷必须归因到最小责任阶段（需求/设计/任务拆解/实现/测试/门禁）
-- 修复必须附带证据，"理论上修好了"不可接受
-- 有复现价值的缺陷必须产出至少一项回填动作：规则、模版、检查项或知识条目
-- 同一缺陷若在案例库中已出现过，自动升级为深层缺陷（方法论级别）
-- 报告必须在修复之前编写，禁止先改规则后写报告
-- 缺陷结论必须区分：已完成 / 未完成 / 未验证 / 未知，无真实证据不得标记为已完成
-- 缺陷必须包含完整的复现步骤、预期结果、实际结果和环境信息
-- 每个缺陷必须有优先级（P0-P4）和严重程度（S1-S4）分类
-- 修复缺陷必须包含根因分析，禁止只修表面症状
-- P0/P1 缺陷修复后必须经过回归测试，不能直接上线
-- 缺陷关闭必须由提单人确认，修复人不能自行关闭
-
-## 验收项
-- [AC-01] 缺陷有归因阶段
-- [AC-02] 修复附带执行证据
-- [AC-03] 有复现价值的缺陷有回填动作
-- [AC-04] 结论区分已完成/未完成/未验证/未知
-- [AC-05] 缺陷有完整复现信息
-- [AC-06] 有优先级和严重程度
-- [AC-07] 修复包含根因分析
-- [AC-08] 高优先级缺陷有回归测试

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

@@ -1,41 +0,0 @@
----
-name: debugging-methodology
-scope:
-  - backend
-  - frontend
-products:
-  - '*'
-id: ka-pattern-debugging-methodology
-lifecycle_status: active
-owner_mechanism_id: mc-general-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["架构设计"]
-triggers: ["调试","debug","排查问题","修复Bug","定位错误","根因分析","排障","故障排查"]
----
-
-## 决策规则
-- 一次只验证一个假设，一次只改一个变量，记录所有结果包括被否定的假设
-- 禁止从观察直接跳到修复，必须经过假设验证
-- 修复范围只覆盖确认的根因，禁止顺手改其他代码
-- 同一现象修复失败 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/patterns//350/276/223/345/205/245/346/240/241/351/252/214/350/247/204/350/214/203.md

@@ -1,42 +0,0 @@
----
-name: input-validation
-scope:
-  - backend
-products:
-  - '*'
-id: ka-pattern-input-validation
-lifecycle_status: active
-owner_mechanism_id: mc-backend-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["联调验证"]
-triggers: ["参数校验","输入验证","字段验证","合法性校验","入参校验","必填","格式校验","参数检查","@Valid","@NotNull"]
----
-
-## 决策规则
-- 必须使用 Bean Validation 注解（@NotBlank、@Size、@Min 等）声明式校验
-- 禁止手写 if-else 逐字段校验（跨字段业务规则除外）
-- 创建和更新必须使用分组校验（CreateGroup/UpdateGroup）
-- 校验失败必须返回 400 + 具体字段名和错误消息
-- 后端必须校验，禁止仅依赖前端校验
-- 数组/集合参数必须校验非空且限制最大长度（防止批量攻击）
-- 枚举类型参数必须校验是否为合法枚举值，禁止直接信任前端传入
-- 日期参数必须指定格式（@DateTimeFormat）并校验合理性（不能是未来日期等）
-- 富文本输入必须使用白名单标签过滤（如 jsoup Whitelist），禁止直接存储原始 HTML
-- 正则表达式校验必须限制输入长度和复杂度，防止 ReDoS 攻击
-- URL 参数必须校验协议白名单（仅允许 http/https），防止 SSRF
-
-## 验收项
-- [AC-01] 所有 DTO 字段有校验注解
-- [AC-02] 创建/更新使用分组校验
-- [AC-03] 校验失败返回 400 + 字段详情
-- [AC-04] 无手写 if-else 参数校验
-- [AC-05] 集合参数有长度限制
-- [AC-06] 枚举参数校验合法值
-- [AC-07] 富文本经过白名单过滤
-- [AC-08] URL 参数校验协议白名单

package/templates/patterns//351/224/231/350/257/257/345/244/204/347/220/206/350/247/204/350/214/203.md

@@ -1,44 +0,0 @@
----
-name: error-handling
-scope:
-  - backend
-products:
-  - '*'
-id: ka-pattern-error-handling
-lifecycle_status: active
-owner_mechanism_id: mc-backend-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["联调验证"]
-triggers: ["异常处理","错误处理","全局异常","错误码","Exception","BusinessException","状态码","报错","异常捕获","错误响应"]
----
-
-## 决策规则
-- 必须使用 @ControllerAdvice 全局异常处理器，禁止散落的 try-catch 吞异常
-- 业务异常必须使用自定义 BusinessException 携带错误码和消息
-- 禁止将异常堆栈信息返回给前端
-- 系统异常必须记录 ERROR 日志并返回通用提示，不暴露内部细节
-- 参数校验失败必须返回 HTTP 400
-- 每个用户可见写操作必须定义失败反馈：提示文案、重试建议、是否可恢复
-- 权限失败、校验失败、资源不存在、冲突失败、系统异常必须有区别化处理
-- 前端提示与接口错误码必须可回链，不得一个写"无权限"、一个写"操作失败"
-- 若失败后需要用户补动作（刷新、重新登录、补齐字段、稍后重试），必须写明
-- 全局异常处理器必须区分业务异常（可预期）和系统异常（不可预期），分别返回不同错误码
-- 错误响应必须包含 traceId，便于日志追踪关联
-- 前端必须对每个 API 调用做错误处理（toast/notification），禁止静默失败
-
-## 验收项
-- [AC-01] 所有异常经全局处理器返回
-- [AC-02] 业务异常返回具体错误码和消息
-- [AC-03] 系统异常不暴露堆栈给前端
-- [AC-04] 校验失败返回 400 + 字段错误详情
-- [AC-05] 用户可见写操作有失败反馈（提示+重试建议）
-- [AC-06] 前端提示与后端错误码可回链
-- [AC-07] 业务异常与系统异常分别处理
-- [AC-08] 错误响应包含 traceId
-- [AC-09] 前端 API 调用有错误提示

package/templates/patterns//351/224/231/350/257/257/350/276/271/347/225/214/350/247/204/350/214/203.md

@@ -1,36 +0,0 @@
----
-name: error-boundary
-scope:
-  - frontend
-products:
-  - '*'
-id: ka-pattern-error-boundary
-lifecycle_status: active
-owner_mechanism_id: mc-frontend-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["联调验证"]
-triggers: [">-"]
----
-
-## 决策规则
-- React 应用必须在路由级别包裹 ErrorBoundary，防止单个组件崩溃导致整个页面白屏
-- 必须提供全局未捕获异常处理（window.onerror / window.addEventListener('error')）
-- ErrorBoundary 的 fallback UI 必须包含：错误提示、重试按钮、返回首页链接
-- 异步请求错误（网络、超时、服务端）统一在 axios 拦截器处理，禁止每个组件单独 try-catch
-- Promise 未捕获 rejection 必须有全局监听（unhandledrejection event）
-- 错误信息禁止暴露技术细节给用户（堆栈、SQL、内部 IP）
-- 生产环境必须上报错误到监控服务（Sentry / 自建），禁止只在控制台打印
-- loading / error / empty 三态必须完整处理，禁止只处理成功状态
-
-## 验收项
-- [AC-01] 路由级别有 ErrorBoundary 包裹
-- [AC-02] fallback UI 有重试和返回首页
-- [AC-03] 异步错误统一在拦截器处理
-- [AC-04] loading/error/empty 三态完整
-- [AC-05] 生产错误上报到监控服务

package/templates/patterns//351/242/206/345/237/237/351/251/261/345/212/250/350/256/276/350/256/241/350/247/204/350/214/203.md

@@ -1,41 +0,0 @@
----
-name: ddd-design
-scope:
-  - backend
-products:
-  - '*'
-id: ka-pattern-ddd-design
-lifecycle_status: active
-owner_mechanism_id: mc-backend-pattern
-authority: supporting
-priority: P2
-version: 1.1.0
-last_reviewed: '2026-06-01'
-consumes: []
-emits: []
-type: pattern
-stages: ["架构设计"]
-triggers: ["领域驱动设计","DDD","领域模型","聚合根","值对象","领域事件","充血模型","贫血模型","模块设计"]
----
-
-## 决策规则
-- 简单 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/procedures/OOD/350/256/276/350/256/241/345/267/245/344/275/234/346/265/201.md

@@ -1,71 +0,0 @@
----
-name: ood-design-workflow
-type: procedure
-scope:
-  - backend
-  - frontend
-products:
-  - '*'
-id: ka-procedure-OOD设计工作流
-lifecycle_status: active
-authority: supporting
-owner_mechanism_id: mc-ood-solid-contract
-priority: P1
-consumes:
-  - mc-ood-solid-contract
-consumed_by:
-  - mc-ood-solid-contract
-  - mc-backend-implementation-contract
-emits:
-  - ood_design_summary
-required_evidence:
-  - execution_evidence
-version: 1.2.0
-last_reviewed: '2026-06-04'
-stages: ["详细设计"]
-triggers: ["面向对象设计","SOLID","领域服务","业务规则实现","重构"]
----
-
-## 适用性判定（前置门控）
-
-| 判定条件 | 适用 | 不适用 |
-|---------|------|--------|
-| 复杂对象边界（多对象协作、继承/组合关系） | ✅ | |
-| 变化点（多策略/多实现/扩展点） | ✅ | |
-| 领域服务或业务规则封装 | ✅ | |
-| 简单 CRUD 或单表操作 | | ✅ |
-| 纯 UI/样式调整 | | ✅ |
-
-不适用时：记录"不适用理由"一句话，跳过本工作流。
-
-## 步骤
-
-### Step 1: 列出对象职责与依赖
-- **属性**: LLM 推理
-- **输入**: 架构设计文档中的模块/实体定义
-- **输出**: 对象职责清单 + 依赖方向图 + 主要协作流程
-
-### Step 2: SOLID 逐项分析
-- **属性**: LLM 推理
-- **输入**: Step 1 对象职责清单
-- **输出**: SOLID 风险与取舍分析
-- **Agent 行为**: 对 S/O/L/I/D 逐项分析，每项标注风险（高/中/低）+ 取舍说明
-
-### Step 3: 修正硬失败
-- **属性**: LLM 推理 + 确定性校验混合
-- **输入**: Step 2 SOLID 分析
-- **输出**: 修正后设计 + 验证证据
-- **Agent 行为**: 高风险项必须修正；修正后重新分析对应项；最多 3 轮；低风险项可标注"已知取舍"
-
-## 输出摘要
-
-| 对象/模块 | 单一职责 | 依赖接口 | 变化点 | SOLID 风险等级 | 修正状态 | 验证证据 |
-|---|---|---|---|---|---|---|
-
-## 输出消费方式
-- 数据库设计（E-01 Step 2）和 API 设计（E-01 Step 3）引用本工作流的对象职责清单和 SOLID 分析
-- 编码后的 SOLID 审查由编码阶段代码审查流程负责，不在此工作流中
-
-## 注意事项
-- 本工作流仅在详细设计阶段执行，不跨阶段
-- 输出摘要表必须填写完整，不得留空行

package/templates/procedures/Schema/345/217/230/346/233/264/346/265/201/346/260/264/347/272/277.md

@@ -1,46 +0,0 @@
----
-name: schema-change-pipeline
-type: pipeline_procedure
-scope:
-  - backend
-products:
-  - '*'
-id: ka-procedure-Schema变更流水线
-lifecycle_status: active
-authority: supporting
-owner_mechanism_id: mc-knowledge-asset-governance
-priority: P1
-consumes:
-  - mc-knowledge-asset-governance
-emits:
-  - schema_change_plan
-  - migration_script
-  - schema_change_verification_result
-required_evidence:
-  - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
-stages: ["编码与单元测试", "联调验证"]
-triggers: ["数据库结构变更","加字段","改字段","新建表","加索引","DDL变更","schema变更","数据库迁移"]
----
-
-# 数据库变更管线
-
-## 第1步：变更设计
-评估变更类型（加列/改列/删列/加索引/数据迁移/新建表）。确认向前兼容性（新列默认值或允许 NULL）。制定四层兼容策略（数据库→接口契约→前端展示→导出逻辑）。
-模版：数据库变更方案模版.md
-产出保存到：docs/architecture/02-数据库设计文档.md
-工具：sf_command
-
-## 第2步：迁移脚本
-编写 migration 脚本（正向 + 回滚），确保幂等。大表加列使用分批更新策略。大表加索引使用 ONLINE DDL。禁止 migration 中写业务逻辑。
-产出保存到：docs/architecture/02-migration.sql
-工具：sf_stage_execute
-
-## 第3步：代码适配
-更新 Entity/DTO 映射。更新接口契约（请求/响应字段）。更新前端展示和表单。更新导出逻辑（如有）。更新相关测试数据和测试用例。
-工具：sf_stage_execute
-
-## 第4步：验证验收
-开发环境执行 migration 验证表结构。运行全量测试。代码审查重点关注：四层兼容完整性、回滚脚本有效性、大表性能影响评估。
-工具：sf_gate_check, sf_review, sf_stage_advance