turnout-cli 0.10.3 → 0.11.0

package/README.md

@@ -58,7 +58,7 @@ $ turnout use
 Ship it:
 
 ```console
-$ turnout deploy web -s prod-eu -b
+$ turnout deploy web-prod-eu -b
 [web] pnpm build
 ✓ Connected to deploy@prod-eu.example.com:22
 ✓ Backup 20260809-011500.tar.gz created in /var/www/web.backups
@@ -74,13 +74,14 @@ And see what has been going on:
 
 ```console
 $ turnout status
-turnout 0.10.2
+turnout 0.11.0
 Data directory: ~/.local/share/lacodda/turnout
 Apps:    2 (api, web)
 Servers: 2 (prod-eu, staging)
 Group:   contour (web, api)
 Creds:   1 (prod-deploy)
 Paths:   1 (wwwroot)
+Targets: 1 (web-prod-eu)
 Bindings:
   api -> staging
   web -> prod-eu
@@ -94,10 +95,11 @@ Recent:
 
 - **A dev gateway.** Apps always talk to `localhost`; turnout forwards to the selected stand over HTTP or HTTPS (self-signed certificates allowed per server), rewrites redirects, proxies WebSockets, and keeps a cookie jar per app+stand pair so switching does not log you out.
 - **Servers, logins and paths kept apart.** A machine, the credential that logs into it and the directory files land in are three named entities. Define a deploy account once and point every stand at it; declare a web root once and reuse it across servers.
+- **Named deploy targets.** The four of them under one name: `turnout deploy web-prod-eu` from any directory, no flags to re-type. A first deploy that has no target yet offers to save the one it just used.
 - **Secrets in the OS keyring** - Windows Credential Manager, macOS Keychain, Linux Secret Service. A secret belongs to a credential, so one `pass set` covers every stand that credential reaches. Copy it to the clipboard with one command; nothing lands in a config file, and `status` only ever reports *that* a credential exists.
 - **Commands from any directory.** `dev`, `build`, `test`, `lint` and any custom command run in the right project folder. Commands are taken from your actual `package.json` scripts, so a project whose dev script is `serve` still answers to `turnout dev`.
 - **Deploy over SSH/SFTP** - build, upload, restart, with remote backup and restore when a release goes wrong. Artifacts travel as a single archive instead of thousands of round trips, falling back to file-by-file when the server cannot unpack one. Linux and Windows servers alike: turnout detects which shell answers SSH and phrases every remote command in it.
-- **Portable settings.** `export` writes your apps, servers, credentials, paths and groups to one file and `import` merges it on another machine; secrets come along only when you ask, sealed with a passphrase.
+- **Portable settings.** `export` writes your apps, servers, credentials, paths, targets and groups to one file and `import` merges it on another machine; secrets come along only when you ask, sealed with a passphrase.
 - **Stays current.** A once-a-day check mentions a new release without ever delaying a command, and `self-update` installs it - leaving package-manager installs to their package manager.
 - **Groups.** Bind a whole contour to one stand with a single `use`.
 - **Nothing to memorize.** Leave a name out and pick it from a list; in bash, Tab completes app, server, credential, path and group names from your own catalogs. The short alias `tn` is installed alongside.
@@ -133,7 +135,7 @@ cargo install turnout
 
 **Binary releases** - grab the archive for your platform from [Releases](https://github.com/lacodda/turnout/releases/latest) (Windows x86_64, Linux x86_64, macOS arm64), unpack and put `turnout` on your `PATH`.
 
-The installers and the npm package also register the short alias `tn` (skipped if the name is already taken; `TURNOUT_NO_ALIAS=1` opts out). `cargo install` gives you `turnout` only.
+The installers and the npm package also register the short alias `tn` (skipped if the name is already taken; `TURNOUT_NO_ALIAS=1` opts out). `cargo install` gives you `turnout` only. The alias is a link to the binary rather than a copy of it, so an install costs one binary and both names always answer with the same version.
 
 Both installers take the newest release by default; set `TURNOUT_VERSION` to a tag to pin one, and `TURNOUT_INSTALL_DIR` to choose where the binary lands.
 
@@ -145,7 +147,7 @@ turnout app add                # register a project (detects its commands)
 turnout server add             # register a stand
 turnout use                    # bind one to the other
 turnout gateway start          # route traffic through the gateway
-turnout deploy-setup           # to deploy: walks the credential and path too
+turnout deploy-setup           # to deploy: walks the credential, path and target
 ```
 
 Data lives in the platform user data directory (e.g. `%LOCALAPPDATA%\lacodda\turnout` on Windows); set `TURNOUT_DATA_DIR` to override.
@@ -156,7 +158,6 @@ Full command reference and concepts: **[lacodda.github.io/turnout](https://lacod
 
 Everything above works today. What is next:
 
-- [ ] **Named builds** - app + server + credential + path under one name, so `turnout deploy webui-prod` works from any directory
 - [ ] **Key-based access, set up rather than only used** - generate a key, install it on the server and verify it in one command, including the Windows administrator case
 - [ ] **Background runs** - `dev --detach`, `ps`, `logs`, `stop`, OS notifications
 - [ ] **Observability** - gateway request log, `doctor`, `report` for handing context to an assistant

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "turnout-cli",
-  "version": "0.10.3",
+  "version": "0.11.0",
   "turnout": {
-    "binary": "v0.10.3"
+    "binary": "v0.11.0"
   },
   "description": "A developer's switchyard: point local apps at any backend stand, keep servers and secrets at hand, build and deploy from any directory",
   "license": "MIT",