soloforge 1.4.16 → 2.0.0

package/templates/internal/rules//346/250/241/347/211/210Frontmatter/350/247/204/350/214/203.md

@@ -0,0 +1,301 @@
+---
+name: template-frontmatter-spec
+type: governance_rule
+scope:
+  - '*'
+owner_mechanism_id: mc-standard-asset-contract
+authority: canonical
+lifecycle_status: active
+stages: ["*"]
+triggers: ["模版文件写入、模版 frontmatter 校验、模版资产注册"]
+---
+
+# 模版 Frontmatter 规范
+
+> 权威来源：本文档定义 `templates/` 下所有 .md 文件的 frontmatter 字段合法值、必填/选填、语义。
+> 引用标准：`docs/SoloForge-工作流管线设计方案.md` 第四章（8 TaskStage）。
+
+---
+
+## 一、字段体系概览
+
+### 1.1 `type` — 消费侧分类（知识注入管线使用）
+
+**必填**。每个 .md 文件必须声明 `type`。
+
+**合法值（9 种）**：
+
+| type | 含义 | 对应目录 |
+|------|------|----------|
+| `pattern` | 编码规范/设计模式 | patterns/, internal/patterns/ |
+| `procedure` | 开发流程/工作流 | procedures/ |
+| `pipeline_procedure` | 管线级流程 | procedures/ |
+| `domain` | 领域知识 | domain/ |
+| `artifact_template` | 产出物模版 | artifacts/ |
+| `acceptance_template` | 验收交付模版 | artifacts/ |
+| `review_rule` | 审查/校验规则 | rules/ |
+| `governance_rule` | 引擎治理硬规则 | internal/rules/, gates/ |
+| `checklist` | 验收清单（打勾式） | checklists/ |
+
+**规则**：
+- `type` 决定文件在知识注入管线中的路由和过滤方式
+- **废弃的 type 值**：
+  - `hard_rule` → 使用 `governance_rule`
+  - `rule` → 使用 `governance_rule`
+  - `domain_knowledge` → 使用 `domain`
+  - `knowledge_pattern` → 使用 `pattern`
+  - `capability_knowledge_doc` → 使用 `pattern`
+  - `pipeline_rule` → 使用 `review_rule`
+  - `pipeline_artifact` → 使用 `artifact_template`
+
+### 1.2 `scope` — 技术栈适用范围
+
+**必填**。声明此资产适用的技术栈。
+
+**合法值**：
+- `backend` — 后端技术栈
+- `frontend` — 前端技术栈
+- `infrastructure` — 基础设施
+- `*` — 所有技术栈（通用）
+
+**注意**：`scope` 仅表达技术栈语义。系统类型（新系统/老系统/共用）由 `system_scope` 字段表达。
+
+### 1.4 `system_scope` — 系统类型适用范围
+
+**选填**。声明此资产适用的系统类型（新系统/老系统）。
+
+**合法值**：
+- `shared` — 两类系统共用（默认）
+- `existing-system` — 仅老系统改造
+- `new-system` — 仅新系统
+
+**默认值**：如果不声明，视为 `shared`。
+
+### 1.4 `stages` — 任务阶段
+
+**必填**。声明此资产在哪些任务阶段生效。
+
+**合法值**（以 `docs/SoloForge-工作流管线设计方案.md` 第四章 8 个 TaskStage 为权威来源）：
+
+| 阶段名 | 英文标识 | 适用系统 |
+|--------|---------|---------|
+| `需求分析` | requirement_analysis | 共用 |
+| `现有系统分析` | existing_system_analysis | 仅老系统 |
+| `架构设计` | architecture_design | 共用 |
+| `详细设计` | detailed_design | 共用 |
+| `任务规划` | slice_planning | 共用 |
+| `编码与单元测试` | coding | 共用 |
+| `代码审查` | code_review | 共用 |
+| `联调验证` | integration_verification | 共用 |
+
+**通配符 `*`**：表示所有阶段均生效。
+
+**gates/ YAML 使用的扩展阶段**（仅限 gates/ 目录内的 YAML 文件使用）：
+
+gates/ 可使用上述 8 个阶段，以及以下细粒度阶段：`交付`、`会话启动`、`决策研讨`、`编码就绪`、`验证验收`、`发布后审查`、`验收测试规划`、`试运行`、`联调缺陷`。.md 文件不允许使用这些扩展阶段。
+
+### 1.5 `triggers` — 触发关键词
+
+**选填**。触发关键词数组，用于辅助知识匹配。
+
+**格式**：字符串数组，如 `["支付", "结算", "退款"]`
+
+**注意**：同簇文件共享触发词是正常的。跨簇文件应避免使用完全相同的触发词，防止路由竞争。替代旧的 `when`（逗号分隔字符串）和 `primary_triggers`。
+
+### 1.6 `authority` — 权威性声明
+
+**选填**。默认 `supporting`。
+
+**合法值**：
+- `canonical` — 权威规则，仅在以下目录允许：
+  - `internal/rules/`（引擎硬规则）
+  - `rules/shared/`（核心审查规则，如 SOLID 代码审查规则）
+- `supporting` — 辅助参考，其他所有目录的默认值
+
+### 1.7 `products` — 产品类型适用范围
+
+**选填**。当前全部为 `['*']`（通配），产品差异化能力待后续版本启用。
+
+**合法值**：`*` | 产品类型标识（未来定义，与 `profiles/` 下的配置对齐）
+
+### 1.8 `owner_mechanism_id` — 机制归属
+
+**必填**（scaffolds/ 和 profiles/ 除外）。声明此资产属于哪个机制。
+
+**命名规范**：`mc-` 前缀 + kebab-case。示例：`mc-ood-solid-contract`。
+
+**注册要求**：新建机制 ID 需在 `docs/SoloForge-工作流管线设计方案.md` 4.4 节中登记。
+
+### 1.9 `consumes` / `emits` / `consumed_by` — 依赖链
+
+**选填**。用于追溯机制间的依赖关系。
+
+- `emits`：此资产产出什么（产物标识）
+- `consumes`：此资产依赖哪个机制产出（mechanism_id 列表）
+- `consumed_by`：此资产被哪个机制消费（mechanism_id 列表）
+- `required_evidence`：此资产需要什么证据才能执行
+
+**推断算法**：同 `owner_mechanism_id` 簇内，如果文件 A 的 `emits` 值 X 与文件 B 的 `required_evidence` 值 X 匹配，
+则 B 的 `consumes` 应包含 A 的 `owner_mechanism_id`，A 的 `consumed_by` 应包含 B 的 `owner_mechanism_id`。
+跨簇无 `required_evidence` 匹配时不填。
+
+### 1.10 `companion_rules` — 四层伴生规则
+
+**选填**（仅 artifact 模版）。声明与此模版配套的规则文件及操作类型。
+
+**格式**：`[规则文件名:usage]`，usage ∈ {`execute`, `review`, `check`}
+- `execute`：修改产物时必须遵守的执行规则
+- `review`：审查产物时必须遵守的审查规则
+- `check`：校验产物时必须执行的一致性检查规则
+
+**文件定位**：规则文件在 `templates/rules/` 下按系统类型分区查找。
+
+### 1.11 `companion_gates` — 四层伴生门禁
+
+**选填**（仅 artifact 模版）。声明与此模版配套的质量门禁文件。
+
+**格式**：gate YAML 文件名数组，如 `[gate-详细设计.yaml]`
+
+**文件定位**：门禁文件在 `templates/gates/` 下按系统类型分区查找。
+
+### 1.12 `requires_context` — 上下文引擎视图
+
+**选填**（仅 artifact 模版）。声明操作此模版前需要从上下文引擎获取的视图。
+
+**合法值**：上下文引擎已注册的视图名数组，如 `[file_impact, reference_trace]`
+
+**运行时行为**：`requires_context` 非空时，操作前触发上下文引擎调用获取指定视图数据。
+
+### 1.13 `lifecycle_status` — 生命周期状态
+
+**必填**。唯一的状态字段。
+
+**合法值**：`active` | `deprecated` | `draft`
+
+**禁止**：不允许同时存在 `status` 和 `lifecycle_status`。统一使用 `lifecycle_status`。
+
+---
+
+## 二、禁止和清理字段
+
+以下字段已废弃，不得出现在新文件中，存量文件应逐步清理：
+
+| 字段 | 原用途 | 处理方式 |
+|------|--------|---------|
+| `when` | 逗号分隔触发词字符串 | 已合并到 `triggers` 数组，全部移除 |
+| `primary_triggers` | 触发关键词列表 | 已合并到 `triggers` 数组，全部移除 |
+| `secondary_triggers` | 次要触发关键词 | 已废弃，全部移除 |
+| `negative_triggers` | 负面触发关键词 | 已废弃，全部移除 |
+| `specificity` | 优先级权重 | 已删除，全部移除 |
+| `asset_kind` | 注册侧分类 | 已统一到 `type`，全部移除 |
+| `routes` | 路由白名单 | 已由 `stages` 替代，全部移除 |
+| `status` | 与 `lifecycle_status` 语义完全重复 | 移除，保留 `lifecycle_status` |
+| `migration_note` | 迁移标记，运行时无意义 | 全部移除 |
+| `artifact_schema` | 产物结构定义 | 已迁移到 `companion_rules`，全部移除 |
+| `process_rules` | 过程规则 | 已迁移到 `companion_rules`，全部移除 |
+| `forbidden_gaps` | 禁止空洞 | 已迁移到 `companion_gates`，全部移除 |
+
+---
+
+## 三、命名规范
+
+### 3.1 文件名用字
+
+- 统一使用 `模版`（不使用 `模版`）
+- 已有文件中 `模版` 应逐步替换为 `模版`
+
+### 3.2 procedures/ 文件后缀
+
+procedures/ 目录下文件后缀按语义区分：
+
+| 后缀 | 含义 | 使用场景 |
+|------|------|---------|
+| `流程` | 标准执行流程 | 功能开发流程、调试排查流程等 |
+| `工作流` | 管线工作流 | 架构设计工作流、OOD设计工作流等由管线直接调度 |
+| `流水线` | 自动化流水线 | 安全加固流水线、迁移流水线等自动化多步骤 |
+
+---
+
+## 四、目录归属规则
+
+### 4.1 每目录对应的 type 和职责
+
+| 目录 | type 主体 | 职责 | 系统类型分区 |
+|------|----------|------|------------|
+| `patterns/` | `pattern` | 用户编码规范 | 无（通用） |
+| `procedures/` | `procedure` / `pipeline_procedure` | 开发流程 | 无（通用） |
+| `artifacts/` | `artifact_template` | 产出物模版 | shared/ + existing-system/ + new-system/ |
+| `internal/rules/` | `governance_rule` | 引擎硬规则 | 无（通用） |
+| `internal/patterns/` | `pattern` | 引擎运行时模式 | 无（通用） |
+| `rules/` | `review_rule` | 审查规则 | shared/ + existing-system/ + new-system/ |
+| `gates/` | `governance_rule`（如纳入） | 阶段门控配置 | shared/ + existing-system/ + new-system/ |
+| `domain/` | `domain` | 领域知识 | 无（通用） |
+| `checklists/` | `checklist` | 验收清单 | 无（通用） |
+| `scaffolds/` | 不适用（.hbs） | 代码脚手架 | 无 |
+| `profiles/` | 不适用（.yaml） | 产品配置 | 无 |
+
+### 4.2 验收文件归属
+
+- **打勾式验收清单**（消费者是 AI 做校验） → `checklists/`（type: `checklist`）
+- **产出物格式模版**（消费者是 AI 按模版输出制品） → `artifacts/`（type: `artifact_template`）
+- 同名主题只能二选一：如果内容是清单则放 `checklists/`，如果内容是格式模版则放 `artifacts/`
+
+### 4.3 排除范围
+
+以下目录不纳入模版资产体系（无 frontmatter、无机制注册）：
+- `scaffolds/`（22 个 .hbs 文件）— 由脚手架引擎直接消费
+- `profiles/`（3 个 .yaml 文件）— 由产品配置加载器直接消费
+
+---
+
+## 五、字段必填矩阵
+
+| 字段 | pattern | procedure | pipeline_procedure | domain | artifact_template | acceptance_template | review_rule | governance_rule | checklist |
+|------|:-------:|:---------:|:------------------:|:------:|:-----------------:|:-------------------:|:-----------:|:---------------:|:---------:|
+| `type` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| `scope` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| `stages` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| `lifecycle_status` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| `owner_mechanism_id` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| `triggers` | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
+| `system_scope` | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
+| `authority` | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
+| `products` | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
+| `consumes` | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
+| `emits` | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
+| `consumed_by` | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
+| `required_evidence` | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
+| `companion_rules` | — | — | — | — | ○ | ○ | — | — | — |
+| `companion_gates` | — | — | — | — | ○ | ○ | — | — | — |
+| `requires_context` | — | — | — | — | ○ | ○ | — | — | — |
+
+✅ = 必填　○ = 选填
+
+---
+
+## 六、合规检查规则
+
+以下规则在 `tests/architecture/template_frontmatter_compliance.test.ts` 中强制执行：
+
+| # | 规则 | 级别 | 说明 |
+|---|------|------|------|
+| 1 | `type` 必填且在 9 种合法值内 | 硬规则 | 所有 .md 文件 |
+| 2 | `scope` 值在 `backend`/`frontend`/`infrastructure`/`*` 内 | 硬规则 | |
+| 3 | `system_scope`（如有）在合法系统类型内 | 硬规则 | |
+| 4 | `stages` 是 8 个 TaskStage 之一或 `*` | 硬规则 | |
+| 5 | `authority`（如有）在 `canonical`/`supporting` 内 | 硬规则 | |
+| 6 | `lifecycle_status` 必填 | 硬规则 | 唯一状态字段，禁止与 `status` 并存 |
+| 7 | `canonical` authority 仅允许出现在 `internal/rules/` 和 `rules/shared/` | 硬规则 | |
+| 8 | `owner_mechanism_id` 必填 | 硬规则 | scaffolds/profiles 除外 |
+| 9 | frontmatter YAML 格式合规 | 硬规则 | 禁止 `]` 后直接跟字段名 |
+| 10 | `triggers`（如有）为非空字符串数组 | 硬规则 | |
+| 11 | `companion_rules`（如有）格式为 `[文件名:usage]` | 硬规则 | usage ∈ {execute, review, check} |
+| 12 | `requires_context`（如有）为合法视图名数组 | 硬规则 | 仅 artifact 模版 |
+
+新增机制 ID 的命名规范：`mc-` 前缀 + kebab-case。按目录/主题分组的常用前缀：
+- `mc-engine-runtime` — 引擎运行时模式（internal/patterns/）
+- `mc-backend-pattern` / `mc-frontend-pattern` / `mc-infra-pattern` / `mc-general-pattern` — 编码规范（patterns/）
+- `mc-domain-knowledge` — 领域知识（domain/）
+- `mc-generic-artifact` / `mc-existing-system-artifact` — 产出物模版（artifacts/）
+- `mc-generic-review` / `mc-existing-system-review` / `mc-new-system-review` — 审查规则（rules/）
+- `mc-checklist` — 验收清单（checklists/）

