# vSEAL Quickstart — Lab Evaluation Guide

vSEAL automates the golden image seal and engage cycle -- the same workflow you handle today with manual scripts or tools like BIS-F. This guide walks you through evaluating vSEAL in your lab environment in about an hour, across three progressive scenarios. You will go from unzipping a portable distribution to running a full seal/engage cycle on a master image, and finish by writing your own custom plugin -- all in TOML configuration, no scripting required.

## What You're Evaluating

vSEAL is not a BIS-F replacement today. It does not ship with 60 product-specific scripts covering Citrix, VMware, Sophos, McAfee, and every other product in your stack. The built-in plugins are working examples that demonstrate patterns -- they exist to show you how the framework operates, not to provide turnkey coverage for every product.

What vSEAL does ship with is an engineered foundation built to solve problems you already know from experience:

- **Declarative plugins** -- Write TOML configuration instead of PowerShell scripts. A service disable/enable is 15 lines of config, not 200 lines of scripting. You will see this firsthand in Scenario 3.
- **Analyze mode** -- See exactly what vSEAL would change before it changes anything. No more "run it and hope." You will use this in Scenario 1.
- **Automatic rollback** -- vSEAL captures a baseline of the pre-seal state. If something goes wrong, `vseal rollback` undoes it without needing a VM snapshot.
- **Plugin isolation** -- One broken plugin cannot crash another. Each runs in its own sandbox. A syntax error in your custom plugin will not take down the Defender optimization.
- **Smart engage** -- vSEAL automatically detects whether it is on the master or a clone by tracking the computer name. No manual "skip on master" configuration needed.
- **Portable distribution** -- Unzip and run. No installation, no module registration, no dependency hunting. Everything is self-contained.

The goal of this evaluation is to test the engine, not judge plugin coverage. Does the seal/engage cycle work reliably? Does analyze give you confidence before committing changes? Can you write a custom plugin for your environment in 10 minutes? If the answer is yes, then building production plugins for your specific stack is straightforward -- the hard problems are already solved.

## Prerequisites

> **Before you start, you need:**
>
> | Requirement | Details |
> |-------------|---------|
> | **Operating System** | Windows 11 or Windows Server 2022+ |
> | **PowerShell 7.4+** | Install: `winget install Microsoft.PowerShell` -- then use **`pwsh`**, not `powershell` |
> | **Admin rights** | vSEAL needs elevation for registry and service operations |
> | **vSEAL portable ZIP** | The self-contained distribution you received -- extract and run, no installer needed |
> | **VM snapshots** | Recommended before Scenario 2 -- standard lab safety practice |
>
> **Important:** Windows ships with PowerShell 5.1 (`powershell.exe`). vSEAL requires PowerShell 7.4 or later (`pwsh.exe`). If you run `pwsh` and get "command not found," install it with the winget command above, then open a new terminal.

## At a Glance

The three scenarios build on each other. Each ends with a checkpoint so you can pause and pick up later.

| Scenario | Title | Time | What You'll Do | System Changes? |
|----------|-------|------|----------------|-----------------|
| 1 | First Contact | ~15 min | Unzip, verify environment, explore plugins, preview seal | None |
| 2 | Full Cycle | ~25 min | Seal the master image, engage on a clone, verify both | Yes (reversible with snapshot) |
| 3 | Your Environment | ~20 min | Write a custom config and declarative plugin, test it end-to-end | Yes (reversible with snapshot) |

**Total time:** approximately 1 hour. Scenario 1 is completely safe -- zero system changes.

## Conventions

- **All commands** are shown as `.\vseal.exe <command>`, run from the extracted folder in an **elevated PowerShell 7 terminal** (right-click `pwsh` and select "Run as Administrator").
- **Output samples** are abbreviated with `...` where the real output will be longer. Your actual output will vary depending on your environment and installed plugins. The branded header (logo, version, build info) appears at the top of every command in an interactive terminal -- it is omitted from most output samples below for brevity.
- **Platform-specific notes** for Citrix, VMware Horizon, or AVD are called out in blockquotes like this:

  > **Citrix / VMware / AVD:** Platform-specific guidance appears here.

---

## Scenario 1: First Contact

### 1.1 Unzip & Orient

