diff --git a/agent-memories/org-memory-chunking-engine.md b/agent-memories/org-memory-chunking-engine.md
new file mode 100644
index 000000000000..6159008279a3
--- /dev/null
+++ b/agent-memories/org-memory-chunking-engine.md
@@ -0,0 +1,36 @@
+# Org-Memory Chunking Engine (Step 005)
+
+## File Location
+- `server/plugins/org-memory/server/chunker.go` — main implementation
+- `server/plugins/org-memory/server/chunker_test.go` — comprehensive tests
+
+## Key Types
+- `ChunkResult` — contains Text, Index (0-based), StartByte, EndByte
+- `ChunkConfig` — TargetChunkTokens, OverlapPercent, MaxChunks, Logger
+- `segment` — internal type for pipeline processing with byte offsets
+
+## Constants
+- `DefaultTargetChunkTokens = 500` (~2000 chars)
+- `DefaultOverlapPercent = 10`
+- `DefaultMaxChunksPerPost = 32`
+- `runesPerToken = 4` (heuristic: 1 token ≈ 4 runes)
+
+## Public API
+- `ChunkText(text string, config ChunkConfig) []ChunkResult` — main entry point, pure function
+- `EstimateTokens(text string) int` — rune-based token count approximation
+
+## Algorithm Pipeline
+1. Strip markdown (regex-based, no goldmark dependency)
+2. Split at paragraph boundaries (double newlines)
+3. Split oversized paragraphs at sentence boundaries
+4. Merge small segments up to target size
+5. Add 10% overlap between adjacent chunks (word-boundary-aware)
+6. Truncate to MaxChunks with logging
+7. Assign sequential 0-based indices
+
+## Important Notes
+- The plugin does NOT use goldmark — markdown stripping is regex-based
+- Code blocks (indented content) are treated as atomic segments, never sentence-split
+- Sentence boundary: `[.!?]\s+[A-Z\p{Lu}]` — splits on "Dr. Smith" but not "e.g. test"
+- The function is source-agnostic — accepts any text, caller determines SourceType
+- All text processing uses rune counts, not byte counts (Unicode-aware)
diff --git a/agent-memories/org-memory-comprehensive-codebase-overview.md b/agent-memories/org-memory-comprehensive-codebase-overview.md
new file mode 100644
index 000000000000..4730fe9ccd52
--- /dev/null
+++ b/agent-memories/org-memory-comprehensive-codebase-overview.md
@@ -0,0 +1,518 @@
+# Org-Memory Plugin - Comprehensive Codebase Overview
+
+## 1. Plugin.go - Main Plugin Struct and Lifecycle
+
+### Plugin Struct Fields
+```go
+type Plugin struct {
+    plugin.MattermostPlugin  // Embeds Mattermost plugin interface
+    client *pluginapi.Client  // Pluginapi client for Mattermost services
+    config *configuration     // Current config (protected by configLock)
+    configLock sync.RWMutex  // Protects concurrent config access
+    db *sql.DB               // Master database handle
+    
+    // AI/Processing Components
+    geminiClient GeminiClient      // Gemini AI client (embedding, extraction, summarization)
+    circuitBreaker *CircuitBreaker // Circuit breaker for Gemini API (KV store backed)
+    rateLimiter *RateLimiter       // Exponential backoff rate limiter (KV store backed)
+    
+    // Storage
+    store Store                    // Knowledge store interface
+    enabledTeams map[string]bool   // Cached enabled team IDs (nil = all enabled)
+    
+    // Job Scheduling
+    jobOnceScheduler *cluster.JobOnceScheduler  // One-time job scheduler (debounce, backfill)
+    processingJob interface{ Close() error }    // Background worker poll-and-process job
+    
+    // Metrics & Future Extensions
+    workerMetrics WorkerMetrics    // Worker operation metrics (atomic counters)
+    summaryScheduler interface{}   // Placeholder for step 011 (channel summaries)
+    metricsCollector interface{}   // Placeholder for step 014 (Prometheus)
+}
+```
+
+### Lifecycle Methods
+
+**OnActivate()** - Initialization sequence:
+1. Create pluginapi.Client
+2. Load & validate configuration
+3. Obtain master DB handle
+4. Run schema migrations (pgvector + 7 tables)
+5. Obtain replica DB handle (fallback to master if unavailable)
+6. Create SQLStore (master + replica)
+7. Initialize CircuitBreaker (KV store backed)
+8. Initialize RateLimiter (KV store backed)
+9. Create GeminiClient
+10. Register /ask slash command
+11. Cache enabled teams set
+12. Initialize JobOnceScheduler (singleton, may reuse existing)
+13. Start processing worker with cluster.Schedule (1-second interval)
+
+**OnDeactivate()** - Graceful shutdown:
+1. Cancel all pending jobs via jobOnceScheduler
+2. Close processing worker (blocks until current item finishes)
+3. Close database via store service
+4. Log clean shutdown
+
+**OnConfigurationChange()** - Config updates:
+1. Load new configuration
+2. Validate configuration
+3. Check if Gemini client needs reinitialization (API key, models, dimensions)
+4. Reinitialize Gemini client if needed (circuit breaker/rate limiter state preserved)
+5. Store config and rebuild cached team set
+
+---
+
+## 2. Configuration Struct
+
+```go
+type configuration struct {
+    GeminiAPIKey string       // Required: Google AI API key
+    GeminiModel string        // LLM model for summarization/extraction/RAG
+    EmbeddingModel string     // Model for vector embeddings
+    EmbeddingDimensions int   // Dimensionality (must match pgvector column)
+    
+    WorkerPollMs int          // Background worker poll frequency
+    ThreadDebounceSeconds int // Inactivity threshold before summarization
+    MaxChunksPerPost int      // Max text chunks per post
+    SkipBotPosts bool         // Filter bot messages from processing
+    EnableForTeams string     // Comma-separated team IDs (empty = all)
+    DailySummaryHour int      // Hour of day (0-23) for channel summaries (step 011)
+}
+
+// Validate() - Ensures GeminiAPIKey is present
+// TeamIDSet() - Parses EnableForTeams into map for O(1) lookup
+// IsTeamEnabled(teamID) - Checks if team is enabled
+```
+
+---
+
+## 3. Store Interface & SQLStore Implementation
+
+### Top-Level Store Interface Groups Subsystems
+```go
+type Store interface {
+    Embedding() EmbeddingStore
+    Extraction() ExtractionStore
+    ThreadSummary() ThreadSummaryStore
+    ChannelSummary() ChannelSummaryStore
+    EntityMention() EntityMentionStore
+    ProcessingLog() ProcessingLogStore
+    QueryLog() QueryLogStore
+    DataRetention() DataRetentionStore
+}
+```
+
+### Key Store Methods by Domain
+
+**EmbeddingStore**
+- Save(embeddings []*Embedding) - Batch insert
+- DeleteByPostID(postID) - Hard delete
+- SoftDeleteByPostID(postID, deleteAt) - Soft delete
+- SearchByVector(vector []float32, channelIDs []string, limit int) - pgvector similarity search
+
+**ExtractionStore**
+- Save(extractions []*Extraction) - Batch insert
+- GetByID(id) - Single extraction
+- List(channelID, extractionType, offset, limit) - Paginated query
+- UpdateContent(id, content, editorUserID, updateAt) - Manual edits
+- SoftDeleteByPostID/DeleteByPostID
+
+**ThreadSummaryStore**
+- Upsert(summary *ThreadSummary) - Insert or update per RootId
+- GetByRootID(rootID) - Single thread summary
+- ListByChannelIDInWindow(channelID, windowStart, windowEnd) - Time-windowed queries
+
+**ChannelSummaryStore**
+- Save(summary *ChannelSummary) - Insert
+- GetLatest(channelID, summaryType) - Most recent
+- List(channelID, summaryType) - All summaries for channel
+
+**EntityMentionStore**
+- Save(mentions []*EntityMention) - Batch insert
+- GetEntityTimeline(entityName, channelIDs, offset, limit) - Cross-channel entity links
+- DeleteByPostID
+
+**ProcessingLogStore** - Work queue with retry logic
+- Create(entry) - Idempotent insert (skip if exists)
+- Upsert(entry) - Insert or reset existing to "pending"
+- UpdateStatus(id, status, errorMessage, completeAt) - Status transitions
+- IncrementRetry(id) - Increment retry counter
+- ListPending(limit) - Get pending items ordered by ScheduleAt
+- FindStale(thresholdMs) - Items stuck in "processing" > threshold
+- ResetStale(thresholdMs) - Reset stale items to "pending"
+- MarkCompleteByPostID(postID, completeAt) - Mark entries complete (post deletion)
+- GetStats() - Status counts
+
+**QueryLogStore** - Audit trail
+- Insert(entry) - Log query execution
+- GetStats() - Total query count and average latency
+
+**DataRetentionStore** - Batch cleanup
+- DeleteBefore(beforeTimestamp, batchSize) - Delete aged data from all tables
+
+### SQLStore Implementation
+- Uses Squirrel query builder (SQL injection safe)
+- Master DB for writes, Replica DB for reads
+- Atomic operations via KV store with SetAtomicWithRetries for state management
+
+---
+
+## 4. Gemini Client Interface & Implementation
+
+### GeminiClient Interface
+```go
+type GeminiClient interface {
+    // Embedding generation with L2 normalization
+    GenerateEmbedding(ctx, text) ([]float32, error)
+    
+    // Knowledge extraction from post/conversation
+    ExtractKnowledge(ctx, conversationText) (*ExtractionResult, error)
+    
+    // Combined thread summarization + extraction
+    SummarizeAndExtract(ctx, threadText) (*ThreadSummaryResult, error)
+    
+    // RAG answer synthesis with citations
+    SynthesizeAnswer(ctx, query, passages, conversationHistory) (*SynthesisResult, error)
+}
+```
+
+### Gemini Client Internals
+```go
+type geminiClient struct {
+    sdkClient *genai.Client         // google.golang.org/genai SDK
+    embeddingModel string            // e.g., "gemini-embedding-001"
+    llmModel string                  // e.g., "gemini-2.5-flash"
+    embeddingDimensions int
+    circuitBreaker *CircuitBreaker
+    rateLimiter *RateLimiter
+}
+```
+
+### Key Methods & Patterns
+
+**GenerateEmbedding()**
+- Checks resilience gates (circuit breaker + rate limiter)
+- 30-second timeout
+- Calls Models.EmbedContent with OutputDimensionality
+- L2-normalizes the output vector
+- Records success/failure with resilience components
+
+**ExtractKnowledge()**
+- Extracts decisions, action items, topics from conversation
+- Returns JSON with items array
+- Each item has: type, content, confidence, assignee (optional), source_post_id (optional)
+- Filters valid extraction types
+
+**SummarizeAndExtract()**
+- Combined operation for thread summarization
+- Returns summary text, key_takeaways array, and items array
+- Handles empty/unparseable responses gracefully
+
+**SynthesizeAnswer()**
+- RAG synthesis: combines query with context passages + conversation history
+- Builds system prompt emphasizing citation format [N]
+- Adds previous turns to multi-turn conversation context
+- Returns answer with inline citations
+
+### Error Handling
+- classifyError() categorizes errors: RateLimit, Retryable, NonRetryable
+- handleError() updates resilience state accordingly
+- handleSuccess() resets rate limiter and circuit breaker state
+
+### Timeouts
+- embeddingTimeout = 30 seconds
+- llmTimeout = 60 seconds (for extraction, summarization, synthesis)
+
+---
+
+## 5. Processing Worker (worker.go)
+
+### Pattern: cluster.Schedule
+```go
+processingJob, err := cluster.Schedule(
+    p.API,
+    "org_memory_processing_worker",           // Unique job name
+    cluster.MakeWaitForInterval(1*time.Second), // Poll frequency
+    p.workerCallback,                         // Callback function
+)
+```
+- Only one instance runs across the cluster at a time
+- Callback invoked on each poll cycle
+- Gracefully shutdown with Close()
+
+### Worker Metrics (Atomic Counters)
+```go
+type WorkerMetrics struct {
+    EmbedProcessed int64
+    ExtractProcessed int64
+    EmbedFailed int64
+    ExtractFailed int64
+    EmbedPermanentErrors int64
+    ExtractPermanentErrors int64
+    StaleRecovered int64
+    LastQueueDepth int64
+    TotalEmbedProcessingTimeMs int64
+    TotalExtractProcessingTimeMs int64
+}
+```
+
+### workerCallback() Main Loop
+1. Check circuit breaker (skip cycle if open)
+2. Query pending items (batch size = 10)
+3. Track queue depth metric
+4. Return immediately if empty (also check for stale recovery)
+5. Process each item sequentially
+   - Return if circuit breaker trips mid-batch
+6. Recover stale items after batch
+
+### processItem() Per-Item Flow
+1. Panic recovery (don't crash worker loop)
+2. Acquire per-post distributed mutex (2-second timeout via KV store)
+3. Transition status to "processing"
+4. Route by job type:
+   - "embed" → handleEmbedJob()
+   - "extract" → handleExtractJob()
+5. Handle result:
+   - If ErrCircuitOpen: return to pending, signal stop
+   - If other error: call handleItemFailure()
+   - If success: mark complete, update metrics
+6. Log completion
+
+### handleItemFailure() Retry Logic
+- Increment retry count
+- If forceError OR retryCount >= 3 (max retries): mark as "error" (permanent)
+- Otherwise: return to "pending" for retry
+
+### handleEmbedJob() - Vector Embedding
+1. Determine content source:
+   - Post: fetch post.Message
+   - File: fetch file text content (3 sources: FileInfo.Content, KV pre-extracted, raw bytes)
+   - Summary: fetch ThreadSummary.Summary
+2. Chunk content (MaxChunksPerPost, TargetChunkTokens, OverlapPercent)
+3. Generate embeddings for each chunk
+4. Delete previous embeddings (for reprocessing after edits)
+5. Store new embeddings
+6. Return nil on success
+
+### handleExtractJob() - Knowledge Extraction
+1. Fetch post from Mattermost
+2. Prepare conversation context:
+   - Include thread context (up to 5 recent messages before current post)
+3. Call Gemini extraction
+4. Delete previous extractions and entity mentions
+5. Store new extractions
+6. Extract named entities (person, topic)
+7. Store entity mentions
+
+### recoverStaleItems() - Detect & Recover Stuck Items
+- Find items in "processing" status > 5 minutes old
+- For each stale item:
+  - Increment retry count
+  - If >= max retries: mark as permanent error
+  - Otherwise: reset to "pending"
+  - Update metric
+
+### Helper: clusterMutex (Custom Implementation)
+- KV store atomic CAS-based mutex (instead of cluster.Mutex)
+- LockWithContext() with context deadline support
+- Refresh goroutine (7.5-second refresh, 15-second TTL)
+- Unlock() stops refresh and deletes key
+
+---
+
+## 6. Debounce Handler (debounce.go)
+
+### Pattern: JobOnceScheduler for Thread Debounce
+- Key prefix: "debounce:"
+- Scheduled via scheduleDebounce() after every message/edit in a thread
+- One-time job per thread root (cancel & reschedule on new message)
+
+### handleDebounceJob() - Thread Summarization & Extraction
+1. Parse job key/props (rootID, channelID, retryCount)
+2. Validate root post still exists
+3. Fetch full thread (PostList)
+4. Filter eligible posts (no bots, no system messages)
+5. Check thread size (skip if < 2 eligible posts)
+6. Enrich posts with usernames (cached within call)
+7. Route by thread size:
+   - < 100 posts: Direct SummarizeAndExtract() call
+   - >= 100 posts: Map-reduce approach (split into 50-post groups, summarize each, synthesize final)
+8. Handle Gemini errors: reschedule with incremented retry (max 3 retries, 60-second delay)
+9. Store thread summary
+10. Store thread extractions and entity mentions
+11. Queue unprocessed individual post embeddings (idempotent create)
+12. Create summary processing entry (source type "summary")
+13. Publish WebSocket event "thread_summary_ready"
+
+### Key Constants
+- largeThreadThreshold = 100 posts
+- mapReduceGroupSize = 50 posts per group
+- debounceMaxRetries = 3
+- debounceRetryDelaySeconds = 60
+
+### Map-Reduce for Large Threads
+1. Map phase: Summarize each group (parallel possible, currently sequential)
+2. Reduce phase: Synthesize group summaries into final summary
+3. Merge extraction items from all groups
+
+---
+
+## 7. Circuit Breaker Pattern
+
+### Implementation
+```go
+type CircuitBreaker struct {
+    kv *pluginapi.KVService  // KV store for cluster-wide state
+}
+
+type CircuitBreakerState struct {
+    State CircuitState       // closed, open, half_open
+    ConsecutiveFailures int
+    LastStateChangeAt int64  // Unix millis
+}
+```
+
+### Constants
+- circuitBreakerFailureThreshold = 5 consecutive failures
+- circuitBreakerOpenDuration = 30 seconds
+
+### State Machine
+1. **Closed** (normal): Requests pass through
+   - On failure: increment counter, open if >= 5
+   - On success: reset counter to 0
+
+2. **Open** (tripped): Reject all requests immediately (return ErrCircuitOpen)
+   - After 30 seconds: transition to half-open
+   - On success (testing): close
+   - On failure (testing): re-open
+
+3. **Half-Open** (recovery testing): Allow one request through
+   - On success: transition to closed
+   - On failure: re-open immediately
+
+### Methods
+- AllowRequest() - Check if request should proceed
+- RecordSuccess() - Reset to closed
+- RecordFailure() - Increment counter, potentially open/re-open
+- GetState() - Read current state
+
+---
+
+## 8. Rate Limiter Pattern
+
+### Implementation
+```go
+type RateLimiter struct {
+    kv *pluginapi.KVService
+}
+
+type RateLimiterState struct {
+    NextAllowedAt int64     // Unix millis until next request allowed
+    CurrentBackoffMs int64  // Current backoff duration
+}
+```
+
+### Exponential Backoff Strategy
+- Initial backoff: 1 second
+- Doubling on each consecutive 429: 1s → 2s → 4s → ... → 60s (max)
+- Jitter: ±20% to prevent thundering herd
+
+### Methods
+- AllowRequest() - Check if within backoff window (return ErrRateLimited if yes)
+- RecordRateLimit() - Double backoff, calculate NextAllowedAt with jitter
+- RecordSuccess() - Reset state (NextAllowedAt=0, CurrentBackoffMs=0)
+- GetState() - Read current state
+
+---
+
+## 9. Event Hooks (hooks.go)
+
+### MessageHasBeenPosted
+1. Eligibility check (ShouldProcessMessage)
+2. Team enablement check
+3. Create processing log entry (embed, post source type)
+4. Trigger thread debounce (scheduleDebounce)
+5. Process file attachments
+
+### MessageHasBeenUpdated
+1. Eligibility check
+2. Team enablement check
+3. Check if message content actually changed
+4. Upsert processing log (resets complete → pending)
+5. Re-trigger thread debounce
+
+### MessageHasBeenDeleted
+1. Manage debounce timers:
+   - Root post deleted: cancel debounce
+   - Reply deleted: reschedule debounce for parent thread
+2. Clean up embeddings, extractions, entity mentions
+3. Mark processing log entries as complete
+4. Clean up file-related data
+
+### FileWillBeUploaded
+1. Size guard (max 10MB)
+2. Extension guard (only supported text types)
+3. Read file content
+4. Validate UTF-8
+5. Store in KV store (10-minute TTL) for later use
+6. Never reject/modify upload
+
+### UserHasBeenDeactivated
+1. Delete all conversation sessions (multi-turn) for user
+2. Preserve all knowledge base content
+
+### dispatchScheduledJob()
+- Routes scheduled jobs by key prefix:
+  - "debounce:" → handleDebounceJob()
+  - "backfill:" → (step 017, not implemented yet)
+
+---
+
+## 10. Models.go - Data Structures
+
+### Embedding
+- PostID, ChannelID, SourceType (post/file/summary)
+- ChunkIndex, ContentSnapshot
+- Embedding ([]float32), CreateAt, DeleteAt
+
+### Extraction
+- PostID, ChannelID, ExtractionType (decision/action_item/topic)
+- Content, Metadata (JSON with assignee, confidence, source_post_id)
+- IsEdited, EditorUserID, CreateAt, UpdateAt, DeleteAt
+
+### ThreadSummary
+- RootID, ChannelID
+- Summary, KeyTakeaways (JSON array)
+- ModelVersion, LastActivityAt, UpdateAt
+
+### ChannelSummary
+- ID, ChannelID, SummaryType
+- Summary, WindowStart, WindowEnd
+- CreateAt
+
+### EntityMention
+- EntityName, EntityType (person/topic)
+- PostID, ChannelID, ExtractionID
+- CreateAt
+
+### ProcessingLogEntry
+- PostID, JobType (embed/extract), SourceType (post/file/summary)
+- Status (pending/processing/complete/error)
+- ScheduleAt, ErrorMessage, RetryCount
+- CreateAt, CompleteAt
+
+---
+
+## Key Architectural Insights
+
+1. **Cluster-Wide Resilience**: Circuit breaker and rate limiter state stored in KV store
+2. **One-Time Jobs**: Thread debounce uses JobOnceScheduler (singleton), cancel & reschedule on activity
+3. **Work Queue Pattern**: Processing log with status tracking, retries, stale recovery
+4. **Thread-Safe Config**: RWMutex protects config and team set during live updates
+5. **Graceful Degradation**: Fail-open for circuit breaker/rate limiter if KV read fails
+6. **Panic Recovery**: Both worker loop and debounce handler recover from panics
+7. **Map-Reduce for Scale**: Large threads (>100 posts) use group summarization
+8. **Source-Aware Processing**: Embeddings can be from posts, files, or summaries
+9. **Entity Linking**: Extractions create entity mentions for cross-channel search
+10. **Mutex Pattern**: Custom KV-based distributed mutex with refresh goroutine
diff --git a/agent-memories/org-memory-e2e-tests.md b/agent-memories/org-memory-e2e-tests.md
new file mode 100644
index 000000000000..acfa274d7e42
--- /dev/null
+++ b/agent-memories/org-memory-e2e-tests.md
@@ -0,0 +1,52 @@
+# Org-Memory Plugin E2E Tests
+
+## E2E Test Location
+`e2e-tests/playwright/specs/functional/plugins/org_memory/`
+
+## Test Files
+- `org_memory_installation.spec.ts` - Plugin install/activation, app bar icon visibility
+- `org_memory_commands.spec.ts` - /ask slash command, WebSocket thread summary events
+- `org_memory_rhs.spec.ts` - RHS panel open/close, query submission, loading states, citations, follow-up queries, new conversation reset
+
+## Helper Files
+- `helpers/test-setup.ts` - `setupOrgMemoryTest()`, `openOrgMemoryRhs()`, `submitQueryInRhs()`
+- `helpers/mock-org-memory-api.ts` - Route interception mocks for all plugin API endpoints
+
+## How to Run
+```bash
+cd e2e-tests/playwright
+npm install                    # Install dependencies (includes @playwright/test)
+npx playwright install         # Install browser binaries
+# Requires a running Mattermost server with org-memory plugin installed
+npx playwright test specs/functional/plugins/org_memory/ --project=chrome
+```
+
+## Prerequisites
+1. Running Mattermost server on localhost:8065 (or configured PW_BASE_URL)
+2. org-memory plugin built and installed/enabled on the server
+3. Playwright dependencies installed (`npm install` in e2e-tests/playwright/)
+4. Playwright browsers installed (`npx playwright install`)
+
+## Key Design Pattern
+All tests use Playwright's `page.route()` for API interception - no real Gemini API key needed. The `setupOrgMemoryTest()` helper handles server config, plugin activation, and page navigation. Tests that need the plugin but it's not installed will `test.skip()` gracefully.
+
+## Tags
+- `@smoke` - Installation test only
+- `@org-memory` - All org-memory tests
+
+## Selective Run Examples
+```bash
+npx playwright test --grep @org-memory --project=chrome
+npx playwright test specs/functional/plugins/org_memory/org_memory_rhs.spec.ts --project=chrome
+```
+
+## Critical Bug Found: CSRF Token Missing
+The webapp bundle (`webapp/dist/main.js`) was missing the `X-CSRF-Token` header in its `fetch()` POST requests to the plugin API. This caused Mattermost's CSRF protection to reject the requests as unauthenticated. Fixed by adding `"X-CSRF-Token": (document.cookie.match(/MMCSRF=([^;]+)/)||[])[1]||""` to the fetch headers.
+
+## Exploratory Testing Notes (2026-03-27)
+- Plugin binary only implements `/api/v1/query` POST endpoint (other spec'd routes return 404)
+- Slash command `/ask` is NOT registered by the deployed plugin binary
+- The deployed plugin tarball (`server/data/plugins/org-memory.tar.gz`) was built on Mar 24
+- Plugin source code (Go files) lives in gitignored `server/plugins/org-memory/server/` directory
+- pgvector extension must be manually installed in PostgreSQL for embeddings to work
+- Password field in Mattermost login form uses `name="password-input"` not `name="password"`
\ No newline at end of file
diff --git a/agent-memories/org-memory-gemini-client.md b/agent-memories/org-memory-gemini-client.md
new file mode 100644
index 000000000000..dadbcbf3a0c4
--- /dev/null
+++ b/agent-memories/org-memory-gemini-client.md
@@ -0,0 +1,29 @@
+# Gemini Client Implementation (Step 004)
+
+## SDK Version
+- `google.golang.org/genai v0.7.0` — the Go SDK for Google Gemini
+- Uses `genai.NewClient(ctx, &genai.ClientConfig{APIKey: key, Backend: genai.BackendGeminiAPI})`
+- Methods: `client.Models.GenerateContent()`, `client.Models.EmbedContent()`
+- Error type: `genai.APIError` (value type, not pointer) with `.Code` for HTTP status
+- JSON output: `ResponseMIMEType: "application/json"` in `GenerateContentConfig`
+- Helper: `genai.Ptr[T](val)` for optional pointer fields
+
+## Files Created
+- `gemini_types.go` — GeminiClient interface, ExtractionItem, ThreadSummaryResult, ContextPassage, SynthesisResult types
+- `gemini_client.go` — Implementation using genai SDK, l2Normalize function
+- `gemini_errors.go` — Error classification (retryable/non-retryable/rate-limit), ErrCircuitOpen, ErrRateLimited sentinels
+- `circuit_breaker.go` — 3-state circuit breaker (closed/open/half-open) with KV store persistence
+- `rate_limiter.go` — Exponential backoff (1s→60s cap, ±20% jitter) with KV store persistence
+- Test files for all components
+
+## Key Design Decisions
+- Circuit breaker state in KV key `gemini_circuit_breaker`, rate limiter in `gemini_rate_limiter`
+- Both use `pluginapi.KV.SetAtomicWithRetries` for cluster-wide consistency
+- Non-retryable errors (400, 401, 403) bypass circuit breaker entirely
+- Rate limit (429) triggers both backoff AND circuit breaker
+- Timeouts: 30s embedding, 60s LLM operations
+- `geminiClient` field on Plugin changed from `interface{}` to `GeminiClient` (typed interface)
+
+## Plugin Lifecycle Integration
+- OnActivate: creates CircuitBreaker → RateLimiter → GeminiClient (steps 8-9)
+- OnConfigurationChange: reinitializes GeminiClient if API key/model names change, preserves CB/RL instances
diff --git a/agent-memories/org-memory-plugin-build-system.md b/agent-memories/org-memory-plugin-build-system.md
new file mode 100644
index 000000000000..3473d6626fd0
--- /dev/null
+++ b/agent-memories/org-memory-plugin-build-system.md
@@ -0,0 +1,18 @@
+# Org-Memory Plugin Build System
+
+## Key Build Details
+- Plugin source lives at `server/plugins/org-memory/`
+- Go server source is in `server/plugins/org-memory/server/` with its own `go.mod`
+- **CRITICAL**: Must set `GOWORK=off` when building the plugin because the parent `server/go.work` workspace interferes. The plugin has its own separate module.
+- Go module path: `github.com/mattermost/mattermost-plugin-org-memory/server`
+- The mattermost public SDK is imported as `github.com/mattermost/mattermost/server/public`
+- Google AI SDK is imported as `google.golang.org/genai`
+- Webapp uses webpack, React/ReactDOM are externals (provided by Mattermost window globals)
+- `@mattermost/types` npm package has stale peer dep on TypeScript ^4.3 — we skip it and use inline types
+- The `make verify` target builds everything and checks all artifacts exist
+- Cross-compilation uses GOOS/GOARCH with 5 targets: darwin-amd64, darwin-arm64, linux-amd64, linux-arm64, windows-amd64
+
+## Plugin Registration
+- Webapp entry point calls `window.registerPlugin('org-memory', new OrgMemoryPlugin())`
+- Plugin class needs `initialize(registry, store)` and `uninitialize()` methods
+- Server plugin struct embeds `plugin.MattermostPlugin` and main calls `plugin.ClientMain(&Plugin{})`
diff --git a/agent-memories/org-memory-plugin-testing-patterns.md b/agent-memories/org-memory-plugin-testing-patterns.md
new file mode 100644
index 000000000000..60b80b90e1b4
--- /dev/null
+++ b/agent-memories/org-memory-plugin-testing-patterns.md
@@ -0,0 +1,39 @@
+# Org-Memory Plugin Testing Patterns
+
+## Mock API for Plugin Tests
+- Use `plugintest.API` (from `server/public/plugin/plugintest`) for mocking the plugin API
+- Use `plugintest.NewDriver(t)` for mocking the database driver
+- Use `pluginapi.NewClient(api, driver)` (NOT `plugintest.NewClient`) to create a client with mocks
+
+## LoadPluginConfiguration Mock Pattern
+The mock's `LoadPluginConfiguration` checks if the return value is `func(interface{}) error` and calls it with the dest argument:
+```go
+func mockLoadPluginConfiguration(cfg *configuration) func(dest interface{}) error {
+    return func(dest interface{}) error {
+        data, _ := json.Marshal(cfg)
+        return json.Unmarshal(data, dest)
+    }
+}
+api.On("LoadPluginConfiguration", mock.AnythingOfType("*main.configuration")).
+    Return(mockLoadPluginConfiguration(cfg))
+```
+
+## GetMasterDB Mock Pattern
+To mock `client.Store.GetMasterDB()`:
+```go
+driver.On("Conn", true).Return("conn-1", nil)
+driver.On("ConnPing", "conn-1").Return(nil)
+```
+To make it fail: `driver.On("Conn", true).Return("", fmt.Errorf("connection refused"))`
+
+## Mock Expectations Tips
+- Use `.Maybe()` for expectations that may or may not be called (e.g., `GetConfig`, `GetServerVersion`, logging)
+- `RegisterCommand` returns `error` (not `*model.AppError`) through the pluginapi layer
+- `LogInfo`, `LogError`, `LogWarn` take variadic args — mock with `mock.Anything` for each arg
+- `SetAPI(api)` and `SetDriver(driver)` are methods on `plugin.MattermostPlugin`
+
+## Key Plugin Lifecycle Facts
+- `OnConfigurationChange` is called BEFORE `OnActivate` on startup
+- During that first call, `p.client` is nil, so must use `p.API.LoadPluginConfiguration` directly
+- `pluginapi.NewClient` must be created exactly once per plugin instance in OnActivate
+- `OnDeactivate` must handle partial initialization (nil checks on all resources)
diff --git a/agent-memories/org-memory-step006-hooks.md b/agent-memories/org-memory-step006-hooks.md
new file mode 100644
index 000000000000..3b09deff8c0b
--- /dev/null
+++ b/agent-memories/org-memory-step006-hooks.md
@@ -0,0 +1,30 @@
+# Step 006: Event Ingestion Hooks - Implementation Notes
+
+## Key Implementation Details
+
+### Files Created/Modified
+- **Created:** `server/plugins/org-memory/server/hooks.go` — All 5 hook implementations + helpers
+- **Modified:** `server/plugins/org-memory/server/plugin.go` — Added scheduler fields, init/shutdown, enabled teams caching
+- **Modified:** `server/plugins/org-memory/server/store.go` — Added `MarkCompleteByPostID` to ProcessingLogStore
+- **Modified:** `server/plugins/org-memory/server/sqlstore.go` — Implemented `MarkCompleteByPostID`
+- **Modified:** Test files — Added KVList, KVDelete, LogDebug mock expectations
+
+### Important Patterns
+1. **JobOnceScheduler is a process-wide singleton** — `cluster.GetJobOnceScheduler()` returns the same instance across all calls. `Start()` fails with "already been started" on second call. OnActivate handles this gracefully by checking for "already" in the error message.
+2. **Enabled teams caching** — Team ID set is cached on the Plugin struct under `configLock` and updated in both `OnActivate` and `OnConfigurationChange`.
+3. **File entries in processing log** — File source type entries use the file ID (not post ID) as the `PostID` field to satisfy the UNIQUE constraint on `(PostId, JobType, SourceType)`.
+4. **Text extraction** — Plugin implements its own text extraction for supported text file extensions since `server/platform/services/docextractor/` is an internal server package not accessible to plugins.
+
+### Test Mock Requirements
+Tests that call `OnActivate()` need these mock expectations:
+- `api.On("KVGet", mock.Anything).Return(nil, nil).Maybe()` 
+- `api.On("KVSetWithOptions", mock.Anything, mock.Anything, mock.Anything).Return(true, nil).Maybe()`
+- `api.On("KVList", mock.Anything, mock.Anything).Return(nil, nil).Maybe()`
+- `api.On("KVDelete", mock.Anything).Return(nil).Maybe()`
+- `api.On("LogDebug", mock.Anything, mock.Anything, mock.Anything).Maybe()`
+
+### Build Command
+```bash
+cd server/plugins/org-memory/server && GOWORK=off go build ./...
+cd server/plugins/org-memory/server && GOWORK=off go test -count=1 -short ./...
+```
\ No newline at end of file
diff --git a/agent-memories/org-memory-step007-worker.md b/agent-memories/org-memory-step007-worker.md
new file mode 100644
index 000000000000..268ddc686e69
--- /dev/null
+++ b/agent-memories/org-memory-step007-worker.md
@@ -0,0 +1,43 @@
+# Step 007: Processing Worker Implementation Notes
+
+## Key Files
+- `server/worker.go` — Processing worker implementation (workerCallback, processItem, handleEmbedJob, handleExtractJob, recoverStaleItems)
+- `server/worker_test.go` — Comprehensive tests for the worker
+
+## Architecture
+- Worker is scheduled via `cluster.Schedule` with 1-second interval in `OnActivate`
+- `Plugin.processingJob` (type `interface{ Close() error }`) holds the scheduled job
+- `Plugin.workerMetrics` (type `WorkerMetrics`) tracks atomic counters for processing stats
+- Worker uses `clusterMutex` (custom per-post distributed mutex using KV store) with 2-second timeout
+
+## Important Test Patterns
+
+### Variadic Logging Mocks
+The worker uses `p.client.Log.Debug/Info/Warn/Error()` with structured key-value pairs, producing variadic calls with 1 to 13+ arguments through the plugintest.API mock. Standard 3-arg mock expectations fail.
+
+**Solution**: `setupVariadicLogMocks(api *plugintest.API)` registers mock expectations for argument counts 1 through 15 for all 4 log levels. Defined in `worker_test.go` but accessible across all test files in the package.
+
+### Background Worker Goroutine in Tests
+`cluster.Schedule` starts a background goroutine that calls `workerCallback()`. In tests that call `OnActivate`, this goroutine may fire and call `ConnQuery` on the mock driver.
+
+**Solution**: 
+1. `mockDriverForMigrations(driver)` adds `ConnQuery` mock returning `("", error)` and `ConnClose` mock
+2. Tests that bypass `mockDriverForMigrations` must add their own `ConnQuery` mock
+3. `ConnQuery` returns `(string, error)` not `(plugin.ResultContainer, error)` — returning an error prevents the need to mock full Rows lifecycle
+
+### Test Cleanup
+Tests with successful `OnActivate` should defer `p.processingJob.Close()` to stop the background goroutine.
+
+## Build Command
+Always use `GOWORK=off` when building/testing the plugin:
+```
+cd server/plugins/org-memory/server && GOWORK=off go test -count=1 -short ./...
+```
+
+## Constants
+- `workerBatchSize = 10`
+- `workerMaxRetries = 3`
+- `workerStaleThresholdMs = 300000` (5 minutes)
+- `workerMutexTimeout = 2 * time.Second`
+- `workerMutexPrefix = "org_memory_post_lock_"`
+- `workerThreadContextLimit = 10`
diff --git a/agent-memories/org-memory-step008-debounce.md b/agent-memories/org-memory-step008-debounce.md
new file mode 100644
index 000000000000..00f69c82903f
--- /dev/null
+++ b/agent-memories/org-memory-step008-debounce.md
@@ -0,0 +1,21 @@
+# Step 008: Thread Debounce and Summarization - Implementation Notes
+
+## Files Created/Modified
+- **Created:** `server/plugins/org-memory/server/debounce.go` — Full debounce handler: parseProps, filterThreadPosts, enrichPostsWithUsernames, buildThreadConversationText, summarizeLargeThread (map-reduce), storeThreadSummary, storeThreadExtractions, queueUnprocessedPostEmbeddings, createSummaryProcessingEntry, handleDebounceGeminiError, publishThreadSummaryEvent
+- **Created:** `server/plugins/org-memory/server/debounce_test.go` — 30+ tests covering all paths
+- **Modified:** `server/plugins/org-memory/server/hooks.go` — Removed placeholder `handleDebounceJob`; it's now in debounce.go
+- **Modified:** `server/plugins/org-memory/server/worker.go` — Added "summary" source type to `handleEmbedJob` switch statement. Loads summary text from ThreadSummaryStore for embedding.
+
+## Key Design Decisions
+1. **Separate file** — All debounce logic in `debounce.go` to keep hooks.go clean. The `handleDebounceJob` method is called from `dispatchScheduledJob` in hooks.go.
+2. **Props parsing** — Props arrive as `map[string]string` when first scheduled but `map[string]interface{}` after KV deserialization. The parser handles both.
+3. **Retry via rescheduling** — On Gemini failure, the job is rescheduled (not retried inline) using the same `JobOnceScheduler.ScheduleOnce`. Retry count is tracked in props.
+4. **Map-reduce for large threads** — Threads >100 messages are split into groups of 50, each summarized separately, then group summaries synthesized into a final result. Extraction items from all groups are merged.
+5. **Summary embedding** — A processing log entry with `SourceType="summary"` is created. The worker's `handleEmbedJob` loads the summary from `ThreadSummaryStore.GetByRootID()`.
+6. **WebSocket event** — Event name `thread_summary_ready` is passed to `PublishWebSocketEvent`. Plugin API auto-prefixes it to `custom_org-memory_thread_summary_ready`.
+
+## Build & Test
+```bash
+cd server/plugins/org-memory/server && GOWORK=off go build ./...
+cd server/plugins/org-memory/server && GOWORK=off go test -count=1 -short ./...
+```
\ No newline at end of file
diff --git a/agent-memories/org-memory-step009-rag-engine.md b/agent-memories/org-memory-step009-rag-engine.md
new file mode 100644
index 000000000000..dc1a1494d9c8
--- /dev/null
+++ b/agent-memories/org-memory-step009-rag-engine.md
@@ -0,0 +1,25 @@
+# Step 009: RAG Query Engine
+
+## Key Files
+- `server/plugins/org-memory/server/rag_engine.go` — RAG engine implementation
+- `server/plugins/org-memory/server/rag_engine_test.go` — 34 unit tests
+
+## Architecture
+- `RAGEngine` interface with `Query()` and `FollowUp()` operations — mockable for step 010
+- `ragEngine` struct holds `plugin.API` (raw API for GetPost/GetUser/etc), `pluginapi.Client` (for KV/Log), `Store`, and `GeminiClient`
+- Constructor: `NewRAGEngine(pluginAPI plugin.API, client *pluginapi.Client, store Store, geminiClient GeminiClient)`
+
+## Key Design Decisions
+- Uses `plugin.API` directly for Mattermost CRUD (GetPost, GetUser, GetTeamsForUser, etc.) — NOT `pluginapi.Client` which doesn't expose these
+- Uses `pluginapi.Client` for KV store (`client.KV.Get/Set`) and logging (`client.Log`)
+- KV Set with TTL: `client.KV.Set(key, value, pluginapi.SetExpiry(duration))` — returns `(bool, error)`
+- Permission cache key: `perms:{userId}` with 60s TTL
+- Session key: `session:{userId}:{sessionId}` with 30min TTL
+- Citation formatting uses regex `\[(\d+)\]` to replace markers with `[N](permalink)` markdown links
+- Uses `model.PermissionReadChannelContent` (NOT `PermissionReadChannel`) — per spec requirement for content-level permission check
+
+## Gotchas
+- `pluginapi.KVService` has no `SetWithExpiry` method — use `Set()` with `pluginapi.SetExpiry()` option
+- `pluginapi.Client` has no `API` field — must pass `plugin.API` separately
+- Test helper `removeExpectedCallByMethod` is defined in `worker_test.go` and shared across test files — don't redefine it
+- `model.PermissionReadChannelContent` is the correct permission constant (NOT `PermissionReadChannel`) — the spec explicitly requires content-level permission
diff --git a/agent-memories/org-memory-step010-http-api.md b/agent-memories/org-memory-step010-http-api.md
new file mode 100644
index 000000000000..9257822bfac8
--- /dev/null
+++ b/agent-memories/org-memory-step010-http-api.md
@@ -0,0 +1,30 @@
+# Step 010: HTTP API Router and Slash Command Handler
+
+## Files Created
+- `server/plugins/org-memory/server/api.go` — Main HTTP API implementation
+- `server/plugins/org-memory/server/api_test.go` — Comprehensive test suite
+
+## Files Modified
+- `server/plugins/org-memory/server/plugin.go` — Updated /ask command registration
+
+## Key Patterns
+- Plugin source lives in `server/plugins/org-memory/server/` (not the root)
+- Go module: `github.com/mattermost/mattermost-plugin-org-memory/server`
+- Must use `GOWORK=off` when running `go test` or `go vet` due to parent go.work
+- Mock store, Gemini client, and variadic log mocks are defined in `worker_test.go`
+- Tests use `plugintest.API`, `plugintest.NewDriver(t)`, and `pluginapi.NewClient()`
+- Plugin HTTP handlers receive paths with `/plugins/{plugin_id}` already stripped
+
+## API Structure
+- 13 endpoints under `/api/v1/`
+- Authentication via `Mattermost-User-Id` header (set by server after session validation)
+- Admin endpoints check `HasPermissionTo(userId, PermissionManageSystem)`
+- Channel endpoints check `HasPermissionToChannel(userId, channelId, PermissionReadChannelContent)`
+- KV store used for: webhook configs (prefix `webhook:`), backfill progress (prefix `backfill_progress:`)
+- RAG engine created per-request via `NewRAGEngine(p.API, p.client, p.store, p.geminiClient)`
+
+## Test Patterns
+- `setupAPITestPlugin()` creates a Plugin with all mocked dependencies
+- `executeHTTPRequest()` builds and executes httptest requests through ServeHTTP
+- `filterExpectedCalls()` helper to re-mock specific KVGet calls for different test scenarios
+- All mock stores reused from `worker_test.go` (same package `main`)
diff --git a/agent-memories/org-memory-step011-channel-summary-worker.md b/agent-memories/org-memory-step011-channel-summary-worker.md
new file mode 100644
index 000000000000..2d36da5c1b5c
--- /dev/null
+++ b/agent-memories/org-memory-step011-channel-summary-worker.md
@@ -0,0 +1,40 @@
+# Step 011: Channel Summary Worker
+
+## What was built
+- **channel_summary_worker.go** — Daily and weekly channel summary generation workers
+- Daily worker: custom `makeWaitForDailySummaryHour()` targeting configured hour (default 8 AM)
+- Weekly worker: `MakeWaitForRoundedInterval(168 * time.Hour)`
+- Both use `cluster.Schedule` for single-node execution
+
+## Key patterns
+- `cluster.NextWaitInterval` signature: `func(now time.Time, metadata cluster.JobMetadata) time.Duration`
+- `cluster.JobMetadata` has `LastFinished time.Time` — check `.IsZero()` for first run
+- First run fires immediately by returning `time.Duration(0)` when `LastFinished.IsZero()`
+- `channelSummaryJobs` struct holds both `*cluster.Job` handles with `Close()` method
+
+## Hierarchical summarization
+- Daily: thread summaries + extractions → channel daily summary
+- Weekly: daily summaries → channel weekly summary
+- Source material is assembled as structured text with thread citations `[Thread: post_id]`
+
+## Store methods added
+- `ThreadSummaryStore.ListActiveChannelIDsInWindow` — finds channels with activity
+- `ExtractionStore.ListByChannelIDInWindow` — gets extractions for a channel+window
+- `ChannelSummaryStore.ListByChannelAndTypeInWindow` — gets daily summaries for weekly rollup
+- `ChannelSummaryStore.ListActiveChannelIDsByTypeInWindow` — finds channels with daily summaries
+
+## GeminiClient addition
+- `SynthesizeChannelSummary(ctx, sourceText, channelName, summaryType string) (string, error)`
+- Uses temperature 0.2, llmTimeout (60s), topic-organized system prompt
+
+## Gotchas
+- `getChannelDisplayName` already existed in api.go — created `getChannelNameForSummary` wrapper to avoid duplicate method declaration
+- Duplicate key errors (PostgreSQL 23505) handled gracefully — `isDuplicateKeyError()` helper
+- Processing log entry uses generated summary ID as PostID so embedding worker can find it
+- WebSocket events: `p.API.PublishWebSocketEvent` auto-prepends `custom_` prefix, so pass `org-memory_channel_summary_ready`
+- Build requires `GOWORK=off` due to parent `server/go.work`
+
+## Build & test
+- `cd server/plugins/org-memory && GOWORK=off go build ./...`
+- `cd server/plugins/org-memory && GOWORK=off go test ./...`
+- `make verify` — cross-platform build for all 5 targets
\ No newline at end of file
diff --git a/agent-memories/org-memory-step012-webhook-dispatcher.md b/agent-memories/org-memory-step012-webhook-dispatcher.md
new file mode 100644
index 000000000000..32cd61975df1
--- /dev/null
+++ b/agent-memories/org-memory-step012-webhook-dispatcher.md
@@ -0,0 +1,44 @@
+# Step 012: Outbound Webhook Dispatcher
+
+## Files Created/Modified
+- **server/webhook.go** (NEW) — Core webhook dispatcher with:
+  - `WebhookDispatcher` struct with pluginapi client, HTTP client, and failed delivery tracking (sync.Map)
+  - `WebhookPayload`, `WebhookExtractionItem`, `WebhookMetadata` types
+  - `ExtractionEvent` type (input from worker/debounce)
+  - CRUD: `CreateWebhook`, `ListWebhooks`, `GetWebhookByID`, `DeleteWebhook`, `FindWebhooksByChannel`
+  - `DispatchWebhooks` — groups by channel, finds matching webhooks, filters by type, dispatches concurrently
+  - `deliverToWebhook` — sends HTTP POST with retries (1s, 2s, 4s backoff), 30s timeout
+  - `computeHMACSignature` — HMAC-SHA256 hex-encoded
+  - `sendHTTPPost` — HTTP POST with Content-Type JSON, optional HMAC header, response size limit
+  - `recordFailure`, `GetFailedDeliveryCount`, `GetTotalFailedDeliveries` — in-memory atomic counters
+  - `redactURL` — removes query params for safe logging
+
+- **server/webhook_test.go** (NEW) — 40 tests covering HMAC, CRUD, dispatch, retries, concurrency, payloads, failure tracking
+
+- **server/api.go** (MODIFIED):
+  - Added `CreatedBy` field to `webhookConfig` struct
+  - Updated `handleWebhookCreate` to use dispatcher when available, sets CreatedBy
+
+- **server/plugin.go** (MODIFIED):
+  - Added `webhookDispatcher *WebhookDispatcher` field to Plugin struct
+  - Initialize in OnActivate step 15
+
+- **server/worker.go** (MODIFIED):
+  - Added webhook dispatch after `handleExtractJob` stores extractions (fire-and-forget)
+
+- **server/debounce.go** (MODIFIED):
+  - Added webhook dispatch after `storeThreadExtractions` stores thread-level extractions
+
+## Key Design Decisions
+- Dispatcher is a separate struct (not embedded in Plugin) for testability
+- Uses sync.Map for thread-safe failed delivery counters
+- HTTP client configured with 30s timeout and no redirect following
+- KV store prefix `webhook:{channelId}:{webhookId}` for channel-scoped lookups
+- Retries: 4 total attempts (1 original + 3 retries) with exponential backoff
+- Dispatches concurrently to multiple webhooks using sync.WaitGroup
+- Empty extraction list returns immediately (no KV lookups)
+- Delivery failures don't affect processing log status
+
+## Build/Test
+- `GOWORK=off go build .` — compiles clean
+- `GOWORK=off go test -count=1 -short .` — all tests pass (including 40 new webhook tests)
diff --git a/agent-memories/org-memory-step013-data-retention.md b/agent-memories/org-memory-step013-data-retention.md
new file mode 100644
index 000000000000..ec8065facb3b
--- /dev/null
+++ b/agent-memories/org-memory-step013-data-retention.md
@@ -0,0 +1,33 @@
+# Step 013: Data Retention and Lifecycle Cleanup
+
+## What Was Implemented
+- `RunDataRetention(nowTime, batchSize int64) (int64, error)` hook on the Plugin struct
+- 7 new `DataRetentionStore` interface methods (replaced the old `DeleteBefore` method)
+- Batch budget distribution algorithm that proportionally allocates across 7 cleanup operations with rollover
+
+## DataRetentionStore Interface Methods
+1. `DeleteOrphanedEmbeddings(limit int)` - LEFT JOIN Posts, WHERE p.Id IS NULL
+2. `DeleteOrphanedExtractions(limit int)` - Same pattern
+3. `DeleteOrphanedEntityMentions(limit int)` - Same pattern
+4. `DeleteOrphanedThreadSummaries(limit int)` - Uses RootId instead of Id as PK
+5. `DeleteAgedChannelSummaries(dailyCutoff, weeklyCutoff int64, limit int)` - Daily >90d, Weekly >365d by WindowEnd
+6. `DeleteCompletedProcessingLogs(cutoff int64, limit int)` - Only "complete"/"error" status, >30d
+7. `DeleteAgedQueryLogs(cutoff int64, limit int)` - All entries >90d
+
+## Key Design Decisions
+- **Batch budget distribution**: `remaining / opsLeft` gives proportional allocation with rollover
+- **Orphan detection via LEFT JOIN**: `LEFT JOIN Posts p ON e.PostId = p.Id WHERE p.Id IS NULL`
+- **Subquery batch pattern**: `DELETE FROM table WHERE Id IN (SELECT Id FROM table WHERE cond LIMIT $1)`
+- **Retention constants are compile-time**: Not user-configurable (90d daily, 365d weekly, 30d processing, 90d query)
+
+## Files Modified
+- `store.go` - Replaced DataRetentionStore interface (7 methods instead of 1)
+- `sqlstore.go` - Replaced implementation section with 7 new methods
+- `hooks.go` - Added RunDataRetention hook + retention constants
+- `worker_test.go` - Updated mockDataRetentionStore to match new interface
+- `data_retention_test.go` - New test file with 25 tests
+
+## Build/Test
+- `GOWORK=off go vet .` and `GOWORK=off go build .` from `/server/plugins/org-memory/server/`
+- `GOWORK=off go test -count=1 .` runs all tests
+- go.work is at `/server/go.work` which doesn't include the plugin, so GOWORK=off is required
diff --git a/agent-memories/org-memory-step014-metrics.md b/agent-memories/org-memory-step014-metrics.md
new file mode 100644
index 000000000000..ffa9dd8a1e76
--- /dev/null
+++ b/agent-memories/org-memory-step014-metrics.md
@@ -0,0 +1,47 @@
+# Step 014: Metrics and Observability
+
+## What was built
+- `metrics.go` — Prometheus metrics collector with interface, no-op impl, and concrete impl
+- `metrics_test.go` — Comprehensive test suite for all metrics methods
+
+## Key design decisions
+- **Isolated registry**: Uses `prometheus.NewRegistry()` (not the global default) to avoid collisions
+- **Namespace**: All metrics use `org_memory` namespace, producing names like `org_memory_processing_items_total`
+- **Interface-based**: `MetricsCollector` interface enables no-op fallback and testing
+- **GaugeFunc for live queries**: Queue depth, stale items, total embeddings use GaugeFunc callbacks that query the replica DB at scrape time
+- **GaugeFunc safety**: All callbacks handle nil DB and errors gracefully (return 0)
+- **Thread-safe circuit breaker state**: Uses `atomic.Int32` for concurrent access
+
+## Important: Column name in GaugeFunc
+The `ai_processing_log` table does NOT have a `StartedAt` column. The stale items callback uses `CreateAt` to detect stale items, matching the `FindStale` store method. Table columns: Id, PostId, JobType, SourceType, Status, ScheduleAt, ErrorMessage, RetryCount, CreateAt, CompleteAt.
+
+## Circuit breaker state mapping
+- CircuitClosed → 0
+- CircuitHalfOpen → 1  
+- CircuitOpen → 2
+Helper: `circuitStateToInt()` converts `CircuitState` string to int.
+
+## Metrics inventory
+- **Processing**: items_total (CounterVec), errors_total (CounterVec), duration_seconds (HistogramVec), queue_depth (GaugeFunc), stale_items (GaugeFunc), items_ingested_total (Counter)
+- **Gemini**: requests_total (CounterVec: operation, status), request_duration_seconds (HistogramVec), rate_limit_hits_total (Counter), circuit_breaker_state (Gauge)
+- **RAG**: queries_total (CounterVec: type), query_duration_seconds (Histogram), search_results (Histogram), permission_cache_total (CounterVec), session_total (CounterVec), no_results_total (Counter)
+- **Embedding**: generated_total (Counter), chunks_per_post (Histogram), total_stored (GaugeFunc)
+- **Summary**: generated_total (CounterVec: type), channels_skipped_total (Counter), batch_duration_seconds (Histogram)
+- **Webhook**: deliveries_total (CounterVec: status), delivery_duration_seconds (Histogram)
+- **Retention**: rows_deleted_total (CounterVec: table)
+
+## How to build
+```bash
+cd server/plugins/org-memory/server
+GOWORK=off go build ./...
+GOWORK=off go test ./...
+```
+
+## Plugin struct changes
+- `metricsCollector` field: `MetricsCollector` interface (was `interface{}`)
+- `metricsHandler http.Handler` field for ServeMetrics hook reuse
+- OnActivate step 16 initializes metrics, falls back to no-op on failure
+- `ServeMetrics` hook delegates to stored handler
+
+## prometheus dependency
+Added `github.com/prometheus/client_golang` (v1.23.2) to go.mod.
\ No newline at end of file
diff --git a/agent-memories/org-memory-step017-backfill.md b/agent-memories/org-memory-step017-backfill.md
new file mode 100644
index 000000000000..3ae8cd97d2bd
--- /dev/null
+++ b/agent-memories/org-memory-step017-backfill.md
@@ -0,0 +1,34 @@
+# Step 017: Historical Backfill System
+
+## Files
+- `server/backfill.go` — Core backfill handler, post fetching, thread tracking, progress estimation
+- `server/api.go` — backfillRequest/backfillProgress types, start/pause/resume handlers, admin status enrichment
+- `server/hooks.go` — dispatchScheduledJob routes `backfill:` prefix to handleBackfillJob
+- `server/metrics.go` — 4 backfill metrics (batches_processed, posts_scanned, posts_queued, duration)
+
+## Architecture
+- Backfill does NOT call Gemini — only creates processing log entries for the existing worker (step 007)
+- Uses `JobOnceScheduler` with `backfill:{channelId}` key prefix for batch scheduling
+- Compound cursor `(CreateAt, PostId)` for deterministic resumable pagination
+- Initial batch uses `GetPostsSince`, subsequent batches use `GetPostsAfter`
+- Thread roots tracked in separate KV key `backfill_threads:{channelId}`
+- Progress persisted in KV under `backfill_progress:{channelId}`
+
+## Key Constants
+- Default batch size: 100
+- Default delay: 500ms
+- Max consecutive errors before stopping: 10
+- Retry delay: 5000ms
+
+## Gotchas
+- `JobOnceScheduler` is a process-wide singleton (`sync.Once`) — test setup must handle this
+- Pause race condition: batch handler re-checks KV status before saving to avoid overwriting admin's pause
+- Nil scheduler check must happen before storing any state to avoid stuck "running" backfills
+- `GOWORK=off` required for building due to workspace configuration
+
+## Build & Test
+```bash
+cd server/plugins/org-memory/server
+GOWORK=off go build ./...
+GOWORK=off go test ./...
+```
\ No newline at end of file
diff --git a/agent-memories/org-memory-step018-testing.md b/agent-memories/org-memory-step018-testing.md
new file mode 100644
index 000000000000..19b0cef9ef74
--- /dev/null
+++ b/agent-memories/org-memory-step018-testing.md
@@ -0,0 +1,38 @@
+# Step 018 - Server-side Integration Tests
+
+## Plugin Module Location
+- Module: `github.com/mattermost/mattermost-plugin-org-memory/server`
+- go.mod: `/Users/pasivuorio/modernpath/mattermost/server/plugins/org-memory/server/go.mod`
+- Must use `GOWORK=off` when running go commands because the server's go.work doesn't include this plugin module
+
+## Build & Test Commands
+```bash
+cd /Users/pasivuorio/modernpath/mattermost/server/plugins/org-memory/server
+GOWORK=off go test -v -count=1 -timeout 120s .           # Run all unit tests
+GOWORK=off go test -v -count=1 -tags integration .        # Run integration tests (needs DB)
+GOWORK=off go vet .                                        # Lint check
+```
+
+## Key Pattern: pluginapi KV.Set() calls api.KVSetWithOptions()
+The `p.client.KV.Set(key, value)` method (from `pluginapi`) internally calls `api.KVSetWithOptions(key, valueBytes, model.PluginKVSetOptions{})`. So when asserting KV writes in tests, always use:
+```go
+api.AssertCalled(t, "KVSetWithOptions", key, value, mock.Anything)
+```
+NOT `api.AssertCalled(t, "KVSet", ...)`.
+
+Similarly, `p.client.KV.Get(key, &value)` internally calls `api.KVGet(key)`.
+
+## Test Files Created (Step 018)
+- `testhelper_test.go` (314 lines) - TestHelper struct, 9 factory methods, 4 vector helpers
+- `hooks_test.go` (1200 lines) - 42 tests for all 5 event hooks
+- `channel_summary_worker_test.go` (845 lines) - 41 tests for daily/weekly summary workers
+- `backfill_test.go` (1262 lines) - 44 tests for historical backfill system
+- `integration_test.go` (788 lines) - 11 integration tests gated by `//go:build integration`
+
+## Pre-existing Test Files (16 files, ~9,334 lines)
+worker_test.go, api_test.go, plugin_test.go, configuration_test.go, debounce_test.go, 
+rag_engine_test.go, webhook_test.go, chunker_test.go, circuit_breaker_test.go, 
+rate_limiter_test.go, gemini_client_test.go, gemini_errors_test.go, 
+gemini_integration_test.go, metrics_test.go, store_test.go, data_retention_test.go
+
+## Total: 451 passing tests across 21 test files
\ No newline at end of file
diff --git a/docs/screenshots/csrf-fix-auth-works.png b/docs/screenshots/csrf-fix-auth-works.png
new file mode 100644
index 000000000000..ea20507c57d0
Binary files /dev/null and b/docs/screenshots/csrf-fix-auth-works.png differ
diff --git a/docs/screenshots/plugin-config-system-console.png b/docs/screenshots/plugin-config-system-console.png
new file mode 100644
index 000000000000..ecd39a080808
Binary files /dev/null and b/docs/screenshots/plugin-config-system-console.png differ
diff --git a/e2e-tests/playwright/specs/functional/plugins/org_memory/helpers/mock-org-memory-api.ts b/e2e-tests/playwright/specs/functional/plugins/org_memory/helpers/mock-org-memory-api.ts
new file mode 100644
index 000000000000..6d5388849fe2
--- /dev/null
+++ b/e2e-tests/playwright/specs/functional/plugins/org_memory/helpers/mock-org-memory-api.ts
@@ -0,0 +1,271 @@
+// Shared route interception helpers for the org-memory plugin E2E tests.
+// Provides reusable functions for mocking the plugin's API endpoints
+// using Playwright's page.route() API, eliminating dependency on
+// a real Gemini API key or server-side processing.
+
+import type {Page} from '@playwright/test';
+
+// -- Route URL patterns --
+
+const QUERY_ENDPOINT = '**/plugins/org-memory/api/v1/query';
+const FOLLOWUP_ENDPOINT = '**/plugins/org-memory/api/v1/query/followup';
+const THREAD_SUMMARY_GLOB = '**/plugins/org-memory/api/v1/threads/*/summary';
+const COMMANDS_ENDPOINT = '**/api/v4/commands/execute';
+
+// -- Default response factories --
+
+/**
+ * Default mock response for a query — includes answer, citations, and session.
+ */
+export function defaultQueryResponse(overrides: Record<string, any> = {}) {
+    return {
+        answer: 'Based on the workspace conversations, the API was redesigned in Q3 to use REST endpoints with OpenAPI documentation [1]. The team agreed on versioned endpoints [2].',
+        citations: [
+            {
+                ref_number: 1,
+                post_id: 'mock-post-1',
+                permalink: '/test-team/pl/mock-post-1',
+                channel_name: 'engineering',
+                author: 'alice',
+                snippet: 'We decided to redesign the API using REST.',
+            },
+            {
+                ref_number: 2,
+                post_id: 'mock-post-2',
+                permalink: '/test-team/pl/mock-post-2',
+                channel_name: 'architecture',
+                author: 'bob',
+                snippet: 'Versioned endpoints are the way to go.',
+            },
+        ],
+        session_id: 'mock-session-001',
+        ...overrides,
+    };
+}
+
+/**
+ * Default mock response for a follow-up query.
+ */
+export function defaultFollowUpResponse(overrides: Record<string, any> = {}) {
+    return {
+        answer: 'The REST API redesign was completed in October. The main changes included switching from GraphQL to REST, adding OpenAPI specs, and implementing versioned endpoints [1].',
+        citations: [
+            {
+                ref_number: 1,
+                post_id: 'mock-post-3',
+                permalink: '/test-team/pl/mock-post-3',
+                channel_name: 'engineering',
+                author: 'charlie',
+                snippet: 'Migration from GraphQL completed.',
+            },
+        ],
+        session_id: 'mock-session-001',
+        ...overrides,
+    };
+}
+
+/**
+ * Default mock thread summary response.
+ */
+export function defaultThreadSummaryResponse(rootId: string, overrides: Record<string, any> = {}) {
+    return {
+        root_id: rootId,
+        channel_id: 'mock-channel-1',
+        summary: 'The team discussed deployment strategy and agreed on blue-green deployments.',
+        key_takeaways: [
+            'Blue-green deployment was chosen',
+            'Rollback plan documented',
+        ],
+        extractions: [
+            {type: 'decision', content: 'Use blue-green deployment', confidence: 0.95},
+            {type: 'action_item', content: 'Document rollback procedures', confidence: 0.88},
+        ],
+        post_count: 12,
+        generated_at: new Date().toISOString(),
+        ...overrides,
+    };
+}
+
+// -- Internal helpers --
+
+/**
+ * Generic route interceptor: filters by HTTP method, applies optional delay,
+ * and fulfills with a JSON response body. Extracted to eliminate duplication
+ * across the individual mock functions.
+ */
+async function interceptJsonRoute(
+    page: Page,
+    urlPattern: string,
+    method: string,
+    body: Record<string, any>,
+    delay?: number,
+): Promise<void> {
+    await page.route(urlPattern, async (route) => {
+        if (route.request().method() !== method) {
+            await route.fallback();
+            return;
+        }
+
+        if (delay) {
+            await new Promise((resolve) => setTimeout(resolve, delay));
+        }
+
+        await route.fulfill({
+            status: 200,
+            contentType: 'application/json',
+            body: JSON.stringify(body),
+        });
+    });
+}
+
+// -- Public mock functions --
+
+/**
+ * Intercept the query endpoint and return a mock response.
+ *
+ * @param page - Playwright page instance
+ * @param response - The mock response to return (defaults to defaultQueryResponse)
+ * @param delay - Optional delay in ms before fulfilling (useful for testing loading states)
+ */
+export async function mockQueryResponse(
+    page: Page,
+    response?: Record<string, any>,
+    delay?: number,
+): Promise<void> {
+    await interceptJsonRoute(page, QUERY_ENDPOINT, 'POST', response || defaultQueryResponse(), delay);
+}
+
+/**
+ * Intercept the follow-up query endpoint and return a mock response.
+ *
+ * @param page - Playwright page instance
+ * @param response - The mock response to return (defaults to defaultFollowUpResponse)
+ * @param delay - Optional delay in ms before fulfilling
+ */
+export async function mockFollowupResponse(
+    page: Page,
+    response?: Record<string, any>,
+    delay?: number,
+): Promise<void> {
+    await interceptJsonRoute(page, FOLLOWUP_ENDPOINT, 'POST', response || defaultFollowUpResponse(), delay);
+}
+
+/**
+ * Intercept the thread summary endpoint for a specific root ID and return a mock response.
+ *
+ * @param page - Playwright page instance
+ * @param rootId - The root post ID to match in the URL
+ * @param summary - Optional custom summary response
+ */
+export async function mockThreadSummary(
+    page: Page,
+    rootId: string,
+    summary?: Record<string, any>,
+): Promise<void> {
+    await interceptJsonRoute(
+        page,
+        `**/plugins/org-memory/api/v1/threads/${rootId}/summary`,
+        'GET',
+        summary || defaultThreadSummaryResponse(rootId),
+    );
+}
+
+/**
+ * Intercept the query endpoint with a controlled promise that allows
+ * the test to observe loading state before resolving.
+ *
+ * @param page - Playwright page instance
+ * @param response - The mock response to return when resolved
+ * @returns An object with `resolve` and `reject` functions to control fulfillment
+ */
+export async function mockQueryResponseDeferred(
+    page: Page,
+    response?: Record<string, any>,
+): Promise<{resolve: () => void; reject: (error: string) => void}> {
+    const body = response || defaultQueryResponse();
+    let resolvePromise: () => void;
+    let rejectPromise: (error: string) => void;
+
+    const deferredPromise = new Promise<void>((resolve, reject) => {
+        resolvePromise = resolve;
+        rejectPromise = (error: string) => reject(new Error(error));
+    });
+
+    await page.route(QUERY_ENDPOINT, async (route) => {
+        if (route.request().method() !== 'POST') {
+            await route.fallback();
+            return;
+        }
+
+        try {
+            await deferredPromise;
+            await route.fulfill({
+                status: 200,
+                contentType: 'application/json',
+                body: JSON.stringify(body),
+            });
+        } catch {
+            await route.fulfill({
+                status: 500,
+                contentType: 'application/json',
+                body: JSON.stringify({error: 'Internal Server Error'}),
+            });
+        }
+    });
+
+    return {
+        resolve: resolvePromise!,
+        reject: rejectPromise!,
+    };
+}
+
+/**
+ * Intercept slash command execution and return a mock ephemeral response.
+ * Only intercepts POST commands starting with '/ask'; all other commands fall through.
+ *
+ * @param page - Playwright page instance
+ * @param responseText - The text to include in the ephemeral response
+ */
+export async function mockSlashCommandResponse(
+    page: Page,
+    responseText?: string,
+): Promise<void> {
+    const text = responseText || 'Based on workspace conversations, the API decisions include REST endpoints and versioned APIs. [1](/test-team/pl/mock-post-1)';
+
+    await page.route(COMMANDS_ENDPOINT, async (route) => {
+        const request = route.request();
+        if (request.method() !== 'POST') {
+            await route.fallback();
+            return;
+        }
+
+        try {
+            const postData = request.postDataJSON();
+            if (postData?.command?.startsWith('/ask')) {
+                await route.fulfill({
+                    status: 200,
+                    contentType: 'application/json',
+                    body: JSON.stringify({
+                        response_type: 'ephemeral',
+                        text,
+                    }),
+                });
+                return;
+            }
+        } catch {
+            // Not our command, fall through
+        }
+
+        await route.fallback();
+    });
+}
+
+/**
+ * Remove all org-memory API route interceptors.
+ */
+export async function unmockAllRoutes(page: Page): Promise<void> {
+    await page.unroute(QUERY_ENDPOINT);
+    await page.unroute(FOLLOWUP_ENDPOINT);
+    await page.unroute(THREAD_SUMMARY_GLOB);
+    await page.unroute(COMMANDS_ENDPOINT);
+}
diff --git a/e2e-tests/playwright/specs/functional/plugins/org_memory/helpers/test-setup.ts b/e2e-tests/playwright/specs/functional/plugins/org_memory/helpers/test-setup.ts
new file mode 100644
index 000000000000..b0155b19a7cd
--- /dev/null
+++ b/e2e-tests/playwright/specs/functional/plugins/org_memory/helpers/test-setup.ts
@@ -0,0 +1,67 @@
+// Shared test setup and UI interaction helpers for org-memory plugin E2E tests.
+// Eliminates duplicated initialization logic across spec files.
+
+import type {Page, Locator} from '@playwright/test';
+import {test, expect} from '@mattermost/playwright-lib';
+
+export const PLUGIN_ID = 'org-memory';
+
+/**
+ * Initialize test environment with plugin active and channels page visible.
+ * Configures server settings, ensures the org-memory plugin is enabled,
+ * navigates to the channels page, and dismisses onboarding overlays.
+ */
+export async function setupOrgMemoryTest(pw: any) {
+    const {adminClient, user, team, townSquareUrl} = await pw.initSetup();
+    const {channelsPage, page} = await pw.testBrowser.login(user);
+
+    await adminClient.patchConfig({
+        PluginSettings: {Enable: true, EnableUploads: true},
+        ServiceSettings: {EnableOnboardingFlow: false, EnableTutorial: false},
+    });
+
+    let pluginActive = false;
+    try {
+        pluginActive = await pw.isPluginActive(adminClient, PLUGIN_ID);
+    } catch {
+        // Plugin not installed
+    }
+    if (!pluginActive) {
+        try {
+            await adminClient.enablePlugin(PLUGIN_ID);
+        } catch {
+            test.skip(true, 'org-memory plugin not available');
+        }
+    }
+
+    await channelsPage.goto();
+    await channelsPage.toBeVisible();
+
+    await page.keyboard.press('Escape');
+    await page.waitForTimeout(500);
+
+    return {adminClient, user, team, townSquareUrl, channelsPage, page};
+}
+
+/**
+ * Open the org-memory RHS panel via the app bar icon.
+ * Waits for the panel to become visible before returning.
+ *
+ * @returns The RHS container locator for further assertions.
+ */
+export async function openOrgMemoryRhs(page: Page, channelsPage: any): Promise<Locator> {
+    const appBarIcon = page.locator(`#app-bar-icon-${PLUGIN_ID}`);
+    await expect(appBarIcon).toBeVisible({timeout: 10000});
+    await appBarIcon.click();
+    await channelsPage.sidebarRight.toBeVisible();
+    return page.locator('#sidebar-right');
+}
+
+/**
+ * Type a query into the RHS textarea and press Enter to submit.
+ */
+export async function submitQueryInRhs(rhsContainer: Locator, query: string): Promise<void> {
+    const queryInput = rhsContainer.locator('textarea').first();
+    await queryInput.fill(query);
+    await queryInput.press('Enter');
+}
diff --git a/e2e-tests/playwright/specs/functional/plugins/org_memory/org_memory_commands.spec.ts b/e2e-tests/playwright/specs/functional/plugins/org_memory/org_memory_commands.spec.ts
new file mode 100644
index 000000000000..c2cb715455ea
--- /dev/null
+++ b/e2e-tests/playwright/specs/functional/plugins/org_memory/org_memory_commands.spec.ts
@@ -0,0 +1,89 @@
+// Copyright (c) 2015-present Mattermost, Inc. All Rights Reserved.
+// See LICENSE.txt for license information.
+
+// E2E tests for the org-memory plugin slash command and WebSocket events.
+// Covers /ask slash command execution and thread summary WebSocket indicators.
+// All tests use route interception — no real Gemini API key required.
+
+import {test, expect} from '@mattermost/playwright-lib';
+
+import {
+    mockSlashCommandResponse,
+    mockQueryResponse,
+} from './helpers/mock-org-memory-api';
+import {setupOrgMemoryTest, PLUGIN_ID} from './helpers/test-setup';
+
+test.describe('Org Memory slash command and WebSocket @org-memory', () => {
+    test('slash command /ask produces an ephemeral post with response and citations', async ({pw}) => {
+        const {channelsPage, page} = await setupOrgMemoryTest(pw);
+
+        await mockSlashCommandResponse(page,
+            'Based on workspace conversations, the API decisions include REST endpoints and versioned APIs. [1](/test-team/pl/mock-post-1)',
+        );
+
+        await channelsPage.postMessage('/ask what decisions were made about the API?');
+
+        const lastPost = await channelsPage.getLastPost();
+        await lastPost.toBeVisible();
+        await lastPost.toContainText('API decisions');
+
+        const postContainer = lastPost.container;
+        const citationLink = postContainer.locator('a[href*="/test-team/pl/mock-post-1"]');
+        await expect(citationLink).toBeVisible({timeout: 5000});
+    });
+
+    test('WebSocket thread summary event updates Redux state', async ({pw}) => {
+        const {adminClient, channelsPage, page, team} = await setupOrgMemoryTest(pw);
+
+        await mockQueryResponse(page);
+
+        // Create a thread (root post + reply)
+        const channel = await adminClient.getChannelByName(team.id, 'town-square');
+        const rootPost = await adminClient.createPost({
+            channel_id: channel.id,
+            message: 'Thread root post for summary testing',
+        });
+        await adminClient.createPost({
+            channel_id: channel.id,
+            message: 'Reply to thread',
+            root_id: rootPost.id,
+        });
+
+        // Reload to see the new posts
+        await channelsPage.goto();
+        await channelsPage.toBeVisible();
+        await page.keyboard.press('Escape');
+        await page.waitForTimeout(500);
+
+        // Open the RHS so the plugin's WebSocket handler is active
+        const appBarIcon = page.locator(`#app-bar-icon-${PLUGIN_ID}`);
+        await expect(appBarIcon).toBeVisible({timeout: 10000});
+        await appBarIcon.click();
+        await page.locator('#sidebar-right').waitFor({state: 'visible'});
+
+        // Simulate a WebSocket event by dispatching the Redux action directly.
+        // This mimics what the WebSocket handler does when the server sends
+        // custom_org-memory_thread_summary_ready.
+        await page.evaluate((rootId: string) => {
+            const store = (window as any).store || (window as any).__store;
+            if (store) {
+                store.dispatch({
+                    type: 'org-memory/THREAD_SUMMARY_AVAILABLE',
+                    rootId,
+                });
+            }
+        }, rootPost.id);
+
+        // Verify the thread summary state was updated in Redux
+        const summaryAvailable = await page.evaluate((rootId: string) => {
+            const store = (window as any).store || (window as any).__store;
+            if (!store) {
+                return false;
+            }
+            const state = store.getState();
+            return state['plugins-org-memory']?.threadSummariesAvailable?.[rootId] === true;
+        }, rootPost.id);
+
+        expect(summaryAvailable).toBe(true);
+    });
+});
diff --git a/e2e-tests/playwright/specs/functional/plugins/org_memory/org_memory_installation.spec.ts b/e2e-tests/playwright/specs/functional/plugins/org_memory/org_memory_installation.spec.ts
new file mode 100644
index 000000000000..a34a2b1598af
--- /dev/null
+++ b/e2e-tests/playwright/specs/functional/plugins/org_memory/org_memory_installation.spec.ts
@@ -0,0 +1,74 @@
+// Copyright (c) 2015-present Mattermost, Inc. All Rights Reserved.
+// See LICENSE.txt for license information.
+
+// E2E test: Plugin installation and activation.
+// Verifies the org-memory plugin can be installed and activated,
+// and the app bar icon appears in the UI.
+// Tagged @smoke @org-memory for selective test execution.
+
+import {test, expect} from '@mattermost/playwright-lib';
+
+const PLUGIN_ID = 'org-memory';
+
+test.describe('Org Memory plugin installation @smoke @org-memory', () => {
+    test('should install and activate plugin, and show app bar icon', async ({pw}) => {
+        // 1. Initialize test environment with a fresh user and team
+        const {adminClient, user} = await pw.initSetup();
+        const {channelsPage, page} = await pw.testBrowser.login(user);
+
+        // 2. Configure server settings
+        await adminClient.patchConfig({
+            PluginSettings: {
+                Enable: true,
+                EnableUploads: true,
+            },
+            ServiceSettings: {
+                EnableOnboardingFlow: false,
+                EnableTutorial: false,
+            },
+        });
+
+        // 3. Navigate to channels page
+        await channelsPage.goto();
+        await channelsPage.toBeVisible();
+
+        // 4. Install and enable the org-memory plugin.
+        // In a real environment, this would use a plugin tarball URL.
+        // For testing purposes, we check if it's already installed or skip.
+        // The plugin must be pre-built and available at the configured URL.
+        let pluginInstalled = false;
+        try {
+            pluginInstalled = await pw.isPluginActive(adminClient, PLUGIN_ID);
+        } catch {
+            // Plugin not installed yet
+        }
+
+        if (!pluginInstalled) {
+            // Try to enable if already uploaded but not active
+            try {
+                await adminClient.enablePlugin(PLUGIN_ID);
+                pluginInstalled = true;
+            } catch {
+                // Plugin not uploaded — skip with informative message.
+                // In CI, the plugin tarball would be built and installed
+                // as part of the test setup pipeline.
+                test.skip(true, 'org-memory plugin not pre-installed; skipping installation test');
+            }
+        }
+
+        // 5. Verify plugin is active via API
+        await expect
+            .poll(async () => {
+                return await pw.isPluginActive(adminClient, PLUGIN_ID);
+            })
+            .toBe(true);
+
+        // 6. Verify the app bar icon appears in the UI
+        // Dismiss any overlays that may have appeared
+        await page.keyboard.press('Escape');
+        await page.waitForTimeout(500);
+
+        const appBarIcon = page.locator(`#app-bar-icon-${PLUGIN_ID}`);
+        await expect(appBarIcon).toBeVisible({timeout: 10000});
+    });
+});
diff --git a/e2e-tests/playwright/specs/functional/plugins/org_memory/org_memory_rhs.spec.ts b/e2e-tests/playwright/specs/functional/plugins/org_memory/org_memory_rhs.spec.ts
new file mode 100644
index 000000000000..19f933a49cb0
--- /dev/null
+++ b/e2e-tests/playwright/specs/functional/plugins/org_memory/org_memory_rhs.spec.ts
@@ -0,0 +1,223 @@
+// Copyright (c) 2015-present Mattermost, Inc. All Rights Reserved.
+// See LICENSE.txt for license information.
+
+// E2E tests for the org-memory plugin RHS panel.
+// Covers opening/closing, query submission, loading states,
+// response rendering, citation navigation, follow-up queries,
+// empty query handling, and new conversation reset.
+// All tests use route interception — no real Gemini API key required.
+
+import {test, expect} from '@mattermost/playwright-lib';
+
+import {
+    mockQueryResponse,
+    mockQueryResponseDeferred,
+    mockFollowupResponse,
+    defaultQueryResponse,
+} from './helpers/mock-org-memory-api';
+import {setupOrgMemoryTest, openOrgMemoryRhs, submitQueryInRhs, PLUGIN_ID} from './helpers/test-setup';
+
+test.describe('Org Memory RHS panel @org-memory', () => {
+    test('clicking the app bar icon opens the RHS panel', async ({pw}) => {
+        const {channelsPage, page} = await setupOrgMemoryTest(pw);
+
+        const rhsContainer = await openOrgMemoryRhs(page, channelsPage);
+
+        await expect(rhsContainer).toContainText(/Ask your workspace|Organizational Memory/);
+    });
+
+    test('clicking the app bar icon again closes the RHS panel', async ({pw}) => {
+        const {channelsPage, page} = await setupOrgMemoryTest(pw);
+
+        const appBarIcon = page.locator(`#app-bar-icon-${PLUGIN_ID}`);
+
+        // Open
+        await appBarIcon.click();
+        await channelsPage.sidebarRight.toBeVisible();
+
+        // Close by clicking again
+        await appBarIcon.click();
+        await expect(page.locator('#sidebar-right')).not.toBeVisible();
+    });
+
+    test('close button closes the RHS panel', async ({pw}) => {
+        const {channelsPage, page} = await setupOrgMemoryTest(pw);
+
+        await openOrgMemoryRhs(page, channelsPage);
+
+        await channelsPage.sidebarRight.close();
+        await expect(page.locator('#sidebar-right')).not.toBeVisible();
+    });
+
+    test('typing a query and pressing Enter shows loading then response', async ({pw}) => {
+        const {channelsPage, page} = await setupOrgMemoryTest(pw);
+
+        const deferred = await mockQueryResponseDeferred(page);
+
+        const rhsContainer = await openOrgMemoryRhs(page, channelsPage);
+        await submitQueryInRhs(rhsContainer, 'What decisions were made about the API?');
+
+        // Verify loading indicator appears
+        await expect(rhsContainer.locator('.org-memory-spinner')).toBeVisible({timeout: 5000});
+        await expect(rhsContainer).toContainText('Searching your workspace...');
+
+        // Resolve the deferred response
+        deferred.resolve();
+
+        // Verify loading goes away and response appears
+        await expect(rhsContainer.locator('.org-memory-spinner')).not.toBeVisible({timeout: 10000});
+        await expect(rhsContainer).toContainText('API was redesigned', {timeout: 5000});
+    });
+
+    test('response renders with markdown formatting', async ({pw}) => {
+        const {channelsPage, page} = await setupOrgMemoryTest(pw);
+
+        await mockQueryResponse(page);
+
+        const rhsContainer = await openOrgMemoryRhs(page, channelsPage);
+        await submitQueryInRhs(rhsContainer, 'What about the API?');
+
+        await expect(rhsContainer).toContainText('API was redesigned', {timeout: 10000});
+        await expect(rhsContainer).toContainText('Sources');
+    });
+
+    test('citation links are present with correct permalink URLs', async ({pw}) => {
+        const {channelsPage, page} = await setupOrgMemoryTest(pw);
+
+        const citationPermalink = '/test-team/pl/mock-post-1';
+        await mockQueryResponse(page, defaultQueryResponse({
+            citations: [
+                {
+                    ref_number: 1,
+                    post_id: 'mock-post-1',
+                    permalink: citationPermalink,
+                    channel_name: 'engineering',
+                    author: 'alice',
+                    snippet: 'We decided to redesign the API.',
+                },
+            ],
+        }));
+
+        const rhsContainer = await openOrgMemoryRhs(page, channelsPage);
+        await submitQueryInRhs(rhsContainer, 'API decisions');
+
+        await expect(rhsContainer).toContainText('Sources', {timeout: 10000});
+
+        const citationLink = rhsContainer.locator(`a[href="${citationPermalink}"]`);
+        await expect(citationLink).toBeVisible();
+        await expect(citationLink).toContainText('[1]');
+    });
+
+    test('citation link navigates to the original post permalink', async ({pw}) => {
+        const {adminClient, channelsPage, page, team} = await setupOrgMemoryTest(pw);
+
+        // Create a real post that we can navigate to
+        const channel = await adminClient.getChannelByName(team.id, 'town-square');
+        const realPost = await adminClient.createPost({
+            channel_id: channel.id,
+            message: 'This is a test post for citation navigation',
+        });
+
+        const permalink = `/${team.name}/pl/${realPost.id}`;
+
+        await mockQueryResponse(page, defaultQueryResponse({
+            citations: [
+                {
+                    ref_number: 1,
+                    post_id: realPost.id,
+                    permalink,
+                    channel_name: 'town-square',
+                    author: 'sysadmin',
+                    snippet: 'Test post for citation',
+                },
+            ],
+        }));
+
+        const rhsContainer = await openOrgMemoryRhs(page, channelsPage);
+        await submitQueryInRhs(rhsContainer, 'Show me the decision');
+
+        await expect(rhsContainer).toContainText('Sources', {timeout: 10000});
+
+        const citationLink = rhsContainer.locator(`a[href="${permalink}"]`);
+        await expect(citationLink).toBeVisible();
+        await citationLink.click();
+
+        await expect(page).toHaveURL(new RegExp(realPost.id), {timeout: 10000});
+    });
+
+    test('follow-up query uses follow-up endpoint and both exchanges are visible', async ({pw}) => {
+        const {channelsPage, page} = await setupOrgMemoryTest(pw);
+
+        await mockQueryResponse(page);
+        await mockFollowupResponse(page);
+
+        const rhsContainer = await openOrgMemoryRhs(page, channelsPage);
+        await submitQueryInRhs(rhsContainer, 'What about the API redesign?');
+
+        // Wait for initial response
+        await expect(rhsContainer).toContainText('API was redesigned', {timeout: 10000});
+
+        // Submit a follow-up query
+        const followUpInput = rhsContainer.locator('textarea[placeholder="Ask a follow-up question..."]');
+        await expect(followUpInput).toBeVisible({timeout: 5000});
+        await followUpInput.fill('When was it completed?');
+        await followUpInput.press('Enter');
+
+        // Wait for follow-up response
+        await expect(rhsContainer).toContainText('completed in October', {timeout: 10000});
+
+        // Verify both exchanges are visible in the conversation history
+        await expect(rhsContainer).toContainText('What about the API redesign?');
+        await expect(rhsContainer).toContainText('API was redesigned');
+        await expect(rhsContainer).toContainText('When was it completed?');
+        await expect(rhsContainer).toContainText('completed in October');
+    });
+
+    test('pressing Enter with empty input does not trigger API call', async ({pw}) => {
+        const {channelsPage, page} = await setupOrgMemoryTest(pw);
+
+        // Set up a mock that tracks whether it was called
+        let apiCalled = false;
+        await page.route('**/plugins/org-memory/api/v1/query', async (route) => {
+            apiCalled = true;
+            await route.fulfill({
+                status: 200,
+                contentType: 'application/json',
+                body: JSON.stringify(defaultQueryResponse()),
+            });
+        });
+
+        const rhsContainer = await openOrgMemoryRhs(page, channelsPage);
+
+        const queryInput = rhsContainer.locator('textarea').first();
+        await queryInput.press('Enter');
+
+        // Wait a moment to ensure no API call is made
+        await page.waitForTimeout(1000);
+
+        expect(apiCalled).toBe(false);
+        await expect(rhsContainer.locator('.org-memory-spinner')).not.toBeVisible();
+    });
+
+    test('New conversation resets the panel to initial state', async ({pw}) => {
+        const {channelsPage, page} = await setupOrgMemoryTest(pw);
+
+        await mockQueryResponse(page);
+
+        const rhsContainer = await openOrgMemoryRhs(page, channelsPage);
+        await submitQueryInRhs(rhsContainer, 'What about the API?');
+
+        await expect(rhsContainer).toContainText('API was redesigned', {timeout: 10000});
+
+        // Click "New conversation" to reset
+        const newConvButton = rhsContainer.locator('button', {hasText: '+ New conversation'});
+        await expect(newConvButton).toBeVisible();
+        await newConvButton.click();
+
+        // Verify the panel resets to initial state
+        const initialInput = rhsContainer.locator('textarea[placeholder="Ask a question about your workspace..."]');
+        await expect(initialInput).toBeVisible({timeout: 5000});
+        await expect(rhsContainer).not.toContainText('API was redesigned');
+        await expect(rhsContainer).toContainText('Ask your workspace');
+    });
+});
diff --git a/mp-sw-factory.yaml b/mp-sw-factory.yaml
new file mode 100644
index 000000000000..5aa990b05737
--- /dev/null
+++ b/mp-sw-factory.yaml
@@ -0,0 +1,146 @@
+# mp-sw-factory.yaml — Mattermost monorepo + org-memory plugin
+# This is a large Go + React/TypeScript monorepo (Mattermost server) with an
+# in-tree plugin at server/plugins/org-memory/ that is the primary development focus.
+
+# ─── AI Instruction Fields ──────────────────────────────────────────────────────
+
+testing: |
+  This repo has multiple test surfaces. The primary development focus is the
+  **org-memory plugin** at `server/plugins/org-memory/`.
+
+  ## Plugin Go tests (primary — run these first)
+  ```bash
+  cd server/plugins/org-memory/server && GOWORK=off go test -v -count=1 ./...
+  ```
+  - CRITICAL: `GOWORK=off` is required because the parent `server/go.work` workspace
+    interferes with the plugin's own `go.mod`.
+  - 21 test files covering: plugin lifecycle, configuration, hooks, worker, debounce,
+    circuit breaker, rate limiter, chunker, RAG engine, API, backfill, metrics,
+    channel summary worker, data retention, Gemini client, Gemini errors.
+  - Tests use `plugintest.API` mocks, `plugintest.NewDriver(t)` for DB driver mocks,
+    and `pluginapi.NewClient(api, driver)` for the client.
+  - Look for "PASS" or "FAIL" in output. Exit code 0 = all passed.
+
+  ## Plugin webapp tests
+  ```bash
+  cd server/plugins/org-memory/webapp && npm test
+  ```
+  - Jest 29 with jsdom environment, ts-jest for TypeScript.
+  - Coverage thresholds: branches 70%, functions 70%, lines 75%, statements 75%.
+  - Test files in `src/__tests__/`.
+
+  ## Mattermost server tests (only if modifying server/ code outside the plugin)
+  ```bash
+  cd server && make test-server
+  ```
+  - Requires Docker services (PostgreSQL, etc.) via `make start-docker`.
+  - Very slow — avoid unless modifying core server code.
+
+  ## Mattermost webapp tests (only if modifying webapp/ code)
+  ```bash
+  cd webapp && npm run test
+  ```
+  - Jest across multiple workspaces (channels, platform/*).
+
+  ## E2E tests
+  - **Cypress** (v15.11): `cd e2e-tests/cypress && npm run test:ci`
+  - **Playwright** (v1.58): `cd e2e-tests/playwright && npm run test:ci`
+  - Both require a running Mattermost server. Use `cd e2e-tests && make` for full setup.
+  - These are slow and should only be run selectively for relevant changes.
+
+linting: |
+  ## Plugin Go linting (primary)
+  There is no golangci-lint config specific to the plugin. Use `go vet`:
+  ```bash
+  cd server/plugins/org-memory/server && GOWORK=off go vet ./...
+  ```
+
+  ## Plugin webapp type checking
+  ```bash
+  cd server/plugins/org-memory/webapp && npm run lint
+  ```
+  This runs `tsc --noEmit` — a type checker, not a traditional linter. It reports
+  TypeScript type errors. No autofix available for type errors.
+
+  ## Mattermost server linting (only if modifying server/ code outside the plugin)
+  ```bash
+  cd server && make check-style
+  ```
+  - Uses golangci-lint v2.6.0 with config at `server/.golangci.yml`.
+  - Linters: bidichk, errcheck, govet, ineffassign, misspell, modernize, revive,
+    staticcheck, unconvert, unused, whitespace.
+
+  ## Mattermost webapp linting (only if modifying webapp/ code)
+  ```bash
+  cd webapp && npm run check
+  ```
+  - ESLint 8.57 across all workspaces.
+  - Autofix: `cd webapp && npm run fix`
+
+  ## Mattermost webapp type checking
+  ```bash
+  cd webapp && npm run check-types
+  ```
+
+install: |
+  ## Plugin dependencies (primary)
+  ```bash
+  # Go dependencies (plugin server)
+  cd server/plugins/org-memory/server && GOWORK=off go mod download
+
+  # Webapp dependencies (plugin frontend)
+  cd server/plugins/org-memory/webapp && npm install
+  ```
+
+  ## Full Mattermost dependencies (if needed)
+  ```bash
+  # Server Go workspace setup
+  cd server && make setup-go-work && go mod download
+
+  # Webapp npm dependencies
+  cd webapp && npm install
+
+  # Docker services for local dev (PostgreSQL, Redis, Minio, etc.)
+  cd server && make start-docker
+  ```
+
+  ## Requirements
+  - Go 1.24+ (check `server/.go-version` for exact version)
+  - Node.js 24+ / npm 11+
+  - Docker & docker-compose (for server integration tests)
+  - PostgreSQL with pgvector extension (for plugin)
+
+logs: |
+  ## Plugin logs
+  - Plugin logs go through Mattermost's plugin logging API (`p.API.LogInfo`,
+    `p.API.LogError`, `p.API.LogWarn`).
+  - In development: logs appear in the Mattermost server stdout/stderr.
+  - Test output: `go test -v` shows log output inline.
+
+  ## Server logs
+  - Dev server: `cd server && make run-server` — logs to stdout.
+  - Docker services: `docker-compose logs -f` from `server/`.
+
+  ## Webapp logs
+  - Browser console for frontend debugging.
+  - Webpack dev server output: `cd webapp && make dev`
+
+coderabbit: auto
+
+# ─── Pipeline Step Configuration ────────────────────────────────────────────────
+
+steps:
+  run_lint:
+    # Lint plugin Go code + typecheck plugin webapp
+    check: "(cd server/plugins/org-memory/server && GOWORK=off go vet ./...) && (cd server/plugins/org-memory/webapp && npx tsc --noEmit)"
+    context: "(cd server/plugins/org-memory/server && GOWORK=off go vet ./... 2>&1) | tail -30; (cd server/plugins/org-memory/webapp && npx tsc --noEmit 2>&1) | tail -30"
+
+  run_tests:
+    # Run plugin Go tests + plugin webapp tests
+    check: "(cd server/plugins/org-memory/server && GOWORK=off go test -count=1 ./...) && (cd server/plugins/org-memory/webapp && npm test -- --watchAll=false)"
+    context: "(cd server/plugins/org-memory/server && GOWORK=off go test -v -count=1 ./... 2>&1) | tail -80; (cd server/plugins/org-memory/webapp && npm test -- --watchAll=false 2>&1) | tail -40"
+
+  check_build:
+    # Build plugin server binary (native platform only) + webapp bundle
+    check: "(cd server/plugins/org-memory/server && GOWORK=off go build -o /dev/null .) && (cd server/plugins/org-memory/webapp && npx webpack --mode=production)"
+    context: "(cd server/plugins/org-memory/server && GOWORK=off go build -o /dev/null . 2>&1) | tail -30; (cd server/plugins/org-memory/webapp && npx webpack --mode=production 2>&1) | tail -30"
diff --git a/tasks/0001-org-memory-ai-knowledge-base/001.md b/tasks/0001-org-memory-ai-knowledge-base/001.md
new file mode 100644
index 000000000000..929633441911
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/001.md
@@ -0,0 +1,97 @@
+# 001: Plugin scaffold, manifest, and build system
+
+## Context
+
+This is the foundational step that creates the plugin's directory structure, Go module, plugin manifest, build system, and bare entry point. Everything in subsequent steps depends on this scaffold existing. The existing `server/plugins/org-memory/` directory contains stale compiled artifacts from a deleted codebase with OpenAI-oriented settings — it must be replaced entirely with a fresh scaffold configured for Gemini.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/plugins/org-memory/plugin.json` — The existing manifest to be replaced. Provides the plugin ID (`org-memory`), name, description, version, and min_server_version. The settings schema must be rewritten for Gemini (currently references OpenAI base URLs, gpt-4o-mini, text-embedding-3-small, 1536 dimensions).
+- `server/plugins/github/plugin.json` — Reference manifest showing best practices: multi-platform executable paths for 5 architectures (darwin-amd64, darwin-arm64, linux-amd64, linux-arm64, windows-amd64), webapp bundle path, icon_path for assets, rich settings_schema with text, bool, number, dropdown, and secret field types, header/footer help text.
+- `server/public/plugin/client.go` — Defines `MattermostPlugin` base struct. The plugin's main struct must embed this. Entry point calls `plugin.ClientMain(&Plugin{})`.
+- `server/public/pluginapi/client.go` — The `pluginapi.Client` that wraps the raw plugin API. The plugin should import this package for later use.
+- `server/public/model/utils.go` — Provides `model.NewId()` for ID generation. The plugin's go.mod must include the Mattermost public model package.
+
+## Reuse Opportunities
+
+- The existing `server/plugins/org-memory/plugin.json` structure (ID, name, description, executable paths, webapp bundle path) can be reused as a starting template, but the settings_schema must be completely replaced with Gemini-oriented settings.
+- The GitHub plugin manifest demonstrates the full range of settings_schema field types (text, bool, number, generated, dropdown, secret) — follow its patterns for the Gemini settings.
+- The Mattermost plugin SDK conventions for Go module naming, import paths, and build targets are standardized — the scaffold should follow the same patterns used by community plugins (separate go.mod for the plugin, importing from `github.com/mattermost/mattermost/server/public/...`).
+
+## Deliverables
+
+### Plugin manifest (plugin.json)
+
+Replace the existing `server/plugins/org-memory/plugin.json` with a new manifest that:
+
+- Retains the plugin ID `org-memory`, updates the name to "Organizational Memory", and keeps min_server_version at `9.5.0`
+- Defines server executables for all 5 platform targets: darwin-amd64, darwin-arm64, linux-amd64, linux-arm64, windows-amd64
+- Defines the webapp bundle path at `webapp/dist/main.js`
+- Includes an icon_path for the plugin icon asset
+- Replaces the entire settings_schema with Gemini-oriented settings:
+  - **GeminiAPIKey** — text, secret, no default. Help text explaining this is the Google AI API key for Gemini.
+  - **GeminiModel** — text, default `gemini-2.5-flash`. The model used for summarization, extraction, and RAG synthesis.
+  - **EmbeddingModel** — text, default `gemini-embedding-001`. The model used for generating vector embeddings.
+  - **EmbeddingDimensions** — number, default `768`. The dimensionality of generated embeddings.
+  - **WorkerPollMs** — number, default `1000`. How frequently the background worker polls for pending processing items (milliseconds).
+  - **ThreadDebounceSeconds** — number, default `120`. How long a thread must be inactive before triggering summarization.
+  - **MaxChunksPerPost** — number, default `32`. Maximum number of chunks a single post can produce for embedding.
+  - **SkipBotPosts** — bool, default `true`. Whether to skip processing messages from bot accounts.
+  - **EnableForTeams** — text, default empty string. Comma-separated list of team IDs to enable processing for; empty means all teams.
+  - **DailySummaryHour** — number, default `8`. The hour of day (0-23) at which daily channel summaries are generated.
+- Includes a descriptive header explaining the plugin's purpose and a note that pgvector must be enabled
+
+### Plugin server source directory
+
+Create a new source directory structure under `server/plugins/org-memory/server/` with:
+
+- A Go module file (go.mod) declaring the module path and Go version, with dependencies on the Mattermost server public packages (plugin, pluginapi, model) and the Google AI Go SDK (`google.golang.org/genai`)
+- A main plugin file containing the Plugin struct that embeds `plugin.MattermostPlugin` and calls `plugin.ClientMain` as the entry point
+- The plugin struct should be a bare skeleton at this stage — no hook implementations, no business logic. Just the minimum needed to compile and be loaded by Mattermost.
+
+### Plugin webapp source directory
+
+Create a new source directory structure under `server/plugins/org-memory/webapp/` with:
+
+- A package.json declaring the webapp as a Node.js project with dependencies on React, TypeScript, and the Mattermost webapp types
+- A webpack or equivalent bundler configuration that produces a single `dist/main.js` bundle
+- A minimal entry point that registers the plugin with Mattermost via `window.registerPlugin('org-memory', ...)` with empty `initialize` and `uninitialize` functions
+- A TypeScript configuration file
+
+### Build system
+
+Create a Makefile (or equivalent build script) at the plugin root (`server/plugins/org-memory/`) that supports:
+
+- Building the Go server binary for all 5 platform targets (cross-compilation via GOOS/GOARCH)
+- Building the webapp bundle via the Node.js toolchain
+- A `dist` or `bundle` target that assembles the final plugin package: manifest + server binaries + webapp bundle + assets into the correct directory structure
+- A `clean` target to remove build artifacts
+
+### Plugin icon asset
+
+Create a simple SVG icon in `server/plugins/org-memory/assets/` for the plugin's branding in the System Console and app bar.
+
+### Remove stale artifacts
+
+Delete the existing compiled artifacts:
+- `server/plugins/org-memory/server/dist/` (old server binaries)
+- `server/plugins/org-memory/webapp/dist/` (old webapp bundle)
+
+These will be regenerated by the new build system.
+
+## Acceptance Criteria
+
+- [x] The plugin manifest at `server/plugins/org-memory/plugin.json` is valid JSON with plugin ID `org-memory`, min_server_version `9.5.0`, and all 10 Gemini-oriented settings in the settings_schema (GeminiAPIKey, GeminiModel, EmbeddingModel, EmbeddingDimensions, WorkerPollMs, ThreadDebounceSeconds, MaxChunksPerPost, SkipBotPosts, EnableForTeams, DailySummaryHour)
+- [x] The manifest references server executables for all 5 platforms (darwin-amd64, darwin-arm64, linux-amd64, linux-arm64, windows-amd64) and the webapp bundle at `webapp/dist/main.js`
+- [x] No references to OpenAI, GPT, or text-embedding-3 remain anywhere in the plugin directory
+- [x] The Go module compiles successfully with `go build` and produces a server binary that Mattermost can load as a plugin process
+- [x] The Go source imports the Mattermost plugin SDK and the Google AI Go SDK as dependencies
+- [x] The Plugin struct embeds `plugin.MattermostPlugin` and the main function calls `plugin.ClientMain`
+- [x] The webapp builds successfully with `npm run build` (or equivalent) and produces a `webapp/dist/main.js` bundle
+- [x] The webapp entry point registers the plugin with Mattermost via `window.registerPlugin('org-memory', ...)` and Mattermost recognizes it on load
+- [x] The Makefile can cross-compile the server binary for all 5 platform targets
+- [x] The Makefile can build the webapp bundle
+- [x] Running the full build produces a complete plugin directory structure matching what plugin.json declares (server binaries at the declared paths, webapp bundle at the declared path, icon asset at the declared path)
+- [x] The old compiled artifacts (server/dist/, webapp/dist/) from the previous implementation have been removed and replaced by the new build output
diff --git a/tasks/0001-org-memory-ai-knowledge-base/002.md b/tasks/0001-org-memory-ai-knowledge-base/002.md
new file mode 100644
index 000000000000..95a2c70e6be1
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/002.md
@@ -0,0 +1,107 @@
+# 002: Configuration management and plugin lifecycle
+
+## Context
+
+With the plugin scaffold from step 001 in place, this step wires up the full plugin lifecycle: loading configuration from the manifest's settings_schema into a typed struct, initializing the pluginapi.Client for organized API access, validating required settings (especially the Gemini API key), registering the `/ask` slash command, and implementing graceful shutdown. This is the last "infrastructure" step before database and business logic work begins — all subsequent steps depend on a functioning plugin that activates cleanly, reloads configuration on changes, and shuts down without leaking resources.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/plugin/hooks.go` (lines 82-107) — Defines `OnActivate`, `OnDeactivate`, and `OnConfigurationChange` hooks. Key lifecycle detail: `OnConfigurationChange` is called once *before* `OnActivate`, so the config struct is populated before activation begins. `OnActivate` errors terminate the plugin; `OnConfigurationChange` errors are logged but non-fatal.
+- `server/public/pluginapi/client.go` (lines 36-69) — `pluginapi.NewClient(api, driver)` creates the helper client with organized services (Bot, Channel, Cluster, Configuration, KV, Log, Post, Store, User, etc.). Must be created exactly once per plugin instance during `OnActivate`.
+- `server/public/pluginapi/configuration.go` — `ConfigurationService.LoadPluginConfiguration(dest any)` unmarshals the plugin's JSON config into a Go struct. Field names match settings_schema keys (case-insensitive matching).
+- `server/channels/app/plugin_api_tests/manual.test_load_configuration_plugin/main.go` — Real test plugin showing the configuration struct pattern: exported fields mapping to plugin.json settings keys, `OnConfigurationChange` calling `LoadPluginConfiguration`, and embedding a `BasicConfig` struct for composition.
+- `server/channels/app/plugin_commands_test.go` (lines 64-77) — Shows `RegisterCommand` in `OnActivate` with `model.Command` fields: TeamId, Trigger, DisplayName, AutoComplete, AutoCompleteDesc. Also shows re-registration during `OnConfigurationChange`.
+- `server/public/pluginapi/example_client_test.go` — Canonical pattern: Plugin struct with `client *pluginapi.Client` field, initialized in `OnActivate` via `pluginapi.NewClient(p.API, p.Driver)`.
+- `server/public/pluginapi/store.go` — `StoreService` with `GetMasterDB()` returning `*sql.DB`. Called during activation to obtain the database handle for later use by the knowledge store.
+- `server/public/plugin/environment.go` (lines 283-305) — Shows execution order: plugin state set to Running, then `OnActivate()` called. If OnActivate returns an error, the supervisor is shut down and the plugin fails to start.
+
+## Reuse Opportunities
+
+- The `pluginapi.Client` provides organized access to all Mattermost services. Use `client.Configuration.LoadPluginConfiguration` for config loading, `client.SlashCommand.Register` for command registration, `client.Store.GetMasterDB` for database access, `client.Log` for structured logging, and `client.KV` for key-value operations. This avoids calling the raw `p.API.*` methods directly throughout the codebase.
+- The configuration struct pattern is well-established: exported Go struct fields with names matching the plugin.json settings_schema keys. The implementer should follow this exact pattern for the 10 Gemini-oriented settings defined in step 001.
+- `model.Command` struct fields for slash command registration are standardized. The `/ask` command should follow the same registration pattern seen in the test plugins.
+
+## Deliverables
+
+### Configuration struct
+
+Define a Go struct with exported fields mapping to each of the 10 settings from the plugin manifest:
+
+- GeminiAPIKey (string, secret)
+- GeminiModel (string)
+- EmbeddingModel (string)
+- EmbeddingDimensions (integer)
+- WorkerPollMs (integer)
+- ThreadDebounceSeconds (integer)
+- MaxChunksPerPost (integer)
+- SkipBotPosts (boolean)
+- EnableForTeams (string — comma-separated team IDs)
+- DailySummaryHour (integer)
+
+The struct should also provide a validation method that checks for required settings (at minimum, GeminiAPIKey must be non-empty) and returns a descriptive error if validation fails. It should provide a convenience method that parses EnableForTeams into a set/map of team IDs for efficient lookup during event ingestion.
+
+### OnConfigurationChange implementation
+
+Implement the `OnConfigurationChange` hook to:
+
+1. Load the plugin configuration into the configuration struct using the plugin API
+2. Validate the loaded configuration
+3. If validation fails, log an error with a descriptive message and return the error
+4. Store the validated configuration on the Plugin struct for access by other components
+
+Since `OnConfigurationChange` is called before `OnActivate` on startup (and also on live config changes), it must work correctly whether or not the plugin is fully initialized yet. It should not attempt to reconfigure components that haven't been created.
+
+### OnActivate implementation
+
+Implement the `OnActivate` hook to perform the following initialization sequence:
+
+1. Create the `pluginapi.Client` and store it on the Plugin struct
+2. Verify that the configuration has been loaded (it should have been populated by the prior `OnConfigurationChange` call)
+3. Validate that the GeminiAPIKey is present — if not, return an error that terminates activation with a clear message
+4. Obtain a database handle via `client.Store.GetMasterDB()` and store it on the Plugin struct for use by later steps (schema migration, store operations)
+5. Register the `/ask` slash command with appropriate display name, description, auto-complete hint, and auto-complete description. The command should be workspace-wide (empty TeamId means all teams).
+6. Log a success message indicating the plugin has activated
+
+If any step fails, return an error to prevent the plugin from starting in a broken state. Resources acquired before the failure point should be cleaned up.
+
+Note: Background scheduler initialization, schema migration, and Gemini client creation are **not** part of this step — they will be added in later steps as those components are implemented. The Plugin struct should have placeholder fields for these components (e.g., fields for the scheduler, store, and Gemini client) that will be populated in subsequent steps.
+
+### OnDeactivate implementation
+
+Implement the `OnDeactivate` hook to:
+
+1. Shut down any background schedulers that have been started (placeholder for now — later steps will register schedulers)
+2. Close the database connection via the store service
+3. Log a message indicating clean shutdown
+
+The deactivation must be safe to call even if activation never fully completed (partial initialization). Each resource cleanup should check whether the resource was actually initialized before attempting to close it.
+
+### Plugin struct fields
+
+Extend the Plugin struct (created in step 001) with fields for:
+
+- The `pluginapi.Client` instance
+- The configuration struct
+- The database handle (`*sql.DB`)
+- Placeholder fields for components added in later steps: a Gemini client interface, a store interface, scheduler references, and a metrics collector. These fields can be nil/zero-valued at this stage but should be defined so that later steps can populate them without modifying the struct definition.
+
+## Acceptance Criteria
+
+- [x] The configuration struct has exported fields for all 10 plugin settings (GeminiAPIKey, GeminiModel, EmbeddingModel, EmbeddingDimensions, WorkerPollMs, ThreadDebounceSeconds, MaxChunksPerPost, SkipBotPosts, EnableForTeams, DailySummaryHour)
+- [x] Configuration validation rejects an empty GeminiAPIKey with a descriptive error message
+- [x] Configuration validation accepts a valid configuration with all required fields populated
+- [x] The EnableForTeams string is parseable into a set of team IDs, and an empty string is interpreted as "all teams enabled"
+- [x] OnConfigurationChange successfully loads the plugin configuration into the struct and stores it on the Plugin
+- [x] OnConfigurationChange works correctly when called before OnActivate (during the initial startup sequence)
+- [x] OnConfigurationChange works correctly when called after OnActivate (during a live config update) and propagates updated values
+- [x] OnActivate creates the pluginapi.Client and stores it on the Plugin struct
+- [x] OnActivate obtains a database handle via the store service and stores it on the Plugin struct
+- [x] OnActivate fails with a descriptive error if the GeminiAPIKey is not configured
+- [x] OnActivate registers the `/ask` slash command with trigger "ask", a display name, auto-complete enabled, and a help description
+- [x] OnActivate logs a success message on successful initialization
+- [x] OnDeactivate completes without errors when all resources were initialized
+- [x] OnDeactivate completes without errors when called after a partial initialization (some resources are nil)
+- [x] OnDeactivate closes the database connection
+- [x] The Plugin struct has placeholder fields defined for the Gemini client, store interface, schedulers, and metrics collector so that subsequent steps can populate them without struct changes
diff --git a/tasks/0001-org-memory-ai-knowledge-base/003.md b/tasks/0001-org-memory-ai-knowledge-base/003.md
new file mode 100644
index 000000000000..aba09c9b345b
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/003.md
@@ -0,0 +1,240 @@
+# 003: Database schema and knowledge store
+
+## Context
+
+With the plugin lifecycle operational from step 002, this step creates the seven database tables that form the knowledge base's persistence layer, plus the store interface that all other components use for data access. The plugin must create the pgvector extension and all tables idempotently during OnActivate (there is no plugin migration framework — plugins run raw SQL against the database). This step also implements the full store interface with CRUD operations, vector similarity search, and permission-filtered queries that subsequent steps (workers, RAG engine, API) depend on.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/channels/db/migrations/postgres/000001_create_teams.up.sql` — Core migration showing Mattermost SQL conventions: `VARCHAR(26)` for IDs, `bigint` for timestamps, `CREATE TABLE IF NOT EXISTS`, `CREATE INDEX IF NOT EXISTS`, `ALTER TABLE ... ADD COLUMN IF NOT EXISTS`. Soft delete via `deleteat bigint` column (0 = active, >0 = deletion timestamp).
+- `server/channels/db/migrations/postgres/000053_create_retention_policies.up.sql` — Shows how foreign keys are added idempotently using `DO $$ BEGIN IF NOT EXISTS (SELECT 1 FROM pg_constraint WHERE conname = '...') THEN ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY ... ON DELETE CASCADE; END IF; END; $$;` blocks.
+- `server/channels/db/migrations/postgres/000149_create_recaps.up.sql` — Shows inline foreign key declaration with `FOREIGN KEY (RecapId) REFERENCES Recaps(Id) ON DELETE CASCADE` inside CREATE TABLE.
+- `server/channels/store/sqlstore/bot_store.go` — Reference store implementation: constructor pre-builds a Squirrel SelectBuilder, GET methods use `GetReplica().Get()` with `sql.ErrNoRows` → `store.NewErrNotFound()` error mapping, writes use `GetMaster().Exec()`, Squirrel queries use `sq.Dollar` placeholder format for PostgreSQL.
+- `server/channels/store/sqlstore/plugin_store.go` — Plugin key-value store showing Squirrel with `INSERT ... ON CONFLICT DO UPDATE` (upsert) pattern, `ToSql()` → `Exec(queryString, args...)` flow, and `errors.Wrap` for error context.
+- `server/channels/store/store.go` — Core store interface pattern: a facade interface with getter methods returning sub-store interfaces (`Team() TeamStore`, `Post() PostStore`, etc.). Each sub-store defines its own CRUD contract.
+- `server/public/pluginapi/store.go` — `StoreService.GetMasterDB()` returns a singleton `*sql.DB`. `GetReplicaDB()` falls back to master if no replica configured. `DriverName()` returns the driver name. `Close()` cleans up connections. The store test in `store_test.go` confirms singleton behavior.
+- `server/public/model/utils.go` — `model.NewId()` generates 26-character base32-encoded UUID v4 strings for row IDs.
+- `server/channels/store/sqlstore/store.go` (lines 915-926) — Query builder setup: `sq.StatementBuilder.PlaceholderFormat(sq.Dollar)` for PostgreSQL dollar-sign placeholders.
+
+## Reuse Opportunities
+
+- **Squirrel query builder** (`github.com/mattermost/squirrel`) is already a Mattermost dependency. The plugin store should use it with `sq.Dollar` placeholder format for all parameterized queries, following the same `Select().From().Where().ToSql()` → `db.Query(sql, args...)` pattern used in core stores.
+- **model.NewId()** from `github.com/mattermost/mattermost/server/public/model` generates IDs consistent with all Mattermost tables. Use for all new row IDs.
+- **pluginapi.StoreService** provides `GetMasterDB()` and `GetReplicaDB()` — the plugin should use master for writes and replica for reads (read queries in the RAG engine and extraction listing).
+- **Error wrapping** via `github.com/pkg/errors` with `errors.Wrap(err, "context")` and `errors.Wrapf(err, "context %s", id)` is the standard pattern across all Mattermost stores.
+- **Store interface pattern** from core (facade with sub-store getters) can be applied in miniature: a plugin-level store interface with methods grouped by table, making it easy to mock for unit tests.
+
+## Deliverables
+
+### Schema migration runner
+
+Add schema migration logic to the OnActivate lifecycle (from step 002). During plugin activation, after obtaining the database handle, the plugin must execute idempotent SQL statements to:
+
+1. Create the pgvector extension (`CREATE EXTENSION IF NOT EXISTS vector`). If this fails (insufficient privileges), activation must fail with an error message instructing the admin to install the extension manually.
+2. Create all 7 tables with `CREATE TABLE IF NOT EXISTS`.
+3. Create all indexes with `CREATE INDEX IF NOT EXISTS`.
+4. Add foreign key constraints idempotently (check pg_constraint before adding).
+
+All migration SQL must be safe to run concurrently from multiple plugin instances in a HA cluster — the IF NOT EXISTS and constraint-existence checks ensure this.
+
+### Table: ai_embeddings
+
+Vector storage for post/file/summary content. Each row represents one chunk of embedded content.
+
+Columns:
+- **Id** — VARCHAR(26), primary key, generated via model.NewId()
+- **PostId** — VARCHAR(26), not null, foreign key to Posts(Id) with ON DELETE CASCADE
+- **ChannelId** — VARCHAR(26), not null, foreign key to Channels(Id) with ON DELETE CASCADE
+- **SourceType** — VARCHAR(20), not null, one of: 'post', 'file', 'summary'
+- **ChunkIndex** — integer, not null, default 0, sequential index within the parent post
+- **ContentSnapshot** — text, not null, the original text content of this chunk (for citation display)
+- **Embedding** — vector(768), not null, L2-normalized embedding from Gemini
+- **CreateAt** — bigint, not null, Unix milliseconds
+- **DeleteAt** — bigint, default 0, soft delete timestamp
+
+Indexes:
+- HNSW index on Embedding column using `vector_cosine_ops` operator class for approximate nearest-neighbor cosine similarity search
+- B-tree index on ChannelId for permission-filtered queries
+- B-tree composite index on (PostId, ChunkIndex) for chunk ordering and deduplication lookups
+
+### Table: ai_extractions
+
+Extracted knowledge items (decisions, action items, topics).
+
+Columns:
+- **Id** — VARCHAR(26), primary key
+- **PostId** — VARCHAR(26), not null, foreign key to Posts(Id) with ON DELETE CASCADE
+- **ChannelId** — VARCHAR(26), not null, foreign key to Channels(Id) with ON DELETE CASCADE
+- **ExtractionType** — VARCHAR(32), not null, one of: 'decision', 'action_item', 'topic'
+- **Content** — text, not null
+- **Metadata** — JSONB, nullable, structured metadata (assignee, status, confidence)
+- **IsEdited** — boolean, default false
+- **EditorUserId** — VARCHAR(26), nullable
+- **CreateAt** — bigint, not null
+- **UpdateAt** — bigint, not null
+- **DeleteAt** — bigint, default 0
+
+Indexes:
+- Composite index on (ChannelId, ExtractionType) with a WHERE DeleteAt = 0 partial index condition for filtered listing queries
+
+### Table: ai_thread_summaries
+
+One summary per thread, keyed by root post ID.
+
+Columns:
+- **RootId** — VARCHAR(26), primary key, foreign key to Posts(Id) with ON DELETE CASCADE
+- **ChannelId** — VARCHAR(26), not null, foreign key to Channels(Id) with ON DELETE CASCADE
+- **Summary** — text, not null
+- **KeyTakeaways** — JSONB, nullable, array of strings
+- **ModelVersion** — VARCHAR(64), not null
+- **LastActivityAt** — bigint, not null
+- **UpdateAt** — bigint, not null
+
+### Table: ai_channel_summaries
+
+Rolling daily and weekly channel digests.
+
+Columns:
+- **Id** — VARCHAR(26), primary key
+- **ChannelId** — VARCHAR(26), not null, foreign key to Channels(Id) with ON DELETE CASCADE
+- **SummaryType** — VARCHAR(16), not null, one of: 'daily', 'weekly'
+- **Summary** — text, not null
+- **WindowStart** — bigint, not null
+- **WindowEnd** — bigint, not null
+- **CreateAt** — bigint, not null
+
+Constraints:
+- UNIQUE constraint on (ChannelId, SummaryType, WindowStart) to prevent duplicate summaries for the same window
+
+### Table: ai_entity_mentions
+
+Cross-channel entity linking for timeline queries.
+
+Columns:
+- **Id** — VARCHAR(26), primary key
+- **EntityName** — VARCHAR(255), not null, normalized to lowercase
+- **EntityType** — VARCHAR(32), nullable, one of: 'project', 'technology', 'person'
+- **PostId** — VARCHAR(26), not null, foreign key to Posts(Id) with ON DELETE CASCADE
+- **ChannelId** — VARCHAR(26), not null, foreign key to Channels(Id) with ON DELETE CASCADE
+- **ExtractionId** — VARCHAR(26), nullable, foreign key to ai_extractions(Id), nullable because the link is optional
+- **CreateAt** — bigint, not null
+
+Indexes:
+- Composite index on (EntityName, CreateAt) for timeline queries ordered by time
+
+### Table: ai_processing_log
+
+Work queue and idempotency tracker for async processing.
+
+Columns:
+- **Id** — VARCHAR(26), primary key
+- **PostId** — VARCHAR(26), not null
+- **JobType** — VARCHAR(32), not null, one of: 'embed', 'extract', 'summarize'
+- **SourceType** — VARCHAR(20), not null, default 'post', one of: 'post', 'file', 'summary'. Distinguishes whether the content to process comes from a post message, an attached file, or a generated summary.
+- **Status** — VARCHAR(16), not null, one of: 'pending', 'processing', 'complete', 'error'
+- **ScheduleAt** — bigint, nullable, for debounce timing
+- **ErrorMessage** — text, nullable
+- **RetryCount** — integer, default 0
+- **CreateAt** — bigint, not null
+- **CompleteAt** — bigint, nullable
+
+Constraints:
+- UNIQUE constraint on (PostId, JobType, SourceType) to prevent duplicate work items for the same post, job type, and content source. This three-column constraint allows a single post to have separate embed entries for the post message, each attached file, and a generated summary without conflict.
+
+Indexes:
+- Composite index on (Status, ScheduleAt) for worker polling queries that fetch pending items ordered by schedule time
+
+### Table: ai_query_log
+
+Audit trail for user queries. Write-only (no updates or deletes).
+
+Columns:
+- **Id** — VARCHAR(26), primary key
+- **UserId** — VARCHAR(26), not null, foreign key to Users(Id) with ON DELETE CASCADE
+- **QueryText** — text, not null
+- **ChannelIdsSearched** — JSONB, nullable, array of channel ID strings
+- **ResultCount** — integer, not null
+- **LatencyMs** — integer, not null
+- **CreateAt** — bigint, not null
+
+### Store interface
+
+Define a store interface (or set of interfaces) that abstracts all database operations. The interface should be designed for easy mocking in unit tests. Group methods logically:
+
+**Embedding operations:**
+- Save one or more embeddings for a post (batch insert for multiple chunks)
+- Delete embeddings by post ID (for reprocessing or cascade cleanup)
+- Soft-delete embeddings by post ID (set DeleteAt)
+- Search embeddings by vector similarity, filtered by a list of permitted channel IDs, excluding soft-deleted entries, returning top N results ordered by cosine similarity
+
+**Extraction operations:**
+- Save one or more extractions for a post
+- Get extraction by ID
+- List extractions filtered by channel ID and/or extraction type, excluding soft-deleted entries, with pagination
+- Update an extraction's content (for manual editing — sets IsEdited, EditorUserId, UpdateAt)
+- Soft-delete extractions by post ID
+- Delete extractions by post ID (hard delete for cascade)
+
+**Thread summary operations:**
+- Upsert a thread summary (insert or update by RootId)
+- Get thread summary by root ID
+- List thread summaries by channel ID within a time window (for channel summary generation)
+
+**Channel summary operations:**
+- Save a channel summary
+- Get the most recent channel summary by channel ID and type (daily/weekly)
+- List channel summaries by channel ID with optional type filter
+
+**Entity mention operations:**
+- Save one or more entity mentions for a post (batch insert)
+- Get entity timeline by name — list mentions across channels, filtered by permitted channel IDs, ordered by creation time, with pagination
+- Delete entity mentions by post ID
+
+**Processing log operations:**
+- Create a processing log entry (with idempotency — ignore if duplicate PostId+JobType+SourceType exists). Used for initial ingestion where skipping duplicates is correct.
+- Upsert a processing log entry — insert if no matching (PostId, JobType, SourceType) row exists, or reset an existing row's status to "pending" (clearing error message and resetting retry count) if one does exist. Used for post edits where reprocessing an already-completed entry is required.
+- Update status (pending → processing, processing → complete, processing → error with message)
+- List pending items ordered by schedule time (for worker polling)
+- Find stale items stuck in "processing" status for longer than a threshold duration
+- Reset stale items back to "pending"
+- Get processing stats (count by status) for the admin status endpoint
+
+**Query log operations:**
+- Insert a query log entry (write-only)
+- Get query stats for the admin status endpoint (count, average latency)
+
+**Data retention operations:**
+- Delete embeddings, extractions, entity mentions, and summaries whose source posts were created before a given timestamp, in batches up to a given size, returning the count of deleted rows
+
+### OnActivate integration
+
+Wire the schema migration and store initialization into the OnActivate lifecycle:
+1. After obtaining the database handle (from step 002), run the schema migration
+2. Create the store instance with the database handle
+3. Store the store instance on the Plugin struct (in the placeholder field from step 002)
+
+## Acceptance Criteria
+
+- [x] Plugin activation on a fresh database with pgvector available creates all 7 tables, the pgvector extension, all indexes, and all foreign key constraints without errors
+- [x] Plugin activation on a database where the tables already exist succeeds without errors (all CREATE statements are idempotent)
+- [x] Plugin activation fails with a descriptive error if the pgvector extension cannot be created (insufficient privileges or extension not installed)
+- [x] All table IDs use VARCHAR(26) and are generated via model.NewId()
+- [x] All timestamps are stored as bigint (Unix milliseconds)
+- [x] ai_embeddings and ai_extractions support soft delete via a DeleteAt column (0 = active, non-zero = deleted)
+- [x] ai_embeddings has an HNSW index on the Embedding column with vector_cosine_ops
+- [x] ai_processing_log enforces uniqueness on (PostId, JobType, SourceType) to prevent duplicate work items while allowing separate entries for the same post's message, attached files, and generated summaries
+- [x] ai_channel_summaries enforces uniqueness on (ChannelId, SummaryType, WindowStart) to prevent duplicate summaries
+- [x] Foreign keys from plugin tables to Posts, Channels, and Users use ON DELETE CASCADE
+- [x] Inserting a 768-dimensional vector into ai_embeddings and retrieving it via cosine similarity search returns the expected row
+- [x] Vector similarity search correctly filters by a list of channel IDs and excludes soft-deleted rows
+- [x] The processing log create operation is idempotent — inserting a duplicate (PostId, JobType, SourceType) does not produce an error or a second row
+- [x] The processing log upsert operation resets an existing entry's status to "pending" (clearing error, resetting retry count) when the entry already exists — used for reprocessing after post edits
+- [x] The processing log polling query returns pending items ordered by ScheduleAt
+- [x] Extraction listing filters correctly by channel ID and extraction type, excluding soft-deleted rows
+- [x] Thread summary upsert creates a new row on first call and updates the existing row on subsequent calls for the same RootId
+- [x] Entity timeline query returns mentions ordered by creation time, filtered by permitted channel IDs
+- [x] The data retention operation deletes rows in batches and returns the count of deleted rows
+- [x] The store interface is defined as a Go interface (or set of interfaces) that can be mocked for unit testing
+- [x] The store instance is created during OnActivate and stored on the Plugin struct
diff --git a/tasks/0001-org-memory-ai-knowledge-base/004.md b/tasks/0001-org-memory-ai-knowledge-base/004.md
new file mode 100644
index 000000000000..30436bbddc79
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/004.md
@@ -0,0 +1,123 @@
+# 004: Gemini client with resilience patterns
+
+## Context
+
+The Gemini client is the bridge between the plugin's processing logic and Google's AI services. Every core feature — embedding generation, knowledge extraction, thread summarization, and RAG synthesis — depends on this component. This step builds the client with four distinct operations behind a mockable interface, plus production-grade resilience (exponential backoff on rate limits, circuit breaker for sustained failures) with cluster-wide state sharing via the KV store. The client must be robust enough that transient Gemini API issues don't cascade into data loss or corrupt processing state.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/platform/services/remotecluster/service.go` (lines 103-122) — Reference HTTP client configuration: Transport with connection timeouts (30s dial, 30s keepalive), HTTP/2 support, idle connection management, TLS handshake timeout. This is the closest architectural match in the codebase for outbound HTTPS calls to external services.
+- `server/platform/services/remotecluster/sendmsg.go` (lines 143-173) — Shows context-with-timeout pattern for outbound requests: `context.WithTimeout()`, `http.NewRequest()`, `req.WithContext()`, status code error checking, `defer resp.Body.Close()`.
+- `server/channels/utils/backoff.go` — Existing progressive retry utility with predefined backoff timeout slices. Provides `ProgressiveRetry(operation)` and `CustomProgressiveRetry(operation, timeouts)`. Could be used as a reference for the exponential backoff implementation, though the Gemini client needs more control (e.g., response-code-specific behavior, jitter).
+- `server/public/pluginapi/kv.go` — KV store wrapper with `Set(key, value, ...options)`, `Get(key, &dest)`, `SetExpiry(ttl)`, and `SetAtomicWithRetries(key, valueFunc)`. The atomic retry function (5 attempts, 10ms between retries) is useful for safely updating shared circuit breaker state across cluster nodes.
+- `server/public/pluginapi/utils.go` — Additional backoff utilities available in the pluginapi package, similar to the core backoff patterns.
+- `server/enterprise/elasticsearch/opensearch/common.go` — Shows TLS configuration for external services and retry-on-status patterns (retry on 429, 502, 503, 504) as configuration for the Elasticsearch client.
+
+## Reuse Opportunities
+
+- **KV store atomic operations**: The `pluginapi.KV.SetAtomicWithRetries` method provides built-in compare-and-swap with retry logic, ideal for updating circuit breaker state without race conditions across cluster nodes.
+- **KV store TTL**: `pluginapi.KV.Set` with `SetExpiry(ttl)` can be used for rate limit backoff state that should auto-expire after the cooldown period.
+- **Backoff utility**: The `server/channels/utils/backoff.go` progressive retry pattern provides a starting point, but the Gemini client needs response-code-aware backoff (e.g., only retry on 429 and 5xx, not on 400 or 401) and doubling intervals rather than fixed schedules.
+- **Context timeout pattern**: All outbound HTTP calls in the codebase use `context.WithTimeout` — the Gemini client should follow this convention to ensure individual API calls have bounded latency.
+
+## Deliverables
+
+### Gemini client interface
+
+Define a Go interface for the Gemini client with four operations:
+
+**Generate embeddings** — Accepts a text string and returns a 768-dimensional float32 vector. The returned vector must be L2-normalized (unit magnitude). The client calls the gemini-embedding-001 model via the Google AI Go SDK, requesting the configured number of dimensions (768 by default). If the SDK returns a vector that is not already normalized, the client normalizes it before returning.
+
+**Extract knowledge** — Accepts conversation text (one or more messages assembled into a prompt) and returns a structured result containing zero or more extraction items. Each item has a type (decision, action_item, or topic), content text, and optional metadata (assignee for action items, confidence level). The client calls Gemini 2.5 Flash with a system prompt instructing the model to analyze the conversation and extract structured knowledge. The prompt design should yield parseable structured output (e.g., by requesting JSON output mode or using a structured extraction prompt format). This operation is used for individual post-level extraction during backfill (step 017) and for the processing worker's "extract" job type (step 007).
+
+**Summarize and extract (thread)** — Accepts conversation text (a full thread assembled as a multi-message prompt) and returns a combined result containing: a concise summary of the thread discussion (string), a list of key takeaways (important conclusions or outcomes, as an array of strings), and zero or more typed extraction items (decisions, action items, topics) with content and optional source post ID references. This is a single Gemini call that produces summary, takeaways, and extractions together, avoiding redundant calls. The client calls Gemini 2.5 Flash with a system prompt instructing the model to produce all three outputs in a single structured response. This operation is used by the thread debounce handler (step 008) and differs from "extract knowledge" in that it additionally produces a summary narrative and key takeaways alongside the structured extractions.
+
+**Synthesize answer (RAG)** — Accepts a user's natural language query, a list of context passages (each with a source identifier and content text), and optionally prior conversation history (for multi-turn). Returns a synthesized answer string with inline citation references (e.g., "[1]", "[2]") mapping to the provided source identifiers. The client calls Gemini 2.5 Flash with a system prompt that instructs the model to: answer only from the provided context, cite sources by reference number, and explicitly state when it cannot find relevant information rather than fabricating an answer.
+
+The interface must be mockable for unit testing — all four operations should be methods on the interface, not standalone functions.
+
+### Gemini client implementation
+
+Implement the interface using the `google.golang.org/genai` Go SDK:
+
+- Initialize the SDK client with the configured Gemini API key during plugin activation
+- Use the configured model names (GeminiModel for LLM tasks, EmbeddingModel for embeddings) from the plugin configuration
+- Each operation creates the appropriate request type for the SDK (embedding request vs. content generation request)
+- All SDK calls must use a Go context with a timeout (30 seconds for embedding, 60 seconds for extraction and synthesis) to prevent unbounded blocking
+
+The client must be reconfigurable when the plugin configuration changes (new API key, new model names) without requiring a full plugin restart. The OnConfigurationChange lifecycle (from step 002) should propagate updated values to the client.
+
+### L2 normalization
+
+The embedding operation must L2-normalize all returned vectors before they are used by callers. L2 normalization divides each component of the vector by the vector's magnitude (square root of the sum of squared components). This ensures cosine similarity calculations in pgvector produce correct results. The normalization should handle edge cases: zero vectors (all components zero) should be returned as-is without division by zero.
+
+### Exponential backoff on rate limits
+
+When the Gemini API returns an HTTP 429 (Too Many Requests) response, the client must:
+
+1. Not immediately retry the request
+2. Apply exponential backoff: start at 1 second, double on each consecutive 429 response, cap at 60 seconds
+3. Add jitter to the backoff duration (±20%) to prevent thundering herd effects across cluster nodes
+4. Store the current backoff state (next allowed request time) in the KV store with a TTL matching the backoff duration, so all cluster nodes respect the same cooldown
+5. Before making any Gemini API call, check the KV store for an active backoff period and fail fast with a "rate limited" error if within the backoff window
+6. Reset the backoff state after a successful API call
+
+### Circuit breaker
+
+Implement a circuit breaker pattern with three states:
+
+**Closed (normal operation)** — All requests pass through to the Gemini API. Track consecutive failure count.
+
+**Open (failing fast)** — After 5 consecutive failures (any error, not just 429), the breaker opens. While open, all Gemini API calls fail immediately with a "circuit open" error without making an actual API request. The breaker stays open for 30 seconds.
+
+**Half-open (testing)** — After the 30-second open period, the breaker transitions to half-open. The next request is allowed through as a test. If it succeeds, the breaker closes and resets the failure counter. If it fails, the breaker re-opens for another 30 seconds.
+
+Circuit breaker state (current state, failure count, last state transition time) must be stored in the KV store using atomic compare-and-swap operations so that all cluster nodes share a consistent view. When one node opens the breaker, all nodes should see it as open.
+
+### Error classification
+
+The client must classify Gemini API errors into categories that inform retry and circuit breaker behavior:
+
+- **Retryable errors**: HTTP 429 (rate limit), HTTP 500/502/503/504 (server errors), network timeouts, connection refused. These increment the circuit breaker failure counter and trigger backoff.
+- **Non-retryable errors**: HTTP 400 (bad request — likely a prompt issue), HTTP 401/403 (authentication — API key problem). These should be returned immediately to the caller without triggering the circuit breaker, since retrying won't help.
+- **Success**: Resets the backoff state and closes the circuit breaker if it was half-open.
+
+### OnActivate integration
+
+Wire the Gemini client into the plugin lifecycle:
+1. During OnActivate (after configuration is loaded), create the Gemini client with the configured API key and model names
+2. Store the client instance on the Plugin struct (in the placeholder field from step 002)
+3. If the API key is missing, activation already fails (from step 002); the Gemini client creation should also validate that the SDK initializes without errors
+
+### OnConfigurationChange integration
+
+When configuration changes:
+1. If the API key or model names have changed, reinitialize the Gemini SDK client with the new values
+2. The circuit breaker and backoff state should be preserved across reconfiguration (they are in the KV store, not in-memory)
+
+## Acceptance Criteria
+
+- [x] The Gemini client interface defines four operations: generate embeddings, extract knowledge, summarize and extract (thread), and synthesize answer
+- [x] The interface is a Go interface that can be mocked for unit testing
+- [x] Embedding generation calls the gemini-embedding-001 model and returns a 768-dimensional float32 vector
+- [x] Embedding vectors are L2-normalized — the magnitude of any returned vector equals 1.0 within floating-point tolerance
+- [x] L2 normalization handles zero vectors without panicking (division by zero)
+- [x] Knowledge extraction calls Gemini 2.5 Flash and returns typed extraction items (decision, action_item, topic) with content and optional metadata
+- [x] Thread summarize-and-extract calls Gemini 2.5 Flash and returns a combined result: summary text, key takeaways array, and typed extraction items in a single response
+- [x] RAG synthesis calls Gemini 2.5 Flash with a user query and context passages, and returns an answer with citation references
+- [x] RAG synthesis instructs the model to state when it cannot find relevant information rather than fabricating answers
+- [x] All Gemini API calls use a Go context with a timeout (30s for embeddings, 60s for LLM tasks)
+- [x] When the Gemini API returns HTTP 429, the client applies exponential backoff starting at 1 second, doubling up to 60 seconds, with ±20% jitter
+- [x] Backoff state is stored in the KV store so all cluster nodes respect the same cooldown
+- [x] Subsequent API calls during an active backoff period fail fast without making an actual API request
+- [x] After a successful API call, the backoff state is reset
+- [x] After 5 consecutive failures, the circuit breaker opens and all calls fail immediately without contacting the API
+- [x] The circuit breaker transitions to half-open after 30 seconds
+- [x] A successful request in half-open state closes the circuit breaker and resets the failure counter
+- [x] A failed request in half-open state re-opens the circuit breaker for another 30 seconds
+- [x] Circuit breaker state is stored in the KV store using atomic operations for cluster-wide consistency
+- [x] Non-retryable errors (HTTP 400, 401, 403) do not trigger the circuit breaker or backoff
+- [x] The Gemini client is created during OnActivate and stored on the Plugin struct
+- [x] Configuration changes (new API key or model names) reinitialize the SDK client without losing circuit breaker state
diff --git a/tasks/0001-org-memory-ai-knowledge-base/005.md b/tasks/0001-org-memory-ai-knowledge-base/005.md
new file mode 100644
index 000000000000..8deb4e1270b3
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/005.md
@@ -0,0 +1,121 @@
+# 005: Chunking engine
+
+## Context
+
+Every post that enters the processing pipeline must be split into embeddable chunks before the Gemini client can generate vector embeddings. Raw posts range from a single sentence to the maximum 4000 runes (or 65535 bytes in v2), and file attachments can be far larger. The chunking engine sits between event ingestion (step 006) and the embedding/extraction worker (step 007): the worker fetches a post's content, passes it through the chunker to get a list of sized, overlapping text segments, and then sends each segment to the Gemini client (step 004) for embedding. The design prioritizes semantic coherence — chunks should break at paragraph and sentence boundaries rather than at arbitrary character counts — so that each embedded vector represents a meaningful unit of text that the RAG engine (step 009) can return as a useful citation.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/shared/markdown/paragraph.go` — Mattermost's markdown paragraph parser. Produces `Paragraph` blocks containing `Text []Range` (byte position ranges within the original markdown string). Part of the full markdown AST that decomposes content into blocks: paragraphs, lists, block quotes, fenced code blocks, etc.
+- `server/public/shared/markdown/inspect.go` — Provides `Inspect(markdown string, f func(any) bool)` for depth-first traversal of the full markdown AST. Also provides `InspectBlock` and `InspectInline` for targeted traversal. Has a built-in max scanning length of 128KB (`maxLen = 1024 * 64 * 2`).
+- `server/public/shared/markdown/inlines.go` — Defines inline elements within paragraphs: `Text`, `CodeSpan`, `SoftLineBreak`, `HardLineBreak`, `InlineLink`, `InlineImage`. Provides `MergeInlineText(inlines []Inline) []Inline` for consolidating adjacent text nodes and `ParseInlines` for converting ranges to typed inline elements.
+- `server/public/shared/markdown/lines.go` — `ParseLines(markdown string) []Line` splits raw markdown into lines on `\n` and `\r` boundaries. Each `Line` has a `Range` with start `Position` and `End` byte offsets.
+- `server/channels/utils/markdown.go` — `StripMarkdown(markdown string) (string, error)` converts Mattermost-flavored markdown to plain text using the goldmark parser. Also provides `StripMarkdownAndDecode` for HTML entity decoding.
+- `server/public/model/utils.go` — `LimitRunes(s string, maxRunes int) (string, bool)` truncates text to a maximum rune count and returns whether truncation occurred. `LimitBytes(s string, maxBytes int) (string, bool)` does the same for byte count. Both handle UTF-8 correctly.
+- `server/public/model/post.go` — Post message size limits: `PostMessageMaxRunesV1 = 4000`, `PostMessageMaxBytesV2 = 65535`. The `Post` struct carries `Message` (rendered content) and `MessageSource` (unmodified content for editing). `FileIds StringArray` links to attached files.
+- `server/platform/services/docextractor/` — Document content extraction: `Extractor` interface with `Match(filename)`, `Extract(filename, reader, maxSize)`. Extractors exist for plain text (with Unicode validation), PDF, Office documents (DOC, DOCX, PPTX, ODT), HTML, and archives. The plain extractor validates that content contains only graphic Unicode characters and whitespace.
+- `server/public/shared/markdown/markdown.go` — Low-level character classification: `isWhitespace(c rune)`, `isWord(c rune)`, `nextNonWhitespace(markdown, position)`, `nextLine(markdown, position)`. Used internally by the markdown parser for boundary detection.
+
+## Reuse Opportunities
+
+- **StripMarkdown** from `server/channels/utils/markdown.go` can convert Mattermost-formatted messages into plain text before chunking. This removes formatting noise (bold markers, link syntax, heading markers) that would otherwise dilute embedding quality. The chunker should strip markdown from post content as a preprocessing step.
+- **Mattermost markdown parser** can be used to identify block-level boundaries (paragraphs, list items, code blocks, block quotes) within post content before falling back to character-level splitting. The `Inspect` traversal plus `Paragraph` block detection provides structural awareness of the content.
+- **LimitRunes** provides safe UTF-8-aware truncation when a final chunk exceeds the target size after merging. This avoids splitting multi-byte characters at byte boundaries.
+- **Document extractors** in `server/platform/services/docextractor/` handle file content extraction for attached documents. The chunking engine should accept pre-extracted text from these extractors as input alongside the post message text.
+- **Rune counting** via `utf8.RuneCountInString` is used consistently throughout the codebase for text length measurement. The chunker should use rune counting (as a proxy for token counting) rather than byte counting, since rune count more closely approximates token count for most text.
+
+## Deliverables
+
+### Chunk result type
+
+Define a result type that represents a single chunk of text ready for embedding. Each chunk must carry:
+
+- The text content of the chunk (plain text, markdown stripped)
+- The sequential chunk index (0-based) indicating the chunk's position within the original content
+- The byte offset range within the original content that this chunk was derived from, so that citation display can map a matched chunk back to its approximate location in the source
+
+The chunking function returns a slice of these chunk results.
+
+### Chunking function
+
+Implement the main chunking function that accepts a text string and configuration parameters (target chunk size in approximate tokens, overlap percentage, maximum chunks) and returns an ordered slice of chunk results. The function implements the following algorithm:
+
+**Step 1: Preprocessing** — Strip markdown formatting from the input to produce clean plain text. Collapse multiple consecutive whitespace characters (including newlines beyond paragraph breaks) into single spaces within paragraphs. Trim leading and trailing whitespace from the full text. If the input is empty or whitespace-only after preprocessing, return an empty slice.
+
+**Step 2: Paragraph splitting** — Split the preprocessed text at paragraph boundaries (sequences of two or more consecutive newlines). Each resulting segment is a candidate paragraph. Preserve the relative ordering of paragraphs.
+
+**Step 3: Sentence splitting for oversized paragraphs** — For any paragraph that exceeds the target chunk size, further split it at sentence boundaries. A sentence boundary is defined as a period, exclamation mark, or question mark followed by whitespace and an uppercase letter, or followed by end-of-string. This heuristic handles common prose while avoiding false splits on abbreviations (e.g., "e.g.", "Dr.", "U.S.") by requiring the subsequent uppercase letter. If a single sentence still exceeds the target chunk size, it remains as-is (it will become an oversized chunk rather than being split mid-word).
+
+**Step 4: Merging small segments** — Iterate through the segments produced by steps 2 and 3. Merge consecutive small segments into a single chunk as long as the combined text does not exceed the target chunk size. When adding the next segment would exceed the target, finalize the current chunk and start a new one with the next segment. This ensures that short paragraphs and sentences are grouped together into reasonably-sized chunks rather than producing many tiny embeddings.
+
+**Step 5: Overlap insertion** — For each pair of adjacent chunks (chunk N and chunk N+1), prepend the last portion of chunk N to chunk N+1. The overlap size is calculated as a percentage (default 10%) of the target chunk size in approximate tokens. The overlap text is taken from the end of the preceding chunk, split at a word boundary to avoid cutting words. This preserves context across chunk boundaries so that information spanning a boundary can still be found by vector search on either adjacent chunk.
+
+**Step 6: Truncation** — If the total number of chunks exceeds the configured maximum (MaxChunksPerPost from the plugin configuration, default 32), truncate the list to the maximum count. Log a warning message including the original text length and the number of chunks that were discarded so administrators can tune the configuration if needed.
+
+**Step 7: Index assignment** — Assign sequential 0-based chunk indices to each chunk in the final list. These indices are stored alongside the embedding in the database (ChunkIndex column in ai_embeddings) and used for ordering when reconstructing content for citation display.
+
+### Token estimation
+
+The chunking engine needs to estimate token counts for text segments without calling the Gemini tokenizer API (which would add latency and API cost). Implement a token estimation function that approximates the token count of a text string. The estimation should use the heuristic that one token equals approximately 4 characters (runes) for English text, which is a widely-accepted approximation for modern language models. The estimation function is used for:
+
+- Determining whether a paragraph exceeds the target chunk size
+- Calculating the merge threshold during the segment merging step
+- Calculating the overlap size (10% of target chunk size)
+
+The target chunk size in the configuration is specified in approximate tokens (default ~500 tokens, which corresponds to roughly 2000 characters). The estimation need not be exact — it serves as a sizing heuristic, and slight over- or under-shooting is acceptable since the embedding model handles variable-length inputs.
+
+### File content integration
+
+The chunking engine must handle two input sources:
+
+**Post messages** — The primary input. The chunker receives the post's `Message` field content, strips markdown, and produces chunks as described above.
+
+**File attachment text** — When a post has file attachments with extracted text content (from Mattermost's built-in document extraction or the plugin's own extraction), the chunker receives the extracted text as a separate input. File content is chunked independently from the post message, with its own sequence of chunk indices. The caller (the processing worker in step 007) is responsible for setting the `SourceType` field on the resulting embeddings to distinguish post-derived chunks from file-derived chunks.
+
+The chunking function itself is source-agnostic — it accepts text and returns chunks. The caller determines the source type and passes it through when storing embeddings.
+
+### Edge case handling
+
+The chunking engine must handle the following edge cases gracefully:
+
+- **Empty input**: Return an empty slice, no error
+- **Whitespace-only input**: Return an empty slice after preprocessing strips all content
+- **Input shorter than target chunk size**: Return a single chunk containing the entire text (no splitting needed)
+- **Single very long sentence with no sentence boundaries**: Return as a single oversized chunk (do not split mid-word). If it exceeds the target size, it is still a valid chunk — the embedding model can handle variable-length inputs.
+- **Content that is entirely a code block**: Treat code blocks as opaque text segments — do not attempt sentence splitting within code. Code blocks from the markdown parser should be kept as atomic units during paragraph-level splitting.
+- **Unicode content**: All text processing must be Unicode-aware, using rune iteration rather than byte indexing. The token estimation heuristic (4 chars per token) applies to rune counts, not byte counts.
+- **Content with markdown tables**: Tables should be preserved as atomic segments during paragraph splitting, since splitting a table row from its header would produce meaningless chunks.
+- **Extremely long content (e.g., large file extractions)**: Apply the maximum chunk limit to prevent runaway memory usage. After truncation, the chunks still represent the beginning of the content, which is often the most relevant portion.
+
+### Configuration integration
+
+The chunking engine reads three configuration values from the plugin configuration (step 002):
+
+- **MaxChunksPerPost** — The hard cap on chunks produced per input text (default 32). Used in the truncation step.
+- **Target chunk size** — Not a separate configuration field; derived from the embedding model's practical limits. Use a constant of approximately 500 tokens (~2000 characters) as the target. This balances embedding quality (too-small chunks lose context) against retrieval precision (too-large chunks dilute the embedding signal).
+- **Overlap percentage** — Not a separate configuration field; use a constant of 10%. This provides cross-boundary context without excessive duplication.
+
+The target chunk size and overlap percentage are compile-time constants rather than configuration fields because they are tuned to the embedding model's characteristics and changing them requires understanding embedding quality trade-offs. MaxChunksPerPost is user-configurable because it affects resource consumption (API calls, storage) rather than embedding quality.
+
+## Acceptance Criteria
+
+- [x] The chunking function accepts a text string and returns an ordered slice of chunk results, each containing the chunk text, a sequential 0-based index, and byte offset information
+- [x] Markdown formatting is stripped from input text before chunking, producing clean plain text for embedding
+- [x] Text is split at paragraph boundaries (double newlines) as the primary segmentation strategy
+- [x] Paragraphs exceeding the target chunk size (~500 tokens) are further split at sentence boundaries (period/exclamation/question mark followed by whitespace and uppercase letter)
+- [x] Consecutive small segments are merged together until the combined text approaches the target chunk size
+- [x] Adjacent chunks have approximately 10% overlap — the end of chunk N is prepended to chunk N+1
+- [x] Overlap text is split at word boundaries to avoid cutting words
+- [x] The total number of chunks is capped at MaxChunksPerPost (default 32), with excess chunks truncated and a warning logged
+- [x] Token count estimation uses a rune-based heuristic (approximately 4 characters per token) without calling the Gemini tokenizer API
+- [x] Empty input returns an empty slice without error
+- [x] Whitespace-only input returns an empty slice after preprocessing
+- [x] Input shorter than the target chunk size returns a single chunk containing the entire text
+- [x] A single long sentence without sentence boundaries is returned as one oversized chunk (no mid-word splitting)
+- [x] Code blocks are treated as atomic segments during paragraph splitting and are not split at sentence boundaries
+- [x] All text processing is Unicode-aware, using rune counts rather than byte counts for length estimation
+- [x] The chunking function is deterministic — identical input always produces identical output
+- [x] Chunk indices are sequential starting from 0 and correspond to the chunk's position in the original content
+- [x] The chunking function is a pure function (no side effects, no database access, no API calls) that can be unit tested in isolation
diff --git a/tasks/0001-org-memory-ai-knowledge-base/006.md b/tasks/0001-org-memory-ai-knowledge-base/006.md
new file mode 100644
index 000000000000..227e55abb612
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/006.md
@@ -0,0 +1,137 @@
+# 006: Event ingestion hooks
+
+## Context
+
+The event ingestion layer is the real-time entry point for all content flowing into the knowledge base. Every post created, edited, or deleted in Mattermost passes through a corresponding plugin hook, and this step implements the handlers that decide what to do with each event. The ingestion hooks do not perform any heavy processing themselves — they make a quick eligibility check (skip bots, system messages, disabled teams), write a lightweight processing log entry to the database (step 003), and schedule or cancel debounce timers (step 008). The actual embedding, extraction, and summarization work is deferred to the background workers (steps 007 and 008), keeping the hook handlers fast and non-blocking. This separation is critical because hooks run synchronously in the Mattermost server's request path — a slow hook degrades the entire server's responsiveness.
+
+This step also handles file upload interception and user deactivation cleanup, completing the full set of event-driven entry points that feed the processing pipeline.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/plugin/hooks.go` — Defines all hook signatures. The relevant hooks for this step are: `MessageHasBeenPosted(c *Context, post *model.Post)`, `MessageHasBeenUpdated(c *Context, newPost, oldPost *model.Post)`, `MessageHasBeenDeleted(c *Context, post *model.Post)`, `FileWillBeUploaded(c *Context, info *model.FileInfo, file io.Reader, output io.Writer) (*model.FileInfo, string)`, and `UserHasBeenDeactivated(c *Context, user *model.User)`.
+- `server/public/pluginapi/post.go` (lines 270-337) — `ShouldProcessMessage(post, ...options)` is a built-in helper that checks whether a post should be processed by a plugin. By default it skips system messages, webhook posts, and bot users. It also supports options for channel ID filtering and bot DM filtering. This is the primary eligibility check the hooks should use.
+- `server/public/model/post.go` — Post struct with key fields: `RootId` (non-empty for threaded replies, identifies the thread root), `UserId`, `ChannelId`, `Message`, `FileIds` (string array of attached file IDs), `Type` (system message prefix check via `IsSystemMessage()`), and properties `PostPropsFromBot` and `PostPropsFromWebhook`.
+- `server/public/model/file_info.go` — `FileInfo` struct with `Id`, `PostId`, `ChannelId`, `Name`, `Extension`, `MimeType`, `Size`, and `Content` (extracted text content, not sent to client). The `Content` field may already be populated by Mattermost's built-in document extraction.
+- `server/public/pluginapi/cluster/job_once_scheduler.go` — `GetJobOnceScheduler(pluginAPI)` returns the singleton scheduler. `SetCallback(func(key string, props any))` registers the handler that fires when a scheduled job executes. `ScheduleOnce(key, runAt, props)` schedules a one-time job (fails if the key already exists — must Cancel first to reschedule). `Cancel(key)` removes a scheduled job. Props are serialized as JSON with a max size of 10KB.
+- `server/channels/app/post.go` (lines 404-414) — Shows how the Mattermost server invokes `MessageHasBeenPosted` asynchronously via `a.Srv().Go(func() { ... })`. This confirms hooks run in a separate goroutine from the request handler, but they still block the hook dispatch pipeline for other plugins.
+- `server/public/plugin/api.go` — Plugin API methods needed by the hooks: `GetChannel(channelId)` to resolve team membership for team-level enablement checks, `GetFileInfo(fileId)` to retrieve file metadata, `GetFile(fileId)` to retrieve raw file bytes when built-in extraction is unavailable, `GetPost(postId)` for fetching the full post when needed.
+- `server/platform/services/docextractor/` — Document extraction implementations: plain text extractor (with Unicode validation), PDF extractor, Office document extractor (DOC, DOCX, PPTX, ODT, HTML, RTF). The `Extractor` interface defines `Match(filename) bool` and `Extract(filename, reader, maxSize) (string, error)`. These can be used to extract text from attached files when `FileInfo.Content` is empty.
+
+## Reuse Opportunities
+
+- **ShouldProcessMessage** from `pluginapi/post.go` handles the most common eligibility checks (skip bots, system messages, webhooks) out of the box. The hooks should call this first and return early if it says to skip. This avoids reimplementing bot detection logic and stays consistent with other Mattermost plugins.
+- **JobOnceScheduler** is the cluster-safe mechanism for thread debounce. The cancel-then-reschedule pattern (cancel the existing debounce timer for a thread, then schedule a new one with a fresh future time) is exactly the pattern this step needs for the thread debounce trigger. The scheduler's singleton nature means only one callback is registered — this step sets up the callback, and step 008 implements the callback's dispatch logic.
+- **Document extractors** from `server/platform/services/docextractor/` can be used to extract text from file attachments when Mattermost's built-in extraction hasn't populated the `FileInfo.Content` field. The plugin can instantiate the appropriate extractor based on the file extension and extract text content for embedding.
+- **Channel lookup via GetChannel** provides the `TeamId` field needed to check whether a post belongs to an enabled team. The channel is fetched once per hook invocation and the team ID is compared against the plugin's configured enabled team list.
+- **Post.RootId** provides thread identification without additional API calls. If `RootId` is non-empty, the post is a reply in a thread and the `RootId` is the thread root's post ID. If `RootId` is empty, the post is itself a root post, and its `Id` serves as the thread key.
+
+## Deliverables
+
+### MessageHasBeenPosted hook
+
+Implement the handler for new messages. When a post is created:
+
+1. **Eligibility check** — Call `ShouldProcessMessage` to skip bot posts, system messages, and webhook posts. Return immediately if the post should not be processed.
+
+2. **Team enablement check** — Resolve the post's channel to get the team ID. Check whether the team is in the plugin's enabled teams list (from configuration, step 002). If the team is not enabled, return immediately. If the enabled teams list is empty (meaning all teams are enabled), skip this check.
+
+3. **Create processing log entry** — Insert a new row into the `ai_processing_log` table (step 003) with status "pending", job type "embed", source type "post", the post's ID, channel ID, and current timestamp as the scheduled time. This entry tells the embedding worker (step 007) that this post needs embedding.
+
+   **Design note — embed only, no extract:** Real-time ingestion creates only "embed" entries, not "extract" entries. Knowledge extraction (decisions, action items, topics) happens at the thread level via the debounce summarization handler (step 008), not per individual post. Individual post-level extraction entries are only created during historical backfill (step 017) for posts that are not part of multi-message threads. This avoids redundant extraction — a single thread-level extraction with full conversation context produces higher-quality results than per-post extraction in isolation.
+
+4. **Trigger thread debounce** — Determine the thread root ID: use `Post.RootId` if non-empty, otherwise use `Post.Id` (the post is itself a thread root). Cancel any existing debounce job for this thread root (using the key pattern `debounce:{rootId}`), then schedule a new one-time job via the `JobOnceScheduler` set to fire after the configured debounce interval (from the plugin configuration's debounce seconds setting). The job's props should include the thread root ID and channel ID so the debounce handler (step 008) knows which thread to summarize.
+
+5. **File content extraction** — If the post has attached files (`FileIds` is non-empty), iterate over each file ID. For each file, retrieve the `FileInfo` to check whether extracted text content is already available in the `Content` field. If content is available, create an additional processing log entry with job type "embed" and source type "file" for the file's content. If content is not available, retrieve the raw file bytes via the plugin API, attempt text extraction using the document extractors (matching by file extension), and if successful, create the processing log entry for the extracted text. If extraction fails or the file type is unsupported, skip that file silently (log at debug level).
+
+### MessageHasBeenUpdated hook
+
+Implement the handler for edited messages. When a post is updated:
+
+1. **Eligibility check** — Same as the posted hook: call `ShouldProcessMessage` on the new post to check if it should be processed. Return immediately if not.
+
+2. **Team enablement check** — Same as the posted hook.
+
+3. **Mark for reprocessing** — Check whether the post's message content actually changed by comparing `newPost.Message` to `oldPost.Message`. If the content is identical (e.g., only metadata changed), return without action. If the content changed, use the store's **upsert** operation (not the idempotent create) to insert a processing log entry with status "pending", job type "embed", and source type "post". The upsert resets an existing entry's status to "pending" even if it was previously "complete", ensuring the edited post gets reprocessed. This is distinct from the idempotent create used for initial ingestion, which skips entries that already exist.
+
+4. **Re-trigger thread debounce** — An edit to a message in a thread may change the thread's summary. Follow the same debounce cancel-and-reschedule pattern as the posted hook.
+
+### MessageHasBeenDeleted hook
+
+Implement the handler for deleted messages. When a post is deleted:
+
+1. **Cancel pending processing** — Cancel any pending debounce job for the deleted post's thread. If the deleted post is a thread root (`RootId` is empty), cancel the debounce job keyed to the post's own ID. If it's a reply, cancel-and-reschedule the debounce for the parent thread (the thread still exists, just lost one message, so its summary should be regenerated).
+
+2. **Clean up derived data** — Call the store's delete methods to remove all embeddings, extractions, and entity mentions associated with the deleted post's ID. The database schema (step 003) uses ON DELETE CASCADE from the Posts table, so if the post row is deleted by Mattermost core, the cascade handles cleanup automatically. However, the hook should also explicitly delete derived data as a defense-in-depth measure, since the cascade depends on foreign key constraints which may not exist if the plugin's tables use a different ID scheme than direct FK references.
+
+3. **Update processing log** — Mark any pending or in-progress processing log entries for the deleted post as "complete" (nothing to do), preventing the worker from attempting to process a post that no longer exists.
+
+### FileWillBeUploaded hook
+
+Implement the handler for file uploads. This hook fires before the file is committed to storage, giving the plugin access to the file content stream:
+
+1. **Content extraction opportunity** — Read the file content from the provided `io.Reader` and attempt text extraction using the document extractors. If extraction succeeds, store the extracted text in a plugin-scoped KV store entry keyed by the file ID, so that when the corresponding `MessageHasBeenPosted` hook fires for the post containing this file, the extracted text is available without a second file read.
+
+2. **Pass-through behavior** — This hook must not reject or modify the file upload. Return `nil` for the modified FileInfo and an empty string for the rejection reason, allowing the upload to proceed normally. The plugin is only observing, not gatekeeping.
+
+3. **Size and type guard** — Only attempt extraction for files under a reasonable size threshold (e.g., 10MB) and for supported file types (text, PDF, Office documents). For unsupported types or oversized files, skip extraction silently and let the `MessageHasBeenPosted` hook handle what it can.
+
+### UserHasBeenDeactivated hook
+
+Implement the handler for user deactivation:
+
+1. **Clean up conversation sessions** — Delete all multi-turn conversation session entries from the KV store for the deactivated user. Sessions are keyed by user ID plus session identifier (from step 009), so the cleanup should use `KVList` with a prefix matching the user's ID pattern and delete each matching entry.
+
+2. **Preserve knowledge content** — Do not delete any embeddings, extractions, summaries, or other knowledge base content created from the user's posts. The knowledge belongs to the conversation context, not the individual user. Other users' RAG queries may depend on this content.
+
+### JobOnceScheduler initialization
+
+During plugin activation (OnActivate, extending step 002), set up the one-time job scheduler:
+
+1. **Get the singleton scheduler** — Call `GetJobOnceScheduler` with the plugin API to obtain the shared scheduler instance.
+
+2. **Register the callback** — Call `SetCallback` with a dispatcher function that inspects the job key prefix to determine which handler to invoke. Jobs with the `debounce:` prefix are dispatched to the thread debounce handler (implemented in step 008). Jobs with the `backfill:` prefix are dispatched to the backfill handler (implemented in step 017). Unrecognized prefixes are logged as warnings and ignored.
+
+3. **Start the scheduler** — Call `Start()` to begin polling for scheduled jobs. This must happen after `SetCallback` and before any hooks fire, so it should be one of the last initialization steps in OnActivate.
+
+4. **Shutdown** — During OnDeactivate (extending step 002), cancel all pending scheduled jobs and stop the scheduler to prevent jobs from firing after the plugin has shut down. List all scheduled jobs via `ListScheduledJobs()` and cancel each one.
+
+### Enabled teams resolution
+
+The team enablement check used by the message hooks needs efficient access to the configured team list:
+
+1. **Parse on configuration change** — When the plugin configuration changes (OnConfigurationChange from step 002), parse the comma-separated enabled team IDs string into a set (map) for O(1) lookup. Store this set on the Plugin struct.
+
+2. **Empty means all** — If the enabled teams configuration is empty or not set, the plugin processes posts from all teams. The hooks should check for this case and skip the team lookup entirely.
+
+3. **Channel-to-team resolution** — For each post, the hook needs to know which team owns the channel. Call `GetChannel(channelId)` to retrieve the channel's `TeamId`. For direct message channels (which have an empty TeamId), always process them regardless of team configuration, since DMs are cross-team.
+
+## Acceptance Criteria
+
+- [x] MessageHasBeenPosted hook skips bot posts, system messages, and webhook posts using `ShouldProcessMessage`
+- [x] MessageHasBeenPosted hook skips posts from teams not in the enabled teams list (when the list is non-empty)
+- [x] MessageHasBeenPosted hook creates a processing log entry with "pending" status and "embed" job type for each new post
+- [x] MessageHasBeenPosted hook determines the thread root ID (Post.RootId if non-empty, otherwise Post.Id) for debounce scheduling
+- [x] MessageHasBeenPosted hook cancels any existing debounce job for the thread root and schedules a new one at the configured debounce interval in the future
+- [x] MessageHasBeenPosted hook creates processing log entries for file attachments when extractable text content is available
+- [x] MessageHasBeenPosted hook attempts document extraction for file attachments when the FileInfo.Content field is empty, using supported extractors
+- [x] MessageHasBeenPosted hook creates processing log entries with source type "post" for the post message and source type "file" for each file attachment, using the idempotent create operation (skip if exists)
+- [x] Real-time ingestion creates only "embed" job type entries, not "extract" — knowledge extraction is handled at the thread level by the debounce handler (step 008)
+- [x] MessageHasBeenUpdated hook only creates reprocessing entries when the post message content actually changed (compares newPost.Message to oldPost.Message)
+- [x] MessageHasBeenUpdated hook uses the store's upsert operation (not idempotent create) to reset existing "complete" entries back to "pending" for reprocessing
+- [x] MessageHasBeenUpdated hook re-triggers the thread debounce when content changes
+- [x] MessageHasBeenDeleted hook cancels the debounce job for a deleted thread root post
+- [x] MessageHasBeenDeleted hook reschedules the debounce for the parent thread when a reply is deleted (the thread still exists but its content changed)
+- [x] MessageHasBeenDeleted hook removes all derived data (embeddings, extractions, entity mentions) for the deleted post
+- [x] MessageHasBeenDeleted hook marks pending processing log entries for the deleted post as "complete"
+- [x] FileWillBeUploaded hook extracts text content from supported file types and stores it in the KV store keyed by file ID
+- [x] FileWillBeUploaded hook never rejects or modifies the file upload — always returns nil FileInfo and empty rejection string
+- [x] FileWillBeUploaded hook skips extraction for unsupported file types and files exceeding the size threshold
+- [x] UserHasBeenDeactivated hook deletes all multi-turn conversation sessions for the deactivated user from the KV store
+- [x] UserHasBeenDeactivated hook does not delete any knowledge base content (embeddings, extractions, summaries) belonging to the user's posts
+- [x] The JobOnceScheduler is initialized during OnActivate with a callback that dispatches jobs by key prefix
+- [x] The JobOnceScheduler is shut down during OnDeactivate (all pending jobs cancelled, scheduler stopped)
+- [x] Direct message channels (empty TeamId) are always processed regardless of the enabled teams configuration
+- [x] All hook handlers return quickly — no Gemini API calls, no heavy computation, only database writes and scheduler operations
+- [x] File extraction failures are logged at debug level and do not prevent the post from being processed
diff --git a/tasks/0001-org-memory-ai-knowledge-base/007.md b/tasks/0001-org-memory-ai-knowledge-base/007.md
new file mode 100644
index 000000000000..acf15e82c7d6
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/007.md
@@ -0,0 +1,167 @@
+# 007: Processing worker for embedding and extraction
+
+## Context
+
+The event ingestion hooks (step 006) write lightweight "pending" entries to the `ai_processing_log` table but perform no AI processing. This step builds the background worker that drains that queue — a recurring job that polls for pending items, acquires a distributed lock per post to prevent duplicate work across cluster nodes, calls the Gemini client (step 004) via the chunking engine (step 005) to generate embeddings and extract knowledge, stores results in the database (step 003), and updates the processing log status. The worker must be resilient to crashes, API failures, and cluster topology changes. If a worker node dies mid-processing, another node must detect the stale item and recover it. If the Gemini API is unavailable (circuit breaker open), the worker must back off gracefully without consuming resources.
+
+This is the engine that converts raw posts into searchable knowledge. Every embedding, every extraction, and every entity mention flows through this worker. Its throughput and reliability directly determine how quickly new content becomes queryable and how much data is lost during failures.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/pluginapi/cluster/job.go` — `Schedule(pluginAPI, key, nextWaitInterval, callback)` creates a recurring job backed by a distributed mutex. `MakeWaitForInterval(duration)` creates a wait function that fires at fixed intervals relative to last completion. The job loop acquires the mutex, reads metadata from KV store, checks if it's time to run, executes the callback, and updates the `LastFinished` timestamp. The callback runs holding the cluster mutex, so only one node executes per interval.
+- `server/public/pluginapi/cluster/mutex.go` — `NewMutex(pluginAPI, key)` creates a distributed mutex. `Lock()` blocks with exponential backoff (1s-5min, ±500ms jitter) until the mutex is acquired. `Unlock()` releases via KV store deletion. TTL is 15 seconds, refreshed every 7.5 seconds while held. If a node crashes while holding the lock, the TTL expires and another node can acquire it.
+- `server/public/pluginapi/cluster/wait.go` — Backoff and jitter utilities used internally by the cluster package: `nextWaitInterval` doubles on error and resets on success, `addJitter()` adds ±500ms randomization. These patterns should inform the worker's own polling interval behavior.
+- `server/channels/jobs/jobs_watcher.go` — Mattermost's core job watcher pattern: a goroutine that polls the database on a fixed interval, queries for pending jobs, and distributes them to workers. Uses `time.After` with jitter for the poll interval. Default polling interval is 15 seconds. The worker should follow this general pattern but at a faster cadence (1 second) since embedding latency is the primary bottleneck.
+- `server/channels/jobs/simple_worker.go` — The core `SimpleWorker` implementation: receive job from channel, claim it with optimistic locking (pending → in-progress status transition), execute the work, set success or error status. This claim-execute-complete pattern is exactly what the processing worker needs.
+- `server/channels/jobs/jobs.go` (lines 211-247) — `UpdateInProgressJobData` uses `LastActivityAt` timestamps as heartbeats. `HandleJobPanic` recovers from panics, captures goroutine stack trace, sets job status to error, then re-panics. The processing worker should implement both patterns — heartbeat for stale detection and panic recovery for crash safety.
+- `server/public/pluginapi/cluster/job_once.go` (lines 14-37) — Retry logic with failure limits: `maxNumFails = 3`, increment counter on each failure, give up after exceeding the limit. This maps directly to the processing log's retry counter behavior.
+- `server/public/pluginapi/log.go` — Plugin logging: `LogError(msg, keyValuePairs...)`, `LogWarn`, `LogInfo`, `LogDebug`. Key-value pairs are alternating string keys and typed values. Used throughout the cluster package for structured logging.
+
+## Reuse Opportunities
+
+- **cluster.Schedule with MakeWaitForInterval** is the primary mechanism for the recurring worker. Schedule a job with a 1-second interval that fires the worker's poll-and-process cycle. The cluster scheduling already handles distributed coordination — only one node runs the worker at a time, and the mutex automatically failover if a node crashes.
+- **cluster.Mutex** provides per-post locking. Within each poll cycle, the worker queries for pending items, then attempts to acquire a mutex keyed to each post's ID before processing it. If another node's worker is already processing the same post (e.g., after a race condition during failover), the mutex prevents duplicate work. The 15-second TTL provides automatic recovery if the lock holder crashes.
+- **SimpleWorker claim pattern** from the core jobs system (pending → in-progress → complete/error) maps directly to the processing log's status field. The worker updates status to "processing" after acquiring the mutex (claim), performs the work, then updates to "complete" or increments the retry counter and returns to "pending" (on failure) or marks as "error" (after max retries).
+- **HandleJobPanic pattern** should be adapted for the worker's per-item processing loop. Wrap each item's processing in a deferred panic recovery that logs the stack trace and marks the item as errored, preventing a single bad input from crashing the entire worker loop.
+- **Structured logging** from the cluster package (alternating key-value pairs) should be used consistently for all worker log messages, including post ID, job type, processing duration, and error details for each item.
+
+## Deliverables
+
+### Worker initialization and lifecycle
+
+Create a recurring background worker using `cluster.Schedule` that starts during plugin activation (OnActivate, extending steps 002 and 006) and stops during deactivation:
+
+1. **Schedule the worker** — Call `cluster.Schedule` with a 1-second interval (`MakeWaitForInterval(1 * time.Second)`) and the worker's main callback function. Store the returned `*Job` handle on the Plugin struct for shutdown.
+
+2. **Shutdown** — During OnDeactivate, call `Close()` on the job handle to stop the recurring schedule. The worker should finish processing the current item (if any) before stopping. Do not cancel mid-processing — let the current item complete to avoid leaving it in a "processing" state.
+
+3. **Plugin struct integration** — Store the worker's job handle alongside the other scheduler handles (from step 006) so that all background jobs can be shut down together during deactivation.
+
+### Poll-and-process cycle
+
+Each time the recurring worker fires (every ~1 second, coordinated by the cluster scheduler), it executes one poll-and-process cycle:
+
+1. **Check circuit breaker** — Before querying for pending items, check whether the Gemini circuit breaker is open (step 004). If the circuit breaker is open, skip this cycle entirely and return. This prevents the worker from claiming items it can't process, which would just increment their retry counters needlessly.
+
+2. **Query pending items** — Call the store's processing log query method (step 003) to fetch a batch of pending items ordered by scheduled time (oldest first). Limit the batch size to a reasonable number (e.g., 10) to prevent a single poll cycle from holding the cluster mutex for too long. Only select items whose scheduled time is in the past (i.e., they are ready to process).
+
+3. **Process each item** — For each pending item in the batch, process it individually with its own error handling (described below). If any item's processing encounters a circuit breaker open error from the Gemini client, stop processing the remaining batch and return — the API is unavailable, and continuing would waste time.
+
+4. **Return** — After processing the batch (or early-returning due to circuit breaker), the cycle is complete. The cluster scheduler will fire the next cycle approximately 1 second later.
+
+### Per-item processing
+
+For each individual pending item from the processing log:
+
+1. **Acquire per-post mutex** — Create a distributed mutex keyed to the item's post ID (with a distinguishing prefix to avoid collision with other mutex users, e.g., `worker:{postId}`). Attempt to lock it with a short timeout — if another node is already processing this post, skip the item and move to the next one. Do not block indefinitely waiting for the lock.
+
+2. **Update status to processing** — Once the mutex is acquired, update the processing log entry's status from "pending" to "processing" and record the current timestamp. This serves as the claim marker — other workers will not pick up this item because it is no longer "pending".
+
+3. **Fetch post content** — Retrieve the full post via the plugin API (`GetPost`). If the post no longer exists (it was deleted between queuing and processing), mark the processing log entry as "complete" and release the mutex. This is a normal condition, not an error.
+
+4. **Route by job type** — The processing log entry specifies a job type. Route to the appropriate handler:
+
+   - **embed** — Pass the post's message content through the chunking engine (step 005) to produce text chunks. For each chunk, call the Gemini client's embedding generation operation (step 004) to produce a 768-dimensional vector. Store each chunk's embedding in the `ai_embeddings` table (step 003) with the chunk's text content, index, channel ID, and source type. If the item has a source type of "file", use the file's extracted text content instead of the post message.
+
+   - **extract** — Pass the post's message content (and thread context if available) to the Gemini client's knowledge extraction operation (step 004). Parse the structured response into individual extraction items (decisions, action items, topics). Store each extraction in the `ai_extractions` table (step 003). For each extraction that identifies an entity (project name, technology, person), create corresponding entries in the `ai_entity_mentions` table.
+
+5. **Mark complete** — After successful processing, update the processing log entry's status to "complete" and record the completion timestamp.
+
+6. **Handle failure** — If any step fails (Gemini API error, database error, unexpected error):
+   - Increment the item's retry count in the processing log
+   - Record the error message in the processing log's error field
+   - If the retry count has reached the maximum (3 retries), set the status to "error" permanently — the item will not be retried again
+   - If the retry count is below the maximum, return the status to "pending" so the item will be picked up again on a future poll cycle
+   - Log the error with structured fields (post ID, job type, retry count, error message)
+
+7. **Release mutex** — Unlock the per-post mutex after processing completes (success or failure). Use a deferred unlock to ensure the mutex is released even if a panic occurs during processing.
+
+8. **Panic recovery** — Wrap the per-item processing in a deferred panic recovery handler. If a panic occurs, log the error with a stack trace, mark the processing log entry as "error", and release the mutex. Do not let a single item's panic terminate the entire poll cycle — continue processing the remaining items in the batch.
+
+### Stale item detection
+
+Items can become stuck in "processing" status if the worker node crashes after claiming them but before completing them. The mutex TTL (15 seconds) ensures the lock is released, but the processing log status remains "processing" indefinitely. Implement stale detection:
+
+1. **Detection query** — As part of each poll cycle (after processing the pending batch), query for items with "processing" status whose status update timestamp is older than a staleness threshold (5 minutes). This threshold is much longer than the expected processing time for any single item (typically under 30 seconds), so items exceeding it are almost certainly stuck.
+
+2. **Recovery action** — For each stale item, reset its status to "pending" and increment its retry count. Log a warning including the post ID, how long the item has been stuck, and the original error (if any). The item will be picked up by the next poll cycle and reprocessed.
+
+3. **Max retry still applies** — If a stale item has already reached the maximum retry count, set its status to "error" instead of returning it to "pending". This prevents infinite retry loops for items that consistently crash the worker.
+
+### Batch size and throughput management
+
+The worker processes items in small batches rather than one at a time to amortize the overhead of polling and mutex acquisition:
+
+1. **Configurable batch size** — Use a reasonable default batch size of 10 items per poll cycle. This is not exposed in the plugin configuration (it's a tuning parameter, not a user-facing setting) but is defined as a named constant for easy adjustment.
+
+2. **Sequential processing within batch** — Items within a batch are processed sequentially, not concurrently. This simplifies error handling, prevents Gemini API rate limit bursts, and makes the worker's behavior predictable. The 1-second poll interval combined with batches of 10 provides a maximum theoretical throughput of 10 items per second, which is sufficient for real-time ingestion since users don't post faster than the worker can process.
+
+3. **Empty batch fast return** — If the pending query returns no items, return immediately from the poll cycle. Do not busy-wait or add artificial delay — the cluster scheduler's 1-second interval already provides the pacing.
+
+### Embedding job handler
+
+When the job type is "embed", the worker performs the full embedding pipeline for a single post:
+
+1. **Determine content source** — Check the processing log entry's source type. If "post", use the post's message content. If "file", retrieve the extracted file text from the KV store (where it was stored by the FileWillBeUploaded hook in step 006) or from the FileInfo's Content field via the plugin API.
+
+2. **Chunk the content** — Pass the text content through the chunking engine (step 005). If the chunking engine returns an empty slice (empty or whitespace-only content), mark the processing log entry as "complete" (nothing to embed) and return.
+
+3. **Generate embeddings** — For each chunk returned by the chunking engine, call the Gemini client's embedding generation operation. Each call returns a 768-dimensional L2-normalized vector.
+
+4. **Store embeddings** — For each chunk, insert a row into the `ai_embeddings` table with: a new ID (via `model.NewId()`), the post ID, the channel ID, the embedding vector, the chunk's text content (as the content snapshot for citation display), the chunk index, the source type, and a creation timestamp. Use the store interface from step 003.
+
+5. **Delete previous embeddings** — Before storing new embeddings (for reprocessing due to post edits), delete any existing embeddings for this post ID and source type. This ensures edited posts get fresh embeddings rather than accumulating stale ones alongside new ones. The delete-then-insert sequence is safe because it occurs within the per-post mutex.
+
+### Extraction job handler
+
+When the job type is "extract", the worker performs knowledge extraction for a single post:
+
+1. **Prepare context** — Assemble the post's message content. If the post is part of a thread (RootId is non-empty), optionally include recent preceding messages in the thread to provide context for the extraction. Limit the context to a reasonable amount (e.g., the 5 most recent messages before this post) to avoid excessive Gemini token usage.
+
+2. **Call extraction** — Pass the assembled text to the Gemini client's knowledge extraction operation. The response contains zero or more typed extraction items (decisions, action items, topics) with content text and optional metadata.
+
+3. **Store extractions** — For each extraction item, insert a row into the `ai_extractions` table with: a new ID, the post ID, the channel ID, the extraction type, the content text, structured metadata (as JSON), and creation timestamp.
+
+4. **Create entity mentions** — For each extraction that identifies named entities (project names, technologies, people), insert rows into the `ai_entity_mentions` table with: the normalized entity name (lowercased), the entity type, a reference to the extraction's ID, the post ID, the channel ID, and creation timestamp.
+
+5. **Delete previous extractions** — Before storing new results, delete existing extractions and entity mentions for this post ID. Same rationale as for embeddings — edits should produce fresh extractions.
+
+### Metrics integration points
+
+The worker should track key operational metrics (for step 014 to expose):
+
+1. **Items processed counter** — Increment on each successful completion, tagged by job type (embed/extract).
+2. **Items failed counter** — Increment on each failure, tagged by job type and whether it was a permanent error (max retries reached) or a transient retry.
+3. **Processing latency** — Record the wall-clock time from claim (status → processing) to completion for each item, tagged by job type.
+4. **Queue depth** — Record the number of pending items returned by each poll query.
+5. **Stale items recovered counter** — Increment each time a stale item is reset to pending.
+
+These metrics are collected as in-memory values on the Plugin struct and exposed by the ServeMetrics hook (step 014). This step only needs to update the counters at the appropriate points — the metrics infrastructure is built later.
+
+## Acceptance Criteria
+
+- [x] The processing worker is scheduled via `cluster.Schedule` with a 1-second interval and starts during OnActivate
+- [x] The worker stops gracefully during OnDeactivate, finishing the current item before shutting down
+- [x] Each poll cycle queries the processing log for pending items ordered by scheduled time (oldest first), limited to a batch size of 10
+- [x] The worker skips the poll cycle entirely when the Gemini circuit breaker is open
+- [x] Each item is processed within a per-post distributed mutex to prevent duplicate work across cluster nodes
+- [x] The processing log status transitions from "pending" to "processing" when an item is claimed
+- [x] The processing log status transitions from "processing" to "complete" on successful processing
+- [x] On failure, the retry count is incremented and the item returns to "pending" status for retry
+- [x] After 3 consecutive failures on the same item, the status is set to "error" permanently
+- [x] The error message is recorded in the processing log for failed items
+- [x] If a post no longer exists when processing begins, the item is marked "complete" without error
+- [x] The embedding job handler chunks content via the chunking engine and generates one embedding per chunk via the Gemini client
+- [x] Embeddings are stored with the chunk's text content, sequential index, post ID, channel ID, and source type
+- [x] Previous embeddings for a post are deleted before storing new ones (to handle reprocessing after edits)
+- [x] The extraction job handler calls Gemini's knowledge extraction and stores typed results (decisions, action items, topics) with metadata
+- [x] Entity mentions are created for named entities identified in extractions
+- [x] Previous extractions and entity mentions for a post are deleted before storing new ones
+- [x] Stale items stuck in "processing" status for more than 5 minutes are detected and reset to "pending" (or "error" if max retries reached)
+- [x] Panic recovery is implemented per item — a panic during one item's processing does not crash the worker loop
+- [x] The per-post mutex is always released after processing (success, failure, or panic), using deferred unlock
+- [x] The worker stops processing the current batch and returns early if a Gemini circuit breaker open error is encountered mid-batch
+- [x] Empty batches (no pending items) return immediately without artificial delay
+- [x] The worker logs structured messages at appropriate levels: debug for routine operations, warn for stale recovery, error for permanent failures
diff --git a/tasks/0001-org-memory-ai-knowledge-base/008.md b/tasks/0001-org-memory-ai-knowledge-base/008.md
new file mode 100644
index 000000000000..29370ca8c21a
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/008.md
@@ -0,0 +1,119 @@
+# 008: Thread debounce and summarization
+
+## Context
+
+Individual posts are embedded by the processing worker (step 007), but threads have a higher-order structure that individual post embeddings miss — the progression of a discussion, the decisions that emerge from back-and-forth dialogue, and the consensus that forms across multiple messages. Thread summarization captures this structure by waiting until a thread goes quiet, then feeding the full conversation to Gemini for summarization and knowledge extraction at the thread level. The "debounce" is critical: without it, every single reply would trigger a summarization, wasting Gemini API quota on partial thread states. Instead, the plugin schedules a one-time job each time a reply arrives in a thread, cancelling the previous timer, so the summarization only fires after the configured quiet period (e.g., 30 seconds of inactivity).
+
+Step 006 already handles the schedule/cancel/reschedule pattern in the message hooks and initializes the `JobOnceScheduler`. This step implements the callback that fires when a debounce timer expires — the handler that fetches the thread, assembles the conversation text, calls Gemini for summarization, stores the result, and ensures individual post embeddings are queued for any posts that haven't been processed yet.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/channels/app/summarization.go` — Mattermost's existing AI summarization implementation. `buildConversationTextWithIDs(posts)` assembles a conversation string from a slice of posts, formatting each as `[HH:MM] username (Post ID: xxx): message\n` and collecting post IDs for citation. `SummarizePosts` sends the assembled text to an LLM with a system prompt that requests highlights and action items in JSON format with source permalinks. This is the closest architectural reference for the plugin's own thread summarization.
+- `server/channels/app/recap.go` — `fetchPostsForRecap` demonstrates thread/channel post retrieval: fetches via `GetPostsSince`, converts `PostList` (map + order array) to an ordered slice, enriches each post with the author's username via `GetUser`, and limits to a configurable count. This fetch-enrich-slice pattern should be followed when assembling thread content.
+- `server/channels/jobs/recap/worker.go` — The recap background worker shows the full lifecycle: `processRecapJob` iterates channels, calls `ProcessRecapChannel` per channel, tracks progress, handles partial failures (some channels fail, others succeed), publishes WebSocket updates on status changes. The progress tracking and partial failure handling patterns are relevant.
+- `server/public/pluginapi/cluster/job_once_scheduler.go` — The singleton `JobOnceScheduler`. `SetCallback(func(key string, props any))` registers the dispatch function. When a scheduled job fires, the callback receives the key (without the `once_` storage prefix) and the deserialized props. Step 006 registers the callback; this step implements the handler that the callback dispatches to for `debounce:` prefixed keys.
+- `server/public/plugin/api.go` — `GetPostThread(postId string) (*model.PostList, *model.AppError)` retrieves all posts in a thread given the root post ID. Returns a `PostList` with `Order` (post IDs in creation order) and `Posts` (map of post ID to Post). Also: `GetUser(userId string) (*model.User, *model.AppError)` for enriching posts with usernames.
+- `server/public/model/post_list.go` — `PostList` struct with `Order []string` and `Posts map[string]*Post`. `ToSlice()` returns ordered `[]*Post`. `SortByCreateAt()` sorts posts by creation timestamp. These methods simplify converting the thread retrieval result into an ordered conversation.
+- `server/public/model/recap.go` — `AIRecapSummaryResponse` with `Highlights []string` and `ActionItems []string` — the response shape Mattermost uses for its recap feature. The plugin's thread summary storage (step 003: `ai_thread_summaries` table) uses a similar structure with a summary text field and key takeaways JSON array.
+
+## Reuse Opportunities
+
+- **Conversation text assembly** from `buildConversationTextWithIDs` in `summarization.go` provides a proven pattern for formatting thread posts into LLM-ready text. The plugin should follow the same format — timestamp, username, post ID, message per line — so that the Gemini extraction prompt can reference specific posts by ID for citation.
+- **Post enrichment with usernames** from `fetchPostsForRecap` in `recap.go` demonstrates the pattern of calling `GetUser` per post to replace user IDs with human-readable usernames in the conversation text. The plugin should do the same, caching user lookups within the thread processing to avoid repeated API calls for users who posted multiple messages.
+- **PostList to ordered slice conversion** using `PostList.Order` iteration plus `PostList.Posts` map lookup is the standard pattern for working with `GetPostThread` results. The plugin should iterate `Order` to get chronological post sequence.
+- **Structured JSON output for summaries** as demonstrated in `summarizePostsJSONSchema` — the plugin's Gemini extraction prompt should request structured JSON with highlights, decisions, action items, and key takeaways, similar to the existing recap schema but extended with the plugin's extraction types (decisions, action items, topics).
+- **WebSocket status publishing** from `publishRecapUpdate` in the recap worker can inform the plugin's own pattern for notifying the webapp when a thread summary becomes available (step 016).
+
+## Deliverables
+
+### Debounce callback handler
+
+Implement the handler function that the `JobOnceScheduler` callback dispatches to when a debounce job fires (key prefix `debounce:`). Step 006 registered the callback and routes by prefix; this step provides the actual handler implementation:
+
+1. **Parse the job key and props** — Extract the thread root post ID and channel ID from the job's key or props. The key format established in step 006 is `debounce:{rootId}`, and the props include the channel ID.
+
+2. **Validate the thread still exists** — Call `GetPost` with the thread root post ID. If the root post has been deleted since the debounce was scheduled, log at debug level and return without processing. This is a normal condition when a thread root is deleted after the last reply.
+
+3. **Fetch the full thread** — Call `GetPostThread` with the root post ID to retrieve all posts in the thread. The result is a `PostList` containing the root post and all replies.
+
+4. **Convert to ordered post slice** — Iterate the `PostList.Order` array, looking up each post in `PostList.Posts`, to build a chronologically ordered slice. Filter out system messages and bot posts from the slice (the same eligibility criteria as the message hooks in step 006).
+
+5. **Check thread size** — If the thread contains fewer than 2 eligible posts (only the root, no meaningful replies), skip summarization. A single message doesn't constitute a conversation worth summarizing. Log at debug level and return.
+
+6. **Enrich posts with usernames** — For each post in the ordered slice, call `GetUser` to retrieve the author's username. Cache user lookups within this processing call to avoid redundant API calls for users who posted multiple times in the thread.
+
+7. **Assemble conversation text** — Format the enriched post slice into a conversation text string following the pattern from `buildConversationTextWithIDs`: each post as a line with timestamp, username, post ID, and message content. Collect the post IDs into a separate list for citation reference.
+
+8. **Handle large threads** — If the thread exceeds a message count threshold (100 messages), apply a map-reduce approach: split the ordered posts into groups (e.g., chunks of 50 messages), summarize each group separately via Gemini, then synthesize the group summaries into a final thread summary with a second Gemini call. This bounds token usage and latency for very long threads. For threads under the threshold, proceed with a single summarization call.
+
+9. **Call Gemini for summarization** — Pass the conversation text to the Gemini client's "summarize and extract" operation (step 004). This is a dedicated operation (separate from "extract knowledge") that returns a combined result containing: a concise summary of the thread discussion, a list of key takeaways, and typed extraction items (decisions, action items, topics) with content and source post ID references — all from a single Gemini call.
+
+10. **Store the thread summary** — Insert or update a row in the `ai_thread_summaries` table (step 003) keyed by the thread root post ID. The row includes: the summary text, key takeaways as a JSON array, the model version used for generation, and the current timestamp as the last activity time. If a summary already exists for this thread (from a previous debounce cycle), update it with the new content — threads evolve as new replies arrive, so summaries must be regenerated.
+
+11. **Store extractions** — For each extraction item (decision, action item, topic) produced by Gemini, store it in the `ai_extractions` table with the thread root post ID as the source. Create corresponding entity mention entries in `ai_entity_mentions` for any named entities. Before storing, delete previous thread-level extractions for this root post ID to avoid accumulating stale extractions from earlier summarization runs.
+
+12. **Queue unprocessed individual embeddings** — After summarization, check whether each individual post in the thread has been processed for embedding (query the processing log for each post). For any post that does not yet have a "complete" embedding entry in the processing log, create a new "pending" entry so the processing worker (step 007) will embed it on its next poll cycle. This ensures that even if a post's initial embedding was missed (e.g., the worker was down when the post arrived), the debounce handler catches it.
+
+### Thread summary embedding
+
+After storing the thread summary, also embed the summary text itself so it becomes searchable via the RAG engine:
+
+1. **Create a processing log entry** — Insert a "pending" entry in the processing log with job type "embed" and a source type of "summary" (distinct from "post" and "file") for the thread root post ID.
+
+2. **The processing worker handles it** — The embedding worker (step 007) will pick up this entry on its next poll cycle, chunk the summary text, and generate embeddings. The source type "summary" tells the worker that the content comes from the thread summary text rather than the raw post message.
+
+### Error handling
+
+The debounce handler operates outside the processing worker's retry framework (it's triggered by the `JobOnceScheduler`, not polled from the processing log), so it needs its own error handling:
+
+1. **Gemini API failure** — If the Gemini client returns an error (circuit breaker open, rate limited, API error), the handler should reschedule the debounce job for a short future time (e.g., 60 seconds) to retry. This reuses the same schedule/cancel pattern from step 006 — schedule a new debounce job for the same thread root with a future time. The retry should be attempted up to 3 times (tracked in the job's props). After 3 failed attempts, log an error and abandon the summarization — the thread's individual posts are still embedded by the worker, so no data is permanently lost.
+
+2. **Database failure** — If storing the summary or extractions fails, log the error and do not reschedule. The next time activity occurs in the thread, a new debounce cycle will trigger and attempt summarization again.
+
+3. **Panic recovery** — Wrap the entire handler in a deferred panic recovery. Log the stack trace and move on — a panic in one thread's summarization must not crash the scheduler or affect other debounce jobs.
+
+### WebSocket notification
+
+After successfully storing a thread summary, publish a custom WebSocket event to notify connected clients that a summary is available for this thread:
+
+1. **Event name** — Pass `thread_summary_ready` as the event name to `PublishWebSocketEvent`. The plugin API automatically prepends `custom_org-memory_` (the `custom_{pluginid}_` prefix), so the full wire-format event name received by clients is `custom_org-memory_thread_summary_ready`. The webapp (step 016) registers its WebSocket handler using this fully-prefixed name.
+
+2. **Event payload** — Include the thread root post ID and channel ID so the webapp (step 016) knows which thread to update.
+
+3. **Broadcast scope** — Broadcast the event to the channel where the thread lives. Only users who are members of the channel and currently connected will receive it. Use the plugin API's `PublishWebSocketEvent` method.
+
+### Configuration dependencies
+
+The debounce handler uses these configuration values from step 002:
+
+- **Debounce interval** — The quiet period before summarization fires. Used by step 006 when scheduling; the handler itself doesn't read this value directly (it fires when the timer expires).
+- **Large thread threshold** — The message count above which the map-reduce approach is used (default 100). This is a compile-time constant, not a user-facing configuration field.
+- **Model version tracking** — The handler stores the Gemini model name (from configuration) alongside the summary to track which model version produced it. If the model is upgraded later, existing summaries can be identified for regeneration.
+
+## Acceptance Criteria
+
+- [x] The debounce callback handler is dispatched when the `JobOnceScheduler` fires a job with the `debounce:` key prefix
+- [x] The handler fetches the full thread via `GetPostThread` and converts it to a chronologically ordered post slice
+- [x] Bot posts and system messages are filtered out of the thread before summarization
+- [x] Threads with fewer than 2 eligible posts are skipped without calling Gemini
+- [x] Each post is enriched with the author's username (via `GetUser`) for the conversation text, with user lookups cached within the handler
+- [x] Conversation text follows the format: timestamp, username, post ID, and message per line
+- [x] For threads exceeding 100 messages, a map-reduce approach splits the thread into groups, summarizes each group, then synthesizes a final summary
+- [x] The Gemini client's "summarize and extract" operation is called with the conversation text and returns a combined result: summary, key takeaways, and typed extractions
+- [x] The thread summary is stored in `ai_thread_summaries` with summary text, key takeaways, model version, and activity timestamp
+- [x] If a summary already exists for the thread root, it is replaced with the updated summary
+- [x] Extraction items (decisions, action items, topics) are stored in `ai_extractions` with the thread root post ID as source
+- [x] Previous thread-level extractions for the root post are deleted before storing new ones
+- [x] Entity mentions are created for named entities identified in thread-level extractions
+- [x] Individual posts in the thread that lack "complete" embedding entries get new "pending" processing log entries
+- [x] A processing log entry with source type "summary" is created for the thread summary text so it gets embedded by the worker
+- [x] If the thread root post has been deleted, the handler returns without error
+- [x] If the Gemini API fails, the debounce job is rescheduled for 60 seconds in the future, up to 3 retry attempts
+- [x] After 3 failed retry attempts, the summarization is abandoned with an error log
+- [x] Database write failures are logged but do not trigger retries (the next thread activity will trigger a new debounce cycle)
+- [x] Panic recovery is implemented — a panic in one thread's summarization does not affect other debounce jobs
+- [x] A custom WebSocket event (`custom_org-memory_thread_summary_ready`) is published after successful summary storage
+- [x] The WebSocket event includes the thread root post ID and channel ID and is broadcast to the channel
+- [x] The model version used for summarization is recorded in the thread summary row
diff --git a/tasks/0001-org-memory-ai-knowledge-base/009.md b/tasks/0001-org-memory-ai-knowledge-base/009.md
new file mode 100644
index 000000000000..396b31cf0330
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/009.md
@@ -0,0 +1,190 @@
+# 009: RAG query engine with permission filtering
+
+## Context
+
+This is the core intelligence layer that turns stored knowledge into answers. When a user asks "What did we decide about the database migration?" the RAG query engine must: resolve which channels the user can read, embed the query into a vector, search for the most similar content chunks across only those permitted channels, fetch surrounding context for the top results, send everything to Gemini for answer synthesis, and format the response with clickable citation links back to the original posts. Every step must respect Mattermost's permission model — a user must never see knowledge derived from channels they cannot access.
+
+The engine also supports multi-turn conversation: after an initial answer, users can ask follow-up questions that build on the previous context. This requires maintaining short-lived session state (conversation history) in the KV store, with a TTL to automatically clean up inactive sessions.
+
+This step has no UI surface of its own — it is a backend component called by the HTTP API (step 010) and the slash command handler (step 010). Its interface must be clean and mockable so both callers and tests can drive it independently.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/plugin/api.go` (line 380) — `GetTeamsForUser(userID string) ([]*model.Team, *model.AppError)` returns all teams the user belongs to in a single call (not paginated). This is the starting point for multi-team permission resolution.
+- `server/public/plugin/api.go` (line 598) — `GetChannelMembersForUser(teamID, userID string, page, perPage int) ([]*model.ChannelMember, *model.AppError)` returns paginated channel memberships for a user within a specific team. Requires iterating over all teams and all pages to build the complete channel list.
+- `server/public/plugin/api.go` (line 1002) — `HasPermissionToChannel(userID, channelId string, permission *model.Permission) bool` checks whether a user has a specific permission on a channel. Used as a fallback verification for individual result items.
+- `server/public/model/permission.go` — `PermissionReadChannelContent` is the permission constant for reading channel messages. This is the permission to check for RAG result filtering — users who can read a channel's content can see knowledge derived from it.
+- `server/public/plugin/api.go` (line 52) — `GetConfig() *model.Config` returns the server configuration. `Config.ServiceSettings.SiteURL` provides the base URL for constructing post permalinks in the format `{SiteURL}/pl/{postId}`.
+- `server/public/plugin/api.go` (line 721) — `GetPost(postId string) (*model.Post, *model.AppError)` retrieves a full post for enriching search results with original content and thread context.
+- `server/public/plugin/api.go` (line 976) — `PublishWebSocketEvent(event string, payload map[string]any, broadcast *model.WebsocketBroadcast)` for sending real-time events. The event name is automatically prefixed with `custom_{pluginid}_`.
+- `server/public/pluginapi/kv.go` — KV store with TTL support: `Set(key, value, SetExpiry(ttl))` stores a value that auto-expires after the specified duration. `Get(key, &dest)` retrieves and unmarshals. `Delete(key)` removes explicitly. Values max ~256KB per key.
+- `server/public/model/channel_member.go` — `ChannelMember` struct with `ChannelId` and `UserId`. Returned by `GetChannelMembersForUser`. The `ChannelId` values form the permission-allowed set for vector search filtering.
+- `server/public/model/channel.go` — `Channel` struct with `TeamId` and `Type`. Channel types include `"O"` (open/public), `"P"` (private), `"G"` (group message), `"D"` (direct message). Direct messages have an empty `TeamId`.
+- `server/channels/app/summarization.go` — `buildConversationTextWithIDs` provides the pattern for assembling context passages with post IDs for citation reference. The RAG engine's context assembly for Gemini follows a similar approach — each passage includes source identifiers that map back to post permalinks.
+
+## Reuse Opportunities
+
+- **GetTeamsForUser + GetChannelMembersForUser pagination** is the standard multi-team channel enumeration pattern. The engine should build a set of allowed channel IDs by iterating teams, then paginating through channel memberships per team. This set is reused for both the vector search filter and result validation.
+- **KV store with TTL** for permission caching. Fetching channel memberships involves multiple paginated API calls across multiple teams, which is expensive for users in many channels. Cache the resolved channel ID set in the KV store with a 60-second TTL keyed by user ID. Subsequent queries within the TTL window hit the cache instead of re-resolving permissions.
+- **KV store with TTL** for multi-turn session state. Conversation history (previous query/answer pairs) is stored in the KV store keyed by user ID + session ID with a 30-minute TTL. This provides automatic cleanup of inactive sessions without a background sweeper.
+- **HasPermissionToChannel** as a secondary verification. The cached channel membership set provides the primary permission filter for vector search, but individual result items can be double-checked against `HasPermissionToChannel(userID, channelId, PermissionReadChannelContent)` for defense-in-depth — a user's permissions may have changed since the cache was populated.
+- **SiteURL from GetConfig** for permalink construction. The engine formats citation links as `{SiteURL}/pl/{postId}`, which is the standard Mattermost post permalink format.
+
+## Deliverables
+
+### RAG query engine interface
+
+Define a Go interface for the RAG query engine with two operations:
+
+**Query** — Accepts a user ID and query text. Returns a structured response containing: the synthesized answer text with inline citation markers, a list of citation objects (each with a reference number, post ID, permalink URL, and content snippet), and a session ID for follow-up queries. This is the entry point for new queries from the HTTP API and slash command.
+
+**FollowUp** — Accepts a user ID, query text, and session ID. Returns the same response structure as Query. Loads the previous conversation history from the session, appends the new query, and sends the full context to Gemini for synthesis. If the session ID is invalid or expired, falls back to a fresh query (no error — sessions are best-effort).
+
+The interface must be mockable for testing the HTTP API and slash command handlers independently of the RAG pipeline.
+
+### Permission resolution
+
+Implement the channel permission resolver that determines which channels a user can read:
+
+1. **Check cache** — Look up the user's cached channel ID set in the KV store with key `perms:{userId}`. If found and not expired (TTL manages expiry automatically), use the cached set.
+
+2. **Resolve from API** — If no cache hit, build the permitted channel set:
+   - Call `GetTeamsForUser(userId)` to get all teams
+   - For each team, paginate through `GetChannelMembersForUser(teamId, userId, page, perPage)` with a page size of 200, collecting all `ChannelId` values into a set
+   - Continue paginating until a page returns fewer results than the page size
+   - The resulting set contains all channels the user is a member of across all teams
+
+3. **Cache the result** — Store the channel ID set in the KV store with a 60-second TTL. The set is stored as a serialized list of channel ID strings.
+
+4. **Handle direct messages** — Direct message channels (type `"D"` and `"G"`) have an empty `TeamId` and are not returned by team-scoped channel membership queries. However, `GetChannelMembersForUser` with an empty string as teamID may not work. If direct message channels are not returned by the team iteration, the engine should accept them by checking `HasPermissionToChannel` on individual result items that reference channels not in the cached set. This ensures DM-derived knowledge is accessible to participants.
+
+### Query vector generation
+
+When a query is received:
+
+1. **Embed the query** — Pass the user's query text through the Gemini client's embedding generation operation (step 004) to produce a 768-dimensional query vector. The same embedding model (gemini-embedding-001) and L2 normalization used for content embeddings ensures the query vector is in the same embedding space.
+
+2. **Handle embedding failure** — If the Gemini client returns an error (circuit breaker open, rate limited), return a user-friendly error to the caller indicating the knowledge base is temporarily unavailable. Do not retry — the HTTP handler or slash command can decide whether to communicate this to the user.
+
+### Vector similarity search
+
+Execute a permission-filtered vector search against the `ai_embeddings` table:
+
+1. **Build the query** — Construct a SQL query that selects from `ai_embeddings` where:
+   - The `ChannelId` is in the user's permitted channel set (from permission resolution)
+   - The `DeleteAt` is 0 (not soft-deleted)
+   - Results are ordered by cosine distance (ascending — smaller distance = more similar) using the pgvector `<=>` operator between the stored embedding vector and the query vector
+   - Limited to the top N results (default 10)
+
+2. **Use the replica database** — Read queries should use `GetReplicaDB()` to avoid loading the primary database with search traffic.
+
+3. **Return result rows** — Each result row includes: the embedding ID, post ID, channel ID, content snapshot (the chunk text stored alongside the embedding), chunk index, source type, and the cosine distance score.
+
+### Result enrichment
+
+For each search result, fetch additional context to provide Gemini with enough information for accurate synthesis:
+
+1. **Fetch the source post** — Call `GetPost(postId)` to retrieve the full post. If the post no longer exists (deleted between embedding and query), skip this result.
+
+2. **Permission double-check** — Verify that the user still has `PermissionReadChannelContent` on the result's channel. If the cache is stale (user was removed from a channel after caching), skip this result. This is a defense-in-depth measure.
+
+3. **Fetch thread context** — If the post is part of a thread (RootId is non-empty), fetch the thread summary from `ai_thread_summaries` if available. The thread summary provides broader conversation context that helps Gemini understand how the matched chunk fits into a larger discussion.
+
+4. **Build passage object** — For each valid result, create a context passage containing: a reference number (sequential, starting from 1), the content snapshot from the embedding, the post author's username (via `GetUser`), the post's creation timestamp, the channel name (via `GetChannel`), and the thread summary snippet (if available). These passages are sent to Gemini for synthesis.
+
+5. **Generate permalink** — Construct the post permalink as `{SiteURL}/pl/{postId}` using the server's `SiteURL` from configuration. Store it on the passage for citation link formatting.
+
+### Answer synthesis
+
+Send the enriched context to Gemini for answer generation:
+
+1. **Assemble the synthesis prompt** — Build a prompt for the Gemini client's RAG synthesis operation (step 004) that includes:
+   - The user's query
+   - All context passages, each labeled with a reference number
+   - Instructions to answer only from the provided context
+   - Instructions to cite sources by reference number (e.g., "[1]", "[2]")
+   - Instructions to state explicitly when the provided context does not contain enough information to answer the query, rather than fabricating an answer
+   - For multi-turn follow-ups: the previous conversation history (query/answer pairs from the session)
+
+2. **Call Gemini** — Pass the assembled prompt to the Gemini client's synthesis operation. The response is the raw answer text with inline citation markers.
+
+3. **Handle no results** — If the vector search returned zero results (no matching content in the user's accessible channels), skip the Gemini call and return a canned response: "I couldn't find any relevant information in your accessible channels. Try rephrasing your question or asking about a different topic."
+
+4. **Handle synthesis failure** — If the Gemini client returns an error, return a user-friendly error to the caller. Do not return partial results — either the full synthesized answer or an error.
+
+### Citation formatting
+
+Parse the Gemini-generated answer and replace citation markers with actual post links:
+
+1. **Parse citation references** — Scan the answer text for citation markers in the format `[N]` where N is a reference number. Map each reference number back to the corresponding passage object.
+
+2. **Format as Mattermost markdown** — Replace each citation marker with a Mattermost-compatible markdown link. The format should be `[N]({permalink})` where the permalink navigates to the original post. When clicked in the Mattermost client, this link navigates directly to the source post.
+
+3. **Build citation list** — In addition to inline citations, build a list of all cited sources with: reference number, post permalink, channel name, author username, and a short content snippet. This list is returned alongside the answer for the UI to display as a "Sources" section.
+
+4. **Handle missing citations** — If Gemini references a number that doesn't correspond to a provided passage (hallucinated citation), strip the marker from the answer rather than linking to nothing. Log a warning when this occurs.
+
+### Multi-turn session management
+
+Support follow-up queries that build on previous context:
+
+1. **Session creation** — When a new query is processed (no session ID provided), generate a new session ID (using `model.NewId()`) and include it in the response. The caller (HTTP API or slash command) passes this ID back for follow-up queries.
+
+2. **Session storage** — Store the conversation history in the KV store with key `session:{userId}:{sessionId}`. The value is a list of query/answer pairs (the user's query text and Gemini's synthesized answer). Set a TTL of 30 minutes on each write — every interaction refreshes the TTL, so sessions stay alive as long as the user is actively querying.
+
+3. **Follow-up context loading** — When a follow-up query arrives with a session ID, load the session from the KV store. If the session exists, append the conversation history to the synthesis prompt so Gemini can reference prior answers. If the session has expired or doesn't exist, treat it as a fresh query.
+
+4. **History truncation** — If the conversation history grows large enough to approach the KV store's value size limit (~256KB), truncate the oldest query/answer pairs, keeping only the most recent exchanges. This ensures writes succeed while preserving recent context. A practical limit is approximately 10 exchanges before considering truncation.
+
+5. **Session update** — After each successful query or follow-up, update the session in the KV store with the new exchange appended and a refreshed TTL.
+
+### Query audit logging
+
+After each query (initial or follow-up), record an entry in the `ai_query_log` table (step 003):
+
+1. **Log fields** — Record: query ID (via `model.NewId()`), user ID, query text, the list of channel IDs that were searched, the number of results returned by vector search, the number of results after enrichment filtering, the total processing latency (wall-clock time from query receipt to response), and the timestamp.
+
+2. **Write-only** — The query log is append-only. No updates or deletes are performed on query log entries.
+
+3. **Async if possible** — The audit log write should not delay the query response to the user. If the store interface supports fire-and-forget inserts, use that. Otherwise, a synchronous write is acceptable since it's a single insert.
+
+### Metrics integration points
+
+The engine should track key operational metrics (for step 014 to expose):
+
+1. **Query count** — Increment on each query (new and follow-up), tagged by type.
+2. **Query latency** — Record the end-to-end latency from query receipt to response delivery.
+3. **Search result count** — Record the number of vector search results before and after permission filtering and enrichment.
+4. **Permission cache hit/miss** — Track how often the cached channel set is used versus freshly resolved.
+5. **Session hit/miss** — Track how often follow-up queries find a valid session versus falling back to fresh queries.
+
+## Acceptance Criteria
+
+- [x] The RAG engine interface defines Query and FollowUp operations that are mockable for testing
+- [x] Query accepts a user ID and query text and returns a synthesized answer with citations and a session ID
+- [x] FollowUp accepts a user ID, query text, and session ID and returns the same response structure
+- [x] Permission resolution fetches the user's channel memberships across all teams via GetTeamsForUser and paginated GetChannelMembersForUser
+- [x] The resolved channel ID set is cached in the KV store with a 60-second TTL keyed by user ID
+- [x] Subsequent queries within the cache TTL window use the cached channel set without re-resolving
+- [x] The query text is embedded via the Gemini client's embedding operation to produce a 768-dimensional query vector
+- [x] Vector similarity search queries ai_embeddings filtered by the user's permitted channel IDs and excluding soft-deleted entries
+- [x] Search results are ordered by cosine distance (ascending) and limited to the top 10
+- [x] Vector search uses the replica database connection (GetReplicaDB)
+- [x] Each search result is enriched with the original post content via GetPost
+- [x] Results whose posts no longer exist are skipped gracefully
+- [x] A permission double-check via HasPermissionToChannel filters out results from channels the user has since lost access to
+- [x] Thread summaries from ai_thread_summaries are included as additional context for results that are part of threads
+- [x] Post permalinks are generated in the format {SiteURL}/pl/{postId}
+- [x] The synthesis prompt includes all context passages with reference numbers, the user's query, and instructions to cite sources and not fabricate answers
+- [x] When no vector search results are found, a canned "no results" message is returned without calling Gemini
+- [x] Citation markers in the answer ([N]) are replaced with Mattermost markdown links to post permalinks
+- [x] Hallucinated citation references (numbers not matching any provided passage) are stripped from the answer
+- [x] A citation list is returned alongside the answer with reference number, permalink, channel name, author, and content snippet
+- [x] Multi-turn sessions are stored in the KV store with key session:{userId}:{sessionId} and 30-minute TTL
+- [x] Each query interaction refreshes the session TTL
+- [x] Expired or missing sessions on follow-up queries fall back to fresh queries without error
+- [x] Conversation history is truncated when approaching the KV store size limit, keeping the most recent exchanges
+- [x] Query audit log entries are written to ai_query_log with user ID, query text, channels searched, result count, and latency
+- [x] Gemini API failures return a user-friendly error message to the caller
diff --git a/tasks/0001-org-memory-ai-knowledge-base/010.md b/tasks/0001-org-memory-ai-knowledge-base/010.md
new file mode 100644
index 000000000000..d53450050af3
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/010.md
@@ -0,0 +1,248 @@
+# 010: HTTP API router and slash command handler
+
+## Context
+
+Up to this point, the knowledge base is fully operational but invisible to users. Posts are ingested, chunked, embedded, extracted, and summarized — but no user-facing interface exists to query it or inspect its contents. This step builds the HTTP API layer and slash command handler that expose the pipeline to consumers: the webapp (steps 015-016), external integrations, and command-line users.
+
+The HTTP API provides 13 endpoints under `/plugins/org-memory/api/v1/` covering the full feature surface: RAG queries, thread and channel summaries, entity timelines, extraction management, admin operations, and webhook configuration. Every endpoint requires authentication, and admin endpoints require system administrator privileges. The slash command provides a lightweight alternative — users can type `/ask <question>` in any channel to get an ephemeral response without opening the RHS panel.
+
+Both the API and slash command are thin dispatch layers. They parse inputs, check permissions, delegate to the RAG engine (step 009) or store (step 003), format outputs, and return responses. No business logic should live in the handlers themselves — that belongs in the engine and store.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/plugin/hooks.go` (lines 109-116) — `ServeHTTP(c *Context, w http.ResponseWriter, r *http.Request)` hook signature. The Mattermost server strips the `/plugins/{plugin_id}` prefix from the request path before passing it to the plugin, so the plugin receives paths starting with `/api/v1/...`. The `Mattermost-User-Id` header is set by the server after session validation — if present, the request is authenticated.
+- `server/public/plugin/hooks.go` (lines 118-122) — `ExecuteCommand(c *Context, args *model.CommandArgs) (*model.CommandResponse, *model.AppError)` hook signature. Receives the parsed command arguments including the user's ID, channel ID, team ID, and the full command text.
+- `server/public/plugin/plugintest/example_hello_user_test.go` (line 25-30) — Reference ServeHTTP implementation: extracts `Mattermost-User-Id` header, calls `GetUser`, writes response. Shows the minimal pattern for an authenticated plugin HTTP handler.
+- `server/public/model/command.go` (lines 21-45) — `Command` struct for registration: `Trigger` (the slash command word), `AutoComplete` (enable autocomplete), `AutoCompleteDesc` (description in autocomplete), `AutoCompleteHint` (hint text showing expected arguments), `DisplayName`, `Description`.
+- `server/public/model/command_args.go` — `CommandArgs` struct: `UserId`, `ChannelId`, `TeamId`, `RootId`, `Command` (the full command string including the trigger word), `SiteURL`.
+- `server/public/model/command_response.go` — `CommandResponse` struct: `ResponseType` (`CommandResponseTypeEphemeral` for private responses), `Text` (the response body as markdown), `Props`, `Attachments`. Returned from `ExecuteCommand`.
+- `server/public/plugin/api.go` (line 29) — `RegisterCommand(command *model.Command) error` registers a slash command during plugin activation. Previously wired in step 002.
+- `server/public/plugin/api.go` (line 685) — `SendEphemeralPost(userID string, post *model.Post) *model.Post` creates a post visible only to one user. Useful for longer slash command responses that need rich formatting.
+- `server/public/plugin/api.go` (lines 984-1002) — `HasPermissionTo(userID string, permission *model.Permission) bool` for system-scope permission checks. `HasPermissionToChannel(userID, channelId string, permission *model.Permission) bool` for channel-scope checks.
+- `server/public/model/permission.go` — `PermissionManageSystem` is the system administrator permission. `PermissionReadChannelContent` for verifying read access to channel data.
+- `server/channels/app/plugin_requests.go` (lines 156-274) — Server-side authentication flow: extracts token from Authorization header (Bearer/Token prefix), Cookie, or query parameter. Validates session. Sets `Mattermost-User-Id` header after CSRF checks. The plugin can trust this header because the server clears it before validation and only re-sets it for valid sessions.
+- `server/channels/app/integration_action.go` (line 255) — Request body size limiting via `io.LimitReader` with a 1MB cap to prevent memory exhaustion attacks. The plugin should apply the same pattern for POST/PUT endpoints.
+
+## Reuse Opportunities
+
+- **Mattermost-User-Id header authentication** is provided by the server's plugin request pipeline. The plugin does not need to implement session validation — if the header is present, the user is authenticated. If absent, the request is unauthenticated and should be rejected with HTTP 401. This is the standard plugin authentication pattern.
+- **CommandResponse with ephemeral type** for slash command responses. The `CommandResponseTypeEphemeral` constant ensures the response is visible only to the invoker. For longer or richer responses, `SendEphemeralPost` can be used instead, which supports full Mattermost markdown.
+- **HasPermissionTo with PermissionManageSystem** provides the admin guard for admin-only endpoints (backfill, status, webhook management). This is the standard system admin check used across Mattermost plugins.
+- **HasPermissionToChannel with PermissionReadChannelContent** provides per-channel access control for summary, entity, and extraction endpoints. Before returning data associated with a channel, the handler must verify the requesting user can read that channel.
+- **io.LimitReader pattern** from integration action handlers prevents oversized request bodies from consuming memory. Apply to all POST and PUT endpoints with a 1MB limit.
+
+## Deliverables
+
+### ServeHTTP router
+
+Implement the `ServeHTTP` hook to route incoming HTTP requests to the appropriate handler based on the request method and path. The router dispatches under the `/api/v1/` prefix (the server has already stripped `/plugins/org-memory`):
+
+1. **Authentication gate** — Before dispatching to any handler, extract the `Mattermost-User-Id` header. If the header is empty, reject the request with HTTP 401 Unauthorized. Store the user ID for the handler to use.
+
+2. **Path routing** — Parse the request path and HTTP method to determine which handler to invoke. The router supports these routes:
+
+   - `POST /api/v1/query` → query handler
+   - `POST /api/v1/query/followup` → follow-up query handler
+   - `GET /api/v1/threads/{root_id}/summary` → thread summary handler
+   - `GET /api/v1/channels/{channel_id}/summary` → channel summary handler
+   - `GET /api/v1/entities/{name}/timeline` → entity timeline handler
+   - `GET /api/v1/extractions` → extractions list handler
+   - `PUT /api/v1/extractions/{id}` → extraction edit handler
+   - `POST /api/v1/admin/backfill` → backfill trigger handler
+   - `GET /api/v1/admin/status` → pipeline status handler
+   - `POST /api/v1/webhooks` → webhook create handler
+   - `GET /api/v1/webhooks` → webhook list handler
+   - `DELETE /api/v1/webhooks/{id}` → webhook delete handler
+
+3. **Not found handling** — If no route matches, return HTTP 404 with a JSON error body.
+
+4. **Method not allowed** — If the path matches but the HTTP method does not, return HTTP 405.
+
+5. **Path parameter extraction** — For routes with path parameters (e.g., `{root_id}`, `{channel_id}`, `{name}`, `{id}`), extract the parameter value from the path segments. Use standard library path parsing — no external router dependency is required, though `gorilla/mux` is available in the dependency tree if preferred.
+
+### JSON request/response conventions
+
+Establish consistent JSON handling across all endpoints:
+
+1. **Request body parsing** — For POST and PUT endpoints, read the request body through a size-limited reader (1MB max). Decode the JSON body into the appropriate request struct. If the body is malformed, return HTTP 400 with a descriptive error message.
+
+2. **Response encoding** — All responses use JSON content type (`Content-Type: application/json`). Success responses include a JSON body with the relevant data. Error responses include a JSON body with an `error` field containing a human-readable message and a `status` field with the HTTP status code.
+
+3. **Content type enforcement** — For POST and PUT endpoints, verify the `Content-Type` header includes `application/json`. If not, return HTTP 415 Unsupported Media Type.
+
+### Query endpoint (POST /api/v1/query)
+
+Handles new RAG queries:
+
+1. **Parse request** — Read the JSON body containing the query text (required, non-empty string).
+2. **Call RAG engine** — Invoke the RAG engine's Query operation (step 009) with the authenticated user's ID and the query text.
+3. **Return response** — Return the synthesized answer, citation list, and session ID as JSON. The session ID is included so the webapp can send follow-up queries.
+4. **Error handling** — If the RAG engine returns an error (Gemini unavailable, etc.), return HTTP 503 with the user-friendly error message.
+
+### Follow-up query endpoint (POST /api/v1/query/followup)
+
+Handles multi-turn follow-up queries:
+
+1. **Parse request** — Read the JSON body containing the query text (required) and session ID (required, non-empty string).
+2. **Call RAG engine** — Invoke the RAG engine's FollowUp operation with the user's ID, query text, and session ID.
+3. **Return response** — Same response format as the query endpoint, with an updated session ID.
+4. **Expired session handling** — If the session has expired, the RAG engine falls back to a fresh query. The response is still successful — the caller does not need to handle session expiry explicitly.
+
+### Thread summary endpoint (GET /api/v1/threads/{root_id}/summary)
+
+Returns the thread summary and extractions for a given thread:
+
+1. **Extract path parameter** — Parse the `root_id` from the URL path.
+2. **Permission check** — Fetch the root post via `GetPost` to determine its channel. Check `HasPermissionToChannel(userId, channelId, PermissionReadChannelContent)`. If the user cannot read the channel, return HTTP 403.
+3. **Fetch data** — Query the store for the thread summary (from `ai_thread_summaries`) and extractions (from `ai_extractions`) where the post ID matches the root ID.
+4. **Return response** — Return the summary text, key takeaways, extractions (decisions, action items, topics), and the summary's generation timestamp. If no summary exists yet, return HTTP 404 with a message indicating the thread has not been summarized.
+
+### Channel summary endpoint (GET /api/v1/channels/{channel_id}/summary)
+
+Returns daily or weekly channel summaries:
+
+1. **Extract path parameter and query params** — Parse the `channel_id` from the path and `type` (daily/weekly) from query parameters. Default to "daily" if not specified.
+2. **Permission check** — Check `HasPermissionToChannel(userId, channelId, PermissionReadChannelContent)`. Return HTTP 403 if denied.
+3. **Fetch data** — Query the store for the most recent channel summary of the requested type for this channel.
+4. **Return response** — Return the summary text, time window (start and end timestamps), and generation timestamp. If no summary exists, return HTTP 404.
+
+### Entity timeline endpoint (GET /api/v1/entities/{name}/timeline)
+
+Returns cross-channel mentions of a named entity:
+
+1. **Extract path parameter** — Parse the entity `name` from the path. URL-decode it to handle spaces and special characters.
+2. **Fetch mentions** — Query the store for entity mentions matching the normalized name (lowercased), ordered by creation time descending.
+3. **Permission filter** — Filter the results to only include mentions from channels the user can read. Use the permission resolver from step 009 (cached channel set) to filter efficiently rather than checking each mention individually.
+4. **Return response** — Return a chronological list of mentions, each with: the entity name, source post ID and permalink, channel name, extraction content, and timestamp. If no mentions are found, return an empty list (not a 404).
+
+### Extractions list endpoint (GET /api/v1/extractions)
+
+Returns extractions filtered by channel and/or type:
+
+1. **Parse query parameters** — Read optional `channel_id` and `type` (decision/action_item/topic) filters from query parameters. Also support `page` and `per_page` for pagination (defaults: page 0, per_page 20).
+2. **Permission check** — If a `channel_id` filter is provided, check that the user can read that channel. If no filter is provided, the store query must be restricted to channels the user can access (use the cached channel set from step 009).
+3. **Fetch data** — Query the store for extractions matching the filters, paginated.
+4. **Return response** — Return the list of extractions with: ID, type, content, metadata, post ID, channel ID, edit status, creation timestamp. Include pagination metadata (total count, page, per_page).
+
+### Extraction edit endpoint (PUT /api/v1/extractions/{id})
+
+Allows users to edit an extraction's content:
+
+1. **Extract path parameter** — Parse the extraction `id` from the path.
+2. **Parse request** — Read the JSON body containing the updated content text.
+3. **Fetch and validate** — Load the extraction from the store. If not found, return HTTP 404. Check that the user can read the extraction's channel (permission check).
+4. **Update** — Update the extraction's content text, set the `edited` flag to true, record the editor's user ID, and update the timestamp.
+5. **Trigger re-embedding** — Create a processing log entry with job type "embed" for the extraction's post to regenerate embeddings with the updated content. The processing worker (step 007) will handle the actual re-embedding.
+6. **Return response** — Return the updated extraction.
+
+### Admin backfill endpoint (POST /api/v1/admin/backfill)
+
+Triggers, pauses, or resumes historical data backfill (admin only). This single endpoint handles all backfill lifecycle actions via an `action` field:
+
+1. **Admin guard** — Check `HasPermissionTo(userId, PermissionManageSystem)`. If the user is not a system admin, return HTTP 403.
+2. **Parse request** — Read the JSON body containing: an `action` field (required, one of "start", "pause", "resume") and channel ID (required). For the "start" action only: since date (optional, as Unix millisecond timestamp — defaults to all history) and batch size (optional, defaults to 100).
+3. **Action: start** — Verify the channel exists. Check that no backfill with status "running" exists for this channel (query the KV store for backfill progress). If one is running, return HTTP 409 Conflict. Otherwise, schedule the backfill job via the `JobOnceScheduler` (step 006) with the `backfill:` key prefix. Store the backfill parameters as job props. Return HTTP 202 Accepted with the backfill job ID for progress tracking.
+4. **Action: pause** — Check that a running backfill exists for the channel in the KV store. If not found or not in "running" status, return HTTP 404. Set the backfill progress status to "paused" in the KV store. Cancel the pending scheduled job via `JobOnceScheduler.Cancel(backfill:{channelId})`. Return HTTP 200 with the current progress state (cursor, counters) so the admin knows where it stopped.
+5. **Action: resume** — Check that a paused backfill exists for the channel in the KV store. If not found or not in "paused" status, return HTTP 404. Set the backfill progress status back to "running". Schedule the next batch from the existing cursor position via `ScheduleOnce` with key `backfill:{channelId}`. Return HTTP 202 Accepted with the resumed backfill state.
+
+### Admin status endpoint (GET /api/v1/admin/status)
+
+Returns pipeline health and operational status (admin only):
+
+1. **Admin guard** — Same system admin permission check as backfill.
+2. **Gather status** — Query the store and in-memory metrics for:
+   - Processing queue depth (count of pending items in `ai_processing_log`)
+   - Error count (count of items with "error" status)
+   - Worker health (whether the processing worker ran recently — check last completion timestamp)
+   - Circuit breaker state (from KV store — closed/open/half-open)
+   - Active backfill progress (if any)
+   - Total knowledge base size (count of embeddings, extractions, summaries)
+3. **Return response** — Return the status data as JSON.
+
+### Webhook create endpoint (POST /api/v1/webhooks)
+
+Creates a new outbound webhook configuration (admin only):
+
+1. **Admin guard** — System admin permission check.
+2. **Parse request** — Read the JSON body containing: channel ID (required), target URL (required, must be a valid URL), extraction types to send (required, array of "decision" and/or "action_item"), and an optional secret for HMAC signing.
+3. **Validate** — Verify the channel exists. Validate the URL format.
+4. **Store** — Generate a webhook ID (via `model.NewId()`), store the configuration in the KV store with key `webhook:{channelId}:{webhookId}`.
+5. **Return response** — Return the created webhook configuration with its ID.
+
+### Webhook list endpoint (GET /api/v1/webhooks)
+
+Lists outbound webhook configurations (admin only):
+
+1. **Admin guard** — System admin permission check.
+2. **Fetch** — Use `KVList` with the `webhook:` prefix to enumerate all webhook configurations. Deserialize each value.
+3. **Return response** — Return the list of webhook configurations.
+
+### Webhook delete endpoint (DELETE /api/v1/webhooks/{id})
+
+Deletes an outbound webhook configuration (admin only):
+
+1. **Admin guard** — System admin permission check.
+2. **Extract path parameter** — Parse the webhook `id` from the path.
+3. **Find and delete** — Locate the webhook by scanning the KV store with the `webhook:` prefix for a matching ID. Delete the KV entry. If not found, return HTTP 404.
+4. **Return response** — Return HTTP 204 No Content on success.
+
+### Slash command handler
+
+Implement the `ExecuteCommand` hook for the `/ask` command:
+
+1. **Parse the query** — Extract the query text from `args.Command` by stripping the `/ask ` trigger prefix. If the remaining text is empty, return an ephemeral response with usage help: "Usage: /ask <your question about workspace knowledge>".
+
+2. **Call RAG engine** — Invoke the RAG engine's Query operation with `args.UserId` and the extracted query text.
+
+3. **Format response** — Build a markdown response containing the synthesized answer with citation links. Citations should be formatted as Mattermost markdown links (`[N](permalink)`) so they are clickable in the client.
+
+4. **Return ephemeral response** — Return a `CommandResponse` with `ResponseType` set to `CommandResponseTypeEphemeral` and `Text` containing the formatted answer. The response is visible only to the user who invoked the command.
+
+5. **Error handling** — If the RAG engine returns an error, return an ephemeral response with a user-friendly message ("Knowledge base is temporarily unavailable. Please try again later."). Do not expose internal error details.
+
+6. **Context from channel** — The slash command inherits the channel context from where it was invoked (`args.ChannelId`). This can be included in the query metadata for relevance weighting in future enhancements, but for now it is logged but not used to bias results.
+
+### Command registration (extending step 002)
+
+The `/ask` command was registered during OnActivate in step 002 with basic fields. This step specifies the complete registration:
+
+1. **Trigger** — `ask`
+2. **AutoComplete** — enabled (`true`)
+3. **AutoCompleteDesc** — "Ask your workspace knowledge base a question"
+4. **AutoCompleteHint** — "[question]"
+5. **DisplayName** — "Ask Workspace"
+6. **Description** — "Query the AI knowledge base for answers from your workspace conversations"
+
+## Acceptance Criteria
+
+- [x] ServeHTTP routes requests to the correct handler based on path and HTTP method
+- [x] All endpoints reject unauthenticated requests (missing Mattermost-User-Id header) with HTTP 401
+- [x] Unmatched paths return HTTP 404 with a JSON error body
+- [x] Mismatched HTTP methods on known paths return HTTP 405
+- [x] POST and PUT endpoints enforce Content-Type: application/json and reject other types with HTTP 415
+- [x] Request bodies are size-limited to 1MB to prevent memory exhaustion
+- [x] All responses use Content-Type: application/json
+- [x] Error responses include a JSON body with error message and status code
+- [x] POST /api/v1/query calls the RAG engine and returns synthesized answer, citations, and session ID
+- [x] POST /api/v1/query/followup passes session ID to the RAG engine for multi-turn context
+- [x] GET /api/v1/threads/{root_id}/summary checks channel read permission before returning thread data
+- [x] GET /api/v1/channels/{channel_id}/summary checks channel read permission and supports daily/weekly type filter
+- [x] GET /api/v1/entities/{name}/timeline returns permission-filtered entity mentions across channels
+- [x] GET /api/v1/extractions supports channel_id and type query parameter filters with pagination
+- [x] PUT /api/v1/extractions/{id} updates content, sets edited flag and editor user ID, and triggers re-embedding
+- [x] POST /api/v1/admin/backfill requires system admin permission and returns HTTP 403 for non-admins
+- [x] POST /api/v1/admin/backfill with action "start" rejects with HTTP 409 when a backfill is already running for the channel
+- [x] POST /api/v1/admin/backfill with action "pause" sets status to "paused" and cancels the pending scheduler job
+- [x] POST /api/v1/admin/backfill with action "resume" resumes a paused backfill from its saved cursor position
+- [x] POST /api/v1/admin/backfill with action "pause" or "resume" returns HTTP 404 when no matching backfill exists
+- [x] GET /api/v1/admin/status requires system admin permission and returns queue depth, error count, circuit breaker state, and knowledge base size
+- [x] POST /api/v1/webhooks requires system admin permission and stores webhook config in KV store
+- [x] GET /api/v1/webhooks requires system admin permission and lists all webhook configurations
+- [x] DELETE /api/v1/webhooks/{id} requires system admin permission and returns HTTP 204 on success
+- [x] The /ask slash command extracts query text by stripping the trigger prefix
+- [x] The /ask command with empty text returns usage help as an ephemeral response
+- [x] The /ask command calls the RAG engine and returns a formatted ephemeral response with citation links
+- [x] The /ask command returns a user-friendly error message when the RAG engine fails
+- [x] The /ask command is registered with autocomplete enabled, description, and hint text
diff --git a/tasks/0001-org-memory-ai-knowledge-base/011.md b/tasks/0001-org-memory-ai-knowledge-base/011.md
new file mode 100644
index 000000000000..3eb982fb099a
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/011.md
@@ -0,0 +1,129 @@
+# 011: Channel summary generation worker
+
+## Context
+
+Thread summaries (step 008) capture the arc of individual conversations, but users also need a higher-level view: "What happened in #engineering yesterday?" or "What were the key decisions in #product this week?" Channel summaries aggregate thread summaries and extractions from a time window into a coherent narrative — a daily digest or weekly recap of channel activity. Unlike thread summaries which are event-driven (triggered by thread inactivity), channel summaries are clock-driven: they run on a daily and weekly schedule aligned to a configurable hour (default 8 AM), so the summaries are ready before the workday starts.
+
+This step builds the recurring background worker that generates these summaries. It uses `cluster.Schedule` with a custom wait function that targets the configured `DailySummaryHour` (from step 002), iterates over channels with activity in the relevant time window, gathers existing thread summaries and extractions as source material, sends them to Gemini for synthesis, and stores the results in `ai_channel_summaries`. Weekly summaries aggregate from daily summaries rather than raw posts, creating a hierarchical summarization structure that bounds Gemini token usage.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/pluginapi/cluster/job.go` (lines 60-89) — `MakeWaitForRoundedInterval(interval)` creates a scheduling function that aligns execution to clock-rounded boundaries. For a 24-hour interval, this means the job fires at approximately the same time each day. On first run (`LastFinished.IsZero()`), it fires immediately. Subsequent runs are scheduled to the next rounded interval after the last completion time.
+- `server/public/pluginapi/cluster/job.go` (lines 36-58) — `MakeWaitForInterval(interval)` for the weekly summary variant, which runs every 7 days relative to last completion. Alternatively, `MakeWaitForRoundedInterval` with a 7-day interval aligns to weekly boundaries.
+- `server/public/plugin/api.go` (line 728) — `GetPostsSince(channelId string, time int64) (*model.PostList, *model.AppError)` returns all posts created after a given Unix millisecond timestamp in a channel. Used to detect whether a channel had activity in the summary window.
+- `server/channels/app/recap.go` — The existing recap feature processes channels iteratively: fetches posts via `GetPostsSince`, enriches with usernames, calls LLM for summarization, tracks progress, handles partial failures (some channels succeed, others fail). This iterative-with-partial-failure pattern is directly applicable.
+- `server/channels/app/summarization.go` — `SummarizePosts` sends conversation text to an LLM and receives structured highlights and action items. The channel summary worker follows a similar pattern but operates on thread summaries and extractions rather than raw posts.
+- `server/channels/jobs/recap/worker.go` — The recap worker iterates over channels, tracks progress as a percentage, publishes WebSocket events on status changes, and handles the case where some channels fail without aborting the entire batch. The plugin's channel summary worker should follow this resilience pattern.
+- `server/public/model/utils.go` — `GetMillis()` returns the current Unix millisecond timestamp. `GetMillisForTime(t)` converts a `time.Time` to milliseconds. `GetTimeForMillis(ms)` converts back. Used for computing time window boundaries.
+- `server/channels/jobs/base_schedulers.go` — `GenerateNextStartDateTime(now, nextStartTime)` computes the next daily execution time given a target hour and minute. Shows the pattern for handling "should run today or tomorrow?" logic based on the current time.
+
+## Reuse Opportunities
+
+- **Custom wait function for daily, MakeWaitForRoundedInterval for weekly** — The daily worker needs a custom `nextWaitInterval` that targets the configured `DailySummaryHour`, following the `GenerateNextStartDateTime` pattern. The weekly worker can use `MakeWaitForRoundedInterval(168 * time.Hour)` since the exact hour matters less for weekly cadence. Two separate `cluster.Schedule` jobs are needed — one for daily, one for weekly.
+- **Recap channel iteration pattern** from `recap/worker.go` — iterate over a list of channels, process each one independently, track successes and failures, continue even if individual channels fail. This prevents a problem in one channel from blocking summaries for all other channels.
+- **GetPostsSince as activity detector** — before attempting to summarize a channel, call `GetPostsSince` with the window start time. If the result is empty, skip the channel (no activity to summarize). This avoids wasteful Gemini calls for quiet channels.
+- **Thread summaries as input** rather than raw posts. The architecture specifies that channel summaries are synthesized from thread summaries and extractions within the window, not from individual post messages. This reduces Gemini token usage dramatically — a channel with 50 threads and 500 posts might have 50 thread summaries of ~100 words each (5,000 words) versus 500 raw messages of ~50 words each (25,000 words).
+- **WebSocket notification** via `PublishWebSocketEvent` after a channel summary is stored, so the webapp can offer to display the new summary. Follow the same pattern as `publishRecapUpdate` in the recap worker.
+
+## Deliverables
+
+### Daily summary worker
+
+Create a recurring background worker using `cluster.Schedule` that generates daily channel summaries, aligned to the configured `DailySummaryHour` (from step 002, default 8 = 8:00 AM server time):
+
+1. **Schedule the worker** — During OnActivate (extending step 002), schedule the daily summary job with a custom `nextWaitInterval` function. Instead of `MakeWaitForRoundedInterval(24h)` (which aligns to epoch boundaries, not a specific hour), implement a custom wait function that calculates the duration until the next occurrence of the configured `DailySummaryHour`. On each invocation, the function computes "today at DailySummaryHour" in the server's local timezone — if that time is in the past, it returns the duration until tomorrow at that hour; if it's in the future, it returns the duration until today at that hour. On first run (`LastFinished.IsZero()`), the function should fire immediately. This follows the `GenerateNextStartDateTime` pattern from `server/channels/jobs/base_schedulers.go`. Store the job handle on the Plugin struct for shutdown.
+
+2. **Determine the summary window** — Calculate the time window for the daily summary: from 24 hours before the current time to the current time. Express both boundaries as Unix millisecond timestamps. These boundaries define the "yesterday" period being summarized.
+
+3. **Identify active channels** — Enumerate all channels across all enabled teams. For each channel, check whether it had activity in the summary window. There are two approaches, and the implementer should choose based on performance:
+   - **Option A (query-based)**: For each channel in the enabled teams, call `GetPostsSince(channelId, windowStart)` and check if any posts were returned. This is simple but requires one API call per channel.
+   - **Option B (store-based)**: Query the `ai_thread_summaries` table for summaries with `LastActivityAt` within the window, group by channel ID. This leverages the plugin's own data and avoids per-channel API calls. Channels with thread summaries in the window definitely had activity.
+
+   Either approach should skip channels that had no activity — no summary should be generated for quiet channels.
+
+4. **Process each active channel** — For each channel with activity, generate a daily summary:
+
+   a. **Gather source material** — Query the store for all thread summaries (`ai_thread_summaries`) and extractions (`ai_extractions`) associated with the channel whose timestamps fall within the summary window. Assemble these into a structured text block with each thread summary and its key extractions.
+
+   b. **Fetch channel metadata** — Get the channel name and team name via the plugin API for inclusion in the Gemini prompt and for display purposes.
+
+   c. **Call Gemini** — Send the assembled source material to the Gemini client's synthesis operation (step 004) with a prompt instructing it to: summarize the key activities, decisions, and outcomes for the channel during the time window; organize by topic or theme; cite specific threads where major decisions were made. The prompt should identify this as a daily summary.
+
+   d. **Store the result** — Insert a row in `ai_channel_summaries` (step 003) with: a new ID, the channel ID, type "daily", the summary text, the window start and end timestamps, and the creation timestamp. The unique constraint on channel + type + window start prevents duplicate summaries if the worker runs twice for the same window.
+
+   e. **Embed the summary** — Create a processing log entry with job type "embed" and source type "summary" for the channel summary text, so the processing worker (step 007) generates embeddings for it. This makes channel summaries searchable via the RAG engine.
+
+5. **Handle channel failures gracefully** — If generating a summary for one channel fails (Gemini error, database error), log the error and continue to the next channel. Do not abort the entire batch. Track the count of successes and failures and log a summary at the end.
+
+6. **Circuit breaker awareness** — Before processing the batch, check the Gemini circuit breaker state. If the circuit breaker is open, skip the entire run and return — summaries will be generated on the next cycle when the API recovers. If the circuit breaker opens mid-batch (a channel's Gemini call fails and triggers the breaker), stop processing remaining channels and return. The remaining channels will be processed on the next run.
+
+### Weekly summary worker
+
+Create a second recurring background worker using `cluster.Schedule` with `MakeWaitForRoundedInterval(168 * time.Hour)` (7 days) for weekly channel summaries:
+
+1. **Schedule the worker** — During OnActivate, schedule the weekly summary job separately from the daily worker. Store its job handle for shutdown.
+
+2. **Determine the summary window** — The weekly window spans from 7 days before the current time to the current time.
+
+3. **Aggregate from daily summaries** — Instead of gathering thread summaries and extractions (which the daily summaries already cover), the weekly worker gathers daily summaries for each channel within the window. This creates a hierarchical summarization: raw posts → thread summaries → daily summaries → weekly summary. Each layer reduces content volume by an order of magnitude.
+
+4. **Process each channel** — For each channel that has at least one daily summary in the weekly window:
+
+   a. **Gather daily summaries** — Query `ai_channel_summaries` for rows matching the channel, type "daily", and window start timestamps within the weekly window. Order by window start ascending.
+
+   b. **Call Gemini** — Send the assembled daily summaries to the Gemini client with a prompt that requests a weekly synthesis: high-level themes, major decisions, key outcomes across the week, and significant trends or patterns. The prompt should identify this as a weekly summary.
+
+   c. **Store the result** — Insert a row in `ai_channel_summaries` with type "weekly", the summary text, and the weekly window boundaries. The unique constraint prevents duplicates.
+
+   d. **Embed the summary** — Same as daily — create a processing log entry for embedding.
+
+5. **Same failure handling** — Per-channel failure isolation and circuit breaker awareness, identical to the daily worker.
+
+### Time window edge cases
+
+The summary workers must handle several time-related edge cases:
+
+1. **First run after activation** — Both workers fire immediately on first activation (since `LastFinished` is zero). The daily worker should generate a summary for "the last 24 hours" relative to the current time, even if no previous summary exists. The weekly worker should generate for "the last 7 days."
+
+2. **Plugin downtime** — If the plugin was deactivated for 3 days and reactivated, the daily worker fires immediately and generates a summary for the last 24 hours. The intervening 2 days are not automatically backfilled — they would need the admin backfill endpoint (step 017) if coverage is desired.
+
+3. **Duplicate prevention** — The unique constraint on (channel_id, type, window_start) in `ai_channel_summaries` prevents duplicate summaries. If the worker runs twice for the same window (e.g., during a cluster failover), the second insert is a no-op. The worker should handle the duplicate constraint gracefully (not treat it as an error).
+
+4. **Time zone considerations** — The window boundaries are calculated in UTC. The configured summary hour (e.g., 8 AM) is in the server's local time zone, as determined by the custom wait function's use of `time.Now().Local()`. This means the "daily summary at 8 AM" runs at 8 AM server time, which may not align with all users' time zones. This is an acceptable limitation documented for administrators.
+
+### WebSocket notification
+
+After storing a channel summary, publish a WebSocket event to notify connected clients:
+
+1. **Event name** — Pass `channel_summary_ready` as the event name to `PublishWebSocketEvent`. The plugin API automatically prepends `custom_org-memory_` (the `custom_{pluginid}_` prefix), so the full wire-format event name received by clients is `custom_org-memory_channel_summary_ready`.
+2. **Payload** — Include the channel ID, summary type (daily/weekly), and the window's end timestamp.
+3. **Broadcast** — Broadcast to the channel so all members can see the new summary indicator.
+
+### Shutdown
+
+During OnDeactivate (extending step 002), close both the daily and weekly worker job handles to stop the recurring schedules. Let any in-progress channel summarization complete before stopping.
+
+## Acceptance Criteria
+
+- [x] The daily summary worker is scheduled via `cluster.Schedule` with a custom wait function that targets the configured `DailySummaryHour` (default 8 AM server time), and starts during OnActivate
+- [x] The weekly summary worker is scheduled via `cluster.Schedule` with `MakeWaitForRoundedInterval(168 * time.Hour)` and starts during OnActivate
+- [x] Both workers stop gracefully during OnDeactivate
+- [x] The daily worker calculates a 24-hour window (current time minus 24 hours to current time) for each run
+- [x] The weekly worker calculates a 7-day window for each run
+- [x] Channels with no activity in the summary window are skipped without generating a summary
+- [x] Daily summaries are synthesized from thread summaries and extractions within the window, not from raw posts
+- [x] Weekly summaries are synthesized from daily summaries within the window, creating a hierarchical summarization
+- [x] Each summary is sent to the Gemini client with a prompt that instructs topic-organized synthesis with thread citations
+- [x] Summary results are stored in `ai_channel_summaries` with the correct type (daily/weekly) and window timestamps
+- [x] The unique constraint on (channel_id, type, window_start) prevents duplicate summaries, and the worker handles duplicates gracefully
+- [x] A processing log entry with source type "summary" is created for each channel summary so it gets embedded by the processing worker
+- [x] Channel-level failures do not abort the entire batch — the worker continues to the next channel
+- [x] Success and failure counts are logged at the end of each batch run
+- [x] The worker skips the entire run when the Gemini circuit breaker is open
+- [x] The worker stops processing remaining channels if the circuit breaker opens mid-batch
+- [x] The first run after plugin activation fires immediately and generates summaries for the most recent window
+- [x] A WebSocket event (`custom_org-memory_channel_summary_ready`) is published after each successful summary storage
+- [x] The WebSocket event is broadcast to the channel and includes the channel ID, summary type, and window end timestamp
+- [x] Both workers use the cluster scheduling to ensure only one cluster node generates summaries at a time
diff --git a/tasks/0001-org-memory-ai-knowledge-base/012.md b/tasks/0001-org-memory-ai-knowledge-base/012.md
new file mode 100644
index 000000000000..30a303c65f09
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/012.md
@@ -0,0 +1,139 @@
+# 012: Outbound webhook dispatcher
+
+## Context
+
+The knowledge base extracts structured information — decisions and action items — from conversations. This information is valuable beyond the Mattermost workspace: project management tools, documentation systems, notification platforms, and custom integrations all benefit from receiving real-time signals about team decisions and commitments. The outbound webhook dispatcher bridges this gap by sending HTTP POST notifications to configured external URLs whenever new decisions or action items are extracted.
+
+This is a lightweight integration layer, not a message queue. Deliveries are best-effort with limited retries (3 attempts with exponential backoff). There is no persistent retry queue — if all retries fail, the delivery is logged and discarded. This design keeps the dispatcher simple and prevents failed webhooks from accumulating unbounded state or blocking the processing pipeline. Webhook configurations are stored in the KV store (not the database) because they are admin-managed, low-volume, and benefit from the KV store's simplicity over a separate SQL table.
+
+The dispatcher is triggered by the processing worker (step 007) and debounce handler (step 008) after new extractions are stored. It does not run on its own schedule — it executes synchronously (but quickly) as the final step in extraction processing.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/channels/app/webhook.go` (lines 99-227) — Mattermost's outgoing webhook implementation. `TriggerWebhook` dispatches to callback URLs concurrently via goroutines (one per URL) and waits for all to complete. `doOutgoingWebhookRequest` constructs the HTTP POST with `context.WithTimeout`, sets Content-Type and Accept headers, and reads the response with a 1MB size limit. The timeout is configurable via `ServiceSettings.OutgoingIntegrationRequestsTimeout` (default 30 seconds). This is the closest reference pattern for the plugin's own outbound HTTP calls.
+- `server/public/shared/httpservice/httpservice.go` — The shared HTTP service that creates outbound HTTP clients with security features: reserved IP filtering (SSRF protection), proxy support, configurable timeouts (connect timeout 3s, request timeout 30s), and TLS configuration. Plugins do not have direct access to this service, but the timeout and transport configuration patterns should be followed when creating the plugin's own HTTP client.
+- `server/public/model/outgoing_webhook.go` — The `OutgoingWebhook` model with `CallbackURLs`, `Token`, `TriggerWords`, `ContentType`. The `OutgoingWebhookPayload` struct defines the standard payload format. While the plugin's webhook payload differs (extraction data, not post data), the model structure and naming conventions are worth referencing.
+- `server/public/pluginapi/kv.go` — KV store operations for webhook configuration storage: `Set(key, value)` for storing configs, `Get(key, &dest)` for retrieving, `Delete(key)` for removal, `ListKeys(page, perPage, WithPrefix(prefix))` for enumerating all configs by prefix. The `webhook:{channel_id}:{webhook_id}` key pattern from the architecture spec.
+- `server/channels/utils/backoff.go` — `ProgressiveRetry` with predefined backoff timeout arrays. The plugin's webhook retry uses a simpler fixed sequence (1s, 2s, 4s) but the general backoff pattern is consistent with this utility.
+- `server/public/model/utils.go` — `model.NewId()` for generating webhook configuration IDs. `model.GetMillis()` for timestamps in webhook payloads.
+- `server/channels/app/integration_action.go` (line 255) — Response body size limiting via `io.LimitReader(resp.Body, MaxIntegrationResponseSize)`. The webhook dispatcher should apply the same limit to prevent external services from consuming memory with oversized responses.
+
+## Reuse Opportunities
+
+- **HTTP client timeout pattern** from `doOutgoingWebhookRequest` — use `context.WithTimeout` with a 30-second timeout for each webhook delivery attempt. This prevents slow or hanging external services from blocking the processing pipeline.
+- **Concurrent dispatch with WaitGroup** from `TriggerWebhook` — when multiple webhooks match a channel, dispatch to each concurrently and wait for all to complete. This keeps the total dispatch latency bounded by the slowest webhook rather than the sum of all webhooks.
+- **KV store prefix-based enumeration** — use `ListKeys` with the `webhook:` prefix to find all webhook configurations, then filter by channel ID. For the common case of checking webhooks for a specific channel, use the more specific prefix `webhook:{channel_id}:` to narrow the search.
+- **model.NewId()** for webhook configuration IDs, consistent with all Mattermost entity IDs.
+- **Response size limiting** from the integration action handler — read at most 1MB from the webhook response body to prevent memory exhaustion from malicious or misconfigured external services.
+
+## Deliverables
+
+### Webhook configuration type
+
+Define a type representing a webhook configuration with these fields:
+
+- **ID** — Unique 26-character identifier (generated via `model.NewId()`)
+- **ChannelId** — The channel this webhook monitors for new extractions
+- **URL** — The target URL to send HTTP POST requests to (must be a valid HTTPS or HTTP URL)
+- **ExtractionTypes** — A list of extraction types that trigger this webhook (e.g., "decision", "action_item"). Only extractions matching one of these types cause a delivery.
+- **Secret** — An optional shared secret used to compute an HMAC-SHA256 signature for payload verification. If empty, no signature is included.
+- **CreatedAt** — Unix millisecond timestamp of creation
+- **CreatedBy** — User ID of the admin who created the webhook
+
+### Webhook configuration CRUD
+
+The CRUD operations for webhook configurations are called by the HTTP API handlers (step 010). This step implements the storage layer:
+
+1. **Create** — Accept a webhook configuration (without ID and timestamps), generate an ID via `model.NewId()`, set the creation timestamp, and store in the KV store with key `webhook:{channelId}:{webhookId}`. Return the complete configuration with the generated ID.
+
+2. **List** — Enumerate all webhook configurations by scanning KV store keys with the `webhook:` prefix. Deserialize each value into a webhook configuration. Return the full list. For efficiency, paginate the `ListKeys` call (page size 100) and accumulate results.
+
+3. **Get by ID** — Given a webhook ID, scan the KV store for a matching key. Since the key includes both channel ID and webhook ID, and the caller may not know the channel ID, scan with the `webhook:` prefix and match the ID suffix. Alternatively, maintain a secondary index in a single KV entry that maps webhook IDs to their full keys.
+
+4. **Delete** — Given a webhook ID, locate the full key (same scan as Get), then delete the KV entry. Return success even if the webhook was already deleted (idempotent).
+
+5. **Find by channel** — Given a channel ID, enumerate KV store keys with prefix `webhook:{channelId}:` and deserialize all matching configurations. This is the primary lookup used by the dispatcher when checking whether to fire webhooks after an extraction.
+
+### Dispatch function
+
+Implement the core dispatch function that is called by the processing worker (step 007) and debounce handler (step 008) after new extractions are stored:
+
+1. **Input** — Accept a list of newly stored extraction items, each with: extraction type, content text, post ID, channel ID, and metadata.
+
+2. **Find matching webhooks** — For each unique channel ID in the extraction list, call the "find by channel" operation to get all webhook configurations for that channel. If no webhooks are configured for the channel, return immediately.
+
+3. **Filter by extraction type** — For each webhook, filter the extraction list to only include types that the webhook is configured to receive. If no extractions match the webhook's type filter, skip that webhook.
+
+4. **Build payload** — For each matching webhook, construct the outbound payload containing:
+   - An array of extraction items, each with: type, content text, source post ID, source post permalink (constructed as `{SiteURL}/pl/{postId}`), channel ID, and timestamp
+   - A metadata block with: the plugin ID, the event type ("extraction_created"), and the delivery timestamp
+
+5. **Dispatch with retries** — For each webhook, send the payload as an HTTP POST to the configured URL. The dispatch includes retry logic:
+   - Serialize the payload as JSON
+   - Set `Content-Type: application/json`
+   - If the webhook has a secret configured, compute an HMAC-SHA256 signature of the raw JSON payload bytes using the secret as the key, and include it in a `X-Org-Memory-Signature` header as a hex-encoded string
+   - Send the request with a 30-second timeout
+   - If the request fails (network error, timeout, or non-2xx response status), retry with exponential backoff: wait 1 second, retry; wait 2 seconds, retry; wait 4 seconds, retry
+   - After 3 failed retries (4 total attempts including the original), log the failure as a warning and discard the delivery
+
+6. **Concurrency** — If multiple webhooks match for a batch of extractions, dispatch to each webhook concurrently (separate goroutines) and wait for all to complete before returning. This keeps the total dispatch latency bounded.
+
+7. **Non-blocking behavior** — The dispatcher must not slow down the processing pipeline. Individual webhook timeouts (30 seconds) and retries (up to ~7 seconds of backoff) are acceptable because the dispatcher runs after extraction storage is already complete — the data is safely persisted regardless of webhook delivery success.
+
+### HMAC signature verification
+
+When a webhook configuration includes a secret, the dispatcher computes an HMAC-SHA256 signature to allow the receiver to verify the payload's authenticity and integrity:
+
+1. **Computation** — Take the raw JSON payload bytes (before any transport encoding), use the webhook's secret as the HMAC key, compute the SHA256 digest, and hex-encode the result.
+
+2. **Header** — Include the signature in the `X-Org-Memory-Signature` request header. The format is the hex-encoded HMAC-SHA256 digest.
+
+3. **Verification by receiver** — The external service computes the same HMAC-SHA256 over the received request body using its copy of the shared secret and compares it to the header value. If they match, the payload is authentic and unmodified. This is a widely-used pattern (GitHub, Stripe, Slack all use similar approaches).
+
+4. **No signature when no secret** — If the webhook's secret field is empty, the signature header is omitted entirely.
+
+### Integration with processing pipeline
+
+The dispatcher is called at two points in the processing pipeline:
+
+1. **From the processing worker (step 007)** — After the extraction job handler stores new extractions for a post, it calls the dispatcher with the new extraction items. This happens within the worker's per-item processing, after the extraction store writes but before the item is marked as "complete". If the dispatcher fails entirely (all webhooks fail), this does not affect the processing log status — extractions are stored regardless.
+
+2. **From the debounce handler (step 008)** — After thread-level summarization produces new extractions, the debounce handler calls the dispatcher with the thread-level extraction items. Same fire-and-forget semantics.
+
+The dispatcher should handle being called with an empty extraction list gracefully (return immediately without any KV lookups).
+
+### Failed delivery tracking
+
+Track webhook delivery failures for admin visibility via the pipeline status endpoint (step 010):
+
+1. **In-memory counter** — Maintain a counter of total failed deliveries (after all retries exhausted) per webhook ID. This counter is exposed by the metrics/observability layer (step 014) and the admin status endpoint.
+
+2. **Log-based audit** — Each failed delivery (after all retries) is logged at the warning level with: webhook ID, target URL (with any query parameters redacted), channel ID, number of extractions in the payload, and the last error message. This provides an audit trail in the server logs.
+
+3. **No persistent retry queue** — Failed deliveries are discarded after logging. There is no mechanism to re-deliver failed payloads. If an admin needs to replay deliveries, they can use the backfill endpoint to reprocess the relevant posts, which will regenerate extractions and re-trigger webhooks.
+
+## Acceptance Criteria
+
+- [x] Webhook configurations are stored in the KV store with key pattern `webhook:{channelId}:{webhookId}`
+- [x] Webhook configurations include ID, channel ID, target URL, extraction type filter, optional HMAC secret, creation timestamp, and creator user ID
+- [x] The create operation generates a unique ID and stores the configuration
+- [x] The list operation enumerates all webhook configurations by scanning the KV store with the `webhook:` prefix
+- [x] The delete operation removes a webhook configuration by ID (idempotent)
+- [x] The find-by-channel operation returns all webhook configurations for a given channel ID
+- [x] The dispatcher accepts a list of new extractions and sends HTTP POST requests to matching webhooks
+- [x] Only webhooks whose extraction type filter includes the extraction's type receive the delivery
+- [x] The webhook payload includes extraction type, content, source post permalink, channel ID, and timestamp
+- [x] Payloads are serialized as JSON with Content-Type: application/json
+- [x] When a webhook has a secret, an HMAC-SHA256 signature of the payload is included in the X-Org-Memory-Signature header
+- [x] When a webhook has no secret, the signature header is omitted
+- [x] Failed deliveries are retried up to 3 times with exponential backoff (1s, 2s, 4s waits between retries)
+- [x] After all retries fail, the delivery is logged as a warning and discarded
+- [x] Each delivery attempt uses a 30-second HTTP request timeout
+- [x] Multiple webhooks for the same channel are dispatched concurrently
+- [x] The dispatcher is called by the processing worker after storing new extractions
+- [x] The dispatcher is called by the debounce handler after storing thread-level extractions
+- [x] An empty extraction list causes the dispatcher to return immediately without KV lookups
+- [x] Failed delivery counts are tracked for admin visibility via the status endpoint
+- [x] Webhook delivery failures do not affect the processing log status — extractions are stored regardless of delivery success
diff --git a/tasks/0001-org-memory-ai-knowledge-base/013.md b/tasks/0001-org-memory-ai-knowledge-base/013.md
new file mode 100644
index 000000000000..594512f3dbe8
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/013.md
@@ -0,0 +1,111 @@
+# 013: Data retention and lifecycle cleanup
+
+## Context
+
+Mattermost's data retention system periodically sweeps the database to delete posts older than a configured retention window. When a post is deleted by retention, all knowledge base artifacts derived from that post — embeddings, extractions, entity mentions, summaries — must be cleaned up too. Without this cleanup, the knowledge base would accumulate stale references to deleted content, waste storage, and potentially return RAG results that reference posts users can no longer access.
+
+The plugin participates in retention by implementing the `RunDataRetention` hook. When Mattermost's data retention job runs (typically scheduled for off-hours, e.g., 2 AM), it calls this hook on every active plugin with the current timestamp and a batch size. The plugin must delete its derived data in batches, returning the count of deleted rows. Mattermost calls the hook repeatedly until the returned count is zero, indicating all aged-out data has been cleaned.
+
+This step also handles cascade deletion from the `MessageHasBeenDeleted` hook (step 006) for individual post deletions, and provides a supplementary cleanup mechanism for orphaned data that might accumulate due to edge cases (e.g., plugin downtime during a retention sweep, or posts deleted directly in the database bypassing hooks).
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/plugin/hooks.go` (line 306) — `RunDataRetention(nowTime, batchSize int64) (int64, error)` hook signature. `nowTime` is the current timestamp in Unix milliseconds. `batchSize` is the maximum number of records to delete per invocation. Returns the count of deleted rows and any error. Hook ID: `RunDataRetentionID = 24`. Minimum server version: 6.4.
+- `server/channels/app/plugin_hooks_test.go` (lines 1333-1376) — Test for the `RunDataRetention` hook. Shows the invocation pattern: `hooks.RunDataRetention(0, 0)` with the server checking the returned count. The server calls `RunMultiHook` which invokes the hook on each active plugin.
+- `server/public/model/config.go` (lines 3260-3327) — `DataRetentionSettings` configuration: `MessageRetentionHours` (how long to keep messages), `BatchSize` (default 3000), `TimeBetweenBatchesMilliseconds` (default 100ms), `DeletionJobStartTime` (default "02:00"), `PreservePinnedPosts` (don't delete pinned posts). The `batchSize` parameter passed to the hook comes from this configuration.
+- `server/channels/store/sqlstore/post_store.go` (lines 2593-2606) — `PermanentDeleteBatch(endTime int64, limit int64)` shows the core batch deletion pattern: `DELETE FROM table WHERE Id = any (array (SELECT Id FROM table WHERE CreateAt < ? LIMIT ?))`. This subquery-based batch deletion ensures a bounded number of rows are deleted per call, preventing long-running transactions.
+- `server/channels/store/sqlstore/retention_policy_store.go` — `genericPermanentDeleteBatchForRetentionPolicies` implements multi-stage batch deletion with cursor tracking. Deletes rows matching retention policies in batches, returns the count and whether more data exists. Uses Squirrel query builder with `sq.Dollar` placeholders.
+- `server/channels/db/migrations/postgres/000053_create_retention_policies.up.sql` — Shows `ON DELETE CASCADE` foreign key patterns for linked tables. When a parent row is deleted, child rows are automatically removed. The plugin's schema (step 003) uses similar cascades from `Posts` to plugin tables.
+- `server/public/model/utils.go` — `GetMillis()` and `GetTimeForMillis(millis)` for timestamp operations. The `nowTime` parameter in the hook is a Unix millisecond timestamp comparable to `CreateAt` columns.
+
+## Reuse Opportunities
+
+- **Batch deletion with subquery pattern** from `PermanentDeleteBatch` — delete rows whose `CreateAt` is older than the retention cutoff, limited by `batchSize`. This prevents the deletion from locking the table for an extended period. The plugin should use the same `DELETE WHERE Id IN (SELECT Id WHERE condition LIMIT batch)` pattern.
+- **ON DELETE CASCADE from Posts** — The plugin's schema (step 003) defines foreign keys from `ai_embeddings`, `ai_extractions`, and `ai_entity_mentions` to the `Posts` table with `ON DELETE CASCADE`. When Mattermost's core retention deletes a post, the cascade automatically removes related plugin rows. The `RunDataRetention` hook acts as a secondary cleanup for rows that might not have FK cascades (e.g., `ai_thread_summaries` keyed by root post ID, `ai_channel_summaries` which reference channels rather than individual posts, and `ai_processing_log` entries).
+- **DataRetentionSettings.BatchSize** — The `batchSize` parameter from the hook call matches the admin-configured retention batch size (default 3000). The plugin should respect this value rather than defining its own batch size.
+- **Squirrel query builder** — Use Squirrel with `sq.Dollar` placeholders for the batch deletion queries, consistent with all store operations from step 003.
+
+## Deliverables
+
+### RunDataRetention hook implementation
+
+Implement the `RunDataRetention` hook that the Mattermost server calls during data retention sweeps:
+
+1. **Determine the retention cutoff** — The `nowTime` parameter represents the current time. However, the plugin does not independently determine the retention window — it relies on the fact that Mattermost's core has already deleted (or is about to delete) posts older than the retention threshold. The plugin's job is to clean up derived data for posts that no longer exist in the core `Posts` table. The cutoff is therefore determined by checking which posts have been deleted.
+
+2. **Delete orphaned embeddings** — Query `ai_embeddings` for rows whose `PostId` no longer exists in the `Posts` table (the post was deleted by retention or manually). Delete up to `batchSize` such orphaned rows. If the ON DELETE CASCADE from the Posts FK handles this automatically, this query may return zero rows — which is correct and expected.
+
+3. **Delete orphaned extractions** — Same pattern for `ai_extractions`: find rows whose `PostId` no longer has a corresponding post, delete up to `batchSize` rows.
+
+4. **Delete orphaned entity mentions** — Same for `ai_entity_mentions`.
+
+5. **Delete orphaned thread summaries** — Query `ai_thread_summaries` for rows whose root post ID (stored as `PostId`) no longer exists in the `Posts` table. Thread summaries reference the root post, so when the root is deleted by retention, the thread summary should be removed.
+
+6. **Delete aged channel summaries** — Channel summaries have their own lifecycle: daily summaries older than a reasonable retention period (e.g., 90 days) and weekly summaries older than a longer period (e.g., 365 days) should be cleaned up even if the channel still exists. These are rolling summaries — older ones become less relevant as newer ones replace them. Delete up to `batchSize` channel summary rows where the window end timestamp is older than the retention threshold.
+
+7. **Delete completed processing log entries** — Processing log entries with "complete" or "error" status that are older than a retention period (e.g., 30 days) can be safely deleted. They serve no further purpose once the work is done. Pending and processing entries are preserved regardless of age.
+
+8. **Delete aged query log entries** — Query log entries older than a retention period (e.g., 90 days) can be cleaned up to prevent unbounded growth. The query log is an audit trail, but infinite retention is unnecessary for a plugin-level log.
+
+9. **Return the total count** — Sum the number of rows deleted across all tables and return the total. If the total is greater than zero, Mattermost will call the hook again to continue cleanup. If the total is zero, all aged-out data has been cleaned and the retention sweep moves on.
+
+10. **Respect the batch size** — The total number of rows deleted across all tables in a single invocation should not exceed `batchSize`. Distribute the batch budget across tables in a round-robin or proportional fashion. A simple approach: allocate `batchSize / number_of_tables` to each table's deletion query. If one table has fewer rows to delete, the remaining budget can be applied to the next table.
+
+### Cascade deletion coordination
+
+The plugin's cleanup strategy has two layers that work together:
+
+1. **Foreign key cascades (automatic)** — The schema (step 003) defines `ON DELETE CASCADE` from plugin tables to the `Posts` table. When Mattermost core deletes a post (via retention or `DeletePost`), PostgreSQL automatically cascades the deletion to `ai_embeddings`, `ai_extractions`, and `ai_entity_mentions` rows that reference that post. This is the primary cleanup mechanism and handles the vast majority of cases.
+
+2. **RunDataRetention hook (supplementary)** — The hook catches cases that cascades don't cover:
+   - `ai_thread_summaries` are keyed by the thread root post ID but may not have a direct FK to `Posts` (depending on schema design choices in step 003)
+   - `ai_channel_summaries` reference channels, not individual posts — they age out independently
+   - `ai_processing_log` entries are transient work items that should be cleaned after completion
+   - `ai_query_log` entries are audit records that should be cleaned after a retention period
+   - Orphaned rows from any edge case where the cascade didn't fire (e.g., posts deleted by direct SQL rather than through Mattermost's API)
+
+### MessageHasBeenDeleted coordination
+
+Step 006's `MessageHasBeenDeleted` hook performs immediate cleanup when an individual post is deleted (not via retention). The retention hook provides a complementary batch cleanup for bulk deletions. The two mechanisms should not conflict:
+
+1. **Idempotent deletions** — Both the per-post hook and the retention hook may attempt to delete the same rows. All delete operations must be idempotent — deleting a row that doesn't exist (already deleted by the other mechanism) should succeed silently.
+
+2. **No double-counting** — If the FK cascade already deleted `ai_embeddings` rows when a post was deleted, the retention hook's orphan check will find zero orphaned rows for that post — which is correct.
+
+### Channel summary retention thresholds
+
+Unlike post-derived data (which follows the core retention policy), channel summaries have their own retention schedule because they are aggregate artifacts, not directly tied to individual posts:
+
+1. **Daily summary retention** — Daily summaries older than 90 days are eligible for cleanup. This keeps approximately 3 months of daily digests available.
+
+2. **Weekly summary retention** — Weekly summaries older than 365 days are eligible for cleanup. This keeps approximately 1 year of weekly recaps.
+
+3. **These thresholds are compile-time constants**, not user-facing configuration. They represent reasonable defaults for a knowledge base plugin. Administrators who need different values can adjust them in a future configuration update.
+
+### Processing log and query log retention
+
+1. **Processing log** — Entries with "complete" or "error" status older than 30 days are deleted. Entries with "pending" or "processing" status are never deleted by retention regardless of age — they represent unfinished work.
+
+2. **Query log** — Entries older than 90 days are deleted. The query log grows with every user query and can become large on active workspaces.
+
+## Acceptance Criteria
+
+- [x] The `RunDataRetention(nowTime, batchSize int64) (int64, error)` hook is implemented
+- [x] The hook deletes orphaned `ai_embeddings` rows whose source posts no longer exist, up to the batch size
+- [x] The hook deletes orphaned `ai_extractions` rows whose source posts no longer exist
+- [x] The hook deletes orphaned `ai_entity_mentions` rows whose source posts no longer exist
+- [x] The hook deletes orphaned `ai_thread_summaries` rows whose root posts no longer exist
+- [x] The hook deletes `ai_channel_summaries` daily entries older than 90 days
+- [x] The hook deletes `ai_channel_summaries` weekly entries older than 365 days
+- [x] The hook deletes `ai_processing_log` entries with "complete" or "error" status older than 30 days
+- [x] The hook does not delete `ai_processing_log` entries with "pending" or "processing" status regardless of age
+- [x] The hook deletes `ai_query_log` entries older than 90 days
+- [x] The total number of deleted rows across all tables does not exceed `batchSize` per invocation
+- [x] The hook returns the total count of deleted rows (zero means cleanup is complete)
+- [x] The hook returns zero when there is no data to clean up
+- [x] All delete operations are idempotent — rows already deleted by FK cascades or per-post hooks do not cause errors
+- [x] The batch deletion uses the subquery pattern (DELETE WHERE Id IN SELECT Id WHERE condition LIMIT N) to prevent long-running transactions
+- [x] FK cascade from Posts to ai_embeddings, ai_extractions, and ai_entity_mentions handles the primary cleanup automatically
+- [x] The RunDataRetention hook provides supplementary cleanup for data not covered by FK cascades
diff --git a/tasks/0001-org-memory-ai-knowledge-base/014.md b/tasks/0001-org-memory-ai-knowledge-base/014.md
new file mode 100644
index 000000000000..10005cd5e176
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/014.md
@@ -0,0 +1,194 @@
+# 014: Metrics and observability
+
+## Context
+
+The plugin operates largely in the background — processing posts, generating embeddings, running extraction jobs, synthesizing summaries, answering queries. Without observability into this machinery, administrators have no way to tell whether the plugin is healthy, underperforming, or silently failing. Is the processing queue backing up? Is Gemini rate-limiting us? How many RAG queries are we serving per hour? Is the circuit breaker open?
+
+This step adds a Prometheus metrics endpoint to the plugin using the `ServeMetrics` hook, which Mattermost routes to `localhost:8067/plugins/{plugin_id}/metrics`. The plugin creates its own `prometheus.Registry`, registers counters, histograms, and gauges covering four domains (processing pipeline, Gemini API, RAG queries, embedding operations), and serves the standard Prometheus text exposition format. Prometheus scrapers (or Grafana Agent, Victoria Metrics, etc.) poll this endpoint at their configured interval and store the time series for dashboards and alerting.
+
+The metrics are collected at instrumentation points throughout the codebase — in the processing worker (step 007), Gemini client (step 004), RAG query engine (step 009), chunking engine (step 005), channel summary worker (step 011), webhook dispatcher (step 012), and event hooks (step 006). This step defines the metrics collector struct and registration; the instrumentation call sites were identified as "metrics integration points" in each of those steps.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/plugin/hooks.go` (line 366) — `ServeMetrics(c *Context, w http.ResponseWriter, r *http.Request)` hook signature. Hook ID: `ServeMetricsID = 39`. Minimum server version: 9.2. The server routes requests to `localhost:8067/plugins/{plugin_id}/metrics` to this hook. The URL path is stripped to just the portion after `/metrics` before calling the hook, so the hook receives relative paths (e.g., `/` or `/subpath`).
+- `server/channels/app/platform/metrics.go` (lines 188-239) — The server-side routing for plugin metrics. The `pluginsMetricsRoute` handler at `/plugins/{plugin_id:[A-Za-z0-9\_\-\.]+}/metrics` strips the path prefix and calls `hooks.ServeMetrics` with an empty `plugin.Context`. The plugin receives a standard `http.ResponseWriter` and `*http.Request`, allowing it to use `promhttp.HandlerFor(registry, opts)` directly.
+- `server/enterprise/metrics/metrics.go` (lines 53-254) — Mattermost's own `MetricsInterfaceImpl` struct shows the canonical pattern: a `prometheus.Registry` field, Counter/Histogram/HistogramVec/Gauge/GaugeFunc/GaugeVec fields for each metric, and `MustRegister` calls in the constructor. The struct uses namespace `"mattermost"` and subsystem constants like `MetricsSubsystemPlugin`. The plugin should use a distinct namespace (e.g., `"org_memory"`) to avoid collisions.
+- `server/enterprise/metrics/metrics.go` (lines 304-311) — Counter registration pattern: `prometheus.NewCounter(prometheus.CounterOpts{Namespace, Subsystem, Name, Help, ConstLabels})` followed by `Registry.MustRegister(counter)`. Counters are monotonically increasing — they only go up and are reset on process restart.
+- `server/enterprise/metrics/metrics.go` (lines 862-903) — HistogramVec registration pattern with labels: `prometheus.NewHistogramVec(prometheus.HistogramOpts{...}, []string{"label1", "label2"})`. The `PluginHookTimeHistogram` uses labels `plugin_id`, `hook_name`, `success`. HistogramVec allows a single metric definition to produce multiple label combinations. The `Observe(elapsed)` method records a duration sample.
+- `server/enterprise/metrics/metrics.go` (lines 360-367) — GaugeFunc pattern: `prometheus.NewGaugeFunc(prometheus.GaugeOpts{...}, func() float64 { ... })`. The callback is called each time the metric is scraped, providing a live snapshot (e.g., current connection count). Useful for queue depth and circuit breaker state.
+- `server/enterprise/metrics/metrics.go` (lines 276-281) — Registry initialization pattern: `prometheus.NewRegistry()` creates an isolated registry (not the global default), then `MustRegister(collectors.NewProcessCollector(...))` and `MustRegister(collectors.NewGoCollector())` add standard Go runtime metrics (goroutines, memory, GC).
+- `server/channels/app/plugin_api_tests/manual.test_serve_metrics_plugin/main.go` — A minimal test plugin implementing `ServeMetrics`. Demonstrates the hook signature: receive `*plugin.Context`, `http.ResponseWriter`, `*http.Request`, and write the response directly. The plugin can route on `r.URL.Path` for sub-paths under the metrics endpoint.
+- `server/channels/app/plugin_api_test.go` (lines 2983-3010) — `TestPluginServeMetrics` test. Shows the setup: enable metrics via `MetricsSettings.Enable = true`, set a custom `ListenAddress`, deploy the plugin, and make HTTP requests to `http://localhost:{port}/plugins/{plugin_id}/metrics`. Validates that the response body matches the expected content.
+- `server/enterprise/metrics/metrics.go` (lines 1987-2001) — Metric observation methods: `ObservePluginHookDuration` calls `HistogramVec.With(prometheus.Labels{...}).Observe(elapsed)`. `ObservePluginAPIDuration` follows the same pattern. These show how observation methods wrap the raw Prometheus calls with a clean interface.
+
+## Reuse Opportunities
+
+- **prometheus.NewRegistry() + promhttp.HandlerFor()** — The plugin creates its own isolated registry (not the global `prometheus.DefaultRegisterer`) and uses `promhttp.HandlerFor(registry, promhttp.HandlerOpts{})` to create an HTTP handler that serves the registry's collected metrics in Prometheus text exposition format. This is the standard approach used by Mattermost's own metrics implementation and avoids conflicts with any global metrics from other plugins.
+- **Namespace/Subsystem/Name hierarchy** from Mattermost's metrics. The plugin uses a unique namespace (`org_memory`) with subsystems for each domain (`processing`, `gemini`, `rag`, `embedding`). This produces metric names like `org_memory_processing_items_total` and `org_memory_gemini_request_duration_seconds` that are self-documenting and sortable.
+- **HistogramVec with labels** for metrics that need dimensional breakdown. For example, processing latency by job type uses a `job_type` label, Gemini request duration uses an `operation` label. This follows the same pattern as `PluginHookTimeHistogram` which uses `plugin_id`, `hook_name`, and `success` labels.
+- **GaugeFunc for live snapshots** — queue depth and circuit breaker state are best represented as GaugeFunc metrics whose callbacks query the current state at scrape time, rather than being updated on every state change. This avoids synchronization complexity and ensures the metric always reflects the latest state.
+- **Process and Go collectors** — Register `collectors.NewProcessCollector` and `collectors.NewGoCollector` on the plugin's registry to expose standard Go runtime metrics (goroutine count, heap usage, GC statistics). These are useful for diagnosing plugin memory leaks or goroutine leaks without requiring custom instrumentation.
+
+## Deliverables
+
+### Metrics collector struct
+
+Define a struct that holds all the plugin's Prometheus metric instruments and a `prometheus.Registry`. This struct is created once during `OnActivate` (extending step 002) and passed to all components that need to record metrics:
+
+1. **Registry** — A `prometheus.Registry` instance created via `prometheus.NewRegistry()`. All metric instruments are registered on this registry. Standard process and Go collectors are also registered.
+
+2. **Namespace** — All metrics use the namespace `org_memory` to clearly identify them as belonging to this plugin and avoid collisions with Mattermost's own `mattermost` namespace or other plugins.
+
+3. **Processing pipeline metrics** — Instruments for the processing worker (step 007) and event hooks (step 006):
+
+   - **Items processed counter** (`org_memory_processing_items_total`) — A `CounterVec` with a `job_type` label (`embed`, `extract`). Incremented each time a processing log item completes successfully. Tracks throughput by job type.
+   - **Items errored counter** (`org_memory_processing_errors_total`) — A `CounterVec` with a `job_type` label. Incremented each time a processing log item transitions to the error state (after all retries exhausted). Tracks the failure rate.
+   - **Processing latency histogram** (`org_memory_processing_duration_seconds`) — A `HistogramVec` with a `job_type` label. Observes the wall-clock time from when a processing item is picked up by the worker to when it completes (or errors). Bucket boundaries should cover the typical range: 0.1s, 0.25s, 0.5s, 1s, 2.5s, 5s, 10s, 30s, 60s.
+   - **Queue depth gauge** (`org_memory_processing_queue_depth`) — A `GaugeFunc` whose callback queries the count of processing log items with "pending" status. Provides a live view of how many items are waiting to be processed. If the queue depth grows consistently, the worker is not keeping up.
+   - **Stale items gauge** (`org_memory_processing_stale_items`) — A `GaugeFunc` whose callback queries the count of processing log items with "processing" status and a start time older than 5 minutes. Indicates items that are stuck and will be reset by the worker's stale detection.
+   - **Items ingested counter** (`org_memory_processing_items_ingested_total`) — A `Counter` incremented each time a new processing log entry is created by the event hooks (step 006). Tracks the ingest rate separate from the processing rate, showing how quickly work is arriving versus being consumed.
+
+4. **Gemini API metrics** — Instruments for the Gemini client (step 004):
+
+   - **Request counter** (`org_memory_gemini_requests_total`) — A `CounterVec` with an `operation` label (`embed`, `extract`, `synthesize`) and a `status` label (`success`, `error`, `rate_limited`). Tracks the total number of Gemini API calls by operation and outcome.
+   - **Request duration histogram** (`org_memory_gemini_request_duration_seconds`) — A `HistogramVec` with an `operation` label. Observes the wall-clock time of each Gemini API call (including retries within the call). Bucket boundaries for API latency: 0.1s, 0.25s, 0.5s, 1s, 2.5s, 5s, 10s, 30s.
+   - **Rate limit hits counter** (`org_memory_gemini_rate_limit_hits_total`) — A `Counter` incremented each time a Gemini API call receives a rate limit response (HTTP 429 or resource exhausted error). Spikes indicate the plugin is exceeding quota and needs throttling.
+   - **Circuit breaker state gauge** (`org_memory_gemini_circuit_breaker_state`) — A `Gauge` that reflects the current circuit breaker state as a numeric value: 0 = closed (healthy), 1 = half-open (testing), 2 = open (failing). Updated whenever the circuit breaker state changes. This allows alerting on prolonged open states.
+   - **Tokens processed counter** (`org_memory_gemini_tokens_total`) — A `CounterVec` with an `operation` label and a `direction` label (`input`, `output`). If Gemini's response includes token usage metadata, track the total tokens consumed. This helps estimate API costs. If token counts are not available from the response, this metric is omitted.
+
+5. **RAG query metrics** — Instruments for the RAG query engine (step 009):
+
+   - **Query counter** (`org_memory_rag_queries_total`) — A `CounterVec` with a `type` label (`new`, `followup`). Incremented on each query processed. Tracks overall usage of the knowledge base.
+   - **Query duration histogram** (`org_memory_rag_query_duration_seconds`) — A `Histogram` observing end-to-end query latency from receipt to response delivery. Bucket boundaries: 0.1s, 0.25s, 0.5s, 1s, 2.5s, 5s, 10s, 30s, 60s.
+   - **Search result count histogram** (`org_memory_rag_search_results`) — A `Histogram` observing the number of vector search results returned per query (before permission filtering). Bucket boundaries: 0, 1, 2, 5, 10, 20. Tracks how much relevant content exists for typical queries.
+   - **Permission cache hit/miss counter** (`org_memory_rag_permission_cache_total`) — A `CounterVec` with a `result` label (`hit`, `miss`). Tracks the effectiveness of the permission cache. A low hit rate suggests the 60-second TTL is too short or query patterns are highly distributed across users.
+   - **Session hit/miss counter** (`org_memory_rag_session_total`) — A `CounterVec` with a `result` label (`hit`, `miss`, `expired`). Tracks multi-turn session usage. A high miss/expired rate may indicate the 30-minute TTL is too short.
+   - **No results counter** (`org_memory_rag_no_results_total`) — A `Counter` incremented when a query returns zero vector search results and the canned "no results" response is returned. A high rate indicates content gaps in the knowledge base.
+
+6. **Embedding operation metrics** — Instruments for the chunking engine (step 005) and embedding storage:
+
+   - **Embeddings generated counter** (`org_memory_embedding_generated_total`) — A `Counter` incremented each time an embedding vector is generated and stored. Tracks the rate of new content entering the vector index.
+   - **Chunks per post histogram** (`org_memory_embedding_chunks_per_post`) — A `Histogram` observing the number of chunks produced per post by the chunking engine. Bucket boundaries: 1, 2, 3, 5, 10, 15, 20, 32. Tracks the distribution of post complexity — most posts should produce 1-3 chunks; posts hitting the 32-chunk cap may indicate unusually long content.
+   - **Total embeddings gauge** (`org_memory_embedding_total_stored`) — A `GaugeFunc` whose callback queries the count of rows in `ai_embeddings` where `DeleteAt = 0`. Provides a live view of the knowledge base size. Useful for capacity planning.
+
+7. **Channel summary metrics** — Instruments for the channel summary worker (step 011):
+
+   - **Summaries generated counter** (`org_memory_summary_generated_total`) — A `CounterVec` with a `type` label (`daily`, `weekly`). Incremented each time a channel summary is successfully generated and stored.
+   - **Channels skipped counter** (`org_memory_summary_channels_skipped_total`) — A `Counter` incremented for each channel skipped during a summary batch because it had no activity in the window. Tracks how many channels are quiet.
+   - **Summary batch duration histogram** (`org_memory_summary_batch_duration_seconds`) — A `Histogram` observing the wall-clock time for an entire daily or weekly summary batch (processing all channels). Tracks how long the summary generation takes end to end.
+
+8. **Webhook delivery metrics** — Instruments for the webhook dispatcher (step 012):
+
+   - **Webhook deliveries counter** (`org_memory_webhook_deliveries_total`) — A `CounterVec` with a `status` label (`success`, `failed`). Incremented for each webhook delivery attempt's final outcome (after all retries).
+   - **Webhook delivery duration histogram** (`org_memory_webhook_delivery_duration_seconds`) — A `Histogram` observing the time for a single webhook delivery (including retries). Tracks whether external services are responding slowly.
+
+9. **Data retention metrics** — Instruments for the retention hook (step 013):
+
+   - **Retention rows deleted counter** (`org_memory_retention_rows_deleted_total`) — A `CounterVec` with a `table` label identifying which plugin table the rows were deleted from. Tracks how much data retention is cleaning up per table.
+
+### ServeMetrics hook implementation
+
+Implement the `ServeMetrics` hook to serve the plugin's Prometheus metrics:
+
+1. **Create the HTTP handler** — During `OnActivate`, after registering all metrics on the registry, create a `promhttp.HandlerFor(registry, promhttp.HandlerOpts{})` handler. Store this handler on the Plugin struct for reuse across scrape requests.
+
+2. **Serve requests** — In the `ServeMetrics` hook method, delegate to the stored `promhttp.HandlerFor` handler. The handler writes the Prometheus text exposition format (`text/plain; version=0.0.4; charset=utf-8`) to the response writer. Each scrape request triggers the registry to collect current values from all registered metrics and format the output.
+
+3. **No authentication** — The metrics endpoint is served on the internal metrics listener (port 8067 by default), which is separate from the main API port. It does not go through Mattermost's session authentication. This is consistent with how Mattermost's own metrics work — the metrics port is typically only exposed within the internal network or cluster, not to the public internet.
+
+4. **Path routing** — The hook receives requests with paths relative to `/plugins/{plugin_id}/metrics`. For the standard Prometheus scrape at the root path (`/` or empty), serve the full metrics output. The plugin does not need to implement sub-paths — the root handler is sufficient.
+
+### Metrics collector initialization
+
+During `OnActivate` (extending step 002):
+
+1. **Create the collector** — Instantiate the metrics collector struct with a new `prometheus.Registry`.
+
+2. **Register standard collectors** — Register `collectors.NewProcessCollector` and `collectors.NewGoCollector` on the registry for Go runtime metrics.
+
+3. **Register all plugin metrics** — Call `MustRegister` for each metric instrument defined in the collector struct. This is done once during activation and the instruments are reused for the lifetime of the plugin.
+
+4. **Create the HTTP handler** — Build the `promhttp.HandlerFor` handler from the registry.
+
+5. **Wire to components** — Pass the metrics collector (or an interface wrapping it) to the processing worker, Gemini client, RAG engine, chunking engine, channel summary worker, webhook dispatcher, and event hooks. Each component calls the appropriate observation methods on the collector.
+
+6. **No-op fallback** — If metrics initialization fails (e.g., a metric name collision), log a warning and continue with a no-op metrics collector. The plugin should function without metrics rather than failing to activate. The metrics collector interface should have a no-op implementation that silently discards observations.
+
+### Metrics collector interface
+
+Define a Go interface for the metrics collector that all components depend on, rather than depending directly on the concrete struct:
+
+1. **Processing methods** — `IncProcessingItemsComplete(jobType string)`, `IncProcessingItemsError(jobType string)`, `ObserveProcessingDuration(jobType string, seconds float64)`, `IncItemsIngested()`
+
+2. **Gemini methods** — `IncGeminiRequest(operation, status string)`, `ObserveGeminiDuration(operation string, seconds float64)`, `IncGeminiRateLimitHit()`, `SetCircuitBreakerState(state int)`
+
+3. **RAG methods** — `IncRAGQuery(queryType string)`, `ObserveRAGDuration(seconds float64)`, `ObserveSearchResultCount(count int)`, `IncPermissionCacheResult(result string)`, `IncSessionResult(result string)`, `IncNoResults()`
+
+4. **Embedding methods** — `IncEmbeddingsGenerated()`, `ObserveChunksPerPost(count int)`
+
+5. **Summary methods** — `IncSummaryGenerated(summaryType string)`, `IncChannelsSkipped()`, `ObserveSummaryBatchDuration(seconds float64)`
+
+6. **Webhook methods** — `IncWebhookDelivery(status string)`, `ObserveWebhookDeliveryDuration(seconds float64)`
+
+7. **Retention methods** — `IncRetentionRowsDeleted(table string, count int64)`
+
+The interface enables a no-op implementation for when metrics are disabled or initialization fails, and a mock implementation for testing.
+
+### GaugeFunc callbacks and store dependency
+
+Several metrics use `GaugeFunc` with callbacks that query the database at scrape time:
+
+1. **Queue depth callback** — Queries `SELECT COUNT(*) FROM ai_processing_log WHERE Status = 'pending'`. This runs on each Prometheus scrape (typically every 15-30 seconds). The query is lightweight (single count with index on Status) and should use the replica database.
+
+2. **Stale items callback** — Queries `SELECT COUNT(*) FROM ai_processing_log WHERE Status = 'processing' AND StartedAt < (now - 5 minutes)`. Also lightweight and replica-safe.
+
+3. **Total embeddings callback** — Queries `SELECT COUNT(*) FROM ai_embeddings WHERE DeleteAt = 0`. On a large knowledge base, this could be slow. Consider using an estimated count via `pg_class.reltuples` if exact counts prove too expensive, or cache the count with a short TTL.
+
+4. **Circuit breaker state** — Not a database query. The callback reads the in-memory circuit breaker state from the Gemini client (step 004). The Gemini client should expose a method that returns the current state as an integer (0/1/2).
+
+All GaugeFunc callbacks must be safe to call from any goroutine (they are called by the Prometheus library during scrape handling). They should not panic — errors should result in a zero value being returned.
+
+### Integration with admin status endpoint
+
+The admin status endpoint (step 010) provides a JSON summary of the plugin's health. Several of the metrics defined here can also be surfaced through that endpoint:
+
+1. **Processing queue depth** — The same "pending items count" used by the GaugeFunc is useful for the status endpoint's queue depth field.
+
+2. **Circuit breaker state** — The status endpoint reports whether the Gemini circuit breaker is open/closed/half-open.
+
+3. **Recent error rate** — The status endpoint can compute this from the error counter, but for simplicity it may maintain its own in-memory counter. The Prometheus metrics and the status endpoint are complementary — Prometheus provides time-series history for dashboards, while the status endpoint provides a point-in-time JSON snapshot for quick checks.
+
+The metrics collector should provide accessor methods (or expose the GaugeFunc callbacks) so the status endpoint handler can reuse the same queries rather than duplicating them.
+
+### Shutdown
+
+During `OnDeactivate` (extending step 002):
+
+1. **No explicit cleanup needed** — Prometheus registries are garbage collected when the metrics collector struct is released. There is no background goroutine to stop or connection to close.
+
+2. **GaugeFunc callbacks become stale** — After deactivation, the database connections used by GaugeFunc callbacks may be closed. Since the ServeMetrics hook will no longer be called after deactivation, this is not a practical concern. However, if there is a race between deactivation closing the DB and a final scrape calling a GaugeFunc, the callback should handle the error gracefully (return 0).
+
+## Acceptance Criteria
+
+- [x] A metrics collector struct is created with a `prometheus.Registry` and all metric instruments
+- [x] All metrics use the namespace `org_memory` to avoid collisions with Mattermost's `mattermost` namespace
+- [x] Standard Go process and runtime collectors are registered on the plugin's registry
+- [x] The `ServeMetrics` hook is implemented and delegates to `promhttp.HandlerFor(registry, opts)`
+- [x] The metrics endpoint serves Prometheus text exposition format at `localhost:8067/plugins/{plugin_id}/metrics`
+- [x] Processing pipeline metrics include: items processed counter (by job type), items errored counter (by job type), processing duration histogram (by job type), queue depth gauge, stale items gauge, and items ingested counter
+- [x] Gemini API metrics include: request counter (by operation and status), request duration histogram (by operation), rate limit hits counter, and circuit breaker state gauge
+- [x] RAG query metrics include: query counter (by type), query duration histogram, search result count histogram, permission cache hit/miss counter, session hit/miss counter, and no-results counter
+- [x] Embedding metrics include: embeddings generated counter, chunks per post histogram, and total stored embeddings gauge
+- [x] Channel summary metrics include: summaries generated counter (by type), channels skipped counter, and batch duration histogram
+- [x] Webhook delivery metrics include: deliveries counter (by status) and delivery duration histogram
+- [x] Data retention metrics include: rows deleted counter (by table)
+- [x] A Go interface for the metrics collector is defined so components can depend on the interface rather than the concrete struct
+- [x] A no-op implementation of the metrics interface exists for when metrics initialization fails or for testing
+- [x] GaugeFunc callbacks query the replica database and handle errors gracefully (return zero on failure)
+- [x] The metrics collector is initialized during OnActivate and the promhttp handler is stored for reuse
+- [x] If metrics initialization fails, the plugin continues to function with the no-op metrics implementation
+- [x] The circuit breaker state gauge reflects the current Gemini circuit breaker state (0=closed, 1=half-open, 2=open)
+- [x] Histogram bucket boundaries are appropriate for each metric's expected range (sub-second to minutes for API calls, 1-32 for chunks per post)
+- [x] The metrics collector provides accessor methods for queue depth and circuit breaker state so the admin status endpoint (step 010) can reuse them
diff --git a/tasks/0001-org-memory-ai-knowledge-base/015.md b/tasks/0001-org-memory-ai-knowledge-base/015.md
new file mode 100644
index 000000000000..77c17d458c5e
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/015.md
@@ -0,0 +1,186 @@
+# 015: Webapp: RHS panel with query interface
+
+## Context
+
+This step creates the plugin's webapp bundle — the browser-side code that provides the "Ask your workspace" user interface. The webapp registers with Mattermost during initialization, adds an icon to the app bar that toggles a Right-Hand Sidebar panel, and renders a query interface within that panel. Users type a natural language question, the plugin sends it to the backend API (step 010), and the response is rendered as markdown with clickable citation links pointing to original posts.
+
+This step focuses on the initial query flow only — one question, one answer, with citation links. Multi-turn follow-up queries, WebSocket event handling, and "summary available" indicators are deferred to step 016. The separation keeps this step focused on the core registration, rendering, and API integration.
+
+The webapp bundle is built as a single JavaScript file (`webapp/dist/main.js`) that Mattermost loads dynamically via a `<script>` tag when the plugin is activated. Plugins share React, Redux, and other libraries from Mattermost's own bundle via `window.*` globals — they do not bundle their own copies. The plugin receives a `PluginRegistry` instance during initialization and uses its methods to register components, reducers, and event handlers.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `webapp/channels/src/plugins/registry.ts` (line 1063) — `registerRightHandSidebarComponent({component, title})`. Returns `{id, showRHSPlugin, hideRHSPlugin, toggleRHSPlugin}` — action dispatch functions the plugin can invoke to control RHS visibility. The component receives `{webSocketClient, theme}` as props (the `BasePluggableProps` injected by the `Pluggable` wrapper).
+- `webapp/channels/src/plugins/registry.ts` (line 1305) — `registerAppBarComponent({iconUrl, tooltipText, supportedProductIds, rhsComponent, rhsTitle})`. When `rhsComponent` is provided (instead of `action`), the registry internally calls `registerRightHandSidebarComponent` and wires the app bar icon to toggle the RHS. Returns `{id, rhsComponent: {showRHS, hideRHS, toggleRHS}}`. This is the simplest way to wire an app bar icon to an RHS panel.
+- `webapp/channels/src/plugins/registry.ts` (line 821) — `registerReducer({reducer})`. Registers a Redux reducer under the key `'plugins-' + pluginId`. The plugin's state is accessible at `state['plugins-org-memory']` from any connected component or selector.
+- `webapp/channels/src/plugins/index.ts` (line 73) — `window.registerPlugin(pluginId, plugin)`. The plugin's entry point must call this to register itself. The `plugin` object must have an `initialize(registry, store)` method that receives a `PluginRegistry` and the Redux store, and optionally an `uninitialize()` method for cleanup.
+- `webapp/channels/src/plugins/index.ts` (lines 139-191) — Plugin loading flow: the server sends the `manifest.webapp.bundle_path`, Mattermost injects a `<script>` tag to load it, the script calls `window.registerPlugin`, then Mattermost calls `plugin.initialize(registry, store)` with a scoped `PluginRegistry` instance.
+- `webapp/channels/src/types/store/plugins.ts` (lines 131-134) — `BasePluggableProps`: `{webSocketClient: WebSocketClient, theme: Theme}`. These props are always injected into plugin RHS components by the `Pluggable` wrapper. The plugin component does not need to fetch them from the Redux store.
+- `webapp/channels/src/types/store/plugins.ts` (lines 340-343) — `RightHandSidebarComponent` type: `PluginComponent & {title: PluggableText, component: React.ComponentType<BasePluggableProps>}`. This is the shape of the registered component in Redux state.
+- `webapp/channels/src/plugins/rhs_plugin/rhs_plugin.tsx` — The RHS plugin wrapper. Renders a `SearchResultsHeader` with the plugin's title and a popout button, then renders the plugin's component via `<Pluggable pluggableName='RightHandSidebarComponent' pluggableId={pluggableId} />`. The plugin's component fills the area below the header.
+- `webapp/channels/src/plugins/rhs_plugin/index.ts` — Redux connector for the RHS plugin wrapper. Maps `state.plugins.components.RightHandSidebarComponent` to find the active plugin component by `pluggableId` from `getPluggableId(state)`. Extracts `title` and `pluginId` for display.
+- `webapp/channels/src/plugins/pluggable/pluggable.tsx` — The universal plugin renderer. Finds registered components by `pluggableName` in Redux state, optionally filters by `pluggableId`, renders each wrapped in `PluggableErrorBoundary` with injected `theme` and `webSocketClient` props.
+- `webapp/channels/src/plugins/export.ts` (lines 119-134) — `window.PostUtils.formatText(text, options, emojiMap)` and `window.PostUtils.messageHtmlToComponent(html, options)`. These are the standard Mattermost text formatting pipeline: `formatText` converts markdown text to HTML, `messageHtmlToComponent` converts that HTML to React elements. Plugins access these via `window.PostUtils`. The pipeline handles Mattermost-specific markdown extensions (mentions, emojis, code blocks, etc.).
+- `webapp/channels/src/components/markdown/markdown.tsx` — Mattermost's `Markdown` component. Uses `formatText` → `messageHtmlToComponent` internally. Accepts a `message` prop (raw markdown text) and renders it. This is a connected component (needs Redux state for emoji map), so plugins that want standalone markdown rendering typically use the `PostUtils` functions directly instead.
+- `webapp/channels/src/components/widgets/loading/loading_spinner.tsx` — `LoadingSpinner` component. A simple animated spinner widget available for reuse.
+- `webapp/channels/src/components/app_bar/app_bar_plugin_component.tsx` — Renders an app bar icon for a plugin. Loads the image from `iconUrl`, shows a tooltip, highlights when the linked RHS is active (`isButtonActive` check), and dispatches the plugin's `action` on click. Falls back to a generic `PluginIcon` if the image fails to load.
+- `webapp/channels/src/actions/views/rhs.ts` — RHS control actions: `showRHSPlugin(pluggableId)`, `hideRHSPlugin(pluggableId)`, `toggleRHSPlugin(pluggableId)`. These dispatch `UPDATE_RHS_STATE` with `RHSStates.PLUGIN` and the pluggable ID, causing `sidebar_right.tsx` to render `<RhsPlugin/>`.
+- `webapp/channels/src/selectors/rhs.ts` — RHS selectors: `getIsRhsOpen(state)`, `getRhsState(state)`, `getPluggableId(state)`, `getActiveRhsComponent(state)`. Useful for checking whether the plugin's RHS is currently visible.
+- `webapp/platform/client/src/client4.ts` (lines 460-474) — `Client4.getPluginsRoute()` returns `/api/v4/plugins`, `Client4.getPluginRoute(pluginId)` returns `/api/v4/plugins/{pluginId}`. However, the plugin's own API lives at `/plugins/org-memory/api/v1/*` (not under `/api/v4/`), so the API client must construct URLs directly.
+- `webapp/platform/client/src/client4.ts` (lines 573-612) — `Client4.getOptions(options)` shows how Mattermost handles auth on fetch: sets `X-Requested-With: XMLHttpRequest` header, adds bearer token if available, attaches CSRF token from `MMCSRF` cookie for non-GET requests, sets `credentials: 'include'` for cookie auth. Plugin API calls to `/plugins/org-memory/*` go through the same Mattermost server, so the existing session cookie and CSRF handling apply automatically — the plugin's API client just needs to call `fetch` with `credentials: 'include'` and the CSRF token.
+- `webapp/channels/src/components/sidebar_right/sidebar_right.tsx` — The main RHS container. When `isPluginView` is true (i.e., `rhsState === RHSStates.PLUGIN`), it renders `<RhsPlugin/>`. The RHS area fills the right sidebar with a fixed width. The plugin component receives the full height below the header.
+- `server/plugins/org-memory/plugin.json` — The plugin manifest (step 001). The `webapp.bundle_path` field points to the bundled JS file. The plugin ID is `org-memory`.
+- `server/plugins/org-memory/webapp/` — The webapp source directory (step 001). Contains `package.json`, bundler config, and entry point. This step adds the actual components, reducer, and API client.
+
+## Reuse Opportunities
+
+- **`registerAppBarComponent` with `rhsComponent`** — The simplest path to wire an app bar icon to an RHS panel. By passing `rhsComponent` and `rhsTitle` instead of `action`, the registry automatically handles the `registerRightHandSidebarComponent` call and wires the icon's click to toggle the RHS. The plugin does not need to manually manage show/hide/toggle actions. This single call handles both the app bar icon and RHS registration.
+- **`window.PostUtils.formatText` + `messageHtmlToComponent`** — Mattermost exposes its full markdown rendering pipeline to plugins. The plugin can render Gemini's markdown response using these functions, which automatically handle code blocks, inline code, bold, italic, lists, links, mentions, and emojis. This avoids bundling a separate markdown library and ensures visual consistency with how Mattermost renders post content.
+- **Mattermost's CSRF and session handling** — Since plugin API calls go through the same origin (`/plugins/org-memory/api/v1/*`), the browser's existing session cookie is included automatically. The only additional step is to extract the CSRF token from the `MMCSRF` cookie and include it as an `X-CSRF-Token` header on non-GET requests. This follows the same pattern as `Client4.getOptions()`.
+- **`window.Components`** — Mattermost exposes internal components on `window.Components` for plugin use: `Textbox`, `Timestamp`, `Avatar`, `AdvancedTextEditor`, etc. The `Textbox` component provides a full-featured input with autocompletion, but for a simple query input a standard HTML textarea or input element is simpler and avoids depending on internal-only APIs. The decision on which to use is left to the implementer.
+- **Existing loading indicator** — `LoadingSpinner` from `components/widgets/loading/loading_spinner` or equivalent CSS animation. The plugin can reuse the standard Mattermost spinner or implement a minimal one to avoid importing internal components.
+
+## Deliverables
+
+### Plugin entry point
+
+Extend the bare entry point created in step 001 to implement the full `initialize` method:
+
+1. **Register the reducer** — Call `registry.registerReducer({reducer})` with the plugin's Redux reducer. This makes plugin state accessible at `state['plugins-org-memory']`.
+
+2. **Register the app bar icon with RHS** — Call `registry.registerAppBarComponent({iconUrl, tooltipText, rhsComponent, rhsTitle})` where:
+   - `iconUrl` is a URL to a plugin icon asset (an SVG or PNG representing a knowledge/brain/search concept). The icon file is included as a static asset in the plugin's `webapp/` directory and served at the plugin's assets path.
+   - `tooltipText` is "Ask your workspace" (the text shown when hovering over the icon).
+   - `rhsComponent` is the main RHS panel component (described below).
+   - `rhsTitle` is "Organizational Memory" (shown in the RHS header bar).
+   - `supportedProductIds` is set to match the default messaging product (or `'*'` to appear everywhere).
+
+3. **Store references** — Save the returned `rhsComponent` object (which contains `showRHS`, `hideRHS`, `toggleRHS`) in a module-level variable so the API client or other modules can programmatically control the RHS if needed.
+
+4. **Implement uninitialize** — The `uninitialize` method should clean up any module-level state. Redux cleanup is handled automatically by Mattermost when the plugin is unloaded.
+
+### RHS panel component
+
+A React component that renders within the RHS plugin area (below the `SearchResultsHeader` added by Mattermost's `RhsPlugin` wrapper). The component receives `{webSocketClient, theme}` as props from the `Pluggable` system. It renders three zones:
+
+1. **Query input area** — A text input field (or textarea) at the top of the panel where users type natural language questions. The input should:
+   - Support pressing Enter (or a send button) to submit the query
+   - Support Shift+Enter for newlines if using a textarea
+   - Be disabled while a query is in progress (loading state)
+   - Show placeholder text like "Ask a question about your workspace..."
+   - Clear itself after successful submission (the submitted query appears in the response area)
+   - Auto-focus when the RHS panel opens
+
+2. **Response display area** — A scrollable area below the input that displays the query and its response:
+   - Shows the user's submitted query text (so they can see what they asked)
+   - Renders the backend's synthesized answer as formatted markdown using `window.PostUtils.formatText` and `messageHtmlToComponent`, ensuring visual consistency with how Mattermost renders post content (code blocks, lists, bold, links, etc.)
+   - Citation links in the response (formatted as Mattermost markdown links with `/pl/{postId}` URLs) should be clickable and navigate to the source post when clicked. Standard Mattermost permalink handling should work because the links use the same URL format as regular post permalinks.
+   - Scrolls to the bottom when a new response arrives
+   - Shows an appropriate empty state when no query has been submitted yet (e.g., a brief description of what the user can ask)
+
+3. **Loading indicator** — Shown while the query is in flight:
+   - Replaces or appears below the query text to indicate processing
+   - Uses a simple spinner animation or pulsing dots
+   - Disappears when the response arrives or an error occurs
+
+4. **Error display** — When a query fails (network error, backend error):
+   - Shows a user-friendly error message in the response area
+   - Allows the user to try again (the input field is re-enabled)
+   - Does not lose the user's original query text (so they can retry without retyping)
+
+### Redux reducer
+
+A reducer registered under `'plugins-org-memory'` that manages the plugin's UI state:
+
+1. **State shape** — The reducer manages:
+   - `query` — The current/most recent query text submitted by the user (empty string initially)
+   - `response` — The response object from the backend (null initially). Contains the answer text, citations array, and session ID for multi-turn context
+   - `isLoading` — Boolean indicating whether a query is currently in flight
+   - `error` — Error message string if the last query failed (null when no error)
+   - `sessionId` — The session identifier returned by the backend for multi-turn conversation (null initially, set after the first successful query). This field is used in step 016.
+
+2. **Actions** — The reducer handles these action types:
+   - Query submitted — Sets `isLoading` to true, clears previous `error`, stores the submitted `query` text
+   - Query succeeded — Sets `isLoading` to false, stores the `response` (answer + citations + session ID), updates `sessionId` from the response
+   - Query failed — Sets `isLoading` to false, stores the `error` message
+   - Clear state — Resets all fields to initial values (used when the RHS is closed or the user explicitly clears the conversation)
+
+3. **Action creators** — Functions that create and dispatch these actions. The query submission action creator is a thunk (or async action) that:
+   - Dispatches "query submitted" immediately
+   - Calls the API client to send the query
+   - Dispatches "query succeeded" or "query failed" based on the response
+   - This pattern keeps the component simple — it just dispatches the submit action and the thunk handles the async flow
+
+### API client
+
+A thin module that handles HTTP communication with the plugin's backend API (step 010):
+
+1. **Base URL** — All requests go to `/plugins/org-memory/api/v1/`. This is the plugin's ServeHTTP endpoint.
+
+2. **Authentication** — Requests include the browser's session cookie automatically (same origin). For non-GET requests (POST), the client reads the CSRF token from the `MMCSRF` cookie and includes it as an `X-CSRF-Token` header. This mirrors how `Client4.getOptions()` handles CSRF.
+
+3. **Query endpoint** — Sends a POST to `/plugins/org-memory/api/v1/query` with a JSON body containing the query text. Returns the backend's JSON response containing the synthesized answer, citations array, and session ID. The API client parses the response and returns it to the caller.
+
+4. **Error handling** — If the response status is not 2xx, the client extracts the error message from the response body (which the backend returns as JSON with a `message` field per step 010) and throws/returns it for the UI to display.
+
+5. **Request headers** — Sets `Content-Type: application/json`, `X-Requested-With: XMLHttpRequest`, and `X-CSRF-Token` for POST requests. Uses `credentials: 'include'` to ensure cookies are sent.
+
+6. **Future endpoints** — The API client module will be extended in step 016 to support the follow-up query endpoint and other endpoints. For this step, only the initial query endpoint is needed.
+
+### Plugin icon asset
+
+An SVG or PNG icon file included in the webapp's assets directory:
+
+1. **Design** — A simple, recognizable icon representing knowledge search or organizational memory (e.g., a brain, lightbulb, book, or magnifying glass with a spark). The specific design is left to the implementer.
+
+2. **Dimensions** — The app bar displays icons at a small size (approximately 20x20px rendered). SVG is preferred for crisp rendering at any size.
+
+3. **Serving** — The icon must be accessible at a URL that the app bar component can load. Plugin static assets are typically bundled with the webapp and served from the plugin's asset path. The `iconUrl` passed to `registerAppBarComponent` should resolve correctly.
+
+### Citation link handling
+
+Citations in the response are Mattermost markdown links that point to post permalinks:
+
+1. **Link format** — The backend (step 009) returns citations formatted as Mattermost markdown: `[1]({SiteURL}/pl/{postId})` using the server's `SiteURL` from configuration. When rendered through `formatText` + `messageHtmlToComponent`, these become clickable `<a>` elements. The `/pl/{postId}` format is the standard Mattermost post permalink — it works across teams and channels without requiring a team name prefix.
+
+2. **Navigation** — When a user clicks a citation link, Mattermost's built-in permalink handling navigates to the source post. If the post is in the current channel, the view scrolls to it. If it is in a different channel, Mattermost switches to that channel and highlights the post. This behavior is provided by Mattermost's core routing — the plugin does not need to implement special click handlers for permalink navigation.
+
+3. **Visual treatment** — Citation links appear as standard Mattermost links (colored and underlined per theme). No special styling is needed beyond what `formatText` provides. The numbered citation markers (e.g., [1], [2]) are part of the response text and are naturally visible.
+
+### Webapp build configuration
+
+Extend the build configuration from step 001 to support the new source files:
+
+1. **External modules** — React, ReactDOM, Redux, and ReactRedux must be declared as externals in the bundler config (they are provided by Mattermost via `window.*` globals, not bundled with the plugin). The plugin must not bundle its own copies of these libraries.
+
+2. **Source files** — The bundler must process the new TypeScript/TSX source files (entry point, RHS component, reducer, API client, action creators).
+
+3. **Output** — The bundle output is `webapp/dist/main.js` as declared in the plugin manifest's `webapp.bundle_path`.
+
+4. **Type safety** — TypeScript compilation should use strict mode. The plugin can reference Mattermost types (Theme, WebSocketClient, etc.) from the `@mattermost/types` package for type safety, but these are dev dependencies only — not bundled into the output.
+
+## Acceptance Criteria
+
+- [x] The plugin's webapp entry point calls `window.registerPlugin('org-memory', plugin)` and implements `initialize(registry, store)` and `uninitialize()`
+- [x] During `initialize`, a Redux reducer is registered via `registry.registerReducer` under the key `plugins-org-memory`
+- [x] During `initialize`, an app bar icon is registered via `registry.registerAppBarComponent` with an `rhsComponent` and `rhsTitle`, wiring the icon click to toggle the RHS
+- [x] The app bar icon renders in the Mattermost app bar with a tooltip reading "Ask your workspace"
+- [x] Clicking the app bar icon opens the RHS panel; clicking again closes it. The icon is highlighted when the RHS is open.
+- [x] The RHS panel displays a title ("Organizational Memory") in the header area managed by Mattermost's `SearchResultsHeader`
+- [x] The RHS panel contains a text input field with placeholder text where users type queries
+- [x] Pressing Enter (without Shift) in the input field submits the query
+- [x] While a query is loading, a loading indicator is visible and the input field is disabled
+- [x] After a successful query, the user's question and the backend's answer are displayed in the response area
+- [x] The response is rendered as formatted markdown using `window.PostUtils.formatText` and `messageHtmlToComponent`, supporting code blocks, lists, bold, italic, and links
+- [x] Citation links in the response (using Mattermost permalink URLs in the `{SiteURL}/pl/{postId}` format) are clickable and navigate to the source post
+- [x] When a query fails, a user-friendly error message is shown and the input is re-enabled for retry
+- [x] The input field auto-focuses when the RHS panel opens
+- [x] An empty state is shown before the first query is submitted (brief description or prompt)
+- [x] The Redux state includes `query`, `response`, `isLoading`, `error`, and `sessionId` fields
+- [x] The API client sends POST requests to `/plugins/org-memory/api/v1/query` with proper JSON body, CSRF token, and credentials
+- [x] The API client handles non-2xx responses by extracting the error message from the response body
+- [x] React, ReactDOM, Redux, and ReactRedux are configured as externals in the bundler (not bundled with the plugin)
+- [x] The plugin icon SVG/PNG asset is included and loads correctly in the app bar
+- [x] The webapp bundle compiles to `webapp/dist/main.js` as declared in the plugin manifest
diff --git a/tasks/0001-org-memory-ai-knowledge-base/016.md b/tasks/0001-org-memory-ai-knowledge-base/016.md
new file mode 100644
index 000000000000..6d2601845520
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/016.md
@@ -0,0 +1,176 @@
+# 016: Webapp: multi-turn conversation and WebSocket events
+
+## Context
+
+Step 015 established the RHS panel with a single query-response flow. This step extends it with two capabilities: multi-turn follow-up queries that maintain conversational context across exchanges, and real-time WebSocket event handling that shows "summary available" indicators without polling.
+
+Multi-turn conversation allows users to refine their queries naturally. After receiving an initial answer about "the database migration decision," a user might follow up with "who was involved?" or "when was this decided?" without repeating the original context. The backend (step 009) stores conversation history in the KV store with a 30-minute TTL and accepts a session ID for follow-up queries. The webapp must track this session ID, display the full conversation history, and send follow-ups to a different endpoint (`/api/v1/query/followup`).
+
+WebSocket events solve a UX problem: when the background pipeline finishes processing a thread (step 008), the webapp has no way to know unless it polls. The server publishes a `custom_org-memory_thread_summary_ready` event broadcast to the channel. The webapp listens for this event and updates its local state so it can show an indicator that a summary is available for a thread the user is viewing. This creates a responsive feel — summaries appear to "arrive" in real time.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `webapp/channels/src/plugins/registry.ts` (line 833) — `registerWebSocketEventHandler({event, handler})`. Registers a handler for a specific WebSocket event name. The handler receives a `WebSocketMessages.Unknown` message with `event`, `data`, `broadcast`, and `seq` fields. For custom plugin events, the event name must match the full wire format including the `custom_{pluginid}_` prefix. Since the server-side `PublishWebSocketEvent` automatically prepends this prefix, the plugin registers the handler using the full event name: `custom_org-memory_thread_summary_ready`.
+- `webapp/channels/src/actions/websocket_actions.ts` (line 170) — The plugin event handler storage: `pluginEventHandlers[pluginId][eventName] = handler`. After built-in event handlers process standard events, all plugin handlers are checked by iterating `Object.values(pluginEventHandlers)` and matching `msg.event` against registered event names. The handler is called synchronously with the full WebSocket message object.
+- `webapp/channels/src/actions/websocket_actions.ts` (lines 701-709) — Plugin event dispatch loop. For each registered plugin event handler, checks if `msg.event` matches the registered event name. If so, calls the handler with the message. This is where the webapp invokes the plugin's WebSocket handler.
+- `webapp/channels/src/plugins/registry.ts` (line 860) — `registerReconnectHandler({handler})`. Registers a callback that fires when the WebSocket connection is re-established after a disconnect. Useful for refreshing stale state — if the webapp missed events during a connection gap, the reconnect handler can refetch relevant data.
+- `webapp/channels/src/plugins/registry.ts` (line 821) — `registerReducer({reducer})`. Already used in step 015 for the initial reducer. This step extends the reducer with new action types and state fields for conversation history and summary indicators.
+- `webapp/channels/src/types/store/plugins.ts` (lines 131-134) — `BasePluggableProps`: `{webSocketClient: WebSocketClient, theme: Theme}`. The `webSocketClient` prop is passed to the RHS component by the `Pluggable` wrapper. However, for event handling, the plugin should use `registerWebSocketEventHandler` in the registry (which is called during `initialize`) rather than using the `webSocketClient` prop directly.
+- `webapp/channels/src/plugins/export.ts` (lines 119-134) — `window.PostUtils.formatText` and `messageHtmlToComponent`. Already used in step 015 for rendering responses. Multi-turn conversation reuses the same rendering pipeline for each response in the conversation thread.
+- `server/public/plugin/api.go` (line 976) — `PublishWebSocketEvent(event string, payload map[string]any, broadcast *model.WebsocketBroadcast)`. The server-side API used by step 008 to publish `thread_summary_ready` events. The server prepends `custom_org-memory_` to the event name. The payload includes `root_id` (thread root post ID) and `channel_id`. Broadcast is scoped to the channel.
+- `server/public/model/websocket_message.go` (lines 129-152) — `WebsocketBroadcast` struct. Fields: `OmitUsers` (map), `UserId` (specific user), `ChannelId` (channel scope), `TeamId` (team scope). For the thread summary event, step 008 broadcasts to the channel where the thread lives.
+- `webapp/platform/client/src/websocket_messages.ts` — `WebSocketMessages.Unknown` type: `BaseWebSocketMessage<string, unknown>`. Has fields `event` (string), `data` (unknown, must be cast), `broadcast` (with channel_id, team_id, user_id), and `seq` (sequence number). Plugin handlers receive this generic type and must cast `data` to the expected shape.
+- `webapp/channels/src/actions/websocket_actions.ts` (lines 1768-1799) — `handleThreadReadChanged` as a pattern for WebSocket-driven Redux updates: the handler receives a message, extracts data, gets current Redux state to check conditions, and dispatches actions to update the store. Connected components re-render automatically.
+- `tasks/0001-org-memory-ai-knowledge-base/010.md` — The follow-up query endpoint: `POST /api/v1/query/followup` accepts a JSON body with `query` text and `session_id`. Returns the same response structure as the initial query endpoint (answer, citations, session ID). If the session has expired, the backend falls back to a fresh query transparently.
+- `tasks/0001-org-memory-ai-knowledge-base/008.md` — The thread summary ready event: after storing a thread summary, the debounce handler publishes `custom_org-memory_thread_summary_ready` with payload `{root_id, channel_id}` broadcast to the channel.
+- `tasks/0001-org-memory-ai-knowledge-base/015.md` — The initial RHS panel, Redux reducer, and API client created in the previous step. This step extends all three.
+
+## Reuse Opportunities
+
+- **Existing Redux reducer and state shape** from step 015 can be extended with new fields for conversation history and thread summary indicators. The initial reducer already handles `query`, `response`, `isLoading`, `error`, and `sessionId`. This step adds `conversationHistory` (array of exchanges) and `threadSummariesAvailable` (set of root post IDs with available summaries).
+- **Existing API client** from step 015 handles CSRF tokens, credentials, and error extraction. This step adds a new `submitFollowUp(query, sessionId)` method alongside the existing `submitQuery(query)` method, both following the same fetch pattern.
+- **`window.PostUtils.formatText` + `messageHtmlToComponent`** rendering pipeline is already integrated for single responses. Multi-turn conversation renders each response in the history using the same pipeline.
+- **`registerWebSocketEventHandler`** provides the standard mechanism for receiving real-time events. Combined with Redux dispatch, it follows the same pattern used by Mattermost's own WebSocket handlers (receive event → extract data → dispatch Redux action → components re-render).
+- **`registerReconnectHandler`** provides a hook for handling WebSocket reconnection. After a reconnect, any thread summaries that were published during the disconnect are missed. The reconnect handler does not need to refetch all summaries — the indicator is a convenience, not a critical data source. If the user opens a thread, the thread summary endpoint provides the authoritative data regardless of WebSocket state.
+
+## Deliverables
+
+### Multi-turn conversation UI
+
+Extend the RHS panel component (step 015) to support follow-up queries after the initial response:
+
+1. **Conversation history display** — Instead of showing a single query/response pair, the response area displays the full conversation as a scrollable list of exchanges. Each exchange consists of:
+   - The user's query text (visually distinguished from the AI response, e.g., different background or alignment)
+   - The AI's response rendered as markdown (using the same rendering pipeline from step 015)
+   - The exchanges are displayed in chronological order — oldest at top, newest at bottom
+
+2. **Follow-up input** — After the initial response is displayed, a second input area appears below the conversation. This follow-up input:
+   - Is visually similar to the initial input but positioned below the conversation
+   - Shows placeholder text like "Ask a follow-up question..."
+   - Submits to the follow-up query endpoint (not the initial query endpoint)
+   - Is disabled while a query is loading
+   - Supports the same Enter-to-submit, Shift+Enter-for-newline behavior as the initial input
+
+3. **New conversation** — A way to start a fresh conversation that clears the history and resets the session:
+   - A "New conversation" button or link in the panel header or above the input area
+   - Clicking it dispatches the "clear state" action, resetting all reducer fields to initial values
+   - The initial query input reappears and the conversation display is cleared
+
+4. **Auto-scroll** — When a new response arrives, the conversation area scrolls to show the latest exchange. If the user has scrolled up to review earlier exchanges, auto-scroll should not force them back down — only scroll if the user is already near the bottom.
+
+5. **Session continuity** — The session ID from the most recent response is stored in Redux state (already defined in step 015). When submitting a follow-up, this session ID is included in the request body. If the session expires (backend falls back to a fresh query), the response still succeeds — the webapp updates its session ID from the new response and continues normally.
+
+6. **Conversation persistence within the session** — The conversation history persists in Redux state as long as the RHS stays open or the user doesn't explicitly start a new conversation. If the RHS is closed and reopened, the last conversation is still visible (Redux state survives RHS close/open cycles). The history is only cleared on explicit "New conversation" action or when the plugin is unloaded.
+
+### Extended Redux reducer
+
+Extend the reducer from step 015 with additional state and actions:
+
+1. **New state fields**:
+   - `conversationHistory` — An array of exchange objects, each containing the user's query text and the AI's response (answer text, citations). This replaces the single `query`/`response` pair from step 015 as the primary display data source. The initial exchange and all follow-ups are appended here.
+   - `threadSummariesAvailable` — A set (or object with root post IDs as keys) tracking which threads have summaries available. Updated via WebSocket events. Used by UI components to show "summary available" indicators.
+
+2. **New action types**:
+   - Follow-up query submitted — Sets `isLoading` to true, clears previous `error`
+   - Follow-up query succeeded — Sets `isLoading` to false, appends the new exchange to `conversationHistory`, updates `sessionId` from the response
+   - Follow-up query failed — Sets `isLoading` to false, stores the `error` message
+   - Thread summary available — Adds a root post ID to the `threadSummariesAvailable` set
+   - Thread summary dismissed — Removes a root post ID from the set (when the user views the summary)
+
+3. **Modified existing actions**:
+   - Query submitted (from step 015) — Additionally clears `conversationHistory` to start fresh
+   - Query succeeded (from step 015) — Additionally appends the first exchange to `conversationHistory`
+   - Clear state (from step 015) — Additionally clears `conversationHistory` and `threadSummariesAvailable`
+
+4. **Follow-up thunk action creator** — Similar to the query submission thunk from step 015, but:
+   - Reads `sessionId` from the current Redux state
+   - Calls the follow-up API endpoint with the session ID
+   - Dispatches follow-up-specific action types
+   - If no session ID exists in state (session expired or cleared), falls back to dispatching a new query instead of a follow-up
+
+### Extended API client
+
+Add a follow-up query method to the API client from step 015:
+
+1. **Follow-up endpoint** — `POST /plugins/org-memory/api/v1/query/followup` with a JSON body containing `query` (string) and `session_id` (string). Uses the same authentication and header conventions as the initial query endpoint.
+
+2. **Response format** — Same as the initial query endpoint: answer text, citations array, and session ID. The API client returns the parsed response to the caller.
+
+3. **Thread summary endpoint** — `GET /plugins/org-memory/api/v1/threads/{root_id}/summary` for fetching a thread summary when the user clicks a "summary available" indicator. Returns the thread summary, key takeaways, and extractions. This endpoint already exists in step 010 — the API client adds a method to call it.
+
+### WebSocket event handler
+
+Register a handler during plugin initialization (`initialize` method) for the thread summary ready event:
+
+1. **Event registration** — Call `registry.registerWebSocketEventHandler({event: 'custom_org-memory_thread_summary_ready', handler})` during `initialize`.
+
+2. **Handler logic** — When the event fires:
+   - Extract `root_id` and `channel_id` from `msg.data`
+   - Dispatch a "thread summary available" action to the Redux store, adding the `root_id` to the `threadSummariesAvailable` set
+   - This triggers a re-render of any connected component that reads from this state
+
+3. **No data fetch on event** — The WebSocket event is a notification only — it does not include the actual summary content. The full summary is fetched via the thread summary API endpoint only when the user explicitly requests it (clicks the indicator). This keeps the event handler lightweight and avoids unnecessary API calls for threads the user may not care about.
+
+4. **Scope consideration** — The event is broadcast to all channel members. The handler should check whether the user's current view or recent activity makes this event relevant (e.g., the root post ID is for a thread in a channel the user has open). However, a simpler approach is to always store the indicator and let the display layer decide visibility — indicators are only shown where the UI displays them, so irrelevant ones have no visual impact.
+
+### Reconnect handler
+
+Register a reconnect handler during initialization to handle WebSocket reconnection:
+
+1. **Registration** — Call `registry.registerReconnectHandler({handler})` during `initialize`.
+
+2. **Reconnect behavior** — When the WebSocket reconnects after a disconnection:
+   - The handler does not attempt to refetch missed thread summary events — the indicators are a convenience feature, not a data integrity concern
+   - If the user had an active query in progress when the disconnect occurred, the loading state may be stale. The reconnect handler can check if `isLoading` is true and has been true for longer than a reasonable timeout (e.g., 30 seconds), and if so, dispatch a "query failed" action with a connection error message
+   - Optionally, log a reconnect to the console for debugging
+
+3. **Cleanup on uninitialize** — The `uninitialize` method calls `registry.unregisterReconnectHandler()` to clean up the reconnect handler.
+
+### Thread summary indicator
+
+Provide a mechanism for the UI to show when a thread summary is available:
+
+1. **Indicator data source** — The `threadSummariesAvailable` set in Redux state contains the root post IDs of threads that have had summaries generated. Any component can read this state to decide whether to show an indicator.
+
+2. **Display approach** — The specific UI surface for the indicator is intentionally minimal in this step:
+   - In the RHS panel, if the user is viewing a conversation that references a thread (via citation links), the panel could show a subtle indicator that a thread summary exists
+   - The primary use is for future enhancement — step 016 establishes the data flow (WebSocket → Redux → component), and subsequent UI refinements can add indicators to post headers, thread views, or channel sidebars
+
+3. **Dismissal** — When the user views a thread summary (by clicking the indicator or navigating to the thread), dispatch a "thread summary dismissed" action to remove the root post ID from the set. This prevents the indicator from persisting after the user has already seen the summary.
+
+4. **Summary viewing** — When the user clicks a summary indicator, the webapp calls the thread summary API endpoint (`GET /api/v1/threads/{root_id}/summary`) via the API client, and displays the result. The display could be a modal, an inline expansion, or a navigation to the thread — the specific UX is left to the implementer. The important aspect is that the data flow (event → indicator → fetch → display) is wired end to end.
+
+### Post dropdown menu action (optional enhancement)
+
+Register a post dropdown menu action that allows users to view the thread summary from any post's context menu:
+
+1. **Registration** — Call `registry.registerPostDropdownMenuAction({text, action, filter})` during `initialize`:
+   - `text` is "View thread summary" or similar
+   - `filter` checks whether the post is a root post (has no `root_id`) or whether a summary is available for the post's thread (by checking `threadSummariesAvailable` in Redux state). Returns true only when relevant.
+   - `action` is called with the post ID when the user clicks the menu item. It fetches the thread summary from the API and displays it (in the RHS or a modal).
+
+2. **This is an enhancement** — If implementing the full post dropdown integration adds significant complexity, it can be deferred. The core deliverables (multi-turn conversation and WebSocket handler) take priority.
+
+## Acceptance Criteria
+
+- [x] After an initial query response, a follow-up input appears below the conversation, allowing the user to ask follow-up questions
+- [x] Follow-up queries are sent to `POST /api/v1/query/followup` with the session ID from the previous response
+- [x] The conversation history displays all exchanges (query + response pairs) in chronological order within the RHS panel
+- [x] Each response in the conversation history is rendered as formatted markdown using the same pipeline as step 015
+- [x] A "New conversation" action clears the conversation history, resets the session ID, and returns to the initial query state
+- [x] The conversation history is stored in Redux state and persists across RHS close/open cycles
+- [x] If the session expires on the backend, the follow-up response still succeeds (backend falls back to fresh query) and the webapp updates its session ID
+- [x] If no session ID exists when submitting a follow-up (e.g., after page reload), the webapp falls back to submitting a new initial query
+- [x] The conversation area auto-scrolls to the latest exchange when a new response arrives, but does not force-scroll if the user has scrolled up
+- [x] A WebSocket event handler is registered for `custom_org-memory_thread_summary_ready` during plugin initialization
+- [x] When the thread summary ready event is received, the root post ID is added to the `threadSummariesAvailable` set in Redux state
+- [x] The thread summary available indicator data is accessible from Redux state for any UI component to read
+- [x] A reconnect handler is registered during initialization to handle WebSocket reconnection gracefully
+- [x] The reconnect handler detects stale loading states (isLoading stuck for >30 seconds) and clears them with an error
+- [x] The API client includes a method for calling the follow-up query endpoint with session ID
+- [x] The API client includes a method for fetching thread summaries from `GET /api/v1/threads/{root_id}/summary`
+- [x] The `uninitialize` method cleans up the reconnect handler
+- [x] When a user views a thread summary, the corresponding root post ID is removed from the available set (dismissed)
+- [x] The Redux reducer handles all new action types: follow-up submitted/succeeded/failed, thread summary available/dismissed
diff --git a/tasks/0001-org-memory-ai-knowledge-base/017.md b/tasks/0001-org-memory-ai-knowledge-base/017.md
new file mode 100644
index 000000000000..06a3de2ce913
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/017.md
@@ -0,0 +1,177 @@
+# 017: Historical backfill system
+
+## Context
+
+The plugin only captures posts created after activation. For workspaces with years of conversation history, the knowledge base starts empty — none of the existing decisions, action items, or discussions are searchable. Admins need a way to retroactively process historical messages so the knowledge base covers the workspace's full institutional memory from day one.
+
+The backfill system is admin-triggered (not automatic), processes posts in configurable batches, tracks progress for resumability, and applies rate limiting to avoid overwhelming the Gemini API. It uses the processing log as its work queue (the same pipeline used for real-time processing), which means backfilled posts are processed by the same worker (step 007) with the same embedding, extraction, and error handling logic. The backfill system's job is to enumerate historical posts and create processing log entries — not to call Gemini directly.
+
+The architecture (step 006) established that the `JobOnceScheduler` callback dispatches to different handlers based on key prefix: `debounce:` for thread summarization and `backfill:` for backfill processing. This step implements the `backfill:` handler and the admin-facing trigger mechanism already defined in step 010 (`POST /api/v1/admin/backfill` and `GET /api/v1/admin/status`).
+
+A critical constraint is that backfilling a large workspace (millions of posts) takes days. The system must survive plugin restarts, cluster node failovers, and admin-initiated pauses without losing progress. All progress state is persisted in the KV store, and each batch advances a cursor that can be resumed from.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/plugin/api.go` (line 723) — `GetPostsSince(channelId string, time int64) (*model.PostList, *model.AppError)` retrieves all posts in a channel modified since a given Unix millisecond timestamp. Returns a `PostList` with `Order` (post IDs) and `Posts` (map). This is the primary mechanism for fetching historical posts per channel. It returns all matching posts in a single call (not paginated), so for channels with very many posts since the given time, the response can be large.
+- `server/public/plugin/api.go` (line 749) — `GetPostsForChannel(channelId string, page, perPage int) (*model.PostList, *model.AppError)` retrieves a paginated list of posts for a channel. Uses page/perPage pagination. Unlike `GetPostsSince`, this supports bounded result sets. Can be used as an alternative for large channels where `GetPostsSince` might return too many posts at once.
+- `server/public/plugin/api.go` (line 735) — `GetPostsAfter(channelId, postId string, page, perPage int) (*model.PostList, *model.AppError)` retrieves posts after a specific post ID, paginated. Useful for cursor-based traversal: start from a known post ID and advance forward through history.
+- `server/public/plugin/api.go` (line 455) — `GetPublicChannelsForTeam(teamID string, page, perPage int) ([]*model.Channel, *model.AppError)` returns paginated public channels for a team. The backfill system needs to enumerate channels to process. For private channels and DMs, the backfill system targets a specific channel provided by the admin, since a system admin can access any channel.
+- `server/public/plugin/api.go` (line 457) — `GetChannel(channelId string) (*model.Channel, *model.AppError)` retrieves a single channel. Used to validate the admin-provided channel ID before starting a backfill.
+- `server/public/pluginapi/cluster/job_once_scheduler.go` — `ScheduleOnce(key, runAt, props)` schedules a one-time job. The backfill uses keys with the `backfill:` prefix. When the job fires, the callback (registered in step 006) dispatches to the backfill handler. `Cancel(key)` cancels a pending backfill job. Props carry the channel ID and cursor state for resumability.
+- `server/public/pluginapi/kv.go` — KV store for persisting backfill progress state. `Set(key, value)` stores the serialized progress struct. `Get(key, &dest)` retrieves it. `Delete(key)` removes it on completion. The key pattern `backfill:progress:{channelId}` allows per-channel progress tracking.
+- `server/public/pluginapi/post.go` (lines 270-337) — `ShouldProcessMessage(post, ...options)` checks eligibility. The backfill handler applies the same eligibility rules as real-time ingestion (skip bots, system messages) to ensure consistent behavior.
+- `server/public/model/post_list.go` — `PostList` struct: `Order []string` (post IDs in order), `Posts map[string]*Post`. `ToSlice()` returns ordered posts. `SortByCreateAt()` sorts. The backfill iterates over posts from `GetPostsSince` or `GetPostsForChannel` using these methods.
+- `server/channels/store/sqlstore/post_store.go` (line 2530) — `GetPostsBatchForIndexing(startTime int64, startPostID string, limit int)` uses a compound cursor `(CreateAt, Id)` for efficient, resumable pagination. This is the pattern the backfill should follow: use a compound cursor (timestamp + post ID) so resuming from a checkpoint never misses or duplicates posts. While this specific method is not exposed via the plugin API, the cursor pattern should be replicated using the available plugin API methods.
+- `server/enterprise/elasticsearch/common/indexing_job.go` — The Elasticsearch indexing worker demonstrates comprehensive progress tracking for a batch job: a progress struct with counts (total, done, cursor position), serialization to job data for resumability, percentage calculation for progress reporting, cancellation checking between batches, and a batch processing loop with configurable inter-batch delays.
+- `server/channels/jobs/batch_worker.go` — The `BatchWorker` pattern: a loop that calls a batch function repeatedly, checks for cancellation between batches, persists state after each batch, and reports progress. The backfill handler follows this same loop structure within the `JobOnceScheduler` callback.
+- `tasks/0001-org-memory-ai-knowledge-base/006.md` (lines 88-96) — The `JobOnceScheduler` callback dispatch setup. Jobs with the `backfill:` prefix are dispatched to the backfill handler. The callback receives the key and deserialized props.
+- `tasks/0001-org-memory-ai-knowledge-base/010.md` (lines 140-161) — The admin backfill endpoint (`POST /api/v1/admin/backfill`) and status endpoint (`GET /api/v1/admin/status`). The backfill endpoint validates the channel, checks for existing active backfills, schedules the backfill job, and returns HTTP 202. The status endpoint reports active backfill progress.
+- `tasks/0001-org-memory-ai-knowledge-base/007.md` — The processing worker that processes entries from the processing log. The backfill system creates processing log entries; the worker handles the actual embedding and extraction work. This separation means the backfill rate is controlled by how fast entries are created, not by Gemini API call speed.
+- `tasks/0001-org-memory-ai-knowledge-base/003.md` (lines 127-146) — The `ai_processing_log` table with UNIQUE constraint on `(PostId, JobType)`. When the backfill encounters a post that has already been processed (the real-time pipeline handled it), the insert must use an upsert or skip pattern to avoid constraint violations.
+
+## Reuse Opportunities
+
+- **Processing log as the work queue** — Instead of the backfill calling Gemini directly, it writes processing log entries with "pending" status. The existing worker (step 007) picks these up and processes them through the normal pipeline. This reuses all the embedding, extraction, error handling, and retry logic without duplication. The backfill system only needs to enumerate posts and create log entries.
+- **ShouldProcessMessage eligibility check** — The same bot/system message filtering used by real-time hooks (step 006) applies to historical posts. This ensures consistent behavior: posts skipped in real-time would also be skipped during backfill.
+- **JobOnceScheduler for batch scheduling** — Each batch of the backfill is a separate `ScheduleOnce` call with a short delay. When a batch completes, the handler schedules the next batch. This approach integrates with the existing scheduler infrastructure, supports cancellation (via `Cancel`), and naturally handles cluster failover (if the node processing the batch goes down, the scheduled job remains in the KV store and another node picks it up).
+- **Compound cursor pattern** from `GetPostsBatchForIndexing` — using `(CreateAt, PostId)` as a cursor ensures no posts are missed or duplicated when resuming from a checkpoint. Even if multiple posts share the same CreateAt timestamp, the secondary sort by PostId ensures deterministic ordering.
+- **KV store for progress persistence** — The backfill progress struct is stored in the KV store, separate from the scheduler's job props. This allows the admin status endpoint to read progress without interacting with the scheduler, and ensures progress survives scheduler-level operations.
+- **Processing log upsert** — The store interface (step 003) should support an insert-or-skip pattern for processing log entries. When the backfill creates an entry for a post that already has a "complete" entry for the same job type, the existing entry is left unchanged. This makes the backfill idempotent — re-running it over the same time range is safe.
+
+## Deliverables
+
+### Backfill progress state
+
+Define a backfill progress structure that persists in the KV store under the key `backfill:progress:{channelId}`:
+
+1. **Identification** — The channel ID being backfilled and a backfill ID (generated via `model.NewId()`) for tracking.
+
+2. **Parameters** — The original parameters from the admin request: since timestamp (Unix milliseconds, 0 for all history), and batch size (number of posts per batch, default 100).
+
+3. **Cursor** — The compound cursor for resumable pagination: the `CreateAt` timestamp and `Id` of the last processed post. When resuming, the next batch fetches posts with `(CreateAt, Id)` strictly after this cursor. Initially both are zero/empty (start from the beginning of history).
+
+4. **Counters** — Total posts scanned, posts that passed eligibility checks and had processing log entries created, posts skipped (already processed or ineligible), and posts in error. These counters allow the admin status endpoint to report meaningful progress.
+
+5. **Status** — One of: `running`, `paused`, `completed`, `error`. The `paused` status is set when the admin requests cancellation; the cursor and counters are preserved so the backfill can be resumed later.
+
+6. **Timestamps** — When the backfill started, when it was last updated (for staleness detection), and when it completed (if finished).
+
+7. **Rate limit delay** — A configurable delay between batches (in milliseconds). Default 500ms. This spaces out processing log entry creation to avoid flooding the processing worker and indirectly throttles Gemini API usage during backfill. Admins can adjust this via the backfill request parameters.
+
+### Backfill trigger (extending step 010)
+
+The admin backfill endpoint (`POST /api/v1/admin/backfill`) already validates the channel and checks for active backfills. This step implements the actual triggering logic:
+
+1. **Create progress state** — Initialize the backfill progress struct with the admin's parameters, set status to "running", and store it in the KV store.
+
+2. **Schedule the first batch** — Use `JobOnceScheduler.ScheduleOnce` with key `backfill:{channelId}`, `runAt` set to now (immediate execution), and props containing the channel ID. The scheduler fires the callback, which dispatches to the backfill handler.
+
+3. **Return the backfill ID** — The endpoint returns HTTP 202 Accepted with the backfill ID and channel ID so the admin can track progress via the status endpoint.
+
+4. **Duplicate prevention** — Before creating a new backfill, check the KV store for an existing progress entry with status "running" for the same channel. If one exists, return HTTP 409 Conflict with a message indicating a backfill is already in progress. Backfills with status "paused", "completed", or "error" do not block new backfills — the old progress is overwritten.
+
+### Backfill batch handler
+
+Implement the backfill handler that the `JobOnceScheduler` callback dispatches to when a `backfill:` prefixed key fires:
+
+1. **Load progress** — Read the backfill progress from the KV store using the channel ID from the job props. If no progress exists (e.g., it was deleted), log a warning and return without rescheduling.
+
+2. **Check cancellation** — If the progress status is "paused" (the admin canceled it), do not process the batch and do not reschedule. The backfill remains paused with its cursor preserved.
+
+3. **Fetch a batch of posts** — Use the plugin API to retrieve the next batch of posts for the channel, starting after the cursor position. The specific API method depends on the cursor state:
+   - **Initial batch** (cursor is zero/empty): Use `GetPostsForChannel` starting from page 0 with the configured batch size, or use `GetPostsSince` with the admin's "since" timestamp.
+   - **Subsequent batches**: Use `GetPostsAfter` with the last processed post ID as the anchor, or use `GetPostsSince` with the cursor's timestamp and then filter to posts after the cursor post ID.
+   - **Ordering**: Posts must be processed in chronological order (oldest first) to ensure thread summarization works correctly — individual post entries should be created before thread summaries are triggered.
+
+4. **Process each post in the batch** — For each post:
+   - Apply `ShouldProcessMessage` to check eligibility (skip bots, system messages). Increment the skipped counter if ineligible.
+   - Check whether a processing log entry already exists for this post and job type (embed/extract). If so, skip it (already processed or in queue). Increment the skipped counter.
+   - Create processing log entries with "pending" status for the eligible job types (`embed` and `extract`). Use an upsert pattern that skips insertion if a row already exists for the `(PostId, JobType)` combination.
+   - Increment the appropriate counters.
+
+5. **Update cursor** — After processing the batch, advance the cursor to the last post's `(CreateAt, Id)`. Update the counters and timestamp in the progress struct. Write the updated progress to the KV store.
+
+6. **Determine completion** — If the batch returned fewer posts than the batch size, the channel has been fully enumerated. Set the progress status to "completed" and the completion timestamp. Do not schedule another batch.
+
+7. **Schedule next batch** — If there are more posts to process (the batch was full), schedule the next batch via `ScheduleOnce` with key `backfill:{channelId}`, `runAt` set to `now + rateLimitDelay`, and the same props. This creates a controlled cadence: fetch a batch, wait, fetch the next batch.
+
+8. **Error handling** — If an error occurs during batch fetching or processing log creation:
+   - Log the error with context (channel ID, cursor position, batch number)
+   - If the error is transient (API timeout, DB connection issue), leave the progress status as "running" and schedule a retry with a longer delay (e.g., 5 seconds). Increment a retry counter in the progress state.
+   - If the error is persistent (channel deleted, permission denied), set the progress status to "error" with the error message. Do not reschedule.
+   - If retries exceed a threshold (e.g., 10 consecutive failures), set status to "error" and stop.
+
+### Thread backfill coordination
+
+Historical posts in threads need summarization, but the thread debounce mechanism (step 008) is designed for real-time flow — it waits for inactivity. For backfill, threads are already complete (no new posts are expected). The backfill system must trigger thread summarization differently:
+
+1. **Track unique thread root IDs** — As the backfill processes posts, collect the unique root post IDs (from `Post.RootId` for replies, or `Post.Id` for root posts that have replies). Store these in the backfill progress state or in a separate KV store key (`backfill:threads:{channelId}`).
+
+2. **Post-channel completion** — After the channel's posts are fully enumerated, iterate over the collected thread root IDs and create processing log entries with job type `summarize` for each thread root that does not already have a thread summary in `ai_thread_summaries`. This queues thread summarization through the normal worker pipeline.
+
+3. **Ordering** — Thread summaries depend on individual post embeddings being available (the summarization handler in step 008 also creates embedding entries for unprocessed posts). Since individual posts are processed first (they are queued in earlier batches), the worker naturally processes them before the summarize entries — but only if there is sufficient time between the backfill creating embed entries and creating summarize entries. The inter-batch delay and the processing worker's FIFO behavior handle this implicitly for small channels. For very large channels, the summarize entries may be created while the worker is still processing embed entries from earlier batches, which is acceptable — the summarization handler checks for and creates any missing embed entries.
+
+### Cancellation (pause) and resume
+
+Support admin-initiated pause and resume of a running backfill:
+
+1. **Pause** — When the admin sends a cancellation request (via a mechanism such as `POST /api/v1/admin/backfill` with a `cancel` action, or a dedicated cancel endpoint), set the backfill progress status to "paused" in the KV store. The next time the batch handler fires, it sees the "paused" status and returns without rescheduling. Also cancel the pending scheduled job via `JobOnceScheduler.Cancel(backfill:{channelId})`.
+
+2. **Resume** — When the admin triggers a new backfill for the same channel with a `resume` action (or simply triggers a new backfill), check if a paused progress state exists. If so, keep the existing cursor and counters (do not reset them) and set the status back to "running". Schedule the next batch from the existing cursor position. This avoids reprocessing posts that were already handled in the paused run.
+
+3. **Restart** — If the admin triggers a new backfill with different parameters (different since date or batch size), overwrite the existing progress state and start from scratch.
+
+### Admin status integration (extending step 010)
+
+The admin status endpoint (`GET /api/v1/admin/status`) already returns pipeline health information. Extend it with backfill-specific data:
+
+1. **Active backfill** — If a backfill is running, include its channel ID, status, cursor position, counters (total scanned, created, skipped, errored), start time, and estimated progress (percentage based on cursor timestamp relative to current time, if a since timestamp was provided).
+
+2. **Completed backfills** — Optionally include the most recent completed backfill's summary (channel ID, total processed, duration).
+
+3. **Queued processing** — The backfill creates processing log entries that the worker processes. The status endpoint already reports processing queue depth. During a backfill, this number rises as new entries are created faster than the worker processes them. The admin can use the queue depth alongside the backfill progress to understand the overall system state.
+
+### Rate limiting and Gemini quota awareness
+
+The backfill system indirectly controls Gemini API usage through two mechanisms:
+
+1. **Inter-batch delay** — The configurable delay between batches (default 500ms) controls how fast processing log entries are created. Since the processing worker polls every second and processes items sequentially, a steady creation rate fills the pipeline at a controlled pace.
+
+2. **Batch size** — Smaller batches (default 100) combined with the inter-batch delay create a natural rate limit. For example, 100 posts every 500ms means 200 posts per second entering the processing log, but the worker may only process 1-10 posts per second (limited by Gemini API call latency). The backlog grows but is bounded by the channel's total post count.
+
+3. **Circuit breaker awareness** — The processing worker (step 007) already respects the Gemini circuit breaker. If Gemini becomes unavailable during a backfill, the worker stops processing (circuit breaker opens), pending items accumulate, and the backfill continues creating entries. When Gemini recovers (circuit breaker closes), the worker resumes processing the backlog. The backfill system does not need its own circuit breaker — it relies on the worker's.
+
+4. **No direct Gemini calls** — The backfill handler never calls Gemini directly. It only creates processing log entries. This separation means the backfill's rate limiting is purely about database write speed, which is fast and cheap compared to API calls.
+
+### Metrics integration
+
+The backfill system should record metrics (for step 014 to expose):
+
+1. **Backfill batches processed** — A counter incremented for each batch completed.
+2. **Backfill posts scanned** — A counter for total posts examined (including skipped ones).
+3. **Backfill posts queued** — A counter for posts that had processing log entries created.
+4. **Backfill duration** — A gauge or histogram tracking total backfill time.
+
+## Acceptance Criteria
+
+- [x] The backfill handler is invoked by the `JobOnceScheduler` callback when a `backfill:` prefixed key fires
+- [x] The backfill processes posts in configurable batch sizes (default 100) with a configurable delay between batches (default 500ms)
+- [x] Each batch fetches posts chronologically (oldest first) starting after the cursor position
+- [x] Historical posts are checked with `ShouldProcessMessage` for eligibility, consistent with real-time ingestion rules
+- [x] Eligible posts have processing log entries created with "pending" status for embed and extract job types
+- [x] Processing log entry creation uses an upsert or skip pattern to handle the `(PostId, JobType)` unique constraint without errors when posts have already been processed
+- [x] Backfill progress (cursor, counters, status) is persisted in the KV store under `backfill:progress:{channelId}`
+- [x] The backfill survives plugin restarts — on restart, the scheduler fires the pending job and the handler resumes from the persisted cursor
+- [x] An admin can pause a running backfill, preserving the cursor position for later resumption
+- [x] An admin can resume a paused backfill, continuing from where it left off without reprocessing already-handled posts
+- [x] A new backfill for the same channel rejects with HTTP 409 if a backfill is already running for that channel
+- [x] After all posts in the channel are enumerated, thread root IDs are collected and processing log entries with job type "summarize" are created for threads without existing summaries
+- [x] The backfill status to "completed" when the channel is fully enumerated and thread summaries are queued
+- [x] The admin status endpoint reports active backfill progress including counters and cursor position
+- [x] Transient errors (API timeouts, DB failures) trigger automatic retry with an increased delay, up to a maximum retry count
+- [x] Persistent errors (channel deleted, permission denied) set the backfill status to "error" and stop rescheduling
+- [x] The backfill does not call Gemini directly — it only creates processing log entries for the existing worker to process
+- [x] The backfill is idempotent — running it over the same time range again skips already-processed posts
+- [x] Batch processing of posts does not block the real-time ingestion pipeline — both write to the same processing log table concurrently
diff --git a/tasks/0001-org-memory-ai-knowledge-base/018.md b/tasks/0001-org-memory-ai-knowledge-base/018.md
new file mode 100644
index 000000000000..c2759c133b85
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/018.md
@@ -0,0 +1,271 @@
+# 018: Server-side integration tests
+
+## Context
+
+Steps 001 through 017 implement the full server-side plugin: schema, lifecycle, ingestion, processing, RAG queries, API endpoints, slash commands, summaries, webhooks, retention, metrics, and backfill. This step creates the test suite that verifies all of these components work together correctly.
+
+The tests fall into two categories. **Unit tests** mock external dependencies (the Mattermost plugin API and the Gemini client) and verify the behavior of individual components in isolation — the store, the chunking engine, the processing worker, the RAG engine, the API handlers, and the event hooks. **Integration tests** require a live PostgreSQL database with the pgvector extension and verify end-to-end flows: schema creation, vector insert and similarity search, cascade deletion, full processing pipelines, and the complete RAG query lifecycle.
+
+The testing plan from `testing.md` defines the full scope of what must be tested. This step specifies how those tests are structured, what infrastructure they require, and the testing patterns to follow for consistency with the Mattermost codebase.
+
+All Gemini API calls are mocked in tests — the test suite must not make real API calls. This keeps tests fast, deterministic, and free of external dependencies beyond PostgreSQL. The Gemini client interface (step 004) enables straightforward mocking: a test implementation returns predetermined embeddings, extractions, and synthesized answers.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `server/public/plugin/plugintest/api.go` — Auto-generated mock for the plugin `API` interface. Uses `github.com/stretchr/testify/mock`. Provides `.On(method, args...).Return(values...)` for stubbing and `.AssertExpectations(t)` for verification. Every plugin API method (GetPost, GetChannel, GetUser, HasPermissionToChannel, KVSet, KVGet, PublishWebSocketEvent, etc.) is mockable. This is the primary mechanism for mocking the Mattermost server in unit tests.
+- `server/public/plugin/plugintest/example_hello_user_test.go` — Reference test showing the standard pattern: create a `plugintest.API{}` mock, stub methods with `.On().Return()`, set the mock on the plugin via `p.SetAPI(api)`, invoke the handler with `httptest.NewRecorder()` and `httptest.NewRequest()`, and verify the response. This pattern applies directly to testing the plugin's ServeHTTP handler (step 010).
+- `server/public/plugin/plugintest/hooks.go` — Auto-generated mock for the `Hooks` interface. Used when testing hook dispatching behavior, though for this plugin the hooks are tested by invoking them directly on the plugin struct.
+- `server/public/plugin/plugintest/driver.go` — Mock for the database `Driver` interface. Provides `Conn(isMaster bool)` for mocking database connections. Can be used when testing store initialization without a real database.
+- `server/channels/store/storetest/settings.go` (line 130) — `MakeSqlSettings(driver string)` creates a temporary test database and returns connection settings. Uses `TEST_DATABASE_POSTGRESQL_DSN` environment variable for custom DSN, or falls back to a default local PostgreSQL connection. The function creates a randomly named database, runs it through setup, and returns settings. The plugin's integration tests can follow this pattern to create an isolated test database with pgvector.
+- `server/channels/testlib/helper.go` (lines 50-60) — `NewMainHelper` and `NewMainHelperWithOptions` set up the test infrastructure including database connections, store instances, and search engines. The `TEST_DATABASE_POSTGRESQL_DSN` environment variable controls the database connection. The plugin's `TestMain` function can follow this pattern for integration test setup.
+- `server/channels/app/helper_test.go` — The app-level `TestHelper` struct demonstrates the test factory pattern: pre-created `BasicTeam`, `BasicUser`, `BasicChannel`, `BasicPost` fixtures with helper methods like `CreateUser`, `CreateTeam`, `CreateChannel`, `CreatePost`. The plugin test suite should define its own test helper with similar factory methods for creating test data (posts, channels, users, embeddings, extractions).
+- `server/channels/app/plugin_api_test.go` — Integration tests for the plugin API. Shows how to test `ServeHTTP` handlers with real or mocked plugin environments. Uses `httptest.NewRecorder/NewRequest` for HTTP testing. Shows how to set up plugin config via `cfg.PluginSettings.Plugins[pluginID]`.
+- `server/channels/store/sqlstore/store_test.go` — Store test patterns: uses `storetest.StoreTest(t, func(t, rctx, store))` wrapper for database-backed tests. Tests use real SQL queries against a test database. The `TestMain` function sets up the database pool, and tests clean up after themselves.
+- `server/channels/store/sqlstore/post_store.go` — The post store implementation demonstrates SQL test patterns: tests exercise CRUD operations and verify results via separate queries. Tests for complex queries (like batch retrieval) verify both correct results and boundary conditions.
+- `server/public/model/utils.go` — `model.NewId()` for generating test IDs. `model.GetMillis()` for current timestamps. Used throughout test factories to create realistic test data.
+- `github.com/stretchr/testify` — The assertion library used across all Mattermost tests. `require.NoError(t, err)` for fatal assertions, `assert.Equal(t, expected, actual)` for soft assertions, `mock.Anything` for flexible argument matching, `mock.MatchedBy(fn)` for custom matchers.
+
+## Reuse Opportunities
+
+- **`plugintest.API` mock** is the foundation for all unit tests. Every component that calls the plugin API (hooks, RAG engine, processing worker, webhook dispatcher) can be tested by stubbing the relevant API methods. The mock supports flexible argument matching (`mock.Anything`, `mock.AnythingOfType`) and call counting (`Times(n)`, `Once()`).
+- **`httptest.NewRecorder/NewRequest` pattern** from the example test applies directly to ServeHTTP handler tests. Create a request with the appropriate method, path, body, and `Mattermost-User-Id` header, invoke the handler, and verify the response status code and body.
+- **Test factory pattern** from `helper_test.go` should be replicated within the plugin's test package. A `TestHelper` struct creates test fixtures (mock users, channels, posts, embeddings, extractions) and exposes factory methods. This avoids repeating boilerplate setup across dozens of test functions.
+- **`MakeSqlSettings` pattern** for integration tests: create a temporary database, run the plugin's schema migrations, execute tests, and clean up. The plugin can implement its own lightweight version that creates a test database with pgvector enabled.
+- **Interface-based mocking** — The plugin's internal interfaces (Gemini client, store, metrics collector) were designed for testability. Unit tests inject mock implementations: a mock Gemini client returns predetermined vectors and extractions, a mock store returns configured results, and a no-op metrics collector discards observations. This isolates each component under test.
+
+## Deliverables
+
+### Test infrastructure
+
+Set up the test infrastructure within the plugin's `server/` directory:
+
+1. **Test helper struct** — A `TestHelper` that encapsulates common test setup:
+   - A `plugintest.API` mock with commonly needed method stubs pre-configured (e.g., `LogDebug`, `LogInfo`, `LogWarn`, `LogError` accepting any arguments)
+   - A mock Gemini client that returns configurable embeddings, extractions, and synthesis results
+   - A mock store (for unit tests) or a real database store (for integration tests)
+   - A no-op metrics collector
+   - Factory methods for creating test data: `MakePost(overrides)`, `MakeChannel(overrides)`, `MakeUser(overrides)`, `MakeEmbedding(overrides)`, `MakeExtraction(overrides)`, `MakeProcessingLogEntry(overrides)`, `MakeThreadSummary(overrides)`
+   - A `Plugin` instance wired up with all mocks
+
+2. **TestMain for integration tests** — A `TestMain` function that:
+   - Checks for the `TEST_DATABASE_POSTGRESQL_DSN` environment variable (or a plugin-specific variant)
+   - If no database DSN is available, skips integration tests gracefully (integration tests are gated by a build tag or environment check)
+   - Creates a temporary test database
+   - Enables the pgvector extension on the test database
+   - Runs the plugin's schema migration to create all 7 tables
+   - Provides the database handle to integration test functions
+   - Cleans up the test database after all tests complete
+
+3. **Integration test gating** — Integration tests that require PostgreSQL with pgvector should be gated so they do not fail in environments without a database. Use either a Go build tag (e.g., `//go:build integration`) or a runtime skip (`t.Skip("no database configured")` when the DSN is empty). This allows unit tests to run in any environment while integration tests require the database.
+
+4. **Deterministic embeddings** — The mock Gemini client for unit tests returns fixed, predetermined 768-dimensional vectors. To test vector similarity search correctly in integration tests, the mock should return vectors with known cosine distances: for example, a "relevant" embedding that is close to a predetermined query vector and an "irrelevant" embedding that is far from it. This allows integration tests to verify that similarity search returns the expected results in the correct order.
+
+### Unit test suites
+
+Organize unit tests by component, following the test plan from `testing.md`:
+
+**Plugin lifecycle tests:**
+- Verify `OnActivate` succeeds with valid configuration and database access
+- Verify `OnActivate` fails with a descriptive error when pgvector is unavailable (mock `GetMasterDB` to return a database without the extension)
+- Verify `OnActivate` fails when the Gemini API key is missing
+- Verify `OnDeactivate` stops all schedulers and releases resources
+- Verify `OnConfigurationChange` applies updated settings without restart
+
+**Event ingestion tests:**
+- For each hook (`MessageHasBeenPosted`, `MessageHasBeenUpdated`, `MessageHasBeenDeleted`, `FileWillBeUploaded`, `UserHasBeenDeactivated`), verify the expected behavior using the `plugintest.API` mock:
+  - Post from a non-bot user in an enabled team creates a processing log entry
+  - Post from a bot with `SkipBotPosts=true` creates no entry
+  - Post in a disabled team creates no entry
+  - Post in a thread schedules a debounce job
+  - Second post in same thread cancels old debounce and schedules new one
+  - Edited post creates re-processing entries
+  - Deleted post cleans up derived data and cancels pending debounce
+  - Deactivated user's sessions are cleaned up from KV store
+- Verify `ShouldProcessMessage` is called with the correct options
+
+**Chunking engine tests:**
+- Short message produces single chunk
+- Multiple paragraphs split at paragraph boundaries
+- Long paragraph splits at sentence boundaries
+- Small paragraphs merge up to target size
+- Adjacent chunks have ~10% overlap
+- Exceeding `MaxChunksPerPost` truncates
+- Empty/whitespace input produces zero chunks
+- Chunk indices are sequential from 0
+- Token estimation heuristic (4 chars/token) produces reasonable chunk counts
+
+**Gemini client tests (with mock HTTP or interface mock):**
+- Embedding generation returns 768-dimensional L2-normalized vector
+- Extraction returns typed items (decision, action_item, topic)
+- RAG synthesis returns answer with citation references
+- RAG synthesis returns "insufficient information" with no relevant context
+- Rate limit (429) triggers exponential backoff
+- 5 consecutive errors open the circuit breaker
+- Circuit breaker transitions to half-open after 30 seconds
+- Successful half-open request closes the circuit breaker
+- Circuit breaker state is stored in KV store
+
+**Processing worker tests:**
+- Worker picks up "pending" items from the processing log
+- Worker acquires mutex before processing and releases after
+- Successful processing sets status to "complete"
+- Failed processing increments retry count and returns to "pending"
+- 3 consecutive failures set status to "error"
+- Stale items (>5 min in "processing") are reset to "pending"
+- Processing same post twice is idempotent (no duplicate results)
+
+**Thread debounce tests:**
+- Debounce callback fetches full thread and sends to Gemini for summarization
+- Thread summary is stored in `ai_thread_summaries`
+- Key takeaways are stored as JSON array
+- Unprocessed individual posts get new processing log entries
+- Callback dispatcher routes `debounce:` and `backfill:` prefixes correctly
+
+**RAG query engine tests:**
+- Query returns results only from permitted channels
+- Query returns no results from channels the user cannot access
+- Permission cache is used on second query within 60 seconds
+- Permission resolution works across multiple teams
+- Citations map to valid post permalinks
+- Query log records user ID, query text, channels, result count, latency
+- Follow-up loads conversation history from KV store
+- Expired session falls back to fresh query
+- History truncation preserves most recent exchanges when approaching size limit
+
+**API handler tests (using httptest):**
+- For each of the 13 endpoints defined in step 010, test:
+  - Successful case with correct authentication and permissions
+  - Missing authentication returns 401
+  - Insufficient permissions returns 403
+  - Invalid input (empty body, malformed JSON) returns 400
+  - Not found cases return 404
+- Specific scenarios:
+  - `POST /query` with valid query returns answer, citations, and session ID
+  - `POST /query/followup` with session ID returns context-aware answer
+  - `GET /threads/{root_id}/summary` checks channel read permission
+  - `GET /channels/{channel_id}/summary` supports type filter parameter
+  - `GET /entities/{name}/timeline` filters by user's channel permissions
+  - `PUT /extractions/{id}` updates content and triggers re-embedding
+  - `POST /admin/backfill` rejects non-admins, rejects duplicate active backfills
+  - `GET /admin/status` returns queue depth, error count, circuit breaker state
+
+**Slash command tests:**
+- `/ask what decisions were made` returns ephemeral response with answer
+- `/ask` with empty text returns usage help
+- Command respects user's channel permissions
+- Command returns error message when RAG engine fails
+
+**Data retention tests:**
+- `RunDataRetention` deletes aged-out embeddings, extractions, entity mentions, summaries
+- Processes up to batch size and returns count
+- Returns 0 when no more data to clean
+
+**Webhook tests:**
+- Decision extraction triggers webhook delivery to configured URL
+- Action item extraction triggers webhook delivery
+- HMAC signature is included when secret is configured
+- Failed delivery retries with exponential backoff
+- 3 failed retries logs failure without blocking pipeline
+- CRUD operations for webhook configs in KV store
+- Non-admin users cannot manage webhooks
+
+**Summary generation tests:**
+- Daily summary worker processes channels with activity
+- Weekly summary aggregates from daily summaries
+- Duplicate prevention via unique constraint
+- Inactive channels are skipped
+
+**Backfill tests:**
+- Backfill handler processes posts in chronological batches
+- Eligible posts get processing log entries created
+- Already-processed posts are skipped (upsert/skip pattern)
+- Progress is persisted in KV store
+- Pause stops rescheduling and preserves cursor
+- Resume continues from saved cursor position
+- Duplicate active backfill is rejected
+- Thread root IDs are collected for post-channel summarization
+- Transient errors trigger retry with delay
+- Persistent errors stop the backfill
+
+**Metrics tests:**
+- All metric instruments are registered on the registry without panics
+- ServeMetrics handler returns Prometheus text format
+- No-op metrics implementation silently discards observations
+- GaugeFunc callbacks return expected values
+
+### Integration test suites
+
+These require PostgreSQL with pgvector and are gated by environment/build tag:
+
+**Schema and database tests:**
+- Running schema migration on a fresh database creates all 7 tables and the pgvector extension
+- Running schema migration twice (idempotent) produces no errors
+- Inserting a 768-dimensional vector into `ai_embeddings` and querying by cosine similarity returns the expected result
+- HNSW index is used by the query planner (verify via `EXPLAIN ANALYZE`)
+- Deleting a post cascades to delete related embeddings, extractions, and entity mentions
+- Unique constraint on `(PostId, JobType)` in processing log prevents duplicates
+- Unique constraint on `(ChannelId, SummaryType, WindowStart)` prevents duplicate summaries
+
+**End-to-end processing pipeline tests:**
+- Create a post → verify processing log entry exists → invoke the worker processing logic (with mock Gemini returning predetermined results) → verify embeddings and extractions are stored in the database
+- Create a thread with multiple posts → invoke the debounce handler (with mock Gemini) → verify thread summary is stored → verify individual post embeddings are queued
+- Edit a post → verify old embeddings are replaced with new ones
+- Delete a post → verify all derived data (embeddings, extractions, entity mentions) is removed
+
+**RAG query pipeline tests:**
+- Insert known embeddings with known vectors into the database → mock Gemini to return a predetermined query vector → invoke the RAG engine → verify the correct embeddings are returned by similarity search → verify the synthesized answer includes expected citations
+- Insert embeddings across channels with different permissions → invoke a query as a user with access to only some channels → verify results come only from permitted channels
+- Execute a follow-up query → verify conversation history is loaded and included in the synthesis prompt
+
+**API endpoint integration tests:**
+- Wire the ServeHTTP handler to a real store (with test database) and mock Gemini → send HTTP requests → verify database side effects (e.g., `PUT /extractions/{id}` actually updates the row in the database)
+- Backfill integration: trigger backfill via HTTP → verify processing log entries are created for historical posts
+
+### Test data management
+
+Each integration test must manage its own test data to avoid cross-test interference:
+
+1. **Isolation** — Each test creates its own users, channels, and posts with unique IDs. Tests do not share data. This allows tests to run in parallel without conflicts.
+
+2. **Cleanup** — Tests clean up their data after execution. For integration tests using a real database, use `t.Cleanup()` to register cleanup functions that delete created rows. Alternatively, use a per-test transaction that is rolled back (though this is complex with pgvector operations).
+
+3. **Deterministic IDs** — Use `model.NewId()` for all test IDs to ensure uniqueness. Do not use hardcoded IDs that could collide across parallel tests.
+
+4. **Mock Gemini responses** — Configure the mock Gemini client per test to return specific results. For example, a test verifying permission filtering configures the mock to return different embeddings for different channels, with vectors that have known similarity relationships.
+
+### Test execution
+
+1. **Unit tests** — Run with `go test ./...` from the plugin's server directory. No external dependencies required. All Mattermost plugin API calls are mocked via `plugintest.API`.
+
+2. **Integration tests** — Run with a database DSN environment variable set, e.g., `TEST_DATABASE_POSTGRESQL_DSN=postgres://user:pass@localhost/testdb go test -tags integration ./...`. The pgvector extension must be available on the test PostgreSQL instance.
+
+3. **CI integration** — The test suite should be runnable in CI with a PostgreSQL service container that has pgvector installed. The testing.md specifies "all verification must be automated" — no manual testing.
+
+4. **Test coverage** — The combined test suites cover all items from `testing.md` under the "Unit Tests" and "Integration Tests" sections. Browser/E2E tests are covered separately in step 019.
+
+## Acceptance Criteria
+
+- [x] A `TestHelper` struct exists with factory methods for creating test data and a pre-configured `plugintest.API` mock
+- [x] A mock Gemini client implementation returns configurable embeddings, extractions, and synthesis results
+- [x] Unit tests for all event ingestion hooks verify correct processing log creation, debounce scheduling, and cleanup behavior using the `plugintest.API` mock
+- [x] Unit tests for the chunking engine verify all splitting, merging, overlap, and truncation behaviors
+- [x] Unit tests for the Gemini client verify backoff, circuit breaker state transitions, and KV store state sharing
+- [x] Unit tests for the processing worker verify status transitions, retry logic, stale detection, and idempotency
+- [x] Unit tests for the RAG query engine verify permission filtering, caching, citation mapping, multi-turn sessions, and query logging
+- [x] Unit tests for all 13 HTTP API endpoints verify authentication, authorization, input validation, and correct responses using `httptest`
+- [x] Unit tests for the slash command verify query processing, empty input handling, and permission-aware responses
+- [x] Unit tests for data retention verify batch deletion across all tables and correct return counts
+- [x] Unit tests for outbound webhooks verify dispatch, HMAC signing, retry logic, and CRUD operations
+- [x] Unit tests for summary generation verify daily and weekly processing, duplicate prevention, and inactive channel skipping
+- [x] Unit tests for the backfill system verify batch processing, progress persistence, pause/resume, and idempotent entry creation
+- [x] Integration tests requiring pgvector PostgreSQL are gated and skipped when no database is configured
+- [x] Integration tests verify schema creation idempotency (running migrations twice succeeds)
+- [x] Integration tests verify vector insert and cosine similarity search returns correct results
+- [x] Integration tests verify HNSW index usage via EXPLAIN ANALYZE
+- [x] Integration tests verify foreign key cascade deletion from Posts to all plugin tables
+- [x] Integration tests verify the end-to-end processing pipeline: post creation → processing log → worker → stored embeddings and extractions
+- [x] Integration tests verify the RAG query pipeline with permission filtering using real vector similarity search
+- [x] All tests pass without making real Gemini API calls — all LLM interactions are mocked
+- [x] All items from the "Unit Tests" and "Integration Tests" sections of testing.md are covered
diff --git a/tasks/0001-org-memory-ai-knowledge-base/019.md b/tasks/0001-org-memory-ai-knowledge-base/019.md
new file mode 100644
index 000000000000..c24254ad511e
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/019.md
@@ -0,0 +1,110 @@
+# 019: Browser and E2E tests
+
+## Context
+
+This step creates the browser-level test suite for the Organizational Memory plugin, covering both webapp component unit tests (Jest + React Testing Library) and end-to-end tests (Playwright). These tests verify the user-facing behavior established in steps 015 and 016 — the RHS panel query interface, multi-turn conversation flow, markdown response rendering, citation link navigation, slash command execution, and WebSocket-driven summary indicators.
+
+The test suite has two distinct layers. Webapp component tests run in a JSDOM environment using Jest and verify individual React components in isolation — the RHS panel, conversation history display, loading states, and Redux reducer logic. These tests mock the plugin API client and Redux store to focus purely on rendering and interaction behavior. End-to-end tests run against a live Mattermost server with the plugin installed and verify the full user journey — clicking the app bar icon, typing a query, seeing results, following citation links, and receiving WebSocket updates. The E2E layer uses Playwright's route interception to mock the plugin's backend API responses, allowing tests to run without a real Gemini API key.
+
+Mattermost's E2E infrastructure provides the `PlaywrightExtended` test fixture with `initSetup()` for creating isolated test environments, `installAndEnablePlugin()` for plugin lifecycle management, and page objects like `ChannelsPage`, `ChannelsSidebarRight`, and `ChannelsAppBar` for UI interaction. The plugin's E2E tests extend this infrastructure with route interception for the plugin's API endpoints and selectors for the plugin's custom UI elements.
+
+## Related Code
+
+Existing files/patterns to reference or extend:
+
+- `e2e-tests/playwright/lib/src/test_fixture.ts` — The `PlaywrightExtended` test fixture class. Exposes `initSetup()` for creating a test user/team/channel, `testBrowser.login(user)` for browser authentication returning `{channelsPage, page}`, and `installAndEnablePlugin(client, url, pluginId)` for plugin installation. All plugin E2E tests extend from this fixture via `import {test, expect} from '@mattermost/playwright-lib'`.
+- `e2e-tests/playwright/lib/src/server/plugin.ts` — Plugin installation helpers: `installAndEnablePlugin(client, pluginUrl, pluginId, force)` with smart status checking (skips if already active, enables if installed but inactive, installs from URL otherwise). `isPluginActive(client, pluginId)` for verification.
+- `e2e-tests/playwright/lib/src/server/init.ts` — `initSetup()` creates admin client, resets server config, creates a new team, creates a new user, adds user to team, returns `{adminClient, adminUser, adminConfig, user, userClient, team, offTopicUrl, townSquareUrl}`. Each test gets a fresh isolated environment.
+- `e2e-tests/playwright/lib/src/ui/pages/channels.ts` — `ChannelsPage` page object. Key properties: `appBar` (ChannelsAppBar), `sidebarRight` (ChannelsSidebarRight), `centerView` (center channel view). Methods: `goto(teamName, channelName)`, `postMessage(message)`, `getLastPost()`, `toBeVisible()`.
+- `e2e-tests/playwright/lib/src/ui/components/channels/sidebar_right.ts` — `ChannelsSidebarRight` page object. Locates via `page.locator('#sidebar-right')`. Methods: `toBeVisible()`, `close()`, `toContainText(text)`, `getLastPost()`. Has `closeButton` via `.sidebar--right__close` selector.
+- `e2e-tests/playwright/lib/src/ui/components/channels/app_bar.ts` — `ChannelsAppBar` page object. Locates via `page.locator('.app-bar')`. The plugin's app bar icon uses the ID `#app-bar-icon-org-memory` (pattern: `#app-bar-icon-{pluginId}`).
+- `e2e-tests/playwright/specs/functional/plugins/demo_plugin_installation.spec.ts` — Reference pattern for a plugin E2E test: uses `pw.initSetup()`, `pw.testBrowser.login(user)`, `pw.installAndEnablePlugin(adminClient, url, pluginId)`, `expect.poll()` for async assertions, and `channelsPage.postMessage('/command')` for slash command testing.
+- `e2e-tests/playwright/specs/functional/channels/autotranslation/helpers/mock-autotranslation.ts` — Reference pattern for Playwright route interception: `page.route('**/api/translate', async (route) => { await route.fulfill({status: 200, contentType: 'application/json', body: JSON.stringify(response)}); })`. This technique intercepts HTTP requests matching a URL pattern and returns mock responses, eliminating the need for a real backend service.
+- `e2e-tests/playwright/playwright.config.ts` — Playwright configuration: test timeout 60 seconds, expect timeout 10 seconds, screenshot on failure, video on failure, Chrome/Firefox/iPad projects, `testDir: 'specs'`, reporters: HTML, JSON, JUnit, list.
+- `webapp/channels/src/plugins/pluggable/pluggable.test.tsx` — Reference pattern for plugin webapp component unit tests. Uses `renderWithContext(component, state)` from `tests/react_testing_utils`, creates a `DeepPartial<GlobalState>` with `plugins.components.RightHandSidebarComponent` populated, `testConfigureStore(state)` for Redux store creation, and standard React Testing Library assertions (`screen.getByTestId`, `toBeInTheDocument`, `toMatchSnapshot`).
+- `webapp/channels/src/tests/react_testing_utils.tsx` — Testing utilities: `renderWithContext(component, initialState, options)` renders with Redux Provider, IntlProvider, Router, and WebSocketContext. Supports `pluginReducers` option for registering plugin reducers in the test store. Also exports `renderHookWithContext` for testing hooks.
+- `e2e-tests/playwright/specs/functional/channels/message_priority/standard_priority.spec.ts` — Reference for RHS interaction testing: opens the RHS by clicking a post, verifies visibility with `channelsPage.sidebarRight.toBeVisible()`, checks content with `toContainText()`, and verifies element absence with `expect(locator).not.toBeVisible()`.
+- `e2e-tests/playwright/specs/functional/channels/sidebar_right/page_up_down_scroll.spec.ts` — Reference for RHS scroll behavior testing: posts multiple messages, interacts with keyboard events, checks scroll position via `element.scrollTop`.
+- `tasks/0001-org-memory-ai-knowledge-base/015.md` — Defines the RHS panel structure: app bar icon with "Ask your workspace" tooltip, query input field, markdown response area using `PostUtils.formatText` + `messageHtmlToComponent`, citation links as permalinks, loading spinner, Redux reducer with `query`/`response`/`isLoading`/`error`/`sessionId` state, API client with CSRF handling.
+- `tasks/0001-org-memory-ai-knowledge-base/016.md` — Defines multi-turn conversation: `conversationHistory` array in Redux, follow-up input below conversation, "New conversation" reset, auto-scroll, WebSocket handler for `custom_org-memory_thread_summary_ready`, reconnect handler for stale loading detection, `threadSummariesAvailable` set in Redux.
+- `tasks/0001-org-memory-ai-knowledge-base/testing.md` (lines 191-219) — The Browser/E2E test acceptance criteria defined during architecture: RHS open/close, query submission, loading indicator, markdown rendering, citation navigation, follow-up queries, empty query handling, thread summary display, slash command, WebSocket indicators.
+
+## Reuse Opportunities
+
+- **PlaywrightExtended fixture** — All E2E tests inherit from `@mattermost/playwright-lib`'s `test` fixture. No custom fixture needed — `pw.initSetup()`, `pw.testBrowser.login()`, and `pw.installAndEnablePlugin()` cover all setup requirements.
+- **ChannelsPage page object** — The existing `channelsPage.appBar`, `channelsPage.sidebarRight`, `channelsPage.centerView`, and `channelsPage.postMessage()` methods cover most navigation and interaction needs. Plugin-specific selectors (query input, response area) are located via `page.locator()` using test IDs or CSS selectors on the plugin's custom elements.
+- **Route interception pattern** — Playwright's `page.route()` API provides deterministic API mocking. A shared helper function intercepts `**/plugins/org-memory/api/v1/**` routes and returns configurable mock responses. This eliminates dependency on Gemini API and server-side processing for UI tests.
+- **renderWithContext utility** — All webapp component tests use `renderWithContext` from `tests/react_testing_utils` with the `pluginReducers` option to register the plugin's Redux reducer. A shared `getPluginBaseState()` helper provides the standard Redux state shape with the plugin component registered in `plugins.components.RightHandSidebarComponent`.
+- **React Testing Library patterns** — Standard RTL patterns: `screen.getByTestId()`, `screen.getByRole()`, `screen.getByText()`, `fireEvent.click()`, `userEvent.type()`, `waitFor()`, and `act()` for async state updates. Jest mocking for the plugin's API client module.
+- **testConfigureStore** — The existing test store factory supports plugin reducers. The plugin's reducer is registered under `'plugins-org-memory'` and test state is set via `DeepPartial<GlobalState>` with the plugin's state nested under that key.
+
+## Deliverables
+
+### Webapp Component Tests (Jest + React Testing Library)
+
+Create test files alongside the plugin's webapp source (within the plugin's `webapp/` directory structure):
+
+**RHS Panel Component Tests** — Tests for the main RHS panel component created in step 015. Covers: rendering the query input field, rendering in empty state (no query submitted yet), submitting a query via Enter key press, displaying loading spinner during API call, rendering a markdown response after API returns, rendering citation links as clickable elements, handling API error responses (displays error message), Shift+Enter inserting a newline instead of submitting, empty query submission being ignored (no API call made). Mock the plugin API client module so no real HTTP requests are made.
+
+**Conversation History Component Tests** — Tests for the multi-turn conversation display created in step 016. Covers: rendering a single query-response exchange, rendering multiple sequential exchanges in chronological order, rendering the follow-up input field below the conversation, "New conversation" action clearing the conversation history and session ID, auto-scroll behavior when new responses arrive (scroll container moves to bottom), preserving user scroll position when user has scrolled up manually.
+
+**Redux Reducer Tests** — Tests for the plugin's Redux reducer. Covers: initial state shape verification, handling query submission action (sets isLoading, clears error), handling query success action (stores response, clears isLoading, sets sessionId), handling query error action (stores error message, clears isLoading), handling follow-up success action (appends to conversationHistory), handling new conversation action (resets conversationHistory, sessionId, response), handling thread summary available action (adds rootId to threadSummariesAvailable set), handling WebSocket reconnect action (clears stale loading state older than 30 seconds).
+
+**API Client Tests** — Tests for the plugin's API client wrapper. Covers: constructing the correct URL for query endpoint, constructing the correct URL for follow-up endpoint, including CSRF token from document cookie in request headers, including credentials in request options, parsing JSON response body, handling non-200 HTTP status codes by throwing with the error message.
+
+**Citation Link Tests** — Tests for the citation rendering logic. Covers: parsing citation references from the response text (e.g., `[1]`, `[2]`), mapping citation numbers to post permalinks, rendering citation links with correct href values, citation links opening in the same window (Mattermost navigation).
+
+### End-to-End Tests (Playwright)
+
+Create test files under `e2e-tests/playwright/specs/functional/plugins/org_memory/`:
+
+**Plugin Installation and Activation** — A setup test that installs and activates the org-memory plugin using `pw.installAndEnablePlugin()`. Verifies the plugin appears in the active plugins list via API check. Verifies the app bar icon appears in the Mattermost UI. This test runs first and is tagged `@smoke`.
+
+**RHS Panel Open and Close** — Tests that clicking the org-memory app bar icon (`#app-bar-icon-org-memory`) opens the RHS panel. Verifies the panel becomes visible and contains the "Ask your workspace" header or title text. Tests that clicking the icon again closes the panel. Tests that the close button (`.sidebar--right__close`) also closes the panel.
+
+**Query Submission and Response** — Uses `page.route()` to intercept `**/plugins/org-memory/api/v1/query` POST requests and return a mock response with a synthesized answer and citations. Tests: typing a query in the input field and pressing Enter submits the request. While the intercepted route is delayed (via a pending promise), verifies the loading indicator is visible. After the route fulfills, verifies the response text appears in the panel rendered as formatted markdown. Verifies citation links are present in the response.
+
+**Citation Link Navigation** — Extends the query response test. The mock response includes citation references pointing to known post IDs (created during test setup via `adminClient.createPost()`). After the response renders, clicks a citation link and verifies Mattermost navigates to the permalink URL for that post (either scrolling to it in the channel or opening the thread).
+
+**Follow-up Query (Multi-turn)** — After an initial query-response exchange, verifies a follow-up input field appears. Types a follow-up question and submits it. Uses `page.route()` to intercept `**/plugins/org-memory/api/v1/query/followup` and return a context-aware mock response. Verifies both the original and follow-up exchanges are visible in the conversation history.
+
+**Empty Query Handling** — Verifies that pressing Enter with an empty input field does not trigger an API call. Uses `page.route()` to set up an interceptor that fails the test if called. Presses Enter with no text. Verifies no loading indicator appears and no error is shown.
+
+**New Conversation Reset** — After establishing a multi-turn conversation, clicks the "New conversation" control. Verifies the conversation history is cleared and the panel returns to the initial empty state with only the query input visible.
+
+**Slash Command Execution** — Posts `/ask what decisions were made about the API?` in the channel message input. Uses `page.route()` to intercept the command execution API call. Verifies an ephemeral post appears in the channel containing the mock response text. Verifies citation links in the ephemeral post are clickable.
+
+**WebSocket Thread Summary Indicator** — Tests the real-time "summary available" indicator. Sets up a mock API response for thread summary. Creates a test post and opens its thread in the RHS. Uses `page.evaluate()` to simulate dispatching a WebSocket event matching the `custom_org-memory_thread_summary_ready` pattern with the thread's root ID in the payload. Verifies a visual indicator appears in the UI without page refresh.
+
+**Route Interception Helper** — A shared helper module (under `e2e-tests/playwright/specs/functional/plugins/org_memory/helpers/`) that provides reusable functions for intercepting the plugin's API routes. Functions: `mockQueryResponse(page, response, delay?)` for the query endpoint, `mockFollowupResponse(page, response, delay?)` for the follow-up endpoint, `mockThreadSummary(page, rootId, summary)` for the thread summary endpoint. Each function uses `page.route()` with URL pattern matching and `route.fulfill()` with configurable response bodies. The optional `delay` parameter holds the response for a specified duration (useful for testing loading states).
+
+### Test Organization
+
+All Playwright tests use `import {test, expect} from '@mattermost/playwright-lib'` for the extended fixture. Tests are tagged with `@org-memory` for selective execution. The plugin installation test is additionally tagged `@smoke`. Each test uses `pw.initSetup()` for a fresh user/team and installs the plugin via the admin client before navigating to the channels page.
+
+Webapp component tests use Jest with `renderWithContext` and `testConfigureStore`. Test files are co-located with their source files or placed in a `__tests__/` directory within the plugin's webapp source tree.
+
+## Acceptance Criteria
+
+- [x] Webapp component tests: RHS panel component renders the query input field in initial empty state
+- [x] Webapp component tests: submitting a query via Enter key dispatches the correct Redux action and calls the API client
+- [x] Webapp component tests: loading spinner is displayed while the API call is in-flight
+- [x] Webapp component tests: markdown response is rendered after the API call completes, using the same rendering pipeline as Mattermost posts
+- [x] Webapp component tests: citation links render as clickable elements with correct permalink URLs
+- [x] Webapp component tests: API error response displays an error message in the panel instead of a response
+- [x] Webapp component tests: Shift+Enter inserts a newline in the input rather than submitting
+- [x] Webapp component tests: empty query submission is ignored — no API call, no loading state change
+- [x] Webapp component tests: conversation history displays multiple exchanges in chronological order
+- [x] Webapp component tests: "New conversation" action resets the Redux state (clears history, sessionId, response)
+- [x] Webapp component tests: Redux reducer handles all defined action types with correct state transitions
+- [x] Webapp component tests: API client includes CSRF token and credentials in requests
+- [x] E2E tests: plugin can be installed and activated, and the app bar icon appears in the UI
+- [x] E2E tests: clicking the app bar icon opens the RHS panel, clicking again closes it
+- [x] E2E tests: typing a query and pressing Enter shows a loading indicator, then the mock response rendered as markdown
+- [x] E2E tests: citation links in the response navigate to the original post permalink
+- [x] E2E tests: follow-up query submission uses the follow-up endpoint and both exchanges are visible in conversation history
+- [x] E2E tests: pressing Enter with an empty input field does not trigger any API call
+- [x] E2E tests: slash command `/ask` produces an ephemeral post with the mock response and citation links
+- [x] E2E tests: WebSocket thread summary event causes a visual indicator to appear without page refresh
+- [x] E2E tests: all Playwright tests use route interception for plugin API calls and do not require a real Gemini API key
+- [x] E2E tests: a shared route interception helper module provides reusable mock response functions for all plugin endpoints
diff --git a/tasks/0001-org-memory-ai-knowledge-base/_history.md b/tasks/0001-org-memory-ai-knowledge-base/_history.md
new file mode 100644
index 000000000000..9f85074e2004
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/_history.md
@@ -0,0 +1,2 @@
+- 2026-03-26 23:10:55 +02:00 Run started (aea42224-8fc9-49cf-8666-03a5fa94f9d8)
+- 2026-03-26 21:16:05 +02:00 Created
diff --git a/tasks/0001-org-memory-ai-knowledge-base/ai_review_criticism.md b/tasks/0001-org-memory-ai-knowledge-base/ai_review_criticism.md
new file mode 100644
index 000000000000..e243cd85fcd5
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/ai_review_criticism.md
@@ -0,0 +1,173 @@
+# AI Spec Review
+
+## Overall Assessment
+High-quality specs with exceptional detail, but contains several schema/interface conflicts that will cause the builder to fail at implementation time.
+
+## Critical Issues
+
+### 1. Processing log schema cannot accommodate post + file embeddings (steps 003, 006, 007)
+The `ai_processing_log` table has a UNIQUE constraint on `(PostId, JobType)` (step 003, line 143). Step 006 says to "create an additional processing log entry with job type 'embed' and source type 'file'" for file attachments — but the table has no `SourceType` column, and the unique constraint means you cannot create two "embed" entries for the same `PostId` (one for the post message, one for the attached file). The builder will hit a constraint violation when implementing step 006 for posts with attachments.
+
+**Fix:** Either add a `SourceType` column to `ai_processing_log` and change the unique constraint to `(PostId, JobType, SourceType)`, or redesign the file processing approach to bundle file content with the post's embed job (e.g., the worker fetches file content during embed processing rather than having a separate processing log entry).
+
+### 2. Gemini client interface insufficient for thread summarization (steps 004, 008)
+Step 004 defines the "extract knowledge" operation as returning "typed extraction items (decision, action_item, topic) with content and optional metadata." Step 008 expects the same operation to also return "a concise summary of the thread discussion" and "a list of key takeaways." The interface as defined in step 004 has no return type for summary text or key takeaways — only extractions.
+
+**Fix:** Either add a fourth operation to the Gemini client interface (e.g., "summarize and extract" that returns a combined result with summary text, key takeaways, AND typed extractions), or extend the "extract knowledge" return type to include optional summary and takeaways fields. Step 004's acceptance criteria must be updated to match.
+
+### 3. No real-time code path creates "extract" processing log entries (steps 006, 007)
+Step 006 (MessageHasBeenPosted) only creates entries with job type "embed." The processing worker (step 007) has an "extract" handler, and the processing log supports "extract" as a job type — but no real-time hook ever creates "extract" entries for individual posts. Thread-level extraction happens directly in step 008 (debounce handler) without the processing log. Individual post-level extraction in real-time is never triggered.
+
+Step 017 (backfill) creates both "embed" and "extract" entries, making backfilled posts get individual extraction while real-time posts do not. This inconsistency seems unintentional.
+
+**Fix:** Either step 006 should create both "embed" and "extract" processing log entries for each new post, or the specs should explicitly state that individual post extraction only happens during backfill and thread-level extraction (via debounce) is the only real-time extraction path. The current specs are silent on this design decision, which will confuse the builder.
+
+### 4. DailySummaryHour config setting is never consumed (steps 002, 011)
+Step 001/002 define a `DailySummaryHour` configuration field (default 8, "The hour of day at which daily summaries are generated"). Step 011 schedules the daily worker using `MakeWaitForRoundedInterval(24 * time.Hour)`, which aligns to 24-hour boundaries from the epoch — it does NOT schedule at a specific hour. The `DailySummaryHour` config value is defined, loaded, stored in the config struct, but never read by any component. The builder will implement a config field that has no effect.
+
+**Fix:** Step 011 needs to use a custom wait function that calculates the next occurrence of the configured hour (similar to `GenerateNextStartDateTime` referenced in step 011's own Related Code section), or the `DailySummaryHour` config field should be removed from steps 001/002 if round-interval scheduling is the actual intent.
+
+### 5. Missing backfill cancel/pause API endpoint (steps 010, 017)
+Step 017 references pause/cancel functionality: "When the admin sends a cancellation request (via a mechanism such as `POST /api/v1/admin/backfill` with a `cancel` action, or a dedicated cancel endpoint)." However, step 010's endpoint definition for `POST /api/v1/admin/backfill` only handles triggering a new backfill — there is no cancel action, no resume action, and no dedicated cancel endpoint in the 13 endpoints listed. The builder implementing step 010 has no specification for cancel/resume, and step 017's pause/resume acceptance criteria reference an endpoint that doesn't exist.
+
+**Fix:** Add cancel/resume to the backfill endpoint definition in step 010 (e.g., `POST /api/v1/admin/backfill` accepts an `action` field: "start", "pause", "resume"), or add a dedicated `DELETE /api/v1/admin/backfill/{channel_id}` endpoint for cancellation. Update step 010's acceptance criteria to include these operations.
+
+### 6. Post edit reprocessing conflicts with idempotent processing log design (steps 003, 006)
+Step 003 says the processing log create operation is "idempotent — ignore if duplicate PostId+JobType exists." Step 006 says when a post is edited, "create a new processing log entry with status 'pending' and job type 'embed' for the post" and notes "the store's unique constraint means this either creates a new entry or the worker will pick up the latest pending entry." These are contradictory: if the create operation ignores duplicates, an edit to an already-processed post (whose processing log entry has status "complete") will NOT create a new pending entry — the existing "complete" entry will be left unchanged and the post will not be reprocessed.
+
+**Fix:** Step 003 needs an upsert operation for the edited-post case that resets status to "pending" when the entry already exists with status "complete". The idempotent create (skip if exists) is correct for initial ingestion, but edits require a different operation that resets the status. Define both operations in the store interface.
+
+## Suggestions
+
+### Step granularity concerns
+- **Step 003** is the largest step by scope: 7 table definitions with columns/indexes/constraints, a full store interface with ~25+ methods across 7 categories, plus a schema migration runner, plus OnActivate wiring. This will produce 1000+ lines of code across at least 3-4 files (migration SQL, store interface, store implementation, store tests). Consider splitting into two steps: one for schema migration (table DDL) and one for the store interface implementation.
+- **Step 010** defines 13 HTTP endpoints plus a slash command handler. Each endpoint has auth, validation, business logic delegation, and response formatting. This is likely 500+ lines of router + handler code. Consider splitting into core query/summary endpoints (user-facing) and admin endpoints (backfill/status/webhooks).
+- **Step 014** defines 30+ individual metric instruments across 9 categories. While conceptually simple, the boilerplate is substantial. The step is manageable if the builder treats it as mechanical registration, but it touches every other component to add instrumentation call sites.
+
+### ai_query_log foreign key missing CASCADE (step 003)
+The `ai_query_log` table defines `UserId VARCHAR(26), not null, foreign key to Users(Id)` without specifying ON DELETE CASCADE. Requirements state "All foreign keys to Mattermost core tables (Posts, Channels, Users) use ON DELETE CASCADE." If a user is deleted, the FK would prevent deletion. Either add CASCADE or remove the FK (query log is write-only audit data where a dangling user ID is acceptable).
+
+### Thread summary embedding source type ambiguity (steps 007, 008)
+Step 008 creates a processing log entry with "source type 'summary'" for thread summary embedding. But the processing log table (step 003) has no `SourceType` column. Step 007's embed handler says "If 'file', retrieve the extracted file text from the KV store." How does the worker know whether to use the post message, file content, or summary text? Without a SourceType column in the processing log, the worker has no way to distinguish these cases.
+
+This overlaps with Critical Issue #1 — the processing log needs a SourceType column (or equivalent mechanism) to distinguish post/file/summary content sources.
+
+### Extraction editing triggers re-embedding but not re-extraction (step 010)
+The extraction edit endpoint (PUT /extractions/{id}) "triggers re-embedding" by creating a processing log entry with job type "embed." But if the extraction content changed, shouldn't the entity mentions also be updated? The current spec only re-embeds, leaving entity mentions based on the pre-edit content.
+
+### WebSocket event naming (steps 008, 011, 016)
+Step 008 says to publish event `custom_org-memory_thread_summary_ready` and notes "the event name is automatically prefixed with `custom_{pluginid}_`" by `PublishWebSocketEvent`. This means the code should pass `thread_summary_ready` as the event name (the server adds the prefix). Step 016's WebSocket handler registers for the full name `custom_org-memory_thread_summary_ready`. Step 011 uses `custom_org-memory_channel_summary_ready`. This is correct but could confuse the builder — clarify in step 008 that the code passes the unprefixed name to `PublishWebSocketEvent` while the webapp registers with the fully-prefixed name.
+
+### Token estimation accuracy for non-English text (step 005)
+The chunking engine uses "4 characters per token" as a heuristic. This is reasonable for English but significantly inaccurate for CJK languages (where 1-2 characters ≈ 1 token) and heavily technical text (where variable names inflate character-to-token ratios). If the target workspace uses non-English languages, chunks will be undersized. This is acceptable as a v1 limitation but should be documented as such in the step.
+
+## Per-File Notes
+
+### requirements.md
+No issues. Clear, well-structured, with specific success criteria and explicit constraints.
+
+### architecture.md
+- The "Thread Debounce Handler" section (§3) says "The singleton scheduler callback dispatches to different handlers based on a key prefix convention — debounce jobs use a 'debounce:' prefix, while backfill jobs use a 'backfill:' prefix." This is a design decision that belongs in the step specs (006, 008, 017) rather than just the architecture doc. It IS documented in the steps, so this is fine, but the architecture doc should note that the debounce handler also performs extraction directly (not via the processing log), which is an important architectural detail.
+- The architecture references `GetInternalMasterDB()` in the constraints section but `StoreService.GetMasterDB()` in the integration points section. The correct plugin API is `pluginapi.StoreService.GetMasterDB()` — the constraints section's reference is misleading.
+
+### testing.md
+- The "Manual Testing" section says "None — all verification must be automated." This is good.
+- The testing plan lists extraction editing tests that verify "re-embedding" but doesn't test whether entity mentions are updated after an extraction edit. Since the spec only re-embeds (doesn't re-extract entity mentions), the test plan is consistent with the spec, but this represents a gap in the feature itself.
+
+### overview.md
+- The step descriptions are concise and accurate summaries of each step file.
+- No issues with ordering or dependency descriptions.
+
+### 001.md
+- References cleaning up "server/plugins/org-memory/server/dist/" and "webapp/dist/" — these are relative paths. The builder should understand these are relative to the plugin root.
+- No other issues. Clear scaffold definition.
+
+### 002.md
+No issues. Well-structured lifecycle management with clear acceptance criteria.
+
+### 003.md
+- **Critical**: Missing SourceType column in `ai_processing_log` (see Critical Issue #1).
+- **Critical**: Idempotent create vs. edit reprocessing conflict (see Critical Issue #6).
+- **Suggestion**: `ai_query_log` FK to Users(Id) should specify ON DELETE CASCADE (or remove the FK entirely).
+- The step is very large — 7 tables + full store interface + OnActivate wiring. See granularity suggestion above.
+
+### 004.md
+- **Critical**: Interface doesn't support thread summarization output (see Critical Issue #2).
+- The step is otherwise very well specified. Resilience patterns (backoff, circuit breaker) are described with precise thresholds and state transitions.
+
+### 005.md
+No issues. The chunking algorithm is described step-by-step with clear edge cases. Acceptance criteria are testable and specific.
+
+### 006.md
+- **Critical**: File attachment processing creates duplicate `(PostId, 'embed')` entries that violate the unique constraint (see Critical Issue #1).
+- **Critical**: Only "embed" entries are created, not "extract" (see Critical Issue #3).
+- The `FileWillBeUploaded` hook stores extracted text in KV store keyed by file ID — this is a reasonable approach, but there's no cleanup mechanism if the file upload is abandoned (no post is ever created for the file). The KV entry would persist indefinitely. Consider adding a TTL.
+- Acceptance criterion "All hook handlers return quickly — no Gemini API calls, no heavy computation, only database writes and scheduler operations" is testable, but "quickly" is subjective. Consider adding a measurable threshold (e.g., "complete within 100ms").
+
+### 007.md
+- The step references processing entries with source type "file" and "summary" but the processing log table has no SourceType column. The worker's embed handler needs to know the content source to determine what to embed. See Critical Issue #1 / suggestion about SourceType.
+- "Delete previous embeddings — Before storing new embeddings (for reprocessing due to post edits), delete any existing embeddings for this post ID and source type." References "source type" filtering that doesn't exist in the schema.
+- Otherwise well-structured with clear status transitions, retry logic, and panic recovery.
+
+### 008.md
+- **Critical**: Calls "knowledge extraction operation" expecting summary + takeaways + extractions, but the interface only returns extractions (see Critical Issue #2).
+- The map-reduce approach for large threads (>100 messages) is well-described but adds significant complexity. Consider whether this should be a separate follow-up step.
+- Error handling for Gemini failures (reschedule at 60s, 3 retries) is well-defined.
+
+### 009.md
+- The direct message channel handling is identified as a gap: "GetChannelMembersForUser with an empty string as teamID may not work." The spec acknowledges the problem but doesn't provide a definitive solution, leaving the builder to figure it out.
+- "Use the replica database" for vector search is specified, which is good for production, but the plugin accesses the DB via `pluginapi.StoreService.GetMasterDB()` — there's also `GetReplicaDB()`. This is correctly referenced.
+- Well-specified overall with clear permission resolution, caching, and citation formatting.
+
+### 010.md
+- **Critical**: Missing backfill cancel/pause endpoint (see Critical Issue #5).
+- The step defines 13 endpoints + slash command — very large scope. See granularity suggestion.
+- Content-Type enforcement returning 415 on non-JSON is specified, which is good. But what about GET requests that may have query params — the spec correctly limits this to POST/PUT.
+
+### 011.md
+- **Critical**: DailySummaryHour config is unused (see Critical Issue #4).
+- The enumeration of active channels is left as "Option A or Option B" — the builder must decide. This is acceptable flexibility but could cause implementation variance.
+- Time zone handling is explicitly called out as a limitation, which is good.
+
+### 012.md
+- "3 failed retries (4 total attempts including the original)" — the wording is slightly ambiguous. Step 012's deliverables section says "retry up to 3 times with exponential backoff (1s, 2s, 4s waits between retries)" and "After 3 failed retries, the delivery is logged as failed" — this means 1 initial attempt + 3 retries = 4 total attempts. The acceptance criteria say "retried up to 3 times" which is consistent. Wording is clear enough.
+- No other issues. Well-scoped step.
+
+### 013.md
+- Channel summary retention thresholds (90 days daily, 365 days weekly) and processing log retention (30 days) are compile-time constants. This is fine but the builder should know these are hardcoded, not configurable.
+- The orphan detection approach (checking which PostIds no longer exist in Posts) requires a LEFT JOIN or NOT EXISTS subquery against the Posts table. For large tables, this could be expensive. The batch deletion pattern mitigates this.
+- Well-specified with clear batch semantics.
+
+### 014.md
+- Very detailed metric definitions. 30+ instruments across 9 categories.
+- The GaugeFunc for "total embeddings" (`SELECT COUNT(*) FROM ai_embeddings WHERE DeleteAt = 0`) could be slow on large tables. The spec acknowledges this and suggests `pg_class.reltuples` as an alternative. Good.
+- The no-op fallback is a good design decision.
+- No issues.
+
+### 015.md
+- References `window.PostUtils.formatText` and `messageHtmlToComponent` — these are real Mattermost APIs available to plugins. Good.
+- The citation link format is described as `[1](/{teamName}/pl/{postId})` in step 015, but step 009 formats as `{SiteURL}/pl/{postId}`. These are different formats — one uses a relative URL with team name, the other uses the absolute SiteURL. The builder needs to know which format the backend produces.
+- The `registerAppBarComponent` with `rhsComponent` pattern is well-documented and correct.
+
+### 016.md
+- Well-structured extension of step 015.
+- The post dropdown menu action is marked as optional, which is appropriate.
+- WebSocket event handler registration correctly uses the full prefixed event name.
+- The reconnect handler's stale loading detection (>30 seconds) is a nice touch.
+
+### 017.md
+- **Critical**: References cancel/pause mechanism that has no API endpoint (see Critical Issue #5).
+- The compound cursor pattern `(CreateAt, Id)` is well-described but the available plugin API methods (`GetPostsSince`, `GetPostsForChannel`, `GetPostsAfter`) don't natively support compound cursors. The builder will need to implement cursor filtering in application code after fetching posts via the available API. This is feasible but the spec could be more explicit about how to bridge the gap.
+- Thread backfill coordination (collecting root IDs, creating "summarize" entries) is well-thought-out.
+
+### 018.md
+- Comprehensive test organization covering all testing.md items.
+- The integration test gating via build tag or environment variable is a good pattern.
+- Deterministic embeddings for integration tests (known cosine distances) is well-specified.
+- No issues.
+
+### 019.md
+- Good use of Playwright route interception to avoid Gemini dependency.
+- The shared route interception helper module is a good pattern.
+- Citation link navigation test depends on creating real posts during setup, which is a realistic E2E approach.
+- No issues.
diff --git a/tasks/0001-org-memory-ai-knowledge-base/architecture.md b/tasks/0001-org-memory-ai-knowledge-base/architecture.md
new file mode 100644
index 000000000000..350bd201dc4a
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/architecture.md
@@ -0,0 +1,264 @@
+# Architecture
+
+## Overview
+
+The Organizational Memory plugin is a self-contained Mattermost plugin living entirely within `server/plugins/org-memory/`. It has two build artifacts: a Go server binary (handling hooks, API, background processing, and database operations) and a React/TypeScript webapp bundle (providing the RHS panel and UI components). The plugin communicates with the Mattermost server via the standard plugin RPC bridge and accesses the same PostgreSQL database (with pgvector extension) via the plugin store service.
+
+## Components Affected
+
+### 1. Plugin Server Core
+
+The main plugin struct embeds `plugin.MattermostPlugin` and initializes all subsystems during activation. On activation, it creates a `pluginapi.Client` for organized API access, obtains a database handle via the store service, runs idempotent schema migrations, starts all background schedulers, and registers the `/ask` slash command. On deactivation, it shuts down all schedulers gracefully and releases database connections.
+
+Configuration changes (Gemini API key, model names, debounce seconds, etc.) are handled by reloading the plugin configuration struct and propagating updated values to the Gemini client and scheduler components without requiring a full restart.
+
+### 2. Event Ingestion Layer
+
+The plugin implements message lifecycle hooks to capture real-time activity:
+
+- **Post created**: When a message is posted, the plugin checks whether to skip it (bot posts, disabled teams), then writes a pending processing entry to the processing log table. It also triggers the thread debounce mechanism — scheduling a one-time job for the thread's root ID to fire after the configured inactivity period. If a debounce job already exists for that thread, it cancels the old one and schedules a new one with a fresh future time.
+- **Post updated**: When a message is edited, the plugin marks any existing embeddings and extractions for that post as needing reprocessing by writing new pending entries to the processing log.
+- **Post deleted**: When a message is deleted, the plugin removes all associated embeddings, extractions, and entity mentions. Database-level cascade deletion handles most cleanup, but the hook also cancels any pending processing jobs for that post.
+- **File uploaded**: When a file is attached to a post, the plugin retrieves the file metadata and, if text content is available from Mattermost's built-in extraction, includes it as additional content for the post's embedding. If extraction content is not available, the plugin fetches the raw file bytes and performs its own text extraction for supported formats.
+- **User deactivated**: When a user is deactivated, no knowledge base content is removed (the knowledge belongs to the conversation, not the individual), but any active multi-turn conversation sessions for that user are cleaned up from the KV store.
+
+### 3. Background Processing Workers
+
+Three distinct background processing patterns run concurrently, all coordinated via the cluster scheduling package to ensure only one cluster node executes a given task:
+
+**Embedding/Extraction Worker** — A recurring job that polls the processing log table every second for items with "pending" status. For each item, it acquires a distributed mutex keyed to the post ID, updates the status to "processing", performs the work (embedding generation, knowledge extraction, or summarization depending on job type), stores results in the appropriate tables, and updates the status to "complete". On failure, it records the error message, increments a retry counter, and returns the item to "pending" status. After three consecutive failures on the same item, it marks it as "error" permanently.
+
+**Thread Debounce Handler** — Uses the one-time job scheduler. When a debounce job fires (meaning a thread has been inactive for the configured period), the handler fetches all posts in the thread, assembles them into a coherent conversation, sends the conversation to Gemini for summarization and knowledge extraction, stores the thread summary, and creates processing log entries for individual post embeddings that haven't been processed yet. The singleton scheduler callback dispatches to different handlers based on a key prefix convention — debounce jobs use a "debounce:" prefix, while backfill jobs use a "backfill:" prefix.
+
+**Summary Generation Worker** — A recurring job using rounded-interval scheduling to generate daily and weekly channel summaries. It runs at the configured hour (default: 8 AM) and processes channels that have had activity since the last summary window. For each channel, it gathers thread summaries and extractions from the window period, sends them to Gemini for synthesis into a channel-level summary, and stores the result. Weekly summaries aggregate from daily summaries rather than raw posts.
+
+### 4. Gemini Integration Layer
+
+A single component manages all communication with the Google Gemini API via the native Go SDK. It provides three operations:
+
+- **Generate embeddings**: Accepts text content, calls gemini-embedding-001 at 768 dimensions, L2-normalizes the resulting vector, and returns it. Handles chunking coordination — if input exceeds ~500 tokens, the caller splits it into chunks first and calls embedding generation per chunk.
+- **Extract knowledge**: Accepts conversation text, calls Gemini 2.5 Flash with a structured extraction prompt, and parses the response into typed extractions (decisions, action items, topics) with metadata (assignee, confidence level).
+- **Synthesize answer (RAG)**: Accepts a user query plus retrieved context passages, calls Gemini 2.5 Flash with a RAG synthesis prompt that instructs the model to answer using only the provided context and cite sources, and returns the synthesized answer with citation references.
+
+This layer implements resilience patterns: exponential backoff on HTTP 429 (rate limit) responses starting at 1 second and doubling up to 60 seconds, a circuit breaker that opens after 5 consecutive failures and stays open for 30 seconds before allowing a test request, and request timeout enforcement. Rate limit state is tracked in the KV store so all cluster nodes share awareness.
+
+### 5. Chunking Engine
+
+A text processing component that splits long content into embeddable chunks using semantic boundaries:
+
+1. Split the input text by paragraph breaks (double newlines)
+2. If any single paragraph exceeds the target chunk size (~500 tokens), further split it at sentence boundaries (period followed by whitespace)
+3. Merge consecutive small segments until they approach the target size, keeping semantic units together
+4. Add overlap between adjacent chunks — the last ~10% of tokens from the previous chunk are prepended to the next chunk to preserve cross-boundary context
+5. Cap at the configured maximum chunks per post (default 32); if content produces more chunks, truncate with a warning log
+
+Each chunk is tracked with a sequential index so that citation reconstruction can map from a matched chunk back to its approximate position in the original content.
+
+### 6. Knowledge Store (Database Layer)
+
+The database layer manages seven tables through a store interface that abstracts all SQL operations:
+
+**ai_embeddings** — Stores vector embeddings per post chunk. Each row holds a 768-dimensional vector (L2-normalized), the original text snapshot for citation display, the source type (post, file, or summary), the chunk index for ordering, and standard Mattermost columns (ID, PostId, ChannelId, CreateAt, DeleteAt). An HNSW index with cosine similarity operator class supports efficient approximate nearest-neighbor search.
+
+**ai_extractions** — Stores knowledge items extracted by Gemini. Each row represents a single decision, action item, or topic with its content text, structured metadata (assignee, status, confidence as JSON), and edit tracking (whether it has been manually modified and by whom). Supports soft delete.
+
+**ai_thread_summaries** — Stores one summary per thread (keyed by root post ID). Includes the summary text, key takeaways as a JSON array, the model version used for generation, and the last activity timestamp to determine when a summary needs regeneration.
+
+**ai_channel_summaries** — Stores rolling daily and weekly summaries per channel. Each row covers a specific time window (start and end timestamps) with a unique constraint preventing duplicate summaries for the same channel, type, and window.
+
+**ai_entity_mentions** — Links extracted entity names (projects, technologies, people) to their source posts and channels. Entity names are normalized to lowercase for consistent matching. Supports cross-channel timeline queries by indexing on entity name and creation time.
+
+**ai_processing_log** — The work queue and idempotency tracker. Each row represents a processing task (embed, extract, or summarize) for a specific post. Status transitions: pending → processing → complete (or error). A unique constraint on post ID plus job type prevents duplicate work items. Includes retry count and error message for failed items.
+
+**ai_query_log** — Audit trail for all user queries. Records who asked, what they asked, which channels were searched, how many results were returned, and the query latency. Write-only — no updates or deletes.
+
+Schema creation is idempotent — all tables use "create if not exists" and run during plugin activation. Future schema evolution uses conditional column additions (check column existence before altering). The pgvector extension is also created idempotently during activation.
+
+### 7. RAG Query Engine
+
+The query engine orchestrates the full retrieval-augmented generation pipeline:
+
+1. **Receive query** — Accept the user's natural language question and their user ID
+2. **Resolve permissions** — Fetch the user's channel memberships across all teams. Cache this list briefly (e.g., 60 seconds in the KV store) to avoid repeated lookups within a session. For workspaces with multiple teams, iterate over each team to build the complete channel list.
+3. **Embed query** — Send the query text through the Gemini embedding layer to get a 768-dimensional query vector
+4. **Search** — Execute a vector similarity search against ai_embeddings, filtering by the user's permitted channel IDs and excluding soft-deleted entries. Return the top N most similar results (default 10).
+5. **Enrich** — For each result, fetch the original post content and thread context to provide the LLM with fuller context. Include the content snapshot from the embedding for citation accuracy.
+6. **Synthesize** — Send the query plus retrieved passages to Gemini for answer synthesis. The prompt instructs the model to: answer only from provided context, cite sources by reference number, and explicitly state when it cannot find relevant information.
+7. **Format response** — Parse the synthesized answer, map citation references to actual post permalinks, and return the formatted response with clickable citation links.
+
+For follow-up queries (multi-turn), the engine loads the previous conversation history from the KV store (keyed by user ID + session identifier), appends it to the context, and includes it in the synthesis prompt so Gemini can reference prior exchanges. Sessions expire after a configurable TTL (default 30 minutes of inactivity).
+
+### 8. HTTP API Router
+
+The plugin's ServeHTTP handler routes incoming requests under `/plugins/org-memory/api/v1/`. All endpoints require a valid Mattermost session (extracted from the request headers). The router dispatches to handlers for:
+
+- **Query endpoints** — POST for new queries and follow-up queries. Validates input, calls the RAG engine, logs the query to the audit table, and returns the response.
+- **Summary endpoints** — GET for thread summaries (by root post ID) and channel summaries (by channel ID and type). Checks that the requesting user has access to the channel before returning data.
+- **Entity endpoints** — GET for entity timelines by name. Returns a chronological list of mentions across channels the user can access.
+- **Extraction endpoints** — GET to list extractions with filtering by channel and type. PUT to edit an extraction's content, which marks it as edited, updates the editor user ID, and triggers re-embedding of the modified content.
+- **Admin endpoints** — POST to trigger historical backfill (restricted to system admins). GET for pipeline status including processing queue depth, error counts, and worker health.
+- **Webhook endpoints** — CRUD operations for outbound webhook configurations (restricted to system admins). Configurations are stored in and retrieved from the KV store.
+
+### 9. Slash Command Handler
+
+The `/ask` command handler receives the command text, strips the trigger word, and passes the remainder as a query to the RAG engine using the invoking user's permissions. Results are returned as an ephemeral post (visible only to the invoker) in the current channel. The response includes the synthesized answer with citation links formatted as Mattermost markdown.
+
+### 10. Outbound Webhook Dispatcher
+
+When the extraction worker produces new decisions or action items, the webhook dispatcher checks whether any webhook configurations exist for the source channel. For each matching webhook, it formats the extraction data according to a standard payload format and sends an HTTP POST to the configured URL. Failed deliveries are retried up to 3 times with exponential backoff. Webhook configurations include: target URL, which extraction types to send (decisions, action items, or both), and an optional secret for HMAC signature verification.
+
+### 11. Webapp Plugin Bundle
+
+The webapp plugin registers with Mattermost during initialization and provides:
+
+**App Bar Icon** — Registers an icon in the Mattermost app bar that toggles the RHS panel open/closed. Uses `registerAppBarComponent` with an `rhsComponent` to link the icon directly to the RHS.
+
+**RHS Panel ("Ask your workspace")** — Registered via `registerRightHandSidebarComponent`. The panel contains:
+- A text input field for entering natural language queries
+- A response display area that renders Gemini's synthesized answers as markdown
+- Citation links rendered as clickable elements that navigate to the original post when clicked
+- A follow-up input that appears after the initial response, allowing multi-turn conversation
+- A loading indicator shown while waiting for the backend response
+
+**WebSocket Event Handler** — Listens for custom plugin events (prefixed with `custom_org-memory_`) to receive real-time updates when processing completes for posts visible to the user. This allows the UI to show "summary available" indicators without polling.
+
+**Redux Reducer** — Manages local state for the plugin: current query, response history, loading state, and session identifier for multi-turn context.
+
+**API Client** — A thin wrapper around `fetch` calls to the plugin's backend endpoints at `/plugins/org-memory/api/v1/*`. Handles authentication via the existing Mattermost session cookie/token.
+
+### 12. Metrics and Observability
+
+The plugin implements `ServeMetrics` to expose Prometheus-compatible metrics:
+
+- Processing pipeline: items processed per second, queue depth, error rate, processing latency by job type
+- Gemini API: request count, latency histogram, error rate, rate limit hits, circuit breaker state
+- RAG queries: query count, latency histogram, result count distribution, cache hit rate for permission lookups
+- Embedding operations: embeddings generated per second, chunking distribution (how many chunks per post)
+
+### 13. Data Retention Integration
+
+The plugin implements the `RunDataRetention` hook to participate in Mattermost's data retention sweeps. When called, it deletes knowledge base entries (embeddings, extractions, entity mentions, summaries) whose source posts fall within the retention window. Processing is batched to avoid blocking the retention pipeline — each invocation processes up to the provided batch size and returns the count of deleted rows, allowing Mattermost to call it repeatedly until all aged-out data is cleaned.
+
+## New Entities
+
+### Database Tables (7 total)
+
+1. **ai_embeddings** — One row per chunk per post. Holds the vector embedding (768-dim), content snapshot, source type, chunk index. Indexed for vector similarity search (HNSW cosine) and by channel ID for permission filtering.
+
+2. **ai_extractions** — One row per extracted knowledge item (decision, action item, or topic). Holds content, type, structured metadata, edit tracking. Indexed by channel and type for filtered listing.
+
+3. **ai_thread_summaries** — One row per thread (keyed by root post ID). Holds summary text, key takeaways, model version, activity timestamps.
+
+4. **ai_channel_summaries** — One row per summary window per channel. Holds summary text, window boundaries, type (daily/weekly). Uniquely constrained by channel + type + window start.
+
+5. **ai_entity_mentions** — One row per entity mention in a post. Holds normalized entity name, type, linked extraction. Indexed by entity name + time for timeline queries.
+
+6. **ai_processing_log** — One row per processing task. Holds job type, status, schedule time, retry count, error message. Indexed by status + schedule time for worker polling and by post + type for idempotency.
+
+7. **ai_query_log** — One row per user query. Holds user, query text, channels searched, result count, latency. Write-only audit trail.
+
+### KV Store Entries
+
+- **Multi-turn conversation sessions** — Keyed by user ID + session ID. Stores recent query/response pairs for follow-up context. TTL of 30 minutes.
+- **Webhook configurations** — Keyed by `webhook:{channel_id}:{webhook_id}`. Stores target URL, extraction type filter, secret.
+- **Permission cache** — Keyed by user ID. Stores the user's channel membership list with short TTL (~60 seconds) to reduce RPC overhead during RAG queries.
+- **Circuit breaker state** — Keyed by a fixed key. Stores failure count, last failure time, and breaker state (closed/open/half-open) for cluster-wide Gemini API resilience.
+
+### API Endpoints
+
+All under `/plugins/org-memory/api/v1/`:
+
+- `POST /query` — Submit a RAG query. Accepts query text, returns synthesized answer with citations.
+- `POST /query/followup` — Submit a follow-up query with session context. Accepts query text and session ID.
+- `GET /threads/{root_id}/summary` — Retrieve thread summary and extractions for a given thread.
+- `GET /channels/{channel_id}/summary` — Retrieve daily or weekly channel summary (type specified via query parameter).
+- `GET /entities/{name}/timeline` — Retrieve cross-channel entity timeline.
+- `GET /extractions` — List extractions filtered by channel ID and/or extraction type.
+- `PUT /extractions/{id}` — Edit an extraction's content (triggers re-embedding).
+- `POST /admin/backfill` — Trigger historical data backfill (system admin only).
+- `GET /admin/status` — Pipeline health status and metrics.
+- `POST /webhooks` — Create outbound webhook configuration (system admin only).
+- `GET /webhooks` — List webhook configurations (system admin only).
+- `DELETE /webhooks/{id}` — Remove webhook configuration (system admin only).
+
+### Slash Command
+
+- `/ask <question>` — Registered during plugin activation. Returns ephemeral post with RAG results.
+
+## Integration Points
+
+### Plugin ↔ Mattermost Server
+
+- **Hooks**: The plugin receives real-time events via `MessageHasBeenPosted`, `MessageHasBeenUpdated`, `MessageHasBeenDeleted`, `FileWillBeUploaded`, `UserHasBeenDeactivated`, and `RunDataRetention`. These hooks are the sole entry points for event-driven processing.
+- **Plugin API (RPC)**: The plugin calls `GetPost`, `GetPostThread`, `GetPostsSince`, `GetChannelMember`, `GetChannelMembersForUser`, `HasPermissionToChannel`, `GetUser`, `CreatePost`, `SendEphemeralPost`, `RegisterCommand`, `GetFileInfo`, `GetFile`, and `GetConfig` across the RPC bridge. These calls are performance-sensitive — the plugin should batch where possible and cache permission lookups.
+- **Database**: The plugin obtains a raw database connection via the plugin store service and executes SQL directly against the same PostgreSQL instance that Mattermost uses. The plugin's tables coexist alongside Mattermost core tables with foreign key relationships (ON DELETE CASCADE) to Posts, Channels, and Users.
+- **KV Store**: The plugin uses the KV store for lightweight state: conversation sessions, webhook configs, permission caches, circuit breaker state. The KV store is automatically namespaced per plugin and supports TTL expiration.
+
+### Plugin ↔ Google Gemini API
+
+- **Outbound HTTPS**: All LLM and embedding calls are outbound HTTPS requests to Google's Gemini API endpoints via the `google.golang.org/genai` Go SDK. The API key is stored in the plugin configuration (marked as secret in the manifest).
+- **Rate limiting**: Gemini imposes per-minute token and request limits. The plugin tracks rate limit state in KV store and implements cluster-wide throttling so all nodes collectively stay within limits.
+
+### Plugin ↔ External Webhooks
+
+- **Outbound HTTP POST**: When new decisions or action items are extracted and matching webhook configurations exist, the plugin sends HTTP POST requests to the configured URLs. Payloads include the extraction content, source channel, source post permalink, and extraction type. An optional HMAC signature header allows receivers to verify authenticity.
+
+### Webapp ↔ Plugin Server
+
+- **HTTP API**: The webapp makes fetch requests to `/plugins/org-memory/api/v1/*` endpoints. Authentication is handled by the existing Mattermost session (cookie or token header) — the plugin extracts the user ID from the Mattermost-User-Id request header set by the server.
+- **WebSocket**: The plugin publishes custom WebSocket events via `PublishPluginClusterEvent` when processing completes. The webapp listens for these events via `registerWebSocketEventHandler` to update the UI in real time (e.g., showing that a thread summary is now available).
+
+### Database ↔ pgvector Extension
+
+- **Extension dependency**: The plugin requires the pgvector extension to be installed in PostgreSQL. It attempts to create it idempotently during activation. If creation fails (insufficient privileges), activation fails with a descriptive error message guiding the admin to install the extension manually.
+- **Vector operations**: The plugin uses pgvector's vector type for the embedding column, the `<=>` operator for cosine distance in queries, and HNSW indexing for approximate nearest-neighbor search. All vector operations go through standard SQL via the database connection.
+
+## Failure Modes
+
+### Gemini API Unavailable
+
+If the Gemini API is unreachable or returns errors, the circuit breaker opens after 5 consecutive failures. While open, all processing items remain in "pending" status in the processing log, and RAG queries return a user-friendly error message ("Knowledge base is temporarily unavailable, please try again later"). The circuit breaker transitions to half-open after 30 seconds, allowing a single test request. If the test succeeds, the breaker closes and normal processing resumes. All pending items are picked up automatically by the worker on its next poll cycle.
+
+### Gemini Rate Limit Exceeded
+
+When the Gemini API returns HTTP 429 (rate limit), the plugin applies exponential backoff starting at 1 second, doubling up to 60 seconds. The current backoff state is stored in the KV store so all cluster nodes respect the same cooldown. During backoff, the worker skips Gemini-dependent tasks but continues polling the processing log. Items that couldn't be processed remain pending and are retried after the backoff period.
+
+### pgvector Extension Missing
+
+If the pgvector extension cannot be created during plugin activation (e.g., the database user lacks privileges or the PostgreSQL instance doesn't have pgvector installed), the plugin fails to activate with a clear error log message. The admin must install the pgvector extension manually before retrying activation.
+
+### Database Connection Failure
+
+If the database connection is lost, all SQL operations fail. The plugin store service manages connection pooling and reconnection. Plugin API calls that depend on the database (hooks, API endpoints, workers) will return errors until the connection is restored. The processing log pattern ensures no data loss — items in "processing" status when the connection dropped will be picked up again because the distributed mutex TTL will expire (15 seconds), and the worker will re-poll pending items.
+
+### Processing Worker Stalls
+
+If a worker crashes or is terminated while processing an item (status = "processing"), the distributed mutex TTL (15 seconds) ensures the lock is eventually released. On the next poll cycle, any other cluster node's worker can pick up items that have been stuck in "processing" for longer than the expected processing time. A "stale processing" detection mechanism identifies items in "processing" status for more than 5 minutes and returns them to "pending".
+
+### Post Deleted During Processing
+
+If a post is deleted while its processing is in progress, the cascade deletion removes related database rows. The worker may encounter "not found" errors when trying to store results. These are handled gracefully — the worker marks the processing log entry as "complete" (nothing to do) and moves on.
+
+### Large Thread Processing (Token Limits)
+
+Gemini 2.5 Flash supports up to 1M tokens of context, but extremely large threads (hundreds of messages) could approach practical limits and cause slow processing. For threads exceeding a configured message count threshold, the system uses a map-reduce approach: it summarizes subsets of messages first, then synthesizes the sub-summaries into a final thread summary. This bounds both token usage and latency.
+
+### Permission Check Overhead
+
+For users who are members of hundreds of channels, building the permission filter for RAG queries requires multiple paginated API calls across multiple teams. The permission cache (60-second TTL in KV store) mitigates this for follow-up queries within a session. If the cache is empty (first query), the initial query may have higher latency. The cache is invalidated implicitly by TTL expiry rather than by channel membership change events.
+
+### KV Store Size Overflow (Multi-turn Sessions)
+
+Multi-turn conversation history grows with each exchange. If a conversation approaches the KV store value size limit (~256KB), the plugin truncates older exchanges from the history, keeping only the most recent N exchanges. This prevents KV store write failures while preserving enough context for coherent follow-up answers.
+
+### Historical Backfill Overload
+
+A backfill of a large workspace (millions of posts) could overwhelm the Gemini API quota and cause processing to take days. The backfill system processes in configurable batches (default 100 posts), writes progress to the processing log for resumability, and applies a configurable rate limit on Gemini calls during backfill that is lower than real-time processing limits. Admins can monitor progress via the status endpoint and stop/resume backfill by canceling the scheduled job.
+
+### Concurrent Schema Migration
+
+In a multi-node deployment, multiple plugin instances may attempt to run schema migrations simultaneously during activation. All migration statements are idempotent ("create if not exists", "add column if not exists") so concurrent execution is safe — the first instance creates the schema, and subsequent instances' migrations are no-ops.
+
+### Webhook Delivery Failure
+
+If an outbound webhook target is unreachable, the dispatcher retries up to 3 times with exponential backoff (1s, 2s, 4s). After all retries fail, the delivery is logged as failed and discarded — no persistent retry queue. Repeatedly failing webhooks are logged as warnings but do not block the processing pipeline. Admins can review failed deliveries via the pipeline status endpoint.
diff --git a/tasks/0001-org-memory-ai-knowledge-base/overview.md b/tasks/0001-org-memory-ai-knowledge-base/overview.md
new file mode 100644
index 000000000000..994a89cfc0b9
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/overview.md
@@ -0,0 +1,27 @@
+# Organizational Memory AI Knowledge Base Plugin
+
+A self-contained Mattermost plugin that transforms workspace conversations into a structured, queryable knowledge base. Posts are automatically captured, summarized, and embedded as vectors using Google Gemini 2.5 Flash and pgvector. Users query via an "Ask your workspace" RHS panel or `/ask` slash command and receive permission-aware, citation-backed answers synthesized by Gemini. The plugin extracts decisions, action items, and topics; generates rolling channel summaries; supports entity timelines; and can push findings to external systems via outbound webhooks.
+
+## Sub-tasks
+
+| Step | Title | Done | Description |
+|------|-------|------|-------------|
+| [001](001.md) | Plugin scaffold, manifest, and build system | [x] | Create the plugin directory structure, Go module, plugin.json manifest with Gemini settings, Makefile for cross-platform builds, and the bare main entry point that embeds MattermostPlugin |
+| [002](002.md) | Configuration management and plugin lifecycle | [x] | Implement the configuration struct matching plugin.json settings, OnActivate (initialize pluginapi.Client, validate config), OnDeactivate (graceful shutdown), and OnConfigurationChange (hot reload). Register the /ask slash command during activation |
+| [003](003.md) | Database schema and knowledge store | [x] | Create idempotent migrations for the pgvector extension and all 7 tables (ai_embeddings, ai_extractions, ai_thread_summaries, ai_channel_summaries, ai_entity_mentions, ai_processing_log, ai_query_log) with indexes. Implement the store interface with CRUD operations, vector similarity search, and permission-filtered queries |
+| [004](004.md) | Gemini client with resilience patterns | [x] | Integrate the google.golang.org/genai Go SDK with four operations: embedding generation (768-dim, L2-normalized), knowledge extraction (decisions, action items, topics), thread summarize-and-extract (combined summary + takeaways + extractions), and RAG synthesis (answer with citations). Implement exponential backoff on rate limits and a circuit breaker (5 failures → open → 30s half-open) with state stored in KV store |
+| [005](005.md) | Chunking engine | [x] | Implement semantic boundary text splitting: split by paragraphs, then sentences for oversized paragraphs, merge small segments up to ~500 tokens, add 10% overlap between adjacent chunks, and cap at MaxChunksPerPost. Return chunks with sequential indices |
+| [006](006.md) | Event ingestion hooks | [x] | Implement MessageHasBeenPosted (skip bots/disabled teams, create processing log entry, schedule debounce), MessageHasBeenUpdated (queue reprocessing), MessageHasBeenDeleted (cleanup derived data, cancel pending jobs), FileWillBeUploaded (extract text content), and UserHasBeenDeactivated (clean up KV sessions) |
+| [007](007.md) | Processing worker for embedding and extraction | [x] | Implement the recurring worker using cluster.Schedule that polls the processing log every second, acquires distributed mutex per post, calls Gemini for embedding/extraction, stores results, handles retries (3 max then permanent error), and detects stale items stuck in processing for over 5 minutes |
+| [008](008.md) | Thread debounce and summarization | [x] | Implement the thread debounce using JobOnceScheduler: schedule/cancel/reschedule pattern on each post in a thread, and on fire fetch the full thread, send to Gemini for summarization, store the thread summary and key takeaways, and create processing log entries for unprocessed individual post embeddings |
+| [009](009.md) | RAG query engine with permission filtering | [x] | Implement the full RAG pipeline: resolve user channel permissions (cached 60s in KV store, multi-team aware), embed the query, vector similarity search filtered by permitted channels, enrich results with post context, synthesize via Gemini with citation instructions, format response with post permalinks. Support multi-turn via KV-stored conversation history with 30-minute TTL |
+| [010](010.md) | HTTP API router and slash command handler | [x] | Implement ServeHTTP with path routing for all 13 endpoints under /plugins/org-memory/api/v1/ (query, followup, thread summaries, channel summaries, entity timelines, extractions CRUD, admin backfill with start/pause/resume lifecycle, admin status, webhook CRUD). Add session authentication, permission checks per endpoint, and admin-only guards. Implement the /ask slash command handler returning ephemeral posts |
+| [011](011.md) | Channel summary generation worker | [x] | Implement the daily and weekly summary generation using cluster.Schedule. The daily worker uses a custom wait function targeting the configured DailySummaryHour (default 8 AM server time). The weekly worker uses MakeWaitForRoundedInterval(168h). Process channels with activity since the last window, gather thread summaries and extractions, synthesize via Gemini into channel-level summaries. Weekly summaries aggregate from daily summaries |
+| [012](012.md) | Outbound webhook dispatcher | [x] | Implement webhook config storage in KV store (key pattern webhook:{channel_id}:{id}), CRUD operations for webhook management, and the dispatch mechanism: on new decision/action item extraction, check for matching webhooks, send HTTP POST with payload and optional HMAC signature, retry up to 3 times with exponential backoff |
+| [013](013.md) | Data retention and lifecycle cleanup | [x] | Implement the RunDataRetention hook to batch-delete aged-out embeddings, extractions, entity mentions, and summaries within the retention window. Ensure cascade deletion handles post-level cleanup. Process up to batchSize rows per invocation and return the count for Mattermost to call repeatedly |
+| [014](014.md) | Metrics and observability | [x] | Implement ServeMetrics exposing Prometheus counters and histograms: processing pipeline throughput/queue/errors/latency, Gemini API request count/latency/errors/rate-limit-hits/circuit-breaker-state, RAG query count/latency/results, and embedding operations count/chunking-distribution |
+| [015](015.md) | Webapp: RHS panel with query interface | [x] | Create the webapp plugin bundle: register with Mattermost via registerPlugin, add app bar icon via registerAppBarComponent that toggles the RHS, implement the RHS panel component with text input, markdown-rendered response display, clickable citation links that navigate to source posts, and loading indicator. Add Redux reducer for plugin state and API client for backend calls |
+| [016](016.md) | Webapp: multi-turn conversation and WebSocket events | [x] | Add follow-up query support to the RHS panel (input appears after initial response, sends session ID for context continuity). Register WebSocket event handler for custom_org-memory_ events to show real-time "summary available" indicators. Manage session state and conversation history in the Redux reducer |
+| [017](017.md) | Historical backfill system | [x] | Implement the admin backfill endpoint that accepts channel ID, since date, and batch size parameters. Process posts in batches via the processing log, apply rate limiting for Gemini calls during backfill, track progress for resumability, and allow stopping/resuming via the scheduled job. Report progress via the admin status endpoint |
+| [018](018.md) | Server-side integration tests | [x] | Write integration tests requiring pgvector PostgreSQL: schema creation idempotency, vector insert+query, HNSW index usage, cascade deletion, end-to-end processing pipeline (post → embedding → extraction), RAG query pipeline with permission filtering, all API endpoint behaviors (auth, permissions, error cases), slash command, and resilience (circuit breaker recovery, worker crash recovery, backfill resumability) |
+| [019](019.md) | Browser and E2E tests | [x] | Write browser tests for the webapp: RHS panel open/close via app bar icon, query submission and response display, citation link navigation, follow-up conversation flow, empty query handling, thread summary display with decisions/action items, slash command execution and ephemeral response, and WebSocket-driven live update indicators |
diff --git a/tasks/0001-org-memory-ai-knowledge-base/requirements.md b/tasks/0001-org-memory-ai-knowledge-base/requirements.md
new file mode 100644
index 000000000000..57d32e1c9d57
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/requirements.md
@@ -0,0 +1,93 @@
+# Requirements
+
+## Problem Statement
+
+Mattermost workspaces accumulate vast amounts of institutional knowledge in conversations — decisions, action items, technical discussions, project updates — but this knowledge is effectively lost once threads scroll out of view. Users cannot find past decisions, new team members cannot onboard from historical context, and critical action items slip through the cracks.
+
+We need a self-contained Mattermost plugin ("Organizational Memory") that transforms conversations into a structured, queryable knowledge base. Users should be able to ask natural language questions and get accurate, permission-aware answers with citations linking back to original messages.
+
+## Success Criteria
+
+### Core Pipeline
+- [ ] Messages posted in Mattermost channels are automatically captured and processed in the background without blocking the user experience
+- [ ] Thread conversations are summarized after a configurable period of inactivity (default 120 seconds), with the debounce timer resetting on each new post in the thread
+- [ ] The system extracts structured knowledge from conversations: decisions made, action items assigned, and topics discussed
+- [ ] All processed content is embedded as vectors for semantic similarity search
+- [ ] File attachments (PDFs, documents, archives) have their text content extracted and included in the knowledge base
+- [ ] Bot posts are skipped by default (configurable)
+- [ ] Processing is idempotent — reprocessing the same post produces the same result without duplicates
+
+### Search & Retrieval
+- [ ] Users can ask natural language questions via an "Ask your workspace" interface and receive synthesized answers drawn from relevant conversations
+- [ ] Search results respect Mattermost channel permissions — users only see answers derived from channels they are members of
+- [ ] Every answer includes citations with clickable links back to the original source messages
+- [ ] When the system lacks sufficient information to answer a query, it clearly states so rather than fabricating an answer
+- [ ] Users can ask follow-up questions that maintain conversational context from previous exchanges within the same session
+
+### Summaries & Insights
+- [ ] Rolling daily and weekly channel summaries are automatically generated on a configurable schedule
+- [ ] Users can view an entity timeline — a chronological cross-channel view of all mentions and discussions about a specific project, technology, or person
+
+### User Interface
+- [ ] A right-hand sidebar (RHS) panel provides the primary "Ask your workspace" interface with a text input, response display area, and citation links
+- [ ] A `/ask` slash command provides quick query access that responds with results in the channel
+- [ ] Thread summaries, key takeaways, and extracted decisions/action items are viewable in a thread header panel
+- [ ] The UI is minimal and functional — text input, markdown-rendered responses, and clickable citation links; visual polish is deferred
+
+### Data Management
+- [ ] Extracted knowledge (decisions, action items, topics) can be manually edited by users, and edits trigger re-embedding to keep search results consistent
+- [ ] When source posts are deleted (by user action or data retention policies), all derived knowledge (embeddings, extractions, entity mentions) is automatically cleaned up
+- [ ] An admin can trigger a historical backfill to process existing messages that predate the plugin's installation, with progress tracking and ability to resume if interrupted
+
+### Integrations
+- [ ] Outbound webhooks can be configured to push extracted action items and decisions to external systems (e.g., Jira, GitHub) when new knowledge is extracted
+- [ ] Webhook configurations are managed via admin API endpoints
+
+### Operations & Administration
+- [ ] Admins can enable or disable the plugin per team
+- [ ] All user queries are logged for audit and compliance purposes (who asked what, when, which channels were searched, result count, latency)
+- [ ] When a user is deactivated in Mattermost, the system handles cleanup appropriately
+- [ ] The plugin exposes Prometheus metrics for monitoring pipeline health, query latency, processing throughput, and error rates
+- [ ] The plugin implements resilience patterns (backoff, circuit breaker) for external API calls to the LLM provider to handle rate limits and transient failures gracefully
+
+## Constraints
+
+### Technical
+- **Mattermost plugin**: Must be a self-contained Mattermost plugin — no modifications to Mattermost core server code, no sidecar services, no external worker processes
+- **LLM provider**: Google Gemini 2.5 Flash for all LLM tasks (summarization, extraction, RAG synthesis). Single model, not tiered.
+- **Embedding provider**: Google gemini-embedding-001 at 768 dimensions. Embeddings must be L2-normalized before storage for correct cosine similarity.
+- **Gemini SDK**: Use the native Google AI Go SDK (`google.golang.org/genai`), not an OpenAI-compatible proxy
+- **Vector database**: pgvector PostgreSQL extension with HNSW cosine similarity indexing. Access via Mattermost's `GetInternalMasterDB()` which returns a raw database connection.
+- **Async processing**: Use the `pluginapi/cluster` package for all background work — `JobOnceScheduler` for thread debounce, `Schedule()` for recurring workers, `Mutex` for distributed locking across cluster nodes. Plugins cannot access Mattermost's server-level job scheduler.
+- **ID format**: All new table IDs must use Mattermost's standard ID generation — 26-character base32-encoded UUID v4 strings (VARCHAR(26)), consistent with Posts, Channels, and Users tables
+- **API routing**: All endpoints under `/plugins/org-memory/api/v1/*` via plugin ServeHTTP — no registration on Mattermost's API4 routes
+- **File extraction**: Reuse Mattermost's built-in docextractor service for PDF, document, and archive text extraction
+- **Multi-turn state**: Conversation history for follow-up queries stored in Plugin KV store (`KVSet`/`KVGet`), not a database table
+- **Webhook config storage**: Outbound webhook configurations stored in Plugin KV store (key pattern: `webhook:{channel_id}:{id}`), not a database table
+- **Chunking**: Semantic boundary splitting — split by paragraph then sentence boundaries, target ~500 tokens per chunk with 10% overlap between adjacent chunks, maximum 32 chunks per post
+
+### Database Schema
+- Seven new tables: `ai_embeddings`, `ai_extractions`, `ai_thread_summaries`, `ai_channel_summaries`, `ai_entity_mentions`, `ai_processing_log`, `ai_query_log`
+- All foreign keys to Mattermost core tables (Posts, Channels, Users) use ON DELETE CASCADE
+- Soft delete pattern (DeleteAt column) on embeddings and extractions, consistent with Mattermost conventions
+- Timestamps as BIGINT (Unix milliseconds), consistent with Mattermost conventions
+
+### Operational
+- Must function correctly in Mattermost high-availability (multi-node) deployments — distributed mutex prevents duplicate processing
+- Plugin minimum server version: 9.5.0
+- pgvector extension must be enabled on the PostgreSQL instance
+
+## Non-Goals
+
+- **Custom embedding model hosting** — we use Google's hosted embedding API, not self-hosted models
+- **Multi-provider LLM support** — this plugin is Gemini-only; no abstraction layer for swapping to OpenAI/Anthropic/etc.
+- **Rich entity timeline UI** — entity timelines are available via API; a polished UI for browsing them is deferred
+- **Webhook configuration UI** — webhook management is API-only for now; no System Console UI for configuring webhooks
+- **Advanced search filters/facets** — the initial UI provides natural language search only; date range filters, channel scoping, and result type faceting are deferred
+- **Dark mode optimization** — the minimal UI uses standard Mattermost theme tokens but does not have dedicated dark mode testing or polish
+- **Accessibility audit** — basic compliance via semantic HTML but no formal WCAG audit
+- **Real-time streaming responses** — initial implementation returns complete responses; streaming/typewriter effect is deferred
+- **Cross-workspace federation** — the plugin operates within a single Mattermost instance only
+- **Mobile app integration** — the RHS panel and custom UI components target the web/desktop client; mobile is not in scope
+- **Data export** — no bulk export of extracted knowledge to external formats
+- **Custom extraction types** — the system extracts decisions, action items, and topics; user-defined extraction categories are not supported
diff --git a/tasks/0001-org-memory-ai-knowledge-base/research.md b/tasks/0001-org-memory-ai-knowledge-base/research.md
new file mode 100644
index 000000000000..ea21f9e7f559
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/research.md
@@ -0,0 +1,201 @@
+# Research
+
+## Related Code
+
+### Plugin SDK Core
+
+- `server/public/plugin/hooks.go` — Defines the `Hooks` interface with 40+ hook methods. The plugin will implement: `OnActivate`, `OnDeactivate`, `OnConfigurationChange`, `MessageHasBeenPosted`, `MessageHasBeenUpdated`, `MessageHasBeenDeleted`, `FileWillBeUploaded`, `UserHasBeenDeactivated`, `ServeHTTP`, `ExecuteCommand`, `ServeMetrics`, `RunDataRetention`.
+- `server/public/plugin/api.go` — ~1581-line API interface with ~150 methods. Key methods for this plugin: `GetInternalMasterDB()`, `KVSet`/`KVGet`/`KVDelete`/`KVList`/`KVSetWithExpiry`, `RegisterCommand`, `GetUser`, `GetPost`, `GetPostThread`, `GetPostsSince`, `GetChannelMember`, `GetChannelMembersForUser`, `HasPermissionToChannel`, `CreatePost`, `SendEphemeralPost`, `GetConfig`, `LoadPluginConfiguration`, `LogDebug`/`LogInfo`/`LogWarn`/`LogError`, `PublishPluginClusterEvent`.
+- `server/public/plugin/client.go` — Defines `MattermostPlugin` base struct that all plugins embed. Provides `API` and `Driver` fields. Entry point is `plugin.ClientMain(&Plugin{})`.
+- `server/public/plugin/plugintest/api.go` — Mockery-generated mock for the full Plugin API interface. Used in unit tests with testify assertions.
+
+### Plugin API Helpers (pluginapi package)
+
+- `server/public/pluginapi/client.go` — `pluginapi.Client` struct wrapping the raw API into organized services: `Bot`, `Channel`, `Cluster`, `Configuration`, `SlashCommand`, `File`, `KV`, `Log`, `Post`, `Store`, `System`, `Team`, `User`. Created via `pluginapi.NewClient(api, driver)`.
+- `server/public/pluginapi/store.go` — `StoreService` with `GetMasterDB()` and `GetReplicaDB()` returning `*sql.DB`. Uses `driver.NewConnector()` to establish connections through the plugin RPC bridge. Also provides `DriverName()` and `Close()`. The plugin imports `_ "github.com/lib/pq"` for PostgreSQL driver registration.
+- `server/public/pluginapi/kv.go` — Enhanced KV store wrapper with `Set(key, value, ...options)`, `Get(key, &dest)` (auto-unmarshal), `Delete`, `ListKeys` (with prefix filtering via `WithPrefix`), and `SetAtomicWithRetries` for optimistic locking. `KVSetOption` includes `SetAtomic(oldValue)` and `SetExpiry(ttl)`.
+
+### Cluster Scheduling (pluginapi/cluster package)
+
+- `server/public/pluginapi/cluster/job_once_scheduler.go` — `JobOnceScheduler` for one-time scheduled jobs. Singleton via `GetJobOnceScheduler(pluginAPI)`. Methods: `SetCallback(func(key string, props any))`, `Start()`, `ScheduleOnce(key, runAt, props)`, `Cancel(key)`, `ListScheduledJobs()`. Props must be JSON-serializable, max 10KB. Jobs persist in KV store with prefix `once_`. Polls DB every 5 minutes for new jobs. Max 3 failures before auto-cancel. Only one cluster node executes a given job.
+- `server/public/pluginapi/cluster/job.go` — `Schedule(pluginAPI, key, nextWaitInterval, callback)` for recurring jobs. Returns `*Job` with `Close()` method. Uses KV store with prefix `cron_` to track last execution time. `MakeWaitForInterval(duration)` for fixed intervals. `MakeWaitForRoundedInterval(duration)` for boundary-aligned intervals (e.g., top of the hour). Only one cluster instance runs the callback at a time.
+- `server/public/pluginapi/cluster/mutex.go` — `NewMutex(pluginAPI, key)` for distributed locking. `Lock()` blocks with exponential backoff (1s to 5min, ±500ms jitter). `LockWithContext(ctx)` supports cancellation. `Unlock()` releases. TTL is 15 seconds, auto-refreshed every 7.5 seconds while held. Uses KV store with prefix `mutex_`.
+
+### Document Extraction
+
+- `server/platform/services/docextractor/interface.go` — `Extractor` interface: `Match(filename string) bool`, `Extract(filename string, file io.ReadSeeker, maxFileSize int64) (string, error)`, `Name() string`.
+- `server/platform/services/docextractor/docextractor.go` — Main entry points: `Extract(logger, filename, reader, settings)` and `ExtractWithExtraExtractors(...)`. Chains extractors in priority order: custom → documentExtractor → pdfExtractor → archiveExtractor → mmPreviewExtractor → plainExtractor (fallback).
+- `server/platform/services/docextractor/pdf.go` — PDF extraction via `github.com/ledongthuc/pdf`. Has panic recovery for malicious PDFs.
+- `server/platform/services/docextractor/documents.go` — Office docs (.doc, .docx, .pptx, .odt, .html, .rtf) via `code.sajari.com/docconv/v2`. Has panic recovery.
+- `server/platform/services/docextractor/plain.go` — Fallback text extractor. Validates first 1024 bytes are UTF-8 text. Match always returns true.
+- `server/platform/services/docextractor/archive.go` — Archive extraction (.zip, .rar, .tar.gz, etc.) via `github.com/mholt/archives`. Supports recursive extraction. Has zip bomb protection via `MaxFileSize`.
+- `server/channels/app/file.go` — `ExtractContentFromFileInfo()` orchestrates extraction. Runs in buffered goroutine. Truncates output to 1MB. Saves to `FileInfo.Content` field. Controlled by `FileSettings.ExtractContent` config flag.
+
+### pgvector Infrastructure
+
+- `server/docker-compose.pgvector.yml` — Docker Compose override replacing standard postgres image with `pgvector/pgvector:pg13`. Activated by `MM_USE_PGVECTOR=true`.
+- `server/Makefile` (lines 233-237, 258-260, 597-607, 663-664, 696-697) — Makefile targets: `run-server-pgvector`, `run-pgvector`, `restart-server-pgvector`. Sets `DOCKER_COMPOSE_OVERRIDE` when `MM_USE_PGVECTOR=true`.
+- No existing `CREATE EXTENSION vector` or vector column definitions found in Mattermost core migrations — pgvector is prepared infrastructure but not used by the core server. The plugin must issue `CREATE EXTENSION IF NOT EXISTS vector` itself.
+
+### Database Patterns
+
+- `server/channels/store/sqlstore/store.go` — `SqlStore` with `getQueryBuilder()` returning `sq.StatementBuilderType` configured with `sq.Dollar` placeholder format (PostgreSQL $1, $2). `GetMaster()` returns write connection, `GetReplica()` returns read connection with round-robin load balancing.
+- `server/channels/store/sqlstore/bot_store.go` — Reference Squirrel pattern. Pre-builds base select queries in constructor. Uses `getQueryBuilder().Select(...).From(...).Join(...).Where(...).ToSql()`. Writes use `GetMaster().NamedExec()` or `GetMaster().Exec()`. Reads use `GetReplica().Get()` or `GetReplica().Select()`. Errors: `sql.ErrNoRows` → `store.NewErrNotFound()`.
+- `server/channels/db/migrations/postgres/` — 88+ numbered migration files (e.g., `000020_create_posts.up.sql`). Pattern: `CREATE TABLE IF NOT EXISTS`, `ALTER TABLE ... ADD COLUMN IF NOT EXISTS`, conditional type changes via `DO $$ ... $$` PL/pgSQL blocks. Indexes: `CREATE INDEX IF NOT EXISTS`. Full-text: `USING gin(to_tsvector('english', ...))`.
+- `server/public/model/utils.go` — `NewId()` generates 26-char IDs using custom base32 encoding (`ybndrfg8ejkmcpqxot1uwisza345h769`) of UUID v4. `IsValidId()` checks length=26 and alphanumeric.
+
+### Plugin Database Access
+
+- `server/channels/app/plugin_db_driver.go` — `DriverImpl` wraps database access for plugins. Manages connection pool with `connMap`, transaction tracking with `txMap`, and statement tracking with `stMap`. `ShutdownConns(pluginID)` cleans up all connections when plugin deactivates. Connections are created per-request with query timeout from `SqlSettings.QueryTimeout`.
+
+### Webapp Plugin SDK
+
+- `webapp/channels/src/plugins/registry.ts` — ~1450-line `PluginRegistry` class. Key registration methods: `registerRightHandSidebarComponent({component, title})` returns `{id, showRHSPlugin, hideRHSPlugin, toggleRHSPlugin}`. Also: `registerAppBarComponent()` (icon in app bar that can toggle RHS), `registerChannelHeaderButtonAction()`, `registerPostTypeComponent()`, `registerSlashCommandWillBePostedHook()`, `registerWebSocketEventHandler()`, `registerReconnectHandler()`, `registerReducer()`, `registerCustomRoute()`.
+- `webapp/channels/src/plugins/index.ts` — Plugin loading: `window.registerPlugin(id, plugin)` exposed globally. Each plugin's bundle loaded as `<script>` tag. `initialize(registry, store)` called after load. `Client4` available for API calls.
+- `webapp/channels/src/plugins/rhs_plugin/rhs_plugin.tsx` — Main RHS panel renderer. Uses `<SearchResultsHeader>` for title bar, then `<Pluggable pluggableName='RightHandSidebarComponent' pluggableId={id} />` to render the registered component.
+- `webapp/channels/src/plugins/pluggable/pluggable.tsx` — Universal component renderer. Looks up components from Redux state (`state.plugins.components[pluggableName]`), wraps each in `<PluggableErrorBoundary>`, passes `theme` and `webSocketClient` as props.
+- `webapp/channels/src/actions/views/rhs.ts` — Redux actions: `showRHSPlugin(pluggableId)` dispatches `UPDATE_RHS_STATE` with `state: RHSStates.PLUGIN`.
+- `webapp/channels/src/selectors/rhs.ts` — Selectors: `getPluggableId(state)`, `getRhsState(state)`. `RHSStates.PLUGIN = 'plugin'`.
+
+### Existing org-memory Plugin Artifacts
+
+- `server/plugins/org-memory/plugin.json` — Existing manifest (v0.1.0, min_server_version 9.5.0). References OpenAI defaults: LLMBaseURL=`https://api.openai.com/v1`, LLMModel=`gpt-4o-mini`, EmbeddingModel=`text-embedding-3-small`, EmbeddingDimensions=1536. These settings need complete replacement for Gemini.
+- `server/plugins/org-memory/webapp/dist/main.js` — Compiled webapp bundle. Registers via `window.registerPlugin("org-memory", ...)`. Uses `registerRootComponent` (not RHS) for a floating button + modal dialog. Makes API calls to `/plugins/org-memory/api/v1/query`.
+- `server/plugins/org-memory/server/dist/` — Compiled server binaries for darwin-amd64, darwin-arm64, linux-amd64. Source code has been deleted.
+
+### GitHub Plugin (Reference Pattern)
+
+- `server/plugins/github/plugin.json` — Well-structured manifest showing best practices: `server.executables` for 5 platforms, `webapp.bundle_path`, rich `settings_schema` with text, bool, dropdown, generated types. Version 2.6.0, min_server_version 10.7.0.
+- `server/plugins/github/` — Directory structure: `assets/` (SVG icons), `server/dist/` (compiled binaries), `webapp/dist/` (compiled JS bundle), `plugin.json`. This is the distribution format — plugins are distributed as `.tar.gz` archives.
+
+## Reuse Opportunities
+
+### pluginapi.Client
+The `pluginapi.Client` wraps the raw plugin API into organized services. The plugin should create a `pluginapi.NewClient(p.API, p.Driver)` in `OnActivate` and use it throughout. Specifically:
+- `client.Store.GetMasterDB()` for database access (cleaner than raw `p.API.GetInternalMasterDB()`)
+- `client.KV.Set/Get/ListKeys` with automatic JSON marshaling and prefix-based listing
+- `client.Post.CreatePost/SendEphemeralPost` for bot responses
+- `client.Log.Info/Error/Debug` for structured logging
+- `client.Configuration.LoadPluginConfiguration` for settings
+
+### pluginapi/cluster Package
+Complete distributed coordination library ready to use:
+- `GetJobOnceScheduler()` for thread debounce (cancel+reschedule pattern)
+- `Schedule()` with `MakeWaitForInterval(1*time.Second)` for the embedding/extraction worker loop
+- `Schedule()` with `MakeWaitForRoundedInterval(24*time.Hour)` for daily summary generation
+- `NewMutex()` for per-PostId processing deduplication
+
+### docextractor Service
+Mattermost already extracts text from uploaded files and stores it in `FileInfo.Content`. The plugin can access this via the Plugin API's `GetFileInfo(fileId)` rather than re-extracting. For files where Content is empty (extraction disabled or failed), the plugin could use `GetFile(fileId)` to get raw bytes and extract independently, but the built-in extraction covers the common cases (PDF, Office docs, plain text, archives).
+
+### Plugin Mock API (plugintest)
+`server/public/plugin/plugintest/api.go` provides Mockery-generated mocks for the entire Plugin API. Tests can use `plugintest.API` with testify's `.On()` and `.Return()` for isolated unit testing of all plugin logic without a running Mattermost server.
+
+### model.NewId()
+Available at `github.com/mattermost/mattermost/server/public/model` — generates IDs consistent with all Mattermost core tables. No need to implement custom ID generation.
+
+### Squirrel Query Builder
+Available at `github.com/mattermost/squirrel` — already a dependency of the Mattermost server. Provides type-safe SQL construction with PostgreSQL dollar-sign placeholders. The plugin should use this for building queries against its custom tables.
+
+### pgvector Docker Infrastructure
+`docker-compose.pgvector.yml` and Makefile targets (`run-pgvector`, `run-server-pgvector`) already exist. Development environment setup for pgvector is a one-command change (`MM_USE_PGVECTOR=true make run`).
+
+## Patterns and Conventions
+
+### Plugin Lifecycle Pattern
+1. `OnActivate()` — initialize everything: load config, create `pluginapi.Client`, get DB handle, run migrations, start schedulers, register slash commands
+2. `OnConfigurationChange()` — reload config into a struct via `API.LoadPluginConfiguration(&config)`, validate, and reconfigure components
+3. `OnDeactivate()` — stop all schedulers (`job.Close()`), close DB connections (`client.Store.Close()`), clean up resources
+4. Plugin runs as a **separate OS process** communicating via net/rpc (not gRPC). Crash isolation is built-in.
+
+### Database Access Pattern
+- Plugins get `*sql.DB` via `pluginapi.Client.Store.GetMasterDB()` (or `GetReplicaDB()` for reads)
+- Plugins must manage their own schema — there is no plugin migration framework. Schema creation happens in `OnActivate()` via raw SQL `CREATE TABLE IF NOT EXISTS`
+- Mattermost core uses Squirrel for query building, but plugins can use raw SQL or Squirrel independently
+- The `lib/pq` PostgreSQL driver is imported by the pluginapi store package
+- Query timeout is enforced at the connection level via `SqlSettings.QueryTimeout`
+- Plugin connections are tracked and auto-cleaned on deactivation via `DriverImpl.ShutdownConns(pluginID)`
+
+### ID Generation
+- All IDs are VARCHAR(26), generated by `model.NewId()` (base32-encoded UUID v4)
+- Validation: `model.IsValidId()` checks length=26 and alphanumeric
+- Used consistently across Posts.Id, Channels.Id, Users.Id — custom tables must match
+
+### Timestamp Convention
+- All timestamps are `BIGINT` storing Unix milliseconds (not seconds, not `TIMESTAMP`)
+- Soft delete: `DeleteAt BIGINT DEFAULT 0`, where 0 means active and non-zero means deleted
+- Common columns: `CreateAt`, `UpdateAt`, `DeleteAt`
+
+### KV Store Key Patterns
+- Plugin KV keys are namespaced per plugin automatically by Mattermost
+- Keys prefixed with `mmi_` are reserved for system use
+- Cluster package uses prefixes: `mutex_`, `cron_`, `once_`
+- KV values are `[]byte` — the `pluginapi.KV.Set/Get` wrapper handles JSON marshal/unmarshal
+
+### Webapp Plugin Pattern
+- Plugins register via `window.registerPlugin(pluginId, {initialize, uninitialize})`
+- `initialize(registry, store)` receives a `PluginRegistry` instance and the Redux store
+- RHS panels: `registry.registerRightHandSidebarComponent({component, title})` returns show/hide/toggle actions
+- App bar integration: `registry.registerAppBarComponent({iconUrl, rhsComponent, rhsTitle})` creates an icon that toggles the RHS
+- Components receive `theme` (current Mattermost theme) and `webSocketClient` as props
+- Custom WebSocket events: `registry.registerWebSocketEventHandler({event, handler})` for `custom_{pluginid}_{eventname}` events
+- Custom post types must be prefixed with `custom_`
+- Plugin reducers stored at `state['plugins-{pluginid}']`
+- API calls to plugin backend: `fetch('/plugins/{pluginid}/api/v1/...')`
+
+### HTTP Routing Pattern
+- All requests to `/plugins/{pluginid}/...` are routed to the plugin's `ServeHTTP` hook
+- The plugin is responsible for its own path routing (typically using a mux or manual path matching)
+- The org-memory plugin uses `/plugins/org-memory/api/v1/query` as its primary endpoint
+
+### Slash Command Pattern
+- Register in `OnActivate()`: `API.RegisterCommand(&model.Command{Trigger: "ask", ...})`
+- Handle in `ExecuteCommand()`: parse `args.Command`, return `*model.CommandResponse{Text: "..."}` or use `SendEphemeralPost` for private responses
+- `args` provides `ChannelId`, `UserId`, `TeamId`, `RootId`, `Command` (full text)
+
+### Error Handling
+- Plugin API returns `*model.AppError` (nil on success)
+- Store layer: `sql.ErrNoRows` → `store.NewErrNotFound(entity, id)`
+- Wrapping: `errors.Wrap(err, "context message")` or `errors.Wrapf(err, "context %s", id)`
+- Hook return values: non-empty string from `MessageWillBePosted` rejects the message
+
+### Permission Checking
+- `API.HasPermissionToChannel(userID, channelId, permission)` — checks channel-level permission
+- `API.GetChannelMember(channelId, userID)` — returns member info or error if not a member
+- `API.GetChannelMembersForUser(teamID, userID, page, perPage)` — lists all channel memberships for a user on a team (paginated)
+- For RAG permission filtering, the plugin needs to get a user's channel list and only return results from those channels
+
+## Risks and Concerns
+
+### pgvector Extension Installation
+Mattermost core does not install or use the pgvector extension. The plugin must execute `CREATE EXTENSION IF NOT EXISTS vector` on activation, which requires the PostgreSQL user to have superuser or `CREATE` privileges on the database. In managed PostgreSQL services (RDS, Cloud SQL), this may require pre-provisioning the extension. The docker-compose override provides a pgvector-capable image, but the extension still needs explicit creation.
+
+### Plugin Process Isolation and Performance
+Plugins run as separate OS processes communicating via net/rpc. Every Plugin API call (GetPost, GetChannelMember, KVSet, etc.) crosses a process boundary. For high-throughput operations like permission checking across hundreds of channels, the RPC overhead could be significant. Batch operations (e.g., getting all channel memberships at once via `GetChannelMembersForUser`) should be preferred over individual `GetChannelMember` calls.
+
+### No Plugin Migration Framework
+Unlike Mattermost core (which uses numbered migration files with morph), plugins have no built-in migration system. Schema changes in `OnActivate()` using `CREATE TABLE IF NOT EXISTS` work for initial creation, but evolving the schema (adding columns, changing types) requires manual idempotent migration logic. A common pattern is to check column existence before ALTER TABLE.
+
+### KV Store Size Limits
+Plugin KV store values have a maximum size (typically 256KB per key). Conversation history for multi-turn RAG sessions must be kept compact. Long conversation histories will need truncation or summarization to stay within limits.
+
+### GetChannelMembersForUser Requires TeamID
+The `GetChannelMembersForUser(teamID, userID, page, perPage)` API requires a team ID parameter. For workspaces with multiple teams, the plugin must iterate over teams to get a user's complete channel list. This adds complexity to permission filtering.
+
+### pgvector pg13 Image Version
+The docker-compose override uses `pgvector/pgvector:pg13` (PostgreSQL 13). However, `server/channels/store/sqlstore/store.go` sets `minimumRequiredPostgresVersion = 140000` (PostgreSQL 14). This is a version mismatch — the pgvector image should be upgraded to at least pg14 to match the server's minimum requirement.
+
+### Worker Scheduling Coordination
+The `JobOnceScheduler` is a singleton — `GetJobOnceScheduler()` returns the same instance on repeated calls. The plugin must set a single callback function that dispatches to different handlers based on the job key. For example, thread debounce jobs and backfill jobs would both go through the same callback and need to be distinguished by key prefix or props.
+
+### Data Retention Hook
+The `RunDataRetention(nowTime, batchSize int64) (int64, error)` hook is called during Mattermost's data retention jobs. The plugin should implement this to clean up aged-out knowledge base entries. However, this hook runs synchronously in the retention job — long-running cleanup could block the retention pipeline.
+
+### File Content Access
+`ExtractContentFromFileInfo()` stores extracted text in `FileInfo.Content`, but this field may not be exposed through the Plugin API's `GetFileInfo()`. The plugin may need to use `GetFile(fileId)` to get raw bytes and run its own extraction. This needs verification during implementation.
+
+### Webapp Bundle Distribution
+The existing org-memory webapp uses `registerRootComponent` (floating button + modal) rather than the proper `registerRightHandSidebarComponent` for RHS integration. The new implementation should use the RHS pattern for a native Mattermost feel, plus `registerAppBarComponent` for the entry point icon.
+
+### Gemini SDK Go Module
+The `google.golang.org/genai` Go SDK is an external dependency that needs to be added to the plugin's `go.mod`. Since the plugin is compiled separately from Mattermost core, dependency management is independent. The SDK's version compatibility and transitive dependencies should be verified.
diff --git a/tasks/0001-org-memory-ai-knowledge-base/testing.md b/tasks/0001-org-memory-ai-knowledge-base/testing.md
new file mode 100644
index 000000000000..4738a1a9ec4a
--- /dev/null
+++ b/tasks/0001-org-memory-ai-knowledge-base/testing.md
@@ -0,0 +1,223 @@
+# Testing Plan
+
+## Unit Tests
+
+### Plugin Lifecycle
+
+- [ ] Plugin activates successfully when configuration is valid and pgvector extension is available
+- [ ] Plugin activation fails with a descriptive error when the pgvector extension cannot be created
+- [ ] Plugin activation fails with a descriptive error when the Gemini API key is missing or empty
+- [ ] Plugin deactivation shuts down all background schedulers and releases database connections without errors
+- [ ] Configuration changes are picked up without restarting the plugin — updated Gemini model name and debounce seconds take effect on the next processing cycle
+
+### Event Ingestion
+
+- [ ] When a non-bot user posts a message in an enabled team, a "pending" entry is created in the processing log
+- [ ] When a bot posts a message and SkipBotPosts is true, no processing log entry is created
+- [ ] When a message is posted in a team that is not in the EnableForTeams list, no processing log entry is created
+- [ ] When EnableForTeams is empty, messages from all teams are processed
+- [ ] When a message is posted in a thread, a debounce job is scheduled for the thread's root ID at now + ThreadDebounceSeconds
+- [ ] When a second message is posted in the same thread before the debounce fires, the old debounce job is canceled and a new one is scheduled with a fresh future time
+- [ ] When a message is edited, new "pending" processing log entries are created for re-embedding and re-extraction
+- [ ] When a message is deleted, all associated embeddings, extractions, and entity mentions are removed from the database
+- [ ] When a message is deleted, any pending debounce job for its thread is canceled
+- [ ] When a user is deactivated, their multi-turn conversation sessions are removed from the KV store
+- [ ] When a user is deactivated, no knowledge base content (embeddings, extractions, summaries) is deleted
+
+### Chunking Engine
+
+- [ ] A short message (under ~500 tokens) produces a single chunk with chunk index 0
+- [ ] A message with multiple paragraphs separated by double newlines is split at paragraph boundaries
+- [ ] A single long paragraph exceeding ~500 tokens is split at sentence boundaries
+- [ ] Consecutive small paragraphs are merged into a single chunk until approaching the target size
+- [ ] Adjacent chunks have approximately 10% overlap — the end of one chunk appears at the start of the next
+- [ ] A message producing more than MaxChunksPerPost chunks is truncated to the maximum number
+- [ ] An empty or whitespace-only message produces zero chunks
+- [ ] Chunk indices are sequential starting from 0
+
+### Gemini Integration
+
+- [ ] Embedding generation returns a 768-dimensional vector
+- [ ] Embedding vectors are L2-normalized (vector magnitude equals 1.0 within floating-point tolerance)
+- [ ] Knowledge extraction returns typed items: decisions, action items, and topics
+- [ ] RAG synthesis returns an answer with citation references that map to provided context passages
+- [ ] RAG synthesis returns an "insufficient information" response when no relevant context is provided
+- [ ] When the Gemini API returns HTTP 429, the client applies exponential backoff starting at 1 second
+- [ ] When the Gemini API returns 5 consecutive errors, the circuit breaker opens and subsequent calls fail immediately without making API requests
+- [ ] When the circuit breaker is open, it transitions to half-open after 30 seconds
+- [ ] When a half-open test request succeeds, the circuit breaker closes and normal operation resumes
+- [ ] Circuit breaker state is stored in the KV store and shared across cluster nodes
+
+### Background Processing Workers
+
+- [ ] The embedding/extraction worker picks up items with "pending" status from the processing log
+- [ ] The worker acquires a distributed mutex before processing a post and releases it after completion
+- [ ] On successful processing, the worker updates the processing log status to "complete"
+- [ ] On processing failure, the worker increments the retry count, records the error message, and returns the item to "pending" status
+- [ ] After 3 consecutive failures on the same item, the worker marks it as "error" permanently
+- [ ] Items stuck in "processing" status for more than 5 minutes are returned to "pending" (stale detection)
+- [ ] Processing the same post ID + job type combination twice does not create duplicate results (idempotency)
+
+### Thread Debounce Handler
+
+- [ ] When a debounce job fires, all posts in the thread are fetched and sent to Gemini for summarization
+- [ ] The thread summary is stored in the ai_thread_summaries table keyed by root post ID
+- [ ] Key takeaways from the summary are stored as a JSON array
+- [ ] Individual post embeddings that haven't been processed yet get new processing log entries created
+- [ ] The singleton scheduler callback correctly dispatches debounce jobs (prefix "debounce:") vs backfill jobs (prefix "backfill:")
+
+### Summary Generation
+
+- [ ] The daily summary worker generates summaries only for channels with activity since the last summary window
+- [ ] The weekly summary worker aggregates from daily summaries rather than raw posts
+- [ ] Duplicate summaries for the same channel, type, and window are prevented by the unique constraint
+- [ ] Channels with no activity since the last window are skipped
+
+### Knowledge Store
+
+- [ ] All table creation statements are idempotent — running them twice produces no errors
+- [ ] IDs generated for new rows are 26-character alphanumeric strings consistent with Mattermost conventions
+- [ ] Soft-deleted embeddings (DeleteAt > 0) are excluded from vector similarity searches
+- [ ] Soft-deleted extractions (DeleteAt > 0) are excluded from extraction listings
+- [ ] Deleting a post in the Posts table cascades to delete related rows in ai_embeddings, ai_extractions, and ai_entity_mentions
+- [ ] Entity names are normalized to lowercase on storage for consistent matching
+- [ ] The processing log prevents duplicate entries for the same post ID + job type combination
+- [ ] Timestamps are stored as BIGINT Unix milliseconds
+
+### RAG Query Engine
+
+- [ ] A query returns results only from channels where the requesting user is a member
+- [ ] A query returns no results from channels where the user is not a member, even if relevant embeddings exist
+- [ ] Permission lookups are cached in the KV store — a second query within 60 seconds does not re-fetch channel memberships
+- [ ] The permission cache is built correctly for users belonging to multiple teams
+- [ ] Citation references in the synthesized answer map to valid post permalinks
+- [ ] The query log records the user ID, query text, channels searched, result count, and latency for every query
+
+### Multi-turn Conversation
+
+- [ ] A follow-up query loads previous conversation history from the KV store and includes it in the Gemini context
+- [ ] Conversation sessions expire from the KV store after 30 minutes of inactivity
+- [ ] When conversation history approaches the KV store size limit, older exchanges are truncated while keeping the most recent ones
+- [ ] A new session ID produces an empty conversation history
+
+### Extraction Editing
+
+- [ ] Editing an extraction updates its content text and marks it as edited with the editor's user ID
+- [ ] Editing an extraction triggers re-embedding — old embeddings for that extraction are replaced with new ones reflecting the updated content
+- [ ] Editing an extraction updates the UpdateAt timestamp
+
+### Data Retention
+
+- [ ] The RunDataRetention hook deletes embeddings, extractions, entity mentions, and summaries whose source posts fall within the retention window
+- [ ] The hook processes up to the provided batch size and returns the count of deleted rows
+- [ ] The hook is called repeatedly by Mattermost until it returns 0 (all aged-out data cleaned)
+
+### Outbound Webhooks
+
+- [ ] When a decision is extracted and a webhook is configured for that channel with "decision" type, an HTTP POST is sent to the webhook URL
+- [ ] When an action item is extracted and a webhook is configured for that channel with "action_item" type, an HTTP POST is sent to the webhook URL
+- [ ] The webhook payload includes the extraction content, source channel ID, source post permalink, and extraction type
+- [ ] When a webhook secret is configured, the request includes an HMAC signature header
+- [ ] Failed webhook deliveries are retried up to 3 times with exponential backoff
+- [ ] After 3 failed retries, the delivery is logged as failed and does not block the processing pipeline
+
+### Webhook Configuration (KV Store)
+
+- [ ] Creating a webhook configuration stores it in the KV store with the correct key pattern
+- [ ] Listing webhooks returns all configurations for the requesting admin
+- [ ] Deleting a webhook removes it from the KV store
+- [ ] Non-admin users cannot create, list, or delete webhook configurations
+
+## Integration Tests
+
+These tests require a running PostgreSQL instance with pgvector extension.
+
+### Schema and Database
+
+- [ ] Plugin activation creates all 7 tables and the pgvector extension on a fresh database
+- [ ] Plugin activation on a database that already has the tables succeeds without errors (idempotent)
+- [ ] Inserting a 768-dimensional vector into ai_embeddings and querying it via cosine similarity returns the expected result
+- [ ] HNSW index is used by the query planner for vector similarity searches (verify via EXPLAIN)
+- [ ] Foreign key cascade: deleting a row from the Posts table cascades to delete all related rows in ai_embeddings, ai_extractions, ai_entity_mentions
+
+### End-to-End Processing Pipeline
+
+- [ ] A post is created → processing log entry appears → worker processes it → embedding and extractions are stored in the database
+- [ ] A thread with multiple posts goes quiet → debounce fires → thread summary is generated and stored
+- [ ] A post is edited → old embeddings are replaced → new embeddings reflect updated content
+- [ ] A post is deleted → all derived data (embeddings, extractions, entity mentions) is cleaned up
+
+### RAG Query Pipeline
+
+- [ ] A user submits a query → query is embedded → vector search returns relevant results filtered by user's channel permissions → Gemini synthesizes an answer → response includes citation links to source posts
+- [ ] A user submits a follow-up query → previous conversation history is loaded from KV store → context-aware answer is returned
+- [ ] A user queries about content in a channel they don't belong to → no results from that channel appear in the response
+
+### API Endpoints
+
+- [ ] POST /query with a valid session and query text returns a successful response with answer and citations
+- [ ] POST /query without authentication returns 401
+- [ ] POST /query with empty query text returns 400
+- [ ] POST /query/followup with a valid session ID returns a context-aware response
+- [ ] GET /threads/{root_id}/summary returns the summary when the user has access to the channel
+- [ ] GET /threads/{root_id}/summary returns 403 when the user does not have access to the channel
+- [ ] GET /channels/{channel_id}/summary?type=daily returns the most recent daily summary
+- [ ] GET /channels/{channel_id}/summary returns 403 when the user does not have access to the channel
+- [ ] GET /entities/{name}/timeline returns mentions only from channels the user can access
+- [ ] GET /extractions?channel_id=X&type=decision returns filtered results for an accessible channel
+- [ ] GET /extractions returns 403 when the user does not have access to the specified channel
+- [ ] PUT /extractions/{id} updates the content and triggers re-embedding
+- [ ] PUT /extractions/{id} returns 404 for a non-existent extraction
+- [ ] POST /admin/backfill returns 403 for non-admin users
+- [ ] POST /admin/backfill starts a backfill job and returns a success status for admin users
+- [ ] GET /admin/status returns processing queue depth, error counts, and worker health
+- [ ] POST /webhooks creates a webhook configuration for admin users
+- [ ] POST /webhooks returns 403 for non-admin users
+- [ ] GET /webhooks returns all webhook configurations for admin users
+- [ ] DELETE /webhooks/{id} removes the configuration and returns success
+
+### Slash Command
+
+- [ ] Executing `/ask what decisions were made about X` returns an ephemeral post with a synthesized answer and citations
+- [ ] Executing `/ask` with no query text returns an ephemeral post with usage instructions
+- [ ] The `/ask` command results respect the invoking user's channel permissions
+
+### Resilience
+
+- [ ] When the Gemini API is unavailable, processing items remain in "pending" status and are retried after the circuit breaker resets
+- [ ] When a worker crashes mid-processing, the distributed mutex expires and another node picks up the item
+- [ ] Historical backfill can be stopped and resumed — progress is tracked in the processing log and the backfill continues from where it left off
+
+## Browser/E2E Tests
+
+### RHS Panel
+
+- [ ] Clicking the org-memory icon in the app bar opens the RHS panel with the "Ask your workspace" interface
+- [ ] Clicking the icon again closes the RHS panel
+- [ ] Typing a query in the input field and pressing Enter submits the query
+- [ ] While the query is processing, a loading indicator is displayed
+- [ ] After the query completes, the synthesized answer is rendered as formatted markdown in the response area
+- [ ] Citation links in the response are clickable and navigate to the original post
+- [ ] After receiving a response, a follow-up input field appears below it
+- [ ] Submitting a follow-up query shows a context-aware response that references the previous exchange
+- [ ] Submitting an empty query does nothing (no API call, no error)
+
+### Thread Summary Display
+
+- [ ] When viewing a thread that has been summarized, the thread summary and key takeaways are visible in the thread panel
+- [ ] Extracted decisions and action items are displayed below the summary
+- [ ] Threads without a summary do not show the summary panel
+
+### Slash Command
+
+- [ ] Typing `/ask what was decided about the API?` in the message input and pressing Enter shows an ephemeral response in the channel
+- [ ] The ephemeral response contains a synthesized answer with citation links
+- [ ] Citation links in the ephemeral response are clickable and navigate to the original post
+
+### WebSocket Updates
+
+- [ ] When a thread summary becomes available for a thread the user is viewing, a visual indicator appears without the user refreshing the page
+
+## Manual Testing
+
+**None** — all verification must be automated.