Activity-Referenz

Diese Referenz beschreibt Konfiguration und Ausgaben jedes Activity-Typs, von PowerShell-Skripten über Dienste und Dateien bis zu REST, SQL und Ablaufsteuerung.

KI-Agent / KI-Agententeam

aiAgent bearbeitet eine Aufgabe über mehrere Modell- und Werkzeugaufrufe. aiAgentTeam enthält einen Supervisor und Spezialisten mit eigenen Sitzungen und begrenzten parallelen Aufträgen. Nur das äußere Team ist ein Workflow-Step. Sichtbare Mitglieder lassen sich anklicken und mit eigenen Rollen, Anweisungen und Werkzeugen konfigurieren. needs_input geht an den Supervisor; während des Steps gibt es keine interaktive Benutzerunterhaltung.

  • Config: task, agent (Einzelagent) oder members (Team), resultFormat (text/json), resultSchema, maxModelCalls, maxToolCalls, maxDelegations, maxParallelMembers, timeoutSeconds. maxParallelMembers begrenzt ein Delegationsbündel zusätzlich zum Admin-Limit Agents:TeamMaxParallelMembers (Standard 3) und zur Mitgliederzahl; 1 bleibt sequenziell. Unabhängige Spezialisten können zusammen arbeiten, Reviewer erst nach den Spezialisten und nie im selben Bündel mit ihnen. Live-Teamhinweise zeigen neue fremde Belege und Registereinträge; sie ersetzen keine Originalbelege und erfüllen keine Prüfpflicht. Agent/Mitglied: stabile id, freie role, instructions, optionales model, tools, skillIds, useServiceIdentity. Teammitglieder haben eigene targetMachineId und credentialId; Einzelagenten verwenden die üblichen Zielfelder des Nodes. Genau ein Mitglied hat isSupervisor: true. Optional erhalten andere Mitglieder isReviewer: true (im Designer: „Funktion im Team“). Diese Prüffunktion ist unabhängig vom frei benannten Rollenfeld. Alle ausgewählten Reviewer müssen den aktuellen Arbeitsstand prüfen. Offene needs_input-/failed- Antworten verhindern einen erfolgreichen Abschluss; nur dasselbe Mitglied kann sie mit completed schließen. Neue Fachantworten oder Werkzeugaufrufe des Supervisors machen frühere Reviews ungültig. Nach höchstens zwei zusätzlichen Nachfassrunden innerhalb der bestehenden Budgets schlägt eine weiterhin unvollständige Prüfung fehl.
  • Entwurf aus Beschreibung: Ist KI aktiv, bietet der Team-Editor Team aus Beschreibung entwerfen (Admin/Operator). Beschreibe das Team und nenne Maschinen, Credentials, Pfade und Workflows genau so, wie sie in NodePilot heißen. Der Entwurf wird gegen das aufgelöst, was du nutzen darfst, und zur Prüfung mit dem wirksamen Ziel, Credential bzw. der Service-Identität, den Werkzeugen, Pfaden, Hosts (eine leere Hostliste steht als „alle Hosts“) und Skills jedes Mitglieds angezeigt. Namen, die sich nicht eindeutig zuordnen lassen oder in deinem Text fehlen, werden nie geraten: Eine nicht auflösbare Maschine, ein Credential oder die Service-Identität sperren Übernehmen, bis du einen Treffer wählst oder den Wunsch verwirfst. Gespeichert oder veröffentlicht wird erst, wenn du den Workflow speicherst und veröffentlichst.
  • Werkzeuge: freigegebene Dateipfade, HTTP GET/HEAD mit optionaler Hostbeschränkung, veröffentlichte Workflows, PowerShell, CMD, installiertes Git Bash und ausgewählte MCP-Tools. MCP unterstützt stdio und Streamable HTTP. Einstellungen → KI-Agenten verwaltet Server, versionierte Skill-ZIPs und Laufzeitobergrenzen. Skills enthalten SKILL.md mit YAML-Name/Beschreibung, Ressourcen und optionalen Skripten. Skripte benötigen das passende freigegebene Shell-Tool. CMD/Bash-Skripte führen die geprüfte kanonische Befehlsform aus, keine gleichnamigen Paketdateien. PowerShell behält Originalbytes und Signaturprüfung auf dem Ziel bei.
  • Leseprüfung: Shells und Skill-Skripte erlauben einen geprüften Umfang an Lesebefehlen. HTTP benötigt keine URL-Whitelist, verbietet Bodies/Weiterleitungen und behält den Netzwerkschutz. MCP-Lesefreigaben sind administrativ an Server- und Werkzeugstände gebunden; externe Dienste und Zugangsdaten müssen Lesezugriff durchsetzen. Kindworkflows und ihre aufgelösten Schritte werden zur Laufzeit geprüft, einschließlich synchroner Folgeaufrufe. Unbekannte Aktionen scheitern.
  • Identität: Credential/Maschinenstandard auswählen oder Dienstidentität ausdrücklich wählen und administrativ erlauben. Shell hat die Betriebssystemrechte dieses Kontos; Werkzeuglisten und Arbeitsverzeichnisse bieten keine Shell-Isolation. Windows lokal/WinRM.
  • Standardbudgets: Einzelagent 20 Modellaufrufe / 40 Tools / 20 Minuten; Team 100 / 500 / 20 Delegationen / 30 Minuten, gemeinsam gezählt. Zwei aktive Läufe pro Serverprozess. Timeout 0 verwendet den Standard. Warteschlange, Tools und untergeordnete Workflows zählen zur Gesamtlaufzeit. Wiederholungen der gesamten Workflow-Aktivität werden abgelehnt. Bei erschöpftem Modellbudget der Untersuchung wird nach Ende gestarteter Mitglieder der reservierte werkzeugfreie Bericht erzeugt; offene Mitglieder/Reviews bleiben Einschränkungen. Budgets steigen dadurch nicht, technische Fehler bleiben Fehler. Ein vorübergehender Modell-Timeout, HTTP 408/429/500/502/503/504 oder eindeutig erkannter Verbindungsabbruch darf nach einer Sekunde einmal innerhalb derselben Budgets wiederholt werden, ohne Werkzeuge erneut auszuführen. Authentifizierungsfehler, ungültige Antworten und Werkzeugfehler werden nicht wiederholt. Bei dauerhaftem Fehler bleiben vorhandene vorläufige Befunde und Journalbelege erhalten, ohne einen Abschluss vorzutäuschen. Abbruch/Neustart macht bereits ausgeführte Aktionen nicht rückgängig.
  • Logs: files_search filtert auf dem Ziel, logs_collect überträgt Blöcke in eine temporäre gemeinsame Ablage, maximal 250 MB pro Lauf/Team. logs_search liefert begrenzte Quellenausschnitte. Rohdateien werden entfernt; verwendete Belege bleiben im Journal.
  • Kontext: 250.000 maximale Ausgabetokens je Modellaufruf; niedrigere Profil- und Modellgrenzen gelten weiter. Die separate Eingabegrenze wird in Zeichen konfiguriert. Ab 75 % verdichtet der Host ältere vollständige Runden zu untrusted Arbeitsnotizen. Originalauftrag und aktuelle Runden bleiben erhalten. Alle Mitglieder können gespeicherte Belege über evidence_list/evidence_read erneut lesen, ohne Maschinenabfragen zu wiederholen. evidence_analyze untersucht begrenzte überlappende Abschnitte und protokolliert deren Bereiche, Befunde und offene Fragen. Zusammenfassungen zählen zum Modell-/Zeitbudget; sie ersetzen keine Originalbelege und keine neue Beobachtung für eine Review-Freigabe. Verdichtungen erscheinen im Journal.
  • Outputs: output, error, param.agentRunId, param.outcome, param.outcomeReason, param.modelCalls, param.toolCalls, param.delegations, param.promptTokens, param.completionTokens. JSON wird lokal geprüft, mit höchstens einer werkzeuglosen Korrekturrunde innerhalb des Budgets. Externe Schema- Referenzen sind gesperrt. Das Journal zeigt nummerierte Ereignisse und lädt bei Reconnect nach.

