Zum Hauptinhalt springen
Die Grammatik qxctl maestro ... macht Maestro-Präsenznachweise sichtbar. Maestro ist die Präsenzautorität; qxctl liest und untersucht lediglich, was Maestro erfasst. Keiner von beiden erstellt eigenständig Docking-Beziehungen.

Inventar

Maestro inventory
qxctl maestro inventory zeigt das vollständige, abgeleitete, schreibgeschützte Inventar von Maestro zu authentifizierten Docking-Beziehungen von Vektor-Engines pro TOPS und Rezeptor.

Verwandte administrative Routen

Weitere qxctl-Leaves stellen Maestro-bezogene Administration bereit:
  • Status und Inspektion von Docking-Nachweisen
  • Wiederherstellungsrouten, begrenzt durch Maestros eigene Verträge
  • Grundlegende Lifecycle-Registrierung und native Überwachung für Maestro selbst
Jede Mutationsroute läuft über den exakten modulverantworteten Adapter. qxctl rendert niemals Maestro-Deskriptoren aus internem Parsing und ruft niemals implizit die neueste Version auf.
Maestro startet, plant, überwacht oder ruft keine Engines auf. qxctl maestro inventory ist schreibgeschützt. Binding, Abstimmung, Session-Koordination oder ein Lifecycle-Plan allein begründen keine Maestro-Präsenz.

Verwandte Oberflächen

Maestro

Vertrag und Grenzen der Präsenzautorität.

qxctl engines

Engine-Binding-Registry (Bindings sind kein Docking).

qxctl session

Authentifizierte Sessions, die zur Erfassung von Präsenz verwendet werden.

Engines-Übersicht

Unabhängig installierbare Vektor-Engines, die bei Maestro andocken.
Zuletzt geändert am 10. Oktober 2026