Sync to upstream e63fe2e, and narrow the TS/JS patch layer to what upstream leaves

[Dshuishui]

Moves the base from 3ed73bc to upstream e63fe2e (main, 2026-09-27), 93
commits on (91 of them not merges), and releases as 1.6.0-fmagent.6.
Supersedes #17, which was never merged: this branch is built on it, so its
commits come along, and the fork layer is then cut back to what upstream still
leaves.

Upstream has since merged four things this matters for:

• fix(dart): index a Dart 3 extension type as the type it is (#1784) colbymchenry/codegraph#1865, this project's own fix for Dart 3 extension types (Dart: extension type members stopped being indexed in #1780 — the method_signature gate has no language check colbymchenry/codegraph#1784). Patch 5
  here was kept byte-identical to it, so it drops out.
• fix(extraction): name a function bound through a curried wrapper (#1747) colbymchenry/codegraph#2002, upstream's fix for TypeScript/JavaScript: a function bound through a wrapper call gets no node unless the wrapper is a React hook colbymchenry/codegraph#1747, which this project reported: a function
  passed through a curried wrapper is named after the binding its result lands
  in — a declarator, or an object member's key.
• fix(extraction): recover single-argument C/C++ function macros (#1373) colbymchenry/codegraph#2017 for C/C++: single-argument function-defining macros are indexed under the wrong symbol, breaking call resolution colbymchenry/codegraph#1373 (C/C++ functions defined through a single-argument macro)
  and fix(rust): keep self method calls on the correct owner colbymchenry/codegraph#1882 for Rust: self.method() resolves to a same-named method on an unrelated type colbymchenry/codegraph#1861 (Rust self.method() owners), both reported from here.

What happens to each patch

1. fm_agent work-directory exclusion — unchanged.

2. Wrapper naming — narrowed to what nothing binds. After the merge both
mechanisms were in place and the fork's ran first, so every wrapped function kept
its wrapper string as its name and colbymchenry#2002 never applied. Now the fork defers:
wrappedFunctionName returns nothing wherever curriedWrapperBoundName names the
function, on both extraction paths. The wrapper string names only a wrapper whose
result nothing binds:

const invoke = Effect.fn("Service.run")(function* () {…})          // invoke        (upstream)
function make() { return { getMode: Effect.fn("ACP.getMode")(…) } } // getMode       (upstream)
Runtime.handler("x", Effect.fn("cli.api")(function* () {…}))       // cli.api       (fork)
yield* InstanceState.make(Effect.fn("Agent.state")(function* …))   // Agent.state   (fork)

On sst/opencode that is 38 of the 1,055 wrapper sites — arguments to another
call, array elements, arrow bodies, return values. Upstream alone reaches the
other 1,017.

3. Effect-TS resolution — the bare-name bridge goes, the service matcher is
rebuilt on upstream's names.

The bridge linked helper() to a node named Ns.helper, for a binding the old
naming had hidden. With the binding now the node's name, all it still did was
mint an edge whenever a string's tail matched another name. This is the codex
P2 on #17:

const invoke = Effect.fn("Service.run")(function* () {…})
function run() {…}
function caller() { invoke(); run() }

	invoke()	run()
.5	the constant invoke	Service.run (false)
this	the function invoke	the function run

The service matcher looked members up by Ns.method node names, which no longer
exist: under upstream's naming the member is evaluate, and the namespace
survives only in Effect.fn("Policy.evaluate") on its own line. Without a
change, about 470 calls on sst/opencode go unresolved —
const policy = yield* Policy.Service; policy.evaluate(), and direct calls on an
imported namespace such as EventV2.readAggregate(). effectWrapperMembers now
reads the wrapper string off the member's line; the namespace comes from the
receiver's own declaration, or from a capitalised receiver itself; the calling
file must import it; only a unique member resolves.

The pre-filter escape in src/resolution/index.ts existed for these lookups and
changes nothing without them — identical call edges on sst/opencode with and
without it — so that file is upstream's again.

4. Generator class fields — unchanged. Upstream's generator fix (colbymchenry#1741) still
does not reach the two class-field helpers, on either extraction path. FORK.md
said the kernel already listed generator_function; it does not upstream, and
the patch changes both paths, so that entry is corrected.

5. Dart extension types — dropped, being colbymchenry#1865.

The four cases the fork had added inside upstream's extraction.test.ts and
kernel-tsjs-parity.test.ts asserted the old naming. They go, so both files are
upstream's again, and their cover moves into fm-agent-* files. Against upstream
the fork now touches 21 files, down from 25.

Verification

sst/opencode at df23b7f, indexed with each build and read through FM-Agent's
own TypeScript consumer (src/languages/typescript.py):

	.5	upstream e63fe2e	this
Effect.fn* wrapper sites with a function node	1,055 / 1,055	1,017 / 1,055	1,055 / 1,055
call edges	29,447	—	27,852
call edges, test code excluded	27,053	—	25,585

The 5% fewer edges are upstream's, and mostly false ones it stopped minting.
Comparing function-to-function edges outside test code by source position, 1,281
of .5's are absent here. About 1,170 of them are method calls on a receiver,
and in the samples we read nearly all are a value of an unrelated type landing on
a same-named project function — value.split("/"), lines.at(-1),
path.normalize(p), window.location.assign(href) — which upstream now declines
without receiver evidence. Of the service calls the old
naming reached, all but 9 still resolve.

Tests, with GIT_CONFIG_GLOBAL=/dev/null and a locally built kernel
(CODEGRAPH_KERNEL_EXPECT=1):

	files	tests
upstream e63fe2e	302 passed	5,296 passed, 23 skipped
this	306 passed	5,318 passed, 23 skipped

The four extra files are the fork's fm-agent-* suites. Run against upstream
unpatched, exactly the nine cases that cover patches 2 and 3 fail, and the rest
of those two files pass.

Not fixed here

In a monorepo where two packages each map @/* to their own src, upstream
e63fe2e resolves an @/ import in one package against the other's. On
sst/opencode, import { showToast } from "@/utils/toast" in packages/app
binds to the same-named handler in packages/opencode; 17 call sites move to a
wrong target this way. The .5 build, on 3ed73bc, does not do this. It is upstream's, not the
fork's, and is left for an upstream report.

Release

1.6.0-fmagent.6. FM-Agent pins .1 today; moving its pin is a separate change
there once this is released.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Dshuishui]

Verification before merge

1. Does this branch still fix what #12, #15 and the since-reverted chained-call fix were for?

The input code from the #12 and #15 tests, taken verbatim, indexed with upstream e63fe2e, the .5 release bundle and this branch (all three on the native kernel), reading the nodes and call edges directly:

Problem	This branch
A function wrapped in Effect.fn("X")(function*) gets a node, and the calls in its body are attributed to it	✅ Named after its binding where it has one (colbymchenry#2002); its callers reach the function node (.5 reached the same-named constant)
helper() on a function-local wrapped const reaches it in the same file, not a same-named function elsewhere	✅ (upstream already does this)
const s = yield* Ns.Service; s.m() reaches the implementation, including through one create() factory	✅ (patch 3; upstream does not)
No edge when the tail is ambiguous, the target is visible only in a sibling scope, or the receiver is shadowed	✅
Provider.configure().model() is not bound to a local model	✅ (upstream colbymchenry#1759)

Run as-is, the #15 test file has 6 failures, all asserting that a node is named after the wrapper string (such as Ns.helper). This branch names by binding, per colbymchenry#2002; the corresponding edges are all present and point at the same place.

2. sst/opencode at e03db9b

	upstream	.5	this branch
Call edges from a real run that are found (of 333)	47	176	177
Method calls on a yield* service that reach the implementation (of 593)	0	451	450
Calls to functions imported through the @/ alias (of 671)	574	592	575
String-named wrapped functions that have a caller (of 954)	219	434	461

Where the real-run edges come from: opencode's own OTLP export, with a scripted fake LLM driving 10 session scenarios, and each Effect span's parent/child pair turned into a function → function edge.

The roughly 1,000 edges .5 has over this branch are mostly built-in method calls such as .replace(), .trim() and .keys() bound to a same-named function in the project, which upstream fixed after .5's base. Of 12 sampled, about 9 are false.

3. Known regressions against .5

• Alias targets that are .tsx (17 call sites). When several packages each define @/*, an import of @/utils/toast.tsx resolves to the same-named file in another package. Upstream introduced this after .5's base; it is outside this fork's patches and will be reported upstream separately.
• The Ns.Service.use((x) => x.m()) callback form. .5 sometimes reached these through its tail-name fallback; with the fallback gone, this branch does not. Non-test code in opencode has 52 calls written this way. Left as is for now.

Overall this branch is not worse than .5; it merges and releases as a regular (non-pre) release.