[Plan] issue-2088: receiver-correlated invoked-property evidence for object-literal value-refs

[carlos-alm]

Part of #2088. Docs-only — this PR adds a delivery plan, no product code. Merging it does not complete the issue; only the execute PR does.

Plan doc: docs/plans/issue-2088.md

---

What the issue asks for

collectInvokedPropertyNames (src/domain/graph/builder/call-resolver.ts:91) reduces to:

if (call.receiver && call.dynamicKind !== 'value-ref') names.add(call.name);

Any non-empty receiver anywhere in the processed file set credits the bare property name. So a promise.resolve() in an unrelated file keeps { resolve: neverCalled } from being flagged dead. Same in the native mirror, collect_invoked_property_names (crates/codegraph-core/src/domain/graph/builder/stages/build_edges.rs:861).

Confirmed still present on main @ 6221df16.

This is the conservative error direction — a false negative for dead-code detection, never a misclassification of live code as dead. Nothing downstream produces wrong results today. This is a recall improvement to the advisory roles --role dead command, not a soundness fix.

The approach in one paragraph

Give every object literal a stable allocation-site identity, teach the existing Andersen points-to solver to propagate those sites into receiver variables, and credit a property as live only when a receiver that provably points at that literal invokes that key. Gate the whole thing on an escape check: a site whose identity can leave what the solver models keeps today's exact predicate. That is what stops the fix from converting a conservative false negative into a false positive.

The resolver ends up with a three-tier ladder:

Tier	Source	Status
T1 correlated site|key	#2088 (new)	Used exclusively when the site is proven local-closed
T2 bare property name	#1895 (unchanged)	Reached only when the site is absent or escaping — today's behavior
T3 computed-access whole-table	#2260 (unchanged)	Independent channel, always ORed in, stays name-keyed

T1 being exclusive rather than ORed with T2 is what produces the recall gain; the escapes guard is what keeps it safe. Both are argued in the plan.

The §8.3 tension, addressed head-on

The dispatch brief flagged a possible conflict with ROADMAP §8.3, whose approach is explicitly field-based, not field-sensitive — "treat all instances of obj.field as the same abstract location regardless of which obj instance".

There is no conflict: field sensitivity and allocation-site abstraction are orthogonal axes. Field sensitivity is about how fields are abstracted; allocation-site abstraction is about how objects are. §8.3's own Approach block already commits to the latter, in the bullet directly below the field-based one:

Allocation-site abstraction: each new Foo(), function literal, or arrow function creates an abstract object tagged with its source location

and §8.3's single remaining unchecked item is "Full allocation-site abstraction and constraint solver". So this plan delivers a slice of §8.3's own open item rather than deviating from it. The pts lattice stays field-based; the site|key evidence set is computed outside the solver, which never learns about fields. The one real extension — §8.3's allocation-site bullet does not mention object literals — is a roadmap text update in WU-9b.

ADR compliance

• ADR-002 §"Resolution in the existing points-to solver" is binding and satisfied: new constraint rows land in src/domain/graph/resolver/points-to.ts and the Rust build_points_to_map. No new subsystem; the 50-iteration solver loop (buildCallSiteTypeMap / MAX_SOLVER_ITERATIONS) is untouched.
• ADR-002 §Trade-offs/Costs.2 names the wasm-worker-{protocol,entry,pool}.ts seam the primary parity-divergence risk, so it is its own work unit (WU-3) with its own verification. Note Call.objectLiteralSite needs no protocol edit — SerializedExtractorOutput.calls is typed Call[] and passed whole (wasm-worker-protocol.ts:51); only top-level ExtractorOutput extras need explicit threading. Verified by reading the file, not assumed.
• ADR-002 §Costs.5 (RES-2 over-approximation): new fixture cases go to pts-javascript; the javascript fixture's precision-1.0 floor must not move.
• ADR-001 dual-engine parity: every WU touching extraction or resolution has a named Rust mirror (WU-7, WU-8). Note the native tree has no domain/graph/resolver/ directory — the Rust solver lives inside build_edges.rs, its pre-existing mirror location.

Building on prior art, not duplicating it

