feat(stack-encrypt)!: declare each operator once and prepare a query once

Every operator is declared once, with its type, its arity and its wire
name; the dynamic enum `Op` (`OpSpec` until now, kept as a deprecated
alias) is generated from that list. Each index declares the operators it
answers once, and a plan reads that declaration: a field declares at most
one index per operator, so `(Ore, Ope)` is refused when the plan is built,
on both paths. The second order term cost a write and told anyone who read
the column how its values order.

`Supports::check`, `verifier` and `admit` are one `prepare`, called once
per query before any keyset is resolved, and the refusals a query makes
are written once, in `sem::query`, for the typed chain and the dynamic
path. The typed chain now refuses text with no normal form before the
keyset is resolved, as the binding did; the conformance rows that
recorded the gap are flipped. `op::Matches` has no case parameter: case
is the match index's configuration alone.

Closes #1279
Closes #1318
Closes #1317
Closes #1321
Closes #1233

Author: coderdan

conformance/stack-encrypt/query-refusals-contract.md

@@ -74,47 +74,42 @@ same diagnostic, and observes that no keyset lookup, data-key generation or
 retrieval happens on any path. Go's deterministic guest makes no network
 request; that is not a logical key-call count.
 
-The operator vocabulary is closed in Rust (`OpSpec`), so the unknown
+The operator vocabulary is closed in Rust (`dynamic::Op`), so the unknown
 operator case is observed at the binding boundary alone; the Rust runner
 checks that the case expects exactly that and continues.
 
 ## The typed chain
 
 `typed` records how the typed Rust query chain answers the same query, for
 the queries it can spell (text on the text fields, a `uint32` range under
-ORE and an `int128` range under OPE): `before_keyset`, `after_keyset` or `none`. The Rust runner
-builds a one-field typed plan with the index that answers the operator,
-runs the chain under a keyset named for the case, and counts the keyset
-load. A refusal before the load is `before_keyset`; one after it is
-`after_keyset`. The error code must equal the binding's.
-
-Today the two paths refuse the same inputs with the same codes, but not at
-the same stage:
-
-| Refusal | Binding (`check_query`, `query_term`) | Typed chain |
-|---|---|---|
-| Match text with no token or no normal form | before any keyset | before any keyset |
-| Equality text with no normal form | before any keyset | after the keyset is loaded |
-| Order text with no normal form (ORE, OPE) | before any keyset | after the keyset is loaded |
-| Block ORE text too long or ending in NUL | before any keyset | after the keyset is loaded |
-
-The binding checks every index's value refusals in `check_input`; the
-typed chain's `Supports::check` runs before the keyset for the match index
-alone, and the other indexes refuse the value when they derive its term.
-This profile pins the current stage as a documented difference. Moving the
-typed refusals earlier is step 2 of "The engine's rules, and the order of
-the work" in the API plan (`docs/plans/2026-10-24-stack-encrypt-api-plan.md`),
-which runs every check that needs no key before a key is used. When it
-lands, the `typed` entries change to `before_keyset` on purpose, and this
-table with them.
+ORE and an `int128` range under OPE): `before_keyset`, `after_keyset` or
+`none`. The Rust runner builds a one-field typed plan with the index that
+answers the operator, runs the chain under a keyset named for the case, and
+counts the keyset load. A refusal before the load is `before_keyset`; one
+after it is `after_keyset`. The error code must equal the binding's.
+
+The two paths refuse the same inputs with the same codes at the same
+stage: before any keyset is resolved. Every `typed` entry of a refused case
+is `before_keyset`. Both paths call the one set of rules in the engine's
+`sem::query` module: the typed chain through each index's
+`Supports::prepare`, and the binding through `check_query`, `query_term`
+and `verify`. A rule written there is a rule on both paths, and a rule
+written anywhere else is a drift this profile fails on.
+
+Until the API plan's step 2 ("The engine's rules, and the order of the
+work", `docs/plans/2026-10-24-stack-encrypt-api-plan.md`) the typed chain
+refused equality text with no normal form, order text with no normal form
+and block ORE text over its limit only after the keyset was loaded, and the
+`typed` entries of those rows said `after_keyset`. They were flipped on
+purpose with that step.
 
 ## Scope and remaining work
 
 The corpus covers scalar operators under `NoTargets`. Match options the
 index cannot use (an n-gram length of zero) are a declaration refusal, in
 `v1/record-declarations-v1.cases.json` (`match-invalid-ngram-zero`). JSON document
