Minor: output-quality issues that hurt LLM/tooling consumption #154

Version: 4.4.2 (Homebrew) · macOS

Small things, grouped rather than filed separately. Each affects using codemap's output as machine input.

1. ANSI escapes are emitted even when not a TTY

Roughly 31% of the bytes of tree output are colour escape codes, present even when piped to a file. For a 59KB tree that's ~18KB of pure escape sequences — real money when the destination is an LLM prompt.

Suggested: honour NO_COLOR, and default to plain when stdout is not a TTY.

2. File extensions are stripped inconsistently in tree output

Multi-file directories render entries without extensions, single-file directories keep them:

├── Features/Detail/
│   └── ✎ DetailView (+4 -4)            <- no extension
│       ✎ DetailViewModel (+10 -9)
└── Integrations/
    └── ✎ SomeManager.swift (+18 -16)  <- extension kept

The result is that paths can't be reliably copied out of the tree, which matters when the consumer is expected to go read those files.

Suggested: always include the extension, or add a flag for machine-oriented output.

3. File counts disagree across modes on the same repo

Same repo, same commit:

Some of this is legitimately different scoping (source files vs all files), but nothing in the output says so, so it reads as inconsistency.

Suggested: label what each count covers, or reconcile them.

4. blast-radius runs importer analysis on non-code files

[importers] docs/some-note.md

Markdown has no importers; this is wasted budget in an output that is explicitly character-capped.

5. Shell source lines are parsed as imports

A shell script containing source "$SOME_VAR" produced a literal "$SOME_VAR" entry in a Swift project's import list. Shell scripts probably shouldn't feed the import graph at all.

6. --diff counts untracked files

--diff reported 52 changed files where git diff --name-only reported 50; the extra two were untracked scratch files. Defensible for a "what's different in my tree" view, but wrong for anything reasoning about a branch/PR — and it means a reviewer's own temporary files get attributed to the change under review.

Suggested: exclude untracked by default under --ref, or add --include-untracked.