Product tour

Watch product video

See SCOrch import, the Workflow Designer, execution history, Live Ops, logs and AI chat in action. English captions, no audio.

Table of Contents

• Product tour
• Why NodePilot
• Coming from System Center Orchestrator
• Install — pick one of three paths
• Documentation
• Project Structure
• Testing
• Contributing
• License

Why NodePilot

NodePilot is a drop-in modern alternative for organizations stuck on legacy SCOrch — same agentless model, same target audience (sysadmins automating Windows estates), but built on a current stack with a UX that doesn't feel like a 2010 MMC snap-in.

Highlights

• Your SCOrch runbooks import directly — native .ois_export XML, with activities, links, conditions, global variables and Published Data references translated into NodePilot's data bus. How it works.
• Visual designer — drag-and-drop canvas with 27 activity types, 6 triggers, typed nodes, a visual condition builder, and a seven-cluster toolbar that puts every editing affordance one click away.
• True parallel engine — event-driven scheduling loop with real fan-out / fan-in, three junction modes (waitAll / waitAny / waitNofM), per-step DI scope, and skip propagation.
• Step debugger — breakpoints, conditional breakpoints, step-over, live variable inspector with runtime overrides, and time-scrubbing replay in the Gantt timeline.
• Real-time UI — SignalR streams step status, output, and variables to every connected client as the workflow runs.
• Agentless remote execution — WinRM + PowerShell SDK; localhost runs in-process without WinRM.
• AI-assisted authoring — generate PowerShell scripts and entire workflows from natural language; works against OpenAI or local Ollama / LM Studio / vLLM for zero-egress setups.
• Global AI chat — a read-only assistant available from the bottom-right chat button and its own page (/ai-chat), sharing conversations, drafts and ongoing answers across navigation. Answers use admin-switchable knowledge sources: documentation, operational data scoped by folder permissions, source code, and read-only SQL against the database. Every source is opt-in; the chat never executes or publishes anything.
• Operations CLI (np) — full-featured command-line client (login, run, watch, audit, lock/publish, import/export), published as a self-contained folder you put on PATH.
• Drivable by AI agents — an opt-in MCP server (nodepilot-mcp) exposes NodePilot to Claude Code, Claude Desktop and any other MCP client — 102 tools over 10 groups, HTTP-only against the same REST API, with destructive operations gated.
• Batteries-included observability — opt-in OpenTelemetry + Prometheus exporter, plus a hardened, loopback-bound Grafana stack with 10 pre-provisioned dashboards (Mission Control, Workflows, Activities, WinRM, Triggers, API, Runtime, Security, AI, Database). Startup requires a unique NODEPILOT_GRAFANA_ADMIN_PASSWORD — Compose fails closed while the password is missing, rather than coming up on a default credential.
• SCOrch-style edit lock — atomic per-user check-out / publish flow, 423 Locked enforced by every mutating endpoint, force-unlock for admins with audit trail.
• Workflow versioning — every edit is snapshotted; one-click rollback; visual diff between any two versions.
• JWT + RBAC — Admin / Operator / Viewer roles, BCrypt passwords, account lockout, DPAPI-encrypted credentials, output redaction, SSRF guards, per-IP rate limits, and an audit-event alert source that pages on failed logins, lockouts, break-glass sign-ins and privilege changes without a SIEM.
• AD SSO Preview (opt-in) — hardened LDAP/Kerberos, OIDC + SCIM, server-side sessions and directory-backed RBAC complement Active/Passive HA, secret providers and ECS-JSON SIEM logging. Production status remains Preview until the real AD/Kerberos/LDAPS field gate passes. See docs/enterprise-features.md.
• Production-grade deployment — turnkey PowerShell installer for Windows Service under a gMSA, direct Kestrel HTTPS, install/data-dir split, in-place upgrades with auto-rollback.

Coming from System Center Orchestrator

SCOrch is not going anywhere: System Center 2025 Orchestrator shipped in November 2024 with mainstream support to January 2030 and extended support to January 2035. If you run it today, you are not on a deadline — so this is not a migration pitch.

What has not moved is authoring. The web console added in 2022 runs and monitors runbooks; it cannot build them. Writing one still means the desktop Runbook Designer, on a machine with the client installed — and once it is written, there is no version history, no diff between two states, and no rollback. NodePilot is built for that gap: the same agentless model, the same job, the same people, with the editor, the debugger and the version history in a browser.

