update for mcp

docs/architecture/backend-project-architecture.md

@@ -337,6 +337,31 @@ backend/app/
 - 当前实现见 `backend/app/mcp/server.py`，只暴露 `search_regulations` 一个 tool，内部直接调用 `get_agent_conversation_service()`。
 - `api/routes/status.py` 的 `GET /status/mcp` 是薄适配层：它只负责解析对外可达的 URL（`settings.mcp_public_url` 或从请求推导），其余全部交给 `mcp.server.get_mcp_status()`，路由不得直接读取 MCP 内部结构。
 
+### 4.7 `perception`
+
+职责：
+
+- 爬取外部法规源（CATARC、国标委强制性/推荐性、EUR-Lex）的列表页与正文（`infrastructure/perception/crawlers/`）
+- 基于内容哈希的变更检测入口，以及**确定性**的段落级差异分析（`regulation_differ.py`：对齐 + 字符级 diff + 数字/情态词/新增删除闸门），只有通过闸门的段落才调用 LLM 分类（`llm_pipeline.py`）
+- 站内通知的广播存储与每用户已读状态（`base_notification_store.py` 及 Mock/Postgres 实现）——广播给所有登录用户，不做订阅/角色过滤
+- 通过 Celery Beat 定时调度全量爬取（`infrastructure/tasks/perception_tasks.py`），调度间隔由 `perception_crawl_interval_seconds` 配置
+- 新事件或"显著变更"（数字/情态词变化，或整段增删）自动写入知识库：本地 markdown 分块（`LocalRegulationChunkBuilder`，与 `chunk_backend=aliyun` 的上传流程无关）→ 复用既有 `embedding_provider`/`vector_index` → 写入与 `/documents` 上传管线**同一个** Milvus collection
+
+非职责：
+
+- 不维护第二套知识库或第二套向量索引——爬取入库与手动上传共用 `get_embedding_provider()` / `get_vector_index()` 这两个端口实现，二者在检索侧不可区分
+- 不做外部推送渠道（Email/Teams/飞书/钉钉）——当前部署无 SMTP/Webhook 凭据，做了也无法验证；只做站内通知
+- 不做订阅/偏好引擎——所有登录用户收到同一份广播，按用户区分的只有"已读"状态
+- 不做整改任务追踪（责任人、期限、验收、证据归档）——PPT 原文将其标注为"扩展功能"，规模上属独立子项目，尚未开始
+- 变更检测判据不依赖 embedding 余弦相似度——该方法被证明无法区分数值/情态词变化（如"30米"→"20米"、"应当"→"宜"），已被字符级 diff + 语言学规则取代
+
+说明：
+
+- `application/perception/crawl_service.py` 的 `CrawlService.run_crawl()` 是本模块的核心编排：单个事件的每一步（结构抽取、影响评估、diff、通知、知识库索引）各自 try/except 包裹，任一步失败只记警告、不中断整次爬取。
+- `_is_significant()` 与 `should_index` 是同一份判据，被通知创建和知识库索引两处复用，避免出现"值得通知"和"值得入库"两套互相漂移的标准。
+- `postgres_event_store.py` / `postgres_notification_store.py` 与对应的 Mock 实现共享同一个开关 `settings.document_repository_backend == "postgres"`，与文档处理模块的 backend 切换方式一致。
+- MinIO 上的 `raw_storage_key` 字段（schema 中声明）目前无人写入；正文改为直接存 `regulation_events.raw_text` 列，供下次爬取做基线对比。
+
 ## 5. Module Responsibilities
 
 ### 5.1 `api`