regulatory-incoming-letter

name	regulatory-incoming-letter
description	处理监管下发函件（行政处罚通知 / 责令整改 / 监管谈话 / 程序性通知 / 专项自查工作函 / 监管问询）的全流程：录入 + 6 分法自动归类 + 任务派发 + 进度跟踪 + 上报材料汇总。本土化版的核心亮点 —— 原版 regulatory-legal 没有这条主线。用户说"我们收到 [监管单位] 一份 [函件类型]"、"监管下发了"、"工作函"、"自查通知"、"约谈"、"监管问询"、"警示函"、"行政处罚决定书"，或上传函件 PDF / 扫描件时使用。
argument-hint	[函件文件路径 或 粘贴函件文本]

/incoming-letter

1. 读 $LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md → 公司画像、escalation_path、归口部门联系人
2. 用下面的 7 阶段工作流
3. 录入（OCR + 字段抽取）→ 自动归类（6 分法）→ 按类处置 → 任务派发 → 进度跟踪 → 上报材料汇总 → 闭环
4. 关键截止日自动锁到监管要求回复期前的内部缓冲日期（默认 5 个工作日）

---

事项上下文

事项上下文：核查实务层级 profile.md 中 ## 事项工作区。如果 启用 是 ✗（企业内部法务用户默认），跳过本段 —— 技能用实务层级上下文，事项机制不可见。如果启用且没有当前事项，问："这是哪个事项？跑 regulatory-matter-workspace switch <slug> 或说切到实务层级。"

对监管下发函的特殊处理：每一份独立的监管函件都可以视作一个独立事项（特别是涉及处罚 / 约谈类高风险函件）。建议在私人执业场景下为重要函件单独建事项，企业内部法务场景下走实务层级 + 内规差异台账（gap-tracker.yaml）跟踪。

---

用途

中国企业内部法务最高频的工作是响应监管下发的函件 —— 这与原版的"主动监控"工作流方向相反，是本土化版的核心增量。本技能处理：

• 接收：纸质函件扫描、邮件附件、监管平台推送（如金管总局检查通报系统、网信办约谈通知等）
• 理解：抽取关键字段（来文单位、文号、要求事项、回复期限）
• 分类：按 6 分法判定函件类型，决定处置路径
• 派发：根据要求事项拆解为内部整改任务（inspection-task），按归口部门派到具体负责人
• 跟踪：截止日三档预警（30 / 15 / 5 天，反映监管截止日的硬刚性）
• 上报：到期前自动汇总各部门提交的整改材料，生成上报草稿
• 闭环：等监管回函（通过 regulatory-reg-feed-watcher（监管动态监测）或人工录入），决定是否结案

与 regulatory-reg-feed-watcher（监管动态监测）的区别：

• 监管动态监测：主动监控 —— 抓取监管公开发布的规则、处罚通报、答记者问等
• 监管来函处置：被动响应 —— 处理监管直接发给本公司的函件（有明确受文单位 = 本公司）

监管动态监测可能会捕获到"金管总局自查工作函"等普遍性通知，如本公司也是受文单位，应转入本技能（监管来函处置）流程做完整处置。

---

第 1 步：录入与字段抽取

1.1 接收来源

支持三种入口：

• 文件路径：用户上传 PDF / 图片扫描件 / Word 等到工作目录或文档存储
• 粘贴文本：函件正文已 OCR / 转写好的纯文本
• 手工字段输入：监管平台推送的结构化数据，用户手工填关键字段

1.2 字段抽取（调用能力 document.extract_fields）

调用 document.extract_fields 能力抽取以下字段（必填项 ✱）：

