@prmichaelsen/remember-mcp 2.0.0 → 2.0.2

package/agent/patterns/pattern.template.md

@@ -0,0 +1,364 @@
+# {Pattern Name}
+
+**Category**: [Architecture | Design | Code | Testing | Deployment]
+**Applicable To**: [What types of projects or components this pattern applies to]
+**Status**: [Stable | Experimental | Deprecated]
+
+---
+
+## Overview
+
+[Provide a high-level description of what this pattern is and when to use it. Include the problem space it addresses and the general approach it takes.]
+
+**Example**: "The Service Layer Pattern provides a clear separation between business logic and data access, enabling better testability, maintainability, and code reuse across different interfaces (API, CLI, etc.)."
+
+---
+
+## When to Use This Pattern
+
+[Describe the scenarios where this pattern is appropriate:]
+
+✅ **Use this pattern when:**
+- Condition 1
+- Condition 2
+- Condition 3
+
+❌ **Don't use this pattern when:**
+- Condition 1
+- Condition 2
+- Condition 3
+
+**Example**:
+
+✅ **Use this pattern when:**
+- You have complex business logic that needs to be shared across multiple interfaces
+- You want to isolate business logic from infrastructure concerns
+- You need to test business logic independently of data access
+
+❌ **Don't use this pattern when:**
+- Your application is very simple with minimal business logic
+- You're building a thin wrapper around a database
+- The overhead of additional layers outweighs the benefits
+
+---
+
+## Core Principles
+
+[List the fundamental concepts that underpin this pattern:]
+
+1. **Principle 1**: [Description]
+2. **Principle 2**: [Description]
+3. **Principle 3**: [Description]
+4. **Principle 4**: [Description]
+
+**Example**:
+
+1. **Separation of Concerns**: Business logic is isolated from data access and presentation
+2. **Single Responsibility**: Each service handles one domain concept
+3. **Dependency Injection**: Services receive their dependencies rather than creating them
+4. **Interface-Based Design**: Services depend on abstractions, not concrete implementations
+
+---
+
+## Implementation
+
+[Provide detailed implementation guidance with code examples:]
+
+### Structure
+
+[Describe the overall structure of the pattern]
+
+```
+directory-structure/
+├── component1/
+│   └── file1.ext
+└── component2/
+    └── file2.ext
+```
+
+### Code Example
+
+[Provide a complete, working example:]
+
+```typescript
+// Example implementation
+interface ExampleInterface {
+  method(): Promise<Result>;
+}
+
+class ExampleImplementation implements ExampleInterface {
+  constructor(private dependency: Dependency) {}
+  
+  async method(): Promise<Result> {
+    // Implementation
+    return result;
+  }
+}
+```
+
+### Key Components
+
+[Break down the major components:]
+
+#### Component 1: [Name]
+[Description and purpose]
+
+```typescript
+// Code example for this component
+```
+
+#### Component 2: [Name]
+[Description and purpose]
+
+```typescript
+// Code example for this component
+```
+
+---
+
+## Examples
+
+[Provide multiple real-world examples showing different use cases:]
+
+### Example 1: [Use Case Name]
+
+[Description of the scenario]
+
+```typescript
+// Complete code example
+class ConcreteExample {
+  // Implementation
+}
+
+// Usage
+const example = new ConcreteExample();
+const result = await example.doSomething();
+```
+
+### Example 2: [Use Case Name]
+
+[Description of the scenario]
+
+```typescript
+// Complete code example
+```
+
+---
+
+## Benefits
+
+[List the advantages of using this pattern:]
+
+### 1. [Benefit Name]
+[Detailed explanation of this benefit and why it matters]
+
+### 2. [Benefit Name]
+[Detailed explanation of this benefit and why it matters]
+
+### 3. [Benefit Name]
+[Detailed explanation of this benefit and why it matters]
+
+**Example**:
+
+### 1. Testability
+Business logic can be tested in isolation without requiring database connections or external services. Mock dependencies can be easily injected for unit testing.
+
+### 2. Reusability
+The same business logic can be used across multiple interfaces (REST API, GraphQL, CLI, etc.) without duplication.
+
+### 3. Maintainability
+Changes to business logic are centralized in service classes, making the codebase easier to understand and modify.
+
+---
+
+## Trade-offs
+
+[Honestly assess the downsides and limitations:]
+
+### 1. [Trade-off Name]
+**Downside**: [Description]
+**Mitigation**: [How to minimize this downside]
+
+### 2. [Trade-off Name]
+**Downside**: [Description]
+**Mitigation**: [How to minimize this downside]
+
+**Example**:
+
+### 1. Additional Complexity
+**Downside**: Adds extra layers and files to the codebase, which can feel like over-engineering for simple applications.
+**Mitigation**: Only apply this pattern when complexity justifies it. Start simple and refactor to this pattern as needs grow.
+
+### 2. Performance Overhead
+**Downside**: Additional function calls and abstractions can add minor performance overhead.
+**Mitigation**: In most applications, this overhead is negligible. Profile before optimizing.
+
+---
+
+## Anti-Patterns
+
+[Document what NOT to do - common mistakes and misuses:]
+
+### ❌ Anti-Pattern 1: [Name]
+
+**Description**: [What people do wrong]
+
+**Why it's bad**: [Consequences]
+
+**Instead, do this**: [Correct approach]
+
+```typescript
+// ❌ Bad example
+class BadExample {
+  // What not to do
+}
+
+// ✅ Good example
+class GoodExample {
+  // Correct approach
+}
+```
+
+### ❌ Anti-Pattern 2: [Name]
+
+[Similar structure as above]
+
+**Example**:
+
+### ❌ Anti-Pattern 1: God Service
+
+**Description**: Creating a single service class that handles all business logic for the entire application.
+
+**Why it's bad**: Violates single responsibility principle, becomes difficult to test and maintain, creates tight coupling.
+
+**Instead, do this**: Create focused services, each handling a specific domain concept.
+
+```typescript
+// ❌ Bad: Everything in one service
+class ApplicationService {
+  createUser() {}
+  deleteUser() {}
+  createProduct() {}
+  deleteProduct() {}
+  processPayment() {}
+  sendEmail() {}
+}
+
+// ✅ Good: Focused services
+class UserService {
+  createUser() {}
+  deleteUser() {}
+}
+
+class ProductService {
+  createProduct() {}
+  deleteProduct() {}
+}
+
+class PaymentService {
+  processPayment() {}
+}
+```
+
+---
+
+## Testing Strategy
+
+[Describe how to test code that uses this pattern:]
+
+### Unit Testing
+[Approach for unit tests]
+
+```typescript
+// Example unit test
+describe('ExampleService', () => {
+  it('should do something', async () => {
+    // Test implementation
+  });
+});
+```
+
+### Integration Testing
+[Approach for integration tests]
+
+```typescript
+// Example integration test
+```
+
+---
+
+## Related Patterns
+
+[Link to related patterns and explain relationships:]
+
+- **[Pattern Name](./pattern-name.md)**: [How it relates]
+- **[Pattern Name](./pattern-name.md)**: [How it relates]
+- **[Pattern Name](./pattern-name.md)**: [How it relates]
+
+**Example**:
+- **[Repository Pattern](./repository-pattern.md)**: Often used together; services use repositories for data access
+- **[Factory Pattern](./factory-pattern.md)**: Can be used to create service instances with proper dependencies
+- **[Dependency Injection](./dependency-injection.md)**: Essential for implementing this pattern correctly
+
+---
+
+## Migration Guide
+
+[If adopting this pattern in an existing codebase, provide migration steps:]
+
+### Step 1: [Action]
+[Detailed description]
+
+### Step 2: [Action]
+[Detailed description]
+
+### Step 3: [Action]
+[Detailed description]
+
+**Example**:
+
+### Step 1: Identify Business Logic
+Review existing code and identify business logic that's currently mixed with data access or presentation code.
+
+### Step 2: Extract to Services
+Create service classes and move business logic into them. Start with the most complex or frequently used logic.
+
+### Step 3: Refactor Dependencies
+Update calling code to use the new services. Inject dependencies rather than creating them directly.
+
+---
+
+## References
+
+[Link to external resources, papers, books, or articles:]
+
+- [Resource 1](URL): Description
+- [Resource 2](URL): Description
+- [Resource 3](URL): Description
+
+**Example**:
+- [Martin Fowler - Service Layer](https://martinfowler.com/eaaCatalog/serviceLayer.html): Original pattern description
+- [Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html): Related architectural concepts
+- [Domain-Driven Design](https://www.domainlanguage.com/ddd/): Context for service design
+
+---
+
+## Checklist for Implementation
+
+[Provide a checklist to ensure proper implementation:]
+
+- [ ] Services are focused on single domain concepts
+- [ ] Dependencies are injected, not created internally
+- [ ] Business logic is isolated from infrastructure concerns
+- [ ] Services have clear, well-documented interfaces
+- [ ] Unit tests cover business logic in isolation
+- [ ] Integration tests verify end-to-end functionality
+- [ ] Error handling is consistent and appropriate
+- [ ] Logging provides adequate visibility
+
+---
+
+**Status**: [Current status of this pattern document]
+**Recommendation**: [When and how to use this pattern]
+**Last Updated**: [YYYY-MM-DD]
+**Contributors**: [Names or "Community"]

package/agent/progress.template.yaml

@@ -0,0 +1,158 @@
+# Project Progress Tracking
+# This file tracks the overall progress of the project, including milestones, tasks, and recent work.
+# Update this file regularly as work progresses.
+
+project:
+  name: project-name                    # Replace with your project name
+  version: 0.1.0                        # Current version (semantic versioning)
+  started: YYYY-MM-DD                   # Date project started
+  status: not_started                   # not_started | in_progress | completed
+  current_milestone: M1                 # Current milestone identifier
+  description: |                        # Brief project description
+    A short description of what this project does and its main purpose.
+
+# Milestones represent major phases of the project
+milestones:
+  - id: M1                              # Unique milestone identifier
+    name: Milestone Name                # Descriptive name
+    status: not_started                 # not_started | in_progress | completed
+    progress: 0                         # Percentage complete (0-100)
+    started: null                       # YYYY-MM-DD when started, null if not started
+    completed: null                     # YYYY-MM-DD when completed, null if not completed
+    estimated_weeks: 2                  # Estimated duration in weeks
+    tasks_completed: 0                  # Number of tasks completed
+    tasks_total: 5                      # Total number of tasks in this milestone
+    notes: |                            # Progress notes and observations
+      Notes about this milestone's progress, blockers, or important decisions.
+  
+  - id: M2
+    name: Second Milestone Name
+    status: not_started
+    progress: 0
+    started: null
+    completed: null
+    estimated_weeks: 3
+    tasks_completed: 0
+    tasks_total: 7
+    notes: |
+      This milestone depends on M1 completion.
+
+# Tasks are granular work items within milestones
+tasks:
+  milestone_1:                          # Group tasks by milestone
+    - id: task-1                        # Unique task identifier
+      name: Task Name                   # Descriptive task name
+      status: not_started               # not_started | in_progress | completed
+      file: agent/tasks/task-1-name.md  # Path to task document
+      estimated_hours: 4                # Estimated time in hours
+      completed_date: null              # YYYY-MM-DD when completed, null if not completed
+      notes: |                          # Task-specific notes
+        Any important notes about this task.
+    
+    - id: task-2
+      name: Second Task Name
+      status: not_started
+      file: agent/tasks/task-2-name.md
+      estimated_hours: 2
+      completed_date: null
+      notes: |
+        Depends on task-1 completion.
+  
+  milestone_2:
+    - id: task-3
+      name: Third Task Name
+      status: not_started
+      file: agent/tasks/task-3-name.md
+      estimated_hours: 6
+      completed_date: null
+      notes: |
+        First task of second milestone.
+
+# Documentation tracking
+documentation:
+  design_documents: 0                   # Number of design documents created
+  milestone_documents: 0                # Number of milestone documents
+  pattern_documents: 0                  # Number of pattern documents
+  task_documents: 0                     # Number of task documents
+  last_updated: YYYY-MM-DD              # Last documentation update date
+
+# Overall progress metrics
+progress:
+  planning: 0                           # Planning phase completion (0-100%)
+  implementation: 0                     # Implementation phase completion (0-100%)
+  testing: 0                            # Testing phase completion (0-100%)
+  documentation: 0                      # Documentation completion (0-100%)
+  overall: 0                            # Overall project completion (0-100%)
+
+# Recent work log (most recent first)
+recent_work:
+  - date: YYYY-MM-DD                    # Date of work
+    description: |                      # Description of what was done
+      Brief description of work completed on this date.
+    items:                              # Specific items completed
+      - ✅ Completed item 1
+      - ✅ Completed item 2
+      - ⚠️  Warning or note about something
+      - 📋 Pending item or follow-up needed
+  
+  - date: YYYY-MM-DD
+    description: |
+      Earlier work session description.
+    items:
+      - ✅ Another completed item
+      - 📋 Something to revisit
+
+# Next steps (prioritized list)
+next_steps:
+  - Next action item 1 (highest priority)
+  - Next action item 2
+  - Next action item 3
+  - Future consideration or enhancement
+
+# General notes and observations
+notes:
+  - Important note 1 about the project
+  - Important note 2 about architectural decisions
+  - Important note 3 about dependencies or constraints
+
+# Current blockers (remove when resolved)
+current_blockers:
+  - Blocker 1: Description of what's blocking progress
+  - Blocker 2: Another blocker and potential resolution
+
+# Team and contributors (if applicable)
+team:
+  - role: Lead Developer              # Role or responsibility
+    name: Name or "Agent"             # Name or identifier
+    focus: |                          # Current focus area
+      What this person/agent is currently working on
+  
+  - role: Documentation
+    name: Name or "Agent"
+    focus: |
+      Maintaining documentation and patterns
+
+# Dependencies and integrations
+dependencies:
+  external_services:                  # External services this project depends on
+    - name: Service Name
+      status: configured | pending | blocked
+      notes: |
+        Notes about this dependency
+  
+  libraries:                          # Key library dependencies
+    - name: Library Name
+      version: 1.0.0
+      purpose: |
+        Why this library is used
+  
+  infrastructure:                     # Infrastructure requirements
+    - name: Infrastructure Component
+      status: ready | pending | blocked
+      notes: |
+        Notes about this infrastructure
+
+# Quality metrics (optional)
+quality:
+  test_coverage: 0                    # Percentage (0-100)
+  code_review_status: pending         # pending | in

package/agent/progress.yaml

@@ -2,11 +2,11 @@
 
 project:
   name: remember-mcp
-  version: 1.0.1
+  version: 2.0.1
   started: 2026-02-11
   status: in_progress
   current_milestone: M5
-  last_updated: 2026-02-12
+  last_updated: 2026-02-14
 
 milestones:
   - id: M1
@@ -378,6 +378,36 @@ progress:
   overall: 50%
 
 recent_work:
+  - date: 2026-02-14
+    description: v2.0.1 Released - Enhanced Error Logging Framework
+    items:
+      - 🎉 v2.0.1 RELEASED - Patch release with error handling improvements
+      - ✅ Created centralized error-handler utility (src/utils/error-handler.ts)
+      - ✅ Enhanced error logging in remember_update_memory
+      - ✅ Detailed error context: userId, memoryId, operation, stack traces
+      - ✅ Separate error handling for fetch and update operations
+      - ✅ Error messages now include full context for Cloud Run debugging
+      - ✅ Framework ready for application to all 12 tools
+      - ✅ Build successful
+      - ✅ All tests passing
+      - 📋 Production error diagnostics significantly improved
+      
+  - date: 2026-02-14
+    description: Project Status Review - ACP Initialization
+    items:
+      - 📊 Comprehensive project review completed via ACP initialization
+      - ✅ All 12 MCP tools implemented and working
+      - ✅ 54 tests passing (53 passed, 1 skipped integration test)
+      - ✅ Test coverage: 29.26% overall
+      - ✅ TypeScript compiles without errors
+      - ✅ Build successful (v2.0.0)
+      - ✅ 30 TypeScript source files in project (added error-handler.ts)
+      - ✅ Dual export: standalone server + factory for mcp-auth
+      - ✅ All 4 milestones complete (M1-M4: 100%)
+      - ✅ Ready to begin M5: Template System
+      - 📋 Project structure follows ACP and bootstrap patterns
+      - 📋 Documentation comprehensive and up-to-date
+      
   - date: 2026-02-12
     description: v1.0.1 Released - Or Operator Bug Fix
     items:
@@ -523,10 +553,14 @@ environment_configured:
   - 📋 Firebase project needs to be created with Firestore enabled
 
 test_status:
-  - ✅ 25 unit tests passing
+  - ✅ 53 unit tests passing
   - ✅ 1 test skipped (integration test requiring live Weaviate)
-  - ✅ Test coverage: 30.37% overall
-  - ✅ All critical paths covered: config, client, factory, paths, content-types
+  - ✅ Test coverage: 29.26% overall
+  - ✅ All critical paths covered: config, client, factory, paths, content-types, weaviate-filters
+  - ✅ 32 tests for weaviate-filters (filter builders and edge cases)
+  - ✅ 9 tests for server-factory (async initialization)
+  - ✅ 7 tests for firestore paths
+  - ✅ 5 tests for weaviate client
   - 📋 Integration tests deferred (Task 6)
   - 📋 E2E tests not yet created
 
@@ -537,11 +571,13 @@ build_status:
   - ✅ Source maps generated
   - ✅ Type definitions generated (.d.ts files)
   - ✅ Package exports configured for both entry points
-  - ✅ Version 1.0.1 published (patch release)
-  - ✅ 29 TypeScript source files (added weaviate-filters.ts)
+  - ✅ Version 2.0.1 published (patch release - error logging)
+  - ✅ 30 TypeScript source files (added error-handler.ts)
   - ✅ All 12 tools implemented
   - ✅ Weaviate v3 filter API implemented
   - ✅ Or/And operator validation implemented
+  - ✅ Async createServer pattern (breaking change in v2.0.0)
+  - ✅ Centralized error handling framework
 
 tools_status:
   memory_tools:

package/agent/scripts/check-for-updates.sh

@@ -0,0 +1,88 @@
+#!/bin/bash
+
+# Agent Context Protocol (ACP) Update Checker
+# This script checks if updates are available for AGENT.md
+
+set -e
+
+# Colors for output
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+BLUE='\033[0;34m'
+NC='\033[0m' # No Color
+
+# Repository URL
+REPO_URL="https://raw.githubusercontent.com/prmichaelsen/agent-context-protocol/mainline"
+AGENT_MD_URL="$REPO_URL/AGENT.md"
+CHANGELOG_URL="$REPO_URL/CHANGELOG.md"
+
+# Silent mode (no output, just exit codes)
+SILENT=false
+if [ "$1" = "--silent" ] || [ "$1" = "-s" ]; then
+    SILENT=true
+fi
+
+# Check if AGENT.md exists
+if [ ! -f "AGENT.md" ]; then
+    if [ "$SILENT" = false ]; then
+        echo -e "${RED}Error: AGENT.md not found in current directory${NC}" >&2
+        echo "This script should be run from your project root where AGENT.md is located." >&2
+    fi
+    exit 2
+fi
+
+# Download latest AGENT.md for comparison
+if [ "$SILENT" = false ]; then
+    echo -e "${BLUE}Checking for updates...${NC}"
+fi
+
+if command -v curl &> /dev/null; then
+    curl -fsSL "$AGENT_MD_URL" -o /tmp/AGENT.md.latest 2>/dev/null
+elif command -v wget &> /dev/null; then
+    wget -q "$AGENT_MD_URL" -O /tmp/AGENT.md.latest 2>/dev/null
+else
+    if [ "$SILENT" = false ]; then
+        echo -e "${RED}Error: Neither curl nor wget is available${NC}" >&2
+    fi
+    exit 2
+fi
+
+if [ $? -ne 0 ]; then
+    if [ "$SILENT" = false ]; then
+        echo -e "${RED}Error: Failed to download latest AGENT.md${NC}" >&2
+        echo "Please check your internet connection." >&2
+    fi
+    rm -f /tmp/AGENT.md.latest
+    exit 2
+fi
+
+# Compare files
+if cmp -s AGENT.md /tmp/AGENT.md.latest; then
+    # Files are identical - no updates
+    if [ "$SILENT" = false ]; then
+        echo -e "${GREEN}✓${NC} Your AGENT.md is up to date!"
+    fi
+    rm -f /tmp/AGENT.md.latest
+    exit 0
+else
+    # Files differ - updates available
+    if [ "$SILENT" = false ]; then
+        echo -e "${YELLOW}⚠${NC}  Updates are available for AGENT.md"
+        echo ""
+        
+        # Download and display changelog
+        echo "Recent changes:"
+        echo "---------------"
+        if command -v curl &> /dev/null; then
+            curl -fsSL "$CHANGELOG_URL" 2>/dev/null | head -n 50
+        elif command -v wget &> /dev/null; then
+            wget -q "$CHANGELOG_URL" -O - 2>/dev/null | head -n 50
+        fi
+        echo ""
+        echo "To update, run: ./agent/scripts/update.sh"
+        echo "Or: curl -fsSL https://raw.githubusercontent.com/prmichaelsen/agent-context-protocol/mainlin./agent/scripts/update.sh | bash"
+    fi
+    rm -f /tmp/AGENT.md.latest
+    exit 1
+fi