home: healthy installed environment shows "No secure environment on this machine yet" when the active-client pointer is missing (doctor disagrees)

[LukasWodka]

Symptom

Field test (Windows, 2026-07-24): freshly installed, connected environment — doctor says

✔ Connected to tracebloc
✔ Ready to run training

— yet the bare tracebloc home screen says, on the same machine, seconds apart:

⚠ No secure environment on this machine yet — run the installer to set one up.

Root cause — detection-source divergence

Home's verdict hangs entirely on the ActiveClientNamespace pointer in ~/.tracebloc/config.json:

• internal/cli/home.go:463 — provisioned = p.ActiveClientNamespace != "".
• internal/cli/home.go:491-493 — the env probe short-circuits to localNoRelease before any kubeconfig/cluster I/O when the binding isn't applied; internal/cli/clustertarget.go:174-178 leaves it unapplied when the pointer is empty.
• home.go:322-327 then classifies → homeNoEnv → the warning at home.go:735-736.

The pointer has exactly one writer: tracebloc client create (internal/cli/client.go:397 → setActiveClient, client.go:763-767). The Windows installer never runs client create (it still uses the legacy manual Client-ID flow — see the companion installer ticket), so on Windows the pointer is never written and home reports "no environment" forever.

doctor doesn't depend on the pointer: internal/cli/doctor.go:167-186 calls bindActiveClientNamespace but ignores .applied, loads the kubeconfig, and discovers the release in the resolved namespace — hence the contradiction.

Fix

Give home a doctor-style fallback: when signed in but the pointer is empty, still run the bounded kubeconfig probe; if a tracebloc release is discovered in the resolved (non-shared) namespace, render the real state (homeOffline/live) instead of homeNoEnv. Respect the deliberate ownership gate for shared clusters (home.go:479-492 comment) — the fallback should only adopt an unambiguous local single-client release, and can offer "run tracebloc client use" otherwise.

Also (small, Windows): tb alias detection never matches

tbAliasAvailable (home.go:652-663) + aliasStatus (delete.go:465-493) only accept a symlink literally named tb, but install.ps1:192-198 installs the alias as tb.cmd, a regular file (symlinks need admin on Windows). So every remedy/example on Windows echoes tracebloc instead of tb. Accept the tb.cmd shim on Windows.

Acceptance

• A healthy installed environment with an empty active-client pointer renders home's real state, not "No secure environment".
• Shared-cluster/ambiguous cases still refuse to adopt silently (ownership gate preserved).
• On Windows with tb.cmd installed, home/doctor examples use tb.
• Unit tests: pointer-empty + discoverable release ⇒ not homeNoEnv; pointer-empty + no release ⇒ homeNoEnv unchanged.

[LukasWodka]

Closing as completed — the implementing PR merged; only the issue never closed.

Why it stayed open: this repo's default branch was main while the PR merged to develop, and GitHub fires closing keywords only on merges into the default branch. So Closes #N never triggered here, no matter how it was written.

Fixed at the source today (2026-07-25): this repo's default branch is now develop, so closing keywords will work from here on. The PR template was also corrected — it previously suggested Ref tracebloc/other-repo#456 for cross-repo links, and Ref is not a closing keyword.

Closed as part of a board hygiene pass. If any part of this issue is not actually covered by the merged PR, please reopen — it was closed on the strength of a merged reference, not a line-by-line audit.