Monorepo代码审查必须嵌入PR流程，重点检查根composer.json的repositories配置、子包name与autoload一致性、require版本约束、symlink启用及CI中符号链接校验。
Monorepo 里做代码审查，根本不是“能不能审”，而是“不审就炸”。本地包之间互相 require、autoload 映射错位、symlink 没生效——这些都不会报错，但会在 CI 或上线后突然失效。必须把审查点嵌进 PR 流程里，而不是靠人眼扫 diff。
review 时重点看根 composer.json 的 repositories 配置
这是整个 Monorepo 本地包加载的开关，90% 的“装了却没用上”问题都出在这儿。
-
url必须是相对路径，比如"packages/*"，不能写"./packages/*"或绝对路径 —— 后者在 CI 机器上直接失效 - 通配符只认一层：
"packages/*"有效，"packages/**"或"**/utils"完全被忽略 - 如果子包在
packages/core-utils和apps/admin-api两个目录下，就得写两条path条目，不能只靠一个"packages/*" - 检查是否漏加
"options": {"symlink": true}—— 没这句，Windows 和某些 Linux 文件系统会静默 fallback 成复制，改代码不生效
子包 composer.json 的 name 和 autoload 是高频翻车区
CI 跑过、本地跑通，但 reviewer 一拉代码就 Class not found，八成是这里错了。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
name字段必须和根项目require中写的**完全一致**，包括大小写、斜杠方向："myorg/utils"≠"MyOrg/Utils"≠"myorgutils" -
autoload的 PSR-4 映射路径要对得上实际文件结构，常见错误是写成"MyOrg\Utils\": "src/"，但子包根目录下根本没有src/，而是lib/或直接平铺 - 别信 IDE 自动补全的命名空间 —— 它可能按文件夹名推断，但 Composer 只认
composer.json里写的那个
require 版本约束写法直接影响本地包是否被加载
写错版本号，Composer 就会绕过本地包，直奔 Packagist 去找“看起来匹配”的已发布版。
- 本地开发阶段统一用
"*"或"*@dev"，别写"^1.2"或"~2.0"—— 这些会触发 Packagist 回退逻辑 - 如果子包
composer.json里写了"version": "dev-main"，那根项目require得对应写"dev-main"，不能只写"*" - 改完
repositories或子包composer.json后，必须composer clear-cache再composer update myorg/utils，否则缓存可能让你以为改成功了
CI 脚本里必须显式校验 symlink 是否真实存在
光跑 composer install 不够，得确认 vendor 下指向 packages/ 的链接真建成了。
- 在 CI 的 test 阶段加一行：
test -L vendor/myorg/utils || (echo "symlink missing" && exit 1) - Linux/macOS 上还要防
noexec或nosymfollow挂载选项导致 symlink 创建失败（尤其 Docker 容器） - Windows CI（如 GitHub Actions 的 windows-latest）需确保 runner 启用了开发者模式，否则
mklink权限被拒，Composer 会静默降级为 copy
最难防的是 autoload 映射和 symlink 都对，但某个子包的 composer.json 里漏写了 type: "library"，导致某些工具（如 PHPStan、psalm）跳过扫描 —— 这类问题不会报错，只会让类型检查形同虚设。
