soloforge 1.0.0

package/templates/knowledge/domain//346/224/257/344/273/230/350/247/204/345/210/231.md

@@ -0,0 +1,38 @@
+---
+name: payment-rules
+type: domain
+when: 支付, 支付流程, 支付宝, 微信支付, 退款, 交易, 结算, 订单支付, 充值, 提现
+scope: [backend]
+products: ["*"]
+---
+
+## 业务规则
+- 支付操作必须幂等：同一笔订单不可重复扣款，支付回调必须做幂等校验（支付流水号唯一约束）
+- 支付状态必须明确：待支付→支付中→支付成功→支付失败→已关闭，不可跳跃
+- 金额计算禁止使用浮点数，必须使用 BigDecimal 或整数分（1 元 = 100 分）
+- 退款金额不得超过实付金额，部分退款累计不得超过实付金额
+- 支付超时未支付订单必须自动关闭（建议 30 分钟），释放库存等占用资源
+- 对账机制：每日定时与第三方支付平台对账，差异记录必须有告警和人工处理流程
+- 支付金额必须校验精度（使用 BigDecimal，禁止 float/double），防止精度丢失
+- 支付状态必须通过主动查询支付网关确认，不能只依赖回调通知
+- 退款必须支持部分退款和全额退款，退款总额不能超过支付总额
+
+## 约束条件
+- 支付密钥必须加密存储，禁止明文配置
+- 支付回调接口必须验证签名，禁止无签名校验直接处理
+- 支付流水表独立于业务表，禁止与订单表耦合
+- 支付敏感操作必须有审计日志（操作人、时间、金额、状态变更）
+- 支付操作必须记录完整流水（请求、响应、回调），便于对账和纠纷处理
+- 支付超时时间必须与支付网关一致（如 30 分钟），超时自动关闭订单
+- 同一笔支付必须防止重复扣款（幂等性），使用支付流水号去重
+
+## 例外情况
+- 测试环境使用沙箱支付，禁止真实交易
+- 充值卡/优惠券抵扣不走第三方支付，但走相同的金额计算和审计规则
+- 银行卡支付可能延迟到账（T+1），需要异步确认最终状态
+
+## 关联模式
+- [[concurrency-control]] 并发扣款控制
+- [[transaction-pattern]] 支付事务保障
+- crud-operation
+- concurrency

package/templates/knowledge/domain//346/225/260/346/215/256/346/235/203/351/231/220.md

@@ -0,0 +1,34 @@
+---
+name: data-permission
+type: domain
+when: 数据权限, 行级权限, 数据隔离, 数据范围, 部门权限, 数据可见性, 数据过滤
+scope: [backend]
+products: ["*"]
+---
+
+## 业务规则
+1. 用户只能查看其权限范围内的数据（按部门、区域、业务线等维度隔离）
+2. 数据权限在功能权限之上叠加，即使用户有功能权限，也受数据范围约束
+3. 数据权限变更实时生效（非缓存延迟）
+4. 管理员可查看全部数据，但仍需审计记录
+5. 数据权限必须支持多维度控制：组织架构（部门/区域）、数据范围（本人/本部门/本部门及下级/全部）
+6. 数据权限过滤必须在 Repository/Mapper 层实现，禁止在 Service 层硬编码过滤条件
+7. 数据权限变更必须实时生效，不能要求用户重新登录
+
+## 约束条件
+- 数据权限规则存储在数据权限表中（user_id → scope_type + scope_value）
+- MyBatis 拦截器根据当前用户自动注入数据范围过滤条件
+- 新建业务表需考虑数据权限字段（如 dept_id、region_id）
+- 数据权限查询性能需优化（大批量数据过滤使用 JOIN 而非 IN）
+- 数据权限必须与角色解耦，一个角色可配置不同的数据范围
+- 管理员（超管）可以查看全部数据，但仍需记录访问日志
+
+## 例外情况
+- 系统级数据（字典、配置）不受数据权限约束
+- 跨部门协作场景需额外的数据共享授权机制
+- 公共数据（如数据字典、系统配置）不受数据权限控制
+
+## 关联模式
+参见 auth-permission 模式（功能权限模型）、multi-tenancy 模式（租户级数据隔离）
+- auth-permission
+- naming-convention

package/templates/knowledge/domain//351/200/232/347/224/250/346/234/272/346/242/260/346/235/241/346/254/276.md

