kc-beta 0.1.0

package/template/skills/zh/meta-meta/quality-control/SKILL.md

@@ -0,0 +1,269 @@
+---
+name: quality-control
+description: Design and execute quality control for production verification workflows. Use when workflows are deployed on Input/ documents and results need to be monitored, when designing the QC sampling strategy for a rule, or when evaluating whether monitoring can be reduced. Covers LLM-as-Judge evaluation, adaptive sampling strategies, confidence-based triage, and the transition from active monitoring to stable oversight. Also use when production quality drops and you need to diagnose whether to trigger the evolution loop.
+---
+
+# 生产环境的质量监控与质控策略
+
+## 质量监控的定位
+
+工作流部署到生产环境后，不能放任不管。但也不可能对每一份单据的核查结果都做人工复查——那就失去了自动化的意义。
+
+质量监控的角色是「观察员」：用最少的复查量，维持对系统准确率的信心。当信心下降时，立即拉响警报、触发演化循环。
+
+## 五层质量保障架构
+
+质量控制不是单一活动——它由五个层级构成，逐层递进。低层级必须通过后，高层级才会执行。
+
+| 层级 | 名称 | 检查内容 | 方法 |
+|------|------|---------|------|
+| L1 | 文本完整性 | 文件存在、编码正确、处理后源文本保持完整 | 脚本（`lint_*`） |
+| L2 | 语法 | 输出格式有效（JSON/CSV）、必填字段存在、类型正确 | 脚本（`lint_*`） |
+| L3 | 数据完备性 | 必填字段已填充、值在有效范围内（日期是日期、金额为正数） | 脚本（`validate_*`） |
+| L4 | 业务逻辑 | 跨字段一致性、阈值合规性、序列合理性 | 脚本 + LLM |
+| L5 | 跨阶段 | 结果中的实体与提取输出匹配、规则与目录匹配、工作流输出与技能基准真值匹配 | 脚本（`cross_validate_*`）+ LLM |
+
+**核心原则：**
+- **快速失败**：如果 L1 失败（文件缺失），不要运行 L4（业务逻辑）。低层级阻塞高层级。
+- **代码优先**：L1-L3 应为纯代码——低成本且确定性强。LLM 评审（见下文）在 L4 和 L5 层级运作。
+- **命名规范**：`lint_*` 用于 L1-L2，`validate_*` 用于 L3-L4，`cross_validate_*` 用于 L5。
+
+**质控 vs 反思**：质控发现输出中的问题（本技能）。反思诊断问题的根因并修复（参见 `evolution-loop`）。质控向反思提供数据；反思向系统反馈修复。
+
+详见 `references/qa-layers.md` 的层级规格和示例模式。
+
+## LLM 作为评审（LLM-as-Judge）
+
+质控的核心机制是用编程智能体（你）或指定的高层级模型，对工作流的输出结果进行独立评审。
+
+### 评审判定等级
+
+每条核查结果的评审结论分为四个等级：
+
+| 等级 | 含义 | 后续处理 |
+|------|------|---------|
+| **correct（正确）** | 工作流判定完全正确，字段提取准确，结论有据 | 无需处理 |
+| **partial（部分正确）** | 核心结论正确，但细节有偏差（如字段提取不完整、批注不够精确） | 记录偏差，低优先级修复 |
+| **incorrect（错误）** | 核查结论错误（漏报或误报） | 触发演化循环 |
+| **missing（缺失）** | 工作流未能给出核查结论（异常退出、超时、格式错误） | 检查工作流健壮性 |
+
+### 字段级评审
+
+除了整体判定之外，对关键字段逐一评审：
+
+```json
+{
+  "document_id": "DOC-2025-0042",
+  "rule_id": "R001",
+  "workflow_verdict": "pass",
+  "judge_verdict": "correct",
+  "field_review": {
+    "invoice_date": {"extracted": "2025-03-15", "judge": "correct"},
+    "contract_start": {"extracted": "2025-01-01", "judge": "correct"},
+    "contract_end": {"extracted": "2025-12-31", "judge": "correct"}
+  },
+  "comment": "",
+  "reviewed_at": "2025-04-01T16:00:00Z"
+}
+```
+
+字段级评审能帮助发现「歪打正着」的情况——结论碰巧正确但提取过程有误，这种隐患在未来的案例中可能导致错误。
+
+## 自适应抽样策略
+
+不是每一份单据都需要复查。抽样比例根据工作流的历史表现动态调整。
+
+### 抽样比例阶梯
+
+```
+初始部署期：100% 全量复查
+  ↓ 连续 2 批次准确率 ≥ 阈值
+稳定期初期：50% 抽样
+  ↓ 连续 3 批次准确率 ≥ 阈值
+稳定期中期：20% 抽样
+  ↓ 连续 5 批次准确率 ≥ 阈值
+长期稳态：5-10% 抽样
+```
+
+**回退机制**：任何一个批次出现准确率下降，抽样比例立即回退一级。连续两个批次下降，回退到 100%。
+
+### .env 中的 MONITOR_FREQUENCY 映射
+
+```
+MONITOR_FREQUENCY=high  → 初始部署期，100% 全量复查
+MONITOR_FREQUENCY=mid   → 稳定期，50% 抽样
+MONITOR_FREQUENCY=low   → 长期稳态，10% 抽样
+```
+
+这个参数是初始值。系统运行后会根据实际表现自动调整。
+
+### 抽样方法
+
+抽样不是简单的随机抽取。采用分层抽样确保覆盖面：
+
+1. **按置信度分层**：优先复查低置信度的案例
+2. **按单据类型分层**：确保每种单据类型都有样本被复查
+3. **按判定结果分层**：不通过的案例优先复查（误报成本高于漏报）
+4. **随机保底**：即使高置信度案例也有一定概率被抽中
+
+## 基于置信度的分诊
+
+工作流输出的置信度（confidence）是分诊的重要依据：
+
+### 高置信度（≥ 0.9）
+
+工作流对自己的判定非常确定。
+
+处理方式：抽检即可。在稳定期，只随机抽取 5-10% 进行复查。
+
+### 中等置信度（0.7 - 0.9）
+
+工作流有一定把握但不完全确定。
+
+处理方式：加大抽样比例，至少 30-50%。关注置信度居中的案例是否存在系统性偏差。
+
+### 低置信度（< 0.7）
+
+工作流对自己的判定没有信心。
+
+处理方式：全量复查。低置信度案例本身就是有价值的数据——它们往往是边界案例或新场景，可以丰富测试集。
+
+## 触发演化循环的条件
+
+质量监控发现以下情况时，需要触发演化循环：
+
+### 准确率下降
+
+```
+IF 当前批次准确率 < WORKFLOW_ACCURACY:
+    触发演化循环
+    抽样比例回退到 100%
+    通知开发者用户
+```
+
+### 新的失败模式
+
+即使整体准确率达标，如果发现了之前未见过的失败类型，也需要启动演化循环进行调查。
+
+### 置信度漂移
+
+工作流的平均置信度持续下降，即使判定结果仍然正确。这可能预示即将出现准确率问题，需要提前介入。
+
+### 分布漂移
+
+输入单据的特征分布发生变化（新的单据格式、新的业务场景），即使当前准确率不受影响，也需要评估是否需要补充测试覆盖。
+
+## 批量处理的质控流程
+
+当 `Input/` 目录中有批量单据需要处理时，按以下流程执行：
+
+### 处理流程
+
+```
+1. 扫描 Input/ 目录，统计待处理单据数量和类型
+2. 按规则逐条执行工作流
+3. 将结果写入 Output/ 目录
+4. 根据当前抽样比例，选取样本进行质控评审
+5. 汇总评审结果
+6. 判断是否需要触发演化循环
+7. 生成质控报告
+```
+
+### 输出结构
+
+```
+Output/
+├── DOC-001/
+│   ├── results.json          # 所有规则的核查结果
+│   └── qc_review.json        # 质控评审结果（如被抽中）
+├── DOC-002/
+│   └── results.json
+└── batch_summary.json        # 本批次汇总
+```
+
+### batch_summary.json
+
+```json
+{
+  "batch_id": "BATCH-2025-04-01",
+  "total_documents": 50,
+  "processed": 50,
+  "rules_applied": ["R001", "R002", "R003"],
+  "qc_sample_size": 25,
+  "qc_sample_rate": 0.5,
+  "qc_results": {
+    "correct": 23,
+    "partial": 1,
+    "incorrect": 1,
+    "missing": 0
+  },
+  "accuracy": 0.92,
+  "threshold": 0.85,
+  "status": "above_threshold",
+  "action": "none",
+  "timestamp": "2025-04-01T18:00:00Z"
+}
+```
+
+## 质控日志
+
+所有质控活动记录在 `logs/qc/` 目录下：
+
+```
+logs/qc/
+├── qc_2025-04-01.json        # 每日质控汇总
+├── reviews/                   # 逐案评审记录
+│   ├── DOC-001_R001.json
+│   └── DOC-001_R002.json
+└── trends.json                # 准确率趋势数据
+```
+
+### trends.json
+
+追踪关键指标的时间序列，供仪表盘展示使用：
+
+```json
+{
+  "R001": {
+    "history": [
+      {"date": "2025-03-28", "accuracy": 0.88, "sample_rate": 1.0, "batch_size": 20},
+      {"date": "2025-03-29", "accuracy": 0.90, "sample_rate": 1.0, "batch_size": 15},
+      {"date": "2025-03-30", "accuracy": 0.93, "sample_rate": 0.5, "batch_size": 30},
+      {"date": "2025-04-01", "accuracy": 0.92, "sample_rate": 0.5, "batch_size": 50}
+    ]
+  }
+}
+```
+
+## 开发者用户参与
+
+质量监控不应该让开发者用户去读 JSON 文件。通过仪表盘技能生成可视化报告，开发者用户只需要关注：
+
+- 当前各规则的准确率状态（绿色/黄色/红色）
+- 是否有需要人工确认的模糊案例
+- 成本趋势是否合理
+- 是否有需要决策的上报事项
+
+质控发现的问题，如果属于系统可自行修复的范围（通过演化循环），不需要打扰开发者用户。只有以下情况需要上报：
+
+- 准确率持续下降且演化循环未能修复
+- 发现了新的业务场景需要确认核查规则
+- 成本异常波动
+- 达到 `MAX_ITERATIONS` 仍未解决的问题
+
+## 用户反馈收集
+
+在你创建的每一个核查应用中，都要构建错误报告和评论机制。这不是可选功能——它们是必要的数据来源。
+
+### 两类受众
+
+- **开发者用户**：技术性错误报告——字段级更正、规则重新评估请求、附带上下文的误报/漏报标记。他们可以看到完整的结果细节。
+- **终端用户**：简化反馈——标记结果为错误、添加评论、标注严重程度。他们看到的是简洁的界面，不涉及技术内部细节。
+
+### 反馈作为基准真值
+
+当用户对核查结果报告错误时，该更正即为基准真值。它优先于编程智能体的判断和 Worker LLM 的输出。将用户更正立即注入 `evolution-loop`，作为已确认的失败案例——其优先级高于智能体自行检测到的问题。
+
+### 反馈数据流
+
+通过仪表盘收集反馈（参见 `dashboard-reporting`）→ 存储为结构化记录（result_id, reporter_role, feedback_type, corrected_value, comment, timestamp）→ 注入 `evolution-loop` 作为回归测试案例 → 在质控指标中追踪更正趋势。

