wandering
ceefe3c4eb
联机跑通 open→login→new_form→fill(basic)→page_state→close：财务系统真的落库（单据编号 202610020850，
basic 页点「下一步」即保存）。据此补上续填能力并把测试草稿清理干净（删除前后截图 + 复查 0 命中）。
- 新增第 25 个工具 browser_open_form：列表页 #seacher 定位 → 唯一命中 → 行内单选 → #update 修改，
读回 #EXPENEXPLAIN 证明数据还在；preview_only 只定位不点开并回显 bill_no/state/amount；
命中多张直接拒绝并回 candidates，不替用户猜单据
- 修 4 个真 bug（都是单元测试看不见的）：
1) navigate_to_reimburse 单点硬等 5 秒偶发超时 → 全程轮询 + 失败带页面文字与截图；
并查明直达报销 URL 不建立会话（会被踢「长时间未操作，请重新登录!」），门户点击链是必经
2) actor.close_all 用 atexit 注册无效：concurrent.futures.thread 的钩子走 threading._register_atexit，
比 atexit 早跑，executor 已 shutdown → close 提交不进去。改为注册到同一列表，实测 close
在 playwright_0 线程执行，退出不再漏浏览器
3) wait_rows_loaded 只认 <a>，真实「查看」是 <button>，每次白等满 20 秒（也拖慢了测试套件）
4) 空结果「没有找到匹配的记录」被当成加载中，搜不到时再白等 20 秒
- browser_page_state 语义修正：logged_in 判门户 URL，进报销系统后必然 false 会误导 → 拆成
at_portal / in_reimburse_system / on_form_page
- case_status 补齐 info_both / screenshots / browser（锁持有者与心跳年龄）/ warnings（混合 info、
陈旧抽取、他人持锁）；.browser.lock 文件名由 cases.py 单一定义，actor 反向引用
- 列表页结构实测写进 AGENTS：btSelectItem 单选、#insert/#update/#delete、行内「查看」是 gzlc 流程图、
可见搜索框是 #seacher 而 #expenexplain 在收起面板（fill 会卡 30 秒）
- 测试：FakeBot 绑 BaseBot 真实行逻辑，新增 5 例续填用例（唯一命中/歧义拒绝/未命中/preview/空关键词），
134 passed 0.36s；文档 docs/MCP.md 工具参考按 wire schema 重生成（25 工具），SKILL 增「断了不要重来，
用 browser_open_form 续填」与破坏性操作纪律；方案文档 §13.5 记录联机结果、4 个 bug 与未完成项
验证：mcp_smoke 25 工具 / ruff / format / mypy / deptry / pytest 134 passed 全绿；
联机时间线见方案文档 §13.5。仍用 --no-verify 提交并手跑等价检查（原因见 AGENTS 提交纪律）。
4.7 KiB
4.7 KiB
name, description
| name | description |
|---|---|
| reimbursement | 财务报销自动化（阜阳师范大学）：把发票、支付截图、出差申请单变成结构化报销数据， 生成低值易耗品申购单，并在财务系统填报。当用户提到报销、发票、差旅费、公务卡刷卡记录、 易耗品申购、财务系统填报时使用本技能。通过 mcp__arb__* 工具操作，禁止臆造财务数据。 |
财务报销（MCP 工具版）
接口细节与参数表见 docs/MCP.md。本文件只写"怎么做才对"的操作纪律。
流程
mcp__arb__case_create建会话，记下case_id与upload_page（手机扫码上传入口，告诉用户）- 材料入库：本地文件用
case_add_files(paths=[...])（路径必须正斜杠D:/Code/...）； 手机上传先落inbox/，再case_add_files(case_id, source="inbox")收取 case_render_pages：text_chars > 0就case_read_text读文本层（比读图准且省 token）， 否则读pages/<stem>/p01.png。PDF 自动转正已处理，但转正角度要看 meta.json- 逐张出 JSON →
case_save_extraction。字段定义用extraction_spec，判读细则见references/invoice-fields.md match_payments：必须逐条处理review_required（未匹配、发票总额小于支付总额、 一对多凑额）。贪心结果ok不等于"已核对"info_skeleton(info_type)取骨架 → 填值 →save_info（自动跑规则校验）。 拿不准的字段用validate_info(draft=...)不落盘反复试；规则原文rules_get- 普通发票：
doc_requisition生成 Excel 申购单（exclude剔除不参与申购的物品） case_status复查态势；要重跑用case_reset(scope)- 填报：
browser_open（默认有头）→browser_login→browser_new_form→ 按它返回的steps顺序逐个browser_fill(step=...)→browser_page_state复查 →browser_close（不提交也不存草稿）。browser_login返回need_human时，让用户在已打开的那个窗口里完成扫码/验证码，然后重调browser_login；browser_new_form在 travel_info 与 normal_info 同时存在时必须显式传kind。 - 中途断了（进程被杀、浏览器被关）不要重来一遍：重新
browser_open+browser_login后用browser_open_form(match=报销说明关键词)找回原单据续填。先preview_only=true核对返回的bill_no，确认后去掉该参数再打开；命中多张会直接拒绝。别再browser_new_form——那会多建一张单， 在财务系统里留下垃圾草稿
必须遵守
- 完整性不由你宣布：以
validate_info/save_info返回的校验报告为准；不完整就向用户要材料， 禁止说"可以提交了" - 不得臆造财务数据：金额、日期、发票号、卡号读不清就标出来问用户，不要猜
- 双通道冲突要复核：PDF 文本层与读图结论不一致时（尤其编号、卡号、金额位数），两条都不许默认采信，
重新放大该区域确认。已知文本层会把"标签"和"值"分段存储，且康熙部首类字符（
⽇⻔）NFKC 后仍不变形 - 不回显密码，不把凭据写进任何产物或日志
- 删除与提交都算破坏性操作：工具层只到填报，
#delete删除、点提交都由人在财务系统里自己做； 要清理测试单据也得先preview_only看清bill_no，再逐条核对状态与金额 - 产物只写
cases/<case_id>/（该目录已 gitignore，含身份证号与卡号） required: true的字段（含值为空串的备注类）必须存在于 JSON 里，这是刻意约束；用骨架别凭记忆造结构
提交必须交人工
submit_preview / submit_execute 还没实现，填完就是终点：把 browser_page_state 的截图与已填内容报给
用户，由本人在财务系统里核对后点提交（提交不可逆，错一条要写情况说明）。
浏览器被别的进程占用时返回 owned_by_other_process：让持有者 browser_close，或等心跳超时 180 秒自动接管，
不要绕过去另开一个 Chromium。步骤函数报错会带 screenshot（在 detail 里），把它给用户看比反复重试有用。
参考
references/invoice-fields.md— 七类票据的字段判读细则（火车票/支付截图/酒店/普通发票/事前申请单/出入库单/其他附件）references/travel-info-fields.md— 差旅报销数据：交通/住宿/会议费、支付方式、按人按天的补助清单references/normal-info-fields.md— 普通报销数据：明细与支付方式.agents/docs/plans/MCP化改造方案-2026-10-19.md— 架构决策与实测记录（含抽取质量闸门数据）