package/templates/internal/rules//346/250/241/347/211/210/350/265/204/344/272/247/345/217/257/350/247/201/346/200/247/350/247/204/345/210/231.md

@@ -0,0 +1,57 @@
+---
+name: template-asset-visibility
+scope:
+  - '*'
+products:
+  - '*'
+id: ka-hard-rule-模版资产可见性规则
+type: governance_rule
+lifecycle_status: active
+authority: canonical
+owner_mechanism_id: mc-template-asset-visibility
+priority: P0
+consumes:
+  - template_asset_contract_registry
+  - template_init_sync
+  - knowledge_index_manager
+hard_blocks:
+  - internal_asset_leak
+  - cross_stack_injection
+  - unregistered_asset_sync
+fallback: manual_required
+required_evidence:
+  - visibility_contract
+  - sync_manifest
+  - runtime_consumption_trace
+version: 1.1.0
+last_reviewed: '2026-06-01'
+stages: ["*"]
+---
+
+# 模版资产可见性规则
+
+## 适用范围
+
+所有 `templates/**` 资产的同步、索引、注入和消费入口。
+
+## 可见性分类
+
+| 可见性 | 说明 |
+|--------|------|
+| user_project | 用户项目知识，可同步到 `.soloforge/knowledge` |
+| soloforge_internal | SoloForge 内部治理，不进入用户项目 |
+| adapter_runtime_only | 仅 adapter 运行时消费，不进入用户知识库 |
+| scaffold_only | 仅脚手架机制消费，不进入知识索引 |
+| global_pattern | 全局工程模式，进入 `~/.soloforge/patterns` |
+
+## 硬规则
+
+- 内部资产不得同步到用户项目。
+- 不同技术栈的审查规则不得互相注入。
+- 脚手架模版只由脚手架机制消费。
+- 全局 patterns 只能作为 `template_guidance`，不得支撑项目事实。
+- 用户可见资产不得包含内部施工术语。
+
+## 术语污染扫描
+
+用户可见资产禁止出现: Batch、validate-release、SoloForge Audit: PASS、Mechanism Contract Registry 等内部术语。

