@unotest/viewer 0.26.0 → 0.27.0

package/CHANGELOG.md

@@ -1,5 +1,135 @@
 # Changelog
 
+## [0.27.0] - 2026-08-31
+
+### Minor Changes
+
+- The server boots quietly: Nest's per-module / per-route boot log is
+  gone from normal runs — the launcher's one useful line is the URL.
+  `UNOTEST_DEBUG` brings the full boot map back.
+
+- The LOCAL schedule registry now shows the EFFECTIVE merged set too:
+  both store flavours read through one `EffectiveSchedulesReader`
+  (`schedules --json` across a process boundary), so config-declared
+  entries appear locally, stamped `source: "config"` and opened as a
+  read-only card ("declared in `unotest.config` — edit it there");
+  yaml entries stay editable. A PUT carries only the file half and
+  answers with the re-merged whole (`SchedulesView` for both verbs);
+  the envelope gains `driftedFromPush` — on a box, true when the set
+  read there hashes differently from the fingerprint recorded at push,
+  shown as a warning line in Home schedule mode. The local schedule
+  mode gets its own caption: "declared here — a box runs what you
+  push". Runners without a schedules command fall back to the yaml
+  half, unchanged.
+
+- The schedule registry on a deployed tree (a box environment) is now
+  the EFFECTIVE merged set, read-only. `GET /api/schedules` returns
+  `{ schedules, readOnly }`; on a box the entries come from the
+  project's own CLI (`schedules --json` via the runner adapter's new
+  `schedulesArgs()`), so config-declared schedules are no longer
+  invisible in the UI. The Schedule popup becomes a read-only card with
+  a provenance note ("declared in the repo — edit there and push"), the
+  Home schedule mode shows a matching badge, and `PUT /api/schedules`
+  is refused with 403: on a box that write used to land in a disposable
+  bundle copy nothing ever re-read. Local viewers are unchanged —
+  editing the file is still the workflow there.
+
+- c843d21: Schedules from the viewer — for collections and single tests.
+
+  Right-click a test or a collection in the viewer → **Schedule…**: a
+  human schedule builder (frequency select — every 5/15 min, hourly,
+  every 2/4/6/12 h, daily, weekly — plus toggle badges for minutes,
+  hours and weekdays; multi-select, so `04` + `16` × `00` + `30` runs
+  four times a day). Saved to `unotest/schedules.yaml`, versioned next
+  to the tests; a box applies it after commit & sync. The Home screen
+  gains a `last run | schedule` toggle: in schedule mode tiles are
+  tinted by how often a test runs (grey = not scheduled), with an
+  upcoming list and per-tile next-run times in your browser's clock.
+
+  Under the hood:
+
+  - `unotest/schedules.yaml` is a new schedule registry; `unotest-web
+schedules [--json]` prints it merged with the config's `schedules`
+    (the file wins on a duplicate target), so boxes pick both up
+    unchanged.
+  - A schedule entry may now target a single test: `scenario:
+<ref>` instead of `collection: <name>`.
+  - `unotest-web e2e <name> --scheduled[=index]` runs a test the way its
+    entry says (env + prepare, exit 94 when prepare fails) — the
+    per-test mirror of `collection --scheduled`.
+  - Viewer server: `GET/PUT /api/schedules` (validated by the same
+    parser the CLI reads the file with).
+
+### Patch Changes
+
+- Updated dependencies [c843d21]
+  - @unotest/protocol@0.27.0
+  - @unotest/core@0.27.0
+  - @unotest/dsl@0.27.0
+
+## [0.26.1] - 2026-08-30
+
+### Patch Changes
+
+- Fix: a run started from a box's viewer stayed pending and never reached
+  the history
+
+  The viewer watched the run directories of environments it could see on
+  disk — overlay files `unotest/.env.<name>` and existing `.runs.<name>`
+  directories. A box has neither at start: environment values come from the
+  daemon, not from a file, and the runs directory appears with the first
+  run. So the viewer watched only the base root while every run was filed
+  under `.runs.<environment>`: the tab stayed PENDING, the history stayed
+  empty and the run 404-ed by its own id, until a restart happened to find
+  the directory already there. The environment a viewer was started for is
+  now known to it by definition, whatever the disk says.
+
+- Fix: a run's captured output landed outside the run's directory
+
+  `stdout.log` / `stderr.log` were written to `<runs-root>/<runId>/` while
+  the run itself lives under its date shard — two orphan directories next to
+  the shard, holding the only copy of what the child said.
+
+- Fix: a viewer started for an environment listed no runs at all
+
+  The standalone launcher read the project root, the port, the host and the
+  target from its environment — but not `UNOTEST_ENV`. A box starts one
+  viewer per environment and names it exactly that way, so every one of them
+  came up on the BASE runs directory while its runs were being filed under
+  `.runs.<environment>`: an empty history on a box that had just finished a
+  suite. Found on the first end-to-end run of the local box stand.
+
+- 9424f6b: Fix: screenshots stayed blank in the viewer when runs write to a separate
+  artifact root
+
+  A run whose artifacts do not live under the working directory — every run on
+  a box, where the sources are a disposable copy of a test bundle — emitted
+  `screenshot` events whose path was relativised against the working directory.
+  That came out as `../../../…`, which the viewer's asset route refuses to
+  serve, so every step preview rendered as a broken image. Artifact paths are
+  now relative to the artifact root, which is still the project root on every
+  local run.
+
+  The failure bundle had the mirror-image problem: it was written to
+  `.unotest/failures/` under the working directory, so on a box it landed
+  inside the bundle copy — outside the tree the viewer serves, and discarded on
+  the next bundle push. It now hangs off the artifact root too, which leaves
+  local runs byte-for-byte unchanged.
+
+  The inspector's Semantic DOM, Console, Network and Snapshot panes were dark
+  for a third reason, and this one bit local runs as well: they composed the
+  run's directory in the browser and left out the date shard runs have been
+  filed under since M-10, plus the environment suffix on a box. The viewer's
+  asset route now takes `?file=<name-relative-to-the-run-dir>` and resolves the
+  directory itself — runs root, target suffix, environment suffix and shard are
+  all things only the server knows. `?path=` stays for the whole paths the
+  server ships on run events.
+
+- Updated dependencies [9424f6b]
+  - @unotest/protocol@0.26.1
+  - @unotest/core@0.26.1
+  - @unotest/dsl@0.26.1
+
 ## [0.26.0] - 2026-08-30
 
 ### Minor Changes

package/dist/server/main.d.ts

@@ -73,6 +73,14 @@ declare function startViewerServer(opts: StartViewerOptions): Promise<ViewerHand
  *  the installed `@unotest/*` runner packages (by name — DIP boundary
  *  intact). `UNOTEST_RUNNER_PKG` (legacy single-runner var) and
  *  `UNOTEST_TARGET` just pick which detected target is active at boot. */
+/** Everything the standalone launcher reads from its environment, in one
+ *  pure place so the plumbing is testable without starting a server.
+ *
+ *  `activeEnv` is the one that has bitten: a box starts one viewer per
+ *  environment and says which through `UNOTEST_ENV`. Dropping it left every
+ *  viewer reading the BASE runs directory while its runs were filed under
+ *  `.runs.<env>` — an empty history on a box that had just run a suite. */
+declare function viewerCliOptions(env: NodeJS.ProcessEnv, cwd: string): Omit<StartViewerOptions, "runners">;
 declare function runViewerCli(): Promise<void>;
 
-export { type RunnerEntry, type StartViewerOptions, type ViewerHandle, runViewerCli, startViewerServer };
+export { type RunnerEntry, type StartViewerOptions, type ViewerHandle, runViewerCli, startViewerServer, viewerCliOptions };