Composer代理本身不内置RBAC，权限控制必须由后端仓库（如Artifactory、Nexus）或前置网关实现；客户端仅发起HTTP请求，不校验角色或执行策略，auth.json仅为认证凭据而非权限载体，须严格设为600权限并配合代理侧完整日志溯源。
企业级 Composer 镜像代理本身不内置 RBAC 权限模型，所有权限控制必须落在代理服务层（如 Artifactory、Nexus、GitLab Package Registry）或前置网关上；直接依赖 composer config 或 auth.json 做“权限管理”是伪安全。
Composer 代理服务不自带 RBAC，权限必须由后端仓库兜底
Composer 客户端（包括 composer install、composer update）只负责解析 composer.json 中的 repositories 配置并发起 HTTP 请求，它不校验角色、不感知会话、不执行策略决策。所谓“RBAC 审计”，实际是指：你用的镜像代理服务是否支持基于角色的访问控制，并能否将请求上下文（用户身份、IP、时间、包名、操作类型）完整记录供溯源。
- Artifactory 支持细粒度的 Repository + Permission Target + User/Group 绑定，可配置
read/deploy/annotate等动作级权限 - Nexus 3 使用
Repository Privileges+Roles+Realms三元组实现 ABAC 混合模型，但默认不开启审计日志，需手动启用audit插件 - GitLab Package Registry 权限继承自项目访问级别（Guest/Reporter/Developer/Maintainer/Owner），无法单独控制
composer install和composer publish的差异权限 - 若自建 Nginx 反向代理 + static 文件服务，
auth.json中的 token 就是唯一凭证——此时 RBAC 退化为「token 白名单」，无审计能力
auth.json 不是权限载体，而是认证凭据泄露高危点
~/.composer/auth.json 存的是 HTTP Basic 或 Bearer Token，它解决的是“你是谁”，不是“你能做什么”。一旦该文件权限失控（如被设为 644），同服务器其他用户就能直接复用凭据，绕过所有 RBAC 策略拉取甚至推送私有包。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须执行
chmod 600 ~/.composer/auth.json，且确保父目录~/.composer/为700 - 避免在 CI/CD 流水线中用
echo '{"http-basic":{...}}' > auth.json—— 这类明文写入极易被进程列表或日志捕获 - 推荐使用环境变量注入凭据：
COMPOSER_AUTH='{"http-basic":{"myrepo.example.com":{"username":"u","password":"p"}}}' composer install - Artifactory/Nexus 支持 token scope 限制（如限定只读、限定路径前缀），比硬编码密码更可控
行为溯源依赖代理服务的完整请求日志，而非 Composer 自身
Composer 客户端不会记录“谁在什么时间安装了哪个版本的 payment-client”，它只打印终端输出。真正的行为链路必须从代理服务侧采集：
- Artifactory 日志路径：
$JFROG_HOME/var/log/request.log，含user、method、url、status、size、remote_addr - Nexus 3 需启用
audit功能（etc/nexus-default.properties中设nexus.security.audit.enabled=true），日志落于sonatype-work/nexus3/log/audit.log - 关键字段必须保留：请求头中的
Authorization（用于反查用户）、User-Agent（识别是composer/2.7还是curl/8.5）、完整 URL（含package-name和version） - 若使用 Kubernetes Ingress 做统一入口，需确保
X-Forwarded-For和X-Original-User正确透传，否则所有日志 IP 都是 Ingress Pod 地址
真正难的不是配置 RBAC 规则，而是让每一次 composer require myorg/logging-bundle 都能对应到具体人、具体 Git 提交、具体 Jenkins Job ID，并在审计报告里自动关联该包的 composer.lock 修改记录和上线时间——这需要代理日志、CI 日志、Git 日志三端时间对齐与字段映射，漏掉任意一环，溯源就断在中间。
