直接修改 composer.json 顶层 minimum-stability 字段（与 require 同级），值为小写 dev/alpha/beta/RC/stable（RC 必全大写），并配 prefer-stable: true；改后需运行 composer update --lock；它仅约束未显式标注稳定性的包版本。
直接改 composer.json 就行，不用插件也不用命令
设 minimum-stability 就是改项目根目录下 composer.json 的顶层字段，和 require 同级。它不是命令行开关，也不是插件配置，写错位置（比如塞进 config 或 extra 里）就完全无效。
-
minimum-stability必须是小写字母：可用值只有dev、alpha、beta、RC、stable（注意RC必须全大写，rc或Rc会被忽略，退回到默认stable） - 改完必须运行
composer update --lock或composer update，否则composer.lock不刷新，新设置不生效 - 它只影响“没显式写稳定性后缀”的包。比如
"monolog/monolog": "^3.0"会受约束；但"monolog/monolog": "^3.0@stable"就完全绕过它
为什么加了 minimum-stability 还报 “Could not find package”
这不是配置没生效，而是 Composer 在按稳定性排序过滤版本时，发现没有一个可用版本满足你设的最低级别——常见于包根本没发布对应标签的版本，或你查错了分支名。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确认包真实有哪些版本：
composer show -a vendor/package-name，看输出里每行末尾括号里的标签，比如v2.0.0-beta1 (beta)或dev-main (dev) - 如果只看到
v1.5.0 (stable)，却写了"vendor/package": "@beta"，那必然失败——beta 版本压根不存在 - 私有包或未同步到 Packagist 的分支（如 GitHub 上刚推的
dev-feature），composer show -a也查不到，得手动加仓库源
prefer-stable: true 不是可选项，是必选项
只设 minimum-stability: "beta" 而不配 prefer-stable: true，Composer 可能选 v3.0.0-beta3 而不是已发布的 v2.9.5 (stable)，哪怕后者完全满足 ^2.0 约束——因为 beta 版本“更新”，它更“符合语义版本优先逻辑”。
-
prefer-stable: true意思是：“在所有满足minimum-stability的候选版本里，优先挑最稳定的那个” - 它必须和
minimum-stability同时存在才起作用；单独写它没意义 - 典型安全组合：
{ "minimum-stability": "beta", "prefer-stable": true }
比全局设 minimum-stability 更推荐的做法：单包加 @ 后缀
除非你在做原型验证或团队统一升级测试版，否则没必要把整个依赖树的稳定性水位拉低。对单个包加 @beta 或 @dev，精准可控，不影响其他依赖。
- 装 Laravel 最新 beta：
composer require laravel/framework:^11.0@beta - 临时试某个包的主干分支：
composer require phpunit/phpunit:dev-main@dev - 这种写法优先级高于
minimum-stability，哪怕全局是stable，也能拉取指定包的 dev 版本 - 不会触发其他依赖连带升级，
composer update vendor/package-name也能精准控制范围
