## Linked issue

n/a — small change

## At a glance

```ts
userCollection.upsert({
  create: {
    id: 'user_001',
    name: 'Alice',
    email: 'alice@example.com',
    active: true,
    metadata: {},
    // @ts-expect-error upsert create does not support relation callbacks
    posts: createNestedPosts,
  },
  update: { name: 'Alice Updated' },
})
```

Before this change, relation callbacks typechecked in `upsert.create`
and the batch-create APIs even though those paths do not execute the
nested mutation graph.

## Decision

This PR makes `upsert({ create })`, `createAll()`, and
`createAndCount()` accept only scalar create fields while preserving
relation callbacks for ordinary `create()` calls. The scalar input
resolves namespace and polymorphic variant fields in the same way as the
existing relation-enabled create input.

## Reviewer notes

- This is a compile-time correction: calls that supplied nested relation
callbacks to `upsert.create`, `createAll()`, or `createAndCount()` now
fail typechecking instead of promising unsupported behavior.
- The negative test first types `createNestedPosts` as a valid relation
callback, ensuring its `@ts-expect-error` guards the rejected `posts`
property rather than an incidental callback-parameter error.
- Nested relation execution inside upsert remains a separate feature
requiring transactional branch-aware mutation orchestration.

## How it fits together

1. [`types.ts`](packages/3-extensions/sql-orm-client/src/types.ts)
extracts the scalar field composition from `CreateInput`; `CreateInput`
continues adding relation mutation fields for supported create
operations.
2. `ResolvedScalarCreateInput` applies the existing polymorphic
discriminator and variant-field rules without adding relation fields.
3.
[`collection.ts`](packages/3-extensions/sql-orm-client/src/collection.ts)
uses that scalar-only type for `upsert().create`, `createAll()`,
`#createAllWithAnnotations()`, and `createAndCount()`, including the
collection namespace state.
4.
[`generated-contract-types.test-d.ts`](packages/3-extensions/sql-orm-client/test/generated-contract-types.test-d.ts)
proves scalar inputs remain accepted by upsert and batch creates while
nested relation callbacks are rejected.

## Behavior changes & evidence

- **Nested relation callbacks under `upsert.create`, `createAll()`, and
`createAndCount()` now produce `TS2353`.** The API restriction is
implemented in
[`types.ts`](packages/3-extensions/sql-orm-client/src/types.ts) and
[`collection.ts`](packages/3-extensions/sql-orm-client/src/collection.ts),
with regression coverage in
[`generated-contract-types.test-d.ts`](packages/3-extensions/sql-orm-client/test/generated-contract-types.test-d.ts).
- **Nested relation callbacks under ordinary `create()` remain
supported.** The relation-enabled `CreateInput` is preserved, and the
existing nested-post create assertion in
[`generated-contract-types.test-d.ts`](packages/3-extensions/sql-orm-client/test/generated-contract-types.test-d.ts)
continues to pass.

## Testing performed

- `pnpm typecheck` in `packages/3-extensions/sql-orm-client`
- `pnpm test` in `packages/3-extensions/sql-orm-client` — 70 files and
771 tests passed; no type errors
- `pnpm build` in `packages/3-extensions/sql-orm-client`
- `pnpm lint` in `packages/3-extensions/sql-orm-client` — passed with 15
pre-existing informational bare-cast findings
- `pnpm lint` — 99 tasks passed
- `pnpm typecheck` — 166 tasks passed
- `pnpm lint:skills`
- `pnpm check:upgrade-coverage --mode pr --prev origin/main`
- `git diff --check`

## Skill update

Adds the `remove-nested-relations-from-sql-orm-upsert-and-batch-create`
entry to
[`skills/prisma-8/upgrading/extension/upgrades/8.0.0-rc.8-to-8.0.0-rc.9/`](skills/prisma-8/upgrading/extension/upgrades/8.0.0-rc.8-to-8.0.0-rc.9/),
instructing extension authors to remove unsupported relation callbacks
or use ordinary `create()` for nested relation creation.

## Alternatives considered

- **Execute nested creates from upsert and batch creates.** This would
require branch-aware or per-row multi-statement transactional
orchestration and is larger than correcting the current false type
promise.
- **Omit relation keys directly from `ResolvedCreateInput`.** A
dedicated scalar composition keeps scalar requirements explicit and
preserves the existing namespace and polymorphic variant behavior
without depending on relation-key subtraction.

## Checklist

- [x] All commits are signed off (`git commit -s`) per the
[DCO](CONTRIBUTING.md#developer-certificate-of-origin-dco).
- [x] I read [CONTRIBUTING.md](CONTRIBUTING.md) and the change is scoped
to one logical concern.
- [x] Tests are updated.
- [x] The PR title follows the conventional-commit format documented in
`CONTRIBUTING.md`; no Linear ticket is attached to this small fix.
- [x] The **Skill update** section above is filled in.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Breaking Changes**
* `upsert()`, `createAll()`, and `createAndCount()` now accept scalar
fields only; nested relation callbacks are no longer supported in these
payloads.
* Use `create()` for nested relation creation, or create related records
separately.

* **Documentation**
  * Added upgrade guidance for migrating to the latest release.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: Steven McClankerton <tatarintsev@prisma.io>
Co-authored-by: Steven McClankerton <tatarintsev@prisma.io>