# CLI

```bash
vendor/bin/storh stats <root> [collection] [doc|log|queue]
vendor/bin/storh verify <root> [collection] [doc|log|queue]
vendor/bin/storh compact <root> [collection] [doc|log]
vendor/bin/storh reindex <root> [collection]
```

`<root>` ist das Speicherstammverzeichnis, mit dem die Engines geöffnet wurden. Dies ist der Pfad, den `StorageRoot::resolve()` zurückgibt: das Basisverzeichnis plus der Namespace. Ein Store, der unter `StorageRoot::resolve(__DIR__ . '/var/storh', 'app')` geöffnet wurde, befindet sich unter `var/storh/app`:

```bash
vendor/bin/storh stats var/storh/app pages doc
vendor/bin/storh verify var/storh/app events log
vendor/bin/storh compact var/storh/app events log
vendor/bin/storh reindex var/storh/app pages
```

Wenn du nur das Basisverzeichnis übergibst (`var/storh`), verweisen die Befehle auf eine Sammlung, die noch nicht existiert. Daher melden sie eine leere Sammlung, statt fehlzuschlagen.

`vendor/bin/storh` benötigt storh 0.5.2 oder neuer, wenn storh als Abhängigkeit installiert ist. Frühere Versionen suchten den Composer-Autoloader nur im eigenen Verzeichnis `vendor/` des Pakets und schlugen mit einem `require`-Fehler fehl.

CLI gibt stabile JSON aus, sodass es in cron-Jobs und Deployment-Integritätsprüfungen verwendet werden kann. Standardmäßig wird die Sammlung auf `default` gesetzt. Die Engine ist für `stats`, `verify` und `reindex` standardmäßig `doc` und für `compact` standardmäßig `log`.

## Wartungsmethoden hinter den Befehlen

Alle Engines stellen die Wartungsmethoden bereit, die CLI aufruft:

```php
$store->stats();
$store->health();
$store->verify();
$store->repair();
```

DocStore bietet zusätzlich:

```php
$docs->reindex();
$docs->compact(); // no-op report for API symmetry
```

SegmentedLog bietet zusätzlich:

```php
$log->compact();
$log->recover();
$log->state_index();
```

Bei DocStore prüft `verify()`, ob Datensätze sauber geparst werden und ob Gleichheits-, Bereichs- und zusammengesetzte Indizes mit einem vollständigen Scan aller Datensätze übereinstimmen. `repair()` verschiebt beschädigte Datensatzdateien unter `.storh/corrupt/` in Quarantäne und erstellt die Indizes anhand gültiger Datensätze neu.

Bei SegmentedLog decodiert `verify()` die Segmentzeilen und vergleicht den aktuellen abgeleiteten Zustandsindex mit einer frischen Wiedergabe der Segmente. `repair()` erstellt den abgeleiteten Zustand neu und schneidet unvollständige Zeilen am Dateiende ab.

Bei Queue decodiert `verify()` alle dauerhaften Ereignisse und vergleicht den Status ausstehender, in Bearbeitung befindlicher und erledigter Jobs sowie Payloads und Reihenfolge der Claims mit einer frischen Wiedergabe von `queue.log`. `repair()` erstellt den Queue-Status anhand des Logs neu und reiht Jobs, deren Bearbeitungszeit abgelaufen ist, erneut ein.