fix(python): avoid local matches for external dotted imports

[yacinehmito]

Summary

Prevent external dotted Python imports like django.apps from falling through to generic suffix matching when the leading package does not exist in-repo, and add Django-based regression coverage for that case.

Motivation / context

Closes #898.

The bug shows up in Django-style projects where multiple local files share framework-like basenames such as apps.py, urls.py, asgi.py, or wsgi.py. GitNexus could emit local IMPORTS edges for django.* imports instead of leaving them unresolved as external dependencies.

Areas touched

• gitnexus/ (CLI / core / MCP server)
• gitnexus-web/ (Vite / React UI)
• .github/ (workflows, actions)
• eval/ or other tooling
• Docs / agent config only (AGENTS.md, CLAUDE.md, .cursor/, llms.txt, etc.)

Scope & constraints

In scope

• Guard the Python import strategy so unresolved dotted imports with no in-repo leading package do not suffix-match unrelated local files
• Add a Django fixture with two apps and a real local cross-app import to reproduce the bug
• Add unit and integration regressions for django.apps, django.urls, django.core.asgi, and django.core.wsgi

Explicitly out of scope / not done here

• Broader redesign of Python import resolution or package-indexing semantics
• Any changes to web UI, MCP contracts, or non-Python resolvers
• Golden snapshot updates unrelated to this fix

Implementation notes

The change is intentionally narrow in gitnexus/src/core/ingestion/import-resolvers/configs/python.ts.

For dotted imports, the Python resolver now checks whether the leading segment appears anywhere in the repo before allowing generic fallback. That keeps internal imports like accounts.models working while absorbing external imports like django.apps so they do not resolve to local files such as accounts/apps.py or config/urls.py.

Testing & verification

• cd gitnexus && npx vitest run test/unit/import-resolver-factory.test.ts test/integration/resolvers/python.test.ts
• cd gitnexus && npx tsc --noEmit
• cd gitnexus && npm test — the full-suite run hit an unrelated failure in test/integration/pipeline-graph-golden.test.ts (fatal: not a git repository) plus vitest worker-exit noise; rerunning npx vitest run test/integration/pipeline-graph-golden.test.ts alone passed

Risk & rollout

Low risk: the behavioral change is limited to Python dotted-import fallback before generic suffix resolution.

No migrations or config changes are required. If the behavior needs to be rolled back, reverting this PR cleanly removes both the resolver guard and the Django regression fixture/tests.

Checklist

• PR body meets repo minimum length (workflow may label short descriptions)
• If AGENTS.md / overlays changed: headers, scope block, and changelog updated per project conventions
• No secrets, tokens, or machine-specific paths committed

[vercel]

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

A member of the Team first needs to authorize it.

[magyargergo]

Nice one! Thank you for your contribution! 🚀

[magyargergo]

@claude Act as a senior reviewer for GitNexus. Your job is to determine whether this PR is production-ready for this repo, not to give a generic code review.

You are reviewing a PR in the GitNexus monorepo:

• gitnexus/ → CLI + MCP
• gitnexus-web/
• gitnexus-shared/

Your task has 2 phases, in this exact order:

PHASE 1 — DEFINE THE BAR
Before reviewing the diff, establish a concise repo-specific definition of “production-ready” for GitNexus, based only on the repo docs and the affected area.
Keep this definition practical and reviewable. Do not invent standards that are not grounded in the repo.

PHASE 2 — REVIEW THE PR AGAINST THAT BAR
Review the actual diff only after defining the bar.
Stay tightly scoped to the changed code and its direct consequences.

---

CONTEXT TO LOAD FIRST
Read these before reviewing:

• AGENTS.md
• GUARDRAILS.md
• CONTRIBUTING.md
• TESTING.md
• ARCHITECTURE.md

Additional context:

• If the diff touches ingestion, also read: ARCHITECTURE.md § Pipeline Phase DAG
• PR [group/sync] Fix ManifestExtractor never called — config.links always produced 0 cross-links #827 diff area is primarily: gitnexus/src/core/group/ (sync + manifest extractor) plus associated tests

---

PRIMARY OBJECTIVE
Decide whether this PR is safe, correct, maintainable, and operationally acceptable to merge into production for GitNexus.

Do not optimize for completeness at the expense of signal.
Do not pad the review.
Do not propose unrelated refactors.
Do not restate the PR description unless needed for verification.

---

