fix: close remaining Dart language support gaps

[xFlaviews]

Summary

Fixes 4 gaps in the Dart language support that were not addressed in PR #204:

• extractFunctionName + FUNCTION_NODE_TYPES: PR feat: add Dart language support #204 moved @definition.function onto function_signature nodes but never added them to FUNCTION_NODE_TYPES or extractFunctionName. Without this, findEnclosingFunctionId can't resolve Dart function scopes — all CALLS edges from inside Dart functions have no sourceId, breaking call attribution.

• formal_parameter_list in paramListTypes: Dart's tree-sitter grammar uses formal_parameter_list (not formal_parameters). Without adding it to paramListTypes, extractMethodSignature returns parameterCount: 0 for every Dart function.

• Write-access queries: PR feat: add Dart language support #204 has no @assignment patterns for Dart. Without them, no ACCESSES write edges are emitted — obj.field = value and this.field = value are invisible to the graph. Every other language (except C) has these.

• initialized_identifier guard: DART_DECLARATION_NODE_TYPES includes initialized_identifier (for comma-separated declarations like String a, b, c), but extractDartDeclaration only handled initialized_variable_definition. Variables after the first comma silently got no type binding because the type lives on the parent node.

Also adds Dart column to the feature matrix in type-resolution-system.md.

Changed files

File	Change
ast-helpers.ts	Add function_signature/method_signature to FUNCTION_NODE_TYPES and extractFunctionName; add formal_parameter_list to paramListTypes
tree-sitter-queries.ts	Add 2 write-access query patterns for Dart
type-extractors/dart.ts	Add initialized_identifier guard in extractDartDeclaration
type-resolution-system.md	Add Dart column to feature matrix

Test plan

• tsc --noEmit passes
• All 4112 tests pass (119 test files, 0 failures)
• No existing language behavior affected (all changes are additive — new else if branches, new set entries, new query patterns)

🤖 Generated with Claude Code

[vercel]

@xFlaviews is attempting to deploy a commit to the NexusCore Team on Vercel.

A member of the Team first needs to authorize it.

[magyargergo]

I'll post my findings and we can fix them here. You nicely identified some gaps already! Thank you

[magyargergo]

Dart Integration Tests & Pipeline Fixes

Added integration tests for Dart field-type resolution and call-result binding, along with five pipeline fixes to make them pass.

What's fixed

1. Field declaration queries — Dart class fields (String name = '', String? name) now captured as Property nodes via new tree-sitter query patterns. Previously zero Property nodes were emitted for Dart classes.

2. Import resolution — import 'models.dart' (bare relative path without ./) was being mangled by the generic Java-style dot-to-slash converter. Now prepends ./ before standard resolution.

3. Call attribution — Dart's tree-sitter grammar places function_body as a sibling of function_signature (not a child). The parent-walk in findEnclosingFunction never found the enclosing function, so all CALLS edges were sourced from the File node instead of the Function. Fixed via a new enclosingFunctionFinder hook on the LanguageProvider interface (same strategy pattern as labelOverride), with the Dart-specific logic in languages/dart.ts. No Dart-specific code in the generic processors.

4. Receiver chain extraction — Added unconditional_assignable_selector to MEMBER_ACCESS_NODE_TYPES and Dart-specific handlers in extractReceiverName, extractReceiverNode, and extractMixedChain for Dart's flat sibling-selector AST model.

5. Relative import ./ prefix — Ensures resolveStandard treats bare Dart imports as relative paths.

Test results

• 9 passing integration tests across 2 describe blocks (field-type resolution + call-result binding)
• 1 skipped — ACCESSES edges for field reads in chains (user.address read tracking). The chain extraction and member detection are wired, but the base receiver type lookup from the type-env doesn't propagate Dart function parameter bindings to the call-processor context yet. Aiming to unskip this — investigating the type-env scoped binding propagation.

Files changed

Category	Files
Language provider	language-provider.ts (new enclosingFunctionFinder hook), languages/dart.ts
Queries	tree-sitter-queries.ts (field declaration patterns)
Import resolver	import-resolvers/dart.ts (./ prefix)
Call analysis	utils/call-analysis.ts (Dart receiver extraction + mixed chain)
Processors	call-processor.ts, workers/parse-worker.ts (generic hook consumption)
Tests	test/integration/resolvers/dart.test.ts (new)
Fixtures	dart-field-types/, dart-call-result-binding/ (new)

[magyargergo]

@xFlaviews Let me know what you think 🙏 There's one integration test skipped and if you could look into it that would be amazing :)

[github-actions]

CI Report

✅ All checks passed

Pipeline Status

Stage	Status	Details
✅ Typecheck	success	tsc --noEmit
✅ Tests	success	unit tests, 3 platforms
✅ E2E	success	gitnexus-web changes only

Test Results

Tests	Passed	Failed	Skipped	Duration
4356	4354	0	2	186s

✅ All 4354 tests passed

2 test(s) skipped — expand for details

• buildTypeEnv > known limitations (documented skip tests) > Ruby block parameter: users.each { |user| } — closure param inference, different feature
• Dart field-type resolution > emits ACCESSES edges for field reads in chains

Code Coverage

Tests

