feat(hermes): enable svos_miranda live; retire irv parakeet and voice-studio

Four operator rulings executed.

svos_miranda is live in Hermes. Gateway restarted 02:10 (PID 3107822 -> 3901622,
confirmed by observing the change). /v1/toolsets now reports 29 rows including
svos_miranda, and an api_server session resolves to exactly the 8 plugin tools
with the write-klass five absent.

agent.disabled_toolsets stays off permanently: 'i dont want the tools disabled
everywhere'. That key is a global end-of-pipeline subtraction rather than an
api_server-scoped one - measured, a default session goes 46 tools to 20 - and it
is unnecessary anyway, since platform_toolsets.api_server alone produces the exact
8-tool surface. The operator's own session was verified intact at 46 tools after
the restart, which was the point of the ruling.

The consequence is now SVOS's to absorb: it must stop verifying against the global
roster before it restarts, because that roster is 29 by design and will not shrink.
Two workable options went to svos-dev - verify the api_server surface instead, or
relax the check to 'svos_miranda present and write-klass absent'. The second also
survives any unrelated plugin landing on this host, which matters because 'stt'
already appears in that endpoint's rows while resolving it logs 'Unknown toolset'.

irv parakeet retired: it lost tts-dev's bench to the FV seat at both clip lengths
and to whisper-large-v3 at 6.24s. Checked for consumers first - no gateway alias
pointed at it, and every other reference on that host was a comment in a
port-allocation register. Retirement banner on its README names the replacement.

