docs(#4157): architect specs for #4405 + #4406, and #4414 (devirtualized boolean-return miscompile)

[ttraenkler]

Description

Docs-only. Lands the two architect specs for the 3.2× compiled-code program, plus the correctness bug their investigation surfaced.

#4405 — receiver-type specialisation (spec)

The spec re-scopes the issue: the whole-program this-receiver inference it originally asked for is already built, sound, default-ON, and at 97.9 % coverage on acorn (488 typed twins, zero declines — measured, not assumed). Every soundness condition the brief asked to "specify precisely" is already implemented and is mapped to file:line in the spec, so a dev reading only the issue body would have rebuilt analyzeProtoMethodWriteOnce.

The real residual, measured: non-this receivers at 4,064 asked → 244 proven (6.0 %) → 88 inlined, 156 proven-then-declined dominated by nofield:Node.*, and zero non-this writes inlined because no write-side emitter exists. Root cause of the 156: __fnctor_Node derives slots from constructor-body writes only, so acorn's entire AST payload lives in the dynamic $resid sidecar.

Two design verdicts, both against the issue's original wording: per-site decline, not all-or-nothing (the shipped architecture is already per-site; all-or-nothing would regress a measured 97.9 %), and keep the ref.test guard — an unguarded cast turns whole-program imprecision into a runtime trap with no fallback. The sound route to "guard-free" is hoisting one test per binding per function.

#4406 — return-type unboxing ABI (spec)

Confirms #4405 §5's seam (ctx.directCallTwins already keys "<F>/<m>" → {twinName, params, results}; fillDirectCallTrampolines already degrades on signature mismatch) and corrects three premises: the booleanFunctionNames fixpoint already exists (inferBooleanFunctionNames, 83 names on acorn) and its result is discarded; all 83 are already swallowed into numericFunctionNames; and the issue's __box_boolean < 100k target is unreachable via returns alone — the producer census shows then_return = 0, i.e. there are no boxed-boolean returns left to remove. The AC is amended in-file rather than left as a target that would read as a null.

#4414 — devirtualized prototype-method call returns a boolean as a number (bug, live on main)

("" + p.eat(5)).length answers 1 instead of 4 on the standalone lane with default flags. Discriminated by measurement:

shape	got	want
"" + true literal, var b = (5===5), plain function eq(){} call	✓	✓
P.prototype.eat = …; "" + p.eat(5)	1	4

build	result
default / JS2WASM_NUMERIC_TWINS=0 / JS2WASM_TYPED_THIS=0	1 ✗
JS2WASM_DIRECT_CALLS=0	4 ✓

The fix this issue originally proposed (an isBooleanish veto on the numericFunctions fixpoint) was implemented and measured: the repro is byte-for-byte unchanged. It is therefore ruled out as the root cause and the issue is retitled to what the evidence supports — the result type chosen in the direct-call devirtualization fill path. acorn keeps checksum 422 only because its predicates are consumed exclusively in conditions, where an f64 0/1 and a boolean agree.

Note on the id: filed first as #4407, which collided with 4407-react-dom-wasm-capture already on main (the allocation ran with a degraded open-PR scan, which warns about precisely this). Reallocated to #4414 via claim-issue --allocate.

CLA

• I have read and agree to the CLA

---

Generated by Claude Code