[Pama-Lee]

Before: several ordinary rules returned a confident, wrong decision with no error. Checked against the released 0.9.0 CLI and server:

• applicant.age < 18 || blacklisted == true with blacklisted: true and no age returned APPROVED. The missing field made the whole condition false, so a blacklisted applicant went through.
• In jev-routing, renaming jev.intent.confidence to jev.intent.confidense passed ordo validate and ordo lint. At run time the field is always missing, so every "not a refund" message falls into the refund path.
• An input field called data or item couldn't be read: data.x == 1 was always false.
• max(scores) == 100 was always false, because max/min given one array returned the array itself.
• "a\sb" turned into asb, so regexes like "\d+" silently matched the wrong thing.
• ordo impact ... | head panicked (exit 101).

After:

• A missing field makes only its own comparison unknown. A true side of || still matches, a false side of && still fails, and anything still unknown stays false as before. This only runs after a missing-field error, so the normal path costs nothing extra.
• With an input schema, ordo validate / ordo lint report each field the rules read that the schema does not declare ([intent] jev.intent.confidense is not in the input schema). Variables ($x) and external data ($data.x) are skipped. An object with no listed fields accepts any sub-path.
• data.x and item.x read the input field when it exists (otherwise they behave as before).
• max(arr) / min(arr) return the largest/smallest element (null for an empty array).
• Unknown escapes keep their backslash. \n \t \r \\ \" \' are unchanged.
• The CLI exits quietly on a closed pipe.
• Docs (en + zh): missing-field wording in expression syntax, rule structure and guard; a short Strings section on escapes; max(arr) in built-in functions.

How: Kleene-style evaluation in RuleExecutor on the lenient missing-field path; undeclared_fields() in rule/input_schema.rs, called by the CLI validator; prefix fallback in Context::get; a shared extreme() for min/max; one parser match arm; SIGPIPE reset in the CLI main.

Tested on the merged tree: cargo fmt --check, cargo clippy --all-targets --all-features -D warnings and cargo test --all-features --workspace all pass, with new tests for each case. All four rule packs validate and all their tests pass. Earlier, 6000 concurrent execute calls against the built server all returned 200.

Not covered: the binary .ordo executor still treats a missing field as making the whole condition false.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
ordo_docs	Ready	Preview	Oct 18, 2026 6:04am UTC

[Pama-Lee]

Dependency audit failed on RUSTSEC-2026-0349, a rustls 0.23.45 advisory published after main last ran CI. It isn't caused by this PR's changes, and main would fail the same check. b57b65b bumps rustls to 0.23.46 in Cargo.lock. Clippy and all workspace tests still pass with it.

[Pama-Lee]

After the 0.23.46 bump, Dependency audit still fails on rustls 0.21.12 (RUSTSEC-2026-0346 and RUSTSEC-2026-0349). That version comes in through tonic 0.10's TLS stack (ordo-grpc / ordo-server), and main has exactly the same lock entry, so this PR doesn't cause it. The fixes only exist in rustls 0.23.46+, which means migrating to tonic/hyper 1.x. That's the same migration deny.toml already tracks for RUSTSEC-2026-0258.

Neither advisory looks reachable here. 0346 only affects Debug output of a custom ClientSessionStore, and Ordo has none. 0349 can drop post-quantum key exchange on resumed client connections, but classical TLS is not weakened. I haven't added them to the deny.toml ignore list: the owner needs to decide that.