tres-rollup-review

TRES Finance — 汇总审核

给定一条完整指定的汇总规则，精确计算它将认领哪些子交易——并应用其所有筛选条件——然后标记真正的问题。你不会设计新的汇总规则，也不会执行任何变更。

所有 GraphQL 调用都通过 TRES Finance MCP connector（execute 工具）执行。所有变量键和嵌套输入字段都必须使用 camelCase，绝不能使用 snake_case。

---

相较于 tres-rollup-rules 的新增内容

tres-rollup-rules 发现步骤只会在（钱包、资产、方向）层面归组子交易——它从不应用某个候选规则的完整筛选条件组合（费用 + method_ids + subtx_type + 金额上下限 + 交易对手 + excludeRollups）。本技能会针对每条规则，通过 subTransactionRollupRulePreview 查询（它会运行引擎的真实 query_sub_transactions）精确执行此操作，从而提供：

• 精确匹配数量 → 零匹配门槛（匹配数量为零的规则不得创建），以及
• 创建前的重叠识别，确保用户只会看到可行的提案。

本技能也可独立使用，用于审核他人提交的规则（模式 B）——这是发现技能未涵盖的场景。

---

两种模式

模式 A — 创建前门槛（由 tres-rollup-rules 调用）

当 tres-rollup-rules（通过 Skill 工具）调用本技能时，这些指令会加载到同一上下文中，该上下文已经包含候选规则对象——它们不是作为参数传入的，而是已经位于上方的对话中。逐条处理这些候选规则；对每条规则运行以下检查，并给出且仅给出一个判定：

• PASS — 规则无问题，可准备提案（包含精确的子交易数 + 父交易数）。
• DROP — 匹配 0 条子交易；不得创建。
• FIX — 配置有问题，并给出确切的修改方式（例如：“minAmount > maxAmount”，“INFLOW 规则中使用了 recipientIdentifier——应为 senderIdentifier”）。

重叠情况报告为备注，而不是 DROP/FIX（参见检查 2）。每条候选规则输出一行判定，然后返回 tres-rollup-rules 的步骤 2.5。

模式 B — 独立审核（按要求审核已提交/待处理规则时）

获取待处理规则并逐条审核；按规则汇总审核发现。

query PendingRollupRules {
  subTransactionRollupRule(status: "Pending", limit: 50) {
    totalCount
    results { id name interval startDate endDate status rule createdBy createdAt }
  }
}

状态筛选值使用标题式大小写（"Pending"、"Active"、"Disabled"）。如果 totalCount 为 0，则回复“此组织没有待处理的汇总请求”，然后停止。

---

真实规则 — 规则如何选择子交易

规则会认领符合以下所有条件的子交易（这与引擎的 query_sub_transactions 一致）：

• belongsTo_In: [internal_account_id]、asset_In: [asset_id]（资产 KEY），platform 匹配，balanceFactor 与 balance_factor 匹配
• 排除已汇总（excludeRollups）以及派生/锁定/已同步的子交易
• fees：EXCLUDE 会排除 GAS/FEE，ONLY 仅保留 GAS/FEE，INCLUDE 则全部保留
• 可选的缩小范围条件：method_ids、min_amount/max_amount、subtx_type、sender_identifier/recipient_identifier、original_sender_prefix/original_recipient_prefix

规则 JSON（存储/返回时）使用 snake_case。balance_factor = -1 表示 OUTFLOW，+1 表示 INFLOW——务必正确判断，否则所有方向检查都会反过来。

已验证的 subTransaction 筛选器名称

意图	筛选器
钱包	belongsTo_In: [ID]
按键筛选资产	asset_In: [ID]
方向	balanceFactor: Float（-1 / 1）
最小 / 最大金额	amount_Gte / amount_Lte
发送方 / 接收方	sender_Identifier_In: [String] / recipient_Identifier_In: [String]
方法 ID	tx_MethodId: String（单个）/ tx_Classification_MethodId_In: [String]
Sub-tx 类型	type: String / type_In: [String]（小写 FinancialAction 值）
排除已汇总项	excludeRollups: true
排除 Gas/手续费	excludeGasFees: true
日期	timestamp_Gte / timestamp_Lte（DateTime）

type / type_In 接受小写的 FinancialAction 值（"gas"、"fee"、 "reward" 等），与规则中的大写 subtxType 枚举大小写相反。因此， subtx_type 可精确计数（type: "<value>"），而 fees: ONLY ≈ type_In: ["gas", "fee"]。

注意：fees: ONLY 已经会筛选 GAS+FEE，因此 Gas/手续费汇总只需 fees: ONLY——再加上 subtxType: GAS 是多余的（还会缩小范围，仅保留 GAS，排除 FEE）。

typeId 不是此处的规则筛选器。 只有在与 type_In: ["rollup", "rollup_fee"] 配合时， type_id 才是汇总规则的 ID。用于其他类型时，它的含义完全不同。要检查现有汇总规则的产出，请查询 type_In: ["rollup","rollup_fee"], typeId: "<rule_id>"——切勿单独使用 typeId。

哨兵日期（操作说明）： 如果 startDate == "0001-01-01" 或 endDate == "9999-12-31"，请省略该边界（不要传入哨兵值——它可能无法解析）。 无界日期很常见，也更合适；这不属于问题。

