@unotest/web 0.39.0 → 0.41.0

package/CHANGELOG.md

@@ -1,5 +1,590 @@
 # Changelog
 
+## [0.41.0] - 2026-09-21
+
+### Minor Changes
+
+- e793fa2: `env push | set | rm`: the box and the token come from the project's own files
+
+  The values commands now resolve the box address and the project token
+  exactly the way `bundle push` does — a flag, then `UNOTEST_BOX_URL` /
+  `UNOTEST_BOX_TOKEN`, then `unotest/.env` and `unotest/.secrets`, where
+  `box create` and `box access` wrote them. A project set up with either of
+  those commands no longer answers "no box address" to `env push` while
+  `bundle push` works, and the two exports stop being typed in front of
+  every line.
+
+  `env set <env> <NAME> <value>` takes the value as an argument. Stdin
+  still works when there is none, and stays the way to pass a credential:
+  an argument is in the shell's history.
+
+  `env push --dry-run` now prints what the overlays resolved to, quoted, so
+  a value that kept its quotes or picked up a trailing space is visible
+  before it reaches a box. `--dry-run --json` carries the same under
+  `values`. A secret's value is still never printed: where it would be, the
+  mask used everywhere else (`‹secret:NAME›`) stands instead.
+
+  A push whose box lacks some of the suite's declared values no longer
+  claims the run "will stop at the first step that reads" one of them: the
+  names are what the suite DECLARES, and a declared name no scenario reads
+  costs a run nothing.
+
+- 41b0369: A box rented from the dashboard now says how to send it a suite
+
+  A box rented from the CLI arrives with the suite already on it: `box create`
+  pushes it and prints the command that runs it. A box rented from the dashboard
+  arrives empty, and the card said nothing about that. It showed the address, the
+  login and the password, and left the customer with a machine that answers, an
+  empty viewer, and no idea that anything else was needed. Everything they had to
+  do next lived in an email and on the box's own empty screen.
+
+  The card of a ready box now carries the three commands that take a project from
+  here to a first run: sign in, take the box's tokens, push the suite. Each is a
+  field that can be copied in one click, with the box's own name already in it.
+  The environment name is filled in when the box has exactly one, and left as
+  `<env>` when it has several — picking one for the customer would send the run
+  to a site they did not mean, and nothing would refuse it, because the name is
+  perfectly valid. The collection is named too: a box runs a collection, not a
+  single scenario, and a push that names none is turned away.
+
+  Those commands are now written in one place and printed by both the card and
+  the "your box is ready" letter. They used to be the letter's alone, and a
+  second copy on the card would have been a second piece of advice the first time
+  either was edited.
+
+  Once a project has taken the box's tokens, the card stops repeating the first
+  two commands and asks only for the push. That is the one thing the cloud can
+  honestly know about the far end of a box: the suite travels from the customer's
+  machine straight to it, and nothing reports back. So the card says nothing at
+  all about runs — not "no runs yet", not "0 runs". It cannot tell a box that has
+  been testing for a week from one nobody has touched, and a page that says
+  otherwise is inventing it.
+
+### Patch Changes
+
+- 36bc4b3: An empty list of environments says which kind of empty it is
+
+  `box envs` on a box that listed nothing said "This box serves no environments
+  you can read." — a sentence about the token, on a list that is not filtered by
+  the token at all. People whose box was simply new went looking for a stronger
+  credential, and the box's own journal had nothing to say either way.
+
+  The list now talks about the box:
+
+      This box serves no environments yet.
+        An environment appears once a suite has been pushed to it.
+
+  A token that really is not let in still answers in its own words, with its own
+  exit code, so the two are told apart by reading them.
+
+  Behind the list, the box now records which of five things happened when it
+  looked for its route table: there is no table yet, the table cannot be read,
+  it is not JSON, its shape is wrong, or it is honestly empty. Each is one line
+  in the box's journal, naming the file and never its contents — the table holds
+  internal addresses. A table that loaded says how many environments it found,
+  because "none" and "three" were otherwise the same silence.
+
+  Two fixes come with it. A line belongs to a state rather than to a request, so
+  a busy box writes one line and not one per proxied asset. And a table that
+  failed to parse is read again a second later instead of being remembered as an
+  empty box until its timestamp changes — which is why "I tried again and it was
+  the same" used to be true.
+
+  An empty list stays a successful answer, `200` with no entries: a box with
+  nothing on it yet is a normal box, not a service that is down.
+
+- 7bac819: A box installs a suite whose `npm ci` is slow, and stops retrying in a loop
+
+  A box could not install a suite whose dependency install went quiet for
+  more than five minutes — which is what a heavy lockfile does. The install
+  died on the 301st second, reported the runner as unavailable, and the box
+  started the whole install again in the second it failed. That repeated for
+  as long as the box existed: nothing ever ran on it, and the message blamed
+  the network rather than naming the timeout that caused it.
+
+  Three things change. The daemon no longer puts a ceiling of its own on
+  reading a run's output, so silence is not a failure; the run's deadline
+  remains the only clock that ends a run, and a backstop behind it covers a
+  connection that stops answering altogether. A run whose output stops
+  without an exit now takes its container with it — abandoned containers
+  used to fill the box's capacity while healthy environments waited for a
+  slot. And a failed install is followed by a pause that grows: 1, 2, 5, 15
+  and 30 minutes, capped there, never "never". Asking for that bundle
+  yourself — a switch or a repair — is tried at once and clears the count,
+  as does an install that succeeds, and the log says when the box will try
+  next by itself.
+
+  The pause is the box's own, never yours: a run you order by hand, and a run
+  a push to your repository orders, install the bundle at once and clear the
+  count. Only the box's unattended retry waits.
+
+- 7880b7d: Installs on a box share one npm cache, and a suite can never reach it
+
+  Until now every install on a box started with an empty npm cache: the
+  container that runs `npm ci` was thrown away with everything it had
+  downloaded, so the second box of the same account — and the same box
+  after a restart — paid the full download again for dependencies it had
+  already had twice.
+
+  Boxes now keep one npm cache and every install uses it. The second
+  install of a dependency is taken from disk instead of the network; how
+  much time that saves depends on your lockfile and your registry, and on a
+  fast registry it can be none at all — the promise here is only that
+  what has already been downloaded is not downloaded again.
+
+  The cache is mounted into the container that installs, and into no other.
+  A container running your suite gets no access to it under any name: the
+  cache is the directory that every later install of every project on that
+  box unpacks, and a test that could write into it would be writing into
+  the next install. That boundary is asserted as a pair — the install has
+  it, the run does not — rather than as two separate claims.
+
+  A substituted cache entry is never installed. npm verifies an entry's
+  checksum when it READS from the cache, not only when it writes one: an
+  entry whose content does not match is reported as corrupted and fetched
+  again (verified on the box's own image, npm 11.16.0 — with a registry
+  reachable the correct package is installed; without one the install fails
+  rather than using the substitute).
+
+  The box keeps the cache's size in hand. It is measured on each
+  housekeeping sweep and, over the ceiling (1 GB by default, and an
+  operator can raise it or turn it off), emptied whole with a line in the
+  log — losing a cache costs a download and nothing else.
+
+- d456001: Ordering a run in an environment now decides what that environment serves
+
+  Pushing a suite and asking for a run in a named environment is a
+  statement about that environment: it should serve the bundle you just
+  sent. Until now the box decided that separately, by matching the
+  bundle's branch — so a suite packed outside a git repository, which is
+  what `init` produces in a clean directory, matched nothing. The run
+  installed, executed and passed, while the environment kept pointing at
+  nothing: its viewer was never started, the guard was given no route for
+  it, `box envs` listed nothing, and `box runs --env <name>` answered that
+  the box does not serve that environment. Four different answers to one
+  question, after the client had been told the suite was accepted and
+  queued.
+
+  An explicit run request now selects the bundle for the environment,
+  through the same path a selection made in the viewer takes, recorded
+  against the token that pushed — so it survives a restart and the box
+  does not silently move the environment back on its next sweep. Branch
+  matching keeps deciding exactly one thing, the one it is right for:
+  which bundle the environment's SCHEDULES run.
+
+  An environment that may not be switched (`allowSwitch: false`) keeps
+  serving what its own branch deploys, and the answer now says so instead
+  of leaving it to be found out: the run goes ahead there, and the
+  acceptance names the branch the environment stays on — so it is clear
+  the result belongs to that environment's journal rather than to the
+  screen the environment shows.
+
+  The one case with nothing to show is refused out loud. An environment
+  that may not be switched and serves nothing yet has no viewer at all, so
+  a run ordered there could only end where this bug ended: executed, green
+  and invisible. The refusal names the branch to deploy to instead.
+
+  Migration note: that refusal is a new error code on the run endpoint.
+  A CLI older than this release does not know it and will report the
+  box's answer as "not a box" rather than as a refusal — the request is
+  still refused, and nothing runs. Upgrade the CLI to see the message.
+  The acceptance note is a new field on an otherwise unchanged answer, and
+  an older CLI ignores it.
+
+- 436b683: The box's own screen gives the same first-run command as everything else
+
+  A freshly rented box shows two commands: one that points the project at the
+  box, one that sends the suite and starts it running. The second was printed
+  without `--collection`, and a box runs a collection or a schedule — never a
+  scenario by name. Copied exactly as shown, into a project straight out of
+  `init`, it came back refused with nothing to run: an answer about a project
+  that had done nothing wrong, from the first screen a new box owner reads.
+
+  The screen now prints the whole command, and says where collections live:
+
+      npx @unotest/web bundle push --run --env ENVIRONMENT --collection examples
+
+  The command is no longer written out on each surface that shows it. The box's
+  screen, the last line of `box create`, and the collection `init` writes all
+  come from one place, so the next flag to change changes in one edit rather
+  than in three. `examples` is the collection `init` creates, and the screen
+  says so — it is an example of a name, not a claim about your project.
+
+  The cabinet half is unchanged in behaviour: with exactly one environment and
+  one collection it still prints a command that can be pasted as is, and
+  placeholders where it cannot know.
+
+- 3d8e45d: `unotest/.secrets` is now created owner-only (`0600`)
+
+  The file holds the box push and read tokens, and was created with the
+  default umask — on a shared machine any other user could read it. It is
+  now narrow from the moment it is created, and a file left wider by an
+  earlier version is narrowed the next time a command writes to it, with one
+  line saying what changed. `unotest/.env` is configuration rather than
+  secrets and keeps the width your project gave it.
+
+- 8a436b9: Exploration tools refuse an unknown `{{NAME}}` instead of typing it
+
+  A `{{NAME}}` the session could not resolve was passed through as text, so
+  `explore_run_flow {args:["admin","{{PASSWORD}}"]}` typed the placeholder
+  into the password field and the page answered with a normal login failure.
+  It now fails with a message that names the variable, says where to declare
+  it, and lists the names the session does have — so the value never has to
+  be pasted into the tool call by hand.
+
+  A bare `SHOUTY_NAME` is unchanged: a reference where it is registered, a
+  literal otherwise. A variable declared with an empty value still
+  substitutes as empty and is reported in `variableWarnings`; a name
+  declared as a secret with an empty value is refused with its own message.
+
+- a1b9eac: Editing a secret in the viewer's variables panel keeps `unotest/.secrets` owner-only
+
+  The panel writes a file by creating a temporary one beside it and renaming
+  it into place, and a rename replaces the target together with its
+  permissions. So a secrets file that was owner-only became world-readable
+  again after a single edit in the panel, with the box tokens inside it, and
+  adding the first secret to a project created the file wide in the first
+  place.
+
+  The temporary file is now created owner-only when the layer being written
+  holds secrets, which also narrows a file an earlier version left wide. A
+  leftover temporary file from an interrupted write is removed rather than
+  reused, so it cannot pass its own permissions on. `unotest/.env` is
+  configuration rather than secrets and keeps the width your project gave it.
+  On Windows there are no POSIX permission bits and nothing is narrowed
+  there.
+
+- Updated dependencies [436b683]
+- Updated dependencies [a1b9eac]
+  - @unotest/protocol@0.41.0
+  - @unotest/viewer@0.41.0
+  - @unotest/core@0.41.0
+  - @unotest/dsl@0.41.0
+  - @unotest/grounder-client@0.41.0
+
+## [0.40.0] - 2026-09-19
+
+### Minor Changes
+
+- fa848e9: A box that finishes coming up tells the person who rented it
+
+  Renting a box takes minutes, and until now it ended in silence. Somebody who
+  closed the tab while the machine was being built learned nothing: not that it
+  was up, not where it answers, not what to do next. A rental that says nothing
+  looks like a rental that did not work.
+
+  The service now sends one message, at the moment the box becomes ready, to the
+  address on the account. It names the box's address, points at the card on the
+  dashboard where the login and password stay readable for as long as the box
+  lives, and gives the three commands that put a suite on it:
+
+      npx @unotest/web login
+      npx @unotest/web box access <box>
+      npx @unotest/web bundle push --run --env <environment> --collection examples
+
+  The last one names a collection because a box runs a collection or a schedule,
+  never a scenario by name, and a project straight out of `init` has no schedule:
+  without the flag the run is refused before it starts. `examples` is what `init`
+  writes, and the message says to name your own instead where you have one.
+
+  The environment is filled in only when the box has one. A box can have several
+  — `box create` sends every environment the project has — and a command naming
+  the first of them reads as a command naming the only one, which would send a
+  run somewhere the reader did not choose. With several, the command carries
+  `<env>` and the message says where the names are written. Same rule as the
+  CLI's own next step, so the two do not answer one question differently.
+
+  The message carries no password. The break-glass password of a box is on its
+  card, which can be looked at again; a copy in a mailbox is one nobody can
+  withdraw. The type the message is built from has no field for it, so it cannot
+  be added back by accident.
+
+  It is sent once. The guard is the transition itself, taken inside the write
+  lock that makes a box ready, so a resumed build, the billing tick and a read
+  of the card all find the box already ready and announce nothing. A mail server
+  that is down is logged and does not touch the rental: the customer paid for a
+  machine, not for mail.
+
+- 42548f7: A box deleted by hand tells its owner too, and the letter says which deletion happened
+
+  A box could go two ways, and only one of them said anything. When the balance
+  stopped covering a box's next hour, the billing tick deleted it and wrote to
+  the owner. When a person deleted one — from the dashboard, the CLI or the REST
+  API — the machine was released, the record was settled, and nobody was told.
+
+  That silence is only harmless while the person who presses delete and the
+  person who pays for the account are the same person. An account can have
+  several people on it, an API key, and a dashboard open where it should not be.
+  The one deletion a customer most needs to hear about is the one they did not
+  make, and it was the one that arrived as nothing at all.
+
+  Every deletion now ends in the same letter, from the same place, and the
+  letter's first paragraph says how the box went: the balance could not cover
+  the next hour, or somebody with access to the account asked for it. The second
+  version names no sum — what the balance happened to be when a person pressed
+  delete explains nothing about why the box is gone, and a figure printed beside
+  a deletion reads as its cause. It points at the dashboard instead, for a reader
+  whose next question is who else has access. Everything after that first
+  paragraph is one text for both: the machine and what was stored on it are gone,
+  the scenarios in the customer's own repository are not, and the name is never
+  reused.
+
+  One letter per deletion, not per caller. The transition to deleted is claimed
+  under the same write lock that settles the record, and only the caller that
+  made it writes. A person and the billing tick arriving at one box in the same
+  moment therefore send one letter between them — previously they could each
+  send their own.
+
+  A box the fleet has no record of is now settled rather than retried forever.
+  The tick used to treat "no such box" from the fleet as a failure to delete,
+  leaving the record live and billable and trying again every hour; it now ends
+  the way it does when a person deletes such a box, which is that there is
+  nothing to release and the record is closed.
+
+  The journal says which way a box went, on both paths. Until now a deletion by
+  hand left no line at all, and the only way to tell one from an eviction was the
+  absence of the tick's own lines.
+
+  A mail server that is down still never holds a deletion up: the machine is
+  released and the record settled first, and a failed send is a line in the log.
+
+- cb4a7e5: `box access` without a name lists the boxes the account already has, instead of advising a second one
+
+  Run in a directory that does not know a box — a fresh checkout, a second
+  project — `box access`, `box status`, `box destroy` and `box picker`
+  refused with three things to try, and the only one anybody can follow
+  without thinking was `box create`. For somebody who already rents a box,
+  following it rents and pays for another.
+
+  The refusal now asks the account first. With one box it names it and gives
+  the command back ready to run:
+
+      no box named and none configured — this account has one box,
+      "larch": run `box access larch`
+
+  With several it lists them and asks which. Only an account with no boxes
+  at all is still told to create one, and a cloud that refused or could not
+  be reached is told the same as before — a cloud that did not answer is
+  never read as "you have no boxes".
+
+- 1cb7ba5: Reading a box takes the same environment name that ordered the run
+
+  `bundle push --run --env prod` has always taken the bare environment
+  name and let the box fill the project in from the token. The commands
+  and MCP tools that read the results back wanted the full
+  `acme/prod`, and a bare name came back as a 404 that talked about the
+  environment rather than about its form:
+
+      ✗ this box does not serve 'prod'
+
+  So the name that worked in one command failed in the next, and nothing
+  on screen said why.
+
+  Both halves now take both spellings. `box runs`, `box run`, `box queue`
+  and `box screenshot` — and `box_runs`, `box_run`, `box_run_download`,
+  `box_queue`, `box_screenshot` — translate the name against the box's own
+  list before the request, exactly the list `box envs` prints. A bare name
+  only one project on the box has is sent as that project's full name; a
+  bare name several projects share is refused before anything is asked,
+  naming them:
+
+      ✗ box runs: more than one project on this box has an environment
+        called "test" (acme/test, beta/test) — name the one you mean in
+        full.
+
+  A name the box serves in neither form is refused the same way, listing
+  what it does serve. Where the list cannot be had — a box that did not
+  answer, a refused token, an empty list, which does not prove there are
+  no environments — the name goes as it was typed and the box decides,
+  exactly as before; its refusal now names the form as well as the
+  command that lists the names.
+
+### Patch Changes
+
+- 9878745: `bundle push` that refuses leaves nothing behind in the project
+
+  The environment check now stands in front of the packing step, not only in
+  front of the upload. Packing writes: a suite that has no `package-lock.json`
+  yet gets one, in your repository, next to your scenarios. So a push refused
+  for naming an environment the box does not have still ended with a file that
+  was not there before the command — the refusal cost something after all, and
+  the next `git status` showed it.
+
+  The order is now: the flags, the box address, the token, the environment, and
+  only then the suite is packed. Nothing that can be refused happens after the
+  first write.
+
+  What was already right stays: `--dry-run` still packs and still prints its
+  bundle id, without asking for a box. The refusals about a missing address and
+  a missing token answer in the same words and with the same exit codes as
+  before — they simply answer sooner, before the lockfile is touched. A push
+  that goes through writes the lockfile exactly as it always did.
+
+- 8cc5b20: `bundle push --run` checks the environment name before uploading, and names the environments itself
+
+  Pushing with an environment name the box does not have uploaded the whole
+  bundle first, and only then came back with a refusal — so the last thing
+  on screen was "uploaded", the wasted upload looked like success, and the
+  refusal read like a problem with the box. The advice that followed was to
+  ask the operator which environments exist; on a rented box the customer
+  is the operator.
+
+  The name is now checked against the box's own list first, with the read
+  token `box envs` uses. An unknown name is refused before anything is
+  uploaded, and the refusal names what the box does serve:
+
+      ✗ no environment named "staging" on https://larch.box.unotest.com
+        — nothing was uploaded.
+        it serves acme/test, acme/prod — push into one of them with
+        --env test
+
+  Both spellings the box itself gives are accepted, `acme/test` and the
+  bare `test`. Where the list cannot be had — no read token, a box that did
+  not answer, an empty list, which does not prove there are none — the push
+  goes ahead exactly as before and the box decides. Refusals that still
+  come from the box now point at `box envs` instead of an operator.
+
+- 8a9c112: A fresh project can start a remote run: `init` writes a collection, and the refusal says what a box runs
+
+  A box runs a collection or a schedule; the local runner takes a scenario by
+  name. Both are true, and nothing said they differ — so a project created by
+  `init`, which wrote neither a collection nor a schedule, could not start a
+  remote run at all. The command the box's own screen offers came back with
+  "nothing to run", and the refusal named the state without naming the
+  difference or anything to try.
+
+  `init` now writes `unotest/e2e/_collections/examples.yaml`, naming the
+  examples it already creates. They hit the public playground, so the first
+  remote run passes before the box can reach the customer's own application:
+
+      npx @unotest/web bundle push --run --env <environment> --collection examples
+
+  A run asked for without a collection is still refused — that has not
+  changed — but the refusal now says that a box runs a collection or a
+  schedule rather than a scenario by name, and what to pass instead.
+
+- 3f9bcb3: The box's screens fit a phone: the header wraps instead of running off the side
+
+  Four things sit in the header of every guard page — the box's own address,
+  who is looking, the link to the other half of the guard, and the way out. On
+  a screen 320 px wide they did not fit on one line, and what did not fit was
+  pushed past the right edge, taking the page's width with it. The whole screen
+  then scrolled sideways, and the control left outside was the one that signs a
+  viewer out: a box could not be left from a phone.
+
+  The header now wraps. On a narrow screen it takes a second row, and every
+  control stays reachable; a long box address or a long directory name wraps
+  with it instead of widening the row. Nothing changes on a wide screen — the
+  header is one row of the same height it always was.
+
+- 7131b87: New box keeps the environment you named, so a box can be rented again
+
+  Renting a box from the cabinet was impossible for anyone who used the
+  Environment field the way it asks to be used. Typing `prod` and pressing Enter
+  turned the name into a tag, as it should; submitting the form then answered
+  "Name what runs at this address — prod, staging, pr-42." and came back with
+  the field empty and the tag gone. The form was refusing the very name it had
+  just been given, and there was no way through it: the only path to a first box
+  through the cabinet was closed.
+
+  The tag the browser makes now travels under the name the server reads
+  environments back from. It had been travelling under the name of the text box
+  it was typed in, so a row with one tag arrived with an address and no names at
+  all, and the refusal about names was the server honestly reporting what it
+  received.
+
+  Two things beside the fix, so this class of failure is harder to repeat. The
+  name a tag posts under is stated once, in the form, and the browser reads it
+  from there rather than spelling it out a second time. And the reader on the
+  server now accepts either half of the field repeated — two tags on one address
+  have always arrived as a repeated field, and a reader that expects a single
+  value drops a repeated one whole rather than in part.
+
+  A form submitted with scripting off is unchanged: the typed name still posts on
+  its own, one name per submit.
+
+- e1db36f: `picker off` says how long the withdrawal takes, as one number
+
+  Switching the Picker off — a box's with `box picker off`, a project's with
+  `picker off` — withdraws its token through a revocation list that two
+  services read on their own schedules: the cloud rewrites the list, the
+  grounding service re-reads it. The command used to say only that the token
+  stops working "once the list is refreshed", because the CLI knew neither
+  interval and half a figure read as the whole would have been wrong.
+
+  The cloud now adds both halves and hands the sum over, and the command
+  says it:
+
+      ✓ The Picker token for this box is revoked — the grounder stops
+        accepting it within about 2 minutes, once it refreshes its
+        revocation list
+
+  The dashboard's own notices after switching off say the same figure. When
+  the cloud cannot name it — the grounding service has not answered yet —
+  the sentence stays as it was, with no number: a default would be a
+  promise nothing keeps.
+
+- 36d1dba: `bundle push --run --env` now names an environment the box will accept, and refuses one it cannot.
+
+  A box lists its environments as `<project>/<environment>`, and that is the
+  form its viewer API and every `box` subcommand take. The door that orders
+  runs takes the bare environment instead and fills the project in from the
+  token that pushed. The pre-upload check accepted both forms but carried
+  whichever was typed straight through, and a refusal advised the listed one
+  — so a push that followed our own advice was refused by the box after the
+  bundle had already been uploaded.
+
+  Both forms are still accepted, with one exception named below. Whichever is
+  given, the run is now ordered under the name the box runs, and a refusal
+  advises that same name.
+
+  On a box that serves several projects, a listed name is translated only
+  while the bare name it becomes belongs to one of them. Where two projects
+  share an environment name, the run would be ordered inside whichever
+  project your token belongs to — not necessarily the one you named — so the
+  push is refused before the upload instead, and the refusal names both:
+
+      ✗ "beta/prod" cannot be ordered by that name on
+        https://larch.box.unotest.com — nothing was uploaded.
+        acme/prod and beta/prod are both called "prod", and a run is
+        ordered by the bare name inside the project your token belongs
+        to — push with --env prod if that project is yours
+
+  A bare name several projects share is left as it was typed: that is the
+  form the box expects, and the token is what says which project it means.
+
+  None of this reaches a box that has not named an environment yet. A box
+  with nothing to list answers with an empty list, which does not prove it
+  serves nothing, so the push goes ahead and the box decides — exactly as
+  before. Until a suite has been pushed to it once, a wrong name is still
+  answered by the box after the upload, not by this check.
+
+- 5193108: The New box dialog closes again after the form has refused something
+
+  A dialog in the dashboard could be opened two ways and closed only one. The
+  Create box button opens it with a link to `#new-box`, and the × and the veil
+  close it by dropping that target again. A form the server refused comes back
+  open too — the refusal has to be visible — but that copy is opened by a class
+  in the served markup, and a link to `#` cannot take a class away. So anyone
+  who filled the form in, got a refusal, and reached for the × found the dialog
+  nailed open until they reloaded the page.
+
+  Closing now undoes whatever opened it. The dialog the button opened still
+  closes on the spot, with no request. The dialog a refusal opened closes by
+  going back to the boxes page — which has no refusal to keep it open — and the
+  × and the veil both carry that address. No script is involved in either case:
+  the dashboard is where boxes are bought, and it works with scripting off.
+
+  Closing after a refusal drops what was typed. That is the intended reading of
+  closing a form, and a draft that reappeared at the next click would be the
+  bigger surprise.
+
+  - @unotest/viewer@0.40.0
+  - @unotest/core@0.40.0
+  - @unotest/dsl@0.40.0
+  - @unotest/grounder-client@0.40.0
+  - @unotest/protocol@0.40.0
+
 ## [0.39.0] - 2026-09-18
 
 ### Minor Changes