collectObjectLiteralValueRefCall already sets a value-ref Call's receiver to the dispatch table's name, feeding computedDispatchTableEvidence (#2260). That is a name-correlated evidence channel and it is kept exactly as-is as T3. #2088 adds a site-correlated tier beside it. The array-literal gap in #2260's own channel is filed separately (see below) rather than folded in.

Shape of the work

10 work units. Critical path is WU-1 → WU-2 → WU-7 → WU-8 → WU-10 → WU-9b — the bottleneck is the Rust chain, since WU-7 is a line-for-line mirror that should not start until the TS escape analysis is settled, and WU-10 cannot start until both engines are done because half of what it asserts is that they agree.

DB: migration v32 (current latest is v31) adds object_literal_sites and invoked_property_sites, both persisted and purged per-file exactly as invoked_property_names (#2087) is — deliberately not the in-memory-only shortcut #2260 took.

Config: exactly one new DEFAULTS key, analysis.correlatedPropertyEvidence. Setting it false restores pre-#2088 behavior exactly. No new language, no LANGUAGE_REGISTRY/AST_TYPE_MAPS/LangAstConfig change, no new runtime dependency.

What no test can prove — reviewer attention needed here

The escape analysis is a judgment about completeness. The tests prove the recognised shapes are classified correctly and that the fail-safe default is escapes: true; they cannot prove the recognised set is exhaustive.

A human reviewer must read computeObjectLiteralSiteEscapes (WU-2b) and its Rust mirror against TRACKED_REFERENCE_PARENTS and confirm every position not in that set is genuinely treated as an escape. That review is the real gate on the plan's soundness requirement. This is called out explicitly in the plan's Testing Strategy rather than left implicit.

Nine existing tests form the regression contract and must pass unedited — notably issue-1895-value-ref-invocation-check, whose fixture literal is returned from an exported makeTable() and therefore escapes and resolves on T2, i.e. today's exact path.

Out of scope — filed, not carried in prose

• computedDispatchTableEvidence is in-memory only — scoped incremental builds can report live dispatch-table properties as dead #2610 — computedDispatchTableEvidence is in-memory only, so a scoped incremental build can report a live dispatch-table property dead. Non-conservative direction, and a full-vs-incremental divergence. Its sibling channel got a durable table in follow-up: persist cross-file invoked-property-name evidence for incremental dead-code classification #2087 for exactly this reason.
• findEnclosingTableName does not traverse array literals — handler-array dispatch tables get no receiver name #2611 — findEnclosingTableName does not traverse array literals, so const RESOLVERS = [{ matches, resolve }] yields no receiver and the Computed-property (bracket-access) dispatch-table lookups lack a real calls edge, unlike dot-property value-refs #2260 pathway can never credit a handler array — the exact idiom named in collectObjectLiteralValueRefCall's own doc comment as Dispatch-table function references (resolve: fn) inconsistently flagged dead-unresolved depending on unrelated fanOut #1771's motivating case. Not closed by this plan, which leaves T3 name-keyed.
• roles --role dead -T: hand-authored test fixture directories aren't excluded, causing reachability noise #2256 (pre-existing) — -T under-filters tests/. Relevant only because the plan's dogfood measurement must filter tests/ by hand rather than trust the raw dead-symbol count.
• Cross-module allocation-site propagation is named in the plan as a follow-up direction but deliberately not filed yet: it is a design direction, not a defect, has no user-visible symptom today, and its right shape depends on what WU-10 measures.

Plan provenance

Round 1. No plan-carry-forward artifact exists on #2088 — gh api .../issues/2088/comments --paginate returns zero comments carrying the sentinel, from any author, trusted or not. Everything in the plan is derived fresh from live source at 6221df16.

Verification status of this PR

Docs-only. npm run lint was run and passes (Biome is scoped to src//tests/, neither touched). It reports 1 pre-existing warning in src/graph/algorithms/louvain.ts:135 (ineffective biome-ignore suppression) — an untouched file, left alone per CLAUDE.md's "don't clean up lint issues in files you aren't working on". Flagging it rather than silently absorbing it.

---

✋ Human approval gate (/oversee)

• Task: issue-2088 (issue follow-up: receiver-type-aware invoked-property matching to reduce dead-code false negatives #2088)
• Plan doc: docs/plans/issue-2088.md
• Current head: 8830670d
• Critic verdict: ✅ PASSED at 59bd5752 — no blocking findings
• Since that verdict: 8830670d, documentation-only (verified no-logic-change by full diff), closing the four non-blocking items the passing critic itself named
• Revise rounds: 24 revision commits across 29 review rounds
• Provenance: oversee/plan-gate=success on the current head

✅ Recommended for approval — with one trade-off you should weigh first.

The soundness bar was met and independently verified by execution. What remains is a
scope decision no reviewer can make for you. It is stated at the bottom of this gate.

What was verified, and how

The bar throughout: can this design ever report live code as dead? Today's
collectInvokedPropertyNames credits any truthy receiver and structurally cannot, so the
plan's whole safety argument is that it never converts that conservative false negative into
a false positive.

The final review drove the real pipeline — parseFileAuto, the real points-to solver,
the real findCaller, cross-checked against a real codegraph build — not a model of it.

• No under-escape path exists, and it is structurally impossible for the final change: the
  probe set feeds only collectInvokedPropertySites, whose sole effect is keys.add(...). It
  never touches escape analysis, nonEscapingSites, or the localClosed predicate.
• Every fixture is non-vacuous. 86 escape-fallback cases and 36 correlation shapes, each
  verified to flip under ablation of the specific fix it covers.
• Both engines checked against real Rust and TypeScript source, not paraphrase.

The trade-off, quantified

The final fix is a tolerance, not a tightening. The extractor and the resolver name scopes
differently, so the site lookup probes four keys instead of one. That cross-credits some
sites — a recall cost, independently raised by Greptile and confirmed rather than disputed.

Measured on codegraph's own src/ — 113 files with a for-of, 577 for-of bindings, 68 relevant
call sites:

	resolving call sites	colliding
single probe	28	2
widened	31	3

+3 resolved, +1 collision (1.5%). The severity is bounded by proof, not assertion: T1's
over-credit is a subset of T2's admit set, so the worst case is byte-identical to pre-#2088
behaviour for the affected pairs. It can never mark live what #1895 marked dead, and never
marks anything dead. The proper fix — reconciling the two naming schemes in the extractor —
is filed as #2647, out of this plan's scope.

How the review got here

Four standing rules now govern the plan, each added after a failure the previous level could
not catch:

Rule	Added after
Guard fixtures — prove a tightening does not over-escape	A fix broke a verified-sound branch while "improving" it
Fixture-parse — confirm the node type a fix keys on exists	A round shipped dead code and closed an issue on it
Ablation — remove a fix; its fixture must flip	A rebuilt guard still passed with its own fix removed
Harness derivation — derive inputs the way the real pipeline does	A harness built a permissive exportedNames and validated five false claims

The last one matters most: a verification model more permissive than reality confirms exactly
the claims reality falsifies — that gap survived twenty-five rounds and ~1M executed
combinations, because volume of execution cannot correct a miscalibrated input.

Residual limitations — all recall-direction, all tracked

Every excluded shape carries a direction label and a real open issue: #2610, #2611, #2617–#2625,
#2627, #2629–#2636, #2638–#2643, #2645–#2647. Under the plan's own standing rule an
UNDER-escape gap may never be filed as an accepted limitation; every one of these is
OVER-escape, except #2610, which is pre-existing and verified not worsened.

Reviewing this plan also surfaced #2628, #2639, #2643 and #2647 — suspected bugs
in shipped product code, unrelated to #2088.

The decision that is actually yours

Soundness has stopped being the interesting variable. T1 correlation now fires for a
deliberately narrow core, with roughly thirty tracked exclusions describing what it will not
catch, and the final tolerance trades a further 1.5% of precision for coverage.

Against that: 10 work units, a dual-engine mirror, and a v32 DB migration — for a recall
improvement to an advisory command (roles --role dead).

That trade is a judgement no critic can make for you, and it is the last thing standing
between this plan and a decision.

---

Review the plan above. To approve it for execution, tick this box, then run /oversee #2612:

• APPROVED FOR EXECUTION — I have reviewed this plan and approve building it

[github-actions]

Heads up: this PR references #2260, #2087 without a closing keyword (Closes #N / Fixes #N). If this PR fully resolves #2260, #2087, update the description so the issue auto-closes on merge — otherwise disregard this comment.

[greptile-apps]

Greptile Summary

The PR adds a docs-only delivery plan for allocation-site-correlated invoked-property evidence while preserving conservative fallback behavior.

• Defines TypeScript and Rust implementation work across extraction, points-to resolution, persistence, and incremental paths.
• Specifies escape-analysis safeguards, dual-engine parity, configuration, migration, and regression coverage.
• Documents the measured receiver-scope probing trade-off and tracked follow-up limitations.

Confidence Score: 5/5

This docs-only planning PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
docs/plans/issue-2088.md	Adds the implementation plan and incorporates the prior review fixes, with no remaining eligible issue identified.

_{Reviews (48): Last reviewed commit: "docs(plan): correct stale declaringScope..." | Re-trigger Greptile}

[greptile-apps]

Returned sites bypass escape tracking

For export const T = makeTable() with a non-exported local makeTable, this branch marks the returned literal local-closed solely from the factory's export status even though the planned call-assignment constraint propagates it into exported T. Exclusive correlated evidence then omits external calls to T, allowing live properties to be reported dead; the plan should account for destinations of returned sites before approving execution.

[carlos-alm]

Addressed in the prior round (commit 8aa0167, "fix WU-2b's return-owner escape gap"): the owner.bindingName === null branch now unconditionally sets entry.escapes = true for a returned-site owner, regardless of the factory function's own export status, since the call-assignment that actually captures the return value can land in any binding this per-file pass can't see. Confirmed still in place at the current head.

[greptile-apps]

Alias references force coarse fallback

In the promised const u = T; u.alpha() case, the reference to T has a variable_declarator parent, which this allowlist rejects and therefore marks the site escaping. The test can still pass through bare-name fallback, leaving unrelated same-named calls able to preserve aliased properties and failing to verify the advertised alias correlation.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[carlos-alm]

Fixed in 899188d. allReferencesTracked's condition 3 now recognizes a variable_declarator reference as tracked when its name field is a plain identifier — i.e. const u = T (the alias shape fnRefBindings already models) — while a destructuring name such as const { k } = T still escapes, since it extracts a property rather than aliasing the reference and fnRefBindings doesn't model it. The guard mirrors the existing name?.type !== 'identifier' check in findEnclosingTableName (src/extractors/javascript.ts:4519), which already draws this exact distinction for table-name resolution.

I also strengthened WU-10's correlation test: each of the four cases now must assert escapes = 0 for its site, not just the liveness outcome — otherwise, as you noted, the alias case could keep passing via T2's bare-name fallback even if this guard regressed, without the test ever catching it.

[carlos-alm]

@_scratch_reply1.txt

[carlos-alm]

Disregard the reply directly above this one (the literal text @_scratch_reply1.txt) — that was a broken tool call from an earlier round, posted to the wrong thread by mistake, not a real comment. This thread's actual answer is the reply already above it (Fixed in 899188d7...), which stands unchanged. The intended target of that broken reply was the separate "Property extraction bypasses escape tracking" thread on this same file, which now has a proper reply.

[carlos-alm]

@greptileai please re-review.

Addressed in 899188d:

• Alias references force coarse fallback: allReferencesTracked now tracks a variable_declarator reference when its name field is a plain identifier (const u = T), while still rejecting destructuring (const { k } = T) — see reply on the inline comment for details. Also strengthened WU-10's correlation test to assert escapes = 0 per case so it can't pass vacuously through T2.
• Returned sites bypass escape tracking: confirmed already fixed by the prior round (8aa0167) and still in place at the current head — see reply on that inline comment.

[carlos-alm]

@greptileai please re-review — re-posting this mention as a fresh comment (the prior comment's mention was only added via a later edit due to a gh api flag mistake on my end, which may not fire your webhook the same way a new comment does).

Summary of what changed in 899188d, also detailed in my replies on both inline threads:

• Alias references force coarse fallback: allReferencesTracked now tracks a variable_declarator reference when its name field is a plain identifier (const u = T), while still rejecting destructuring (const { k } = T). WU-10's correlation test now also asserts escapes = 0 per case so it can't pass vacuously through T2.
• Returned sites bypass escape tracking: confirmed already fixed by the prior round (8aa0167) and still in place at the current head.

[greptile-apps]

Alias uses bypass escape tracking

When T is aliased with const u = T and u is then passed to an imported or otherwise unmodeled function, allReferencesTracked accepts the declarator while scanning only references to T, so the site is marked local-closed despite escaping through u. Exclusive correlated evidence then omits external property invocations and can report a live object-literal value as dead.

[carlos-alm]

Fixed in 62606d0. The rebinding branch of allReferencesTracked now recurses: accepting const u = T additionally requires allReferencesTracked to also hold for u itself, capped at 6 hops (reusing findEnclosingTableName's existing bound as defense-in-depth against a pathological alias chain, since a chain of fresh const bindings can't actually cycle). So const u = T; importedFn(u) now correctly escapes. Added case (e) to WU-10's escape-fallback test list covering exactly this shape.

You're right that the same transitivity gap exists on the paramBindings branch (a bare-identifier argument to a local non-exported function) — verified against the real, already-shipped buildParamFlowConstraints in src/domain/graph/resolver/points-to.ts, which has no escape-safety check of its own. That's a separate, currently-unreported branch of the same condition, and fixing it needs to scope the recursive check into the callee's own body rather than reuse this same file-level walk, so I filed it separately as #2617 rather than folding it into this fix.

[carlos-alm]

@_scratch_reply2.txt

[carlos-alm]

Disregard the reply directly above this one (the literal text @_scratch_reply2.txt) — that was a broken tool call from an earlier round, posted to the wrong thread by mistake, not a real comment. This thread's actual answer is the reply already above it (Fixed in 62606d04...), which stands unchanged. The intended target of that broken reply was the separate "Property extraction bypasses escape tracking" thread on this same file, which now has a proper reply.

[carlos-alm]

@greptileai please re-review.

Addressed in 62606d0 — see reply on the inline comment for the alias-transitivity fix and issue #2617 for the analogous param-flow branch filed separately.

[greptile-apps]

Property extraction bypasses escape tracking

When a property value leaves through an expression such as const u = T; importedFn(u.alpha), allReferencesTracked accepts u because its direct parent is a member_expression without checking the enclosing expression's use. The site is consequently treated as local-closed, so exclusive correlated evidence can report alpha dead even though the recipient invokes it.

[carlos-alm]

Already addressed, in the commit right after this comment was posted: 9156a889 ("gate tracked reference positions on T1 visibility in WU-2").

u's reference inside u.alpha in importedFn(u.alpha) is a bare (non-call) property read, structurally identical to const f = T.k; f()'s bare read of T.k — which 9156a889's isTrackedReferencePosition narrowing now excludes explicitly: a member-expression reference is tracked only when it is itself the object of a member expression that is in turn the function of an enclosing call_expression. In importedFn(u.alpha), u.alpha's parent is the call's argument list, not u.alpha itself being called — so the grandparent-is-call_expression-with-matching-function-field check fails, isTrackedReferencePosition returns false for u's reference, and (since this is a non-vacuous, genuinely failing reference) allReferencesTracked correctly returns false for u — so T is classified escaping via the round-4 rebinding recursion, exactly as intended.

WU-10's escape-fallback case (h) (const R = { beta: fnF }; const f = R.beta; f();) is the direct-owner regression gate for this exact shape; this specific alias variant (const u = T; importedFn(u.alpha)) is one recursion hop further through the round-4 rebinding branch, and is covered by the same fix since the call-position check applies uniformly to every reference allReferencesTracked walks, direct or recursive.

Re-confirmed unaffected by this PR's latest round (round 7, five further gaps closed — see the new top-level comment): round 7 adds an isArrayOwner short-circuit that runs before this call-position check, and T here is a direct (non-array) binding, so isArrayOwner is false and this reasoning is unchanged.

(Note: two replies landed on the wrong threads on this PR around this same time, each with a literal @_scratch_replyN.txt placeholder body instead of real content — a broken tool call from an earlier round, not a comment from a human. Please disregard those two; this reply is the actual answer to this thread.)

[carlos-alm]

@greptileai please re-review.

New head since your last pass: 515140a3 ("docs: treat param-flow positions as escaping in WU-2 condition 3").

Both of your earlier inline findings were answered against the heads that followed them, and each has a reply on its own thread:

• "Alias references force coarse fallback" — addressed in 899188d7; condition 3 now recognises a variable_declarator rebinding (const u = T) as a tracked reference.
• "Alias uses bypass escape tracking" (P1) — addressed in 62606d04; the rebinding branch now recurses into the alias's own references (depth-capped at 6), so const u = T; importedFn(u) correctly marks the site escaping. WU-10 escape case (e) is the regression gate.

What 515140a3 changes, from an independent review of the plan at 62606d04: the parameter-passing branch of condition 3 had the same transitivity gap the alias branch had just closed. It credited a bare-identifier argument to a local, non-exported function as tracked without inspecting what the callee does with that parameter, so const P = { beta: fnB }; function use(t) { register(t); } use(P); (with register imported) marked the site local-closed and could report fnB dead while it is live.

That branch is now dropped: a bare-identifier argument always marks the site escaping, falling back to T2 (today's exact bare-name predicate). WU-4's "parameter flow comes for free" claim is corrected, and WU-10's old correlation case 4 moved into the escape-fallback test as case (f) asserting escapes = 1 — it previously asserted escapes = 0, which would have locked the unsound classification into the test suite.

Extending correlation to the parameter-flow shape properly (recursing into the callee body) is tracked as a follow-up recall enhancement in #2617, not deferred plan work.

[carlos-alm]

@greptileai please re-review. Commit 515140a fixes the parameter-flow branch of WU-2b's escape analysis (condition 3): a bare-identifier argument to a function is no longer treated as a tracked reference, so such sites always fall back to today's exact bare-name predicate instead of being credited as correlated evidence. See the inline replies on the two alias-branch threads for confirmation those fixes are unaffected, and the comment on #2617 re-scoping it from a plan defect to a follow-up recall enhancement.

[carlos-alm]

@greptileai please re-review.

Commit 9156a88 fixes a new escape-analysis gap in WU-2 found in review after 515140a. TRACKED_REFERENCE_PARENTS was a bare tree-sitter node-type set, so parent-type membership alone let two more shapes through as wrongly "tracked" (non-escaping) even though T1 never actually gets correlated evidence for them:

1. this.k() called on a sibling property from within the SAME literal (const T = { alpha: fnA, run() { return this.alpha(); } }; T.run();) — nothing binds this to the literal's site (the solver's only this key is ${callee}::this, seeded from thisCallBindings for .call(ctx) shapes only), so T1 finds zero evidence while the reference itself looked tracked.
2. A bare (non-call) member/subscript read — T's parent is member_expression in const f = T.k; exactly as in T.k(), but only the latter is a call.

Fix, in order:

• Stated an explicit invariant at the definition of the tracked set: a position may be listed only if EVERY invocation reachable through it is visible to T1 as a correlated call, not merely if the object's identity stays visible to the solver — identity-visibility-without-invocation-evidence is the root cause behind rounds 3, 5, and this one.
• Replaced bare TRACKED_REFERENCE_PARENTS.has(parent.type) membership with a structural isTrackedReferencePosition check: a member/subscript reference is tracked only when it's the object of a member/subscript expression that is itself the callee of an enclosing call — a bare read now escapes.
• While closing that gap, found the same relaxed check would still wrongly track a subscript call with a DYNAMIC key (T[k]()) anywhere, not only inside a loop — added a static-key requirement (string/template-string index only), mirroring collectComputedDispatchTableEvidence's own existing static/dynamic distinction.
• Added condition 4 to computeObjectLiteralSiteEscapes: a literal defining a method/function whose body references this is now always escaping (conservative exclusion, not modeled — extending correlation to it would need per-call-site tracking the tier ladder doesn't do today).
• Narrowed for_in_statement to the for...of variant only, reusing the exact of-keyword discriminator collectForOfBinding already applies. for...in enumerates keys, not values, and for (const k in T) T[k]() gets neither T1 evidence (dynamic key, no static name) nor T3 evidence (collectComputedDispatchTableEvidence requires the const x = T[expr]; x(...) declarator form, verified against its guard clauses — never a direct call).
• Mirrored all of the above in WU-7's Rust TRACKED_REFERENCE_PARENT_KINDS/is_tracked_reference_position/literal_has_unmodeled_this_reference.
• Added escape-fallback regression cases (g) this.k()-inside-literal and (h) bare const f = T.k; f(), each asserting escapes = 1 and live-only-via-T2, matching case (f)'s style.
• Filed issue-2088 plan: same-literal this.k() calls excluded from correlation (conservative), not modeled #2618 (same-literal this correlation), issue-2088 plan: for...in enumeration and direct TABLE[computedExpr]() calls get no correlated or computed-dispatch evidence #2619 (for...in / direct computed-call dispatch evidence), issue-2088 plan: bare object-literal property reads assigned to a local (const f = T.k) have no alias-tracking #2620 (bare-read property-alias tracking) as deferred capabilities rather than silently narrowing recall, and reconciled Success Criteria, the Testing Strategy shape count, and the reviewer-checklist paragraph to match.

[carlos-alm]

@greptileai please re-review.

Round 7. New head: e8efa37a ("docs: close five round-7 escape-analysis soundness gaps in WU-2"), on top of 9156a889. This round re-applied the doc's own binding invariant — a position is trackable only if EVERY invocation reachable through it is visible to T1 as a correlated call, not merely if the object's identity stays visible to the solver — to round 6's own result, and found five more places where it still didn't hold. All five are fixed, mirrored in WU-7's Rust plan, and gated by six new WU-10 escape-fallback cases.

1. Array-owned sites treated a member/subscript call on the CONTAINER as tracked. const RESOLVERS = [{ matches: isFoo }]; RESOLVERS.forEach((r) => r.matches('foo')) — the plan's own headline Dispatch-table function references (resolve: fn) inconsistently flagged dead-unresolved depending on unrelated fanOut #1771 idiom — passed the old check (RESOLVERS is the object of a call-position member expression), but buildArrayCallbackConstraints only seeds a points-to fact for Array.from's callback, never for .forEach/.map/.find/.filter/.some, so r.matches(...) produces zero T1 evidence regardless. Fix: isTrackedReferencePosition now takes isArrayOwner (derived from owner.key !== owner.bindingName) and rejects the member/subscript branch outright for an array owner — only a for...of head over the container remains admissible. Follow-up: issue-2088 plan: array-owned sites correlate only through for...of - container-level array methods (.forEach/.map/.find/.filter/.some) are not modeled #2621.

2. The for...of branch didn't recurse into the loop variable. for (const r of A) sink(r) (sink imported) accepted the reference to A but never checked what r itself does — the same alias-transitivity gap round 4 fixed for const u = T, recurring one binding later. Fix: allReferencesTracked now recurses into the loop variable exactly as it recurses into a rebinding alias (same depth-6 cap, isArrayOwner hardcoded false since a loop variable always denotes a single element) — and only when that loop variable is a single plain identifier, mirroring collectForOfBinding's own extraction shape. A destructuring loop variable (for (const { k } of A) k()) is now rejected outright, since collectForOfBinding never seeds a points-to fact for it at all. Re-verified: WU-10's existing handler-array shape (for (const r of RESOLVERS) if (r.matches(x)) return r.resolve(x);) still resolves correctly under this tightened rule. Follow-up (destructuring sub-case): issue-2088 plan: destructured for-of loop variables have no alias-tracking (array-element analogue of #2620) #2622.

3. Condition 4 (literalHasUnmodeledThisReference) skipped identifier-valued properties. const T = { alpha: alphaImpl, run: runImpl }; T.run(); with function runImpl(){ return this.alpha(); } defined elsewhere in the file — round 6 only inspected a pair's value when written inline (method_definition, function_expression); an identifier value naming a same-file function was invisible to the check entirely. Fix: a plain-identifier pair value is now resolved against the file's own top-level function/variable definitions; a resolved non-arrow function's body is checked for this (fail-safe true if it can't be resolved in-file at all, matching this function's existing arrow-exclusion and fail-safe conventions).

4. The static-key check accepted interpolated template indices. T[`al${part}`]() was accepted as a static subscript key because indexType === 'template_string' alone was checked — but extractSubscriptCallInfo only produces a named, receiver-carrying call when the text has no $; an interpolated template falls through to <dynamic:unresolved> with no receiver. Fix: the escape check now mirrors the extractor's own guard exactly (string, or template string containing no $) in both engines. Follow-up: issue-2088 plan: interpolated template-string subscript keys get no correlated evidence #2623.

5. resolveSiteOwner's bindingName contract was unstated for the array case. If it ever returned the [*]-suffixed key instead of the bare identifier, allReferencesTracked would search the AST for literal text that can never exist, get a vacuous (zero-reference) result, and read that as non-escaping — silently bypassing condition 2's export check for every array-owned site. Fix: the contract is now stated explicitly (bindingName is always the bare declarator identifier; only key carries a structural suffix), with a dedicated export const A = [{…}] regression case.

On the vacuous-allReferencesTracked question (zero surviving references, for any reason): concluded it should stay true, not be forced to false — reasoned through explicitly in the doc. Every escape channel this design accounts for manifests as some concrete AST reference; an empty reference set isn't a gap in coverage, it's proof that channel doesn't exist for this binding. Forcing it to false would forfeit T1 correlation for legitimately fully-local dispatch tables without closing any actual soundness gap.

Also cleaned up on this PR: two inline replies from an earlier round landed on the wrong threads with a broken @_scratch_replyN.txt placeholder body instead of real content (a tool-call mistake, not a comment from anyone). Posted the actual answer on the thread it was meant for ("Property extraction bypasses escape tracking" — already fixed by 9156a889, confirmed unaffected by round 7) and a short correction on the two threads that got the misfire.

Reconciled throughout: the tracked-set doc comment, Testing Strategy's shape count (8 → 14 escape-fallback cases), the Success Criteria exclusion list, and the WU-7 Rust mirror section (is_tracked_reference_position, literal_has_unmodeled_this_reference + two new helpers, resolve_site_owner, all_references_tracked — all five fixes apply to both engines).

[greptile-apps]

Quoted dollar keys lose evidence

When an object-literal binding is invoked as T['cos$t'](), this predicate accepts the string index as tracked, but both extractors classify names containing $ as unresolved and emit no receiver. The site can therefore become local-closed with no correlated invocation evidence, causing the live property value to be reported dead.

[carlos-alm]

Fixed in 0bdfb32. isTrackedReferencePosition's subscript branch now applies one check to both string and template_string index kinds identically: strip quote/backtick characters from the index text, then require the result non-empty and free of $ — mirroring extractSubscriptCallInfo/extract_call_info exactly, the same way round 7 already intended but only implemented for the template_string arm. T['co$t']() is now rejected on the string arm too (the template-string form of the same shape, a plain backtick-quoted key containing $, was already correctly rejected by round 7's fix) — so it correctly falls through to escaping/T2 instead of being accepted as a tracked reference with zero T1 evidence behind it.

Added WU-10 escape-fallback case (p) as the regression test: const V2 = { co$t: fnA4 }; V2['co$t'](); with a cross-file decoy via ordinary dot notation (otherObj.co$t();, which needs no bracket/quote at all since $ is a valid identifier character) — asserting live + escapes = 1, so the fix is checked against exactly this shape rather than trusted by inspection alone.

[carlos-alm]

@greptileai please re-review.

Round 22 (3e92903) on top of e8ad327:

• Blocking finding fixed: class_static_block is absent from FUNCTION_SCOPE_NODE_TYPES in both engines, so functionScopeDeclaresVar attributed a var hoisted inside a static { } block to the enclosing function — a false-positive shadow that prunes a genuine reference (UNDER-escape: live code reported dead). Fixed via a new WU-2-local functionScopeDeclaresVarExcludingStaticBlocks re-derivation, substituted in allReferencesTracked (extended from round 18's method_definition-only carve-out to all six FUNCTION_SCOPE_NODE_TYPES kinds) and in findDeclaringScopeNode's function-shape ancestor test. The shared, multi-consumer functionScopeDeclaresVar/FUNCTION_SCOPE_NODE_TYPES stay untouched; the residual gap in that primitive's other, already-shipped consumer is filed separately as functionScopeDeclaresVar treats a var inside a class static block as hoisting to the enclosing function #2644 (UNDER-escape, contrasting with round 21's functionScopeDeclaresVar cannot see a for (var x of y) loop-head binding #2643, which is OVER-escape/recall-only). Mirrored in the Rust extractor. Verified against the real tree-sitter-javascript@0.25.0 grammar and a real Node runtime oracle across eight trigger constructions and two controls; ablation confirms the fix flips exactly the eight triggers and neither control. Nine new escape-fallback fixtures (bq)-(by) and correlation shape 27 added to WU-10.
• Report-integrity corrections to round 21's own text: the ablation-flip count ("flips nine...") corrected to what actually reproduces (6 fixtures / 8 of 10 constructions, see the round-21 essay); the dangling (bk)-(bq) case-range citation corrected to (bk)-(bp); findEnclosingFunctionBody/isVarKindDeclarator now honestly labeled as this round's own exposition-only coinages rather than implied pre-existing names; a stale code-adjacent comment at the top-level allReferencesTracked call site (flagged in an earlier review comment, replied to above) corrected to describe round 21's actual per-recursion-level contract instead of the pre-round-21 behavior it still described.
• Structural change: WU-10 now specifies a mechanically generated fixture matrix (container × decoy × escape-shape × owner-form, executed under Node against the design's own escapes verdict) as the primary mechanism for finding new gaps going forward — the last two blocking findings (round 21's alias shape, this round's static-block shape) were both ordinary constructions found by executing generated combinations, not by reading the prose. The 94 hand-written cases are retained as named regression anchors, not superseded.

[carlos-alm]

@greptileai please re-review. This commit fixes the round-22 fixture matrix's own test methodology, not the escape analysis — an independent audit (~1,127 executed combinations) confirmed the escape analysis is sound and the class_static_block fix is correct and load-bearing at this head.

What changed in docs/plans/issue-2088.md:

• Oracle fix. The matrix compared the runtime oracle to escapes as a two-way invoked <=> !escapes check, which flags the round-22 fix itself as a new gap (escapes=1 on a genuinely invoked handler is correct T2/T3 fallback behavior, not a mismatch). Replaced with the three-term predicate the contract actually needs: invoked === true && escapes === 0 && !hasT1Evidence. escapes=1 on a live handler is now stated explicitly as a pass, never a finding.
• Axes. Added an alias/hop-depth axis (direct, const/let/var alias, two-hop chain, for-of loop variable) and an object-literal content axis (identifier/function/shorthand/__proto__/getter/setter/spread/method/call-expression/nested value); split the owner-form and for-of-decoy axes by declarator/loop-head keyword. Verified all five of this plan's own historical blocking findings (const u = T; class_static_block; __proto__; a var-kind for-of head; a bare run => {} arrow parameter) are each reachable as a single generated combination now, not just the one the matrix happened to be built around.
• Case (by) reshaped. Its inline for-of array literal (for (const r of [T])) made T's own reference a child of an array node, which TRACKED_REFERENCE_PARENTS doesn't recognise — the site escaped for that unrelated reason before the for-of-loop-variable recursion under test was ever reached. Self-ablation on the original form showed only 7 of the 8 claimed (bq)-(by) triggers actually flipped. Reshaped to the named array-element-owner form (bo)/(bd) already use; the reshaped case now flips correctly.
• Count reconciliation. 77 escape-fallback + 27 correlation shapes = 104 (a stray "ninety-four" corrected); fixed a self-contradictory sentence naming both "twenty-six" and "1-27" shapes in the same breath, plus two further stale pre-shape-27 counts; completed a "(bk)-(bp), ten constructions" enumeration that was missing A10.
• Misc. Fixed a misattribution (findEnclosingFunctionBody credited to round 22 in one spot, round 21 everywhere else it's named — round 21 is correct) and a severed sentence in the round-21 essay.

No change to WU-2/WU-2b's escape-analysis logic or any shared primitive. No Rust-mirror (WU-7/WU-8) update needed — everything here is WU-10 test-harness methodology, and fixture (by) already runs against both engines unchanged in shape.

[carlos-alm]

@greptileai please re-review. This commit fixes two documentation-level defects in the round-22 fixture matrix's own test apparatus (WU-10), found by an independent critic who ran the full 831,600-combination matrix twice at the prior head (1,099,956 executed combinations, zero under-escape paths under both readings of the oracle) — the escape analysis itself is confirmed sound and untouched, and the matrix is not shrunk.

What changed in docs/plans/issue-2088.md:

• hasT1Evidence scoping fixed. The contract said hasT1Evidence is true "iff the walk identified a real, tracked reference as the invocation," which admits two readings: site-scoped (any tracked reference anywhere at the site) or property-scoped (a tracked reference to the specific handler property under test). Site-scoped is the natural first reading of the prior wording, and it's wrong: constructed and executed against this plan's own five named historical findings with each round's fix ablated, site-scoped wrongly reports PASS on 3 of 5 (rounds 12, 17, 19 — each has a genuine, tracked reference to an unrelated property at the same site, which site-scoping credits as "T1 evidence" for the property actually under test). Property-scoped catches all 5. The contract now defines hasT1Evidence(O, p) explicitly, parameterized by owner O and property p, and the mismatch predicate is restated as invoked(p) === true && escapes === 0 && !hasT1Evidence(O, p).

• Three coverage-check claims didn't reproduce. Each was checked by constructing the exact combination the plan claimed exposes the finding, then executing it with the relevant round's fix ablated — none of the three flipped:

  • __proto__ (round 19): the escape-shape axis had no "no escape" control value, so every generated combination is forced to add a leak (e.g. sink(N)) that already forces escapes = 1 at condition 3 regardless of the proto fix. Added the missing control value.
  • a var-kind for-of head (round 17): the decoy axis can only target the owner's or an alias's name, never the content axis's own identifier (run41) — the one name this finding actually needs rebound. Added a decoy-target dimension for the for-of/kind values.
  • a bare run => {} arrow parameter (round 12): the owner-placement pin declares the object literal at MODULE scope unconditionally, but the finding needs the literal INSIDE the arrow for findResolvingScopeNode's walk to ever traverse the bare-parameter field. Added a literal-placement axis (module scope / inside the container).

  All three additions are additive. Re-verified all five coverage-check findings by constructing and executing the generated combination for each (not asserting) — all five now flip correctly.

• Count reconciliation. 15 containers × 18 decoys × 12 escape shapes × 5 owner forms × 6 alias/hop-depth values × 12 content values × 2 literal-placement values = 2,332,800 nominal combinations, up from 831,600.

• Execution strategy named. The plan never said how the matrix runs — a 25× wall-clock ambiguity between in-process (~22 min single-threaded, 176s across 8 shards) and one node spawn per combination (~9.2h). Stated that in-process is the intended reading, and that this is a nightly job, not a per-PR gate (too slow for the per-PR Verification Commands block); the existing named regression anchors ((a)-(by), correlation shapes 1-27) stay in the per-PR suite unchanged.

• Three uncited figures dropped. A "2,505 constructed cases" delta, "36 and 231 SyntaxErrors in two independently-built implementations," and a "43%/72% false-alarm rate" (found adjacent to the hasT1Evidence rewrite) had no run log backing them in this document — removed rather than left as unverifiable precision.

No change to WU-2/WU-2b's escape-analysis logic or any shared primitive. No Rust-mirror (WU-7/WU-8) update needed — this is WU-10 test-apparatus methodology only.

[greptile-apps]

Coverage recipes miss binding scope

When the round-17 recipe leaves the literal at module scope, its function-local var loop head rebinds a different identifier, while the round-12 recipe does not require its content identifier to match the parameter decoy. The generated cases therefore either flip through an unrelated name-based scan or do not flip at all, so the matrix can claim coverage without exercising the intended fixes.

[carlos-alm]

Executed both recipes to check this. Both claims hold under the plan's own stated criterion, but the underlying precision gaps you're pointing at are real, and I've tightened both bullets in 0e3d3c4 rather than just asserting they're fine.

Round-12 recipe (run => {...} shadow): the bare-parameter decoy does shadow the content axis's own identifier as designed -- but you're right that the decoy axis's own TARGET sub-dimension is only defined explicitly for the for-of decoy, leaving the parameter decoy's own target implicit. It's defensible as written (the decoy axis's note already says the bare parameter is "the exact shape case (ad)/round 12 exercises," and case (ad) itself names the content identifier as what it shadows), but a generator implementing the axes literally could, in principle, pick a non-shadowing parameter name and silently miss this recipe. Flagged that gap explicitly in the doc rather than leaving it implicit.

Round-17 recipe (var-kind for-of head): this one flips escapes correctly in all fifteen containers -- the static analysis doesn't care whether the containing function is ever called. But the runtime oracle's invoked only reads true for module scope and the five block-shaped containers (bare block, if, try, switch case, loop body), not the nine function-shape containers the bullet named, because a function-shape container has to actually be invoked for its body to run, and nothing in the axis definitions auto-invokes every container value. So the three-term contract (invoked && escapes===0 && !hasT1Evidence) is only observable for six of the fifteen, not reachable-and-correct-but-unobserved for the other nine as the bullet implied. escapes itself is unaffected by this -- it's a gap in what the matrix can currently demonstrate, not in the fix. Corrected the bullet to name the six containers where this is actually observable and filed the container-invocation gap as a follow-up for the generator itself.

Both corrections are in the Coverage check section of WU-10 (search "GREPTILE (P1)" in the diff).

[carlos-alm]

@greptileai please re-review.

Round 25 (0e3d3c4) on top of 8bc1b0a: closes an UNDER-escape gap in condition 2's own recursion, independent of the "round 24" review pass this PR's history already confirmed clean.

Blocking finding closed: condition 2 (the export check) ran exactly once, against the top-level owner's own bindingName, before allReferencesTracked ever ran -- never re-applied to any alias name the rebinding/for-of recursion introduces. An alias can itself be exported while the table it aliases is not:

// a.mjs
function fnAlpha() { return 1; }
const T = { alpha: fnAlpha, run() { return 0; } };
export const api = T;                 // exported ALIAS, T itself never exported
T.run();
// b.mjs
import { api } from './a.mjs';
api.alpha();                          // fnAlpha IS invoked

Verified end-to-end under real Node: fnAlpha genuinely runs on every b.mjs import, but the pre-fix algorithm reads escapes = false for T's site (condition 2 only ever checked T, never api) -- fnAlpha would be reported dead though api.alpha() invokes it on every import.

Fixed by threading exportedNames through allReferencesTracked as a new parameter, unchanged across both the rebinding-alias and for-of recursions, and re-checking it -- the same check the caller already runs once, at the top -- at the start of every recursive call. Mirrored in WU-7's Rust; WU-8 needs no change (the parameter never crosses the NAPI boundary). Self-ablated against a standalone reference model (real tree-sitter-javascript parse, real Node): five flipping constructions and four controls that correctly do not flip.

Matrix gap closed alongside it: the fixture matrix had no export dimension on any axis, so four consecutive clean sweeps never had a way to generate this bug's class. Added an exported const/let/var alias and an exported two-hop chain to the alias/hop-depth axis; recomputed the nominal count (2,332,800 -> 3,888,000).

#2610 re-derived, not withdrawn: its standing exception argued "any table with a cross-file computed-access consumer must itself be exported" -- false whenever only an alias is exported. The conclusion (the site escapes via condition 2 or condition 3, before condition 4 ever runs) survives under the corrected premise, so the exception stands, re-derived on the repaired behavior.

Also in this push, all non-blocking: replied to and tightened the round-17/round-12 coverage-check recipes your own P1 flagged (both hold, with real precision gaps now stated explicitly rather than glossed over); corrected the pre-round-22 combinatorial baseline (5,445, which silently counted two round-22-only additions under a "pre-round-22" label -- corrected to 4,620); added the missing "executed" qualifier to the matrix's per-combination timing figures; relabeled the prior commit's "ROUND 23" tags to "ROUND 24" to match this PR's actual review-cycle count, with a note on the resulting non-contiguous 22/24 numbering.

No change to any prior fix, the shared primitives, the oracle, or the matrix's own size beyond the one new axis dimension.

[greptile-apps]

Export matrix masks regression

When the exported-alias matrix case invokes the property through that alias in the same generated file, the call supplies T1 evidence and makes the stated invoked && escapes === 0 && !hasT1Evidence oracle false even with the pre-round-25 escape behavior. The nightly matrix therefore reports no gap for the cross-module under-escape this case is intended to guard.

[carlos-alm]

Confirmed correct, thank you — fixed in the doc.

The three-term oracle (invoked && escapes === 0 && !hasT1Evidence) can't flag this family: the escape-shape axis's own in-file alias.prop(...) call is itself a tracked alias reference the points-to solver already correlates to the table's own site (condition 3's alias-flow support, per Success Criteria's own "direct binding, array element + for-of, and alias" list), so hasT1Evidence reads true unconditionally, regardless of what escapes says. The matrix can generate the combination and show escapes flip on inspection, but its own generate-and-check loop can never use that flip to raise a finding — which is exactly why round 25's own gap (and five further let/var/two-hop variants this round found) were caught by a hand-built, two-file real-Node oracle, never by the matrix's nightly run.

Changed in docs/plans/issue-2088.md:

• The "Coverage check" section's header no longer claims the matrix's own oracle would flag all six historical findings — it now says plainly that 5 of 6 are matrix-self-detected and the 6th (this one) structurally cannot be with the matrix in its current single-file shape.
• The round-25 entry in that same list now carries the full explanation above, with a pointer to this comment.
• Filed WU-10 fixture matrix: extend generator/oracle to cross-file combinations #2646 to track extending the generator/oracle to cross-file combinations, which is what would actually close this gap — out of scope for this round's own fix (the exportedNames derivation bug this revision is otherwise about).

[carlos-alm]

@greptileai please re-review.

This round (26) fixes a bug in round 25's own verification: its self-ablation harness computed exportedNames more permissively than the real extractor does (collectExportedDeclarations restricts a non-function identifier/pattern export to const, #2070), which validated condition-2 claims the real extractor falsifies for export let/export var object-valued bindings and aliases — confirmed against the real parser, a corrected reference-model harness, and real two-file Node runtime oracles.

Summary of changes:

• Pinned exportedNames' derivation to a new WU-2-local, keyword-agnostic collectExportedBindingNames, never a widening of the shared, regression-tested collectExportedDeclarations. Mirrored in WU-7/WU-8's Rust.
• Corrected the two false "declarator keyword is irrelevant" claims in place, and added real lettered fixtures (cb)-(ch) for the let/var and two-hop shapes instead of the bundled prose that hid the bug.
• Re-derived computedDispatchTableEvidence is in-memory only — scoped incremental builds can report live dispatch-table properties as dead #2610's standing exception on the corrected behavior; it now holds for every export keyword, not only const.
• Added a fourth standing rule: a verification harness must derive its inputs the way the real pipeline derives them, not by an independent re-implementation.
• Addressed the outstanding P1 (comment 3852228371, "Export matrix masks regression") — replied inline; corrected the "Coverage check" section's overclaim and filed WU-10 fixture matrix: extend generator/oracle to cross-file combinations #2646 for the underlying capability gap.
• Fixed inverted "before condition 4 ever runs" wording, normalized correlation shape 28's label, and named the eval()/new Function() opacity residual in Out of Scope.

[carlos-alm]

@greptileai please re-review.

This round (27) fixes three bugs an independent critic found in round 26's own plan text — two of them in code this plan proposes to ship, not in test apparatus — verified against the real, freshly-built pipeline (dist/domain/parser.js + dist/domain/graph/resolver/points-to.js) rather than argued from reading alone.

Summary of changes:

• B1 (blocking). collectInvokedPropertySites was going to be called with raw symbols.calls, so every call.callerName would read undefined and resolveReceiverSites could only ever probe the bare pts key — but buildForOfConstraints (unchanged, pre-existing) only ever writes a scoped key (${enclosingFunc}::${varName}, e.g. pick::r). Executed against the plan's own headline Dispatch-table function references (resolve: fn) inconsistently flagged dead-unresolved depending on unrelated fanOut #1771 idiom through the real extractor and solver: the site token lands at pts.get('pick::r'), never pts.get('r') — so this would have silently broken correlation for every for-of-bound handler array in the codebase, the exact case follow-up: receiver-type-aware invoked-property matching to reduce dead-code false negatives #2088 exists to fix. Fixed by deriving callerName via findCaller, the same way the existing edge-resolution pass already does, with null mapped to the '<module>' sentinel emitPtsNoReceiverEdges already uses. Mirrored in the Rust WU (find_enclosing_caller + the existing caller_name.is_empty() → "<module>" conversion). Correlation shape 2 gets a self-ablation note proving the flip.
• B2 (blocking). buildPointsToMapForFile's null guard checks nine legacy binding arrays but was never going to gain the new objectLiteralSites field, so a file whose only pts-relevant content is a parenthesised / as const / satisfies / non-null-asserted object literal would return null, and the new site-seeding constraints would never run for that file — even though the site provably doesn't escape. Verified against the real extractor across all four wrapper spellings (table in WU-4). Fixed by adding objectLiteralSites to the guard on both engines; four new correlation shapes (29–32) fixture each spelling with self-ablation notes.
• B3. The definitionNames derivation this plan's own standing rule (round 26) used as its own worked example was itself wrong: it claimed new Set(definitions.map((d) => d.name)) "exactly as points-to.ts already builds it," but the real points-to.ts filters to kind === 'function' || 'method' first — the unfiltered form belongs to an unrelated native-FFI payload. Corrected to the filtered form (confirmed to match the real Rust mirror too), and pinned findTopLevelFunctionNodeByName's existing (verified, not assumed) behavior of returning null for a non-function-shaped declarator value.
• Corrected a stale escape-fallback shape count (79 → 86, missed when round 26 added seven cases), a "sixteen total readings" arithmetic error (seven cases × two dimensions is fourteen), and softened an overstated typeMap-reuse claim. Counts reconciled: 86 escape-fallback + 32 correlation shapes = 118.

[carlos-alm]

@greptileai please re-review.

This round (28) closes a gap in round 27's own B1 fix: deriving callerName via findCaller was necessary but not sufficient, because it silently assumed findCaller's callerName always equals buildForOfConstraints's own enclosingFunc scope prefix. Executed end-to-end against the real, unmodified pipeline (dist/domain/parser.js + dist/domain/graph/resolver/points-to.js + dist/domain/graph/builder/call-resolver.js), that equality is false for three shapes ordinary in this very (TypeScript) codebase — round 27's own single-probe fix leaves all three reporting the plan's #1771 idiom's handlers dead again.

Summary of changes:

• B1 completion (blocking). For a TS class method (instance/static/getter/async, all four confirmed independently), buildForOfConstraints writes the bare method name (run::r) while findCaller resolves the qualified one (C.run::r) — TS class names parse as type_identifier, and the context-collector's class-name qualification is identifier-only. For a class-field arrow or an object-literal arrow-valued property, buildForOfConstraints writes <module>::r while findCaller resolves C.run/obj.run — the context-collector's dispatch has no case for field_definition/public_field_definition or a pair at all, on either engine. Both root causes verified independently in the Rust extractor too (enclosing_func_context, whose own doc comment already names the TS-class caveat) and filed as #2647 rather than fixed at the source — it's a shared primitive that also scopes param-flow/array-elem/spread-arg/array-callback constraints on both engines, well outside this plan's stated scope. Also confirmed (execution, not hypothesis): two same-named TS methods in different classes collapse onto the identical bare key, so a bare/normalised fallback inherits a bounded, pre-existing collision risk — bounded to over-crediting an unrelated method's own array as a possible target, never to hiding a real one. Considered and rejected widening WU-4's seeding instead (the plan's own "option 2"): buildObjectLiteralSiteConstraints never produces a ${enclosingFunc}::${varName}-shaped key in the first place, so no version of "WU-4 also writes a normalised key" can rescue a key WU-4 never writes. Fixed by widening resolveReceiverSites's probe set (callerName, its own last-dot segment, and the '<module>' sentinel, unioned) rather than the derivation — a documented tolerance for the divergence, not a claim it doesn't exist. Three new correlation shapes (33–35, one per previously-uncovered enclosing-scope shape) fixture this with self-ablation showing the one probe that rescues each. Mirrored into WU-7/WU-8 for the Rust engine.
• Four smaller fixes found in the same pass: ptsMapsByFile's Pass 1/3 typing (buildPointsToMapForFile genuinely returns PointsToMap | null; the map was typed as if it couldn't be), the misspelled buildNativeFilesInput → buildNativeFileInputs, the round-10 Builder note's shape count left at "twenty-eight" after round 27 added four shapes without updating this line, and callAssignments's "exactly two fields" overclaim (it carries two more, unused here).

Counts reconciled: 86 escape-fallback + 35 correlation shapes = 121.

[greptile-apps]

Fallback scopes cross-credit sites

When a file has multiple for-of bindings with the same receiver name, candidateScopesFor unconditionally probes the caller's unqualified name and module scope, then unions every matching site. The call consequently supplies T1 evidence to unrelated object-literal sites, preserving their same-named handlers as live and losing the intended dead-code recall improvement.

[carlos-alm]

Confirmed — you're right on the mechanism, and this was independently found in the same round: candidateScopesFor unions the scoped, last-dot, and <module> probes unconditionally, never short-circuiting once an earlier probe already resolved a call correctly, so a same-named receiver elsewhere in the file (another for-of, or a same-bare-named module-level function) does get cross-credited. Fixed in the doc at 8830670, not in the probe set — this is a deliberate, bounded, measured trade, not an oversight, and the analysis is now written up in full in WU-5(a)'s collision note plus WU-10 correlation shape 36.

Measured cost, from executing the widened set against codegraph's own src/: 113 files contain a for-of, 577 for-of bindings, 68 non-value-ref member calls on a for-of-bound receiver. Round 27's single (scoped-only) probe: 28 hits / 2 collisions. The round-28 widened set: 31 hits / 3 collisions — +3 resolving call sites against +1 new colliding one, 1.5% of the 68 candidates. Per probe: the last-dot probe alone contributed 1 genuine rescue and 0 collisions in this repo; the <module> probe alone contributed 0 rescues here and 3 leaks.

The proved bound: T1's over-credit is a subset of T2's own admit set. collectInvokedPropertySites and the real collectInvokedPropertyNames share the same collection predicate (call.receiver && call.dynamicKind !== 'value-ref') and the same key source (call.name) — the only difference is T2's set is accumulated globally across every file before any file's points-to map exists, while T1's correlation is per-file. Any property name a collision could ever attribute to an unrelated site is, by that identical predicate, already a member of T2's global invokedNames. So the worst case is byte-identical to pre-#2088 behaviour for the affected pairs: it can never mark live what #1895 already marked dead, and it never marks anything dead — it can only make T1 credit, for the wrong structural reason, a property T2 would already have credited anyway.

Why the probes stay rather than narrowing back down: removing the <module> probe reopens shapes 34 and 35 (class-field arrow, object-literal arrow prop — enclosingFunc never gets a context for either node kind and falls through to <module> unconditionally); removing the last-dot probe reopens shape 33 (TS class method — a TS class name parses as type_identifier, so enclosingFunc stays unqualified while findCaller resolves the qualified name). Each was independently verified dead under that probe's own single-probe ablation before this round. The actual fix — reconciling funcStack with findCaller at the extractor so the two stop diverging — is out of this plan's scope and is filed at #2647.

Shape 36 (WU-10, above the escape-fallback shapes) is the fixture covering this specific cost: two same-named TS class methods, each with its own for-of array bound to the same receiver name, colliding on one scoped pts key via the last-dot probe — asserting the over-credited-but-still-live outcome directly, with a self-ablation showing the collision (and, inseparably, the correct resolution) both disappear when that one probe is removed. The write-side collision and the extractor/solver output it depends on were re-executed against the real, unmodified pipeline rather than only argued.

[carlos-alm]

@greptileai please re-review.

Round 29 (8830670) on top of 59bd575 — documentation-only, per an independent critic's PASS at the prior head: the escape analysis, the probe set, the axes, the oracle, and every fixture's behaviour are unchanged. Four items, all in docs/plans/issue-2088.md:

1. Collision write-up expanded, one claim corrected. WU-5(a)'s B1-completion note named one collision family (two same-named TS class methods' arrays colliding on a shared pts key) and said the widened probe set introduces "not a new risk" — false as written, true only of that one family. Replied to directly on your own "Fallback scopes cross-credit sites" thread, which independently found the same mechanism. Rewritten to name all three families (the pre-existing write-side collision; a correctly-resolving call additionally picking up a same-bare-named module-level function via the last-dot probe; the unconditional <module> probe merging any module-scope for-of into every same-named-receiver call in the file), state the actual bound (T1's over-credit is a subset of T2's own admit set — same collection predicate, same key source, so the worst case is byte-identical to pre-follow-up: receiver-type-aware invoked-property matching to reduce dead-code false negatives #2088 behaviour and can never mark anything dead), and quantify it against codegraph's own src/ (68 candidate calls; 28→31 hits, 2→3 collisions).
2. Correlation shape 36 added (WU-10): a minimal two-array fixture of Family 1, asserting the over-credited-but-still-live outcome directly rather than only arguing it, with a self-ablation isolating the collision to the one responsible probe. The write-side pts collision and the extractor output it depends on were re-executed against the real, unmodified pipeline. Shape/case counts reconciled everywhere they're enumerated (35→36 correlation shapes, 121→122 total).
3. Noted the widened probe set reaches beyond for-of receivers: a this receiver inside a method also gets probed against thisCallBindings' ${callee}::this keys via the same last-dot/<module> mechanism — same T2 bound, inert in every fixture tested, no probe-set change.
4. Two real citations added and corrected against current main (src/domain/parser.ts:1181, src/domain/wasm-worker-entry.ts:646) illustrating the <module>-probe mechanism concretely — verified before use; the second site's receiver turned out to be a same-named parameter, not itself the _extToLang.get(ext) local, and the credited array is independently exported/escaping, so T2 already governs its own outcome regardless of the collision. Both corrections are reflected in the write-up.

[carlos-alm]

@greptileai

[greptile-apps]

Stale recursive scope instructions

When an implementer follows these instructions for an alias or loop binding whose name collides in the original scope, allReferencesTracked reuses the fixed outer boundary instead of deriving the recursion subject's scope. The walk can then miss an escaping use such as sink(r), mark the site local-closed, and cause exclusive T1 evidence to report a live property dead.

[carlos-alm]

Confirmed and fixed in 8aced6d. The Top-level call comment above computeObjectLiteralSiteEscapes's call to allReferencesTracked (lines 1410-1420) still described the pre-round-21 contract verbatim — "threads that fixed node through its own recursive calls unchanged" / "the boundary must be computed exactly once, here, rather than re-derived per recursive call" — even though round 21's own essay (this file, further down) explicitly supersedes that: each recursion (rebinding alias, for-of loop variable) recomputes its OWN declaringScope, seeded from the recursion subject's own lexical position, falling back to the enclosing call's scope (never straight to root) only when nothing shadows the subject between its own position and that boundary. The essay text itself already carried inline "corrected by ROUND 21" annotations at every point it was originally stated (lines 3806, 3825, and the Rust mirror at 5514), but this specific comment — the one sitting directly above the actual call site, the most likely place an implementer reads literally rather than archaeologizing through the full round history — never got the same correction and flatly contradicted it.

Rewrote the comment to state the round-21-corrected contract directly (per-level recomputation, with the enclosing-call fallback and the for-of kind === 'var'" split's own #2643 pointer), rather than the superseded round 8-20 one, while still pointing to allReferencesTracked`'s own doc comment and the round-21 essay for the full mechanism and counter-example. No behavior or code changes — this PR is docs-only — just correcting the one instructional comment that was out of sync with the design it's supposed to be summarizing.

[carlos-alm]

@greptileai