Context
Found during round-26 review of the #2088 implementation plan (docs/plans/issue-2088.md, PR #2612), responding to Greptile P1 review comment 3852228371 on the WU-10 fixture matrix's "Coverage check" section.
The gap
The mechanically-generated fixture matrix (WU-10) is single-file only: every generated combination lives in one file, and the matrix's own oracle for flagging a gap is the three-term invoked && escapes === 0 && !hasT1Evidence.
For the round-25/round-26 finding's own shape — an object literal owner whose only export is through an ALIAS, correlated in-file via alias.prop(...) — the matrix can generate the combination and observe escapes flip between the buggy and fixed reading, but its own oracle cannot flag it as a gap: alias.prop(...) is itself a tracked alias reference the points-to solver (WU-4) already correlates to the same site the owner's own binding resolves to (condition 3's alias-flow support), so hasT1Evidence reads true regardless of escapes, which makes !hasT1Evidence false, which makes the whole conjunction false unconditionally.
This is structural, not a tuning problem: any escape-shape value that invokes the property through the exported alias itself, in the same generated file, supplies T1 evidence regardless of the table's own export status — which is exactly the only in-file invocation available for this family, since the owner's own binding is by construction never itself exported.
Why it matters
This family of regressions (an object literal reachable cross-module only through an exported alias, not through the owner's own binding) is invisible to the matrix's nightly run. It was found — twice (round 25 for const, round 26 for let/var) — only via a separately hand-built, two-file real-Node oracle (two real ES modules, one exporting/invoking the alias, one holding the table), not via the mechanically-generated matrix. The matrix's own "Coverage check" section previously overclaimed that all six of its named historical findings were mechanically self-detected; five are, the sixth (round 25's own) is not and cannot be with the matrix in its current single-file shape.
Suggested fix shape
Extend the generator to also emit two-file combinations for axis values that involve an EXPORT (the alias/hop-depth axis's own EXPORTED values): one file holding the owner/decoy/content axes as today, a second, generated companion file that imports the exported name and performs the escape-shape's own invocation through it — with hasT1Evidence computed only from the OWNER's file, so an alias-only invocation in the companion file cannot supply it. Needs its own oracle wiring (the existing single-process, in-process execution model this matrix already uses, per WU-10's "Execution strategy and budget" note, extended to import a second generated module) and a "skip as unconstructible" rule for axis values that cannot be meaningfully split across two files.
Not built as part of #2088's own round-26 fix: it is a change to the matrix's own generator and oracle (out of that round's scope, which is the exportedNames derivation itself), and a larger undertaking suited to its own review pass.
Context
Found during round-26 review of the #2088 implementation plan (docs/plans/issue-2088.md, PR #2612), responding to Greptile P1 review comment 3852228371 on the WU-10 fixture matrix's "Coverage check" section.
The gap
The mechanically-generated fixture matrix (WU-10) is single-file only: every generated combination lives in one file, and the matrix's own oracle for flagging a gap is the three-term invoked && escapes === 0 && !hasT1Evidence.
For the round-25/round-26 finding's own shape — an object literal owner whose only export is through an ALIAS, correlated in-file via alias.prop(...) — the matrix can generate the combination and observe escapes flip between the buggy and fixed reading, but its own oracle cannot flag it as a gap: alias.prop(...) is itself a tracked alias reference the points-to solver (WU-4) already correlates to the same site the owner's own binding resolves to (condition 3's alias-flow support), so hasT1Evidence reads true regardless of escapes, which makes !hasT1Evidence false, which makes the whole conjunction false unconditionally.
This is structural, not a tuning problem: any escape-shape value that invokes the property through the exported alias itself, in the same generated file, supplies T1 evidence regardless of the table's own export status — which is exactly the only in-file invocation available for this family, since the owner's own binding is by construction never itself exported.
Why it matters
This family of regressions (an object literal reachable cross-module only through an exported alias, not through the owner's own binding) is invisible to the matrix's nightly run. It was found — twice (round 25 for const, round 26 for let/var) — only via a separately hand-built, two-file real-Node oracle (two real ES modules, one exporting/invoking the alias, one holding the table), not via the mechanically-generated matrix. The matrix's own "Coverage check" section previously overclaimed that all six of its named historical findings were mechanically self-detected; five are, the sixth (round 25's own) is not and cannot be with the matrix in its current single-file shape.
Suggested fix shape
Extend the generator to also emit two-file combinations for axis values that involve an EXPORT (the alias/hop-depth axis's own EXPORTED values): one file holding the owner/decoy/content axes as today, a second, generated companion file that imports the exported name and performs the escape-shape's own invocation through it — with hasT1Evidence computed only from the OWNER's file, so an alias-only invocation in the companion file cannot supply it. Needs its own oracle wiring (the existing single-process, in-process execution model this matrix already uses, per WU-10's "Execution strategy and budget" note, extended to import a second generated module) and a "skip as unconstructible" rule for axis values that cannot be meaningfully split across two files.
Not built as part of #2088's own round-26 fix: it is a change to the matrix's own generator and oracle (out of that round's scope, which is the exportedNames derivation itself), and a larger undertaking suited to its own review pass.