“could not find package”主因是repositories未置于composer.json根级、type未设为"path"、url非相对路径，或本地包name/version不匹配；需三要素齐备且验证配置生效。
为什么composer require报“Could not find package”，但包明明在本地？
不是 Composer 没扫描，而是它压根没去你放包的目录里找——repositories没配、配错位置、或类型写成了"package"或"vcs"。Composer 不会自动发现./packages/xxx这种路径，必须显式声明为path类型仓库，且只认项目根目录composer.json里的配置。
repositories必须怎么写才生效？
三要素缺一不可：写对位置、选对类型、用对路径。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
repositories字段必须是项目根目录composer.json的**顶层数组**，不能嵌套在require、config或其他字段下 -
type必须严格为"path"（不是"package"、"vcs"或"git"） -
url必须是相对于composer.json的**相对路径**，例如"./packages/my-utils"；file://前缀、绝对路径（如/home/user/xxx）、Windows盘符路径（如C:/xxx）均会静默失效 - 整个配置必须是 JSON 数组格式：
[{ "type": "path", "url": "./packages/my-utils" }]，哪怕只有一个源也不能省略方括号
本地包的composer.json要满足什么条件？
即使repositories写对了，如果本地包自身不合规，Composer 也会跳过它，不报错也不提示。
-
name字段必须和你在composer require时输入的**完全一致**（大小写敏感），比如mycompany/utils不能写成MyCompany/utils - 必须有
version字段，或项目composer.json中已设"minimum-stability": "dev"，否则dev-main这类分支名会被稳定性策略直接过滤 -
composer.json语法必须合法（可用json_decode(file_get_contents('composer.json'), true)简单验证），空文件、注释、BOM头都会导致解析失败 - 若依赖自动加载，需确保
autoload段正确，例如"psr-4": {"MyCompany\Utils\": "src/"}，之后还得运行composer dump-autoload
常见静默失败场景和验证方法
Composer 对配置错误往往不报错，只安静 fallback 到 packagist.org，结果当然还是“not found”。用这几招快速定位：
- 执行
composer config repositories，确认输出里确实包含你配的path项；如果没出现，说明配置不在有效位置或格式非法 - 执行
composer show --all | grep your-package-name，若无输出，基本可判定仓库未被识别 - 临时删掉
repositories数组，再运行composer require，如果错误不变，说明你根本没配上——别信“我肯定改过了” - 把本地包目录挪到
./packages/my-utils后，手动进该目录运行composer validate，看是否提示composer.json错误
path仓库本身不难，真正容易卡住的是路径相对性、name拼写一致性、以及version与minimum-stability的隐式耦合——这三处出错，Composer 都不会告诉你哪里错了，只会说“包不存在”。
