Sub Skills

---
name: 案情梳理和法律分析
description: 对案件进行结构化分析，输出案情报告。适用于案由识别、法律关系梳理、请求权基础确定、要件分析等。
---

# 案情梳理和法律分析

## 强制约束

1. **本阶段本阶段只记录讨论过程、列出可能性、标注待确认事项，最终结论由律师在信息充分后做出**。只能记录讨论过程、列出可能性、标注待确认事项。最终结论由律师在信息充分后做出。
2. **关键事实缺失时，主动提问**，每次1-3个问题，由宏观到具体。
3. **采用八模块结构化分析框架输出报告**，不跳过任何模块。
4. **代理原告与代理被告的分析视角必须正确对应**（原告侧：进攻、请求权基础、证据证明；被告侧：防御、抗辩点、证据缺口）。
5. **示例使用通用命名规则，不出现真实案件信息**，使用通用命名规则。

---

## 执行前检查

按 `references/执行前强制检查清单.md` 完成基础检查。

**通用行为原则读取（强制）**：
- 读取 `references/通用行为原则.md`，全程遵守事实与观点区分、法律分析不预设立场、观点保持一致性、法条与案例引用先核验、事实一致性优先、风险提示常态化、输出结构化可复核等原则。

补充：
1. **加载本skill**：读取当前 `02_案情梳理和法律分析_SKILL.md` 文件，熟悉死刑条款和执行步骤。
2. **检查偏好**：若存在 `./办案记录.md`，读取其中是否有用户格式/风格偏好声明。
3. **⚠️ 观点一致性强制检查**：读取 `工作底稿/` 下的**所有**过程性文件以及在先生效诉讼文书（`案件卷宗/` 下的起诉状、答辩状、判决书等）。本次产出的所有事实主张、法律观点、数额计算、诉讼策略必须与在先文件保持完全一致，保持一致。若发现在先文件存在错误，必须先向用户明确指出并经确认后方可调整。
4. **确认任务**：确认案件名称、代理方身份、分析目标。

---

## 执行步骤

### Step 1：读取 `./办案记录.md`
读取案件基本信息、代理方身份、历史沟通记录、待办事项，以及**文件重要性索引**。

**依据文件重要性索引动态升级 OCR**：
- 若 `办案记录.md` 中某 P2/P3/P4 文件标记为"涉及核心事实：是"，或内容摘要涉及金额、主体、法律关系、关键时间，则本次必须优先读取并触发单文件即时 OCR。
- 读取前检查 `工作底稿/OCR状态.json`，确保该文件状态为 `done`；否则先补漏。

### Step 2：读取案件核心材料（PDF自动读取）

**🆕 读取前强制：OCR 状态检查**

在读取任何 PDF 文件前，必须检查 `工作底稿/OCR状态.json`：
- 状态为 `done` → 直接读取
- 状态为 `pending` / `processing` → 若当前分析需要，执行单文件即时 OCR（见下文）
- 状态为 `failed` / `skipped` → 用 AI 视觉或文件摘要辅助判断，必要时向用户报告

**文件读取范围（按 L1-L4 等级执行）：**

| 读取等级 | 文件位置 | 读取内容 | 说明 |
|:---|:---|:---|:---|
| **L1 必读** | `案件卷宗/04_法院文书/` | 判决书、裁定书、传票、立案通知等 | 了解诉讼程序状态和法院认定 |
| **L1 必读** | `案件卷宗/03_对方文件/` | 对方起诉状/上诉状、证据目录、证据材料、代理词 | 了解对方主张和证据 |
| **L1 必读** | `案件卷宗/02_己方文件/` | 己方答辩状/上诉状、证据目录、证据材料、代理词 | 了解己方已确立立场 |
| **L2 按需** | `工作底稿/` | 最新的案情分析报告、要件映射表、关键事实基准表 | 若存在则必读，作为分析起点 |
| **L3 触发** | `资料收集/一审材料/` | 一审起诉状、答辩状、证据、判决书 | 仅当前为二审/再审时必须读取 |
| **L3 触发** | `资料收集/关联案件/` | 关联案件判决书、裁定书 | 仅当 `办案记录.md` 标记为涉及核心事实时读取 |
| **L4 兜底扫描** | `资料收集/` | 全部文件名 + 01 生成的一句话摘要 | 不读全文，用于判断是否存在明显遗漏 |

