check_config cannot tell an env-pinned connection from a blind scan — both report auto_discovered and both get the fallback warning

[PYDuquesnoy]

check_config reports connection_source: auto_discovered and emits the fallback warning for a connection that was pinned explicitly by IRIS_HOST/IRIS_WEB_PORT. An env-pinned connection and a blind port scan are indistinguishable in its output.

Measured

Same binary (0.18.0), same instance, two environments:

	connection_source	fallback_warning
IRIS_HOST=localhost IRIS_WEB_PORT=43080 …	auto_discovered	PRESENT
no IRIS_* at all	auto_discovered	PRESENT

Byte-identical on both fields. (The namespace differs only because the localhost scan reads IRIS_NAMESPACE for its own probe credentials — not a source distinction.)

Cause

crates/iris-agentic-dev-core/src/tools/mod.rs:4106-4110, at startup:

let (source, file) = if config_path.is_some() {
    (ConnectionSource::ConfigFile, config_path)
} else {
    (ConnectionSource::AutoDiscovered, None)   // env vars land here
};

The decision reads only whether a .iris-agentic-dev.toml was found. ConnectionSource::EnvVars is assigned in exactly one place — ConnectionState::new_disconnected(ConnectionSource::EnvVars) at :4114 — so no live connection can ever report it.

The information is not missing, it is discarded: discovery.rs step 2 sets DiscoverySource::EnvVar on the IrisConnection correctly. The mapping to ConnectionSource never asks.

Why this is worse than a wrong label

check_config's explicit-source test is:

let is_explicit = matches!(conn.source, ConnectionSource::ConfigFile | ConnectionSource::EnvVars);

so the fallback warning fires on an explicitly pinned connection and instructs the operator to pin what is already pinned:

No .iris-agentic-dev.toml config file found. Connection established via fallback discovery (Docker/port scan). Set OBJECTSCRIPT_WORKSPACE or create a .iris-agentic-dev.toml in your project root to pin the target instance.

That warning exists (#21) to flag the one genuinely dangerous case — fallback discovery can silently target the wrong instance. Firing it on every env-registered setup buries the case it was built for. Every workshop VM and every ~/.claude.json registration with an env block is in this state today.

0.18.0 widens it. A connection resolved from VS Code settings is explicit configuration too, and currently gets the same treatment.

This is the report-vs-mechanism split that #169 fixed for the write gate by routing reporting and enforcement through one function. Same shape, different pair.

Fix

Derive ConnectionSource from the connection's own DiscoverySource rather than from config_path alone, and let is_explicit follow it:

• DiscoverySource::EnvVar → EnvVars
• DiscoverySource::VsCodeSettings → a VsCodeSettings variant, explicit
• DiscoverySource::ExplicitFlag → explicit
• LocalhostScan / Docker → AutoDiscovered, which is the only case the warning should fire on

A config file still wins, since it is the narrowest statement of intent.

[PYDuquesnoy]

Landed in fcff2d4 (PR #193), released in 0.19.0 once cut.

Verified with the same probe that produced the table in the report — same binary, same instance, only the environment differing:

	before	after
IRIS_HOST=localhost IRIS_WEB_PORT=43080 …	auto_discovered + warning	explicit_flag, no warning
no IRIS_* at all	auto_discovered + warning	auto_discovered + warning

The two states are now distinguishable, and the #21 fallback warning fires only on the blind scan it was built for.

What changed. ConnectionSource::for_connection derives the label from the connection's own DiscoverySource rather than from config_path.is_some(); a config file still wins as the narrowest statement of intent. is_explicit() replaces the hand-written variant list at the check_config call site, so the reported value and the warning predicate cannot drift apart again. The tool description now names the real value set and states the rule that carries the meaning: only auto_discovered is a guess.

Two notes for whoever reads this next.

The label for an env-configured MCP server is explicit_flag, not env_vars. mcp.rs:86 builds the connection from self.host, which clap fills from --host or $IRIS_HOST — one value by the time the connection is stamped, so discovery's env-var step is effectively dead on the MCP path. ExplicitFlag documents that it covers both. Separating a real flag from the env var would need clap's value_source() plumbed through the bin crate; that is not done here and is not required to close this.

ConnectionSource::EnvVars remains reachable only through the seedless cascade, which is what env_var_discovery_maps_to_env_vars covers. That test proves the mapping, not that the server emits it — it was originally named as though it proved the latter.

Closing deliberately rather than by commit keyword, so the closure is a decision and not a parser side effect.