@lamalibre/create-lamaste 4.4.1 → 4.6.0

package/vendor/docs/02-guides/managing-users.md

@@ -4,7 +4,7 @@
 
 ## In Plain English
 
-Every tunneled app in Lamaste is protected by Authelia, a login system that requires a username, password, and a one-time code from an authenticator app. When you create a user in the Lamaste panel, that person can log in to any of your tunneled apps. This guide covers the full lifecycle: creating users, enrolling them in two-factor authentication, changing passwords, and safely removing users.
+Every tunneled app in Lamaste is protected by Authelia, a login system that requires a username, password, and a one-time code from an authenticator app. When you create a user in the Lamaste panel, that person can log in to any of your tunneled apps. This guide covers the full lifecycle: creating users, enrolling them in two-factor authentication, changing passwords, and offboarding them — disabling, deleting and erasing users. The same users can be given roles in agent-hosted plugins ([Agent-Hosted Plugins](../04-api-reference/agent-hosted-plugins.md#users-and-identity)), which know them by a stable user ID.
 
 ## Prerequisites
 
@@ -20,7 +20,7 @@ Log in to the Lamaste admin panel at `https://<ip>:9292`.
 
 Click **Users** in the sidebar navigation.
 
-You see a list of existing users. After onboarding, there is one user: `admin` — the account created during provisioning.
+You see a list of existing users — each with its status (**active** or **disabled**) and its **user ID**, the stable id plugins know the user by (click it to copy). After onboarding, there is one user: `admin` — the account created during provisioning.
 
 ### 2. Add a New User
 
@@ -43,7 +43,7 @@ Fill in the form and click **Create User**.
 1. The panel validates all fields against the schema.
 2. The password is hashed with **bcrypt** (not argon2id — argon2id uses ~93 MB per hash and causes OOM kills on 512 MB droplets).
 3. The user record is written to `/etc/authelia/users.yml` using an atomic write (write to temp file, then rename) to prevent corruption.
-4. Authelia is reloaded to pick up the new user.
+4. The user directory gives the user a `userId` (a UUID v4), then Authelia is reloaded to pick up the new user.
 
 **Expected result:** The new user appears in the list. Share the username and password with the person — they need these to log in to your tunneled apps.
 
@@ -107,22 +107,85 @@ To change a user's display name, email, or group membership:
 
 Only the fields you change are updated — the password and TOTP secret remain the same unless explicitly changed.
 
-### 7. Remove a User
+### 7. Disable a User (Offboarding)
+
+When someone leaves, **disable** them first — it is immediate and reversible:
+
+1. Go to the **Users** page.
+2. Click **Disable** on the user and confirm.
+
+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 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.
+
+```bash
+lamaste-server users disable alice
+lamaste-server users enable alice
+```
+
+### 8. Delete a User
 
 1. Go to the **Users** page.
 2. Click the **Delete** button next to the user you want to remove.
-3. Confirm the deletion.
+3. Leave **Also erase personal data** unchecked to keep a tombstone (see below), or check it to erase at once.
+4. Confirm the deletion.
 
 **Safety rule:** You cannot delete the last user. Lamaste enforces this to prevent locking everyone out of the tunneled apps. If you try to delete the last user, the panel returns an error: "Cannot delete the last user."
 
 **What happens behind the scenes:**
 
-1. The panel removes the user from `users.yml` (atomic write).
-2. Authelia is reloaded.
-3. Any active sessions for that user expire naturally (Authelia does not have a "force logout" mechanism, but sessions have a timeout).
+1. The panel removes the user from `users.yml` (atomic write, under the panel's one lock for user changes) and restarts Authelia.
+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.
+5. The user's registry tokens, desktop sessions and legacy plugin-access grants end.
+
+A user removed from `users.yml` by hand is offboarded the same way within a minute, when the panel notices.
 
 After deletion, the user can no longer log in to any tunneled app.
 
+```bash
+lamaste-server users delete alice           # keeps the tombstone
+lamaste-server users delete alice --erase   # and erases it in the same step
+```
+
+### 9. Erase a Deleted User
+
+A tombstone keeps a name and an address. When a person asks for their personal data to be removed, **erase** it:
+
+1. Go to the **Users** page and scroll to **Deleted users** — every tombstone the directory keeps, with its `userId`, when it was removed and whether Gatekeeper's cleanup is still pending.
+2. Click **Erase** on the user and confirm.
+
+Erasing deletes the user's invitations, Gatekeeper's access-request log entries for them and any second factors Authelia still holds, then scrubs the tombstone to the bare `userId`. Every plugin that ever had the user as a member is sent an erasure: its agent half scrubs its own row and anonymises what the plugin keeps about the user — and never takes the user back afterwards, whatever it is sent later. Until each plugin has acknowledged it, **Deleted users** lists that plugin under the user as a pending erasure — seconds while the hosting agent is online, or when it reconnects. A plugin that was uninstalled while an agent keeps its data, or that no longer declares users, is listed too, marked as not taking the feed: the erasure reaches its data when it comes back, or goes with the data when you purge it (Plugins page, Retained data).
+
+Erasure cannot be undone. It cannot reach what Authelia keeps on its own — the user's OpenID Connect identity (the reason a username that ever signed in to an OpenID Connect application cannot be given to anyone else) and its authentication log — nor nginx's access logs, the system journal's older entries or backups taken before it ([what the logs keep](../05-operations/monitoring.md#logs-and-personal-data)).
+
+```bash
+lamaste-server users directory              # every user the directory knows, tombstones and pending erasures
+lamaste-server users erase 7d9e1a2b-3c4d-4e5f-8a6b-7c8d9e0f1a2b
+```
+
+### Disable, delete or erase?
+
+| Action      | Can sign in | Plugins see                            | Reversible | Use when                                      |
+| ----------- | ----------- | -------------------------------------- | ---------- | --------------------------------------------- |
+| **Disable** | No          | The user, `disabled`                   | Yes        | Someone leaves or must be locked out now      |
+| **Delete**  | No          | A removed user, last name kept         | No         | The account is gone for good; history matters |
+| **Erase**   | —           | A bare `userId`; their data anonymised | No         | The person asked for their data to be removed |
+
+### Re-created usernames
+
+A username that comes back after a deletion — re-created by hand, through an invitation, or edited into `users.yml` — is a **new user with a new `userId`**. Plugins key their data on the `userId`, so the new person sees nothing of the old one's. Before the panel creates the user, Gatekeeper drops everything it holds under the username and Authelia deletes any second factors under it — every time, even when nothing should be left: no grant, group membership, plugin role, TOTP or security key passes from one person to the next, nor a desktop session. If that cannot be done now (Gatekeeper or Authelia's storage unavailable), creating the user is refused with a message saying so — try again later. While a deleted user's username is not held by anyone, nothing can be granted to it (refused with "username_deleted").
+
+**A username that has signed in to an OpenID Connect application cannot be reused.** When a user signs in to an application through Lamaste's OpenID Connect provider (a plugin's login, a registry), Authelia gives them an identifier tied to their username, which it cannot delete. A new person under that username would be the old person to every such application — so the panel refuses to create a user, or accept an invitation, under it (`username_has_oidc_identity`): choose another username, such as `alice2`.
+
 ## For Developers
 
 ### User Storage
@@ -150,13 +213,34 @@ All writes to this file are atomic: write to a temp file, then rename. This prev
 
 ### API Endpoints
 
-| Method   | Path                              | Purpose                                                     |
-| -------- | --------------------------------- | ----------------------------------------------------------- |
-| `GET`    | `/api/users`                      | List all users (sorted alphabetically, no sensitive fields) |
-| `POST`   | `/api/users`                      | Create a new user                                           |
-| `PUT`    | `/api/users/:username`            | Update user fields                                          |
-| `DELETE` | `/api/users/:username`            | Delete a user (not the last one)                            |
-| `POST`   | `/api/users/:username/reset-totp` | Generate a new TOTP secret                                  |
+| Method   | Path                                    | Purpose                                                                                 |
+| -------- | --------------------------------------- | --------------------------------------------------------------------------------------- |
+| `GET`    | `/api/users`                            | List all users (sorted alphabetically, no sensitive fields), with `userId` and `status` |
+| `POST`   | `/api/users`                            | Create a new user                                                                       |
+| `PUT`    | `/api/users/:username`                  | Update user fields; `{ "disabled": true \| false }` disables or enables                 |
+| `DELETE` | `/api/users/:username[?erase=true]`     | Delete a user (not the last one); a tombstone stays unless erased                       |
+| `POST`   | `/api/users/:username/reset-totp`       | Generate a new TOTP secret                                                              |
+| `GET`    | `/api/identity/directory`               | Every user the directory knows, tombstones and pending erasures included                |
+| `POST`   | `/api/identity/directory/:userId/erase` | Erase a removed user                                                                    |
+
+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.
+
+### The CLI
+
+Every command goes through the running panel with the admin certificate (`--json` prints NDJSON):
+
+```bash
+lamaste-server users list                 # username, status, userId, groups
+lamaste-server users disable <username>
+lamaste-server users enable <username>
+lamaste-server users delete <username> [--erase]
+lamaste-server users erase <userId>
+lamaste-server users directory            # tombstones, erasures, pending cleanups and erasures
+```
 
 ### Create User Request
 
@@ -242,14 +326,18 @@ Authelia reads `users.yml` on restart. If the restart fails, a warning is logged
 | **Edit user**       | Users page, "Edit" on user, modify fields, "Save" |
 | **Change password** | Edit user, enter new password, "Save"             |
 | **Reset TOTP**      | Users page, "Reset TOTP" on user, share QR code   |
+| **Disable user**    | Users page, "Disable" on user, confirm            |
 | **Delete user**     | Users page, "Delete" on user, confirm             |
-
-| Constraint       | Value                                           |
-| ---------------- | ----------------------------------------------- |
-| Username format  | `^[a-z0-9][a-z0-9_-]*$` (users and invitations) |
-| Username length  | 2-32 characters                                 |
-| Password length  | 8-128 characters                                |
-| Password hashing | bcrypt (cost 12)                                |
-| Minimum users    | 1 (cannot delete last user)                     |
-| TOTP algorithm   | SHA1, 6 digits, 30-second period                |
-| User file        | `/etc/authelia/users.yml`                       |
+| **Erase user**      | Users page, Deleted users, "Erase", confirm       |
+
+| Constraint       | Value                                                       |
+| ---------------- | ----------------------------------------------------------- |
+| Username format  | `^[a-z0-9][a-z0-9_-]*$` (users and invitations)             |
+| Username length  | 2-32 characters                                             |
+| Password length  | 8-128 characters                                            |
+| Password hashing | bcrypt (cost 12)                                            |
+| Minimum users    | 1 (cannot delete last user)                                 |
+| Administrators   | The last enabled `admins` member cannot be disabled         |
+| User ID          | UUID v4, never reused; a re-created username gets a new one |
+| TOTP algorithm   | SHA1, 6 digits, 30-second period                            |
+| User file        | `/etc/authelia/users.yml`                                   |

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.4.1` 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.6.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.4.1`)
+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`)
 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.4.1` to create the droplet