@@ -0,0 +1,24 @@
+---
+name: mechanical-clauses
+type: domain
+when: 幂等, 乐观锁, 软删除, 硬删除, 级联, 可恢复删除, 补偿, 并发控制, 删除策略
+scope: [backend]
+products: ["*"]
+---
+
+## 常见机械条款
+
+| 条款 | 含义 | 适用场景 |
+|------|------|---------|
+| 幂等 | 同一请求多次执行结果一致 | PUT/DELETE 接口、支付回调 |
+| 乐观锁 | 基于版本号的并发控制 | 编辑保存、状态流转 |
+| 软删除 | 标记删除而非物理删除 | 有审计要求的数据 |
+| 硬删除 | 物理移除数据，不再保留主记录 | 临时数据、可重建数据 |
+| 级联 | 主记录变更自动传递到子记录 | 主从表同步、状态联动 |
+| 可恢复删除 | 删除后可在一定窗口内恢复 | 回收站、误删保护 |
+| 补偿 | 正向操作失败时执行反向操作 | 分布式事务、saga 模式 |
+
+## 使用规则
+- 需求中出现上述条款时必须明确其在本项目中的具体实现语义
+- 不得假设"大家都懂"，必须在需求澄清阶段确认
+- 机械条款的选择属于裁决（团队决策），不属于需求事实

package/templates/knowledge/domain//351/200/232/347/237/245/350/247/204/345/210/231.md

@@ -0,0 +1,36 @@
+---
+name: notification-rules
+type: domain
+when: 通知规则, 消息推送, 消息模板, 站内信, 通知, 提醒, 消息中心, 推送, 邮件通知
+scope: [backend, frontend]
+products: ["*"]
+---
+
+## 业务规则
+1. 通知通过消息模板 + 规则引擎触发，不在业务代码中硬编码通知内容
+2. 每种通知类型有独立的开关和渠道配置（站内信/邮件/短信/钉钉）
+3. 通知必须包含：触发时间、触发人、事件类型、事件详情、操作链接
+4. 通知支持已读/未读状态，未读通知聚合展示
+5. 通知频率限制：同类通知 24 小时内最多发送 3 次（防骚扰）
+6. 通知必须支持多渠道（站内信、邮件、短信、企业微信/钉钉），用户可配置偏好
+7. 通知必须支持优先级（紧急/普通/低），紧急通知强制推送所有渠道
+8. 相同内容的通知必须有合并/去重策略（如 5 分钟内相同类型不重复推送）
+
+## 约束条件
+- 消息模板使用变量占位符（如 `${userName} 提交了 ${orderNo} 订单`）
+- 通知发送失败需重试（最多 3 次），并记录发送状态
+- 站内信存储在独立表中，定期清理超过 90 天的已读通知
+- 前端通过轮询或 WebSocket 获取未读通知数量
+- 通知发送失败必须有重试机制（最多 3 次，退避间隔）
+- 短信/邮件发送必须有频率限制，防止骚扰用户
+- 通知模板必须通过配置管理，禁止硬编码文案
+
+## 例外情况
+- 系统级通知（安全告警、服务异常）不受频率限制
+- 紧急通知（如审批超时提醒）可通过短信/电话直接推送
+- 系统维护通知可以绕过用户偏好设置，强制推送
+
+## 关联模式
+参见 scheduled-task 模式（定时检查触发通知）、logging 模式（通知发送日志）
+- event-driven
+- error-handling

package/templates/knowledge/procedures/Figma/344/272/244/344/273/230/346/265/201/347/250/213.md

@@ -0,0 +1,35 @@
+---
+name: figma-to-delivery
+type: pipeline_procedure
+when: "用户提供需求文档和Figma原型链接"
+scope: [backend, frontend]
+products: ["*"]
+---
+
+# Figma 需求到交付
+
+### 第1步：原型抓取
+逐页抓取 Figma 原型界面，提取每个页面的布局结构、组件数据绑定、交互流转和边界异常。对每个页面独立输出原型说明。
+模板：原型说明模版.md
+产出保存到：.soloforge/output/01-原型说明.md
+工具：figma
+
+### 第2步：架构设计
+根据原型说明和需求文档，设计系统模块划分、数据流向、技术选型与依据、风险点与应对方案。
+产出保存到：.soloforge/output/02-架构设计.md
+
+### 第3步：详细设计
+根据架构设计产出，展开模块内部逻辑：状态机定义、异常处理策略、并发与缓存方案。
+产出保存到：.soloforge/output/03-详细设计.md
+
+### 第4步：接口设计
+设计 API 路径、请求/响应结构、错误码、鉴权方案。后端和前端的接口契约在此确定。
+产出保存到：.soloforge/output/04-接口设计.md
+
+### 第5步：编码实现
+根据接口设计和详细设计产出，进行前后端编码实现。可使用脚手架生成骨架代码。
+工具：sf_scaffold, sf_expand
+
+### 第6步：测试与审查验收
+执行自动验证（构建 + 测试）、代码审查（质量/安全/性能/架构/技术债务五维度）、学习记录。
+工具：sf_verify, sf_review, sf_learn

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

