update.

Author: blacknon

.github/workflows/release.yaml

@@ -5,11 +5,7 @@
 name: Release Job.
 
 on:
-  push:
-    branches:
-      - master
-    paths-ignore:
-      - '**/README.md'
+  workflow_dispatch:
 
 permissions:
   contents: write

README.md

@@ -13,11 +13,11 @@ lssh
 <img src="./images/demo.gif" width="720" />
 </p>
 
-lssh is a terminal-native remote access suite for SSH workflows, cloud inventories, and provider-backed connectors.
+`lssh` is a terminal-native remote access suite for SSH workflows, cloud inventories, and provider-backed connectors.
 
-It lets you select hosts from OpenSSH config, lssh config, or provider inventories, then operate them through native SSH or connector backends such as AWS SSM, EC2 Instance Connect Endpoint, WinRM, Telnet, and custom providers.
+It lets you select hosts from OpenSSH config, `lssh` config, or provider inventories, then operate them through native SSH or connector backends such as AWS SSM, EC2 Instance Connect Endpoint, WinRM, Telnet, and custom providers.
 
-Use it for interactive shells, parallel commands, mux workspaces, file transfer, sync, mount, and monitoring. Connector-backed hosts expose only the operations supported by that connector.
+Use it for interactive shells, parallel commands, mux workspaces, file transfer, sync, mount, and monitoring. Connector-backed hosts expose only the operations their connector supports.
 
 - works with your existing SSH config
 - interactive host selection
@@ -60,7 +60,7 @@ lssh
 
 Want to generate an `lssh` config from your existing SSH config?
 
-```bash id="w2e9m1"
+```bash
 lssh --generate-lssh-conf > ~/.lssh.toml
 ```
 
@@ -121,17 +121,17 @@ For the telnet connector + multi-hop provider flow, use [`demo-telnet-provider/R
 
 ## OpenSSH config and lssh config
 
-lssh supports both your existing OpenSSH config and its own `lssh` config format.
+`lssh` supports both your existing OpenSSH config and its own config format.
 
-If you want to get started quickly, you can keep using `~/.ssh/config` as-is. If you want more advanced host metadata and workflow-oriented settings, you can use an `lssh` config instead.
+If you want to get started quickly, you can keep using `~/.ssh/config` as-is. If you want richer host metadata and workflow-oriented settings, you can move to an `lssh` config instead.
 
 You can also generate an `lssh` config from your existing SSH config:
 
 ```bash
 lssh --generate-lssh-conf > ~/.lssh.toml
 ```
 
