soloforge 1.1.2 → 1.1.31

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

@@ -1,34 +0,0 @@
----
-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

@@ -1,24 +0,0 @@
----
-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

@@ -1,36 +0,0 @@
----
-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

@@ -1,35 +0,0 @@
----
-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

@@ -1,28 +0,0 @@
----
-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

@@ -1,33 +0,0 @@
----
-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

@@ -1,31 +0,0 @@
----
-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

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

@@ -1,43 +0,0 @@
----
-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

@@ -1,27 +0,0 @@
----
-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

@@ -1,46 +0,0 @@
----
-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

@@ -1,38 +0,0 @@
----
-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

@@ -1,30 +0,0 @@
----
-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

@@ -1,24 +0,0 @@
----
-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

@@ -1,40 +0,0 @@
----
-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

@@ -1,45 +0,0 @@
----
-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

@@ -1,33 +0,0 @@
----
-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 小时内完成事故复盘

package/templates/knowledge/procedures//347/274/272/351/231/267/344/277/256/345/244/215/346/265/201/346/260/264/347/272/277.md

@@ -1,28 +0,0 @@
----
-name: bug-fix-pipeline
-type: pipeline_procedure
-when: "缺陷修复, Bug修复, 问题修复, 异常修复, 错误修复, bug fix, 缺陷处理"
-scope: [backend, frontend]
-products: ["*"]
----
-
-# 缺陷修复管线
-
-### 第1步：问题复现
-获取具体操作步骤、输入数据、环境信息。确认可稳定复现（或记录偶现条件）。确定影响范围（全部用户/特定条件，偶发/必现）。
-模板：Bug分析模版.md
-产出保存到：.soloforge/output/01-Bug分析.md
-工具：sf_classify
-
-### 第2步：根因定位
-根据日志 traceId 追踪完整请求链路，查看接口耗时和错误率。根据异常堆栈定位到具体文件和方法。区分代码 Bug/配置错误/数据异常/环境问题。一次只验证一个假设，记录所有结果包括被否定的假设。
-产出保存到：.soloforge/output/02-根因分析.md
-工具：sf_analyze
-
-### 第3步：修复实现
-编写最小修复代码，修复范围只覆盖确认的根因，禁止顺手改其他代码。使用 RED-GREEN 验证（回退修复→确认失败→恢复修复→确认通过）。添加回归测试防止同类问题再发生。
-工具：sf_expand, sf_scaffold
-
-### 第4步：验证闭环
-执行构建 + 测试验证，代码审查（质量/安全/性能），学习记录（补防御性代码或规则）。
-工具：sf_verify, sf_review, sf_learn