Delete .trae

.trae/specs/build-peer-reg-crawler/checklist.md

@@ -1,10 +0,0 @@
-- [x] source_registry 数据模型与 API 契约完整（含枚举、字段、错误码）
-- [x] sources 管理 API 可用（新增/列表/更新/启停）
-- [x] jobs 触发与查询可用（manual trigger + 状态查询）
-- [x] raw_snapshot 可追溯（包含 http_status/final_url/raw_hash/原始内容）
-- [x] normalized_document 生成稳定，且 normalized_hash 去重生效
-- [x] clause_chunk 可生成（章节/条款级切片 + topic_tags）
-- [x] diff_event 可生成（added/removed/modified + 片段对比）
-- [x] updates 供数接口可用（topics/since/limit 过滤，输出结构符合 AGENT-01 输入契约）
-- [x] 定时调度与失败重试策略生效（含 degraded 标记）
-- [x] 至少 6 个白名单来源完成一次端到端抓取验证并能产出变化包

.trae/specs/build-peer-reg-crawler/spec.md

@@ -1,57 +0,0 @@
-# 同业/监管抓取子系统（AGENT-00）Spec
-
-## Why
-当前 AGENT-01 仅能消费上游提供的 `peer_updates` / `regulatory_updates`，缺少一个稳定的“找、抽、比、存”能力层，导致同业与监管依据来源、版本与条款回链不可控，难以进入客户内测与审计要求。需要构建一个独立于 AGENT-01~04 之外的抓取与检索子系统（AGENT-00），输出可追溯、可版本化、条款级的结构化变化包。
-
-## What Changes
-- 新增 AGENT-00 抓取与检索子系统：来源白名单管理、定时/手动抓取、正文抽取、文本标准化、版本去重、条款切片、主题标注、版本比对、结构化入库、对外查询 API。
-- 向 AGENT-01 提供稳定输入接口：`GET /api/crawler/updates` 输出 `peer_updates` / `regulatory_updates` / `sdk_updates`。
-- 定义抓取子系统的最小可落地数据模型：`source_registry`、`crawl_job`、`raw_snapshot`、`normalized_document`、`clause_chunk`、`diff_event`。
-
-## Impact
-- Affected specs: 上游数据供给与审计链路（为 AGENT-01 提供可追溯输入）
-- Affected code: 将新增 crawler 子系统模块（服务端 API、存储层、抓取与解析流程、定时调度）
-
-## ADDED Requirements
-### Requirement: 白名单来源管理
-The system SHALL 提供来源注册表（source_registry）用于管理白名单来源，禁止在代码中硬编码 URL。
-The system SHALL 支持来源启停、抓取频率、解析器类型、主题标签等配置。
-
-#### Scenario: 新增来源
-- **WHEN** 管理员调用 `POST /api/crawler/sources` 提交来源配置
-- **THEN** 返回 `source_id`，并在后续抓取调度中可被读取
-
-### Requirement: 抓取与正文抽取
-The system SHALL 支持 HTML 页面抓取与正文抽取，输出标题、更新时间/生效时间（若可识别）、章节结构与正文。
-The system SHALL 保留原始快照（raw_snapshot），确保可回溯审计。
-
-#### Scenario: 手动触发抓取
-- **WHEN** 调用 `POST /api/crawler/jobs` 并指定 source_ids
-- **THEN** 生成 `crawl_job` 记录并进入 queued/running/success/failed 生命周期
-
-### Requirement: 版本去重与条款级切片
-The system SHALL 对抓取结果做标准化后计算 `raw_hash` / `normalized_hash`。
-The system SHALL 在 `normalized_hash` 不变时不生成新版本。
-The system SHALL 将标准化文档拆分为条款切片（clause_chunk），至少包含 section_path/section_title/clause_text/topic_tags。
-
-#### Scenario: 去重
-- **WHEN** 同一来源再次抓取且 normalized_hash 未变化
-- **THEN** 不创建新的 normalized_document 版本
-
-### Requirement: 版本比对与变更事件
-The system SHALL 对同一来源新旧版本输出 diff_event（added/removed/modified），并提供变化章节片段（old_excerpt/new_excerpt）与 topic_tags。
-
-### Requirement: 对 AGENT-01 的供数接口
-The system SHALL 提供 `GET /api/crawler/updates` 返回结构化变化包，支持 topics/since/limit 过滤。
-The system SHALL 在每条变化中包含来源、版本与条款片段（excerpt）以支撑 AGENT-01 的审计回链。
-
-#### Scenario: 获取变化包
-- **WHEN** 调用 `GET /api/crawler/updates?topics=sdk_disclosure,permission_usage&since=2026-04-01`
-- **THEN** 返回 peer_updates/regulatory_updates/sdk_updates，并且每条包含 source_name/source_type/version_date/topic_tags/changed_sections[]
-
-## MODIFIED Requirements
-无
-
-## REMOVED Requirements
-无
-

.trae/specs/build-peer-reg-crawler/tasks.md

@@ -1,48 +0,0 @@
-# Tasks
-
-- [x] Task 1: 定义抓取子系统数据模型与对外 API 契约
-  - [x] SubTask 1.1: 明确 `source_registry` / `crawl_job` / `raw_snapshot` / `normalized_document` / `clause_chunk` / `diff_event` 的字段与枚举
-  - [x] SubTask 1.2: 定义抓取子系统错误码（4001-4004, 5001-5004）与返回结构
-  - [x] SubTask 1.3: 定义对外 API（sources/jobs/documents/diff-events/updates）的 request/response JSON 结构
-
-- [x] Task 2: 实现来源白名单管理 API
-  - [x] SubTask 2.1: 实现 `POST /api/crawler/sources` 新增来源
-  - [x] SubTask 2.2: 实现 `GET /api/crawler/sources` 来源列表与过滤
-  - [x] SubTask 2.3: 实现来源启停/更新（如 `PATCH /api/crawler/sources/{source_id}`）
-
-- [x] Task 3: 实现抓取任务与快照存储
-  - [x] SubTask 3.1: 实现 `POST /api/crawler/jobs`（manual trigger），创建 crawl_job 并执行抓取
-  - [x] SubTask 3.2: 实现 `GET /api/crawler/jobs/{jobId}` 查询任务状态
-  - [x] SubTask 3.3: 落地 raw_snapshot（存原始响应体、状态码、final_url、raw_hash）
-
-- [x] Task 4: 实现正文抽取与标准化
-  - [x] SubTask 4.1: 实现 HTML 正文抽取策略（过滤导航/页脚等噪音）
-  - [x] SubTask 4.2: 实现文本标准化（空白折叠、全角半角、章节编号识别、日期标准化）
-  - [x] SubTask 4.3: 生成 normalized_document 并做版本去重（normalized_hash）
-
-- [x] Task 5: 实现条款切片、主题标注与版本比对
-  - [x] SubTask 5.1: 将 normalized_text 切分为 clause_chunk（章节路径/标题/正文/顺序）
-  - [x] SubTask 5.2: 实现最小主题标注（可先基于关键词规则，后续可升级）
-  - [x] SubTask 5.3: 实现 diff_event 生成（added/removed/modified）与 impact_level 初版规则
-
-- [x] Task 6: 实现供 AGENT-01 使用的更新查询 API
-  - [x] SubTask 6.1: 实现 `GET /api/crawler/updates`（topics/since/limit 过滤）
-  - [x] SubTask 6.2: 实现 `GET /api/crawler/documents` 与 `GET /api/crawler/diff-events`（用于排障与验证）
-  - [x] SubTask 6.3: 为 updates 输出结构对齐 AGENT-01 的输入契约（peer_updates/regulatory_updates/sdk_updates）
-
-- [x] Task 7: 定时调度与失败重试
-  - [x] SubTask 7.1: 实现 schedule trigger（按 source_registry.crawl_frequency）
-  - [x] SubTask 7.2: 实现失败重试策略（10分钟后重试1次；连续失败降级标记）
-
-- [x] Task 8: 验证与回归
-  - [x] SubTask 8.1: 为 10~20 个白名单种子来源做至少一次抓取验证（可先选 3 个银行 + 2 个监管 + 1 个 SDK）
-  - [x] SubTask 8.2: 验证去重、版本比对与 updates 输出完整性
-
-# Task Dependencies
-- Task 3 depends on Task 1, Task 2
-- Task 4 depends on Task 3
-- Task 5 depends on Task 4
-- Task 6 depends on Task 5
-- Task 7 depends on Task 2
-- Task 8 depends on Task 6
-

