@dommaker/harness 0.16.9 → 0.17.1

package/src/core/constraints/definitions/guidelines.ts

@@ -1,193 +1,45 @@
 /**
- * 约束定义拆分文件（工单 20）：原 definitions.ts 按层拆分，
- * definitions.ts 保持原路径做薄聚合（studio rule-scanner 契约）。
+ * check · guideline 定义（ADR-0001：kind 二元模型）
+ *
+ * 只保留带真实 checker 的指导原则。每条必须：
+ * - kind: 'check'
+ * - level: 'guideline'
+ * - 在 checkers/ 注册表中有对应实现（注册表闭环，缺失即加载期抛错）
  */
 
 import type { Constraint } from '../../../types/constraint';
 
-// ========================================
-// GUIDELINES（指导原则）
-// 
-// 定义：优先建议，有例外，违背发警告但不阻止
-// ========================================
-
 export const GUIDELINES: Record<string, Constraint> = {
   /**
-   * 高风险改动优先使用 worktree
-   * 原因：隔离工作区，安全回滚，并行开发
-   * 来源：Superpowers prefer_worktree
-   */
-  prefer_worktree: {
-    id: 'prefer_worktree',
-    rule: 'USE WORKTREE FOR HIGH-RISK CHANGES',
-    message: '高风险改动应在 worktree 中进行',
-    level: 'guideline',
-    trigger: ['code_implementation'],
-    enforcement: 'check-worktree',
-    description: `高风险改动应在隔离的 worktree 中进行。
-
-【何时需要 worktree】
-- 新功能开发（新增模块/API）
-- 跨模块改动（>3 文件）
-- 基础设施变更（CI/CD、依赖）
-
-【何时不需要】
-- 配置文件修改
-- 单文件 bug fix
-- 外科手术式修复（typo、missing import）
-
-【原因】
-- 隔离风险：worktree 中的改动不会影响主工作区
-- 安全回滚：删除 worktree 即可放弃改动
-- 并行开发：多个任务可同时在不同 worktree 中进行`,
-    promptInjection: '高风险改动（新功能、跨模块、基础设施）应在 worktree 中进行。配置修改、单文件 fix 可直接编辑。',
-  },
-
-  /**
-   * 禁止无调查修复 bug
-   * 例外：简单 typo、配置错误
-   */
-  no_fix_without_root_cause: {
-    id: 'no_fix_without_root_cause',
-    rule: 'NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST',
-    message: '复杂 bug 必须先调查根本原因',
-    level: 'guideline',
-    trigger: 'code_implementation',
-    enforcement: 'debug-systematic',
-    description: `在尝试修复 bug 之前，按复杂度区分调查要求：
-
-[复杂 bug - 必须系统性调查]
-- 业务逻辑错误（需追踪数据流）
-- 状态不一致（需分析状态变化链）
-- 性能问题（需定位瓶颈）
-- 多模块联动问题（需分析调用链）
-
-[简单 bug - 快速确认即可]
-- typo/拼写错误
-- 配置值错误
-- 缺少必要配置
-
-[禁止]
-- 没有任何调查就直接猜测修复
-- 看到 error 就直接 try-catch 掩盖`,
-    exceptions: ['simple_typo', 'config_value_error', 'missing_config'],
-    promptInjection: '修复问题时必须先定位根因。不绕过问题、不遮掩症状、不用临时方案代替根本修复。在分析文档中记录根因分析过程。',
-  },
-
-  /**
-   * 业务逻辑代码必须先写测试
-   * 例外：配置文件、类型定义
+   * 禁止硬编码凭证
+   * 原因：密码/token/密钥泄露是最严重的安全漏洞，一旦提交到版本控制即不可逆
    */
-  no_code_without_test: {
-    id: 'no_code_without_test',
-    rule: 'PRODUCTION LOGIC CODE MUST HAVE TESTS FIRST',
-    message: '业务逻辑代码必须先写测试',
+  no_hardcoded_credentials: {
+    id: 'no_hardcoded_credentials',
+    kind: 'check',
+    rule: 'NO HARDCODED PASSWORDS, TOKENS, SECRETS, OR CREDENTIALS IN ANY SOURCE FILE',
+    message: '禁止在代码/文档/配置文件中硬编码密码、token、密钥、API key',
     level: 'guideline',
-    trigger: 'code_implementation',
-    enforcement: 'tdd-cycle',
-    description: `在编写代码时，按类型区分测试要求：
-
-[必须先写测试]
-- 业务逻辑代码（算法、计算、数据处理）
-- 工具函数（可复用的独立函数）
-- API 接口（输入输出验证）
-- 核心组件（影响系统行为的组件）
-
-[不强制测试]
-- 配置文件（config、env）
-- 类型定义文件（.d.ts、interface）
-- 简单 getter/setter
-- 纯展示 UI 组件（无交互逻辑）`,
-    exceptions: ['config_file', 'type_definition', 'simple_accessor', 'pure_display_component'],
-    promptInjection: '新代码必须同时编写测试。实现功能前先写测试用例（RED），然后实现让测试通过（GREEN）。不得提交无测试覆盖的实现代码。',
+    trigger: ['code_implementation', 'doc_update', 'config_change', 'commit'],
+    enforcement: 'credential-scan',
+    description: `凭证（密码/token/密钥/API key）必须从环境变量或加密配置读取，严禁以明文形式出现在任何源代码文件中。包括但不限于：源码、Markdown 文档、YAML/JSON 配置、脚本文件。模板文件（.example/.sample/.template）允许占位符但不得包含真实值。建议配合 pre-commit hook 做自动扫描。`,
+    promptInjection: '禁止在代码中硬编码密码、API 密钥、Token 等凭证。使用环境变量或安全的凭证管理方案存储敏感信息。',
   },
 
   /**
-   * 避免 any 类型
-   * 例外：JSON.parse、第三方库无类型
+   * 禁止跳过检查点验证
+   * 原因：安全底线，检查点是质量门控
    */
-  no_any_type: {
-    id: 'no_any_type',
-    rule: 'AVOID ANY TYPE, USE UNKNOWN OR SPECIFIC TYPES',
-    message: '避免 any 类型',
+  no_bypass_checkpoint: {
+    id: 'no_bypass_checkpoint',
+    kind: 'check',
+    rule: 'NO BYPASSING CHECKPOINTS',
+    message: '禁止跳过检查点验证',
     level: 'guideline',
     trigger: 'code_implementation',
-    enforcement: 'type-safe',
-    description: `TypeScript 代码中应避免使用 any 类型：
-
-[推荐做法]
-- 使用 unknown + 类型守卫
-- 使用具体类型定义
-- 使用泛型约束
-
-[允许例外] 但需添加注释说明
-- JSON.parse/JSON.stringify 结果
-- 第三方库无类型定义
-- 迁移遗留代码临时使用`,
-    exceptions: ['json_parse_result', 'third_party_no_types', 'legacy_migration'],
-    promptInjection: '禁止使用 TypeScript any 类型。使用具体类型、泛型或 unknown 代替。any 绕过类型检查带来运行时风险。',
-  },
-
-  /**
-   * 简单方案优先
-   * 例外：扩展性、安全性、性能需求
-   */
-  simplest_solution_first: {
-    id: 'simplest_solution_first',
-    rule: 'CHECK LOCAL/SIMPLE OPTIONS BEFORE REMOTE/COMPLEX',
-    message: '先检查本地/简单方案',
-    level: 'guideline',
-    trigger: ['code_implementation', 'module_extension'],
-    enforcement: 'check-local-first',
-    description: `在实现功能时，必须按顺序检查：
-1) 是否有本地数据源（内存/文件）？
-2) 是否有更简单的方案（更少依赖/更少代码）？
-3) 如需远程查询/复杂架构，必须说明理由。
-
-例外情况（可跳过简单方案）：
-- scalability_required: 需要多实例/分布式部署
-- security_required: 需要加密/鉴权等安全措施
-- performance_required: 本地方案性能不足
-- reliability_required: 需要持久化/高可用`,
-    exceptions: ['scalability_required', 'security_required', 'performance_required', 'reliability_required'],
-    promptInjection: '简单至上：仅用最少代码解决问题。不添加"以防万一"的冗余功能。不为仅用一次的代码强行设计抽象。自检：资深工程师是否会认为此实现过度复杂？若是，立即简化。',
-    injectPrompt: true,
-  },
-
-  /**
-   * 复用检查优先
-   * 例外：紧急修复、hotfix、安全补丁
-   */
-  no_creation_without_reuse_check: {
-    id: 'no_creation_without_reuse_check',
-    rule: 'NO NEW CAPABILITIES WITHOUT REUSE CHECK FIRST',
-    message: '创建新能力前必须检查复用',
-    level: 'guideline',
-    trigger: [
-      'module_creation',
-      'module_creation',
-      'module_creation',
-      'module_creation',
-      'module_extension',
-      'code_implementation',
-    ],
-    enforcement: 'reuse-first',
-    description: `在创建新能力之前，必须先执行复用检查：
-
-1. 查询现有能力索引
-2. 检查是否有功能相似的能力
-3. 评估是否可以复用或扩展
-4. 记录复用检查结果
-
-复用优先级：
-1. 直接复用现有能力
-2. 扩展现有能力
-3. 组合多个现有能力
-4. 创建新能力
-
-例外情况下可跳过，但必须记录跳过原因。`,
-    exceptions: ['emergency_fix', 'hotfix', 'security_patch'],
-    promptInjection: '创建新模块/文件前，先检查项目中是否已有类似实现可以复用。优先扩展现有模块，避免引入重复代码和功能。',
+    enforcement: 'checkpoint-required',
+    description: '所有检查点必须通过，不能跳过验证步骤。检查点是质量的最后一道防线。',
+    promptInjection: '每个关键步骤后有 checkpoint 验证点，必须通过才能继续。通过标准：测试通过、类型检查无错误、lint 无新增警告。未通过时回退修复，不得跳过。',
   },
 
   /**
@@ -196,6 +48,7 @@ export const GUIDELINES: Record<string, Constraint> = {
    */
   capability_sync: {
     id: 'capability_sync',
+    kind: 'check',
     rule: 'CODE CHANGES MUST UPDATE CAPABILITIES.MD',
     message: '核心模块变更必须同步功能清单（支持模块级目录条目登记）',
     level: 'guideline',
@@ -218,152 +71,13 @@ export const GUIDELINES: Record<string, Constraint> = {
     exceptions: ['internal_refactor', 'bug_fix_only', 'performance_optimization'],
   },
 
-  /**
-   * 禁止砍功能
-   * 例外：冗余代码清理
-   */
-  no_simplification_without_approval: {
-    id: 'no_simplification_without_approval',
-    rule: 'NO SIMPLIFYING LOGIC WITHOUT USER APPROVAL',
-    message: '禁止砍功能，合理重构除外',
-    level: 'guideline',
-    trigger: 'code_implementation',
-    enforcement: 'preserve-complexity',
-    description: `在实现或修改代码时，区分简化类型：
-
-[禁止] 必须向用户说明并获取批准
-- 为了赶进度砍掉必要功能
-- 为了省事跳过边界条件处理
-- 为了简化逻辑牺牲用户体验
-
-[允许] 合理优化，不需要批准
-- 发现冗余代码后的重构优化
-- 用更简洁的实现达到相同效果
-- 删除不再使用的遗留代码`,
-    exceptions: ['redundant_code_cleanup', 'same_effect_refactor', 'unused_code_removal'],
-    promptInjection: '不得擅自简化或删除测试、lint 规则、类型检查或约束。如需降低检查标准，必须先提案并获明确批准。',
-  },
-
-  /**
-   * 技能需要测试
-   * 例外：MVP
-   */
-  no_skill_without_test: {
-    id: 'no_skill_without_test',
-    rule: 'NO SKILL WITHOUT A FAILING TEST FIRST',
-    message: '创建技能前必须先定义测试场景',
-    level: 'guideline',
-    trigger: 'module_creation',
-    enforcement: 'skill-test-scenario',
-    description: `在创建新的 agent 技能之前，必须先定义测试场景：
-
-1. 定义输入/输出期望
-2. 定义边界条件
-3. 定义失败场景
-4. 编写测试用例
-
-测试场景帮助：
-- 明确技能的功能边界
-- 验证技能的正确性
-- 防止回归`,
-    promptInjection: '新创建的 Skill 模块必须有对应的测试文件。测试应覆盖正常路径、边界情况和错误处理。',
-  },
-
-  /**
-   * 测试覆盖率要求
-   * 例外：遗留代码
-   */
-  test_coverage_required: {
-    id: 'test_coverage_required',
-    rule: 'TEST COVERAGE MUST MEET REQUIREMENTS',
-    message: '测试覆盖率必须达到要求',
-    level: 'guideline',
-    trigger: 'code_implementation',
-    enforcement: 'check-coverage',
-    description: `在提交代码前，测试覆盖率必须达到项目要求（默认 80%）。
-
-检查命令：
-- npm run test:coverage
-- 查看覆盖率报告
-
-提升覆盖率：
-- 为未覆盖的分支添加测试
-- 为边界条件添加测试`,
-  },
-
-  /**
-   * 设计决策需先讨论
-   * 例外：明确指令、紧急修复、已有设计文档
-   */
-  design_decision_requires_discussion: {
-    id: 'design_decision_requires_discussion',
-    rule: 'DESIGN DECISIONS MUST BE DISCUSSED BEFORE IMPLEMENTATION',
-    message: '设计决策类任务需先讨论方案再实现',
-    level: 'guideline',
-    trigger: ['design_request', 'architecture_change', 'code_implementation'],
-    enforcement: 'require-discussion',
-    description: `当用户问"怎么实现"、"设计方案"时，应先：
-
-1. 提供方案选项（至少 2 个）
-   - 方案 A: ...（优点/缺点）
-   - 方案 B: ...（优点/缺点）
-
-2. 说明推荐方案和理由
-
-3. 让用户选择或确认
-
-4. 用户确认后再实现
-
-[判断标准]
-- 用户问"怎么实现"、"如何设计" → 设计决策
-- 用户说"帮我做 xxx" → 执行任务
-
-[例外]
-- 用户明确说"直接做"、"不用问"
-- 紧急修复
-- 已有明确设计文档`,
-    exceptions: ['explicit_instruction', 'emergency_fix', 'existing_design'],
-    promptInjection: '涉及架构变更、新增依赖、API 设计等重大决策时，必须先提出讨论获得确认，再开始实现。不要凭单方面判断做架构决策。',
-  },
-
-  /**
-   * 覆盖率不能下降
-   * 例外：删除测试、重构核心逻辑
-   */
-  no_coverage_decrease: {
-    id: 'no_coverage_decrease',
-    rule: 'COVERAGE MUST NOT DECREASE ON NEW COMMITS',
-    message: '新提交不能降低测试覆盖率',
-    level: 'guideline',
-    trigger: 'commit',
-    enforcement: 'coverage-gate',
-    description: `每次提交代码时，测试覆盖率不能低于上一次提交：
-
-[检查方式]
-- Git pre-commit hook 运行覆盖率检查
-- GitHub Actions 在 PR 时验证
-- 对比上一次覆盖率报告
-
-[阈值要求]
-- Statements ≥ 85%
-- Branches ≥ 75%
-- Functions ≥ 80%
-- Lines ≥ 85%
-
-[例外]
-- 删除废弃功能
-- 重构核心逻辑（需评审）
-- 紧急修复（需后续补测）`,
-    exceptions: ['deprecated_removal', 'core_refactor_with_review', 'emergency_fix_pending_test'],
-    promptInjection: '代码覆盖率不得下降。新增代码必须有对应的测试覆盖。运行 npm test -- --coverage 验证覆盖率。',
-  },
-
   /**
    * 关键目录需要 CONTEXT.md
    * 例外：临时目录、测试目录、生成代码目录
    */
   context_doc_sync: {
     id: 'context_doc_sync',
+    kind: 'check',
     rule: 'KEY DIRECTORIES SHOULD HAVE CONTEXT.MD',
     message: '关键目录缺少 CONTEXT.md，运行 harness sync-docs 创建模板后填写实际内容',
     level: 'guideline',
@@ -385,286 +99,4 @@ export const GUIDELINES: Record<string, Constraint> = {
 - 生成代码目录（dist、build、generated）`,
     exceptions: ['temp_dir', 'test_dir', 'generated_code'],
   },
-
-  /**
-   * 文档应与代码同步
-   * 例外：WIP 分支、实验性修改
-   */
-  /**
-   * 禁止借口模式
-   * 例外：已有明确修复计划
-   * 来源：Superpowers 借口防御表
-   */
-  no_excuse_patterns: {
-    id: 'no_excuse_patterns',
-    rule: 'NO EXCUSE PATTERNS WITHOUT CONCRETE ACTION PLAN',
-    message: '禁止借口模式，必须给出具体行动计划',
-    level: 'guideline',
-    trigger: ['code_implementation'],
-    enforcement: 'excuse-check',
-    description: `遇到困难时，禁止使用借口搪塞，必须给出具体的解决计划。
-
-【禁止借口】
-- "稍后修复" → 没有具体时间
-- "小问题" → 没有影响评估
-- "不影响功能" → 没有证据
-- "以后再说" → 没有计划
-- "先这样" → 没有后续步骤
-- "临时方案" → 没有正式方案时间表
-
-【必须】
-- 说明问题的具体影响
-- 给出修复的时间点或版本
-- 如果是临时方案，说明正式方案的计划
-
-【例外】
-- 已有明确的修复计划（issue 编号 + 排期）`,
-    promptInjection: '遇到困难时，禁止使用借口搪塞（稍后修复、小问题、不影响功能、以后再说、先这样、临时方案）。必须给出：① 问题的具体影响；② 修复的时间点或版本；③ 如果是临时方案，说明正式方案的计划。',
-    exceptions: ['has_concrete_plan'],
-  },
-
-  /**
-   * YAGNI 检查：禁止过度设计
-   * 例外：已有明确扩展需求、多平台支持、安全强相关抽象
-   * 来源：Superpowers yagni_check
-   */
-  yagni_check: {
-    id: 'yagni_check',
-    rule: 'NO SPECULATIVE GENERALIZATION WITHOUT CONCRETE USE CASE',
-    message: '禁止过度设计，遵循 YAGNI 原则',
-    level: 'guideline',
-    trigger: ['code_implementation', 'design_request'],
-    enforcement: 'yagni-check',
-    description: `遵循 YAGNI 原则（You Aren't Gonna Need It），不要为"未来可能需要"的需求添加代码。
-
-【过度设计信号】
-- 只有一个实现者的抽象（interface/abstract class 只有一个 class 实现）
-- "以后可能会用到"的参数或配置项
-- 为"未来扩展"预留的插件系统
-- 超过当前需求的泛型化
-
-【允许】
-- 明确在 Spec/Roadmap 中规划的扩展
-- 多个平台/环境需要不同实现
-- 安全强相关的抽象（如加密算法可替换）
-
-【判断标准】
-如果一个抽象只有一个实现者 → 删除这个抽象`,
-    promptInjection: '遵循 YAGNI 原则（You Aren\'t Gonna Need It）。不要为"未来可能需要"的需求添加抽象层、接口、配置项或插件系统。如果一个 interface/abstract class 只有一个实现者，删除这个抽象。只实现当前明确需要的功能。',
-    exceptions: ['planned_extension', 'multi_platform', 'security_abstraction'],
-  },
-
-  /**
-   * 禁止无验证完成声明
-   * 原因：口头声明"done"与实际情况不符，需要可复现的证据
-   */
-  no_claim_without_evidence: {
-    id: 'no_claim_without_evidence',
-    rule: 'NO "DONE" CLAIM WITHOUT VERIFIABLE EVIDENCE',
-    message: '禁止无验证的完成声明，必须提供可复现的验证证据',
-    level: 'guideline',
-    trigger: ['code_implementation', 'file_deletion', 'module_modification'],
-    enforcement: 'evidence-check',
-    description: `声称任何任务"完成"前，必须提供验证证据：
-【代码完成】提供 test 输出（如 "142 passed, 0 failed"）
-【文件删除】提供 ls 确认（如 "ls pkg/ → No such file"）
-【Spec 完成】提供逐 AC 对照表（每项 pass/fail）
-【文档更新】提供 grep 确认（如 "grep '遗留' CLAUDE.md → no match"）`,
-    promptInjection: '声称任务"完成"前，必须提供可复现的验证证据：test 输出数字、ls 文件确认、grep 文档确认、spec AC 逐项对照。禁止"我记得""之前说""大部分"等无验证声明。',
-  },
-
-  /**
-   * 禁止无上下文删除
-   * 原因：删除代码前应评估是否有可吸收的功能，避免丢弃有用设计
-   */
-  no_delete_without_context: {
-    id: 'no_delete_without_context',
-    rule: 'NO DELETION WITHOUT DESIGN DOCUMENT REVIEW',
-    message: '禁止删除代码前未审查设计文档和吸收价值',
-    level: 'guideline',
-    trigger: ['file_deletion', 'module_deletion'],
-    enforcement: 'context-check',
-    description: `删除任何代码（包/模块/文件）前，必须：
-1. 查设计文档（CLAUDE.md / roadmap / specs）
-2. 分析是否有可吸收的功能
-3. 查替代函数是否丢失了关键设计模式（零引用≠无价值）
-4. 分类：未接线（应接线）/ 被替代但有可吸收设计 / 真正无用
-5. 记录分析结论（有/无吸收价值，原因）`,
-    promptInjection: '删除任何代码前，先查设计意图（JSDoc/commit/spec），分析被替代的函数是否有丢失的关键模式。零引用≠无价值。分类：未接线→接线，被替代→吸收模式，真正无用→才删。',
-  },
-
-  /**
-   * 外科手术式修改 — Mnilax Rule 3
-   * 原因：只改必要部分，不顺手改相邻代码
-   */
-  surgical_changes_only: {
-    id: 'surgical_changes_only',
-    rule: 'ONLY CHANGE WHAT IS ABSOLUTELY NECESSARY',
-    message: '只改必要部分，不顺手改相邻代码和格式',
-    level: 'guideline',
-    trigger: ['code_implementation', 'file_modification'],
-    enforcement: 'surgical-check',
-    description: `仅改动绝对必要的部分。不"顺手优化"相邻代码、注释或排版格式。未出问题的代码不重构。严格贴合项目既有风格。`,
-    promptInjection: '外科手术式修改：仅改动绝对必要的部分。不顺手"优化"相邻代码、注释或格式。未出问题的代码不重构。',
-    injectPrompt: true,
-  },
-
-  /**
-   * 模型只做判断 — Mnilax Rule 5
-   * 原因：路由/重试/状态码用代码比 LLM 可靠
-   */
-  no_model_for_deterministic: {
-    id: 'no_model_for_deterministic',
-    rule: 'USE MODEL ONLY FOR JUDGMENT CALLS, NOT DETERMINISTIC LOGIC',
-    message: '路由/重试/状态码处理→代码，不要调 LLM 决策',
-    level: 'guideline',
-    trigger: ['code_implementation'],
-    enforcement: 'deterministic-check',
-    description: `仅将模型用于需要判断与裁量的场景：分类、内容起草、摘要、信息提取。切勿将模型用于：路由分发、重试机制、状态码处理、确定性数据转换。若常规代码能给出答案，就由代码处理。`,
-    promptInjection: '模型只做判断不做决策：路由、重试、状态码处理→用代码，不调 LLM。若常规代码能给出答案，就由代码处理。',
-    injectPrompt: true,
-  },
-
-  /**
-   * 暴露冲突 — Mnilax Rule 7
-   * 原因：两种模式冲突时不要折中
-   */
-  no_conflict_blending: {
-    id: 'no_conflict_blending',
-    rule: 'SURFACE CONFLICTS, DO NOT BLEND THEM',
-    message: '两种模式冲突→选其一+说明理由，不折中',
-    level: 'guideline',
-    trigger: ['code_implementation', 'module_extension'],
-    enforcement: 'conflict-check',
-    description: `若代码库中既有的两种模式相互矛盾，明确选择其一（优先更新或更经测试的版本），阐明选择理由，将另一种标记为待清理项。试图同时迎合两套规则的中庸代码往往是最糟的。`,
-    promptInjection: '暴露冲突不折中：若两种模式冲突→选其一（优先更经测试的版本）+说明理由+标记另一种为待清理。',
-    injectPrompt: true,
-  },
-
-  /**
-   * 先读后写 — Mnilax Rule 8
-   * 原因：加代码前必须理解上下文
-   */
-  read_before_write: {
-    id: 'read_before_write',
-    rule: 'READ IMPORTS AND CALLERS BEFORE ADDING CODE',
-    message: '加代码前先读文件的导入、调用方、工具函数',
-    level: 'guideline',
-    trigger: ['code_implementation', 'file_modification'],
-    enforcement: 'read-check',
-    description: `在文件中添加代码前，必须通读该文件的导出接口、直接调用方以及任何显而易见的公共工具函数。"看似互不干涉"是最危险的判断。若不理解现有代码为何采用当前结构，在动手添加前必须先提问确认。`,
-    promptInjection: '先读后写：加代码前读 imports/callers/工具函数。"看似互不干涉"是最危险的判断。不理解现有结构时先提问。',
-    injectPrompt: true,
-  },
-
-  /**
-   * 约定胜于新奇 — Mnilax Rule 11
-   * 原因：规范一致性 > 技术偏好
-   */
-  follow_conventions: {
-    id: 'follow_conventions',
-    rule: 'MATCH CODEBASE CONVENTIONS, EVEN IF YOU DISAGREE',
-    message: '规范一致性 > 技术偏好，有异议显式提出不暗中背离',
-    level: 'guideline',
-    trigger: ['code_implementation', 'module_extension'],
-    enforcement: 'convention-check',
-    description: `在代码库内部：规范一致性 > 个人技术偏好。若项目用 snake_case 而你偏好 camelCase：用 snake_case。若项目用 class 组件而你偏好 hooks：用 class。若确信某规范存在实质危害，请显式提出。切勿暗中背离规范另起范式。`,
-    promptInjection: '约定胜于新奇：规范一致性 > 技术偏好。项目用 snake_case 就用 snake_case。有异议显式提出，不暗中另起范式。',
-    injectPrompt: true,
-  },
-
-  /**
-   * 第一性优先 — Mnilax extension
-   * 原因：从当前状态推导结论会自我证明。正确顺序：第一性→事实校验→结论。
-   */
-  first_principles_first: {
-    id: 'first_principles_first',
-    rule: 'ANALYZE FROM FIRST PRINCIPLES, NOT FROM CURRENT STATE',
-    message: '分析顺序: 第一性→事实校验→结论。禁止"代码就是这样"作为理由',
-    level: 'guideline',
-    trigger: ['code_implementation', 'module_modification', 'file_modification'],
-    enforcement: 'principle-check',
-    description: `架构分析与设计决策必须从第一性原理出发，而非从当前实现状态推导。禁止的模式: "当前代码这样写的所以应该保持这样"——这是自我证明的错误逻辑。`,
-    promptInjection: '第一性优先: 分析设计问题从本质出发，不从当前代码推导。正确设计是什么→当前实现匹配吗→差距决定行动。禁止"代码就是这样"作为理由。',
-    injectPrompt: true,
-  },
-
-  /**
-  /**
-   * 原因：质量门阻断是信号，不是障碍。调整门禁而非修复违规是自我欺骗。
-   */
-  fix_the_problem_not_the_gate: {
-    id: 'fix_the_problem_not_the_gate',
-    rule: 'FIX THE PROBLEM THAT TRIGGERED THE GATE, NOT THE GATE ITSELF',
-    message: '修复触发门禁的问题，不降低门禁本身',
-    level: 'guideline',
-    trigger: ['code_implementation', 'module_modification', 'file_modification'],
-    enforcement: 'principle-check',
-    description: `质量门禁（测试失败、lint 报错、覆盖率不足、约束违规）阻断时，修复导致阻断的代码，而非调整门禁门槛。降低阈值、删除测试、关闭 lint 规则是对质量信号的压制，不是质量改进。`,
-    promptInjection: '质量门禁阻断时修复代码，不修复门禁。不降阈值、不删测试、不关 lint、不改断言让 CI 通过。',
-    injectPrompt: true,
-  },
-
-  /**
-   * 下游修复前先诊断上游
-   * 原因：兼容/兜底是掩盖，不是修复。连续 fallback 同一位置 2+ 次是上游 bug 信号。
-   */
-  no_fallback_without_root_cause: {
-    id: 'no_fallback_without_root_cause',
-    rule: 'BEFORE ADDING FALLBACK, TRACE UPSTREAM FIRST',
-    message: '禁止用兼容/兜底掩盖上游数据异常。先追根因——谁产生的？为什么是空？',
-    level: 'guideline',
-    trigger: ['code_implementation', 'module_modification', 'file_modification'],
-    enforcement: 'principle-check',
-    description: `遇到空值/异常/不完整数据时，禁止直接用 fallback/default/兜底值掩盖。必须先追踪数据来源——哪个上游产生的？为什么异常？修复上游 OR 添加防御性兜底——选择后者时必须在代码注释中说明根因。重复 fallback 同一问题 2+ 次是 sign of upstream bug。`,
-    promptInjection: '改动前先问: 数据从哪来？为什么是空的？fix upstream first, fallback second。连续 2+ 次相同错误 → 停止修下游,追踪源头。',
-    injectPrompt: true,
-  },
-
-  /**
-   * 诊断→修复闸门：必须先呈现确认的根因+方案才能编辑，禁止 Read→Edit 直跳
-   * 原因：读代码定位问题后直接改，不查设计意图、不验证假设，是"凭猜测修 bug"
-   */
-  diagnosis_to_fix_gate: {
-    id: 'diagnosis_to_fix_gate',
-    rule: 'PRESENT ROOT CAUSE + FIX PLAN BEFORE EDITING CODE',
-    message: '诊断出根因后，必须先呈现方案+设计原型对照，禁止从 Read 直接跳到 Edit',
-    level: 'guideline',
-    trigger: ['code_implementation', 'module_modification', 'file_modification'],
-    enforcement: 'principle-check',
-    description: `用 Read/Grep 定位问题后，禁止立即 Edit 修改。必须先：① 确认根因（不止是"哪里出错"，而是"为什么设计成这样"）；② 检查设计原型/文档（CLAUDE.md、类型定义、commit message），确认原设计意图；③ 提出方案草案。满足以上三条后才能 Edit。违反此约束会导致"改了但不对"——因为根本没理解代码为什么那么写。`,
-    promptInjection: '诊断→修复闸门: 读代码定位根因后，必须先查设计原型（为什么这么写？CLAUDE.md/类型定义/commit message），呈现确认的根因+方案草案，然后才能 Edit。禁止 Read→Edit 直跳，禁止对现有设计做未经原型对照的语义变更。',
-    injectPrompt: true,
-  },
-
-  /**
-   * 分析闸门：从数据到结论之间，必须先验证关键假设的含义和量纲
-   * 原因：看到可疑数字直接跳结论而跳过验证是诊断错误的第一来源（累积 vs 单次、正常 vs 异常、相关 vs 因果）
-   */
-  analysis_verification_gate: {
-    id: 'analysis_verification_gate',
-    rule: 'VERIFY KEY ASSUMPTIONS BEFORE DRAWING CONCLUSIONS FROM DATA',
-    message: '从数据到结论之间，必须先验证关键假设的含义和量纲',
-    level: 'guideline',
-    trigger: ['code_implementation', 'design_request', 'module_modification', 'file_modification', 'diagnosis'],
-    enforcement: 'principle-check',
-    description: `从代码/日志/指标中发现异常数据时，禁止直接从"数字异常"跳到"根因结论"。必须先验证：① 数字的含义（累积/单次？量纲是什么？）；② 正常范围（这个数值在健康状态下是多少？）；③ 对比验证（同类场景下是什么值？有无反例？）。验证完关键假设后，再进行因果推断和方案设计。违反此约束导致"翻烧饼"——因为结论建立在未经验证的假设上。`,
-    promptInjection: '分析闸门: 从数据到结论必须验证关键假设。一个异常数字≠根因——先确认含义（累积/单次？量纲？正常范围？同类对比？），再推断因果。禁止"数字A太大→一定是B导致的→应该改C"这种跳级推理。',
-    injectPrompt: true,
-  },
-
-  /**
-   * 禁止硬编码凭证
-   * 原因：密码/token/密钥泄露是最严重的安全漏洞，一旦提交到版本控制即不可逆
-   */
-  no_hardcoded_credentials: {
-    id: 'no_hardcoded_credentials',
-    rule: 'NO HARDCODED PASSWORDS, TOKENS, SECRETS, OR CREDENTIALS IN ANY SOURCE FILE',
-    message: '禁止在代码/文档/配置文件中硬编码密码、token、密钥、API key',
-    level: 'guideline',
-    trigger: ['code_implementation', 'doc_update', 'config_change', 'commit'],
-    enforcement: 'credential-scan',
-    description: `凭证（密码/token/密钥/API key）必须从环境变量或加密配置读取，严禁以明文形式出现在任何源代码文件中。包括但不限于：源码、Markdown 文档、YAML/JSON 配置、脚本文件。模板文件（.example/.sample/.template）允许占位符但不得包含真实值。建议配合 pre-commit hook 做自动扫描。`,
-    promptInjection: '禁止在代码中硬编码密码、API 密钥、Token 等凭证。使用环境变量或安全的凭证管理方案存储敏感信息。',
-  },
 };