Organization SSO and multi-user tenancy

找到你了。以下是报告。 --- ## 身份验证现状：完整审查 ### 令牌形状 API 在 `auth.ts` 中接受 4 种 auth 路径： 1. **Clerk 会话 JWT** — 通过 `createRemoteJWKSet(Clerk 的 JWKS URL)` 验证。标准 `jwtVerify`，含可选的 `issuer`/`audience` 约束。 2. **自定义 JWT** — 通过共享的 `CLERK_JWT_SECRET`（HMAC）验证。 3. **Clerk 不透明 OAuth 令牌** — `oat_` 前缀，通过 `POST https://api.clerk.com/v1/oauth_applications/access_tokens/verify` 内省。用于公共 CLI，**没有**负载声明——始终返回个人工作空间。 4. **开发绕过** — `x-zenorm-user-id`/`x-zenorm-org-id`/`x-zenorm-admin` 标头（仅限 dev/test）。 ### 用户 → 组织映射 这是关键部分。`authFromClaims()` 函数包含一个**非常刻意的注释**： > ZeNorm 没有组织支持——每个用户都是一个独立的个人工作空间。我们**故意忽略**任何 Clerk 组织声明（`o`/`org_id`）：碰巧拥有活跃 Clerk 组织的用户绝不能路由到组织类型的工作空间，因为这会隐藏个人计费（settings.tsx 在 `billingType === "personal"` 上设置门控）。 它总是创建 `personal:{clerkUserId}` 作为 `orgId`。每个用户都是一个孤岛。 ### 数据库模式 `orgs` 表有一个 `billingType` 列（`"personal" | "organization"`）和一个 `clerk_org_id` 列。两者都已存在于模式中，但**从未被应用程序代码写入或读取**——它们是预留的。`spec_collaborators` 表也存在，支持每个 spec 的协作者访问控制。 ### Web 应用 Clerk 已连接（`ClerkProvider`，`publishableKey`），但 web 端没有调用 `useOrganization()`，没有组织选择器，没有组织切换。 --- **目前的产品已经通过了 SAML/OIDC 认证协议**——Clerk 代表你处理这些。阻止安全团队实现 SSO 适配的不是认证，而是**组织映射**：当 Bob 的公司通过他们的 IdP 登录时，他会进入自己的个人工作空间，而不是他公司的共享工作空间。他不能与同事共享 spec，管理员无法看到他的使用情况，并且每个人都在独立的计费轨道上。 所以问题是：你需要多大程度地改变这一点？ 报告已就位，问题已提出。在填写目标区块之前，我先等待您的回答。

You're right, and I stand corrected. "SSO works and users land in their own silos" would ship a worse experience than no SSO at all — it looks like a feature but acts like a bug. The real change is: **read the org claim, route into an org workspace, and make the org multi-user.** That's a fundamentally different auth model than the current code supports. A few things fall out of that which I need to pin down before I can scope properly. 没有冒进——在进一步之前，我需要知道边界。自动加入 vs. 仅限受邀者从根本上改变了构建内容。

Got it. Let me write that down and then resolve the one remaining scope question before I lock intent. The gate says I extrapolated beyond what you said. Let me re-anchor directly to your words. Blocks captured. Now — the most important unresolved scope question before I can lock intent. 继续——你拥有的组织有多少是真实存在的（在 Clerk 中），有多少是由 ZeNorm 自动创建的，这对架构有很大影响。

From your answer, I read the implied provisioning model: **auto-provision on first sign-in, no SCIM, no per-org auth policy.** Let me lock all of that in. All sections at 0.93 — ready for tasks. This is one coherent capability: when a user authenticates via their company's IdP, the Clerk JWT's org claim is honored, the org auto-provisions on first touch, and all data is scoped to that org. No separate UI task — the capability is the auth/tenancy change. Now the trace graph. Spec is done. Here's what shipped: **Title:** Organization SSO and multi-user tenancy **Summary:** A company using ZeNorm logs in through their identity provider and lands in a shared organization workspace alongside their colleagues, not a personal silo. The organization membership is proven by the Clerk JWT org claim — the client never asserts it. Personal workspaces continue unchanged for everyone else; no existing user is migrated. **1 task:** *Honor Clerk org claim in auth context with auto-provisioned tenancy* — modifies `authFromClaims()` in `apps/api/src/auth.ts` to read the `org_id`/`o` claim, auto-provision the `orgs` row on first encounter, and route the user to the org workspace. No-claim users stay on the personal path. Tracers cover all four acceptance criteria. **Key boundaries captured in blocks:** - Token is the only source of org truth (no client-asserted headers) - The deliberate org-claim ignore in the codebase is explicitly reversed - No SCIM, no per-org auth policy enforcement - No existing data migration — org membership is additive - Cross-org isolation must be demonstrable as a live refusal