chore: stewardPlanModel 适配注册表动作结构并更新规则表与日志

- stewardPlanModel 适配新的意图注册表动作步骤结构
- 更新交通/通信/差旅等财务规则表，补 2026-06-25 work-log

document/work-log/2026-06-25.md

@@ -28,15 +28,40 @@
   - 影响：模型给出低置信度差旅申请意图时不再直接建预览，先反问确认；闲聊类输入不再误触发模型规划，响应更快、减轻后端压力。
   - 局限：`agent-change-log` Skill 在当前环境不可调用，已按 AGENTS.md 规范手动增量更新本日志。
 
+- 22:40：我落地了注册表驱动的意图插槽架构,让新增意图从「改 6+ 处硬编码」降到「写一个描述符 + 执行函数 + 注册」,并端到端跑通了「查差旅标准」查询意图作为样板。
+  - Git 提交检查：`git fetch --all --prune` 后本地与 origin/main 同步(不 ahead 不 behind);工作区有本次新增/修改的后端文件。
+  - 背景：排查确认旧架构里 `task_type`/`assigned_agent`/`flow_id` 在 schema(Literal)、function call schema(enum)、model_plan_builder(白名单)、action_contracts(if/else)、action_executor(if/elif)五层硬编码,加一个意图要同步改 6+ 处,完全没有扩展点;且"查差旅标准"这类查询意图无任何位置(task_type enum 只有 expense_application/reimbursement)。
+  - 修改①(注册表核心):新建 `steward_intent_registry.py`——`IntentDescriptor` 声明 task_type/assigned_agent/signal_keywords/ontology_field_allowlist/action_steps_builder/executor/flow_id/prompt_fragment;新建 `steward_intent_bootstrap.py` 在 import 时注册 3 个意图(expense_application/reimbursement/query_travel_standard)。
+  - 修改②(schema 放宽):`schemas/steward.py` 把 `StewardTaskType`/`StewardAssignedAgent`/`StewardActionType`/`StewardFlowId` 从 Literal 改为 str,运行时校验下沉到 registry,让 schema 不再是扩展拦路虎。
+  - 修改③(执行分发):`steward_action_executor.py` 的 `execute()` 从 if/elif 链改为优先查 registry(`resolve_intent_by_action`)委托 executor;新增 `_dispatch_application_action`/`_dispatch_reimbursement_action` 分发入口;`SUPPORTED_ACTIONS`/`NOOP_ACTIONS` 改为与 registry 聚合(`all_side_effect_actions`/`all_noop_actions`)。
+  - 修改④(动作生成):`steward_action_contracts.py` 的 `build_task_action_steps` 改为查 registry 的 `action_steps_builder`;原 `_build_application_steps`/`_build_reimbursement_steps` 改公开供 registry 引用。
+  - 修改⑤(function schema 动态化):`steward_intent_agent.py` 的 task_type/flow_id enum 改为 `all_task_types()`/`all_flow_ids()` 动态生成;system prompt 改为从 registry 拼接意图列表 + 每个 intent 的 prompt_fragment。
+  - 修改⑥(白名单放开):`steward_model_plan_builder.py` 的 task_type 白名单改 `get_intent`;assigned_agent/flow_id/字段过滤全部改 registry 驱动;`_sanitize_model_ontology_fields`/`_sanitize_model_missing_fields` 改 per-task_type allowlist(`field_allowlist_for`);查询类意图(flow_id=None)跳过必填字段推断。
+  - 修改⑦(查询执行器):新建 `steward_query_executors.py`——`build_travel_standard_query_steps` 生成单步无副作用动作;`execute_travel_standard_query` 从槽位取 location/employee_grade/standard_category,复用 `DEFAULT_TRAVEL_POLICY_CONFIG` 按职级×城市分级查住宿/交通标准,拼装 Markdown 回复(补助标准因未纳入运行时配置用占位说明)。
+  - 修改⑧(门控适配):`steward_planner_extraction.py` 的 `_looks_like_ambiguous_travel_flow` 加查询信号词前置判断(命中查询意图直接返回 False,不走候选流程);`_build_task` 的 task_id/assigned_agent/label 改 registry 驱动;`steward_planner_fallback.py` 的 `_classify_irrelevant_input` 补充 registry signal_keywords 判断(避免查询类输入被判 off_topic);`steward_graph_planner.py` import bootstrap 触发注册。
+  - 修改⑨(前端):`stewardPlanModel.js` 的 `TASK_TYPE_LABELS`/`AGENT_LABELS`/`EXECUTABLE_STEWARD_ACTION_TYPES` 加 query_travel_standard/execute_travel_standard_query/policy_query_assistant。
+  - 验证:后端全量 steward 测试 **72 passed**(含新增 14 个:registry 7 + query executor 7);前端意图测试 **28 passed**;既有申请/报销/规划/动作执行/槽位决策链路全部无回归。
+  - 容器:容器名为 `x-financial-local-linux`(非 `local-x-financial-linux`),已运行 19 小时;后端测试在该容器内执行,venv 在 `/tmp/x-financial-server-venv`。
+  - 影响:现在加一个新意图(如查报销进度、查预算执行)只需:① 写 `IntentDescriptor` 声明 task_type/槽位/信号词/executor;② 注册进 bootstrap;③ 写执行函数。function schema、动作生成、执行分发、字段过滤、门控全部自动适配,零硬编码改动。
+  - 局限:补助标准(allowance)尚未接入运行时配置,查询时返回占位说明;前端查询结果当前以 Markdown 消息展示,未做卡片化;registry 只在后端,前端 task_type 分发仍是 `resolveNextActionContext` 的 if/else(本次只加了 query 分支,未全面注册表化)。
+
 ## 遗留问题
 
 - 09:18：官方 `quick_validate.py` 仍因当前 Python 环境缺少 `PyYAML` 无法运行，已用 frontmatter、必需文件、占位符和 diff check 做人工兜底。建议后续统一为 skill 校验脚本补齐依赖或增加无 PyYAML 的轻量校验路径。
 - 09:23：当前环境没有找到 Skill Creator 的 `quick_validate.py` 脚本文件本体，因此本次继续采用人工兜底校验。建议后续恢复系统 Skill Creator 脚本路径，或把轻量校验脚本纳入仓库级工具。
 - 21:30：`expense-application-fast-preview.test.mjs` 仍有 12 个既有失败（文案「小财管家」「此意图系统不支持」与 markdown 表格整块渲染相关），与本次意图门控改动无关，建议单独排查。
 - 21:30：本次未纳入范围的三项已记录：时间过滤维度扩展（仅支持 N天前/昨天/今天）、排除词两处重复维护、`handleInlineDraftDeletionIntent` 命名与职责不符，建议后续分批处理。
