doctor should debug LSP issues

[draxxris]

Description

I can see from pstree that aft does not have a child LSP process, therefore lsp_diagnostics always returns "everything is fine". Would be nice if we could somehow debug LSP process spawning and language checking. Something like

bunx ... lsp_doctor ./python/mywebapp/main.py

and it would use the lsp stanza in aft.jsonc to see if it should even launch an LSP daemon based on the file extension, root_markers; then check the given file for errors.

aft.jsonc - attempt 1

  "lsp": {
    "python": "ty",  // enables ty AND disables Pyright in one go
   }

aft.jsonc - attempt 2

  "lsp": {
    "servers": {
      "python": {
        "extensions": [".py"],
        "binary": "ty",
        "args": ["server"],
        "root_markers": ["python/requirements.txt", "requirements.txt"]
      }
    }

Project layout

> ls -1 python/requirements.txt python/dns_editor/__init__.py
python/dns_editor/__init__.py
python/requirements.txt

Use case

No response

[ualtinok]

Fixed in v0.17.1 (released today).

Run from your project:

bunx --bun @cortexkit/aft doctor lsp ./python/dns_editor/__init__.py

You'll get exactly what was missing: which servers AFT registered for that file, where each binary resolves (project node_modules / lsp_paths_extra / PATH / not found), whether the workspace root marker resolves walking up from the file, the spawn outcome, and (if a server actually spawned) the diagnostics it returned.

For your specific case — lsp.python: "ty" with python/requirements.txt — the most likely cause is ty not being on PATH; the new command will tell you that explicitly with an install hint:

Server attempts:
  ✗ ty
    Binary: ty (NOT FOUND on PATH or in lsp_paths_extra)
    Workspace root: /repo/python (markers: requirements.txt)
    Status: binary not installed
    Action: Install with `uv tool install ty` or `pip install ty`.

Pass --harness opencode (or --harness pi) if both plugins are installed.

The lsp_diagnostics tool description also got tightened in this release so agents now distinguish "nothing was checked" (no server registered) from "checked clean" (server returned zero) and point at this command when the response is unhelpful.

Thanks for the detailed report — the diagnosis you wrote is exactly what motivated the design.