Die Veröffentlichung autorisiert die konfigurierten autonomen Aktionen. Chat-Freigaben und llmQuery bleiben unverändert. Voraussetzung: aktivierte KI mit aktivem LLM-Profil.

ScopeAusführungsort
RemoteWindows-Zielsystem über targetMachineId und WinRM
Engine-localNodePilot-API-Prozess
HybridAbhängig von der Konfiguration remote oder engine-local

Jeder Step unterstützt config.retry mit maxAttempts, backoff, initialDelayMs und maxDelayMs. maxDelayMs deckelt jede Wartezeit vor einem neuen Versuch; 0 oder ein fehlender Wert bedeutet 30000 ms, eine Wartezeit ist also nie unbegrenzt. Dauerhafte Remote-Fehler sind davon ausgenommen: ein abgelehnter WinRM-Logon, eine per SSL-Policy geblockte Session und ein nicht entschlüsselbares Credential lassen den Step beim ersten Versuch scheitern — Wiederholen hilft dort nicht, und wiederholte Fehl-Logons können ein Domänenkonto sperren. config.timeoutSeconds begrenzt einen Step. Der Execute-Request kann zusätzlich die gesamte Execution begrenzen.


runScript

Hybrid. Führt PowerShell aus — mit gesetzter Maschine über NodePilots managed WinRM-Session; ohne Maschine engine-local im API-Host, wo das Script die Remote-Verbindung via Invoke-Command/New-PSSession auch selbst managen kann (SCOrch-Stil, Trade-offs siehe Remote-Execution).

  • Config: script, engine (auto/powershell/pwsh/runspace), timeoutSeconds, isolated (bool, nur lokal — eigener Prozess im Windows Job Object: Crash-/Leak-Containment, keine verwaisten Prozesse) + optionale Caps memoryLimitMb (lässt Allokationen fehlschlagen, terminiert nicht) / maxProcesses, successExitCodes (komma-separiert, opt-in Exit-Code-Gate), transcript (bool — zeichnet Befehle und Ausgabe verschränkt wie in einer Konsole auf)
  • Engine (nur lokal; ein Remote-Step läuft immer in Windows PowerShell 5.1 auf dem Ziel):
    • auto (Standard) und powershell führen das Skript in Windows PowerShell 5.1 als eigenen Prozess aus. Ein lokaler Step sieht damit dieselben Module wie dasselbe Skript remote: alle Windows-Module und alle Module, die auf dem NodePilot-Server für alle Benutzer installiert sind.
    • pwsh nimmt einen PowerShell-7-Prozess und setzt eine PowerShell-7-Installation voraus.
    • runspace läuft im In-Process-Pool mit PowerShell 7. Das ist am schnellsten, weil kein Prozessstart anfällt. Dafür lädt es nur Module mit Core-Kennzeichnung, kann keine Hintergrund-Jobs starten (Start-Job, Get-WindowsUpdateLog) und lässt sich nicht mit isolated kombinieren. Startet ein Skript dort selbst eine Windows PowerShell, bekommt nur der direkte Aufruf & powershell.exe die richtigen Module; eine über cmd /c, Start-Process oder [Diagnostics.Process] gestartete fehlen Befehle wie New-Guid.
  • Module aus der PowerShell Gallery (z. B. PSWindowsUpdate mit Get-WindowsUpdate) sind keine Windows-Module. Sie müssen dort installiert sein, wo der Step läuft: lokal für alle Benutzer auf dem NodePilot-Server, remote auf der Zielmaschine.
  • Hintergrundprogramme und Isolation-Robustheit: Ein Step, der als Prozess läuft, endet mit seinem Skript. Nach dem Skriptende sammelt NodePilot restliche Ausgabe höchstens Engine:IsolatedDrainGraceSeconds lang (default 5 s). Ein Programm, das das Skript ohne neues Fenster im Hintergrund startet (Start-Process -NoNewWindow, cmd /c start), läuft weiter, hält den Step aber nicht mehr fest. Außerdem serialisiert NodePilot inheritable-handle-Spawns, damit ein in einen Fremdprozess geleaktes Pipe-Handle einen isolierten Lauf nicht dauerhaft blockiert.
  • Ausgabelimit: Engine:MaxCapturedOutputChars (default 16.777.216 Zeichen, restart-pflichtig) begrenzt die Ausgabe, die eine Skriptausführung über alle Streams sammelt, für Prozess-, Runspace- und WinRM-Ausführung gleichermaßen. Eine Überschreitung beendet den Step mit einem Ausgabelimit-Fehler. Der Standard lässt Platz für die beiden je 1 MiB großen Ausgaben von startProgram; ein kleinerer Wert begrenzt auch diese Aktivität.
  • Outputs: output, error, param.exitCode (immer — das letzte native Kommando dieses Skripts), param.* (die Variablen, die dieses Skript zuweist). output enthält jedes Pipeline-Objekt als Text, wie bei einem Remote-Step; Write-Host, Warnungen und Fortschritt gehören nicht dazu.
  • Erfolg (fehler-basiert, lokal wie remote): Ein Step scheitert, sobald das Skript einen PowerShell-Fehler schreibt, auch einen nicht terminierenden (Write-Error, ein fehlgeschlagenes Cmdlet unter Continue), oder wenn es sich nicht parsen lässt. In Windows PowerShell 5.1 zählt stderr eines nativen Programms als Fehler und beendet das Skript; wer das nicht will, führt die Ströme im Programmaufruf zusammen: cmd /c "tool.exe 2>&1". Ein exit N markiert den Step nicht automatisch als fehlgeschlagen. Für exit-code-basierte Bewertung ist successExitCodes zu setzen, zum Beispiel "0". successExitCodes/param.exitCode greifen für Native-Command-Codes ($LASTEXITCODE) in allen Engines; ein script-eigenes exit N ist nur im Prozess/isoliert-Modus als Wert sichtbar (Runspace sieht exit nicht).
  • Notes: Variablen, die das Skript zuweist, werden zu param.* ($hostName = … → {{step.param.hostName}}) — auch wenn das Skript danach mit exit oder return endet oder einen Fehler wirft. Ein Upstream-Parameter, den das Skript nur liest, bleibt Output des erzeugenden Steps; PowerShell-Automatiken und Preference-Variablen werden nie publiziert. Auto-Quoting: {{step.output}} wird als Single-Quoted String eingesetzt — $x = {{step.output}} schreiben, nicht $x = '{{step.output}}'. In einem Wort oder Pfad wird der Wert Teil dieses einen Worts, egal wo die Vorlage steht: C:\logs\{{step.output}}.txt, {{step.param.dir}}\app.txt und {{step.param.name}}.log bleiben jeweils ein Argument. Ein Methodenaufruf wie {{step.output}}.Trim() bleibt ein Methodenaufruf.

