RFC-0001 · P1 · cli — §7.3 "selected is not connected": bind data commands to the active client + show connected state in `client list`

[saadqbal]

Context

client use <id> is a backend-account lookup + local pointer write (client.go runClientUse) — it never touches the cluster, by design. So it succeeds even when the client's cluster is gone (e.g. k3d cluster delete after an i.sh setup): the backend EdgeDevice record still lists, so use happily sets the pointer.

That's the correct behaviour for use (you may select a client to operate on from another machine, or before the cluster is up). The gap is that RFC-0001 §7.3 "'Selected' is not 'connected'" is only half-built:

• Data commands preflight the cluster but don't bind to the active client. data ingest/list/delete already do cluster.Load→exit 3 / DiscoverParentRelease→exit 4 (data.go:594-620), so a dead cluster errors cleanly. But namespace defaults to the --namespace/context default, not the active client's namespace, and nothing verifies the reached cluster actually hosts the active client. The real hazard is the remote / multi-cluster case: kubeconfig points at a different live cluster than where the active client runs → silent wrong-target, exactly what §7.3 warns about.
• client list shows no connection state. runClientList prints clients + an (active) marker only. §7.3 wants selected (local pointer) vs connected (🟢 = cluster reachable + recent heartbeat) — that's where a user sees "this client's cluster is gone." ActiveClientID is currently consumed only in auth.go / client.go / doctor.go / config.go — never in the data commands.

cluster doctor (#88, shipped) already gives the health verdict; this ticket wires the active-client ↔ cluster relationship into the everyday commands.

Tasks

• Bind data commands to the active client (§7.3). Default -n to the active client's namespace; resolve a reachable kube-context hosting <ns>-jobs-manager (reuse DiscoverParentRelease). --context/-n still override.
• Fail clearly when the active client runs elsewhere. If no reachable context hosts the active client: "client X runs on another machine — run data commands there, or tracebloc client use a local one." No silent wrong-target.
• client list connected column. Distinguish selected vs connected (🟢 = reachable + recent heartbeat). Needs the backend heartbeat surfaced (RFC-0001 C.4 — coordinate with backend if the heartbeat/last_seen field isn't on the list payload yet).
• (Optional) soft warning on client use. Non-fatal, bounded-timeout probe: ⚠ selected client X, but its cluster isn't reachable from here — run 'tracebloc cluster doctor'. Must NOT hard-fail use (keeps remote/offline selection working).

Related

• RFC-0001 §7.3 (docs/rfcs/0001-cli-auth-and-client-provisioning.md)
• RFC-0001 · P1 · cli — client create / list / use + location auto-detect + name→slug #84 (client create/list/use basics), WS3 · tracebloc cluster doctor — live-cluster health check with remedies #88 (cluster doctor), CLI quick wins: cluster-connect + kubeconfig-flag helpers, rename sweep, pinned lint + deadcode gate #127 (resolveClusterTarget refactor — the natural place the binding helper lands)
• Not covered here: the k3d destroy+recreate orphan (rebuilt cluster → new kube-system UID → re-provision mints a duplicate + orphans the old client with a dead heartbeat). That's R12 offboarding / client delete --uninstall, still un-ticketed — separate issue.

Part of tracebloc/backend#830.

[LukasWodka]

Superseded, in two halves: (1) the data-command active-client binding + the §7.3 "runs on another machine" failure copy shipped in cli#142 (bindActiveClientNamespace + cluster-wide fallback scan, live on develop); (2) the selected-vs-connected picker/list work is explicitly superseded by the Rev 8 amendment (#139: use removed, list hidden — one machine = one client). If Rev 8 lands, surface connection state on the dashboard instead. Board hygiene audit 2026-07-07 with Lukas.