@thebaycloud/cli 1.0.0 → 1.1.0

package/CHANGELOG.md

@@ -1,5 +1,80 @@
 # Changelog
 
+## 1.1.0
+
+**Everything below `Unreleased` was already written and none of it was shipped.**
+
+`1.0.0` sat in main looking released while npm held a tarball without
+`bay share`, without `ship --name`, and without the thebay.cloud rename. The
+publish workflow guards on the version field and a no-op publish reports success,
+so every push since said "Publish CLI: success" and changed nothing anybody could
+install. Its own comment records this happening twice before: "BOTH times the
+version sat in main looking released."
+
+Found from the outside, by a deploy report: `bay ship --name` was rejected as an
+unknown flag and `bay share <app> public` printed help, both of which the manual
+documents and the repository implements. Verified by pulling the published
+tarball and diffing `SHIP_FLAGS`.
+
+So this is a version bump and nothing else. What it releases:
+
+- `bay share <app> public|private|shared`, and the whole access surface — add and
+  remove people, company rules, pending requests. Implemented, never published.
+- `bay ship --name <name>`, so an app is not stuck with a generated slug.
+- The rename: `bay` as the command, `thebay.cloud` as the domain, `~/.bay` with
+  `~/.supersonic` still honoured.
+- `bay logs` as a filter rather than a line count — a level, `source=`, `status=`,
+  `path=`, or free text — and `--follow` as a real stream over server-sent events
+  instead of polling every 2.5 seconds against a set of every line it had seen.
+
+## Unreleased
+
+**The command is `bay`, and the package is `bay-cli`.**
+
+The product is Bay and the domain is thebay.cloud, so the thing you type is
+`bay ship`. Everything about the old name keeps working, and none of it is
+deprecated: the package still installs a `supersonic` binary, `~/.supersonic`
+is still read when it is the directory that exists, and `SUPERSONIC_TOKEN`,
+`SUPERSONIC_URL` and `SUPERSONIC_WHO` are still honoured beside `BAY_TOKEN`,
+`BAY_URL` and `BAY_WHO`. A rename that silently stops reading a token file
+does not read as a rename — it reads as the platform signing you out — so the
+migration is: use the new name if it is there, otherwise keep using theirs.
+`lib/home.js` holds that rule and `test/home.test.js` pins it.
+
+Not renamed, deliberately: `supersonic.json`, the `x-supersonic-*` headers,
+`SUPERSONIC_RUN`, `SUPERSONIC_CODE_*`, and the encryption salt. Those are read
+by the CONTROL PLANE rather than typed by a person, and moving them from this
+side would break every ship against a server that has not moved with them.
+
+**Everything the dashboard does, the CLI does.**
+
+`bay share` (visibility, people, and `@company` rules), `bay domains` (attach a
+domain you own and print the one DNS record to create), `bay db` (tables, rows,
+one read-only SELECT), `bay git` (which branch, and whether a push ships),
+`bay plan` (the plan and every limit left) and `bay tokens` (every CLI signed
+in to the account, and revoking one). No new endpoints were needed: the control
+plane resolves a Bearer token wherever it resolves a session cookie.
+
+The DNS record comes from the server rather than being derived here. Apex versus
+subdomain is a public-suffix question, and a second copy of that rule would agree
+until the day the list grew — then tell somebody to create a CNAME their
+registrar refuses.
+
+**Fixed: `check` claimed every service started from a Dockerfile.**
+
+It printed "start · the Dockerfile's own CMD" for every non-static service,
+because it asked whether the lane was `container` — and after the buildpack
+lane was removed, `container` means all of them. So a repository with no
+Dockerfile, whose start command is stated in the config in plain text, had that
+command hidden by the one command whose job is to say what will run. It reads
+the author's Dockerfile now.
+
+**Fixed: `open` and `status` knew exactly one domain.**
+
+Both built `https://<app>.supersonic.cv` in the published package — a URL that
+survives a rebrand, ignores every attached domain, and can only be corrected by
+a release. They ask the API for the app's own address.
+
 ## 0.12.1
 
 **A ship now says who is shipping.**

package/LICENSE