@@ -0,0 +1,28 @@
+---
+name: schema-change-pipeline
+type: pipeline_procedure
+when: "数据库结构变更, 加字段, 改字段, 新建表, 加索引, DDL变更, schema变更, 数据库迁移"
+scope: [backend]
+products: ["*"]
+---
+
+# 数据库变更管线
+
+### 第1步：变更设计
+评估变更类型（加列/改列/删列/加索引/数据迁移/新建表）。确认向前兼容性（新列默认值或允许 NULL）。制定四层兼容策略（数据库→接口契约→前端展示→导出逻辑）。
+模板：数据库变更方案模版.md
+产出保存到：.soloforge/output/01-变更方案.md
+工具：sf_classify
+
+### 第2步：迁移脚本
+编写 migration 脚本（正向 + 回滚），确保幂等。大表加列使用分批更新策略。大表加索引使用 ONLINE DDL。禁止 migration 中写业务逻辑。
+产出保存到：.soloforge/output/02-migration.sql
+工具：sf_expand
+
+### 第3步：代码适配
+更新 Entity/DTO 映射。更新接口契约（请求/响应字段）。更新前端展示和表单。更新导出逻辑（如有）。更新相关测试数据和测试用例。
+工具：sf_expand
+
+### 第4步：验证验收
+开发环境执行 migration 验证表结构。运行全量测试。代码审查重点关注：四层兼容完整性、回滚脚本有效性、大表性能影响评估。
+工具：sf_verify, sf_review, sf_learn

package/templates/knowledge/procedures//344/273/243/347/240/201/351/227/250/347/246/201/346/265/201/347/250/213.md

@@ -0,0 +1,33 @@
+---
+name: code-gate
+type: procedure
+when: 代码门禁, 代码审查门禁, gate review, 发布门禁, 上线检查, 代码评审, 发布审查
+scope: [backend, frontend]
+products: ["*"]
+---
+
+## 适用场景
+代码变更的最终门禁审查，确保每行变更可追溯、有真实运行证据、符合项目约束和架构红线。
+
+## 步骤
+1. 确认存在真实 diff 和真实测试证据，无证据不启动审查
+2. 先运行预检查和快照链验证，识别缺口后再下结论
+3. 逐行审查 diff：每行必须追溯到任务卡、交付蓝图、实现映射或阻塞性缺陷
+4. 无关变更、顺手重构、主动抽象、无任务依据的删除默认为阻断
+5. 验证集成证据：部署结果、服务就绪、API 动态验证、DDL 迁移、运行时证据
+6. 拒绝以下类型作为通过证据：dry-run、skipped、not_run、静态分析、AI 摘要、生成截图
+7. 产出三级结论之一：通过 / 有条件通过（附改进清单）/ 不通过（附返回阶段路由）
+8. 审查方与实现方分歧时记录 DISPUTE，按角色层级仲裁
+
+## 检查点
+- [ ] 每个 diff 行追溯到任务卡或缺陷
+- [ ] 无 dry-run/静态分析/AI 摘要冒充运行时证据
+- [ ] 部署、就绪、API、DDL、运行时、流程覆盖均有证据
+- [ ] 每个发现项有唯一返回路由和修复权限
+- [ ] 无关变更和顺手重构已被阻断
+
+## 注意事项
+- 禁止接受 dry-run/静态分析/AI 摘要/生成截图作为运行时证据
+- 禁止在缺少运行时证据时通过
+- 禁止先下结论再找理由（先查缺口再判断）
+- draft 状态的桥接/快照/边车文件为阻断项

package/templates/knowledge/procedures//344/273/273/345/212/241/346/213/206/350/247/243/346/265/201/347/250/213.md

