VM: the bitwise and boolean operator families

[EvanWinget]

What changed

The bitwise family (ash, lsh, logand, logior, logxor, lognot) and the
boolean family (not, any, all) enter the spec, the reference
implementation, the vector corpus, and the diff harness. The two
families share one PR by decision (Evan, 2026-07-27): boolean is three
trivial flat-cost operators. After this PR, crypto is the only Phase 1
family left.

One new error class, shift_too_large, for a shift count whose
magnitude exceeds 65535. Shift count shape violations reuse bad_index
with substr's indices, matching the consensus oracle's identical
reporting of both.

Spec sections

VM.md section 4 (operator rows and the two prose blocks), section 5
(taxonomy rows for shift_too_large and the broadened bad_index, plus
the misleading-message caveat extending to shift counts). COSTS.md
section 1 (charge order bullets), new sections 6 and 7 (weight mapping
and condition costs renumbered to 8 and 9).

Read the commits in this order

1. Spec: the bitwise and boolean families, probed against both oracles. The semantics and cost claims, all probe-established.
   The subtle ones: the shifts' per-byte term counts the result's
   magnitude bytes rather than its encoded bytes (disambiguated by a
   result of 128, one magnitude byte but two encoding bytes), lsh
   reads its value atom unsigned so it can change a value's sign and
   magnitude, and not costs a flat 200 with no per-argument term.
2. Implement the bitwise and boolean families. Nine operators
   following the established charge-order style. The log fold reuses
   op_add's accrue-then-check loop shape. The shifts run every check
   before any charge.
3. Pin the bitwise and boolean families: 98 vectors. Every
   expectation was generated against chia-rs 0.46.0 flags 0, with ok
   cases also cross-checked against clvm 0.9.15. Budget-boundary
   vectors pin check-versus-charge order at one-unit margins.
4. Reach the bitwise and boolean families in the diff harness. New
   count distribution mirroring the substr index treatment, three new
   message mappings, and a seventh tolerated Python-oracle
   disagreement (its pair-in-count message is indistinguishable from
   pair-in-value, where consensus distinguishes them).

Verify independently

.venv/bin/pytest python/tests
.venv/bin/python tools/run_vectors.py
.venv/bin/python tools/diff_clvm.py --count 10000 --seed 20260727
.venv/bin/python tools/diff_clvm.py --count 10000 --seed 1123581321
ci/lint/lint.sh

Both 10k seeds are fresh to this PR and finish with zero failures,
with the new shift-count-conflation tolerance counter nonzero on
both. Any fresh seed should behave the same, and an unexplained
divergence fails the run loudly.

[EvanWinget]

Code review

Found 1 issue:

1. Off-by-one in the new spec text: the left-shift growth bound says "at most 8191 bytes over its input", but the true maximum is 8192. A count of 65535 bits adds up to 8192 magnitude bytes, and this PR's own vector ash_max_left_count in vectors/vm/bitwise.json shifts a 1-byte value left by 65535 and pins an 8193-byte result, a growth of 8192 bytes. The sentence backs the section 2 encodability argument, whose conclusion still holds, but the constant is falsified by the corpus in the same PR.

BitLisp/spec/VM.md

Lines 338 to 342 in c84dd93

	A left shift can grow an atom by at most 8191 bytes over its input,
	and the result charges plain malloc per byte, so the section 2
	threshold for building an atom the wire format cannot encode applies
	unchanged.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[EvanWinget]

Review disposition: the growth-bound issue is fixed in f2d5ce8. Five lower-confidence findings from the same review pass were also addressed: two inaccurate comments corrected in 3989b2a, and six vectors added in cd31a47 (the all short-one boundary, lsh's own value-check boundary pair, lsh's negative range cap, and the 0xff-padded count spellings, all established against the consensus oracle). One finding was declined: a lognot below-boundary partner at max_cost 20, which would pin only the dispatch-charge boundary already covered by dispatch.json and the logand and ash pairs.

[EvanWinget]

Upstream cross-check, performed after implementation as review evidence (reading policy guardrail: probes established the spec, source read only confirms). Against clvm_rs 0.18.0 in references/, every probe-derived claim matches the source: all ten cost constants, the shift per-byte term as value length plus result magnitude bytes (limbs_for_int is bits div_ceil 8, sign-agnostic), lsh's unsigned BigUint reading of the raw value atom, the check order (arity, value atom, count shape, count range, then cost), the inclusive 65535 cap in both directions, the count reader accepting redundant encodings within four bytes while its error text claims otherwise (the misleading message is hardcoded in i32_atom regardless of input, confirming the VM.md section 5 caveat at the source level), the log fold's per-argument check points and fold identities, lognot's formula, not's flat 200 with no per-argument term, and any/all charging per argument with no node checks. Two structural differences with no observable effect: clvm_rs folds log arguments through separate positive and negative accumulators combined at the end, and clvm_rs ops return one machine-checked total where bitlisp charges stepwise, equivalent at every budget the sweeps covered. Zero meaningful differences found.