Metric	Coverage	Covered	Base	Delta	Status
Statements	70.65%	10928/15467	70.29%	📈 +0.4	🟢 ██████████████░░░░░░
Branches	61.22%	7440/12152	60.71%	📈 +0.5	🟢 ████████████░░░░░░░░
Functions	74.62%	950/1273	73.93%	📈 +0.7	🟢 ██████████████░░░░░░
Lines	73.19%	9758/13332	72.79%	📈 +0.4	🟢 ██████████████░░░░░░

---

_{📋 View full run · Generated by CI}

[magyargergo]

Dont worry about it! I'm defierring it into #494

[magyargergo]

@claude Let's run a final review if this PR is production ready and ready to be merged

[github-actions]

Claude finished @magyargergo's task in 3m 10s —— View job

---

PR #524 Final Review

• Gather context and understand the request
• Read all changed source files
• Review test fixtures and integration tests
• Analyze CI results and skipped tests
• Provide final production-readiness assessment

---

Verdict: ✅ Production-ready — safe to merge

CI is green, 4339/4341 tests pass, coverage up across all metrics. The 2 skipped tests are properly documented known limitations.

---

What the PR does (two contributor layers)

xFlaviews (original 4 fixes):

• FUNCTION_NODE_TYPES + extractFunctionName — adds function_signature / method_signature so the Dart enclosingFunctionFinder hook can validate prev-sibling types
• formal_parameter_list in paramListTypes (inside extractMethodSignature) — fixes parameterCount: 0 for all Dart functions
• Write-access queries — correct assignable_expression + unconditional_assignable_selector patterns; this handled separately from identifier which matches Dart's grammar
• initialized_identifier guard — reads the type annotation from the parent node for comma-separated declarations (String a, b, c)

magyargergo (5 pipeline fixes with integration tests):

• enclosingFunctionFinder hook on LanguageProvider — clean strategy-pattern extension; Dart's function_body ↔ function_signature sibling AST model is fully isolated to languages/dart.ts
• Field declaration queries (declaration > initialized_identifier_list) — emits Property nodes for class fields
• Import resolution — bare models.dart → ./models.dart prefix before resolveStandard
• Dart receiver extraction (unconditional_assignable_selector in MEMBER_ACCESS_NODE_TYPES, receiver extraction from selector.previousNamedSibling)
• extractMixedChain Dart selector branch

---

Issues found (all minor, none blocking)

1. Non-null assertion on previousSibling in hook consumption (call-processor.ts:225, parse-worker.ts:329)

// call-processor.ts:225
const override = provider.labelOverride(current.previousSibling!, finalLabel);
// parse-worker.ts:329
const override = provider.labelOverride(current.previousSibling, finalLabel);

call-processor.ts uses ! while parse-worker.ts doesn't — inconsistency. If a future language implements both enclosingFunctionFinder and labelOverride simultaneously, and the function_body-equivalent has no previous sibling, this crashes in call-processor.ts. Not a Dart issue today since Dart doesn't use labelOverride, but worth noting.
Fix this →

2. paramListTypes is recreated per call

paramListTypes is a new Set([...]) inside extractMethodSignature (called very frequently). Minor perf concern — pre-existing pattern but formal_parameter_list now adds to a hot allocation. Not worth blocking the PR; could be extracted to module scope in a follow-up.

3. extractMixedChain Dart selector branch handles fields only, not calls

When a Dart chain has a call-selector (.getAddress()) followed by a field-selector (.city), the selector branch only extracts unconditional_assignable_selector children — it has no argument_part handling. Mixed Dart chains are unresolvable via this path. This is exactly what the skipped test covers ('emits ACCESSES edges for field reads in chains'), so it is already tracked. Tracked in #494.

---

What's solid

• Additive design — every change is a new else if branch, a new set entry, or a new query pattern. No existing language behavior is touched. ✅
• Hook isolation — Dart-specific logic lives only in languages/dart.ts; the two pipeline files (call-processor.ts, parse-worker.ts) use a generic strategy hook. ✅
• Import resolver — stripped.startsWith('.') ? stripped : './' + stripped is minimal and correct; dart: and package: paths are handled before this line. ✅
• Write-access queries — both obj.field = value and this.field = value patterns are covered, matching every other language that supports write edges. ✅
• Integration tests — cover class/property detection, HAS_PROPERTY edges, CALLS attribution to named function (not File), and import edges. Skipped test is it.skip() with detailed comment (not it.todo()), explains exactly what's missing and why. ✅
• CI: 4339 passed / 0 failed / 2 skipped (1 Dart chain ACCESSES, 1 pre-existing Ruby). Coverage up +0.4–0.7% across all metrics. ✅

[xFlaviews]

@xFlaviews Let me know what you think 🙏 There's one integration test skipped and if you could look into it that would be amazing :)

should i do it or it's deferred to #494 ?

[magyargergo]

@xFlaviews Let me know what you think 🙏 There's one integration test skipped and if you could look into it that would be amazing :)

should i do it or it's deferred to #494 ?

No, I'm doing a much more bigger refactoring and it needs some architectural decision I have in mind. Thank you! Btw, if you want feel free to join to our Discord and if you have more ideas for contribution we'll always welcome it! :)