package/templates/internal/rules//346/263/250/345/206/214/350/241/250/345/237/272/347/241/200/350/256/276/346/226/275/350/247/204/345/210/231.md

@@ -0,0 +1,53 @@
+---
+name: registry-infrastructure
+scope:
+  - '*'
+products:
+  - '*'
+id: ka-hard-rule-注册表基础设施规则
+lifecycle_status: active
+authority: canonical
+owner_mechanism_id: mc-registry-infrastructure
+priority: P0
+consumes:
+  - mc-all-mechanisms
+hard_blocks:
+  - contract未登记
+  - policy无映射
+fallback: manual_required
+required_evidence:
+  - contract_registry
+  - mechanism_layer_map
+version: 1.1.0
+last_reviewed: '2026-06-01'
+type: governance_rule
+stages: ["*"]
+triggers: ["注册表基础设施规则"]
+---
+
+# 注册表基础设施规则
+
+## 核心原则
+
+注册表是 SoloForge 契约体系的基础设施层。所有机制必须通过注册表发现、验证和追踪其契约和资产。
+
+## 规则
+
+1. **注册完整性**: 每个机制必须在 MechanismContractRegistry 注册，包含 id、status、priority
+2. **资产可发现**: 所有可消费模版资产必须在 ConsumableAssetRegistry 注册，包含 path、consumption_mode、owner_mechanism_id
+3. **生命周期测试**: 每个注册表条目必须有对应的生命周期测试，验证注册/查询/状态变更
+4. **跨注册表一致性**: owner_mechanism_id 必须在 DualLayerMechanismRegistry 中存在对应条目
+5. **注册表健康检查**: validate-mechanisms 和 audit-template-mechanisms 必须能检测注册表不一致
+
+## 失败模式
+
+- 注册表条目无对应测试 → 应补充 lifecycle test
+- owner_mechanism_id 指向不存在的机制 → 应修复引用
+- 模版文件存在但未注册 → 应在 ConsumableAssetRegistry 登记
+
+## 验收标准
+
+- [ ] 所有机制契约在 registry 中可查询
+- [ ] 所有模版资产有 owner_mechanism_id
+- [ ] 注册表查询函数返回非空结果
+- [ ] validate-mechanisms 不报告注册表缺失