字段	必填	说明
来文单位 ✱	是	具体监管机构名称（如"国家金融监督管理总局上海监管局"、"国家网信办网络数据管理局"），含层级（中央 / 省 / 市）
文号 ✱	是	格式如 沪金监函〔2026〕XX 号 —— 关键追溯标识
收文日期 ✱	是	公司实际收到的日期（不是函件落款日期），可能差几天
落款日期	否	监管在函件上的落款日期
函件名称 ✱	是	如《关于开展消费金融业务合规自查的工作函》
函件类型 (初判)	否	字段抽取大模型的初步判断，第 2 步会用 6 分法重新核定
受文单位 ✱	是	必须是本公司全称（如果不是 → 函件转错，确认后退回）
抄送范围	否	其他抄送方（如"抄送：上海地方金融监管局")
要求事项 ✱	是	列表，从函件正文抽取每条具体要求（如"自查放贷利率合规性、自查营销话术合规性、提交自查报告"等）
回复期限 ✱	是	监管要求公司提交回复 / 整改报告的最晚日期。如函件用"X 日内"等相对表述，结合收文日期计算
是否要求书面回复	否	如"以书面形式提交"、"提交整改报告"
是否要求面谈 / 到场	否	如"派分管负责人参加 X 月 X 日座谈"
是否含听证 / 申辩告知	否	如有 → 触发第 4 类程序性通知 的紧急路径
提交方式	否	如"密码邮件至 [e-mail]"、"现场提交"、"挂号信"
执法人员 / 联系人	否	函件中署名的执法人员或具体联系人电话
附件清单	否	函件附带的清单、自查表等

抽取后必须给用户人工核对，特别是 ✱ 必填字段。在大模型抽取结果旁标 [抽取自第 X 段] 让用户能溯源核对。

1.3 抽取结果保存

抽取后落地为结构化 YAML 文件到 $LEGAL_AGENT_PROFILE_HOME/regulatory-legal/incoming-letters/<letter-id>/letter.yaml，附原始扫描件 / 文本副本到同目录。

letter-id 命名建议：YYYY-MM-DD-<监管缩写>-<文号尾号>，例如 2026-05-25-金管沪-XX。

---

第 2 步：自动归类（6 分法 + 子类）

按以下决策树自动归类（详细分类规则见 references/letter-classification-rules.md）：

是否含"作出行政处罚决定 / 罚款 / 没收 / 暂停业务 / 吊销许可"等表述？
├── 是 → 第 1 类 行政处罚类
└── 否
    │
    是否含"事先告知 / 听证通知 / 陈述申辩告知"等表述？
    ├── 是 → 第 4 类 程序性通知类（行政处罚法第 44-47 条）
    └── 否
        │
        是否含"约谈 / 监管谈话 / 派负责人到场说明"等表述？
        ├── 是 → 第 3 类 监管谈话类
        └── 否
            │
            是否含"现场检查 / 现场检查意见书"等表述？
            ├── 是 → 第 2 类（子类 2b）行政监管措施—现场检查反馈
            └── 否
                │
                是否含"自查 / 专项整改 / 排查"等表述？
                ├── 是 → 第 5 类 专项自查 / 工作函类
                └── 否
                    │
                    是否含"说明情况 / 反馈材料 / 提供资料"等表述？
                    ├── 是 → 第 6 类 监管问询类
                    └── 否（默认）→ 第 2 类（子类 2a）行政监管措施—责令整改

归类后输出给用户人工确认（除非置信度 > 0.95）：

"根据要求事项和函件语言，初判为第 X 类（[类别名]）。处置路径：[简短说明]。 确认归类后我会触发对应处置流程。如归错，请告诉我正确类别。"

---

第 3 步：按类别选择处置路径

第 1 类：行政处罚类

触发动作：

1. 法定时效核查（最高优先级，当天完成）：

   • 行政复议申请期限：60 日（《行政复议法》第 9 条），自收到决定书之日起算
   • 行政诉讼期限：6 个月（《行政诉讼法》第 46 条），自知道或者应当知道作出行政行为之日起算
   • 特别注意：证监会等特别监管领域可能有更短的复议期，需对照具体法规
   • 在 letter.yaml 中记录两个法定截止日：reconsider_deadline、litigation_deadline

2. 法务总监 + 首席合规官紧急会签（escalation_path.重大业务影响决策）：

   • 是否接受处罚？
   • 是否申请行政复议？
   • 是否提起行政诉讼？
   • 是否进行公司内部责任追究？

