soloforge 1.1.40 → 1.1.43

package/templates/internal/rules//346/236/266/346/236/204/345/206/263/347/255/226/347/240/224/350/256/250/350/247/204/345/210/231.md

@@ -1,44 +0,0 @@
----
-name: architecture-decision-workshop
-id: ka-rule-architecture-decision-workshop
-lifecycle_status: active
-authority: canonical
-scope: ['*']
-products:
-  - '*'
-priority: P0
-version: 1.1.0
-last_reviewed: '2026-06-01'
-owner_mechanism_id: mc-architecture-decision-workshop
-hard_blocks:
-  - 必要架构决策域未确认时生成正式架构设计文档
-  - 现有系统无现状与差距证据时声称架构完成
-required_evidence:
-  - architecture_decision_workshop
-  - user_confirmation_ref
-consumes:
-  - user_intent
-  - project_context_detection
-  - existing_system_analysis
-fallback: manual_required
-type: governance_rule
-stages: ["*"]
----
-
-# 架构决策研讨规则
-
-## 硬底线
-
-- 正式架构文档生成前必须覆盖业务流程、数据架构、安全架构、后端架构、前端架构、基础设施六类决策域。
-- 每个必要域必须记录事实和约束、候选方案、推荐理由、风险和用户确认引用。
-- 现有系统必须先引用现状分析和差距分析证据；空项目必须先确认目标、端范围和非功能约束。
-- 任一必要域为未开始、讨论中、待确认或返工状态时，只能输出讨论清单或明确的不可执行草案。
-- 决策变化必须将受影响设计产物标记为需要重新验证。
-
-## 低风险边界
-
-普通缺陷修复、样式或文案调整、只读解释不触发完整六域研讨；涉及契约、数据、安全、部署或重大模块边界变化时重新触发。
-- ADR-HARD-01: 每条架构决策必须有对应 ADR，禁止口头决策不留记录
-- ADR-HARD-02: ADR 状态变更必须经用户确认，Agent 不得自动变更状态
-- ADR-HARD-03: 已 Accepted 的 ADR 被推翻时，必须创建新 ADR 并标注 Superseded-By
-- ADR-HARD-04: 跳过决策研讨必须用户明确声明，Agent 不得自行跳过

package/templates/internal/rules//346/240/207/345/207/206/350/265/204/344/272/247/350/246/206/347/233/226/350/247/204/345/210/231.md

@@ -1,59 +0,0 @@
----
-name: standard-asset-override
-scope:
-  - '*'
-products:
-  - '*'
-id: ka-hard-rule-标准资产覆盖规则
-type: governance_rule
-lifecycle_status: active
-authority: canonical
-owner_mechanism_id: mc-standard-asset-coverage
-priority: P0
-consumes:
-  - template_asset_contract_registry
-  - explicit_asset_registry
-  - observed_consumption
-hard_blocks:
-  - unregistered_template_asset
-  - missing_runtime_consumer
-  - missing_revalidation_entrypoint
-fallback: manual_required
-required_evidence:
-  - asset_contract
-  - consumption_evidence
-  - validation_entrypoint
-version: 1.1.0
-last_reviewed: '2026-06-01'
-stages: ["*"]
----
-
-# 标准资产覆盖规则
-
-## 覆盖范围
-
-所有 `templates/**` 下的资产类型必须被审计覆盖：
-
-- 验收模版 (acceptance_templates)
-- 规则 (rules)
-- 流程 (procedures)
-- 检查清单 (checklists)
-- 审查规则 (review_rules)
-- 模式 (patterns)
-- 脚手架 (scaffolds)
-- Adapter 工作流 (adapter_workflow)
-
-## 覆盖检查要求
-
-每个资产必须具备：
-
-1. **标准承载路径** — 资产存放在正确的类型目录中
-2. **复验路径** — 可通过 sf_gate_check、template_mechanism_auditor 或 validate-release 复验
-3. **主链路消费者** — 被实际工具（sf_stage_execute、sf_gate_check、sf_stage_advance 等）消费
-
-## 门禁规则
-
-- P0 资产缺少标准承载路径时 hard_fail
-- P0 资产未在 Consumable Asset Registry 注册时 hard_fail
-- P0 资产缺少 owner_mechanism_id 时 hard_fail
-- `mc-design-artifact-pack` 仅作为首批 P0 子机制保留