package/templates/internal/rules//346/274/224/350/277/233/345/233/236/345/275/222/351/227/250/346/216/247/350/247/204/345/210/231.md

@@ -0,0 +1,63 @@
+---
+name: evolution-regression-gate
+scope:
+  - '*'
+products:
+  - '*'
+id: ka-hard-rule-演进回归门控规则
+type: governance_rule
+lifecycle_status: active
+authority: canonical
+owner_mechanism_id: mc-evolution-regression
+asset_role: required
+consumed_by:
+  - mc-evolution-regression
+  - consumable_asset_registry
+  - knowledge_injection
+priority: P2
+consumes:
+  - mc-evolution-regression
+hard_blocks:
+  - 重复问题未检测
+  - pending 状态通过
+  - 新 Batch 未继承回归门禁
+  - 模版层需更新但未更新
+fallback: manual_required
+required_evidence:
+  - evolution_gate_result
+  - duplicate_check_result
+  - batch_regression_report
+version: 1.1.0
+last_reviewed: '2026-06-01'
+stages: ["*"]
+---
+
+# 演进回归门控规则
+
+## hard_rules
+
+- 新增问题 / 新增 Batch / 新机制 / 新模版 / 新测试必须经过回归门控，不得打穿既有体系。
+- 必须包含以下检查项：
+  1. 跨 Batch 总回归门：新变更不得破坏已验收的 Batch 门禁。
+  2. 模版补齐检查：新机制必须有 required 模版资产。
+  3. 机制归属检查：新模版必须归属到正确机制。
+  4. 发布门禁更新：新问题/Batch 必须更新发布门禁配置。
+  5. 旧问题反向影响检查：新变更不得使已关闭问题重新失效。
+- 重复问题必须被 DuplicateIssueCheck 检测并阻断。
+- pending 状态的问题/机制不得通过门禁。
+
+## not_done_if_missing
+
+- 新问题未经 DuplicateIssueCheck → hard fail。
+- 新增功能批次未继承既有历史回归基线 → hard fail。
+- 模版层需更新但未更新 → hard fail。
+- 新增机制无 required 模版资产 → hard fail。
+- 发布门禁配置未更新 → hard fail。
+
+## verification_evidence
+
+- `EvolutionGateResult` 包含 passed/failed 状态和检查项列表。
+- `DuplicateCheckResult` 包含重复检测结果。
+- `performEvolutionGate()` 执行全部五项检查。
+- `checkDuplicateIssue()` 检测重复问题。
+- `diagnostic_codes`: duplicate-issue, pending-gate, missing-template, batch-regression-failed。