+- 22:40：补助标准(allowance)未纳入 `DEFAULT_TRAVEL_POLICY_CONFIG`,查询差旅标准时住宿/交通有确定数值,补助只返回占位说明。补助数据在 `server/rules/finance-rules/出差补助标准.xlsx`,后续需把补助标准接入运行时配置并在 `resolve_travel_standard_snapshot` 补全。
+- 22:40：前端查询结果当前以普通 Markdown 消息展示,没有像申请预览那样的卡片化视图;查询意图的前端分发仍是 `resolveNextActionContext` 的 if/else,未全面注册表化(本次只加了 query 分支)。
+- 22:40：`server/rules/finance-rules/` 下有两个 Excel(交通工具等级标准、交通费用预估表)被标记为 modified,疑似容器运行时产物,非本次代码改动,未处理。
+- 22:40：`agent-change-log` Skill 在当前环境不可调用,已按 AGENTS.md 规范手动增量更新本日志。
 
 ## TODO
 
 - [ ] 为 `quick_validate.py` 准备稳定运行环境，避免后续新增 Skill 时继续依赖人工兜底。（来源：09:18 技能校验）
 - [ ] 排查 `expense-application-fast-preview.test.mjs` 的 12 个既有失败（小财管家文案 / 表格整块渲染）。（来源：21:30 意图门控加固）
 - [ ] 评估意图门控剩余三项：时间过滤维度扩展、排除词常量抽取、`handleInlineDraftDeletionIntent` 重命名。（来源：21:30 意图门控加固）
+- [ ] 把补助标准(`出差补助标准.xlsx`)接入运行时配置,补全 `resolve_travel_standard_snapshot` 的 allowance 数值查询。（来源：22:40 注册表架构）
+- [ ] 前端查询结果卡片化,并把前端 task_type 分发也改成注册表驱动。（来源：22:40 注册表架构）
+- [ ] 在真实 LLM 连通环境下,用「我去武汉出差的住宿标准是多少」端到端验证查询意图识别→执行→回复。（来源：22:40 注册表架构）
+- [ ] 评估是否需要把 LangGraph 迁移 Phase 5(trace UI、legacy 收敛)与注册表架构的查询意图 trace 打通。（来源：22:40 注册表架构）

web/src/views/scripts/stewardPlanModel.js

@@ -16,7 +16,8 @@ import {
 
 const TASK_TYPE_LABELS = {
   expense_application: '费用申请',
-  reimbursement: '费用报销'
+  reimbursement: '费用报销',
+  query_travel_standard: '差旅标准查询'
 }
 
 const AGENT_LABELS = {
@@ -25,14 +26,17 @@ const AGENT_LABELS = {
   expense_application: '申请助手',
   reimbursement_assistant: '报销助手',
   reimbursement: '报销助手',
-  expense: '报销助手'
+  expense: '报销助手',
+  policy_query_assistant: '政策查询助手',
+  query_travel_standard: '政策查询助手'
 }
 
 const EXECUTABLE_STEWARD_ACTION_TYPES = new Set([
   'save_application_draft',
   'submit_application',
   'create_reimbursement_draft',
-  'associate_attachments'
+  'associate_attachments',
+  'execute_travel_standard_query'
 ])
 
 export function buildStewardPlanRequest({