vh/esh-pfi-infrastructure
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

docs(memory): svos-dev fixed the roster check; disabled_toolsets deleted from config

Browse Source 
svos-dev landed c9d2a96 - build_miranda_roster now returns an empty disabled list
unconditionally and the startup line no longer names the key. The 28-name list is
removed from ~/.hermes/config.yaml rather than left commented, since a paste-ready
array behind a hash is what a future session uncomments; a short warning stands in
its place.

Their mechanism is better than mine and replaces it in the record.
_get_platform_tools resolves platform_toolsets first and applies global suppression
last, so subtracting 28 names from a one-element platform set is a no-op by
resolution order - not merely 'adds no safety on top'. That holds for any future
platform; the measurement only established the single case.

And the endpoint already carried the answer. _handle_toolsets computes each row's
enabled as membership in the per-platform set, so verified live: 29 rows with
svos_miranda the only one reporting enabled=True. A check reading that field rather
than counting rows was correct all along, against a config that never needed the key.
This commit is contained in:
vh
2026-09-15 02:14:09 -07:00
parent 379fc27e7d
commit 868b56642c
1 changed files with 17 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
persistent-memory.d/2026-09-15-svos-miranda-plugin-validation.md
+17
View File
@@ -66,6 +66,23 @@ 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.
✅ **RESOLVED — svos-dev fixed it at `c9d2a96`; the key is DELETED from config.**
Their reading is better than mine and is the one to keep: `_get_platform_tools`
resolves `platform_toolsets[<key>]` **FIRST** and applies the global suppression
**LAST**, so subtracting 28 names from a one-element platform set is a **no-op by
resolution order** — not merely "adds no safety". That generalises to any future
platform; my measurement only established the single case.
⭐ And the endpoint already carried the answer: `gateway/platforms/api_server.py::
_handle_toolsets` computes each row's `enabled` as `name in _get_platform_tools(config,
"api_server")`. Verified live — **29 rows, and `svos_miranda` is the ONLY row with
`enabled=True`.** A check reading `enabled` rather than counting rows was always
correct. SVOS's `build_miranda_roster` now returns an empty disabled list
unconditionally and its startup line no longer names the key.
⚠ The 28-name list was **removed, not commented** — a paste-ready array behind a `#`
is what a future session uncomments. A short warning comment stands in its place.
⚠ **`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