# Selvstændig brug

Queuety er pakket som et WordPress-plugin, men det meste af runtime-miljøet har faktisk ikke brug for en aktiv WordPress-forespørgsel.

Køen, workflow-motoren, tilstandsmaskinerne, signalerne, artefakterne, batchbehandlingen, planlægningen, logningen, målingerne og ressourcestyringen kører alle mod de samme MySQL-tabeller. Hvis en anden PHP-proces kan åbne den samme database, kan den bruge denne kerne direkte.

Det er grænsen for selvstændig brug i Queuety. Den databasebaserede orkestreringsmotor kan bruges uden for WordPress. Broerne til WordPress hører stadig til i WordPress.

## Hvad fungerer uden for WordPress

Med en direkte `Connection` kan en selvstændig proces initialisere Queuety og bruge de samme facade-metoder som pluginet til kernens runtime-miljø:

- afsend jobs
- kør workers og worker-pools
- opbyg og afsend workflows
- send signaler, godkendelser og workflow-input
- opbyg og afsend tilstandsmaskiner
- undersøg status for workflows og maskiner
- gem og læs artefakter
- styr batchbehandling, kædning og tilbagevendende tidsplaner
- forespørg på logfiler, målinger, køer og runtime-status

Det betyder, at et eksternt produkt kan tilgå den samme orkestreringstilstand uden først at starte WordPress, så længe det bruger den samme database og de samme tabelnavne.

Worker-pools er den eneste undtagelse i øjeblikket: `Queuety::run_worker_pool()` og `Queuety::run_auto_scaling_worker_pool()` læser konstanterne WordPress `DB_HOST`, `DB_NAME`, `DB_USER` og `DB_PASSWORD` i stedet for den initialiserede forbindelse, så en selvstændig proces skal definere disse konstanter, før den starter en pool ([#5](https://github.com/inline0/queuety/issues/5)).

## Hvad forbliver i WordPress

Bro-laget, der er specifikt for WordPress, afhænger stadig af, at WordPress er indlæst.

Det omfatter:

- plugin-opstart og aktiveringsadfærd i `queuety.php`
- `Queuety::on_action()`, som kræver `add_action()`
- `Queuety::replace_wp_cron()` og `Queuety::restore_wp_cron()`, som afhænger af filtrene WordPress cron og `do_action()`
- den egentlige kommandoregistreringssti for `wp queuety ...`, som afhænger af, at WP-CLI indlæser WordPress

Disse dele er adaptere omkring kernens runtime-miljø. De er ikke selve runtime-miljøet.

## Initialisering

Den selvstændige sti er bevidst enkel. Åbn en DB-baseret `Connection`, initialiser facaden, og sørg for, at skemaet findes.

```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();
```

Derefter er den normale runtime-API tilgængelig:

```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();
```

## Tabelnavngivning

Selvstændig brug kræver ikke specifikt tabelnavne fra WordPress. Den kræver blot en stabil præfiksstrategi.

Hvis du peger Queuety mod en WordPress-database, skal du bruge det samme præfiks, som pluginet bruger dér. Hvis du bruger Queuety i en separat database, kan forbindelsespræfikset være det, din værtsapplikation forventer. Den tabeldel, der er specifik for Queuety, styres stadig af `QUEUETY_TABLE_PREFIX` og tilsidesættelserne for de enkelte tabeller.

Indlejrede runtime-miljøer, der deler én database, kan angive denne Queuety-specifikke del for hver forbindelse:

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

Det lader databasepræfikset fra WordPress være urørt og oversætter tabelnavne som `queuety_jobs` til `wp_themequeue_jobs`.

## Mental model

Den enkleste måde at forstå opdelingen på er:

- Queuety-kerne = kø, workers, workflows, tilstandsmaskiner, signaler, artefakter og runtime-metadata
- WordPress-adapter = plugin-opstart, hook-broer, WP-Cron-erstatning og WP-CLI-registrering

Det bevarer én orkestreringsmotor, mens hændelses- og anmodningsintegration, der er specifik for WordPress, forbliver dér, hvor den hører til.