@@ -0,0 +1,31 @@
+---
+name: task-breakdown
+type: procedure
+when: 任务拆解, 工作分解, task breakdown, 任务拆分, 任务规划, 工单, 工作拆分
+scope: [backend, frontend]
+products: ["*"]
+---
+
+## 适用场景
+将设计产物转化为可执行的任务卡片，包含明确范围、验收标准和测试映射。适用于编码前的任务规划阶段。
+
+## 步骤
+1. 确定工单模式：skip（跳过）/ mini（简化）/ full（完整），基于变更类型和风险等级
+2. 先产出交付蓝图：目标、冲突、推荐方案、确认状态、验收标准、3 轮重试策略
+3. 生成任务卡片：每张卡有明确成功标准、上游引用、验收映射和测试映射
+4. DDL 独立为前置任务；多服务按服务拆分；单接口/页面可合并为一张可验证卡
+5. 控制实现上下文：必须读/可选读/默认不读列表，引用上游路径而非复制全文
+6. 验证可追溯性：每张任务卡追溯到需求、接口和设计锚点
+
+## 检查点
+- [ ] 工单模式匹配风险等级和变更类型
+- [ ] 每张任务卡有可验证的成功标准（非"让它工作"）
+- [ ] 任务卡追溯到需求和设计锚点，无孤立任务
+- [ ] DDL 独立为前置任务
+- [ ] 外部系统/大表 DDL/数据迁移/权限安全标记为高风险
+
+## 注意事项
+- 禁止复制上游全文到工单中（引用路径）
+- 禁止只拆后端不拆前端和集成
+- 禁止模糊成功标准如"功能正常"
+- 自动修复循环上限 3 轮

package/templates/knowledge/procedures//345/212/237/350/203/275/345/274/200/345/217/221/346/265/201/347/250/213.md

@@ -0,0 +1,37 @@
+---
+name: feature-development
+type: procedure
+when: 新功能开发, 需求实现, feature, 新增功能, 需求开发, 功能实现, 新建功能
+scope: [backend, frontend]
+products: ["*"]
+---
+
+## 适用场景
+从需求到上线的完整功能开发流程。适用于需要前后端协作的中等及以上复杂度功能。
+
+## 步骤
+1. 需求澄清：确认功能边界、验收标准、影响范围
+2. 技术方案设计：确定接口契约（API 定义）、数据模型、技术选型
+3. 前后端对齐：API 文档/接口契约评审，确认字段和状态流转
+4. 后端开发：按 crud-operation / api-pagination 等模式实现，先写接口再写逻辑
+5. 前端开发：按 react-component / react-api-integration 等模式实现页面和接口对接
+6. 单元测试：Service 层核心逻辑 + 前端关键组件
+7. 联调测试：前后端联调，验证完整流程
+8. 代码审查：使用 sf_review 检查质量/安全/性能
+9. 提测：部署到测试环境，执行验收标准
+10. 修复反馈问题后准备发布
+
+## 检查点
+- [ ] API 接口契约已对齐并文档化
+- [ ] 后端接口有 Swagger/OpenAPI 文档
+- [ ] 核心逻辑有单元测试覆盖
+- [ ] 前后端联调通过
+
+## 注意事项
+- 接口契约先于实现（避免前端等后端）
+- 复杂功能拆分为多个子任务并行开发
+- 每个子任务完成后及时联调，不要全部完成后才联调
+- 编码前确认交付蓝图状态，敏感领域（金额算法/状态流转/审批规则/跨系统同步）需用户确认
+- 通过交付蓝图的必须读/可选读/默认不读列表控制上下文，禁止默认读取全部上游文档
+- 修复限于同一限界上下文可继续；跨越无关模块必须返回任务拆解
+- 变更映射必须覆盖所有改动，unmapped_changes 不允许非零

