App 本地权限设计

业务 App 的成员、角色和权限属于业务 App，不上传到 IWish Auth。统一身份并不等于统一业务授权：Auth 只证明“这个人是谁、属于哪个组织、员工是否有效、可以进入哪个 App”，业务 App 决定“他在本 App 能做什么、能看哪些数据”。

1. 建议数据模型

app_members(id, iwish_auth_user_id, status, created_at)
app_roles(id, key, name, status)
app_permissions(id, key, name)
app_role_permissions(role_id, permission_id)
app_member_roles(member_id, role_id)
app_authorization_audit(actor_member_id, action, target_id, before, after, created_at)

iwish_auth_user_id 必须唯一并直接来自 App Session 的 session.user.id。不要在每次请求中按邮箱猜测身份，也不要保存飞书 token、Supabase token 或员工密码。

2. 权限命名

本地 permission 建议使用稳定业务动作，例如 contact.read、contact.write、report.export、settings.manage。不要把客户 ID、部门 ID、用户 ID、环境名或 UI 组件写进 key。数据范围应通过独立规则表达，例如 owner、team、assigned_client、all，而不是创建成千上万个带客户名的角色。

3. 服务端顺序

requireAppAccess
-> 根据 iwish_auth_user_id 查 active 本地成员
-> 计算本地角色与 permission
-> 校验资源归属、客户范围和字段规则
-> 执行业务动作

任何一步缺失都默认拒绝。前端菜单、按钮或路由守卫只能改善体验，不能替代服务端授权。高风险操作如导出、配置、成员管理和删除应使用独立 permission，并写入本地审计日志。

4. 客户项目上下文

clientAssignments 可用于默认客户筛选或确认员工参与某项目，但它不是 permission。即使存在 assignment，用户没有本地角色或本地权限时仍返回 403；即使本地角色足够，assignment 为空时也不能自动扩大到全部客户。每个 App 应明确自己的组合规则并增加测试。

5. 生命周期

本地角色变化由 App 自己立即生效并清理缓存。Auth 用户停用、飞书离职、组织或 App 停用会使统一 session 失效，即使本地角色仍存在也不能访问。角色 key 的语义不得静默改变；拆分或合并权限时先新增、迁移、双读验证，再删除旧值，并保留审计与回滚证据。