## What happened

After installing Hermes Desktop via `omarchy install ai hermes`, Omarchy's own readiness probe for Hermes (`omarchy-install-hermes-cli --check` → `desktop_hermes_ready()`) never passes, even though the install is fully functional (`hermes chat --help` works fine, the CLI wrapper is correctly pointed at `~/.hermes`).

The practical symptom: `omarchy-theme-set-hermes --activate` — including the one-shot migration `1788619462.sh` ("Hand Hermes Desktop the Omarchy theme as a skin") that's supposed to backfill this on update — permanently reports:

```
Hermes is not ready, so the Omarchy skin is published but not active.
Once Hermes runs, activate it with: hermes config set display.skin omarchy
```

Since that migration only runs once, this leaves the theme→Hermes skin sync silently broken forever on any machine where it hits this path, with no automatic recovery.

## Root cause

`desktop_hermes_ready()` in `omarchy-install-hermes-cli` requires this file to exist:

```
[[ -f $HOME/.hermes/hermes-agent/.hermes-bootstrap-complete ]] || return 1
```

That marker is normally written by Hermes Desktop's Electron bootstrap flow (`apps/desktop/electron/main.ts`, `writeBootstrapMarker()`), at the end of its **first-run bootstrap wizard**.

But `omarchy-install-ai-hermes` (`/usr/share/omarchy/bin/omarchy-install-ai-hermes`) provisions the runtime via:

```bash
bash /usr/share/hermes-desktop/install.sh --skip-setup --branch main --commit "$release_commit" --force-commit --dir "$runtime" --hermes-home "$HERMES_HOME"
```

This headless path reconstructs the same repo+venv layout the Electron bootstrap wizard would produce, but never goes through `bootstrap-runner.ts`, so `.hermes-bootstrap-complete` never gets written. Hermes Desktop itself handles this gracefully by design (`apps/desktop/electron/active-runtime-state.ts` — `classifyActiveRuntime()` explicitly treats a missing/stale marker as fine as long as the runtime is otherwise usable, logging `"...usable but the bootstrap marker is missing or stale; skipping first-run bootstrap."` and launching it directly). So this isn't a Hermes Desktop bug — it's that Omarchy's own readiness probe relies on a marker that Omarchy's own install path never produces.

A comment in `bootstrap-runner.ts` ("Prefer a real pin already written by install.ps1's bootstrap-marker stage") suggests the Windows installer (`install.ps1`) *does* write an equivalent marker as part of its scripted install — so this looks like a Linux/`install.sh --skip-setup` gap relative to `install.ps1`, or something `omarchy-install-ai-hermes` needs to write itself after calling `install.sh`.

## Expected

`omarchy install ai hermes` should leave the install in a state where `omarchy-install-hermes-cli --check` succeeds (and therefore `omarchy-theme-set-hermes --activate` / the one-shot migration succeeds) without a manual step.

## Steps to reproduce

1. `omarchy install ai hermes` on a machine that doesn't already have Hermes set up.
2. Let it finish and launch.
3. Run `omarchy-theme-set-hermes --activate` (or just switch themes and wait for the next Omarchy update to run migration `1788619462.sh`).
4. Observe: "Hermes is not ready, so the Omarchy skin is published but not active." — even though Hermes is fully installed and running.
5. Check: `~/.hermes/hermes-agent/.hermes-bootstrap-complete` does not exist.

## Workaround

Manually run `hermes config set display.skin omarchy` after each theme change, or write a marker file matching the schema in `writeBootstrapMarker()` (`{schemaVersion: 1, pinnedCommit: <current HEAD sha, >=7 hex chars>, pinnedBranch, completedAt, desktopVersion}`) at `~/.hermes/hermes-agent/.hermes-bootstrap-complete`.

## System details

- Omarchy version: 4.0.4-1
- `hermes-desktop` package: 2026.8.31-3 (Hermes Agent v0.21.3 / v2026.9.14)
- CPU: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
- GPU: Intel Corporation Skylake-U GT2 [HD Graphics 520]