Composer 的 path 仓库仅支持 * 作单层通配符，且必须独占末尾一级目录（如 "../packages/*"），不支持 **、中间路径或前缀匹配（如 "../packages/*/src" 或 "../packages/my-*"）。
path仓库通配符写法只支持url字段中的*，不支持**或正则
Composer 的 path 类型仓库允许用 * 作单层通配符，但仅限于 url 值末尾一级目录位置。例如 "../packages/*" 表示扫描 ../packages/ 下所有**直接子目录**，每个子目录必须是合法包（含 composer.json 且有 name 字段）。它不会递归进 ../packages/a/b/ 这类嵌套路径。
常见错误现象：
-
"../packages/**"→ Composer 报错或静默忽略，**不被识别 -
"../packages/*/src"→ 不合法，通配符不能出现在中间或带子路径 -
"../packages/my-*"→ 不支持前缀匹配，*必须独占整个目录名层级
通配符路径生效的前提：目标目录必须存在且可读
即使写了 "../packages/*"，如果 ../packages/ 根本不存在，Composer 仍会报 Source path "../packages/*" does not exist —— 它先检查父目录是否存在，再遍历子项。这不是“找不到包”，而是“连包所在的文件夹都没看见”。
验证方法（Linux/macOS）：
-
ls -d ../packages/确认该目录存在 -
ls -1 ../packages/ | head -3看前几个子目录是否结构合规（含composer.json） - 注意大小写：
MyPackage和mypackage在 macOS/Linux 上是不同目录，但 Composer 匹配require时严格按name字段大小写
为什么composer update vendor/name有时不触发通配符重扫描
Composer 缓存了 repositories 的路径解析结果。当你新增一个包目录到 ../packages/ 后，直接运行 composer update vendor/name 可能仍找不到它，因为 Composer 没重新枚举通配路径。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
必须执行完整刷新动作：
-
composer clear-cache清掉内部路径缓存 - 再运行
composer update --lock或composer install，强制重新扫描所有path仓库 - 不要只更新单个包：
composer update vendor/name跳过仓库发现逻辑，只查已知包版本
通配符 + symlink 的权限陷阱（尤其 Windows）
默认情况下，Composer 对通配符匹配到的每个包都尝试创建符号链接。Windows 上若未启用开发者模式或未以管理员身份运行终端，symlink 会失败，导致部分包被跳过或退化为复制（可能不生效）。
稳妥做法是显式禁用软链：
{
"repositories": [
{
"type": "path",
"url": "../packages/*",
"options": {
"symlink": false
}
}
]
}
这样所有匹配包都会被复制进 vendor/，行为可预测；调试时再切回 "symlink": true 并确认环境支持。
真正容易被忽略的是：通配符本身不解决包名冲突问题。如果 ../packages/a 和 ../packages/b 都声明了相同的 name（如 "acme/utils"），Composer 只取第一个扫描到的，不会报错也不会合并 —— 你得自己保证目录名唯一或用 "options": {"versions": {...}} 显式覆盖版本号。