package/template/skills/zh/meta-meta/quality-control/references/qa-layers.md

@@ -0,0 +1,92 @@
+# QA Layer Specifications
+
+Detailed specifications for the five-layer QA architecture. Each layer builds on the one below it.
+
+## Layer Details
+
+### L1: Text Integrity
+
+- **Description**: Verify that source files exist, are readable, and that text content is preserved correctly after any processing (parsing, OCR, conversion).
+- **Input**: Raw document files and their processed text output.
+- **Output**: Pass/fail per file with error details.
+- **Example checks**: File exists and is non-empty. Encoding is UTF-8 (or declared encoding). No null bytes in text output. Character count is within expected range for document type.
+- **Common failures**: File path changed after processing. OCR produced empty output. Encoding mismatch causes garbled characters.
+- **Escalation**: If L1 fails, do not proceed to higher layers. Log the failure and flag for reprocessing.
+
+### L2: Syntax
+
+- **Description**: Verify that output files conform to their declared format and schema.
+- **Input**: Output files (JSON, CSV, etc.) from workflows.
+- **Output**: Pass/fail per file with parse errors or schema violations.
+- **Example checks**: JSON is valid (parses without error). Required top-level keys exist. Array fields are arrays, not strings. Date fields match ISO 8601 format.
+- **Common failures**: Trailing comma in JSON. Missing closing bracket. CSV with inconsistent column count. Unexpected null where value is required.
+- **Escalation**: Syntax failures indicate a bug in the output generation code. Fix the code, not the data.
+
+### L3: Data Completeness
+
+- **Description**: Verify that required data fields are populated with values in their valid domain.
+- **Input**: Parsed output records.
+- **Output**: Per-field validation results with reasons for any failures.
+- **Example checks**: Invoice date is a valid date (not "N/A" or empty). Amount is a positive number. Entity name is non-empty and does not contain only whitespace. Enum fields contain allowed values.
+- **Common failures**: Extraction returned "unable to determine" as a value. Amount includes currency symbol (string instead of number). Date extracted as partial (month and day but no year).
+- **Escalation**: Completeness failures feed back to extraction prompt improvement. If a field is consistently incomplete, the extraction logic needs work.
+
+### L4: Business Logic
+
+- **Description**: Verify cross-field consistency and compliance with business rules.
+- **Input**: Complete, validated records from L3.
+- **Output**: Per-rule validation results with reasoning.
+- **Example checks**: Contract end date is after start date. Invoice date falls within contract validity period. Total amount equals sum of line items. Signatory name matches authorized personnel list.
+- **Common failures**: Date comparison fails due to timezone differences. Rounding errors in amount calculations. Cross-reference lookup fails because entity names differ slightly (e.g., "ABC Corp" vs "ABC Corporation").
+- **Escalation**: Business logic failures may indicate rule misunderstanding. Consult the developer user if the rule intent is ambiguous.
+
+### L5: Cross-Phase
+
+- **Description**: Verify consistency across different phases of the verification pipeline.
+- **Input**: Outputs from multiple pipeline stages (extraction, verification, reporting).
+- **Output**: Cross-phase consistency report.
+- **Example checks**: Entities in final results match those in extraction output (nothing added or dropped). Rule IDs in results exist in the rule catalog. Workflow output for a skill matches the skill's own ground truth output. Confidence scores in results match those computed by the confidence system.
+- **Common failures**: A rule was added to the catalog but the workflow was not updated to include it. Extraction found 5 entities but results only report 4. Workflow output diverges from skill ground truth on edge cases.
+- **Escalation**: Cross-phase failures often indicate integration issues. Check the pipeline connections, not individual components.
+
+## Script Naming Convention
+
+| Prefix | Layer | Purpose | Examples |
+|--------|-------|---------|----------|
+| `lint_` | L1-L2 | Fast, syntactic checks | `lint_json.py`, `lint_encoding.py`, `lint_schema.py` |
+| `validate_` | L3-L4 | Domain and logic validation | `validate_fields.py`, `validate_dates.py`, `validate_amounts.py` |
+| `cross_validate_` | L5 | Cross-phase consistency | `cross_validate_extraction.py`, `cross_validate_rules.py` |
+
+Scripts should:
+- Accept a file or directory path as input.
+- Output structured JSON results (pass/fail per check, with reasons).
+- Return exit code 0 if all checks pass, non-zero otherwise.
+- Be idempotent — running twice produces the same result.
+
+## QC vs Reflection
+
+| Dimension | QC (this skill) | Reflection (evolution-loop) |
+|-----------|-----------------|---------------------------|
+| **Who runs it** | Coding agent or automated scripts | Coding agent |
+| **What triggers it** | Every batch, on schedule | QC failures, accuracy drops |
+| **Input** | Workflow outputs | QC reports, failure logs, iteration history |
+| **Output** | Pass/fail verdicts, accuracy metrics | Root cause diagnosis, fix proposals |
+| **Cost** | Low (mostly scripts, some LLM at L4-L5) | Higher (deep analysis, prompt rewriting) |
+| **When to use** | Always — every production batch | Only when QC reveals problems |
+| **Goal** | Detect problems | Fix problems |
+
+QC without Reflection detects issues but cannot fix them. Reflection without QC has no data to work from. They are complementary, not alternatives.
+
+## Integration Points
+
+### With `data-sensibility`
+
+The `data-sensibility` skill provides input validation that feeds L1-L3. If data-sensibility checks flag a document as anomalous before processing, QC can prioritize reviewing that document's outputs. Data-sensibility operates on inputs; QC operates on outputs. Together they bracket the pipeline.
+
+### With `cross-document-verification`
+
+Cross-document verification enables L5 cross-doc consistency checks. When multiple documents reference the same entity (e.g., same contract number across invoice and purchase order), L5 can verify that extracted values are consistent across documents. Without cross-document verification, L5 is limited to single-document cross-phase checks.
+
+### With `confidence-system`
+
+QC results calibrate the confidence system. When QC reveals that high-confidence results are sometimes wrong, the confidence thresholds need adjustment. Conversely, confidence scores drive QC sampling — low-confidence results get more review. This creates a feedback loop: QC improves confidence calibration, better calibration improves QC efficiency.

