Alex Newman
c5e68a17c8
* 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>
1 line
6.2 KiB
JSON
1 line
6.2 KiB
JSON
[{"type":"text","text":"## Session Search Successfully Retrieves Full Session Summaries\n*Source: claude-mem://observation/10654*\n\n**Search query for search architecture returns complete session records with request, investigated, learned, completed, and next steps fields**\n\nThe session search test demonstrated successful functionality, contrasting sharply with the failed observation searches. Using type=sessions, the query retrieved 57 semantic matches from Chroma and returned comprehensive session summaries. Each result includes the full session structure: completed (what was accomplished), learned (key insights), investigated (what was explored), next steps (planned actions), and notes (additional context). The first result details a session reviewing search architecture guidelines and the MCP-as-DRY-source principle, including specifics about the build pipeline, unified search API design with catch-all parameters, and the layered architecture pattern. This successful session search, combined with earlier log evidence showing prompt searches also working, confirms that Chroma's failures are isolated to observation queries specifically.\n\n---\nType: discovery | Facts: Session search query succeeded with 57 semantic matches from Chroma; Results include full session summary format with completed, learned, investigated, next steps, and notes sections; First result shows session about MCP architecture review from November 17, 2025; Session records tagged with source link format claude-mem://session/UUID; Sessions contain detailed context about build pipeline, search architecture decisions, and unified API design; Session search uses type=sessions parameter successfully unlike observation searches | Concepts: how-it-works | Files: test-results/test-20-session-search.json\n\n---\nDate: 11/17/2025, 9:33:37 PM\n\n---\n\n## Architecture Guidelines for Search Established\n*Source: claude-mem://observation/10633*\n\n**Code review requested to verify commit follows MCP-based search architecture with specific DRY principles.**\n\nA commit review was requested to ensure compliance with established architecture guidelines for the search functionality. The architecture mandates that MCP (Model Context Protocol) acts as the single, authoritative search source following DRY principles. All HTTP API search requests must route through MCP rather than implementing parallel search logic. This architectural decision confirms that MCP is the active, non-deprecated component for search operations, establishing clear boundaries between API layers and preventing code duplication across the search infrastructure.\n\n---\nType: decision | Facts: MCP serves as the DRY (Don't Repeat Yourself) search source in the architecture; HTTP API is designed to route through MCP for search functionality; MCP is confirmed as not deprecated and remains the canonical search implementation | Concepts: pattern, why-it-exists, how-it-works\n\n---\nDate: 11/17/2025, 9:22:30 PM\n\n---\n\n## Search Architecture Guidelines Enforcement\n*Source: claude-mem://observation/10629*\n\n**Architecture review requested to validate commit follows search design: MCP as dry source, HTTP routes through MCP.**\n\nA commit review was requested to validate compliance with established search architecture guidelines. The architecture mandates that MCP (Model Context Protocol) functions as the DRY (Don't Repeat Yourself) search source, with HTTP API routes required to route through MCP rather than implementing search logic independently. This ensures centralized search implementation and prevents code duplication. The review specifically aims to confirm MCP remains the canonical, non-deprecated search implementation approach.\n\n---\nType: decision | Facts: MCP serves as the dry search source in the system architecture; HTTP API routes must go through MCP rather than implementing search directly; MCP is the active, non-deprecated approach for search functionality | Concepts: pattern, why-it-exists, how-it-works\n\n---\nDate: 11/17/2025, 9:21:29 PM\n\n---\n\n## Search Architecture Guidelines Validation Requested\n*Source: claude-mem://observation/10621*\n\n**Commit review requested to verify adherence to search architecture: MCP as dry source, HTTP through MCP, MCP not deprecated.**\n\nA commit review was requested to ensure compliance with established search architecture guidelines. The architecture mandates that MCP (Model Context Protocol) functions as the canonical dry search source, with HTTP API endpoints routing through MCP rather than implementing search logic directly. This design decision maintains MCP as the active, non-deprecated integration layer for search functionality, ensuring consistency and avoiding duplication of search logic across different access methods.\n\n---\nType: decision | Facts: Architecture guideline: MCP serves as the dry search source; Architecture guideline: HTTP API routes search requests through MCP; Architecture guideline: MCP is not deprecated and remains the primary search integration layer | Concepts: why-it-exists, pattern, how-it-works\n\n---\nDate: 11/17/2025, 9:16:24 PM\n\n---\n\n## Search server contains no deprecation warnings or plans to remove MCP\n*Source: claude-mem://observation/10617*\n\n**Zero matches for deprecated, legacy, TODO, FIXME, replace MCP, or remove MCP in search-server.ts**\n\nThe absence of any deprecation warnings, legacy markers, or plans to remove MCP functionality confirms that the search server refactoring treats MCP as a first-class, actively maintained interface rather than a deprecated feature. This aligns with the architectural guideline that MCP should not be deprecated. The implementation invests in MCP with comprehensive tool definitions, schema validation, and feature parity with HTTP APIs, indicating it's the preferred interface rather than a transitional technology.\n\n---\nType: discovery | Facts: Case-insensitive search for deprecation-related terms returned zero matches in src/servers/search-server.ts; No comments indicating MCP is deprecated or will be replaced; No TODO or FIXME items suggesting future removal of MCP functionality; Search server implementation treats MCP as the primary, actively maintained interface | Concepts: pattern, why-it-exists | Files: src/servers/search-server.ts\n\n---\nDate: 11/17/2025, 9:10:45 PM"}] |