package/templates/knowledge/procedures//345/256/211/345/205/250/345/212/240/345/233/272/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,43 @@
+---
+name: security-hardening-pipeline
+type: pipeline_procedure
+when: "安全加固, 安全审计, 安全修复, 漏洞修复, 合规整改, 安全检查, 安全增强"
+scope: [backend, frontend]
+products: ["*"]
+---
+
+# 安全加固管线
+
+### 第1步：安全审计
+扫描现有代码和配置的安全漏洞（OWASP Top 10 维度）。检查认证授权机制的完整性。检查数据加密和脱敏策略。检查第三方依赖的已知漏洞。
+模板：安全审计模版.md
+产出保存到：.soloforge/output/01-安全审计.md
+工具：sf_classify, sf_analyze
+
+### 第2步：方案设计
+按风险等级（Critical/High/Medium/Low）排序修复优先级。针对每个漏洞设计修复方案。评估修复对现有功能的影响。确定合规要求（数据加密/审计日志/访问控制）。
+产出保存到：.soloforge/output/02-修复方案.md
+
+### 第3步：安全修复
+按优先级逐个修复安全漏洞。每个修复后回归验证功能无影响。禁止降级安全等级来通过测试。
+工具：sf_expand
+
+### 第4步：验证验收
+重新扫描确认漏洞已修复。代码审查专注安全维度。学习记录（漏洞类型、修复模式、预防规则）。
+工具：sf_verify, sf_review, sf_learn
+
+### 第5步：深度安全扫描
+运行依赖漏洞扫描（npm audit / OWASP Dependency-Check），高危漏洞阻断构建。运行容器镜像扫描（Trivy / Snyk），检测基础镜像已知漏洞。检查生产环境配置（禁用 debug 模式、关闭 actuator 暴露端点、验证 HTTPS 强制）。
+
+## 检查点
+- [ ] 漏洞扫描报告已输出
+- [ ] 修复方案已评审
+- [ ] 验收扫描无高危漏洞
+- [ ] 依赖漏洞扫描无高危漏洞
+- [ ] 容器镜像扫描通过
+- [ ] 生产配置安全检查通过
+
+## 注意事项
+- 修复前必须评估对现有功能的影响，尤其是认证授权模块
+- 漏洞修复优先级：Critical > High > Medium > Low，Critical/High 必须在上线前修复
+- 误报的漏洞必须记录到白名单并定期复核

package/templates/knowledge/procedures//346/200/247/350/203/275/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,27 @@
+---
+name: performance-pipeline
+type: pipeline_procedure
+when: "性能优化, 慢查询, 内存泄漏, 首屏优化, 性能问题, 响应慢, 超时优化, 性能调优"
+scope: [backend, frontend]
+products: ["*"]
+---
+
+# 性能优化管线
+
+### 第1步：性能定位
+量化性能指标（当前值/目标值）。定位瓶颈（慢查询/内存/CPU/网络/前端渲染）。收集证据（APM/慢查询日志/浏览器 DevTools/压测数据）。确定优化优先级（收益/成本排序）。
+模板：性能分析模版.md
+产出保存到：.soloforge/output/01-性能分析.md
+工具：sf_classify, sf_analyze
+
+### 第2步：方案设计
+针对瓶颈设计优化方案（索引优化/SQL 重写/缓存/连接池/异步/分页/懒加载）。评估方案影响范围和风险。确定可衡量的优化目标。
+产出保存到：.soloforge/output/02-优化方案.md
+
+### 第3步：优化实施
+按优先级逐步实施，每步优化后重新测量性能指标。禁止一次改多处再测量。保持优化前后功能行为一致。
+工具：sf_expand
+
+### 第4步：效果验证
+对比优化前后的性能指标。全量测试确认无功能回归。代码审查关注：优化是否引入新问题、缓存一致性、并发安全。
+工具：sf_verify, sf_review, sf_learn

