资源分配优先级排序

它解决什么问题

当多个项目或任务争抢同一批人力、算力、预算时，资源该先给谁、后给谁，往往靠会议讨论和 Excel 手工排序。判断标准分散在各团队，优先级结论难以追溯，规则更新后也没有统一入口同步。

资源分配优先级排序 属于受保护能力，所有工作流都必须先完成授权校验，再从云端拉取 protected instructions，才能按返回内容执行排序，而不是依赖本地提示或历史上下文猜测。

核心能力与工作流程

授权逻辑全部由 scripts/auth.py 处理，包含本地凭证缓存、WorkBuddy 用户绑定、平台授权校验和错误信号输出。关键步骤如下：

• 先执行授权检查，脚本读取包内 _meta.json 的 slug 作为服务端 skillCode，形如 BT_E01E5EB4，而不是展示名称。
• stdout 输出 AUTH_OK 表示授权通过，可以继续执行本 Skill。
• 输出 AUTH_REQUIRED + CREDENTIALS_MISSING 或 AUTH_INVALID + CREDENTIALS_INVALID 时，调用 WorkBuddy 的 connect_cloud_service 工具获取登录用户 JWT，再执行 auth.py --bind-jwt 完成绑定。
• 绑定成功后输出 AUTH_BIND_OK，需要重新执行授权检查拿到 AUTH_OK。
• 授权通过后运行 scripts/protected.py，只有成功返回 protected instructions，才严格按照返回内容继续，否则停止业务输出。

适用边界与注意点

• 鉴权失败必须停下：遇到非成功信号时，立即停止业务推理，按报告模板转述 stdout 信号与 stderr 关键行，不做静默重试，也不用“系统繁忙”这类模糊提示替代。
• 重试上限为 1 次：凭证缺失或失效时重新走一次绑定流程；两次失败说明是服务端问题，告知用户数据服务暂时不可用。
• 密钥不可见：AppKey / AppSecret 由脚本内部处理，不要明文拼接到业务命令、环境变量或回复中。
• 云端指令优先：本地 SKILL.md 只说明入口流程，不能替代 protected instructions，未拿到云端内容时不得继续生成。