**多版本文件读取规则**：
- 同类型文件（如起诉状、答辩状）存在多个版本时，默认读取 `办案记录.md`「最新版本索引」中标记的 `latest` 版本
- 若未建立版本索引，以文件名日期前缀判断（`YYYYMMDD` 最大者为最新）
- 关键文件存在多版本时，向用户提示："检测到 X 份[文件类型]，默认读取最新版 [路径]，是否需要对比旧版？"

**单文件即时 OCR（按需补漏）**：当目标文件状态为 `pending` 且当前分析需要读取时，使用子技能 01 的 3.1 检测逻辑 判断是否需要 OCR → 需要则在当前流程中即时执行单文件 OCR：

```bash
# 单文件即时 OCR（非批量，使用自适应 zoom）
python3 scripts/pdf_ocr_processor.py <单文件.pdf> <输出/> --skip-existing
```

完成后更新 `OCR状态.json` 中该文件的状态为 `done`，然后继续读取。

> **设计原则**：OCR 不阻塞案情分析。后台批量已完成的直接读取；未完成的在当前流程中即时补漏，单文件 OCR 通常仅需数秒，对整体效率影响极小。

**自动读取以下文件并提取文本：**

| 文件位置 | 读取顺序 | 提取内容 |
|:---|:---:|:---|
| L1：`案件卷宗/04_法院文书/` 下的判决书/裁定书 | 第1优先 | 法院认定事实、裁判理由、程序状态 |
| L1：`案件卷宗/03_对方文件/` 下的起诉状/上诉状 | 第2优先 | 原告诉讼请求、事实理由 |
| L1：`案件卷宗/03_对方文件/` 下的证据目录 | 第3优先 | 原告证据清单、证明目的 |
| L1：`案件卷宗/02_己方文件/` 下的答辩状/上诉状 | 第4优先 | 己方已确立的反驳立场 |
| L2：`工作底稿/` 下的案情分析报告/要件映射表 | 第5优先 | 在先分析结论 |
| L3：`资料收集/一审材料/`（二审/再审时） | 第6优先 | 一审/原审事实和证据 |
| L4：`资料收集/` 全部文件名+摘要 | 最后 | 检查是否存在明显遗漏 |

**PDF读取方式**（按优先级尝试）：

> **注意**：若以上方式均不用，使用原生Python二进制解析（解析PDF对象流、ToUnicode CMap映射表、hex字符串解码）提取文本。

**自动识别矛盾证据**：

> **"核心证据材料"层级区分**（代理被告时必须注意）：
> - **诉讼程序性文件**：起诉状、答辩状、裁定书、判决书、上诉状等——用于理解诉讼态势
> - **原始交易文件**：合同、补充协议、共管协议、往来函件、微信记录、会议纪要等——这才是案件事实的根基
> - 当用户要求"把核心证据材料找出来"时，应**优先呈现原始交易文件**，因为诉讼程序性文书用户通常已经阅读过，而原始交易材料才是需要AI辅助梳理的核心

**自动识别矛盾证据**：
- 时间线矛盾：比对原被告证据中的日期是否一致
- 金额矛盾：比对原告主张金额与证据显示金额
- 事实矛盾：比对双方对同一事件的描述差异

**输出证据矛盾清单**：
```
⚠️ 证据矛盾识别结果：
1. [时间矛盾] 原告起诉状称XXX vs 被告材料显示XXX
2. [金额矛盾] 原告主张XXX元 vs 证据显示XXX元
3. [待核实] XXX事项
```

