# 规则引擎逻辑重构计划：支持多级条件与流程编排

您说得非常对。目前的扁平化规则（单层 `if-match-then-action`）在处理“组合条件”时会导致规则数量爆炸，配置极其繁琐且难以维护。

**核心问题**：现在的结构是“单层匹配”，无法表达“先判断A，再判断B”的逻辑。
**您的需求**：
1.  **第一层（事件分类）**：先根据 `event_define_no` 判断业务类型（微信支付/退款/投诉），决定用哪个**模板**。
2.  **第二层（渠道分发）**：再根据 `remark` 判断归属（门店002/003），决定推给哪个**渠道**。

为此，我将对系统进行深度的逻辑重构，引入**“规则组（Rule Group）”**和**“条件链（Condition Chain）”**的概念，但为了保持用户界面的直观性，我设计了更符合您直觉的 **“流程树（Flow Tree）”** 方案。

## 方案设计：嵌套式规则引擎

### 1. 数据模型升级 (DB)
*   **ProcessingRule 表变更**：
    *   新增 `parent_rule_id` (Integer, nullable): 允许规则嵌套。子规则只有在父规则匹配成功后才会执行。
    *   此变更实现了“树状结构”。

### 2. 核心逻辑升级 (Engine)
*   **递归匹配**：
    *   引擎首先查找所有 `parent_id` 为空的**根规则**。
    *   如果根规则匹配成功（例如 `event_define_no == pay.wx_scaned`）：
        *   执行根规则挂载的动作（例如：设置模板变量 `pay_method="微信"`）。
        *   **继续检查其子规则**。
    *   子规则（例如 `remark == imcgcd03`）匹配成功：
        *   执行子规则挂载的动作（例如：推送到 `渠道003`）。
        *   动作执行时，会**继承**父规则上下文中设置的变量（如模板ID或变量）。

### 3. 用户界面重构 (UI)
*   **端点详情页**：
    *   不再是扁平列表，而是**树形展示**。
    *   在每个规则卡片内部，增加“**添加子规则**”按钮。
    *   视觉上通过缩进或连线表示层级关系。
    *   支持**拖拽排序**（优先级调整）。

## 实施步骤
1.  **数据库迁移**：为 `ProcessingRule` 添加 `parent_rule_id` 字段。
2.  **后端逻辑**：重写 `engine.py` 的 `process` 方法，改为递归处理。
3.  **前端交互**：重写 `endpoint_detail.html`，使用递归模板渲染规则树。
4.  **无损更新**：编写 SQL 脚本或逻辑，确保现有数据平滑迁移到新结构（现有规则都视为根规则）。

这样，您的配置流程将变为：
1.  **根规则**：`event_define_no == pay.wx_scaned`
    *   动作：设置变量 `pay_type="微信"`（**不需要指定渠道**）
    *   **子规则 A**：`remark == imcgcd02`
        *   动作：推送到 `渠道002`（**复用父级的模板设置**）
    *   **子规则 B**：`remark == imcgcd03`
        *   动作：推送到 `渠道003`

这完美符合您的思维模型。