@oxy.so/contracts 4.16.0 → 4.21.0

package/dist/cjs/accountAccess.js

@@ -0,0 +1,72 @@
+"use strict";
+/**
+ * Wire contract for `GET /internal/accounts/:accountId/access/:userId`: Oxy
+ * answers a trusted first-party service's question "may this person act FOR
+ * that account, and with what?" with no session of that person in the request.
+ *
+ * It exists for the account Oxy never lets anybody act AS: a `channel`
+ * ({@link isDelegatedActAsEligibleKind} refuses it). An app publishes to a
+ * channel with ITS OWN credential, on behalf of a member Oxy vouches for here,
+ * so nobody holds a bearer that speaks as the channel. A long-running import
+ * (Oxy Move) has only a service token and `X-Oxy-User-Id`, which the
+ * user-facing `GET /accounts/:id/members` refuses; this is its answer.
+ *
+ * Needs a service token whose application is platform-trusted AND holds the
+ * privileged {@link ACCOUNTS_MEMBERSHIP_READ_SCOPE}. The answer is always 200:
+ * `access` is `null` for no active membership, an archived account, an unknown
+ * account and an unclaimed directory account alike. Callers must treat every
+ * other status as a refusal (fail closed), and must not cache the answer longer
+ * than the action it authorizes.
+ *
+ * Platform-agnostic — zod only.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.accountAccessVerdictSchema = exports.accountAccessGrantSchema = exports.accountAccessSourceSchema = exports.ACCOUNT_ACCESS_SOURCES = exports.ACCOUNTS_MEMBERSHIP_READ_SCOPE = void 0;
+const zod_1 = require("zod");
+const accountGraph_1 = require("./accountGraph");
+/**
+ * The scope the endpoint requires.
+ *
+ * Privileged (staff-granted). Channel membership is sensitive because a channel
+ * is anonymous: its members are the people behind a voice that is published
+ * without their names, and "is this person a member of that channel" is
+ * exactly the fact the channel exists to withhold.
+ */
+exports.ACCOUNTS_MEMBERSHIP_READ_SCOPE = 'accounts:membership:read';
+/**
+ * Where the access comes from.
+ *
+ * - `self` — the person IS the account (a personal account asked about itself).
+ * - `direct` — an active membership row on the account.
+ * - `inherited` — an active, cascading membership on an ancestor account.
+ */
+exports.ACCOUNT_ACCESS_SOURCES = ['self', 'direct', 'inherited'];
+exports.accountAccessSourceSchema = zod_1.z.enum(exports.ACCOUNT_ACCESS_SOURCES);
+/**
+ * One person's EFFECTIVE access over one account.
+ *
+ * `role` and `permissions` are strings rather than closed enums on purpose: the
+ * role and permission vocabularies are the API's, they grow, and a consumer
+ * pinned to an older contracts release must keep reading new ones. Gate on
+ * `permissions` (the role's baseline adjusted by per-member grants and
+ * revokes), never on `role`.
+ */
+exports.accountAccessGrantSchema = zod_1.z.object({
+    role: zod_1.z.string().min(1),
+    permissions: zod_1.z.array(zod_1.z.string().min(1)),
+    /** Only an active membership grants access, so this is the one value. */
+    status: zod_1.z.literal('active'),
+    source: exports.accountAccessSourceSchema,
+});
+exports.accountAccessVerdictSchema = zod_1.z
+    .object({
+    accountId: zod_1.z.string().min(1),
+    /** `null` when no such account exists. */
+    kind: accountGraph_1.accountKindSchema.nullable(),
+    /** `null` means: this person may not act for this account. */
+    access: exports.accountAccessGrantSchema.nullable(),
+})
+    .refine((verdict) => verdict.access === null || verdict.kind !== null, {
+    message: 'An account that does not exist grants no access',
+    path: ['access'],
+});

package/dist/cjs/accountEmail.js

