用途：端到端实现身份认证与授权，包括登录、授权判定、租户隔离、会话与受保护路由。前提是优先使用现有身份提供商，不在没有用户明确决定时引入或替换身份系统。
主要能力与流程：先探测框架/路由版本、认证包及版本、数据库/ORM、会话传输、用户与账号表、租户模型、中间件或代理、受保护资源以及已有迁移。区分认证与授权，为实际存在的公开、已登录、所有者、团队成员、管理员、服务/后台路径编写访问矩阵。判断是否需要本地用户镜像；如需要，在可能存在多种登录方式时把提供商身份与应用用户分开建模，绝不用未验证的客户端邮箱关联账号。仅在存在实质性选择时才询问：提供商选择、账号关联策略、删除行为、组织/租户模型、是否回填既有用户。
技术参考：检测到确切技术栈和安装版本后，才使用匹配的提供商参考：Clerk 用于当前 Next.js 的 Clerk 保护与已验证用户同步；Auth.js 用于当前 Auth.js/NextAuth 处理器、适配器、会话与路由保护；Supabase Auth 用于公开资料同步与 Supabase 会话处理。Firebase、Auth0、自定义 JWT 或未覆盖的提供商/数据库组合，应保留现有代码并查阅提供商文档，不要套用不兼容示例。
授权与同步：在每个受保护的读取/变更旁强制执行访问控制；中间件/代理只能提供粗粒度路由，不是唯一授权边界。Supabase Data API 需按实际令牌策略实现 RLS 与授权，在所有权可能变化处同时加 using 和 with check；服务凭据仅限服务端，凭据已绕过 RLS 时不创建冗余 service-role 策略。同步需幂等且可验证：优先使用签名的提供商 webhook 做生命周期同步，或在服务端拉取权威数据做即时同步，处理创建、更新、删除、重放、乱序投递与回填。
验证与输出：测试新注册、回访登录、登出、过期/刷新、账号切换、已验证关联、提供商更新/删除、重放同步。对每个受保护资源，以未认证、其他用户、其他租户、非管理员做负向测试，并单独测试允许的所有者/管理员/服务场景。在目标运行时执行迁移及仓库的 lint/type/test/build 命令。最终报告提供商/版本与身份模型、改动的文件与迁移、访问矩阵与执行点、同步策略、RLS/授权、环境变量名、自动化验证证据及手动仪表盘/回填/生产检查。
限制：资料未提供具体代码示例、价格、支持平台或效果保证。