Doctor.ts's Interceptor check reports 'live' without verifying the CLI/daemon/profile setup actually exists

[waveman2020-sudo]

Doctor.ts's Interceptor capability check is too shallow — reports "live" when Interceptor isn't actually usable

What happens

LIFEOS/TOOLS/Doctor.ts's interceptor capability check only verifies:

1. The Interceptor skill files exist on disk (skills/Interceptor/SKILL.md)
2. A Chrome/Brave/Chromium binary exists somewhere on the system

If both are true, it reports ✅ live — skill present, browser found (brave-browser).

But this tells you nothing about whether Interceptor is actually usable. On a fresh LifeOS install, none of the following exist yet, and Doctor never checks for them:

• The interceptor CLI binary (not on PATH — nothing installed it)
• The interceptor-daemon binary
• ~/Projects/interceptor (the source repo Doctor's own skill docs assume is already cloned)
• The Chrome/Brave extension loaded into any profile
• A pinned test-profile context (INTERCEPTOR_TEST_CONTEXT_ID in preferences.env)
• The native-messaging-host manifest registered with the browser

Running bash ~/.claude/skills/Interceptor/Tools/PreflightIsolation.sh (the skill's own mandatory gate, required before any browser command) on a Doctor-reported "live" install fails immediately:

[PreflightIsolation] FAIL: INTERCEPTOR_TEST_CONTEXT_ID is not set.
exit code: 8

So Doctor's "live" status and the skill's own preflight gate directly disagree — a user (or an agent) trusting Doctor's output has no signal that Interceptor requires a substantial one-time setup (clone the repo, bun install, build, register native messaging, create an isolated browser profile, load the unpacked extension, set a context ID) before it can drive anything.

Why this matters

Doctor's own design doc calls it "diagnostic register only" and something that should catch "capabilities that are assumed but never worked, degrade silently." This is exactly that failure mode, just inverted — it's not that Interceptor silently broke, it's that Doctor reports a capability as ready when it was never set up in the first place, on every fresh install, every time, for every user, until someone tries to actually use it and discovers the real prerequisite chain by hand (as happened here).

Suggested fix

Doctor's Interceptor check should attempt the real preflight (PreflightIsolation.sh, or equivalent minimal checks: interceptor --version succeeds, interceptor status reports daemon running, a pinned context is configured) rather than just checking for skill files + any browser binary. A capability should not report live unless it's actually been exercised end-to-end at least once, or unless the specific missing prerequisite is at minimum named in the broken detail (e.g. "skill present, browser found, but interceptor CLI not installed — see Workflows/Update.md").

Evidence this was tested end-to-end, not theoretical

After doing the full one-time setup (cloned Hacker-Valley-Media/Interceptor, built CLI+daemon+extension via bun install + scripts/build.sh, ran scripts/install.sh --browser-only --brave --profile "Profile 1", manually loaded the unpacked extension into an isolated Brave profile, set context ID interceptor-test in the extension popup), the preflight gate passes and a real authenticated page load succeeds:

$ bash ~/.claude/skills/Interceptor/Tools/PreflightIsolation.sh
[PreflightIsolation] OK — interceptor 0.22.6, pinned context "interceptor-test" connected and not denied.

$ interceptor status
mode: browser-only
daemon: running

Followed by a real interceptor open <authenticated-url> --context interceptor-test that returned live page content from a logged-in session. So this isn't a report of Interceptor being broken — it's a report of Doctor's health check not reflecting reality.