Extract the vSEAL ZIP to a folder on the machine you plan to test with. We recommend `C:\Tools\vSEAL\`, but any location works.

Open **PowerShell 7** as Administrator (right-click `pwsh` and select "Run as Administrator"), then navigate to the extracted folder and confirm vSEAL is working:

```
cd C:\Tools\vSEAL
.\vseal.exe version
```

You should see a branded header with the vSEAL logo followed by version details:

```
░█░█░█▀▀░█▀▀░█▀█░█░░ │ 0.1.19 · MIT License
░▀▄▀░▀▀█░█▀▀░█▀█░█░░ │ built 2026-02-21 14:30 · (c) GoldenImageLabs & friends
░░▀░░▀▀▀░▀▀▀░▀░▀░▀▀▀ │ https://github.com/GoldenImageLabs/vSEAL

  commit: a1b2c3d
  module: 0.1.19
  pwsh:   7.5.4
```

The header includes the vSEAL logo, version, build date, and project URL. In a color-capable terminal the logo renders with a gradient and the metadata is color-coded. The **module** and **pwsh** lines confirm it found the bundled PowerShell module and your PowerShell 7 installation.

### 1.2 Health Check

Run the built-in environment check to verify everything vSEAL needs is in place:

```
.\vseal.exe doctor
```

```
vSEAL Environment Check
────────────────────────────────────────

PowerShell
  ✓ pwsh.exe found: C:\Program Files\PowerShell\7\pwsh.exe
  ✓ Version 7.5.4 (requires 7.4+)

vSEAL Module
  ✓ Installed: C:\Tools\vSEAL\module\vSEAL (portable)
  ✓ Bundled deps: C:\Tools\vSEAL\deps
  ✓ Version 0.1.19

CLI Compatibility
  ✓ CLI v0.1.19 compatible with module v0.1.19

Dependencies
  ✓ PSToml 0.4.0

Plugin Health
  ✓ Plugins: 12 healthy

Plugin Discovery
  ✓ local      C:\Tools\vSEAL\plugins-custom: (not found)
  ✓ shared     C:\ProgramData\vSEAL\plugins: (not found)
  ✓ built-in   C:\Tools\vSEAL\module\vSEAL\Plugins: 12 plugins

Configuration
  ⚠ Config source: Not found at C:\ProgramData\vSEAL\vseal.toml
    Run: vseal config init

────────────────────────────────────────
11 passed · 1 warning
```

Here is what each section tells you:

- **PowerShell** -- Confirms PowerShell 7.4+ is installed and reachable.
- **vSEAL Module** -- The bundled PowerShell module loaded correctly from the portable folder.
- **CLI Compatibility** -- The CLI and module versions are compatible with each other.
- **Dependencies** -- Required modules (PSToml for configuration parsing) are bundled and available.
- **Plugin Health** -- All discovered plugins passed validation.
- **Plugin Discovery** -- Shows where vSEAL looks for plugins: a local custom folder, a shared folder, and the built-in plugins that ship with vSEAL.
- **Configuration** -- Checks for a config file at the default location. The warning (⚠) is expected -- we have not placed a config there yet. We will point at a config file explicitly in step 1.4.

All checks passing except the config warning? You are good to continue.

### 1.3 Explore Plugins

See which plugins are available:

```
.\vseal.exe plugins
```

```
Available Plugins
────────────────────────────────────────

