fix(query): evaluate grouped SELECT expressions once per group - #2006

Non-vacuity log for this PR, moved out of the description to keep it under GitHub's size limit: for each fix, what was reverted and what went red. Every row was committed first, then only the fix reverted, rebuilt, watched fail, restored, and the needle grepped.

The rows through 1936c5d32 were run before the rebase onto bf523e24e; the rebase applied without conflicts and changed none of the fix code. The rows from 2c4aa850c on were run after it. Mutations sharing a build letter (A through F) were applied together, and each test went red with its own mutation's failure message. The one test that went red outside its own row is noted in the lanes row.

Suggested follow-ups (not blocking):

• ASK and CONSTRUCT with GROUP BY or HAVING are now refused. CONSTRUCT … GROUP BY … HAVING is meaningful, and lower_select_level should make supporting it cheap.
• ORDER BY ?nosuch (grouped or not) is still a 500: "Sort variable VarId(n) not found in query schema".
• Routing stamps for the other detectors that now gate on binds: implicit_single_aggregate, stats_count_by_predicate, star_topk, whole_graph_scalar_aggs, and the fused R2RML / SQL lanes.
• HAVING that reads a non-aggregate SELECT alias (e.g. (COUNT(?e)+0 AS ?n) … HAVING (?n > 1)) silently drops every group. A diagnostic would help.

The deviations from the design, each written up in full: moved out of the description to keep it under GitHub's size limit. They describe the branch at 87576fdb1.

