founder-schema 0.2.0 → 0.4.0

package/dist/domains/onboarding/onboarding.js

@@ -0,0 +1,717 @@
+/**
+ * founder-schema — Onboarding: steps, enums, and the two shapes of the answers
+ *
+ * ONE LIST DEFINES THE FLOW, AND IT IS DERIVED. Each step's fields are a pick
+ * of the finish body (`ONBOARDING_STEP_SCHEMAS`), and `FOUNDER_ONBOARDING_STEPS`
+ * is built FROM those picks: its `fields`, and even whether a step may be
+ * skipped, come from the schema rather than from a second hand-written list.
+ * GymMonk arrived at one list after keeping two in sync by hand, where a step
+ * could exist with no title or, worse, no validation gate at all; until 0.2.0
+ * this file still wrote the field lists twice.
+ *
+ * TWO SHAPES, ONE SET OF RULES. A half-filled form legitimately holds `null`
+ * for a choice nobody has made yet; the finalize body only ever sees completed
+ * answers. So the rules are written once and expressed over both shapes:
+ * `onboardingFormSchema` for work in progress and `completeOnboardingBodySchema`
+ * for the end. Letting those two drift is how a wizard says a step is optional
+ * and then answers 422 at Finish.
+ *
+ * NO COPY IN HERE. Step titles, help lines and topic category names are
+ * translation KEYS (`titleKey`, `helpKey`, `labelKey`), Jansathi's rule for
+ * every config string: an English sentence in a shared package is a sentence
+ * every other language has to match by wording.
+ *
+ * @module founder-schema/domains/onboarding
+ */
+import { z } from 'zod';
+import { GENDER_VALUES, GOAL_VALUES, genderSchema, goalSchema, INDUSTRY_VALUES, industrySchema, locationSchema, optionalTrimmedString, phoneSchema, SKILL_VALUES, STARTUP_STAGE_VALUES, skillSchema, startupStageSchema, } from '../../core/common.js';
+import { ABOUT_MAX, CITY_MAX, COUNTRY_MAX, DISPLAY_NAME_MAX, GOALS_MIN, HEADLINE_MAX, LINK_URL_MAX, SKILLS_MAX, STATE_MAX, TEAM_SIZE_MAX, VENTURE_NAME_MAX, } from '../../core/limits.js';
+import { VALIDATION_MESSAGE } from '../../core/validation.js';
+import { founderLinksSchema, ventureSchema } from '../profile/founder-profile.js';
+import { uploadKeySchema } from '../uploads/uploads.js';
+// ─── Age ─────────────────────────────────────────────────────────────────────
+/**
+ * 18, ruled by the user 2026-09-21. Under-18 would pull in parental-consent
+ * duties under the DPDP Act, which is a different and larger problem than a
+ * validation rule.
+ *
+ * ⚠️ The SERVER refuses at finalize. This schema exists so the member sees a
+ * useful message; it is not the gate.
+ */
+export const MIN_AGE_YEARS = 18;
+/** A sanity ceiling, not a product rule. Catches a mistyped year. */
+export const MAX_AGE_YEARS = 120;
+/**
+ * Whole years completed, by the calendar.
+ *
+ * ⚠️ NOT `elapsedMs / (365.25 * day)`, which is what the sibling product uses.
+ * That approximation reads 17.9986 at the start of somebody's eighteenth
+ * birthday and only crosses 18 about halfway through the day, so it refuses
+ * them for the half of their birthday they are most likely to be signing up on.
+ * Measured: it disagrees with the calendar on all 400 of the next 400 days.
+ * An age gate is exactly the place an approximation is not good enough.
+ */
+export function ageInYears(isoDate, now = new Date()) {
+    // ⚠️ A STRING, `YYYY-MM-DD`, not a `Date`. This is a wire contract, so it
+    // takes the wire type. The backend is the obvious caller and the backend
+    // holds a `Date`, so it must format first; passing the Date straight in used
+    // to fail with `isoDate.split is not a function`, which says nothing useful.
+    // Naming the fix costs one line and saves the next person the detour.
+    if (typeof isoDate !== 'string') {
+        throw new TypeError('ageInYears expects a YYYY-MM-DD string, not a Date. Format it first, e.g. date.toISOString().slice(0, 10).');
+    }
+    const [y, m, d] = isoDate.split('-').map(Number);
+    let age = now.getUTCFullYear() - y;
+    const monthNow = now.getUTCMonth() + 1;
+    if (monthNow < m || (monthNow === m && now.getUTCDate() < d))
+        age -= 1;
+    return age;
+}
+/** A calendar date with no time component, `YYYY-MM-DD`. */
+export const isoDateSchema = z
+    .string()
+    .trim()
+    .regex(/^\d{4}-\d{2}-\d{2}$/, VALIDATION_MESSAGE.dateInvalid);
+/** True only for a date that exists. Rejects 2026-02-30 and 2026-13-01. */
+function isRealDate(iso) {
+    const [y, m, d] = iso.split('-').map(Number);
+    if (m < 1 || m > 12 || d < 1)
+        return false;
+    const asDate = new Date(Date.UTC(y, m - 1, d));
+    return (asDate.getUTCFullYear() === y && asDate.getUTCMonth() === m - 1 && asDate.getUTCDate() === d);
+}
+/**
+ * Date of birth, with the age gate applied per parse.
+ *
+ * ⚠️ THE CLIENT IS NOT THE GATE. This schema exists so the member sees a useful
+ * message, and the server must refuse the same dates at finalize regardless.
+ * The sibling dating product validates the identical rule on its client and
+ * still shipped a defect where an under-age date of birth produced a live,
+ * discoverable profile, because the client was the only thing checking.
+ */
+export const dateOfBirthSchema = isoDateSchema
+    .refine(isRealDate, { error: VALIDATION_MESSAGE.dobInvalid })
+    .refine((v) => ageInYears(v) >= MIN_AGE_YEARS, { error: VALIDATION_MESSAGE.dobUnderAge })
+    .refine((v) => ageInYears(v) <= MAX_AGE_YEARS, { error: VALIDATION_MESSAGE.dobTooOld });
+// ─── Business ────────────────────────────────────────────────────────────────
+export const BUSINESS_TYPE_VALUES = ['startup', 'sme', 'enterprise'];
+export const businessTypeSchema = z.enum(BUSINESS_TYPE_VALUES);
+// ─── Topics: the shared vocabulary ───────────────────────────────────────────────────────────────
+/**
+ * ONE vocabulary, used TWICE: a member picks these as their `interests`, and a
+ * post carries them as its `topics`. That is what makes relevance an index
+ * lookup rather than a guess, and it is why this list is not called "interests"
+ * - naming it for one of its two jobs would have invited a second list for the
+ * other, which is the mistake this package has already made once with goals.
+ * (User's ruling via hary, 2026-09-21.)
+ *
+ * Deliberately DISTINCT from two neighbours that will otherwise collect the
+ * same words:
+ *
+ *   industry  what your company does
+ *   skills    what you can do
+ *   interests what you want to read about
+ *
+ * If the copy does not keep them apart, members fill all three identically and
+ * every one of them stops telling us anything.
+ *
+ * A closed list, consistent with industry, skill and stage, for the reason
+ * already written beside those: free text means two people typing "growth" and
+ * "Growth Marketing" never match, and matching is the entire point. The cost is
+ * that adding an interest needs a publish.
+ *
+ * Tuned down from the dating product's 246, which is mostly dating material.
+ * Values reuse its exact strings wherever one existed, so its Hindi
+ * translations can be lifted across.
+ *
+ * ⚠️ Stored per member. Append only; removing a value orphans data.
+ */
+export const TOPIC_VALUES = [
+    // Career growth
+    'mentoring',
+    'leadership',
+    'networking',
+    'public_speaking',
+    'teaching',
+    'hiring_talent',
+    'personal_branding',
+    'career_transition',
+    'remote_work',
+    // Innovation and tech
+    'ai_ml',
+    'blockchain',
+    'crypto_web3',
+    'robotics',
+    'data_science',
+    'cybersecurity',
+    'game_dev',
+    'ux_design',
+    'app_development',
+    'open_source',
+    'electronics',
+    'space_exploration',
+    'green_tech',
+    'deeptech',
+    'no_code',
+    // Business
+    'entrepreneurship',
+    'investing',
+    'stock_trading',
+    'personal_finance',
+    'fundraising',
+    'marketing',
+    'sales',
+    'consulting',
+    'ecommerce',
+    'retail',
+    'real_estate',
+    'supply_chain',
+    'product_management',
+    'growth',
+    'b2b_saas',
+    'd2c',
+    // Personal development
+    'meditation',
+    'journaling',
+    'self_improvement',
+    'productivity',
+    'reading',
+    'online_courses',
+    'philosophy',
+    'psychology',
+    'therapy',
+    'sleep_optimization',
+    'gym',
+    'yoga',
+    // Creative
+    'photography',
+    'writing',
+    'graphic_design',
+    'filmmaking',
+    'digital_art',
+    'content_creation',
+    'blogging',
+    'vlogging',
+    'podcasts',
+    'animation',
+    'music_production',
+    // Impact and community
+    'volunteering',
+    'ngo_work',
+    'environmental',
+    'women_empowerment',
+    'community_service',
+    'social_enterprise',
+    'education_access',
+];
+export const topicSchema = z.enum(TOPIC_VALUES);
+/**
+ * The grouping the picker renders.
+ *
+ * ⚠️ `TOPIC_VALUES` above is the single source of truth and this is typed
+ * against it, so a typo here is a compile error rather than a chip that renders
+ * and can never be selected. The dating product keeps a categorised list and a
+ * flat list side by side and they have already drifted apart by two values;
+ * a test in this package asserts these two agree exactly, in both directions.
+ */
+export const TOPIC_CATEGORY_KEYS = [
+    'career',
+    'tech',
+    'business',
+    'growth',
+    'creative',
+    'impact',
+];
+const topicCategory = (key, values) => ({
+    key,
+    labelKey: `topics.category.${key}`,
+    values,
+});
+export const TOPIC_CATEGORIES = [
+    topicCategory('career', [
+        'mentoring',
+        'leadership',
+        'networking',
+        'public_speaking',
+        'teaching',
+        'hiring_talent',
+        'personal_branding',
+        'career_transition',
+        'remote_work',
+    ]),
+    topicCategory('tech', [
+        'ai_ml',
+        'blockchain',
+        'crypto_web3',
+        'robotics',
+        'data_science',
+        'cybersecurity',
+        'game_dev',
+        'ux_design',
+        'app_development',
+        'open_source',
+        'electronics',
+        'space_exploration',
+        'green_tech',
+        'deeptech',
+        'no_code',
+    ]),
+    topicCategory('business', [
+        'entrepreneurship',
+        'investing',
+        'stock_trading',
+        'personal_finance',
+        'fundraising',
+        'marketing',
+        'sales',
+        'consulting',
+        'ecommerce',
+        'retail',
+        'real_estate',
+        'supply_chain',
+        'product_management',
+        'growth',
+        'b2b_saas',
+        'd2c',
+    ]),
+    topicCategory('growth', [
+        'meditation',
+        'journaling',
+        'self_improvement',
+        'productivity',
+        'reading',
+        'online_courses',
+        'philosophy',
+        'psychology',
+        'therapy',
+        'sleep_optimization',
+        'gym',
+        'yoga',
+    ]),
+    topicCategory('creative', [
+        'photography',
+        'writing',
+        'graphic_design',
+        'filmmaking',
+        'digital_art',
+        'content_creation',
+        'blogging',
+        'vlogging',
+        'podcasts',
+        'animation',
+        'music_production',
+    ]),
+    topicCategory('impact', [
+        'volunteering',
+        'ngo_work',
+        'environmental',
+        'women_empowerment',
+        'community_service',
+        'social_enterprise',
+        'education_access',
+    ]),
+];
+/**
+ * How many a member must pick. A minimum exists because these drive feed
+ * relevance and zero of them means no relevance at all.
+ *
+ * ⚠️ If 3 turns out to be hard to reach against this list, that is a signal
+ * about the LIST, not about the minimum. The sibling product enforces no
+ * minimum at all, and its own field config says "pick up to 10" while every
+ * screen and schema enforces 20.
+ */
+export const INTERESTS_MIN = 3;
+export const INTERESTS_MAX = 10;
+// ─── The step keys ───────────────────────────────────────────────────────────
+/**
+ * The step keys, in order, as a literal union, so a consumer can key a table by
+ * step and have TypeScript insist on every one. Before 0.2.0 `key` was a plain
+ * string and the web client kept its own copy of this list to get the same
+ * check; a test there held the two together. Now there is one list.
+ */
+export const ONBOARDING_STEP_KEYS = [
+    'identity',
+    'contact',
+    'location',
+    'goals',
+    'interests',
+    'business',
+    'guidelines',
+];
+// ─── Guidelines ──────────────────────────────────────────────────────────────
+/**
+ * The community guidelines a member agrees to at the last step, by version.
+ *
+ * The finish body accepts THIS version and no other: an old tab still showing
+ * last month's text cannot record agreement to text it never displayed, and
+ * `'whatever'` is not a version. Until 0.2.0 any non-empty string passed, and
+ * the web client held this constant on its own.
+ *
+ * ⚠ Changing the guidelines text means bumping this, in the same publish.
+ * Every member who agreed to an earlier version keeps that version on their
+ * profile; that record is the point.
+ */
+export const GUIDELINES_VERSION = '2026-10-03';
+export const guidelinesVersionSchema = z.literal(GUIDELINES_VERSION, {
+    error: VALIDATION_MESSAGE.guidelinesOutdated,
+});
+// ─── Contact ─────────────────────────────────────────────────────────────────
+/**
+ * The links the contact step collects, picked from the profile's own links so
+ * the two cannot disagree on what a link is. The phone is `phoneSchema`: ten
+ * digits, stored raw with no country code, on the account rather than here.
+ */
+export const contactLinksSchema = founderLinksSchema.pick({
+    linkedin: true,
+    x: true,
+    instagram: true,
+});
+/** A team size has at most this many digits: `TEAM_SIZE_MAX` written out. */
+export const TEAM_SIZE_DIGITS_MAX = String(TEAM_SIZE_MAX).length;
+// ─── The form, mid-flight: the draft each step saves ──────────────────────────
+/**
+ * The answers so far, keyed by the finish body's own field names: what each
+ * step SAVES (`PATCH /onboarding`, merged per field), what `GET` hands back
+ * to resume, and so the only keys a draft may hold
+ * (`ONBOARDING_DRAFT_KEYS`).
+ *
+ * RAW, on purpose: a draft is what the member TYPED, not what Finish will send.
+ * A half-typed link is ordinary text, a team size is digits as typed, and every
+ * choice is `null` until made ("not answered" is not "answered with nothing").
+ * Nothing here is required; whether a member may FINISH is
+ * `completeOnboardingBodySchema`'s decision, and the client builds that body
+ * from these answers.
+ *
+ * Screens may hold a different shape on top of this one (the web draws first
+ * and last name as two fields and joins them into `displayName`). Derive that
+ * type from `OnboardingForm` rather than writing it out, so a field added here
+ * reaches every screen.
+ *
+ * A stored draft is UNTRUSTED when it comes back: an older client, or another
+ * one, wrote it, and the server stores values opaquely. Read it with
+ * `readOnboardingDraft`, never by casting.
+ */
+export const onboardingFormSchema = z.object({
+    displayName: z.string().max(DISPLAY_NAME_MAX),
+    gender: genderSchema.nullable(),
+    /** `YYYY-MM-DD` once complete; whatever has been typed until then. */
+    dateOfBirth: z.string(),
+    headline: z.string().max(HEADLINE_MAX),
+    about: z.string().max(ABOUT_MAX),
+    /**
+     * Allowed as a key, and NEVER restored by `readOnboardingDraft`: an upload
+     * not attached within a day is deleted by the storage lifecycle rule, so a
+     * key from an older draft would fail at Finish, on the last screen, about a
+     * photo picked days ago. Clients hold it for the visit and do not save it.
+     */
+    avatarUploadKey: uploadKeySchema.nullable(),
+    skills: z.array(skillSchema).max(SKILLS_MAX),
+    /** As typed; the finish body takes `phoneSchema`'s ten digits. */
+    phone: z.string(),
+    /** As typed; the finish body takes full `https://` URLs. */
+    links: z.object({
+        linkedin: z.string().max(LINK_URL_MAX),
+        x: z.string().max(LINK_URL_MAX),
+        instagram: z.string().max(LINK_URL_MAX),
+    }),
+    /** `null` until the member opens the location step, and when they skip it. */
+    location: z
+        .object({
+        city: z.string().max(CITY_MAX),
+        state: z.string().max(STATE_MAX),
+        country: z.string().max(COUNTRY_MAX),
+    })
+        .nullable(),
+    goals: z.array(goalSchema).max(GOAL_VALUES.length),
+    interests: z.array(topicSchema).max(INTERESTS_MAX),
+    /**
+     * Always present; empty until started. Onboarding does not ask for a
+     * tagline (the profile does, later), so the draft has none.
+     */
+    venture: z.object({
+        name: z.string().max(VENTURE_NAME_MAX),
+        website: z.string().max(LINK_URL_MAX),
+        industry: industrySchema.nullable(),
+        stage: startupStageSchema.nullable(),
+        /** Digits as typed, at most `TEAM_SIZE_DIGITS_MAX`; the body sends a number. */
+        teamSize: z.string().max(TEAM_SIZE_DIGITS_MAX),
+    }),
+    businessType: businessTypeSchema.nullable(),
+    /** The guidelines text the member agreed to, or `null`. */
+    guidelinesVersion: z.string().nullable(),
+});
+// ─── Reading a stored draft back ─────────────────────────────────────────────
+/** Longest date of birth worth keeping from a draft: `YYYY-MM-DD`. */
+const DATE_INPUT_MAX = 10;
+/** Longest phone number worth keeping from a draft, as typed with spaces. */
+const PHONE_INPUT_MAX = 20;
+/** Text, cut to its limit; anything that is not text is "not answered". */
+const draftText = (max) => z
+    .string()
+    .catch('')
+    .transform((v) => v.slice(0, max));
+/** One of a vocabulary, or `null` ("not answered"). */
+const draftChoice = (values) => z.enum(values).nullable().catch(null);
+/**
+ * Items of a vocabulary, deduplicated and capped. Unknown items (a value since
+ * retired, or junk) are dropped one by one, so the rest of the answer survives.
+ */
+const draftList = (values, max) => z
+    .array(z.unknown())
+    .catch([])
+    .transform((items) => {
+    const allowed = new Set(values);
+    const kept = items.filter((v) => typeof v === 'string' && allowed.has(v));
+    return [...new Set(kept)].slice(0, max);
+});
+/** An object of the given fields, or `null` when the draft holds none. */
+const draftObject = (shape) => z
+    .record(z.string(), z.unknown())
+    .nullable()
+    .catch(null)
+    .pipe(z.union([z.null(), z.object(shape)]));
+const draftReaderSchema = z.object({
+    displayName: draftText(DISPLAY_NAME_MAX),
+    gender: draftChoice(GENDER_VALUES),
+    dateOfBirth: draftText(DATE_INPUT_MAX),
+    headline: draftText(HEADLINE_MAX),
+    about: draftText(ABOUT_MAX),
+    avatarUploadKey: z
+        .unknown()
+        .optional()
+        .transform(() => null),
+    skills: draftList(SKILL_VALUES, SKILLS_MAX),
+    phone: draftText(PHONE_INPUT_MAX),
+    links: draftObject({
+        linkedin: draftText(LINK_URL_MAX),
+        x: draftText(LINK_URL_MAX),
+        instagram: draftText(LINK_URL_MAX),
+    }).transform((links) => links ?? { linkedin: '', x: '', instagram: '' }),
+    location: draftObject({
+        city: draftText(CITY_MAX),
+        state: draftText(STATE_MAX),
+        country: draftText(COUNTRY_MAX),
+    }),
+    goals: draftList(GOAL_VALUES, GOAL_VALUES.length),
+    interests: draftList(TOPIC_VALUES, INTERESTS_MAX),
+    venture: draftObject({
+        name: draftText(VENTURE_NAME_MAX),
+        website: draftText(LINK_URL_MAX),
+        industry: draftChoice(INDUSTRY_VALUES),
+        stage: draftChoice(STARTUP_STAGE_VALUES),
+        teamSize: z
+            .string()
+            .catch('')
+            .transform((v) => v.replace(/\D/g, '').slice(0, TEAM_SIZE_DIGITS_MAX)),
+    }).transform((venture) => venture ?? { ...EMPTY_ONBOARDING_VENTURE }),
+    businessType: draftChoice(BUSINESS_TYPE_VALUES),
+    /** Agreement to an OLDER text is not agreement to this one. */
+    guidelinesVersion: z
+        .unknown()
+        .optional()
+        .transform((v) => (v === GUIDELINES_VERSION ? GUIDELINES_VERSION : null)),
+});
+/** The business step before anything is chosen. */
+export const EMPTY_ONBOARDING_VENTURE = {
+    name: '',
+    website: '',
+    industry: null,
+    stage: null,
+    teamSize: '',
+};
+/**
+ * A stored draft as an `OnboardingForm`, FIELD BY FIELD.
+ *
+ * Every field is checked against its own vocabulary and cut to its own limit;
+ * one that does not fit becomes "not answered" (`''`, `null`, `[]`) and the
+ * rest of the draft survives. Never coerced into a different answer: a value
+ * outside a vocabulary is dropped, not mapped to the nearest one. A photo key
+ * is never restored (see `avatarUploadKey`), and agreement only counts for the
+ * CURRENT guidelines.
+ *
+ * It fills in no answer the member did not give: a blank country stays blank.
+ * Whatever a screen shows by default is that screen's choice.
+ */
+export function readOnboardingDraft(draft) {
+    const source = draft && typeof draft === 'object' && !Array.isArray(draft) ? draft : {};
+    return draftReaderSchema.parse(source);
+}
+// ─── The finalize body ───────────────────────────────────────────────────────
+/**
+ * What the client sends to finish. Completed answers only.
+ *
+ * ⚠️ EVERY OPTIONAL FIELD HERE MUST BE ABSENT WHEN UNANSWERED, never a default
+ * standing in for one. The sibling gym product sent `bloodGroup ?? 'O+'`, so
+ * every member who skipped the question was recorded as O-positive: a real
+ * answer, indistinguishable from one somebody gave, sitting on a screen staff
+ * would read in an emergency. Absent has to stay absent.
+ *
+ * ⚠️ AND THIS IS NOT THE GATE EITHER. The server re-checks the age and refuses
+ * at finalize. `isOnboarded` may be set here and nowhere else: four of the
+ * profile's partial indexes are gated on it, so a half-built profile carrying
+ * it true appears in Discover half-built.
+ *
+ * Location, venture and links are the profile's own shapes, not copies: the
+ * copies are how the profile model came to lack Instagram.
+ */
+export const completeOnboardingBodySchema = z.object({
+    // Plain bounds, no custom message: `too_small` with minimum 1 already says
+    // "required", and the client words it in the member's language.
+    displayName: z.string().trim().min(1).max(DISPLAY_NAME_MAX),
+    /**
+     * ⚠️ NO `username` HERE, and its absence is deliberate.
+     *
+     * It used to be required, and that was a defect: no onboarding step collects
+     * one, the design draws no screen for one, and it was not even on the
+     * in-progress form, so a finalize could never have succeeded. Found by
+     * checking every finalize-required field against the step list; a test now
+     * asserts that relationship in both directions.
+     *
+     * The handle is DERIVED SERVER-SIDE at finalize and edited later from the Me
+     * tab, which is what the product describes. That also makes the collision
+     * case kinder: a server deriving a handle can suffix it and move on, whereas
+     * a member who picked one six steps ago can only be told, at the end, that
+     * step one failed.
+     */
+    gender: genderSchema,
+    dateOfBirth: dateOfBirthSchema,
+    headline: optionalTrimmedString(HEADLINE_MAX),
+    about: optionalTrimmedString(ABOUT_MAX),
+    /**
+     * The key the presign handed out, in the minted format. It was a bare
+     * string until 0.2.0, so `'../../etc/passwd'` passed this schema and only
+     * the server's own commit check stood in the way.
+     */
+    avatarUploadKey: uploadKeySchema.optional(),
+    phone: phoneSchema,
+    links: contactLinksSchema.optional(),
+    /** Absent when the member skipped the step or refused the permission. */
+    location: locationSchema.optional(),
+    goals: z.array(goalSchema).min(GOALS_MIN).max(GOAL_VALUES.length),
+    interests: z.array(topicSchema).min(INTERESTS_MIN).max(INTERESTS_MAX),
+    skills: z.array(skillSchema).max(SKILLS_MAX).optional(),
+    /**
+     * Absent when the member skipped the business step. The profile's venture
+     * without `foundedYear`, which onboarding does not ask; the Me tab does.
+     */
+    venture: ventureSchema.omit({ foundedYear: true }).optional(),
+    businessType: businessTypeSchema.optional(),
+    /**
+     * The version of the guidelines this member read: `GUIDELINES_VERSION`,
+     * exactly.
+     *
+     * A version and not a boolean, and the server stamps the time. A boolean says
+     * somebody agreed; a version and a timestamp say WHAT they agreed to and
+     * WHEN, which is the only form worth anything the day the text changes or a
+     * moderation decision is disputed.
+     */
+    guidelinesVersion: guidelinesVersionSchema,
+});
+// ─── The steps ───────────────────────────────────────────────────────────────
+/**
+ * Each step's slice of the finish body, picked FROM it, so a client validating
+ * "may I leave this step" and the server validating the finish apply the very
+ * same rules. A copy would drift, and the drift shows up as a wizard that lets
+ * a step pass and a finish that refuses it, on the last screen.
+ *
+ * THIS IS THE ONE PLACE A STEP'S FIELDS ARE WRITTEN. `FOUNDER_ONBOARDING_STEPS`
+ * below reads them from here. A test asserts that every finish field belongs to
+ * exactly one step.
+ *
+ * These validate the FINISH shape (skipped = absent), not the in-progress form:
+ * a client maps its form state to the slice first. The server does not run them
+ * on a draft save, because a half-answered step must be storable.
+ */
+export const ONBOARDING_STEP_SCHEMAS = {
+    identity: completeOnboardingBodySchema.pick({
+        displayName: true,
+        gender: true,
+        dateOfBirth: true,
+        headline: true,
+        about: true,
+        avatarUploadKey: true,
+        // Here because ruling D8 folded the design's orphan "title, achievements,
+        // skills" screen into step one. It was on no step until 0.2.0, which made
+        // it the one finish field no step owned.
+        skills: true,
+    }),
+    contact: completeOnboardingBodySchema.pick({ phone: true, links: true }),
+    location: completeOnboardingBodySchema.pick({ location: true }),
+    goals: completeOnboardingBodySchema.pick({ goals: true }),
+    interests: completeOnboardingBodySchema.pick({ interests: true }),
+    business: completeOnboardingBodySchema.pick({ venture: true, businessType: true }),
+    guidelines: completeOnboardingBodySchema.pick({ guidelinesVersion: true }),
+};
+export const FOUNDER_ONBOARDING_STEPS = ONBOARDING_STEP_KEYS.map((key) => {
+    const slice = ONBOARDING_STEP_SCHEMAS[key];
+    return {
+        key,
+        titleKey: `onboarding.steps.${key}.title`,
+        helpKey: `onboarding.steps.${key}.help`,
+        fields: Object.keys(slice.shape),
+        required: !slice.safeParse({}).success,
+    };
+});
+export const ONBOARDING_TOTAL_STEPS = FOUNDER_ONBOARDING_STEPS.length;
+/** Fields gating each step, in step order. Read from the same picks. */
+export const ONBOARDING_STEP_FIELDS = FOUNDER_ONBOARDING_STEPS.map((s) => s.fields);
+/** What finishing answers: the new profile's id and the handle derived for it. */
+export const completeOnboardingResponseSchema = z.object({
+    id: z.string(),
+    username: z.string(),
+});
+// ─── The resume cursor ───────────────────────────────────────────────────────
+/**
+ * The keys a draft may hold: exactly the in-progress form's fields.
+ *
+ * ⚠ The server writes each key as a dot path (`draft.<key>`). Unchecked, a key
+ * holding a dot writes somewhere nested the form never asked for, and the
+ * collection fills with whatever a client invents. Until 0.2.0 the backend
+ * kept its own copy of this list and DROPPED unknown keys without a word; now a
+ * draft carrying one is refused, with the key in the issue's path.
+ */
+export const onboardingDraftKeySchema = onboardingFormSchema.keyof();
+export const ONBOARDING_DRAFT_KEYS = onboardingDraftKeySchema.options;
+/**
+ * Where the member got to, kept in its own collection, separate from the
+ * profile.
+ *
+ * `step` is a flat index into `FOUNDER_ONBOARDING_STEPS`, not a `(step, sub)`
+ * pair: one number is what lets a member start on the web and resume elsewhere,
+ * provided both ends agree on the encoding.
+ *
+ * The draft's KEYS come from the form; its VALUES are opaque on purpose. A
+ * half-answered step must be storable even though it would fail the finish,
+ * and everything in it is re-validated strictly at finalize.
+ *
+ * `partialRecord`, not `record`: in Zod 4 an enum-keyed `z.record` demands
+ * every key, and a draft holds whichever steps the member has reached.
+ */
+export const onboardingDraftSchema = z.partialRecord(onboardingDraftKeySchema, z.unknown());
+export const onboardingProgressSchema = z.object({
+    step: z.number().int().min(0).max(ONBOARDING_TOTAL_STEPS),
+    draft: onboardingDraftSchema.optional(),
+});
+/**
+ * `PATCH` body: any subset of the cursor, merged server-side. No defaults.
+ * `step` may equal `ONBOARDING_TOTAL_STEPS`: "past the last step", which the
+ * client sends on its way to finish.
+ */
+export const onboardingProgressUpdateSchema = z.object({
+    step: z.number().int().min(0).max(ONBOARDING_TOTAL_STEPS).optional(),
+    draft: onboardingDraftSchema.optional(),
+});
+/**
+ * What the client reads on return, from `GET` and from every `PATCH`.
+ *
+ * ⚠️ `onboarded` is the gate and it comes from the profile, not from the
+ * cursor: a finished member on a new device must be recognised even when the
+ * cursor row is gone, and a cursor that failed to load must never make an
+ * unfinished member look finished.
+ */
+export const onboardingStatusSchema = z.object({
+    onboarded: z.boolean(),
+    step: z.number().int().min(0).max(ONBOARDING_TOTAL_STEPS),
+    draft: onboardingDraftSchema.optional(),
+});
+//# sourceMappingURL=onboarding.js.map