From dec57326871d5b74a9ddb3d2d5158008dd890aef Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Fri, 11 Sep 2026 09:07:41 +0200 Subject: [PATCH 1/7] fix(onboarding): checklist queries follow its own setup rule The card's visibility rule gained a "ran the setup flow" disjunct; the component's query gate kept restating the older half of it. A wizard-run account past five readings therefore saw a permanent checklist whose medication, data-source, notification and insight rows were frozen at "not done", because every supporting query was disabled. Both places now read one exported predicate, isStillInSetup, which also keeps the rows live for a restarted run nobody finished. --- .../getting-started-checklist.test.tsx | 139 ++++++++++++++++++ .../onboarding/getting-started-checklist.tsx | 25 +++- .../onboarding/__tests__/checklist.test.ts | 73 +++++++++ src/lib/onboarding/checklist.ts | 46 ++++-- 4 files changed, 265 insertions(+), 18 deletions(-) create mode 100644 src/components/onboarding/__tests__/getting-started-checklist.test.tsx diff --git a/src/components/onboarding/__tests__/getting-started-checklist.test.tsx b/src/components/onboarding/__tests__/getting-started-checklist.test.tsx new file mode 100644 index 000000000..cfe0c20e9 --- /dev/null +++ b/src/components/onboarding/__tests__/getting-started-checklist.test.tsx @@ -0,0 +1,139 @@ +/** + * v1.39 (Wave C, C1) — the checklist's data queries follow the same rule as + * its visibility. + * + * `shouldShowChecklist` gained `hasEnteredOnboardingFlow` as a third + * disjunct; `checklistRelevant` in the component kept restating the older + * half of the rule, so a wizard-run account past five readings still saw the + * card while every supporting query was `enabled: false` — the medication, + * data-source, notification and insights rows read "not done" for things the + * account had already done (research I9). + * + * Rendered SSR-only, per this repo's component-test convention. `useQuery` is + * mocked to honour `enabled` exactly the way tanstack does — a disabled query + * has no data — so what the rows say here is what the dashboard says. + */ +import { renderToStaticMarkup } from "react-dom/server"; +import { describe, expect, it, vi } from "vitest"; + +import { I18nProvider } from "@/lib/i18n/context"; +import type { AuthUser } from "@/hooks/use-auth"; +import { + defaultOnboardingSteps, + emptyOnboardingNeeds, + type OnboardingStateDto, +} from "@/lib/onboarding/needs"; + +let currentUser: AuthUser | null = null; +/** Every `enabled` flag the component asked for, keyed by its query key. */ +const enabledByKey = new Map(); + +vi.mock("@/hooks/use-auth", () => ({ + useAccountOnceMounted: () => currentUser, +})); + +vi.mock("@/lib/queries/use-dashboard-snapshot", () => ({ + useDashboardSnapshot: () => ({ + data: { tiles: { summaries: { weight: { count: 12 } } } }, + }), +})); + +const RESPONSES: Record = { + '["medications"]': [{ id: "m1" }, { id: "m2" }, { id: "m3" }], + '["user","ai-provider"]': { aiAvailable: true }, + '["integrations","status"]': { + integrations: [{ integration: "whoop", connected: true }], + }, + // Deliberately NOT configured: one open row keeps the card on screen, so + // the rows this test is about are actually rendered. + '["notifications","preferences"]': { channels: [{ enabled: false }] }, +}; + +vi.mock("@tanstack/react-query", async (importOriginal) => { + const actual = await importOriginal(); + return { + ...actual, + useQuery: (options: { + queryKey: readonly unknown[]; + enabled?: boolean; + }) => { + const key = JSON.stringify(options.queryKey); + const enabled = options.enabled !== false; + enabledByKey.set(key, enabled); + return { data: enabled ? RESPONSES[key] : undefined }; + }, + }; +}); + +const { GettingStartedChecklist } = + await import("../getting-started-checklist"); + +/** A record the flow really finished: Q1 answered, confirmed, task settled. */ +function settledOnboarding(): OnboardingStateDto { + return { + steps: defaultOnboardingSteps().map((step) => ({ + ...step, + status: "done" as const, + })), + needs: { ...emptyOnboardingNeeds(), recordTarget: "me" }, + completedAt: "2026-09-10T08:00:00.000Z", + firstResult: { + task: "log-reading", + target: null, + completedAt: "2026-09-10T08:05:00.000Z", + }, + } as OnboardingStateDto; +} + +function user(overrides: Partial = {}): AuthUser { + return { + id: "u1", + email: "a@b.c", + username: "a", + heightCm: 175, + dateOfBirth: "1990-01-01T00:00:00.000Z", + gender: "MALE", + onboardingCompletedAt: "2026-09-10T08:00:00.000Z", + onboarding: settledOnboarding(), + ...overrides, + } as AuthUser; +} + +function render(): string { + enabledByKey.clear(); + return renderToStaticMarkup( + + + , + ); +} + +describe(" — rows for an established account", () => { + it("reads the real medication, data-source and insights state once the flow is behind the account", () => { + currentUser = user(); + const html = render(); + + // The card is on screen: the notifications row is genuinely open. The + // list itself is collapsed on a server paint, so the progress meter is + // what the rows add up to — profile, measurement, medication, data + // source and insights done, notifications not. + expect(html).toContain('data-testid="onboarding-card"'); + expect(html).toContain("5 of 6 done"); + }); + + it("keeps the supporting queries enabled while the card can render", () => { + currentUser = user(); + render(); + expect(enabledByKey.get('["medications"]')).toBe(true); + expect(enabledByKey.get('["integrations","status"]')).toBe(true); + expect(enabledByKey.get('["notifications","preferences"]')).toBe(true); + expect(enabledByKey.get('["user","ai-provider"]')).toBe(true); + }); + + it("still fetches nothing for a record that never entered the flow and is long past five readings", () => { + currentUser = user({ onboarding: null }); + render(); + expect(enabledByKey.get('["medications"]')).toBe(false); + expect(enabledByKey.get('["integrations","status"]')).toBe(false); + }); +}); diff --git a/src/components/onboarding/getting-started-checklist.tsx b/src/components/onboarding/getting-started-checklist.tsx index 09d678d29..15343b037 100644 --- a/src/components/onboarding/getting-started-checklist.tsx +++ b/src/components/onboarding/getting-started-checklist.tsx @@ -26,6 +26,7 @@ import { queryKeys } from "@/lib/query-keys"; import { buildChecklist, checklistProgress, + isStillInSetup, shouldShowChecklist, upcomingVisitCountFrom, visibleChecklist, @@ -239,17 +240,27 @@ export function GettingStartedChecklist() { }, [snapshotData]); // v1.15.20 — only fetch the checklist's supporting data while the card - // can actually render: the user is still in setup (`shouldShowChecklist`'s - // `onboardingCompletedAt == null || measurementCount < 5` rule) and has - // not dismissed it. Established users used to pay this medications fetch - // (and, pre-v1.5, two more) on every dashboard load for a card that - // never mounts. Gated on the snapshot having resolved so the count is - // real, not the loading-default 0. + // can actually render: the user is still in setup and has not dismissed + // it. Established users used to pay this medications fetch (and, pre-v1.5, + // two more) on every dashboard load for a card that never mounts. Gated on + // the snapshot having resolved so the count is real, not the + // loading-default 0. + // + // v1.39 (Wave C, C1) — the rule is `isStillInSetup`, the same predicate + // `shouldShowChecklist` applies, rather than a restatement of half of it. + // The two drifted apart once already: the visibility rule learned about + // records that ran the setup flow and this gate did not, so the card + // rendered for a wizard-run account past five readings with every + // network-backed row frozen at "not done" (research I9, M-p). const checklistRelevant = !!user && !dismissedAll && snapshotData !== undefined && - (user.onboardingCompletedAt == null || measurementCount < 5); + isStillInSetup({ + onboarding: user.onboarding ?? null, + onboardingCompletedAt: user.onboardingCompletedAt ?? null, + measurementCount, + }); const { data: medsData } = useQuery>({ queryKey: queryKeys.medications(), diff --git a/src/lib/onboarding/__tests__/checklist.test.ts b/src/lib/onboarding/__tests__/checklist.test.ts index 6d19e8fa1..693f336d3 100644 --- a/src/lib/onboarding/__tests__/checklist.test.ts +++ b/src/lib/onboarding/__tests__/checklist.test.ts @@ -9,6 +9,7 @@ import { CHECKLIST_BASE_ITEM_IDS, CHECKLIST_ITEM_IDS, isProfileComplete, + isStillInSetup, shouldShowChecklist, trendHintFor, upcomingVisitCountFrom, @@ -608,3 +609,75 @@ describe("shouldShowChecklist and the setup flow", () => { ).toBe(false); }); }); + +describe("isStillInSetup", () => { + // The one predicate both the visibility rule and the component's query gate + // read, so the card can never render with its supporting queries switched + // off (research I9). + it("is true for a record that ran the flow, whatever its reading count", () => { + expect( + isStillInSetup({ + onboarding: onboardingState(), + onboardingCompletedAt: "2026-01-01T00:00:00Z", + measurementCount: 120, + }), + ).toBe(true); + }); + + it("is true for a restarted run nobody finished (M-p)", () => { + const restarted = onboardingState({ completedAt: null }); + expect( + isStillInSetup({ + onboarding: restarted, + // `restart` deliberately leaves the account stamp alone. + onboardingCompletedAt: "2026-01-01T00:00:00Z", + measurementCount: 120, + }), + ).toBe(true); + }); + + it("keeps the pre-flow rule for a record that never entered the flow", () => { + const untouched: OnboardingStateDto = { + steps: defaultOnboardingSteps(), + needs: emptyOnboardingNeeds(), + completedAt: null, + firstResult: null, + }; + expect( + isStillInSetup({ + onboarding: untouched, + onboardingCompletedAt: "2026-01-01T00:00:00Z", + measurementCount: 10, + }), + ).toBe(false); + expect( + isStillInSetup({ + onboarding: untouched, + onboardingCompletedAt: "2026-01-01T00:00:00Z", + measurementCount: 4, + }), + ).toBe(true); + expect( + isStillInSetup({ + onboarding: null, + onboardingCompletedAt: null, + measurementCount: 10, + }), + ).toBe(true); + }); + + it("is the rule `shouldShowChecklist` itself applies", () => { + const args = { + onboarding: onboardingState(), + onboardingCompletedAt: "2026-01-01T00:00:00Z", + measurementCount: 120, + }; + expect( + shouldShowChecklist({ + ...args, + dismissedAll: false, + items: buildChecklist(inputs({ measurementCount: 120 })), + }), + ).toBe(isStillInSetup(args)); + }); +}); diff --git a/src/lib/onboarding/checklist.ts b/src/lib/onboarding/checklist.ts index c0fda5294..fab022c00 100644 --- a/src/lib/onboarding/checklist.ts +++ b/src/lib/onboarding/checklist.ts @@ -282,11 +282,7 @@ export function checklistProgress(items: ChecklistItem[]): ChecklistProgress { * unfinished, because the one task the flow offered is not one of the six * rows: "every row done" and "the setup finished" are different statements. */ -export function shouldShowChecklist(args: { - onboardingCompletedAt: string | null; - measurementCount: number; - dismissedAll: boolean; - items: ChecklistItem[]; +export interface StillInSetupInputs { /** * v1.39 (C1) — the needs-based setup state for this record, or null before * the account payload resolves. A record that never entered the flow reads @@ -295,17 +291,45 @@ export function shouldShowChecklist(args: { * on the rule it already had. */ onboarding?: OnboardingStateDto | null; -}): boolean { + onboardingCompletedAt: string | null; + measurementCount: number; +} + +/** + * v1.39 (Wave C, C1) — "is this record still being set up?", as ONE predicate. + * + * Two places decide this: whether the card renders at all, and whether the + * component fetches the data its rows are about. They were two restatements of + * the same rule and they drifted — the visibility rule gained + * `hasEnteredOnboardingFlow`, the query gate kept the older half, and a + * wizard-run account past five readings got a permanently visible card whose + * every network-backed row read "not done" (research I9). A record whose + * restarted run was abandoned is in the same state (M-p): `restart` clears the + * record's own `completedAt` and deliberately not the account stamp, so + * `hasEnteredOnboardingFlow` is what keeps its rows live. + * + * Exported so the component calls it rather than restating it. + */ +export function isStillInSetup(args: StillInSetupInputs): boolean { + return ( + hasEnteredOnboardingFlow(args.onboarding ?? null) || + args.onboardingCompletedAt == null || + args.measurementCount < 5 + ); +} + +export function shouldShowChecklist( + args: StillInSetupInputs & { + dismissedAll: boolean; + items: ChecklistItem[]; + }, +): boolean { if (args.dismissedAll) return false; const onboarding = args.onboarding ?? null; const visible = visibleChecklist(args.items); if (visible.length === 0) return false; - const stillInSetup = - hasEnteredOnboardingFlow(onboarding) || - args.onboardingCompletedAt == null || - args.measurementCount < 5; - if (!stillInSetup) return false; + if (!isStillInSetup(args)) return false; if (!isOnboardingSettled(onboarding)) return true; return visible.some((item) => !item.done); From 0e79b195b0b58dd80ebb292c47c062922094c523 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Fri, 11 Sep 2026 09:12:36 +0200 Subject: [PATCH 2/7] fix(onboarding): a failed completion leaves confirm usable The baseline form raised its pending flag and lowered it on only two of three exits; the success path went through the confirm screen's finish(), which caught its own error and returned normally. A failed completion therefore disabled both buttons until the page was reloaded. The reset now lives in a finally, finish() rethrows so the form sees the failure, and the two managed-arm buttons report it themselves. The step passes before the completion run off a ledger ref, so a retry after a failure midway no longer re-sends a step the ledger already carries. --- .../confirm-failure-recovery.test.ts | 155 ++++++++++++++++++ src/components/onboarding/baseline-form.tsx | 109 +++++++----- src/components/onboarding/confirm-screen.tsx | 103 +++++++++--- 3 files changed, 303 insertions(+), 64 deletions(-) create mode 100644 src/components/onboarding/__tests__/confirm-failure-recovery.test.ts diff --git a/src/components/onboarding/__tests__/confirm-failure-recovery.test.ts b/src/components/onboarding/__tests__/confirm-failure-recovery.test.ts new file mode 100644 index 000000000..0fae32763 --- /dev/null +++ b/src/components/onboarding/__tests__/confirm-failure-recovery.test.ts @@ -0,0 +1,155 @@ +/** + * v1.39 (Wave C, C2) — a failed completion leaves the confirm screen usable. + * + * Two defects, one symptom. `advance()` in the baseline form set its pending + * flag and never reset it on the success path, and `finish()` on the confirm + * screen caught its own error and returned normally — so a failed + * `POST /api/onboarding/complete` (or a 429 on the answer PATCHes before it) + * left "Überspringen" and "Bestätigen und weiter" disabled for the rest of the + * page's life and only a reload recovered (research I10). + * + * The second defect is the retry itself: `finish()` fires one PATCH per + * question the flow never showed, and a failure midway left a partly-passed + * ledger that the next attempt walked from the top again (M-j). + * + * Both are pinned at the seam the component drives, because this repo's + * component tests render server-side and cannot click. + */ +import { describe, expect, it, vi } from "vitest"; +import { readFileSync } from "node:fs"; +import { join } from "node:path"; + +import { + defaultOnboardingSteps, + emptyOnboardingNeeds, + type OnboardingStateDto, +} from "@/lib/onboarding/needs"; + +import { runBaselineAttempt } from "../baseline-form"; +import { runConfirmFinish } from "../confirm-screen"; + +type PassableStep = Parameters< + Parameters[0]["passStep"] +>[0]; + +/** + * A flow with no unit-bearing area: Q6 is the question the machine never + * showed, so the confirm screen has to pass it on the ledger before the + * completion. + */ +function state( + overrides: Partial = {}, +): OnboardingStateDto { + return { + steps: defaultOnboardingSteps().map((step) => + step.id === "who" ? { ...step, status: "done" as const } : step, + ), + needs: { ...emptyOnboardingNeeds(), recordTarget: "me" }, + completedAt: null, + firstResult: null, + ...overrides, + }; +} + +/** The ledger as the server would answer it after one step was passed. */ +function withPassed( + base: OnboardingStateDto, + ids: readonly string[], +): OnboardingStateDto { + return { + ...base, + steps: base.steps.map((step) => + ids.includes(step.id) ? { ...step, status: "skipped" as const } : step, + ), + }; +} + +describe("runBaselineAttempt", () => { + it("hands the buttons back when the completion rejects", async () => { + const pending: boolean[] = []; + const onError = vi.fn(); + await runBaselineAttempt( + (value) => pending.push(value), + async () => { + throw new Error("complete failed"); + }, + onError, + ); + expect(pending).toEqual([true, false]); + expect(onError).toHaveBeenCalledTimes(1); + }); + + it("hands the buttons back on the success path too", async () => { + const pending: boolean[] = []; + await runBaselineAttempt( + (value) => pending.push(value), + async () => {}, + vi.fn(), + ); + expect(pending).toEqual([true, false]); + }); + + it("is the form's only way to move the pending flag", () => { + // A second, inline `setSaving(false)` is how the flag stopped being + // reset on one of the three exits in the first place. + const source = readFileSync( + join(process.cwd(), "src/components/onboarding/baseline-form.tsx"), + "utf8", + ); + expect(source).not.toContain("setSaving(false)"); + expect(source).not.toContain("setSaving(true)"); + }); +}); + +describe("runConfirmFinish", () => { + it("rethrows a failed completion instead of returning normally", async () => { + const ledger = { current: state() }; + const passed: PassableStep[] = []; + const navigate = vi.fn(); + await expect( + runConfirmFinish({ + ledger, + // The server answers the written ledger; only the runner may put it + // back, which is the whole point of the ref. + passStep: async (step) => { + passed.push(step); + return withPassed(ledger.current, [step]); + }, + complete: async () => { + throw new Error("429"); + }, + navigate, + }), + ).rejects.toThrow("429"); + // Q6 was never shown for a flow with no unit-bearing area, so it is + // passed on the ledger before the completion — and that write survived. + expect(passed).toEqual(["units"]); + expect(navigate).not.toHaveBeenCalled(); + }); + + it("does not pass a step the failed attempt already passed (M-j)", async () => { + const ledger = { current: state() }; + const passed: PassableStep[] = []; + const passStep = async (step: PassableStep) => { + passed.push(step); + return withPassed(ledger.current, [step]); + }; + let attempt = 0; + const complete = async () => { + attempt += 1; + if (attempt === 1) throw new Error("429"); + return { onboarding: ledger.current }; + }; + const navigate = vi.fn(); + + await expect( + runConfirmFinish({ ledger, passStep, complete, navigate }), + ).rejects.toThrow("429"); + await runConfirmFinish({ ledger, passStep, complete, navigate }); + + // "units" exactly once across both attempts; "first-result" is the + // second attempt's own pass, because these answers offer no task. + expect(passed).toEqual(["units", "first-result"]); + expect(navigate).toHaveBeenCalledTimes(1); + }); +}); diff --git a/src/components/onboarding/baseline-form.tsx b/src/components/onboarding/baseline-form.tsx index 3f0cdc266..5ff30b80f 100644 --- a/src/components/onboarding/baseline-form.tsx +++ b/src/components/onboarding/baseline-form.tsx @@ -71,6 +71,37 @@ interface BaselineFormState { gender: string; } +/** + * v1.39 (Wave C, C2) — one attempt at confirming, with the buttons always + * handed back. + * + * `advance()` used to raise its own pending flag and lower it again on two of + * the three exits: the refused-field return and its catch. The third exit — + * the success path, `await onConfirmed()` — never lowered it, and + * `onConfirmed` is the confirm screen's completion, which caught its own + * error and returned normally. So a failed completion disabled "Skip" and + * "Confirm and continue" for the rest of the page's life and only a reload + * recovered (research I10). + * + * The reset lives in a `finally` here, which is the one place it cannot be + * forgotten on a new exit, and the component has no other way to move the + * flag. + */ +export async function runBaselineAttempt( + setPending: (pending: boolean) => void, + attempt: () => Promise, + onError: (err: unknown) => void, +): Promise { + setPending(true); + try { + await attempt(); + } catch (err) { + onError(err); + } finally { + setPending(false); + } +} + export function BaselineForm({ initial, backHref, @@ -152,50 +183,50 @@ export function BaselineForm({ async function advance(opts: { saveProfile: boolean }) { if (saving || confirming) return; - setSaving(true); setFieldErrors({}); - try { - if (opts.saveProfile) { - const profileBody = buildBaselineProfileBody( - form, - heightAdapter.toCanonicalCm(form.height), - ); - if (Object.keys(profileBody).length > 0) { - const outcome = describeBaselineSaveOutcome( - await putBaselineProfile(profileBody), - t, - baselineFieldLabelKeys(heightAdapter.usesFeetInches), + await runBaselineAttempt( + setSaving, + async () => { + if (opts.saveProfile) { + const profileBody = buildBaselineProfileBody( + form, + heightAdapter.toCanonicalCm(form.height), ); - if (outcome.notice) { - const show = - outcome.notice.tone === "warning" ? toast.warning : toast.error; - show(outcome.notice.message); + if (Object.keys(profileBody).length > 0) { + const outcome = describeBaselineSaveOutcome( + await putBaselineProfile(profileBody), + t, + baselineFieldLabelKeys(heightAdapter.usesFeetInches), + ); + if (outcome.notice) { + const show = + outcome.notice.tone === "warning" ? toast.warning : toast.error; + show(outcome.notice.message); + } + if (!outcome.advance) { + // A field was refused. Staying on the step is the point — + // each refused input now says why under itself, the values + // the person typed are still in front of them, and the + // account is not stamped as set up over a value that never + // landed. + setFieldErrors(outcome.fieldErrors); + return; + } } - if (!outcome.advance) { - // A field was refused. Staying on the step is the point — - // each refused input now says why under itself, the values - // the person typed are still in front of them, and the - // account is not stamped as set up over a value that never - // landed. - setFieldErrors(outcome.fieldErrors); - setSaving(false); - return; - } - } - // Anamnesis — only write when the user actually filled a field - // (the helper returns null for an untouched card, so a - // collapsed card never round-trips). - const aboutMeBody = buildAnamnesisAboutMeBody(baseAboutMe, anamnesis); - if (aboutMeBody) { - await apiPut("/api/coach/about-me", aboutMeBody); + // Anamnesis — only write when the user actually filled a field + // (the helper returns null for an untouched card, so a + // collapsed card never round-trips). + const aboutMeBody = buildAnamnesisAboutMeBody(baseAboutMe, anamnesis); + if (aboutMeBody) { + await apiPut("/api/coach/about-me", aboutMeBody); + } } - } - await onConfirmed(); - } catch (err) { - toast.error(localizedApiError(err, t, "onboarding.errorGeneric")); - setSaving(false); - } + await onConfirmed(); + }, + (err) => + toast.error(localizedApiError(err, t, "onboarding.errorGeneric")), + ); } return ( diff --git a/src/components/onboarding/confirm-screen.tsx b/src/components/onboarding/confirm-screen.tsx index 9a0b053ca..8f55be3a5 100644 --- a/src/components/onboarding/confirm-screen.tsx +++ b/src/components/onboarding/confirm-screen.tsx @@ -1,6 +1,6 @@ "use client"; -import { useState } from "react"; +import { useRef, useState } from "react"; import Link from "next/link"; import { useRouter } from "next/navigation"; import { toast } from "sonner"; @@ -20,7 +20,13 @@ import { localeLabels } from "@/lib/i18n/config"; import { useTranslations } from "@/lib/i18n/context"; import { MODULE_REGISTRY } from "@/lib/modules/registry"; import { confirmedModules } from "@/lib/onboarding/confirm-summary"; -import type { OnboardingStateDto } from "@/lib/onboarding/needs"; +import { + ONBOARDING_SKIPPABLE_STEP_IDS, + type OnboardingStateDto, +} from "@/lib/onboarding/needs"; + +/** A step the confirm screen may pass on the ledger without an answer. */ +type PassableStepId = (typeof ONBOARDING_SKIPPABLE_STEP_IDS)[number]; import { firstResultApplies, nextScreen, @@ -51,6 +57,40 @@ import { * offer, otherwise done. When there is no task, the first-result step is * passed explicitly so the ledger reads as settled rather than owed. */ +/** + * v1.39 (Wave C, C2) — the completion sequence, apart from the component so + * a failure partway through it can be pinned without a browser. + * + * Passes every question the flow never showed (the route derives only once + * EVERY question is answered or passed, and a step nobody was asked cannot be + * answered), completes, passes the first-result step when there is no task to + * offer, and navigates. It reports a failure by THROWING — the caller owns the + * buttons and the toast. + */ +export async function runConfirmFinish(args: { + /** The ledger as the last write left it; updated in place as steps pass. */ + ledger: { current: OnboardingStateDto }; + managedRecordId?: string; + passStep: (step: PassableStepId) => Promise; + complete: ( + managedRecordId?: string, + ) => Promise<{ onboarding?: OnboardingStateDto | null }>; + navigate: (href: string) => void; +}): Promise { + for (const id of questionsToPassBeforeConfirm(args.ledger.current)) { + args.ledger.current = await args.passStep(id); + } + const { onboarding } = await args.complete(args.managedRecordId); + let written = onboarding ?? args.ledger.current; + if (!firstResultApplies(written)) { + // Nothing to offer, so the step is passed rather than left owed: a + // pending step would keep the setup reading as unfinished forever. + written = await args.passStep("first-result"); + } + args.ledger.current = written; + args.navigate(screenHref(nextScreen(written, "confirm") ?? "done")); +} + export function ConfirmScreen({ state }: { state: OnboardingStateDto }) { const { t, locale } = useTranslations(); const router = useRouter(); @@ -58,6 +98,17 @@ export function ConfirmScreen({ state }: { state: OnboardingStateDto }) { const complete = useOnboardingComplete(); const answer = useOnboardingAnswer(); const [finishing, setFinishing] = useState(false); + /** + * v1.39 (Wave C, C2) — the ledger as the last write left it (M-j). + * `finish()` sends one PATCH per question the flow never showed; a failure + * midway used to leave a partly-passed ledger that the next attempt walked + * from the top again, because the `state` prop it read was the one this + * screen was rendered with. Every mutation answers the written state, so + * the ref carries the progress across attempts and + * `questionsToPassBeforeConfirm` — which lists pending steps only — then + * skips what the failed attempt already passed. + */ + const ledger = useRef(state); const needs = state.needs; const forSomeoneElse = needs.recordTarget === "someone-else"; @@ -73,37 +124,39 @@ export function ConfirmScreen({ state }: { state: OnboardingStateDto }) { * after" just created: the route then applies the derivation to THAT * record and stamps this one complete without deriving, so the guardian's * own modules are never re-ordered around the child's answers. + * + * v1.39 (Wave C, C2) — this RETHROWS. `` owns the two + * buttons and releases them in its own `finally`, and it can only do that + * for a failure it is told about: the previous version caught, toasted and + * returned normally, which left both buttons disabled until a reload + * (research I10). The two managed-arm callers, which have no form around + * them, go through `finishReporting` below. */ async function finish(managedRecordId?: string) { if (finishing) return; setFinishing(true); try { - // A question this flow never showed — Q6 for somebody with no - // unit-bearing area — is passed on the ledger before the completion, - // because the route derives only once EVERY question is answered or - // passed, and a step nobody was asked cannot be answered. - for (const id of questionsToPassBeforeConfirm(state)) { - await answer.mutateAsync({ step: id, status: "skipped" }); - } - const { onboarding } = await complete.mutateAsync( - managedRecordId ? { managedRecordId } : undefined, - ); - let written = onboarding ?? state; - if (!firstResultApplies(written)) { - // Nothing to offer, so the step is passed rather than left owed: - // a pending step would keep the setup reading as unfinished forever. - written = await answer.mutateAsync({ - step: "first-result", - status: "skipped", - }); - } - router.push(screenHref(nextScreen(written, "confirm") ?? "done")); + await runConfirmFinish({ + ledger, + managedRecordId, + passStep: (step) => answer.mutateAsync({ step, status: "skipped" }), + complete: (id) => + complete.mutateAsync(id ? { managedRecordId: id } : undefined), + navigate: (href) => router.push(href), + }); } catch (err) { - toast.error(localizedApiError(err, t, "onboarding.errorGeneric")); setFinishing(false); + throw err; } } + /** The managed arm's two buttons: nothing above them reports a failure. */ + function finishReporting(managedRecordId?: string) { + void finish(managedRecordId).catch((err) => { + toast.error(localizedApiError(err, t, "onboarding.errorGeneric")); + }); + } + const moduleNames = (keys: readonly (keyof typeof MODULE_REGISTRY)[]) => keys.map((key) => t(MODULE_REGISTRY[key].labelKey)).join(", "); @@ -196,7 +249,7 @@ export function ConfirmScreen({ state }: { state: OnboardingStateDto }) { void finish(profile.id)} + onCreated={(profile) => finishReporting(profile.id)} />

{t("onboarding.flow.confirm.managedLater")}

@@ -212,7 +265,7 @@ export function ConfirmScreen({ state }: { state: OnboardingStateDto }) {
@@ -241,12 +259,18 @@ export function ConfirmScreen({ state }: { state: OnboardingStateDto }) { ) : null}

- - {t("onboarding.flow.confirm.changeInSettings")} - + {settingsReachable ? ( + + {t("onboarding.flow.confirm.changeInSettings")} + + ) : ( + + {t("onboarding.flow.confirm.changeInSettings")} + + )}

{forSomeoneElse ? ( From 982c35287db0f5190e33211846b042c7a0cba657 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Fri, 11 Sep 2026 09:26:10 +0200 Subject: [PATCH 6/7] fix(demo): the setup flow's baseline writes are allowlisted A demo visitor who typed a height on the confirm screen got a 403 and a generic toast, and the "someone I look after" arm could only take "Finish without the profile": the profile PUT, the self-context PUT and the managed-profile POST were missing from the demo allowlist, so only the empty-form path completed. All three are added, pinned per method as the rest of the list is. None of them creates health data. --- .../proxy-demo-mode-allowlist.test.ts | 30 +++++++++++++++++++ src/proxy.ts | 13 ++++++++ 2 files changed, 43 insertions(+) diff --git a/src/__tests__/proxy-demo-mode-allowlist.test.ts b/src/__tests__/proxy-demo-mode-allowlist.test.ts index d51c61082..0f7a6af0d 100644 --- a/src/__tests__/proxy-demo-mode-allowlist.test.ts +++ b/src/__tests__/proxy-demo-mode-allowlist.test.ts @@ -106,6 +106,36 @@ describe("proxy.ts DEMO_MODE mutation allowlist", () => { expect(missing, "onboarding writes the demo cannot make").toEqual([]); }); + it("permits the baseline writes the confirm screen makes (M-m)", () => { + // v1.39 (Wave C, C6) — a demo visitor who typed a height got a 403 and a + // generic toast, and "someone I look after" could only take "Finish + // without the profile": the three writes the confirm screen makes were + // not on the list. None of them is health data — the account's own + // profile fields, the encrypted self-context the anamnesis card writes, + // and the managed record the flow's guardian arm creates. + for (const [path, method] of [ + ["/api/auth/profile", "PUT"], + ["/api/coach/about-me", "PUT"], + ["/api/managed-profiles", "POST"], + ] as const) { + expect( + proxy(makeRequest(path, method)).status, + `${method} ${path} is blocked in the demo`, + ).not.toBe(403); + } + }); + + it("does not drag in a sibling verb on the baseline paths", () => { + expect(proxy(makeRequest("/api/auth/profile", "DELETE")).status).toBe(403); + expect(proxy(makeRequest("/api/managed-profiles", "DELETE")).status).toBe( + 403, + ); + // The per-profile routes are a different path and stay closed. + expect( + proxy(makeRequest("/api/managed-profiles/abc", "DELETE")).status, + ).toBe(403); + }); + it("still blocks a health-data mutation (POST /api/measurements)", () => { const res = proxy(makeRequest("/api/measurements", "POST")); expect(res.status).toBe(403); diff --git a/src/proxy.ts b/src/proxy.ts index 5184878e7..b73d8c3ed 100644 --- a/src/proxy.ts +++ b/src/proxy.ts @@ -174,6 +174,19 @@ const DEMO_MUTATION_ALLOWLIST: ReadonlyArray<{ path: string; method: string }> = // Neither creates health data. { path: "/api/onboarding/disclaimer", method: "POST" }, { path: "/api/onboarding/tour", method: "POST" }, + // v1.39 (Wave C, C6) — the three writes the confirm screen makes. Without + // them a demo visitor who typed a height got a 403 and a generic toast, + // and the "someone I look after" arm could only take "Finish without the + // profile" — only the empty-form/Skip path completed, so the demo did not + // in fact walk the same flow (design spec §Principles 5). None of the + // three creates health data: the caller's own profile fields, the + // encrypted self-context behind the optional anamnesis card, and the + // managed record the guardian arm of the flow exists to create. The + // per-profile routes (`/api/managed-profiles/{id}`, its guardians) are + // different paths and stay closed. + { path: "/api/auth/profile", method: "PUT" }, + { path: "/api/coach/about-me", method: "PUT" }, + { path: "/api/managed-profiles", method: "POST" }, ]; // Legacy route redirects (German → English) From bda18f9e2d863e0a9e764ff795c76db593ba5222 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Fri, 11 Sep 2026 09:35:17 +0200 Subject: [PATCH 7/7] test(profile): the edge proxy is not a profile submitter The demo allowlist names a path and a method as data, which reads to the submitter matcher exactly like a request expression. proxy.ts submits nothing and has no answer to read, so it is excluded by name. --- .../profile-rejection-surface-guard.test.ts | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/src/__tests__/profile-rejection-surface-guard.test.ts b/src/__tests__/profile-rejection-surface-guard.test.ts index 7bed465fd..e18fec0d0 100644 --- a/src/__tests__/profile-rejection-surface-guard.test.ts +++ b/src/__tests__/profile-rejection-surface-guard.test.ts @@ -31,12 +31,19 @@ const SRC = join(process.cwd(), "src"); const PROFILE_ROUTES = ["/api/auth/profile", "/api/user/profile"]; function sourceFiles(): string[] { - return walkSourceFiles(SRC, { floor: 3000 }) - .filter((p) => !p.startsWith("generated/")) - .filter((p) => !p.startsWith("app/api/")) - .filter((p) => !p.includes("__tests__")) - .filter((p) => !p.endsWith(".test.ts") && !p.endsWith(".test.tsx")) - .sort(); + return ( + walkSourceFiles(SRC, { floor: 3000 }) + .filter((p) => !p.startsWith("generated/")) + .filter((p) => !p.startsWith("app/api/")) + // v1.39 (Wave C, C6) — the edge proxy names routes and methods as DATA + // (the demo-mode mutation allowlist is a list of path/method pairs), and + // a pair reads to the matcher below exactly like a request expression. It + // submits nothing and has no answer to read. + .filter((p) => p !== "proxy.ts") + .filter((p) => !p.includes("__tests__")) + .filter((p) => !p.endsWith(".test.ts") && !p.endsWith(".test.tsx")) + .sort() + ); } function read(rel: string): string {