drop2run 0.1.1 → 0.1.2

package/README.md

@@ -8,8 +8,8 @@ drop2run login
 drop2run deploy dist
 ```
 
-Node 20 or newer. That is the whole of it: `login` opens a browser and stores a token, `deploy` prints the
-URL. Full documentation at [dropto.run/docs/cli](https://dropto.run/docs/cli).
+Node 20 or newer. `login` opens a browser and stores a token, `deploy` prints the URL. Full
+documentation at [dropto.run/docs/cli](https://dropto.run/docs/cli).
 
 ```
 drop2run login [--device]                    Sign in and store a token
@@ -23,6 +23,7 @@ drop2run rm <site> --yes                     Delete a site and everything on it
 drop2run token list                          List your access tokens
 drop2run whoami                              Check the token and whose it is
 drop2run where                               Show which token source is in use
+drop2run --version                           Print the version
 ```
 
 `--json` on any command prints machine-readable output instead of text.
@@ -37,117 +38,50 @@ drop2run init dist        # creates a site, writes drop2run.json
 drop2run deploy           # publishes dist to it, no arguments
 ```
 
-The order is not a convenience. A `deploy` that created a site while a project file sat next to it would
-leave the real site untouched and the person looking at a URL they did not expect.
+`deploy` never creates a second site while a `drop2run.json` sits next to it — that would leave the real
+site untouched and you looking at a URL you did not expect.
 
-`rm` is the one command that will not act on what it worked out: it prints the site it would delete and
-stops, and only runs with `--yes`. There is no undo — the files go and the subdomain is released — and a
-terminal has no confirmation dialog, so the flag is the dialog.
-
-`token create` and `token revoke` do not exist; see below.
+`rm` prints the site it would delete and stops; it only runs with `--yes`. There is no undo — the files
+go and the subdomain is released.
 
 ## Signing in
 
 `drop2run login` opens a browser, waits on `127.0.0.1`, and stores the token it is handed in
-`~/.config/drop2run/config.json` with mode `0600`.
-
-Two things about it are worth knowing, because they decide when it works:
+`~/.config/drop2run/config.json` with mode `0600`. It uses PKCE, so there is no client secret to leak.
 
-- **It needs a browser and loopback on the same machine.** The token is delivered by a redirect to a
-  temporary server this process opens on `127.0.0.1`, which is what keeps it out of clipboards and
-  scrollback. A remote shell whose browser is on another machine cannot complete that redirect — use
-  `--device` there.
-- **It uses PKCE, so there is no client secret.** A verifier is generated per sign-in and never leaves the
-  process; only its SHA-256 travels through the browser. A code intercepted anywhere along the way cannot
-  be exchanged without the verifier.
+It needs a browser and loopback **on the same machine**: the token arrives by redirect to a temporary
+server on `127.0.0.1`, which is what keeps it out of clipboards and scrollback. On a remote shell, use
+`--device` instead.
 
 ### `--device`, for a machine with no browser
 
 `drop2run login --device` prints a short code and waits. Enter it at <https://dropto.run/device> from any
-machine you are signed in on — a phone will do — and the terminal picks up its token.
-
-The short code is not the credential: it names the pending request, and approving it releases a long code
-that never left the waiting process. Somebody reading it over your shoulder learns which sign-in is
-waiting, not how to collect its token. It lasts fifteen minutes and works once.
-
-For CI, neither flow applies — nothing there can open a browser or approve anything. Create a token at
-<https://dropto.run/account/tokens> and either set it in the environment:
-
-```
-DROP2RUN_TOKEN=d2r_...
-```
-
-or put it in `~/.config/drop2run/config.json`:
-
-```json
-{ "token": "d2r_..." }
-```
-
-The environment wins. That is the same file and the same precedence `@drop2run/mcp` uses, so signing in
-once covers both.
-
-`drop2run where` says which source is in force without ever printing the token. That is deliberate: the
-output of a command line ends up in issue reports, terminal recordings and CI logs, and "why is it using
-the wrong account" is answerable without showing the secret.
+machine you are already signed in on — a phone will do — and the terminal picks up its token.
 
-## What `token create` is not
+The short code is not the credential; it names the pending request, so somebody reading it over your
+shoulder learns which sign-in is waiting, not how to collect its token. It lasts fifteen minutes and
+works once.
 
