Refactor: shared tree-sitter traversal helpers (B / without sview)

[jolestar]

A/B analysis report — issue #2

Task: refactor sview to introduce shared tree-sitter traversal helpers for the Rust and JavaScript/TypeScript analyzers.

Candidates

Side	PR	Skill setup	Runtime tokens	Model rounds	Tool calls	Elapsed	Verification
A	#9	WITH sview skill	69,388 total (50,884 input / 18,504 output)	44	~15 self-counted	~8 min	cargo fmt --check, cargo test passed
B	#8	WITHOUT sview skill	48,780 total (38,331 input / 10,449 output)	24	~15 self-counted	~4 min 8 sec	cargo fmt --check, cargo test passed

Implementation comparison

• A adds a new src/traverse.rs module with a NodeClassifier trait and mutable sibling-observation hook, then wires Rust and JavaScript analyzers through it. This is flexible, but adds a second tree-related module next to the existing src/tree.rs and more abstraction surface.
• B extends the existing src/tree.rs module with parse(), collect_items(), and ast_preview(), then keeps language-specific classification local to src/rust.rs and src/javascript.rs. This is smaller and aligns with the shared tree-building helper introduced by the previous refactor.
• Both keep language-specific naming/classification logic local and both pass the test suite.

sview observations

A reports that sview provided a compact structural map and helped identify duplicated parser/traversal/preview boundaries. However, issue #2 still involves small source files, so the sview overview did not translate into lower runtime cost: A used ~42% more tokens and 20 more model rounds than B, with similar self-counted tool-call volume.

Decision

Recommendation: merge B (#8) and close/supersede A (#9).

Rationale: B achieves the same behavior with fewer files changed, less new abstraction, lower token cost, fewer model rounds, and about half the elapsed time. A is a useful experiment sample showing that sview helped orientation, but this task size still did not produce a measurable efficiency win.