package/templates/knowledge/procedures//346/216/245/345/217/243/351/233/206/346/210/220/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,46 @@
+---
+name: api-integration-pipeline
+type: pipeline_procedure
+when: "第三方接口对接, 外部服务集成, API集成, 接口联调, 服务对接, 第三方API"
+scope: [backend, frontend]
+products: ["*"]
+---
+
+# 接口对接管线
+
+### 第1步：契约分析
+梳理第三方 API 能力清单（认证方式、请求/响应格式、错误码、限流配额、沙箱环境）。识别核心交互场景和数据映射关系。
+模板：接口对接方案模版.md
+产出保存到：.soloforge/output/01-接口对接方案.md
+工具：sf_classify
+
+### 第2步：适配层实现
+实现统一的 API 客户端封装（超时、重试、熔断、日志）。定义请求/响应 DTO 映射。配置 Mock 方案（沙箱/本地 Mock）支持独立开发。错误码映射为业务异常。
+工具：sf_expand, sf_scaffold
+
+### 第3步：联调测试
+使用 Mock 环境验证基本流程。切换到沙箱环境验证真实交互。覆盖：正常流程、网络超时、服务端错误、限流响应、数据格式异常。
+模板：测试计划模版.md
+工具：sf_verify
+
+### 第4步：验收上线
+代码审查重点：超时配置、错误处理、敏感信息、日志脱敏。生产配置确认（URL、密钥、限流参数）。监控告警配置（调用成功率、响应时间）。
+工具：sf_review, sf_verify, sf_deliver
+
+### 第5步：契约管理与监控增强
+定义接口契约（OpenAPI/Swagger），明确请求/响应格式、错误码、版本号。编写接口 Mock 服务，前后端并行开发。接口变更必须更新文档并通知消费方，给予充足迁移时间。集成测试覆盖正常流 + 异常流（超时、错误响应、边界值）。接口上线后配置监控告警（响应时间 P99、错误率、调用量）。
+
+## 检查点
+- [ ] 第三方 API 能力清单已梳理
+- [ ] 适配层超时/重试/熔断已配置
+- [ ] 沙箱联调通过
+- [ ] 接口文档与实现一致
+- [ ] Mock 服务可用
+- [ ] 集成测试覆盖异常场景
+- [ ] 接口监控告警已配置
+
+## 注意事项
+- 第三方接口必须有降级方案（Mock/缓存/默认值），避免外部故障拖垮主流程
+- 外部接口调用必须设置超时（连接超时 + 读超时），禁止无限等待
+- 接口重试必须有退避策略和最大重试次数限制
+- 敏感数据传输必须加密（HTTPS + 敏感字段加密）

package/templates/knowledge/procedures//346/225/260/346/215/256/345/272/223/350/277/201/347/247/273/346/265/201/347/250/213.md

@@ -0,0 +1,38 @@
+---
+name: database-migration
+type: procedure
+when: 数据库变更, 表结构修改, migration, DDL, 加字段, 建表, 索引, 数据迁移, 表结构变更
+scope: [backend]
+products: ["*"]
+---
+
+## 适用场景
+数据库表结构变更（新增表、加字段、改字段、加索引、数据迁移等）。所有 DDL 变更必须通过 migration 脚本管理，禁止手动执行。
+
+## 步骤
+1. 评估变更类型：加列、改列、删列、加索引、数据迁移、新建表
+2. 确认向前兼容性：新列必须有默认值或允许 NULL，不删除正在使用的列
+3. 编写 migration 脚本（Flyway/MyBatis Migrations），DDL 脚本放 resources/db，文件名 V{version}__{description}.sql（正向）和 U{version}__{description}.sql（回滚）
+4. 确保 migration 脚本幂等（重复执行不出错）
+5. 编写回滚脚本（每个 migration 必须有对应的 rollback）
+6. 禁止在 migration 脚本中写业务逻辑（业务变更走应用代码）
+7. 大表加列必须指定默认值或使用分批更新
+8. 在开发环境执行 migration，验证表结构变更正确
+9. 检查数据迁移逻辑：大数据量迁移需分批执行（每批 1000 条）
+10. 在测试环境验证：运行应用 + 执行全量测试
+11. 评估执行时间：大表加索引可能锁表，需在低峰期执行
+12. 生产执行前备份数据库（全量或变更表）
+
+## 检查点
+- [ ] migration 脚本有对应回滚脚本
+- [ ] migration 脚本幂等（可重复执行）
+- [ ] 新增列有默认值或允许 NULL（向前兼容）
+- [ ] migration 脚本无业务逻辑
+- [ ] 大数据量迁移使用分批策略
+- [ ] 生产执行前已完成数据库备份
+
+## 注意事项
+- 禁止使用 DROP COLUMN（应标记为 deprecated 后续清理）
+- 加索引在 >100 万行表上使用 ONLINE DDL 或 pt-online-schema-change
+- migration 脚本一旦执行到生产不可修改（只能新增补偿脚本）
+- 字段兼容策略必须同时覆盖四层：数据库、接口契约、前端展示、导出逻辑

package/templates/knowledge/procedures//346/236/266/346/236/204/350/256/276/350/256/241/346/265/201/347/250/213.md

