opentui(phase3): launcher integration — HERMES_TUI_ENGINE dual-engine
hermes --tui launches the native OpenTUI engine (Bun) when HERMES_TUI_ENGINE=opentui (env) or display.tui_engine=opentui (config); Ink stays the default and the shipping path is untouched. - _resolve_tui_engine() (env > config > ink); refuses opentui on Windows/Termux (no Bun) -> falls back to ink with a notice. - _make_opentui_argv() -> [bun, src/entry.real.tsx] (no build step). - _bun_bin() with HERMES_BUN override. - Branch at top of _make_tui_argv BEFORE _ensure_tui_node (Bun-only host must not bootstrap Node). - Gate _launch_tui NODE_OPTIONS/--max-old-space-size on engine==ink (Bun is JSC; the V8 flag errors/ignores). Verified end-to-end via tmux: real hermes --tui -> Bun -> OpenTUI -> real Python gateway streamed a real reply. No-flag default still ink.
This commit is contained in:
@@ -401,43 +401,6 @@ The agent can create, update, and delete its own skills via the `skill_manage` t
|
||||
The `patch` action is preferred for updates — it's more token-efficient than `edit` because only the changed text appears in the tool call.
|
||||
:::
|
||||
|
||||
### Gating agent skill writes (`skills.write_approval`)
|
||||
|
||||
By default the agent writes skills freely — including from the [background
|
||||
self-improvement review](/user-guide/features/memory#controlling-memory-writes-write_approval)
|
||||
that runs after a turn. If you'd rather approve every skill write first
|
||||
(small models that misjudge what they learned, secure environments, or just
|
||||
wanting eyes on the self-improvement loop), turn on the write-approval gate:
|
||||
|
||||
```yaml
|
||||
skills:
|
||||
write_approval: false # false = write freely (default) | true = require approval
|
||||
```
|
||||
|
||||
When `write_approval: true`, every `skill_manage` write (create / edit /
|
||||
patch / delete / write_file / remove_file) is **staged** instead of committed —
|
||||
a SKILL.md is too large to review inline, so staging applies regardless of
|
||||
whether the write came from a foreground turn or the background review.
|
||||
Staged writes survive restarts under `~/.hermes/pending/skills/` and are
|
||||
reviewed with the same familiar approve/deny flow as dangerous commands:
|
||||
|
||||
```
|
||||
/skills pending # list staged skill writes + a one-line gist each
|
||||
/skills diff <id> # full unified diff (best viewed in CLI or dashboard)
|
||||
/skills approve <id> # apply it (or 'all')
|
||||
/skills reject <id> # drop it (or 'all')
|
||||
/skills approval on # turn the gate on (or 'off') and persist it
|
||||
```
|
||||
|
||||
The review surface works in the interactive CLI and on messaging platforms
|
||||
(diff output is truncated for chat bubbles — read the full diff on the CLI or
|
||||
in the pending JSON file). Memory writes have the same gate under
|
||||
`memory.write_approval` — see [Controlling memory writes](/user-guide/features/memory#controlling-memory-writes-write_approval).
|
||||
|
||||
> The separate `skills.guard_agent_created` setting is a content scanner
|
||||
> (dangerous-pattern heuristics), not an approval gate — the two are
|
||||
> independent. See [Guard on agent-created skill writes](/user-guide/configuration#guard-on-agent-created-skill-writes).
|
||||
|
||||
## Skills Hub
|
||||
|
||||
Browse, search, install, and manage skills from online registries, `skills.sh`, direct well-known skill endpoints, and official optional skills.
|
||||
|
||||
Reference in New Issue
Block a user