Register the schemas that annotated themselves into nothing

[MBombeck]

Sixty-four annotations in the OpenAPI registry named a schema and registered nothing.

In Zod 4 .meta() clones the schema and registers the clone, so a bare statement that discards the return value is a no-op:

loginPasswordSchema.meta({ id: "LoginPasswordRequest", ... });        // registers nothing
const LoginPasswordRequest = loginPasswordSchema.meta({ ... });       // registers

The failure is invisible from the registry side, because the annotation looks correct and the document still builds. It shows only in the emitted file: MeasurementType, MeasurementSource, LoginPasswordRequest, CreateMeasurementRequest, ListMeasurementsQuery and CreateBatchWorkoutRequest appeared zero times under components.schemas, while the one schema that was force-registered by hand appeared once.

What it cost: the schemas inlined anonymously at every use site, and the descriptions written for them were never published at all. A client generated from this contract got a nameless duplicate type per operation instead of one named model, which is the opposite of why the contract is published.

What changed

Seventy-seven calls converted to the assigning form, use sites repointed. Where a schema comes from src/lib/validations/* the import is untouched and the annotated clone takes a new name, so the runtime validator is never mutated.

The seven in shared.ts had no use site in shared.ts at all: their consumers are eight other modules, which now import the annotated clones. Without that step none of them could ever have registered.

Sixty-three new named components in the emitted document, none removed. MoodTagLayout needed the same forced registration as Medication and CoachPrefs — its annotation was already correct, but both consumers .extend() the base, and .extend() builds a new object rather than a reference.

Verified rather than eyeballed

The document diff is three thousand lines, so both halves were checked by fully dereferencing every $ref in the baseline and in the regenerated file and deep-comparing the resolved paths trees.

The result across every affected path: 116 added description strings and nothing else. No property, type, enum, required, format or array-length difference anywhere, no path added or removed, no pre-existing component removed. Those descriptions are exactly the text the bare calls had been throwing away.

Findings

Two published descriptions were factually wrong. HealthRecordExportRequest and CreateShareLinkRequest both described a sections field that neither schema has — the export route refuses it explicitly, and the share link freezes scope through selection plus documentIds / documentOnly. Wiring them as written would have published a lie, so both are corrected to what the routes take. Both were also annotated in a module that imported the schemas for no other purpose and never referenced them; they now live beside the operations that send them.

Six apparent hits were not defects. The record-settings.ts calls sit inside a z.union([...]) argument list, where the returned clone is the union member, so they always worked. Verified against the committed spec: all six ids were already published.

Three annotations were dead twice. Two named ids for a query the route does not publish (it merges both modes into one hand-written query), and one named a query whose parameters are hand-written because it carries a cross-field .refine() the expansion cannot express. No use site to wire, and keeping them as unused exports turned knip red. Every clause of their text is already published on the operations, so nothing left the contract.

Twelve ids legitimately never reach components.schemas and are left in the assigning form for consistency: they annotate requestParams.query objects, which the emitter expands into inline parameters. Every pre-existing query id behaves the same way.

Gates: typecheck, lint, format:check, knip, openapi:check, 21,551 unit tests and the production build, all green.