-And even after moving to `lssh` config, you can still point it at your existing OpenSSH config to load hosts from there:
+Even after moving to `lssh` config, you can still point it at your existing OpenSSH config and load hosts from there:
 
 ```toml
 [sshconfig.default]
@@ -143,42 +143,18 @@ For more details about config formats and settings, see [docs/configuration.md](
 ## Providers
 
 `lssh` can work with more than static SSH config entries.
-Providers let it pull hosts from external inventory sources, resolve secrets just before connect, or use non-SSH connection backends such as cloud-managed connectors.
-
-Provider capabilities are grouped into a few roles:
-
-- `inventory`: generate `server` entries from APIs or cloud inventories
-- `connector`: define how a resolved target is actually reached
-- `secret`: resolve `*_ref` values at execution time
-- `mixed`: combine multiple roles in one provider implementation
+Providers let it pull hosts from external inventory sources, resolve secrets just before connect, and use non-SSH connection backends such as cloud-managed connectors.
 
-This is what makes workflows such as cloud inventory lookup, secret-manager-backed credentials, and connector-backed sessions possible without hardcoding them into the base config format.
+At a high level, providers fall into four roles: `inventory`, `connector`, `secret`, and `mixed`.
+That split makes cloud inventory lookup, secret-manager-backed credentials, and connector-backed sessions possible without hardcoding those workflows into the base config format.
 
 If you want to try provider-oriented flows locally, start from these demos:
 
 - [demo/README.md](./demo/README.md): core SSH, proxy chains, and general multi-host workflow examples
 - [demo-telnet-provider/README.md](./demo-telnet-provider/README.md): provider-managed telnet connector flow, including direct telnet access and telnet behind a double SSH hop
 
-<table>
-  <tr>
-    <td valign="top" width="25%">
-      <strong><a href="./provider/inventory/README.md">Inventory</a></strong><br />
-      Generate <code>server</code> entries from cloud or API-backed inventories.
-    </td>
-    <td valign="top" width="25%">
-      <strong><a href="./provider/connector/README.md">Connector</a></strong><br />
-      Reach targets through connector-backed runtimes such as managed sessions.
-    </td>
-    <td valign="top" width="25%">
-      <strong><a href="./provider/secret/README.md">Secret</a></strong><br />
-      Resolve <code>*_ref</code> values from secret stores at execution time.
-    </td>
-    <td valign="top" width="25%">
-      <strong><a href="./provider/mixed/README.md">Mixed</a></strong><br />
-      Combine inventory, connector, or secret roles in one provider.
-    </td>
-  </tr>
-</table>
+For the provider architecture and protocol overview, start with [provider/README.md](./provider/README.md).
+Category details are also documented under [inventory](./provider/inventory/README.md), [connector](./provider/connector/README.md), [secret](./provider/secret/README.md), and [mixed](./provider/mixed/README.md).
 
 ### Bundled providers
 
@@ -239,15 +215,15 @@ These provider implementations are currently bundled in this repository.
   <tr>
     <td valign="top" width="33%">
       <strong><a href="./provider/secret/provider-secret-bitwarden/README.md">provider-secret-bitwarden</a></strong><br />
-      Resolve secret references from Bitwarden.
+      Resolve secret references from [Bitwarden](https://bitwarden.com/).
     </td>
     <td valign="top" width="33%">
-      <strong><a href="./provider/secret/provider-secret-custom-script/README.md">provider-secret-custom-script</a></strong><br />
-      Resolve secret references through custom local scripts.
+      <strong><a href="./provider/secret/provider-secret-onepassword/README.md">provider-secret-onepassword</a></strong><br />
+      Resolve secret references from [1Password](https://1password.com/).
     </td>
     <td valign="top" width="33%">
-      <strong><a href="./provider/secret/provider-secret-onepassword/README.md">provider-secret-onepassword</a></strong><br />
-      Resolve secret references from 1Password.
+      <strong><a href="./provider/secret/provider-secret-custom-script/README.md">provider-secret-custom-script</a></strong><br />
+      Resolve secret references through custom local scripts.
     </td>
   </tr>
   <tr>
@@ -260,11 +236,9 @@ These provider implementations are currently bundled in this repository.
   </tr>
 </table>
 
-For the provider architecture and protocol overview, start with [provider/README.md](./provider/README.md).
-
 ## Tools in the lssh suite
 
-The lssh project includes multiple tools for SSH-centered workflows.
+The `lssh` project includes multiple tools for SSH-centered workflows.
 
 <table>
   <tr>
@@ -354,14 +328,14 @@ The lssh project includes multiple tools for SSH-centered workflows.
 ## Alternatives
 
 If you are evaluating `lssh`, these projects are also worth a look.
-They overlap in some workflows, but usually cover a narrower slice of what the `lssh` suite does.
+They overlap with parts of the suite, but each usually covers a narrower slice of the overall workflow.
 
 | Project | Closest `lssh` command(s) | Main focus | How it differs from `lssh` |
 | --- | --- | --- | --- |
-| [`sshs`](https://github.com/quantumsheep/sshs) | [`lssh`](./cmd/lssh/README.md) | TUI-based SSH host picker | Similar single-tool host selection UX, but `lssh` also covers parallel execution, forwarding, mux workflow, and provider/connector-backed hosts. |
-| [`ClusterSSH (cssh)`](https://github.com/duncs/clusterssh) | [`lssh -P`](./cmd/lssh/README.md), [`lsmux`](./cmd/lsmux/README.md), [`lsshell`](./cmd/lsshell/README.md) | Multi-host interactive administration | Strong for broadcast typing into multiple terminals; `lsshell` and `lsmux` are closer when you want synchronized shell workflows inside one suite. |
-| [`pssh`](https://github.com/lilydjwg/pssh) | [`lssh -p`](./cmd/lssh/README.md), [`lscp`](./cmd/lscp/README.md), [`lssync`](./cmd/lssync/README.md) | Parallel command execution and transfer tools | Good fit for parallel CLI jobs, while `lssh` adds TUI host selection, interactive workflows, and a more integrated multi-command toolset. |
-| [`tmuxinator`](https://github.com/tmuxinator/tmuxinator) | [`lssh -P`](./cmd/lssh/README.md), [`lsmux`](./cmd/lsmux/README.md) | tmux session layout management | Great for predefined tmux workspaces, but it is not an SSH host picker or transfer tool by itself; `lsmux` is SSH-oriented from the start. |
+| [`sshs`](https://github.com/quantumsheep/sshs) | [`lssh`](./cmd/lssh/README.md) | TUI-based SSH host picker | Similar in spirit to a focused host picker, but `lssh` also covers parallel execution, forwarding, mux workflows, and provider/connector-backed targets. |
+| [`ClusterSSH (cssh)`](https://github.com/duncs/clusterssh) | [`lssh -P`](./cmd/lssh/README.md), [`lsmux`](./cmd/lsmux/README.md), [`lsshell`](./cmd/lsshell/README.md) | Multi-host interactive administration | Strong for broadcast typing into multiple terminals; `lsshell` and `lsmux` are a closer fit when you want synchronized shell workflows inside one suite. |
+| [`pssh`](https://github.com/lilydjwg/pssh) | [`lssh -p`](./cmd/lssh/README.md), [`lscp`](./cmd/lscp/README.md), [`lssync`](./cmd/lssync/README.md) | Parallel command execution and transfer tools | A good fit for parallel CLI jobs, while `lssh` adds TUI host selection, interactive workflows, and a more integrated multi-command toolset. |
+| [`tmuxinator`](https://github.com/tmuxinator/tmuxinator) | [`lssh -P`](./cmd/lssh/README.md), [`lsmux`](./cmd/lsmux/README.md) | tmux session layout management | Great for predefined tmux workspaces, but it is not an SSH host picker or transfer tool by itself. `lsmux` is SSH-oriented from the start. |
 
 ### How the `lssh` suite is different
 
@@ -371,7 +345,7 @@ They overlap in some workflows, but usually cover a narrower slice of what the `
 - [`lsmux`](./cmd/lsmux/README.md) provides a pane-based SSH workspace rather than only session templating.
 - [`lspipe`](./cmd/lspipe/README.md) keeps selected hosts reusable from local pipelines and automation.
 