╭──────────────────────┬───────────┬─────────┬────────┬──────────╮
│ Name                 │ Category  │ Version │ Status │ Source   │
├──────────────────────┼───────────┼─────────┼────────┼──────────┤
│ bloatware            │ bloatware │ 1.0.0   │ Valid  │ built-in │
│ example-declarative  │ example   │ 1.0.0   │ Valid  │ built-in │
│ example-defender     │ example   │ 1.0.0   │ Valid  │ built-in │
│ example-engine       │ example   │ 1.0.0   │ Valid  │ built-in │
│ example-eventlogs    │ example   │ 1.0.0   │ Valid  │ built-in │
│ example-hybrid       │ example   │ 1.0.0   │ Valid  │ built-in │
│ example-imperative   │ example   │ 1.0.0   │ Valid  │ built-in │
│ example-minimal      │ example   │ 1.0.0   │ Valid  │ built-in │
│ example-office       │ example   │ 1.0.0   │ Valid  │ built-in │
│ example-pagefile     │ example   │ 1.0.0   │ Valid  │ built-in │
│ example-sccm         │ example   │ 1.0.0   │ Valid  │ built-in │
│ test-schema          │ test      │ 1.0.0   │ Valid  │ built-in │
╰──────────────────────┴───────────┴─────────┴────────┴──────────╯
12 valid, 0 skipped, 0 errors
```

The **STATUS** column tells you whether each plugin is ready to run:

- **Valid** -- The plugin is loaded and ready. This is what you want to see.
- **Skipped** -- The plugin has requirements not met on this machine (for example, a Citrix-specific plugin on a VMware host). This is normal behavior, not an error.
- **Error** -- Something is wrong with the plugin definition itself. Rare with built-in plugins.

The built-in example plugins cover the kinds of tasks you already do during image sealing: Windows Defender optimization, SCCM client handling, event log clearing, pagefile management, Office cache cleanup, and bloatware removal. They serve as working references that demonstrate different plugin patterns -- from simple TOML declarations to more advanced hybrid approaches.

For more detail on any plugin, run `.\vseal.exe plugins --detail`.

### 1.4 Dry Run with Analyze

Now preview what a seal operation would actually do -- without touching the system. We point at the included skeleton config so vSEAL has a configuration to work with:

```
.\vseal.exe seal --analyze --config .\examples\vseal.skeleton.toml
```

```
  Config:     .\examples\vseal.skeleton.toml
  Preflight:  module 0.1.19, PowerShell 7.5.4
  Mode:       Analyze
  Analyzing Seal...

✓ example-defender   up to date  (up to date)
✓ example-sccm       up to date  (up to date)
✓ example-declarative 5 changes, 6 no-op  (rollback: no)
✓ example-hybrid     2 changes, 5 no-op  (rollback: yes)
✓ example-pagefile   up to date  (up to date)
✓ example-imperative up to date  (up to date)
✓ example-minimal    up to date  (up to date)
✓ example-engine     up to date  (up to date)

✓ Analyze complete  7 changes across 8 plugins  (2.5s)
```

Here is how to read the output:

- **X changes** -- Actions that would modify the system (registry writes, service changes, etc.) if you ran seal for real.
- **up to date** -- The plugin checked the system and found nothing to change. The desired state already matches.
- **rollback: yes / no** -- Whether the plugin captures a baseline so the changes can be undone later. Plugins with rollback support let you revert to pre-seal state if needed.

This is the output you would review before running seal on a production master image. It gives you full visibility into what every plugin plans to do -- before any change is made.

### Checkpoint

You have confirmed:

- vSEAL runs on your machine and found all its dependencies (version + doctor)
- 12 built-in plugins are loaded and valid
- You previewed exactly what a seal operation would do, plugin by plugin
- You understand the analyze output: changes, no-ops, and rollback support

**No system changes were made.** Everything in this scenario was read-only.

---

## Scenario 2: Full Cycle

### 2.1 Understand the Workflow

In VDI, sealing and engaging are two sides of the same coin:

```
    Master Image                             Clone (provisioned VM)
    ┌─────────────────────┐                  ┌─────────────────────┐
    │  .\vseal seal       │  ── deploy ──>   │  .\vseal engage     │
    │                     │                  │                     │
    │  Disables services  │                  │  Restores services  │
    │  Optimizes registry │                  │  Reverts registry   │
    │  Clears caches      │                  │  Prepares for user  │
    └─────────────────────┘                  └─────────────────────┘
```

**How vSEAL tells them apart:** When you seal, vSEAL records the computer name of the machine that performed the seal. When you run engage, vSEAL checks: "Am I on the same machine that sealed?"

- **Same computer name** -- skips engage. You are on the master. Undoing the seal here is never what you want.
- **Different computer name** -- runs engage. You are on a clone. Restore operational state.

This means engage can safely run at every boot. On the master it is a no-op. On clones it does the right thing. In production, you would run engage via a startup script or scheduled task -- that feature is planned but not yet implemented, so we will test it manually.

### 2.2 Snapshot the Master

Take a VM snapshot now before making changes. This is your safety net.

> **Citrix:** Hypervisor snapshot via XenCenter or vSphere.
> **VMware:** vSphere snapshot or Horizon image checkpoint.
> **AVD:** Azure VM snapshot or image version save.

Standard lab practice -- you would do this before running any sealing tool.

### 2.3 Seal the Master

Run the seal operation against the skeleton config:

```
.\vseal.exe seal --config .\examples\vseal.skeleton.toml
```

```
  Config:     .\examples\vseal.skeleton.toml
  Preflight:  module 0.1.19, PowerShell 7.5.4
  Starting Seal...