fileOperation

Remote.

  • Config: operation (copy/move/delete/exists/create/rename), path, destination, newName. Asserts -PathType Leaf auf destruktiven Ops. create erzeugt eine leere Datei (truncated mit -Force).
  • Outputs: param.operation, param.path, param.destination, param.exists, param.fullName, param.creationTime, param.newPath/param.newName (op-abhängig)

folderOperation

Remote.

  • Config: operation (copy/move/delete/exists/list/create/rename), path, destination, newName. Asserts -PathType Container. list enumeriert direkte Children.
  • Outputs: param.operation, param.path, param.destination, param.exists, param.fullName, param.creationTime, param.newPath/param.newName; list → param.items + param.count + param.truncated

textFileEdit

Remote. BOM-aware, atomarer Write (tmp-Datei + File.Replace), der die Berechtigungen der Originaldatei beibehält.

  • Config: operation (append/prepend/insert/delete/replace/replaceLine), path, content, lineNumber, lineRange ([from,to], Selektor für delete), matchPattern, replace, useRegex, ignoreCase, occurrences, encoding (auto/utf8/utf8-bom/utf16le/utf16be/ascii), lineEnding (preserve/crlf/lf), createIfMissing, dryRun, backupSuffix, appendIfMissing, appendIfMissingExact (default true), maxFileSizeMB (default 50)
  • Outputs: param.operation, param.path, param.linesBefore/linesAfter/linesChanged, param.encoding, param.lineEnding, param.backupPath, param.dryRun