package/templates/internal/rules//347/224/250/346/210/267/345/217/215/351/246/210/345/245/221/347/272/246/350/247/204/345/210/231.md

@@ -0,0 +1,99 @@
+---
+name: user-feedback-contract
+scope:
+  - '*'
+products:
+  - '*'
+id: ka-hard-rule-用户反馈契约规则
+lifecycle_status: active
+authority: canonical
+owner_mechanism_id: mc-user-feedback
+priority: P0
+consumes:
+  - mc-task-context-lifecycle
+  - mc-first-principles
+  - mc-detail-discipline
+  - mc-evolution-regression
+hard_blocks:
+  - 反馈未响应
+  - 阻塞性信息未展示
+  - 仅按表面文件或单个场景收窄处理
+  - 未做机制族归因
+  - 未分析 SoloForge 自身与用户项目双路径影响
+  - 未分析模版层、知识层、机制层、adapter、CLI、MCP、发布门禁、迁移和防回归影响
+fallback: manual_required
+required_evidence:
+  - user_feedback_message
+  - global_abstraction_review
+  - mechanism_family_mapping
+  - cross_layer_impact_matrix
+version: 1.1.0
+last_reviewed: '2026-06-01'
+type: governance_rule
+stages: ["*"]
+triggers: ["用户反馈契约规则"]
+---
+
+# 用户反馈契约规则
+
+## 核心约束
+
+1. 每个工具只能输出其 `getAllowedFeedbackKinds` 允许的反馈类型。
+2. 反馈消息必须包含：kind、severity、title、summary。禁止空洞反馈。
+3. 技术内容（路径、命令、错误码）禁止翻译，必须保留原文。
+4. `blocked` 类型反馈必须包含阻塞原因和建议下一步。
+5. `failure` 类型反馈必须包含失败证据和 retry_hint。
+6. 任何用户反馈、缺陷、设计疑问或实际使用偏差，不得只按表面文件、单个目录或单个场景收窄处理。
+7. 进入修复讨论前，必须先完成全局抽象审查：
+   - 该问题属于哪个机制族？
+   - 是否只是某个现象暴露出来的系统性问题？
+   - 是否同时影响 SoloForge 自身与用户项目使用路径？
+   - 是否涉及模版层、知识层、机制层、adapter、CLI、MCP、发布门禁、迁移和防回归？
+   - 是否需要抽象成通用能力，而不是只修当前案例？
+8. 如果全局抽象审查未完成，只能输出待分析项、影响矩阵和建议讨论顺序，不得直接给单点修复结论。
+9. 如果当前案例只是系统性问题的一个样本，修复方案必须覆盖同类入口、同类资产、同类任务和新增资产防回归。
+
+## 适用场景
+
+- 所有 SoloForge 工具的输出反馈
+- sf_gate_check 结果反馈
+- sf_stage_advance 学习反馈
+- sf_stage_execute 降级/澄清反馈
+- 用户反馈实际使用问题
+- 讨论新增机制、模版、规则、流程、验收或发布风险
+- 将问题落入 Batch、备忘录、发布门槛或施工合同前
+
+## 违规处理
+
+- 禁止的反馈类型 → hard_fail，阻断输出
+- 空洞反馈 → advisory，标记质量降级
+- 翻译技术内容 → advisory，标记违规
+- 未做全局抽象审查就收窄为单点修复 → hard_fail，退回机制族归因
+- 只修当前文件/目录/样例但未覆盖同类路径和防回归 → hard_fail，要求补齐通用能力
+- 未分析 SoloForge 自身与用户项目双路径影响 → hard_fail，要求补齐影响矩阵
+- 未说明模版层、知识层、机制层、adapter、CLI、MCP、发布门禁、迁移和防回归影响 → hard_fail，要求补齐跨层影响
+
+## 全局抽象审查输出
+
+每次用户反馈进入讨论或施工合同前，必须形成以下结构化结论：
+
+```text
+1. 表面现象:
+2. 机制族归因:
+3. 是否系统性问题:
+4. SoloForge 自身影响:
+5. 用户项目影响:
+6. 涉及层级:
+   - 模版层:
+   - 知识层:
+   - 机制层:
+   - adapter:
+   - CLI:
+   - MCP:
+   - 发布门禁:
+   - 迁移:
+   - 防回归:
+7. 是否应抽象成通用能力:
+8. 不应只修的局部案例:
+9. 施工和验收必须覆盖的同类路径:
+```

