@lamalibre/create-lamaste 4.1.0 → 4.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lamalibre/create-lamaste",
-  "version": "4.1.0",
+  "version": "4.2.0",
   "description": "One-command setup for secure reverse tunnels with a management dashboard",
   "type": "module",
   "license": "SEE LICENSE IN LICENSE.md",
@@ -43,7 +43,7 @@
     "mtls"
   ],
   "dependencies": {
-    "@lamalibre/lamaste": "^4.1.0",
+    "@lamalibre/lamaste": "^4.2.0",
     "chalk": "^5.3.0",
     "execa": "^9.0.0",
     "listr2": "^8.0.0"

package/vendor/docs/00-introduction/how-it-works.md

@@ -55,14 +55,14 @@ SSH into a fresh Ubuntu droplet and run one command:
 
 ```bash
 apt install -y npm
-npx @lamalibre/create-lamaste@4.1.0
+npx @lamalibre/create-lamaste@4.2.0
 ```
 
 This installs everything the relay needs: nginx, Node.js, firewall rules, certificates, and the management panel. At the end, it prints a client certificate file and password. You download the certificate, import it into your browser, and disconnect SSH. You never SSH in again.
 
 **Option B: Desktop app (cloud provisioning)**
 
-Install the desktop app (`npx @lamalibre/create-lamaste-desktop@4.1.0`) and use the Servers tab to create a DigitalOcean droplet. The app handles everything — droplet creation, Lamaste installation, certificate download, and connection — without you ever touching SSH. Cloud API tokens are stored in your OS credential store (macOS Keychain or Linux libsecret), never in plaintext. See the [Cloud Provisioning guide](../02-guides/cloud-provisioning.md) for a step-by-step walkthrough.
+Install the desktop app (`npx @lamalibre/create-lamaste-desktop@4.2.0`) and use the Servers tab to create a DigitalOcean droplet. The app handles everything — droplet creation, Lamaste installation, certificate download, and connection — without you ever touching SSH. Cloud API tokens are stored in your OS credential store (macOS Keychain or Linux libsecret), never in plaintext. See the [Cloud Provisioning guide](../02-guides/cloud-provisioning.md) for a step-by-step walkthrough.
 
 **Phase 2: Onboarding (10 minutes, browser)**
 

package/vendor/docs/00-introduction/quickstart.md

@@ -59,7 +59,7 @@ Once connected:
 
 ```bash
 apt install -y npm
-npx @lamalibre/create-lamaste@4.1.0
+npx @lamalibre/create-lamaste@4.2.0
 ```
 
 The installer displays a confirmation banner showing what it will do:
@@ -253,7 +253,7 @@ Every tunnel is carried by one **agent** — the machine that runs the app. Enro
 Install the Lamaste Desktop app, which provides a GUI with automatic service discovery and one-click tunnel creation:
 
 ```bash
-npx @lamalibre/create-lamaste-desktop@4.1.0
+npx @lamalibre/create-lamaste-desktop@4.2.0
 ```
 
 The app auto-detects local services (Ollama, ComfyUI, PostgreSQL, Docker containers, etc.) and lets you expose them with one click. See the [Desktop App Setup](../02-guides/desktop-app-setup.md) guide for details.
@@ -263,7 +263,7 @@ The app auto-detects local services (Ollama, ComfyUI, PostgreSQL, Docker contain
 In the panel, go to **Certificates → Enrollment Token** and create a token for a label such as `laptop`. Then, on the machine that runs your app, install the agent globally and run setup:
 
 ```bash
-npm install -g @lamalibre/lamaste-agent@4.1.0
+npm install -g @lamalibre/lamaste-agent@4.2.0
 LAMALIBRE_LAMASTE_ENROLLMENT_TOKEN=<token> \
   lamaste-agent setup --label laptop --panel-url https://203.0.113.42:9292
 ```
@@ -345,7 +345,7 @@ Your Mac                          DigitalOcean Droplet            Internet
 The installer accepts optional flags:
 
 ```bash
-npx @lamalibre/create-lamaste@4.1.0 [flags]
+npx @lamalibre/create-lamaste@4.2.0 [flags]
 ```
 
 | Flag            | Effect                                          |
@@ -435,7 +435,7 @@ In development mode (`NODE_ENV=development` or `NODE_ENV` unset), the panel serv
 # 2. SSH in and install
 ssh root@203.0.113.42
 apt install -y npm
-npx @lamalibre/create-lamaste@4.1.0
+npx @lamalibre/create-lamaste@4.2.0
 
 # 3. Download cert (from your local machine)
 scp root@203.0.113.42:/etc/lamalibre/lamaste/pki/client.p12 .

package/vendor/docs/00-introduction/what-is-lamaste.md

@@ -36,7 +36,7 @@ Lamaste solves the problem of exposing local services to the internet securely.
 **Option A: Manual setup (SSH)**
 
 1. Create a fresh Ubuntu 24.04 droplet on DigitalOcean
-2. SSH in once and run `npx @lamalibre/create-lamaste@4.1.0`
+2. SSH in once and run `npx @lamalibre/create-lamaste@4.2.0`
 3. Download the client certificate it prints
 4. Import the certificate into your browser
 5. Open `https://<droplet-ip>:9292` — you are in the admin panel
@@ -46,7 +46,7 @@ Lamaste solves the problem of exposing local services to the internet securely.
 
 **Option B: Desktop app cloud provisioning**
 
-1. Install the desktop app (`npx @lamalibre/create-lamaste-desktop@4.1.0`)
+1. Install the desktop app (`npx @lamalibre/create-lamaste-desktop@4.2.0`)
 2. Go to the Servers tab and click "Create a new server"
 3. Enter your DigitalOcean API token — the app validates scopes and stores it securely in your OS credential store
 4. Pick a region (the app measures latency to each) and a domain name
@@ -93,14 +93,14 @@ All backend services bind `127.0.0.1` only — nginx is the sole public-facing s
 
 State is stored in JSON files (`/etc/lamalibre/lamaste/panel.json`, `tunnels.json`) with atomic writes (write to temp → fsync → rename). No database is needed at this scale.
 
-The installer (`npx @lamalibre/create-lamaste@4.1.0`) is completely non-interactive — it detects the environment, provisions everything, and prints a summary. All configuration happens through the browser-based onboarding wizard after installation.
+The installer (`npx @lamalibre/create-lamaste@4.2.0`) is completely non-interactive — it detects the environment, provisions everything, and prints a summary. All configuration happens through the browser-based onboarding wizard after installation.
 
 ## Quick Reference
 
 | Item                 | Value                           |
 | -------------------- | ------------------------------- |
 | **Minimum VPS**      | 512MB RAM, Ubuntu 24.04         |
-| **Install command**  | `npx @lamalibre/create-lamaste@4.1.0` |
+| **Install command**  | `npx @lamalibre/create-lamaste@4.2.0` |
 | **Admin panel**      | `https://<ip>:9292` (mTLS)      |
 | **Auth for admin**   | Client certificate (zero-login) |
 | **Auth for apps**    | TOTP 2FA via Authelia           |
@@ -108,5 +108,5 @@ The installer (`npx @lamalibre/create-lamaste@4.1.0`) is completely non-interact
 | **TLS certificates** | Let's Encrypt (auto-renewing)   |
 | **State storage**    | JSON files (no database)        |
 | **RAM usage**        | ~245MB total (all services)     |
-| **npm package**      | `@lamalibre/create-lamaste@4.1.0`     |
+| **npm package**      | `@lamalibre/create-lamaste@4.2.0`     |
 | **License**          | Polyform Noncommercial 1.0.0    |

package/vendor/docs/01-concepts/certificates.md

@@ -29,7 +29,7 @@ For the IP-based admin panel (`https://<ip>:9292`), there is no domain to verify
 
 ### When certificates are issued
 
-- **Self-signed + mTLS certs** — created during `npx @lamalibre/create-lamaste@4.1.0` installation
+- **Self-signed + mTLS certs** — created during `npx @lamalibre/create-lamaste@4.2.0` installation
 - **Core Let's Encrypt certs** — issued during onboarding for `panel`, `auth`, and `tunnel` subdomains
 - **App Let's Encrypt certs** — issued when you create a new tunnel or a managed static site
 - **Custom-domain site certs** — issued when a custom-domain site's DNS is verified: one certificate lineage, named after the site's domain, covering the domain and every redirect alias (re-issued when aliases change)
@@ -82,7 +82,7 @@ The most critical scenario is the mTLS CA expiring, but it has a 10-year validit
 
 ### Let's Encrypt implementation
 
-Lamaste uses certbot with the nginx plugin for certificate issuance. The implementation lives in `@lamalibre/lamaste@4.1.0/server` (`packages/core/lib/src/server/certbot.ts`), wrapped by `packages/server/daemon/src/lib/certbot.js`.
+Lamaste uses certbot with the nginx plugin for certificate issuance. The implementation lives in `@lamalibre/lamaste@4.2.0/server` (`packages/core/lib/src/server/certbot.ts`), wrapped by `packages/server/daemon/src/lib/certbot.js`.
 
 The panel runs as the unprivileged `lamaste` user and never runs `certbot` or `openssl` on Let's Encrypt files directly. It calls two root-owned wrapper scripts through sudo:
 
@@ -193,7 +193,7 @@ This three-step check prevents unnecessary certificate issuance and respects rat
 
 #### Custom-domain site certificate issuance
 
-A custom-domain static site may have redirect aliases (e.g. `www.myblog.net`). `issueSiteCert(fqdn, aliases, email)` in `@lamalibre/lamaste@4.1.0/server` keeps them on **one** lineage named after the primary domain:
+A custom-domain static site may have redirect aliases (e.g. `www.myblog.net`). `issueSiteCert(fqdn, aliases, email)` in `@lamalibre/lamaste@4.2.0/server` keeps them on **one** lineage named after the primary domain:
 
 ```bash
 sudo /usr/local/sbin/lamaste-certbot issue admin@example.com myblog.net myblog.net www.myblog.net

package/vendor/docs/01-concepts/mtls.md

@@ -25,7 +25,7 @@ You encounter mTLS during two moments:
 
 ### Importing the certificate
 
-After running `npx @lamalibre/create-lamaste@4.1.0`, the installer prints something like:
+After running `npx @lamalibre/create-lamaste@4.2.0`, the installer prints something like:
 
 ```
 ╔══════════════════════════════════════════════════════════════╗
@@ -101,7 +101,7 @@ When connecting a machine to Lamaste using `lamaste-agent`, you should **not** u
 2. Click "Generate" and enter a label (e.g., `macbook-pro`)
 3. Save the displayed password — it cannot be retrieved later
 4. Download the `.p12` file
-5. Share the `.p12` file and password with the agent machine through a secure channel, then install the agent there (`npm install -g @lamalibre/lamaste-agent@4.1.0`) and run `lamaste-agent setup` (an enrollment token avoids moving the key at all — see [Agent Setup](../02-guides/agent-setup.md))
+5. Share the `.p12` file and password with the agent machine through a secure channel, then install the agent there (`npm install -g @lamalibre/lamaste-agent@4.2.0`) and run `lamaste-agent setup` (an enrollment token avoids moving the key at all — see [Agent Setup](../02-guides/agent-setup.md))
 
 Agent certificates have capability-based access. By default, a new agent can only read tunnel configuration. Admins can grant additional capabilities per-agent from the panel UI:
 

package/vendor/docs/01-concepts/security-model.md

@@ -467,7 +467,7 @@ Anything else is refused — including directives nginx would accept, backslashe
 
 #### Root code never writes through the panel's paths
 
-`create-lamaste` (including a self-update the panel triggers) and `sudo lamaste-server` run as root on directories `lamaste` can write to, which a compromised panel could have seeded with symlinks. So root never writes through an existing path there: new files are created `O_EXCL | O_NOFOLLOW` under a random name, `fchown`ed and renamed into place; temporary directories are `mkdtemp`; `lamaste-server reset-admin` runs `openssl`, `cp` and `chmod` as `lamaste`; `lamaste-server plugins install|enable|disable|uninstall` re-runs itself as `lamaste` (npm and state writes) and only restarts the panel as root.
+`create-lamaste` (including a self-update the panel triggers) and `sudo lamaste-server` run as root on directories `lamaste` can write to, which a compromised panel could have seeded with symlinks. So root never writes through an existing path there: new files are created `O_EXCL | O_NOFOLLOW` under a random name, `fchown`ed and renamed into place; temporary directories are `mkdtemp`; `lamaste-server reset-admin` runs `openssl`, `cp` and `chmod` as `lamaste`; `lamaste-server plugins install|enable|disable|uninstall` change nothing on disk themselves: they call the panel's plugin routes with the admin certificate (the panel runs npm and writes its registry as `lamaste`), and root only restarts the panel.
 
 ### Secret generation
 

package/vendor/docs/01-concepts/tickets.md

@@ -264,9 +264,9 @@ The integration flow:
 }
 ```
 
-### Client SDK (`@lamalibre/lamaste-tickets@4.1.0`)
+### Client SDK (`@lamalibre/lamaste-tickets@4.2.0`)
 
-The `@lamalibre/lamaste-tickets@4.1.0` package is a TypeScript SDK that provides the client-side ticket lifecycle for plugins and agents. It uses `undici` for HTTP with mTLS dispatcher support and has no other runtime dependencies.
+The `@lamalibre/lamaste-tickets@4.2.0` package is a TypeScript SDK that provides the client-side ticket lifecycle for plugins and agents. It uses `undici` for HTTP with mTLS dispatcher support and has no other runtime dependencies.
 
 The SDK exports three main classes:
 

package/vendor/docs/01-concepts/tunneling.md

@@ -144,7 +144,7 @@ On the API side the same rule holds: `GET /api/tunnels/agent-config` returns onl
 
 ### Client configuration
 
-The Chisel client runs as a user-level service managed by `lamaste-agent` (and `lamaste-agentd`): a LaunchAgent plist on macOS, a systemd **user** unit on Linux. Both are generated by one implementation in `@lamalibre/lamaste@4.1.0/agent`. The client command looks like:
+The Chisel client runs as a user-level service managed by `lamaste-agent` (and `lamaste-agentd`): a LaunchAgent plist on macOS, a systemd **user** unit on Linux. Both are generated by one implementation in `@lamalibre/lamaste@4.2.0/agent`. The client command looks like:
 
 ```bash
 chisel client \
@@ -208,7 +208,7 @@ location / {
 
 ### Concurrency and locking
 
-Every tunnel workflow — create, delete, toggle, assign, reconfigure, the combined `PATCH`, releasing a revoked agent's tunnels, and startup reconciliation — runs under one tunnel lock (`withTunnelLock` in `@lamalibre/lamaste@4.1.0/server`'s `tunnels.ts`), with its validation inside the lock. Two concurrent requests therefore cannot both pass a uniqueness check for the same subdomain or port. Authfile renders are additionally serialized with a keyed promise-chain mutex in `chisel-users.ts`, so enrollments and credential rotations never interleave authfile writes with tunnel changes.
+Every tunnel workflow — create, delete, toggle, assign, reconfigure, the combined `PATCH`, releasing a revoked agent's tunnels, and startup reconciliation — runs under one tunnel lock (`withTunnelLock` in `@lamalibre/lamaste@4.2.0/server`'s `tunnels.ts`), with its validation inside the lock. Two concurrent requests therefore cannot both pass a uniqueness check for the same subdomain or port. Authfile renders are additionally serialized with a keyed promise-chain mutex in `chisel-users.ts`, so enrollments and credential rotations never interleave authfile writes with tunnel changes.
 
 ### Startup reconciliation
 
