fix(client): organizations.invitations.resend forwards teamId, so resending a team invitation keeps its team - #18429

Fixes #17274

Clause-②: yes (widening) — organizations.invite gains a teamId member on its published request type. Nothing is narrowed: every existing call still compiles and still sends byte-identical requests.

The defect

organizations.invitations.resend has declared teamId?: string | null since the organizations.* family's first commit (371445c27, 2026-05-07) and has never forwarded it. The re-invite it issues carried email, role and organizationId only, so a caller resending a TEAM invitation passed the team, the compiler accepted it, the request succeeded — and the invitation landed with no team. Nothing refused, nothing warned, and the success path carried no trace of the loss.

Which repair this is, and the measurement that decided it

The card left the direction open between forwarding the member and deleting it, and required the endpoint to be DRIVEN rather than read off the vendor's types. Driven here: a real AuthManager (better-auth 1.7.3, organization plugin, teams: { enabled: true } — the posture auth-manager.ts:2921 hard-wires) over a real ObjectQL on a real SqliteWasmDriver, with the SDK's own fetch handing each Request to AuthManager.handleRequest.

Row 1 settles the direction: FORWARD IT. The endpoint accepts a team on this call, the handler validates the id against the organisation's own teams, and the adapter stores the placement on the invitation row where invitations.list reads it back. Removing the member would have deleted a capability the wire really has.

Why it is not forwarded verbatim — rows 3 and 4

null is this SDK's own spelling of "no team": invitations.list answers teamId: string | null, and handing that object straight back into resend is the ordinary way to resend. The vendor's spelling of the same fact is ABSENCE.

A bare spread would therefore put teamId: null on the wire and convert today's SILENT drop into a LOUD 400 for every caller who ever read an invitation back out of list() — a second defect wearing the fix's clothes. So invite lifts teamId out of the spread and sends it only when it is a string; null and an omitted member both send no teamId at all.

Nothing else is normalised. An unknown id keeps reaching the vendor, because TEAM_NOT_FOUND is exactly the loud refusal that replaces the silent drop.

What changed

• organizations.invite declares teamId?: string | null and lifts it out of the body spread. It is the only route resend has to the wire, so declaring the member is what lets the placement be typed rather than smuggled through an undeclared property.
• organizations.invitations.resend forwards teamId.
• resend stops spelling its own role ?? 'member' and takes invite's default instead. This is the behaviour-neutral tidy-up the card names, taken deliberately: one family, one substitution, no second copy to drift. An omitted or explicitly-undefined role still reaches the wire as 'member', in the same byte position, and a caller-named role still survives — pinned by case ④d.
• The sibling #16582 docblock sentence that asserted resend substitutes its own default is corrected in the same edit, because this change is what makes it false.

Reverse verification — the pins fail on BOTH wrong answers

The fix was committed first, each leg mutated the file on disk, proved the mutation landed by counting its own anchors and comparing git hash-object against the HEAD blob, ran, then restored and proved the restore by blob equality plus an empty git diff HEAD. No dist is in the resolution path: the suite imports ./index relatively, inside its own package, so the bytes under test are the source bytes in this checkout.

Leg B is the one the card asked for: a pin that fails on the wrong fix rather than merely passing on the right one. Case ③ throws Error: [body.teamId] Invalid input against the real vendor, and ④b reads

Expected: {"email":"probe@example.com","role":"member","organizationId":"org_probe"}
Received: {"email":"probe@example.com","role":"member","organizationId":"org_probe","teamId":null}

Every byte case is FULL-STRING equality, never a containment check: the drive proves the vendor accepts what we send and is structurally blind to a body carrying MORE than it should, which is exactly how a stray null gets through.

The family question the card asked — answered, and the PR deliberately not widened

#14314 did NOT miss this member, and the member was not added after it.

• teamId on resend arrived in 371445c27 (2026-05-07), the commit that first created the whole organizations.* SDK surface.
• #14314 landed four months later as 7092d63e4 (2026-09-07, PR #16576), and its axis was the RESPONSE: nineteen Promise of any returns bound to the shapes better-auth sends. Its own changeset says so in this repo's tree — "No request bytes, no URL and no response handling change" — and names resend explicitly as closing because it delegates to invite, "not named here because its site is unchanged".
• The route ledger, the other binding artifact, carries route, family, source, disposition, client, requires and an optional responseSchema. There is no request-member relation anywhere in it.

So: REQUEST-member fidelity across the organizations.* family has never had a binding artifact, which is why both #16582 and this card had to be found by hand. That is a coverage observation, not a defect in this method, and per the dispatch this PR does not re-audit the other seventeen.

One note for whoever follows it up: issue #14314 itself now answers 404 on this board through the REST API, while #16582 answers 200 through the same token and endpoint — so the commit and its changeset in this tree, cited above, are the surviving record.

Verification

• pnpm --filter @objectstack/client test — 44 files, 534 passed.
• pnpm --filter @objectstack/client typecheck — clean, including check:test-typecheck over tsconfig.test.json, which is what compiles case ⑤'s type-level pins.
• pnpm --filter "@objectstack/client^..." build — the dependency closure, exit 0. pnpm build (73 tasks) exit 0.
• pnpm lint — repo-wide eslint . --no-inline-config, exit 0. No narrowing was needed.
• Gate families derived from the ACTUAL changed paths with node scripts/pm/dispatch-gates.mjs --commands, each run with its exit code written to disk before anything read it, then reconciled: 61 derived, 61 run, 0 NOT-MEASURED, 0 UNRUN, all green except the one below.
• packages/client has no integration tier in this diff's reach: test:integration is a separate script against a live server and is not part of pnpm test; nothing here touches a spawn entry point.

⚠️ One red, pre-existing and not this PR's: pnpm check:cross-package-test-inputs exits 1 on any tree where packages/spec/dist is built. It names packages/cli/test/init-created-files-summary.e2e.test.ts descending packages/spec/dist/ — neither path is in this diff. Already filed as #18353 / #18348; no fourth card.

Acceptance notes

Observed while measuring, deliberately NOT filed and NOT fixed here:

• The vendor accepts teamId as a string ARRAY as well as a string, and stores the ids comma-joined. This SDK declares only string | null, which is what every shape in the family uses (invitations.list answers teamId?: string | null) and all that is delivered here. Declaring the array form is a capability decision, not a defect.
• The vendor accepts teamId: '' with a 200 and stores the empty string verbatim: its validation is guarded on truthiness, so an empty id skips the TEAM_NOT_FOUND check entirely. The SDK forwards what the caller declared rather than inventing a meaning for it. Vendor-side, and a reading only.
• better-auth's own body schema carries a resend?: boolean flag on invite-member that re-sends to an already-invited address instead of refusing it. This SDK implements resend as cancel-then-invite instead. Both work; the difference is deliberate and untouched.

This PR parks, by declaration

The dispatching seat measured itself below CONTRACT_REVIEW_TIER and therefore may not perform the clause-② review, which was declared up front on the card rather than discovered at the enqueue gate. This PR waits outside the merge queue until a tier-qualified seat clears it. That is a seat limitation, and no scope was cut for it.

needs:contract-review is the seat's to apply or remove; this branch neither applied nor removed it, and its state at hand-off is reported in the delivery comment on #17274.

Generated by Claude Code