REVISIONS

What this covers: querying the REVISIONS entity (8 rows; label field ID).

Why you need it: list, fetch, count, and aggregate revisions; answer "which/how many/how much" questions.

Syntax:

• LIST REVISIONS [WHERE ...] [ORDER BY <FIELD> [DESC]] [LIMIT n] [OFFSET n]
• GET REVISIONS "<id>"
• COUNT REVISIONS [BY <FIELD>] [WHERE ...]
• SUM REVISIONS <NUMERIC FIELD> [BY <FIELD>] [WHERE ...]
• RESOLVE REVISIONS "<name>"
• Operators: IS, IS_NOT, CONTAINS, GT, GTE, LT, LTE; combine with AND / OR.

Returns: JSON rows plus _meta (provenance, epoch, related follow-up queries, hints).

Workflows:

1. COUNT REVISIONS - size the data before listing.

2. COUNT REVISIONS BY MODIFIED_BY then LIST REVISIONS WHERE MODIFIED_BY IS "alice@acme.com" LIMIT 10 - segment, then drill in.

3. SUM REVISIONS SIZE_BYTES BY MODIFIED_BY - aggregate by segment.

4. RESOLVE REVISIONS "<fuzzy name>" then GET REVISIONS "<canonical>" - resolve before fetching when a name lookup misses.

Constraints:

• Filter only on fields listed in HELP SCHEMA; unknown fields are hard errors.
• Enum values are exact strings (e.g. MODIFIED_BY: alice@acme.com, bob@acme.com, carol@acme.com).
• Default LIMIT is 100; count in a LIST response is not the true total.