证据： 链上哈希是 tx.identifier（子选择 tx { identifier }）， 而不是 typeId。示例还应获取 amount、sender { identifier }、 recipient { identifier }、asset { symbol key }。

---

范围 — DISABLED 规则不在范围内

只有 Active 和 Pending 规则处于生效状态。切勿查询、比较或标记 DISABLED 规则（它们是已被取代的版本）。

---

检查项

检查 1 — 精确影响（核心；始终运行）

通过 subTransactionRollupRulePreview 查询直接从引擎获取真实计数。该查询会在服务端应用所有规则筛选条件，并运行真正的 query_sub_transactions，因此你无需手动重建筛选条件：

query RollupPreview($rule: RollupRuleInputType!, $startDate: Date, $endDate: Date, $interval: Interval) {
  subTransactionRollupRulePreview(rule: $rule, startDate: $startDate, endDate: $endDate, interval: $interval) {
    subTransactionCount
    transactionCount
  }
}

将候选规则对象原样作为 $rule 传入，使用与创建变更相同的 camelCase 结构（internalAccountId、assetId、platform、balanceFactor、fees 使用 OUTFLOW/ONLY 等枚举名称，以及任何 methodIds/subtxType/minAmount/maxAmount/标识符）。始终传入 $interval，其值为候选规则的周期（DAY 或 MONTH）；它决定资格窗口边界如何规范化，因此，对相同数据，MONTH 规则和 DAY 规则可能返回不同的计数。startDate/endDate 为可选的 YYYY-MM-DD；若要使用规则完整且不受限的范围，则省略这两个参数。

该计数表示规则下次运行时实际会汇总的内容，而非所有时间内的原始匹配数：引擎会根据自身的资格逻辑处理窗口，因此当前未完成的周期和未同步／缓冲区尾部都会被排除。 transactionCount 是不同父级交易的数量。（已汇总的子交易也会被排除；若要了解现有规则已产生的内容，请参阅下文的现有规则部分。）

• subTransactionCount == 0 → 丢弃（模式 A）／阻止标记（模式 B）：“按配置匹配到 0 个子交易”——指出哪些筛选条件导致计数为 0（常见原因：minAmount > maxAmount、标识符方向错误，或日期范围颠倒）。说明原因才有帮助。

如果此组织的 MCP 架构中没有 subTransactionRollupRulePreview（通过 validate_query 或 introspect 确认），则改用完全筛选的计数查询：执行单个 subTransaction(... excludeRollups: true ...) 查询，使用上方已验证的筛选条件名称表应用规则的每一项筛选条件，并且只选择 totalCount。这种方式的精确度略低于引擎预览（不会排除未完成周期／缓冲区尾部）；报告数量时要说明这一点，并保留 ~ 前缀。

检查 2 — 重叠（仅供参考，不是硬性限制）

相同 internalAccountId + assetId + platform + balanceFactor 下，日期范围有交集且筛选条件并非互斥的其他 Active/Pending 规则（或其他候选规则），可能会匹配到部分相同的子交易。这不会阻止创建：引擎按 ID（PK）顺序逐条处理规则，因此，匹配多个规则的子交易始终会被同一条规则一致地认领。将其作为备注告知用户（其他规则的名称和 ID，以及最多 3 个示例交易哈希），让用户知晓——绝不要仅因重叠而丢弃规则或强制拆分。

无需单独进行配置验证。 日期顺序、方向错误的标识符、互斥前缀以及无效的 cutoffTime 都由创建变更强制执行（作为阻止性的 validationIssues 返回），此处不要重新验证。将开始日期设为跳过已锁定周期的日期是合理做法，不应标记（结束日期保持开放）。

现有规则的影响（模式 B — 审查 Active/Pending 规则）

不要仅因检查 1 返回的计数较低，就认定现有规则没有用。正在运行的规则已经汇总了其交易池中的交易，而这些汇总会从检查 1 的结果中排除——因此，一条一直正常工作的规则只会显示少量近期尚未汇总的子交易。还要统计它已产生的内容： subTransaction(type_In: ["rollup","rollup_fee"], typeId: "<rule_id>") { totalCount }。 两项结果都要报告：“当前匹配到 N 个新的子交易；已产生 M 条汇总记录”。只有在几乎没有产生任何内容且当前几乎没有匹配项时，规则才算无效。（如果规则筛选条件看起来已过时——例如，methodId 已无法匹配新交易——应说明这一点，并列出已产生与当前匹配的数量，而不是说规则“没有用”。）

输出

模式 A： 每个候选项用一行回复给 tres-rollup-rules： <#> <name>: PASS (<subtx>/<tx> sub-txs) / DROP — <reason> / FIX — <change>，并附上任何重叠说明。

模式 B： 每条规则对应一个发现区块。使用无层级的项目符号列表，每条都要提供具体证据；没有发现问题的检查项省略。始终包含影响说明。如果没有问题： “已审查 （id ）——在约 笔交易中匹配约 个子交易。未发现问题。”

---

规则

• 切勿查询、比较或标记已禁用的规则。
• 切勿提出新的汇总规则或优化方案——这属于 tres-rollup-rules 的职责。你只负责计算影响并标记问题。
• 切勿执行变更操作。
• 每项标记都必须附有证据（数量、日期、配置值或交易哈希）。