What: when the Pasqal validator can't RUN (missing SDK/interpreter — exit codes outside {0,2,3,4}), the credential route correctly classifies it as the config lane and returns the precise message pasqal_validator_config: the Pasqal validator could not run — check the Python interpreter and the pasqal-cloud SDK — but the panel renders by state bucket (unreachable) and shows "Service unreachable — check the URL or try again". The user debugs the wrong thing (2026-07-20: this cost a live-testing hour and, in alpha.1's variant, misread as "Key rejected").
Post-amicode#189 relevance: provisioning makes the lane rare, not impossible — it is exactly the fresh-install transient (~first 2 min before the venv lands) and every future provisioning failure. The truth already exists server-side; only the rendering discards it.
Fix sketch: in the panel's connection status rendering, prefer the response's error text when present over the state-generic copy; ideally also introduce a distinct misconfigured state so the dot/copy don't imply a network problem. Defense-in-depth from the same incident: consider mapping validator exit 1 distinctly rather than folding all unknown exits into config.
AC: kill the venv + unset AMICO_PYTHON → Connect shows the pasqal_validator_config message, not "Service unreachable"; a genuine network failure (exit 3) still shows unreachable copy.
🤖 Generated with Claude Code
What: when the Pasqal validator can't RUN (missing SDK/interpreter — exit codes outside {0,2,3,4}), the credential route correctly classifies it as the config lane and returns the precise message
pasqal_validator_config: the Pasqal validator could not run — check the Python interpreter and the pasqal-cloud SDK— but the panel renders by state bucket (unreachable) and shows "Service unreachable — check the URL or try again". The user debugs the wrong thing (2026-07-20: this cost a live-testing hour and, in alpha.1's variant, misread as "Key rejected").Post-amicode#189 relevance: provisioning makes the lane rare, not impossible — it is exactly the fresh-install transient (~first 2 min before the venv lands) and every future provisioning failure. The truth already exists server-side; only the rendering discards it.
Fix sketch: in the panel's connection status rendering, prefer the response's
errortext when present over the state-generic copy; ideally also introduce a distinctmisconfiguredstate so the dot/copy don't imply a network problem. Defense-in-depth from the same incident: consider mapping validator exit 1 distinctly rather than folding all unknown exits intoconfig.AC: kill the venv + unset AMICO_PYTHON → Connect shows the pasqal_validator_config message, not "Service unreachable"; a genuine network failure (exit 3) still shows unreachable copy.
🤖 Generated with Claude Code