@@ -1,6 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.EMAIL_VERIFICATION_ERROR_CODES = exports.emailVerificationConfirmResponseSchema = exports.emailVerificationConfirmRequestSchema = exports.emailVerificationStartResponseSchema = exports.emailVerificationStartRequestSchema = exports.emailTicketSchema = exports.emailAddressSchema = exports.EMAIL_TICKET_TTL_MS = exports.EMAIL_CODE_MAX_ATTEMPTS = exports.EMAIL_CODE_TTL_MS = exports.EMAIL_CODE_LENGTH = exports.EMAIL_VERIFICATION_PURPOSES = void 0;
+exports.emailVerificationConfirmResponseSchema = exports.emailVerificationConfirmRequestSchema = exports.emailVerificationStartResponseSchema = exports.emailVerificationStartRequestSchema = exports.emailTicketSchema = exports.emailAddressSchema = exports.EMAIL_VERIFICATION_ERROR_CODES = exports.EMAIL_TICKET_TTL_MS = exports.EMAIL_CODE_MAX_ATTEMPTS = exports.EMAIL_CODE_TTL_MS = exports.EMAIL_CODE_LENGTH = exports.EMAIL_VERIFICATION_PURPOSES = void 0;
 /**
  * Email codes and tickets (ADR 0030).
  *
@@ -16,22 +16,16 @@ exports.EMAIL_VERIFICATION_ERROR_CODES = exports.emailVerificationConfirmRespons
  * (`reauth`) use the same code, through their own routes (`signIn.ts`).
  */
 const zod_1 = require("zod");
-/**
- * - `signup`: above.
- * - `signin`: the code (and link) of an email sign-in (`POST /auth/signin/email/start`).
- * - `reauth`: a signed-in person proving it is them before a sensitive step
- *   (`POST /users/me/reauth/email`): a password, an authenticator, deleting the
- *   account, linking Commons.
- */
-exports.EMAIL_VERIFICATION_PURPOSES = ['signup', 'signin', 'reauth'];
-/** Digits in a code. */
-exports.EMAIL_CODE_LENGTH = 6;
-/** How long a code can be confirmed. */
-exports.EMAIL_CODE_TTL_MS = 10 * 60 * 1000;
-/** Wrong codes before a verification is spent and a new code is needed. */
-exports.EMAIL_CODE_MAX_ATTEMPTS = 5;
-/** How long a confirmed code's ticket can be spent. */
-exports.EMAIL_TICKET_TTL_MS = 15 * 60 * 1000;
+// The Zod-free half of this contract lives in `./client/` (`@oxy.so/contracts/client`);
+// it is re-exported here so the root entry is unchanged.
+const accountEmail_1 = require("./client/accountEmail");
+var accountEmail_2 = require("./client/accountEmail");
+Object.defineProperty(exports, "EMAIL_VERIFICATION_PURPOSES", { enumerable: true, get: function () { return accountEmail_2.EMAIL_VERIFICATION_PURPOSES; } });
+Object.defineProperty(exports, "EMAIL_CODE_LENGTH", { enumerable: true, get: function () { return accountEmail_2.EMAIL_CODE_LENGTH; } });
+Object.defineProperty(exports, "EMAIL_CODE_TTL_MS", { enumerable: true, get: function () { return accountEmail_2.EMAIL_CODE_TTL_MS; } });
+Object.defineProperty(exports, "EMAIL_CODE_MAX_ATTEMPTS", { enumerable: true, get: function () { return accountEmail_2.EMAIL_CODE_MAX_ATTEMPTS; } });
+Object.defineProperty(exports, "EMAIL_TICKET_TTL_MS", { enumerable: true, get: function () { return accountEmail_2.EMAIL_TICKET_TTL_MS; } });
+Object.defineProperty(exports, "EMAIL_VERIFICATION_ERROR_CODES", { enumerable: true, get: function () { return accountEmail_2.EMAIL_VERIFICATION_ERROR_CODES; } });
 /** An email address as the API stores it: trimmed and lowercase. */
 exports.emailAddressSchema = zod_1.z.string().trim().toLowerCase().min(3).max(254).email();
 /** An opaque one-use ticket (32 random bytes, base64url). */
@@ -54,26 +48,10 @@ exports.emailVerificationConfirmRequestSchema = zod_1.z
     code: zod_1.z
         .string()
         .trim()
-        .regex(new RegExp(`^\\d{${exports.EMAIL_CODE_LENGTH}}$`), `code must be ${exports.EMAIL_CODE_LENGTH} digits`),
+        .regex(new RegExp(`^\\d{${accountEmail_1.EMAIL_CODE_LENGTH}}$`), `code must be ${accountEmail_1.EMAIL_CODE_LENGTH} digits`),
 })
     .strict();
 exports.emailVerificationConfirmResponseSchema = zod_1.z.object({
     ticket: exports.emailTicketSchema,
     expiresAt: zod_1.z.number().int().positive(),
 });
