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

take()/skip()/cursor()/distinct()/distinctOn()/orderBy() before groupBy()
now route through buildAggregateInput, the same row-scoping wrap root
aggregates use, instead of being silently dropped. aggregateInputColumns
gains a groupByColumns parameter so the wrap's projection also carries
the group-key columns GROUP BY needs, seeded via a default so the root
aggregate call site is untouched.

Rewrites the grouped it.fails case in aggregate-pagination.test.ts
against the real compiled shape and adds an integration test proving
the group-key-projection gap: without it, GROUP BY resolves against a
column absent from the wrap and the query errors outright.

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

Post-group clauses page the groups themselves: ORDER BY / LIMIT / OFFSET
applied to compileGroupedAggregate's own select, no wrap needed since
grouping already collapsed the rows. orderBy() orders by group key only
(Pick<ModelAccessor, GroupFields[number]>) — ordering by an aggregate
alias needs its own builder surface and stays out of scope.

Kept as a separate GroupPagingState field on GroupedCollection, never
merged with the pre-group CollectionState — that merge is the defect
this shape exists to prevent. A shape test drives both positions in one
chain with different take() values and asserts each lands in its own
place; two integration tests cover having() present at both positions,
one asserting the emitted clause order (GROUP BY, HAVING, ORDER BY,
LIMIT).

Not this dispatch: the type-state gate requiring orderBy() before
take()/skip() on the grouped collection.

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

GroupedCollection gains a fifth type parameter, HasOrderBy, mirroring
the hasOrderBy flag Collection's own cursor() gate already reads
(collection.ts:865-869). orderBy() returns the collection with it set
to true; take()/skip() narrow their parameter to `never` unless it is,
so an unordered post-group take()/skip() is a compile error rather
than a runtime surprise — a database may return groups in any order,
so "page 2 of the groups" is undefined without one.

skip() is gated the same as take(), not left open: at the root
position skip() without take() is well-defined (slice 1's "reduce all
but the first n"), but that reasoning doesn't transfer to the grouped
position, where there's no such thing as "the first n groups" without
an ordering either. Prisma pairs skip/take with orderBy on groupBy for
the same reason.

The gate is a pure type-state addition — no runtime field changes, no
existing runtime expectation moved. Asserted with @ts-expect-error in
a new grouped-pagination-gate.test-d.ts, positive and negative cases
both covered, mirroring the shape distinct-on-capability.test-d.ts
already uses for slice 1's distinctOn gate.

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

Both grouped positions now assert real query results against a live
database on both targets, not just compiled-plan shape.

Postgres: adds a bare post-group orderBy()/take() case (group-by.test.ts)
alongside D2/D3's existing pre-group and having()-entangled post-group
cases, so the post-group cell has an unambiguous values test of its own.

SQLite: extends aggregate-sqlite.test.ts (the harness slice 1 already
established, reused rather than inventing a second approach) with a
groupBy describe block covering pre-group scoping, post-group paging,
and both positions in a single chain with different limits.

Every case seeds rows where the scoped/paged answer differs from the
unscoped/unpaged one, per the slice's values-not-shape lesson.

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

compileGroupedAggregate has never taken a modelName, so a grouped
aggregate on an MTI variant (.variant('Feature').groupBy(...)) dropped
the variant table's join in both branches, wrapped and unwrapped —
verified pre-existing back to before this slice's D1 (no join handling
in either branch at the commit right before slice 1 merged either).

Threads modelName through the same way compileAggregate does: resolves
polyInfo/variantJoins via resolvePolymorphismInfo/buildMtiJoins and
passes modelName into buildAggregateInput for the wrapped path, adds
withJoins(variantJoins) to the pass-through path. GroupedCollection's
aggregate() now passes this.modelName.

Covered by three failing-first tests in
variant-include.query-plan-aggregate.test.ts: a variant-owned filter
reaching the join wrapped by a pre-group scoping clause, the same
unwrapped with no scoping clause, and an STI variant still adding no
join (unchanged, no MTI variant table to join).

