@lamalibre/create-lamaste 4.6.0 → 4.7.0

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

@@ -264,9 +264,9 @@ The integration flow:
 }
 ```
 
-### Client SDK (`@lamalibre/lamaste-tickets@4.6.0`)
+### Client SDK (`@lamalibre/lamaste-tickets@4.7.0`)
 
-The `@lamalibre/lamaste-tickets@4.6.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.7.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.6.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.7.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.6.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.7.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.6.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.6.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.7.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.7.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.6.0
+npm install -g @lamalibre/lamaste-agent@4.7.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.6.0
+npm install -g @lamalibre/lamaste-agent@4.7.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.6.0
+npm install -g @lamalibre/lamaste-agent@4.7.0
 lamaste-agent update
 ```
 
@@ -172,7 +172,7 @@ lamaste-agent uninstall --label <l>  # stop and remove one agent, including its
 To let the panel install the agent halves of app plugins on this machine — their accounts, units and directories — enable the app host helper once, from a root-owned install:
 
 ```bash
-sudo npm install -g @lamalibre/lamaste-agent@4.6.0
+sudo npm install -g @lamalibre/lamaste-agent@4.7.0
 sudo lamaste-agent apphost enable              # the agent runs as the user who ran sudo
 lamaste-agent apphost status                   # helper, pinned relay keys, installed agent halves
 sudo lamaste-agent apphost pin                 # after the relay rotated its signing key
@@ -184,7 +184,7 @@ The agent reports it on its next sync, and the panel can then host plugins whose
 
 | 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.6.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.7.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.             |
@@ -196,7 +196,7 @@ The agent reports it on its next sync, and the panel can then host plugins whose
 | New tunnel returns 502                                      | The agent has not synced yet (up to ~30 s), or nothing listens on `127.0.0.1:<port>` on the agent. Run `lamaste-agent update` to apply at once.                                                                                     |
 | Upload fails with 413                                       | The request is larger than the tunnel's body limit. Raise **Largest request body** on the tunnel (`maxBodySizeMb`).                                                                                                                 |
 | `uninstall` refuses: agent halves are installed             | Agent halves run here for this agent. Unhost or uninstall those plugins on the panel (the next sync removes them), or `sudo lamaste-agent apphost disable --force` (data is kept).                                                  |