@@ -223,7 +223,7 @@ It **fails closed**: if the authfile cannot be established, Chisel is stopped **
 
 ### Installation
 
-On the server, Chisel is installed by `npx @lamalibre/create-lamaste@4.1.0` — as root, together with its hardened systemd unit (`User=nobody`, `Group=lamaste-chisel`, `NoNewPrivileges`, `ProtectSystem=strict`, empty `CapabilityBoundingSet`) — and kept at the pinned release by every redeploy. The panel never installs a binary or writes the unit; onboarding only checks the binary exists, creates the server key and authfile, and starts the service. Both the server installer and the agents download the pinned release (`CHISEL_RELEASE` in `@lamalibre/lamaste@4.1.0`'s `constants.ts`) from its fixed URL, with no GitHub API lookup and no "latest":
+On the server, Chisel is installed by `npx @lamalibre/create-lamaste@4.2.0` — as root, together with its hardened systemd unit (`User=nobody`, `Group=lamaste-chisel`, `NoNewPrivileges`, `ProtectSystem=strict`, empty `CapabilityBoundingSet`) — and kept at the pinned release by every redeploy. The panel never installs a binary or writes the unit; onboarding only checks the binary exists, creates the server key and authfile, and starts the service. Both the server installer and the agents download the pinned release (`CHISEL_RELEASE` in `@lamalibre/lamaste@4.2.0`'s `constants.ts`) from its fixed URL, with no GitHub API lookup and no "latest":
 
 ```
 https://github.com/jpillora/chisel/releases/download/v1.12.0/chisel_1.12.0_<os>_<arch>.gz
@@ -320,7 +320,7 @@ sudo systemctl restart chisel
 
 ```bash
 # Install globally, then set up the agent (interactive)
-npm install -g @lamalibre/lamaste-agent@4.1.0
+npm install -g @lamalibre/lamaste-agent@4.2.0
 lamaste-agent setup --label <label>
 
 # Apply tunnel changes now (the sync timer does it within 30 s anyway)

package/vendor/docs/02-guides/agent-setup.md

@@ -59,7 +59,7 @@ The token is single-use and expires after 10 minutes. `tunnels:read` is enough f
 Install the agent **globally** first:
 
 ```bash
-npm install -g @lamalibre/lamaste-agent@4.1.0
+npm install -g @lamalibre/lamaste-agent@4.2.0
 ```
 
 A global install is required, not a convenience. Setup installs a sync timer (see [How tunnel changes reach the agent](#how-tunnel-changes-reach-the-agent)) that runs the installed `lamaste-agent` every 30 seconds for as long as the agent exists. An `npx` copy lives in npm's cache, which npm may clear at any time — the timer would silently stop. `setup` and `update` therefore refuse to run from `npx`, and they check this **before** an enrollment token is spent. For an installation npm does not manage, set `LAMALIBRE_LAMASTE_AGENT_CLI_PATH` to the absolute path of the `lamaste-agent` script the timer should run.
@@ -148,7 +148,7 @@ Each agent authenticates to the relay with its own chisel credential, stored in
 Upgrade agents **before** the server. Agents from before this version reject the new shape of the relay's Chisel arguments; a current agent works against an older server, keeping its credential until the server offers rotation.
 
 ```bash
-npm install -g @lamalibre/lamaste-agent@4.1.0
+npm install -g @lamalibre/lamaste-agent@4.2.0
 lamaste-agent update
 ```
 
@@ -171,7 +171,7 @@ lamaste-agent uninstall --label <l>  # stop and remove one agent, including its
 
 | Symptom                                                     | Cause and fix                                                                                                                                                                                                                   |
 | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `setup` says the agent must be installed globally           | It was run through `npx`. Run `npm install -g @lamalibre/lamaste-agent@4.1.0`, then `lamaste-agent setup ...` again. The enrollment token was not spent.                                                                              |
+| `setup` says the agent must be installed globally           | It was run through `npx`. Run `npm install -g @lamalibre/lamaste-agent@4.2.0`, then `lamaste-agent setup ...` again. The enrollment token was not spent.                                                                              |
 | Log shows a TLS / x509 error                                | `tunnel.<domain>` does not present a valid certificate for its name. Check the relay's certificate (`Certificates` page) and that the agent's clock is correct.                                                                 |
 | Log shows authentication failed                             | The credential was rotated on the panel. The next sync picks it up; `lamaste-agent chisel refresh-credential` applies it now.                                                                                                   |
 | Log shows `access denied` for a remote                      | The relay no longer grants this agent that port: the tunnel was disabled, deleted, or moved to another agent. The next sync drops it. If it persists, check `lamaste-agent status` — the sync timer may not be running.         |

package/vendor/docs/02-guides/certificate-management.md

@@ -196,7 +196,7 @@ The admin certificate (`CN=admin`) has unrestricted access to all panel endpoint
 
 ### Distribute to the Agent Machine
 
-Send the `.p12` file and password to the agent machine (macOS or Linux) securely, and install the agent there with `npm install -g @lamalibre/lamaste-agent@4.1.0` and run `lamaste-agent setup --label <label>` — or import it into the Desktop App. An enrollment token is preferable where possible, because the private key is then generated on the agent and never travels. See [Agent Setup](agent-setup.md) for details.
+Send the `.p12` file and password to the agent machine (macOS or Linux) securely, and install the agent there with `npm install -g @lamalibre/lamaste-agent@4.2.0` and run `lamaste-agent setup --label <label>` — or import it into the Desktop App. An enrollment token is preferable where possible, because the private key is then generated on the agent and never travels. See [Agent Setup](agent-setup.md) for details.
 
 ### Update Capabilities
 
@@ -293,7 +293,7 @@ Revocation is immediate — the certificate serial is added to a revocation list
 
 ### mTLS Rotation Internals
 
-Admin certificate rotation lives only in `lamaste-server reset-admin` (`packages/server/cli/src/commands/reset-admin.js`), run as root on the server. The panel's `rotateClientCert()` in `lib/mtls.js` is a stub that returns `503` with that instruction; `@lamalibre/lamaste@4.1.0/server` no longer exports a rotation function. The PKI directory belongs to `lamaste`, so `reset-admin` runs every file operation inside it (`openssl genrsa`/`req`/`x509 -req`/`pkcs12`, `cp`, `chmod`) as `lamaste`, and writes `panel.json` and `revoked.json` as fresh files renamed into place — root never writes through a path the panel could have replaced with a symlink.
+Admin certificate rotation lives only in `lamaste-server reset-admin` (`packages/server/cli/src/commands/reset-admin.js`), run as root on the server. The panel's `rotateClientCert()` in `lib/mtls.js` is a stub that returns `503` with that instruction; `@lamalibre/lamaste@4.2.0/server` no longer exports a rotation function. The PKI directory belongs to `lamaste`, so `reset-admin` runs every file operation inside it (`openssl genrsa`/`req`/`x509 -req`/`pkcs12`, `cp`, `chmod`) as `lamaste`, and writes `panel.json` and `revoked.json` as fresh files renamed into place — root never writes through a path the panel could have replaced with a symlink.
 
 The PKCS12 bundle uses legacy encryption settings (`-keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -macalg sha1`) because newer OpenSSL defaults produce files that macOS Keychain Access cannot import.
 

package/vendor/docs/02-guides/cloud-provisioning.md

@@ -14,7 +14,7 @@ Before you start, make sure you have:
 
 | Requirement               | Details                                                                                                                                                           |
 | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Desktop app installed** | `npx @lamalibre/create-lamaste-desktop@4.1.0` ([setup guide](desktop-app-setup.md))                                                                                     |
+| **Desktop app installed** | `npx @lamalibre/create-lamaste-desktop@4.2.0` ([setup guide](desktop-app-setup.md))                                                                                     |
 | **DigitalOcean account**  | A free account at [cloud.digitalocean.com](https://cloud.digitalocean.com). **If you have other infrastructure on DO, create a dedicated team first** (see below) |
 | **Payment method**        | A credit card or PayPal on file in DigitalOcean (required to create droplets)                                                                                     |
 | **Domain name**           | Optional for initial setup — you can add a domain later through the panel                                                                                         |
@@ -221,7 +221,7 @@ The wizard shows up to 12 steps with live progress indicators. Each step shows a
 | **Waiting for boot**            | Polls DigitalOcean until the droplet has a public IP and is ready (up to 5 minutes)                         |
 | **Setting up DNS records**      | Creates A and wildcard A records in DigitalOcean DNS (only if a domain was selected in the Domain step)     |
 | **Connecting via SSH**          | Establishes an SSH connection using the temporary key                                                       |
-| **Installing Lamaste**          | Runs `npx @lamalibre/create-lamaste@4.1.0` on the droplet (up to 10 minutes)                                      |
+| **Installing Lamaste**          | Runs `npx @lamalibre/create-lamaste@4.2.0` on the droplet (up to 10 minutes)                                      |
 | **Retrieving credentials**      | Downloads the admin certificate (`.p12` file) from the droplet                                              |
 | **Enrolling admin certificate** | Imports the certificate into your OS credential store                                                       |
 | **Saving configuration**        | Writes the server entry to `~/.lamalibre/lamaste/servers.json`                                              |
@@ -315,7 +315,7 @@ If you already have a Lamaste server set up (via the manual SSH method), you can
 
 The app checks that the panel is reachable before adding it. The server is added with `active: false` — click **Set Active** on its card to start using it.
 
-> **Note:** Adding an existing server registers it in the app but does not configure authentication. You will still need to set up your agent certificate separately using `lamaste-agent setup` (after `npm install -g @lamalibre/lamaste-agent@4.1.0`) or by importing a certificate manually.
+> **Note:** Adding an existing server registers it in the app but does not configure authentication. You will still need to set up your agent certificate separately using `lamaste-agent setup` (after `npm install -g @lamalibre/lamaste-agent@4.2.0`) or by importing a certificate manually.
 
 ---
 

package/vendor/docs/02-guides/desktop-app-setup.md

@@ -26,7 +26,7 @@ The Lamaste Desktop app is a native application (built with Tauri) that wraps th
 Run the installer:
 
 ```bash
-npx @lamalibre/create-lamaste-desktop@4.1.0
+npx @lamalibre/create-lamaste-desktop@4.2.0
 ```
 
 The installer:
@@ -56,11 +56,11 @@ After the app launches, it shows a setup screen with two options:
 Install the agent globally and run its setup command:
 
 ```bash
-npm install -g @lamalibre/lamaste-agent@4.1.0
+npm install -g @lamalibre/lamaste-agent@4.2.0
 lamaste-agent setup --label my-server
 ```
 
-The agent must be a global install — setup installs a sync timer that runs it every 30 seconds to pick up tunnel changes, and refuses to run from `npx`. (When the app sets up an agent itself, it installs `@lamalibre/lamaste-agent@4.1.0` globally for you.) The `--label` flag names this agent connection (used for multi-agent support). This command connects to your VPS panel using the agent certificate and configures the local Chisel client. During setup, the client certificate and key are extracted from the P12 bundle for mTLS client authentication. Once setup completes, the app detects the configuration and switches to the main interface.
+The agent must be a global install — setup installs a sync timer that runs it every 30 seconds to pick up tunnel changes, and refuses to run from `npx`. (When the app sets up an agent itself, it installs `@lamalibre/lamaste-agent@4.2.0` globally for you.) The `--label` flag names this agent connection (used for multi-agent support). This command connects to your VPS panel using the agent certificate and configures the local Chisel client. During setup, the client certificate and key are extracted from the P12 bundle for mTLS client authentication. Once setup completes, the app detects the configuration and switches to the main interface.
 
 **Option B: Create a new server**
 
@@ -72,7 +72,7 @@ The desktop app has two modes, toggled via a pill switch in the sidebar header.
 
 ### Agent Mode (default)
 
-Agent mode provides local agent management. The agent-mode pages (Dashboard, Tunnels, Services, Plugins, Logs, Settings) are imported from the shared `@lamalibre/lamaste-agent-ui@4.1.0` package. The landing page is the **Agents** list, showing all configured agents with their connection status. Click an agent to drill into its management pages:
+Agent mode provides local agent management. The agent-mode pages (Dashboard, Tunnels, Services, Plugins, Logs, Settings) are imported from the shared `@lamalibre/lamaste-agent-ui@4.2.0` package. The landing page is the **Agents** list, showing all configured agents with their connection status. Click an agent to drill into its management pages:
 
 - **Agents** (landing) — list of all configured agents with start/stop controls and status
 - **Dashboard** — per-agent connection status, Chisel version, start/stop/restart controls
@@ -84,7 +84,7 @@ Agent mode provides local agent management. The agent-mode pages (Dashboard, Tun
 
 ### Server Mode
 
-Server mode provides the full admin panel — the same management pages available in the browser-based panel UI. These pages are imported from the shared `@lamalibre/lamaste-server-ui@4.1.0` package:
+Server mode provides the full admin panel — the same management pages available in the browser-based panel UI. These pages are imported from the shared `@lamalibre/lamaste-server-ui@4.2.0` package:
 
 - **Dashboard** — system stats (CPU, RAM, disk, uptime) + service health
 - **Tunnels** — tunnel CRUD, carrying agent, access mode, body limit
@@ -169,7 +169,7 @@ Stopping an agent's tunnels from the app is remembered: the agent's sync timer k
 Run the installer again to get the latest version:
 
 ```bash
-npx @lamalibre/create-lamaste-desktop@4.1.0
+npx @lamalibre/create-lamaste-desktop@4.2.0
 ```
 
 If a new release is available, it downloads and installs the update. The previous version is replaced.
@@ -202,9 +202,9 @@ Deleting `~/.lamalibre/lamaste/` by hand instead would leave the agents' service
 
 | Action               | Command / Location                                                                   |
 | -------------------- | ------------------------------------------------------------------------------------ |
-| **Install**          | `npx @lamalibre/create-lamaste-desktop@4.1.0`                                              |
-| **Update**           | `npx @lamalibre/create-lamaste-desktop@4.1.0`                                              |
-| **Agent setup**      | `npm install -g @lamalibre/lamaste-agent@4.1.0`, then `lamaste-agent setup --label <name>` |
+| **Install**          | `npx @lamalibre/create-lamaste-desktop@4.2.0`                                              |
+| **Update**           | `npx @lamalibre/create-lamaste-desktop@4.2.0`                                              |
+| **Agent setup**      | `npm install -g @lamalibre/lamaste-agent@4.2.0`, then `lamaste-agent setup --label <name>` |
 | **App location**     | `/Applications/Lamaste.app` (macOS)                                                  |
 | **Agent registry**   | `~/.lamalibre/lamaste/agents.json`                                                   |
 | **Per-agent data**   | `~/.lamalibre/lamaste/agents/<label>/`                                               |
@@ -215,7 +215,7 @@ Deleting `~/.lamalibre/lamaste/` by hand instead would leave the agents' service
 | **Chisel logs**      | `~/.lamalibre/lamaste/agents/<label>/logs/chisel.log`                                |
 | **Cloud tokens**     | OS credential store (`com.lamalibre.cloud`)                                          |
 | **P12 passwords**    | OS credential store (`com.lamalibre.lamaste.server`)                                 |
-| **npm package**      | `@lamalibre/create-lamaste-desktop@4.1.0`                                                  |
+| **npm package**      | `@lamalibre/create-lamaste-desktop@4.2.0`                                                  |
 
 ### Related Documentation
 

package/vendor/docs/02-guides/installation.md

@@ -62,7 +62,7 @@ Execute the Lamaste installer:
 
 ```bash
 apt install -y npm
-npx @lamalibre/create-lamaste@4.1.0
+npx @lamalibre/create-lamaste@4.2.0
 ```
 
 The installer displays a confirmation banner before making any changes:
@@ -90,7 +90,7 @@ The installer displays a confirmation banner before making any changes:
   Press Enter to continue or Ctrl+C to abort...
 ```
 
-Press **Enter** to proceed. To skip the confirmation prompt, use `npx @lamalibre/create-lamaste@4.1.0 --yes`.
+Press **Enter** to proceed. To skip the confirmation prompt, use `npx @lamalibre/create-lamaste@4.2.0 --yes`.
 
 ### 4. What the Installer Does
 
@@ -380,7 +380,7 @@ The service includes security hardening: `ProtectHome=true`, `PrivateTmp=true`,
 
 | Item                     | Value                                                        |
 | ------------------------ | ------------------------------------------------------------ |
-| **Install command**      | `npx @lamalibre/create-lamaste@4.1.0`                              |
+| **Install command**      | `npx @lamalibre/create-lamaste@4.2.0`                              |
 | **Minimum VPS**          | Ubuntu 24.04, 512 MB RAM                                     |
 | **Required ports**       | 22 (SSH), 80 (HTTP/Let's Encrypt), 443 (HTTPS), 9292 (panel) |
 | **Certificate location** | `/etc/lamalibre/lamaste/pki/client.p12`                      |

package/vendor/docs/02-guides/onboarding.md

@@ -113,7 +113,7 @@ Chisel is the tunneling engine. The installer already put the pinned Chisel rele
 
 Authelia provides two-factor authentication for your tunneled apps. The installer already put the pinned Authelia release, its systemd unit and its `lamaste-authelia` service account in place; the provisioner checks the binary is there, writes the configuration file (using your domain), creates the initial admin user with a random password, and starts the service. Authelia listens on `127.0.0.1:9091`.
 
-Onboarding downloads nothing. If either task fails with "… is not installed. Run `npx @lamalibre/create-lamaste@4.1.0` on the server to repair the installation.", re-run the installer on the server (it is idempotent) and start provisioning again.
+Onboarding downloads nothing. If either task fails with "… is not installed. Run `npx @lamalibre/create-lamaste@4.2.0` on the server to repair the installation.", re-run the installer on the server (it is idempotent) and start provisioning again.
 
 Authelia uses **bcrypt** for password hashing (not argon2id) because argon2id uses approximately 93 MB per hash, which causes out-of-memory kills on a 512 MB droplet.
 
@@ -213,7 +213,7 @@ Each provisioning task calls library functions in `packages/lamaste-serverd/src/
 
 The DNS check resolves these hostnames using Node's `dns.resolve4()`:
 
-1. `panel.example.com`, `auth.example.com`, `tunnel.example.com` — must resolve to the server IP (required; `CORE_SUBDOMAINS` in `@lamalibre/lamaste@4.1.0`)
+1. `panel.example.com`, `auth.example.com`, `tunnel.example.com` — must resolve to the server IP (required; `CORE_SUBDOMAINS` in `@lamalibre/lamaste@4.2.0`)
 2. `test-lamaste-check.example.com` — tests wildcard resolution (optional)
 3. `example.com` — reported, not required
 

package/vendor/docs/02-guides/standalone-plugin-with-tickets.md

@@ -27,7 +27,7 @@ Using the desktop app's cloud provisioning wizard:
 
 - Enter your DigitalOcean API token
 - Select a region and droplet size
-- The wizard calls `@lamalibre/lamaste-cloud@4.1.0` to create the droplet
+- The wizard calls `@lamalibre/lamaste-cloud@4.2.0` to create the droplet
 - Progress streams back as NDJSON events in the desktop UI
 - Complete onboarding in the browser panel
 
@@ -96,7 +96,7 @@ The Sync server now runs as a local service on the Mac. It operates independentl
 
 ### 5. Register Sync Scopes and Instance on Lamaste
 
-The Sync server detects that the Mac has a Lamaste agent certificate. Using that cert (mTLS), it registers a ticket scope and instance with the Lamaste panel. This is handled automatically by `TicketInstanceManager` from `@lamalibre/lamaste-tickets@4.1.0` — the admin does not need to do anything.
+The Sync server detects that the Mac has a Lamaste agent certificate. Using that cert (mTLS), it registers a ticket scope and instance with the Lamaste panel. This is handled automatically by `TicketInstanceManager` from `@lamalibre/lamaste-tickets@4.2.0` — the admin does not need to do anything.
 
 ```mermaid
 sequenceDiagram

package/vendor/docs/03-architecture/installer-flow.md

@@ -1,6 +1,6 @@
 # Installer Flow
 
-## What `npx @lamalibre/create-lamaste@4.1.0` Does
+## What `npx @lamalibre/create-lamaste@4.2.0` Does
 
 The installer is a **zero-prompt, fire-and-forget** command. It assumes:
 
@@ -13,7 +13,7 @@ It requires **no user input**. All configuration happens later through the brows
 ## Execution Flow
 
 ```
-$ npx @lamalibre/create-lamaste@4.1.0
+$ npx @lamalibre/create-lamaste@4.2.0
 
   Lamaste Installer v1.0.0
 

package/vendor/docs/03-architecture/installer.md

@@ -4,14 +4,14 @@
 
 ## In Plain English
 
-When you run `npx @lamalibre/create-lamaste@4.1.0` on a fresh VPS, the installer takes over and does everything automatically: hardens the OS, installs dependencies, generates security certificates, configures nginx, deploys the panel, and starts the service. It prints a summary with instructions for downloading your client certificate and accessing the panel. No prompts, no questions, no configuration files to edit.
+When you run `npx @lamalibre/create-lamaste@4.2.0` on a fresh VPS, the installer takes over and does everything automatically: hardens the OS, installs dependencies, generates security certificates, configures nginx, deploys the panel, and starts the service. It prints a summary with instructions for downloading your client certificate and accessing the panel. No prompts, no questions, no configuration files to edit.
 
 The installer is deliberately limited in scope. It sets up just enough to serve the panel UI over a secure connection. Everything else — domain configuration, tunnel setup, user management — happens through the browser-based onboarding wizard after the installer finishes.
 
 ## Overview
 
 ```
-npx @lamalibre/create-lamaste@4.1.0
+npx @lamalibre/create-lamaste@4.2.0
   │
   ├── bin/create-lamaste.js          ← CLI entry point
   │     └── calls main() from src/index.js
@@ -181,7 +181,7 @@ Six task groups run sequentially through Listr2:
 **Chisel and Authelia** (`lib/relay-services.js`, run on install and on every redeploy):
 
 - Creates the `lamaste-chisel` group (and adds `lamaste` to it) and the `lamaste-authelia` system account (no login shell, no home)
-- Installs Chisel 1.12.0 and Authelia 4.39.28 to `/usr/local/bin` (`lib/binaries.js`): downloaded from fixed release URLs, verified against the SHA-256 digests pinned in `@lamalibre/lamaste@4.1.0` (`CHISEL_RELEASE`, `AUTHELIA_RELEASE`) before anything is unpacked, staged in a `mkdtemp` directory and renamed into place. A binary already at the pinned version is left alone; an Authelia **newer** than the pin is kept, never downgraded (its database may use a schema the pinned release cannot read)
+- Installs Chisel 1.12.0 and Authelia 4.39.28 to `/usr/local/bin` (`lib/binaries.js`): downloaded from fixed release URLs, verified against the SHA-256 digests pinned in `@lamalibre/lamaste@4.2.0` (`CHISEL_RELEASE`, `AUTHELIA_RELEASE`) before anything is unpacked, staged in a `mkdtemp` directory and renamed into place. A binary already at the pinned version is left alone; an Authelia **newer** than the pin is kept, never downgraded (its database may use a schema the pinned release cannot read)
 - Writes `/etc/systemd/system/chisel.service` (`User=nobody`, `Group=lamaste-chisel`) and `/etc/systemd/system/authelia.service` (`User=lamaste-authelia`, `UMask=027`, `Environment=X_AUTHELIA_CONFIG_FILTERS=template`, `ProtectSystem=strict` with `ReadWritePaths=/etc/authelia /var/log/authelia`, `SystemCallFilter=@system-service`, empty `CapabilityBoundingSet`, `NoNewPrivileges`); both are enabled and started later by onboarding
 - Generates the OpenID Connect issuer key `/etc/authelia/oidc-issuer.pem` if it is missing (`lib/oidc-issuer-key.js`): RSA 4096 generated in the installer process, written by a child process running as `lamaste-authelia` (`wx`, 0600, renamed into place) so root never writes through `/etc/authelia`. The panel references it from Authelia's configuration with a `{{ secret "…" }}` template expression — which is why the unit and `lamaste-priv authelia-totp` set the `template` configuration filter — and can never read it. A key owned by anyone else is replaced; one owned by the Authelia account is kept (its mode fixed through a descriptor if it drifted)
 - Sets ownership (`lib/ownership.js`): `/var/www/lamaste` `lamaste:www-data 2750`; `/etc/authelia` `lamaste:lamaste-authelia 2770` (setgid) with `configuration.yml` `0640`, `users.yml` `0660`, `.secrets.json` `0600` (lamaste), `db.sqlite3*` and `notifications.txt` `lamaste-authelia 0600`; `/var/log/authelia` `lamaste-authelia 0750`; `chisel-server.key` (if present) `lamaste:lamaste-chisel 0640`; the PKI directory `lamaste:lamaste` (the panel is the CA)
@@ -253,7 +253,7 @@ When the installer detects an existing Lamaste installation (`/etc/lamalibre/lam
 
 Redeploy mode stops the panel and gatekeeper, secures the install directory (a non-root-owned tree is moved aside and removed at the end), redeploys the panel server, `lamaste-server` CLI, UI, docs, gatekeeper and cert help page, merges `panel.json`, runs the same Chisel/Authelia step as a fresh install (stopping a running Authelia while its files change hands), rewrites the panel's systemd unit, the root-owned programs and the sudoers rules, ensures the port-80 redirect, then restarts Chisel if its binary or unit changed, starts Authelia and the gatekeeper if they were running, and restarts the panel. It does not touch OS hardening, mTLS certificates or the panel's vhosts. The panel's self-update (`sudo lamaste-priv self-update <version>`) runs this path as root, so it never writes through a path the `lamaste` user controls.
 
-This provides a fast upgrade path: re-running `npx @lamalibre/create-lamaste@4.1.0` on an existing installation updates the code and the pinned services while preserving all configuration and certificates. Use `--force-full` to bypass this and run the complete installer.
+This provides a fast upgrade path: re-running `npx @lamalibre/create-lamaste@4.2.0` on an existing installation updates the code and the pinned services while preserving all configuration and certificates. Use `--force-full` to bypass this and run the complete installer.
 
 The redeploy logic lives in `tasks/redeploy.js`, with shared systemd unit and sudoers content generators in `lib/service-config.js`.
 

package/vendor/docs/03-architecture/management-flow.md

@@ -276,7 +276,7 @@ Everything else the panel does needs no rule: the PKI directory (agent CSR signi
 
 The certbot wrappers accept only lowercase DNS hostnames (no wildcards or path characters, at most 100 per certificate) and a syntactically valid email address. Renewals the panel triggers pass `--no-random-sleep-on-renew`, because certbot otherwise sleeps up to about 8 minutes before a non-interactive renewal (a delay meant for `certbot.timer`) while an operator waits.
 
-Redeploying (`npx @lamalibre/create-lamaste@4.1.0` on an existing install) reinstalls the programs, removes retired ones (`lamaste-sign-csr`, `lamaste-pki-rename`), and replaces this file atomically after `visudo -c` accepts it, so upgrades pick up new rules.
+Redeploying (`npx @lamalibre/create-lamaste@4.2.0` on an existing install) reinstalls the programs, removes retired ones (`lamaste-sign-csr`, `lamaste-pki-rename`), and replaces this file atomically after `visudo -c` accepts it, so upgrades pick up new rules.
 
 ## File Operation Safety
 

package/vendor/docs/03-architecture/overview.md

@@ -6,7 +6,7 @@
 
 Lamaste has three main pieces:
 
-1. **The Installer** (`npx @lamalibre/create-lamaste@4.1.0`) — a one-shot script you run once on a fresh VPS. It sets up nginx, generates security certificates, and deploys a web-based control panel. After it finishes, you never SSH into the server again.
+1. **The Installer** (`npx @lamalibre/create-lamaste@4.2.0`) — a one-shot script you run once on a fresh VPS. It sets up nginx, generates security certificates, and deploys a web-based control panel. After it finishes, you never SSH into the server again.
 
 2. **The Panel** (browser UI + backend API) — a management interface protected by a client certificate. Through it, you configure your domain, create tunnels, manage users, and monitor services.
 
@@ -321,7 +321,7 @@ lamaste/
 │   │           ├── files.js          ← Static site file operations (upload, delete, list)
 │   │           └── app-error.js      ← Operational error class (AppError)
 │   │
-│   ├── lamaste-server-ui/          ← React 18 + Vite + Tailwind SPA + shared admin components (@lamalibre/lamaste-server-ui@4.1.0)
+│   ├── lamaste-server-ui/          ← React 18 + Vite + Tailwind SPA + shared admin components (@lamalibre/lamaste-server-ui@4.2.0)
 │   │   └── src/
 │   │       ├── index.js              ← Package exports (pages, context, utilities)
 │   │       ├── context/
@@ -337,7 +337,7 @@ lamaste/
 │   │       │   └── formatters.js     ← Byte, uptime, relative time formatters
 │   │       └── pages/                ← Admin pages (Dashboard, Tunnels, Sites, Users, Certs, Services, Plugins, Tickets, Settings)
 │   │
-│   ├── lamaste-agent-ui/          ← Shared React agent UI (pages, context, components) (@lamalibre/lamaste-agent-ui@4.1.0)
+│   ├── lamaste-agent-ui/          ← Shared React agent UI (pages, context, components) (@lamalibre/lamaste-agent-ui@4.2.0)
 │   │
 │   ├── lamaste-tickets/              ← Agent-to-agent authorization SDK (mTLS, undici)
 │   │   └── src/
@@ -377,7 +377,7 @@ lamaste/
 │           │   │   └── CompleteStep.jsx   ← Credentials + TOTP QR + next steps
 │           │   ├── management/            ← Legacy standalone implementations (kept for reference)
 │           │   │   ├── Certificates.jsx   ← Standalone certificates page (dead code)
-│           │   │   ├── Dashboard.jsx      ← Standalone dashboard (not imported — App.jsx uses @lamalibre/lamaste-server-ui@4.1.0)
+│           │   │   ├── Dashboard.jsx      ← Standalone dashboard (not imported — App.jsx uses @lamalibre/lamaste-server-ui@4.2.0)
 │           │   │   ├── Plugins.jsx        ← Standalone plugins page (dead code)
 │           │   │   ├── Services.jsx       ← Standalone services page (dead code)
 │           │   │   ├── Settings.jsx       ← Standalone settings page (dead code)
@@ -486,7 +486,7 @@ The Panel Server runs as the `lamaste` user with minimal privileges and cannot b
 The full lifecycle of a Lamaste installation:
 
 ```
-Phase 1: Installation (npx @lamalibre/create-lamaste@4.1.0)
+Phase 1: Installation (npx @lamalibre/create-lamaste@4.2.0)
   └─ OS hardening, Node.js, mTLS certs, nginx, panel deploy
   └─ Result: Panel accessible at https://<ip>:9292
 

package/vendor/docs/03-architecture/panel-client.md

@@ -10,9 +10,9 @@ The client has two modes. On first visit, it shows an onboarding wizard that wal
 
 ## Shared Panel Packages
 
-The management-mode admin pages (Dashboard, Tunnels, Sites, Users, Certificates, Services, Plugins, Tickets, Logs, Settings) live in `@lamalibre/lamaste-server-ui@4.1.0`. This package provides both the browser SPA build and the shared admin components consumed by `lamaste-desktop` (Tauri app).
+The management-mode admin pages (Dashboard, Tunnels, Sites, Users, Certificates, Services, Plugins, Tickets, Logs, Settings) live in `@lamalibre/lamaste-server-ui@4.2.0`. This package provides both the browser SPA build and the shared admin components consumed by `lamaste-desktop` (Tauri app).
 
-The agent-mode pages (Dashboard, Tunnels, Services, Plugins, Logs, Settings) are extracted into a separate shared package: `@lamalibre/lamaste-agent-ui@4.1.0`. This package is consumed by `lamaste-desktop` for agent mode.
+The agent-mode pages (Dashboard, Tunnels, Services, Plugins, Logs, Settings) are extracted into a separate shared package: `@lamalibre/lamaste-agent-ui@4.2.0`. This package is consumed by `lamaste-desktop` for agent mode.
 
 The shared package exposes an `AdminClientContext` abstraction that decouples admin UI pages from their data transport. Each host provides its own client implementation:
 
@@ -118,7 +118,7 @@ The shell renders the appropriate step component and shows a progress indicator
 
 ### Management Mode
 
-React Router handles navigation within the `Layout` component (sidebar + content area). Management page components are imported from the shared `@lamalibre/lamaste-server-ui@4.1.0` package and wrapped with the `AdminClientProvider` (which supplies the web-specific data client):
+React Router handles navigation within the `Layout` component (sidebar + content area). Management page components are imported from the shared `@lamalibre/lamaste-server-ui@4.2.0` package and wrapped with the `AdminClientProvider` (which supplies the web-specific data client):
 
 | Path                     | Component           | Description                                                         |
 | ------------------------ | ------------------- | ------------------------------------------------------------------- |
@@ -350,9 +350,9 @@ The app root wraps all content in five providers:
 ```
 
 1. **QueryClientProvider** — react-query cache with global defaults (`retry: 1`, `refetchOnWindowFocus: false`)
-2. **AdminClientProvider** — from `@lamalibre/lamaste-server-ui@4.1.0`, supplies the host-specific data client (`webAdminClient` for browser fetch, Tauri `invoke` for desktop)
-3. **ToastProvider** — from `@lamalibre/lamaste-server-ui@4.1.0`, notification toast system
-4. **TwoFaProvider** — from `@lamalibre/lamaste-server-ui@4.1.0`, handles 2FA verification prompts when the panel has 2FA enabled
+2. **AdminClientProvider** — from `@lamalibre/lamaste-server-ui@4.2.0`, supplies the host-specific data client (`webAdminClient` for browser fetch, Tauri `invoke` for desktop)
+3. **ToastProvider** — from `@lamalibre/lamaste-server-ui@4.2.0`, notification toast system
+4. **TwoFaProvider** — from `@lamalibre/lamaste-server-ui@4.2.0`, handles 2FA verification prompts when the panel has 2FA enabled
 5. **BrowserRouter** — React Router for client-side navigation
 
 ## Documentation Viewer