chore: sync the spec and regenerate response types

[AminChirazi]

spec/openapi.json was vendored before the API's response-typing work: 209 of its 239 operations described no response body.

That is not a cosmetic gap. openapi-typescript turns a bodyless operation into responses: never, and extracting a 200 body out of that infers unknown — so most of this SDK's surface typed its return values as unknown, which is precisely the drift the 1.0 rewrite existed to end.

Copied the current spec from datamaker@next and ran pnpm generate.

What changes

	before	after
operations with a typed response	30 / 239	209 / 240
components["schemas"]	15	123

• 178 operations gain a real response type.
• GET /scenarios/jobs is new.
• Additive only. All 15 pre-existing schemas are byte-identical, so nothing that compiles today stops compiling. Hence minor, not major.

Verification

Beyond the four CI steps, I wrote a type-level proof (scratch, not committed) and — importantly — checked it wasn't vacuous.

A naive assertion here is worthless: both unknown and never swallow a loose assignability check, so const x: Body<...> = {...} passes against the old schema too. My first attempt at this proof did exactly that and told me nothing. The real proof asserts exact type identity:

type Exact<X, Y> = (<T>() => T extends X ? 1 : 2) extends <T>() => T extends Y ? 1 : 2 ? true : false;
type Assert<T extends true> = T;

It confirms:

1. GET /scenarios yields exactly Scenario[].
2. The environment-variable asymmetry survives generation — GET is {key, value}[], the writes are a Record<string, string>. Had those been collapsed into one schema upstream, exactly one of these two assertions would fail.
3. PlanRun["files"] is PlanRunFile[] | undefined — optional, not nullable.
4. /export/rest, still deliberately bodyless upstream, resolves to unknown — which is the mechanism this whole PR is about, demonstrated rather than asserted.

Run against the old schema, assertions 1–3 all fail. Assertion 4 passes against both, correctly, since that route is bodyless in each.

• pnpm generate:check — generated types match the spec
• pnpm lint (tsc) — clean
• pnpm test — 11/11
• pnpm build — ESM + CJS + DTS

Scope — what this does not do

It widens the exported paths and components types, which consumers can use directly. It does not add methods to the resource clients: dm.projects, dm.templates, dm.sets, dm.keymaps, dm.maskingPolicies and dm.plans still cover exactly what they covered before, because resources.ts hand-picks the schemas it exposes. There are now 108 more schemas available to build against; wiring them into ergonomic clients is a separate, larger piece of work worth its own PR.

Still unknown, on purpose

31 operations remain deliberately untyped upstream: the 22 Tosca/Jira/SAP pass-throughs, whose bodies belong to those systems rather than to DataMaker, and 9 routes that return credentials and are kept out of the published contract (automators-com/datamaker#2882, #2916, #2919). The API now has a CI ratchet (automators-com/datamaker#2922) that stops any new operation from shipping bodyless, so this gap should not reopen.

datamaker-py needs the same backfill and has not had it.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.