3. 内部整改任务派发：将处罚决定中"责令整改"部分拆解为 inspection-task

4. 舆情准备：如处罚涉及公众披露（上市公司、消费者保护类），同步触发产品 / 公关部门信息披露评估

关键风险点：处罚事实的认定 + 处罚程序的合法性 + 是否有从轻 / 从重 / 不予处罚情节未被采纳 —— 这些是后续复议 / 诉讼的核心争点。

第 2 类：行政监管措施类（子类 2a 责令整改 / 2b 现场检查反馈）

触发动作：

1. 时效核查：

   • 多数监管措施类决定也可申请行政复议 / 诉讼，但时效与处罚相同（60 日 / 6 月）
   • 警示函 / 监管意见书在部分领域被认为"不可诉"（如证券公司收到证监会警示函），但 2020 年以来司法实务有变化，建议保留复议 / 诉讼路径

2. 限期整改 → 拆解为 inspection-task：

   • 子类 2a（责令整改）：整改任务通常较具体，按业务部门派单
   • 子类 2b（现场检查反馈）：常伴检查发现的问题清单，需逐项拆解 + 内部根因分析

3. 整改报告（如要求书面回复）：

   • 收文 + 缓冲 30/15/5 天三档预警
   • 到期前 X 天自动汇总各部门提交材料 → 上报草稿

第 3 类：监管谈话类

触发动作：

1. 派人到场的准备：

   • 谁去？默认派"业务对应分管 + 法务"组合，按 escalation_path.重大业务影响决策 决定具体人选
   • 准备材料：本次涉及业务的近期数据、合规自查结论、已经采取的措施

2. 谈话纪要的处置：

   • 谈话结束后几天内通常会有"约谈通报"或"谈话纪要"发回
   • 如要求出具书面承诺 / 整改计划：拆解为 inspection-task

3. 是否触发行政复议 / 诉讼：一般认为单独的监管谈话不可诉（不直接产生权利义务变动），但约谈通报如含"责令整改"等内容，按第 2 类处理

第 4 类：程序性通知类（新增，原 6 分法没有）

触发动作 —— 这是法定程序，时效极短，错过有不利后果：

1. 听证申请期限：收到事先告知书之日起 3 个工作日内（行政处罚法第 47 条）。当天计算，预留 1 个工作日内部决策缓冲。

2. 陈述申辩准备：

   • 行政处罚法第 44 条：拟作出行政处罚决定前，应告知拟作出的内容、依据、事实
   • 陈述申辩材料应当指向：事实认定有误 / 法律适用不当 / 程序违法 / 从轻减轻情节

3. escalation_path.重大业务影响决策 紧急触发：

   • 是否申请听证？
   • 是否提交陈述申辩？
   • 谁去陈述 / 听证？

4. 法务 + 外聘律师协同：建议立即启动外聘律师介入（特别是听证）

第 5 类：专项自查 / 工作函类

触发动作：

1. 要求事项拆解为 inspection-task：

   • 14 条自查事项 → 14 个 inspection-task
   • 每条任务自动匹配归口部门（按 policy_owner 索引）
   • 整改负责人按业务部门指派（task_owner）

2. 进度跟踪：30 / 15 / 5 天三档预警

3. 上报材料汇总（到期前 X 天）：

   • 自动收集各部门提交的自查材料
   • 按监管要求格式生成上报草稿
   • 走法务总监 + 首席合规官会签后由法务联系人提交

第 6 类：监管问询类

触发动作：

1. 判断问询性质：

   • 普通问询函（如证监会问询）—— 要求公司说明情况、提供材料
   • 关注函（深沪交易所对上市公司）—— 监管关注但不必然导致后续动作
   • 信息核实函（如反洗钱可疑交易核实）—— 涉具体客户 / 业务的事实问询

2. 回函起草：

   • 按监管问询事项逐条回应
   • 涉具体客户 / 业务数据需脱敏处理
   • 不要主动披露问询范围外的事项

3. 是否触发后续监管动作：问询本身一般不直接产生权利义务，但回函内容会被监管援引，故回函质量决定后续走向