serviceManagement

Remote.

  • Config: serviceName, action (start/stop/restart/status/create/delete/setStartType; create/setStartType nehmen binaryPath/displayName/description/startupType; delete stoppt den Dienst und entfernt ihn dauerhaft via sc.exe delete). sc.exe meldet Fehler auf stdout und lässt den Error-Stream leer, deshalb wird der Exit-Code der sc.exe-Aufrufe hinter delete und hinter einem AutomaticDelayedStart-Startup-Type geprüft und ein Non-Zero-Exit lässt den Step scheitern — ein abgelehnter Delete oder Startup-Type-Wechsel wird nie als Erfolg gemeldet. serviceName muss den Windows-Regeln für Dienstnamen folgen (höchstens 256 Zeichen, kein / oder \); NodePilot lehnt zusätzlich doppelte Anführungszeichen und Steuerzeichen ab, weil der Name als natives Argument an sc.exe geht.
  • Outputs: param.name, param.status, param.startType

registryOperation

Remote.

  • Config: operation (read/write/deleteValue/deleteKey/createKey/exists/listSubKeys/listValues), keyPath, valueName, value, valueType (String/ExpandString/Binary/DWord/MultiString/QWord). read+exists agieren auf Key- oder Value-Ebene je nach valueName.
  • Outputs: param.value+param.type (single-read), param.values+param.count (listValues), param.subKeys+param.count (listSubKeys), param.exists, param.created

