[alukach]

Follows #674. Items 3 and on from the follow-ups discussed on #667: /accounts/{account_id} becomes the one endpoint for an account. DELETE only deletes, and the /profile and /flags sub-routes fold into its GET and PATCH. #665 needs to rebase onto it (see below).

What

Endpoint	Before	Now
GET /accounts/{account_id}	the whole record to whoever may read it; 401/403 to everyone else	the whole record to whoever may read it, its PublicAccount view to everyone else, signed in or not
GET /accounts/{account_id}/profile	the public profile	removed; GET /accounts/{account_id} answers it
GET /accounts/{account_id}/flags	the account's flags	removed; they're in the record GET /accounts/{account_id} answers, to the same readers
PUT /accounts/{account_id}/flags	replaces the flags (admin)	removed; PATCH /accounts/{account_id} takes flags (admin)
DELETE /accounts/{account_id}, service account	disabled it	deletes it, through deleteAccount
DELETE /accounts/{account_id}, person or organization	disabled it	409 to a caller who may disable it, saying to PATCH { "disabled": true }; a person or an organization is never deleted

GET answers two shapes

getAccount absorbs getAccountProfile: GetAccount gets the Account record, else GetAccountProfile gets a PublicAccount, else a disabled or service account is a 404 and anything else is refused. The reference documents the 200 as anyOf the two, and the route declares optionalBearer, since it answers anonymous callers. Who sees a 404 is unchanged from the profile route.

PublicAccount is the record without its private fields: account_id, type, name, disabled and metadata_public, plus a computed profile_image. It replaces the flattened AccountProfileResponse, which had no account_id, so it couldn't serve as the account embedded in a product or a list.

Products embed the same view. shown() already cut a product's account down for a caller who may not read it, but cast the result to Account, so the reference promised flags, created_at and updated_at that weren't sent. ProductResponseSchema now carries the Product name in the reference and declares account as Account | PublicAccount. The Product type the app reads from the database is unchanged.

flags on PATCH

flags is one more field on UpdateAccount, and takes PutAccountFlags the way disabled takes DisableAccount: a caller may hold any of the three permissions alone, and is refused only for the fields they send. A service account still can't hold admin (400, naming flags). Only the flags are written, so a concurrent profile edit survives. The account-flags form's updateAccountFlags server action keeps its name and calls updateAccount. API.md already said one resource is edited through one endpoint, which the flags route contradicted. Its methods table now cites PUT /data-connections/{id} as the PUT example in place of /flags.

Deleting a service account

deleteAccount:

1. disables the account first, writing only disabled, so no key exchanges and nothing new can be granted, issued or trusted while it's torn down (granting, issuing a key and adding a trust each already refuse a disabled service account);
2. deletes every membership and every key row it held, in parallel;
3. deletes the account row, whose trusts go with it.

Keys are deleted rather than revoked, so a service account that later takes the same ID starts with no keys, instead of listing its predecessor's. As a backstop, the key exchange refuses a key whose created_at is earlier than its account's. That ties a key to the account it was issued to, so a key the cleanup misses (a race, GSI lag, a delete path that skips deleteAccount) can't sign in as a re-created account with the same ID. A key minted with an account at creation is never older than it: the account's timestamp is taken first.

Known gap: disabling first only stops requests that read the account after the disable. A grant or trust from a request that read it just before can still land after the cleanup lists memberships, and survive the delete. A service account re-created with the same ID would then inherit it. Keys have the "older than its account" backstop, but memberships and trusts have none yet. Closing that needs conditional writes or the same check on memberships and trusts, which is a follow-up.

Authorization comes before anything an unauthorized caller shouldn't learn: a service account the caller can't manage is a 404, as GET answers, and the 409 pointing at PATCH goes only to a caller who may disable that person or organization.

The service-account settings page's deleteServiceAccount action goes through the same operation, so deleting from the UI cleans up keys too; on main it left them live. On a refusal it shows its own message rather than the API's.

#665

#665 makes the same DELETE change through its own deleteServiceAccount operation, but still disables any other account. Rebased onto this, it can drop that operation and its DELETE route, and keep the rest of its service-account and trust endpoints.

Nothing calls these yet