---

第 4 步：任务派发（拆解为 inspection-task）

将函件要求事项拆解为 N 条 inspection-task 类型的整改事项，写入 $LEGAL_AGENT_PROFILE_HOME/regulatory-legal/gap-tracker.yaml：

gaps:
  - id: INS-001                            # 函件相关任务 ID 用 INS- 前缀（区别于 GAP- 前缀的政策内规差异）
    requirement: "自查放贷利率合规性 —— 是否符合金管总局新规第 X 条"
    regulation: "金管总局《关于开展消费金融业务合规自查的工作函》 沪金监函〔2026〕XX 号"
    policy_affected: "消费金融业务合规手册"
    gap_type: "inspection-task"            # 阶段 3 启用的新类型
    inspection_letter_id: "2026-05-25-金管沪-XX"  # 关联到 letter.yaml
    inspection_category: "第 5 类 专项自查"  # 来自第 2 步的归类结果

    # 负责人模型（与 gap-surfacer 的结构定义 v2 对齐）
    policy_owner:
      name: "王琳"
      department: "法务部"
      dm_id: "feishu_xxx"
    task_owner:
      name: "张总"
      department: "业务一部"
      dm_id: "feishu_yyy"

    # 时效
    opened: 2026-05-25
    due: 2026-06-19                        # 监管要求回复期 - 5 个工作日内部缓冲
    regulatory_deadline: 2026-06-24        # 监管要求的硬截止日
    status: "open"
    status_verified: true                  # 函件来源已核实（监管直接下发）

    # 任务派发追踪
    notified_task_owner: false
    notified_policy_owner: false
    reminders_sent: []

    # 上报追踪
    submission_required: true              # 是否需要纳入上报材料
    submission_received: false             # 是否已收到业务部门反馈
    submission_received_date: ""           # 收到反馈的日期
    submission_content: ""                 # 业务部门提交内容摘要

    source_tags:
      - "[监管下发函]"
      - "[金管总局公开栏目]"

派发后逐条预审给法务联系人审核后才发 DM（继承 regulatory-gap-surfacer（内规差异呈现）的逐条预审 + 显式批准规则）。

---

第 5 步：进度跟踪

复用 regulatory-gap-surfacer（内规差异呈现）的提醒机制，但 inspection-task 用三档预警（比常规内规差异更紧）：

距离监管截止日	提醒动作
30 天	一次预提醒给 task_owner（"监管要求 30 天后提交，开始动手"）
15 天	二次提醒，抄送 policy_owner
5 天	三次紧急提醒，task_owner + policy_owner + escalation_path.重大业务影响决策
已超期（监管截止日已过且未上报）	🔴 红色告警，立即上报 escalation_path.最终决策 + 法务总监紧急会议

提醒发送严格走 notification.preview_and_send 能力 + 逐条预审。

---

第 6 步：上报材料汇总

监管截止日前 X 个工作日（默认 5 天，可在冷启动访谈中配置），自动汇总：

6.1 收集

• 遍历该 inspection_letter_id 下的所有 inspection-task
• 收集每条任务的 submission_content、submission_received_date
• 标识缺失项（仍未收到反馈的任务）

6.2 生成上报草稿

按 references/report-material-template.md（上报材料模板）中的格式生成草稿：

# [函件名称] 整改 / 自查报告

致：[来文单位]
关于：[函件名称]
文号引用：[文号]
公司名称：[本公司]

---

## 一、回应概述

本公司收到贵 [局 / 委] 于 [日期] 下发的 [函件名称]（[文号]），高度重视，
立即组织相关部门开展自查 / 整改工作。现将工作情况报告如下：

## 二、整改 / 自查事项明细

### 事项 1：[要求事项 1]

**整改情况**：
[业务部门提交的内容]

**已完成 / 进行中 / 风险接受**：[状态]

**支持材料**：[附件清单]

[逐条罗列每个 `inspection-task`]

## 三、整体结论

[整改 / 自查整体结论。如有未完成项需诚实说明，给出后续时间表]