wmiQuery

Remote.

  • Config: className, namespace, filter, mode (query/wql/invokeMethod), query (für wql), methodName/arguments (für invokeMethod), captureProperties (optionales string[]). Mit captureProperties → erste Row in param.<Name> + param.count. Ohne → Legacy-Text output. Property-Namen müssen CIM-konform sein (^[A-Za-z_][A-Za-z0-9_]*$).
  • Outputs: param.*, param.count, output

startProgram

Remote.

  • Config: filePath, arguments, workingDirectory, useShellExecute, waitForExit, timeoutSeconds, successExitCodes
  • Outputs: param.exitCode, param.processId, param.stdout, param.stderr, param.stdoutTruncated, param.stderrTruncated, param.waited

stdout und stderr werden als UTF-8 dekodiert, wenn das Programm gültiges UTF-8 (oder UTF-16 mit Byte-Order-Mark) geschrieben hat, sonst in der OEM-Codepage des Rechners, dem Standard von Konsolenprogrammen. Jeder Strom ist auf 1 MiB begrenzt. Überschreitet das Programm timeoutSeconds, wird es beendet und der Step scheitert mit der bis dahin gesammelten Ausgabe.

Der gespeicherte filePath muss ein absoluter lokaler Programmpfad auf dem Zielrechner sein. Die Engine lehnt UNC-Pfade und bloße Programmnamen ab und durchsucht PATH nicht. Im Designer werden cmd, powershell, cscript und wscript (jeweils auch mit .exe) beim Verlassen des Felds zu absoluten Pfaden ergänzt. API/MCP-Clients und generierte Definitionen müssen absolute Pfade selbst liefern. useShellExecute: true wird abgelehnt, wenn StartProgram:DisallowShellExecute aktiviert ist.

Mit waitForExit: false liefert die Activity die Prozess-ID, während das Programm weiterläuft; stdout und stderr werden nicht erfasst. Für den Exit-Code muss waitForExit: true gesetzt sein, für die Ausgabeerfassung zusätzlich useShellExecute: false.