REVIEW RULES

• Every finding must be grounded in specific evidence from the diff or directly relevant surrounding code.
• Every finding must include path:line.
• If you make a behavioral claim, cite the code that proves it.
• If you make a performance claim, explain the mechanism.
• If something cannot be verified from the diff alone, explicitly say so.
• Distinguish clearly between:
  • verified issue
  • plausible risk
  • unverified concern
• Avoid vague wording like “might be better” or “could be improved” unless you explain exactly why.
• Keep the review focused on this PR’s scope only.

For each finding, assign one severity:

• BLOCKING → must be fixed before merge
• NON-BLOCKING → valid issue, but merge may still be acceptable
• NIT → stylistic/minor, not merge-relevant

---

REPO-SPECIFIC REVIEW CHECKLIST
Use these exact headings.

1. Correctness & functional completeness

Check:

• Does the implementation actually satisfy the PR claim?
  • ManifestExtractor is truly invoked
  • config.links produces non-zero cross-links where expected
• Resolver contracts are preserved:
  • resolveSymbol remains exact-match
  • label-scoped Cypher remains correct per contract type
  • flag any regression toward fuzzy or unscoped matching
• Graph schema integrity is preserved:
  • no silent changes to node labels
  • no silent changes to edge types
  • no silent changes to ID generation (generateId)
• Call out any missing wiring, partial integration, dead branch, or mismatch between tests and runtime behavior

2. Code clarity & clean code

Check:

• naming quality
• local cohesion
• dead code
• unnecessary abstraction
• hidden control flow
• confusing indirection
• adherence to repo conventions:
  • direct imports from gitnexus-shared
  • no barrel re-export regressions
  • no // removed comments
  • no unused re-exports
• no drive-by refactors outside stated scope per CONTRIBUTING.md and GUARDRAILS.md § Scope

3. Test coverage & change safety

Evaluate against TESTING.md:

• Are there unit tests under gitnexus/test/unit/ covering the newly wired path?
• Is there a regression guard for 0-link → N-link behavior?
• Are assertions meaningful rather than tautological?
• Are fixtures realistic for manifest inputs?
• If memoization/cache was introduced, is there a test proving hit/miss behavior and correctness?
• Is there evidence the expected validation path would pass for staged gitnexus/ files?
  • tsc --noEmit
  • vitest run --project default
    If not verifiable, say exactly what is missing.

4. Performance

Inspect for:

• hot-path overhead in ingestion/group sync
• excess allocations per manifest entry
• redundant Cypher round-trips
• missed batching or missed parallelism (Promise.all) where it materially matters
• O(n²) or repeated lookup patterns on large repos
• memoization tradeoffs:
  • correctness
  • invalidation
  • bounded vs unbounded memory growth
    Do not speculate casually; explain the mechanism and likely impact.

5. Operational risk

Check:

• Windows/cross-platform safety:
  • stream lifecycle
  • FD/file handle lifecycle
  • path separator assumptions
  • anything resembling prior ENOTEMPTY-style lifecycle regressions
• LadybugDB single-writer invariant is preserved
• Embeddings preservation:
  • no silent breakage of --embeddings
  • .gitnexus/meta.json.stats.embeddings not silently zeroed by changed paths
• MCP contracts remain compatible:
  • group_*
  • query
  • context
  • impact
  • detect_changes
  • rename
  • cypher
    Flag any schema or contract break without migration note
• staleness behavior still triggers correctly (gitnexus/src/mcp/staleness.ts)
• rollback safety:
  • can this PR be reverted safely without re-analyze?
  • if not, explain why

6. Maintainability

Check:

• Does the change respect Pipeline Phase DAG boundaries?
• Is cross-phase coupling being introduced?
• Are manifest-extractor entry points discoverable from group/sync.ts?
• Would the next contributor know where to extend this?
• Is shared logic placed appropriately:
  • in gitnexus-shared/
  • or gitnexus/src/core/**/utils.ts
  • and not duplicated between CLI and web bridge (server/api.ts)?

---

NON-NEGOTIABLES TO VERIFY
From GUARDRAILS.md / CONTRIBUTING.md:

• no secrets, tokens, or machine-specific paths committed
• no blind find-and-replace renames
• if a symbol rename occurred, rename MCP tool or equivalent careful review was used
• upstream impact was considered for modified shared symbols
• no HIGH/CRITICAL impact left unaddressed
• PR title follows conventional commit style + [area] Short description
• PolyForm Noncommercial license headers/metadata untouched

