# Utilisation autonome

Queuety est fourni sous la forme d’un plugin WordPress, mais la plupart de son environnement d’exécution n’a pas réellement besoin d’une requête WordPress active.

La file d’attente, le moteur de workflow, les machines à états, les signaux, les artefacts, le traitement par lots,
la planification, la journalisation, les métriques et la gestion des ressources utilisent tous les mêmes
tables MySQL. Tout autre processus PHP pouvant ouvrir la même base de données peut utiliser directement ce
cœur.

C’est la limite entre les deux modes dans Queuety. Le moteur d’orchestration adossé à une base de données peut être utilisé en dehors de WordPress. Les ponts WordPress restent propres à WordPress.

## Ce qui fonctionne en dehors de WordPress

Avec un `Connection` direct, un processus autonome peut initialiser Queuety et utiliser les mêmes méthodes de façade que le plugin pour le cœur de l’environnement d’exécution :

- déclencher des jobs
- exécuter des workers et des pools de workers
- créer et déclencher des workflows
- envoyer des signaux, des approbations et des données d’entrée de workflow
- créer et déclencher des machines à états
- consulter l’état des workflows et des machines
- stocker et lire des artefacts
- exécuter le traitement par lots, l’enchaînement de tâches et les planifications récurrentes
- interroger les journaux, les métriques, les files d’attente et l’état de l’environnement d’exécution

Un produit externe peut donc accéder au même état d’orchestration sans démarrer WordPress au préalable, à condition d’utiliser la même base de données et les mêmes noms de tables.

Les pools de workers constituent actuellement la seule exception : `Queuety::run_worker_pool()` et
`Queuety::run_auto_scaling_worker_pool()` lisent les constantes WordPress `DB_HOST`,
`DB_NAME`, `DB_USER` et `DB_PASSWORD` au lieu de la connexion initialisée. Un processus autonome doit donc définir ces constantes avant de démarrer un pool ([#5](https://github.com/inline0/queuety/issues/5)).

## Ce qui reste dans WordPress

La couche de pont propre à WordPress dépend toujours du chargement de WordPress.

Cela comprend :

- l’initialisation du plugin et son comportement à l’activation dans `queuety.php`
- `Queuety::on_action()`, qui nécessite `add_action()`
- `Queuety::replace_wp_cron()` et `Queuety::restore_wp_cron()`, qui dépendent des filtres WordPress cron et de `do_action()`
- le véritable chemin d’enregistrement des commandes `wp queuety ...`, qui dépend du chargement de WordPress par WP-CLI

Ces éléments sont des adaptateurs autour du cœur de l’environnement d’exécution. Ils ne constituent pas l’environnement d’exécution lui-même.

## Initialisation

Le chemin autonome est volontairement simple. Ouvrez un `Connection` adossé à une base de données, initialisez la façade et vérifiez que le schéma existe.

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

Le API normal de l’environnement d’exécution est ensuite disponible :

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

## Nommage des tables

L’utilisation autonome n’exige pas spécifiquement les noms de tables WordPress. Elle requiert uniquement une stratégie de préfixe stable.

Si vous connectez Queuety à une base de données WordPress, utilisez le même préfixe que le plugin. Si vous utilisez Queuety dans une base de données distincte, le préfixe de connexion peut correspondre aux attentes de votre application hôte. La partie des noms de tables propre à Queuety reste contrôlée par `QUEUETY_TABLE_PREFIX` et les remplacements propres à chaque table.

Les environnements d’exécution intégrés qui partagent une base de données peuvent définir cette partie propre à Queuety pour chaque connexion :

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

Le préfixe de base de données WordPress reste ainsi intact, et les tables telles que `queuety_jobs` sont résolues en `wp_themequeue_jobs`.

## Modèle mental

Pour comprendre simplement cette séparation :

- cœur de Queuety = file d’attente, workers, workflows, machines à états, signaux, artefacts et métadonnées de l’environnement d’exécution
- adaptateur WordPress = initialisation du plugin, ponts de hooks, remplacement de WP-Cron et enregistrement de WP-CLI

Cela permet de conserver un seul moteur d’orchestration tout en laissant l’intégration aux événements et aux requêtes propres à WordPress à sa place.