-| `apphost enable` says the install is not root-owned         | Root installs the helper only from code no other user can change: `sudo npm install -g @lamalibre/lamaste-agent@4.6.0`, then `sudo lamaste-agent apphost enable` from that install.                                                       |
+| `apphost enable` says the install is not root-owned         | Root installs the helper only from code no other user can change: `sudo npm install -g @lamalibre/lamaste-agent@4.7.0`, then `sudo lamaste-agent apphost enable` from that install.                                                       |
 | `apphost enable` says the helper serves another user        | App hosting serves one OS user per machine. Unhost or uninstall the plugins that user's agents host (`sudo lamaste-agent apphost status` lists their agent halves), then `sudo lamaste-agent apphost enable --user <name> --force`. |
 | `apphost pin` says a label is not an agent of the user      | Root pins only labels the agent user's registry lists. Pin as the user the agent runs as (`--user <name>`; `--user root` for an agent running as root).                                                                             |
 | Hosting refused: the helper trusts another relay key        | The relay's signing key was replaced, or the agent enrolled again. Run `sudo lamaste-agent apphost pin`; compare the key id with the relay's ([App Host](../04-api-reference/app-host.md#pinning-the-relay-key)).                   |

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.6.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.7.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.6.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.7.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.6.0` ([setup guide](desktop-app-setup.md))                                                                                     |
+| **Desktop app installed** | `npx @lamalibre/create-lamaste-desktop@4.7.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.6.0` on the droplet (up to 10 minutes)                                      |
+| **Installing Lamaste**          | Runs `npx @lamalibre/create-lamaste@4.7.0` on the droplet (up to 10 minutes)                                      |
 | **Retrieving credentials**      | Downloads the admin certificate (`.p12` file) and reads the panel's TLS key pin 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.6.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.7.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.6.0
+npx @lamalibre/create-lamaste-desktop@4.7.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.6.0
+npm install -g @lamalibre/lamaste-agent@4.7.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.6.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.7.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.6.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.7.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.6.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.7.0` package:
 
 - **Dashboard** — system stats (CPU, RAM, disk, uptime) + service health
 - **Tunnels** — tunnel CRUD, carrying agent, access mode, body limit
@@ -170,7 +170,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.6.0
+npx @lamalibre/create-lamaste-desktop@4.7.0
 ```
 
 If a new release is available, it downloads and installs the update. The previous version is replaced.
@@ -203,9 +203,9 @@ Deleting `~/.lamalibre/lamaste/` by hand instead would leave the agents' service
 
 | Action               | Command / Location                                                                   |
 | -------------------- | ------------------------------------------------------------------------------------ |
-| **Install**          | `npx @lamalibre/create-lamaste-desktop@4.6.0`                                              |
-| **Update**           | `npx @lamalibre/create-lamaste-desktop@4.6.0`                                              |
-| **Agent setup**      | `npm install -g @lamalibre/lamaste-agent@4.6.0`, then `lamaste-agent setup --label <name>` |
+| **Install**          | `npx @lamalibre/create-lamaste-desktop@4.7.0`                                              |
+| **Update**           | `npx @lamalibre/create-lamaste-desktop@4.7.0`                                              |
+| **Agent setup**      | `npm install -g @lamalibre/lamaste-agent@4.7.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>/`                                               |
@@ -216,7 +216,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.6.0`                                                  |
+| **npm package**      | `@lamalibre/create-lamaste-desktop@4.7.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.6.0
+npx @lamalibre/create-lamaste@4.7.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.6.0 --yes`.
+Press **Enter** to proceed. To skip the confirmation prompt, use `npx @lamalibre/create-lamaste@4.7.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.6.0`                              |
+| **Install command**      | `npx @lamalibre/create-lamaste@4.7.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/managing-users.md

@@ -117,13 +117,13 @@ When someone leaves, **disable** them first — it is immediate and reversible:
 The user's status turns **disabled**. From that moment:
 
 - they can no longer sign in to Authelia (Authelia's `disabled: true`);
-- every agent-hosted plugin's user surface refuses them (`403`) — the panel's directory is updated before Authelia restarts;
+- every agent-hosted plugin's user surface refuses them (`403`) — the panel's directory is updated in the same step;
 - every plugin they use sees them as `disabled` in its audience (its agent half is told within seconds while it is online);
 - their desktop app sessions end and their registry (Feria) tokens are revoked.
 
 Their `userId`, grants and group memberships stay, so **Enable** brings everything back as it was (their desktop app signs in again). The last enabled member of the `admins` group cannot be disabled — the panel refuses with "Cannot disable the last enabled administrator". A user disabled by editing `users.yml` directly is offboarded the same way within a minute, when the panel notices.
 
-If Authelia rewrites `users.yml` at the very moment you disable someone (a password reset it handles writes the whole file), the panel notices after Authelia restarts and disables the user again; should that not stick either, the panel says the change did not persist instead of reporting success — check the user and disable them again.
+If Authelia rewrites `users.yml` at the very moment you disable someone (a password reset it handles writes the whole file), the panel notices when it reads the file back and disables the user again; should that not stick either, the panel says the change did not persist instead of reporting success — check the user and disable them again.
 
 ```bash
 lamaste-server users disable alice
@@ -141,7 +141,7 @@ lamaste-server users enable alice
 
 **What happens behind the scenes:**
 
-1. The panel removes the user from `users.yml` (atomic write, under the panel's one lock for user changes) and restarts Authelia.
+1. The panel removes the user from `users.yml` (atomic write, under the panel's one lock for user changes); Authelia reloads it and ends the user's session at their next request.
 2. The user directory keeps a **tombstone**: the user's `userId` and their last username, display name and email, marked `removed`. Plugins that had the user as a member are told the user was deleted and keep what they last received, so a plugin's history — "approved by Alice Smith" — stays readable.
 3. Gatekeeper drops every grant naming the username and its membership of every Lamaste group. If Gatekeeper is unreachable, the panel says so and retries every minute; until it succeeds, the username holds no role in any plugin and cannot be given to a new user.
 4. Authelia deletes the user's second factors — their TOTP configuration and WebAuthn security keys.
@@ -227,7 +227,7 @@ Details: [Users API](../04-api-reference/users.md).
 
 ### The User Directory
 
-Authelia's `users.yml` stays Authelia's credential file; the panel's `state.db` holds the **directory** beside it: a `userId` per user, the status, and the tombstones of deleted users. Every write of `users.yml` the panel makes goes through one lock that brings the directory in line before Authelia restarts. The panel also reads `users.yml` at start and every minute — never writing it — and adopts what changed outside Lamaste (Authelia's own password reset rewrites the file): a new username gets a new `userId`, a changed name, address or `disabled` flag is taken over, and a user gone from the file (seen in two reads) becomes a tombstone marked `deleted-outside`. Audit entries name users by `userId` only.
+Authelia's `users.yml` stays Authelia's credential file; the panel's `state.db` holds the **directory** beside it: a `userId` per user, the status, and the tombstones of deleted users. Every write of `users.yml` the panel makes goes through one lock that brings the directory in line in the same step. The panel also reads `users.yml` at start and every minute — never writing it — and adopts what changed outside Lamaste (Authelia's own password reset rewrites the file): a new username gets a new `userId`, a changed name, address or `disabled` flag is taken over, and a user gone from the file (seen in two reads) becomes a tombstone marked `deleted-outside`. Audit entries name users by `userId` only.
 
 ### The CLI
 
@@ -310,13 +310,7 @@ Passwords are hashed with bcrypt at cost factor 12. The `hashPassword()` functio
 
 ### Authelia Reload
 
-After every write to `users.yml`, the panel restarts Authelia:
-
-```bash
-sudo systemctl restart authelia
-```
-
-Authelia reads `users.yml` on restart. If the restart fails, a warning is logged but the API request still succeeds — the user data is persisted and the next Authelia restart picks it up.
+Authelia watches `users.yml` (`authentication_backend.file.watch: true`) and reloads it in place; with the watch it re-reads a user's details at each of their requests, so a change applies at the user's next request without a restart and without ending anyone else's session. It skips a reload within 0.5 s of the previous one, so the panel writes the file once more 0.6 s after its last write. Who may reach which domain is part of the file too: the groups Lamaste owns (`lamaste:m:<key>`, `lamaste:x:<key>`, `lamaste:s:<site id>`, hostnames, `lamaste:oidc@<client>` — never shown as groups). Authelia restarts when its configuration changes — a domain or a protected static site added or removed, the OIDC clients changed — and when a change takes a device-code OIDC client (`feria login`) away from someone, because Authelia's device flow checks the groups a session last read. Authelia's own password change and reset are disabled (they cannot work on a relay: its notifier is a file); passwords are set by invitation or by an administrator.
 
 ## Quick Reference
 

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.6.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.7.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.6.0`)
+1. `panel.example.com`, `auth.example.com`, `tunnel.example.com` — must resolve to the server IP (required; `CORE_SUBDOMAINS` in `@lamalibre/lamaste@4.7.0`)
 2. `test-lamaste-check.example.com` — tests wildcard resolution (optional)
 3. `example.com` — reported, not required
 

package/vendor/docs/02-guides/second-domain.md

@@ -0,0 +1,82 @@
+# Adding a Second Domain
+
+> Serve another base domain from the same relay, with its own sign-in and its own members — `codelama.com.tr` beside `samplepark.tr`, or a customer's domain.
+
+## In Plain English
+
+One relay can serve several domains. Each gets a sign-in page at `auth.<domain>` and a member list; a person signs in to each domain once with the same account and reaches only the domains they are a member of. The panel and the tunnel endpoint stay on the primary domain, so agents change nothing.
+
+## 1. Add the domain
+
+Panel → **Domains** → enter the name → **Add domain**, or:
+
+```bash
+sudo lamaste-server domains add codelama.com.tr
+```
+
+It is `pending`: nothing is served on it yet.
+
+## 2. Create the DNS records
+
+At the domain's DNS host, point the sign-in at the relay:
+
+| Type | Name                   | Value            |
+| ---- | ---------------------- | ---------------- |
+| A    | `auth.codelama.com.tr` | the relay's IPv4 |
+
+Then either one wildcard for every later hostname, or one record per hostname:
+
+| Type | Name                | Value            |
+| ---- | ------------------- | ---------------- |
+| A    | `*.codelama.com.tr` | the relay's IPv4 |
+
+Explicit records keep precedence over a wildcard, so an apex, `www` or mail (MX, SPF, DKIM) record elsewhere stays as it is. Some DNS hosts (Turhost among them) take a wildcard as a plain record named `*`; if yours refuses one, create an A record per hostname as you add tunnels and sites. Certificates are Let's Encrypt HTTP-01 per hostname, issued by the relay — the DNS host does not matter.
+
+**Check DNS** on the domain's card (or `lamaste-server domains verify-dns codelama.com.tr`) lists the records the panel expects and whether each resolves here.
+
+## 3. Choose the members
+
+Add members on the domain's card (**Members**), or `lamaste-server domains members codelama.com.tr add <username>`. Members of a pending domain are let in the moment it goes live. From now on new users and invitations name their domains.
+
+## 4. Activate
+
+**Activate** (or `lamaste-server domains activate codelama.com.tr`) issues `auth.codelama.com.tr`, serves its sign-in and admits its members. It is one operation: if the certificate, nginx or Authelia step fails, nothing changes.
+
+## 5. Put hostnames on it
+
+Tunnel and managed-site forms gain a **Domain** picker; the CLI takes `--domain`. A plugin belongs to one domain: move it on its card (or `lamaste-server plugins domain <name> <domain>`) before giving it a user or web surface there.
+
+## What members see
+
+- A member signs in at `auth.<domain>` once per domain (browsers never share cookies between domains), with the same password and TOTP.
+- A signed-in non-member gets a "not a member of this domain" page with your contact and a sign-out link.
+- `authenticated` means "any member of this domain"; `restricted` still needs a Gatekeeper grant.
+
+## External members
+
+A client's people can sign in on your domain without reaching all of it: make them **external** members. An external member reaches only what names them:
+
+- a `restricted` tunnel, user surface or web surface — with a Gatekeeper grant (to them, or a Lamaste group they are in);
+- a protected static site that lists them in its allowed users;
+- an OIDC client of a plugin on the domain that is granted to them (the plugin card's **OIDC sign-in**, or `lamaste-server plugins oidc-clients <plugin> grant <client> --user <name>`).
+
+Every `authenticated` host stays closed to them — they get the access-request page. They hold no Authelia groups (`admins`, `feria-*`): remove a user's groups before making them external. A plugin's audience counts them when they are entitled to it, so the plugin sees them with their roles.
+
+Make someone external when you create or invite them (the membership's kind, or **External member** on a one-domain relay), on the domain's **Members** list (**Make external**), or with the CLI:
+
+```
+lamaste-server domains members codelama.com.tr add client-ali --external
+lamaste-server domains members codelama.com.tr kind onur external
+```
+
+None of this restarts Authelia or signs anyone out: a change applies at the person's next request.
+
+## Removing a domain
+
+Delete or move what uses it first (the card lists it), then **Remove**. Its memberships end; the primary can never be removed.
+
+## Related
+
+- [Domains API](../04-api-reference/domains.md)
+- [DNS & Domains](../01-concepts/dns-and-domains.md#multiple-domains)
+- [Authorization](../01-concepts/authorization.md)

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.6.0` to create the droplet
+- The wizard calls `@lamalibre/lamaste-cloud@4.7.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.6.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.7.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.6.0` Does
+## What `npx @lamalibre/create-lamaste@4.7.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.6.0
+$ npx @lamalibre/create-lamaste@4.7.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.6.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.7.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.6.0
+npx @lamalibre/create-lamaste@4.7.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.6.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.7.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.6.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.7.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

@@ -278,7 +278,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.6.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.7.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/nginx-configuration.md

@@ -204,7 +204,7 @@ Identical to the IP vhost except:
 - `server_name` is `panel.<domain>`
 - Requires the `map $http_upgrade $connection_upgrade` block from the IP vhost (or a shared config) to be present
 
-### 3. Auth Vhost (`lamalibre-lamaste-auth`)
+### 3. Auth Vhost (`lamalibre-lamaste-auth-<domain>`)
 
 Created during onboarding provisioning. Serves the Authelia authentication portal.
 
@@ -282,7 +282,7 @@ Key characteristics:
 - 24-hour read/send timeouts to keep tunnel connections alive without nginx closing them
 - No mTLS and no Authelia — Chisel handles its own authentication
 
-### 5. App Vhost (`lamalibre-lamaste-app-<name>`)
+### 5. App Vhost (`lamalibre-lamaste-app-<fqdn>`)
 
 Created when a tunnel is added via the management UI or `POST /api/tunnels`. Each tunnel gets its own vhost, rendered by one of three writers according to the tunnel's `accessMode`:
 
@@ -468,7 +468,7 @@ server {
 
 Moving a bound tunnel's host to a web surface hands the hostname over in **one reload**: the tunnel's vhost is unlinked, the site's written and linked, `nginx -t` run, nginx reloaded once; the tunnel's file stays installed, unlinked, so the tunnel can be enabled again once the site is deleted. On a failed test both are put back.
 
-### 7. Public Tunnel Vhost (`lamalibre-lamaste-app-<name>`, access mode: public)
+### 7. Public Tunnel Vhost (`lamalibre-lamaste-app-<fqdn>`, access mode: public)
 
 Created when a tunnel is configured with public access. Direct proxy with no authentication.
 
@@ -505,7 +505,7 @@ server {
 
 No `auth_request`, no Authelia, no Gatekeeper. Traffic is proxied directly to the tunneled app. Use only for services that handle their own authentication or are intentionally public.
 
-### 8. Authenticated Tunnel Vhost (`lamalibre-lamaste-app-<name>`, access mode: authenticated)
+### 8. Authenticated Tunnel Vhost (`lamalibre-lamaste-app-<fqdn>`, access mode: authenticated)
 
 Created when a tunnel requires Authelia login but no per-user grant checking. Any authenticated Authelia user can access the tunnel.
 
@@ -582,7 +582,7 @@ Key characteristics:
 
 > **Note:** The `lamalibre-lamaste-authz-cache.conf` nginx snippet is installed by the Gatekeeper installer task, but the generated vhosts do not currently include `proxy_cache` directives. Authorization caching relies on the Gatekeeper's in-memory session cache (30-second TTL) rather than nginx-level proxy caching.
 
-### 9. Restricted Tunnel Vhost (`lamalibre-lamaste-app-<name>`, access mode: restricted)
+### 9. Restricted Tunnel Vhost (`lamalibre-lamaste-app-<fqdn>`, access mode: restricted)
 
 Created when a tunnel requires both Authelia login and an explicit access grant. Only users with a matching grant in Gatekeeper (`gatekeeper.db`) can access the tunnel.
 
@@ -757,6 +757,16 @@ Gatekeeper authorizes the tunnel named in the path, and refuses a check whose `X
 
 Authelia evaluates the raw `$request_uri`, while nginx serves the normalized `$uri` (`/a/../b` is `/b`, `%2e` is `.`). Lamaste writes no path (`resources`) rules into Authelia's `access_control`, only hostname rules; a path rule added by hand would see a different path than nginx serves.
 
+## Vhosts on several domains
+
+A relay may serve several base domains ([Domains API](../04-api-reference/domains.md)). Vhost files are therefore named by full hostname — `lamalibre-lamaste-app-<fqdn>`, `lamalibre-lamaste-agent-panel-<fqdn>`, `lamalibre-lamaste-auth-<domain>` — so the same subdomain on two domains never shares a file. At start the panel renames vhosts written under the earlier names (`lamalibre-lamaste-app-<subdomain>`, `lamalibre-lamaste-agent-panel-<subdomain>`, `lamalibre-lamaste-auth`): the new file is written with the old one's link state, the old file and link removed, then one `nginx -t` and reload, with the old files restored if the test fails. `lamaste-priv` accepts the hostname names for every action and the legacy names for everything but `write`.
+
+- **One auth vhost per active domain** (`auth.<domain>`, its own certificate). Only the primary's carries `/api/user-access/authorize` and the `user_access_auth` rate-limit zone (desktop user access is primary-only); every domain's serves `/`, `/invite/` and `/api/invite/`.
+- **The 401 redirect** of tunnel and web-surface vhosts goes to `https://auth.<the host's domain>/?rd=…`; static sites follow Authelia's `$redirection_url`, which Authelia builds for the host's cookie domain.
+- **A 403** from Gatekeeper (a signed-in non-member, or a missing grant) is served inline; Authelia-protected static sites route `error_page 403` to Gatekeeper's `/authz/refusal/<fqdn>`.
+- **Authenticated and restricted tunnels share one vhost** (`writeGatekeeperVhost`): Gatekeeper decides by the access mode in `tunnels.json`.
+- **Certificates** stay HTTP-01 per hostname; a wildcard is used when one for the host's domain is already present.
+
 ## The backend cookie map
 
 Authelia's session cookie (`authelia_session`, the name core configures in `server/authelia.ts` and exports as `AUTHELIA_SESSION_COOKIE`) is scoped to the base domain, so a browser sends it to every host under it. No tunnel or agent backend may receive it: every location that proxies to one sends

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

@@ -6,7 +6,7 @@
 
 Lamaste has three main pieces:
 
-1. **The Installer** (`npx @lamalibre/create-lamaste@4.6.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.7.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.
 
@@ -318,7 +318,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.6.0)
+│   ├── lamaste-server-ui/          ← React 18 + Vite + Tailwind SPA + shared admin components (@lamalibre/lamaste-server-ui@4.7.0)
 │   │   └── src/
 │   │       ├── index.js              ← Package exports (pages, context, utilities)
 │   │       ├── context/
@@ -334,7 +334,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.6.0)
+│   ├── lamaste-agent-ui/          ← Shared React agent UI (pages, context, components) (@lamalibre/lamaste-agent-ui@4.7.0)
 │   │
 │   ├── lamaste-tickets/              ← Agent-to-agent authorization SDK (mTLS, undici)
 │   │   └── src/
@@ -374,7 +374,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.6.0)
+│           │   │   ├── Dashboard.jsx      ← Standalone dashboard (not imported — App.jsx uses @lamalibre/lamaste-server-ui@4.7.0)
 │           │   │   ├── Plugins.jsx        ← Standalone plugins page (dead code)
 │           │   │   ├── Services.jsx       ← Standalone services page (dead code)
 │           │   │   ├── Settings.jsx       ← Standalone settings page (dead code)
@@ -483,7 +483,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.6.0)
+Phase 1: Installation (npx @lamalibre/create-lamaste@4.7.0)
   └─ OS hardening, Node.js, mTLS certs, nginx, panel deploy
   └─ Result: Panel accessible at https://<ip>:9292