# Uso independiente

Queuety se distribuye como un plugin de WordPress, pero la mayor parte del entorno de ejecución no necesita una solicitud activa de WordPress.

La cola, el motor de flujos de trabajo, las máquinas de estado, las señales, los artefactos, el procesamiento por lotes, la programación, el registro, las métricas y la gestión de recursos funcionan con las mismas tablas de MySQL. Si otro proceso de PHP puede abrir la misma base de datos, puede usar directamente ese núcleo.

Ese es el límite de uso independiente en Queuety. El motor de orquestación respaldado por la base de datos puede usarse fuera de WordPress. Los puentes de WordPress siguen perteneciendo a WordPress.

## Qué funciona fuera de WordPress

Con una `Connection` directa, un proceso independiente puede inicializar Queuety y usar los mismos métodos de fachada que el plugin usa para el entorno de ejecución principal:

- enviar trabajos
- ejecutar workers y grupos de workers
- crear y enviar flujos de trabajo
- enviar señales, aprobaciones y entradas de flujos de trabajo
- crear y enviar máquinas de estado
- inspeccionar el estado de los flujos de trabajo y las máquinas
- almacenar y leer artefactos
- ejecutar procesamiento por lotes, encadenamiento y programaciones recurrentes
- consultar registros, métricas, colas y el estado del entorno de ejecución

Esto permite que un producto externo acceda al mismo estado de orquestación sin iniciar WordPress primero, siempre que use la misma base de datos y los mismos nombres de tabla.

Hoy, los grupos de workers son la única excepción: `Queuety::run_worker_pool()` y `Queuety::run_auto_scaling_worker_pool()` leen las constantes WordPress `DB_HOST`, `DB_NAME`, `DB_USER` y `DB_PASSWORD` en lugar de la conexión inicializada, por lo que un proceso independiente debe definir esas constantes antes de iniciar un grupo ([#5](https://github.com/inline0/queuety/issues/5)).

## Qué sigue dentro de WordPress

La capa puente específica de WordPress sigue dependiendo de que WordPress esté cargado.

Esto incluye:

- el inicio del plugin y el comportamiento de activación en `queuety.php`
- `Queuety::on_action()`, que requiere `add_action()`
- `Queuety::replace_wp_cron()` y `Queuety::restore_wp_cron()`, que dependen de los filtros WordPress cron y de `do_action()`
- la ruta real de registro de comandos `wp queuety ...`, que depende de que WP-CLI cargue WordPress

Esas piezas son adaptadores alrededor del entorno de ejecución principal. No son el entorno de ejecución en sí.

## Inicialización

La ruta de uso independiente es deliberadamente sencilla. Abra una `Connection` respaldada por DB, inicialice la fachada y asegúrese de que el esquema exista.

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

Después, estará disponible la API habitual del entorno de ejecución:

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

## Nombres de tabla

El uso independiente no requiere nombres de tabla de WordPress específicamente. Solo necesita una estrategia estable para los prefijos.

Si conecta Queuety a una base de datos de WordPress, use el mismo prefijo que utiliza el plugin allí. Si usa Queuety en una base de datos independiente, el prefijo de conexión puede ser el que espere la aplicación host. La parte del nombre de tabla específica de Queuety sigue controlada por `QUEUETY_TABLE_PREFIX` y las anulaciones por tabla.

Los entornos de ejecución integrados que comparten una base de datos pueden establecer esa parte específica de Queuety por conexión:

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

Así se conserva intacto el prefijo de base de datos de WordPress y se resuelven tablas como `queuety_jobs` en `wp_themequeue_jobs`.

## Modelo mental

Una forma clara de entender la separación es:

- núcleo de Queuety = cola, workers, flujos de trabajo, máquinas de estado, señales, artefactos y metadatos del entorno de ejecución
- adaptador de WordPress = inicio del plugin, puentes de hooks, sustitución de WP-Cron y registro de WP-CLI

Así se mantiene un único motor de orquestación y se deja la integración de eventos y solicitudes específica de WordPress donde corresponde.