@@ -0,0 +1,34 @@
+The MIT License (MIT)
+
+Copyright (c) 2026 Bay
+
+This directory is a deliberate exception to the repository's licence. Everything
+else in github.com/thebaycloud/bay is AGPL-3.0-only; `packages/cli` is MIT.
+
+The reason is that this is client software. It is installed globally, run by
+coding agents inside other people's projects, and a copyleft licence on it would
+make "we used the Bay CLI" a licensing question for every project it touches.
+The platform is the thing the AGPL is protecting; the CLI is the thing we want
+in as many toolchains as possible. It stays in this repository — and not in one
+of its own — because `scripts/bundle-detector.mjs` and
+`scripts/bundle-resolver.mjs` compile the control plane's own stack detector and
+resolver into it at publish time, so the CLI and the server cannot disagree
+about what a project is.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -1,32 +1,42 @@
 # @thebaycloud/cli
 
-Deploy anything to [Bay](https://app.thebay.cloud) in one command.
+Ship anything to [Bay](https://thebay.cloud) in one command.
 
 ```bash
 npm install -g @thebaycloud/cli
 ```
 
+The command is `bay`. It also installs as `supersonic`, which is the name it had
+before and which every existing script, CI job and agent prompt still says — that
+alias is permanent, not deprecated.
+
 ## Usage
 
 ```bash
-bay init                  # write a DRAFT bay.json from this repo
+bay init                  # write a DRAFT supersonic.json from this repo
 bay check                 # what each phase would run, and what would fail
-bay login                 # authenticate (defaults to app.thebay.cloud)
-bay deploy                # deploy the current repo (uses your git origin)
-bay deploy --repo <url>   # or deploy any public git repo
+bay login                 # authenticate (defaults to app.supersonic.cv)
+bay ship                  # ship this folder — a live URL now, the build behind it
+bay ship --github         # or ship from your git origin / any public repo
 bay whoami
 bay logout
 ```
 
-`bay deploy` streams the live build log — clone → detect stack → build → Cloud Run — and prints your live URL when it's up.
+`bay ship --wait` streams the live build — clone → detect stack → build → run — and
+prints the live URL when the app is actually serving it. `bay deploy` is the same
+command under its older name and always will be.
+
+Everything the dashboard does, this does: `bay share` (who can open it),
+`bay domains` (a domain you own, and the DNS record to create), `bay db`,
+`bay git` (branch + ship-on-push), `bay plan`, `bay tokens`. Run `bay help --all`.
 
-## Before you deploy
+## Before you ship
 
 `init` and `check` are local. No cloud, no build, no model, about two seconds each,
-and they are the loop an agent authoring a `bay.json` should be in — because
-the same loop through a real deploy is eleven minutes long.
+and they are the loop an agent authoring a `supersonic.json` should be in — because
+the same loop through a real ship is eleven minutes long.
 
-`bay init` reads the repository and writes a **draft** `bay.json`: the
+`bay init` reads the repository and writes a **draft** `supersonic.json`: the
 monorepo split, the install command from the lockfile, the build command and output
 directory, the start command bound to `$PORT`, the runtime version the manifests ask
 for, and the framework. Then it prints what it could not determine — which service
@@ -47,7 +57,14 @@ after the runner had moved to 3.14.
 
 ## Options
 
-- `bay login --url <control-plane>` — point at a different control-plane (defaults to `https://app.thebay.cloud`; also settable via `BAY_URL`).
-- `bay login --email <e>` — skip the email prompt. Password can be piped via `SUPERSONIC_PASSWORD`.
+- `bay login --url <control-plane>` — point at a different control-plane (defaults to `https://app.supersonic.cv`; also settable via `BAY_URL`).
+- `bay login --token <t>` — for CI and headless agents. `BAY_TOKEN` in the environment does the same and overrides anything saved.
+
+Your session is stored in `~/.bay/config.json`. An existing `~/.supersonic/config.json`
+is still read, so an upgrade does not sign anybody out — and `SUPERSONIC_URL` /
+`SUPERSONIC_TOKEN` are still honoured alongside the `BAY_` names.
 
-Your session is stored in `~/.bay/config.json`.
+What is deliberately NOT renamed: the config file is still `supersonic.json`, and the
+`x-supersonic-*` headers, `SUPERSONIC_RUN` and `SUPERSONIC_CODE_*` are still what they
+were. Those are read by the control plane, not typed by a person; they change when the
+server changes, not before.