fix(webapp): backwards-compat for type-level scope on runs list + tighten team action authz

Two related findings reviewing the RBAC route migration.

1. api.v1.runs / realtime.v1.runs: type-level scope no longer granted unfiltered access
   Pre-RBAC the resource was a plain object (`{ tasks: searchParams[...] }`
   for api.v1.runs, the searchParams object itself for realtime.v1.runs)
   and the legacy `checkAuthorization` iterated `Object.keys`. So a JWT
   with type-level `read:tasks` (api.v1.runs) or `read:tags`
   (realtime.v1.runs) — no id — granted access to the unfiltered list.
   The new `anyResource([…])` model only matches resources we list,
   and the post-migration list dropped the type-level alternative when
   no filter was set, so those JWTs started 403'ing on unfiltered
   listings. Add `{ type: "tasks" }` and `{ type: "tags" }` (no id)
   alongside `{ type: "runs" }` so the legacy semantic is preserved
   verbatim — per-id `read:tasks:foo` / `read:tags:bar` still grants
   only when the filter contains the matching id.

2. team action: explicit per-intent authz gate
   The team route's action handler accepts three intents (set-role,
   purchase-seats, remove-member). set-role already gates on
   `manage:members`, but purchase-seats and remove-member relied on
   model-layer enforcement (SetSeatsAddOnService, removeTeamMember).
   The loader gates on `read:members` (broader audience than
   pre-RBAC's owner/admin-only loader), so any user reaching the page
   could submit those forms — banking on defense in depth at the
   model layer.

   Fix:
   - purchase-seats → require `manage:billing`
   - remove-member → require `manage:members`, with self-leave
     (target.userId === actor.userId) carved out as always allowed
   - removeTeamMember model fn previously only verified the actor was
     a member of the org — any org member could remove any other
     member by id. The new route gate closes that hole.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: matt-aitken

apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.team/route.tsx

@@ -151,9 +151,13 @@ export const action = dashboardAction(
       return orgId ? { organizationId: orgId } : {};
     },
     // No top-level authorization — different intents have different
-    // requirements (set-role needs manage:members; remove/leave is
-    // gated by the existing model layer; purchase-seats by the
-    // SetSeatsAddOnService). Per-intent ability checks happen inside.
+    // requirements. Each branch inside checks the right ability:
+    //   set-role        → manage:members
+    //   purchase-seats  → manage:billing
+    //   remove-member   → manage:members (skipped for self-leave)
+    // Don't rely on the model-layer (removeTeamMember /
+    // SetSeatsAddOnService) for enforcement — those are defense in
+    // depth; the route layer is where the ability gate belongs.
   },
   async ({ user, ability, request, params, context }) => {
     const userId = user.id;
@@ -187,6 +191,15 @@ export const action = dashboardAction(
     }
 
     if (formType === "purchase-seats") {
+      // Adjusting seat count is a billing operation. Pre-RBAC the team
+      // page's loader gated the entire route on Owner/Admin, so reaching
+      // this action implied authority. Post-RBAC the loader requires
+      // `read:members` (broader audience), so gate the seat purchase
+      // explicitly here against the right ability rather than relying
+      // on the SetSeatsAddOnService for enforcement at the model layer.
+      if (!ability.can("manage", { type: "billing" })) {
+        return json({ ok: false, error: "Unauthorized" } as const, { status: 403 });
+      }
       const org = await $replica.organization.findFirst({
         where: { slug: organizationSlug },
         select: { id: true },
@@ -231,6 +244,21 @@ export const action = dashboardAction(
       return json(submission);
     }
 
+    // Default intent: remove a member or leave the org. Self-leave (the
+    // actor removing their own membership) is always allowed. Removing
+    // another member requires `manage:members` — pre-RBAC the
+    // `removeTeamMember` model fn only verified the actor was a member
+    // of the target org, so any org member could remove any other
+    // member by id; this gate fixes that latent permissions hole.
+    const targetMember = await $replica.orgMember.findFirst({
+      where: { id: submission.value.memberId },
+      select: { userId: true },
+    });
+    const isSelfLeave = targetMember?.userId === userId;
+    if (!isSelfLeave && !ability.can("manage", { type: "members" })) {
+      return json({ ok: false, error: "Unauthorized" } as const, { status: 403 });
+    }
+
     try {
       const deletedMember = await removeTeamMember({
         userId,

apps/webapp/app/routes/api.v1.runs.ts

@@ -18,8 +18,19 @@ export const loader = createLoaderApiRoute(
       action: "read",
       resource: (_, __, searchParams) => {
         const taskFilter = searchParams["filter[taskIdentifier]"] ?? [];
+        // Pre-RBAC, the resource was `{ tasks: searchParams["filter[taskIdentifier]"] }`
+        // and the legacy `checkAuthorization` iterated `Object.keys` — so a
+        // JWT with type-level `read:tasks` (no id) granted access to the
+        // unfiltered runs list. The new ability model only matches against
+        // resources we list, so the type-level `{ type: "tasks" }` element
+        // (alongside `{ type: "runs" }` and the per-id task elements)
+        // preserves that semantic — `read:tasks` JWTs in the wild still
+        // list unfiltered runs without needing a separate `read:runs`
+        // scope. Per-id `read:tasks:foo` still grants only when the
+        // filter includes `foo`.
         return anyResource([
           { type: "runs" },
+          { type: "tasks" },
           ...taskFilter.map((id) => ({ type: "tasks", id })),
         ]);
       },

apps/webapp/app/routes/realtime.v1.runs.ts

@@ -25,8 +25,15 @@ export const loader = createLoaderApiRoute(
     authorization: {
       action: "read",
       resource: (_, __, searchParams) =>
+        // Pre-RBAC, the resource was the searchParams object itself and
+        // the legacy `checkAuthorization` iterated `Object.keys`, so a
+        // JWT with type-level `read:tags` (no id) granted access to the
+        // unfiltered runs stream. Including `{ type: "tags" }` here
+        // preserves that — per-id `read:tags:<tag>` still grants only
+        // when the filter includes that tag.
         anyResource([
           { type: "runs" },
+          { type: "tags" },
           ...(searchParams.tags ?? []).map((tag) => ({ type: "tags", id: tag })),
         ]),
     },