package/template/skills/zh/meta-meta/quality-control/references/sampling-strategies.md

@@ -0,0 +1,76 @@
+# Sampling Strategies for Quality Control
+
+## Adaptive Sampling
+
+The core idea: review more when you are uncertain, less when you are confident. Confidence grows with evidence — consecutive batches of high accuracy.
+
+### Continuous Decay Model
+
+Rather than cliff-edge transitions between phases, use a smooth exponential decay driven by observed accuracy:
+
+```
+sampling_rate = max(floor_rate, exp(-λ × consecutive_successes))
+```
+
+Where:
+- `consecutive_successes`: number of consecutive batches where accuracy meets or exceeds the threshold. **Resets to 0** whenever a batch's accuracy drops below the threshold. This is the self-correcting mechanism — quality drops immediately increase monitoring.
+- `λ` (decay speed): controlled by MONITOR_FREQUENCY in `.env`.
+- `floor_rate`: the minimum sampling rate, never goes below this.
+
+### MONITOR_FREQUENCY Mapping
+
+| Setting | λ | floor_rate | Character |
+|---------|---|------------|-----------|
+| `high` | 0.1 | 0.10 | Slow decay, cautious — for high-stakes verification where errors are costly |
+| `mid` | 0.2 | 0.05 | Balanced decay — standard for most scenarios |
+| `low` | 0.3 | 0.05 | Fast decay — for well-understood domains with simple rules |
+
+As a rough mental model of the curve shape (for `mid`):
+- After 1 success: ~82% sampling
+- After 3 successes: ~55%
+- After 5 successes: ~37%
+- After 10 successes: ~14%
+- After 15 successes: ~5% (floor)
+
+These numbers, the formula, and even the exponential shape are recommended defaults. The coding agent and developer user should discuss and calibrate based on the specific business scenario. If a different decay function (linear, sigmoid, or hand-tuned) works better, use it. The framework — accuracy-driven decay with reset on quality drop — matters more than the specific formula.
+
+## Priority Sampling
+
+Not all results are equally worth reviewing. Priority sampling ensures that the most informative results are always in the review set:
+
+### Always Review
+- Results where the workflow reported low confidence (below the full-review threshold from `confidence-system`).
+- Results where the workflow produced an error or missing result.
+- Results from document types not seen during skill/workflow testing.
+
+### Usually Review
+- Results where the workflow's confidence is in the medium band.
+- Results from rules that historically have lower accuracy.
+- Results from the first occurrence of a new document format or variant.
+
+### Spot-Check
+- Results with high confidence from rules that historically have high accuracy.
+- These are selected randomly from the high-confidence pool.
+- The purpose is regression detection, not active improvement.
+
+## Stratified Sampling
+
+When documents vary significantly in complexity or type, stratify the sample:
+
+1. **Group documents** by type, complexity, or any relevant characteristic.
+2. **Sample proportionally** from each group, ensuring that minority groups are represented.
+3. **Over-sample** from groups that historically have lower accuracy.
+
+This prevents the random sample from being dominated by easy documents while missing systematic failures in hard documents.
+
+## Confidence Calibration Check
+
+Periodically (every N batches), run a calibration check:
+
+1. Take a random sample of high-confidence results.
+2. Review them (LLM-as-Judge or human).
+3. Compare: are 90%+ of "high confidence" results actually correct?
+4. If not, the confidence system needs recalibration (see `confidence-system` skill).
+5. If yes, you can safely reduce the sampling rate for high-confidence results.
+
+This is a meta-check on the quality of the quality control system itself.