-The brief's §5 lists `token create|list|revoke`. **Create and revoke cannot exist here**, and that is a
-decision rather than an omission: a token that can mint tokens is not a leaked credential but a permanent
-one — whoever takes it makes a second, and revoking the first changes nothing because the replacement is
-one the owner never made and will not recognise. Both endpoints require a browser session. `gh` and
-`vercel` draw the line in the same place.
+### CI
 
-`token list` does exist, and answers the question a terminal can answer: which machines are holding a
-credential, and which of them has not used it since it was made. It prints prefixes, never secrets.
-`token revoke` is refused with a message rather than treated as `list` — somebody will type it, and
-listing instead would read as having worked.
+Neither flow works in CI — nothing there can open a browser or approve anything. Create a token at
+<https://dropto.run/account/tokens> and set it in the environment:
 
----
-
-Everything below is for whoever maintains this package. It is here rather than in the monorepo's docs
-because it is about this directory — but it is on the npm page too, so it says who it is for.
-
-## Releasing
-
-The current version is whatever `package.json` says; the first release with `login` in it was `0.1.0`,
-published 02/09/2026. `0.0.0` is also on the registry and is not a release — it held the bare name
-`drop2run` (brief §9.1) and predates `login` entirely, so nothing should ever be pinned to it.
-
-Check a publish from outside rather than from its own output, because the failure worth ruling out is a
-tarball with no `dist` — which the publish log looks perfectly happy about:
-
-```
-$ npx drop2run@<version> --version
 ```
-
-Publishing is one command:
-
-```bash
-cd packages/cli && npm publish
+DROP2RUN_TOKEN=d2r_...
 ```
 
-`prepublishOnly` builds and runs the tests first, and that is load-bearing rather than tidy: `files` is
-`["bin", "dist"]`, `dist` is gitignored, and `bin/drop2run.mjs` imports `../dist/index.js`. A publish from
-a checkout that had not been built would ship a package that throws on its first line — at a version
-number that can never be reused, because npm burns one even after `unpublish`.
+The environment wins over `~/.config/drop2run/config.json`, and that is the same file and precedence
+`@drop2run/mcp` uses, so signing in once covers both.
 
-**No `--provenance`, and not by oversight.** It needs a public repository, and this is a private monorepo;
-the flag fails locally with `Automatic provenance generation not supported for provider: null` and would
-fail in Actions too. Provenance arrives with the `drop2run-cli` split in brief §9.2 — which has its own
-precondition, a `gitleaks` sweep of the whole history rather than of HEAD.
+`drop2run where` says which source is in force without printing the token, so "why is it using the wrong
+account" is answerable in an issue report or a CI log.
 
-Two release chores still outstanding, neither blocking: changesets across `core` → `node` → `cli`, whose
-versions have to move in that order, and the fact that this package is the only one of the four with a
-licence field.
+## `token create` and `token revoke` do not exist
 
-The bundle itself works. `@drop2run/core` and `@drop2run/node` are resolved by build aliases rather than
-installed, and `vite build` folds both into `dist/index.js`, so the tarball has no import pointing at
-something npm cannot fetch.
+Both need a browser session, and that is deliberate rather than missing. A token that can mint tokens is
+not a leaked credential but a permanent one: whoever takes it makes a second, and revoking the first
+changes nothing. Make and revoke tokens at <https://dropto.run/account/tokens>.
 
-## Running it from the monorepo
-
-```bash
-cd packages/cli && npm run build
-node bin/drop2run.mjs --help
-```
+`token list` does exist and answers what a terminal can answer — which machines hold a credential, and
+which of them has not used it since it was made. It prints prefixes, never secrets.

package/dist/index.js

@@ -1191,7 +1191,7 @@ async function run(argv) {
   const positional = argv.filter((argument) => !argument.startsWith("-"));
   const [command, ...rest] = positional;
   if (argv.includes("--version")) {
-    const { version } = await import("./package-BGfKrpb3.js").then(
+    const { version } = await import("./package-RiuDiPsO.js").then(
       (module) => module.default
     );
     return { text: version, json: { version }, code: 0 };

package/dist/{package-BGfKrpb3.js → package-RiuDiPsO.js}

@@ -1,5 +1,5 @@
 const name = "drop2run";
-const version = "0.1.1";
+const version = "0.1.2";
 const description = "Publish a static site to Drop2Run from the command line.";
 const license = "MIT";
 const type = "module";

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "drop2run",
-	"version": "0.1.1",
+	"version": "0.1.2",
 	"description": "Publish a static site to Drop2Run from the command line.",
 	"license": "MIT",
 	"type": "module",