package/templates/internal/rules//346/240/270/345/277/203/344/275/223/351/252/214/345/216/237/345/210/231.md

@@ -1,38 +0,0 @@
----
-name: core-experience-principle
-scope: ['*']
-products:
-  - '*'
-owner_mechanism_id: mc-core-experience-principle
-id: ka-hard-rule-core-experience-principle
-lifecycle_status: active
-authority: canonical
-consumes:
-  - mc-plan-proposal-gate
-priority: P0
-version: 1.1.0
-last_reviewed: '2026-06-01'
-hard_blocks:
-  - 机制未接主线
-  - 用户路径过长
-  - 假完成
-required_evidence:
-  - CoreExperiencePrincipleEvaluation
-fallback: manual_required
-type: governance_rule
-stages: ["*"]
-triggers: ["新增机制","新增模版","新增 workflow","发布门禁"]
----
-
-## 核心体验原则
-
-### 四条原则
-1. **机制强，路径短** — 机制必须接入真实主链路，用户主入口不超过一次自然语言指令或一个 CLI 命令
-2. **规则硬，体验轻** — 关键失败硬阻断，低风险任务轻量
-3. **证据足，不啰嗦** — 证据可审查，输出清晰简洁
-4. **能自动修复，不假装完成** — 失败进入 repair_reverify 或 manual_required
-
-### 禁止
-- 机制只存在于文档，不接主链路
-- 硬规则降级为 warning 后继续
-- 验证失败后标记 completed/delivered

package/templates/internal/rules//346/240/270/345/277/203/345/267/245/347/250/213/346/211/247/350/241/214/345/216/237/345/210/231.md