Das Timeout begrenzt das Warten auf den laufenden Prozess. Nach seinem Ende wird weitergelesen, bis beide Ausgabeströme enden oder für Engine:IsolatedDrainGraceSeconds (Standard 5 s) keine weiteren Bytes erfasst werden. Das Erfassen gepufferter Daten startet diese Nachlesefrist erneut; verworfene Bytes oberhalb des Erfassungslimits tun das nicht. Die gesamte Erfassung ist auf Prozess-Timeout plus Nachlesefrist begrenzt, auch wenn ein überlebendes Enkelkind weiterschreibt. Endet eine Pipe nicht rechtzeitig, gibt der Step die erfasste Ausgabe mit einem Hinweis in der Meta-Zeile zurück. Erreicht ein Ausgabestrom sein Erfassungslimit, wird weitere Ausgabe verworfen, während der Prozess weiterläuft; stdoutTruncated beziehungsweise stderrTruncated zeigt das an.

powerManagement

Remote.

  • Config: action (shutdown/restart/logoff/abort/hibernate), delaySeconds, force, message
  • Outputs: —

Bei Shutdown und Restart ist force standardmäßig true. Mit force=false muss delaySeconds auf 0 stehen; ein positiver Wert wird vor der Ausführung abgelehnt. Windows erzwingt bei einem positiven Shutdown-Timer das Schließen von Apps. Zum Warten ohne erzwungenes Schließen eine separate delay-Aktivität vor diesen Schritt setzen und delaySeconds=0 beibehalten.

scheduledTask

Remote. Erfordert meist Admin auf dem Ziel.

  • Config: action (get/start/stop/enable/disable/unregister/register, default get), taskName, taskPath (default \). Register-only: program, arguments, workingDirectory, triggerType (once/daily/weekly/atLogon/atStartup), startTime, daysOfWeek[], weeksInterval, daysInterval, runAsUser (Default SYSTEM; ein eingebautes Konto oder ein Managed Service Account wie DOMAIN\gmsa$, kein normaler Domänenbenutzer), runLevel (limited/highest), description, force
  • Outputs: param.taskName, param.state, param.lastRunTime, param.lastTaskResult, param.nextRunTime
  • Provider-Fallback: Aktionen auf vorhandenen Tasks verwenden zuerst die PowerShell-Cmdlets. Nur wenn der ScheduledTasks-CIM-Provider mit 0x80041318 fehlschlägt, greift die Activity innerhalb derselben lokalen/WinRM-PowerShell-Session auf die Task-Scheduler-Automation-API zurück. register bleibt ausschließlich Cmdlet-basiert.

fileHash

Remote.

  • Config: path, algorithm (MD5/SHA1/SHA256/SHA384/SHA512, default SHA256), expected (optional — verifiziert; Mismatch ⇒ Step fails)
  • Outputs: param.hash, param.algorithm, param.match

zipOperation

Remote. Compress baut einen explizit validierten Datei-Manifest auf und schreibt ihn direkt mit ZipArchive; Wildcards sind nur im letzten Source-Segment erlaubt und eckige Klammern werden literal behandelt. Extract validiert und schreibt jeden Entry einzeln. Zip-Slip, vorhandene Junctions/Symlinks in Source oder Destination und das Folgen eines bestehenden Output-Links werden abgelehnt; die Ziel-ACL bleibt die Grenze gegen parallele Parent-Renames.

  • Config: operation (compress/extract, default compress), source (Wildcards erlaubt für compress), destination, compressionLevel (Optimal/Fastest/NoCompression — compress only), force
  • Outputs: param.destination, param.sizeBytes (extract ⇒ 0)

restApi

Engine-local.

  • Config: url, method, body, headers (bei einem Request mit Body wandert ein hier gesetzter Content-Type auf die Entity — kein zweites, widersprüchliches Feld auf der Leitung; ein unparsbarer Wert bleibt unbeachtet und der Body geht weiter als application/json raus. Ein Request ohne Body und jedes GET/HEAD hat keine Entity, ein dort gesetzter Content-Type fällt weg), timeoutSeconds, proxyMode (default/direct/custom), proxyAddress, noProxy
  • Outputs: param.statusCode (Response-Body in output als HTTP {code} {status}\n{body}; Headers nicht als param)

sql