### Step 3：确认诉讼目标
向用户确认：
- 我方当事人及代理身份
- 核心诉讼目标
- 优先级排序

> **注**：根据实践经验，本阶段不再确认"可接受方案/调解底线"，聚焦核心诉讼目标即可。调解策略可后续在诉讼方案或庭前准备中单独讨论。

### Step 4：梳理客观事实时间轴
按事件发生的先后顺序，客观还原"主体、时间、行为、结果、证据"。
- 不带入法律评价
- 标注准确日期
- 交叉验证不同证据间的时间一致性

### Step 5：主动提问澄清缺失信息
在以下情形下主动提问：
- 诉讼目标不明确
- 关键事实缺失
- 时间线断裂
- 证据存疑
- 法律关系模糊
- 存在多种可能性

### Step 6：法律事实剥离（要件法初筛）
过滤与法律规范构成要件无关的"生活事实"，提取五要素：**时间、地点、主体、行为、证据**。

### Step 6.5：案由自由扫描（第一层：放）🆕

> **本步骤为强制执行步骤**，不跳过。在进入要件锁定之前，必须先让 AI 从事实出发自由扫描可能的案由和法律关系，避免过早锁死在错误框架中。

**目的**：在未锁定具体案由的情况下，基于已剥离的法律事实，广泛扫描可能的案由类型。**不在本步骤过早加载精修版要件库。**

**执行流程**：

1. **读取 `references/请求权基础检索总表.md`**，确定本案的请求权基础大类方向（合同/侵权/物权/不当得利/人格权/婚姻家庭/继承/公司等）。

2. **读取 `references/案由请求权基础检视总览.md`**，搜索与本案核心事实最相关的 **2-5 个候选案由**：
   - 按"主张与诉请"匹配度排序
   - 列出每个候选案由的核心特征（2-3 句话）
   - 标注每个候选案由与本案事实的匹配度（高/中/低）

3. **输出候选案由排序表**：
   ```markdown
   ### 候选案由分析
   | 候选案由 | 核心特征 | 与本案匹配度 | 与本案的关键差异 |
   |:---|:---|:---|:---|
   | 案由A | （2-3句核心特征） | 高 | — |
   | 案由B | | 中 | （如适用） |
   | 案由C | | 低 | |
   ```

4. **向律师确认**：若案由存在明显多种可能性（匹配度均为"高"或"中"），或案由选择对诉讼策略有重大影响，**必须向律师展示候选案由并请求确认**。若案由高度明确（仅一个高匹配度候选且无竞争案由），可直接进入 Step 7.A。

> ⚠️ **严格禁止行为**：本步骤本步骤不加载精修版要件库（`案件类型要件库_{{类型}}.md`），不输出"根据某要件库，本案应适用..."等锁定性判断。保持扫描态。

### Step 6.6：中立评估——对方主张的合理性检验（代理被告时强制执行）

**目的**：在进入八模块分析前，必须抛开代理立场，以法官中立视角逐项检验对方每一项指控的事实基础和逻辑自洽性。只有诚实面对对方主张中的合理成分，才能设计出真正有效的防御策略。

**执行规则**：

1. **逐项检验每项指控的事实基础**：有证据支撑 → 部分有支撑 → 完全无支撑，标注证据来源
2. **逐项检验每项指控的逻辑自洽性**：逻辑自洽 → 存在内部矛盾 → 被己方其他证据削弱，标注矛盾点
3. **找出对方证据中对己方有利的内容**：对方自认、对方证据中的矛盾、对方证据证明的己方有利事实
4. **诚实标注对方主张中的合理成分**：不回避或美化。对本方不利的事实必须记录，不选择性忽略
5. **输出结论**：将对方指控按可信度排序（高/中/低），标注每项指控对己方的真实风险等级

