本地path依赖不支持^、~等语义化版本约束，仅“*”合法；composer直接读取本地composer.json的version字段安装，不解析版本号、不查tag、不识别分支。
本地 path 依赖不支持语义化版本约束，"*" 是唯一合法写法；所谓“忽略版本限制”其实是误解——它根本没在做版本匹配，只是读取本地 composer.json 的 version 字段直接安装。
为什么 ^1.2.0 或 dev-main 在 path 仓库里无效
Composer 对 type: "path" 仓库的处理逻辑和 Packagist 完全不同：它不解析语义化版本、不查 Git tag、不识别分支别名。所有 ^、~、=、@stable 都被跳过，只认 "*" 这个占位符。
- 写
"myorg/utils": "^1.2.0"→ Composer 仍按本地包composer.json里的version值安装，同时报 warning：Skipped tag v1.2.0, no composer.json found - 写
"myorg/utils": "dev-main"→ 直接报错：Could not find a matching version，因为 path 类型不支持分支标识 - 真正起作用的只有
"myorg/utils": "*"，它强制 Composer 忽略远程规则，直读本地version字段
path 仓库生效的三个硬性前提
漏掉任意一条，Composer 就静默跳过整个仓库，composer install 时连 warning 都不抛，只会报 Could not find package。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
type必须是"path"（大小写敏感，"Path"或"package"都失败） -
url必须指向含合法composer.json的目录，且为**绝对路径或项目根目录下的相对路径**（如"./packages/my-utils"），末尾不能带/ - 本地包根目录下必须有语法正确的
composer.json，且含name和version字段（name格式必须为vendor/name，全小写、仅含短横线）
Windows 下 symlink 不生效的真相
你以为改了本地代码，vendor/ 里却还是旧逻辑？大概率是 fallback 到了 copy 模式——这不是配置问题，而是 symlink 能力未启用。
- 关键不在主项目
composer.json，而在**本地包自己的composer.json中必须声明"options": {"symlink": true}** - Windows 默认禁用符号链接，需以管理员身份运行终端，否则创建失败且无提示
- 验证是否真用了 symlink：
dir vendormyorgutils，看到JUNCTION才算成功；若显示普通文件夹，说明已 fallback 成复制
autoload 不生效？别怪 Composer，先看 PSR-4 映射
类 new 不出来、use 报错，往往不是 path 仓库没配对，而是自动加载路径没对上。
- 本地包
composer.json中的autoload（如"psr-4": {"MyOrg\": "src/"}）必须指向其真实源码目录 - 主项目执行
composer dump-autoload -o才会重新扫描并合并 autoload 映射 - IDE 断点失效？确认 IDE 里打开的文件路径和磁盘实际路径一致（尤其 Docker 或 WSL 环境下映射路径容易错位）
最常被忽略的是：path 仓库的 url 必须指向含 composer.json 的目录，而不是父级或同级；很多人把包放 ./packages/utils/src，却在 url 里填 "./packages/utils"，结果 Composer 根本找不到 composer.json，静默失败。