package/templates/internal/rules//347/237/245/350/257/206/346/262/273/347/220/206/350/247/204/345/210/231.md

@@ -0,0 +1,36 @@
+---
+name: knowledge-governance
+scope:
+  - '*'
+products:
+  - '*'
+id: ka-hard-rule-知识治理规则
+type: governance_rule
+lifecycle_status: active
+authority: canonical
+owner_mechanism_id: mc-knowledge-governance
+priority: P0
+consumes:
+  - knowledge_governance_gate
+hard_blocks:
+  - promotion_without_evidence
+  - unauthorized_design_doc_fact
+  - language_policy_missing
+fallback: manual_required
+required_evidence:
+  - knowledge_governance_report
+version: 1.1.0
+last_reviewed: '2026-06-01'
+stages: ["*"]
+---
+
+# 知识治理规则
+
+知识资产从草稿、演进、同步到注入必须有统一治理入口。
+
+## 硬规则
+
+- 知识晋级必须有证据，不能由 AI 推理直接变成核心事实。
+- 中文优先项目的用户可见语义不得被英文默认模版污染。
+- 设计文档只能承载已验证事实，不能承载施工日志或未验证假设。
+- 多语言策略必须显式声明，不能用日志或 stderr 替代用户反馈。

package/templates/internal/rules//347/237/245/350/257/206/346/263/250/345/205/245/350/276/271/347/225/214/350/247/204/345/210/231.md

