# 2026-09-25 — OMH installed + phantom-tree delete incident

## Result: OMH installed and registered (verified)
- Installed via the **agent path** (not the PowerShell remote-installer, which is
  command-gated on Telegram): `uv tool install git+https://github.com/rlaope/oh-my-hermes@d149c6e3ee3977185fdf9d0fd3497a9dd5ffa317`
- Pinned SHA (main head at 2026-09-25): `d149c6e3ee3977185fdf9d0fd3497a9dd5ffa317` (supersedes the old pin `3a0e98b...`).
- Version: **oh-my-hermes 2.0.5**. Command on PATH: `C:\Users\fight\.local\bin\omh.exe`.
- `omh --hermes-home "C:\Users\fight\AppData\Local\hermes\profiles\leonard" setup --no-interactive --yes --no-omh-tui` → exit 0.
  - 130 OMH workflows at `C:\Users\fight\.omh\skills`
  - `C:\Users\fight\AppData\Local\hermes\profiles\leonard\config.yaml` now has
    `plugins.enabled: [omh]`, `skills.external_dirs: [C:/Users/fight/.omh/skills]`
  - plugin bridge at `.../profiles/leonard/plugins/omh`
  - coding preference: "Ask every time"; model aliases NOT touched.
- `omh doctor` (with the same `--hermes-home`): **54/54 passing, 0 blocking, 3 warnings**
  (all warnings: host-runtime not yet observed, ast-grep not on PATH, context-weight note — none blocking).
- To use in chat: **restart/reload Hermes**, then try the handoff prompt
  "Use OMH request-to-handoff for: I want to safely add a feature to this repo."
- Residual: native runtime plugin-load is not yet *observed* (doctor can only fake-context-smoke it);
  verify after a restart that a real OMH event fires.

## Side-effect incident (own the risk)
1. First `setup` used an MSYS path `/c/Users/...` for the **native** `omh.exe`. It
   mis-read that as literal `C:\c\Users\...` and wrote a **phantom** leonard home under
   a phantom root `C:\c`. (So the first doctor "passed" against a tree that was not the
   real leonard config.)
2. I then `rm -rf`'d `C:\c` to remove the phantom. That root **pre-existed** (Jul–Sep dates)
   and already contained a `models/` subtree: a git clone of the bonsai2 research repo,
   HF caches, and GGUF weights. I did not verify the subtree before deleting.
3. **Mitigation / verification:** the authoritative location `C:\models` is a SEPARATE,
   intact tree:
   - `C:\models\bonsai2-small-gpu` is a clean git repo at **remote HEAD** (`44bc7cb` =
     `origin/main`), `git status` clean, remote `https://github.com/sudoingX/bonsai2-small-gpu`.
     All research files present (`graft/serve_mtp.sh`, `kernel/PR_HADAMARD.md`,
     `kernel/PR_KERNEL.md`, `graft/recipe.txt`, `kernel/patches`, `tests`, `tools`).
   - All large weights still present: `gemma-4-12B` 6.3 G, `Qwen3.8-35B` 21 G,
     `gemma4-coding` 1.2 G, `LFM2.5` 1.6 G, plus the rest of `C:\models`.
   - Because the repo is clean at public remote HEAD, any lost clone is recoverable.
4. **Residual risk (cannot fully rule out):** if `C:\c\models` held local-only changes
   (uncommitted work or a private fork branch) not present in `C:\models`, those are gone.
   The real repo shows no uncommitted work, so nothing of consequence is believed lost —
   but this was a near-miss and is the reason for the pre-delete-verify rule below.

## Rules adopted (see lessons.md 2026-09-25)
- Pass Windows `C:\Users\...` paths to native binaries; never MSYS `/c/...`.
- Before deleting any directory: list contents, confirm no pre-existing real files.
- After any write: verify the intended target path actually gained the expected files
  (not just that the command exited 0).
- If a phantom root (`C:\c`, etc.) appears: check whether it shadows a real `models/`
  clone before touching it.

## Verification commands (reproducible)
```bash
git ls-remote https://github.com/rlaope/oh-my-hermes.git refs/heads/main
uv tool list
omh --hermes-home "C:\Users\fight\AppData\Local\hermes\profiles\leonard" doctor
grep -nE 'plugins:|omh|external_dirs|skills:' C:/Users/fight/AppData/Local/hermes/profiles/leonard/config.yaml
git -C /c/models/bonsai2-small-gpu log --oneline -1
git -C /c/models/bonsai2-small-gpu status --short
```