Feature Request: Incremental Mapping via Git Diff to speed up `clawpatch map`

[Tanmay-008]

Problem Statement

Currently, running clawpatch map performs a full scan of the entire project repository. It executes all heuristic mappers, traverses the filesystem, collects all seeds, and reconciles all features.

In large monorepos or substantial codebases, if a developer modifies only 1 or 2 files, scanning thousands of unchanged files is a massive waste of resources. This creates a severe bottleneck for both local development workflows and CI pipelines.

Expected Impact

• Performance: Massive reduction in mapping execution time (up to 10x faster for iterative changes).
• Efficiency: Significantly speeds up CI checks and tightens the local development loop by restricting map operations strictly to modified scopes.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 2, 2026, 10:50 PM ET / August 3, 2026, 02:50 UTC.

Summary
Current main still performs full deterministic discovery and marks every stored feature absent from the complete result as skipped, so the requested incremental mode is not implemented. The related implementation PR was closed unmerged after live testing showed it neither scoped the 17 mappers nor safely preserved untouched records; this remains a maintainer product-contract decision, not a safe repair dispatch.

Reproducibility: not applicable. as a defect reproduction: the report proposes a new mapping mode, and source inspection confirms that current map intentionally performs full discovery.

Root-cause cluster
Relationship: canonical
Canonical: #171
Summary: This issue remains the canonical product-direction request; the related pull request attempted the same solution but was closed unmerged after concrete performance and reconciliation failures.

Members:

• same_root_cause: feat(mapper): support incremental mapping via --since and --include-d… #172 - It attempted the requested Git-diff incremental mapping behavior, but maintainer live testing found it did not scope discovery and was unsafe for untouched records.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should Clawpatch sponsor a new incremental-mapping mode with mapper-specific scoped discovery and a durable reconciliation contract, or defer this feature for now?	Defer incremental mapping: Keep full mapping as the supported behavior and revisit only when measured monorepo demand justifies a complete design.

Why: The closed implementation established that post-hoc filtering is both insufficient for performance and unsafe for stored feature state; choosing the supported semantics, scope, and benchmark bar is product and maintenance policy rather than a mechanical bug repair.

Next step
A maintainer must choose whether this large new mapping mode merits sponsorship; the closed proposal cannot be safely repaired without deciding the discovery and persistence contract.

Review details

Best possible solution:

Keep full mapping as the default and, only if sponsored, define a measured incremental-mapping contract that lets each mapper avoid irrelevant discovery while preserving untouched feature records across changed, deleted, renamed, and dirty-worktree paths.

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

Not applicable as a defect reproduction: the report proposes a new mapping mode, and source inspection confirms that current map intentionally performs full discovery.

Is this the best way to solve the issue?

No—the closed proposal's post-hoc filtering is not the best solution because it still ran every mapper and could stale untouched records; a sponsored scoped-discovery and reconciliation contract is the safer path.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A post-discovery file filter would not deliver the requested mapping speedup because all mappers still traverse the repository.
• Partial results can corrupt registry state by marking untouched features skipped unless changed, deleted, renamed, and dirty-worktree paths have explicit persistence rules.
• The proposed 10x benefit is unverified without representative monorepo benchmarks and mapper-specific scoped-discovery measurements.

Codex review notes: model internal, reasoning high; reviewed against 3bae0a1ddcbe.

Label changes

Label justifications:

• P3: This is a speculative performance feature with no current regression or verified user-facing failure.

Evidence reviewed

What I checked:

• Current mapper runs the complete suite: mapFeatures always calls collectSeeds; collectSeeds iterates all 17 registered heuristic mappers and emits start/done progress for each. Its only existing filter is applied after seed discovery, not mapper selection. (src/mapper.ts:57, 3bae0a1ddcbe)
• Current reconciliation is full-registry reconciliation: After mapping, mapCommand writes all returned features and changes every existing feature absent from that result to skipped, so a partial seed set is unsafe without an explicit untouched-record contract. (src/app.ts:115, 3bae0a1ddcbe)
• Map has no Git-diff flags today: The CLI map command accepts dry-run, source, provider, model, reasoning-effort, and Git-repository-check flags, while --since and --include-dirty are implemented for review/revalidation selection rather than mapping. (src/cli.ts:133, 3bae0a1ddcbe)
• Maintainer-tested proposal was rejected: The provided maintainer comment at Feature Request: Incremental Mapping via Git Diff to speed up clawpatch map #171 (comment) reports that the linked PR still started all 17 mappers for a six-file run and would mark 31 of 36 baseline features stale; it recommends deferring the feature unless a broader scoped-discovery and reconciliation contract is sponsored.
• Release and current-main check: The latest release tag v0.7.2 is an ancestor of current main, while current HEAD is a later documentation commit; no mapping implementation changed after the issue opened, so the requested capability is neither shipped nor present on current main. (src/mapper.ts:77, 3bae0a1ddcbe)
• Feature-history owner signal: Blame for the mapper registry and mapFeatures currently attributes this surface to the v0.7.2 release commit by Peter Steinberger; the shallow checkout has only the release lineage available for these files, so ownership confidence is moderate rather than definitive. (src/mapper.ts:57, 3c2a1a4e2d04)

Likely related people:

• Peter Steinberger: Current blame and the available file history attribute the mapper registry and mapping entry point to the v0.7.2 release commit; this is the strongest available source-history signal in the shallow checkout. (role: recent mapping-surface contributor; confidence: medium; commits: 3c2a1a4e2d04; files: src/mapper.ts, src/app.ts, src/cli.ts)
• steipete: Posted the concrete live-test decision rejecting the closed incremental-mapping proposal and describing the necessary safety contract. (role: decision author; confidence: high; files: src/mapper.ts, src/app.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]

Maintainer decision brief after live-testing the linked implementation:

• The optimization is directionally useful, but feat(mapper): support incremental mapping via --since and --include-d… #172 does not implement scoped discovery: a six-file incremental run still started all 17 heuristic mappers.
• Its reconciliation is unsafe: after a 36-feature baseline, the incremental dry run returned five filtered features and planned to mark the other 31 stale.

Options are to (1) close/defer this feature, or (2) sponsor a new contract covering mapper-specific scoped discovery plus changed, deleted, renamed, untouched, and dirty-worktree reconciliation.

My recommendation is option 1 for now and CLOSE #172. Revisit only with measured monorepo evidence and a persistence contract that proves untouched records remain untouched; post-hoc filtering is neither the requested speedup nor safe incremental mapping.

[steipete]

Closing per Peter's maintainer decision to defer this feature.

The linked implementation established two important constraints: post-hoc filtering still started all 17 mappers, so it did not deliver scoped discovery, and its partial result would have marked 31 of 36 untouched features stale. A safe implementation needs a designed contract for mapper-specific discovery plus changed, deleted, renamed, untouched, and dirty-worktree reconciliation, backed by representative monorepo benchmarks.

We can revisit when measured demand justifies that broader contract; the current full-map behavior remains intentional.