-## Licence
+## License
 
 [MIT](LICENSE.md)
 

cli_help_test.go

@@ -26,7 +26,7 @@ func TestCLIAppsExposeExpectedVersionStrings(t *testing.T) {
 	}
 
 	for _, tt := range cases {
-		if !strings.Contains(tt.version, "lssh-suite 0.9.1") {
+		if !strings.Contains(tt.version, "lssh-suite 0.10.0") {
 			t.Fatalf("%s version = %q", tt.name, tt.version)
 		}
 	}

cmd/README.md

@@ -14,6 +14,6 @@ Each command has its own `main.go` and delegates the actual application logic to
 - [`lscp`](./lscp/README.md): A file transfer client that provides an SCP-style interface.
 - [`lssync`](./lssync/README.md): A one-way sync command over SSH/SFTP with optional destination pruning.
 - [`lsdiff`](./lsdiff/README.md): A synchronized TUI diff viewer for comparing remote files across multiple hosts.
-- [`lsshfs`](./lsshfs/README.md): A single-host mount command that uses FUSE on Linux and NFS on macOS. Windows is not supported in `0.10.0`.
+- [`lsshfs`](./lsshfs/README.md): A single-host mount command that uses FUSE on Linux and NFS on macOS. Windows is currently not supported.
 - [`lsmon`](./lsmon/README.md): A TUI monitor for viewing the status of multiple hosts side by side.
 - [`lspipe`](./lspipe/README.md): A persistent pipe-oriented runner for reusing selected SSH hosts from local shell pipelines. FIFO bridge features are Unix-only.

cmd/lspipe/README.md

@@ -157,5 +157,5 @@ echo 'cat' > ~/.cache/lssh/lspipe/fifo/default/ops/web01.cmd
 - Windows supports normal `lspipe` session creation and command execution through the local TCP fallback.
 - `--mkfifo` creates `all.*` pipes plus one `host.*` set per host: `.cmd`, `.stdin`, `.out`.
 - Write stdin into `.stdin`, then write the remote command into `.cmd`; read the result from `.out`.
-- `--mkfifo` is currently Unix-only. Windows does not support the FIFO bridge workflow in `0.10.0`.
+- `--mkfifo` is currently Unix-only. Windows does not support the FIFO bridge workflow yet.
 - The default config search order is `~/.lssh.toml`, `~/.lssh.yaml`, `~/.lssh.yml`, then `~/.lssh.conf`.

cmd/lsshfs/README.md

@@ -8,7 +8,7 @@ It reuses the same host selection and SSH config flow as `lssh`, but exposes the
 
 - Linux clients use `FUSE`
 - macOS clients use `NFS`
-- Windows is not supported in `0.10.0`
+- Windows is currently not supported
 - connector-backed mounts that rely on `sftp_transport` are currently supported on Linux and macOS
 
 The command runs in the background by default and automatically unmounts when the SSH connection is lost.
@@ -82,7 +82,7 @@ lsshfs --list-mounts
 - `lsshfs` supports only one host at a time.
 - `@host:/path` is the preferred remote path format, but `host:/path` is still accepted for compatibility.
 - On macOS, the local mount is created with `mount_nfs`.
-- On Windows, `lsshfs` is not supported in `0.10.0`.
+- On Windows, `lsshfs` is currently not supported.
 - The default config search order is `~/.lssh.toml`, `~/.lssh.yaml`, `~/.lssh.yml`, then `~/.lssh.conf`.
 
 ### mount options

docs/install.md

@@ -104,7 +104,7 @@ brew install blacknon/lssh/lssh
 - `lsshfs` uses a different local mount backend on each OS:
 - Linux: FUSE support and a working `fusermount`/FUSE setup are required.
 - macOS: `mount_nfs` is used locally, so the client must allow local NFS mounts.
-- Windows: `lsshfs` is not supported in `0.10.0`.
+- Windows: `lsshfs` is currently not supported.
 - The repository intentionally replaces `github.com/kevinburke/ssh_config` with the vendored fork at `./internal/ssh_config` so the generated config and parser behavior stay in sync with `lssh`.
 
 ## Shell completion

internal/lsshfs/backend.go

@@ -35,7 +35,7 @@ func backendForGOOS(goos string) (Backend, error) {
 	case "darwin":
 		return BackendNFS, nil
 	case "windows":
-		return "", fmt.Errorf("lsshfs does not support windows in 0.10.0")
+		return "", fmt.Errorf("lsshfs does not support windows")
 	default:
 		return "", fmt.Errorf("lsshfs does not support %s", goos)
 	}

provider/connector/README.md

@@ -1,18 +1,19 @@
 Connector Providers
 ===================
 
-Connector providers are not implemented yet, but this directory is reserved for the provider type that describes how a resolved target can actually be used.
+Connector providers describe how a resolved target can actually be used once inventory and config resolution are complete.
+This repository already includes working connector-capable providers and mixed providers that expose connector behavior.
 
 This document uses `connector` as the provider category name.
 If older discussion or notes use the spelling `connecter`, they refer to the same design direction.
 
-Current prototype providers:
+Current connector-capable providers:
 
 - [`provider-connector-openssh`](./provider-connector-openssh/README.md)
 - [`provider-connector-telnet`](./provider-connector-telnet/README.md)
 - [`provider-connector-winrm`](./provider-connector-winrm/README.md)
 
-Planned design-only connector families:
+Planned or future-facing connector families:
 
 - `provider-connector-openssh`
 - cloud-specific connectors that may internally use OpenSSH-compatible transport