No caller in the app's API clients, the CLI, the data proxy or the other repos in the org (code search for /profile and /flags). The account-flags form uses its server action, not the route. No production traffic in the last day for DELETE /accounts/{account_id}.

UI

The settings page's delete button and the account-flags form call the same server actions as before, which now adapt deleteAccount and updateAccount; their stories stub the actions, so they are unchanged.

One visual change: a signed-out reader of /products gets each product's account as a PublicAccount, which has no emails, so the hover card couldn't find an individual's Gravatar. The public view carries the profile_image worked out before the emails were dropped, avatarUrl uses it, and the account links, hover card and avatar accept Account | PublicAccount. New story: AccountLinks › Public View. No screenshot: headless Chromium didn't get past Storybook's loader locally.

Docs, ADRs and llms.txt

• public/llms.txt's public-profile line now points at /api/v1/accounts/{account_id}, which answers anonymously.
• API.md's methods table cites PUT /data-connections/{id} instead of the removed /flags route.
• API.md's rule for published summary and description text now says how to write it: lead with a verb, don't drop words, one rule per sentence, name who gets what actively, 25 words or fewer a sentence, and address the caller as "you". These are ASD-STE100's writing rules without its controlled vocabulary, which would read stiffly in developer docs and which nothing here could enforce. The GET, PATCH and DELETE descriptions on /accounts/{account_id} are rewritten to it. Descriptions on other routes keep the older style until someone touches them.
• Checked docs.source.coop: using-source/upload/with-service-account.md names only the key-revocation endpoint and says a service account can be deleted without saying what goes with it, so it still holds. No page names the profile or flags endpoints.
• Checked the data-proxy ADRs: 013 records that a revoked key stops new exchanges within the proxy's cache TTL. A deleted key, or one older than its account, answers inactive the same way, so 013 and 014 still hold.

Testing

At b06dbf94: npm run type-check passes, and the full npx jest passes (94 suites, 1,017 tests).

• operations/accounts.test.ts: getAccount answering the record or a PublicAccount without emails, flags or private metadata, and 404 for a hidden service or disabled account; flags on updateAccount (takes PutAccountFlags, no admin for a service account, writes only the flags, rejects an unknown flag); deleteAccount disabling first and deleting memberships and keys, the 409 only to a caller who may disable, the 404 to whoever may not manage a service account.
• exchanges/route.test.ts: a key older than its account answers inactive.
• actions/service-accounts.test.ts: the action redirects on success and shows its own message on refusal; setProductAccess grants nothing to a disabled service account but still revokes its grant.

🤖 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 16, 2026 4:36am UTC
source-cooperative	Ready	Preview	Oct 16, 2026 4:36am UTC

[claude]

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

---

✅ No blocking issues — safe to merge.

I read the operations, exchange route, action and key-table changes. I did not run the type-check or jest. The PR says they haven't been run since the rebase, so CI is the check.

Non-blocking notes:

• src/lib/operations/accounts.ts (deleteAccount): the cleanup is not atomic. If it fails after the disable and before accountsTable.delete, the account is left disabled with some memberships or keys gone. Retrying DELETE finishes it, because a disabled service account is still found by managedServiceAccount. That recovery path is worth a test.
• src/lib/actions/service-accounts.ts (deleteServiceAccount): every !result.ok shows "You do not manage that service account". Failures from deleteAccount other than a refusal, such as a DynamoDB error, are not handled in the action. The previous action behaved the same way, so this isn't a regression.
• src/app/api/v1/service-account-keys/exchanges/route.ts: Date.parse returns NaN for a malformed or missing created_at, and NaN < x is false. A key with a bad timestamp therefore passes the age check and fails open. That is probably fine for records this app writes, but say so if it is deliberate.
• The known gap you describe (a grant or trust that lands after the membership listing survives the delete) is real and is correctly flagged as a follow-up.

Simplify (ponytail)

• src/lib/operations/accounts.ts (publicView): this is exported, but the diff shows no importer outside the file. Drop export unless another module uses it.

Docs

The description names the docs.source.coop page and the data-proxy ADRs it checked, and llms.txt is updated in this PR. Nothing is missing.

---

💰 Estimated review cost: $0.15 · 0m19s · 6 turns