@@ -66,7 +651,7 @@ picker on` fetches this project's own access and writes the three grounder
 
   That screen named one command:
 
-      npx @unotest/web bundle push --run --env ENVIRONMENT
+          npx @unotest/web bundle push --run --env ENVIRONMENT
 
   In a project that has just been created, the command refuses with `no box
 address` before it does anything: the project holds neither the box's address
@@ -75,8 +660,8 @@ address` before it does anything: the project holds neither the box's address
 
   The screen now names both steps, in the order they have to happen:
 
-      npx @unotest/web box access larch
-      npx @unotest/web bundle push --run --env ENVIRONMENT
+          npx @unotest/web box access larch
+          npx @unotest/web bundle push --run --env ENVIRONMENT
 
   The box's own name is filled in when its licence carries one. `box access`
   with no name refuses, and its refusal offers to create a box — to somebody who

package/README.md

@@ -171,7 +171,10 @@ has no price of its own — and the answer defaults to no. On a box you already
 this box's, which is left alone and reported. `off` also revokes the
 box's Picker token, so a copy of it on another machine stops working
 too: the grounder refuses it once it has re-read the operator's
-revocation list — how often it does that is the operator's own setting. Either way the charge follows at the
+revocation list, and `off` says how long that takes — "within about 2
+minutes" — whenever the cloud knows both halves of the wait. Where it
+does not, the sentence stays true and carries no figure rather than
+half of one. Either way the charge follows at the
 next hourly tick, because a started hour is charged at the rate it
 started with. `box status` says which state a box is in, and — while the
 Picker is on — which models the cloud grounds with: `Our GPU` or