Your runbooks come with you. NodePilot reads SCOrch's native .ois_export XML directly (exports from 2012, 2016 and 2019 all parse) and turns runbooks into workflows:

• Activities are mapped, not dropped. Roughly forty SCOrch type names translate directly — scripts and programs, the file, folder, archive and text-file activities, Query XML, Query Database, Query WMI, Invoke Web Services, Send Email, Start/Stop Service, Restart System, Generate Random Text, the Monitor activities that have a NodePilot trigger, and the Runbook Control set (Initialize Data, Return Data, Junction, and Invoke Runbook, which SCOrch writes as Trigger Policy) including the arguments passed to a child runbook.
• Published Data becomes the data bus. SCOrch's \`d.T.~Vb/{GUID}\`d.T.~Vb/ references are rewritten into NodePilot's {{globals.Name}} and {{step.param.field}} syntax, resolving through a readable name derived from each activity rather than a bare GUID. Where the two products name the same value differently the field is translated too, and where SCOrch published something NodePilot has no equivalent for, the reference is reported instead of quietly pointing at the nearest-looking name. This is usually the part that makes a migration expensive.
• Branches keep branching. Compare Values becomes a decision, and the links that read its result are re-pointed at it — a comparison whose outcome nothing could read would leave every branch behind it dead.
• Links, conditions and global variables come across, including on-success / on-failure links, the TRIGGERS filter logic, and whether a link matched all or any of its filters.
• Every runbook is runnable on arrival. NodePilot starts a workflow from a trigger node, and a SCOrch runbook invoked by another needs no trigger of its own — so one is added and wired to the entry activities.
• Nothing disappears silently. An activity the importer cannot map becomes a disabled placeholder carrying the original type name and its full property list; a mapping that cannot fill a required setting degrades to one too, rather than leaving a node that looks configured and does nothing. The import report names every lossy translation: a reference to a field the NodePilot activity does not publish, a reference across parallel branches (SCOrch's data bus is run-scoped, NodePilot's is ancestor-scoped), a remote step with no target machine, a dropped run-as account, an approximated schedule, and any link that ended up unconditional.
• Your folder tree comes with you. A SCOrch export carries the structure its console showed — for runbooks and for global variables — and the import rebuilds both below the destination you pick, reusing folders that are already there. Re-filing a few hundred workflows by hand is work a migration should not create.
• The canvas looks like your runbook. SCOrch positions activities as small icons on a tight grid; NodePilot draws cards several times that size, so the coordinates cannot be copied as they are. The graph is scaled uniformly instead — a similarity transform, so every distance keeps its ratio and the arrangement is the one its author drew, just larger. Links are then made to read as curves rather than the angular loop the designer draws for an edge running backwards: a pair stacked in one column docks top-to-bottom without either node moving, and anything else is nudged apart horizontally. Rows are never touched. Where the arrangement cannot be reproduced (activities sharing a position, or spaced too tightly for any usable canvas) the import says so and falls back to a left-to-right layout.

Import from the UI, from POST /api/workflows/import-scorch, or from the CLI:

np workflow import-scorch --file .\runbooks.ois_export

Treat the result as a reviewed draft, not a finished migration. Imported workflows arrive disabled, credentials are never reconstructed (SCOrch encrypts them), and anything the report flags needs a decision. After review, activate a workflow explicitly through POST /api/workflows/{id}/enable or np workflow enable <id>. Both import APIs return the created ids; the CLI exposes the same report as machine-readable stdout with -o json. The point is that you start from your actual runbooks instead of a blank canvas.

How the two compare

The last row is the honest one: NodePilot gives you the source, not a support contract. Judge it on that basis.

Need to make the case to someone else? A ready-made slide deck lives in presentations/, self-contained HTML — download and open in a browser:

• NodePilot — technical deck (39 slides) — overall architecture, the activity model, migrating from SCOrch, operational practice.

The deck is in German. It predates this README and is not maintained in step with it — treat it as a starting point for your own slides rather than as current reference material.

Install — pick one of three paths

NodePilot runs in exactly three supported shapes. Pick the row that describes you; each one is a complete route to a working login, and nothing below mixes them.

NodePilot is Windows-only by design — the engine drives PowerShell remoting over WinRM and protects credentials with DPAPI. There is no Linux, container or Kubernetes target.

