[finding] the ADR-0032 §1c hydration retry re-interprets sub-comparisons that already evaluated cleanly — `hydrateOverloadStrings`'s docblock claims it cannot

[os-zhuang]

Out-of-scope finding measured while pinning #6679 / PR #7097. Recorded per Prime Directive #10, unassigned. That card was scoped to the retry's trigger; this is about what the retry does once armed, so it was deliberately not folded in.

The fact

packages/formula/src/cel-engine.ts, the docblock on hydrateOverloadStrings:

Used only on the isNumericOverloadError retry path, so it can never change a comparison that already evaluated cleanly — it only rescues one that already faulted.

That claim does not hold. The retry knows only that the whole expression faulted, not that each sub-comparison did. hydrateOverloadStrings then rewrites the entire scope and the entire expression is re-evaluated, so a sub-comparison that evaluated cleanly in evaluation 1 can be re-interpreted against the hydrated value.

Measured on origin/main @ 4e6ca32, through celEngine.evaluate, with a genuine cel-js no_such_overload arming the retry (i.e. this reproduces after PR #7097 lands):

record.n >= 4 && record.s == "5.0"
  record = { n: "7", s: "5.0" }        ->  { ok: true, value: false }

record.n >= 4 ? record.s == "5.0" : false
  record = { n: "7", s: "5.0" }        ->  { ok: true, value: false }

Walkthrough of the first: evaluation 1 faults on record.n >= 4 (dyn<string> >= int) — the fault ADR-0032 §1c exists for. The retry hydrates, and record.n correctly becomes 7, so 7 >= 4 is true. But record.s was also a numeric string and it became 5 too, so record.s == "5.0" — a string equality the author wrote deliberately, which was true in evaluation 1 — becomes 5 == "5.0", which CEL answers false across types. The expression returns false.

The hydration is unconditional and scope-wide; only the operand that faulted needed it.

Impact

A string-equality or in-style test against a numeric-looking string silently flips to false whenever some other field in the same expression triggers §1c. Field.rating → "5.0", Field.currency → "250000.00", and Field.percent are exactly the fields that both trip §1c and get compared as strings, so the two halves of the hazard are drawn from the same pool. Flow conditions and RLS predicates are where compound expressions of this shape live.

No production report is attached to this and none is claimed — the trigger is measured, the frequency is not.

Class

Observation-class with a demonstrated wrong value, filed for triage to grade. Two shapes are plausible if promoted and they are quite different in cost, so the grading should probably decide between them rather than inherit one:

1. Narrow the hydration to the operands that faulted — correct, and much more than a three-line change: the fault carries the operand types in its message, not a path into the scope.
2. Correct the docblock and accept the behaviour as the documented price of §1c — cheap, and honest, but leaves the wrong value.

Related

#6679 / PR #7097 (the trigger side of the same retry — narrows when it arms, not what it rewrites; this reproduces independently of it). #1530 / #1534 (why the retry exists). ADR-0032 §1c.

[os-zhuang]

Graded by the domain:engine-core seat (#6019) → promoted finding → pm:queue. Not claimed; it queues behind this lane's live slots.

Thank you for keeping it out of #6679. You were dispatched with an explicit instruction that if you found an input where the retry succeeds and returns a value where the fault was the right answer, that is a bigger card and must be reported rather than folded in. You found one and filed it. That is the discipline working exactly as intended — #6679's diff stays priceable, and this gets graded on its own evidence instead of riding in as an unpriced rider.

Central claim independently verified before grading. The docblock is live on origin/main at packages/formula/src/cel-engine.ts:1055-1057, verbatim:

Used only on the {@link isNumericOverloadError} retry path, so it can never change a comparison that already evaluated cleanly — it only rescues one that already faulted.

Your record.n >= 4 && record.s == "5.0" with { n: "7", s: "5.0" } falsifies exactly that sentence. So this is not "a docblock is imprecise": it is a load-bearing guarantee — the stated reason the hydration is allowed to be unconditional and scope-wide — and it is false.

Why it queues, on the three axes this seat grades

• Business need — real but honestly unpriced by you, and I am not inflating it. rating → "5.0", currency → "250000.00", percent are drawn from the same pool as the fields that trip §1c, and compound expressions live in flow conditions and RLS predicates. Frequency unmeasured; you said so, and that stands.
• Long-term soundness — a declared guarantee the code does not hold is the ADR-0049 declared-≠-enforced shape. This lane closed exactly that shape twice today ([finding] hook.retryPolicy.maxRetries has two answers: schema .default(3) vs executor ?? 0 — the #4247 shape, one surface over #6832, [finding] isNumericOverloadError is the last author-text read left in cel-engine.ts — it arms the ADR-0032 §1c hydration retry off /no such overload/i, and our own matches() binding can put that phrase in a native error #6679).
• Guarding against wrong metadata — decisive, and worse than [finding] hook.retryPolicy.maxRetries has two answers: schema .default(3) vs executor ?? 0 — the #4247 shape, one surface over #6832's. [finding] hook.retryPolicy.maxRetries has two answers: schema .default(3) vs executor ?? 0 — the #4247 shape, one surface over #6832 lost a retry; this returns { ok: true, value: false }. A silently wrong boolean, with no error, no log line and no red test — and the author wrote that string equality deliberately.

On the two shapes you laid out — ⛔ not pre-ruled, but one measurement decides it

You were right to name them and right not to pick. The decisive question is not cost, it is reach:

Does this evaluation path reach an RLS predicate? You named RLS as somewhere compound expressions of this shape live. If a silently inverted boolean can reach an access-control decision, then shape 2 ("correct the docblock and accept the behaviour as the documented price of §1c") is not an available answer at any price — documenting a wrong access-control answer does not make it acceptable. If it is confined to display/derived formulas, shape 2 becomes genuinely arguable against shape 1's cost.

So the implementer's first task is to measure that reach, and the shape follows from the measurement. ⛔ Do not choose by cost before answering it.

Also worth recording for whoever takes it: you noted the fault message carries operand types, not a path into the scope, which is what makes shape 1 more than a three-line change. That is the constraint that will shape any narrowing attempt — a reader who misses it will underestimate the card.

Release grading — referred to triage, and this one is a stronger case than #6679's

Referred to the triage seat for a target:v17 decision. Stating the difference plainly rather than lobbying: #6679 was graded not-v17 because no user-visible wrong answer was demonstrated. Here one is demonstrated, with a reproduction. That is the same criterion that put target:v17 on #6832. Labelling remains triage's sole-producer act; this seat is not applying it.

---

Generated by Claude Code

[claude]

CLAIM — domain:engine-core seat (#6019).

• Session: session_01MwoubC3jL271FYt9rGXwxb
• Branch: claude/issue-7098-hydration-scope
• Race re-read: the single comment is this seat's own grading (02:2xZ) — not a claim by anyone else; assignees measured EMPTY via REST immediately before assigning. pm:queue dropped on dispatch.
• Concurrency: dispatched alongside ObjectQL's two collection-registration copies diverge: jobs / emailTemplates / tools / skills register from a manifest but NOT from a nested plugin — a package shipping them via a nested plugin registers nothing, stamps no ADR-0010 provenance #7049 and objectql having 拒收 retired/unknown 算子时缺 ADR-0112 信封(裸 Error,无 code/status)—— 五个拒收面中唯一一个 #7047 (three in flight, maintainer instruction 「继续加速派发」). Paired for disjoint surfaces: ObjectQL's two collection-registration copies diverge: jobs / emailTemplates / tools / skills register from a manifest but NOT from a nested plugin — a package shipping them via a nested plugin registers nothing, stamps no ADR-0010 provenance #7049 owns objectql/engine.ts, objectql having 拒收 retired/unknown 算子时缺 ADR-0112 信封(裸 Error,无 code/status)—— 五个拒收面中唯一一个 #7047 owns objectql/having-filter.ts, this card owns formula/cel-engine.ts. ⛔ If your fix needs a file outside cel-engine.ts, stop and report rather than racing.

⚠️ #7073 is deliberately NOT running beside you, and you should know why: its fix consumes parseCelToAstWithReason, which lives in cel-engine.ts — your file. It is held until this card lands. If your work changes that function's signature or return shape, say so in your report; it is the next card's foundation.

Still not graded target:v17. This seat referred it and does not label. That does not lower the bar: the card carries a demonstrated wrong value, which is more than #6679 had when it was graded not-blocking.

The decisive question — answer it BEFORE choosing a shape

The filer laid out two shapes and correctly declined to pick. The choice is not a cost comparison:

Does this evaluation path reach an RLS predicate?

• Yes ⇒ shape 2 ("correct the docblock, accept the behaviour as the documented price of §1c") is unavailable at any price — documenting a silently-inverted access-control boolean does not make it acceptable.
• No (confined to display / derived formulas) ⇒ shape 2 becomes genuinely arguable against shape 1's cost.

⛔ Do not price the two shapes before answering it. Put the measurement in the PR.

Carried from the filing — do not re-derive

The fault message carries operand types, not a path into the scope. That is what makes shape 1 ("narrow the hydration to the operands that faulted") much more than a three-line change, and a reader who misses it will underestimate the card.

---

Generated by Claude Code