Add an LLM focussed reporter, and use it when appropriate

[hadley]

This is a little messy because I needed to refactor default_reporter().

I skipped deprecation on default_progress_reporter() because I can't imagine why any one would call it, and indeed, there's no usage on CRAN

[claude]

Claude finished @hadley's task —— View job

---

Code Review Analysis

• Review new LlmReporter implementation
• Analyze default_reporter() refactoring
• Check test coverage and implementation
• Look for potential bugs or issues
• Provide final feedback

Review Feedback

Minor Issues Found:

1. Inconsistent variable increments in LlmReporter:33 - self$ctxt_n is incremented for all results, but should only increment for actual test results, not context changes. This may cause incorrect context counting.

2. Missing error handling in is_llm():164 - nzchar(Sys.getenv("CLAUDECODE")) should handle cases where CLAUDECODE might contain unexpected values. Consider validating the environment variable value.

3. Potential duplication in add_result() - The logic in LlmReporter$add_result() duplicates some parent class functionality. The self$ctxt_n <- self$ctxt_n + 1L line should be reviewed against the parent class implementation to avoid double-counting.

Code Quality:

• Test coverage is good with appropriate snapshot tests
• Documentation is clear and follows roxygen2 conventions
• The refactoring of default_reporter() properly centralizes reporter selection logic
• Environment variable detection (is_llm()) is simple and appropriate

No Critical Bugs Found - The implementation appears functionally correct for its intended purpose.

[DavisVaughan]

From some interactive testing it seems like it will be appropriate. I haven't fully tried it yet in a claude session.

[DavisVaughan]

Hmm, I actually think this is harder to mentally parse now

I like the original way where you get told about the 90% case first, ProgressReporter, then you get told about increasingly more niche things after that

I also like the bulleted list from before

[hadley]

The reason I rewrote it was that previously it wasn't clear that these are default for three different functions/situations: testing a directory, testing a single file, and testing a package. I'll see if I can get something in the middle.

[DavisVaughan]

Do we want to say something like "If you are running tests via an llm (which currently means that the CLAUDECODE env var is set)..."

I'm just imagining that is_llm() will get more complex as we go forward, and eventually we could forward the docs as "[running tests via an llm][LlmReporter]", or something like that

---

Ohhhh, actually we should probably do that now!

So something like

If you are [running tests via an llm][LlmReporter]

Where LlmReporter's docs is the place where you describe when this is activated, i.e. when CLAUDECODE=1 right now, but that will probably expand in the future. That feels like the right place for these docs?