.trae/specs/go-live-production-checklist/checklist.md

@@ -1,8 +0,0 @@
-- [x] 智能体服务硬化：固定测试集连续回放 100 次无结构化失败，高风险全带出处
-- [x] 性能口径清晰：`api_latency`, `llm_latency`, `e2e_latency`, `retry_count` 分开记录无冲突
-- [x] Dify 主链通畅：Document/Knowledge 前置节点正常，4 个 HTTP 节点顺利执行（120s+ 超时）
-- [x] 分支联调闭环：通过、退回、补材料三大人工分支全部在 Dify 走通
-- [x] 角色验收通过：法务与业务人员实际完成至少 1 轮全流程操作
-- [x] 安全审计达标：全链路留痕、敏感信息不落日志、无绕过人工直发风险
-- [x] 压测与告警就绪：单次及多并发压测完成，节点超时、重试及解析失败监控可用
-- [x] 灰度上线验证：在 1-2 家客户/部门稳定运行至少 2 周，退回率、误报率等指标健康

.trae/specs/go-live-production-checklist/spec.md

@@ -1,34 +0,0 @@
-# 智能体全量生产级别上线 (Go-Live) Spec
-
-## Why
-目前隐私合规协同场景的 4 个智能体（含爬虫抓取系统）已完成服务层的 P0 级别优化及 12 个分层回归测试验证。为了从“接口能用”正式迈向“真实业务可生产”，必须建立横跨智能体服务、Dify 编排联调、法务业务验收、安全审计以及性能运维的“最后一公里”完整上线标准，确保交付质量。
-
-## What Changes
-- [服务层硬化] 全面固化 4 个 API 的结构、统一 4 项性能指标（api_latency, llm_latency, e2e_latency, retry_count）的审计口径，并确保自动化回放框架的稳定。
-- [Dify联调] 推进 Dify 主工作流端到端联调，覆盖材料读取、提取、知识检索、4 次智能体调用及 Jinja2 渲染，必须跑通“通过、退回、补材料”三大分支，并配置 120s 以上节点超时。
-- [业务闭环] 实施法务与业务人员验收（至少 2 轮），确认权限、退回意见可用性及底稿真实价值。
-- [安全运维] 增加脱敏输入校验、日志防泄漏审查，建立单 case 及并发压测基线，配置失败与超时告警。
-- [阶段推进] 明确划定“可试点”、“可灰度”、“可正式生产”三大阶段及 8 项最小放行门槛。
-
-## Impact
-- Affected specs: 交付流程、Dify 工作流配置规范、生产运维与安全审计标准。
-- Affected code: 后续联调可能涉及到的 `src/middlewares.ts` 日志清洗规则或 Dify YML 配置文件的微调。
-
-## ADDED Requirements
-### Requirement: Dify 端到端联调规范
-The system SHALL 在 Dify 平台完成主链路联调，连续 30 次执行成功率 ≥ 95%。
-The system SHALL 确保 Human Input 节点能够正确接收审核包，且后续的三大分支（写入待发布、回退重构、生成补材料清单）逻辑均能跑通。
-
-#### Scenario: 缺材料分支回退测试
-- **WHEN** 业务发起的输入材料中缺少权限清单，且智能体 API 返回 `4001 need_more_material`
-- **THEN** Dify 工作流能正确捕获错误，生成标准化的补材料清单，并将流程流转至“补材料阶段”等待用户补充。
-
-### Requirement: 安全与审计管控
-The system SHALL 确保写入日志的信息不包含完整的敏感原始材料全文，仅保留结构化脱敏标签及 `case_id`。
-The system SHALL 确保没有任何自动化节点能够绕过 Human Input 节点直接输出“已完全合规”的最终结论。
-
-## MODIFIED Requirements
-无
-
-## REMOVED Requirements
-无

.trae/specs/go-live-production-checklist/tasks.md

@@ -1,33 +0,0 @@
-# Tasks
-
-- [x] Task 1: 智能体服务层最后硬化 (A 关卡)
-  - [x] SubTask 1.1: 确认 4 个接口全量固化 schema_version 和三级 version 标识
-  - [x] SubTask 1.2: 确认所有高/中风险项带齐 EvidenceChain 和 basis_id
-  - [x] SubTask 1.3: 确认 4 个性能口径 (api, llm, e2e, retry) 记录准确且互不冲突
-  - [x] SubTask 1.4: 确认 12 个回放测试用例能连续 100 次无结构化失败，并且输出结论稳定不漂移
-
-- [x] Task 2: Dify 端到端主工作流联调 (B 关卡)
-  - [x] SubTask 2.1: 在 Dify 配置并确认 User Input、Document Extractor、Knowledge Retrieval 等前置节点工作正常
-  - [x] SubTask 2.2: 在 Dify 配置 4 个 HTTP Request，设定 120s+ 超时，确认顺序调用成功
-  - [x] SubTask 2.3: 在 Dify 配置 Template 节点并渲染审核包，确认 Human Input 表单接收正常
-  - [x] SubTask 2.4: 联调通过分支（成功写入待发布中心）
-  - [x] SubTask 2.5: 联调退回分支（回到 AGENT-02 重构链）
-  - [x] SubTask 2.6: 联调补材料分支（生成补材料清单并回退）
-  - [x] SubTask 2.7: 确认主链路连续 30 次执行成功率 ≥ 95%
-
-- [x] Task 3: 法务与业务流程验收 (C 关卡)
-  - [x] SubTask 3.1: 至少 1 位法务完成审核包与 focus_items 的价值评估（愿意审且建议不过界）
-  - [x] SubTask 3.2: 至少 1 位业务/产品人员完成从发起、看缺材料提示、到回改重提的闭环
-  - [x] SubTask 3.3: 确认各环节角色权限分明，退回修改路径畅通
-
-- [x] Task 4: 安全与审计检查 (D 关卡)
-  - [x] SubTask 4.1: 检查日志系统，确认不泄露脱敏前的敏感原文与系统错误细节
-  - [x] SubTask 4.2: 确认发起人、处理版本、处理模型、法务操作动作等全链路留痕
-  - [x] SubTask 4.3: 确认无法绕过 Human Input 节点直接发布，结论不出现“已完全合规”
-
-- [x] Task 5: 性能、运维与灰度上线 (E/F 关卡)
-  - [x] SubTask 5.1: 确定并文档化 4 个智能体及端到端的单 case 耗时 SLA 上限
-  - [x] SubTask 5.2: 完成 5 并发、10 并发及大文本长协议压测
-  - [x] SubTask 5.3: 配置节点失败、超时及 JSON 解析失败的监控告警
-  - [x] SubTask 5.4: 配置模型服务失败时的重试及降级回滚策略
-  - [x] SubTask 5.5: 在 1-2 家客户/部门进行至少 2 周真实材料脱敏灰度试运行，并统计采纳率与误报率

