feat(dashboard): add configurable Chat UI sub-features — chat system monitor, agent profile picker, and per-profile gating

[emmanuel-a-otchere]

Summary

Adds three new configurable sub-features to the Hermes dashboard Chat tab:

Flag	Default	Description
dashboard.chat_ui	true	Master switch for the Chat tab (requires --tui server flag)
dashboard.chat_system_monitor	true	Shows live memory · disk · token · time metrics bar above the terminal
dashboard.chat_by_agent_profile	true	Shows Agent Profile selector card + profile switcher dialog in the Chat sidebar

Backend additions

• POST /api/profiles/{name}/activate — activates a named profile persistently (sticky across restarts)
• GET /api/agents/metrics — live telemetry: memory usage, disk usage, token totals+by-model, active profile name, server time

Frontend additions

• AgentMetricsBar.tsx — mini SVG arc gauges for memory/disk, token bar, live clock. Polls /api/agents/metrics every 30s. Stops polling entirely when visible={false}.
• ProfilePickerDialog.tsx — profile switcher with active indicator, soul badge, emoji icon, inline soul editor.

Files changed

M hermes_cli/config.py         — 3 new dashboard config keys
M hermes_cli/web_server.py     — 2 new API endpoints
M web/src/App.tsx              — reads all 3 flags, passes sub-feature props
M web/src/pages/ChatPage.tsx   — wires AgentMetricsBar + chatByAgentProfile
M web/src/components/ChatSidebar.tsx — profile card gated on chatByAgentProfile
M web/src/lib/api.ts           — activateProfile(), getAgentMetrics() + types
M web/src/lib/dashboard-flags.ts
A web/src/components/AgentMetricsBar.tsx
A web/src/components/ProfilePickerDialog.tsx

Testing

1. Start dashboard with hermes dashboard --tui
2. Verify Chat tab appears in nav
3. Toggle each sub-feature in Config → Display
4. Confirm Agent Profile card appears in Chat sidebar and profile switching works

---

Contributed by Emmanuel A Otchere · feat/chat-ui-feature-gating

[RobinAngele]

Live deployment report — working, with 3 issues + fixes

Deployed the profile switching parts of this PR on Debian 12, Hermes v0.14.0, --tui dashboard. The core (ProfilePickerDialog, activateProfile API, activate endpoint) works. Below is exactly what we deployed, what we changed, and why.

What we used as-is from this PR ✅

• web/src/components/ProfilePickerDialog.tsx — no changes needed
• web/src/lib/api.ts activateProfile() — correct
• POST /api/profiles/{name}/activate endpoint — correct

What we skipped (unrelated to profile switching)

• AgentMetricsBar.tsx + chat_system_monitor — not needed for switcher
• pnpm-lock.yaml / pnpm-workspace.yaml — npm build works fine without
• web/vite.config.ts changes — build succeeded without

Issue 1 — PTY ignores switched profile (fixed in #33056)

_resolve_chat_argv() spawns the PTY with the dashboard process's own HERMES_HOME from os.environ.copy(). After activateProfile() updates the sticky file and the page reloads, the new PTY still uses the startup profile. This also breaks the "default" profile case: set_active_profile("default") deletes the sticky file, so the PTY sees no file and falls back to the startup profile.

Fix: #33056 adds 14 lines to _resolve_chat_argv() to read ~/.hermes/active_profile and set HERMES_HOME accordingly before spawning the PTY. Also adds a public GET /api/active-profile endpoint.

Issue 2 — getAgentMetrics() fails silently

In ChatSidebar.tsx, the initial useEffect calls api.getAgentMetrics() which hits GET /api/agents/metrics. This endpoint may not be registered before the SPA catch-all, or the auth middleware blocks it. The .catch(() => {}) swallows the error silently → activeProfile stays "default" until the PTY connects.

Workaround: Replaced api.getAgentMetrics() with fetch("/api/active-profile") (the public endpoint from #33056).

Issue 3 — session.info race condition

When the PTY connects, session.info.profile_name overwrites activeProfile. If the PTY spawned before _resolve_chat_argv was fixed (issue 1), this sets the WRONG profile. Even when fix 1 is applied, there's a timing race with the API fetch on mount — whichever resolves last wins.

Quick fix we used: Removed the setActiveProfile(ev.payload.profile_name) override (3 lines). The /api/active-profile fetch on mount is authoritative.

Proper fix (not yet implemented — suggested for this PR): use a useRef flag so the API fetch takes priority once it completes, but session.info still works as a fallback if the API hasn't responded yet:

const profileFetched = useRef(false);
useEffect(() => {
  fetch("/api/active-profile")
    .then(r => r.json())
    .then(d => { setActiveProfile(d.name); profileFetched.current = true; });
}, []);
// In session.info handler:
if (ev.payload.profile_name && !profileFetched.current) {
  setActiveProfile(ev.payload.profile_name);
}

Modified in ChatSidebar.tsx

// handleProfileActivated: removed api.getAgentMetrics chain, replaced with:
setTimeout(() => location.reload(), 1000);  // API already called by ProfilePickerDialog

// Initial fetch: replaced api.getAgentMetrics() with:
fetch("/api/active-profile").then(r => r.json()).then(d => setActiveProfile(d.name));

// session.info handler: removed profile_name override (3 lines deleted)

Suggestion for this PR

1. The _resolve_chat_argv fix in fix(web_server): resolve dashboard PTY profile from sticky active_profile on reload #33056 is essential — without it, the PTY never switches profiles
2. Consider replacing getAgentMetrics() with the lightweight /api/active-profile endpoint (also in fix(web_server): resolve dashboard PTY profile from sticky active_profile on reload #33056)
3. The session.info approach is correct, but add a useRef guard (shown above) so the API fetch takes priority once it completes

[teknium1]

Thanks for the dashboard work. Current main has since adopted a different, machine-level profile-selection architecture, so this needs selective rework before its remaining monitor/gating work can be considered.

Problems

• web/src/components/ProfilePickerDialog.tsx:92 activates a profile, then its callback reaches web/src/components/ChatSidebar.tsx:339, which activates it a second time.
• hermes_cli/web_server.py:2986 and :2993 hardcode ~/.hermes and a profiles/active_profile path. Current main resolves sticky selection through hermes_cli.profiles (web_server.py:12922) and scopes Chat explicitly through ?profile= (web_server.py:14572-14645).
• Main commit 875aa8f162aa40f07b19b2ca229720da70193d41 already supplies a global ProfileSwitcher; Chat derives its PTY scope from it at web/src/pages/ChatPage.tsx:299-302 and forwards it at :911-915. A second sidebar picker would duplicate and conflict with that source of truth.

Suggested changes

• Salvage only the monitor/gating idea onto the shared profile-scope flow, with profile-safe metrics and one activation owner.
• Add resolver-level profile-scope coverage rather than mock-only switch-flow tests.

Automated hermes-sweeper review.

[teknium1]

This request is duplicated by the callback path: onProfileActivated(name) reaches ChatSidebar.handleProfileActivated, which calls api.activateProfile(name) again. Make either the dialog or the sidebar the sole mutation owner, then have the other layer only report success/reconnect.

[teknium1]

Do not hardcode ~/.hermes here. This bypasses profile-aware path resolution; the adjacent active-profile read also targets ~/.hermes/profiles/active_profile, while the current profile helper owns the sticky-file location. Use the profile helpers / get_hermes_home() and test with a temporary HERMES_HOME.