package/template/skills/zh/meta-meta/rule-extraction/SKILL.md

@@ -0,0 +1,208 @@
+---
+name: rule-extraction
+description: Extract and organize business verification rules from regulation documents into discrete, testable units. Use when processing documents in Rules/ to identify individual verification rules, when decomposing a regulation into atomic checks, or when the developer user adds new regulation files. Covers reading regulation text, identifying rule boundaries, determining granularity, handling cross-references, and producing a rule catalog. Also use when rules are provided in structured formats like xlsx or csv.
+---
+
+# 法规条文解构与核查规则提取
+
+## 核心理念
+
+规则是整个核查体系的原子单元。一条规则对应一个技能文件夹，一个技能文件夹对应一个可独立测试的核查逻辑。规则提取的质量直接决定后续所有环节的上限——技能编写、工作流蒸馏、质量监控，全部建立在规则提取的基础之上。
+
+提取得好，后面事半功倍。提取得差，后面反复返工。
+
+## 高质量规则的四个特征
+
+### 原子性
+
+一条规则只做一件事。如果你发现一条规则需要用「并且」「同时」连接两个独立的判断逻辑，大概率应该拆成两条规则。
+
+反例：「发票日期应在合同有效期内，且发票金额不超过合同总额」——这是两条规则。
+
+### 可测试性
+
+规则的判定结果必须是明确的：通过、不通过、无法判定。不能出现「大致合理」「基本符合」这种模糊结论。如果一条规则无法给出确定性结论，说明它还没提取到位。
+
+### 自包含性
+
+规则的执行不应依赖于其他规则的执行结果。每条规则应该能独立运行。如果规则A的判定需要先知道规则B的结果，说明存在耦合，需要重新设计。
+
+例外：交叉验证类规则（如「发票金额与合同金额一致」）本身就是一条独立规则，它依赖的是数据字段而非其他规则的结论。
+
+### 明确的作用域
+
+规则必须清楚说明它适用于什么类型的单据、什么业务场景、什么前提条件。作用域模糊的规则在实际核查中会产生大量误判。
+
+## 规则体系的系统性设计原则
+
+单条规则应当满足上述四个特征。规则目录作为一个整体，还需要满足系统级属性：
+
+### 覆盖度目标
+提取的规则应覆盖法规可核查要求的至少 95%。初次提取完成后，执行覆盖度审计：端到端通读原始法规，标注每个段落是否被至少一条规则覆盖。未覆盖的段落要么是非核查性内容（定义、背景），要么是需要补充的空白。
+
+### 原子性测试
+一条规则 = 一个通过/不通过结论。如果一条规则能产出两个独立的通过/不通过结果，它应该被拆为两条规则。自问：「这条规则能部分通过吗？」如果能，继续拆分。
+
+### 歧义最小化
+不能有两条规则对同一文档的同一实体给出矛盾结论。提取完成后，审查作用域重叠的规则对。如果规则 A 判定通过而规则 B 判定不通过（针对同一实体），说明它们的作用域边界不清——必须修正。
+
+### 下游预判
+规则最终将被蒸馏为工作流（参见 `skill-to-workflow`）。设计时就要考虑蒸馏的需求：清晰的输入/输出边界、显式的判定标准、尽量减少对隐含领域知识的依赖。如果一条规则需要「读出言外之意」，把那个解读显式写出来。使用 `task-decomposition` 来识别规则之间的自然边界。
+
+### 目录版本化
+当规则发生变更（新增、修改、废弃）时，将整个规则目录作为一个整体进行版本化。单条规则的版本跟踪的是具体规则；目录版本跟踪的是规则集的一致性状态。在 `versions.json` 中记录目录版本，与单条规则版本并列。
+
+## 策略一：结构化输入（开发者用户提供规则表格）
+
+当开发者用户以 xlsx、csv 或其他结构化格式提供规则清单时，这是最理想的情况。
+
+### 处理步骤
+
+1. 读取文件，理解表格结构（列名、分组方式）
+2. 尊重开发者用户的规则划分——他们比你更懂业务
+3. 为每条规则生成标准编号（R001、R002...）
+4. 检查是否存在隐含的复合规则需要进一步拆分
+5. 补充表格中可能缺失的信息：适用范围、前提条件、判定标准
+
+### 注意事项
+
+- 不要擅自合并开发者用户已经拆分的规则
+- 如果表格中某条规则的描述过于笼统，标记为「待细化」，向开发者用户确认
+- 保留原始表格的引用关系（如行号），便于回溯
+
+## 策略二：从法规原文层层剥解
+
+当输入是法规文件、监管通知、内部制度等非结构化文本时，采用「洋葱剥皮法」逐层提取。
+
+### 第一层：通览全文结构
+
+快速阅读，识别文件的组织方式：
+- 章节编号体系（第X条、第X款、第X项）
+- 哪些章节是定义性条款（不含核查规则）
+- 哪些章节是实质性要求（包含核查规则）
+- 哪些章节是程序性条款（审批流程，可能包含时限类规则）
+- 附则、附件中是否有补充规则
+
+### 第二层：识别规则承载段落
+
+聚焦于实质性要求章节，逐段判断：
+- 该段落是否包含「应当」「必须」「不得」「需要」等规范性用语？
+- 该段落是否描述了可以被验证的具体要求？
+- 该段落是叙述性说明还是操作性要求？
+
+只有包含可核查要求的段落才进入下一层处理。
+
+### 第三层：逐段提取规则
+
+对每个规则承载段落：
+
+1. 提取核查对象（哪个字段、哪份单据）
+2. 提取核查标准（什么条件、什么阈值）
+3. 提取适用范围（什么业务场景、什么前提条件）
+4. 提取例外情形（什么情况下不适用）
+5. 标注原文位置（法规名称 + 条款编号）
+
+### 第四层：处理交叉引用
+
+法规文本中常见的交叉引用模式：
+- 「依据本办法第X条规定」——需要找到被引用条款，整合上下文
+- 「参照XX法规执行」——需要确认外部法规是否在 `Rules/` 中，如果没有则标记为待补充
+- 「前款所述情形」——需要回溯上文，明确指代
+
+处理原则：将交叉引用解析为自包含的规则描述，在规则的 `references/` 中保留原始引用关系。
+
+### 第五层：拆解复合规则
+
+识别并拆分以下模式：
+
+- 并列条件：「A且B」→ 拆为规则A、规则B
+- 条件分支：「若X则A，若Y则B」→ 拆为规则A（前提X）、规则B（前提Y）
+- 阶梯条件：「金额≤10万执行A流程，金额>10万执行B流程」→ 拆为规则A（阈值条件）、规则B（阈值条件）
+
+不需要拆分的情形：
+- 规则本身就是一个条件判断：「发票日期应在合同有效期内」——这就是一条原子规则
+- 规则包含多个字段但逻辑统一：「收款单位名称、账号应与合同约定一致」——可以保留为一条规则，因为核查逻辑相同
+
+## 策略三：开发者用户口述的专家经验
+
+有时候开发者用户不会给你法规文件，而是直接告诉你业务经验和核查要点。这种输入同样有效。
+
+### 处理方式
+
+1. 完整记录开发者用户的口述内容
+2. 将口述转化为结构化规则（编号、名称、核查逻辑、判定标准）
+3. 回读给开发者用户确认，特别注意：
+   - 是否遗漏了隐含的前提条件
+   - 阈值和标准是否准确
+   - 是否有例外情况没提到
+4. 在规则来源中标注「专家经验」而非法规条文
+
+## 规则目录管理
+
+所有提取的规则汇总为一份轻量级目录，存放在工作空间根目录的 `rule-catalog.json` 中：
+
+```json
+{
+  "rules": [
+    {
+      "id": "R001",
+      "name": "发票日期有效性",
+      "source": "《增值税发票管理办法》第十五条",
+      "status": "extracted",
+      "priority": "high",
+      "skill_folder": "rule-skills/R001-invoice-date-validity/",
+      "notes": ""
+    }
+  ],
+  "total": 1,
+  "extracted": 1,
+  "skill_authored": 0,
+  "workflow_distilled": 0,
+  "last_updated": "<时间戳>"
+}
+```
+
+### 状态流转
+
+每条规则的生命周期状态：
+
+```
+extracted → skill_authored → skill_tested → workflow_distilled → workflow_tested → production
+```
+
+目录中实时跟踪每条规则所处的阶段。
+
+## 处理模糊与歧义
+
+法规条文中经常存在模糊表述，如「合理期限内」「必要时」「视情况而定」。处理原则：
+
+1. **先提取，不要跳过**——模糊不等于不重要
+2. **在规则中标注歧义**——明确指出哪个部分存在解读空间
+3. **向开发者用户确认**——提供你的理解，请开发者用户裁定
+4. **确认后更新规则**——将开发者用户的裁定写入规则描述
+
+绝对不要自行决定模糊条款的含义。你对业务的理解不如开发者用户。
+
+## 法规变更时的处理
+
+当 `Rules/` 中新增或修改了法规文件时：
+
+1. 对比新旧版本，识别变更点
+2. 定位受影响的已有规则
+3. 判断影响程度：
+   - 措辞调整但核查逻辑不变——更新引用文本，无需重新测试
+   - 阈值或标准变更——更新规则参数，需要重新测试
+   - 新增核查要求——提取新规则
+   - 废止原有要求——将规则标记为 `deprecated`，不删除
+4. 更新规则目录
+5. 通知开发者用户变更影响范围
+
+## 输出交付物
+
+规则提取阶段完成后，应产出：
+
+1. `rule-catalog.json`——规则总目录
+2. 每条规则的初始描述文档（存放在对应技能文件夹的草稿中）
+3. 模糊与歧义清单（待开发者用户确认）
+4. 交叉引用映射（规则之间、规则与法规之间的引用关系）
+5. 向开发者用户汇报提取结果的摘要