## 四、本公司承诺

[本公司就本次自查 / 整改作出的承诺]

---

附件：
- 附件 1：[支持材料 1]
- 附件 2：[支持材料 2]
- ...

公司盖章：[公章位置]
签发人：[签字]
日期：[日期]
联系人：[姓名 + 电话]

6.3 走会签

按 escalation_path：

• 法务负责人初审
• 首席合规官（CCO）复审
• 总经理 / 法定代表人签字（如要求公章 + 法人签字）
• 法务联系人提交

6.4 提交追踪

提交后在 letter.yaml 中记录 submission_date、submission_method（密码邮件 / 现场 / 挂号信）、submission_receipt（监管收讫回执）。

---

第 7 步：闭环

等监管回函：

• 提交后通常 7-30 天内收到回函（监管确认收讫 / 提补充要求 / 通过验收 / 启动下一轮）
• 通过 regulatory-reg-feed-watcher（监管动态监测）监控相关监管栏目，或通过邮箱 / 收发室人工录入回函
• 回函如要求"补充材料"或"再次自查" → 进入新一轮监管来函处置流程（同一 letter-id 下加 round: 2）
• 回函如确认"通过验收 / 不再追究" → 标 letter.yaml 的 status: closed + 同步关闭关联的 inspection-task

长期未收到回函（>60 天）：

• 标 status: 待回函
• 不自动关闭，但移出活跃台账显示
• 重要函件（处罚类 / 重大整改类）保持关注，重要节点（如周年）触发"回函未到提醒"

---

重大动作确认环节（按函件类别分档触发）

当前动作	触发 escalation_path 字段	提示内容
第 1 类 行政处罚：决定是否复议 / 诉讼	重大业务影响决策 + 法务总监 + 首席合规官联签	"本动作涉及处罚决定的法定救济。业务规范显示需要 [角色] 拍板。是否已上报？"
第 4 类 程序性通知：决定是否申请听证 / 陈述申辩	重大业务影响决策（紧急）	"听证申请期限 3 个工作日。业务规范显示需要 [角色] 立即拍板。"
第 1 / 2 / 3 / 5 / 6 类：提交上报材料 / 整改报告 / 回函	重大业务影响决策 + 会签	"本动作进入监管档案，作为公司正式表态。业务规范显示需要 [角色 A] + [角色 B] 会签。是否完成？"
任一类：标某 inspection-task 为风险接受	显著不符合项目会签	"风险接受是有意识的合规决策。需要 [角色] 签字。是否已完成？"
任一类：关闭整个函件（status: closed）	首道审核（法务确认）	"确认本函件相关整改均已完成且监管已确认。是否标记为关闭？"

未明确"是"前不触发对应动作。

---

输出

