root包的require字段不触发仓库查找，仅其声明的依赖才按repositories顺序匹配；禁用packagist.org是私有源生效前提，否则会fallback覆盖；repositories顺序仅对明确声明支持该包的仓库有效。
Root包的require字段不走仓库优先级逻辑
Composer 的 root package（即项目根目录下的 composer.json）本身不被当作“可安装包”去查仓库，它的 require 字段只是依赖声明起点——真正触发仓库查找的是这些被 require 的包名，而不是 root 包自己。
这意味着：即使你把私有仓库放在 repositories 数组最前面，也**不会影响 root 包自身的解析行为**（它压根不进仓库查找流程），只会影响它所 require 的那些包从哪下载。
-
require中的包，才会按repositories顺序 +"packagist": false状态被匹配 - root 包没有版本号约束（除非显式加
"version"字段），也不参与 SAT 求解器的 conflict/require 交集计算 - 如果你在 root
composer.json里写了"require": { "my-org/utils": "^1.0" }，那才真正启动仓库查找；但"name": "my-org/my-app"这行只是元信息，无实际解析权重
为什么禁用 packagist.org 是私有源生效的前提
只要 "packagist": true（默认未显式配置时即为 true），Composer 就会把官方源作为兜底仓库——哪怕你的私有源排第一、且明确声明了 "packages"，只要它没返回完整元数据（比如缺少某个版本的 dist 或 source），Composer 就会 fallback 到 packagist.org 去找同名包，导致私有代码被覆盖。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须显式写
"packagist.org": false或"packagist": false（后者是简写，效果相同） - 禁用后，所有包都必须由
repositories数组中某个仓库“明确认领”，否则直接报Package not found - 常见错误：只调换顺序但没关 packagist，结果私有
my-org/utils被官方同名包劫持，而你根本没意识到
repositories数组顺序只对“命中包”起作用
不是所有仓库都会被查询。Composer 不是挨个发 HTTP 请求试错，而是先检查每个仓库是否“声明支持该包”——通过 packages 白名单、pattern 正则、或 type 为 vcs 时的自动推导（如 Git URL 含 vendor/package 名）。
- 靠前的仓库如果没声明
"my-org/utils"，哪怕它是 composer 类型源，也会跳过 - 靠后的仓库如果在
"packages"里写了"my-org/utils": {"0.1.0": {...}}，就会被选中 - 所以“顺序即优先级”的前提是：至少有一个仓库明确覆盖了目标包；否则顺序再靠前也没用
- 典型配置陷阱：私有 Satis 仓库的
packages.json没更新，漏掉了新发布的版本，结果 Composer 查完所有仓库都找不到，报错而非 fallback
conflict 和 require 在 root 包里是全局约束，但不改变仓库查找路径
conflict 字段和 require 一起喂给 SAT 求解器做逻辑求解，但它**不参与仓库路由决策**。它只决定“哪个版本能被接受”，不决定“从哪个仓库拿这个版本”。
- 例如：
"require": { "monolog/monolog": "^2.0" }+"conflict": { "monolog/monolog": " → 最终只会装 <code>2.10.0+的版本 - 但如果私有源只提供了
2.9.0，而 packagist.org 有2.10.0，且你没关 packagist，那 Composer 就会从官方源装——conflict并不会阻止它去找 packagist - 要确保私有源版本满足 conflict，就得让它成为唯一可用源，再次回到“关 packagist + 私有源置顶 + packages.json 完整”这个闭环