---

OUTPUT FORMAT

Production-ready bar for this PR

Give a concise repo-specific definition in 5–10 bullets.

Findings

For each finding, use this structure exactly:

[BLOCKING|NON-BLOCKING|NIT] Short title

• Evidence: path:line, path:line
• Why it matters: ...
• Recommendation: ...
• Confidence: High / Medium / Low

Only include findings that are real and supported.
If there are no findings in a section, say:

• No issues found in this area based on the diff and reviewed context.

What I could not fully verify

List any behavior you could not prove from the diff, tests, or available context.

Final verdict

Choose exactly one:

• ✅ Ready to merge — no blocking issues.
• ⚠️ Merge after addressing blocking items.
• ❌ Not ready — fundamental concerns.

If verdict is not ready, list the blocking items in priority order.

---

IMPORTANT REVIEW BEHAVIOR

• Be strict on correctness and contracts.
• Be conservative about operational risk.
• Be explicit about uncertainty.
• Do not suggest unrelated refactors.
• Do not turn nits into blockers.
• Do not reward intent; review actual implementation.

[github-actions]

Claude finished @magyargergo's task in 4m 8s —— View job

---

Senior Review — PR #899: fix(python): avoid local matches for external dotted imports

---

Production-ready bar for this PR

Based on GUARDRAILS.md, CONTRIBUTING.md, TESTING.md, and ARCHITECTURE.md, production-ready for a Python import resolver fix means:

1. Resolver contract preserved — { kind: 'files', files: [] } (absorbing sentinel) stops the chain; null continues it. The fix must use exactly these semantics and not regress either path.
2. No fuzzy matching introduced — The guard must not loosen suffix matching for unrelated imports; it must only tighten it for external dotted imports.
3. Graph schema integrity — No changes to node labels, edge types, or generateId logic.
4. Behavioral unit test + integration regression — New behavior must have unit tests covering both the new absorbing path and the preserved fall-through path; integration test must exercise a realistic multi-app fixture and assert both the positive case (local cross-app import retained) and the negative cases (external framework imports absorbed).
5. tsc --noEmit clean — No type errors introduced.
6. Scope discipline — Changes strictly limited to Python import strategy + test additions, per GUARDRAILS.md § Scope.
7. No secrets or tokens — Fixture files must be inert test data only.
8. PR title follows conventional commit format — fix(scope): subject required per CONTRIBUTING.md.
9. Rollback safety — Revert must cleanly restore pre-fix behavior with no DB schema, MCP contract, or embeddings side effects.
10. PolyForm license untouched.

---

Findings

1. Correctness & functional completeness

Correctness of the guard logic — Verified.

The key invariant is that resolvePythonImportInternal (python.ts:52) short-circuits with null for all dotted imports (if (pathLike.includes('/')) return null). This means the new guard in configs/python.ts:29–39 is exclusively responsible for handling multi-segment absolute imports. The three membership checks are all necessary and complementary:

