Desktop beta guide (macOS)

Using Windows? See the Windows tester guide instead. Platform status is in the README.

This guide describes the desktop beta, including the language settings added on 2026-09-09: DesktopStore is already wired up in main.tsx (apps/web/src/main.tsx, "Único punto de elección BrowserStore/DesktopStore" — single choice point for BrowserStore/DesktopStore), with transactional saving, safe closing via a native dialog, recents, and the E2E test seam described below. It includes nothing promised or planned: wherever something is not yet wired up, this is stated explicitly under "Limitations of this beta" below.

Requirements

• A Mac with Apple Silicon (arm64). This beta's artifact is only built for arm64 (apps/desktop/electron-builder.yml); there is no Intel (x64) build.
• macOS 13 (Ventura) or newer (LSMinimumSystemVersion of the packaged .app).
• No extra installation requirements: the app bundles Electron with its own Chromium and Node, and does not depend on Node being installed on the machine.

Where the installer is and how to open it unsigned

The installer is a .dmg generated with electron-builder (npm run dist:mac -w @lila-modeler/desktop), named Lila-Modeler-1.0.0-beta.16-mac-arm64.dmg for the current release (hyphens, no spaces, matching the SHA256SUMS file's entry). Download it and SHA256SUMS from the v1.0.0-beta.16 release — not /releases/latest, since GitHub excludes prereleases from that link. The release also attaches the Windows installer (Lila-Modeler-1.0.0-beta.16-win-x64.exe), which is unsigned and untested on a real Windows machine: see the Windows tester guide. There is no Linux installer on the release (CI builds an AppImage, untested — see "Limitations" below). The .dmg is not distributed inside the repository (the apps/desktop/release/ folder is in .gitignore): you can also build it yourself (see below).

Verify the download before opening it, with both files in the same folder:

shasum -a 256 -c --ignore-missing SHA256SUMS

SHA256SUMS also lists the Windows installer; --ignore-missing skips it if you did not download it.

The app is ad-hoc sealed but not notarized: it has no Developer ID signature (identity: null in electron-builder.yml; scripts/adhoc-sign.cjs seals the bundle after packing).

Unsigned first launch (macOS 15 and newer)

On recent macOS (Sequoia 15, and the 26/27 line), the first double-click of the downloaded app is blocked outright, with no direct "Open anyway" option in the block dialog:

1. Go to System Settings ▸ Privacy & Security, scroll to the security message naming "Lila Modeler", and click Open Anyway. Then launch the app again (double-click, or Control-click ▸ Open) and confirm Open in the dialog that follows.
2. On older macOS, Control-click (right-click) the app in Finder ▸ Open ▸ Open works directly, without needing System Settings.

Either way, this authorization is a one-time step per copy of the app — it is how macOS is designed to treat software from outside the App Store that isn't notarized. Do not disable Gatekeeper to work around it. Beta 1 verified on macOS 27.0 that the quarantined download is blocked on first launch and that System Settings ▸ Privacy & Security offers Open Anyway (the app is ad-hoc sealed, so macOS does not report it as damaged).

The app uses the Lila icon in the Dock and in Finder.

Project files: .lila vs .bpmn

Two file types register with Finder and double-click to open in this app (Beta 1 verification: see Limitations):

• .lila is the whole project container: the model, its scenarios, revisions and saved runs, zipped into one file (see PROJECT_FORMAT.md). This is the form to hand to somebody else — it is everything they need, self-contained.
• .bpmn on its own is the diagram only, with no scenarios or runs attached. Opening a loose .bpmn and saving (⌘S) writes that same .bpmn file back in place; it does not create a project folder or a .lila unless you explicitly use Save as… (see "Save and restore" below).

Backup guidance: keep a copy of the .lila (or the project folder) before large edits — the app does not version your work for you beyond the "Save as…" workflow. The web app's browser-local storage is not a backup: it lives only in that browser's storage on that machine, and is lost if you clear site data or switch browsers or profiles. Treat a downloaded .lila as the durable copy.

What the window shows on launch

Browser and desktop startup show the detailed horizontal Lila logo and manifest version until the initial canvas is ready. Startup offers localized reload recovery on failure and respects reduced motion. See the branding decision and the 2026-09-14 local installation record.

When nothing was double-clicked, the desktop app then shows a welcome overlay (design artboard 08): open a .lila project file, open a project folder, create a new process, or pick one of the public examples from the Examples gallery (pedido, the four Bizagi tutorial levels, and the two M/M/c queues — docs/EXAMPLES_POLICY.md); the right column lists recent projects (the same list as File → Open recent), what's new in this version, and the current theme and density. Opening any project, or an example, dismisses it. Double-clicking a .lila or .bpmn skips it.

The app always starts with the same example diagram bundled with it: the pedido process from examples/pedido/model.bpmn (imported directly in apps/web/src/main.tsx, not an external file). Until you pick a theme it shows with Lila Dark when the system is in dark mode and Lila Light otherwise (the bpmn-js palette on the left, the properties panel on the right), loaded on the fly from lila-dark.json / lila-light.json; tokens.css still ships Eva-01 as the paint before any theme loads.

Usage walkthrough

The top bar has three modes: Model, Simulate and Results (since 1.0.0-beta.23). Comparing scenarios («Compare with…») and the token replay live in Results; Validate paths is a Model tool (the button over the canvas, or ⌘K). English is the base language and Spanish is available as a translation. The app follows the system language unless you select English or Spanish in Settings. The native File menu and close dialogs follow that same setting. This walkthrough uses the English labels.

Model («Modelar»)

• On desktop you work with New project and Open project by folder. You can also open a loose .bpmn by double click (see Limitations). Use Save as to retain its scenarios and runs in a project folder, as described below.
• The central canvas is the bpmn-js editor: you edit it by dragging shapes from the palette, just like any bpmn.io editor.
• Undo / Redo: buttons at the top of the window, in the top bar.
• The edited XML is saved as model.bpmn inside the project folder.

Simulate (the "Simulación" tab in the right-hand panel)

• Scenario ▾ (over the canvas, in Simulate and Results) lists the loaded scenarios (the project ships with as-is and to-be-3-cajeros as examples), each with its BASE badge, «Simulated» or «Not simulated» and the scenario it extends; pick one to make it the active scenario. Next to it, Duplicate copies the active scenario in one click (the copy extends it) and leaves the copy's name ready to edit: type TO-BE and Enter. The dropdown also has Rename, Save project, Download template / Import Excel/CSV… and the scenario as JSON. The validation chips next to it jump to the first problem.

• The scenario panel has six steps, in this order: Arrivals (how often each start event fires and how many cases it creates; the Arrivals by start event list summarizes them), Times (the time of each task and timer), Routes (gateway branching), Resources (pools, units, a pool's calendar and capacity per shift, and which task takes which pool), Calendars (calendars and holidays, and which element follows which calendar) and Run (the run window and replications). Each control lives in exactly one step. The panel lets you edit run, calendars, resources, and the process's per-element properties. Union-shaped fields — today only resources.<id>.capacity — have an explicit Fija (Fixed, a number) / Por turno (Per shift, a list of { calendar, capacity } segments, with calendar as a dropdown of already-declared calendars) selector.

• A field inherited from an extends shows a Quitar heredado (Remove inherited) button (or Quitar — Remove — if the field belongs to the file itself, not inherited): clicking it writes null into the delta, which is how you "delete" an inherited value (§ 6 of the scenario format). If it is already deleted, the button switches to Restaurar heredado (Restore inherited), which removes that null and goes back to inheriting from the parent.

• Duplicate is also in the scenario panel's header. Save project is the top bar's File menu, «Scenario ▾» or ⌘S.

• Run simulation: runs the simulation on whatever is on the canvas right now. While it runs, a Cancel button and a progress indicator (% · replication N) appear; with problems that hold the run back, the button carries their count and takes you to the first one instead. When the run finishes the app moves to Results by itself.

• Quick view · simulation: select an element on the canvas and the Properties panel shows its simulation data under the header: Time, Resource (tasks only) and the resource wait (p95 when the run's log sample is in memory, the mean otherwise; no run before the first run). Edit in Times and Edit in Resources jump to the matching step.

• The scenario panel can be detached into its own window with the toggle in the top bar (Scenario docked ↗ / In its own window); Dock in the stand-in, or closing the window, brings it back. While it is detached the right panel hides, so the stand-in only shows after reopening the panel with ⇧⌘P; the toolbar toggle also docks it.

Results («Resultados»)

A finished run lands here, on the same diagram:

• Heat map: every task is tinted by its mean resource wait against its own processing time and carries a «Wait …» badge; the engine's bottlenecks get a BOTTLENECK mark. The «Heat map» button in the bar turns it off and on without re-simulating.
• Tokens: the run's event log replays on the same map, with a time bar at the bottom (play / pause, reset, speed, a slider, the simulated clock and the pools' busy units). Space plays and pauses (not while you type or with a button focused). The «Tokens» button hides the bar.
• Summary (right panel): the six KPIs — cycle time, wait per case, completed cases, cost per case, max utilization and cases in progress at the end — with the exact value and the 95 % confidence interval in their tooltip, the engine's bottleneck ranking (click one to select it) and the detail of the task you select on the map or in the table.
• Results table under the map (collapse it with ▾, ⌘J, the View menu or a double-click on its edge; drag the edge to resize): Tasks (task, resource, cases, mean processing, mean wait, utilization, total cost), Full results (the elements, resources, process and flows tables with their charts, each with Export CSV — byte for byte what npx lila run --csv writes — and Export XLSX), Run log and Warnings (grouped by code). CSV and XLSX are also in the table's header.
• Results can be detached into their own window with the top-bar toggle (Results docked ↗ / Results in their own window). While detached the summary shows Show and Dock; the window always shows the current run, closing it docks Results again, and its size and position are remembered.

Compare (in Results)

• Compare with… in the Results bar lists the other scenarios; one that has no results yet is simulated when you pick it (with its own seed and replications; Cancel on its card stops it and Retry runs it again). A duplicate's first run opens compared with the scenario it came from.
• The comparison shows the six KPIs of the other scenario with their change against the reference (green = better, red = worse, ▲▼ up or down), the comparison warnings, and two maps side by side: the reference's heat map and the other's, with the change in mean wait of each task. ⇄ swaps the sides, Choose scenario picks another one, Close comparison ✕ goes back to the map.
• Comparison tables and charts (below the maps): every scenario with a current run, the reference first. Show every KPI reveals the flows table. The Warnings section only appears when there is something to say, and groups up to five kinds, in this order:
  1. Costs in different currencies: if the compared runs do not use the same currency (run.currency), no cost delta is marked as comparable — the warning says so explicitly, and cost cells carry no significance asterisk.
  2. Different time units: each run is shown with the unit it was generated with (run.baseTimeUnit), with no normalization.
  3. No confidence intervals: if any run has fewer than 2 replications, there is no 95% CI, so no difference is marked significant in any table.
  4. Different seeds: an informational warning; it blocks nothing.
  5. Different replication count: same, informational.
• Significance section: an asterisk (*) in a cell means "significant difference (non-overlapping 95% CIs) against the reference"; highlighted cells are the ones that changed relative to it. If warning 3 above applies, this section repeats it and no asterisk is drawn at all.

Validate paths («Validar rutas»)

• A Model tool: the «Validate paths» button over the canvas, or ⌘K. Animation is entered only from there: pressing plain T on the canvas does not toggle it (it used to switch the token simulation on and off in any mode).
• This is not the engine's DES simulation: it animates bpmn-js-token-simulation tokens on top of the open diagram. It does not read the active scenario or produce results, and the tab itself says so: «Animación de tokens de bpmn-js: no es simulación de eventos discretos; no usa el escenario ni produce resultados.» (bpmn-js token animation: this is not discrete-event simulation; it does not use the scenario or produce results.) It is there to eyeball which routes get taken, not to measure anything.
• While it is on, the validation markers are not drawn and the diagram cannot be edited; turning it off (or leaving Model) restores everything.
• The controls are the bpmn.io module's own, and since LILA-205 (#264) they appear in Spanish: the canvas's left-hand palette («Reproducir o pausar la simulación» — Play or pause the simulation, «Reiniciar simulación» — Restart simulation, «Registro de la simulación» — Simulation log), the buttons that appear over shapes («Disparar evento» — Trigger event, to start from a start event; «Añadir punto de pausa» — Add breakpoint, to stop at an activity and step through it; «Elegir el flujo de salida» — Choose outgoing flow, for a gateway's output), and the log's messages. The module does not use bpmn-js's translate service — its text is written straight into the HTML — so the translation is done by substituting it on the canvas (traducirSimulacion in apps/web/src/TokenSim.tsx, with the inventory in strings.es.ts): if the module is ever updated and a label changes, that label will simply show up in English again, never broken.
• The diagram keeps the theme's colors during the animation (#264). Out of the box, the module repaints it in black and white for the whole mode, built for a white canvas; Lila overrides two of its services (moduloColoresDelTema in apps/web/src/TokenSim.tsx) so it paints with the theme's tokens instead. A gateway's chosen output is marked with the theme's selection color (lime in Eva-01, red in Papel) and the discarded one with a normal connection's color; the animation's own markers — the scopes' green, the token counter — are left as they come.

Save and restore («Guardar y recuperar»)

This is real, working functionality: DesktopStore is wired up in main.tsx and reads/writes a project folder on disk, not a loose file downloaded by the browser.

• New project: asks you to choose a folder. It can be empty, or already contain a project with the same id (to save back into it); a folder holding content from another project (a lila-project.json with a different id, or a model.bpmn with no matching manifest) is rejected with E-CARPETA-OCUPADA, without touching anything that was already there.
• Open project: a native folder picker; loads whatever project is there.
• Save project: saves into the active folder (the one from the last successful "New"/"Open"/"Save as").
• Save as…: asks where to create a new .lila — the whole project in one file (ADR-027), which is the form to hand to somebody else. Save as folder… is the same thing towards a project folder, which is the form to keep in git. Both apply the same E-CARPETA-OCUPADA rules as "New project": a destination that already holds a different project is refused without touching it.
• The top bar shows the file name followed by · Unsaved or · Saved depending on whether there are pending changes (apps/web/src/App.tsx). With several processes in the project it shows the active process's name instead of the file name.
• Closing with unsaved changes: the window (red button, Cmd+Q, or closing it from the Dock) shows the system's native dialog with Save / Discard / Cancel. Save waits up to 30 s for the app's response before closing; a cancelled save keeps the window open without an error. If saving fails or the response never arrives, an error is shown and the window does not close. A loose diagram saved with pending scenarios or runs shows an informational message explaining that Save as… is required to save the complete project. Closing the last window also quits the app on Mac; on reopening, use Open project to get the saved folder back.
• Autosave and recovery (#459): five seconds after each change, a copy of the unsaved project is written to recovery.lila in the app's data folder (~/Library/Application Support/Lila Modeler/). Saving, or discarding the changes when closing, deletes it. If the app quit without either (a crash, a forced quit), the next launch offers Restore / Discard: the restored project opens as unsaved and with no file behind it, so its first save asks where with Save as… — your original file is never overwritten without you choosing it.
• What files a project folder holds: model.bpmn (the diagram), one <name>.scenario.json per scenario (for example as-is.scenario.json, to-be.scenario.json), lila-project.json (metadata: id, name, revisions), and a runs/ subfolder with one saved run per file.
• A .bpmn with a different name inside the folder is saved as a loose diagram: the manifest (lila-project.json) describes only model.bpmn — its name and its revision. If you open ventas.bpmn (double click) in a folder that is already a Lila project, ⌘S writes that ventas.bpmn and nothing else: model.bpmn, the scenarios, and the manifest stay byte for byte as they were, and runs are not saved. The bottom bar warns about it while that diagram is open — «Diagrama suelto: los escenarios y las corridas no se guardan hasta «Guardar como»» (Loose diagram: scenarios and runs are not saved until "Save as") —, the same as with a loose .bpmn in ~/Descargas: it is the same save mode. Reopening the folder from recents shows the model.bpmn project again, not the other diagram. To turn ventas.bpmn into its own project, use Guardar como (Save as) into a new folder: there the XML becomes that new project's model.bpmn (Guardar como always writes model.bpmn; asking it for a different file name is rejected with E-DESTINO-INVALIDO, because it would leave a folder with no manifest that could never be reopened). Choosing the SAME project folder is rejected with a warning («esta carpeta ya tiene su model.bpmn» — this folder already has its model.bpmn): there, "Guardar como" would overwrite the project's model with the loose diagram. A loose .bpmn that is not inside a project — the one in ~/Descargas — can indeed become a project in its own folder: there is no model.bpmn or manifest to overwrite, and the project is created alongside it, leaving the original .bpmn untouched.
• Model.bpmn (capitalized) is not opened INSIDE a project folder: if there is a lila-project.json next to it, it is rejected with E-ARGUMENTO and the message asks you to rename it. On Mac the disk is case-insensitive, so there that file is the project's model.bpmn, but the app would treat it as "another diagram" and save only half of it (the model, yes; the manifest and scenarios, no). Outside a project — a Model.bpmn in ~/Descargas, say — it opens and saves normally, like any loose diagram.
• A scenario with broken JSON does not block opening the project: that file is excluded and noted in problems; the rest of the project (the model and the other scenarios) opens normally. This does show up in the interface: App.tsx reads doc.problems when it activates the project and renders it as a warning (<span role="alert">) with the file and the reason.
• Saving into a folder with no write permission shows an error (E-DESTINO-INVALIDO) and loses nothing: the previous file stays intact and the bar keeps showing "Sin guardar" (Unsaved). What you see today is Electron's raw text ("Error invoking remote method…"), not a friendly translation (see "Limitations" below).
• External changes on disk (someone else — or another process — modified model.bpmn, the manifest, or a scenario after this window last read or saved it): when you try to save, the app refuses with E-CAMBIO-EXTERNO: <files> without touching disk. There is no "Overwrite" button today: the only way out from the interface is "Guardar como" (Save as, into another folder).
• The open project is watched (#539): when an agent or a script rewrites the open .lila (or a project folder's model, manifest or scenarios) through the CLI or MCP, the app notices within a fraction of a second. With nothing unsaved it reloads on its own, keeping the mode, the process tab and the scenario on screen when they still exist. With unsaved changes the status bar says «The file changed outside Lila» with Reload (take the file, drop your edits) and Keep mine (keep editing; the next save is still refused with E-CAMBIO-EXTERNO, as above). Lila's own saves never trigger it.

Recents and window («Recientes y ventana»)

• The window's size/position and the list of recent projects are saved in ~/Library/Application Support/Lila Modeler/estado.json, and restored the next time the app opens (if the saved window no longer fits any connected screen, the default size is used).
• File → Open recent lists those projects (newest first) and reopens them with no dialog; if the folder no longer exists, it drops off the list and the app says so in the status bar. The native menu also carries New project (⌘N), Open project… (⌘O), Import BPMN… (a .bpmn or .xml from another tool), Save project (⌘S), Save as… (⇧⌘S), and Preferences… (⌘,) in the app menu; View carries the command palette (⌘K) and the three modes (⌘1…⌘3), and Simulation runs the simulation (⌘↩). Every shortcut is listed in Keyboard shortcuts.

Settings («Ajustes»)

• ⌘, (or the ⚙ button in the bar) opens Settings on the General tab (language, density — Compact/Normal/Comfortable — and the Advanced switch); Appearance and Shortcuts are the other two tabs. Appearance holds Follow the system theme and one of seven themes (Lila Light, Lila Dark, Eva-01 dark, Paper light, Tieso light, Akira dark, Montana purple). The theme change is immediate, it repaints the diagram too, and it is remembered across launches (the app's localStorage, under lila://). Switching themes remounts the canvas, so it clears the undo stack; the diagram and any unsaved changes are kept.
• The per-token color editor and theme import/export is LILA-114 (#144), still pending.

Limitations of this beta

(as of 1.0.0-beta.26, tag v1.0.0-beta.26; the macOS verification notes below were recorded for Beta 1. Check whether any of these has already been resolved before trusting this list blindly at a later date)

• No Developer ID signature or notarization: a received copy requires macOS's opening authorization (see "Unsigned first launch" above). This is expected; do not disable Gatekeeper to work around it.
• Only macOS arm64 is exercised: the Windows (NSIS) installer is built by the CI matrix (.github/workflows/desktop.yml) and attached to the release, but it is unsigned and nobody on the project has run it on a real Windows machine yet (see the Windows tester guide); the Linux AppImage is built the same way, untested and not attached.
• Finder double-click: Beta 1 verified the macOS open-file route for .lila on macOS 27.0 (arm64) with open -a, the same event Finder sends on double-click, with the app closed and already running, including a name with accents and an em dash. A physical double-click in Finder, and opening a .bpmn that way, were not exercised.
• Saving a .lila opened by double-click or launch argument is fixed in Beta 1 (#378). Verified in Beta 1 by the real-Electron regression in tools/e2e-desktop-open-path.mjs (launch argument, open-file event, recents, dialog; ASCII, spaces, accents in NFC and NFD)
• Raw error messages: some errors reach the interface untranslated — zod's raw validation JSON (for example, a scenario that references a nonexistent task id) and Electron's generic "Error invoking remote method…" text (for example, when saving into a folder with no permissions).
• Visual calendar editor postponed: calendars is edited with the same generic form fields as the rest of the scenario (numbers, text, lists of intervals); there is no drawn calendar/schedule view yet.
• Exportar CSV (Export CSV) is only available in Results mode, not in Compare.
• No currency conversion or unit normalization across runs: if scenarios with different currency or baseTimeUnit are compared, the app warns about it (see "Compare" above) instead of making up a conversion.
• The MCP guide (stdio, run_simulation/compare_scenarios) is not part of this increment: see docs/MCP.md, which belongs to a different work package (OP-17 increment 2, issues #56/#48).

Rebuilding from source

From the repository root, in order:

npm ci                              # solo la primera vez, o si package-lock.json cambió
npm run build -w @lila-modeler/engine       # compila el motor de simulación (TypeScript)
npm run build -w @lila-modeler/web          # compila engine (si hiciera falta) + build de Vite
npm run dist:mac -w @lila-modeler/desktop   # tsc + copia dist/web + electron-builder --mac --arm64

The last command chains together: apps/desktop's tsc --build, copying apps/web/dist to apps/desktop/dist/web, and electron-builder --mac --arm64. The result lands in apps/desktop/release/ (the version in apps/desktop/package.json: 1.0.0-beta.26 for Beta 26):

• apps/desktop/release/Lila-Modeler-1.0.0-beta.26-mac-arm64.dmg — the installer.
• apps/desktop/release/Lila-Modeler-1.0.0-beta.26-mac-arm64.dmg.blockmap.
• apps/desktop/release/mac-arm64/Lila Modeler.app — the app unpackaged from the DMG, useful for quick testing.
• apps/desktop/release/ORIGEN.txt — the build's sha, fecha (date, ISO), and arch (uname -m), written by apps/desktop/scripts/origen.mjs at the end of dist:mac.

If Vite is already running on the machine (for example npm run dev -w @lila-modeler/web from another session), stop it before building dist:mac: the production build does not need it, and two processes fighting over the same port only adds noise to the logs, though it does not break the build itself (the final binary loads via the lila:// protocol, not http://localhost).

To try the .app without generating the DMG (faster, useful in development):

npm run pack:mac -w @lila-modeler/desktop   # mismo build, pero --dir en vez de --mac

A minimal check that the package launches, without opening a window:

LILA_SMOKE=1 "apps/desktop/release/mac-arm64/Lila Modeler.app/Contents/MacOS/Lila Modeler"

Prints a JSON object (lienzo, tema, fuente, puente, consoleErrors, loadFailure, ok — canvas, theme, font, and bridge, respectively) and exits with code 0 if everything loads fine; the screenshot lands in a system temp folder ($TMPDIR/lila-smoke/captura.png, outside app.asar, which is read-only inside the package).

For agents/QA: the E2E seam

apps/desktop/src/main.ts accepts these environment variables meant only for automated testing (for example, so a hands-off agent can drive native dialogs it could not otherwise touch). They are not a public API and must never be used in normal use of the app:

• LILA_E2E_FOLDER=<absolute path>: makes chooseFolder return that path directly, without opening the native picker (it creates the folder if missing, and authorizes it just like the real dialog would). The literal value "cancel" simulates the user closing the picker without choosing anything.
• LILA_E2E_CLOSE=save|discard|cancel: makes the native "close with unsaved changes" dialog (Guardar/Descartar/Cancelar — Save/Discard/Cancel) resolve automatically with that value, instead of waiting for a click.
• LILA_E2E_SAVE_FILE=<absolute path to a .lila>: the same as LILA_E2E_FOLDER, for the native "Save as…" dialog.
• LILA_E2E_IMPORT=<absolute path to a .bpmn/.xml>: the same, for File › Import BPMN….
• LILA_E2E_EXPORT_FILE=<absolute path>: every export the app saves through its own save dialog (diagram as SVG/PNG/PDF, process document, the results' XLSX and CSV, the comparison workbook, the scenario template, a theme) is written to exactly that path, without opening the dialog and without adding an extension. Each export overwrites the previous one. "cancel" simulates cancelling the dialog.
• LILA_E2E_RECOVERY=restore|discard: makes the launch offer of the autosave copy (Restore / Discard) resolve automatically with that value.
• LILA_E2E_LOG=<file path>: if present, appends one JSON line per relevant event (chooseFolder, writeProject, closeRequested, openPath, recovery, exportar) to that file.

With none of them set, the app behaves exactly as if they did not exist. Warning: these are a shortcut for testing, not something an end user should ever set — they leave the app answering its own dialogs with no human involved.