✓ [1/8] example-defender (400ms)
✓ [2/8] example-sccm (300ms)
✓ [3/8] example-declarative (500ms)
✓ [4/8] example-hybrid (400ms)
✓ [5/8] example-pagefile (200ms)
✓ [6/8] example-imperative (300ms)
✓ [7/8] example-minimal (100ms)
✓ [8/8] example-engine (200ms)

✓ Seal complete  8 plugins, 0 failed  (3.1s)
  Baseline:  20260221_143022
  Computer:  YOURHOST
```

Each plugin ran in priority order. The summary confirms all eight succeeded with zero failures.

Two things to note in the summary:

- **Baseline** -- An ID referencing the saved pre-seal state. You will inspect this next.
- **Computer** -- The machine that sealed. This is the value vSEAL uses to distinguish master from clone.

Detailed logs are written to `C:\ProgramData\vSEAL\logs\vseal.log` if you want to inspect individual plugin actions.

### 2.4 Inspect Seal State

Check what vSEAL recorded:

```
.\vseal.exe status
```

```
Last Run Status
────────────────────────────────────────

Seal Phase
  Result:   Success
  Computer: YOURHOST
  Time:     2026-02-21T14:30:22
  Version:  0.1.19
  Plugins:  8 run, 0 failed
```

The computer name is how vSEAL knows "this is the master." When engage runs on a clone with a different name, vSEAL knows to proceed. The Engage Phase section will appear once engage has been run.

Now check the baseline that was captured during seal:

```
.\vseal.exe baselines
```

```
Available Baselines
────────────────────────────────────────

╭─────────────────┬────────────┬──────────────────────┬─────────┬────────╮
│ ID              │ OS         │ Created              │ Plugins │ Status │
├─────────────────┼────────────┼──────────────────────┼─────────┼────────┤
│ 20260221_143022 │ Windows 11 │ Feb 21, 2026 14:30   │ 4       │ valid  │
╰─────────────────┴────────────┴──────────────────────┴─────────┴────────╯
1 baselines
```

The baseline captures the state **before** seal made changes. This is how engage knows what to restore on clones. For a closer look at what the baseline contains, run `.\vseal.exe baselines show 20260221_143022`.

### 2.5 Try Engage on Master

Now try running engage on the same machine that sealed. This should **not** work -- and that is the correct behavior.

```
.\vseal.exe engage --config .\examples\vseal.skeleton.toml
```

```
  Config:     .\examples\vseal.skeleton.toml
  Preflight:  module 0.1.19, PowerShell 7.5.4
  Starting Engage...

— Engage skipped  Running on seal machine (YOURHOST)  (400ms)
```

This is correct. vSEAL detected that your computer name matches the seal record. Engaging the master would undo the seal -- which is never what you want. The skip is automatic and requires no configuration.

### 2.6 Test Engage on a Clone

To see engage in action, you need a machine with a **different computer name** that has access to the seal record. There are a few ways to get one:

- **Best:** Provision a clone from the sealed master using your VDI platform (Citrix MCS/PVS, Horizon linked clones, AVD session hosts).
- **Alternative:** Create a linked clone or full clone in the hypervisor directly.

On the clone, copy or mount the vSEAL portable folder (or access it via a network share), then run:

```
.\vseal.exe engage --config .\examples\vseal.skeleton.toml
```

```
  Config:     .\examples\vseal.skeleton.toml
  Preflight:  module 0.1.19, PowerShell 7.5.4
  Starting Engage...

✓ [1/8] example-defender (300ms)
✓ [2/8] example-sccm (300ms)
✓ [3/8] example-declarative (400ms)
✓ [4/8] example-hybrid (300ms)
✓ [5/8] example-pagefile (200ms)
✓ [6/8] example-imperative (200ms)
✓ [7/8] example-minimal (100ms)
✓ [8/8] example-engine (200ms)

✓ Engage complete  8 plugins, 0 failed  (2.4s)
  Computer:  YOURCLONE