**输出格式**（可嵌入分析报告争议焦点部分，或单独输出）：

| 对方指控 | 事实基础 | 逻辑自洽 | 合理成分 | 己方风险 |
|:---|:---|:---|:---|:---|
| 指控一 | 强/中/弱 | 自洽/部分矛盾/严重矛盾 | 有/部分有/无 | 高/中/低 |

**原则**：本步骤要求完全的智识诚实。如果某项指控确有一定道理，必须如实记录，不因代理立场而忽视或弱化。

### Step 7.A：要件锁定与映射（第二层：收）🆕

> **本步骤为强制执行步骤（阻断级）**，除非案由完全无法确定（应在 Step 6.5 向律师确认），否则不跳过。

**目的**：律师确认案由后（或案由高度明确时），加载精修版要件库，逐要件对照本案事实，输出要件映射表。**本步骤的输出是后续所有文书（03-10）的规范锚点，各子技能必须从此处继承要件分析结果。**

**执行流程**：

1. **加载要件库**：根据 Step 6.5 确认的案由，读取对应的 `references/案件类型要件库_{{类型}}.md`。**若 10 个要件库均未覆盖当前案由**，自动加载 `案由请求权基础检视总览.md` 搜索对应案由的完整检视程式。

2. **提取以下内容**：
   - a. 案由的构成要件（逐项列出，每项对应法条）
   - b. 常见抗辩与攻防焦点
   - c. AI 审查思考框架
   - d. 常见诉请主张（如有）

3. **逐要件映射本案事实**（核心产出）：
   ```markdown
   ### 要件映射表（本案）
   | 序号 | 构成要件 | 法条依据 | 规范性质 | 本案对应事实 | 满足状态 | 现有证据 | 待补强 |
   |:---:|:---|:---|:---:|:---|:---:|:---|:---|
   | 1 | （要件描述） | 《XX法》第X条 | 主要/辅助/抗辩 | （本案具体事实） | ✅满足 / ⚠️存疑 / ❌不满足 | （证据名称） | （如有） |
   ```

4. **输出攻防要点**（基于要件映射）：
   - **我方可攻击的薄弱要件**：标注对方要件中"存疑"或"不满足"的项
   - **我方需重点防守的要件**：标注我方要件中"存疑"的项
   - **关键证据缺口**：标注"待补强"列的汇总

5. **标注要件映射表的版本信息**：
   ```markdown
   > 📋 要件映射表
   > - 来源要件库：`案件类型要件库_{{类型}}.md`
   > - 生成时间：YYYY-MM-DD HH:MM
   > - 案由确认方式：[律师确认 / AI自判（案由高度明确）]
   > - 本表为后续子技能（03-10）的规范锚点
   ```

> ⚠️ **强制执行纪律**：
> - 要件映射表必须写入案情分析报告的「模块四」，替代原有的"请求权基础判断"自由描述
> - 本步骤必须逐要件对照，不仅列出要件名称而不映射本案事实
> - "满足状态"必须标注为 ✅满足 / ⚠️存疑 / ❌不满足，不含糊
> - **规范性质识别（强制）**：在填写"法条依据"列时，必须对照 `请求权基础检索总表.md` 的「二、核心请求权基础规范类型速查表」标注法条的规范性质（主要/辅助/抗辩）。**仅「主要」规范可以作为请求权基础的直接依据**；「抗辩」规范用于预判被告抗辩；「辅助」规范用于细化要件内容。

### Step 7.B：八模块结构化分析
**所有案件必须完整输出以下八个模块**：

> **模块四的变更说明**：模块四（请求权基础判断）的内容必须基于 Step 7.A 的要件映射表输出，不再使用 AI 自由分析。在报告中，模块四直接展示「要件映射表」+「攻防要点」。

#### 模块一：案涉主体及法律关系
- 识别所有当事人及其法律地位
- 必要时核查公开登记信息

