Current Context Actively implementing the Signet memory pipeline (Phase D) - focusing on explicit mutation APIs and end-to-end testing with concurrent sessions. The daemon's memory system is transitioning from shadow writes to controlled writes with proper safety gates. Active Projects Signet Memory Pipeline - Phase D Location: `packages/daemon/src/transactions.ts`, `packages/daemon/src/daemon.ts`, `docs/wip/memory-pipeline-plan.md` - Status: Just completed D1 (mutation APIs), ready to start D2 (optimistic concurrency + policy guards) - Next steps: Implement D2/D3 from spec section 14.5-14.8, add full integration tests - Current state: Handlers and transaction closures for `PATCH /api/memory/:id`, `DELETE /api/memory/:id`, `POST /api/memory/forget`, `POST /api/memory/modify` are in place. Need to add optimistic concurrency and policy validation. UI Development Location: Any frontend component work - Status: In progress - Critical rule: Never delegate UI work to subagents. Must be done directly by Opus, passing same image references provided by user. (See: [fact]) Qwen3-14B Model Setup Location: Ollama / local model - Status: Just configured with custom Modelfile for high-reasoning work - Next steps: Integration with daemon or other services Recent Work Feb 21, 2026: - Completed Phase C of memory pipeline - dual-mode worker (shadow vs controlled-write), minFactConfidenceForWrite config, extended decision outputs with fact context - Implemented D1 mutation APIs with thin Hono handlers calling pure DB transaction closures - Validated txIngestEnvelope writes all v2 memory columns (normalized_content, is_deleted, extraction_status, embedding_model, extraction_model) - Set up Ollama model `teichai-qwen3-14b` for local inference Key decisions: - Keep mutation logic in pure DB transaction closures (`txModifyMemory`, `txForgetMemory`, etc.) - handlers are thin validators - Transaction boundaries must be respected - no provider calls in transaction closures - Use normalized/hash-derived content for consistent embeddings - Maintain audit trail via `reason` and `if_version` fields Problems solved: - Fixed v2 column population in txIngestEnvelope - both daemon remember path and pipeline derived-memory path now populate metadata correctly - Established safety gates pattern with `applyPhaseCWrites` pure DB closure Technical Notes Codebase: - Go/TypeScript daemon with SQLite database - Transaction system: `transactions.ts` contains closures like `txIngestEnvelope`, `txApplyDecision`, `txModifyMemory` - Hono for HTTP routing with thin handlers delegating to transaction closures Database Schema: - Memory table has v2 columns: `normalized_content`, `is_deleted`, `extraction_status`, `embedding_model`, `extraction_model` - IngestEnvelope struct has optional fields for different metadata sources - Concurrency via `if_version` field and optimistic locking Models: - Qwen3-14B-Claude-4.5-Opus-High-Reasoning-Distill (Q8_0 quant, 15.7GB) via Ollama - Custom Modelfile with system prompt and tool definitions Testing: - Integration tests for mutation APIs, audit trail, and recovery semantics needed - End-to-end pipeline validation completed for Phase C Rules & Warnings - UI Work Rule: Never delegate UI/frontend work to subagents. Must be handled directly by the current model (Opus) passing identical image references as provided by user. This is critical for maintaining context and fidelity. - Architecture: Keep transaction closures pure (no async, no provider calls). Handlers validate and call closures. - Phase Order: Follow spec order - D1 (mutation APIs) → D2 (concurrency/policy) → D3 (integration tests). - Safety Gates: minFactConfidenceForWrite must be respected in all write paths. - Content Normalization: Use normalized/hash-derived content for consistent embeddings across different sources. - Audit Trail: Always include `reason` and `if_version` fields in mutation operations.