@lamalibre/create-lamaste 4.3.0 → 4.3.1

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.3.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.3.1` 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.3.0`)
+1. `panel.example.com`, `auth.example.com`, `tunnel.example.com` — must resolve to the server IP (required; `CORE_SUBDOMAINS` in `@lamalibre/lamaste@4.3.1`)
 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.3.0` to create the droplet
+- The wizard calls `@lamalibre/lamaste-cloud@4.3.1` 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.3.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.3.1` — 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.3.0` Does
+## What `npx @lamalibre/create-lamaste@4.3.1` 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.3.0
+$ npx @lamalibre/create-lamaste@4.3.1
 
   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.3.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.3.1` 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.3.0
+npx @lamalibre/create-lamaste@4.3.1
   │
   ├── 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.3.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.3.1` (`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.3.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.3.1` 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.3.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.3.1` 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.3.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.3.1`) — 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.3.0)
+│   ├── lamaste-server-ui/          ← React 18 + Vite + Tailwind SPA + shared admin components (@lamalibre/lamaste-server-ui@4.3.1)
 │   │   └── 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.3.0)
+│   ├── lamaste-agent-ui/          ← Shared React agent UI (pages, context, components) (@lamalibre/lamaste-agent-ui@4.3.1)
 │   │
 │   ├── 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.3.0)
+│           │   │   ├── Dashboard.jsx      ← Standalone dashboard (not imported — App.jsx uses @lamalibre/lamaste-server-ui@4.3.1)
 │           │   │   ├── 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.3.0)
+Phase 1: Installation (npx @lamalibre/create-lamaste@4.3.1)
   └─ 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.3.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.3.1`. 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.3.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.3.1`. 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.3.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.3.1` 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.3.0`, supplies the host-specific data client (`webAdminClient` for browser fetch, Tauri `invoke` for desktop)
-3. **ToastProvider** — from `@lamalibre/lamaste-server-ui@4.3.0`, notification toast system
-4. **TwoFaProvider** — from `@lamalibre/lamaste-server-ui@4.3.0`, handles 2FA verification prompts when the panel has 2FA enabled
+2. **AdminClientProvider** — from `@lamalibre/lamaste-server-ui@4.3.1`, supplies the host-specific data client (`webAdminClient` for browser fetch, Tauri `invoke` for desktop)
+3. **ToastProvider** — from `@lamalibre/lamaste-server-ui@4.3.1`, notification toast system
+4. **TwoFaProvider** — from `@lamalibre/lamaste-server-ui@4.3.1`, handles 2FA verification prompts when the panel has 2FA enabled
 5. **BrowserRouter** — React Router for client-side navigation
 
 ## Documentation Viewer

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

@@ -453,7 +453,7 @@ See [nginx-configuration.md](./nginx-configuration.md) for detailed coverage.
 
 ### chisel-users.js — Chisel Credentials and Grants
 
-- Thin shim over `@lamalibre/lamaste@4.3.0/server`: per-agent credentials in `chisel-credentials.json` (0600)
+- Thin shim over `@lamalibre/lamaste@4.3.1/server`: per-agent credentials in `chisel-credentials.json` (0600)
 - Renders the authfile `chisel-users` from the credentials and `tunnels.json`: each `agent-<label>` may bind exactly `^R:127\.0\.0\.1:<port>$` for its enabled tunnels
 - Adds the `lamaste-no-grants` sentinel user (password in `chisel-sentinel`, 0600) so the authfile is never empty — Chisel disables authentication on an empty authfile
 - Never grants a reserved port (3100, 9090, 9091, 9292, 9294) or a port claimed by two tunnels
@@ -535,7 +535,7 @@ Agent-to-agent authorization with scopes, instances, tickets, and sessions. Prov
 - **Periodic cleanup** — stale/dead instances, expired tickets, dead sessions
 - **Concurrency** — promise-chain mutex with atomic file writes (temp → fsync → rename)
 
-Client SDK: `@lamalibre/lamaste-tickets@4.3.0` (TypeScript, undici) provides `TicketClient`, `TicketInstanceManager` (source side), and `TicketSessionManager` (target side) for plugin integration.
+Client SDK: `@lamalibre/lamaste-tickets@4.3.1` (TypeScript, undici) provides `TicketClient`, `TicketInstanceManager` (source side), and `TicketSessionManager` (target side) for plugin integration.
 
 State files: `/etc/lamalibre/lamaste/ticket-scopes.json` (scopes, instances, assignments) and `/etc/lamalibre/lamaste/tickets.json` (tickets, sessions).
 

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

@@ -331,7 +331,7 @@ Read returns `[]` for missing files (ENOENT), enabling the system to start with
 5. `DELETE /api/certs/agent/:label` (revocation) — the agent's app and plugin tunnels lose their `agentLabel` (unassigned), and its `agent-<label>` panel tunnel is removed
 6. At startup (background, fail closed): an ownerless `agent-<label>` panel tunnel is bound to the agent it names when that agent is active; other ownerless tunnels (from versions before tunnel ownership) are bound to the sole active agent, or left unassigned when there are several. Then the pinned Chisel binary, the unit and the authfile are re-established — and Chisel is stopped if they cannot be
 
-Every one of these workflows runs under the single tunnel lock (`withTunnelLock` in `@lamalibre/lamaste@4.3.0/server`), with its validation inside the lock.
+Every one of these workflows runs under the single tunnel lock (`withTunnelLock` in `@lamalibre/lamaste@4.3.1/server`), with its validation inside the lock.
 
 ## Site State (`sites.json`)
 
@@ -486,7 +486,7 @@ The PKI directory belongs to `lamaste` because the panel is the CA (it signs age
 
 The Panel Server is a single-process Node.js application, but a single-threaded event loop does not serialize asynchronous workflows: two requests that each read `tunnels.json`, await a certificate or an nginx test, and then write it back would interleave, and both could pass the same uniqueness check. Serialization is therefore explicit:
 
-**Tunnel state** is guarded by one promise-chain lock, `withTunnelLock` in `@lamalibre/lamaste@4.3.0/server`'s `tunnels.ts`. Every tunnel workflow — create, delete, toggle, assign, reconfigure, the combined `PATCH /api/tunnels/:id`, releasing a revoked agent's tunnels, and startup reconciliation — takes it for its whole duration, and does its validation (subdomain and port uniqueness, reserved ports, agent checks, authorization against the current entry) inside it.
+**Tunnel state** is guarded by one promise-chain lock, `withTunnelLock` in `@lamalibre/lamaste@4.3.1/server`'s `tunnels.ts`. Every tunnel workflow — create, delete, toggle, assign, reconfigure, the combined `PATCH /api/tunnels/:id`, releasing a revoked agent's tunnels, and startup reconciliation — takes it for its whole duration, and does its validation (subdomain and port uniqueness, reserved ports, agent checks, authorization against the current entry) inside it.
 
 **Chisel authfile renders** are serialized by a promise-chain mutex in `chisel-users.ts`, keyed by the credentials file, around every render (enroll, revoke, rotate, tunnel change). The daemon's `syncChisel()` renders after the tunnel state is written and restarts Chisel (`systemctl try-restart`) only when the render withdrew something.
 

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

@@ -58,7 +58,7 @@
 │  │                                                                │  │
 │  │   Lamaste Desktop (Tauri v2) — dual mode                      │  │
 │  │    ├─ Agent mode: service discovery + tunnel management        │  │
-│  │    │   (pages from @lamalibre/lamaste-agent-ui@4.3.0)            │  │
+│  │    │   (pages from @lamalibre/lamaste-agent-ui@4.3.1)            │  │
 │  │    ├─ Server mode: full admin panel (via lamaste-server-ui) │  │
 │  │    ├─ Multi-server registry (~/.lamalibre/lamaste/servers.json)         │  │
 │  │    ├─ Cloud provisioning (DigitalOcean via lamaste-cloud)     │  │

package/vendor/docs/04-api-reference/agent-hosted-plugins.md

@@ -333,10 +333,10 @@ What the agent's host offers — see [Host facts](#host-facts).
 
 `lamaste-agent sync` (the 30-second timer) fetches a plugin's config when it does not hold the secret issued at `secretIssuedAt`, writes `~/.lamalibre/lamaste/agents/<label>/app-plugins/<route>.json` (0600, atomic), acknowledges it, and removes the file of a plugin the relay no longer lists. For an agent half Lamaste installed it first writes the service's own copy, `/etc/lamalibre/apps/<route>/plugin-config.json`, and acknowledges only once both are written. `sync.log` records `plugin config fetched: <route>` and `plugin config delivered to its service: <route>`.
 
-The agent half reads that file — `LAMALIBRE_LAMASTE_APP_PLUGIN_CONFIG` by convention — for its port and verifies every request on `/admin/*` with `createCallerAssertionVerifier` from `@lamalibre/lamaste@4.3.0/agent`, which re-reads the file when a signature does not verify, so a rotation needs no restart:
+The agent half reads that file — `LAMALIBRE_LAMASTE_APP_PLUGIN_CONFIG` by convention — for its port and verifies every request on `/admin/*` with `createCallerAssertionVerifier` from `@lamalibre/lamaste@4.3.1/agent`, which re-reads the file when a signature does not verify, so a rotation needs no restart:
 
 ```js
-import { createCallerAssertionVerifier } from '@lamalibre/lamaste@4.3.0/agent';
+import { createCallerAssertionVerifier } from '@lamalibre/lamaste@4.3.1/agent';
 
 const verifier = createCallerAssertionVerifier({ configPath, plugin: 'market-indicators' });
 const port = await verifier.port();

package/vendor/docs/04-api-reference/app-host.md

@@ -15,12 +15,12 @@ The helper does only what the relay **signed**. When it is enabled it remembers
 Once per agent machine (Linux with systemd; macOS agents cannot host an agent half Lamaste installs):
 
 ```bash
-sudo npm install -g @lamalibre/lamaste-agent@4.3.0   # a root-owned install
+sudo npm install -g @lamalibre/lamaste-agent@4.3.1   # a root-owned install
 sudo lamaste-agent apphost enable              # the agent runs as the user who ran sudo
 sudo lamaste-agent apphost enable --user root  # the agent runs as root: no sudoers rule
 ```
 
-`enable` refuses to act from an install another user could have changed: the package, the helper it ships and the core library it loads — and every directory above them — must be root-owned and writable by no group or other user. A user-level install (`nvm`, a home-directory prefix) is not; install it root-owned with `sudo npm install -g @lamalibre/lamaste-agent@4.3.0` and run `enable` from that install. It also needs `/usr/bin/node` (the helper's interpreter and the Node.js every agent half runs on — from the distribution or NodeSource), systemd as the system manager (`/run/systemd/system`), and `sudo` and `visudo` unless the agent runs as root.
+`enable` refuses to act from an install another user could have changed: the package, the helper it ships and the core library it loads — and every directory above them — must be root-owned and writable by no group or other user. A user-level install (`nvm`, a home-directory prefix) is not; install it root-owned with `sudo npm install -g @lamalibre/lamaste-agent@4.3.1` and run `enable` from that install. It also needs `/usr/bin/node` (the helper's interpreter and the Node.js every agent half runs on — from the distribution or NodeSource), systemd as the system manager (`/run/systemd/system`), and `sudo` and `visudo` unless the agent runs as root.
 
 What `enable` does:
 
@@ -313,7 +313,7 @@ The contract:
 - **Its config** is `LAMASTE_APP_CONFIG` (0600): `{ plugin, port, secret, issuedAt, previousSecret?, previousIssuedAt?, fetchedAt, acknowledged }`. Listen on `127.0.0.1:<port>` and verify every `/admin/*` request:
 
   ```js
-  import { createCallerAssertionVerifier } from '@lamalibre/lamaste@4.3.0/agent'; // bundled
+  import { createCallerAssertionVerifier } from '@lamalibre/lamaste@4.3.1/agent'; // bundled
 
   const verifier = createCallerAssertionVerifier({
     configPath: process.env.LAMASTE_APP_CONFIG,

package/vendor/docs/04-api-reference/lifecycle-hooks.md

@@ -233,13 +233,13 @@ Relay hooks run in `lamalibre-lamaste-hooks@<route>.service`, started by its soc
 
 `lamaste-priv hooks install <route> <sha256|none>` (module on stdin, checked against the approved digest) writes the module root-owned to `/opt/lamalibre/lamaste/hooks/<route>/<sha256>.mjs` and enables the socket; `hooks activate` points back at the previous module (an update's revert); `hooks restart` stops a stuck runner; `hooks remove` disables it and deletes its modules. The panel reinstalls an approved runner at start-up if it is missing.
 
-The protocol between the panel and the runner is one length-prefixed JSON frame each way per connection (`@lamalibre/lamaste@4.3.0/hooks`, `protocol.ts`).
+The protocol between the panel and the runner is one length-prefixed JSON frame each way per connection (`@lamalibre/lamaste@4.3.1/hooks`, `protocol.ts`).
 
 ## Writing hooks
 
 ```js
 // hooks/relay.mjs — bundled into one file (esbuild), Node built-ins only
-import { defineRelayHooks } from '@lamalibre/lamaste@4.3.0/hooks';
+import { defineRelayHooks } from '@lamalibre/lamaste@4.3.1/hooks';
 
 export default defineRelayHooks({
   'install:pre-tunnel': async (input) =>
@@ -266,10 +266,10 @@ Every decision may carry `effects` (at most 10): `{ type: 'audit', event, data?
 
 ### Agent hooks
 
-The agent half answers `POST /admin/hooks/<stage>` (body `{ stage, input }`, answer `{ ok: true, output? }` or `{ ok: false, reason }`). `createAgentHookHandler` from `@lamalibre/lamaste@4.3.0/agent` does the checking — the caller assertion must name Lamaste itself (`{ type: 'lamaste' }`), which no forwarded caller can, and the forwarder never reaches `/admin/hooks`:
+The agent half answers `POST /admin/hooks/<stage>` (body `{ stage, input }`, answer `{ ok: true, output? }` or `{ ok: false, reason }`). `createAgentHookHandler` from `@lamalibre/lamaste@4.3.1/agent` does the checking — the caller assertion must name Lamaste itself (`{ type: 'lamaste' }`), which no forwarded caller can, and the forwarder never reaches `/admin/hooks`:
 
 ```js
-import { createAgentHookHandler, createCallerAssertionVerifier } from '@lamalibre/lamaste@4.3.0/agent';
+import { createAgentHookHandler, createCallerAssertionVerifier } from '@lamalibre/lamaste@4.3.1/agent';
 
 const hooks = createAgentHookHandler({
   verifier: createCallerAssertionVerifier({ configPath, plugin: 'fx' }),

package/vendor/docs/04-api-reference/onboarding.md

@@ -255,7 +255,7 @@ The wildcard check probes `test-lamaste-check.<domain>`. Wildcard DNS is optiona
 
 ### `POST /api/onboarding/provision`
 
-Starts the full stack provisioning process in the background. This configures and starts Chisel and Authelia, issues certbot certificates, and writes nginx vhosts. The Chisel and Authelia binaries and units are installed by `create-lamaste`, not here: if one is missing, the task fails with the error "Chisel is not installed. Run `npx @lamalibre/create-lamaste@4.3.0` on the server to repair the installation." (likewise for Authelia). Task IDs are unchanged from earlier versions; only the titles changed.
+Starts the full stack provisioning process in the background. This configures and starts Chisel and Authelia, issues certbot certificates, and writes nginx vhosts. The Chisel and Authelia binaries and units are installed by `create-lamaste`, not here: if one is missing, the task fails with the error "Chisel is not installed. Run `npx @lamalibre/create-lamaste@4.3.1` on the server to repair the installation." (likewise for Authelia). Task IDs are unchanged from earlier versions; only the titles changed.
 
 Provisioning runs asynchronously. This endpoint returns immediately with a 202 status. Use the WebSocket stream endpoint to follow progress in real time.
 

package/vendor/docs/04-api-reference/registry-and-oidc.md

@@ -198,7 +198,7 @@ Agent certificates only; identity is the certificate label, never a parameter. R
 - An agent may be issued at most **ten new tokens per hour**; beyond that the route answers `429` with `Retry-After` (seconds) and `retryAfterSeconds`. The per-IP limit (30 per minute) remains as a backstop.
 - `403` for any other certificate — an admin certificate has no agent identity to broker for (plugin-agent certificates get `400`); `404` when no registry credential is configured (the agent installs from the public registry as before); `502` when the registry refuses.
 
-CLI: `lamaste-server registry-credential show | set --url <registry> (--oidc | --token-stdin) | clear`. The token for `--token-stdin` is read from stdin (or `LAMASTE_REGISTRY_TOKEN`), never from an argument.
+CLI: `lamaste-server registry-credential show | set --url <registry> (--oidc | --token-stdin) | clear`. The token for `--token-stdin` is read from stdin (or `LAMASTE_REGISTRY_TOKEN`), never from an argument, and the CLI hands the request body to curl on stdin, so the token is not in curl's arguments either.
 
 ### Group changes
 

package/vendor/docs/05-operations/backup-and-restore.md

@@ -197,7 +197,7 @@ sudo chown lamaste-authelia:lamaste-authelia /etc/authelia/db.sqlite3* /etc/auth
 sudo chmod 600 /etc/authelia/db.sqlite3* /etc/authelia/notifications.txt
 ```
 
-A backup taken on a version before the privilege boundary holds root-owned Authelia files and older unit files. After restoring one, re-run `npx @lamalibre/create-lamaste@4.3.0 --yes`: the redeploy rewrites the `chisel` and `authelia` units and converts the ownership of `/etc/authelia`, the Chisel key and the PKI directory (see [Upgrades](upgrades.md)).
+A backup taken on a version before the privilege boundary holds root-owned Authelia files and older unit files. After restoring one, re-run `npx @lamalibre/create-lamaste@4.3.1 --yes`: the redeploy rewrites the `chisel` and `authelia` units and converts the ownership of `/etc/authelia`, the Chisel key and the PKI directory (see [Upgrades](upgrades.md)).
 
 The panel re-applies the authfile's group and mode itself on every start, so a Chisel that fails to read it before the panel is up is started again by the panel's reconciliation.
 
@@ -273,6 +273,8 @@ sudo openssl req -x509 -nodes -days 3650 \
   -addext "subjectAltName=IP:NEW_IP"
 ```
 
+The new certificate has a new key. Agents re-pin it with `lamaste-agent panel reset-pin`, the desktop app with **Re-pin** on the server's card; compare both with `sudo lamaste-server panel-pin` on the new server. Until then they refuse the panel at its IP address.
+
 **Step 7: Update DNS records** to point to the new IP
 
 **Step 8: Fix permissions (same as Step 3 above)**

package/vendor/docs/05-operations/uninstalling.md

@@ -29,7 +29,7 @@ It stops and disables the panel, gatekeeper, Chisel and Authelia; removes their
 The manual guide is also available from the CLI:
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --uninstall
+npx @lamalibre/create-lamaste@4.3.1 --uninstall
 ```
 
 This prints the same steps listed below.

package/vendor/docs/05-operations/upgrades.md

@@ -27,7 +27,7 @@ Coming from 3.x, upgrade the **agents first**, as 4.0 required: agents from befo
 On each agent machine, after the server:
 
 ```bash
-sudo npm install -g @lamalibre/lamaste-agent@4.3.0
+sudo npm install -g @lamalibre/lamaste-agent@4.3.1
 lamaste-agent update
 ```
 
@@ -84,7 +84,7 @@ exit
 
 ### Updating Chisel
 
-Chisel is the tunnel server binary at `/usr/local/bin/chisel`. Lamaste pins it: server and agents run Chisel 1.12.0 (`CHISEL_RELEASE` in `@lamalibre/lamaste@4.3.0`), downloaded from the fixed release URL and verified against a pinned SHA-256 before it is unpacked. **Do not replace the binary by hand.** On the server, `create-lamaste` installs it (as root) and replaces a binary that reports any other version; the panel cannot install binaries, and only logs an error at startup when the installed Chisel is not the pinned release (it then restarts Chisel on every authfile change). Each agent's sync replaces its own copy.
+Chisel is the tunnel server binary at `/usr/local/bin/chisel`. Lamaste pins it: server and agents run Chisel 1.12.0 (`CHISEL_RELEASE` in `@lamalibre/lamaste@4.3.1`), downloaded from the fixed release URL and verified against a pinned SHA-256 before it is unpacked. **Do not replace the binary by hand.** On the server, `create-lamaste` installs it (as root) and replaces a binary that reports any other version; the panel cannot install binaries, and only logs an error at startup when the installed Chisel is not the pinned release (it then restarts Chisel on every authfile change). Each agent's sync replaces its own copy.
 
 A new Chisel version therefore arrives with a Lamaste release that changes the pin: re-run the installer, which installs it and restarts Chisel. To check what is running:
 
@@ -98,7 +98,7 @@ Tunnel clients reconnect on their own after the brief interruption (they retry a
 
 ### Updating Authelia
 
-Authelia is the authentication server binary at `/usr/local/bin/authelia`. Lamaste pins it too: Authelia 4.39.28 (`AUTHELIA_RELEASE` in `@lamalibre/lamaste@4.3.0`), downloaded by `create-lamaste` from its fixed release URL and verified against a pinned SHA-256 per architecture. A new Authelia version arrives with a Lamaste release that changes the pin — re-run the installer. It stops Authelia while it replaces the binary and starts it again.
+Authelia is the authentication server binary at `/usr/local/bin/authelia`. Lamaste pins it too: Authelia 4.39.28 (`AUTHELIA_RELEASE` in `@lamalibre/lamaste@4.3.1`), downloaded by `create-lamaste` from its fixed release URL and verified against a pinned SHA-256 per architecture. A new Authelia version arrives with a Lamaste release that changes the pin — re-run the installer. It stops Authelia while it replaces the binary and starts it again.
 
 An installed Authelia **newer** than the pin is kept, never downgraded: its database may already use a schema the pinned release cannot read, and Authelia refuses to start on a database newer than itself. If you install a newer release by hand, stop the service, replace the binary as root with a `root:root 0755` file, and start it again; check the [Authelia changelog](https://github.com/authelia/authelia/blob/master/CHANGELOG.md) first, since the configuration format may change between versions.
 
@@ -237,7 +237,7 @@ The panel server, CLI, client, docs and gatekeeper are always redeployed (files
 
 ### Version Pinning
 
-Chisel and Authelia are pinned by version and SHA-256 in `packages/core/lib/src/constants.ts` (`CHISEL_RELEASE`, `AUTHELIA_RELEASE`); changing a pin means updating the version and every digest there. The downloads are verified by `downloadVerifiedChisel` / `downloadVerifiedAuthelia` (exported from `@lamalibre/lamaste@4.3.0`) before anything is unpacked; the server installer uses them in `packages/provisioners/server/src/lib/binaries.js`. The configuration the panel writes needs Authelia 4.38 or later.
+Chisel and Authelia are pinned by version and SHA-256 in `packages/core/lib/src/constants.ts` (`CHISEL_RELEASE`, `AUTHELIA_RELEASE`); changing a pin means updating the version and every digest there. The downloads are verified by `downloadVerifiedChisel` / `downloadVerifiedAuthelia` (exported from `@lamalibre/lamaste@4.3.1`) before anything is unpacked; the server installer uses them in `packages/provisioners/server/src/lib/binaries.js`. The configuration the panel writes needs Authelia 4.38 or later.
 
 ### Automated Updates
 
@@ -259,7 +259,7 @@ sudo dpkg-reconfigure -plow unattended-upgrades
 | Panel server | `/opt/lamalibre/lamaste/lamaste-serverd/`      | Re-run `npx @lamalibre/create-lamaste@latest`         |
 | Panel client | `/opt/lamalibre/lamaste/lamaste-server-ui/`    | Re-run `npx @lamalibre/create-lamaste@latest`         |
 | Chisel       | `/usr/local/bin/chisel`                        | Pinned; installed by `create-lamaste`                 |
-| Agents       | `sudo npm install -g @lamalibre/lamaste-agent@4.3.0` | Upgrade after the server, then `lamaste-agent update` |
+| Agents       | `sudo npm install -g @lamalibre/lamaste-agent@4.3.1` | Upgrade after the server, then `lamaste-agent update` |
 | Authelia     | `/usr/local/bin/authelia`                      | Pinned; installed by `create-lamaste` (newer is kept) |
 | nginx        | System package                                 | `sudo apt-get update && sudo apt-get upgrade`         |
 | certbot      | System package                                 | `sudo apt-get update && sudo apt-get upgrade`         |

package/vendor/docs/06-reference/config-files.md

@@ -823,6 +823,9 @@ Stores the server registry for the desktop app's multi-server support. Created b
 | `adminAuth.method`           | string         | `"p12"` or `"keychain"` — how the admin cert is stored                                              |
 | `adminAuth.p12Path`          | string \| null | Path to admin P12 file (when method is `"p12"`)                                                     |
 | `adminAuth.keychainIdentity` | string \| null | Keychain identity for admin cert (when method is `"keychain"`)                                      |
+| `panelServerPubkeySha256`    | string         | The pin of the panel's TLS key for a panel reached at its IP address (see below)                    |
+| `panelServerPinnedAt`        | string         | ISO 8601 timestamp of the pin                                                                       |
+| `panelServerPinSource`       | string         | `ssh`, `installer`, `local`, `agent`, `first-use` or `re-pin` (see below)                           |
 
 **Example:**
 
@@ -853,6 +856,8 @@ Stores the server registry for the desktop app's multi-server support. Created b
 
 **Notes on `adminAuth`:** When `adminAuth` is present and valid, the desktop app shows the Agents/Servers mode toggle in the sidebar. Cloud-provisioned servers populate `adminAuth` automatically (the admin certificate is downloaded during provisioning). For manually added servers, the user must import an admin certificate to enable Server mode.
 
+**Panel key pin:** At its IP address (`https://<ip>:9292`) the panel serves a self-signed certificate, so the app verifies every call to it by `panelServerPubkeySha256` — the base64 SHA-256 of the certificate's public key (SubjectPublicKeyInfo), curl's `--pinnedpubkey sha256//…` form and the same value an agent's config holds. `panelServerPinSource` says where it came from: `ssh` (read from the server over SSH by cloud provisioning or an admin recovery), `installer` (a local install, from the installer's report), `local` (a local install imported, or installed by an older installer: read from the certificate file through `pkexec`), `agent` (migrated from the agent's `agent.json`), `first-use` (taken from the first connection) or `re-pin` (the user replaced it on the Servers page, the only way it changes). A panel reached at its domain has no pin: its Let's Encrypt certificate is verified normally. `sudo lamaste-server panel-pin` on the relay prints the value to compare with.
+
 **P12 password:** Not stored in the JSON file. Retrieved from the OS credential store (`com.lamalibre.lamaste.server` service, keyed by server UUID).
 
 **Cloud API token:** Not stored in this file. Retrieved from the OS credential store (`com.lamalibre.cloud` service).
@@ -920,7 +925,7 @@ Service files use per-agent names:
 - macOS: `com.lamalibre.lamaste.chisel-<label>` (plist label), `~/Library/LaunchAgents/com.lamalibre.lamaste.chisel-<label>.plist` — mode 0600, because it carries `AUTH` in `EnvironmentVariables`
 - Linux: `lamalibre-lamaste-chisel-<label>` (unit name), `~/.config/systemd/user/lamalibre-lamaste-chisel-<label>.service` — a systemd **user** unit with `EnvironmentFile=` pointing at `chisel.env`; enable lingering (`sudo loginctl enable-linger <user>`) for it to start at boot without a login
 
-Both run `chisel client --max-retry-interval 30s https://tunnel.<domain>:443 R:127.0.0.1:<port>:127.0.0.1:<port> ...` with TLS verification and no credential in argv. They are generated by `@lamalibre/lamaste@4.3.0/agent` (`chisel-service.ts`) and rewritten by `lamaste-agent setup`, `update` and `sync` — do not edit them by hand. An agent carrying no tunnels has its service unloaded (Chisel cannot run without a remote).
+Both run `chisel client --max-retry-interval 30s https://tunnel.<domain>:443 R:127.0.0.1:<port>:127.0.0.1:<port> ...` with TLS verification and no credential in argv. They are generated by `@lamalibre/lamaste@4.3.1/agent` (`chisel-service.ts`) and rewritten by `lamaste-agent setup`, `update` and `sync` — do not edit them by hand. An agent carrying no tunnels has its service unloaded (Chisel cannot run without a remote).
 
 The sync timer, which runs `<node> <installed lamaste-agent> sync --label <label> --quiet` (`<node>` is a stable path such as `/opt/homebrew/bin/node` when one on `PATH` resolves to the running binary, so a Node.js upgrade does not break it):
 

package/vendor/docs/06-reference/glossary.md

@@ -24,7 +24,7 @@ If you are reading documentation and hit an unfamiliar term, this is the place t
 
 **Where it appears:**
 
-- Enrolled from the panel (**Certificates → Enrollment Token**) and `lamaste-agent setup` (installed globally with `npm install -g @lamalibre/lamaste-agent@4.3.0`)
+- Enrolled from the panel (**Certificates → Enrollment Token**) and `lamaste-agent setup` (installed globally with `npm install -g @lamalibre/lamaste-agent@4.3.1`)
 - Agent registry: `/etc/lamalibre/lamaste/agents.json` on the server; `~/.lamalibre/lamaste/agents/<label>/` on the agent
 - The **Agent** column and field on the panel's Tunnels page
 
@@ -242,7 +242,7 @@ See also: [mTLS](#mtls-mutual-tls), [CA](#ca-certificate-authority), [PKCS12](#p
 
 **Where it appears:**
 
-- Generated by `lamaste-agent setup` / `update` (implementation in `@lamalibre/lamaste@4.3.0/agent`)
+- Generated by `lamaste-agent setup` / `update` (implementation in `@lamalibre/lamaste@4.3.1/agent`)
 - Installed to `~/Library/LaunchAgents/com.lamalibre.lamaste.chisel-<label>.plist` on the agent
 - Manages the Chisel client process lifecycle
 
@@ -373,7 +373,7 @@ See also: [Client Certificate](#client-certificate), [CA](#ca-certificate-author
 
 **Plain English:** A small scheduled job on every agent that checks with the panel every 30 seconds and adjusts the tunnel client when the agent's tunnels changed — so tunnels created, disabled or moved in the panel reach the agent without anyone running a command on it.
 
-**Technical:** Runs `lamaste-agent sync --label <label>`, which fetches `GET /api/tunnels/agent-config` and converges the agent's Chisel client with it (relay URL, credential, pinned binary, granted remotes, running or stopped). It exists because Chisel rejects a client's whole session when one requested remote is not granted: an agent must drop a revoked tunnel promptly or all its other tunnels go dark. Requires a global install of `@lamalibre/lamaste-agent@4.3.0`.
+**Technical:** Runs `lamaste-agent sync --label <label>`, which fetches `GET /api/tunnels/agent-config` and converges the agent's Chisel client with it (relay URL, credential, pinned binary, granted remotes, running or stopped). It exists because Chisel rejects a client's whole session when one requested remote is not granted: an agent must drop a revoked tunnel promptly or all its other tunnels go dark. Requires a global install of `@lamalibre/lamaste-agent@4.3.1`.
 
 **Where it appears:**
 

package/vendor/docs/06-reference/installer-flags.md

@@ -1,11 +1,11 @@
 # Installer Flags
 
-> CLI flags, environment variables, and exit codes for `npx @lamalibre/create-lamaste@4.3.0`.
+> CLI flags, environment variables, and exit codes for `npx @lamalibre/create-lamaste@4.3.1`.
 
 ## Usage
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 [flags]
+npx @lamalibre/create-lamaste@4.3.1 [flags]
 ```
 
 The installer runs as root on a fresh Ubuntu 24.04 server. It is completely non-interactive by default — all configuration happens later through the browser-based onboarding wizard.
@@ -26,7 +26,7 @@ The installer runs as root on a fresh Ubuntu 24.04 server. It is completely non-
 Prints a description of what the installer does, lists all flags, and exits with code 0. Does not modify anything on the system.
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --help
+npx @lamalibre/create-lamaste@4.3.1 --help
 ```
 
 ### `--yes`, `-y`
@@ -34,7 +34,7 @@ npx @lamalibre/create-lamaste@4.3.0 --help
 Skips the interactive confirmation prompt that appears before installation begins. Useful for automated deployments or scripts where you cannot press Enter.
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --yes
+npx @lamalibre/create-lamaste@4.3.1 --yes
 ```
 
 Without this flag, the installer displays a banner listing all changes it will make and waits for the user to press Enter or Ctrl+C.
@@ -51,7 +51,7 @@ Skips all OS hardening tasks:
 Everything else (Node.js, nginx, mTLS, panel deployment) still runs.
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --skip-harden
+npx @lamalibre/create-lamaste@4.3.1 --skip-harden
 ```
 
 Use this if you manage your own firewall rules, already have fail2ban configured, or are running on a platform that handles security at a different layer.
@@ -61,7 +61,7 @@ Use this if you manage your own firewall rules, already have fail2ban configured
 Allows the installer to run on a machine with a private or non-routable IP address (e.g., `192.168.x.x`, `10.x.x.x`). By default, the installer requires a public IP.
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --dev
+npx @lamalibre/create-lamaste@4.3.1 --dev
 ```
 
 This is useful for:
@@ -76,7 +76,7 @@ When `--dev` is active, the installer prints the detected IP with a note: `(dev
 Forces the installer to run the complete installation pipeline, ignoring skip guards that would normally detect an existing installation. This is useful when an installation is in an inconsistent state and you want to ensure all components are fully deployed.
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --force-full
+npx @lamalibre/create-lamaste@4.3.1 --force-full
 ```
 
 Use this if:
@@ -90,7 +90,7 @@ Use this if:
 Prints a step-by-step guide for manually removing Lamaste from the server, then exits with code 0. Does not modify anything on the system.
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --uninstall
+npx @lamalibre/create-lamaste@4.3.1 --uninstall
 ```
 
 The printed guide first points to the automated removal, `sudo lamaste-server uninstall`, then covers:
@@ -207,25 +207,25 @@ Components that are always redeployed on re-run:
 
 ```bash
 ssh root@203.0.113.42
-npx @lamalibre/create-lamaste@4.3.0
+npx @lamalibre/create-lamaste@4.3.1
 ```
 
 **Automated install (no confirmation prompt):**
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --yes
+npx @lamalibre/create-lamaste@4.3.1 --yes
 ```
 
 **Install without OS hardening:**
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --yes --skip-harden
+npx @lamalibre/create-lamaste@4.3.1 --yes --skip-harden
 ```
 
 **Test in a local VM:**
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --dev
+npx @lamalibre/create-lamaste@4.3.1 --dev
 ```
 
 **Update an existing installation:**
@@ -237,7 +237,7 @@ npx @lamalibre/create-lamaste@latest --yes
 **View the uninstall guide:**
 
 ```bash
-npx @lamalibre/create-lamaste@4.3.0 --uninstall
+npx @lamalibre/create-lamaste@4.3.1 --uninstall
 ```
 
 ## Quick Reference

package/vendor/docs/06-reference/ports-and-services.md

@@ -34,7 +34,7 @@ A tunnel's port is also a loopback port on the relay: its vhost proxies to `127.
 | 9292 | IP-based panel listener |
 | 9294 | Gatekeeper              |
 
-A tunnel on one of them would publish that internal service on a public hostname. For the panel that is an administrator takeover, not a leak: the panel trusts the client-certificate headers nginx sets. `RESERVED_TUNNEL_PORTS` in `@lamalibre/lamaste@4.3.0` is enforced by the request schema, inside the tunnel workflow, and again when the Chisel grants are rendered. Tunnel ports must also be 1024–65535.
+A tunnel on one of them would publish that internal service on a public hostname. For the panel that is an administrator takeover, not a leak: the panel trusts the client-certificate headers nginx sets. `RESERVED_TUNNEL_PORTS` in `@lamalibre/lamaste@4.3.1` is enforced by the request schema, inside the tunnel workflow, and again when the Chisel grants are rendered. Tunnel ports must also be 1024–65535.
 
 ## Systemd Units