`provider-doctor` cannot diagnose a configured named profile, and its error message routes users in a circle

Source commit: 008abc44b1653efa65ccf98acb3b7236ce8507e6 (upstream master, chore(release): prepare v0.81.3)
Binary identity: jcode v0.81.5-dev (422da2bc0), SHA-256 ff2639739dc8b71c591cca8e02a3fb79255ef340bd7ce80bbb621ec9f9275ec8
Platform: macOS 26.6.2, Darwin 25.6.0, arm64, Apple M3 Pro

Summary

jcode provider-doctor describes itself as the way to "diagnose why a
provider/model or the model picker is broken by walking the strict end-to-end
checkpoints". It cannot be pointed at a user-configured named provider profile.
Every invocation is rejected before any checkpoint runs.

The error message tells the user to run jcode provider-test-coverage to find
valid ids. That command lists the profile, and then states in its own output
that provider-doctor does not cover it. The suggested remedy confirms the
limitation rather than resolving it, so a user following the tool's guidance
ends where they started.

This is a diagnosability gap, not a routing failure. Inference through the
profile works when invoked with --provider-profile.

Reproduction

# ~/.jcode/config.toml
[providers.mlx-serve]
provider_type = "openai-compatible"
base_url = "http://127.0.0.1:11234/v1"

All three forms fail:

$ jcode provider-doctor mlx-serve
Error: `mlx-serve` is not a known OpenAI-compatible provider. Run `jcode provider-test-coverage` to see provider ids, or check your spelling.
exit=1

$ jcode provider-doctor --provider-profile mlx-serve mlx-serve
Error: `mlx-serve` is not a known OpenAI-compatible provider. ...
exit=1

$ jcode provider-doctor mlx-serve --tier offline
Error: `mlx-serve` is not a known OpenAI-compatible provider. ...
exit=1

--tier offline is documented to "check wiring only" and still rejects the
profile, so even the non-network path is unreachable.

Following the error's own instruction:

$ jcode provider-test-coverage | grep mlx-serve
  mlx-serve                 0/1     1 not ready (best 0/11, stuck before live catalog)
  0/11   mlx-serve / Qwen3.5-4B-MLX-4bit-...   stuck before `live catalog`; re-run the mlx-serve live suite (provider-doctor does not cover it yet); ...

The profile is known to the coverage tool. The parenthetical is the whole
report: provider-doctor does not cover it yet.

Substituting the built-in generic id does not help, because it diagnoses a
different target than the configured profile:

$ jcode provider-doctor openai-compatible
Error: no API key found for `openai-compatible` (looked in env `OPENAI_COMPAT_API_KEY` and `openai-compatible.env`). ...

A local endpoint needs no API key, so the generic slot's auth precondition
fails for a profile that requires no auth at all.

Expected behavior

provider-doctor should accept an id from the [providers.*] config table and
run its checkpoints against that profile's base_url and auth mode, including
the no-auth local case. If full coverage is genuinely not implemented, the
rejection should say so directly and name the supported alternative, rather
than referring the user to a command that reports the same limitation.

The minimum useful fix is to make --tier offline work for configured named
profiles, since wiring-only validation needs no provider-specific support.

Related: local models are foreclosed as a memory sidecar

Reported together because it shares the assumption that a model must map to a
built-in provider. In crates/jcode-base/src/sidecar.rs:165,
Sidecar::with_configured_model resolves agents.memory_model through
provider_for_model and accepts only two results:

match crate::provider::provider_for_model(&model) {
    Some("openai") => (SidecarBackend::OpenAI, model, None),
    Some("claude") => (SidecarBackend::Claude, model, None),
    _ => {
        crate::logging::warn(&format!(
            "Ignoring unsupported memory sidecar model override '{}'; expected an OpenAI or Claude model",
        // ...
    }
}

Any OpenAI-compatible named profile model is warned about and silently replaced
with the default. The memory sidecar is a bounded, high-volume, low-authority
workload, which is the best possible fit for a local model, yet it is
unreachable by construction. This one is a feature request, not a defect.

The constraint is structural rather than a missing branch.
provider_for_model returns Option<&'static str>
(crates/jcode-provider-core/src/models.rs:209), so it can only ever name a
compiled-in provider. A user-configured profile id from [providers.*] is not a
'static string and cannot be represented in that return type at all. Honoring
a named profile here therefore needs a signature change or a separate
resolution path, not just a third match arm.

Duplicate check

Searched 1jehuang/jcode on 2026-08-31 for provider-doctor,
provider-doctor named profile, memory_model local, and
JCODE_NAMED_PROVIDER_PROFILE. No open issue covers either behavior. Issue
#712 (closed) concerns auth-test clearing the profile environment
variable, which is a different command and a different mechanism.

Notes on what was tested

Two claims were checked and withdrawn before this packet was written, and are
recorded so the maintainer knows what was tested rather than assumed:

• jcode model list does list all six configured local models, with or
  without JCODE_NAMED_PROVIDER_PROFILE set. Catalog visibility is not broken.
• The claim that the environment variable successfully reached the local models
  was false. It never reached the local server; that is a separate report.

Related: #1121 (same profile subsystem, different command).

Start at the provider-doctor validation and profile-resolution paths, then inspect crates/jcode-base/src/sidecar.rs:165 and crates/jcode-provider-core/src/models.rs:209 for the related model constraint. Reproduce the named-profile cases, especially --tier offline; done means configured profiles reach the supported checkpoints or receive a direct limitation message instead of circular guidance.