RTerm v3.2.19

History search live-fixed (3 stacked bugs found by a wiring check)

A "check it's wired, not a placeholder" pass against the running daemon found the v3.2.18 history search returning sessions by title but zero message matches. Three stacked bugs, all fixed and live-verified:

1. The bridge fed the search metadata, not messages

agentService.getAllChatHistory() returns session summaries (messagesCount, lastMessagePreview) with no messages array — and its session ids can diverge from the durable store. The bridge now searches historyStore.listChatSessions() directly (full records with messages), falling back to metadata only if the store is unavailable.

2. Stored messages are double-wrapped

The store persists {id, type, data: {type, data: {content}}}; extractMessageText read content one level too early and always got undefined. It now unwraps nested data layers (bounded; only when the inner object actually has content or another data), handling both shapes. normalizeMessages() added so Map-shaped and object-shaped message collections are searched, not just arrays.

3. The history store resolved its data dir from process.cwd()

Under launchd the daemon runs with cwd=/, so the store opened /.gybackend-data — an empty DB silently diverged from the real ~/.gybackend-data. Resolution order is now GYSHELL_STORE_DIR → GYBACKEND_DATA_DIR → ~/.gybackend-data.

Live verification

GET /api/v1/history/search?q=netexec  → 1 session, 3 message matches, real snippets
GET /api/v1/history/search?q=synapse  → 2 sessions, 581 matches

Verification

• 77/77 v3218Comprehensive tests still green
• typecheck clean
• Live end-to-end against the running daemon

npm

neuralos@3.2.19 · rterm-backend@3.2.19 · rterm-cli@3.2.19