专注计时器最容易让人安心的时刻，是屏幕上那枚安静的绿色圆环准确走到零；最容易让人焦虑的时刻，却往往发生在更新应用之后：上周的完成记录没有了，原先的八次目标变回默认值，或者历史列表出现了两次同一条会话。FocusGarden 已经实现截止时刻倒计时、前后台恢复、历史去重、七日统计和周目标配置。最后一篇选择一个比动画更值得做的收尾主题：当本地数据结构需要升级，怎样让旧记录能被理解、异常能被发现、恢复操

巡检工具最难交付的部分，不是把三个任务勾成绿色，而是面对一台刚从无信号配电间拿回来的设备，能够回答三个问题：这条记录存在本机吗？接收端是否真的确认了？如果两者不一致，应该由谁做出下一步决定？ShiftCheck 从页面状态、草稿保存、版本冲突走到离线待办和人工裁决，这一篇不再添加新的同步噱头，而是给整个工程建立一套可以重复执行的启动检查、人工恢复和交付验收。只要存在任何没有证据的状态，就不把它包装

PageShelf 的最后一次工程评审，没有再讨论书卡是不是足够漂亮。问题发生在一名图书管理员的日常操作中：他先勾选“只看待处理”，再把平板窗口缩成窄屏，书架只剩两本书；随后其中一本被借走，另一本被删除。页面若仍保留上一轮的滚动偏移和当前详情 ID，就可能出现看似有内容、实际上卡片为空，或点击返回后落在一段空白里的情况。对于一套日常使用的借阅工作台，空态不是四本示例数据之外的小事，而是状态模型是否

一名开发者在“工程文档速查”里连续输入 n、na、nav。第三次请求最先返回，界面已经出现 Navigation、NavDestination、NavPathStack 三条建议；不久后，第一次请求才慢吞吞结束，却把结果覆盖成一组与当前搜索词无关的项目。页面没有崩溃，日志也未必报错，用户却会怀疑搜索框的质量。根因不是 TextInput 更新太快，而是我们默认异步完成顺序等于用户输入顺序。 这类问

专注记录做得越详细，越容易产生一个看似简单的产品争论：用户设定“每周完成 8 次专注”，统计页到底应该显示 8 次、8 天，还是 8 × 25 分钟？这三项都能画成漂亮的进度条，但表达的是不同承诺。FocusGarden（专注花园）上一期已经按日归组 SessionEntry，这次不再复制一份统计结果，而是给用户增加一个可以保存和修改的每周完成次数目标，让统计值与目标值独立变化。 沿用 focus

“补交失败，请重试”看起来是个无害提示，在巡检系统中却可能诱导危险操作。值班员刚把“备用电源”改为已检查，设备进入离线状态；恢复链路后，系统发现另一名同事已经更新了任务。此时反复按“补交”，不会让旧数据变新，反而可能掩盖现场到底采用了谁的结果。更合适的界面不是一个无限旋转的加载圈，而是一张能说明分歧、允许用户选择的冲突处置单。 本篇沿用 ShiftCheck 现场巡检台：三项 CheckTask

在 PageShelf 借阅工作台里，窗口从平板宽度收窄到手机宽度，书卡会自动从四列变成一列。上一期加入 Navigation 和 NavPathStack 后，点进《算法的日常》再返回，也能保留“只看待处理”。然而一次普通的拖动窗口仍可能制造新问题：书架原本停在靠下的位置，列数改变，卡片被重新排版；同样的纵向偏移不再对应同一本书。有时用户甚至误以为筛选条件丢了，实际上只是“视口的位置”与“业务记

把一笔 128 元账单平均分给三个人，看起来不值得专门做一个应用。但只要把“128 ÷ 3”的结果直接当成三个人的付款金额，界面就很容易出现 42.666666…；即便显示层把每人格式化为 42.67，三份相加也会变成 128.01。真实需求是每人只看到两位小数、所有份额加起来必须严格等于原始账单。这与普通表单的“输入是否为空”是两类不同的问题，关键在于金额的表示与尾差的分配规则。 这里制作一个独

打开 FocusGarden（专注花园）的“专注记录”，能看到每次完成专注的时间和任务标签，但如果想回答一个更日常的问题——“过去七天，哪几天真正完成了专注？”——原来的历史列表就显得不够直观。把最近七条记录写成“最近七天”也会得出错误结论：某天完成了三次，另一天一次没有，列表依旧可能只有七条。本篇从会话源数据计算每日汇总，刻意不再引入另一套可变的累计计数。 前文的计时器依旧使用 fullSec、

巡检现场的网络往往不像办公室那样稳定。值班员走到配电间，勾选“备用电源”后进入没有信号的通道；等他回到有网络的位置，页面里的勾选还在，却无法判断这笔操作究竟有没有交到确认端。此时最危险的交互不是“提示失败”，而是把本地操作完成写成远端确认成功。ShiftCheck 前三篇依次解决了任务状态更新、草稿可靠落盘和版本冲突，本篇将两者之间最后一段空白补上：确认请求先落入本机待办，再由一个受控的串行流程补