Explore tree-sitter based structured editing

[thegdsks]

From discussion #19 by @yunfan.

Stacklit already parses codebases with tree-sitter and builds dependency graphs. The next logical step is using those same parsed trees for structured code editing, locating a node by its tree-sitter path and replacing it with generated code.

What this could look like:

• Target a specific function/type/export by its tree-sitter path
• Replace or patch that node while preserving surrounding code
• Use stacklit's dependency graph to find cross-file call sites that need updating

Open questions:

• Tree-sitter gives syntax, not semantics. Cross-file renames need the dependency layer too.
• How to handle edits that change the tree structure (adding params, changing return types)
• Could work as a separate companion tool that reads stacklit.json for the graph

No timeline. Scoping for now.

[yunfan]

for these questions, i think

1, a project means one tree-sitter tree, and we could tag/alias the target file in the specific node

2, the edits and its post actions works just like the current code Agent, for eg, you post a question, the behind model react which might cause your further post for tool call response or others, in our case, when a edits happens, this cause a tree structure change, and we got this change in diff like syntax, then cause many post actions , i could image some at once, 1, find all deps this, 2, decide processing order, 3, check all dependant follow the step 2 order, and cause edits if needs, which then cause a sub-loop of this