剂型改良与产品升级换代

要解决的问题

「剂型改良与产品升级换代」是一项受保护能力，调用前必须先通过平台授权校验。实际集成中最常见的坑不是业务流程本身，而是授权失败后被静默跳过：脚本重试、降级输出、拿过期凭证硬跑，最终产出一份未经平台校验的业务结果，排查时却发现日志里什么都没有。因此这个技能把「授权门禁」作为第一道也是唯一一道硬关卡。

技能如何工作

授权逻辑全部由 scripts/auth.py 承担，包括本地凭证缓存、WorkBuddy 用户绑定、平台授权校验和错误信号输出。不要在业务代码里手动解析 JWT、拼接 AppKey/AppSecret 或自行调用绑定接口。

关键步骤：

• 授权脚本优先读取包内 _meta.json 的 slug 作为服务端 skillCode（如 BT_8AF36D0D），只有包内缺少该文件时才手动传 --skill-code
• 先执行授权检查：输出 AUTH_OK 才能继续；若输出 AUTH_REQUIRED、AUTH_INVALID、CREDENTIALS_MISSING 或 CREDENTIALS_INVALID，则通过 WorkBuddy 的 connect_cloud_service 获取登录用户 JWT，交给授权脚本完成绑定
• 绑定成功输出 AUTH_BIND_OK 后，重新执行授权检查；仍未拿到 AUTH_OK 就停止，并按失败模板向用户报告
• 授权通过后必须调用 scripts/protected.py 拉取云端 protected instructions，拿到后才能按返回内容执行；未拿到就停止，不凭本地提示或历史上下文继续生成

失败处理与边界

• stdout 信号只有 5 种：AUTH_OK、AUTH_REQUIRED + CREDENTIALS_MISSING、AUTH_INVALID + CREDENTIALS_INVALID、AUTH_BIND_OK、AUTH_INVALID（仅 --bind-jwt 失败时）；业务错误细节走 stderr，必须同时观察两者
• 鉴权失败时立即停止业务推理，原样转述信号与 stderr 关键行，给出分步操作清单；禁止「失败但仍产出结果，末尾补一句鉴权有问题」
• 区分网络错误（network error、HTTP 401/403）与鉴权拒绝（authorization failed、签名），给出不同处理建议
• 重试上限为 1 次；两次失败视为服务端问题，告知数据服务不可用后停止
• 任何情况下不得向用户展示或在回复中拼接 AppKey/AppSecret 明文，密钥字段必须打码