> **🆕 企业主体信息核实（条件触发）**：
> 
> 当案件涉及企业主体（公司、合伙企业等）时，通过元典 MCP 自动核查企业工商登记信息，辅助主体身份确认和法律关系梳理。
> 
> **触发条件**（满足任一条即执行）：
> - 案件涉及公司股权、股东出资、抽逃出资、法人人格否认等公司类纠纷
> - 需要确认企业存续状态、股东结构、法定代表人等基础信息
> - 需要核实企业历史变更记录（如股权转让时间节点）
> - 需要确认母子/关联公司关系
> 
> **执行流程**：
> 
> 1. **企业搜索**——先通过名称获取企业 ID：
>    ```
>    mcp__yuandian-mcp__yuandian_rh_enterpriseSearch({name: "企业全称", top_k: 5})
>    ```
>    - 从候选结果中确认目标企业，获取 `id` 和 `tyshxydm`（统一社会信用代码）
> 
> 2. **基础信息查询**——获取企业完整基本信息：
>    ```
>    mcp__yuandian-mcp__yuandian_rh_enterpriseBaseInfo({id: "企业ID"})
>    ```
>    - 返回：基本信息 + 股东 + 十大股东 + 十大流通股东 + 核心成员 + 分支机构
>    - 提取与本案相关的内容：法定代表人、注册资本、成立日期、经营状态、股东结构
> 
> 3. **变更记录查询**（按需）——追溯历史状态：
>    ```
>    mcp__yuandian-mcp__yuandian_rh_enterpriseChangeInfo({id: "企业ID", pageNo: 1})
>    ```
>    - 用于核实关键时间节点的企业状态（如股权转让时的股东结构、增资/减资时间等）
>    - 按时间倒序排列，提取与案件相关时间段内的变更事项
> 
> 4. **输出整合**：在模块一中输出企业信息核实结果：
>    ```markdown
>    ### 企业主体信息核实
>    | 企业名称 | 统一社会信用代码 | 法定代表人 | 注册资本 | 成立日期 | 经营状态 |
>    |:---|:---|:---|:---|:---|:---|
>    | XX公司 | 91110000XXXXXXXX | 张三 | 1000万元 | 2010-01-01 | 存续 |
>    
>    **股东结构**（与案件相关部分）：
>    - 股东A：持股60%（与原告主张的持股比例一致/不一致）
>    - 股东B：持股40%
>    
>    **变更记录（与案件相关时间段）**：
>    - 2020-03-15：股权变更——股东C将30%股权转让给股东A
>    
>    **与案件核心事实的交叉验证**：
>    - ✅ 原告主张的持股比例与企业登记信息一致
>    - ⚠️ 被告主张的股权转让时间与企业变更记录不一致（被告主张2020-01，登记2020-03）
>    ```
> 
> > ⚠️ **使用纪律**：
> > - 企业信息核实为**辅助性工作**，不替代律师对主体资格的独立判断
> > - 查询结果以"初步核实"口径呈现，标注数据来源和查询时间
> > - 若元典 MCP 不用，使用 Web 检索或企查查/天眼查等公开渠道补充
> > - 如查询结果与当事人陈述不一致，标注为"⚠️存疑"并在模块一中提示

#### 模块二：主要时间线
- 按时间顺序排列关键事件
- 标注法律行为时点

#### 模块三：原告诉讼请求/诉讼目标
- 代理被告时：列出预判的原告请求
- 代理原告时：明确我方诉讼目标

#### 模块四：请求权基础判断
- 分析请求权基础（合同/侵权/不当得利/物权等）
- 判断构成要件是否满足

#### 模块五：事实及证据分析
- 代理原告：明确需证明的要件事实，设计证据组织方案
- 代理被告：分析对方证据缺失环节，规划应诉证据收集方向

#### 模块六：可能的争议点
- 预判事实争议与法律争议焦点

