feat(core): index failed tool results for retrieval

[Cyb3rN8]

search() covers messages.text and nothing else, so a past failure is findable only when the assistant happened to quote the error — and it usually doesn't, because the model fixes an error rather than restating it. That makes "how did I fix this last time" miss precisely the cases it gets asked about most.

Measurement

Against a real index — 380k messages, 127k tool results, 2.5 GB of transcripts — I sampled 400 error identifiers (ENOENT, TypeError, error TS2339, …) taken from is_error=1 rows and asked whether messages_fts could locate the session they occurred in:

	share
found in the right session via messages_fts	33.7%
found only in other sessions (wrong hit)	29.0%
absent from messages.text entirely	37.3%

InputValidationError (96 rows) and JSONDecodeError (52 rows) are typical: zero hits in messages_fts, because they are runtime class names that only ever appeared in tool output.

For contrast, the same probe over all tool output — not just failures — is far less alarming (48.8% locatable), and over file names it is 74%. Failures are the sharp edge, which is why this PR indexes only them.

What this does

tool_errors_fts indexes is_error rows only — 0.6% of tool_results by size (1.3 MB here), about 6 MB of inverted index on a 950 MB database.

Successful tool output stays unindexed on purpose. It is ~99% of the volume (Read 98.9 MB, Bash 90.7 MB on my index), and full-text indexing it would add roughly 1.1 GB. It doesn't earn that: once retrieval has produced a session_id, a LIKE scoped to it is ~1 ms via idx_tr_session, and even an unscoped scan of all 209 MB is 1.7–3.2 s — fine as a deliberate last resort.

Refreshed wholesale in finalize, not maintained by triggers. tool_results is written with INSERT OR REPLACE, and REPLACE fires DELETE triggers only when recursive_triggers is on (off by default) — a trigger pair would leave superseded error text searchable forever, and re-indexing the same tool call would silently accumulate duplicates. A full refresh of a few thousand rows costs ~0.5 s warm (4.7 s on a cold page cache), against a 113 s full build. Both index paths do it: packages/core/src/indexer.ts via rebuildToolErrorsFts(), and the app's rebuildFts().

Every write path stays correct without bookkeeping, since the refresh is unconditional: force build (DELETE FROM tool_results then re-index), incremental build, and per-session retraction all converge.

Verification

tests/tool-errors-fts.test.mjs, 7 tests — including the two that motivate the no-trigger decision: re-indexing the same tool_use_id leaves no stale text searchable, and a result that stops being an error drops out. Also idempotence, is_error filtering, session pivot, and the force-build path.

Full suite / lint / typecheck / build:core / build:cli: no regression — failing tests on my machine are identical with and without this change (22 files, all better-sqlite3, which cannot build on Node 26). I could not exercise the app's rebuildFts() at runtime for that reason, only typecheck it — that call site deserves a second look.

Notes

• The skill is updated too (references/schema.md, references/query-patterns.md); without it agents won't know the table exists and will keep missing these.
• Independent of feat(core): make the FTS5 tokenizer configurable (CJK recall) #14, but they touch adjacent ground: if feat(core): make the FTS5 tokenizer configurable (CJK recall) #14 lands first, tool_errors_fts should join FTS_TABLES so a configured tokenizer applies to it as well. Happy to rebase in whichever order you prefer.
• No tokenizer specified here, so it follows the schema default. Error text is overwhelmingly ASCII, so unicode61 is a reasonable default even for CJK users.

🤖 Generated with Claude Code