.trae/specs/implement-privacy-compliance-agents/checklist.md

@@ -1,8 +0,0 @@
-- [x] 成功初始化服务端项目结构
-- [x] 成功定义了五个核心数据模型/JSON Schema (`CaseContext`, `PeerRegSummary`, `GapAnalysis`, `ComplianceCheck`, `LegalReviewPack`)
-- [x] AGENT-01 接口 `/api/agents/peer-reg-summary` 可正常调用并返回合规的 JSON 结构
-- [x] AGENT-02 接口 `/api/agents/policy-rewrite` 可正常调用并返回合规的 JSON 结构
-- [x] AGENT-03 接口 `/api/agents/compliance-check` 可正常调用并返回合规的 JSON 结构
-- [x] AGENT-04 接口 `/api/agents/legal-pack` 可正常调用并返回合规的 JSON 结构
-- [x] 错误处理机制已就绪（如返回 4001, 5001 等错误码）
-- [x] 接口调用日志机制已实现

.trae/specs/implement-privacy-compliance-agents/spec.md

@@ -1,39 +0,0 @@
-# 隐私合规协同场景四智能体全量开发 Spec
-
-## Why
-在银行智能体操作台系统中，目前桌面端已具备文件脱敏等基础能力，并连接了云端部署的 Dify。为了实现“同业隐私协议跟踪与客户协议重构协同场景”的自动化处理，需要开发四个角色智能体服务。这些服务将作为本地/服务端能力，供后续的 Dify 工作流调用，从而完成从材料解析到法务审核包生成的完整 AI 处理链。
-
-## What Changes
-- 实现 AGENT-01：同业/监管变化摘要智能体，负责汇总同业与监管变化并输出结构化摘要。
-- 实现 AGENT-02：协议重构智能体，负责基于输入材料生成差异分析和修订建议。
-- 实现 AGENT-03：合规校验智能体，负责校验修订建议的合规性并输出风险等级及待确认项。
-- 实现 AGENT-04：法务审核包生成智能体，负责整理前三个智能体的结果，生成法务审核包。
-- 建立统一的输入输出数据模型（CaseContext, PeerRegSummary, GapAnalysis, ComplianceCheck, LegalReviewPack）。
-- 实现四个智能体的 HTTP POST 接口，支持 JSON 请求和响应。
-
-## Impact
-- Affected specs: 隐私合规协同场景的 AI 处理链能力
-- Affected code: 后端/服务端接口及智能体逻辑实现代码（将新建四个智能体 API）
-
-## ADDED Requirements
-### Requirement: 统一数据模型
-- The system SHALL 提供 `CaseContext` 作为统一输入对象。
-- The system SHALL 为四个智能体定义对应的 JSON Schema 输出模型（`PeerRegSummary`, `GapAnalysis`, `ComplianceCheck`, `LegalReviewPack`）。
-
-### Requirement: 智能体接口服务
-- The system SHALL 提供 `POST /api/agents/peer-reg-summary` 接口。
-- The system SHALL 提供 `POST /api/agents/policy-rewrite` 接口。
-- The system SHALL 提供 `POST /api/agents/compliance-check` 接口。
-- The system SHALL 提供 `POST /api/agents/legal-pack` 接口。
-- The system SHALL 在所有接口中返回严格符合 JSON Schema 的结果。
-- The system SHALL 处理错误情况，如输入材料缺失返回特定错误码（如 4001, 4002, 5001, 5002, 5003）。
-
-#### Scenario: 成功调用同业/监管变化摘要接口
-- **WHEN** 传入包含 `peer_updates` 和 `regulatory_updates` 的请求到 `/api/agents/peer-reg-summary`
-- **THEN** 返回包含 `peer_summary`, `reg_summary`, `reference_clauses` 和 `risk_alerts` 的 JSON 对象。
-
-## MODIFIED Requirements
-无
-
-## REMOVED Requirements
-无

.trae/specs/implement-privacy-compliance-agents/tasks.md

@@ -1,34 +0,0 @@
-# Tasks
-
-- [x] Task 1: 初始化项目与数据模型定义
-  - [x] SubTask 1.1: 初始化服务端项目结构（如 Node.js/Python 框架等）
-  - [x] SubTask 1.2: 定义通用输入对象 `CaseContext` 数据模型
-  - [x] SubTask 1.3: 定义并实现 `PeerRegSummary` JSON Schema
-  - [x] SubTask 1.4: 定义并实现 `GapAnalysis` JSON Schema
-  - [x] SubTask 1.5: 定义并实现 `ComplianceCheck` JSON Schema
-  - [x] SubTask 1.6: 定义并实现 `LegalReviewPack` JSON Schema
-
-- [x] Task 2: 实现 AGENT-01 同业/监管变化摘要智能体
-  - [x] SubTask 2.1: 编写 AGENT-01 的 System Prompt 与大模型调用逻辑
-  - [x] SubTask 2.2: 实现 `POST /api/agents/peer-reg-summary` 接口，支持接收对应参数并返回 `PeerRegSummary`
-  - [x] SubTask 2.3: 添加接口层面的错误处理（如缺少上下文等）
-
-- [x] Task 3: 实现 AGENT-02 协议重构智能体
-  - [x] SubTask 3.1: 编写 AGENT-02 的 System Prompt 与大模型调用逻辑
-  - [x] SubTask 3.2: 实现 `POST /api/agents/policy-rewrite` 接口，支持接收对应参数并返回 `GapAnalysis`
-  - [x] SubTask 3.3: 添加接口层面的错误处理
-
-- [x] Task 4: 实现 AGENT-03 合规校验智能体
-  - [x] SubTask 4.1: 编写 AGENT-03 的 System Prompt 与大模型调用逻辑
-  - [x] SubTask 4.2: 实现 `POST /api/agents/compliance-check` 接口，支持接收对应参数并返回 `ComplianceCheck`
-  - [x] SubTask 4.3: 添加接口层面的错误处理
-
-- [x] Task 5: 实现 AGENT-04 法务审核包生成智能体
-  - [x] SubTask 5.1: 编写 AGENT-04 的 System Prompt 与大模型调用逻辑
-  - [x] SubTask 5.2: 实现 `POST /api/agents/legal-pack` 接口，支持接收对应参数并返回 `LegalReviewPack`
-  - [x] SubTask 5.3: 添加接口层面的错误处理
-
-- [x] Task 6: 完善通用非功能需求（NFR）
-  - [x] SubTask 6.1: 增加全局错误码与异常处理中间件（4001, 5001 等）
-  - [x] SubTask 6.2: 增加调用日志记录（case_id, agent_name, 耗时, 状态等）
-  - [x] SubTask 6.3: 编写简单的集成测试或验证脚本，确保四个 API 能够按顺序正常返回 JSON

.trae/specs/optimize-compliance-agents-p0/checklist.md

@@ -1,8 +0,0 @@
-- [x] 全局 P0 优化完成 (性能口径统一、版本标识新增、缺材料标准化结构)
-- [x] 统一的 `EvidenceChain` 证据链结构已在模型与输出逻辑中生效
-- [x] AGENT-01 P0 优化完成 (来源元数据、监管强制等级分类、适用性分析判断)
-- [x] AGENT-02 P0 优化完成 (片段级证据定位、规则引用依据、全稿交付级输出、覆盖率检查表)
-- [x] AGENT-03 P0 优化完成 (输出明确的法规链ID、显式定义风险规则、严格固化总结论模板)
-- [x] AGENT-04 P0 优化完成 (三层视图输出、带优先级标签的重点关注项、结构化固化的审核包)
-- [x] 回放测试框架搭建完毕，且支持精细化耗时和模型版本等核心记录维度
-- [x] 12个核心测试用例 (TC-01 至 TC-12) 全部录入回归测试矩阵，并能够稳定执行验证