+- The wizard calls `@lamalibre/lamaste-cloud@4.6.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.4.1` — 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.6.0` — the admin does not need to do anything.
 
 ```mermaid
 sequenceDiagram

package/vendor/docs/02-guides/static-sites.md

@@ -181,6 +181,10 @@ The file browser lets you:
 
 The Let's Encrypt certificate is left in place (certbot manages its lifecycle).
 
+### Sites that belong to a plugin
+
+An agent-hosted plugin can own a site: its **web surface**, where the relay serves the application its users open, from the files its approved version ships ([Web surface](../04-api-reference/agent-hosted-plugins.md#web-surface)). Such a site is listed on the Sites page with the plugin it belongs to, but it is managed on the plugin's card — no uploads, no settings, no deletion here, and `lamaste-agent deploy` refuses it: its files change only with an approved version of the plugin.
+
 ## For Developers
 
 ### Site Data Model

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

@@ -1,6 +1,6 @@
 # Installer Flow
 
-## What `npx @lamalibre/create-lamaste@4.4.1` Does
+## What `npx @lamalibre/create-lamaste@4.6.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.4.1
+$ npx @lamalibre/create-lamaste@4.6.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.4.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.
+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.
 
 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.4.1
+npx @lamalibre/create-lamaste@4.6.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.4.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)
+- 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)
 - 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.4.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.
+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.
 
 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

@@ -263,6 +263,8 @@ lamaste ALL=(root) NOPASSWD: /usr/sbin/nginx -t
 # --- root-owned programs that validate their own arguments ---
 #   lamaste-priv nginx-site write|backup|restore|discard-backup|enable|disable|remove <name>
 #   lamaste-priv authelia-totp <username>                    secret on stdin
+#   lamaste-priv authelia-user purge-second-factors <username>  TOTP + WebAuthn deleted
+#   lamaste-priv authelia-user has-oidc-identifier <username>   prints yes or no
 #   lamaste-priv self-update <version>                       create-lamaste in a transient unit
 #   lamaste-certbot issue <email> <cert-name> <domain>...    certbot certonly --nginx
 #   lamaste-certbot renew <cert-name> [force] | renew-all | list
@@ -276,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.4.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.
+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.
 
 ## File Operation Safety