-operators against JSON fields, EQL target refusals, `target_limit` inputs and the match-case
-mismatch only the typed chain can express remain with their existing
-tests. The match-case mismatch goes away with the API plan's step 3,
-which removes `Matches`'s case parameter and `.via`. The Go runner does not exercise generated query methods; those keep
+operators against JSON fields, EQL target refusals and `target_limit`
+inputs remain with their existing tests. The match-case mismatch is gone:
+`Matches` has no case parameter, and a match index's configuration is the
+one place case is declared. The Go runner does not exercise generated query methods; those keep
 their fixture tests. No existing test is removed.

conformance/stack-encrypt/v1/record-query-refusals-v1.cases.json

@@ -1299,7 +1299,7 @@
         "code": "stack_encrypt::term_normalize"
       },
       "typed": {
-        "refusal": "after_keyset"
+        "refusal": "before_keyset"
       }
     },
     {
@@ -1316,7 +1316,7 @@
         "code": "stack_encrypt::term_normalize"
       },
       "typed": {
-        "refusal": "after_keyset"
+        "refusal": "before_keyset"
       }
     },
     {
@@ -1342,7 +1342,7 @@
         "code": "stack_encrypt::term_normalize"
       },
       "typed": {
-        "refusal": "after_keyset"
+        "refusal": "before_keyset"
       }
     },
     {
@@ -1368,7 +1368,7 @@
         "code": "stack_encrypt::term_normalize"
       },
       "typed": {
-        "refusal": "after_keyset"
+        "refusal": "before_keyset"
       }
     },
     {
@@ -1385,7 +1385,7 @@
         "code": "stack_encrypt::ore_block_too_long"
       },
       "typed": {
-        "refusal": "after_keyset"
+        "refusal": "before_keyset"
       }
     },
     {
@@ -1402,7 +1402,7 @@
         "code": "stack_encrypt::ore_block_trailing_nul"
       },
       "typed": {
-        "refusal": "after_keyset"
+        "refusal": "before_keyset"
       }
     },
     {
@@ -1428,7 +1428,7 @@
         "code": "stack_encrypt::ore_block_trailing_nul"
       },
       "typed": {
-        "refusal": "after_keyset"
+        "refusal": "before_keyset"
       }
     },
     {
@@ -1454,7 +1454,7 @@
         "code": "stack_encrypt::ore_block_too_long"
       },
       "typed": {
-        "refusal": "after_keyset"
+        "refusal": "before_keyset"
       }
     },
     {
@@ -1480,7 +1480,7 @@
         "code": "stack_encrypt::ore_block_too_long"
       },
       "typed": {
-        "refusal": "after_keyset"
+        "refusal": "before_keyset"
       }
     },
     {
@@ -1506,7 +1506,7 @@
         "code": "stack_encrypt::ore_block_trailing_nul"
       },
       "typed": {
-        "refusal": "after_keyset"
+        "refusal": "before_keyset"
       }
     },
     {

docs/plans/2026-10-24-stack-encrypt-api-plan.md

@@ -2001,7 +2001,7 @@ Decided on 7 November 2026, as area two of the query design review.
   does not know which bound the caller meant. The `InvertedRange` error
   asked for in #1279 predates that commit and is dropped.
 - **Stored format and wire.** Unchanged. A query sends the operator's wire name. That name does not change.
-- **Tracked in.** Issues #1318 and #1279 are open. Issues #1317, #1319, and #1321 are open. Issue #1320, the inverted-range rule, is open. This plan's decision supersedes it, so it should be closed.
+- **Tracked in.** The pull request for #1279, #1318, #1317, #1321 and #1233 does this area's `Op` enum and the `Matches` case change. Issues #1319 and #1321 were open; #1321 closes with that pull request. Issue #1320, the inverted-range rule, is closed: this plan's decision superseded it.
 - **Finished when** these are all true:
   - the dynamic enum is generated from the `op` types;
   - `Matches` has no type parameter;
@@ -2130,7 +2130,7 @@ review. The rules are the query artifact's.
   `.via`. The `MatchConfig` documentation says a field and its query agree "by
   construction". That is true only for one-value plans today. Both
   are amended, not contradicted in silence.
-- **Tracked in.** Issues #1318 and #1279 are open. Issue #1233 is open: refuse a second order index. That is rule 2. Issues #1317 and #1321 are open.
+- **Tracked in.** Steps 1 and 2 are one pull request, which closes #1279, #1318, #1317, #1321 and #1233 (rule 2, the second order index). It brings `prepare`, the `sem::query` rules and `Op`, and drops `Matches`'s case parameter; the analyzer of "Match configuration: one analyzer" is its own work (#1319). Steps 3 and 4 are #1486 and #1488.
 - **Finished when** these are all true:
   - every index's operators appear in one declaration, and a test shows
     the typed and dynamic lookups agree on every index;

languages/golang/CHANGELOG.md

@@ -12,6 +12,16 @@ listed under **Breaking**. Releases are tagged `languages/golang/vX.Y.Z`.
 
 ### Breaking
 
+- **A field declares at most one order index** (#1233). The engine refuses
+  a field tagged `index=ore;ope` (or `ore;ore_block`), so `stashgen` now
+  reports it as a field error at generate time, and a plan built by hand
+  with both is refused by the guest (`overlapping_outputs`) before any key
+  is requested. Before, the field stored both terms and every query used
+  the ORE one; the OPE term cost a write and told anyone who read the
+  column how its values order. `stashgen`'s notice for a second order index
+  is gone with the case it described; the notice for an order index on
+  bytes stays.
+
 - **`Cipher.Extend` is now `Cipher.Scope`, and `Cipher.Bind` is new**
   (#1487). A scope narrows the data and the queries over it. A binding ties
   a ciphertext to its row: it is in the stored context, after every scope,

languages/golang/encrypt/guest/src/ops.rs

@@ -250,7 +250,7 @@ where
 /// The input is one value for every operator but `between`, whose input is
 /// a list of two, low then high, and a document's operators, whose input
 /// is an object of named inputs (`{"json"}`, `{"path", "json"}`, ...; see
-/// [`dynamic::OpSpec::input`]). A value is read as the field's declared
+/// [`dynamic::Op::input`]). A value is read as the field's declared
 /// kind first, so a host's float `34.0` queries a `uint64` field. A field
 /// with indexes derives the term of the index that answers the operator,
 /// as bytes; `between` derives one per bound, as a list of two. A field
@@ -390,18 +390,18 @@ fn parse_field<'f>(plan: &Bytes, field: &'f [u8]) -> Result<(dynamic::record::Pl
 }
 
 /// The plan, field name and operator a query names: [`parse_field`]'s two,
-/// and the operator one the engine knows ([`dynamic::OpSpec::parse`]); an
+/// and the operator one the engine knows ([`dynamic::Op::parse`]); an
 /// unknown operator is refused naming the field, as an operator the field
 /// does not answer is.
 fn parse_query<'f>(
     plan: &Bytes,
     field: &'f [u8],
     operator: &[u8],
-) -> Result<(dynamic::record::Plan, &'f str, dynamic::OpSpec), u32> {
+) -> Result<(dynamic::record::Plan, &'f str, dynamic::Op), u32> {
     let (plan, field) = parse_field(plan, field)?;
     let operator = std::str::from_utf8(operator)
         .ok()
-        .and_then(dynamic::OpSpec::parse)
+        .and_then(dynamic::Op::parse)
         .ok_or_else(|| {
             fail_dynamic(&dynamic::Error::Source {
                 field: Some(field.to_owned()),
@@ -767,8 +767,8 @@ mod tests {
     #[test]
     fn an_encoded_answer_has_no_spare_capacity() {
         let entries = [
-            dynamic::OperatorEntry::new(dynamic::OpSpec::Eq, &IndexSpec::Equality),
-            dynamic::OperatorEntry::new(dynamic::OpSpec::Between, &IndexSpec::Ope),
+            dynamic::OperatorEntry::new(dynamic::Op::Eq, &IndexSpec::Equality),
+            dynamic::OperatorEntry::new(dynamic::Op::Between, &IndexSpec::Ope),
         ];
         for out in [
             encode_answer(&vec![true, false, true]),

languages/golang/encrypt/guest/src/targets.rs

@@ -288,7 +288,7 @@ mod tests {
     #[cfg(feature = "eql")]
     #[test]
     fn a_document_names_the_leaf_element_and_predicate_domains() {
-        use stack_encrypt::dynamic::{self, record, OpSpec};
+        use stack_encrypt::dynamic::{self, record, Op};
         let targets = resolver().targets();
         let document = targets
             .iter()
@@ -307,7 +307,7 @@ mod tests {
             Some("eql_v4.query_json_predicate")
         );
         assert!(
-            document.operators().contains(&OpSpec::Match),
+            document.operators().contains(&Op::Match),
             "the type lists match: {:?}",
             document.operators()
         );
@@ -331,12 +331,12 @@ mod tests {
                 .collect::<Vec<_>>()
         };
         let ordered = field_operators(&["$.contacts[*].relationship"]);
-        for present in [OpSpec::ElementMatch, OpSpec::Match] {
+        for present in [Op::ElementMatch, Op::Match] {
             assert!(ordered.contains(&present), "{present:?}: {ordered:?}");
         }
         let unordered = field_operators(&[]);
-        assert!(unordered.contains(&OpSpec::Match), "{unordered:?}");
-        assert!(!unordered.contains(&OpSpec::ElementMatch), "{unordered:?}");
+        assert!(unordered.contains(&Op::Match), "{unordered:?}");
+        assert!(!unordered.contains(&Op::ElementMatch), "{unordered:?}");
     }
 
     #[cfg(feature = "eql")]