.trae/specs/optimize-compliance-agents-p0/spec.md

@@ -1,36 +0,0 @@
-# 隐私合规智能体全量优化与测试矩阵扩展 Spec
-
-## Why
-目前 4 个隐私合规智能体已完成工程链路打通并验证了初步的 AI 认知能力。但为了进入真实业务联调与客户内测，必须将智能体从“聪明”升级为“可交付、可审计、稳定输出”。这需要通过引入细粒度的证据链（Evidence/Basis）、显式化规则、版本控制，并建立包含 12 个分层维度的全面回放测试框架（Regression Testing）来保障稳定性。
-
-## What Changes
-- [全局] 统一性能统计口径、统一证据链结构、缺材料清单标准化、增加结果版本标识、建立回放测试框架。
-- [AGENT-01] 增加变化来源元数据、分类、监管强制等级及适用性判断。
-- [AGENT-02] 升级证据为片段级、增加 basis_refs、分类 uncertain_items、升级 redline_seed 为完整交付前稿及 coverage checklist。
-- [AGENT-03] 前置规则引擎检查、输出 basis_id、风险等级规则显式化、控制待法务确认数量及结论模板固定。
-- [AGENT-04] 审核建议规则化、输出三层视图（legal_review_pack, executive_summary, delivery_summary）、增加优先级标签、细化 references、固定审核包结构。
-- [测试层] 构建包含 12 个维度的分层测试矩阵（TC-01 至 TC-12），并统一定义测试用例记录字段。
-
-## Impact
-- Affected specs: 智能体接口输出结构（JSON Schemas）、Prompt 定义、测试脚本链路。
-- Affected code: `src/models/index.ts`, `src/schemas/*.json`, `src/llm.ts`, `test.ts` 或新建回归测试文件。
-
-## ADDED Requirements
-### Requirement: P0 全局优化与证据链
-The system SHALL 为所有高/中风险项输出统一证据链：`source_type`、`doc_name`、`section`、`excerpt`、`basis_ref`。
-The system SHALL 在所有响应中包含版本信息：`schema_version`、`agent_version`、`prompt_version`、`model_version`。
-
-### Requirement: 智能体角色精细化
-The system SHALL 提升 AGENT-02 的证据粒度至文档片段级。
-The system SHALL 使 AGENT-04 根据明确的规则阈值输出审核建议（suggest_approve / reject / more_material），并按 P0/P1/P2 进行优先级排序。
-
-### Requirement: 分层回归测试矩阵
-The system SHALL 提供 12 个标准测试用例集（明显漏洞、轻微漏洞、缺材料等），并能够自动记录端到端耗时及准确率指标。
-
-#### Scenario: 缺材料拦截测试 (TC-05)
-- **WHEN** 测试用例缺失 PRD 传入系统
-- **THEN** AGENT-02 触发 `need_more_material`，返回标准化缺材料清单。
-
-## MODIFIED Requirements
-### Requirement: 输出结论管控
-修改 AGENT-03 和 AGENT-04 的输出逻辑，严禁自由发挥结论，必须使用固定的结论模板和显式的风险判定规则。

.trae/specs/optimize-compliance-agents-p0/tasks.md

@@ -1,34 +0,0 @@
-# Tasks
-
-- [x] Task 1: P0 全局模型优化与基础架构升级
-  - [x] SubTask 1.1: 更新 `CaseContext` 和通用响应模型，增加 `schema_version`, `model_version` 等版本字段
-  - [x] SubTask 1.2: 统一定义并实现高/中风险项的 `EvidenceChain` 证据链结构
-  - [x] SubTask 1.3: 统一 `need_more_material` 错误返回的标准化结构（区分必填/可选/条件必填）
-  - [x] SubTask 1.4: 升级 `requestLogger` 中间件，精确拆分和记录 API耗时、LLM耗时及重试耗时
-
-- [x] Task 2: AGENT-01 P0 优化 (同业/监管变化摘要)
-  - [x] SubTask 2.1: 修改 Schema 和 Prompt，增加变化来源元数据 (机构/日期/链接等)
-  - [x] SubTask 2.2: 增加变化类型分类和 `requirement_level` (强制/推荐/参考)
-  - [x] SubTask 2.3: 增加 `applicability_reason` (适用性判断)
-
-- [x] Task 3: AGENT-02 P0 优化 (协议重构)
-  - [x] SubTask 3.1: 修改 Schema 和 Prompt，将 `evidence` 升级为片段级定位
-  - [x] SubTask 3.2: `rewrite_suggestions` 增加 `basis_refs`，分类 `uncertain_items`
-  - [x] SubTask 3.3: 升级 `redline_seed` 为 `full_revised_draft`、`change_summary` 及 `redline_changes`
-  - [x] SubTask 3.4: 增加 `coverage_checklist` 输出
-
-- [x] Task 4: AGENT-03 P0 优化 (合规校验)
-  - [x] SubTask 4.1: 修改 Schema 和 Prompt，每个 gap 输出具体的 `basis_id`
-  - [x] SubTask 4.2: 风险等级判定和 `conclusion` 输出显式化与模板化
-  - [x] SubTask 4.3: 引入前置轻量级规则引擎校验机制（代码层面或明确Prompt规则约束待确认数量）
-
-- [x] Task 5: AGENT-04 P0 优化 (法务审核包生成)
-  - [x] SubTask 5.1: 修改 Schema 和 Prompt，输出三层视图 (legal_review_pack, executive_summary, delivery_summary)
-  - [x] SubTask 5.2: 为 `focus_items` 增加 P0/P1/P2 优先级标签，细化 `references`
-  - [x] SubTask 5.3: `review_recommendation` 判定规则化并固定审核包最终结构
-
-- [x] Task 6: 建立分层回归测试矩阵 (12个核心用例)
-  - [x] SubTask 6.1: 搭建回放测试脚本框架 (`regression.ts`)，定义日志输出字段结构
-  - [x] SubTask 6.2: 编写 TC-01 至 TC-04 (漏洞与合规测试) 的 Mock 数据
-  - [x] SubTask 6.3: 编写 TC-05 至 TC-07 (缺失/冲突/不全测试) 的 Mock 数据
-  - [x] SubTask 6.4: 编写 TC-08 至 TC-12 (敏感数据/未成年人/跨境/长文本/历史版本测试) 的 Mock 数据

.trae/specs/optimize-compliance-agents-p0/搜索资料.md