Engine-local. Connection-Precedence: connectionRef > Builder > raw connectionString.

  • Config: provider (sqlserver/sqlite/postgres), query, parameters (benannte Query-Parameter), timeoutSeconds. Connection-Optionen: (a) Builder — SQL Server: server/database/authentication/username/password/encrypt/trustServerCertificate; Postgres: host/port/database/username/password/sslMode (VerifyFull + Trust Server Certificate=false default; schwächere Modi nur für literale Loopback-Hosts); SQLite: dataSource; (b) raw connectionString; (c) named connectionRef aus SqlActivity:ConnectionStrings:{name}. Die Postgres-TLS-Policy gilt auch für raw/ref.
  • Outputs: SELECT → param.rowCount + erste-Row-Spalten als param.<col> + param.row{i}_{col} (erste 20 Rows) + param.truncated/param.flatKeysTruncated. DML/DDL → param.rowsAffected + param.rowCount
  • Die Form hängt am Statement, nicht an der Trefferzahl: ein SELECT ohne Treffer liefert weiterhin die SELECT-Form ([], param.rowCount von 0) und kein rowsAffected. Skalare Spalten werden invariant veröffentlicht — 1.5, nie 1,5 — ein Vergleich bedeutet damit auf jedem Host dasselbe.

emailNotification

Engine-local. Einzeler-Empfänger. SMTP via Smtp:*.

  • Config: to, subject, body, isHtml, timeoutSeconds
  • Outputs: —

delay

Engine-local.

  • Config: seconds
  • Outputs: —

junction

Engine-local, controlFlow.

  • Config: mode (waitAll/waitAny/waitNofM), requiredCount (für waitNofM)
  • Outputs: param.* der vorgelagerten Steps (bei gleichem Namen gilt der erste Wert)

forEach

Engine-local, controlFlow. Teilt sich ISubWorkflowGate mit startWorkflow.

  • Config: items (Template → JSON-Array oder Zeilenliste), itemsFormat (auto/json/lines), childWorkflowNameOrId, itemParameterName (default item), indexParameterName (default index), parameters (statisch, an jedes Child), maxParallelism (default 1, hard cap 64), continueOnError, timeoutSecondsPerItem (default 3600)
  • Outputs: param.total, param.succeeded, param.failed, param.skipped, param.firstError, param.results (JSON-Array)

decision

Engine-local, controlFlow. Routing via step.param.case == "name" Edge-Conditions.

  • Config: cases (Array, each {name, condition}; condition nutzt denselben AST wie Edge conditionExpression, type hier obligatorisch), defaultCaseName (default default)
  • Outputs: param.case, param.matched, param.reason

startWorkflow

Engine-local, controlFlow.

  • Config: workflowNameOrId, parameters, waitForCompletion, timeoutSeconds
  • Outputs: sync → param.* (gespiegelt aus Child-returnData) + immer param.__executionId/__status/__workflowId/__workflowName. fire-and-forget → param.workflowId/param.workflowName/param.executionId/param.waited

returnData

Engine-local, controlFlow.

  • Config: data (Objekt mit {{template}}-Werten)
  • Outputs: param.* (Keys aus data)

xmlQuery

Hybrid. Mit Zielmaschine werden Datei und XPath dort über WinRM verarbeitet. Ohne Ziel läuft die Abfrage auf dem NodePilot-Server. Auch Inline-Inhalte werden auf dem gewählten Ziel ausgewertet.

  • Config: source, path/content, xpath, namespaces, resultMode, timeoutSeconds
  • Outputs: param.result, param.count
  • resultMode schaltet nur die Kardinalität. Beide Modi liefern den Elementtext, all als JSON-Array. Numerische XPath-Ergebnisse verwenden einen invarianten Dezimalpunkt — ein Vergleich bedeutet damit auf jedem Host dasselbe.

jsonQuery

