# Eigenständige Nutzung

Queuety wird als WordPress-Plugin bereitgestellt, aber für den Großteil der Laufzeitumgebung ist keine aktive WordPress-Anfrage erforderlich.

Warteschlange, Workflow-Engine, State Machines, Signale, Artefakte, Batchverarbeitung, Zeitplanung, Protokollierung, Metriken und Ressourcenverwaltung greifen alle auf dieselben MySQL-Tabellen zu. Wenn ein anderer PHP-Prozess dieselbe Datenbank öffnen kann, kann er den Kern direkt verwenden.

Das ist die Grenze der eigenständigen Nutzung von Queuety. Die datenbankgestützte Orchestrierungs-Engine lässt sich außerhalb von WordPress verwenden. Die WordPress-Bridges gehören weiterhin zu WordPress.

## Was außerhalb von WordPress funktioniert

Mit einer direkten `Connection` kann ein eigenständiger Prozess Queuety initialisieren und dieselben Fassadenmethoden wie das Plugin für die Laufzeitumgebung des Kerns verwenden:

- Jobs ausführen
- Worker und Worker-Pools starten
- Workflows erstellen und ausführen
- Signale, Genehmigungen und Workflow-Eingaben senden
- State Machines erstellen und ausführen
- Workflow- und Maschinenstatus einsehen
- Artefakte speichern und lesen
- Batchverarbeitung, Verkettung und wiederkehrende Zeitpläne steuern
- Protokolle, Metriken, Warteschlangen und Laufzeitstatus abfragen

So kann ein externes Produkt auf denselben Orchestrierungsstatus zugreifen, ohne zuvor WordPress zu starten, solange es dieselbe Datenbank und dieselben Tabellennamen verwendet.

Worker-Pools sind derzeit die einzige Ausnahme: `Queuety::run_worker_pool()` und `Queuety::run_auto_scaling_worker_pool()` lesen die Konstanten WordPress `DB_HOST`, `DB_NAME`, `DB_USER` und `DB_PASSWORD` statt der initialisierten Verbindung. Deshalb muss ein eigenständiger Prozess diese Konstanten definieren, bevor er einen Pool startet ([#5](https://github.com/inline0/queuety/issues/5)).

## Was innerhalb von WordPress bleibt

Die WordPress-spezifische Bridge-Schicht setzt weiterhin voraus, dass WordPress geladen ist.

Dazu gehören:

- Plugin-Bootstrap und Aktivierungsverhalten in `queuety.php`
- `Queuety::on_action()`, wofür `add_action()` erforderlich ist
- `Queuety::replace_wp_cron()` und `Queuety::restore_wp_cron()`, die auf WordPress cron-Filter und `do_action()` angewiesen sind
- der echte Registrierungsweg des `wp queuety ...`-Befehls, der voraussetzt, dass WP-CLI WordPress lädt

Diese Komponenten sind Adapter für die Laufzeitumgebung des Kerns. Sie sind nicht die Laufzeitumgebung selbst.

## Initialisierung

Der eigenständige Pfad ist bewusst schlank gehalten. Öffne eine datenbankgestützte `Connection`, initialisiere die Fassade und stelle sicher, dass das Schema vorhanden ist.

```php
use Queuety\Connection;
use Queuety\Queuety;

$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
);

Queuety::init( $conn );
Queuety::ensure_schema();
```

Danach ist die normale Laufzeit-API verfügbar:

```php
Queuety::dispatch( 'send_email', [ 'to' => 'user@example.com' ] );

$workflow_id = Queuety::workflow( 'report' )
    ->then( FetchReportData::class )
    ->then( RenderReport::class )
    ->dispatch( [ 'report_id' => 42 ] );

$machine_id = Queuety::machine( 'agent_session' )
    ->state( 'awaiting_input' )
    ->on( 'message', 'planning' )
    ->state( 'planning' )
    ->action( PlanSessionAction::class )
    ->dispatch();
```

## Tabellennamen

Für die eigenständige Nutzung sind keine spezifischen Tabellennamen von WordPress erforderlich. Du brauchst lediglich eine konsistente Präfixstrategie.

Wenn du Queuety auf eine WordPress-Datenbank verweist, verwende dasselbe Präfix wie das Plugin. Wenn du Queuety in einer separaten Datenbank verwendest, kann das Verbindungspräfix dem entsprechen, was deine Host-Anwendung erwartet. Der Queuety-spezifische Tabellenanteil wird weiterhin durch `QUEUETY_TABLE_PREFIX` und die Überschreibungen pro Tabelle gesteuert.

Eingebettete Laufzeitumgebungen, die eine Datenbank gemeinsam nutzen, können diesen Queuety-spezifischen Anteil pro Verbindung festlegen:

```php
$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
    table_prefix: 'themequeue_',
);
```

Dadurch bleibt das Datenbankpräfix von WordPress unverändert, während Tabellen wie `queuety_jobs` in `wp_themequeue_jobs` aufgelöst werden.

## Denkmodell

Die Aufteilung lässt sich am besten so verstehen:

- Queuety-Kern = Warteschlange, Worker, Workflows, State Machines, Signale, Artefakte und Laufzeitmetadaten
- WordPress-Adapter = Plugin-Bootstrap, Hook-Bridges, WP-Cron-Ersatz und WP-CLI-Registrierung

So bleibt eine einzige Orchestrierungs-Engine erhalten, während die ereignis- und anfragebezogene Integration für WordPress dort bleibt, wo sie hingehört.