• ctx.index.get(\${leadingSegment}.py`)— catches a root-levelaccounts.py` module
• ctx.index.get(\${leadingSegment}/init.py`)— catches a regular package withinit.py`
• ctx.index.getFilesInDir(leadingSegment, '.py').length > 0 — catches namespace packages (Python 3.3+, no __init__.py) and any other .py files under that directory

All three SuffixIndex operations are O(1) Map lookups. No correctness gaps found.

Internal import fall-through validated — In the unit test:

makeCtx(['accounts/models.py', 'billing/models.py'])

buildSuffixIndex indexes 'accounts:.py' → ['accounts/models.py'], so getFilesInDir('accounts', '.py') returns 1 file. hasRepoCandidate is true, so the strategy returns null and delegates to createStandardStrategy. The chain continues correctly. ✓

Integration test covers the critical positive case (billing/models.py → accounts/models.py) and four negative cases (django.apps, django.urls, django.core.asgi, django.core.wsgi). ✓

• No issues found with ManifestExtractor (not applicable to this scope).
• No changes to node labels, edge types, or ID generation. ✓

2. Code clarity & clean code

No issues found in this area based on the diff and reviewed context. The comment block at configs/python.ts:25–28 precisely explains the invariant. Naming is clear. No dead code, no barrel re-export changes, no // removed comments, no drive-by refactors.

NIT — Redundant .filter(Boolean) in leading segment extraction

• Evidence: configs/python.ts:31
• Why it matters: pathLike is derived from rawImportPath.replace(/\./g, '/'), which cannot produce leading or trailing slashes (Python import identifiers cannot start or end with . at this point — relative imports are already handled above). .filter(Boolean) is therefore dead but harmless.
• Recommendation: const [leadingSegment] = pathLike.split('/'); is equivalent and cleaner.
• Confidence: High

3. Test coverage & change safety

Unit tests added in test/unit/import-resolver-factory.test.ts:519–547:

• Covers the new absorbing path for django.apps (external + no local leading segment) ✓
• Covers django.urls, django.core.asgi, django.core.wsgi in a single it block ✓
• Covers the fall-through path when the leading segment exists in-repo (accounts.models) ✓
• Existing 'returns null for non-relative imports' test is preserved ✓

Integration test added in test/integration/resolvers/python.test.ts:1854–1902:

• Fixture is realistic (real Django project structure with two apps) ✓
• Positive regression: billing/models.py → accounts/models.py IMPORTS edge retained ✓
• Four negative assertions confirm no wrong IMPORTS edges from framework imports ✓

Stated validation from PR description:

• npx vitest run test/unit/import-resolver-factory.test.ts test/integration/resolvers/python.test.ts — passes ✓
• npx tsc --noEmit — passes ✓
• Full suite failure in pipeline-graph-golden.test.ts is attributed to fatal: not a git repository (environment issue unrelated to this change). That test passed when re-run in isolation. Cannot independently verify this from the diff.

NON-BLOCKING — Integration test assertion is slightly under-specified for the negative local-import case

• Evidence: python.test.ts:1861–1867
• Why it matters: The test asserts that a IMPORTS edge from billing/models.py → accounts/models.py exists, confirming local dotted imports still resolve. It does not assert the total count of IMPORTS edges from billing/models.py (which would rule out spurious edges from from django.db import models resolving to some local db.py). If a future fixture addition introduced a db.py at the root, this test would still pass while masking a regression.
• Recommendation: Add expect(imports.filter(e => e.sourceFilePath === 'billing/models.py').length).toBe(1) to pin the edge count.
• Confidence: Medium (plausible risk, not a verified failure in the current fixture)

4. Performance

No issues found. The guard adds exactly 3 O(1) Map lookups per dotted import during the parse phase. No additional allocations per import. The pathLike.includes('/') short-circuit means single-segment imports pay no overhead. No O(n²) introduced.

5. Operational risk

• Windows/cross-platform: Safe. leadingSegment is derived from a Python import path (dots → forward slashes). No OS-level path operations. ctx.index is pre-normalized.
• LadybugDB single-writer invariant: Not affected. No changes to graph load, schema, or adapter.
• Embeddings: Not affected. No changes to run-analyze.ts or any --embeddings code path.
• MCP contracts: Not affected. No changes to tools, resources, or staleness detection.
• Rollback safety: Clean revert. Removing this PR removes the guard and the tests; pre-fix behavior is fully restored. No migrations, no DB schema changes, no config changes required.

6. Maintainability

The fix is placed in exactly the right file per ARCHITECTURE.md (import-resolvers/configs/python.ts). The guard follows the same structural pattern as the existing relative-import absorber immediately above it. The next contributor extending Python import behavior will find this in the natural location.

No cross-phase coupling introduced. No logic duplicated between CLI and web bridge.

---

What I could not fully verify

1. Full suite greenness — The PR reports test/integration/pipeline-graph-golden.test.ts failed with fatal: not a git repository and passed when re-run alone. This is plausible (golden tests often require git context), but CI run status was not independently accessible.
2. Suffix index deduplication behavior on Windows paths — buildSuffixIndex normalizes paths in makeCtx for tests, but the production code path's normalization was not traced end-to-end. Noted as a pre-existing concern, not introduced here.
3. Behavior when a local file coincidentally shadows a framework name (e.g., a top-level django.py in-repo) — the guard would treat django as in-repo and allow suffix fallback. Considered acceptable and correct behavior, but not exercised by a test.

---

Final verdict

✅ Ready to merge — no blocking issues.

The implementation is correct, the resolver contracts are preserved, the tests are behavioral and grounded in the bug being fixed, the scope is disciplined, and the risk is low. The NON-BLOCKING item (under-specified import count assertion) and the NIT (redundant .filter(Boolean)) are worth addressing in a follow-up but do not warrant blocking the merge.

---

[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
6550	6453	0	97	256s

✅ All 6453 tests passed

97 test(s) skipped — expand for details

• Swift MethodExtractor > isTypeDeclaration > recognizes class_declaration
• Swift MethodExtractor > isTypeDeclaration > recognizes protocol_declaration
• Swift MethodExtractor > isTypeDeclaration > rejects import_declaration
• Swift MethodExtractor > visibility > extracts public method
• Swift MethodExtractor > visibility > extracts private method
• Swift MethodExtractor > visibility > defaults to internal when no modifier
• Swift MethodExtractor > protocol methods > marks protocol method as abstract
• Swift MethodExtractor > static and class methods > detects static func as isStatic
• Swift MethodExtractor > static and class methods > detects class func as isStatic
• Swift MethodExtractor > parameters > extracts parameters with types and default values
• Swift MethodExtractor > return type > extracts return type from -> annotation
• Swift MethodExtractor > annotations > extracts @objc attribute
• Swift MethodExtractor > isFinal > detects final func
• Swift MethodExtractor > isFinal > is false when not final
• Swift MethodExtractor > isAsync > detects async func
• Swift MethodExtractor > isOverride > detects override method
• buildTypeEnv > constructor inference (Tier 1 fallback) > lookupClassByName regression coverage > Swift lookupClassByName regression coverage > Swift cross-file constructor inference uses lookupClassByName
• buildTypeEnv > constructor inference (Tier 1 fallback) > lookupClassByName regression coverage > Swift lookupClassByName regression coverage > Swift explicit init inference uses lookupClassByName
• buildTypeEnv > constructor inference (Tier 1 fallback) > lookupClassByName regression coverage > Swift lookupClassByName regression coverage > Swift cross-file constructor inference does not bind plain functions
• buildTypeEnv > known limitations (documented skip tests) > Ruby block parameter: users.each { |user| } — closure param inference, different feature
• Swift constructor-inferred type resolution > detects User and Repo classes, both with save methods
• Swift constructor-inferred type resolution > resolves user.save() to Models/User.swift via constructor-inferred type
• Swift constructor-inferred type resolution > resolves repo.save() to Models/Repo.swift via constructor-inferred type
• Swift constructor-inferred type resolution > emits exactly 2 save() CALLS edges (one per receiver type)
• Swift self resolution > detects User and Repo classes, each with a save function
• Swift self resolution > resolves self.save() inside User.process to User.save, not Repo.save
• Swift parent resolution > detects BaseModel and User classes plus Serializable protocol
• Swift parent resolution > emits EXTENDS edge: User → BaseModel
• Swift parent resolution > emits IMPLEMENTS edge: User → Serializable (protocol conformance)
• Swift cross-file User.init() inference > resolves user.save() via User.init(name:) inference
• Swift cross-file User.init() inference > resolves user.greet() via User.init(name:) inference
• Swift return type inference > detects User class and getUser function
• Swift return type inference > detects save function on User (Swift class methods are Function nodes)
• Swift return type inference > resolves user.save() to User#save via return type of getUser() -> User
• Swift return-type inference via function return type > resolves user.save() to User#save via return type of getUser()
• Swift return-type inference via function return type > user.save() does NOT resolve to Repo#save
• Swift return-type inference via function return type > resolves repo.save() to Repo#save via return type of getRepo()
• Swift implicit imports (cross-file visibility) > detects UserService class in Models.swift
• Swift implicit imports (cross-file visibility) > resolves UserService() constructor call across files (no explicit import)
• Swift implicit imports (cross-file visibility) > resolves service.fetchUser() member call across files
• Swift implicit imports (cross-file visibility) > creates IMPORTS edges between files in the same module
• Swift extension deduplication > detects Product class
• Swift extension deduplication > resolves Product() constructor despite extension creating duplicate class node
• Swift extension deduplication > resolves product.save() to Product.swift (primary definition)
• Swift constructor call fallback (no new keyword) > resolves OCRService() as constructor call across files
• Swift constructor call fallback (no new keyword) > resolves ocr.recognize() member call via constructor-inferred type
• Swift export visibility (internal vs private) > resolves PublicService() constructor across files
• Swift export visibility (internal vs private) > resolves internalHelper() across files (internal = module-scoped)
• Swift if let / guard let binding resolution > detects User and Repo classes
• Swift if let / guard let binding resolution > resolves user.save() inside if-let to User#save
• Swift if let / guard let binding resolution > resolves repo.save() inside guard-let to Repo#save
• Swift if let / guard let binding resolution > user.save() in if-let does NOT resolve to Repo#save
• Swift await / try expression unwrapping > resolves user.save() via await fetchUser() return type
• Swift await / try expression unwrapping > resolves repo.save() via try parseRepo() return type
• Swift await / try expression unwrapping > detects fetchUser and parseRepo as functions
• Swift for-in loop element type inference > detects User and Repo classes
• Swift for-in loop element type inference > creates implicit import edges between files
• Swift field-type resolution > detects classes and their properties
• Swift field-type resolution > emits HAS_PROPERTY edges from class to field
• Swift field-type resolution > resolves field-chain call user.address.save() → Address#save
• Swift field-type resolution > emits ACCESSES edges for field reads in chains
• Swift field-type resolution > populates field metadata (visibility, declaredType) on Property nodes
• Swift call-result binding > resolves call-result-bound method call user.save() → User#save
• Swift call-result binding > getUser() is present as a defined function
• Swift call-result binding > emits processUser -> getUser CALLS edge for let-assigned free function call
• Swift method enrichment > detects Animal protocol and Dog class
• Swift method enrichment > emits IMPLEMENTS edge Dog -> Animal
• Swift method enrichment > emits HAS_METHOD edges for Dog methods
• Swift method enrichment > marks protocol Animal.speak as isAbstract
• Swift method enrichment > marks Dog.speak as NOT isAbstract
• Swift method enrichment > marks breathe as isFinal
• Swift method enrichment > marks classify as isStatic
• Swift method enrichment > captures @objc annotation on breathe
• Swift method enrichment > populates parameterTypes for classify(_ name: String)
• Swift method enrichment > records parameterCount for classify
• Swift method enrichment > records returnType for speak
• Swift method enrichment > resolves dog.speak() CALLS edge
• Swift method enrichment > resolves Dog.classify("dog") CALLS edge
• Swift abstract dispatch > detects Repository protocol and SqlRepository class
• Swift abstract dispatch > emits IMPLEMENTS edge SqlRepository -> Repository
• Swift abstract dispatch > emits HAS_METHOD edges for Repository.find and Repository.save
• Swift abstract dispatch > emits HAS_METHOD edges for SqlRepository.find and SqlRepository.save
• Swift abstract dispatch > marks base Repository.find as isAbstract
• Swift abstract dispatch > marks base Repository.save as isAbstract
• Swift abstract dispatch > marks concrete SqlRepository.find as NOT isAbstract
• Swift abstract dispatch > resolves repo.find(id: 42) CALLS edge
• Swift abstract dispatch > resolves repo.save(entity: user) CALLS edge
• Swift abstract dispatch > populates parameterTypes for Repository.find
• Swift abstract dispatch > populates parameterTypes for Repository.save
• Swift abstract dispatch > records returnType for SqlRepository.find
• Swift abstract dispatch > emits METHOD_IMPLEMENTS edges from SqlRepository methods → Repository protocol methods
• Swift overloaded method disambiguation > detects 2 distinct find Method nodes on SqlRepository
• Swift overloaded method disambiguation > emits METHOD_IMPLEMENTS edges for both find overloads
• Swift overloaded method disambiguation > emits METHOD_IMPLEMENTS edge for save
• Swift overloaded method disambiguation > emits exactly 3 METHOD_IMPLEMENTS edges total
• Swift Child extends Parent — inherited method resolution (SM-9) > detects Parent and Child classes
• Swift Child extends Parent — inherited method resolution (SM-9) > resolves c.parentMethod() to Parent.parentMethod via first-wins MRO walk

Code Coverage

Tests

Metric	Coverage	Covered	Base	Delta	Status
Statements	73.02%	17658/24182	73%	📈 +0.0	🟢 ██████████████░░░░░░
Branches	62.02%	11215/18080	61.97%	📈 +0.1	🟢 ████████████░░░░░░░░
Functions	77.65%	1668/2148	77.65%	＝ 0.0	🟢 ███████████████░░░░░
Lines	75.6%	16024/21195	75.58%	📈 +0.0	🟢 ███████████████░░░░░

---

_{📋 View full run · Generated by CI}