Files
claude-mem/test-results/test-11-search-server-changes.json
T
Alex Newman c5e68a17c8 refactor: Clean up search architecture, remove experimental contextualize endpoint (#133)
* Refactor code structure for improved readability and maintainability

* Add test results for search API and related functionalities

- Created test result files for various search-related functionalities, including:
  - test-11-search-server-changes.json
  - test-12-context-hook-changes.json
  - test-13-worker-service-changes.json
  - test-14-patterns.json
  - test-15-gotchas.json
  - test-16-discoveries.json
  - test-17-all-bugfixes.json
  - test-18-all-features.json
  - test-19-all-decisions.json
  - test-20-session-search.json
  - test-21-prompt-search.json
  - test-22-decisions-endpoint.json
  - test-23-changes-endpoint.json
  - test-24-how-it-works-endpoint.json
  - test-25-contextualize-endpoint.json
  - test-26-timeline-around-observation.json
  - test-27-multi-param-combo.json
  - test-28-file-type-combo.json

- Each test result file captures specific search failures or outcomes, including issues with undefined properties and successful execution of search queries.
- Enhanced documentation of search architecture and testing strategies, ensuring compliance with established guidelines and improving overall search functionality.

* feat: Enhance unified search API with catch-all parameters and backward compatibility

- Implemented a unified search API at /api/search that accepts catch-all parameters for filtering by type, observation type, concepts, and files.
- Maintained backward compatibility by keeping granular endpoints functional while routing through the same infrastructure.
- Completed comprehensive testing of search capabilities with real-world query scenarios.

fix: Address missing debug output in search API query tests

- Flushed PM2 logs and executed search queries to verify functionality.
- Diagnosed absence of "Raw Chroma" debug messages in worker logs, indicating potential issues with logging or query processing.

refactor: Improve build and deployment pipeline for claude-mem plugin

- Successfully built and synced all hooks and services to the marketplace directory.
- Ensured all dependencies are installed and up-to-date in the deployment location.

feat: Implement hybrid search filters with 90-day recency window

- Enhanced search server to apply a 90-day recency filter to Chroma results before categorizing by document type.

fix: Correct parameter handling in searchUserPrompts method

- Added support for filter-only queries and improved dual-path logic for clarity.

refactor: Rename FTS5 method to clarify fallback status

- Renamed escapeFTS5 to escapeFTS5_fallback_when_chroma_unavailable to indicate its temporary usage.

feat: Introduce contextualize tool for comprehensive project overview

- Added a new tool to fetch recent observations, sessions, and user prompts, providing a quick project overview.

feat: Add semantic shortcut tools for common search patterns

- Implemented 'decisions', 'changes', and 'how_it_works' tools for convenient access to frequently searched observation categories.

feat: Unified timeline tool supports anchor and query modes

- Combined get_context_timeline and get_timeline_by_query into a single interface for timeline exploration.

feat: Unified search tool added to MCP server

- New tool queries all memory types simultaneously, providing combined chronological results for improved search efficiency.

* Refactor search functionality to clarify FTS5 fallback usage

- Updated `worker-service.cjs` to replace FTS5 fallback function with a more descriptive name and improved error handling.
- Enhanced documentation in `SKILL.md` to specify the unified API endpoint and clarify the behavior of the search engine, including the conditions under which FTS5 is used.
- Modified `search-server.ts` to provide clearer logging and descriptions regarding the fallback to FTS5 when UVX/Python is unavailable.
- Renamed and updated the `SessionSearch.ts` methods to reflect the conditions for using FTS5, emphasizing the lack of semantic understanding in fallback scenarios.

* feat: Add ID-based fetch endpoints and simplify mem-search skill

**Problem:**
- Search returns IDs but no way to fetch by ID
- Skill documentation was bloated with too many options
- Claude wasn't using IDs because we didn't tell it how

**Solution:**
1. Added three new HTTP endpoints:
   - GET /api/observation/:id
   - GET /api/session/:id
   - GET /api/prompt/:id

2. Completely rewrote SKILL.md:
   - Stripped complexity down to essentials
   - Clear 3-step prescriptive workflow: Search → Review IDs → Fetch by ID
   - Emphasized ID usage: "The IDs are there for a reason - USE THEM"
   - Removed confusing multi-endpoint documentation
   - Kept only unified search with filters

**Impact:**
- Token efficiency: Claude can now fetch full details only for relevant IDs
- Clarity: One clear workflow instead of 10+ options to choose from
- Usability: IDs are no longer wasted context - they're actionable

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* chore: Move internal docs to private directory

Moved POSTMORTEM and planning docs to ./private to exclude from PR reviews.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* refactor: Remove experimental contextualize endpoint

- Removed contextualize MCP tool from search-server (saves ~4KB)
- Disabled FTS5 fallback paths in SessionSearch (now vector-first)
- Cleaned up CLAUDE.md documentation
- Removed contextualize-rewrite-plan.md doc

Rationale:
- Contextualize is better suited as a skill (LLM-powered) than an endpoint
- Search API already provides vector search with configurable limits
- Created issue #132 to track future contextualize skill implementation

Changes:
- src/servers/search-server.ts: Removed contextualize tool definition
- src/services/sqlite/SessionSearch.ts: Disabled FTS5 fallback, added deprecation warnings
- CLAUDE.md: Cleaned up outdated skill documentation
- docs/: Removed contextualize plan document

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* refactor: Complete FTS5 cleanup - remove all deprecated search code

This completes the FTS5 cleanup work by removing all commented-out
FTS5 search code while preserving database tables for backward compatibility.

Changes:
- Removed 200+ lines of commented FTS5 search code from SessionSearch.ts
- Removed deprecated degraded_search_query__when_uvx_unavailable method
- Updated all method documentation to clarify vector-first architecture
- Updated class documentation to reflect filter-only query support
- Updated CLAUDE.md to remove FTS5 search references
- Clarified that FTS5 tables exist for backward compatibility only
- Updated "Why SQLite FTS5" section to "Why Vector-First Search"

Database impact: NONE - FTS5 tables remain intact for existing installations

Search architecture:
- ChromaDB: All text-based vector search queries
- SQLite: Filter-only queries (date ranges, metadata, no query text)
- FTS5 tables: Maintained but unused (backward compatibility)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* refactor: Remove all FTS5 fallback execution code from search-server

Completes the FTS5 cleanup by removing all fallback execution paths
that attempted to use FTS5 when ChromaDB was unavailable.

Changes:
- Removed all FTS5 fallback code execution paths
- When ChromaDB fails or is unavailable, return empty results with helpful error messages
- Updated all deprecated tool descriptions (search_observations, search_sessions, search_user_prompts)
- Changed error messages to indicate FTS5 fallback has been removed
- Added installation instructions for UVX/Python when vector search is unavailable
- Updated comments from "hybrid search" to "vector-first search"
- Removed ~100 lines of dead FTS5 fallback code

Database impact: NONE - FTS5 tables remain intact (backward compatibility)

Search behavior when ChromaDB unavailable:
- Text queries: Return empty results with error explaining ChromaDB is required
- Filter-only queries (no text): Continue to work via direct SQLite

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* fix: Address PR 133 review feedback

Critical fixes:
- Remove contextualize endpoint from worker-service (route + handler)
- Fix build script logging to show correct .cjs extension (was .mjs)

Documentation improvements:
- Add comprehensive FTS5 retention rationale documentation
- Include v7.0.0 removal TODO for future cleanup

Testing:
- Build succeeds with correct output logging
- Worker restarts successfully (30th restart)
- Contextualize endpoint properly removed (404 response)
- Search endpoint verified working

This addresses all critical review feedback from PR 133.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>
2025-11-21 18:59:23 -05:00

1 line
8.2 KiB
JSON

[{"type":"text","text":"## Unified search handler implements Chroma-first with FTS5 fallback on zero results\n*Source: claude-mem://observation/10757*\n\n**Lines 403-489 show current implementation attempts Chroma first, falls back to FTS5 when empty.**\n\nThe unified search handler in search-server.ts (lines 390-489) reveals the current implementation architecture. The handler first attempts Chroma semantic search when chromaClient is available, calling queryChroma with the query parameter at line 419. If Chroma throws an error, it catches at line 465 and falls through to FTS5. However, the problematic FTS5 fallback logic at line 470 triggers when all result arrays are empty, not just on errors. This contradicts the insight that FTS5 contains identical data to Chroma, making zero-result fallback pointless. Additionally, lines 476-483 call search methods (searchObservations, searchSessions, searchUserPrompts) with the query parameter without checking if it's undefined, which will cause failures when query is not provided. The handler needs modification to skip Chroma when query is undefined and only fall back to FTS5 on Chroma errors.\n\n---\nType: discovery | Facts: Line 403 checks `if (chromaClient)` to attempt Chroma semantic search first; Line 419 calls `queryChroma(query, 100, whereFilter)` with query parameter as required; Lines 465-467 catch Chroma errors and fall through to FTS5 fallback; Line 470 triggers FTS5 fallback when all result arrays have zero length; Lines 476-483 call SessionSearch methods with query parameter without checking if undefined; Hybrid search applies 90-day recency filter at lines 424-431 | Concepts: how-it-works, problem-solution, gotcha | Files: src/servers/search-server.ts\n\n---\nDate: 11/17/2025, 11:50:29 PM\n\n---\n\n## Search Query Parameter Made Optional for Filter-Only Queries\n*Source: claude-mem://observation/10744*\n\n**Unified search tool now supports filter-only queries by making query parameter optional.**\n\nThe unified search tool was updated to support filter-only query patterns by making the 'query' parameter optional. Previously, the search tool required a natural language query string, but now users can perform searches using only metadata filters such as observation type, date ranges, concepts, or file paths. The parameter description was enhanced to explicitly indicate that the query is optional and should be omitted for filter-only queries. Additionally, the description was clarified to state that ChromaDB is used for semantic ranking when available, with FTS5 serving as a fallback when ChromaDB is unavailable, making the system's fallback behavior more transparent. This change increases the flexibility of the search interface and better aligns with use cases where users want to browse or filter by specific criteria without performing text-based search.\n\n---\nType: change | Facts: The 'query' parameter in the search tool's inputSchema changed from required to optional; File modified: /Users/alexnewman/Scripts/claude-mem/src/servers/search-server.ts; Updated description clarifies query is optional and can be omitted for filter-only queries; Description now explicitly states ChromaDB is used when available, FTS5 as fallback when unavailable; Change enables searching by filters (type, dateRange, concepts, files) without providing search text | Concepts: what-changed, how-it-works, pattern | Files: /Users/alexnewman/Scripts/claude-mem/src/servers/search-server.ts\n\n---\nDate: 11/17/2025, 11:47:49 PM\n\n---\n\n## Search Tool Requires Query Parameter as Non-Optional String\n*Source: claude-mem://observation/10743*\n\n**The search tool schema defines query as mandatory string parameter, preventing filter-only queries through current interface.**\n\nThe search tool definition in src/servers/search-server.ts reveals that the query parameter is currently defined as a mandatory string using z.string(), which prevents filter-only queries from being submitted through the MCP interface. The tool is described as providing unified search across observations, sessions, and user prompts using hybrid semantic and full-text search, with ChromaDB as primary and SQLite FTS5 as fallback. While the schema includes optional filters like type (for document type filtering), the query parameter itself cannot be omitted. To support the newly identified filter-only query pattern where queries go directly to SQLite instead of ChromaDB, this schema will need modification to make the query parameter optional using z.string().optional(), allowing users to submit filter-only requests.\n\n---\nType: discovery | Facts: The search tool is defined at line 363 in src/servers/search-server.ts; The query parameter is defined as z.string() without optional modifier, making it mandatory; The query parameter description states it enables semantic ranking via ChromaDB with FTS5 fallback; The inputSchema includes optional type filter for observations, sessions, or prompts; The search tool provides index and full output format options with index as default | Concepts: how-it-works, problem-solution | Files: src/servers/search-server.ts\n\n---\nDate: 11/17/2025, 11:47:33 PM\n\n---\n\n## Unified search handler fix requires five-step query routing logic\n*Source: claude-mem://observation/10739*\n\n**Route by query presence, error-based FTS5 fallback only, remove zero-results fallback check.**\n\nThe fix for the unified search handler requires restructuring the query routing logic into five distinct steps. First, check whether the query parameter exists at the top of the handler. If query is undefined, bypass Chroma entirely and invoke a new filter-only path in SessionSearch that performs direct SQLite filtering. If query exists, proceed with Chroma semantic search. The FTS5 fallback logic must change fundamentally - it should only trigger when Chroma throws an error (caught at line 465), not when Chroma successfully returns zero results. When Chroma returns zero results, that is the correct answer since FTS5 contains identical data and would also return zero. This requires removing the zero-results check from line 472's fallback condition, fixing the current incorrect fallback behavior.\n\n---\nType: decision | Facts: Step 1: Check if query parameter exists at beginning of unified search handler; Step 2: If query is undefined, skip Chroma and call new filter-only path in SessionSearch; Step 3: If query exists, attempt Chroma semantic search; Step 4: If Chroma throws error (line 465 catch block), fall back to FTS5; Step 5: If Chroma succeeds with zero results, accept zero as correct answer without FTS5 fallback; Line 472 condition must be modified to remove zero-results check | Concepts: problem-solution, how-it-works, pattern, trade-off | Files: src/servers/search-server.ts\n\n---\nDate: 11/17/2025, 11:42:18 PM\n\n---\n\n## Chroma requires query text; FTS5 fallback logic is incorrect\n*Source: claude-mem://observation/10735*\n\n**Chroma cannot do filter-only queries, and FTS5 fallback on zero results is pointless.**\n\nTwo critical insights emerge about the search architecture. First, Chroma cannot perform filter-only queries without query text because it fundamentally operates on semantic search via vector embeddings. When query is undefined, the system must bypass Chroma entirely and proceed directly to SQLite structured filtering. Second, the current FTS5 fallback logic at line 472 is fundamentally flawed - it triggers when Chroma returns zero results. However, since FTS5 maintains a 1:1 copy of the SQLite data that Chroma also indexes, if Chroma returns zero results, FTS5 will also return zero results. FTS5 fallback should only activate when Chroma is unavailable or encounters an error, not when it successfully returns an empty result set.\n\n---\nType: discovery | Facts: Chroma vector database requires query text for semantic search operations; Filter-only queries must skip Chroma and use SQLite structured filtering directly; FTS5 fallback at line 472 triggers on zero results, not on Chroma errors; FTS5 contains 1:1 copy of SQLite data, so zero Chroma results means zero FTS5 results; FTS5 fallback should only activate when Chroma is unavailable or errors, not on empty results | Concepts: problem-solution, gotcha, how-it-works, why-it-exists | Files: src/servers/search-server.ts\n\n---\nDate: 11/17/2025, 11:41:43 PM"}]