fix(discovery): merge all three VS Code scopes, and let $IRIS_NAMESPACE outrank the editor

[PYDuquesnoy]

0.17.0 moved the VS Code reader ahead of the blind scans — and it still could not read the shape people actually have. GENAI-Course supplied the real workshop file, and it is split across three scopes:

Alumno/Alumno.code-workspace           "settings": { "intersystems.servers": { "workshop-iris": {…} } }
Alumno/Ejercicios/Hospital/.vscode/    "objectscript.conn": { "server": "workshop-iris", "ns": "HOSPITAL" }
  settings.json

Each file alone resolves to NotConfigured. A reader that checks paths one at a time finds nothing however many paths it checks — which is the trap this shape sets, and why the fix merges the scopes and resolves once, narrower winning as VS Code itself resolves a setting:

scope	path
user	dirs::config_dir()/{Code, Code - Insiders, VSCodium}/User/settings.json
workspace	nearest *.code-workspace at or above the cwd — its settings block
folder	./.vscode/settings.json

The walk-up mirrors what workspace_config already does for .iris-agentic-dev.toml.

$IRIS_NAMESPACE now outranks the editor's ns

This is the part that matters most, and it came from GENAI-Course pushing back rather than from me.

Reading the .code-workspace resolves the connection with the editor's namespace — which would have handed the model a working default and silently deleted the IRIS_NAMESPACE=DONOTUSE guardrail. That default points at a read-only namespace on purpose, so a write that forgets to name its namespace fails at once instead of landing somewhere real. They measure 95% of namespace-omitted calls failing loudly today; that is the intended behaviour, not noise.

So operator scope beats editor scope, exactly as $IRIS_PASSWORD supplies what the editor will not. Shipping the scope merge without this would have made their most valuable failure mode disappear.

Evidence

25 unit tests, 12 new — three-scope overlay, workspace-wins-per-key, user entries surviving, a workspace "active": false that user scope cannot undo, the .code-workspace settings nesting parsed off the real workshop file, and the namespace override.

.code-workspace reading, at the wire. From the Hospital folder the binary walks up two levels and reaches http://198.51.100.7:59999/irishealth/… — host, port and pathPrefix that exist only in that file. Remove the file and it falls back to the scans and compiles. A Web Gateway on port 80 behind a path prefix is not something a scan of 52773 could ever have found.

Namespace override, at the wire, on the MCP path — the one that actually uses conn.namespace:

	with .code-workspace	control (removed)
no IRIS_NAMESPACE	APP (editor's ns)	USER
IRIS_NAMESPACE=USER	USER (override wins)	USER

APP appears only when resolution succeeds and no operator override — so both effects are caused, not coincidental.

One test of mine was a false positive, and it is worth recording. My first attempt to prove the override went through the CLI compile and printed /v1/DONOTUSE/, which looked like confirmation. It came from clap's #[arg(env = "IRIS_NAMESPACE")], not from this code — that subcommand never consults the discovered connection at all. Hence the MCP-driven test above.

Scope

Version 0.18.0 — behaviour change, documented at the top of discovery.rs. Gate run as one command: fmt, clippy -D warnings, full workspace → 47 suites green.

Issue 187 stays open for the OS-keychain reader, which is unlikely ever to land: VS Code keeps secrets in an encrypted store, not as per-server items an outside process can read. For this workshop it is moot — their .code-workspace already carries the password.

🤖 Generated with Claude Code