必须用 artifact 类型仓库，zip 文件名、内部 composer.json 的 name/version、require 声明三者字面完全一致，url 指向 zip 目录（不加斜杠），路径推荐绝对路径，目录需真实存在且 php 有读权限，文件名格式为 vendor/package-version.zip，解压后 composer.json 必须在根目录，version 必须是语义化版本，require 时需精确匹配且先 update 才能识别新 zip。
不能直接 composer require ./xxx.zip，必须用 artifact 类型仓库，且 ZIP 文件名、内部 composer.json 的 name/version、require 声明三者字面完全一致，否则静默跳过——不是报错，是根本找不到。
artifact 仓库的 url 必须指向 ZIP 所在目录，不是 ZIP 文件本身
写成 "url": "./packages/mylib-1.2.0.zip" 或 "url": "file:///path/to/pkg.zip" 都会触发 Invalid repository type "artifact"。正确做法是把所有 ZIP 平铺放进一个目录（如 ./packages），然后配置：
{
"repositories": [
{
"type": "artifact",
"url": "./packages"
}
]
}
注意：url 值结尾**不能加斜杠**（./packages/ 在某些 Composer 版本下会被忽略）；路径推荐用绝对路径（如 /opt/myproject/artifacts），避免 CI 或不同用户执行时因相对路径失效；该目录必须真实存在，且 PHP 进程有读权限（Linux 下注意 www-data 或 php-fpm 用户能否访问）。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
ZIP 包命名和内部结构必须严格合规
Artifact 仓库不解析 ZIP 内容，而是靠文件名反向推导包信息。常见错误现象：Could not find package acme/utils，其实 ZIP 就在目录里，只是结构不对。
- 文件名必须为
{vendor}/{package}-{version}.zip格式，例如acme/utils-1.2.0.zip（注意斜杠，不是短横） - 解压后必须**直接看到
composer.json**，不能是acme-utils-1.2.0/composer.json—— 多一层目录就失败 -
composer.json中的name（如"acme/utils"）和version（如"1.2.0"）必须与文件名中出现的字符串**字面完全一致** -
version必须是语义化版本号，不支持dev-main、dev-develop等别名
require 时版本号必须精确匹配，且需先 update 才能识别新 ZIP
composer install 只按 composer.lock 安装，不会重新扫描 ./packages 目录；只有 composer update acme/utils 或 composer update 才会刷新可用版本列表。
- 执行
composer require acme/utils:1.2.0—— ✅ 正确，版本号与 ZIP 文件名一致 - 执行
composer require acme/utils:^1.2—— ❌ 失败，artifact 不做版本约束解析 - 新增了
acme/utils-1.2.1.zip，但没运行update—— ❌install仍装旧版，lock 文件不会自动更新 dist URL - 离线环境首次生成
composer.lock必须在配置好 artifact 仓库后执行composer update，否则 lock 里仍记录 Packagist 的 URL
为什么不用 package 类型仓库？
虽然 package 类型允许手动声明单个 ZIP 的 dist.url（支持 file:// 协议），但它要求你显式补全 autoload、type、require 等全部元信息，且 ZIP 修改后必须手动删 vendor 和 composer.lock 并重跑 update。而 artifact 是为批量托管预打包场景设计的，只要 ZIP 合规，Composer 会自动读取其内部 composer.json，省去重复维护元数据的麻烦——前提是，你得把命名、路径、权限、版本这四件事一次做对。
