@monster-orange/den 0.4.20 → 0.4.22

package/CHANGELOG.md

@@ -4,6 +4,170 @@ All notable changes to Den are documented here. Each release lists the
 config and manifest changes a distribution must make to move to it under
 **Migrations**.
 
+## [0.4.22] - 2026-11-10
+
+### Added
+
+- **Opt-in: agents meant to keep running across logout (D18, D20).**
+  `service install --mode always` installs the web server and the session
+  host as LaunchDaemons that run as you (`UserName`): they start at boot
+  and are meant to keep running when you log out of the desktop, and so
+  every terminal and agent. It is not yet proven across a logout: `service
+  help`, `--plan`, install, `doctor` and the agents page say so. It takes your admin password once (sudo); `--mode login`, the
+  default, keeps LaunchAgents in the desktop session (they stop at
+  logout). Without `--mode`, install keeps the mode already installed.
+  Switching removes the other mode's jobs.
+- **The session host is its own launchd job** (`<label>` with `.web` →
+  `.sessions`), in both modes, so it runs in the mode's session whoever
+  starts the first terminal: before, it inherited the launchd session of
+  whatever started it, and one started from the desktop ended at logout
+  with every agent in it. `<cli> sessions` and agents wait for the job.
+- **Full Disk Access for Den, not for every node program.** The host job
+  runs a copy of node Den owns, `<stateDir>/bin/<cli>-sessions-host`
+  (0700), the path to grant Full Disk Access to (protected folders: other
+  volumes, Desktop, Documents); agents inherit it. Install refreshes the
+  copy when node changes and says when the grant must be given again (a
+  new signer, an ad-hoc signed node). A node that can't be copied
+  (Homebrew's) is run directly, and install says so.
+- **Where it runs, shown honestly.** Every session records the launchd
+  session its host ran in (`launchctl managername`). The Agents page tags
+  each agent **Stops at logout** (the desktop session; tap for the fix) or
+  **No GUI** (kept across logout: no login keychain, no GUI apps; 1Password
+  through the service-account token, headless browsers, Full Disk Access
+  for protected folders). `doctor` ends with **where it runs**: the
+  server's and the host's session, Full Disk Access and the path to grant,
+  and the service's mode. `web up` from an ssh (Background) shell says what
+  a server started there means.
+- **Rename, visible (D25).** **Rename…** in an agent pane's ⋯ menu and
+  **Rename** on a stopped agent's row, by touch or keyboard, and
+  `<cli> agents rename <id> <name>` (`--clear`: back to its id). Before,
+  only a double-click on an open tab renamed one.
+- **Agents tell apart in a list of sessions (D24).** Den names each
+  Claude Code agent's session `<cli>-<ws>:<name, else id>` (`--name`) at
+  start and resume, so another session listing its peers sees which agent
+  is which, not a generic name. A rename shows at its next start or resume.
+
+### Fixed
+
+- **`service install` said running while its job crash-looped (D26).** A
+  plain `web up` server of the same install on the port answered the
+  check, while the job failed to start on the taken port. Install now
+  stops a plain server of this install first, and says running only when
+  the server answering is the job's own process; `service status` says
+  when another process holds the port. `--plan` says when install would
+  stop one.
+- **`service status` names a job whose plist is present but not loaded**,
+  with the `launchctl bootstrap` that loads it (`sudo` for a LaunchDaemon);
+  `doctor` shows it too.
+- **Tests never reach this machine's launchctl, gh or vendor CLIs**, even
+  through a spawn without `env`: the inert stand-ins are now first on the
+  real PATH (jest's globalSetup), not only on each test file's sandboxed
+  `process.env`.
+
+### Migrations
+
+- None required. An existing install keeps its mode (login). To try
+  keeping agents running across logout (not yet proven), run
+  `<cli> service install --mode always` once (one sudo), then grant Full
+  Disk Access to the path `doctor` names if agents read protected folders.
+- `<cli> service` with no subcommand prints its help (before, an error).
+
+## [0.4.21] - 2026-11-09
+
+### Added
+
+- **Every developer connects GitHub from the browser (D17).** A company
+  makes its own Den repo, every developer runs their own instance, and
+  everyone opens the same edge URL (such as `https://den.local.<zone>`,
+  whose DNS says 127.0.0.1). Before, they all got the signed-out page with
+  no way in from the browser: behind Docker Desktop, OrbStack or a TCP
+  passthrough the edge sees a gateway's address, so Den couldn't tell a
+  browser on its own machine; the one-time link needed a terminal, pairing
+  needed Settings, and Sign in with GitHub needed an owner already linked.
+  Now, while an instance has no owner, the signed-out page leads with
+  **Connect your GitHub account**:
+  - **This is my computer** (for a member of `web.allowed_github_org`):
+    a top-level round trip through `http://localhost:<port>/attest`, which
+    only a browser on this machine reaches, back to the edge page with a
+    short-lived, single-use code bound to that edge hostname and signed
+    with `web.secret` (in the URL fragment, never logged; only to this
+    Den's own edge hostnames). The GitHub sign-in that follows makes a
+    member of the org the owner and signs the browser in. The proof alone
+    never makes a session (any program on the machine can reach
+    localhost), so the GitHub approval is always the person's.
+  - **Sign in as @login** (`web.owner_github`): that login claims it from
+    any browser, such as a laptop reaching a devbox.
+  - Anyone else is refused with the reason (not a member; a member but not
+    on this computer; not that login; a private membership the GitHub App
+    can't read, naming the fix). With neither set, the page names both
+    settings and offers no claim.
+- **`create --github-org <org>`** writes `web.allowed_github_org` into the
+  team config; without the flag it uses the GitHub owner of the repo the
+  new folder is in, else writes a commented line and says to set it
+  (`create --json`: `githubOrg`, null when unknown).
+- **`web up`, `web restart` and `service install` record
+  `web.owner_github`** in `config/local/user.yml` from `gh api user` when
+  `gh` is signed in, no owner is linked and it isn't set, and print it.
+  When `gh` isn't signed in, they and `doctor` say so, with the fix
+  (`gh auth login`, or set `web.owner_github`).
+- **doctor** shows who may claim the instance (`web:owner` in
+  `doctor --json`), and fails when there is no owner, neither setting, and
+  the edge is reachable from other machines.
+- **`web.login_link_ttl` (D16)**: how long a sign-in link lasts, 5 minutes
+  unless set (it was 60 s, and expired while people switched windows);
+  30s to 60m. `web login` shows the time left while it waits.
+
+### Fixed
+
+- doctor no longer shows `usage (invalid config) ✗ unavailable: no selector
+  for this kind` on every fresh install (D9). Usage sources are all read at
+  once, so the row names them (`claude-code (implicit)`), as any strategy
+  kind with no selector of its own now does; never a failure. The state
+  column lines up past 20 characters.
+- **Every page was broken for a distribution whose name has a hyphen**
+  (`acme-den`), since 0.4.20 at least. `header.js` put the
+  `__DEN_CLI__` placeholder inside a variable name, so the served file
+  read `let _acme-denConfig`, a syntax error: no page mounted anything,
+  the signed-out page included ("Error / local"), and Settings showed an
+  error. A new check fills every served page and script with hyphenated,
+  digit-bearing and short names and parses each one, and no placeholder
+  may touch a name's letters.
+- `/attest` reached through the edge shows its own "only on the computer
+  this Den runs on" page, not the generic signed-out one.
+- doctor, when `web.owner_github` isn't set but `gh` is signed in, says to
+  run `web restart` to record it (not that gh isn't signed in).
+
+### Changed
+
+- The sign-in smoke runs against a remote browser with `DEN_PW_WS` (a
+  Playwright run-server): WebKit from Playwright's Linux image when the
+  shell can't start a GUI app (CONTRIBUTING.md).
+- The GitHub code on the sign-in page has its copy button right beside it,
+  on its line (as every command on that page), at any width.
+- Tests put a stub `launchctl` first on PATH, as for gh and the agent
+  CLIs: no test can reach this machine's real launchd.
+- Pages, `--version`, doctor and the server agent's name say the brand's
+  name (`brand.name` in the org config: "Sign in to Acme Den"), not the CLI
+  name upper-cased ("Acme-den") (D11). A `brand.name` with characters that
+  could break a page (quotes, `&`, `<`) falls back to the old title.
+- `product.cli` in den.yml must be lower-case letters, digits and `-`,
+  starting with a letter (as `product.name`). `product.config`,
+  `manifest`, `services_dir` and `workspaces_dir` may use letters, digits,
+  `.`, `_`, `-` and `/` only: the pages carry these names, and a quote or
+  `$` would break their scripts. A value outside that is refused at start,
+  naming the key.
+- The page behind a `web login` link that asks for its code is a plain
+  sign-in page: no shell frame and no request id, the code field focused.
+
+### Migrations
+
+- A `product.cli` or product path outside the characters above now stops
+  the CLI and server with a message naming the key: rename it.
+- To let your team connect GitHub from the browser, set
+  `web.allowed_github_org: <your GitHub org>` in the team config (or run
+  `web up` with `gh` signed in, for `web.owner_github`). The GitHub App
+  needs the org's Members (read) permission to see private memberships.
+
 ## [0.4.20] - 2026-11-09
 
 ### Added

package/README.md

@@ -10,8 +10,8 @@
 </p>
 
 <picture>
-  <source media="(prefers-color-scheme: dark)" srcset="docs/images/0.4.20/hero-dark.png">
-  <img src="docs/images/0.4.20/hero-light.png" width="100%" alt="Den's Graph page: the demo workspace's services grouped by application, all healthy, with the status chip and the left rail">
+  <source media="(prefers-color-scheme: dark)" srcset="docs/images/0.4.21/hero-dark.png">
+  <img src="docs/images/0.4.21/hero-light.png" width="100%" alt="Den's Graph page: the demo workspace's services grouped by application, all healthy, with the status chip and the left rail">
 </picture>
 
 ## Set up by your agent
@@ -39,7 +39,7 @@ It doesn't replace your tools. Your repos, Docker, your test runners, your secre
 yours. Den connects them and turns on good practice from the start.
 
 <p align="center">
-  <img src="docs/images/0.4.20/up.gif" width="100%" alt="make up in the Graph page: every stack down, then demo-api, demo-web and demo-notes come up in dependency order until the status chip reads All 3 healthy">
+  <img src="docs/images/0.4.21/up.gif" width="100%" alt="make up in the Graph page: every stack down, then demo-api, demo-web and demo-notes come up in dependency order until the status chip reads All 3 healthy">
 </p>
 
 ## How it helps
@@ -69,10 +69,10 @@ yours. Den connects them and turns on good practice from the start.
   lives in your own repo.
 
 <p align="center">
-  <img src="docs/images/0.4.20/agents.png" width="49%" alt="The Agents tab: the demo workspace's sessions on the left, and one open in a terminal pane on the right, running demo-api's test and then the service">
-  <img src="docs/images/0.4.20/workspaces.png" width="49%" alt="The Workspaces page: the demo workspace's repos with their health, mode and Start, Stop, Restart and Logs actions">
-  <img src="docs/images/0.4.20/status-drawer.png" width="49%" alt="The status drawer: nothing needs attention, and every service in the demo workspace, by application, with its latency">
-  <img src="docs/images/0.4.20/edge.png" width="49%" alt="The Edge page: the edge container up, its ports and TLS, and every route it serves, Den's own and each stack's, with its upstream">
+  <img src="docs/images/0.4.21/agents.png" width="49%" alt="The Agents tab: the demo workspace's sessions on the left, and one open in a terminal pane on the right, running demo-api's test and then the service">
+  <img src="docs/images/0.4.21/workspaces.png" width="49%" alt="The Workspaces page: the demo workspace's repos with their health, mode and Start, Stop, Restart and Logs actions">
+  <img src="docs/images/0.4.21/status-drawer.png" width="49%" alt="The status drawer: nothing needs attention, and every service in the demo workspace, by application, with its latency">
+  <img src="docs/images/0.4.21/edge.png" width="49%" alt="The Edge page: the edge container up, its ports and TLS, and every route it serves, Den's own and each stack's, with its upstream">
 </p>
 
 ## Get started

package/docs/distributions.md

@@ -1004,15 +1004,21 @@ brand:
     - "  └───────────┘"
 ```
 
-| Field     | Used for                                                                     |
-| --------- | ---------------------------------------------------------------------------- |
-| `name`    | Web page `<title>`s, the banner fallback, the web route on the edge (`acme`) |
-| `tagline` | The line under the banner                                                    |
-| `banner`  | The CLI and web server startup banner                                        |
+| Field     | Used for                                                                                                                                                                 |
+| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `name`    | The name people see: page titles and copy ("Sign in to Acme Den"), `--version`, doctor, the server agent's name, the banner fallback, the web route on the edge (`acme`) |
+| `tagline` | The line under the banner                                                                                                                                                |
+| `banner`  | The CLI and web server startup banner                                                                                                                                    |
 
 Runtime names (env vars, files, directories) always come from `den.yml`,
 never from the brand.
 
+`brand.name` is used in pages and messages only when it is letters, digits,
+spaces, `.`, `_` and `-` (up to 40, starting with a letter or digit), so
+it can't break a page. Anything else (a quote, `&`, `<`) falls back to the
+product name with its first letter upper-cased ("Acme-den"); the page
+`<title>` still shows it.
+
 ## Plugins
 
 A plugin adds to Den without changing it: a theme, a page in the web UI, and
@@ -1613,7 +1619,10 @@ user, and the CLI does that for you:
 
 - **The link** is `http://localhost:<port>/auth?c=<code>`, with `&next=<path>`
   for where to land (`web login --next /settings`). The code works once,
-  within 60 seconds, and only this server's secret makes one. It is printed
+  within `web.login_link_ttl` (5 minutes unless set; 30s to 60m, as `90s`,
+  `5m` or `1h`, in `config/local/user.yml` or the team config), and only
+  this server's secret makes one. `web login` shows the time left while it
+  waits, on a terminal. It is printed
   only on the one line you asked for (`web login`, or `web up` when it
   couldn't open the browser), never logged. Through the edge or a LAN name,
   the cookie belongs to that name: `web login --host acme.acme.localhost`
@@ -1853,7 +1862,8 @@ the account's id and login, never a token, and no other account gets in.
   last seen; "This device" on yours), each with **Revoke**, which ends its session at once (its
   open terminals included). **Pair a device** makes a one-time link and a
   QR code for an edge hostname you pick (`web login --host <name>` in the
-  browser): scan it on the other device within 60 seconds.
+  browser): scan it on the other device before it expires
+  (`web.login_link_ttl`; the page counts down).
 - **`web.github_client_id`** is the GitHub App's client id (public; no
   secret). The default is Den's own App, **Monster Orange Den**
   (`Iv23liKL12gnN6WvRV5b`), so Sign in with GitHub works out of the box. A
@@ -1868,6 +1878,61 @@ the account's id and login, never a token, and no other account gets in.
   it never prints the token. `GET /api/web/owner` reports it as
   `tokenExpiry: true`.
 
+### A company's Den: every developer connects GitHub from the browser
+
+The common shape: a company makes its own Den repo (`create`), pushes it to
+its GitHub org, and every developer clones it and runs their own instance
+on their own machine. Everyone opens the same URL (an edge name such as
+`https://den.local.<your zone>`, whose DNS says 127.0.0.1) and connects
+their GitHub account there, with no terminal and nothing to explain.
+
+```yaml
+# config/<name>.yml (the team's, committed): who may claim an instance
+web:
+  allowed_github_org: acme
+```
+
+- **`create` writes it**: `--github-org <org>`, else the GitHub owner of the
+  repo the new folder is in. Neither: a commented line and a next step.
+- **`web.owner_github`** (`config/local/user.yml`, per machine) is the
+  GitHub login of whoever runs this instance. `web up`, `web restart` and
+  `service install` record it from `gh` (`gh api user`) when `gh` is signed
+  in, no owner is linked and it isn't set, and print it. Only the login is
+  kept. This is the path most people take: org memberships are private
+  by default. When `gh` isn't signed in, `web up` and `doctor` say so,
+  with the fix (`gh auth login`, then `web restart`; or set
+  `web.owner_github` yourself).
+- **The signed-out page leads with Connect your GitHub account** while the
+  instance has no owner and one of the two is set. Who may claim it:
+  - **A member of `allowed_github_org`, on this computer.** **This is my
+    computer** navigates to `http://localhost:<port>/attest` and straight
+    back: only a browser on the machine Den runs on reaches it there. It
+    returns with a short-lived (2 minutes), single-use code, signed with
+    `web.secret`, bound to the edge hostname, in the URL fragment (never
+    sent to a server or logged), and only to one of this Den's own edge
+    hostnames. The page then starts Sign in with GitHub with it; when
+    GitHub says the account is a member of the org, it becomes the owner
+    and the browser is signed in. This exists because Docker Desktop,
+    OrbStack and a TCP passthrough show the edge a gateway's address, so
+    Den can't tell a browser on its own machine from another one.
+  - **`owner_github`'s login, from any browser** (a devbox you reach from a
+    laptop).
+  - **Anyone else is refused, with the reason**: not a member of the org;
+    a member, but not on this computer; not the login `owner_github` names.
+    The proof alone never signs a browser in: any program on the machine
+    can reach localhost, so the GitHub approval is always the person's.
+- **Membership.** Den asks GitHub with the sign-in's own token: the
+  account's own membership (`GET /user/memberships/orgs/<org>`, which needs
+  the App to have the org's Members (read) permission), then the public
+  member list. A private membership the App can't read is refused, saying
+  so: make the membership public, give the App that permission, or set
+  `web.owner_github`.
+- **Neither set**: the page names both settings and offers no claim.
+  `doctor` shows who may claim the instance, and fails (✗) when neither is
+  set and the edge is reachable from other machines.
+- Once claimed, it is an ordinary owner: Sign in with GitHub from any
+  browser, as above.
+
 ### The GitHub App (once, by whoever ships the Den)
 
 Den's default App is Monster Orange Den. A distribution that wants its own
@@ -1892,16 +1957,88 @@ Apps › New GitHub App):
 
 ## Running the web UI as a service (macOS)
 
-Den ships a launchd installer that runs the web UI at login and restarts it if
-it exits:
+Den ships a launchd installer that runs the web UI and the session host (every
+terminal and agent) as launchd jobs, restarted if they exit:
 
 ```bash
-./bin/acme service install     # install (or refresh) and start it
+./bin/acme service install                # install (or refresh) and start them
+./bin/acme service install --mode always  # meant to keep them running across logout (opt-in, not yet proven)
 ./bin/acme service install --plan  # what install would do; writes and loads nothing
 ./bin/acme service status      # launchd's view: state, pid, last exit code
-./bin/acme service print       # the LaunchAgent plist it would install; installs nothing
-./bin/acme service uninstall   # stop it and remove the LaunchAgent
-```
+./bin/acme service print       # the web plist it would install; installs nothing
+./bin/acme service uninstall   # stop them and remove their plists
+```
+
+### Login or always
+
+| `--mode`          | Jobs                                                  | At logout                            |
+| ----------------- | ----------------------------------------------------- | ------------------------------------ |
+| `login` (default) | LaunchAgents in the desktop session (`gui/<uid>`)     | stop, with every agent               |
+| `always`          | LaunchDaemons that run as you (`UserName`), from boot | meant to keep running, and so agents |
+
+`always` is opt-in and not yet proven across a logout: no logout has
+shown it keeping an agent on the same conversation yet. Use `login` unless
+you are testing it.
+
+`always` takes your admin password once (sudo writes and loads the
+LaunchDaemons in `/Library/LaunchDaemons`); it is never asked for again.
+Without `--mode`, install keeps the mode already installed, so re-running it
+after an upgrade never changes it. Switching mode removes the other mode's
+jobs: never both. Use `always` on a machine you reach from elsewhere (ssh, a
+browser on another machine); `login` on a laptop.
+
+A process outside the desktop session has no login keychain and no GUI. So
+under `always`, agents use:
+
+- **1Password**: the service-account token (`secrets.onepassword.token`),
+  not the desktop app. `doctor` warns when this process has none.
+- **Browsers**: headless Chromium and Firefox. WebKit on macOS needs a
+  desktop session; run it from Playwright's Linux image instead
+  (CONTRIBUTING.md, `DEN_PW_WS`).
+- **Protected folders** (other volumes, Desktop, Documents): Full Disk
+  Access, granted once (below).
+
+Each session records the launchd session its host ran in, and the Agents page
+tags it: **Stops at logout** (the desktop session; tap it for the fix) or
+**No GUI** (kept across logout). `web up` from an ssh shell (a Background
+session) says the same before it starts a server there.
+
+### The session host job and Full Disk Access
+
+Both modes install the session host as its own job, `<label>` with `.web`
+replaced by `.sessions` (`local.acme.sessions`), so it runs in the mode's
+session whoever starts the first terminal; `<cli> sessions` and agents then
+wait for it rather than starting a host in the caller's session. It runs a
+copy of node Den owns, `<stateDir>/bin/<cli>-sessions-host` (0700), and
+macOS grants Full Disk Access to that path: never to the shared node, which
+would give it to every node program. To grant it: System Settings → Privacy &
+Security → Full Disk Access → + → that path (⌘⇧G to type it), then
+`<cli> sessions host --stop` (it restarts with the grant). Agents inherit it.
+
+Install refreshes the copy when node changes. An official node build
+(nodejs.org, nvm) is signed by the Node.js project, so the grant holds across
+upgrades; install says when the signer changed and it must be granted again.
+An ad-hoc signed node needs a new grant after every change, and Homebrew's
+node loads libraries beside it and can't be copied: install then runs it
+directly and says so. `doctor` shows whether the host has Full Disk Access,
+and the path to grant.
+
+### What doctor shows
+
+`doctor` ends with **where it runs**: the web server's and the session host's
+launchd session (a warning with the fix when it stops at logout), Full Disk
+Access, and the service: its mode, or `plist present, job not loaded:
+launchctl bootstrap <domain> <plist>` (`sudo` for a LaunchDaemon) when launchd
+has dropped a job whose plist is still there.
+
+### Running means the job's own process
+
+A plain `web up` server of the same install on the port would answer for the
+job, which then fails to start on the taken port and restarts forever. So
+install stops a plain server of this install first (and says so), and says
+`running` only when the server answering is the job's own process (its pid is
+launchd's). Otherwise it says `port <N> is served by pid <P>, not the job`
+and exits 1; `status` says the same.
 
 The label and log directory come from the org config:
 
@@ -1946,12 +2083,14 @@ node_modules/@monster-orange/den/service/install.sh uninstall
 node_modules/@monster-orange/den/service/install.sh print       # the plist only
 ```
 
-| Variable            | Default                                  |
-| ------------------- | ---------------------------------------- |
-| `DEN_ROOT`          | required in a distribution               |
-| `DEN_SERVICE_LABEL` | `local.<distribution dir name>.web`      |
-| `DEN_SERVICE_LOGS`  | `~/Library/Logs/<distribution dir name>` |
-| `DEN_SERVICE_NODE`  | see below                                |
+| Variable               | Default                                                                 |
+| ---------------------- | ----------------------------------------------------------------------- |
+| `DEN_ROOT`             | required in a distribution                                              |
+| `DEN_SERVICE_LABEL`    | `local.<distribution dir name>.web`                                     |
+| `DEN_SERVICE_LOGS`     | `~/Library/Logs/<distribution dir name>`                                |
+| `DEN_SERVICE_NODE`     | see below                                                               |
+| `DEN_SERVICE_MODE`     | `login` (or `always`)                                                   |
+| `DEN_SERVICE_HOST_EXE` | none: the host runs that node (`<cli> service install` sets Den's copy) |
 
 The service runs the engine's server, from the distribution root, with the
 `node` on your `PATH` at install time. A version manager's node (nvm, fnm,
@@ -2430,6 +2569,15 @@ server scoped to its workspace.
   start and resume answers). 0.4.12 sent the name shown as `sessionName`;
   read `sessionTitle` instead. Records are unchanged, so none written
   before needs migrating.
+- **Renaming.** `agents rename <id> <name>` (or `--clear`, back to its
+  id) names an agent; so do **Rename…** in its pane's ⋯ menu and **Rename**
+  on a stopped agent's row, by touch or keyboard, as well as a double-click
+  on its tab. The id never changes.
+- **The name other sessions see.** Den names a Claude Code agent's session
+  `<cli>-<ws>:<name, else id>` (`--name`) at every start and resume, so
+  another session listing its peers tells Den's agents apart. A rename
+  shows at its next start or resume. The record's `peerName` is the name
+  last given, so reading it back is never taken for a `/rename`.
 - `list` shows agents only: sessions with an agent record. A session from
   `sessions start` is not an agent; `sessions list` shows it.
 - `stop` sends its session TERM and marks it stopped. `resume` works only

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@monster-orange/den",
-  "version": "0.4.20",
+  "version": "0.4.22",
   "description": "Den: a local multi-repo dev orchestrator, HTTPS edge and E2E harness",
   "type": "module",
   "bin": {