# Uso independente

Queuety é distribuído como um plugin WordPress, mas a maior parte do runtime não
precisa de uma solicitação WordPress ativa.

A fila, o mecanismo de workflow, as máquinas de estado, os sinais, os artefatos, o processamento em lote,
o agendamento, o registro em log, as métricas e o gerenciamento de recursos funcionam nas mesmas
tabelas de MySQL. Se outro processo PHP puder abrir o mesmo banco de dados, poderá usar esse
núcleo diretamente.

Esse é o limite de uso independente em Queuety. O mecanismo de orquestração com banco de dados pode ser usado fora do WordPress. As pontes WordPress ainda pertencem ao
WordPress.

## O que funciona fora do WordPress

Com uma conexão `Connection` direta, um processo independente pode inicializar Queuety e usar
os mesmos métodos de fachada que o plugin usa para o runtime central:

- Despachar jobs
- Executar workers e pools de workers
- Criar e despachar workflows
- Enviar sinais, aprovações e entradas de workflow
- Criar e despachar máquinas de estado
- Inspecionar o status de workflows e máquinas
- Armazenar e ler artefatos
- Executar processamento em lote, encadeamento e agendamentos recorrentes
- Consultar logs, métricas, filas e status do runtime

Isso significa que um produto externo pode acessar o mesmo estado de orquestração sem
inicializar WordPress primeiro, desde que use o mesmo banco de dados e os mesmos nomes de tabela.

Os pools de workers são a única exceção no momento: `Queuety::run_worker_pool()` e
`Queuety::run_auto_scaling_worker_pool()` leem as constantes WordPress `DB_HOST`,
`DB_NAME`, `DB_USER` e `DB_PASSWORD`, em vez da conexão inicializada; portanto, um processo independente precisa definir essas constantes antes de iniciar um pool ([#5](https://github.com/inline0/queuety/issues/5)).

## O que permanece dentro do WordPress

A camada de integração específica do WordPress ainda depende de WordPress estar carregado.

Isso inclui:

- A inicialização do plugin e o comportamento de ativação no `queuety.php`
- `Queuety::on_action()`, que requer `add_action()`
- `Queuety::replace_wp_cron()` e `Queuety::restore_wp_cron()`, que dependem dos filtros WordPress cron e de `do_action()`
- O caminho real de registro de comandos `wp queuety ...`, que depende de WP-CLI carregar WordPress

Essas partes são adaptadores em torno do runtime central. Elas não são o próprio runtime.

## Inicialização

O caminho independente é intencionalmente simples. Abra um `Connection` com banco de dados,
 inicialize a fachada e garanta que o 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();
```

Depois disso, a API normal do runtime estará disponível:

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

## Nomenclatura das tabelas

O uso independente não exige especificamente os nomes de tabela de WordPress. Basta usar uma estratégia de prefixo estável.

Se você apontar Queuety para um banco de dados WordPress, use o mesmo prefixo que o plugin utiliza nele. Se usar Queuety em um banco de dados separado, o prefixo da conexão pode ser o que o aplicativo host esperar. A parte específica das tabelas de Queuety continua sendo controlada por `QUEUETY_TABLE_PREFIX` e pelas substituições por tabela.

Runtimes incorporados que compartilham um banco de dados podem definir essa parte específica de Queuety por conexão:

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

Isso mantém intacto o prefixo do banco de dados de WordPress e resolve tabelas como `queuety_jobs` para `wp_themequeue_jobs`.

## Modelo mental

Uma forma clara de entender essa divisão é:

- Núcleo de Queuety = fila, workers, workflows, máquinas de estado, sinais, artefatos e metadados do runtime
- Adaptador de WordPress = inicialização do plugin, pontes de hooks, substituição de WP-Cron e registro de WP-CLI

Isso mantém um único mecanismo de orquestração, deixando a integração de eventos e solicitações específica do WordPress onde ela deve ficar.