메뉴
授权（authZ）约束——默认拒绝/fail-close；后端必校、前端权限仅 UX；集中决策禁散落 `if role==`；两级检查 = 角色/权限 + 资源 ownership。触发：设计/实现权限校验、角色或权限模型、资源 ownership、多租户隔离、管理员鉴权。跳过：身份认证（→auth-constraints）、纯公开资源、与权限无关的业务逻辑。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | authz-constraints |
| description | 授权（authZ）约束——默认拒绝/fail-close；后端必校、前端权限仅 UX；集中决策禁散落 `if role==`；两级检查 = 角色/权限 + 资源 ownership。触发：设计/实现权限校验、角色或权限模型、资源 ownership、多租户隔离、管理员鉴权。跳过：身份认证（→auth-constraints）、纯公开资源、与权限无关的业务逻辑。 |
适用于：后端服务的权限校验、角色/权限模型、资源归属、多租户隔离等授权相关的设计、实现、文档与 review。接在 auth-constraints（认证 authN）之后——authN 确认「你是谁」，本约束判定「你能不能做这件事」。原则技术栈无关，示例用 Go + SQL。
定位：技术框架定型，钉死「机制骨架」（【硬】必守），不绑「业务策略」（【软】给能力、由项目按业务选）。
TRIGGER：设计/实现权限校验、角色或权限模型、资源 ownership、多租户隔离、管理员/后台鉴权；文档 / PRD / 设计 / review 涉及"谁能访问什么"。
SKIP：身份认证与会话（属 auth-constraints）、纯公开资源（无访问控制）、与权限无关的业务逻辑。
user_id 等），禁采信前端请求体里自称的 role / is_admin / user_id——这些一律视为不可信输入。if user.Role == "admin"、if user.ID == owner。observability 的"级别映射单点维护"。// ✅ 集中判定
if err := authz.Enforce(ctx, sub, "order:delete", order); err != nil {
return err // 统一返回 403 错误码
}
// ❌ 业务代码散落角色判断，规则漂移、漏点难查
if sub.Role != "admin" && sub.ID != order.OwnerID { ... }
授权必须同时覆盖两个粒度，缺一不可：
| 粒度 | 校验内容 | 位置 | 漏掉的后果 |
|---|---|---|---|
| 粗粒度 | 角色/权限：有没有「删除订单」这个能力 | 入口中间件 / 拦截器 | 越权调用受限接口 |
| 细粒度 | 资源 ownership：这一单是不是你的 / 在你租户内 | service / 数据层（中间件拿不到具体资源） | 横向越权（IDOR）——有权限但操作了别人的数据 |
核心提醒：中间件只能拦"有没有这类权限"，拦不住"操作了不属于你的那一个"。ownership 必须在取到资源后、在业务/数据层显式校验。
仅当系统是多租户（SaaS）时适用，但一旦适用即为硬约束：
tenant_id 从会话身份带入，所有数据访问强制带租户过滤。WHERE tenant_id = ?，禁靠每个 handler 记得手写 if 兜底（漏一个就跨租户泄露）——同 database-constraints 软删除"所有查询带 deleted = 0"的思路。-- 任何业务查询都必须带租户与软删除双过滤
SELECT * FROM orders WHERE tenant_id = ? AND deleted = 0 AND id = ?;
401（属 authN）；已认证但无权 → 403。错误码并入 api-design 的 A-BBB-CCCC，禁另起体系。xxx 权限"等内部规则；对敏感资源可用 404 替代 403（假装不存在）以防存在性枚举——403/404 的取舍是【软】，由项目按资源敏感度定。observability-constraints。subject / action / resource / decision / reason；授权拒绝用 WARN（业务非阻断），不污染 ERROR 告警。框架不钉死，由各项目按业务定：
tenant_id / 独立 schema / 独立库）。if role== / if id==ownertenant_id 强制过滤下沉数据层默认作用域，非逐 handler 手写api-design 的 A-BBB-CCCC；敏感资源已决定 403/404 策略observability本地 ultrareview——多代理、对抗验证、只读的 PR 级 review；默认 base=main；并发 5 个 finder（质量/安全/简洁/鲁棒性/文档同步），每条 🔴/🟡 发现交 3 个独立怀疑视角对抗验证、多数决去留；可选追加本次 review 重点，注入每个 finder 优先关注（不替代其他维度）。触发：/review、给当前分支做深度审查、PR 前 ultrareview。跳过：不在 git 仓库、当前分支=base。
产出修订（诊断→定向修正→回归验证）——对 spec→plan→exec 偏差做根因归类：spec-defect / impl-defect / requirement-change；先诊断再修正、改代码必先 Red 测试、最小影响只改必须改的层；已完成 plan 是历史审计快照禁止回改；启动先 worktree 感知定位修复现场（主仓库停在 main 时自动定位到进行中的 worktree）。触发：/revise、有 bug、结果不对、和预期不符、产出需要优化、review 发现违规需修复。跳过：纯新增需求（→/spec→/plan）、还没有 spec/plan/代码可对照。
本地 ultrareview——跨模型、多代理、对抗验证、只读的 PR 级 review（依赖 Workflow 工具，Claude Code ≥2.1.154）；默认 base=main；并发 6 个 finder（质量/安全/简洁/鲁棒性/文档同步/Codex 跨模型），每条 🔴/🟡 发现交 3 个独立怀疑视角对抗验证、多数决去留；可选追加本次 review 重点，注入每个 finder 优先关注（不替代其他维度）。触发：/review、给当前分支做深度审查、PR 前 ultrareview。跳过：无 Workflow 工具、不在 git 仓库、当前分支=base。
产出修订（诊断→定向修正→回归验证）——对 spec→plan→exec 偏差做根因归类：spec-defect / impl-defect / requirement-change；先诊断再修正、改代码必先 Red 测试、最小影响只改必须改的层；已完成 plan 是历史审计快照禁止回改；启动先 worktree 感知定位修复现场（主仓库停在 main 时自动定位到进行中的 worktree）。触发：/revise、有 bug、结果不对、和预期不符、产出需要优化、review 发现违规需修复。跳过：纯新增需求（→/spec→/plan）、还没有 spec/plan/代码可对照。
Git 开发流程纪律——禁 main 直接提交；新任务前扫工作区根，有 workspace 标记走多 repo 工作区，否则 `question` 工具 询问 worktree（默认）或切分支；worktree 一律落 `~/.bb-spec/worktrees/` 下、禁嵌套当前 repo / 禁放 sibling 目录；本地 commit 不立即 push、整功能验证完才推；合并后清理本地+远程。触发：开始改代码、提到开分支、要求 commit/push/开 PR、PR 合并后清理。跳过：纯咨询/阅读、极小打字纠错。
前端技术栈强制约束——默认 Vue 3 + TS + Vite + Tailwind；bun 是默认包管理器（新项目强制），既有项目跟随 lockfile 不迁移。触发：新建前端项目；编辑 package.json/vite.config/tailwind.config/.vue/.ts/.tsx；用户提到前端/vue/vite/tailwind。跳过：纯后端/CLI/工具项目；用户明确说用 React/Nuxt/Svelte 等。