# `packages/rules` — 规则引擎（TD-10 自研数据驱动决策表）

架构 §8.1 / ADR-05：**结论由规则引擎产出，LLM 只负责表达**（防幻觉红线）。

## 模块

- `dsl.py` —— kb_rule DSL 的 pydantic 解析校验 + 画像匹配（纯逻辑）。封闭词汇表：
  未识别的键一律拒绝而非忽略，规则不会静默失效。
- `engine.py` —— 纯域求值：priority 降序（同序按 confidence）、`is_hard` 的 avoid
  命中进 `hard_blocks`（调用方必须据此做硬过滤）、高优先级 avoid 剔除严格低优先级
  的冲突 recommend（用户禁忌 95 压过专业推荐 ≤90）。
- `repo.py` —— kb_rule 表的唯一读写点（经共享 ORM 访问）。
- `service.py` —— CRUD、draft→published→archived 状态机（同 T6 语义）、published
  规则进程内缓存（量级 ~400，整表载入，管理动作后 `invalidate()`）。

## 设计约束

- **规则是数据不是代码**。求值器是代码，规则本身在 `kb_rule` 表里，
  顾问在后台维护，改规则不发版（NFR-MAINT-05）。
- 每次求值必须输出**命中链**（`rule_hits`：rule_key/priority/category/is_hard/
  confidence/explanation），这是报告与 Agent 可解释性的来源，
  也是 `pf_diagnosis.rule_hits` 与 `ag_message.rule_hits` 的数据来源。
- p95 < 50ms（FR-KB-05）：求值是纯内存操作，400 条规则量级实测远低于预算
  （见 `tests/unit/test_rules_engine.py` 的基准用例）。
- 黄金集雏形：`tests/unit/test_rules_golden.py`（固定画像 → 期望输出，含硬禁忌
  与多规则叠加场景），改引擎行为必须先过黄金集。
- 已发布规则集缓存在进程内；Redis TTL + 发布广播失效（架构 §10）为后续接入项，
  失效入口已收敛到 `service.invalidate_published_cache()`。