[P1] The execution parser disagrees with published precedence #12

Reproduced during the 2026-09-04 language review at a20753c6cff96ee86758744e227a04460234a832. Priority: P1.

let n = 0
true || false && (n = 1)
n

The result is 1. Under the published grammar, && binds more tightly than ||, so the entire right-hand side should be skipped and n should remain 0. A granted tool.call in place of the assignment actually executes. This reproduces in an optimized build.

The pure-value difference is equally direct:

true || false && false       // observed: false
true || (false && false)     // observed: true

The canonical parser expresses the expected hierarchy in profile.rs. The inherited parser's short-circuit handling patches an existing ShortCircuitEnd without checking its originating operator's precedence; see parser.rs.

There is a second precedence mismatch in ordinary comparisons: true == 2 > 1 yields false, while true == (2 > 1) yields true. The workflow grammar assigns comparisons higher precedence than equality, whereas the VM's operator table groups them together.

Treat precedence and associativity as executable contracts. Generate tests for every pair of operators, plus side-effect counters on both sides of logical operators. The durable fix is to derive execution from the canonical parse tree or otherwise share its binding-power rules. Admission plus a second parser's acceptance is not sufficient.

Acceptance: implement the described correction, publish the resulting language contract, and add focused regression coverage including applicable capability, streaming-parser, and resource-limit cases.

Fix and executable regressions: PR #19. Workspace tests, explicit vendor suites, formatting, strict Clippy, and the Linux ARM64/RISC-V and Windows GNU compile checks pass locally. All GitHub Actions checks pass on f1e775f, including Linux tests, fuzzing, AddressSanitizer, and Miri. This issue remains open until the fix is merged.