Document measured milestones and add reproducible architecture experiments

Author: Paul Meng

CHANGELOG.md

@@ -8,6 +8,7 @@
 - Keep SQL constants out of the source-field namespace, apply FROM aliases to stdin consistently with files, and fix duplicate-alias full-sort/Top-N binding and a Top-N panic. Accept following clauses after IN, postfix and CAST expressions.
 - Add a same-engine fresh/reused-plan diagnostic and a bounded fixed-schema external-sort example with temporary-disk quotas and exact-output validation. Retain both as experiments: measurements do not justify a production session API, and production spilling still needs lossless dynamic-value storage and shared query accounting.
 - Add generated cross-path correctness checks and a generated conformance index checked in CI. Runtime numbers remain Int32/Float32.
+- Publish reproducible CLI, lifecycle, kernel and external-sort runners with independent answer checks, immutable manifests and archived source/binary identities. Record the completed plan, [measured adoption decisions](docs/performance-execution-2026-09-06.md), and a proposed [Int64/Float64 compatibility contract](docs/numeric-migration.md).
 
 ## Unreleased — correctness, performance, and documentation audit (2026-09-06)
 

README.md

@@ -21,6 +21,8 @@ logq's streaming queries used 8–9 MiB peak RSS in that run. Subsequent executi
 changes are measured in the September 5 [performance results](docs/performance-2026-09-05.md),
 [expanded workloads](docs/performance-expansion-2026-09-05.md), and
 [operator and file controls](docs/performance-next-milestones-2026-09-05.md).
+The September 6 [execution milestones](docs/performance-execution-2026-09-06.md)
+cover nested pruning, batch output, arithmetic, plan reuse, and external sorting.
 See the [benchmark guide](docs/benchmarks.md) for versions, methodology, and limitations.
 
 ## Supported Log Formats
@@ -247,10 +249,17 @@ from it
 select approx_count_distinct(user_agent) from it
 ```
 
-`HAVING` currently refers to aggregate output aliases: use `having cnt > 10`
-with `count(*) as cnt`. Writing the aggregate call again in HAVING is unsupported.
-`GROUP BY` also requires at least one aggregate expression; use `SELECT DISTINCT`
-when only distinct keys are needed.
+`HAVING` accepts aggregate aliases and aggregate calls, including aggregates not
+returned by SELECT. For example, `select category from it group by category
+having sum(score) > 25` filters groups without adding the sum to the output.
+Without an explicit GROUP BY, SELECT must itself contain an aggregate:
+`select count(*) as n from it having count(*) > 0` is supported.
+`GROUP BY` requires an aggregate in SELECT or HAVING; use `SELECT DISTINCT`
+when only distinct keys are needed. See the [executable SQL examples](tests/conformance/README.md).
+
+Numeric equality currently distinguishes integers from floats. SUM returns a
+float, so use `having sum(score) = 25.0` for equality; ordered comparisons such
+as `sum(score) > 25` compare across numeric types.
 
 ### ORDER BY and LIMIT
 

docs/architecture.md

@@ -80,7 +80,14 @@ Non-correlated subqueries are planned recursively with the same source registry.
 
 The logical layer distinguishes value-producing `Expression` from boolean
 `Formula`. Physical conversion in `logical/types.rs` builds execution nodes and
-places generated constant bindings in a `Variables` map.
+keeps literals as constant values, so JSON fields cannot shadow SQL constants.
+
+`logical/having.rs` binds aggregate calls in HAVING to aggregate outputs before
+ordinary planning. It reuses unambiguous SELECT aggregates or adds collision-free
+hidden aggregates, then removes hidden outputs after HAVING and before
+DISTINCT/ORDER/LIMIT. Nested aggregate calls are rejected. HAVING-only aggregates
+require explicit GROUP BY when SELECT contains no aggregate, matching the current
+grouped-projection subset rather than silently discarding SELECT expressions.
 
 ### 4. Pipeline Selection (`execution/types.rs`)
 
@@ -90,8 +97,11 @@ tree. Eligible subtrees use columnar operators. Unsupported parents can still
 consume a batch child through `BatchToRowAdapter`.
 
 Fixed-format files support typed batch scans. JSONL batching requires a known set
-of required root fields, which can be empty for `count(*)`; nested selected
-values use dynamic `Value` storage. Bare scans, stdin, table bindings, regex
+of required root fields, which can be empty for `count(*)`. Required object paths
+prune unreferenced nested siblings while preserving full consumed-line validation.
+Whole-object references override narrower masks; array/index/wildcard and scoped
+shapes retain their safe full-value fallback. Nested selected values still use
+dynamic `Value` storage. Bare scans, stdin, table bindings, regex
 formats, joins, set operations, and some expression/path shapes use row
 operators. Prefix LIMIT paths preserve demand-driven parsing and expression
 evaluation so they need not read later invalid rows.
@@ -125,6 +135,19 @@ to avoid converting rejected rows back into records. Supported expressions bind
 function handles for repeated evaluation. Typed kernels operate on contiguous
 numeric data and validity bitmaps; mixed values retain scalar semantics.
 
+JSON/NDJSON consume the selected batch stream directly, borrowing string and
+mixed-value cells instead of rebuilding a map per output row. The row API, CSV
+and table consumers still use `BatchToRowAdapter` as needed. Both result interfaces
+share pipeline selection, LIMIT guards and the query memory tracker. Duplicate
+output names use the last occurrence consistently in projection, predicates,
+sorting and serialization.
+
+Trusted Float32 arithmetic can produce a typed output column directly for a
+left-associated chain of addition by constants/root Float32 columns and
+multiplication by Float32 constants. Every operation retains f32 rounding;
+custom functions, integer overflow-aware arithmetic and unsupported trees use
+the original evaluation path.
+
 | Operation | Retained state |
 | --- | --- |
 | Scan/filter/project/limit | Current input buffers and batches; queued batches for parallel scans |
@@ -203,6 +226,12 @@ floats and may lose precision. Large identifiers should be stored as strings.
 Integer arithmetic uses checked operations so overflow is an error in both
 debug and release builds.
 
+Equality distinguishes Int32 from Float32, while ordered comparisons compare
+across numeric types. For example, SUM returns a float and `SUM(x) = 5.0`
+differs from `SUM(x) = 5`. The [numeric migration proposal](numeric-migration.md)
+specifies the compatibility work required for a future Int64/Float64 runtime;
+it does not change the current representation.
+
 NULL means an unknown value; MISSING means an absent field. Both participate in
 three-valued arithmetic/comparison logic, and `IS NULL`/`IS MISSING` distinguish
 them. Boolean logic includes rules such as `NULL AND FALSE = FALSE` and