docs: comments name what the code does, not how it was built

Thirty-one files carried internal build vocabulary and anchors pointing at
notes that are not in the repository: a reader of `checklist.ts` in a year
would find its rationale keyed to a research id they cannot open, inside a
comment that also names an internal build stage. Two test titles carried the
same anchors.

The version tags and the whole of the reasoning stay; only the vocabulary and
the dangling references go, with the few sentences that were built around an
anchor rewritten to stand on their own.

src/components/onboarding/__tests__/confirm-failure-recovery.test.ts

@@ -1,16 +1,16 @@
 /**
- * v1.39 (Wave C, C2) — a failed completion leaves the confirm screen usable.
+ * v1.39 — 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).
+ * page's life and only a reload recovered.
  *
  * 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).
+ * ledger that the next attempt walked from the top again.
  *
  * Both are pinned at the seam the component drives, because this repo's
  * component tests render server-side and cannot click.
@@ -127,7 +127,7 @@ describe("runConfirmFinish", () => {
     expect(navigate).not.toHaveBeenCalled();
   });
 
-  it("does not pass a step the failed attempt already passed (M-j)", async () => {
+  it("does not pass a step the failed attempt already passed", async () => {
     const ledger = { current: state() };
     const passed: PassableStep[] = [];
     const passStep = async (step: PassableStep) => {

src/components/onboarding/__tests__/confirm-screen.test.tsx

@@ -1,13 +1,13 @@
 /**
- * v1.39 (Wave C) — what the confirm screen is allowed to claim.
+ * v1.39 — what the confirm screen is allowed to claim.
  *
- * C5 (research M-l): both of the screen's own Settings links are page routes,
+ * Both of the screen's own Settings links are page routes,
  * and `hl_onboarding=pending` is still set while this screen is on — the
  * completion is what clears it, and this screen is what calls the completion.
  * The proxy sends both straight back to the flow, so on a first run they are
  * dead links under a sentence that is not yet true.
  *
- * C4 (research I6): the screen listed what the answers switch ON and said
+ * The screen listed what the answers switch ON and said
  * everything else "stays one click away under Settings, Modules" — true of
  * reachability, false of the navigation entry. A module the answers do not
  * ask for leaves the navigation, and nothing said so.
@@ -75,7 +75,7 @@ function render(
   );
 }
 
-describe("<ConfirmScreen> — modules leaving the navigation (C4)", () => {
+describe("<ConfirmScreen> — modules leaving the navigation", () => {
   it("names them when the answers do not ask for what the record shows", () => {
     const html = render(state({}, { areas: ["sleep"], medication: "no" }), {
       medications: true,
@@ -111,7 +111,7 @@ describe("<ConfirmScreen> — modules leaving the navigation (C4)", () => {
   });
 });
 
-describe("<ConfirmScreen> — Settings links on a first run (C5)", () => {
+describe("<ConfirmScreen> — Settings links on a first run", () => {
   it("renders both as plain text while the completion has not run", () => {
     const html = render(state());
     expect(html).not.toContain('href="/settings/modules"');

src/components/onboarding/__tests__/done-screen.test.tsx

@@ -150,7 +150,7 @@ describe("<DoneScreen> AI panel", () => {
 });
 
 /**
- * v1.38.19 (wave D) — the shared provider, offered only when it works.
+ * v1.38.19 — the shared provider, offered only when it works.
  *
  * The card used to read `managedBy === "server"` and promise that insights
  * "work for you right now". That is a presence read: it knew a key was

src/components/onboarding/__tests__/first-result-screen.test.tsx

@@ -1,5 +1,5 @@
 /**
- * v1.38.19 (wave B / C1, C2, I1, I2, I3) — the connect arm of the one task
+ * v1.38.19 — the connect arm of the one task
  * the flow ends on.
  *
  * This arm is the only place in the flow that renders a claim about real
@@ -202,7 +202,7 @@ describe("<FirstResultScreen> — the connect arm", () => {
   });
 
   /**
-   * v1.38.19 (wave B / I1) — the heading is chosen from the answers alone on
+   * v1.38.19 — the heading is chosen from the answers alone on
    * the server, because no status is in hand there. Once the envelope has
    * resolved the screen re-picks: a source that is already delivering is not
    * a task, and "Connect WHOOP" over a WHOOP that has been feeding the

src/components/onboarding/__tests__/getting-started-checklist.test.tsx

@@ -1,5 +1,5 @@
 /**
- * v1.39 (Wave C, C1) — the checklist's data queries follow the same rule as
+ * v1.39 — the checklist's data queries follow the same rule as
  * its visibility.
  *
  * `shouldShowChecklist` gained `hasEnteredOnboardingFlow` as a third
@@ -7,7 +7,7 @@
  * 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).
+ * account had already done.
  *
  * Rendered SSR-only, per this repo's component-test convention. `useQuery` is
  * mocked to honour `enabled` exactly the way tanstack does — a disabled query

src/components/onboarding/__tests__/units-screen.test.tsx

@@ -1,5 +1,5 @@
 /**
- * v1.39 (Wave C, C3) — Q6 cannot be answered with nothing chosen (M-k).
+ * v1.39 — Q6 cannot be answered with nothing chosen.
  *
  * "Weiter" used to be live on an untouched units screen: it wrote
  * `{ units: {} }`, which marked the step DONE without recording a preference,

src/components/onboarding/baseline-form.tsx

@@ -72,7 +72,7 @@ interface BaselineFormState {
 }
 
 /**
- * v1.39 (Wave C, C2) — one attempt at confirming, with the buttons always
+ * v1.39 — 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
@@ -81,7 +81,7 @@ interface BaselineFormState {
  * `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).
+ * recovered.
  *
  * 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

src/components/onboarding/confirm-screen.tsx

@@ -59,7 +59,7 @@ import {
  * passed explicitly so the ledger reads as settled rather than owed.
  */
 /**
- * v1.39 (Wave C, C2) — the completion sequence, apart from the component so
+ * v1.39 — 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
@@ -112,7 +112,7 @@ export function ConfirmScreen({
   const answer = useOnboardingAnswer();
   const [finishing, setFinishing] = useState(false);
   /**
-   * v1.39 (Wave C, C2) — the ledger as the last write left it (M-j).
+   * v1.39 — the ledger as the last write left it.
    * `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
@@ -125,7 +125,7 @@ export function ConfirmScreen({
 
   const needs = state.needs;
   /**
-   * v1.39 (Wave C, C5) — is `hl_onboarding=pending` still set? (research M-l)
+   * v1.39 — is `hl_onboarding=pending` still set?
    *
    * Both of this screen's Settings links are page routes, and the cookie is
    * cleared by the completion — which is what THIS screen calls. So on a
@@ -161,12 +161,12 @@ export function ConfirmScreen({
    * 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. `<BaselineForm>` owns the two
+   * v1.39 — this RETHROWS. `<BaselineForm>` 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.
+   * returned normally, which left both buttons disabled until a reload.
+   * The two managed-arm callers, which have no form around them, go through
+   * `finishReporting` below.
    */
   async function finish(managedRecordId?: string) {
     if (finishing) return;

src/components/onboarding/done-screen.tsx

@@ -35,7 +35,7 @@ interface AiProviderStatus {
   /** Origin of the provider that would serve this user, if any. */
   managedBy?: "user" | "local" | "server" | null;
   /**
-   * v1.38.19 (wave D) — the instance-wide tri-state. Fail closed for the
+   * v1.38.19 — the instance-wide tri-state. Fail closed for the
    * offer: neither `unhealthy` nor `unknown` earns one. Only `unhealthy` is
    * a verdict this screen may state out loud.
    */
@@ -112,7 +112,7 @@ export function DoneScreen({ state }: { state: OnboardingStateDto }) {
     router.push("/");
   }
 
-  // ── v1.38.19 (wave D) — the shared provider, offered only when it works ──
+  // ── v1.38.19 — the shared provider, offered only when it works ──
   //
   // This block used to be one line: `managedBy === "server"` painted a note
   // reading "insights work for you right now — no setup needed". Both halves

src/components/onboarding/getting-started-checklist.tsx

@@ -246,12 +246,12 @@ export function GettingStartedChecklist() {
   // 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
+  // v1.39 — 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).
+  // network-backed row frozen at "not done".
   const checklistRelevant =
     !!user &&
     !dismissedAll &&