[工作秘密标识 —— 按 ## 谁在用这个插件 + shared/header-by-role.md 选定，通常为"内部合规分析 — 公司内部使用"]

> **⚠️ 复核提示**
> - **来源**：函件 [letter-id]（原件保存在 $LEGAL_AGENT_PROFILE_HOME/regulatory-legal/incoming-letters/[letter-id]/）
> - **分类**：第 X 类 [类别名] —— [简短依据]
> - **关键截止日**：监管要求 [日期]，内部缓冲 [日期]
> - **拆解任务**：[N] 条 `inspection-task`，[已分配 / 待分配]
> - **需要你判断的事项**：[N 项已用 `[复核]` 内联标注]

## 监管来函处置工单：[函件名称]

**来文**：[来文单位] [文号]
**收文**：[收文日期]
**函件类型**：第 X 类 [类别名]
**回复期限**：[日期]（剩 [N] 天）

### 字段抽取结果

| 字段 | 值 |
|---|---|
| 来文单位 | [...] |
| 文号 | [...] |
| 函件名称 | [...] |
| 要求事项 | [...] |
| 回复期限 | [...] |
| 抄送范围 | [...] |
| ...（其余字段） | ... |

### 6 分法归类依据

[函件文本中触发归类的关键短语 + 类别置信度]

### 处置路径

[按类别的具体动作清单，含时效 / 责任人 / 必要文档]

### `inspection-task` 拆解

| ID | 要求事项 | 归口部门 | 整改负责人 | 截止日 |
|---|---|---|---|---|
| INS-001 | [...] | [...] | [...] | [...] |
| ...（共 N 条） | | | | |

### 下一步必做

1. [紧急动作 1，如"3 个工作日内决定是否申请听证"]
2. [紧急动作 2]
3. [常规动作]

---

**下一步？选一个我来展开**：

1. **派发任务** —— 我把 [N] 条 `inspection-task` 通过 DM 通道（逐条预审）发给负责人
2. **触发会签** —— 我起草给法务总监 + 首席合规官的简报，含函件全文 + 分类依据 + 待决策点
3. **追加补充信息** —— 我注意到 [事项] 在函件中表述含糊，需要 [获取来源] 进一步确认
4. **打开任一任务详情** —— 告诉我 INS-XX，我展开任务的细节 + 起草给具体负责人的 DM
5. **生成上报材料草稿** —— 各部门反馈到位后，我按 `references/report-material-template.md`（上报材料模板）生成草稿
6. **其他** —— 告诉我

**清单之外我会问的一个问题**：[本函件中可能被遗漏但有影响的事项 —— 如"本次自查范围是否会牵出关联问题"、"抄送方上海地方金融监管局是否会单独跟进"等]

---

与其他技能的协作

上游 / 下游	协作方式
regulatory-reg-feed-watcher（监管动态监测） ←	如果监管信息源中识别到"针对本公司"的工作函（通常通过反向匹配关注清单 + 公司全称），转入本技能处理
regulatory-gap-surfacer（内规差异呈现） →	inspection-task 写入 gap-tracker.yaml，复用其内规修改跟进 / 提醒 / 关闭机制
regulatory-policy-diff（政策比对） →	函件中如涉及具体监管规则（如新发布的部门规章），可触发政策比对对照公司政策库分析
regulatory-policy-redraft（政策修订红线） →	整改过程中如需修订内部政策，触发政策修订红线起草修订草案
regulatory-customize（个性化调整） →	用户可通过个性化调整：上报材料缓冲天数、字段抽取置信度阈值、各类别的默认负责人

---

配置依赖降级

配置项缺失	行为
document.extract_fields 能力未配置	退化为纯文本输入模式（用户粘贴文本而非上传 PDF），其他流程不变
escalation_path 未配置	重大动作确认环节降级为通用提示，不路由到具体角色
政策库索引未填写归口部门	inspection-task 派不到 task_owner，标"未跟进"，由冷启动访谈流程引导用户填
关键截止日未识别（监管函件中文表述含糊）	停下来问用户，不擅自补

---

收尾决策树

按 profile.md 中 ## 输出 的决策树收尾。对监管下发函的特殊性：

• 决策树的"选项 2 上报 / 会签"通常是高优先 —— 监管函件多数会涉及对外提交，需要会签链
• 决策树的"选项 4 观察等待"对监管函件慎用 —— 监管截止日是硬刚性的，不响应有处罚后果

---

本技能不做的事

• 不起草处罚决定的复议申请书 / 诉讼起诉状（这是律师代理工作的专业内容，本技能仅触发"建议启动外聘律师"的提示）
• 不起草听证申请书 / 陈述申辩书（同上，建议外聘律师介入）
• 不判定监管处罚 / 措施的合法性（这是法律意见，需律师出具）
• 不自动提交上报材料（必须经法务负责人 + 首席合规官会签 + 法定代表人 / 法务联系人手工提交）
• 不自动监控监管回函（与 regulatory-reg-feed-watcher（监管动态监测）协作 + 人工录入兜底，不替代秘书 / 收发室）
• 不做监管沟通策略建议（如"要不要主动联系执法人员"等 —— 这是合规 / 公关策略，超出本技能范围）

详细 6 分法处置规则见 references/letter-classification-rules.md；inspection-task 模板见 references/inspection-task-template.md；上报材料模板见 references/report-material-template.md。