-/**
- * Stable error codes (`error.code` in the API error body). Clients map these
- * through their localization, never the English message.
- */
-exports.EMAIL_VERIFICATION_ERROR_CODES = {
-    /** The code is wrong, or its verification expired or was spent. */
-    codeInvalid: 'EMAIL_CODE_INVALID',
-    /** Too many wrong codes: request a new one. */
-    tooManyAttempts: 'EMAIL_CODE_TOO_MANY_ATTEMPTS',
-    /** The ticket is unknown, expired, spent, or for another email or purpose. */
-    ticketInvalid: 'EMAIL_TICKET_INVALID',
-    /** A sign-up without a confirmed email. */
-    ticketRequired: 'EMAIL_TICKET_REQUIRED',
-    /** This server cannot send mail. */
-    unavailable: 'EMAIL_UNAVAILABLE',
-};

package/dist/cjs/accountGraph.js

@@ -8,250 +8,30 @@
  * {@link ACCOUNT_CATEGORY_IDS} for the four rules that govern it.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.createAccountRequestSchema = exports.accountNameSchema = exports.ACCOUNT_CATEGORY_KINDS = exports.accountCategoriesSchema = exports.MAX_ACCOUNT_CATEGORIES = exports.SELECTABLE_ACCOUNT_CATEGORY_IDS = exports.RETIRED_ACCOUNT_CATEGORY_IDS = exports.accountCategoryIdSchema = exports.ACCOUNT_CATEGORY_IDS = exports.childAccountKindSchema = exports.CHILD_ACCOUNT_KINDS = exports.accountKindSchema = exports.ACCOUNT_KINDS = void 0;
-exports.isDelegatedActAsEligibleKind = isDelegatedActAsEligibleKind;
-exports.isOperatorSwitchTargetKind = isOperatorSwitchTargetKind;
-exports.isAccountKind = isAccountKind;
-exports.isSelectableAccountCategoryId = isSelectableAccountCategoryId;
-exports.newlyAddedRetiredCategories = newlyAddedRetiredCategories;
-exports.kindAcceptsAccountCategories = kindAcceptsAccountCategories;
+exports.createAccountRequestSchema = exports.accountNameSchema = exports.accountCategoriesSchema = exports.accountCategoryIdSchema = exports.childAccountKindSchema = exports.accountKindSchema = exports.kindAcceptsAccountCategories = exports.ACCOUNT_CATEGORY_KINDS = exports.MAX_ACCOUNT_CATEGORIES = exports.newlyAddedRetiredCategories = exports.SELECTABLE_ACCOUNT_CATEGORY_IDS = exports.isSelectableAccountCategoryId = exports.RETIRED_ACCOUNT_CATEGORY_IDS = exports.ACCOUNT_CATEGORY_IDS = exports.isAccountKind = exports.isOperatorSwitchTargetKind = exports.isDelegatedActAsEligibleKind = exports.CHILD_ACCOUNT_KINDS = exports.ACCOUNT_KINDS = void 0;
 const zod_1 = require("zod");
 const avatarCharacter_1 = require("./avatarCharacter");
 const organizations_1 = require("./organizations");
 const username_1 = require("./username");