Hybrid. Mit Zielmaschine werden Datei und JSONPath dort über WinRM verarbeitet. Ohne Ziel läuft die Abfrage auf dem NodePilot-Server. Auch Inline-Inhalte werden auf dem gewählten Ziel ausgewertet. Die JSONPath-Bibliothek wird im Speicher bereitgestellt; auf dem Ziel ist keine zusätzliche Installation nötig.

  • Config: source, path/content, jsonPath, resultMode, timeoutSeconds
  • Outputs: param.result, param.count
  • Skalare werden invariant veröffentlicht: 9.99, Booleans klein geschrieben. Ein ISO-8601-Zeitstempel bleibt der Originaltext — er wird nie in ein host-formatiertes Datum umgewandelt.

log

Engine-local.

  • Config: level (info/warning/error), message
  • Outputs: output (Meldung), param.level, param.message

generateText

Engine-local. Entropie aus RandomNumberGenerator, rejection-sampled (kein Modulo-Bias). Generierter Wert wird nicht redigiert.

  • Config: mode (alphanumeric default /alphabetic/numeric/hex/guid/password/custom), length (1–1024, default 16; ignoriert für guid), customCharset (required für mode=custom), excludeAmbiguous (entfernt verwechslungsfähige Zeichen 0/O, 1/l/I …). password = nur Charset-Preset (keine Policy-Garantie).
  • Outputs: output (generierter String), param.text, param.length

llmQuery

Engine-local. Ruft einen OpenAI-kompatiblen Endpunkt auf (Prompt → Text) — Chat Completions oder die Responses-API, je nach Pfad der Base-URL. Nutzt per Default das aktive LLM-Profil (Llm:ActiveProfileId → Llm:Profiles:<id>); per-Node überschreibbar. Braucht Llm:Enabled=true und ein auflösbares aktives Profil (zentraler Kill-Switch — gilt auch bei Node-eigenem Endpunkt). Teilt Transport + SSRF-Guard mit dem KI-Assistenten (LlmEndpointGuard validiert jede baseUrl, Cloud-Metadata-Endpoints sind blockiert).

  • Config: prompt (required; {{templates}} erlaubt), systemPrompt (optional; leer = Passthrough), jsonMode (bool → response_format:json_object, Antwort wird nicht validiert). Per-Node-Overrides (leer → global): baseUrl (absolute http/https), model, apiKey (Secret, auto-redigiert), maxTokens (>0), temperature (0–2, per-Node-only), timeoutSeconds (>0). Zeigt baseUrl auf einen anderen Origin (Schema, Host, Port) als das aktive Profil, geht der API-Key des Profils nicht dorthin; gesendet wird nur ein am Node gesetzter apiKey.
  • Outputs: output (Antworttext), param.model, param.promptTokens, param.completionTokens, param.totalTokens, param.finishReason (Token-Keys immer gesetzt; "" wenn der Server keine usage liefert).

waitForCondition

Hybrid.

  • Config: conditionType (script default / pathExists / serviceRunning / portOpen / httpOk), intervalSeconds, timeoutSeconds. Mode-spezifisch: script → script (PowerShell-Expression, keine {{…}}-Templates), pathExists → path, serviceRunning → serviceName, portOpen → host+port, httpOk → url. Typed Modes akzeptieren {{upstream.param.x}} — die Engine quotet Werte sicher. Netzwerkmodi laufen nur für Hosts, die exakt unter WaitForCondition:AllowedHosts freigegeben sind (default ["localhost"]); Schema, Port, Pfad und Wildcards gehören nicht in diese Liste. Das ist nicht dieselbe Liste wie RestApi:AllowedHosts — letztere betrifft nur restApi. Sie ist für beide Netzwerkmodi die alleinige Autorität: RestApi:BlockPrivateNetworks/RestApi:AllowedHosts werden nicht mitgeprüft, eine Loopback-Probe braucht also keine restApi-Ausnahme. Immer gesperrt bleibt Link-Local/Cloud-Metadata (169.254/16) — das lässt sich über keine Allow-Liste öffnen.
  • Engine (Script-Modus, nur lokal): engine mit denselben Werten wie bei runScript; Standard auto = Windows PowerShell 5.1 wie ein Remote-Step. Die getypten Modi laufen immer im In-Process-Pool.
  • Outputs: param.attempts, param.elapsedSeconds, param.lastResult
Alle Kapitel