[Bug/Perf] Node-centric coupling in collectSeeds causes unnecessary I/O overhead on non-Node projects

[Tanmay-008]

Currently, the collectSeeds orchestrator unconditionally executes discoverNodeProjects(root) and turboTaskGraph(root) before invoking any feature mappers.

This design assumes a Node.js-centric environment and passes the eager results to all 17 language mappers (Go, Python, Rust, C++, etc.) via the MapperContext. While Node-ecosystem mappers require this context, non-Node mappers completely ignore it. This means that for pure Go or Python repositories, the CLI pays a heavy, unnecessary I/O penalty (recursively scanning for package.json, project.json, lockfiles, etc.) blocking the non-Node mappers from starting their execution.

Expected Behavior

Non-Node mappers should not wait for Node.js workspace discovery. The MapperContext should be evaluated lazily so that Node workspace discovery only runs when a mapper actually requests it, avoiding redundant disk I/O in polyglot or non-JS/TS repositories.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 12, 2026, 2:45 AM ET / 06:45 UTC.

Summary
Current main still places a real Node-specific discovery barrier ahead of all mapper execution, so the performance concern remains actionable. The suggested lazy context shape needs refinement because Node-family mappers always run and would still trigger the same scans; the repair should improve scheduling and prove any I/O skip preserves nested and polyglot Node discovery.

Reproducibility: yes. at source level: collectSeeds serially awaits Node project and Turbo discovery before starting all seventeen mappers, while only four consume that context. Runtime measurement would quantify the delay but is not necessary to establish the blocking dependency.

Next step
The current-main dependency is concrete and the repair is bounded, but implementation must preserve nested Node discovery rather than applying an unsafe root-only shortcut.

Review details

Best possible solution:

Start root-only mappers without awaiting Node context, then use one memoized Node-context computation for Node-family mappers and reduce discovery work only through a signal that demonstrably preserves nested and polyglot Node project mapping.

Do we have a high-confidence way to reproduce the issue?

Yes at source level: collectSeeds serially awaits Node project and Turbo discovery before starting all seventeen mappers, while only four consume that context. Runtime measurement would quantify the delay but is not necessary to establish the blocking dependency.

Is this the best way to solve the issue?

No, not fully as proposed: laziness alone may still perform the same I/O because Node-family mappers always execute. The narrow maintainable fix should combine non-blocking mapper scheduling with safe, tested avoidance or reuse of irrelevant Node discovery.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The issue has no benchmark quantifying how much total mapping time is attributable to Node discovery on representative non-Node repositories.
• A root-only Node signal could incorrectly skip nested JavaScript or TypeScript projects in polyglot repositories, so any I/O gating needs explicit regression coverage.

Codex review notes: model internal, reasoning high; reviewed against 61ddfe0df86f.

Label changes

Label changes:

• add P2: The issue identifies a current, bounded CLI mapping performance problem without correctness loss, data loss, or an unusable core workflow.
• add impact:other: Node-specific recursive discovery currently delays thirteen unrelated language and configuration mappers.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: The issue identifies a current, bounded CLI mapping performance problem without correctness loss, data loss, or an unusable core workflow.
• impact:other: Node-specific recursive discovery currently delays thirteen unrelated language and configuration mappers.

Evidence reviewed

Acceptance criteria:

• pnpm test src/mapper.test.ts
• pnpm typecheck
• pnpm lint
• pnpm test
• pnpm build

What I checked:

• Eager mapper barrier: collectSeeds fully awaits discoverNodeProjects and turboTaskGraph before starting the Promise.all that invokes any feature mapper. (src/mapper.ts:288, 61ddfe0df86f)
• Mostly non-Node consumer set: The registry contains seventeen mappers, but only Node, Next, React, and Node routes consume MapperContext; the other thirteen mapper functions accept only the repository root. (src/mapper.ts:50, 61ddfe0df86f)
• Discovery performs recursive I/O: Node project discovery recursively traverses candidate directories and searches for package and Nx project metadata, confirming that the barrier is more than a few root-level checks. (src/mappers/projects.ts:630, 61ddfe0df86f)
• Orchestration provenance: Blame ties the eager collectSeeds structure to the 0.7.0 release commit, with later reconciliation work retaining the same ordering. (src/mapper.ts:288, 0cd24d07a262)
• Node discovery provenance: Pickaxe history associates Node monorepo project discovery with commit 869cdacc5bac168897b04406cdbe55f7b2f13142 and Turbo task graph support with 9bbce4e20d9c76142d58385ed6a7372c363e000c. (src/mappers/projects.ts, 869cdacc5bac)
• No canonical replacement found: Repository issue, pull-request, source, and history searches found no duplicate report, open fix PR, or current-main implementation for demand-driven Node mapper context.

Likely related people:

• steipete: Current-line blame and the recent mapper reconciliation, Node tooling, and nearby-test performance history center on this contributor. (role: mapper orchestration and recent performance contributor; confidence: high; commits: 0cd24d07a262, 57aa23b6c5b8, d0d01211935a; files: src/mapper.ts, src/mappers/projects.ts, src/mappers/turbo.ts)
• camwest: Git pickaxe and GitHub commit metadata associate the original monorepo Node project mapping behavior with this contributor. (role: Node monorepo mapping introducer; confidence: medium; commits: 869cdacc5bac; files: src/mappers/projects.ts)
• cz-locomind: Git pickaxe and GitHub commit metadata associate Turbo task graph support with this contributor. (role: Turbo task graph introducer; confidence: medium; commits: 9bbce4e20d9c; files: src/mappers/turbo.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

Resolved by #156 and landed on main through 69014be87b0957c435deeb45ed606b9383350c25.

The landed implementation gates all four Node-family mappers behind detected or bounded fallback signals, starts non-Node mappers without waiting, and shares one lazy Node project/Turbo context per mapping run. It preserves package-less conventional, nested React, and package-less Nx discovery.

Canonical proof:

• Exact PR-head runtime, instrumentation, timing, audit, and review evidence: perf(mapper): lazily evaluate Node.js project discovery in MapperContext #156 (comment)
• Post-merge main CI/package smoke: https://github.com/openclaw/clawpatch/actions/runs/29195403835
• Post-merge verified-secret scan: https://github.com/openclaw/clawpatch/actions/runs/29195403862
• Post-merge CodeQL: https://github.com/openclaw/clawpatch/actions/runs/29195403837

Tanmay's original authored commit is retained on main as ec1b12a092edc3aa6bddb49733e03d6ad5bf924d; release-note context and @Tanmay-008 credit remain in the merged PR body for the release process.