> **争点整理方法**（来源：要件审判方法论）。在预判争议焦点时，应综合运用以下方法，不仅凭主观判断：
>
> | 方法 | 操作 | 适用场景 |
> |:---|:---|:---|
> | **要件分析法**（推荐首选） | 以 Step 7.A 要件映射表为基础，逐要件审查：标注为「⚠️存疑」或「❌不满足」的要件 → 即为核心争议焦点 | 所有案件，尤其是案由明确、要件清晰的案件 |
> | **请求权基础分析法** | 从请求权基础的检索顺序出发，逐层审查：特别法请求权→身份法请求权→合同→类合同→无因管理→物权→人格权→侵权→不当得利 | 案由存疑、涉及多重请求权竞合的案件 |
> | **法律关系分析法** | 先确定本案核心法律关系（合同/侵权/物权/不当得利），再在该法律关系内审查各构成要件的争议 | 法律关系复杂、涉及多方主体的案件 |
> | **历史方法** | 按事件发生的时间顺序梳理争议点，关注每个关键节点的权利变动 | 时间跨度长、行为链条复杂的案件 |
> | **类比法** | 对照同类案由的典型案例，识别本案中与典型案例不同的争议点 | 新类型案件或疑难案件 |
> | **综合法** | 上述方法交叉使用，确保无遗漏 | 复杂案件 |

> **代理被告时争议焦点排序原则（强制）**：
> 争议焦点的分析必须严格遵循以下逻辑递进链：
> ```
> 原告诉请 → 原告主张的违约行为是否成立（逐项检验） → 该行为是否构成根本违约/致使合同目的不实现 → 我方是否存在抗辩事由（先履行抗辩/同时履行抗辩/对方违约在先等） → 合同解除权归属 → 法律后果（定金罚则是否适用）
> ```
> **不将己方反攻论点作为第一争议焦点（如"对方是否违约在先"）作为第一争议焦点。** 代理被告时，第一争议焦点必须锚定原告所主张的违约行为是否成立，逐项检验。我方的反攻论点应在原告主张检验完毕后，作为抗辩/反攻层面的争议焦点单独列出。

#### 模块七：下一步工作方向
- 列出待研究的法律问题
- 列出待核实的事实
- 列出待收集的证据清单
- 列出后续工作步骤

#### 模块八：核心事实归纳（脱敏版）
- 以**1个连贯段落文字**归纳核心事实，以连贯段落文字输出，不使用分点
- **字数控制**：控制在 **200-300字** 以内，力求精炼
- 对当事人姓名、具体时间、金额、公司名称、地点进行模糊化处理
- 涵盖：相关主体、主要事实、核心争议、待研究问题
- **用途**：本模块输出可作为案件高效摘要，用于向客户/合伙人介绍案情、起诉状事实素材、庭审陈述准备，以及复制到其他问答式AI中进行后续法律研究

### Step 8：确定进一步研究方向
基于前八个模块的分析，列出3-5个最值得深入研究的具体问题，帮助律师快速锁定研究重点。每个研究方向应包含：
- **具体问题**
- **研究意义**
- **预期产出**
- **建议研究方法**（法条检索/判例检索/学术文章/实务文章）

被告提出的某抗辩理由在实践中是否被支持？研究意义：提前准备反驳策略。预期产出：抗辩成立/不成立的判例对比分析。

### Step 9：法律研究启动（通道①自动执行，通道②/③/④手动触发）

在完成Step 7.B-8后，按以下规则启动法律研究：

- **通道①（Web检索）**：由AI**自动执行**，无需额外指令。
- **通道②（北大法宝MCP）**：**不自动启动**。如律师需要，由律师明确指示后手动启动。
- **通道③（元典MCP权威案例+语义检索）**：**不自动启动**。如律师需要，由律师明确指示后手动启动。
- **通道④（AI问答版提示词）**：**不自动调用AI工具执行**。AI仅在报告中生成并输出提示词，供律师自行复制到DeepSeek/ChatGPT等外部工具使用。

