# 単独での使用

QueuetyはWordPressプラグインとしてパッケージ化されていますが、実行時機能の大半は、実行中のWordPressリクエストを実際には必要としません。

キュー、ワークフローエンジン、状態マシン、シグナル、アーティファクト、バッチ処理、スケジューリング、ログ、メトリクス、リソース管理はすべて、同じMySQLテーブルを使って動作します。別のPHPプロセスから同じデータベースを開けるなら、そのコアを直接利用できます。

これがQueuetyにおける単独利用の境界です。データベースベースのオーケストレーションエンジンはWordPressの外でも使えます。WordPressブリッジは引き続きWordPressに属します。

## WordPressの外で使える機能

直接`Connection`を使うと、独立したプロセスでQueuetyを初期化し、プラグインがコアランタイムで使用するものと同じファサードメソッドを利用できます。

- ジョブをディスパッチする
- ワーカーとワーカープールを実行する
- ワークフローを構築してディスパッチする
- シグナル、承認、ワークフロー入力を送信する
- 状態マシンを構築してディスパッチする
- ワークフローとマシンの状態を確認する
- アーティファクトを保存して読み取る
- バッチ処理、チェーン処理、定期スケジュールを実行する
- ログ、メトリクス、キュー、実行時状態を照会する

つまり、外部の製品から、先にWordPressを起動せずに同じオーケストレーション状態へアクセスできます。ただし、同じデータベースとテーブル名を使用する必要があります。

ワーカープールは現時点で唯一の例外です。`Queuety::run_worker_pool()`と`Queuety::run_auto_scaling_worker_pool()`は初期化済みの接続ではなく、WordPress `DB_HOST`、`DB_NAME`、`DB_USER`、`DB_PASSWORD`定数を読み取ります。そのため、単独プロセスではプールの起動前にこれらの定数を定義する必要があります（[#5](https://github.com/inline0/queuety/issues/5)）。

## WordPress内にとどまる機能

WordPress固有のブリッジ層は、引き続きWordPressが読み込まれていることに依存します。

対象には次が含まれます。

- `queuety.php`でのプラグイン初期化と有効化の動作
- `Queuety::on_action()`。`add_action()`が必要です
- `Queuety::replace_wp_cron()`と`Queuety::restore_wp_cron()`。WordPress cronフィルターと`do_action()`に依存します
- 実際の`wp queuety ...`コマンド登録経路。WP-CLIがWordPressを読み込む必要があります

これらはコア実行環境を囲むアダプターであり、実行環境そのものではありません。

## 初期化

単独利用の手順は意図的に簡潔です。データベース対応の`Connection`を開き、ファサードを初期化して、スキーマが存在することを確認します。

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

その後、通常の実行時APIを利用できます。

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

## テーブル名

単独利用では、WordPress固有のテーブル名は必要ありません。安定したプレフィックス戦略があれば十分です。

QueuetyをWordPressデータベースに接続する場合は、そこでプラグインが使うものと同じプレフィックスを使います。別のデータベースでQueuetyを使う場合、接続プレフィックスはホストアプリケーションに合わせて設定できます。Queuety固有のテーブル部分は、引き続き`QUEUETY_TABLE_PREFIX`とテーブルごとの上書き設定によって制御されます。

1つのデータベースを共有する組み込み実行環境では、接続ごとにQueuety固有の部分を設定できます。

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

これにより、WordPressのデータベースプレフィックスはそのままに、`queuety_jobs`などのテーブル名を`wp_themequeue_jobs`として解決できます。

## 考え方

この分割は次のように考えると分かりやすくなります。

- Queuetyコア = キュー、ワーカー、ワークフロー、状態マシン、シグナル、アーティファクト、実行時メタデータ
- WordPressアダプター = プラグイン初期化、フックブリッジ、WP-Cronの置き換え、WP-CLI登録

これにより、オーケストレーションエンジンを1つに保ちながら、WordPress固有のイベント連携とリクエスト連携を適切な場所に置けます。