fix: include codeflash.toml in config resolution depth comparison

[mashraf-222]

Problems fixed

When a package.json exists in a parent directory (e.g., monorepo root or dev dependency), parse_config_file() would always prefer it over a closer codeflash.toml in the current project directory. This caused Java projects to resolve the wrong module_root and project_root, leading to:

• Generated tests written to the wrong directory
• Maven invoked from the wrong cwd (no pom.xml → build failure)
• Maven Central runtime JAR resolution failing (because dependency:resolve also needs a valid pom.xml in the working directory)

Root cause

The depth comparison in parse_config_file() only checked package.json against pyproject.toml. Java projects use codeflash.toml, which was never included in the comparison. When pyproject_toml_path was None (no pyproject.toml exists), the code unconditionally set use_package_json = True — regardless of whether a closer codeflash.toml existed.

Solution

Find the closest toml config file (either pyproject.toml or codeflash.toml) and use that in the depth comparison against package.json. A closer codeflash.toml now correctly takes priority over a farther package.json.

Code changes

• codeflash/code_utils/config_parser.py: Added codeflash.toml lookup via find_closest_config_file(), pick the closer of pyproject.toml / codeflash.toml, and compare that against package.json depth.

Testing

• All 145 setup tests pass (tests/test_setup/ — 22 config + 65 detector + 29 e2e + 29 first_run)
• Verified manually:
  • Java project with codeflash.toml + parent package.json → now correctly resolves codeflash.toml
  • JS project with package.json → still resolves package.json (unchanged)
  • Python project with pyproject.toml → still resolves pyproject.toml (unchanged)
• Full E2E Fibonacci optimization passed with fix applied

Impact

• Java projects nested inside repos with package.json (e.g., dev testing) now work correctly
• No behavior change for JavaScript or Python projects

[claude]

Claude finished @mashraf-222's task in 2m 15s —— View job

---

PR Review Summary

Tasks

• Triage: assess PR scope (production code change, not trivial)
• Lint and type check changed files
• Resolve stale review threads (none found)
• Code review
• Duplicate detection
• Test coverage analysis

---

Prek Checks

✅ ruff check and ruff format both pass cleanly. No auto-fixes needed.

Mypy: 6 pre-existing errors in config_parser.py (lines 151, 176, 183, 191, 204, 205) — none are introduced by this PR's changes (lines 99–120). Not fixing pre-existing issues.

---

Code Review

The fix is logically correct and well-scoped. The root cause and solution match.

One potential concern — max() tie-breaking when both toml files share the same depth (config_parser.py:105):

closest_toml_path = max(pyproject_toml_path, codeflash_toml_path, key=lambda p: len(p.parent.parts))

If pyproject.toml and codeflash.toml are in the same directory (equal depth), max() returns whichever has the lexicographically greater path, which could be non-deterministic across OSes. In practice this scenario is unlikely (both config files in the same dir would be an unusual setup), but it's worth noting. A tie-break in favor of pyproject.toml (for Python backward compatibility) could be made explicit: Fix this →

Observation — >= comparison means same-depth package.json wins (config_parser.py:120):

use_package_json = package_json_depth >= toml_depth

If package.json and codeflash.toml are in the same directory, package.json is preferred. This matches the original behavior, so no regression. Just confirming it's intentional.

---

Duplicate Detection

No duplicates detected. find_closest_config_file is only defined and used in config_parser.py.

---

Test Coverage

• config_parser.py overall: 57% coverage (142 stmts, 61 missed)
• All 145 test_setup/ tests pass ✅
• Gap: The new codeflash_toml_path lookup + closest_toml_path computation (lines 99–107) has no dedicated unit test covering the scenario described in the PR (Java project with codeflash.toml in CWD and package.json in a parent dir). The fix is manually verified per the PR description, but a regression test would prevent future regressions: Add test →

---