@@ -0,0 +1,52 @@
+---
+name: knowledge-injection-boundary
+scope:
+  - '*'
+products:
+  - '*'
+id: ka-hard-rule-知识注入边界规则
+lifecycle_status: active
+authority: canonical
+owner_mechanism_id: mc-knowledge-injection-boundary
+priority: P0
+consumes:
+  - mc-knowledge-injection-boundary
+hard_blocks:
+  - 注入越权
+  - deprecated被注入
+fallback: manual_required
+required_evidence:
+  - injection_report
+  - consumption_snapshot
+version: 1.1.0
+last_reviewed: '2026-06-01'
+type: governance_rule
+stages: ["*"]
+triggers: ["知识注入边界规则"]
+---
+
+# 知识注入边界规则
+
+## 核心原则
+
+知识注入必须经过三道门过滤: 状态门、路由门、预算门。未经审核的知识不可进入 prompt。
+
+## 三道门
+
+1. **状态门**: draft/quarantine/deprecated 知识被过滤，不进入 prompt
+2. **路由门**: 知识类型必须匹配当前路由，防止错误注入
+3. **预算门**: budget 不足时优先保留 required，supporting 可被裁剪
+
+## 规则
+
+1. consumption_mode=required 资产缺失时必须报错，不可静默降级
+2. pending_review 知识只能进入 advisory_only，不可进入 injected
+3. 所有注入结果必须生成 KnowledgeInjectionReport
+4. route 不匹配时跳过模版注入，不可强行注入
+
+## 验收标准
+
+- [ ] draft/quarantine 知识不出现在 injected 列表中
+- [ ] required 资产缺失时产生 missing_required_knowledge finding
+- [ ] KnowledgeInjectionReport 包含完整字段
+- [ ] budget 不足时 required 优先于 supporting