Experiment A: refactor shared analyzer tree building

[jolestar]

Summary

This is experiment A for #1: refactor the repeated analyzer tree-building logic while keeping the shared helper inside src/analyzer.rs.

The current project structure is small and layered:

• src/main.rs: CLI entry point and argument handling
• src/analyzer.rs: language dispatch and shared analyzer model helpers
• src/rust.rs, src/javascript.rs, src/markdown.rs: language-specific tree-sitter extraction
• src/model.rs, src/render.rs, src/util.rs: shared data model, rendering, and utility code
• tests/fixtures/*: language fixture coverage used by the existing test suite

A/B analysis report

Goal: evaluate two implementations of issue #1 and compare the usefulness of the sview skill for navigating the refactor.

Experiment A: sview skill enabled

Implementation in this PR:

• adds a shared build_analyzer_tree helper in src/analyzer.rs
• removes duplicated parent/child tree assembly code from Rust, JavaScript/TSX, and Markdown analyzers
• keeps language analyzers focused on producing flat (parent, node) entries

Observed navigation characteristics:

• one sview outline pass plus targeted reads was enough to identify the repeated shape across analyzer modules
• the skill made the repeated function boundaries and module responsibilities easy to compare without reading every file fully
• total observed tool-call count was still similar to the no-skill run, so the immediate value was clearer navigation rather than fewer calls

Experiment B: no sview skill

Comparison branch/PR uses a separate src/tree.rs module for the shared helper.

Observed navigation characteristics:

• normal rg/sed exploration was also sufficient for this small repository
• the resulting module boundary is cleaner because tree construction becomes its own module
• navigation evidence was less direct, but the final code shape may be preferable

Recommendation

Both implementations solve #1 and pass tests. I slightly prefer the B shape (src/tree.rs) for long-term module boundaries, but this A PR is useful evidence that sview helps an agent quickly understand the repository outline and repeated code structure.

Verification

• cargo fmt --check
• cargo test --quiet

[jolestar]

Closing in favor of #7. In the A/B comparison, Experiment B had the cleaner module boundary and lower token/round cost while passing verification.