[alukach]

A disabled service account can still be granted a product, or have its grant raised from read_data to write_data, through inviteMember and updateMembership. That reaches it from the service-account page (setProductAccess) and from POST /accounts/{owner}/members and POST /products/{account}/{product}/members. Enabling the account again brings that access with it, although disabling is meant to freeze it, which is how adding a trust or issuing an API key already treats it.

serviceAccountGrantProblem, which every grant and role change already asks, now returns "That service account is disabled" for a disabled service account (a 400 from the API). Revoking access still works, so a disabled account can still be stripped down. People and organizations are unaffected.

Found reviewing #665, which documents the rule in its UpdateServiceAccount schema. This PR stands on its own, off main.

Docs, ADRs, llms.txt

• docs.source.coop docs/using-source/upload/with-service-account.md: I checked it, and it doesn't describe granting access to a disabled account, so it still holds.
• data.source.coop ADRs: I checked 005 (authorization). It covers what a grant permits, not when one may be made, so it still holds.
• public/llms.txt: no line covers this.

Storybook

No component changed. The service-account page shows the refusal through the action-state message it already renders.

Testing

• npm run type-check: clean.
• npx jest src/lib/accounts src/lib/operations src/lib/actions/service-accounts.test.ts src/lib/actions/memberships.test.ts: 119 tests pass, including a new test that a disabled service account is refused read_data and write_data and that other accounts aren't held to the rule.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
source-coop-ui	Ready	Preview	Oct 15, 2026 6:12am UTC
source-cooperative	Ready	Preview	Oct 15, 2026 6:12am UTC

[claude]

Claude finished @alukach's task in 14s —— View job

---

✅ No blocking issues — safe to merge.

The guard sits in serviceAccountGrantProblem (src/lib/accounts/service-accounts.ts:28). All three callers go through it: inviteMember (operations/memberships.ts:120), updateMembership (operations/memberships.ts:290) and setProductAccess (actions/service-accounts.ts:323). That is the right place for the check. In setProductAccess, access === "none" revokes before the check, so stripping a disabled account still works. Only service accounts are checked, and the new test covers that.

Non-blocking observations:

• updateMembership also refuses a downgrade (write_data to read_data) on a disabled account, because it asks the same function. The PR says revoking still works, and that holds, but it can't lower a grant either. Revoking is the same end state, so this is probably fine. It does mean an API client gets a 400 for a change that only reduces access.
• On that path the error is attached to the role field (operations/memberships.ts:291). For the disabled case the role isn't the problem. inviteMember already handles this by dropping the field when the role is allowed. A small inconsistency in field-level error display.

Docs

The description names the docs.source.coop page and ADR 005 it checked, and says why both still hold. It also covers llms.txt. Nothing further is needed.

---

💰 Estimated review cost: $0.10 · 0m13s · 5 turns