-/**
- * The union is spelled out above and the array proves coverage BOTH ways
- * (`satisfies` here, the `Gap` alias below) — the same shape this package's
- * `ACCOUNT_CATEGORY_IDS` / `TRUST_TIERS` pairs use, and the one
- * `db/schema/users.ts` mirrors to keep the `users_kind_check` CHECK honest.
- *
- * Deriving the union from the array instead would cost nothing here and be paid
- * by consumers: `kind` travels into `@oxy.so/services` on every device-directory
- * context (`deviceContextSchema.kind` → `DeviceContext` → the switcher rows),
- * and an indexed-access type is materially more expensive to check there than a
- * literal union.
- */
-exports.ACCOUNT_KINDS = [
-    'personal',
-    'organization',
-    'project',
-    'bot',
-    'channel',
-];
-exports.accountKindSchema = zod_1.z.enum(exports.ACCOUNT_KINDS);
-exports.CHILD_ACCOUNT_KINDS = [
-    'organization',
-    'project',
-    'bot',
-    'channel',
-];
-exports.childAccountKindSchema = zod_1.z.enum(exports.CHILD_ACCOUNT_KINDS);
-/**
- * Whether an account of this kind may be the SUBJECT OF A DELEGATION — an
- * application acting as it on some person's authority. `POST /internal/accounts/
- * :id/service-switch` and the OAuth delegated subject both gate on this.
- *
- * It is NOT the question an account switcher asks. See
- * {@link isOperatorSwitchTargetKind}, and the note below on why the difference
- * is `bot`.
- *
- * Two kinds are refused, for opposite reasons:
- *
- *  - `personal` is a human login, so assuming it would be impersonation.
- *  - `channel` is a CONTENT identity, not an operating one. A channel exists so
- *    that posts can be authored BY it; it is never a seat anybody occupies. Its
- *    operators act on it through their own membership, and an application
- *    publishes to it with its own credential. Refusing act-as is what makes
- *    "no login, ever" structural rather than incidental: no session can be
- *    minted whose subject is a channel, so no bearer exists that could add an
- *    auth method to one (every auth-method write resolves its target from the
- *    authenticated subject, never from a parameter).
- *
- * Consumers must gate on this predicate rather than testing `kind === 'personal'`,
- * which silently admits every kind added after it was written.
- *
- * Being act-as-eligible is NOT being without an identity of one's own. A bot is
- * act-as-eligible AND its own actor (`accountKindActorNature` → `'agent'` in
- * `accountSubject.ts`): an application acting as it on a person's authority
- * records that person as the actor, and the bot acting with nobody operating it
- * records the bot. Neither ever records the bot's owner in the bot's place.
- */
-function isDelegatedActAsEligibleKind(kind) {
-    return kind === 'organization' || kind === 'project' || kind === 'bot';
-}
-/**
- * Whether a PERSON may switch into an account of this kind — become it, in an
- * account switcher, for the rest of their session.
- *
- * ## Why this is not the same question as {@link isDelegatedActAsEligibleKind}
- *
- * The two differ on exactly one kind, `bot`, and that difference is the whole
- * reason both exist.
- *
- * **A bot is not something you become. It is somebody of its own.** It is an
- * agent's identity, with its own resources, roles, plan and balance, and it is
- * the actor of what it does unoperated. A person may still act AS it on their
- * own authority — that is delegation, recorded with the person as actor, and it
- * is what {@link isDelegatedActAsEligibleKind} admits it for. What a person
- * never does is occupy its seat. This is a refusal of a SEAT, not a capability
- * restriction: nothing a bot may do depends on this predicate.
- *
- * Handing a person the bot's seat instead inverts that. It puts a human inside
- * the identity that exists to act without one, and it does so on the human's own
- * device, next to their personal login — which is precisely what happened: a
- * `bot` account held a live session on a person's device, offered to them by a
- * switcher that had asked the delegation question by mistake.
- *
- * `channel` is refused here as well, for the reason set out above, and
- * `personal` because assuming somebody else's login is impersonation.
- *
- * ## This is the narrower predicate, deliberately
- *
- * Everything a person may become, a service may also act as; the reverse does
- * not hold. A caller that is unsure which question it is asking wants THIS one:
- * being wrong here withholds an affordance, while being wrong the other way
- * hands out a seat.
- */
-function isOperatorSwitchTargetKind(kind) {
-    return kind === 'organization' || kind === 'project';
-}
-/**
- * Narrow an unknown value to an {@link AccountKind}.
- *
- * The user-DTO serializers read from structurally-permissive `unknown` sources
- * (a Drizzle row, a raw document, an already-formatted object), so each one
- * would otherwise hand-roll this check and they would drift on what counts.
- */
-function isAccountKind(value) {
-    return typeof value === 'string' && exports.ACCOUNT_KINDS.includes(value);
-}
-// ===========================================================================
-// Account categories
-//
-// Four rules govern this taxonomy. Each one is here because the obvious
-// alternative fails silently rather than loudly.
-//
-// 1. AN ID IS AN OPAQUE, IMMUTABLE SLUG — the LABEL is not stored anywhere.
-//    Every value below is an identifier that no rename may ever change. The
-//    human-readable label lives in each client's own translation catalogue,
-//    keyed by the id. Re-labelling `agency` from "Real estate agency" to
-//    "Agency" is therefore a one-line locale edit that touches no row; moving
-//    the label into the column or the DTO would make the same edit a data
-//    migration, and would pin every reader to the language of whoever chose it.
-//
-// 2. THE PRIMARY CATEGORY IS THE FIRST ELEMENT of an ordered list. Not a
-//    separate flag, and not a second field: a flag admits two primaries and
-//    admits none, and ordering makes both unrepresentable. The cost is that
-//    ORDER IS DATA — anything that re-serializes, sorts or de-duplicates this
-//    list can change which category is primary without erroring, so no layer
-//    between the column and the client may reorder it.
-//
-// 3. THE VOCABULARY IS APPEND-ONLY. `ACCOUNT_CATEGORY_IDS` may gain ids and may
-//    never lose one, because rows already carry the ids it holds. Withdrawing a
-//    category means listing it in {@link RETIRED_ACCOUNT_CATEGORY_IDS}, which
-//    removes it from the picker while leaving it readable and re-writable. The
-//    database enforces the same asymmetry: its CHECK is re-evaluated on EVERY
-//    update to a row, so narrowing the allowed set makes an unrelated write —
-//    saving a bio — fail on any account that had picked the withdrawn value.
-//    Measured on a real Postgres, `NOT VALID` included; it does not help.
-//
-// 4. THE SET IS CLOSED. An id nobody can validate is an id no client can render:
-//    the label comes from a translation key derived from the id, so an invented
-//    value paints as a blank or a raw slug in every app at once. Closing it also
-//    costs nothing that rule 3 does not already charge — adding a category needs
-//    a migration to widen the CHECK whether or not the enum exists, so an open
-//    list would buy back no work, only the validation.
-// ===========================================================================
-/**
- * Every account category, by stable id.
- *
- * Grouped by comment for readability only; the storage, the wire and the picker
- * all treat this as one flat list. `other` is the escape hatch for an account
- * that fits nothing here.
- *
- * TO ADD ONE: append an id (lowercase ASCII, `snake_case`) here, publish
- * `@oxy.so/contracts`, then ship a migration that widens
- * `users_account_categories_check` — never edit an existing migration — and add
- * an `accounts.accountCategory.<id>` label to each client's locales.
- *
- * TO WITHDRAW ONE: leave the id here and add it to
- * {@link RETIRED_ACCOUNT_CATEGORY_IDS}. See rule 3 above.
- */
-exports.ACCOUNT_CATEGORY_IDS = [
-    // ---- media & public information -----------------------------------------
-    'news',
-    'politics',
-    // ---- business & economy --------------------------------------------------
-    'business',
-    'startup',
-    'finance',
-    'crypto',
-    'marketplace',
-    'retail',
-    // The four ids the single-valued `organizationCategory` field used to hold,
-    // carried forward VERBATIM. Their labels may be rewritten freely; their ids
-    // may not, because live rows hold them.
-    'real_estate',
-    'agency',
-    'landlord',
-    'cooperative',
-    'architecture',
-    // ---- technology ----------------------------------------------------------
-    'technology',
-    'software',
-    'ai',
-    'security',
-    'automation',
-    // ---- knowledge -----------------------------------------------------------
-    'science',
-    'education',
-    'books',
-    // ---- health --------------------------------------------------------------
-    'health',
-    'fitness',
-    // ---- sport & play --------------------------------------------------------
-    'sports',
-    'gaming',
-    // ---- culture & entertainment ---------------------------------------------
-    //
-    // There is deliberately NO generic `entertainment` here, and re-adding one is
-    // a regression rather than a gap. It is the only id this list ever carried
-    // that was dominated by its own specifics — `film`, `music`, `gaming` and
-    // `comedy` all exist — and a generic drawer sitting beside its four
-    // concretions collects the lazy pick, which degrades the data for all four at
-    // once: the accounts that would have said `film` say `entertainment` instead,
-    // and `film` stops meaning what it meant.
-    //
-    // The other overlaps in this vocabulary are NOT the same case and must not be
-    // merged on this reasoning: `sports`/`fitness`, `art`/`photography`,
-    // `business`/`startup`, `finance`/`crypto`, `home_garden`/`diy` and
-    // `technology`/`software`/`security` are genuinely different audiences, and
-    // with a cap of four the granularity is cheap.
-    'music',
-    'film',
-    'podcast',
-    'art',
-    'photography',
-    'comedy',
-    // ---- everyday life -------------------------------------------------------
-    'food',
-    'travel',
-    'fashion',
-    'home_garden',
-    'diy',
-    'automotive',
-    'animals',
-    'family',
-    // ---- society -------------------------------------------------------------
-    'nonprofit',
-    'government',
-    'community',
-    'activism',
-    'environment',
-    'religion',
-    // ---- fallback ------------------------------------------------------------
-    'other',
-];
+// The Zod-free half of this contract lives in `./client/` (`@oxy.so/contracts/client`);
+// it is re-exported here so the root entry is unchanged.
+const accountGraph_1 = require("./client/accountGraph");
+var accountGraph_2 = require("./client/accountGraph");
+Object.defineProperty(exports, "ACCOUNT_KINDS", { enumerable: true, get: function () { return accountGraph_2.ACCOUNT_KINDS; } });
+Object.defineProperty(exports, "CHILD_ACCOUNT_KINDS", { enumerable: true, get: function () { return accountGraph_2.CHILD_ACCOUNT_KINDS; } });
+Object.defineProperty(exports, "isDelegatedActAsEligibleKind", { enumerable: true, get: function () { return accountGraph_2.isDelegatedActAsEligibleKind; } });
+Object.defineProperty(exports, "isOperatorSwitchTargetKind", { enumerable: true, get: function () { return accountGraph_2.isOperatorSwitchTargetKind; } });
+Object.defineProperty(exports, "isAccountKind", { enumerable: true, get: function () { return accountGraph_2.isAccountKind; } });
+Object.defineProperty(exports, "ACCOUNT_CATEGORY_IDS", { enumerable: true, get: function () { return accountGraph_2.ACCOUNT_CATEGORY_IDS; } });
+Object.defineProperty(exports, "RETIRED_ACCOUNT_CATEGORY_IDS", { enumerable: true, get: function () { return accountGraph_2.RETIRED_ACCOUNT_CATEGORY_IDS; } });
+Object.defineProperty(exports, "isSelectableAccountCategoryId", { enumerable: true, get: function () { return accountGraph_2.isSelectableAccountCategoryId; } });
+Object.defineProperty(exports, "SELECTABLE_ACCOUNT_CATEGORY_IDS", { enumerable: true, get: function () { return accountGraph_2.SELECTABLE_ACCOUNT_CATEGORY_IDS; } });
+Object.defineProperty(exports, "newlyAddedRetiredCategories", { enumerable: true, get: function () { return accountGraph_2.newlyAddedRetiredCategories; } });
+Object.defineProperty(exports, "MAX_ACCOUNT_CATEGORIES", { enumerable: true, get: function () { return accountGraph_2.MAX_ACCOUNT_CATEGORIES; } });
+Object.defineProperty(exports, "ACCOUNT_CATEGORY_KINDS", { enumerable: true, get: function () { return accountGraph_2.ACCOUNT_CATEGORY_KINDS; } });
+Object.defineProperty(exports, "kindAcceptsAccountCategories", { enumerable: true, get: function () { return accountGraph_2.kindAcceptsAccountCategories; } });
+exports.accountKindSchema = zod_1.z.enum(accountGraph_1.ACCOUNT_KINDS);
+exports.childAccountKindSchema = zod_1.z.enum(accountGraph_1.CHILD_ACCOUNT_KINDS);
 /**
  * Accepts EVERY id, withdrawn ones included — see rule 3.
  *
@@ -260,60 +40,7 @@ exports.ACCOUNT_CATEGORY_IDS = [
  * picked one could no longer save its bio either. That is the same failure the
  * nullable `bio` / `avatar` fix addressed, wearing a different hat.
  */
