# Uso autonomo

Queuety è distribuito come plugin WordPress, ma la maggior parte dell'ambiente di esecuzione non ha effettivamente bisogno di una richiesta WordPress attiva.

La coda, il motore dei workflow, le macchine a stati, i segnali, gli artefatti, l'elaborazione in batch, la pianificazione, la registrazione dei log, le metriche e la gestione delle risorse usano tutte le stesse tabelle MySQL. Se un altro processo PHP può aprire lo stesso database, può usare direttamente quel nucleo.

Questo è il confine dell'uso autonomo in Queuety. Il motore di orchestrazione basato su database è utilizzabile al di fuori di WordPress. I bridge WordPress restano invece parte di WordPress.

## Cosa funziona al di fuori di WordPress

Con un `Connection` diretto, un processo autonomo può inizializzare Queuety e usare gli stessi metodi facade impiegati dal plugin per il runtime principale:

- inviare processi
- eseguire worker e pool di worker
- creare e inviare workflow
- inviare segnali, approvazioni e input ai workflow
- creare e inviare macchine a stati
- esaminare lo stato di workflow e macchine
- archiviare e leggere artefatti
- gestire elaborazioni in batch, concatenamenti e pianificazioni ricorrenti
- interrogare log, metriche, code e stato di esecuzione

Questo significa che un prodotto esterno può accedere allo stesso stato di orchestrazione senza avviare prima WordPress, purché usi lo stesso database e gli stessi nomi delle tabelle.

Al momento, i pool di worker sono l'unica eccezione: `Queuety::run_worker_pool()` e `Queuety::run_auto_scaling_worker_pool()` leggono le costanti WordPress `DB_HOST`, `DB_NAME`, `DB_USER` e `DB_PASSWORD` invece della connessione inizializzata, quindi un processo autonomo deve definire tali costanti prima di avviare un pool ([#5](https://github.com/inline0/queuety/issues/5)).

## Cosa resta all'interno di WordPress

Il livello bridge specifico di WordPress dipende ancora dal caricamento di WordPress.

Include:

- bootstrap del plugin e comportamento di attivazione in `queuety.php`
- `Queuety::on_action()`, che richiede `add_action()`
- `Queuety::replace_wp_cron()` e `Queuety::restore_wp_cron()`, che dipendono dai filtri e dagli hook di WordPress cron `do_action()`
- il percorso effettivo di registrazione dei comandi `wp queuety ...`, che dipende dal caricamento di WP-CLI WordPress

Questi componenti sono adattatori attorno al runtime principale. Non costituiscono il runtime stesso.

## Inizializzazione

Il percorso autonomo è volutamente essenziale. Aprite un `Connection` basato su DB,
inizializzate la facade e verificate che lo schema esista.

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

Dopodiché, il normale API runtime è disponibile:

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

## Denominazione delle tabelle

L'uso autonomo non richiede specificamente nomi di tabelle WordPress. Serve solo una
strategia di prefissi stabile.

Se configurate Queuety su un database WordPress, usate lo stesso prefisso utilizzato lì dal
plugin. Se usate Queuety in un database separato, il prefisso della connessione può
essere quello previsto dall'applicazione host. La parte dei nomi delle tabelle specifica di Queuety è comunque controllata da `QUEUETY_TABLE_PREFIX` e dalle
sovrascritture per singola tabella.

I runtime incorporati che condividono un database possono impostare quella parte specifica di Queuety per connessione:

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

In questo modo il prefisso del database WordPress resta invariato e le tabelle, come
`queuety_jobs`, vengono risolte in `wp_themequeue_jobs`.

## Modello mentale

Per comprendere chiaramente la suddivisione:

- Core di Queuety = coda, worker, workflow, macchine a stati, segnali, artefatti e metadati runtime
- Adapter di WordPress = avvio del plugin, bridge degli hook, sostituzione di WP-Cron e registrazione di WP-CLI

Così si mantiene un unico motore di orchestrazione, lasciando l'integrazione di eventi e richieste specifica di WordPress al suo posto.