答案是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 vendorendor ame（Windows）看到JUNCTION才是成功；普通文件夹说明fallback了

autoload不生效，不是没加载，而是映射没更新

path仓库让包“存在”，但类能否被new或use，取决于autoload映射是否包含它的真实路径。即使本地包composer.json写了"psr-4": {"Acme\": "src/"}，主项目也不会自动同步这个映射。

• 每次修改本地包的autoload配置后，必须在主项目中手动运行composer dump-autoload -o
• Xdebug断点失效？检查IDE里设置的路径是否和真实磁盘路径完全一致（尤其Windows下C: vs c:）
• 如果本地包用了classmap，也要确保composer dump-autoload -o重新生成了映射表

真正卡住的地方往往不是版本号本身，而是symlink是否生效、autoload是否刷新、以及name/url是否严格对齐——这三个点没验清楚，调版本号只是白忙。