## Summary Follow-ups identified by the `mr-complexity-reviewer` review of !11 (user-facing CONSTRUCT query support), deliberately deferred out of that MR to keep it focused. None of these are regressions introduced by !11 — see notes per item. ## 1. `order_by()` + `limit()` + a collection field silently selects arbitrary subjects (needs design discussion) For a CONSTRUCT query with a collection field, `limit()` (when a grounding pattern is present) pushes LIMIT into an inner `SELECT DISTINCT ?s ... LIMIT n` subquery that has no `ORDER BY` of its own — the outer `ORDER BY` is appended *after* that subquery has already picked which `n` subjects to return: ```sparql WHERE { { SELECT DISTINCT ?s WHERE { ... } LIMIT 2 } # arbitrary 2 subjects ... } ORDER BY ASC(?genres·inner) # orders the output, not the selection ``` So `Query(BookWithGenres).construct().order_by("genres").limit(2)` returns 2 *arbitrary* books, not "the 2 with the lowest genre" — silently wrong, no error. For CONSTRUCT specifically the outer `ORDER BY` is additionally a no-op (the result is a triple set with no inherent order). **Not a regression**: the reviewer confirmed the identical shape exists on `main` today for the equivalent `SELECT` query (`Query(BookWithGenres).order_by("genres").limit(2).compile()`), and there it's arguably worse — the emitted `ORDER BY ASC(?genres)` references a variable that's neither grouped nor aggregated. Needs a design decision (not a quick fix) along the lines already used elsewhere in `construct()`: either push `ORDER BY` into the grounding subquery too (correctness fix, more compiler complexity), or reject `order_by()` + `limit()`/`offset()` + collection-field combinations with a `QueryError` (consistent with `construct()`'s existing "fail loudly instead of silently wrong" philosophy — see the six existing rejections in `ConstructForm._validate()`). Whichever direction is chosen for CONSTRUCT, consider whether the same fix should extend to `SELECT`. ## 2. Simplification: `ConstructForm` duplicates existing SELECT-path helpers - `ConstructForm._assemble()` (`sparqlmojo/orm/query/forms.py`) is functionally identical to `QueryClausesMixin._assemble_query_string()` — confirmed by construction (`f._assemble(q, tmpl, where) == q._assemble_query_string(f"CONSTRUCT {{\n {tmpl}\n}}", where)`). Could call the existing helper with the CONSTRUCT template passed as the "select clause" instead of maintaining a second copy. - `ConstructForm._append_modifiers()` largely duplicates `QueryClausesMixin._append_query_modifiers()` — the only real differences are ORDER BY variable resolution (`triple_object_var()` vs. `flattened_order_var()`) and skipping GROUP BY/DISTINCT (both already parameterizable on the existing method). Collapsing this keeps future LIMIT/OFFSET/ORDER BY changes in one place instead of two that can drift. ## 3. Test coverage gaps (combinations that already work correctly, just unasserted) - `construct()` + `from_graph()`/`from_named()` — compiles correctly (emits `FROM`/`FROM NAMED`, wraps collection triples in `GRAPH`), nothing asserts it. - Grounding via `filter_by()` on `SubjectField` and via `values({"s": [...]})` — only the `IRIField`-default grounding path (`BookWithGenres`) is tested; `_has_grounding_patterns_for_limit_subquery()` has four distinct grounding sources. - `filter_by()` on an IRI field under `construct()` — the WHERE clause emits `?s p <IRI> .` plus `BIND(<IRI> AS ?field)`, and the CONSTRUCT template relies on that BIND to resolve `?field`. Load-bearing, undocumented by any test. - `filter_lang()` on a *non*-collection field under `construct()` — explicitly allowed (only the collection-field case is rejected), untested. ## 4. Minor nits - A subject-only model (no other fields) compiles to `CONSTRUCT {\n \n}` — legal SPARQL, silently returns an empty graph. Given this feature's own bar for failing loudly, consider a guard or at least a pinning test. - `distinct()` is silently a no-op under `construct()` (harmless — a constructed graph already dedupes — but inconsistent with the six other combinations that reject loudly instead of silently ignoring). - `SelectForm()`/`ConstructForm()` instances are stateless; could be module-level singletons instead of a fresh allocation per `Query`. - No dedicated user-facing docs page for CONSTRUCT support (unlike `docs/collection-fields.md`, `docs/property-paths.md`, `docs/values-clause.md`) — currently only a CHANGELOG entry and docstrings. A `docs/construct-queries.md` would match the established per-feature-guide pattern and is a natural home for documenting item 1's caveat once resolved. ## Context Raised during independent review of !63 / MR !11. See MR discussion for the full review report.