-exports.accountCategoryIdSchema = zod_1.z.enum(exports.ACCOUNT_CATEGORY_IDS);
-/**
- * Ids withdrawn from the picker. Empty today.
- *
- * A withdrawn id keeps working everywhere it is already stored: it validates,
- * it survives a round-trip save, it still renders from its label key, and it
- * stays PRIMARY if it was primary. Nothing rewrites a stored list — a read-time
- * or migration-time demotion would silently replace a choice its owner made,
- * which is precisely what stable ids exist to prevent. The owner drops it on
- * their next edit; until then it is honoured.
- *
- * What withdrawal changes is only this: the id leaves
- * {@link SELECTABLE_ACCOUNT_CATEGORY_IDS}, so no picker offers it, and
- * {@link newlyAddedRetiredCategories} refuses to let a write ADD it to an
- * account that did not already have it.
- */
-exports.RETIRED_ACCOUNT_CATEGORY_IDS = [];
-/** Whether a category may still be OFFERED. A stored one is readable either way. */
-function isSelectableAccountCategoryId(id) {
-    return !exports.RETIRED_ACCOUNT_CATEGORY_IDS.includes(id);
-}
-/** The ids a picker may offer, in declaration order. */
-exports.SELECTABLE_ACCOUNT_CATEGORY_IDS = exports.ACCOUNT_CATEGORY_IDS.filter(isSelectableAccountCategoryId);
-/**
- * Which of `next` are withdrawn ids the account did not already carry — i.e.
- * the ones a write must be refused for.
- *
- * `retired` is a parameter rather than a module read so the rule can be
- * exercised against a non-empty set while the production one is empty; a test
- * over `RETIRED_ACCOUNT_CATEGORY_IDS` alone would pass vacuously today and stay
- * passing if the rule were deleted.
- */
-function newlyAddedRetiredCategories(next, previous, retired) {
-    return next.filter((id) => retired.includes(id) && !previous.includes(id));
-}
-/**
- * How many categories one account may carry.
- *
- * Four, not "as many as you like". Three reasons, in the order they bind:
- *
- *  - The primary has to MEAN something. At ten categories the first element
- *    reads as a sort artifact rather than a choice, and rule 2 above is the
- *    entire mechanism by which a primary exists.
- *  - The profile RENDERS them as a row of chips; four labels of this length is
- *    what fits a phone-width profile header before the row wraps or truncates.
- *  - Four is enough to place a genuinely compound account without a tag cloud:
- *    a housing cooperative that is also a non-profit serving a local community
- *    spends `cooperative`, `nonprofit`, `community`, `real_estate` — and is the
- *    most compound real example in the ecosystem.
- *
- * One constant, read by the wire schema, the database CHECK and the picker, so
- * changing it is one edit plus a migration.
- */
-exports.MAX_ACCOUNT_CATEGORIES = 4;
+exports.accountCategoryIdSchema = zod_1.z.enum(accountGraph_1.ACCOUNT_CATEGORY_IDS);
 /**
  * An account's categories on the wire. ORDER IS MEANINGFUL — index 0 is the
  * primary (rule 2).
@@ -326,7 +53,7 @@ exports.MAX_ACCOUNT_CATEGORIES = 4;
  */
 exports.accountCategoriesSchema = zod_1.z
     .array(exports.accountCategoryIdSchema)