```

vSEAL detected a different computer name and ran engage. Plugins restored operational state in the same priority order they were sealed.

### 2.7 Verify

On the clone, check the status:

```
.\vseal.exe status
```

```
Last Run Status
────────────────────────────────────────

Seal Phase
  Result:   Success
  Computer: YOURHOST
  Time:     2026-02-21T14:30:22
  Version:  0.1.19
  Plugins:  8 run, 0 failed

Engage Phase
  Result:   Success
  Computer: YOURCLONE
  Time:     2026-02-21T14:45:10
  Version:  0.1.19
  Plugins:  8 run, 0 failed
```

The status now shows both phases: seal ran on YOURHOST, engage ran on YOURCLONE. This is the complete lifecycle.

In production, engage would run automatically at clone boot via a startup script or scheduled task. That feature is planned but not yet implemented, which is why we ran it manually here.

### Checkpoint

You have completed the core VDI lifecycle:

- **Sealed** the master image -- optimizations applied by all plugins
- **Confirmed** engage skips on the master -- the safety check works
- **Engaged** a clone -- operational state restored automatically
- **Verified** vSEAL tracks master vs. clone by computer name

This is the workflow your master images would follow in production.

---

## Scenario 3: Your Environment

### 3.1 Pick a Target

Think about one thing you currently do manually during image preparation. Common examples:

- **A Windows service** -- Print Spooler, Windows Update (wuauserv), BITS, SysMain (Superfetch)
- **A registry key** -- disable Cortana, disable first-run animations, disable Consumer Features
- **A scheduled task** -- telemetry collection, disk defragmentation on SSD-based images

Pick one. We will use **Print Spooler** as the running example because it is present on every Windows machine, safe to disable in a sealed image, and easy to verify. Substitute your own target if you prefer.

### 3.2 Create a Custom Config

Copy the skeleton config to a new file you can edit freely:

```
Copy-Item .\examples\vseal.skeleton.toml .\vseal-mylab.toml
```

Open `vseal-mylab.toml` in a text editor (Notepad, VS Code, whatever you use). At the bottom of the file, add a section for the plugin you are about to create:

```toml
[plugins.my-lab-plugin]
enabled = true
```

That is the only required edit. The example plugins will still run alongside yours. If you want a quieter run that only exercises your plugin, set `enabled = false` on the example plugins you do not need -- but this is optional.

### 3.3 Write a Declarative Plugin

A declarative plugin is a folder containing two TOML files: one for metadata, one for the actions. No PowerShell scripting required.

**1. Create the plugin folder.** The portable distribution includes a `plugins-custom\` directory for your own plugins:

```
mkdir .\plugins-custom\my-lab-plugin
```

**2. Create the metadata file** `plugins-custom\my-lab-plugin\plugin.toml` with the following content:

```toml
[plugin]
name = "my-lab-plugin"
version = "1.0.0"
category = "custom"
phases = ["seal", "engage"]
priority = 50
description = "Lab-specific service management"
```

**3. Create the template file** `plugins-custom\my-lab-plugin\my-lab.toml` with the actions to perform during seal:

```toml
[template]
name = "Lab Service Management"
version = "1.0.0"
description = "Manages services for lab image optimization"

[[groups]]
name = "Optimize Services"

[[groups.actions]]
type = "service"
operation = "disable"
name = "Spooler"
description = "Disable Print Spooler for sealed image"
```

**That is it -- two files, both TOML.** vSEAL discovers the folder, reads the metadata and template, and executes the actions during seal. When a declarative service action disables a service, vSEAL automatically captures the original service state as a baseline entry. During engage (or rollback), vSEAL restores the service to that captured state -- no separate engage group is needed. No scripting, no registration, no configuration beyond what you already did.

Your plugin folder should look like this:

```
plugins-custom\
└── my-lab-plugin\
    ├── plugin.toml
    └── my-lab.toml
