@kosuke-ai/cli 1.0.0 → 1.0.1-next.2

package/README.md

@@ -24,6 +24,36 @@ The token comes from `--api-key`, then `KOSUKE_API_KEY`, then the file
 `KOSUKE_CONFIG_DIR`). `--api-url` / `KOSUKE_API_URL` point it at another
 deployment.
 
+## Nightly builds
+
+The `next` dist-tag tracks the newest build of `main` that touched `apps/cli`
+(a burst of merges publishes only the last one), so the CLI can be as new as
+stage without waiting for a `cli-v*` release:
+
+```sh
+npm install -g @kosuke-ai/cli@next
+```
+
+`next` is a moving tag: the same command updates. Each build is a prerelease
+(`1.0.1-next.12`), and npm never resolves a prerelease from a plain range, so
+`npm install -g @kosuke-ai/cli` keeps giving the released line.
+
+`kosuke auth login` writes the token, and the API URL when it is not the
+default, into one `credentials.json` that replaces whatever was there, so a
+config directory holds exactly one deployment and logging into stage would
+overwrite a production login. Give stage its own directory, and keep
+`KOSUKE_CONFIG_DIR` exported for every `kosuke` call meant for stage: a new
+shell without it is silently back on production.
+
+```sh
+export KOSUKE_CONFIG_DIR=~/.config/kosuke-stage
+kosuke auth login --api-url https://app.stage.kosuke.ai
+kosuke projects list    # same shell, so it reads the stage token and URL
+```
+
+A shell alias or direnv keeps the variable set; `kosuke auth status` prints
+which URL, which token source and which credentials file won.
+
 ## Generated from the API
 
 `openapi.json` is the platform's own `GET /api/openapi.json`, snapshotted by

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kosuke-ai/cli",
-  "version": "1.0.0",
+  "version": "1.0.1-next.2",
   "description": "Kosuke platform CLI. The client customers install to drive app.kosuke.ai from their own machine.",
   "license": "MIT",
   "repository": {