-    .max(exports.MAX_ACCOUNT_CATEGORIES)
+    .max(accountGraph_1.MAX_ACCOUNT_CATEGORIES)
     .superRefine((ids, ctx) => {
     const seen = new Set();
     ids.forEach((id, index) => {
@@ -340,31 +67,6 @@ exports.accountCategoriesSchema = zod_1.z
         seen.add(id);
     });
 });
-/**
- * Kinds that may carry categories: every kind EXCEPT `personal`.
- *
- * A person has interests, not a sector — and their interests are not a
- * classification anybody else gets to read off their profile. Spelled out
- * positively, like {@link isDelegatedActAsEligibleKind} and for the same reason: a `kind
- * !== 'personal'` test silently admits every kind invented after it was
- * written, whereas this list forces whoever adds one to decide.
- */
-exports.ACCOUNT_CATEGORY_KINDS = [
-    'organization',
-    'project',
-    'bot',
-    'channel',
-];
-/**
- * Whether an account of this kind may carry categories.
- *
- * The API refuses the write and the `users_account_categories_kind_check`
- * constraint makes it unrepresentable; both derive from
- * {@link ACCOUNT_CATEGORY_KINDS}, so they cannot disagree.
- */
-function kindAcceptsAccountCategories(kind) {
-    return exports.ACCOUNT_CATEGORY_KINDS.includes(kind ?? '');
-}
 /**
  * An account's name on the create/update wire.
  *