* docs(mbo): fleet-connect — a local-RPC provider plugin framework + the herdr provider (#266) What: the design, spec (21 features with per-feature evaluation criteria), plan (25 TDD tasks, file inventory, DAG) and execution trio for giving `fleet` a drill-down view of what lives on a host, and a plugin boundary underneath it. Why: fleet knows one thing about a host — dotfiles install drift — and its only "connect" is a bare ssh shell. Everything an operator wants to reach (a herdr session with agents in it, a Kubernetes pod's logs, a container's shell, an htop/nvtop view) sits below the host row. A read-only probe of the fleet found two Kubernetes flavours, docker everywhere, three live agent tmux sessions and a herdr server, so the heterogeneity argues for a plugin boundary rather than a growing switch inside fleet. Shape: providers are processes addressed over a versioned, MCP-shaped JSON-RPC protocol on a local transport (URL-addressed, so the same methods later serve a remote endpoint). A plugin's only route to a machine is a `host/exec` callback into fleet's existing runner seam — it carries a `callId`, never an alias, so a plugin cannot name a machine it was not asked about. Streams and interactive handoffs are declared as data and executed by fleet, never spawned by the plugin. Onboarding a tool is a `~/.config/fleet/providers.yaml` stanza with no rebuild; herdr ships in-process for speed and is simultaneously servable over the wire so protocol v1 is proven by a real consumer. Impact: docs only — no code, no install change, no host-side writes. Kubernetes is registered as the next objective (`fleet-connect-k8s`) and is purely additive under protocol v1. Testing: not applicable (documentation). The plan's verification section maps all 48 evaluation criteria to named tests, sets a >=90% bar for the three new packages, and lists six live gates including a dual-path equality proof that the in-process and over-the-wire herdr trees render identically. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mkwgmh4NZNnmJh9EUpiGjN * docs(mbo): record the fleet-connect design PR number in the index Replaces the "(this PR)" placeholder with #267 so the objective's row names its design PR after the branch lands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mkwgmh4NZNnmJh9EUpiGjN * docs(mbo): correct the fleet-connect worker registry in TRACKING The ledger claimed the design artifacts lived on `worktree/fleet-more-than-ssh`. They are committed on the gss feature worker `fleet-connect/edward-raigosa/design` (PR #267). A resumption ledger naming the wrong worktree sends the next session to the wrong place, so record the refs captured from `gss feature worker add --json` and note the anchors in the session log. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mkwgmh4NZNnmJh9EUpiGjN * docs(mbo): fleet-connect — port bridges as a third action kind (Tunnel), the ports provider, one ssh -N per host The operator asked for N-port ssh bridges per target host: expose a dsh or web-app port that only listens on the remote as a local URL, start/stop/see bridges on several hosts at once, and never let a bridge outlive fleet. Design §3.4 records the four mechanisms weighed and the choice (A): one `ssh -N` per host carrying every `-L`, owned by `internal/bridge`, restarted on change, torn down on `q`/Ctrl-C/`Close()`; `-O forward` on the mux rejected for its ControlPersist lifetime, a detached forwarder rejected by the operator. Contract: `Action` is exactly one of Handoff | Stream | Tunnel; `Tunnel` is two ports and a scheme with no address field (a forward only targets the dispatched host's loopback); `Handoff` loses its `Host` field — fleet stamps the level's alias on every action kind, closing the handoff-path enumeration escape the review found. Spec: UC6, F1d, F2d, F21c, F22–F26 with criteria. Plan: leaf H (T25–T28: bridge manager, ports provider, TUI `t`/`T` + `⇄` markers + quit teardown, `fleet bridge`), T29 integration, T3 rewritten around BridgeArgv/RunBridgeCtx since RunStreamCtx already exists (#270); 29 tasks, 26 features. Trio and index updated. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBxUpSShKENH7evm8ssdyJ * docs(mbo): fleet-connect — fold in the /code-review findings on #267 - Host.Exec takes a ctx and stdin and returns ExecResult{stdout, stderr, exitCode} on both paths, over a new runner.RunCtx: the batch lane had no context (a hung built-in could hang loadLevel) and the wire/in-process shapes differed, which would have broken the dual-path keystone test on the absent case. - The plugin deadline measures plugin time only: it pauses while a host/exec is outstanding, and a breach fails the call (re-dial on the next call), so a slow host no longer kills the shared plugin process for the session. - Action.Key is a one-rune string; the fleet ls --json golden is regenerated from the frozen structs (unavailable, handoff/stream/tunnel) and Attrs["binary"] is an absolute path, so §3.4 no longer contradicts §3.1. - runner.Quote is updexec.ShQuote moved (updexec imports runner, so an alias the other way is an import cycle); updexec and cmd.shQuote re-point. - StubPlugin is its own main package under providertest/stubplugin; T4's gate names the §3.1 interfaces, not leaf C's registry, so leaf A truly has no in-edges. - §1.3 seam claims corrected against the branch base: RunStreamCtx exists (#270), yaml.v3 is already a direct requirement (no go.mod change), eleven Exec{} sites. - The read-only claim is scoped to built-ins; a plugin's host/exec is stated as trusted, with a per-plugin allowlist named as a cheap follow-on. - shutdown answers {}; IMPLEMENTATION names the design PR. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBxUpSShKENH7evm8ssdyJ * docs(mbo): fleet-connect — eight stacked PRs blocking-first, roadmap as goal 8, and the fleet-connect-k8s objective Operator decisions (2026-09-05): priority herdr → ports → k8s resources; one PR per blocking leaf, blocking ones first, with a complete plan for each; the roadmap items are program goals, not non-goals. fleet-connect - Plan §6.1: the leaf DAG becomes an eight-PR stack (contract → protocol → registry → {herdr, tui, cli} → bridges → integrate) with worker refs, bases, review gates and the exact `gss feature worker add` commands; TODO phases name their PR and end in a CHECKPOINT; TRACKING lists the planned workers; IMPLEMENTATION's worker map matches. - Design §2: the roadmap is goal 8 (herdr → ports → k8s → containers → sessions → system → declarative plugin → remote transports, each zero-framework-change); the non-goals shrink to two rejected items (a bridge that outlives fleet or binds a LAN address; sandboxing). Spec §8 trimmed to match. - Two contract additions before the freeze: `Tunnel.Keeper` — a provider-quoted host command the bridge keeps alive, which is what `kubectl port-forward` needs to make a ClusterIP service a local URL (F23g) — and `ReservedKeys` plus the F18c rule that any declared key runs the cursor row's action and shows in the header (F1e), so a provider's `l d e x t` keys need no fleet keymap change. fleet-connect-k8s (new objective; design, spec, plan, trio; index rows) - Grounded in a read-only probe of the three cluster hosts: k3s 1.36 on the Jetson (`k3s kubectl`, root-owned but readable kubeconfig), kind on the WSL host, kind on the Pi with kubectl under ~/opt/bin off the ssh PATH; every service ClusterIP. - A built-in provider, also served over the wire; five levels (contexts → namespaces → curated kinds → objects → containers) with 1/0/1/1/1 round trips; `l d e` streams, `x` exec with a bash→sh fallback literal, `t` service tunnels via Keeper; every cluster value quoted, no secret value leaves the host; degraded states as rows. - 8 tasks in four stacked PRs (kA core → kB levels → kC actions → kD integrate), starting after fleet-connect PR 3. Also registered as ideas: fleet-connect-containers, -sessions, -system, fleet-provider-decl, fleet-connect-remote. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBxUpSShKENH7evm8ssdyJ * docs(mbo): fleet-connect — one program label (`fleet-connect`) on every related PR and issue Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBxUpSShKENH7evm8ssdyJ * docs(mbo): fleet-connect — record the GitHub anchors (#289–#296, k8s #297 with #298–#301) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBxUpSShKENH7evm8ssdyJ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

fleet-connect-k8s/integrate: PR kD · dual-path proof, registration, docs, live gates (T8) #301

Description

Activity

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions