refute-doctor

Model Guidance

Recommended model: mid. Procedural diagnostic with light judgment on which language entries actually matter for this project.

Purpose

Tell the user whether Refute is healthy for the languages this project actually uses, and exactly what to fix when it is not.

Required inputs

• The path to the project root (defaults to the current working directory).

Behavior

1. Run the doctor

From the project root:

refute doctor

If the project uses Refute as a Go-tool dependency rather than a global binary, run instead:

go tool refute doctor

Capture the output. If the command is missing, point the user at install-refute and stop.

2. Detect relevant languages

Inspect the project root for these markers:

• go.mod → Go
• Cargo.toml → Rust
• package.json → TypeScript / JavaScript

Restrict the report to the languages present in the project. Mention but do not block on languages the doctor reports for which the project does not use.

3. Report

For each language present in the project, report:

• backend status (ready / missing / out of date / extension missing)
• which refactoring operations are currently usable
• the exact remediation command, taken from the doctor output, when the backend is not ready

Use this shape:

## Refute Health

- Go (gopls): READY at v0.x.y — rename, reference search usable
- Rust (rust-analyzer): MISSING
  Fix: rustup component add rust-analyzer
- TypeScript: BACKEND OUT OF DATE
  Fix: npm install -g typescript-language-server@latest

4. Summary

Close with a one-line summary: "Refute is ready for the languages this project uses" or "Refute is blocked on N backends — see above".

Out of scope

• Installing backends (covered by install-refute).
• Performing refactorings (covered by refute-rename, deferred).
• Pinning versions (covered by pin-refute, deferred).