以下**四个并行的法律研究通道**说明：

#### 通道①：Web检索研究（同步执行）

- 任何案件必须检索人民法院案例库（https://rmfyalk.court.gov.cn/），优先指导性案例和参考案例。
- 结合研究方向进行 Web 检索补充，提取法条原文、条文解析、典型案例、法律论证、诉讼策略建议。
- 输出文件：`法律研究报告_四问专项研究.md`（保存至`工作底稿/`）

#### 通道②：北大法宝MCP法律研究（手动触发）
- 触发方式：需律师明确指示后执行。
- 执行动作：使用北大法宝 MCP 检索法条与案例，整理为结构化摘要。
- 输出文件：`法律研究报告_北大法宝通道.md`（保存至`工作底稿/`）

#### 通道③：元典MCP三层案例检索（手动触发）🆕

- 触发方式：需律师明确指示后执行（可通过“元典案例检索”“三层案例检索”等关键词激活）。
- 三层体系：权威层（`qwal_search`）→ 类案层（`case_vector_search`）→ 补充层（北大法宝 `search_case`）。
- 执行动作：按争议焦点逐层检索，提取案号、来源、裁判要旨，整合为《案例检索汇总表》。
- 输出文件：`法律研究报告_元典案例检索通道.md`（保存至`工作底稿/`）

#### 通道④：AI问答版研究提示词（仅输出，不自动调用AI执行）

- 输出可直接复制到 DeepSeek/ChatGPT 等通用 AI 的结构化研究提示词，AI 不自动调用外部工具执行。
- 提示词中必须嵌入：不编造法条/案例/案号/裁判要旨；无法核验的内容标注“需人工复核”；返回内容需经北大法宝/元典/裁判文书网回验后方可引用。
- 输出文件：将提示词嵌入案情分析报告。

### Step 10：更新前期工作成果索引

02 模块完成后，在 `办案记录.md` 的「前期工作成果索引」章节中更新 02 模块状态：

1. **更新 02 模块状态**：
   - 将 `### 02 案情梳理和法律分析（未完成）` 改为 `### 02 案情梳理和法律分析（[当前日期] 完成）`
   - 填写成果文件路径：
     - `工作底稿/YYYYMMDD_案情分析报告.md`
     - `工作底稿/YYYYMMDD_要件映射表.md`
     - `工作底稿/YYYYMMDD_案件关键事实基准表.md`
     - `工作底稿/YYYYMMDD_已验证引用清单.md`

2. **更新后续模块状态**：
   - 根据代理身份，将不适用模块标记为"不适用"
   - 将待执行模块的"前置依赖"状态更新为已满足

3. **更新团队协作状态**：
   - **最近处理人**：[当前操作者]
   - **最近处理时间**：[当前日期时间]
   - **最近执行模块**：02_案情梳理和法律分析
   - **当前阶段**：案情分析已完成，待起草[起诉状/答辩状]

**示例**：
```markdown
### 02 案情梳理和法律分析（2026-07-18 完成）
- 状态：已完成
- 前置依赖：01 已完成
- 成果文件：
  - `工作底稿/20260718_案情分析报告.md`（八模块结构化分析）
  - `工作底稿/20260718_要件映射表.md`（请求权基础分析）
  - `工作底稿/20260718_案件关键事实基准表.md`（事实基准线）
  - `工作底稿/20260718_已验证引用清单.md`（法条案例引用清单）

### 03 民事起诉状写作（未完成）
- 状态：待执行
- 前置依赖：02 已完成 ✅
```

## 输出前自检清单（必须逐条确认"是"）

