Skip to content

docs: RFC recommending against a write/rename engine (closes #242)#249

Merged
Wolfvin merged 1 commit into
mainfrom
docs/issue-242-refactor-graph-rfc
Jul 12, 2026
Merged

docs: RFC recommending against a write/rename engine (closes #242)#249
Wolfvin merged 1 commit into
mainfrom
docs/issue-242-refactor-graph-rfc

Conversation

@Wolfvin

@Wolfvin Wolfvin commented Jul 12, 2026

Copy link
Copy Markdown
Owner

Closes #242.

Summary

RFC evaluating whether CodeLens should build an actual rename/move execution engine. Conclusion: no — recommend the issue close with this document as the record.

Key points:

No code changes — this is RFC-only per the issue's own scope constraint ("RFC boleh berakhir dengan rekomendasi 'tidak lanjut', itu outcome yang valid").

@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@Wolfvin Wolfvin merged commit bcf736d into main Jul 12, 2026
1 of 7 checks passed
@Wolfvin Wolfvin deleted the docs/issue-242-refactor-graph-rfc branch July 12, 2026 12:58
…e (issue #242)

Analyzed whether CodeLens should build an actual rename/move execution
engine to eliminate drift between the graph used for analysis (trace/
impact) and a hypothetical graph used to execute writes. Conclusion:
don't build it.

Issue #241 (merged) already delivers the real value — a rename
checklist computed from the same graph trace/impact already use, with
an explicit caveat about what static analysis can't see (dynamic
imports, string-keyed dispatch, cross-language string-literal
references like Tauri IPC command names). A full write engine would
mean re-implementing what language servers already do correctly via
LSP rename providers — CodeLens already has partial LSP integration
(--deep, hybrid_engine.py) that's the right foundation IF this is ever
revisited, not a bespoke AST rewriter built from scratch.

The graph-drift concern this RFC was meant to address is lower-stakes
than framed: every refactor tool (including LSP-based ones) faces
"analysis computed at time T can be stale by time T+1 of execution" —
the mitigation is re-verify close to execution (which issue #237's
staleness signal, merged, already provides), not sharing one graph
object across analysis and a write engine that doesn't exist and
shouldn't.
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

rfc: unified graph for read (trace/impact) and write (rename/move) — no CodeLens refactor engine exists today

1 participant