voice-studio stopped: it existed for the dots mint loop and Breeze obsoleted dots
on 2026-09-06, so it was retired rather than repaired.
This commit is contained in:
vh
2026-09-15 02:12:19 -07:00
parent 1f98a1be32
commit 379fc27e7d
3 changed files with 27 additions and 6 deletions
@@ -105,8 +105,12 @@ that is where the `ext-tts` family lives, and it needs no gateway restart.
## Loose ends
- The **irv-ml1 parakeet is still running** (healthz 200 on `100.64.0.6:8765`).
Two Parakeets now. Retiring the old one is the operator's call — not touched.
- ✅ **irv-ml1 parakeet RETIRED 2026-09-15** (operator ruling, on tts-dev's bench
evidence). `docker compose down`; retirement banner prepended to its on-host
README naming the replacement. Checked for consumers first: **no gateway alias
pointed at it**, and every other `8765`/`parakeet` reference on that host was a
comment in a port-allocation register, not a dependency. Model files left on
disk at `/worktank/parakeet/models/` (regenerable). One Parakeet now.
- `/opt/docker/compose/parakeet` and `/tank/parakeet` normalised to `root:docker
2775`; the rest of fv-ml1's deploy tree is still `lkraven:lkraven` (it was not
part of the 5-host normalisation).
@@ -59,7 +59,21 @@ expected refusal — which looked like the plugin's collision reading was wrong.
was not: doctor's sandbox holds no built-ins, so nothing was claimed and **my
positive case was not positive.** Reported as untested rather than as a finding.
## ENABLED in config 2026-09-15 (operator-directed) — but NOT activated
## ✅ LIVE 2026-09-15 02:10 — gateway restarted, plugin registered
`GET /v1/toolsets` = **29 rows including `svos_miranda`**. An api_server session
resolves to **exactly 8** tools, write-klass absent. Operator's default session
verified **intact at 46** tools after the restart (memory / read_file / write_file /
terminal / web_search / browser_exec all present) — the whole point of the ruling.
⚠ **`agent.disabled_toolsets` stays OFF permanently** — operator: *"i dont want the
tools disabled everywhere."* So **SVOS must stop verifying against the global
`/v1/toolsets`** before it restarts: it will see 29 and refuse. Options put to
svos-dev: (1) verify the api_server surface instead — recommended; (3) relax to
"svos_miranda present AND write-klass five absent", which also survives any unrelated
plugin landing on this host. Option 2 (accept the fleet-wide cost) is ruled out.
## ENABLED in config 2026-09-15 (operator-directed)
Installed to `~/.hermes/plugins/svos_miranda`; `plugins.enabled`, the settings block
(dispatch key pulled from the vault, verified byte-equal), and
@@ -67,9 +81,8 @@ Installed to `~/.hermes/plugins/svos_miranda`; `plugins.enabled`, the settings b
`config.yaml.bak-20260915-svos-miranda-enable`; diffed against it, only the intended
non-comment lines changed. `hermes plugins list` → `svos_miranda enabled 0.1.0 user`.
**The Hermes gateway was NOT restarted**, so the plugin is not live: the running
process loaded its plugin set at 2026-09-14 12:35 and `/v1/toolsets` still reports 28
without `svos_miranda`.
Gateway restarted 02:10:17 PDT — PID 3107822 → 3901622, confirmed by **observing the
change** rather than assuming it.
## ⚠⚠ `agent.disabled_toolsets` is GLOBAL — it would have cost 26 tools fleet-wide
+4
View File
@@ -177,6 +177,10 @@ hardened for ha-dev (`d1769ed` ff); `kb` KB-search tool (`68fa80f`).
- `[2026-09-15]` **Parakeet STT live on fv-ml1 GPU 0, behind LiteLLM `ext-stt` / `whisper-1`.** ⚠ **Placed on GPU 3 first, which was wrong — operator caught it.** A ~800 MiB seat should ride the card with the most uncommitted headroom (GPU 0, util 0.88, ~13 GB spare), not put the first fingerprint on the one pristine 96 GB card: vLLM sizes KV cache against TOTAL VRAM, so any tenant on an empty card eats a future full-size seat's profiling margin (flash-next needs 93 of 96 GiB). **GPU 3 is now a deliberate reserve at 2 MiB.** Retargeted the existing `stacks/parakeet/` (sherpa-onnx + our own FastAPI wrapper) from irv-ml1; v3 int8, 25 languages. ⚠ **ORT's CUDA EP compiles kernels lazily and the first decode on sm_120 took 45.7 s** — every later call ~0.5 s; a startup warmup in `app.py` now absorbs it, so the first real request is 0.65 s instead of a 45 s hang that no client would wait through. GPU use was **verified by a process on GPU 3 (922 MiB), not by the `provider=cuda` log line**, because ORT falls back to CPU silently and still returns correct text. Silence → `""` (null control), known sentence → near-exact (positive control). → `persistent-memory.d/2026-09-15-parakeet-stt-fv-ml1.md`
- `[2026-09-15]` ⭐ **`svos_miranda` ENABLED and LIVE in Hermes — but `agent.disabled_toolsets` is permanently OFF by operator ruling ("i dont want the tools disabled everywhere").** That key is a **global** end-of-pipeline subtraction, not api_server-scoped: measured 46 tools → 20 on a default session. It is also **unnecessary** — `platform_toolsets.api_server: [svos_miranda]` alone resolves an api_server session to exactly the 8 tools, write-klass absent. Gateway restarted 02:10 (PID 3107822→3901622, observed); `/v1/toolsets` now 29 rows incl. `svos_miranda`; operator's own surface verified intact at 46. ⚠ **SVOS must stop verifying against the GLOBAL roster before it restarts** — it will see 29 and refuse, by design now. → `persistent-memory.d/2026-09-15-svos-miranda-plugin-validation.md`
- `[2026-09-15]` **irv-ml1 parakeet RETIRED; voice-studio STOPPED.** Both operator rulings. Parakeet lost tts-dev's bench to the FV seat at both clip lengths and to whisper-large-v3 at 6.24 s; no gateway alias depended on it and every other host reference was a port-register comment. voice-studio existed for the dots mint loop, which Breeze obsoleted 2026-09-06 — retired rather than repaired.
- `[2026-09-15]` **`svos_miranda` Hermes plugin validated; found its load blocker.** Absolute intra-package imports (`from hermes_plugin.x`) could not resolve at the documented install name — fixed by svos-dev at `c964e64`. ⚠ **`hermes plugins validate` and `doctor` can NEVER pass this plugin**, by construction: validate's probe stub is config-blind AND returns `None` from `register_tool` (which the plugin's guard reads as a collision), and doctor runs under a temp `HERMES_HOME` with no config. ⚠ `doctor` exits **0** on ERROR (use `--ci`); `compat` reads a **nonexistent path as a pass**. Roster verified 8/7 by a probe supplying real settings. → `persistent-memory.d/2026-09-15-svos-miranda-plugin-validation.md`
- `[2026-09-15]` ⚠ **ana-docker resolves NO `.internal` names** — its `/etc/resolv.conf` is `1.1.1.1`/`1.0.0.1`, not the fleet AdGuard. LiteLLM only reaches `irv-ml1.nh3.internal` because of a hand-pinned `extra_hosts` in its compose. New gateway aliases therefore use **raw IPs**; adding a hosts entry would mean recreating the container and bouncing the gateway for every consumer. Fleet-wide DNS fix is unowned.