@@ -0,0 +1,30 @@
+---
+name: architecture-design
+type: procedure
+when: 架构设计, 模块划分, 系统设计, 技术方案, 方案设计, architecture, 架构评审
+scope: [backend, frontend]
+products: ["*"]
+---
+
+## 适用场景
+从需求基线产出模块边界、状态机、一致性策略和架构红线。适用于技术方案设计阶段。
+
+## 步骤
+1. 确认需求基线已冻结
+2. 回答四个根本问题（顺序不可跳过）：边界 → 状态 → 一致性 → 扩展点
+3. 记录每个决策的理由、可逆性评估和下游影响
+4. 模型选择：简单 CRUD 不强行套用 DDD，复杂状态/一致性问题不伪装为简单 CRUD
+5. 冻结授权边界、外部依赖弹性和关键时序
+6. 运行架构健康检查：循环依赖、实体泄漏、硬编码地址、包结构
+
+## 检查点
+- [ ] 四个根本问题（边界/状态/一致性/扩展点）已回答
+- [ ] 每个决策有理由、可逆性、下游影响
+- [ ] 简单 CRUD 未被过度设计
+- [ ] 授权边界和外部依赖策略已冻结
+- [ ] 架构健康检查无循环依赖、实体泄漏
+
+## 注意事项
+- 禁止未回答四个根本问题就开始细化
+- 禁止简单 CRUD 强行套用复杂领域模型
+- 决策必须包含可逆性和返工触发条件

package/templates/knowledge/procedures//346/246/202/345/277/265/351/252/214/350/257/201/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,24 @@
+---
+name: poc-pipeline
+type: pipeline_procedure
+when: "技术验证, POC, 可行性验证, 技术选型, 技术调研, 原型验证, spike"
+scope: [backend, frontend]
+products: ["*"]
+---
+
+# 技术验证管线
+
+### 第1步：调研分析
+明确验证目标和成功标准。调研候选方案的生态成熟度、社区活跃度、性能基准、与现有技术栈兼容性。列出关键评估维度和权重。
+产出保存到：.soloforge/output/01-调研报告.md
+工具：sf_classify
+
+### 第2步：原型实现
+选择 1-2 个最有前景的方案实现最小原型。原型聚焦核心验证点，不追求完整功能。记录实现过程中的关键发现（坑、限制、惊喜）。
+工具：sf_expand, sf_scaffold
+
+### 第3步：评估结论
+对比各方案在关键维度的表现（附量化数据）。给出推荐方案和理由。列出遗留风险和后续关注点。明确结论：推荐采用/需进一步验证/不建议采用。
+模板：POC结论模版.md
+产出保存到：.soloforge/output/03-POC结论.md
+工具：sf_verify, sf_learn

package/templates/knowledge/procedures//347/237/245/350/257/206/347/273/264/346/212/244/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,40 @@
+---
+name: knowledge-maintenance-pipeline
+type: pipeline_procedure
+when: "知识维护, 知识更新, 知识审计, 新增知识, 知识库维护, SoloForge维护"
+scope: [backend, frontend]
+products: ["*"]
+---
+
+# 知识维护管线
+
+### 第1步：知识审计
+扫描现有知识库，识别过时条目（长期未被匹配/引用）、重复条目、缺失覆盖的领域。检查知识文件格式一致性。对比设计文档与实际实现的偏差。
+工具：sf_knowledge_audit
+
+### 第2步：知识新增
+根据审计结果和 sf_learn 积累的高频问题，生成新知识条目草稿。草稿保存到 .soloforge/knowledge/drafts/ 目录，人工 review 后移入正式目录。
+工具：sf_knowledge_add
+
+### 第3步：知识更新
+更新已有条目的决策边界、when 触发词、验收项。同步更新设计文档中对应的描述。标记废弃条目（不删除，标记 deprecated）。
+工具：sf_knowledge_update
+
+### 第4步：一致性验证
+重新构建知识索引，验证新增/更新条目可被正确匹配。运行全量测试确认无功能影响。更新设计文档中的知识规模统计。
+工具：sf_verify, sf_learn
+
+### 第5步：定期审计与质量控制
+定期审计知识库（每月），检查过期/重复/不准确的条目。新增知识条目必须经过 review 后才发布（草稿 → 审核 → 正式）。知识条目使用统计数据纳入监控，低使用率条目评估是否保留。知识条目格式必须符合规约（字段顺序、body 标题、when 风格），使用 sf_knowledge_audit 检查。
+
+## 检查点
+- [ ] 知识库审计执行完毕
+- [ ] 新增/更新条目索引验证通过
+- [ ] 新条目经过 review
+- [ ] 低使用率条目已评估
+- [ ] 格式规约检查通过
+
+## 注意事项
+- 废弃条目标记为 deprecated 而非直接删除，保留历史参考
+- 知识条目应保持精简（决策规则 ≤ 20 条），过长难以匹配和阅读
+- 知识条目变更应记录变更历史（更新原因、时间）