Every path ends the same way: the first login creates the Admin account, and it needs a one-time setup token. Where to find that token differs per path and is called out below.

Path 1 — Desktop app

A local desktop application for Windows 11 x64: one .exe that bundles the app, a self-contained .NET 10 runtime and a local PostgreSQL server, installs everything as background Windows services, and opens a native Electron window on top — fully offline, no runtime prerequisites, no external database.

Download NodePilot-Desktop-Setup-<version>.exe from the latest release and run it. The installer needs local admin: it provisions the database cluster, a loopback certificate and both services, then launches the shell and hands the first-run setup token straight to the login screen — you never have to find a file. If provisioning fails it says so and names its log, rather than finishing green with an app that will not start. When something does go wrong, docs/desktop-troubleshooting.md covers the log locations, first-run recovery and a complete removal; the full inventory of every log file — server and desktop, with paths, retention and which one to read when — is at Logs & diagnostics.

The backend runs as an always-on service, so scheduled and webhook triggers keep firing when the window is closed. It uses the Deployment:Mode=Desktop posture: Production-hardened, but with a loopback-only Kestrel and a 127.0.0.1 Postgres. The Electron shell is a thin, hardened viewer that pins the loopback certificate by SHA-256 and trusts no system root CA.

deploy\desktop\Build-DesktopInstaller.ps1 -PgBinariesPath 'C:\Packages\pgsql' -Version 1.2.0
# -> deploy\desktop\out\NodePilot-Desktop-Setup-1.2.0.exe

deploy\Build-Artifact.ps1 -SigningCertificateThumbprint <artifact-signer> `
    -IncludeDesktopInstaller -PgBinariesPath 'C:\Packages\pgsql' `
    -InstallerSigningCertificateThumbprint <authenticode-signer>

Path 2 — Windows service

The production rollout: a signed artifact plus a PowerShell installer that registers NodePilot as a Windows service under a gMSA, terminates HTTPS in Kestrel directly, and splits install and data directories so in-place upgrades can roll back.