Also drops the three-line comment above the groupBy describe in
aggregate-sqlite.test.ts explaining distinctOn's absence — an absence
doesn't need documenting.

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

Delivers the project's last un-owned DoD item (docs half only — the
TSDoc half was explicitly refused per operator direction in spec.md).

Adds docs/reference/ORM Collection Chaining.md — no ORM chaining guide
existed, so this is a new one, scoped tightly to the position-semantics
rule (pagination before groupBy() scopes rows, after it pages groups)
rather than a full API reference, following Mongo Pipeline Builder.md's
conventions for tone and shape.

Adds docs/releases/v8.0.0-rc.5.md, hand-authored per the process
docs/releases/README.md documents for pre-cut entries, covering both
halves of the project: root aggregate() honoring pagination (#30067,
already merged) and groupBy() position semantics (this slice, PR
number pending). Aimed at someone who already wrote the previously
silent-no-op form and will see their numbers change on upgrade with no
error.

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

Two changes[] entries in the 8.0.0-rc.4-to-8.0.0-rc.5 transition,
mirroring the two breaking-change entries in the release note:
pre-group pagination now scoping rows before groupBy() instead of
being silently dropped (no reliable detection pattern, prose-only),
and post-group take()/skip() now requiring a prior post-group
orderBy() (a compile error otherwise) — a decision only the caller
can make, not a rote find-and-replace.

Satisfies pnpm check:upgrade-coverage --mode pr's per-pr-declaration
rule for this PR's packages/3-extensions/sql-orm-client/** diff.

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

The charter's probe for this passed silently (slice 1's LIMIT -1 fix
lives generically in renderSelect, not special-cased to root
position), so nothing pinned it for the grouped select specifically.
Adds the assertion so a future refactor can't regress it unnoticed.

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

Splits the docs+release-note DoD item from the refused TSDoc half in
spec.md (the operator's direction: docs land in user-facing guides,
not hovers). Adds the project's learnings log, the manual QA script,
its run report, and the slice 2 PR description.

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

The entry shipped with the template's <pr> placeholder because the PR
number did not exist until the branch was pushed. Manual QA caught it as
a would-be dead link in the published GitHub Release body.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Steven McClankerton <tatarintsev@prisma.io>

This branch picked up a describe.sequential() rewrite of an existing
concurrent: false option in a completely unrelated example's e2e test
at some point in its history. It has nothing to do with grouped
pagination and doesn't belong in this PR — restoring the original form
byte-for-byte.

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

CodeRabbit review, PR #30092: orderBy([]) set HasOrderBy to true while
postGroup.orderBy stayed empty, so .groupBy('x').orderBy([]).take(1)
compiled and paged groups with no ORDER BY — exactly the
non-deterministic paging the gate exists to prevent, reachable through
the gate itself.

Type level: the array form of orderBy()'s parameter is now a
non-empty tuple, so an empty array literal doesn't typecheck.

Runtime: an empty array (however it arrives — a hand-built
CollectionState, a plain-JS caller with no types) throws
ORM.ARGUMENT_INVALID before HasOrderBy is ever set. Guards where
GroupedCollection's state is consumed, not only where it's set,
mirroring the distinctOn capability guard's own precedent.

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

Per operator review on PR #30092: nobody asked for a whole new
reference guide, and it was shipping a factual error CodeRabbit
caught (claiming cursor/distinct/distinctOn apply post-groupBy(), when
GroupedCollection only exposes orderBy/take/skip). Deleted rather than
replaced at a smaller size — the project DoD asked for the rule to be
documented, not for a new doc file.

The two rc.5 entries move from Breaking changes to Fixes and shrink to
one sentence plus a PR citation each, matching the format of the
file's other short entries — these are bug fixes, not behaviour a
reader needs a migration plan for.

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