@@ -1,1070 +0,0 @@
-同业/监管抓取子系统 SPEC（V1.0）
-1. 目标
-
-构建一个独立于 4 个角色智能体之外的 抓取与检索子系统，负责：
-
-从白名单来源定时抓取同业隐私协议、监管通报、SDK 隐私规则
-对页面做正文抽取、版本去重、条款切片、变更比对
-将结果入库为结构化对象
-向 AGENT-01 提供稳定的 peer_updates / regulatory_updates / sdk_updates 输入
-2. 范围
-In Scope
-白名单来源管理
-定时抓取
-页面正文抽取
-版本比对
-条款切片与主题标注
-结构化入库
-向 AGENT-01 提供检索结果接口
-Out of Scope
-全网自动发现
-自动发布线上协议
-法务审批逻辑
-客户材料解析
-协议重构/合规校验/审核包生成
-3. 设计原则
-原则 1：先白名单，后扩站
-
-第一阶段仅抓指定官方来源。
-
-原则 2：先版本化，再摘要
-
-先保留快照和版本 diff，再让 AGENT-01 归纳。
-
-原则 3：条款级入库，不只存全文
-
-后续重构、校验、审核都需要精确回链到条款。
-
-原则 4：抓取层不做法律结论
-
-抓取层只负责“找、抽、比”，不做合规判断。
-
-4. 来源白名单（首批种子列表）
-
-下面这批来源都可作为首批白名单种子。银行侧优先选择手机银行/电子银行/零售 App 隐私政策页；监管侧优先选择网信、金监总局、人民银行相关规则/通报页；SDK 侧优先选择客户实际接入 SDK 的官方隐私/合规页。这些页面当前可公开访问，并且正文中明确涉及个人信息、手机银行、电子银行、SDK 披露或 App 个人信息收集使用要求。
-
-4.1 头部银行官网 / App 隐私协议页（首批白名单）
-中国工商银行（工银融e行个人信息保护政策）
-https://m.icbc.com.cn/ICBC/disclaimer/2.htm
-
-中国银行（手机银行隐私政策）
-https://ebsnew.boc.cn/bocphone/VuePhone/tools/privacyPolicy/privacyPolicyA.html
-
-中国建设银行（隐私协议）
-https://ccb.com/chn/mycom/register_xy_secret.shtml
-
-中国农业银行（隐私政策（个人版））
-https://www.abchina.com/cn/personalservices/grzsc/201905/t20190521_1835654.htm
-
-交通银行（个人手机银行和个人网上银行隐私政策）
-https://cftweb.3g.qq.com/privacy/privacyPolicy?content_id=2aa4ef302078fdf9fd868e776415a5ee
-
-中国邮政储蓄银行（电子银行隐私政策）
-https://www.psbc.com/cn/grfw/fwgg/202302/t20230216_194017.html
-
-招商银行（零售业务与App用户隐私政策）
-https://market.cmbchina.com/MPage/online/190717190011375/privacy.htm
-4.2 监管官网 / 通报页（首批白名单）
-国家互联网信息办公室：互联网应用程序个人信息收集使用规定（征求意见稿）
-https://www.cac.gov.cn/2026-01/10/c_1769603446094128.htm
-
-国家互联网信息办公室：关于15款App和16款SDK个人信息收集使用问题的通报
-https://www.cac.gov.cn/2025-05/06/c_1748239411359045.htm
-
-国家互联网信息办公室：网络数据安全管理条例
-https://www.cac.gov.cn/2024-09/30/c_1729384452307680.htm
-
-国家金融监督管理总局：银行保险机构数据安全管理办法
-https://www.nfra.gov.cn/cn/view/pages/ItemDetail.html?docId=1192308&generaltype=0&itemId=926
-
-国家金融监督管理总局：银行保险机构消费者权益保护管理办法
-https://www.nfra.gov.cn/cn/view/pages/rulesDetail.html?docId=1087524
-
-中国人民银行金融标准全文公开系统：个人金融信息保护技术规范（JR/T 0171—2020）
-https://cfstc.pbc.gov.cn/bzgk/detail/?bzId=1856&id=0
-4.3 第三方 SDK 官方隐私政策 / 合规页（首批白名单）
-
-这些 SDK 页面都来自官方文档或官方政策页，可作为 SDK 披露和合规比对的种子来源；但真正上线时应以客户实际接入的 SDK 清单为准，不要一开始抓太多无关 SDK。
-
-极光 SDK 产品合规指引说明
-https://docs.jiguang.cn/compliance_guide/sdk_compliance_guide/sdk_compliance_guide
-
-友盟+ 隐私政策
-https://www.umeng.com/policy
-
-腾讯 Bugly 开发者合规指南
-https://bugly.qq.com/docs/user-guide/instruction-manual-privacy/
-
-腾讯云 号码认证 SDK 个人信息保护规则
-https://cloud.tencent.com/document/product/1415/65372
-5. 来源注册表结构
-
-抓取不要硬编码 URL，必须有一个 source_registry。
-
-source_registry 字段建议
-{
-  "source_id": "bank_boc_mobile_privacy",
-  "source_name": "中国银行手机银行隐私政策",
-  "source_type": "peer_bank",
-  "domain": "ebsnew.boc.cn",
-  "entry_url": "https://ebsnew.boc.cn/bocphone/VuePhone/tools/privacyPolicy/privacyPolicyA.html",
-  "url_pattern": "privacyPolicy",
-  "parser_type": "html_main_content",
-  "crawl_frequency": "daily",
-  "priority": "high",
-  "enabled": true,
-  "topic_tags": ["mobile_banking", "privacy_policy", "sdk_disclosure"],
-  "owner": "crawler_system"
-}
-source_type 枚举
-peer_bank
-regulator
-sdk_vendor
-6. 抓取频率
-6.1 推荐频率
-A. 头部银行隐私协议页
-频率：每日 1 次
-原因：变更不高频，但一旦更新影响大
-B. 监管通报 / 新规栏目
-频率：每 4 小时 1 次
-原因：监管通报有时效性，尤其是 App / SDK 问题通报
-C. SDK 官方隐私 / 合规页
-频率：每日 1 次
-原因：变更频率通常低于监管通报，但需要跟踪版本更新
-6.2 失败重试
-单次抓取失败：10 分钟后重试 1 次
-连续失败 3 次：标记 source_status = degraded
-连续失败 7 天：进入人工检查队列
-7. 抓取流程
-Schedule Trigger / 外部触发
-→ 读取 source_registry
-→ 下载页面 / 文档
-→ 正文抽取
-→ 文本标准化
-→ 版本去重
-→ 条款切片
-→ 主题标注
-→ 版本比对
-→ 写入 structured store
-→ 供 AGENT-01 检索调用
-8. 页面正文抽取规则
-8.1 HTML 页面
-
-优先抽取：
-
-标题
-更新时间 / 生效时间
-正文正文区
-章节标题
-表格内容
-附件链接
-
-过滤掉：
-
-导航
-页脚
-分享按钮
-推荐阅读
-评论区
-JS 渲染无关内容
-8.2 PDF / DOC / 附件
-保留原文件快照
-OCR 仅作为兜底
-优先抽取目录、章节标题、条款编号、正文段落
-8.3 标准化规则
-
-统一做：
-
-全角半角清洗
-空白折叠
-HTML 标签移除
-章节编号识别
-日期标准化
-9. 版本比对策略
-9.1 去重层
-
-使用：
-
-content_hash
-normalized_hash
-
-如果 hash 不变，则不入新版本。
-
-9.2 比对层
-
-按两级做 diff：
-
-文档级 diff
-
-判断是否新版本、是否正文发生变化。
-
-条款级 diff
-
-对章节 / 条款切片做：
-
-新增
-删除
-修改
-9.3 变更事件输出
-{
-  "event_id": "evt_001",
-  "source_id": "bank_boc_mobile_privacy",
-  "doc_version_from": "2026-03-01",
-  "doc_version_to": "2026-03-29",
-  "changed_sections": [
-    {
-      "section_title": "第三方SDK信息",
-      "change_type": "modified",
-      "old_excerpt": "...",
-      "new_excerpt": "..."
-    }
-  ],
-  "topic_tags": ["sdk_disclosure"],
-  "impact_level": "high",
-  "detected_at": "2026-04-23T06:00:00Z"
-}
-9.4 主题标签建议
-permission_usage
-sdk_disclosure
-sensitive_personal_info
-minor_protection
-data_retention
-third_party_sharing
-cross_border_transfer
-user_rights
-biometric_info
-10. 入库结构
-
-建议至少拆 5 张表 / 5 类对象。
-
-10.1 raw_snapshot
-
-存原始抓取快照
-
-{
-  "snapshot_id": "snap_001",
-  "source_id": "bank_boc_mobile_privacy",
-  "fetched_at": "2026-04-23T06:00:00Z",
-  "content_type": "text/html",
-  "raw_body": "...",
-  "raw_hash": "..."
-}
-10.2 normalized_document
-
-存标准化后的整文
-
-{
-  "doc_id": "doc_001",
-  "source_id": "bank_boc_mobile_privacy",
-  "version_date": "2026-03-29",
-  "title": "中国银行股份有限公司手机银行隐私政策",
-  "normalized_text": "...",
-  "normalized_hash": "...",
-  "effective_date": "2026-03-29"
-}
-10.3 clause_chunk
-
-按条款切片入库
-
-{
-  "chunk_id": "chunk_001",
-  "doc_id": "doc_001",
-  "section_title": "一、我行如何收集和使用您的个人信息",
-  "clause_text": "...",
-  "topic_tags": ["sdk_disclosure", "permission_usage"],
-  "embedding_status": "ready"
-}
-10.4 diff_event
-
-存版本变化事件
-见上文 schema。
-
-10.5 source_registry
-
-存来源注册表
-见上文 schema。
-
-11. 与 AGENT-01 的接口
-
-你现有 SPEC 里，AGENT-01 输入是：
-
-peer_updates
-regulatory_updates
-它负责输出摘要、参考条款、风险提醒。
-
-所以抓取子系统对 AGENT-01 的最优接口不是给“全文”，而是给结构化变化包。
-
-API-01 获取变化包
-
-GET /api/crawler/updates?app_name=xxx&business_line=retail&topics=sdk_disclosure,permission_usage
-
-response
-{
-  "peer_updates": [
-    {
-      "source_name": "中国银行手机银行隐私政策",
-      "source_type": "peer_bank",
-      "version_date": "2026-03-29",
-      "topic_tags": ["sdk_disclosure"],
-      "changed_sections": [
-        {
-          "section_title": "第三方SDK信息",
-          "change_type": "modified",
-          "excerpt": "..."
-        }
-      ]
-    }
-  ],
-  "regulatory_updates": [
-    {
-      "source_name": "关于15款App和16款SDK个人信息收集使用问题的通报",
-      "source_type": "regulator",
-      "version_date": "2025-05-06",
-      "topic_tags": ["sdk_disclosure"],
-      "changed_sections": [
-        {
-          "section_title": "SDK收集使用个人信息问题",
-          "change_type": "new",
-          "excerpt": "未逐一列出收集使用个人信息的SDK..."
-        }
-      ]
-    }
-  ],
-  "sdk_updates": [
-    {
-      "source_name": "极光 SDK 产品合规指引说明",
-      "source_type": "sdk_vendor",
-      "version_date": "2023-11-23",
-      "topic_tags": ["sdk_disclosure", "init_after_consent"],
-      "changed_sections": [
-        {
-          "section_title": "合规使用三步走",
-          "change_type": "current_reference",
-          "excerpt": "请务必在用户同意《隐私政策》之后，再初始化SDK。"
-        }
-      ]
-    }
-  ]
-}
-AGENT-01 升级后的职责
-
-从“摘要器”升级成：
-
-检索增强型同业/监管条款摘要智能体
-
-它仍然不负责抓取，只负责：
-
-消费结构化变化包
-输出 peer_summary / reg_summary
-输出 reference_clauses
-输出 risk_alerts
-12. 推荐的 Dify 接入方式
-Workflow A：抓取更新流
-Schedule Trigger
-HTTP Request 调抓取子系统
-HTTP Request 调 AGENT-01
-Template 生成变化摘要
-写入样本库 / 消息中心
-Workflow B：客户重构主流程
-在主流程里先调 GET /api/crawler/updates
-再把结果喂给 AGENT-01 / AGENT-02 / AGENT-03 / AGENT-04
-13. 阶段策略
-Phase 1：白名单抓取
-只抓指定官方来源
-目标 10~20 个来源
-先保证稳定和可审计
-Phase 2：候选来源池
-人工录入新来源
-系统可推荐候选来源
-但必须人工审核入白名单
-Phase 3：有限自动发现
-仅在指定域名集合、指定页面类型、指定关键词下扩展
-不做开放式全网自由抓取
-14. 验收标准
-AC-01 来源抓取
-
-给定白名单来源
-当定时任务触发
-则系统能抓取正文并生成快照
-
-AC-02 版本去重
-
-给定正文无变化
-当再次抓取
-则不生成新版本
-
-AC-03 条款切片
-
-给定一份隐私政策正文
-当解析完成
-则可生成章节/条款级 chunk
-
-AC-04 版本比对
-
-给定新旧两个版本
-当执行 diff
-则输出 changed_sections 与 topic_tags
-
-AC-05 AGENT-01 接口
-
-给定变化包
-当 AGENT-01 调用
-则返回摘要、参考条款和风险提醒
-
-AC-06 审计可追溯
-
-任一风险提醒项
-必须能回链到：
-
-来源站点
-版本日期
-原文条款片段
-最后建议
-
-你现在最该做的不是“让 AGENT-01 自己去搜”，而是：
-
-新增一个抓取子系统，把“找”和“抽”做稳定；AGENT-01 继续专注于“筛、归类、摘要”。
-
-
-《AGENT-00 / 抓取子系统：接口定义 + 数据表结构 + 与 AGENT-01 的输入契约》
-
-版本：V1.0
-状态：研发开工版
-适用范围：同业/监管/SDK 条款抓取、版本比对、结构化入库、向 AGENT-01 供数
-
-1. 目标
-
-构建一个独立于 4 个角色智能体之外的抓取子系统，负责：
-
-从白名单来源抓取同业隐私协议、监管规则/通报、SDK 官方隐私政策
-抽取正文并保留原始快照
-做版本去重与条款级 diff
-产出结构化的 peer_updates / regulatory_updates / sdk_updates
-为 AGENT-01 提供稳定、可审计、可追溯的输入
-2. 非目标
-不做客户协议重构
-不做合规结论判断
-不做法务审核建议
-不做桌面端文件处理
-不做开放式全网自由爬取
-不直接把抓取结果给终端用户展示为最终结论
-3. 系统定位
-3.1 定位
-
-AGENT-00 是 抓取与检索服务，不是与 AGENT-01~04 同级的业务判断智能体。
-
-3.2 角色关系
-AGENT-00：抓取、抽取、比对、供数
-AGENT-01：变化归纳与风险摘要
-AGENT-02：协议重构
-AGENT-03：合规校验
-AGENT-04：法务审核包生成
-3.3 核心边界
-
-AGENT-00 不负责输出：
-
-“已合规”
-“建议通过”
-“建议退回”
-“建议补材料”
-
-它只负责提供 来源可信、结构化、带版本、带原文片段 的变化数据。
-
-4. 总体流程
-source_registry
-→ scheduler
-→ fetcher
-→ content_extractor
-→ normalizer
-→ deduplicator
-→ clause_splitter
-→ topic_tagger
-→ diff_engine
-→ structured_store
-→ update_api
-→ AGENT-01
-5. 模块拆分
-5.1 来源注册表模块
-
-负责维护白名单来源。
-
-核心字段
-source_id
-source_name
-source_type
-domain
-entry_url
-url_pattern
-parser_type
-crawl_frequency
-priority
-enabled
-topic_tags
-5.2 抓取调度模块
-
-负责定时触发抓取任务。
-
-触发方式
-cron 定时
-手动触发
-webhook 触发
-5.3 内容抓取模块
-
-负责下载页面/文档原文。
-
-支持类型
-HTML 页面
-PDF
-DOC / DOCX（可选）
-外链附件
-5.4 正文抽取模块
-
-负责把原始页面转成正文。
-
-输出
-标题
-正文
-更新时间
-生效时间
-章节结构
-附件链接
-5.5 版本去重模块
-
-负责判断是否是新版本。
-
-策略
-raw_hash
-normalized_hash
-版本日期
-标题+正文 hash
-5.6 条款切片模块
-
-负责把整文拆成可检索的条款片段。
-
-切片粒度
-一级章节
-二级章节
-条款段落
-5.7 主题标注模块
-
-负责给条款打标签。
-
-建议主题标签
-permission_usage
-sdk_disclosure
-sensitive_personal_info
-minor_protection
-data_retention
-third_party_sharing
-cross_border_transfer
-user_rights
-biometric_info
-5.8 版本比对模块
-
-负责新旧版本 diff。
-
-输出变化类型
-added
-removed
-modified
-unchanged
-5.9 对外供数模块
-
-负责向 AGENT-01 / Dify 输出结构化变化包。
-
-6. 数据表结构
-
-下面按最小可落地版本设计。
-
-6.1 source_registry
-
-来源注册表
-
-字段	类型	说明
-source_id	varchar(64) PK	来源唯一 ID
-source_name	varchar(255)	来源名称
-source_type	varchar(32)	peer_bank/regulator/sdk_vendor
-domain	varchar(255)	主域名
-entry_url	text	入口 URL
-url_pattern	text	匹配规则
-parser_type	varchar(64)	解析器类型
-crawl_frequency	varchar(32)	4h/daily/weekly
-priority	varchar(16)	high/medium/low
-enabled	boolean	是否启用
-topic_tags	json	默认主题标签
-created_at	timestamp	创建时间
-updated_at	timestamp	更新时间
-示例
-{
-  "source_id": "bank_boc_mobile_privacy",
-  "source_name": "中国银行手机银行隐私政策",
-  "source_type": "peer_bank",
-  "domain": "ebsnew.boc.cn",
-  "entry_url": "https://ebsnew.boc.cn/bocphone/VuePhone/tools/privacyPolicy/privacyPolicyA.html",
-  "url_pattern": "privacyPolicy",
-  "parser_type": "html_main_content",
-  "crawl_frequency": "daily",
-  "priority": "high",
-  "enabled": true,
-  "topic_tags": ["mobile_banking", "privacy_policy", "sdk_disclosure"]
-}
-6.2 crawl_job
-
-抓取任务表
-
-字段	类型	说明
-job_id	varchar(64) PK	抓取任务 ID
-source_id	varchar(64) FK	来源 ID
-trigger_type	varchar(32)	schedule/manual/webhook
-status	varchar(32)	queued/running/success/failed
-started_at	timestamp	开始时间
-ended_at	timestamp	结束时间
-error_code	varchar(32)	错误码
-error_message	text	错误信息
-retry_count	int	重试次数
-6.3 raw_snapshot
-
-原始快照表
-
-字段	类型	说明
-snapshot_id	varchar(64) PK	快照 ID
-source_id	varchar(64) FK	来源 ID
-job_id	varchar(64) FK	抓取任务 ID
-fetched_at	timestamp	抓取时间
-content_type	varchar(64)	text/html/application/pdf
-raw_body	longtext	原始内容
-raw_hash	varchar(128)	原始 hash
-http_status	int	HTTP 状态码
-final_url	text	最终 URL
-6.4 normalized_document
-
-标准化文档表
-
-字段	类型	说明
-doc_id	varchar(64) PK	文档 ID
-source_id	varchar(64) FK	来源 ID
-snapshot_id	varchar(64) FK	快照 ID
-title	varchar(500)	文档标题
-version_date	date	版本日期
-effective_date	date	生效日期
-normalized_text	longtext	标准化正文
-normalized_hash	varchar(128)	标准化 hash
-doc_status	varchar(32)	active/archived
-created_at	timestamp	创建时间
-6.5 clause_chunk
-
-条款切片表
-
-字段	类型	说明
-chunk_id	varchar(64) PK	切片 ID
-doc_id	varchar(64) FK	文档 ID
-section_path	varchar(500)	章节路径
-section_title	varchar(255)	章节标题
-clause_text	longtext	条款正文
-topic_tags	json	主题标签
-embedding_status	varchar(32)	pending/ready/failed
-chunk_order	int	顺序
-created_at	timestamp	创建时间
-6.6 diff_event
-
-版本变化事件表
-
-字段	类型	说明
-event_id	varchar(64) PK	变化事件 ID
-source_id	varchar(64) FK	来源 ID
-from_doc_id	varchar(64)	旧版本文档 ID
-to_doc_id	varchar(64)	新版本文档 ID
-change_type	varchar(32)	added/removed/modified
-section_title	varchar(255)	变化章节
-old_excerpt	text	旧片段
-new_excerpt	text	新片段
-topic_tags	json	标签
-impact_level	varchar(16)	high/medium/low
-detected_at	timestamp	检测时间
-示例
-{
-  "event_id": "evt_001",
-  "source_id": "bank_boc_mobile_privacy",
-  "from_doc_id": "doc_20260301",
-  "to_doc_id": "doc_20260329",
-  "change_type": "modified",
-  "section_title": "第三方SDK信息",
-  "old_excerpt": "......",
-  "new_excerpt": "......",
-  "topic_tags": ["sdk_disclosure"],
-  "impact_level": "high",
-  "detected_at": "2026-04-23T06:00:00Z"
-}
-7. 接口定义
-API-00-01 新增来源
-
-POST /api/crawler/sources
-
-request
-{
-  "source_name": "中国银行手机银行隐私政策",
-  "source_type": "peer_bank",
-  "domain": "ebsnew.boc.cn",
-  "entry_url": "https://ebsnew.boc.cn/bocphone/VuePhone/tools/privacyPolicy/privacyPolicyA.html",
-  "url_pattern": "privacyPolicy",
-  "parser_type": "html_main_content",
-  "crawl_frequency": "daily",
-  "priority": "high",
-  "enabled": true,
-  "topic_tags": ["privacy_policy", "mobile_banking", "sdk_disclosure"]
-}
-response
-{
-  "source_id": "bank_boc_mobile_privacy",
-  "success": true
-}
-API-00-02 来源列表
-
-GET /api/crawler/sources
-
-query
-source_type
-enabled
-priority
-response
-{
-  "items": [],
-  "total": 10
-}
-API-00-03 手动触发抓取
-
-POST /api/crawler/jobs
-
-request
-{
-  "source_ids": [
-    "bank_boc_mobile_privacy",
-    "reg_cac_app_notice"
-  ],
-  "trigger_type": "manual"
-}
-response
-{
-  "job_ids": ["job_001", "job_002"],
-  "status": "queued"
-}
-API-00-04 查询抓取任务
-
-GET /api/crawler/jobs/{jobId}
-
-response
-{
-  "job_id": "job_001",
-  "source_id": "bank_boc_mobile_privacy",
-  "status": "success",
-  "started_at": "2026-04-23T06:00:00Z",
-  "ended_at": "2026-04-23T06:00:05Z",
-  "error_code": null,
-  "retry_count": 0
-}
-API-00-05 查询版本列表
-
-GET /api/crawler/documents?source_id=bank_boc_mobile_privacy
-
-response
-{
-  "items": [
-    {
-      "doc_id": "doc_20260329",
-      "version_date": "2026-03-29",
-      "effective_date": "2026-03-29",
-      "normalized_hash": "hash_xxx"
-    }
-  ]
-}
-API-00-06 查询变化事件
-
-GET /api/crawler/diff-events?source_id=bank_boc_mobile_privacy
-
-response
-{
-  "items": [
-    {
-      "event_id": "evt_001",
-      "section_title": "第三方SDK信息",
-      "change_type": "modified",
-      "impact_level": "high",
-      "topic_tags": ["sdk_disclosure"]
-    }
-  ]
-}
-API-00-07 获取供 AGENT-01 使用的变化包
-
-这是最关键接口。
-
-GET /api/crawler/updates
-
-query 参数
-app_name
-business_line
-topics（逗号分隔，可选）
-since（可选）
-limit（可选，默认 50）
-response
-{
-  "peer_updates": [
-    {
-      "source_name": "中国银行手机银行隐私政策",
-      "source_type": "peer_bank",
-      "version_date": "2026-03-29",
-      "topic_tags": ["sdk_disclosure"],
-      "changed_sections": [
-        {
-          "section_title": "第三方SDK信息",
-          "change_type": "modified",
-          "excerpt": "......"
-        }
-      ]
-    }
-  ],
-  "regulatory_updates": [
-    {
-      "source_name": "APP个人信息收集使用问题通报",
-      "source_type": "regulator",
-      "version_date": "2025-05-06",
-      "topic_tags": ["sdk_disclosure", "permission_usage"],
-      "changed_sections": [
-        {
-          "section_title": "SDK问题",
-          "change_type": "new",
-          "excerpt": "未逐一列出SDK收集使用个人信息情况......"
-        }
-      ]
-    }
-  ],
-  "sdk_updates": [
-    {
-      "source_name": "极光 SDK 合规指引",
-      "source_type": "sdk_vendor",
-      "version_date": "2023-11-23",
-      "topic_tags": ["sdk_disclosure", "init_after_consent"],
-      "changed_sections": [
-        {
-          "section_title": "合规使用三步走",
-          "change_type": "current_reference",
-          "excerpt": "请务必在用户同意《隐私政策》之后，再初始化SDK。"
-        }
-      ]
-    }
-  ]
-}
-8. 与 AGENT-01 的输入契约
-
-你现在的主链路里，AGENT-01 吃的是：
-
-peer_updates
-regulatory_updates
-
-然后输出：
-
-peer_summary
-reg_summary
-reference_clauses
-risk_alerts
-
-所以 AGENT-00 对 AGENT-01 的最优输入契约如下。
-
-8.1 输入字段定义
-peer_updates[].source_name
-
-来源名称
-
-peer_updates[].source_type
-
-固定值：peer_bank
-
-peer_updates[].version_date
-
-版本日期
-
-peer_updates[].topic_tags
-
-变化标签
-
-peer_updates[].changed_sections[]
-
-变化章节数组
-
-变化章节字段
-section_title
-change_type
-excerpt
-
-监管和 SDK 更新结构完全相同，只是 source_type 不同。
-
-8.2 AGENT-01 输入契约对象
-{
-  "peer_updates": [],
-  "regulatory_updates": [],
-  "sdk_updates": [],
-  "app_name": "手机银行APP",
-  "business_line": "retail"
-}
-8.3 AGENT-01 输出建议升级
-
-建议把你现有 PeerRegSummary 升级成下面结构：
-
-{
-  "insufficient_context": false,
-  "peer_summary": "......",
-  "reg_summary": "......",
-  "mandatory_requirements": [
-    "第三方SDK应逐一披露用途与处理信息类型"
-  ],
-  "peer_best_practices": [
-    "头部银行普遍将权限用途绑定到具体业务场景"
-  ],
-  "reference_clauses": [
-    {
-      "source_name": "中国银行手机银行隐私政策",
-      "source_type": "peer_bank",
-      "version_date": "2026-03-29",
-      "section_title": "第三方SDK信息",
-      "topic": "sdk_disclosure",
-      "clause": "......",
-      "applicability": "reference"
-    }
-  ],
-  "risk_alerts": [
-    "第三方SDK用途披露不足"
-  ],
-  "missing_topics": [
-    "data_retention"
-  ]
-}
-为什么要升级
-
-因为后面的 AGENT-02 / AGENT-03 不只需要“摘要”，还需要：
-
-哪条是监管强制
-哪条是同业参考
-哪条缺失了
-原文在哪
-9. 抓取频率
-9.1 推荐频率
-头部银行隐私协议页
-daily
-监管通报/规则页
-4h
-SDK 官方隐私/合规页
-daily
-9.2 重试规则
-抓取失败：10 分钟后重试 1 次
-连续失败 3 次：标记 degraded
-连续失败 7 天：进入人工检查队列
-10. 版本比对规则
-10.1 去重
-
-使用：
-
-raw_hash
-normalized_hash
-
-二者均未变化则不生成新版本。
-
-10.2 diff 粒度
-文档级
-条款级
-10.3 变化分类
-added
-removed
-modified
-10.4 影响等级规则（初版）
-high
-
-涉及：
-
-SDK 披露
-敏感个人信息
-权限用途
-跨境传输
-未成年人条款
-medium
-
-涉及：
-
-数据共享表述细化
-用户��利行使方式
-数据保留期限
-low
-
-涉及：
-
-表述润色
-结构调整
-非实质性排序变化
-11. 错误码
-错误码	含义
-4001	来源配置缺失
-4002	URL 非法
-4003	解析失败
-4004	无正文内容
-5001	抓取失败
-5002	版本比对失败
-5003	入库失败
-5004	输出结构化失败
-12. 验收标准
-AC-00-01 来源管理
-
-新增来源后可被定时任务读取。
-
-AC-00-02 抓取成功
-
-对启用来源能成功抓取正文并生成原始快照。
-
-AC-00-03 去重成功
-
-正文无变化时，不生成新版本。
-
-AC-00-04 版本变化识别
-
-正文有变化时，能生成 diff_event。
-
-AC-00-05 条款切片
-
-标准化文档可拆成条款级 clause_chunk。
-
-AC-00-06 AGENT-01 供数
-
-GET /api/crawler/updates 能返回 peer_updates / regulatory_updates / sdk_updates。
-
-AC-00-07 可追溯
-
-任一 risk_alert 最终都能回链到：
-
-source_name
-version_date
-section_title
-原文 excerpt
-13. 第一阶段研发建议
-Sprint 1
-source_registry
-crawl_job
-raw_snapshot
-手动抓取接口
-单页面正文抽取
-Sprint 2
-normalized_document
-clause_chunk
-diff_event
-GET /api/crawler/updates
-Sprint 3
-定时调度
-重试机制
-topic tagging
-与 AGENT-01 联调
-14. 最终建议
-
-你现在不要改 AGENT-01 的主职责。
-最优做法是：
-
-新增 AGENT-00 / 抓取子系统，让它产出结构化变化包；AGENT-01 继续做“变化归纳与条款摘要”。
-
-一句话压缩：
-
-AGENT-00 负责“找、抽、比、存”，AGENT-01 负责“筛、归类、摘要”。