Complete portable query selection, ordering, paging and specifications

[woksin]

Scope

Make queries executable portable contracts: typed caller/context arguments, result cardinality/optionality, selection predicates and optional-filter behavior, deterministic ordering/tie-breakers, paging limits, allowed caller sorting, snapshot/live-current semantics, authorization/scope, constrained implementation and query specifications.

Non-goals

SQL/LINQ/Mongo/EF/HTTP transport syntax in the core model.

Acceptance criteria

• Existing by/same-name filters have defined compatibility lowering.
• Unsupported selection never renders as broader all/by-id data.
• Live means initial current answer plus defined current updates, not arbitrary streaming.
• Query Given/When/Then covers absence, single, ordered collection, page and live update.
• Reference, Stage and rendered backends pass common vectors.
• SQL and target languages bind through constrained realization profiles.

Child of #128; depends on ESM and constrained implementations.

[cratis-direct]

Thanks for opening this - it has been received and will be looked at.

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.

[woksin]

Work has started locally as part of the coordinated end-to-end Screenplay/Stage/Studio/CLI delivery effort tracked in #174. @woksin is coordinating implementation in dependency order with repository-specific AI corpus instructions and specifications. Existing work/PRs will be reconciled rather than duplicated. This is a kickoff, not a completion claim; focused progress, verification evidence and blockers will follow here.

[woksin]

Open decisions blocking this issue, from a triage against the source after v4.20.0. Each needs a product or architecture choice before implementation; the options and their consequences:

1. Ordering syntax and default determinism — order by <prop> [asc|desc] with an implicit tie-breaker vs ordering on the projection vs deferring to realization profiles. Note the asymmetry: the spec runner already asserts exact row order (specifications.md:108) while nothing can declare it.
2. Paging model — offset/limit (trivially portable, non-deterministic without a total order) vs cursor (deterministic, needs a stable sort key and a portable token in the ESM). Settle against Chronicle's read-model paging surface first .
3. What live promises — per-instance notifications vs whole-result replacement vs never admitting it (leaving SemanticQueryDelivery.Live permanently unreachable, which is honest but makes criterion 3 unsatisfiable).
   A grounded first slice exists: admit filter as an equality-conjunction selection with defined lowering, ordering and paging excluded — C/M.

[woksin]

Ruled and recorded as accepted decision 0010 (PR #255): mirror Arc — page number plus page size, one caller-selected sort field and direction, live queries deliver change sets; results compare unordered unless the query declares order by. First increment: collection queries with equality filters. Rendering stays Cratis/Stage#58.