主要竞争对手识别与分类

要解决的问题

在调用受保护的技能时，最常见的工程事故是「鉴权失败，但业务流程照常跑完」。不少自动化流程在遇到凭证失效、远程校验拒绝或网络异常时，会选择静默重试或降级处理，最终产出一份看似正常、实则未经授权的结果。这对数据分析类技能尤其危险，因为错误结论会直接流入下游决策。

本技能把鉴权当作一道硬门禁：授权未通过时，业务推理与结果输出被完全禁止，二者互斥。

工作原理

核心逻辑集中在 scripts/auth.py，遵循一套明确的信号协议：

• 执行 auth.py --ensure 做授权检查，包内 _meta.json 的 slug 会被优先读取，作为服务端 skillCode；
• 输出 AUTH_OK 才代表通过，之后必须调用 scripts/protected.py 拉取云端 protected instructions，严格按照返回内容执行；
• 输出 AUTH_REQUIRED + CREDENTIALS_MISSING 或 AUTH_INVALID + CREDENTIALS_INVALID 时，需通过 WorkBuddy 的 connect_cloud_service 获取用户 JWT，再执行 auth.py --bind-jwt 完成绑定；
• 绑定成功输出 AUTH_BIND_OK，此时必须重新执行一次 --ensure，确认 AUTH_OK 后才能继续业务。

关键工程约束

• 失败即停：出现任何非成功信号时，禁止静默重试、静默降级或继续业务推理，必须立即按模板向用户输出中文报告，原样转述 stdout 信号与 stderr 关键行；
• 重试上限为 1：仅在 CREDENTIALS_MISSING、CREDENTIALS_INVALID、HTTP 401/403、authorization failed 等明确失效场景下，允许重走一次绑定流程，第二次失败说明是服务端问题，应停止；
• stderr 必须同时观察：业务错误细节只出现在 stderr，需要与 stdout 信号联合判断，例如区分网络错误与鉴权拒绝；
• 密钥不外显：AppKey / AppSecret 不得拼接到业务命令、环境变量或回复中，报告中相关字段必须打码；
• 不手工造轮子：不要手动解析 JWT、拼接凭证或调用绑定接口，这些统一由 auth.py 处理。