LedgerDock前七篇已经把CSV导入中比较难缠的事情拆开处理：引号里的换行要留在同一条记录里，坏金额要保留行列位置，金额以整数分计算，重复文件通过指纹拦截，分块解析时界面进度不能跟着每个字符刷新。最后要补的不是另一种解析算法，而是把核对完成的结果交出去，同时确保本地HAR模块升级后旧数据还能读取。 当前账单依然是四条：TX001物料12500分、TX002配件8600分、TX003差旅金额1

LedgerDock的CSV导入已经跨过了几道容易遗漏的关口：引号字段可以跨物理行，错误行能够定位到起始位置，金额统一用整数分保存，重复批次则按业务指纹识别。前六篇为了看清每个分支，始终使用四笔账单：TX001物料12500分、TX002配件8600分、TX003差旅的原始金额12.5x、TX004办公4300分。有效合计25400分，目标27000分、差额1600分。这些数值会继续作为分块边界的

上一节已经把LedgerDock的金额统一成整数分：TX001为12500分，TX002为8600分，TX004为4300分，有效合计25400分；TX003的12.5x金额仍放在错误列表。目标对账单是27000分，正向差额1600分。但进入账单导入操作后，一个新问题很容易让这些数字失去意义：用户连续选择两次费用导入.csv，如果每次都把三条有效流水插入本地账本，就会出现六笔支出，有效合计也被重复

CSV解析器到了第四篇，已经能把跨行说明字段还原成一条业务记录，并指出错误所在的物理位置。接下来要处理的是最容易被忽略的财务细节：金额。界面展示的是“125.00元”，文件给到的却可能是“12500分”；如果直接用小数求和，金额位数和类型转换的差异会传到对账页。更糟的是，TX003的金额原文为12.5x，如果把它交给宽松的数值解析函数，有机会误读成一个合法前缀。 这份费用导入.csv继续沿用前四篇

上一节的CSV扫描器已经能够把跨行引号保留在同一条业务记录里，但财务同事真正需要看的不是“文件有一条坏记录”，而是错误落在第几行、哪一个字段、哪一列。TX003的金额写成12.5x时，如果只报“记录3格式错误”，用户还要自己回到原始CSV查找。更麻烦的是，TX002的说明字段从“配件”换到下一物理行的“需复核”，后面所有记录的物理行号都会比业务记录序号多一。 LedgerDock仍处理同一份费用导

上一节把 CSV 行解析封装进本地 HAR 后，调用方拿到的是稳定的 CsvParserPort 和错误结果。接着要处理一个文件导入中很容易被漏掉的场景：一条账单的说明列被双引号包裹，说明本身又包含换行。此时把文本先按 \n 拆成数组再送给单行解析器，会把一个合法账单拆成两条记录，后面的行号、金额和错误定位也会一起错位。 本篇仍使用 LedgerDock 的四条费用明细。TX001 金额 1250

上一节的费用导入入口已经能把四条 CSV 明细分成三条有效记录和一条错误记录。真正让它适合长期维护的下一步，不是继续往 ImportPage.ets 塞功能，而是把解析能力从入口页面抽离出来。财务账单以后可能出现多行引号、不同编码和不同金额策略；如果页面直接引用解析器的内部文件结构，一次目录调整就能牵连整套导入页面。 这里把解析协议做成工程内的独立 HAR 模块，由 ohpm 以本地源码依赖方式接

财务同事从不同表格软件导出费用账单时，最棘手的不是把文本按逗号拆开，而是把格式错误与有效明细分开处理。一个金额字段混入字母，不应该让另外三条准确的记录跟着消失；反过来，也不能看到三条正常明细，就悄悄把错误行写进本地账本。这个导入入口在界面上看起来只是一个文件选择和确认按钮，真正决定质量的是中间那层可替换的解析协议。 本次从四条固定的费用明细切入：TX001、TX002、TX003、TX004。前三

工序排班台已经走到跨窗口协作这一步。前面几篇解决了容器换列、滚动锚点、时间轴映射、工位冲突、键盘编辑和异步回执乱序，但还有个看起来不起眼的问题：同一套排程数据被两个窗口打开，左边窗口选中焊接B02，右边窗口切到质检C03，为什么左边的选中框也跟着跑了？最初把所有状态塞进一个单例对象时，这种串联几乎不可避免。排程记录需要共享，页面焦点却不应该共享。 这里把应用中的窗口分成“主看板”和“对照看板”。两

排程页面已经有两条分开的交互状态：橙色表示业务选中的B02焊接，青色表示键盘停留的C03质检。上一节按十分钟步长移动候选时间，确认时才会检查工位占用。接上异步保存接口以后，麻烦反而出现在用户按下确认之后：连续两次调整C03，第二次保存的回执可能先于第一次到达。页面如果只写this.c03 = receipt.slot，晚到的旧回执会把新时间覆盖，时间轴看起来像自己退回了一格。 这个问题与网络快慢没