@@ -250,13 +253,18 @@ run reads:
 
 ```sh
 npx @unotest/web env push dev                 # .env + .env.dev + .secrets + .secrets.dev
+npx @unotest/web env set dev REGION eu-west
 printf '%s' "$KEY" | npx @unotest/web env set dev API_KEY --secret
 ```
 
 `.env*` become the environment's variables, `.secrets*` its secrets,
-`APP_BASE_URL` its target; `UNOTEST_*` stay home. A value never prints.
-The token must be minted with `--values` on the box. Admins also see and
-change them on the box's admin page. Manual: [An environment's values on a
+`APP_BASE_URL` its target; `UNOTEST_*` stay home. A secret's value never
+prints; `env push --dry-run` shows what the other values resolved to. The
+box and the token come from the same places `bundle push` reads them
+from — flags, the environment, then `unotest/.env` and
+`unotest/.secrets` — and the token must be minted with `--values` on the
+box. Admins also see and change them on the box's admin page. Manual: [An
+environment's values on a
 box](https://docs.unotest.com/box/environments-and-values/).
 
 A run on the box happens inside the box's own container: nothing on your
@@ -306,6 +314,16 @@ file; `--box` and `--token` win over both.
 The token is never read from `unotest/.env` — that file travels inside a
 pushed bundle, and `.secrets` does not.
 
+`unotest/.secrets` is created owner-only (`0600`), so the tokens in it are
+not readable by other users of a shared machine. A file left wider by an
+earlier version is narrowed the next time a command writes to it, and the
+command says so once. Editing a secret in the viewer's variables panel
+keeps the same width. `unotest/.env` is configuration, not secrets, and
+keeps whatever width your project gave it.
+
+On Windows there are no POSIX permission bits, so nothing is narrowed there
+and no width is promised: protect the file with the tools your system has.
+
 Keeping it in the file is what lets your agent read runs: an MCP server is
 started by your editor, so a token that only exists in your shell is a
 token the agent never sees. A token added while the server is running is
@@ -317,7 +335,8 @@ hand you mint it for yourself on the box's guard, where it is shown once
 and can be revoked. Either way it is read-only whatever your role on the
 box — it cannot start a run or change a value. `UNOTEST_BOX_TOKEN` is the
 project's push credential and cannot read runs. `box envs` lists the
-environments a token may look at.
+environments the box serves — an empty list means the box has none yet,
+not that the token is too weak to see them.
 
 ## 5. Watch it run — the viewer