```

### 3.4 Analyze First

Before making any changes, preview the run to confirm your plugin was discovered:

```
.\vseal.exe seal --analyze --config .\vseal-mylab.toml
```

Look for `my-lab-plugin` in the output. You should see it listed with one change (the Spooler service disable):

```
✓ my-lab-plugin     1 changes  (rollback: no)
```

If the plugin does not appear: verify the folder is in `plugins-custom\`, check that `plugin.toml` has valid TOML syntax (watch for missing quotes or brackets), and run `.\vseal.exe doctor` to confirm plugin discovery shows the correct count.

### 3.5 Seal & Engage with Custom Config

**Take a snapshot** of your VM before proceeding -- same as in Scenario 2.

**Seal with your custom config:**

```
.\vseal.exe seal --config .\vseal-mylab.toml
```

**Verify the service was actually disabled.** In the same elevated PowerShell session:

```
Get-Service Spooler | Select-Object Status, StartType
```

You should see `Status: Stopped` and `StartType: Disabled`. Your plugin worked.

**Engage on a clone** to confirm the service is restored. If you provisioned a clone from the sealed master:

```
.\vseal.exe engage --config .\vseal-mylab.toml
```

For quick local validation, you can revert to your VM snapshot and run engage there instead. Note that this bypasses the computer name check (the name will match the seal machine), so vSEAL will skip engage. To work around this in a lab-only scenario, provision a proper clone or rename the machine before engaging.

After engage completes on a clone, verify the service is back to its original state:

```
Get-Service Spooler | Select-Object Status, StartType
```

The service should show `Status: Running` and `StartType: Automatic` -- restored automatically from the baseline captured during seal.

### Checkpoint

You have written a custom vSEAL plugin in pure TOML:

- Created a plugin folder with metadata (`plugin.toml`) and a template (`my-lab.toml`)
- vSEAL discovered it automatically alongside the built-in plugins
- It sealed and engaged your chosen target correctly

This is how you extend vSEAL for your environment -- one plugin per concern, all declarative, no scripting required for standard operations like services, registry keys, and scheduled tasks.

---

## Troubleshooting

If you hit a problem during the walkthrough, check here first.

| Symptom | Likely Cause | Fix |
|---------|-------------|-----|
| `Not running as administrator` | Terminal not elevated | Close and reopen PowerShell 7 with "Run as Administrator" |
| `PowerShell 7.4+ required` | Using Windows PowerShell 5.1 (`powershell.exe`) | Use `pwsh.exe` instead. Install: `winget install Microsoft.PowerShell` |
| Doctor shows PSToml missing | ZIP not fully extracted | Extract the ZIP to a real folder -- don't run from inside the archive |
| Plugin shows "Skipped" | Requirements not met on this machine | Normal behavior. The plugin needs software or settings you don't have (e.g., Citrix plugin on a VMware host) |
| Engage skipped on clone | `status.json` not accessible from the clone | Ensure the storage path in your config is reachable from the clone |
| Custom plugin not discovered | Folder in wrong location or bad TOML | Run `.\vseal.exe doctor` to check plugin count. Verify `plugin.toml` syntax. |
| `vseal.exe` won't start | Antivirus blocking unsigned binary | Add an exception for the vSEAL folder -- this is a pre-release build without code signing |

---

## Glossary

vSEAL uses specific terminology for operations you may already know by different names.

| vSEAL Term | What It Means |
|-----------|---------------|
| **Seal** | Optimize the master image for deployment -- disable services, set registry keys, clear caches. Equivalent to BIS-F "Seal" or manual image preparation. |
| **Engage** | Restore operational state on a clone after provisioning -- re-enable services, revert registry changes. Equivalent to BIS-F "Personalize" or a startup script. |
| **Analyze** | Dry-run mode -- shows what seal or engage would do without making changes. Your pre-flight review. |
| **Plugin** | A self-contained optimization module. Each plugin targets one concern (Defender, SCCM, services, etc.). Like a BIS-F script or DVAT module. |
| **Baseline** | A snapshot of system state captured before seal makes changes. Used by engage to know what to restore, and by rollback to undo a seal. |
| **Rollback** | Undo a seal on the master image using the saved baseline. For when you sealed and need to go back without restoring a VM snapshot. |
| **Doctor** | Environment health check -- verifies PowerShell, module, dependencies, plugins, and configuration are all in order. |

---

## What's Next

- **More plugin patterns:** The built-in `example-imperative` and `example-hybrid` plugins show how to use PowerShell for complex logic beyond what TOML templates can express. See their README files in the `Plugins` folder.
- **CI/CD integration:** `.\vseal.exe doctor --json` and `.\vseal.exe seal --json` output machine-readable JSON for pipeline automation.
- **Automated engage:** Running engage automatically at clone boot (via scheduled task or startup script) is planned but not yet implemented. For now, trigger it manually or add it to your existing boot scripts.