Prerequisites (all enforced by the installer's pre-flight, which fails with a named error):

• Windows Server 2022 or 2025, domain-joined for the gMSA path — -UseLocalSystem works without a domain
• ASP.NET Core Runtime 10.0.11 or newer in the 10.x line (x64) — the plain runtime, not the Hosting Bundle (that one wires up IIS and restarts W3SVC). NodePilot ships as win-x64; a 32-bit runtime cannot host it and the pre-flight says so rather than passing the row
• PostgreSQL 16+ or SQL Server 2022 CU1+ (build ≥ 16.0.4003.1 — earlier builds cannot serve the Encrypt=Strict / TDS 8.0 connections NodePilot opens, and are rejected)
• a TLS certificate in Cert:\LocalMachine\My with its private key
• antivirus exclusions agreed with your security team — see docs/av-exclusions.md

There are two ways to run it, and they install the same thing.

With the wizard. Download NodePilot-Server-Setup-<version>.exe from the latest release and run it. It carries the signed artifact and the ASP.NET Core runtime, checks every prerequisite above before changing anything — showing each as green, amber or red with a copyable fix — and can install the runtime, create the SQL login and database, or issue a lab certificate for you. One file instead of five, and no manual thumbprint comparison. Unattended: Setup.exe /VERYSILENT /SUPPRESSMSGBOXES /ANSWERFILE=answers.json. Details, answer-file schema and switches: deploy/server/README.md.

With the scripts, which is what the wizard runs and what you want for automation. Download the signed NodePilot-<version>.zip together with its .manifest.json and .manifest.json.p7s, verify it against NodePilot-<version>.SHA256SUMS.txt, then:

.\deploy\Install-NodePilot.ps1 `
    -ArtifactPath 'C:\Packages\NodePilot-1.2.0.zip' `
    -TrustedArtifactSignerThumbprint '<publisher thumbprint from the release notes>' `
    -CertThumbprint '<your TLS cert thumbprint>' `
    -ServiceAccount 'CONTOSO\svc-nodepilot$' `
    -PublicHostname 'nodepilot.corp.example.com'

The installer refuses unsigned or tampered artifacts — -TrustedArtifactSignerThumbprint is mandatory, and the signature, the signer's identity, its code-signing eligibility and its validity are all verified, not just the hash. It does not require the publisher to be trusted on the target machine: pinning the thumbprint is the trust decision, so there is nothing to import before installing. If you build the artifact yourself you also sign it yourself; docs/deployment-guide.md walks through creating the self-signed code-signing certificate.

Full walkthrough — service identity, database, certificates, first login: Windows Server deployment. Verifying what you downloaded, and building it yourself — plus a troubleshooting table for what actually goes wrong: docs/deployment-guide.md. Operator reference — every parameter, update and uninstall: deploy/README.md.

Path 3 — From source

For contributors and for evaluating on a workstation.

Prerequisites

• Windows 10 / 11 (or a Windows Server — this path is not picky, it just needs Windows)
• .NET 10 SDK — download; the exact band is pinned in global.json
• Node.js — the minimum is declared in each package.json engines field (react-router 8 sets it); npm warns if you are below it
• PostgreSQL 16+ — or SQL Server 2022 CU1+ with Database:Provider: sqlserver

1. Create the database

Neither shipped connection string carries a password, so this step is not optional.

winget install PostgreSQL.PostgreSQL
$psql = "C:\Program Files\PostgreSQL\16\bin\psql.exe"
& $psql -U postgres -c "CREATE ROLE nodepilot WITH LOGIN PASSWORD 'ChangeMe!';"
& $psql -U postgres -c "CREATE DATABASE nodepilot OWNER nodepilot;"

2. Start the backend (port 5000)

Pass the password through the environment rather than editing a tracked file — that way it never becomes a commit:

$env:ConnectionStrings__Postgres = "Host=127.0.0.1;Port=5432;Database=nodepilot;Username=nodepilot;Password=ChangeMe!;SSL Mode=Disable"
cd src\NodePilot.Api
dotnet run

Start PostgreSQL before the API — without a reachable database the process exits during the migration bootstrap and tells you which server and database it could not reach.

On first start NodePilot writes a one-time setup token to admin-setup.token next to the project (src\NodePilot.Api\admin-setup.token — it lands in the content root, not the directory you started from). Sign in with the admin username and password you want; the login screen reveals a Setup token field on the first attempt, and pasting the token creates the Admin account.

3. Start the frontend (port 5173)

cd src\nodepilot-ui
npm install
npm run dev

Open http://localhost:5173 — the Vite dev server proxies /api, /healthz and /hubs to port 5000.

4. (optional) Bring up Grafana

cd grafana
Copy-Item .env.example .env     # then set NODEPILOT_GRAFANA_ADMIN_PASSWORD - compose refuses to start without it
docker compose up -d
# Grafana    -> http://localhost:3000   (user "admin", the password you just set)
# Prometheus -> http://localhost:9090

Enable the Prometheus exporter on the API — all three variables are required, the third is what lets Prometheus scrape /metrics without credentials:

$env:OpenTelemetry__Enabled = "true"
$env:OpenTelemetry__Exporters__PrometheusScrape = "true"
$env:OpenTelemetry__Exporters__PrometheusScrapeAllowAnonymous = "true"

See grafana/README.md for the full walk-through.

The same walkthrough, with more detail per step, lives on the documentation site — in English and German.

Example workflow

Want to see the designer in action without building anything? Import the bundled showcase — a nightly fleet health-check that fans out three parallel probes, gathers them at a junction, and routes a decision to an alert or an all-green log:

scripts/readme-showcase-workflow.json

Import it via the Workflows page → Import (or POST /api/workflows/import). It exercises every shape you'll meet in production — schedule trigger, runScript, log, junction (waitAll), decision, emailNotification, returnData, plus three phase sticky-notes — laid out to fill the canvas width and run top-to-bottom.

Documentation

Everything below the surface lives on the documentation site — 43 pages in English and German, with search and deep links. This README deliberately stops at "installed and logged in".

The API also documents itself: the OpenAPI spec is served at GET /openapi/v1.json, with Swagger UI at GET /swagger (Development by default).

Production deployment

For a real server rollout, follow Windows Server deployment on the documentation site — a lab-validated walkthrough covering service identity, both database providers, certificates and the first admin account. The installer runs NodePilot as a Windows service under a gMSA with direct Kestrel HTTPS, splits install and data directories, and upgrades in place with automatic rollback.

Two companions to it: docs/deployment-guide.md covers what happens before you install — verifying the download against its checksums and publisher, and building the artifact yourself — and carries the troubleshooting table. deploy/README.md is the parameter reference, and states what the installer deliberately does not do.

Before you deploy anywhere with endpoint protection, hand docs/av-exclusions.md to whoever owns it — NodePilot runs PowerShell by design, and that trips heuristics.

Project Structure

src/
  NodePilot.Core/         Domain models, interfaces, enums (zero dependencies)
  NodePilot.Ai/           LLM stack — ILlmClient/OpenAI transport + SSRF guard, prompt catalog, script/workflow gen + chat assistant (Core-only; used by Api and Engine)
  NodePilot.Data/         EF Core DbContext, CredentialStore (DPAPI), provider-agnostic migrations
  NodePilot.Remote/       WinRM session factory + PowerShell SDK session
  NodePilot.Engine/       WorkflowEngine, 27 activities, RetryPolicy, DebugCoordinator
  NodePilot.Scheduler/    TriggerOrchestrator (Quartz.NET), 4 polling trigger sources + retention/cluster services
  NodePilot.Telemetry/    OpenTelemetry setup, Prometheus client, metric constants
  NodePilot.Api/          ASP.NET Core host, controllers, SignalR hub, security middleware
  NodePilot.Cli/          `np` — operations CLI (Spectre.Console.Cli), shipped in both installers under tools\np
  NodePilot.Mcp/          `nodepilot-mcp` — MCP server for AI agents (ModelContextProtocol), shipped under tools\mcp
  NodePilot.Switcher/     WPF utility for exclusive local NodePilot/SCOrch service control
  nodepilot-ui/           React 19 SPA (Vite 8 + Tailwind CSS 4 + React Flow 12)
  nodepilot-docs-ui/      Documentation website (Vite + React SPA) — its OWN curated markdown corpus under content/{de,en}/, maintained alongside docs/ (not a 1:1 render)
  nodepilot-desktop/      Electron shell for the desktop app — thin hardened viewer, no business logic

tests/
  NodePilot.Engine.Tests/   xUnit — engine + every activity executor
  NodePilot.Ai.Tests/       xUnit — LLM client factory, endpoint guard, prompt catalog, gen/chat services
  NodePilot.Data.Tests/     xUnit — EF context + migrations
  NodePilot.Api.Tests/      xUnit — controllers, auth, telemetry, validation
  NodePilot.Cli.Tests/      xUnit + WireMock.Net — CLI ApiClient + DPAPI TokenStore
  NodePilot.Mcp.Tests/      xUnit + WireMock.Net — MCP tools + stdio-process smoke test
  NodePilot.LoadTests/      Standalone load harness (Console EXE, HdrHistogram)
  NodePilot.Switcher.Tests/ xUnit — discovery, state machine, fail-closed switching
  NodePilot.TestCommons/    Shared test infrastructure (TestDbFactory, FakeLlmClient, fixtures)

grafana/                  Docker-compose stack: Prometheus + Grafana + 10 dashboards
deploy/                   Production install / update / uninstall PowerShell scripts
docs/                     Feature docs (AI, styleguide, perf, security, deployment)
samples/                  Example workflows for the importer

Dependency graph: Api → Ai, Engine, Scheduler, Data, Remote, Core, Telemetry Engine → Ai, Data, Remote, Core, Telemetry Ai → Core · Data → Core · Remote → Core · Telemetry → Core Cli → Core · Mcp → Core (HTTP-only — no backend project references)

Testing

Six CI jobs gate every pull request and every push to main: backend build + tests with an enforced 85 % line / 70 % branch coverage gate, frontend lint/build/vitest, docs-site lint/tests/build, desktop-shell typecheck + tests, and hermetic Playwright E2E. A local nightly task runs the same four suites against the checked-out tree.

Tests are mandatory — every behaviour change ships with tests in the same change. Which tests you run locally is scoped to what you touched; the full suite is CI's job, not yours. Commands, the scoping rules, and the guard-test mapping are in CONTRIBUTING.md and CLAUDE.md.

Two conventions worth knowing before you write one: the WinRM remote layer is always mocked, and backend database tests run on in-memory SQLite — a test backend only, never a supported production provider.

Contributing

Contributions are welcome. CONTRIBUTING.md has the full setup: prerequisites, how to get a local PostgreSQL and a first admin account, the build and test commands, and the conventions that CI enforces.

The short version:

1. Open an issue first for anything non-trivial — it saves a round of "we already explored that" review comments.
2. Tests ship with the change, not after it. CI fails without them.
3. No backwards-compat shims. NodePilot is greenfield — replace cleanly rather than keeping the old path alive behind a flag.
4. Hand-building workflow JSON? Read docs/workflow-styleguide.md first — layout rules, edge-label conventions, and engine gotchas.

Found a security problem? Do not open a public issue — SECURITY.md has the private reporting path. Everyone taking part is expected to follow the Code of Conduct.

CLAUDE.md and .agents/ are working notes for AI coding agents, not contributor documentation. They are checked in deliberately: NodePilot is built with agentic engineering, so the context an agent needs to work on this codebase belongs in the repository rather than in someone's private setup. What that does not change is the bar every change has to clear — behaviour changes ship with tests, and CI enforces the coverage gate on every pull request. CONTRIBUTING.md is the file written for people.

License

NodePilot is licensed under the Apache License 2.0. You are free to use, modify, and distribute it — including commercially — provided you retain the copyright and license notices. See LICENSE for the full text.

Acknowledgments

• System Center Orchestrator — for proving that visual workflow orchestration on Windows is a real need, and for inspiring the per-user check-out / publish lifecycle.
• React Flow — the canvas library underneath the designer.
• Quartz.NET — the cron engine behind scheduleTrigger.
• Serilog — structured logging across the stack.
• OpenTelemetry — vendor-neutral traces & metrics.
• Spectre.Console — the CLI presentation layer.

Further Reading

• 📚 sev7enup.github.io/NodePilot — the documentation website: 43 pages in English and German, with search, sidebar navigation and light/dark themes. Start at Introduction or jump to Installation. The same site ships with the product — every installation serves it at /docs, without a login and without internet access, at the version actually installed.
• CLAUDE.md — architecture conventions, full activity/trigger reference, variable resolution details, edge-condition grammar, test guidelines, and the complete API endpoint table.
• src/nodepilot-docs-ui/ — standalone documentation website (Vite + React SPA) with client-side search, sidebar navigation, light/dark theme, and English/German via i18next (the language lives in the route: #/en/…, #/de/…). Note: it ships its own curated markdown corpus under content/en/ and content/de/ — changes to docs/ must be mirrored there deliberately (it is not a 1:1 render), and both languages must be kept in step or the parity test fails. It has two deployments: GitHub Pages, and wwwroot/docs inside the server artifact and desktop package, which the API serves at /docs.
• docs/workflow-designer-features.md — complete feature inventory of the workflow designer (canvas, nodes, edges, properties, overlays, modes, shortcuts, mobile), organized by area.
• docs/workflow-styleguide.md — layout rules, edge-label conventions, and engine gotchas for hand-built workflow JSON.
• docs/ai-features.md — LLM configuration, recommended models, security model, error taxonomy.
• docs/performance-improvements.md — capacity tuning playbook (parallel workflow targets, runspace pools, DB pool sizing).
• docs/security-findings.md — register of resolved security findings with fix and test, by severity.
• docs/av-exclusions.md — antivirus/EDR exclusions for the server and desktop roles (folders, processes, temp-file patterns, behaviour rules), each with its rationale and residual risk — written to be handed to a security team.
• docs/enterprise-features.md — enterprise features, configuration switches and release gates, including the current AD SSO Preview.
• docs/ha-active-passive.md — Active/Passive HA setup, lease/fencing model, failover RTO.
• docs/secrets-providers.md — secret-provider operator runbook (DPAPI ↔ AES-GCM migration).
• docs/ldap-windows-sso.md — LDAPS, Windows Negotiate/Kerberos, OIDC and SCIM setup and field-test checklist.
• docs/roadmap.md — the roadmap: what is committed, what is trigger-gated, what was deliberately ruled out and why.
• grafana/README.md — Prometheus + Grafana stack walk-through.
• deploy/README.md — production deployment operator manual (Windows Service, external DB).
• docs/switcher.md — local NodePilot/System Center switcher behavior and safety model.
• deploy/desktop/README.md — desktop app: offline one-click installer with bundled PostgreSQL, plus the fast dev loop for iterating without rebuilding the installer.
• docs/desktop-troubleshooting.md — desktop app troubleshooting: log locations, first-run setup recovery, port conflicts, and how to remove it completely.