turnout-cli 0.17.0 → 0.19.0

package/README.md

@@ -32,10 +32,15 @@ Start working, from wherever you happen to be:
 
 ```console
 $ cd ~/dev/web/src/components
-$ turnout dev
-[web] pnpm dev
+$ turnout dev --open
+[web] pnpm dev --port 5100
+[web] http://web.localhost -> dev server port 5100
+◇  web ready in 1.4s - http://web.localhost
 ```
 
+The server is up, the page is open, and the console stays quiet from here -
+until something breaks, which is when you want it loud.
+
 Move the whole contour at once when the frontend and the API must agree:
 
 ```console
@@ -74,7 +79,7 @@ And see what has been going on:
 
 ```console
 $ turnout status
-turnout 0.17.0
+turnout 0.19.0
 Data directory: ~/.local/share/lacodda/turnout
 Apps:    2 (api, web)
 Servers: 2 (prod-eu, staging)
@@ -85,8 +90,9 @@ Targets: 1 (web-prod-eu)
 Bindings:
   api -> staging
   web -> prod-eu
-Gateway: running (pid 24180; web:7100 -> VITE_API_URL, api:7101 -> TURNOUT_GATEWAY_URL)
+Gateway: running (pid 24180)
 Front:   http://localhost - http://NAME.localhost
+Spare:   web:7100 -> VITE_API_URL, api:7101 -> TURNOUT_GATEWAY_URL
 Recent:
   2026-08-09T01:15:02Z  deploy         web -> prod-eu (142 files)
   2026-08-09T01:12:44Z  use            web -> prod-eu
@@ -96,13 +102,14 @@ 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.
 - **One address per app.** `http://myapp.localhost` reaches the dev server turnout started for `myapp`, whichever port it took - the gateway's front door routes by name, and `*.localhost` needs no hosts file. The port is assigned once and handed to the server as `PORT` and `{port}`; `turnout open myapp` opens the address.
-- **The port is written once.** An app's gateway port lives in turnout only; the app is handed the address - `turnout dev` sets it as an environment variable the framework can see (`VITE_API_URL`, `REACT_APP_API_URL`, your pick), and a `.env.development.local` that turnout keeps in step covers a dev server started from an IDE. `build` never gets it, so a production bundle cannot bake in localhost.
+- **You never type a port.** turnout assigns an app's gateway port when you register it and its dev port on the first `dev`; both live in turnout only, and the app is handed the address - `turnout dev` sets it as an environment variable the framework can see (`VITE_API_URL`, `REACT_APP_API_URL`, your pick), and a `.env.development.local` that turnout keeps in step covers a dev server started from an IDE. `build` never gets it, so a production bundle cannot bake in localhost.
 - **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.
 - **Key access set up, not just used.** `turnout key setup prod` generates an ed25519 key, authorizes it on the server, proves it signs in and only then switches the credential over - so a server-side misconfiguration never costs you the password that still works. Windows servers included: an administrator account keeps its keys in a different file that sshd reads instead, and turnout writes to the right one.
 - **The SSH agent signs for you.** A credential can authenticate with a key the agent already holds unlocked, so a passphrase is typed once per login session instead of once per command - turnout never reads the key file at all. `SSH_AUTH_SOCK` on Linux and macOS; on Windows, Pageant or the OpenSSH agent service, whichever is running. An agent holding several keys is the normal case: they are offered in turn and the first the server accepts wins.
 - **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`.
+- **A quiet console.** A build shows a loader and its elapsed time, not two minutes of scrollback; a dev server goes quiet once it reports itself and speaks again only when something breaks. A failure prints its output on the spot - no re-run to see what went wrong - and every job's output is kept in a log file whatever the terminal showed. `-v` gives you all of it, and so does any pipe, so scripts and CI logs are unchanged.
 - **A hand on the server.** `turnout ssh web-prod` opens a session with host, port, user and key from the catalogs, in the deploy directory, the password already on the clipboard; `turnout exec web-prod -- docker compose ps` runs one command there and hands back its exit code.
 - **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, targets and groups to one file and `import` merges it on another machine; secrets come along only when you ask, sealed with a passphrase.
@@ -169,13 +176,10 @@ Full command reference and concepts: **[lacodda.github.io/turnout](https://lacod
 
 ## Status
 
-Everything above works today. What is next:
-
-- [ ] **Background runs** - `dev --detach`, `ps`, `logs`, `stop`, OS notifications
-- [ ] **Observability** - gateway request log, `doctor`, `report` for handing context to an assistant
-- [ ] **Deploy consists** - atomic deploy and rollback across a group of apps
-
-Released versions and what landed in each: [CHANGELOG on the Releases page](https://github.com/lacodda/turnout/releases).
+v0.19.0, in daily use. Everything above works today: stands and switching
+between them, the gateway, secrets in the OS keyring, the quiet console, and
+build and deploy from any directory. What landed in each version:
+[the Releases page](https://github.com/lacodda/turnout/releases).
 
 ## Documentation
 

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "turnout-cli",
-  "version": "0.17.0",
+  "version": "0.19.0",
   "turnout": {
-    "binary": "v0.17.0"
+    "binary": "v0.19.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",