• Placement rule, three refinements (ir::SelectExprPlacer, shared by SPARQL and JSON-LD) over the design's literal version of the JSON-LD rule (JSON-LD keeps per-group lists for non-key variables):
  • A read of a variable that nothing binds before grouping doesn't keep an expression before grouping (it's unbound either way — the same rule the plan-time check uses). Without this, the design's literal rule would place SPARQL (EXISTS { ?key ex:p ?inner } AS ?x) before grouping (?inner is not a key) and then fail the plan.
  • An expression that reads an aggregate output or an earlier per-group alias is always per-group (today's JSON-LD rule, kept as the first clause). A mixed read of an aggregate output and a non-key variable is therefore rejected by the plan-time check, instead of silently becoming a list.
  • A key-only alias that a per-solution expression reads is evaluated per solution too (from review). place_all places forward, then moves such aliases back before grouping until nothing changes, so the reader sees a value per solution and both stay per-group lists in JSON-LD, as at base. In SPARQL the reader is a grouped SELECT expression over a non-key variable, which V4 rejects.
• The shared placement helper arrives with the SPARQL commit, not the JSON-LD one, so the JSON-LD commit only touches JSON-LD lowering.
• One SPARQL function for a SELECT level (lower_select_level), used by the top level and sub-SELECTs, instead of the design's per-call-site sequence. lower_select_extends takes the level's pre-group variables (the helper needs them).
• JSON-LD alias guard implemented standalone. Reject Cypher alias and JSON-LD bind collisions that silently returned zero rows #1867 isn't merged, so this PR doesn't extend its check_bind_targets; it adds a narrow check that a per-group alias is not a variable the WHERE binds (which closes the shape where a post-group alias silently replaced a group key, e.g. (as (str ?n) ?a) under groupBy ?a). It should fold into check_bind_targets when this rebases onto Reject Cypher alias and JSON-LD bind collisions that silently returned zero rows #1867.
• Streaming lane, wildcard (the design didn't cover it; review caught an earlier head of this branch silently narrowing the columns on the stream, so the wildcard now gets the same refuse-before-the-stream treatment as an explicit list). What a JSON-LD select "*" under groupBy returns on /query depends on the grouping lane: with aggregates that all stream, the streaming GroupAggregateOperator returns the keys and aggregates only; otherwise the GroupByOperator lane also returns the other WHERE variables as per-group lists. The stream refuses the wildcard, before the response starts, only on the GroupByOperator lane when the WHERE binds a variable that is not a key — naming the list columns and pointing at /query or an explicit projection of the keys and aggregates. Grouping::aggregates_stream gives the lane from the same predicate as the planner (AggregateFn::is_streamable, which GroupAggregateOperator::all_streamable now delegates to). The stream still plans with Reject.
• Trailing VALUES placement is kept, a deviation from §18.2.4.3 now documented in docs/reference/compatibility.md (0509e806e), which also gives the portable forms. I decided to keep base placement: a trailing VALUES clause joins right after the WHERE, before grouping, at the top level and in a sub-SELECT, as at base. It therefore restricts what the aggregates count (the "VALUES as a parameter" idiom: … GROUP BY ?a VALUES ?e { ex:e1 } gives (Net, 1)), and a VALUES variable the WHERE doesn't bind multiplies their input (VALUES ?x { 1 2 } doubles COUNT). The spec joins it after HAVING. An earlier commit on this branch (97eb988d0) moved it there for grouped queries; that silently changed the idiom's answers, and af22f8e49 reverts it. What the branch keeps is HAVING's view (089e6c96e): the SELECT-level lowering takes the trailing VALUES pattern at both levels, counts its variables as bound before grouping (so ORDER BY can read one as a SAMPLE), and, before the SAMPLE rewrite, has HAVING read each one the WHERE doesn't bind, and that is not a key or an aggregate output, as a fresh variable nothing binds: unbound, as after HAVING. That's the same renaming that already kept a HAVING-as-filter from seeing the SELECT expressions, factored out as ir::read_as_unbound. The generated binds (aggregate inputs, GROUP BY expressions, SELECT expressions placed before grouping) now follow the join at the top level too, as they already did in a sub-SELECT (e6e2061e5): Query.post_values carries them as PostValues::then.
• HAVING shares FILTER's evaluator (from review; not in the design). FilterOperator's predicate is now a RowPredicate that HavingOperator uses too, so an EXISTS in HAVING is resolved per group row (uncorrelated once per batch, correlated per row with the semijoin cache). A Cypher metadata read in HAVING (an aggregating WITH … WHERE) under a non-root view policy now resolves through the policy filter too; it read as empty. A HAVING with neither runs the same synchronous batch filter as before. HavingOperator::new takes the planning context for the EXISTS subplans. JSON-LD having has no EXISTS form, so that surface has no twin to fix; a test pins the refusal.
• ASK and CONSTRUCT group (from bplatz's review). Both lower their solution modifiers through lower_select_level with a SELECT that projects nothing. ASK keeps LIMIT 1, which now stops at the first surviving group. CONSTRUCT renames each template variable the grouping doesn't produce to a variable nothing binds, so its triples are skipped (§16.2: an unbound template variable produces no triple). JSON-LD ask parses groupBy / having. DESCRIBE still refuses them. A CONSTRUCT with an aggregate ORDER BY is now one implicit group, where it used to be refused (sparql_construct_aggregate_order_by_groups).
• The Cypher parity test lives in it_query_sparql_grouped_projection.rs (grp_query_sparql) rather than it_query_cypher.rs, to stay clear of Reject Cypher alias and JSON-LD bind collisions that silently returned zero rows #1867's changes to that file.
• The indexed-ledger lanes test (fast paths on and off) is its own test binary, it_grouped_projection_lanes, because it toggles the process-global fast-path switch (the reason it_distinct_object_numbig_gate is its own binary). It also covers the dedup-only shape.
• Grouping::assemble errors have two variants (HavingWithoutGrouping, BindsWithoutGrouping); SPARQL maps them to a new LowerError::InvalidGrouping, JSON-LD to ParseError::InvalidOption, Cypher to its generic lowering error. All three are unreachable from the current lowerers.
• Trim under Reject also keeps COUNT(DISTINCT *)'s visible variables into the traditional grouping lane, which reads them.
• SELECT * with an explicit GROUP BY (reachable only from unvalidated entry points) projects the user-visible keys.
• Docs: the JSON-LD having example used a form that doesn't parse ([["filter", …]]); it now uses the string form.
• SHACL sh:select isn't in the design. It's lowered like SPARQL but never validated, so it inherits the grouped semantics (HAVING filter, implicit SAMPLE). A pre-bound variable ($this, $PATH) is constant within one evaluation, so a (sub-)SELECT level that projects one is also grouped by it, which changes no group (from review). That's what lets the family of sub-SELECTs that must project $this (the pre-binding restriction) evaluate: at base they never fired, and at the first head that review ran against, they refused every write. A shape query the planner still rejects (a projected non-key variable, or one nothing binds) fails as ShaclError::SparqlConstraint, whose message names the shape and the variable, and is decided by severity and mode (below); its constraint field is now the constraint's IRI (String, was its Sid). Pinned by the shacl_tests below; listed in the behavior table.
• An existing test (sparql_order_by_expression_over_grouped_var_errors_cleanly) pinned the error for ORDER BY over a non-key variable; per my earlier call to follow the spec where it's clean, that shape now returns rows, so it pins the sampled result instead.
• Error names (not in the design). The plan-time check has no variable names, so it returns a typed QueryError::UngroupedRead carrying ids. QueryError::name_variables turns it into InvalidQuery naming them wherever the query's registry is at hand: the runner's execute and execute_prepared (which also covers a sub-query, planned at run time), the API's view, dataset and stream prepare sites, and EXPLAIN. Nothing is plumbed into the planner. An error that surfaces unnamed keeps InvalidQuery's 400 and stream error code. A grouped projection of a variable nothing binds is the same typed error (ReadStage::UnboundProjection), raised by the post-group schema check where VariableNotFound("Selected variable VarId(n) …") was, and the stream's pre-flight renders the same message. A synthetic variable no user wrote (?__…, ?#…, _:…; for example the variable a Cypher property access e.area lowers to) is described instead of named ("an ORDER BY key is neither …"). That internal-name rule now has one definition, var_registry::is_internal_var_name, which the formatters' wildcard filter re-exports and SPARQL's SELECT * lowering uses; both had their own copy. Plan errors outside the grouped tail that still print ids are a follow-up.
• produced_vars_of shared (after the rebase). main's planner already had produced_vars_of (the variables a pattern list may bind). The grouped lowering computed the same set in four more places; it now lives in ir::pattern, and all five callers use it. SelectExprPlacer doesn't duplicate main's placement machinery (Settled in where_plan): Settled decides where in the WHERE join chain a BIND or FILTER can run, while the placer decides whether a SELECT expression runs per solution or per group, from the GROUP BY keys, the aggregates and the WHERE's may-bind set. A per-solution expression becomes a WHERE BIND, and main's Settled then schedules it.
• HAVING reads SELECT aliases (an extension of §18.2.4; my call). Grouping::binds_before_having splits the grouping's binds: the ones HAVING reads, directly or through another bind, run before it, and the rest after it, each part in SELECT order and each once per group. The executor, the plan-time ungrouped-read check and dependency tracing walk the same order. SPARQL 1.1 leaves such an alias unbound in HAVING. Many engines read it, and the W3C aggregate tests repeat the aggregate in HAVING, so they pin neither reading. Documented once in the compatibility reference, for simple and compound aliases alike.
• EXISTS-body variables are free over the group row (from bplatz's review). Expression::row_reads / substitute_row_read skip EXISTS bodies. The implicit SAMPLE, the plan-time check, the SELECT-expression placer and dependency tracing all use them. This replaces this PR's earlier reading, where a non-key variable in an EXISTS body read a SAMPLE.
• A Cypher WITH's WHERE filters after its slice (my call, aligning with openCypher).
  • The evidence was read, not executed. openCypher's grammar places the WHERE last: <with statement> ::= WITH <return statement body> [ <order by and page clause> ] [ <where clause> ]. The openCypher 9 reference says that after WITH, "WHERE simply filters the results". The TCK has no WITH with both, and no openCypher engine was run.
  • The lowering. A WITH with both lowers without its WHERE. A stage over the sliced rows then joins the WHERE's property accessors and filters, and repeats DISTINCT, because an accessor over a property with several values can repeat a row.
  • Scope. After a plain WITH, Fluree's WHERE also sees the variables before it, as it always did with no slice, where it filtered in the clause's body. So the sliced rows carry the ones it reads (an exists { … } body's included), and the stage drops them. After an aggregating or DISTINCT WITH, it sees only the projection, and any other read is an error rather than a free variable.
  • Unsliced shapes. A WITH without a slice lowers exactly as before.
• A WITH inside a CALL body carries the imports (pre-existing).
  • The bug. A subquery correlates with its parent only on what it selects. A WITH f after MATCH (p)-[:knows]->(f) selected f alone, so the CALL's per-row p never reached it, and the CALL crossed every outer row with the body's whole result.
  • The lowering. Inside a CALL body, every subquery the Cypher lowering builds now selects the imports it reads, groups by them when it groups (as the CALL's own grouping RETURN already did), and pins them. That covers a WITH, its two-level and after-the-slice stages, and an aggregating RETURN's first level.
  • Scope. An import carried this way but not projected stays out of scope after the WITH. A nested CALL can't import it, and WITH * doesn't bring it back.
  • The planner, one rule (subquery_correlation_vars). A pinned import counts as a correlation input even when the body binds it. Before, a CALL whose body binds its import looked uncorrelated and could be placed before the import's producer. The executor still picks evaluate-once plus hash join when the body allows it, and per-row when a nested slice needs it. Only Cypher sets pinned_vars, so SPARQL and JSON-LD planning is unchanged.
• Cypher reads after the aggregation. When an aggregating WITH's WHERE / ORDER BY or an aggregating RETURN's ORDER BY lowers anything (a property accessor of a node the clause projects, or the bind of an expression sort key such as c + 1), the clause lowers as two levels: the aggregation, then a stage that joins the accessors and computes the binds, filters on the WHERE, sorts and slices, which is what an explicit second WITH lowers to (with a SKIP or LIMIT, the WHERE moves to a stage after the slice; see the bullet above). Every read must be visible to the second stage; otherwise the clause stays one level and a property of a node the clause doesn't project stays a plan error, matching Cypher's scope rule. This replaces an earlier SAMPLE rewrite on this branch (23c3f1ee2), which joined the property before grouping and so repeated a group's rows once per value of a multi-valued property (422d986c4, ad89f13b9). The second stage keeps Fluree's model for a property with several values: it joins every value, as MATCH … WHERE does, and the reference says what that does in WHERE, ORDER BY, DISTINCT and a later aggregate (5422809d4).
• Nested conformance counts every result (my call, per SHACL §3.5). Whether a node conforms to a nested shape counted only Violation results. It now counts every result: one conforms check covers all six sites (the node-level sh:node, sh:not, sh:and, sh:or and sh:xone, and check_value_against_nested_shape, which serves every per-value form, qualified value shapes and the literal-focus checks). Severity still decides the write, on the result the outermost referencing shape reports. It composes with the next bullet: a constraint that cannot run is not a result, so it doesn't change conformance, and it is decided at that same outermost severity.
• sh:sparql failures follow severity and mode (my call). The engine records them when the caller collects them (the transaction path) and raises them otherwise. A Violation shape in a reject-mode graph fails the write with the same ShaclError::SparqlConstraint. Which query errors count as the constraint's own failure is an exhaustive match over QueryError (raised_whatever_the_severity): the request's budgets, storage / catalog / policy access, data state and internal faults are raised whatever the severity; everything else (an invalid query, filter or expression, a named plan error, an unsupported feature, arithmetic and comparison errors) is the constraint's failure. A new variant has to be placed. A failure in a shape checked as a nested shape (sh:node, sh:not, sh:and, sh:or, sh:xone, and sh:node or sh:qualifiedValueShape on a property shape) takes the severity of the outermost shape that reports the result, as that shape's own results do (also my call): node-level nesting reports under the node shape, a property shape's under the property shape, and an enclosing nesting keeps its own. The nested shape's results keep their severity, which the conformance check reads (7999b625e).
• ASK applies OFFSET and LIMIT. ASK is true when a solution remains after them: OFFSET applies and LIMIT becomes at most 1. ORDER BY cannot change the answer and is dropped. With an OFFSET, ASK no longer takes the WHERE planner's multiplicity-blind license.
• A trailing VALUES after every query form. One parser helper reads it after SELECT, ASK, CONSTRUCT, DESCRIBE and a sub-SELECT. ASK and CONSTRUCT lower it into post_values as SELECT does; DESCRIBE appends it to its target subquery's WHERE, as a sub-SELECT does. SPARQL parameter substitution (feat: SPARQL parameters, fulltext() in SPARQL, structured SHACL rejections #2024) walks it after every form, as it did after SELECT, so a parameter the trailing VALUES assigns is refused rather than substituted in the WHERE while the VALUES still binds it (bd3797dcc).
• The count top-k and the bound-object count stamp a decline at open. Both stamp Proceed at plan time; a fallback at open (novelty, policy, history) now also stamps Fallback(GateDeclined), as the star top-k and the directory count already did.
• Sort keys nothing binds are dropped at plan time, for the top level and each sub-query operator. A key some stage binds is kept, so a plan that lost one still fails validation.
• The stream's pre-flight runs Grouping::first_ungrouped_read with the query's own projection policy.
• The WHERE cursor names variables at plan, open and pull, so every update surface gets named grouped-read errors.
• The fused R2RML aggregate now records a routing stamp (fused_r2rml_aggregate) at open, for its canary.

Moved out of the description to keep it under GitHub's size limit: the full test list (current at 87576fdb1), and the perf detail and gate log from when this PR was first opened, at the pre-rebase SHAs they name.

Full test list

• grp_query_sparql — it_query_sparql_grouped_projection.rs (new): the SPARQL matrix on a non-injective fixture (3 areas → 2 labels), each case asserting SPARQL-JSON rows and JSON-LD values; alias chains; ORDER BY / LIMIT order; sub-SELECT scalars under outer FILTER / GROUP BY / aggregates; HAVING reading an aggregate or expression alias, through a chain, and RAND() / STRUUID() tested as returned; STRUUID once per group; empty implicit group; SELECT * under implicit grouping (top level and as a sub-SELECT joined outside); every results format (XML, CSV, TSV, typed JSON); implicit SAMPLE for HAVING (both lanes) and ORDER BY (bare and expression); HAVING as a filter; V4 under HAVING-only grouping; V4 for an expression over a non-key variable read by another expression; V009; trailing VALUES before grouping, as at base (VALUES as a parameter restricts COUNT, a VALUES-only variable multiplies it, ORDER BY samples one), and HAVING reading a VALUES-only variable as unbound (grouped and ungrouped, top level and sub-SELECT; a VALUES variable that is a key is still read); grouped ASK (true / false through grouped and implicit HAVING, one implicit group over no solutions, EXISTS free over the group row) and CONSTRUCT (per group, a skipped non-key triple), DESCRIBE still refused; HAVING EXISTS / NOT EXISTS per group, EXISTS-body variables free (flag on e1 or e2, GROUP_CONCAT lane, EXISTS SELECT expression); Cypher parity; a Cypher grouped-read error that prints no internal variable (now on a node the WITH doesn't project); solo must-not-change guards; ORDER BY a variable nothing binds (grouped, ungrouped, sub-SELECT); generated binds read a trailing VALUES at both levels; Cypher key-node properties after an aggregating WITH / RETURN (WHERE, ORDER BY, composite alias, exists {}); the trailing-VALUES internal-predicate check (it_query_sparql_annotations); CONSTRUCT with an aggregate ORDER BY (it_query_construct).
• grp_query — it_query_jsonld_grouped_projection.rs (new): the JSON-LD twins (SAMPLE, having-as-filter), key-only select expressions as scalars, unchanged list shapes (including a key-only alias read by a per-solution expression), the subquery error, the grouped-read error naming ?x with no VarId( (subquery, planned at run time, and a top-level expression, planned before), SPARQL-results refusal of lists, ask with groupBy / having, having refusing an EXISTS form, the ?count name pin, solo guards; having reading a select expression alias; orderBy a variable nothing binds; top-level values reaching select expressions; the update grouped-read error naming ?x (and the SPARQL UPDATE twin, refused at validation).
• grp_transact — SPARQL UPDATE over a grouped sub-SELECT expression (with and without an aggregation stage), and the JSON-LD update twin over a grouped subquery.
• grp_misc — it_stream_query.rs: SPARQL grouped expression streams 3 rows; a JSON-LD per-group list is refused before the stream; select * under groupBy is refused on the stream when /query returns per-group lists, and streams when every WHERE variable is a key or when every aggregate streams (/query then returns the keys only); a projected variable nothing binds is the same named 400 on /query and the stream. A grouped SELECT expression's read is the same 400 on /query and the stream, before it starts; ORDER BY a variable nothing binds streams every row.
• it_query_explain — plan pins: streaming GroupAggregateOperator under the Extend (COUNT and MIN); dedup-only grouping with early dedup.
• it_policy_cypher — an aggregating WITH … WHERE size(keys(n)) = 1 under a view policy that hides one property sees the policy-filtered keys (with a no-policy control).
• it_grouped_projection_lanes (new binary; toggles the process-global fast-path switch) — bulk-imported indexed ledger, fast paths on and off, hand-derived answers. Routing stamps as canary pairs for every aggregate fast path that gates on the grouping's binds: the GROUP BY ?o count top-k, the star top-k, the per-predicate directory count, COUNT(*), SUM(?o) and the whole-graph scalar aggregates. Each serves the key-only query (MustFire) and declines it with a SELECT expression (MustNotFire, with no fast-path stamp but the fused chain's). Each also declines a trailing VALUES.
• fluree-db-api lib shacl_tests (feature shacl) — sh:select constraints: HAVING without grouping filters; HAVING over a non-key variable samples; a projected non-key variable fails validation with a sh:sparql constraint failure naming the constraint, its shape and ?value; the seven probe shapes from review (a sub-SELECT grouped by another variable that projects $this, sub-SELECTs grouped explicitly and implicitly, HAVING with and without GROUP BY, ?message and ?value expressions over $this and an aggregate) fire on the violating node and pass the conforming one. Severity × mode cells for plan, parse and lower failures, including the fail-closed cell, and a failing Warning shape next to an enforced Violation shape.
• Unit: SPARQL lowering placement (every grouping form, SELECT order, sub-SELECT, SELECT *); validator (V4 counting a HAVING/ORDER BY aggregate as grouping, and V009); SelectExprPlacer rule; sample_ungrouped_reads (keys / aggregate outputs / Extend outputs / never-bound left alone, JSON-LD pre alias sampled, EXISTS renamed, SortSpec moved, idempotent, reuses an existing SAMPLE); having_as_filter; Grouping::assemble errors; first_ungrouped_read stage × variable-kind × policy table; rewrite-then-predicate pairing; apply_solution_modifiers without dependency sets; eval on a Grouped binding; formatter refusal (JSON, NDJSON, XML); binds_before_having; EXISTS bodies are not group-row reads; sort keys nothing binds dropped, and a lost key still an error.
• it_sql_pushdown_lane (features sql,native): the grouped-statement canary pair (with a SELECT expression the query stays in the engine).
• it_fused_aggregate_routing (new binary, features iceberg,native; its own binary because it asserts the absence of a span-capture event): the fused R2RML aggregate canary pair on the local people Iceberg fixture.
• Updated: sparql_order_by_expression_over_grouped_var_errors_cleanly pinned the old error for ORDER BY over a non-key variable; it now pins the sampled result. Two hand-built-IR executor tests updated for the new error text / projection. cypher_grouped_read_error_names_no_internal_variable now uses a node the WITH doesn't project; having_exists_is_evaluated_per_group (third case: every group kept); test_build_operator_tree_validates_sort_vars became …_drops_sort_keys_nothing_binds (in both unit-test modules); sparql_construct_aggregate_order_by_is_rejected became …_groups.

Added since the review, by binary:

• grp_query_sparql:
  • cypher_output_node_properties_are_read_after_aggregation: Alice with two ages, with count, sum and collect under WHERE, a WITH's ORDER BY and a RETURN's ORDER BY, hand-derived, and the explicit two-WITH form. It also pins the multi-value model in row order: an unsliced ORDER BY in a WITH and in a RETURN, WITH DISTINCT … ORDER BY, count(*) and sum(c) after the WHERE, and collect(p.age) beside count(f).
  • ORDER BY c + 1 and ORDER BY -c after an aggregating WITH, and ORDER BY c + 1 after an aggregating RETURN (cypher_reads_a_key_nodes_property_after_grouping).
  • aggregate_over_a_variable_nothing_binds_is_a_named_error (both query paths) and cypher_aggregate_of_a_sibling_aggregate_is_a_named_error.
  • ask_applies_offset_limit_and_values (SPARQL and JSON-LD, grouped included, in it_query_ask) and construct_and_describe_read_a_trailing_values (both CONSTRUCT forms, grouped, DESCRIBE with and without a WHERE, and the JSON-LD construct values twin, in it_query_construct).
  • subselect_grouped_expression_sorts_in_the_outer_query, with its JSON-LD twin in grp_query (d466ca9df): a sub-SELECT's grouped SELECT expression sorts in the outer ORDER BY. At base it was a per-group list there, and the outer sort compared lists: a debug build panics at sort.rs:208 ("Grouped bindings should not appear in sort comparisons"), a release build leaves the rows unsorted.
  • cypher_call_body_with_keeps_the_import, inside CALL (p) { … }: WITH f; WITH f ORDER BY f.age LIMIT 1, and the same with a WHERE after the slice; WITH DISTINCT; OPTIONAL MATCH … WITH count(f) (a friendless p counts 0); a WHERE reading p; and an aggregating RETURN … ORDER BY c + 1. Each gives the per-p answer. After WITH f, and after WITH f WITH *, a nested CALL (p) is refused.
  • cypher_with_where_filters_after_the_slice: a WITH's WHERE after LIMIT, after SKIP alone and without a slice (unchanged), on each lowering path: plain, including a WHERE reading a variable from before the WITH and an exists { … } that correlates with them; aggregating in one level and in two; and DISTINCT. The rows are pinned in order. It also pins that the variables the WHERE read leave scope (a later MATCH (p:P) binds p afresh), and that a property with several values gives a row once per passing value, or once after DISTINCT. Three reads of a variable an aggregating or DISTINCT WITH doesn't project are errors. Two exists cases tell a carried f from a body variable of its own, g.
• grp_query: jsonld_aggregate_variable_errors_name_the_variable.
• it_query_cypher: ORDER BY size(friends) after an aggregating WITH and a RETURN, ORDER BY any(x IN friends WHERE …), and friends, tail(friends), friends + ['x'] still refused (cypher_collect_through_with).
• shacl_tests:
  • shacl_sparql_constraint_failure_follows_severity_and_mode gains an aggregate over a variable nothing binds, two aggregates with one output and an unknown function, and asserts the message names the shape and prints no VarId.
  • shacl_nested_constraint_failure_takes_the_outer_severity: every nesting (sh:node, sh:not, sh:and, sh:or, sh:xone, property sh:node, sh:qualifiedValueShape, and a chain through a Violation middle shape) × a Warning / Info / Violation outer shape, a Warning inner shape, and a warn-mode graph; shapes written in JSON-LD and with SPARQL UPDATE.
  • shacl_sparql_only_shape_keeps_its_severity: a Warning, Info and Violation shape whose only constraint is sh:sparql, targeting its own instances as a class, written in JSON-LD and with SPARQL UPDATE.
  • shacl_nested_warning_results_count_toward_conformance: a Warning inner shape whose check reports a result for the node, either an sh:sparql constraint or a Warning property shape. It's reached through each of seven nestings (sh:node, sh:not, sh:and, sh:or, sh:xone, and sh:node and sh:qualifiedValueShape on a property), under a Violation and a Warning outer shape, written in JSON-LD and with SPARQL UPDATE. sh:not commits; the rest reject under Violation and commit under Warning. All 28 Violation-outer cells failed before the fix.
  • shacl_logical_lists_resolve_from_either_surface: sh:and, sh:or and sh:xone over two shapes each, a conforming and a violating node for each, both surfaces.
• it_grouped_projection_lanes: JSON-LD canary pairs for the count top-k and the directory count with a per-group list; the per-group IRI list through both JSON-LD formatters; the whole-graph aggregates' trailing-VALUES case; a MustFire also requires no decline stamped at open, and a canary failure lists the sites that declined at open; and a second indexed ledger with overflow integers (SPARQL and JSON-LD, both lanes, typed JSON for the datatypes).
• fluree-db-shacl unit: constraint_query_errors_are_classified_by_variant, one representative per QueryError variant. The classifier table is built by a macro whose patterns are also a match with no wildcard, so a new QueryError variant fails to compile until it has an entry; R2rml has its row (a dev-dependency on fluree-db-r2rml, already in the graph).
• fluree-db-query unit: test_parse_order_by_expression_names_the_alias_route, every orderBy term form.
• fluree-db-sparql unit: test_ask_keeps_offset_and_caps_limit and test_trailing_values_after_every_query_form (lowering); a_parameter_the_query_assigns_is_an_error adds a trailing VALUES after ASK, CONSTRUCT and DESCRIBE (with and without a WHERE).
• Updated: shacl_nested_constraint_failure_takes_the_outer_severity now writes every nesting with SPARQL UPDATE too, and its inner shape no longer targets an unused class.

Perf detail, when this PR was first opened

New bench. Local run: bench profile (fat LTO), quick profile, 16-core dev Mac shared with other jobs (load 6–16). Before and after binaries were built from the same bench code: base sources, then this branch at its pre-rebase tip. Runs alternate before/after, and the two tiny reps use opposite order. Tiny figures are rep 2; rep 1 agrees within 8% on every figure. After the fix, expr_count and jsonld_keyonly_expr are within noise of key_count, as the design expected. dedup_expr runs below it (0.74 vs 1.00 ms at small, 90 vs 107 µs at tiny) because it has no aggregate: a dedup-only GROUP BY gets WHERE-level early dedup (pinned in it_query_explain), so it groups the distinct keys instead of counting every entity. implicit_const_count is far below it too (one group and no key). subselect_expr is expr_count wrapped in a sub-SELECT, so expr_count is its control: the gap between them (1.97 vs 0.99 ms at small after; 25.9 vs 20.0 ms before) is the sub-query wrapper, present on both sides. expr_min aggregates with MIN over IRIs rather than COUNT, so key_count is not its control.

Watched benches, which the design expected not to change: query_hot_bsbm (Q9: GROUP BY + COUNT + HAVING + ORDER BY), query_overlay_matrix (incl. groupby_{base,cached,novelty,overlay}), query_hot_negation_count (incl. grouped_join_count), query_hot_whole_graph_agg and query_hot_bsbm_bi. All runs are interleaved before/after on a shared 16-core machine. A single rep can swing ±15% at tiny and up to ±40% at small under a load spike, so every conclusion here rests on several reps. The tiny and small sweeps were taken at the pre-rebase tip, before the fixes from the review pass; the check at dcb896772 follows them.

Tiny (CI's scale, 10% budget), four reps, two in each order. All 29 scenarios have a mean change within ±5.3%: Q9 +1.3%, groupby_base +4.2%, grouped_join_count −0.4%, whole-graph count +4.2%. Two moved the same way in all four reps:

• join_count was faster by 1.0–1.6%.
• not_exists_after_optional was slower by 0.5–5.0% (mean +2.5%). The query has no grouping.

Small (5% budget). I ran the whole suite twice in opposite orders, the overlay matrix twice more, and then the outliers in isolation using criterion's filter, three alternations each. One overlay rep ran under a load spike of 44 and is excluded.

• query_hot_bsbm: Q9 −3.2%, Q5 −2.6%. query_hot_whole_graph_agg and query_hot_bsbm_bi are within ±5%.
• grouped_join_count: +17.4% and +4.0% in the full runs, then +4.8%, +2.0% and +2.8% isolated (mean +3.2%). That's within budget but always positive. On its per-row path this PR changes only Binding::Grouped arms that never run there: a debug_assert in the group-key function, which release builds compile out, and an error return in join substitution.
• Quiet box, session 1 (2026-10-01, three AB/BA/AB rounds of the previous head's merge bd885e365 against main): two query_overlay_matrix losses, both on the COUNT query, count_cached +5.1% (+0.9 µs) and count_novelty +9.4% (312.6 → 342.0 µs); count_base was +3.9%, stable.
  • count_base and count_cached were real per-query work this PR added. Every query level collected the variables its WHERE binds, and a grouping level also built a SELECT-expression placer and a copy of those variables for the SAMPLE rewrite. V009 and the plan-time ungrouped-read check built sets too. All of it ran even when the level had nothing to sample or place. c67dc3516 collects them only for a stage that reads them. Per query on the COUNT query (n=1000), main / before / after: allocations 190 / 197 / 189 indexed and 1238 / 1245 / 1237 novelty; instructions 168.8k / 173.6k / 168.1k indexed. In the bench itself (the box's trees, an instrumented copy of query_overlay_matrix, M4), count_base and count_cached run 186–187k instructions per query at c67dc3516 and on main, against 191–192k before it.
  • count_novelty runs no code of this PR per row or per flake. Per-row allocations are identical (the previous head added 7 allocations per query at every n and on both ledgers). On an M4 the box's exact trees matched main, alone and in the full matrix: 3.40–3.47M instructions and 671–685k cycles per query on both sides. Cross-built for x86-64 (rustc 1.97, fat LTO, config L), every function on that path is instruction-for-instruction the same with immediates masked; the 178 functions that differ are the per-query code this PR touched. What moved is placement: the hottest loop, SipHash-1-3's write (about a third of the query's CPU, hashing fact keys in remove_stale_flakes), sits at offset 0 of a 64-byte line on main and at offset 32 in bd885e365. At c67dc3516 the SipHash loop is back at offset 0, and its callers are at new offsets. Session 2 confirmed the placement reading under perf stat (part C below): equal instructions with different cycles.

Quiet box, session 2, at c67dc3516 (merge 2caedb047; same box type, harness and rule; 3 rounds, plus count_novelty run alone). The rows for this PR's target and the count queries; every other row is stable:

Part C, perf stat. Each count scenario alone per binary, per-iteration medians over 3 alternations; the old merge is bd885e365, the new one 2caedb047:

Formatter micro-bench format::tests::bench_stream_vs_dom: 10k rows, release builds of base and this branch, two alternated reps. SPARQL JSON moved −2.6% to −4.6% (streaming) and −0.6% to −5.4% (DOM) across the three shapes, inside the −7%..+5% (one +18% outlier) that the formats this PR doesn't touch moved — so no measurable change either way from dropping the per-row list scan.

Gates, when this PR was first opened

The full gates ran at 2a540f61e (on bf523e24e). 4f992fa4a only adds the compatibility-reference paragraph on trailing VALUES, and c67dc3516, the per-query-cost fix, was gated on its own on top of it, with 0 failures (the log below has the runs). At 2a540f61e, cargo check (right after the rebase), fmt (workspace and testsuite-sparql), clippy with -D warnings, the doc tests, testsuite-sparql (36/36 suites, registers checked both ways) and the wasm check are all clean. The full nextest run (CI's test job) is 13,765 run / 13,760 passed, and the other five need a word:

• 1 failure, fluree-raft-core forward::tests::propose_connect_timeout_is_retryable: ECONNRESET on macOS, in a crate that depends on no fluree-db crate, and it failed the same way at the pre-rebase tip.
• 4 timeouts at nextest's 360 s limit, all bulk-import / incremental-indexing tests that passed in the pre-rebase full run and pass when run alone at 2a540f61e (per-test times in the gate log below). The machine is just slower than it was for the pre-rebase run (load 7–26 here).

Across the four interleaved A/B pairs, the head is faster on two (8%, 15%) and slower on two (6%, 21%), and the 21% — the last compaction run — ran at load 13–15 against 10–12 for its base run. Both compaction tests run no code this PR changes, and the same slowness shows on main, so it's the box, not this PR.

Not run: the wasm-smoke browser suites and npm package build (headless Chrome), testsuite-sparql clippy (no file there changed), the sql-bridge workspace (it depends on no fluree crate), and the bench.yml compare against the committed baseline (host_class differs). testsuite-shacl is local only — no CI workflow runs it — and it doesn't compile on main today; e112dddf3 (d3df023d7 after the rebases) adds its two missing ValidateOptions fields as its own commit, and base and head then have the same status for every test (details below).

c67dc3516 (the per-query lowering cost) was gated on its own, on top of 4f992fa4a:

• cargo fmt --all -- --check: clean. cargo clippy --all --all-features --all-targets --locked -- -D warnings, after touching the five changed files: clean.
• cargo test -p fluree-db-query -p fluree-db-sparql: green (lib 1,658 passed with 1 ignored, and 658 passed, plus integration and doc tests).
• cargo nextest run --all-features --no-fail-fast -p fluree-db-query -p fluree-db-sparql -p fluree-db-api -p fluree-db-shacl -p fluree-db-cypher: 7,198 run, 7,192 passed, 6 timed out at the 360 s limit, 28 skipped, 0 failed (5,568 s at load 7–11). The six are indexing-heavy: the four in the table below, plus it_indexing_stats::large_dataset_statistics_accuracy and it_indexing_workflow::file_based_indexing_then_new_connection_loads_and_queries. Rerun alone with no limit, all six pass (the four grp_index tests together in 1,204 s, numbig in 440 s, rdf_type_star in 267 s; load spiked to 116 during the reruns).
• testsuite-sparql cargo test: 36/36 suites pass.
• Mutation check: making sample_ungrouped_reads collect the pre-group variables eagerly fails the new sample_ungrouped_reads_collects_where_vars_only_for_a_non_key_read.
• Under plain cargo test (every test in one process), it_annotation_filter_pushdown::annotation_body_threshold_reduces_scan_work_on_both_surfaces missed its lane event. It passes alone and under nextest, which runs each test in its own process, as CI does.

Run locally (CARGO_BUILD_JOBS=4, --test-threads 4) at 2a540f61e on bf523e24e, unless noted (4f992fa4a adds only the compatibility-reference paragraph on trailing VALUES):

• cargo check --workspace --all-targets --all-features --locked right after the rebase: clean.

• cargo fmt --all -- --check: clean. testsuite-sparql: cargo fmt --all -- --check clean.

• cargo clippy --all --all-features --all-targets --locked -- -D warnings, after touching every .rs file the PR changes so no target is linted from cache: clean (0 warnings).

• cargo nextest run --workspace --all-features --no-fail-fast --locked (CI's test job): 13,765 run, 13,760 passed, 1 failed, 4 timed out, 41 skipped (4,655 s at load 8–14; the pre-rebase run of the same command took 840 s). The failure is fluree-raft-core forward::tests::propose_connect_timeout_is_retryable (ECONNRESET on macOS; the crate depends on no fluree-db crate, and it failed the same way at the pre-rebase tip). The four timeouts hit nextest's 360 s limit. All four are bulk-import / incremental-indexing tests. Each passes alone with libtest (no per-test limit) at 2a540f61e:

  Test	alone at 2a540f61e	pre-rebase full run	interleaved A/B, same box: base bf523e24e / this head
  it_query_sparql_indexed::indexed_rdf_type_star_count_exact_across_incremental_builds	219 s	28 s	204 s, 219 s / 185 s, 206 s
  it_distinct_object_numbig_gate::distinct_object_count_counts_numbig_object_keys_exactly	391 s	46 s	344 s / 365 s
  it_fwd_pack_compaction::incremental_cycles_compact_the_forward_pack_tail	651 s	100 s	731 s / 625 s
  it_fwd_pack_compaction::a_namespace_that_goes_quiet_stays_bounded_and_readable	850 s	127 s	987 s / 1194 s

  The machine is slower than for the pre-rebase run (load 7–26 here), and on it base and this head are close. The A/B columns are one or two runs per side, interleaved: the head was faster on two tests (by 8% and 15%) and slower on two (by 6% and 21%); the 21% (the last compaction run) ran at load 13–15 against 10–12 for its base run. The two compaction tests run no code this PR changes, and the same slowness shows on main: a_namespace_that_goes_quiet… was still running at 8 min there (12.5 min alone in a separate measurement).

• cargo test --workspace --all-features --doc --locked (CI's doc-test step): 48 passed, 164 ignored, 0 failed.

• testsuite-sparql: cargo test --no-fail-fast (CI's command): 36/36 suites pass with registers checked both ways (no register churn); lib 45, w3c_rdf 3.

• wasm: cargo check -p fluree-db-wasm -p fluree-db-browser --target wasm32-unknown-unknown --lib --tests --locked with CI's RUSTFLAGS: clean.

• testsuite-shacl, local only — not run by CI (no workflow references it; it is an excluded workspace). It does not compile on main today: ValidateOptions gained max_fuel and cancellation, and its runner still builds the struct without them. e112dddf3 (d3df023d7 after the rebases) adds the two fields (None, as before) as its own commit. Base bf523e24e with the same two lines, and this PR's head: SHACL Core 81/98 and SHACL-SPARQL 17/22 on both, with the same status for every test. The only difference in failure details, after masking blank-node labels, is pre-binding/shapesGraph-001 (failing on both): its message now names the constraint by IRI instead of by SID (d18c572b7, now b998482c5). The five SHACL-SPARQL failures are the same on both sides: three conforms expectations, the unsupported $shapesGraph, and unsupported-sparql-006. No W3C SHACL-SPARQL test uses GROUP BY, HAVING or an aggregate (grep of tests/sparql), which is why this PR's sh:select change doesn't show up there; the four shacl_tests above pin it.

This continues the non-vacuity log in the first comment, which covers the PR as first opened. It has every fix since then, from the review onward.

Same method throughout: each fix was committed first. Then only the fix was reverted, using a needle taken from the post-fmt source and required to match an exact number of times. The tree was rebuilt, the named tests were run and watched fail on an assertion (never a compile error, except the one row below that is meant not to compile), and the files were restored with git checkout --, with git diff empty afterwards. One honest miss: the first run of the severity-and-mode mutation used a needle that matched nothing, so that run was green on unmutated code. It was discarded and re-run against the formatted line. Commits are named by their SHAs on the branch at 87576fdb1. Each mutation ran on the branch as it stood at the time, before the later rebases, and those rebases left every fix commit patch-identical apart from context. A SHA marked "measured on" names a build used for a comparison, not a commit on the branch.

Grouping: EXISTS, HAVING and sort keys

Cypher

What the earlier SAMPLE reading did with a two-valued property. The 422d986c4 row stops at the test's first assertion, so a throwaway test (added, run, then removed with git checkout --) printed three WHERE p.age > 30 queries on the same fixture, under the revert and with the fix. Alice (aged 40 and 41) knows Bob (score 10) and Carol (100); Dave knows Alice (1), Bob and Carol:

Alice appears twice in the fixed column because both of her ages pass the filter: the second stage reads every value. That matches the existing Cypher behavior for a multi-valued property, checked on the same fixture. MATCH (p:P) WHERE p.age > 30 RETURN p.name returns Alice twice, Carol and Dave; with > 40, it returns Alice once and Dave; and RETURN p.name ORDER BY p.age DESC lists Alice twice.

Trailing VALUES, and ASK / CONSTRUCT / DESCRIBE

Fast paths and routing canaries

The canary pairs check that each fast path that gates on the grouping's binds serves the key-only query (MustFire) and declines the same query with a SELECT expression (MustNotFire).

SHACL

The outer-severity test without its workaround. shacl_nested_constraint_failure_takes_the_outer_severity passes with or without 2db734978. The outer shape's severity governs every cell, so the inner shape's own severity, which 2db734978 restores, never decides one. That's why its workaround (an inner sh:targetClass ex:Unused) could go, and why shacl_sparql_only_shape_keeps_its_severity is the test that pins 2db734978.

Error names, formatting and the stream

The sub-SELECT sort panic, checked rather than mutated. A sub-SELECT's grouped SELECT expression, sorted in the outer ORDER BY, is fixed by this PR's per-group evaluation itself, not by one commit. So I ran the same queries on debug CLIs built at main (2941d470c), at the branch head then (measured on ba598107f), and at the branch as first reviewed, rebased (measured on 8f8cf77ff). Main panics at fluree-db-query/src/sort.rs:208:13, "Grouped bindings should not appear in sort comparisons", on the SPARQL STRLEN query and on the JSON-LD subquery. Both branch builds return Remote 6, Local 5, Net 3 on both. The COUNT * 2 control sorts at all three. subselect_grouped_expression_sorts_in_the_outer_query and its JSON-LD twin (d466ca9df) pin it.

Not mutated, and why

• de26852a2 and 320ae3e98 (named aggregate-variable errors): their tests assert the named text and the absence of VarId(. The text before the fix is exactly a VarId( print, so a revert fails them by construction. Not run.
• a99f444d1's directory-count check: only the count top-k half was mutated.
• 5efca0d81's LIMIT cap (LIMIT 0 is false): not mutated separately.
• The bound-object count's decline stamp (270dcb51d): diagnostic only; no canary covers that site.
• 7ce891589 is a test.
• The multi-value model pins (5422809d4 and its tests): they pin today's model, not a fix. The per-value rows, DISTINCT keeping the copies, a later count and sum, and collect(p.age) beside count(f) are meant to flip on purpose if the model changes.
• The canary failure message (62fa6798a): it's text. The routing check behind it is served(), which the MustFire row above shows is load-bearing.
• claim_metadata's rule that a severity given to a shape after it was registered stays. It only decides between two conflicting sh:severity values on one shape in different graphs, and no test covers that.
• The claim of sh:message, sh:name and sh:description. For a shape whose only constraint is sh:sparql, validation reads none of them: its results take the constraint node's message. They reach the compiled shape, which the GraphQL schema reads for name and description; no test covers that.
• Docs and comments: 6ca526c24, 290964aa1, 492683294, 2acbe23e6, 241d3fe41, 622bb386c, b6f867305, 87576fdb1.

Thanks for these, @bplatz. All four ended up in this PR rather than as follow-ups, and the branch is rebased onto 745736a04 with them:

• CONSTRUCT and ASK with GROUP BY / HAVING (b383c709d).
  • Both lower through lower_select_level with a SELECT that projects nothing.
  • ASK is true when some group passes HAVING. CONSTRUCT instantiates its template once per group.
  • On the one judgment call, I went with the spec rather than a 400: a template variable that isn't a GROUP BY key is unbound in the group solution, so the triples that read it are skipped (§16.2).
  • JSON-LD ask takes groupBy / having, and DESCRIBE still refuses them.
  • A CONSTRUCT with an aggregate ORDER BY is now one implicit group where it used to be refused, and its test moved with it.
  • ASK also dropped OFFSET and LIMIT: ASK { … } OFFSET 2 over two solutions was true, and so was LIMIT 0. 5efca0d81 makes ASK true only when a solution remains after them; ORDER BY can't change that and is still dropped. JSON-LD ask now applies offset, limit and values, and construct applies values; both ignored them before.
• ORDER BY ?nosuch (a4c2aa764).
  • A sort key that no stage of the level can bind is unbound in every row, so it orders nothing and is dropped. The stages are the WHERE, a trailing VALUES, grouping, an ORDER BY expression and the projection.
  • Sub-queries drop it once per operator, not per parent row.
  • A key some stage binds is kept, so a plan that loses one still fails the sort validation.
  • Tested on SPARQL (grouped, ungrouped, sub-SELECT), JSON-LD and the stream.
• Routing stamps for the other binds-gated detectors (923c428e1, tightened in 1d2c0d6a3 and 4e30eaf0e).
  • Each has a canary pair: the key-only query must take the fast path, and the same query with a SELECT expression must not. Both are checked with hand-derived rows in both lanes.
  • On the indexed ledger, the pairs cover the star top-k, the per-predicate directory count, COUNT(*), SUM(?o) and the whole-graph scalar aggregates. The SQL lane's grouped statement has a pair in it_sql_pushdown_lane.
  • The fused R2RML aggregate has a pair on a local Iceberg table, with its rows checked with fast paths on only. It had no routing stamp before, so it now records Proceed or Fallback at open.
  • Only the count top-k and the directory count decline the expression on their binds gate alone. The rest also decline it on their projection check. So removing just their binds gate leaves the test green, and removing both turns it red. The non-vacuity log has both runs, in the follow-up comment that continues the first comment's.
  • The mutation runs turned up two more checks:
    • With the single-aggregate gate removed, the COUNT(*) query went to a sibling lane, the count planner. So the MustNotFire queries now also assert that the fused-chain stamp is the only one.
    • The count top-k stamped Proceed when it was planned, but could still fall back at open without saying so. It now stamps the decline at open (270dcb51d, as does the bound-object count), and a MustFire requires that no decline was stamped.
  • The count top-k and the directory count also never read the projection, so a JSON-LD query projecting a per-group list next to the key and the count took them. The top-k answered null for the list, and the directory count failed with "Projected variable not in child schema". Both now decline any projection other than the key and the count (a99f444d1), pinned as JSON-LD canary pairs.
• HAVING reading a non-aggregate SELECT alias (19512aec1).
  • I decided to extend visibility rather than add a diagnostic. In a grouped query, HAVING reads a SELECT expression's alias as well as an aggregate's.
  • The expressions HAVING reads, and the aliases they read in turn, run before HAVING. The rest run after it, each once per group, so HAVING tests the value the query returns. That's pinned with RAND() and STRUUID() over 40 groups.
  • (COUNT(?e) + 0 AS ?n) … HAVING (?n > 1) keeps Local and Net, and the ?seg case keeps the Net group.
  • It's a Fluree extension, though many engines share it. The W3C aggregate tests repeat the aggregate in HAVING, so they pin neither reading. It's documented once in the compatibility reference.
  • The same rule holds for JSON-LD having and Cypher WITH … WHERE, and it fixes the Cypher composite alias (WITH p, count(f) + 0 AS c WHERE c > 1), which dropped every row at base too.

A few more things turned up while tracing these. They're all pre-existing, and I folded them in rather than file them, so each has a row in the description's behavior table:

• the internal-predicate check in SPARQL lowering didn't walk the trailing VALUES; now it does (71af73a38);
• two comments still described the old HAVING/EXISTS order (290964aa1);
• the aggregate-output plan errors printed raw variable ids, Aggregate output variable VarId(0) already exists in schema and Duplicate aggregate output variable VarId(1). SPARQL's validator catches both first, but JSON-LD and sh:select reach the plan check. They're now aggregate output variable ?a is already bound in the WHERE pattern and variable ?n is the output of more than one aggregate (de26852a2). Cypher's WITH p, count(f) AS c, sum(c) AS s gets the named unbound-aggregate-input error (320ae3e98);
• a Cypher ORDER BY on a value read from a collected list, such as WITH p, collect(f) AS fs ORDER BY size(fs), was refused as an ORDER BY on the list. It sorts after the aggregation now; a key whose value is the list itself is still refused (92f4913be);
• a JSON-LD orderBy on an expression said "orderBy must be an array of objects with 'var' field". It now lists the forms orderBy takes, and says to sort on an alias (7de911c5e);
• on an indexed ledger, the JSON-LD formatters failed on a per-group list of IRIs: "format_binding called without QueryResult for encoded IRI binding". They now materialize encoded bindings inside lists and maps, as typed JSON already did (c44d22aca).

The last ones change the answers, or the write verdicts, of queries and shapes that run today without an error, so I'd especially like your eyes on these. Happy to talk through any of them:

• A Cypher WITH's WHERE filtered before the clause's SKIP / LIMIT. openCypher's grammar puts it after them, and it filters the clause's results. So UNWIND range(1, 10) AS x WITH x ORDER BY x LIMIT 5 WHERE x > 3 gave 4 to 8, where openCypher gives 4 and 5. It now filters the sliced rows (b2ef72fba), and a WITH without a slice lowers as before. That evidence is from the grammar and the reference; no openCypher engine was run.
• A WITH inside a CALL (p) { … } body lost its correlation with p. MATCH (p:P) CALL (p) { MATCH (p)-[:knows]->(f) WITH f RETURN f.name AS fn } RETURN p.name, fn crossed every p with every knows edge, and a slice in the body ran once for all of them. The body's subqueries now carry the imports they read, and the planner keeps a CALL's import as a correlation input (f553cd86c). This was there at base too.
• Two SHACL compile bugs.
  • The shape compiler dropped the sh:severity of a node shape whose only constraint is sh:sparql. Such a shape is registered by its rdf:type after the compiler has read the severity, so a Warning shape rejected writes. It keeps its severity now (2db734978).
  • sh:and / sh:or / sh:xone lists written by SPARQL UPDATE are stored as an rdf:first / rdf:rest collection, and the compiler took the collection's head for a shape ("Referenced shape … could not be resolved"). They resolve now, like JSON-LD and Turtle lists (8913e8c49).
• Whether a node conforms to a nested shape counted only Violation results. That covers sh:node, sh:not, sh:and, sh:or, sh:xone and sh:qualifiedValueShape. SHACL §3.5 counts every result, and severity only categorizes them, so a Warning nested shape that reported a result let sh:node pass and made sh:not fail. Every result counts now, through one check (4594e0dfb). The referencing shape still reports at its own severity, and a constraint that cannot run is still decided at the outermost one.