@oxyhq/contracts 0.22.0 → 0.24.0

package/dist/esm/accountGraph.js

@@ -1,16 +1,16 @@
 /**
- * Account graph wire contracts — the account-kind vocabulary, organization
- * taxonomy, and create-account input.
+ * Account graph wire contracts — the account-kind vocabulary, the account
+ * category taxonomy, and the create-account input.
  *
- * `organizationCategory` classifies `kind: 'organization'` accounts (agency,
- * cooperative, landlord, …) without polluting `User.kind`. Meaningful only when
- * `kind === 'organization'`.
+ * `accountCategories` classifies a NON-PERSONAL account — what it is about, what
+ * it does — without polluting `User.kind`. See the block above
+ * {@link ACCOUNT_CATEGORY_IDS} for the four rules that govern it.
  */
 import { z } from 'zod';
 /**
  * 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
- * `ORGANIZATION_CATEGORIES` / `TRUST_TIERS` pairs use, and the one
+ * `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
@@ -66,13 +66,246 @@ export function isActAsEligibleKind(kind) {
 export function isAccountKind(value) {
     return typeof value === 'string' && ACCOUNT_KINDS.includes(value);
 }
-export const ORGANIZATION_CATEGORIES = [
+// ===========================================================================
+// 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
+ * `@oxyhq/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.
+ */
+export const 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',
-    'cooperative',
     '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',
 ];
