用途
该技能面向 Backstage 插件开发，解决两类权限需求：前端需要根据权限隐藏按钮、菜单或页面；后端路由处理器需要在执行操作前对调用者进行授权。此外还覆盖为插件定义新权限，以及按资源粒度检查权限（例如“能否更新这个组件”，而非“能否更新组件”这一泛化判断）。
主要能力
声明权限
在 *-common 库中使用 createPermission({ name, attributes }) 为插件定义新权限。权限对象只声明一次、两处使用：前端（usePermission）与后端（permissions.authorize）导入同一份定义，不应在两个地方重复声明。
前端模式
- 根据权限条件渲染 UI：使用 usePermission({ permission }) 钩子。
- 将整个子树包裹在权限门控中：使用 <RequirePermission permission={...}>...</RequirePermission>。
后端模式
- 授权基本操作权限：coreServices.permissions.authorize([{ permission }], { credentials })。
- 按资源授权（含条件决策）：permissions.authorizeConditional([{ permission, resourceRef }], { credentials }) 配合 permissionsRegistry.addResourceType(...)。当决策可能依赖资源（如“所有者可更新”）时，优先使用 authorizeConditional 而非 authorize，它返回条件决策，可翻译为数据库层过滤，避免把所有候选资源加载进内存。
两种调用模式
- 独立模式（开发中途）：用户正在编辑已有插件，根据所添加内容选择对应参考——定义权限、门控 UI 或后端授权。
- 脚手架后模式（由 creating-backstage-plugin 调用）：当意图描述“只有管理员可以……”“当前用户必须拥有……权限”或任何访问控制语言时，将相关模式加入刚生成的插件。
使用方式与注意事项
- 宿主应用必须启用权限框架：采用方需在 app-config.yaml 中设置 permission.enabled: true 并安装 PermissionPolicy。若未启用权限，authorize 始终返回 AuthorizeResult.ALLOW——插件代码本身正确，只是未被强制执行。应在插件 README 中记录该前置条件。
- permissions.authorize 返回的数组与请求顺序一致。对单个权限，可解构 const [decision] = await permissions.authorize(...)，且判断条件是 decision.result === AuthorizeResult.ALLOW，而不是布尔值。
- usePermission 是异步的，返回 { allowed, loading, error }；加载期间应渲染 <Skeleton />，否则用户会看到权限判定过程中的 UI 闪烁。
- 后端插件的 coreServices.permissions 与 coreServices.permissionsRegistry 来自 @backstage/backend-plugin-api，它们是插件作用域的——插件获得的 PermissionsService 已知道自身的 pluginId。
适用场景
适用于 Backstage 插件开发中需要访问控制的场景：前端按权限隐藏或显示界面元素，后端在路由处理器或定时任务中授权操作，定义插件级新权限，以及需要按资源做细粒度授权判断的场合。
限制
资料未提供该技能的具体安装命令、依赖版本、支持的 Backstage 版本范围、收费或价格信息，也未提供完整代码示例与参考文档正文，这些内容暂未提供。