答案是name或路径不匹配：name须大小写及分隔符（仅短横线-）完全一致，路径须指向含composer.json的目录且相对于主项目根目录，末尾不可加/；windows需管理员权限，docker需--cap-add=sys_admin。
path依赖require失败，90%是name或路径不匹配
Composer根本不会模糊匹配本地包的name或url，写错一个字符就静默忽略。常见现象是执行composer require vendor/name后报Could not find package vendor/name，但composer show --all里压根没它。
-
name字段必须和require中字符串逐字一致：大小写、分隔符（只允许短横线-，不能用下划线_或驼峰）、vendor名全部对齐 -
url必须指向**含合法composer.json的目录**，且是相对于主项目composer.json的位置，例如"../my-pkg"，不能是"./packages/my-pkg"（如果当前终端不在项目根目录） - 路径末尾不能加
/，"url": "../my-pkg/"会导致整个仓库被跳过 - Windows下路径含中文或空格可能触发PHP解析失败，建议全英文无空格路径
path依赖版本号写^1.2.0或dev-main会失效
path类型仓库不参与语义化版本解析，所有^、~、=、@stable都无效。它只读取本地包composer.json里的version字段值，然后硬绑定。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须用
"*"作为唯一约束，例如"my-vendor/my-local-package": "*" - 别写
"my-vendor/my-local-package": "^1.2.0"——它不起作用，还可能误导后续维护者 - 本地包
composer.json里"version": "dev-main"，而主项目require写"my-vendor/my-local-package": "^1.0"，就会冲突（dev-main不满足^1.0） - 想“锁定”内容，靠的是文件系统状态或Git commit hash，不是版本字符串
改了本地代码没生效？symlink没启用或fallback成copy了
path仓库默认尝试创建符号链接，失败时静默回退到复制（copy），结果你改本地源码，vendor/里还是旧副本——这是最隐蔽的调试陷阱。
- 关键不在主项目配
"symlink": true，而在**本地包自己的composer.json里是否声明了"options": {"symlink": true}** - Windows必须以管理员身份运行终端，否则symlink创建失败且无提示
- Docker需加
--cap-add=SYS_ADMIN并确认挂载方式支持symlink - 验证是否真用了symlink：
ls -la vendor/vendor/name（Linux/macOS）看到箭头，或dir vendor endor ame（Windows）看到JUNCTION才是成功；普通文件夹说明fallback了
autoload不生效，不是没加载，而是映射没更新
path仓库让包“存在”，但类能否被new或use，取决于autoload映射是否包含它的真实路径。即使本地包composer.json写了"psr-4": {"Acme\": "src/"}，主项目也不会自动同步这个映射。
- 每次修改本地包的
autoload配置后，必须在主项目中手动运行composer dump-autoload -o - Xdebug断点失效？检查IDE里设置的路径是否和真实磁盘路径完全一致（尤其Windows下
C:vsc:） - 如果本地包用了
classmap，也要确保composer dump-autoload -o重新生成了映射表