-export const organizationCategorySchema = z.enum(ORGANIZATION_CATEGORIES);
+/**
+ * Accepts EVERY id, withdrawn ones included — see rule 3.
+ *
+ * A schema that rejected a withdrawn id would 400 the whole request whenever a
+ * client round-trips the categories it was served, so an account that had
+ * picked one could no longer save its bio either. That is the same failure the
+ * nullable `bio` / `avatar` fix addressed, wearing a different hat.
+ */
+export const accountCategoryIdSchema = z.enum(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.
+ */
+export const RETIRED_ACCOUNT_CATEGORY_IDS = [];
+/** Whether a category may still be OFFERED. A stored one is readable either way. */
+export function isSelectableAccountCategoryId(id) {
+    return !RETIRED_ACCOUNT_CATEGORY_IDS.includes(id);
+}
+/** The ids a picker may offer, in declaration order. */
+export const SELECTABLE_ACCOUNT_CATEGORY_IDS = 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.
+ */
+export 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.
+ */
+export const MAX_ACCOUNT_CATEGORIES = 4;
+/**
+ * An account's categories on the wire. ORDER IS MEANINGFUL — index 0 is the
+ * primary (rule 2).
+ *
+ * A duplicate is REJECTED rather than silently collapsed. De-duplicating would
+ * rewrite the caller's list, and any rewrite of this list can move which id sits
+ * at index 0 — so the one repair available here is the one that would break the
+ * property the list exists to carry. A duplicate only ever comes from a client
+ * bug, and a 400 naming the index is how that bug gets found.
+ */
+export const accountCategoriesSchema = z
+    .array(accountCategoryIdSchema)
+    .max(MAX_ACCOUNT_CATEGORIES)
+    .superRefine((ids, ctx) => {
+    const seen = new Set();
+    ids.forEach((id, index) => {
+        if (seen.has(id)) {
+            ctx.addIssue({
+                code: z.ZodIssueCode.custom,
+                message: `Duplicate account category "${id}"`,
+                path: [index],
+            });
+        }
+        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 isActAsEligibleKind} 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.
+ */
+export const 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.
+ */
+export function kindAcceptsAccountCategories(kind) {
+    return ACCOUNT_CATEGORY_KINDS.includes(kind ?? '');
+}
 /**
  * An account's name on the create/update wire.
  *
@@ -96,10 +329,16 @@ const accountNameSchema = z
     .optional();
 /**
  * POST /accounts — create a non-personal account under the caller's tree.
- * `organizationCategory` is accepted only when `kind` is `organization`.
+ *
+ * No cross-field refinement guards `accountCategories`, and that is not an
+ * omission: `kind` here is a CHILD kind, and every child kind is in
+ * {@link ACCOUNT_CATEGORY_KINDS}, so `personal` is already unrepresentable on
+ * this route. The refinement the single-valued predecessor needed disappeared
+ * along with the restriction that made it necessary. A child kind that does NOT
+ * accept categories would break that reasoning silently, so
+ * `__tests__/accountGraph.test.ts` asserts the two lists agree.
  */
-export const createAccountRequestSchema = z
-    .object({
+export const createAccountRequestSchema = z.object({
     parentAccountId: z.string().trim().min(1).optional(),
     kind: childAccountKindSchema,
     username: z.string().trim().min(1).max(100),
@@ -107,14 +346,6 @@ export const createAccountRequestSchema = z
     bio: z.string().trim().max(500).optional(),
     avatar: z.string().optional(),
     description: z.string().trim().max(1000).optional(),
-    organizationCategory: organizationCategorySchema.optional(),
-})
-    .superRefine((data, ctx) => {
-    if (data.organizationCategory !== undefined && data.kind !== 'organization') {
-        ctx.addIssue({
-            code: z.ZodIssueCode.custom,
-            message: 'organizationCategory applies only when kind is organization',
-            path: ['organizationCategory'],
-        });
-    }
+    /** Ordered, PRIMARY FIRST — see rule 2 above {@link ACCOUNT_CATEGORY_IDS}. */
+    accountCategories: accountCategoriesSchema.optional(),
 });

package/dist/esm/deviceSession.js

@@ -45,10 +45,11 @@ export const deviceTokenMintRequestSchema = z.object({
 });
 /**
  * Wire shape of a successful `POST /session/device/token`: the freshly-minted
- * short access token for the active account, its expiry, the NEXT rotating
- * device secret the client must persist (rotation-in-use — the presented secret
- * stays valid for a short grace so multi-tab races don't lock out), and the
- * projected device-session state.
+ * short access token for the active account, its expiry, the device secret the
+ * client must persist (`nextDeviceSecret` — on mint this echoes the presented
+ * secret unchanged so concurrent refreshes from multiple origins do not race),
+ * and the projected device-session state. Sign-in rotates the secret via
+ * `issueDeviceSecret`; mint does not.
  */
 export const deviceTokenMintResponseSchema = z.object({
     accessToken: z.string(),

package/dist/esm/followGraph.js

@@ -0,0 +1,27 @@
+/**
+ * The follow graph wire contract (`/v2/follows`).
+ *
+ * These types are the boundary between the API that owns the graph and every
+ * application that reads it. They live here — not in the API and not in the
+ * SDK — because both ends have to agree, and a shape defined on one side is a
+ * shape the other side re-declares slightly differently within a release or two.
+ *
+ * ## Why the state is three fields and not a boolean
+ *
+ * A user can follow something globally and turn it off in ONE application. That
+ * is a state the user themselves created, so the client has to be able to see
+ * it and say so — "following, but not shown here" is a sentence a boolean
+ * cannot express. `globalState`, `applicationMode` and `effectiveState` are
+ * therefore reported separately, and only the last one answers "does this
+ * appear in my feed right now".
+ *
+ * ## Why kinds are strings
+ *
+ * `FollowTargetKind` is a plain `string`, not a union. Applications register
+ * their own kinds at runtime (`mercaria.store`, `syra.artist`), so a union here
+ * would mean every new application in the ecosystem needs a release of this
+ * package before it can follow anything. The namespace rule is enforced by the
+ * database, which is the one place that can enforce it for applications this
+ * package has never heard of.
+ */
+export {};

package/dist/esm/index.js

@@ -9,7 +9,7 @@
  * Platform-agnostic — zod is the only runtime dependency. No react/react-native/
  * expo, no `require()` in the ESM build.
  */
-export { ACCOUNT_KINDS, accountKindSchema, CHILD_ACCOUNT_KINDS, childAccountKindSchema, isAccountKind, isActAsEligibleKind, ORGANIZATION_CATEGORIES, organizationCategorySchema, createAccountRequestSchema, } from './accountGraph.js';
+export { ACCOUNT_KINDS, accountKindSchema, CHILD_ACCOUNT_KINDS, childAccountKindSchema, isAccountKind, isActAsEligibleKind, ACCOUNT_CATEGORY_IDS, ACCOUNT_CATEGORY_KINDS, accountCategoriesSchema, accountCategoryIdSchema, isSelectableAccountCategoryId, kindAcceptsAccountCategories, MAX_ACCOUNT_CATEGORIES, newlyAddedRetiredCategories, RETIRED_ACCOUNT_CATEGORY_IDS, SELECTABLE_ACCOUNT_CATEGORY_IDS, createAccountRequestSchema, } from './accountGraph.js';
 export { 
 // Schemas
 userNameSchema, userRelationshipSchema, themePreferenceSchema, userResponseSchema, userProfileUpdateSchema, currentUserResponseSchema, deviceLinkedSessionSchema, deviceLinkedSessionsResponseSchema, 

package/dist/esm/userResponse.js

@@ -30,7 +30,7 @@
  */
 import { z } from 'zod';
 import { verifiedDomainSchema } from './identity.js';
-import { accountKindSchema, organizationCategorySchema } from './accountGraph.js';
+import { accountCategoriesSchema, accountKindSchema } from './accountGraph.js';
 export const userNameSchema = z
     .object({
     first: z.string().optional(),
@@ -115,10 +115,24 @@ export const userResponseSchema = z
      */
     kind: accountKindSchema.optional(),
     /**
-     * Real-estate / team taxonomy for `kind: 'organization'` accounts.
-     * Absent on personal, project, bot, and channel accounts.
+     * What this account is about — the field a profile screen RENDERS.
+     *
+     * **Ordered, primary first.** `accountCategories[0]` is the primary
+     * category; there is deliberately no sibling `primaryCategory` field,
+     * because two representations of one fact can disagree (see rule 2 in
+     * `accountGraph.ts`). Nothing downstream may sort, de-duplicate or
+     * otherwise reorder this array.
+     *
+     * **Ids, never labels.** Each element is a stable slug; the visible text
+     * comes from the reader's own translation catalogue, keyed
+     * `accounts.accountCategory.<id>`. A label on the wire would paint every
+     * profile in the language of whoever picked it.
+     *
+     * Absent when the account has none — which is every `personal` account,
+     * and any non-personal one that has not chosen. A renderer reads
+     * `user.accountCategories ?? []`.
      */
-    organizationCategory: organizationCategorySchema.optional(),
+    accountCategories: accountCategoriesSchema.optional(),
     /**
      * The authenticated viewer's relationship to this profile. Present ONLY
      * on single-profile fetches (`GET /profiles/username/:username`,