@@ -1,151 +0,0 @@
----
-name: core-engineering-principles
-scope:
-  - '*'
-products:
-  - '*'
-id: ka-hard-rule-核心工程执行原则
-lifecycle_status: active
-authority: canonical
-owner_mechanism_id: mc-core-engineering-principles
-priority: P0
-consumes:
-  - mc-all-mechanisms
-hard_blocks:
-  - 中文策略违反
-  - 非必要英文
-fallback: manual_required
-required_evidence:
-  - core_principles_report
-version: 1.1.0
-last_reviewed: '2026-06-01'
-type: governance_rule
-stages: ["*"]
-triggers: ["核心工程执行原则"]
----
-
-# 核心工程执行原则
-
-> 适用: 所有 code_execution / multi_stage_plan / single_artifact 路由。
-
-## 四条原则
-
-### 原则一: Think Before Coding — 编码前先思考
-
-编码前先明确问题、目标、输入、约束和不确定性。不假设、不隐藏困惑、不把模糊需求直接转成代码。
-
-**必须做到:**
-- 暴露阻塞性困惑，不假装理解
-- 区分可推断事实、假设、需要用户确认的问题
-- 只问最小阻塞问题，不把非阻塞细节抛给用户
-- 把 material 级不确定记录为 assumption，不得假装确定
-
-**硬失败条件:**
-- 缺少必要输入却开始写代码
-- 写入 scope 不明确却修改文件
-- 外部副作用权限不明确却执行命令
-- 把未知事实写成确定结论
-- 隐藏需要用户确认的业务口径
-
-**不确定性分级:**
-- `blocking`: 不问不能继续（写入路径、业务口径、外部副作用授权、破坏性操作）
-- `material`: 可先推进，但必须记录假设和风险（UI 文案偏好、非关键默认配置）
-- `minor`: 可合理默认，但在结果里说明（文件命名细节、无风险排序偏好）
-- `non_blocking`: 不打断用户，不影响当前执行
-
-### 原则二: Simplicity First — 简单优先
-
-优先用最少代码、最少抽象、最少新增文件解决已确认目标。不为了未确认的未来需求提前设计复杂结构。
-
-**必须做到:**
-- 最少代码解决问题
-- 引入新抽象、新依赖、新模块时说明必要性
-- 不为简单 CRUD 强行套复杂领域模型
-
-**硬失败条件:**
-- 为局部问题引入无必要新依赖
-- 为简单修复新增大范围架构层
-- 没有用户目标支撑却扩展公共 API/配置/registry
-- 使用复杂方案绕过已有简单本地模式
-
-**不是"少做":**
-- 不写测试不叫简单
-- 不接主链路不叫简单
-- 不处理边界不叫简单
-- 不做必要错误处理不叫简单
-- 不建必要抽象不叫简单
-
-**minimum_sufficient_solution 必须满足:**
-- 满足用户目标
-- 接入真实路径
-- 覆盖关键失败路径
-- 有验证证据
-- 没有不必要抽象/依赖/公共 API 扩张
-
-### 原则三: Surgical Changes — 精准修改
-
-只改必须改的内容，不顺便重构、不无关格式化、不扩大 scope、不污染用户已有改动。
-
-**必须做到:**
-- 只改必要文件、必要行、必要行为
-- 遇到用户已有修改时必须保护，不得回滚
-
-**硬失败条件:**
-- 修改 scope 外文件
-- 修改与目标无关的文件或行为
-- 未经确认回滚用户已有改动
-- 大范围格式化掩盖真实变更
-- 为了让测试过而删除断言、降低覆盖率、增加无关 mock
-
-**允许的必要联动修改:**
-- 主链路接入必须修改入口文件
-- 类型变化必须修改调用方
-- schema 变化必须修改 model/query/API
-- 验证失败需要修改测试或 fixture
-- contract 状态变化必须修改 registry、diagnostic、verification 和相关测试
-
-### 原则四: Goal-Driven Execution — 目标驱动执行
-
-先定义可验证目标，再执行；执行后必须验证；验证失败要修复并重新验证，直到通过或明确阻塞。
-
-**必须做到:**
-- 明确目标和验收标准
-- 禁止"功能正常""看起来没问题"等模糊成功标准；必须写出已执行验证和剩余风险
-- 输出未验证项和人工确认项
-
-**硬失败条件:**
-- 没有可验证目标就开始实现
-- 没有 VerificationPlan 就标记完成
-- 未执行验证却输出"全部通过"
-- 验证失败仍进入 completed / delivery_ready
-- 隐藏未验证项
-
-## 原则冲突优先级
-
-```text
-安全/权限/隐私 > Goal-Driven Execution > Think Before Coding > Surgical Changes > Simplicity First
-```
-
-裁决规则:
-- 不能为了简单而牺牲验证
-- 不能为了少改而不接入主链路
-- 不能为了快而隐藏阻塞性不确定性
-- 必要验证、必要入口接入、必要错误处理优先于"少写代码"
-
-## 反规避规则
-
-四原则必须由证据证明，不接受 AI 自述。
-
-伪满足示例:
-- 写一句"已思考清楚"，但没有输入、假设、目标证据
-- 说"保持简单"，但实际新增大抽象
-- 说"只改必要文件"，但 diff 里有无关变更
-- 说"验证通过"，但没有真实 evidence
-- 把未执行验证写成"建议验证"后仍标记完成
-- 把用户没确认的业务口径写成事实
-
-硬规则:
-- 自述不能代替 ClarificationNeed / AssumptionRecord / GoalDefinition / VerificationEvidence
-- required 原则失败不能进入 completed
-- 验证失败必须进入 repair_reverify 或 manual_required
-- 不能用 advisory 结果覆盖 required 失败

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

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

@@ -1,57 +0,0 @@
----
-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 等内部术语。