package/templates/knowledge/procedures//347/264/247/346/200/245/344/277/256/345/244/215/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,45 @@
+---
+name: hotfix-pipeline
+type: pipeline_procedure
+when: "线上故障紧急修复, 生产事故处理, P0紧急修复, 线上报错紧急处理, hotfix"
+scope: [backend, frontend]
+products: ["*"]
+---
+
+# 紧急修复管线
+
+### 第1步：故障定位
+确认问题影响范围和严重程度，通知相关干系人。评估止血方案（配置回滚/功能开关关闭/服务降级/版本回滚），执行止血操作。
+产出保存到：.soloforge/output/01-故障定位.md
+工具：sf_classify, sf_analyze
+
+### 第2步：最小修复
+从 main/release 分支拉取 hotfix 分支。编写最小修复代码（仅修复问题，不重构不优化），快速验证修复场景 + 回归核心功能。
+工具：sf_expand, sf_verify
+
+### 第3步：验证部署
+合并到 main 和 release 分支，打 hotfix tag。部署到生产环境，验证修复效果，监控 30 分钟。
+工具：sf_verify, sf_deliver
+
+### 第4步：故障复盘
+编写事故复盘（根因、影响范围、修复过程、暴露的监控盲区、后续改进项）。与 sf_learn 配合形成闭环。
+模板：故障复盘模版.md
+产出保存到：.soloforge/output/04-故障复盘.md
+工具：sf_learn
+
+### 第5步：验证与闭环
+确认修复影响范围，评估是否需要数据修复脚本。修复代码必须包含回归测试，防止相同问题复现。修复后执行冒烟测试验证关键路径。修复上线后持续观察 1 小时监控，确认无副作用。修复完成后编写故障复盘（根因、影响、修复、预防措施）。
+
+## 检查点
+- [ ] 故障已止血，影响范围已控制
+- [ ] 修复代码已合并并部署
+- [ ] 影响范围已评估
+- [ ] 修复包含回归测试
+- [ ] 冒烟测试通过
+- [ ] 故障复盘已编写
+
+## 注意事项
+- 止血优先于根因修复，先恢复服务再排查问题
+- 紧急修复可以简化流程但不能跳过测试
+- 修复后必须补齐完整测试用例和文档
+- 同一问题重复出现必须升级处理（架构级修复）

package/templates/knowledge/procedures//347/264/247/346/200/245/344/277/256/345/244/215/346/265/201/347/250/213.md

@@ -0,0 +1,33 @@
+---
+name: hotfix-procedure
+type: procedure
+when: 紧急修复, hotfix, 线上问题修复, 生产事故, 线上报错, 紧急上线, 线上故障, P0, P1, 事故修复
+scope: [backend, frontend]
+products: ["*"]
+---
+
+## 适用场景
+生产环境出现紧急故障（P0/P1），需要跳过常规流程快速修复。核心原则：先止血再治本。
+
+## 步骤
+1. 确认问题影响范围和严重程度，通知相关干系人
+2. 评估止血方案：配置回滚 / 功能开关关闭 / 服务降级 / 版本回滚
+3. 执行止血操作，确认影响消除或缩小
+4. 从 main/release 分支拉取 hotfix 分支
+5. 编写最小修复代码（仅修复问题，不重构不优化）
+6. 快速验证：修复场景 + 回归核心功能（可缩减测试范围）
+7. 合并到 main 和 release 分支，打 hotfix tag
+8. 部署到生产环境
+9. 验证修复效果，监控 30 分钟
+10. 编写事故复盘（根因、影响、修复、预防措施）
+
+## 检查点
+- [ ] 止血操作已执行且生效
+- [ ] 修复代码仅包含问题修复，无附带变更
+- [ ] 核心功能回归通过
+- [ ] 事故复盘已记录
+
+## 注意事项
+- hotfix 分支必须同时合并回 main（防止下次发版丢失修复）
+- 优先考虑回滚而非修复（回滚风险更低）
+- 修复后 24 小时内完成事故复盘