- [ ] 代理方身份及诉讼目标已确认？
- [ ] PDF核心材料已读取（起诉状、证据目录、被告方材料）？
- [ ] **🆕 OCR 状态已检查**：读取 PDF 前已查询 `工作底稿/OCR状态.json`？状态为 `pending` 的文件已完成单文件即时 OCR？
- [ ] **证据矛盾已自动识别并标注**（时间/金额/事实矛盾）？
- [ ] 时间轴已按客观顺序梳理？
- [ ] 缺失信息已主动提问？
- [ ] **🆕 Step 6.5 案由自由扫描已执行**（民事案由请求权基础总览已加载，候选案由2-5个已列出）？
- [ ] **🆕 案由已确认**（律师确认或AI自判，案由高度明确）？
- [ ] **代理被告时：Step 6.6 中立评估已执行**（对方每项指控的事实基础、逻辑自洽性已逐项检验）？
- [ ] **🆕 Step 7.A 要件锁定与映射已执行**（要件库已加载，逐要件映射表已输出，满足状态已标注）？
- [ ] **代理被告时：Step 10「二之一、对方诉请及核心事实主张」已完整输出**（诉请、事实主张、证据清单、值得关注的细节）？
- [ ] **代理被告时：争议焦点排序已遵循"原告指控→违约成立→根本违约→我方抗辩→解除权→后果"的逻辑链**？我方反攻论点未被设为第一争议焦点？
- [ ] **🆕 企业主体信息核实**（如涉及企业主体）：元典 enterpriseSearch/enterpriseBaseInfo 已查询？变更记录与案件关键时间节点已交叉验证？
- [ ] **🆕 Step 9.5 策略发散已执行**（要件内攻击点、替代案由、储备论点、关键风险已输出）？
- [ ] 模块八采用段落式文字而非列表？
- [ ] 报告内无"因此...""结论是..."等确定性判断？
- [ ] **通道①Web检索已自动执行**（法律法规、典型案例检索完成）？
- [ ] **🔴 人民法院案例库已强制检索**（记录入库编号、案例标题、裁判要旨，并标注参考价值）？
- [ ] **元典MCP检索**如需启动，已获律师明确指示？
- [ ] **北大法宝MCP检索**如需启动，已获律师明确指示？
- [ ] **AI问答版提示词已在报告中输出**（Step 10「七、法律研究提示词」已生成，且提示词中已包含"严格编造法条、案例、案号、法院"的严格禁止性要求）？
- [ ] **元典三层案例检索（如已启动）：** 权威层(qwal_search)已优先检索？类案层(vector_search)已补充？冲突案例已标注并说明取舍？
- [ ] **🆕 已验证引用清单是否已生成并保存至`工作底稿/YYYYMMDD_已验证引用清单.md`？**（仅含已验证引用，不含待核实项）
- [ ] 法律研究报告/备忘录已整合研究成果？
- [ ] **🆕 Step 10 前期工作成果索引已更新**（`办案记录.md` 中 02 模块状态已标记为完成，成果文件路径已列出）？
- [ ] `办案记录.md` 已更新沟通记录和待办事项？
- [ ] **所有产出文件已按 `YYYYMMDD_内容简述_身份后缀` 格式命名？**
- [ ] **诉讼文书副本已同步归入 `案件卷宗/`（如适用）？**
- [ ] **案情分析报告已保存至 `工作底稿/`**？
- [ ] 正文中所有法条引用是否均已完成外部检索核验（优先北大法宝 MCP `get_article`/`search_article`）？是否有仅依赖 AI 记忆而未经验证的法条引用？
- [ ] 正文中所有案例引用是否均标注了完整案号和检索来源（优先北大法宝 MCP `search_case`）？是否有无案号的案例引用？
- [ ] **外部 AI 返回的法条/案例是否已通过北大法宝/元典/裁判文书网等权威渠道重新核验？是否存在未核验即写入正文的情况？**
- [ ] 是否存在"【待核实】"标记未向用户报告的情况？
- [ ] 法条引用是否为全句引用？是否存在"依据《XX法》相关规定"等模糊表述？