KitchenPulse 已经可以同时管理灶台和烤箱两条倒计时，允许暂停、恢复、重新开始，能够在应用返回前台时按照截止时间重新计算剩余秒数；上一轮又加入可编辑的分钟预设。功能列表看起来完整，真正的工程难点却在最后一步：用户可能在烤箱倒计时进行中编辑预设，随后锁屏、进后台，等五分钟再打开应用，发现灶台早已完成，而烤箱仍在计时。界面要呈现哪一份状态，哪些事件需要补充提醒，哪些动作绝不能重复？这不是再添

一张活动卡片从列表进入详情、完成收藏、退回列表，最后重新打开应用仍然显示刚才的选择，这条看似普通的用户路径穿过了 CityStage 的多个状态边界。前五篇分别解决筛选状态所有权、Navigation 详情跳转、Preferences 收藏落盘、目录异步请求竞态，以及 LazyForEach 的稳定键与图片失败回退。收尾阶段真正要回答的问题是：当这些单独成立的能力同时遇到断网、重建、重复请求和坏数

EnergyNest 的最后一道工程题，已经不在七日柱状图的配色上。假设用户在周日把 7.8 kWh 更正为 7.1 kWh，列表立刻显示新值，但顶部周总量仍是旧数字；或者用户查看“异常模式预览”后退出，下次打开却发现预览数据写进了真实账本。这两种情况都比一根柱子的视觉误差严重：界面看起来合理，数据却在不同环节产生了分歧。前面三篇分别完成了响应式看板、以日期为主键的 ArkData 落盘，以及缺失

一张物流取件码卡片，看上去比聊天页面简单：驿站名称、六位取件码、截止时间，再加一个“已取件”按钮。但如果把字号扩大到普通模式的 1.4 倍，最先出问题的往往不是字号，而是布局假设。原本一行放得下的驿站地址被截断，取件码和操作按钮挤在一起；屏幕朗读选中卡片时，又可能把“682419”读成一串难以分组的数字。对于站在快递柜前、单手拿着包裹的使用者，这些细小问题会直接拖慢完成任务的速度。 这篇采用一款独

“把烤箱预设从十二分钟改成十五分钟”，听起来只是修改一个数字；可如果用户正让烤箱倒计时，这个动作究竟是修改下一次的默认值，还是把已经运行的计时延长三分钟？KitchenPulse 前四篇已经实现双工位状态机、前后台恢复、Preferences 检查点及完成通知尝试。本轮不再重复定时器逻辑，而是单独设计一份可编辑的预设配置：编辑、确认、持久化以及对运行中任务的影响，全部采用明确的业务约定。 一、一个

用户从“展览”切回“全部活动”，CityStage 的目录数据已经更新，列表却出现另一种难追踪的问题：图片卡片偶尔显示上一条活动的海报，滚动位置也因为数据更新突然跳动。它不是第04篇处理的“旧请求覆盖新请求”，而是数据快照正确后，渲染节点怎样认出自己的业务身份。本篇延续 CityStage 的活动 ID、目录缓存、收藏状态和 Navigation 详情入口，处理长列表节点的稳定身份、图片加载状态以

EnergyNest 的七日图终于从示例数组接到了本地数据库，却出现了一个比布局更棘手的问题：当某天没有采集记录，界面应该画出多高的柱子？如果某天真实记录为零，又应该如何区别？如果某天突然读到远高于其余日期的电量，是否应该直接从周总量中删掉？这三个问题的答案决定了账本是否值得信任。上一章已经用 energy_day(day_key, wh, source, updated_at) 和日期唯一键完成

一份只有几千字节的 CSV 文件，也可能让移动应用陷入一连串尴尬：选择器返回了地址却打不开、中文名字被解码成乱码、表头顺序被改动后数据错列，甚至有两条错误记录混进了用户的正式账本。与把一段字符串简单 split(',') 然后展示相比，“导入”是一条完整的信任链。以 PlantLedger 植物养护记录为例，我们希望用户从系统文件管理器选择本地 CSV，先看到逐行验证结果，再主

厨房计时器只要能把 08:00 变成 00:00，就算完成了吗？对 KitchenPulse 而言，还差一层：用户需要知道“灶台·焖煮”已经结束，同时不应因为切换页面、重新进入应用而反复收到相同的完成提醒。前一篇用 deadlineMs 和 Preferences 检查点解决前后台恢复；本篇沿用 hob、oven 两个工位，把业务完成事件接到 HarmonyOS 的通知管理能力上，重点讨论授权、去

在 CityStage 的活动列表中，用户先点击“展览”，随即又改成“全部”。如果“展览”的请求慢半拍，第二次的“全部”请求先返回，页面短暂出现了完整列表，紧接着却被第一份旧响应覆盖。这不是接口数据错误，而是请求完成顺序不等于用户操作顺序。前面三篇已经完成筛选状态归属、详情导航和收藏落盘，现在我们要把写死的活动数组改为可刷新的目录源，并让网络不佳时的界面仍然有明确的状态。 一、把活动目录和收藏偏好