Two primitives power everything:
Commands.execute()for request/response andEvents.subscribe()/emit()for publish/subscribe. Daemons orchestrate. Rust workers handle heavy compute. The entity system stores data. Generators encode patterns. Logging observes it all. This is the machinery that makes Continuum run.
Status: Core infrastructure operational. 15+ daemons, Rust worker IPC, multi-database handles, entity system, generator pipeline all proven.
| Document | Summary |
|---|---|
| AI-PROVIDER-WORKER-ARCHITECTURE | Core architecture for AI provider workers: routing, model selection, provider abstraction |
| AI-PROVIDER-MIGRATION | Migration plan for AI provider refactoring and consolidation |
| AI-PROVIDER-TESTING-STRATEGY | Testing approach for AI providers: mocking, integration, provider-specific edge cases |
| AI-INFRASTRUCTURE-DASHBOARD | Observability dashboard for AI infrastructure: latency, token usage, error rates |
| AI-ADAPTER-ARCHITECTURE-REFACTOR | Refactoring AI adapters to clean interface-driven design |
| OLLAMA-WORKER-ARCHITECTURE | (LEGACY) Ollama-era worker design: local model management, GPU sharing. Now Candle-based. |
| OLLAMA-QUEUE-COORDINATION | (LEGACY) Ollama-era queue coordination. Now Candle-based inference queue. |
| AI-REPORTED-TOOL-ISSUES | Catalog of tool-calling issues reported by AI personas during operation |
| AI-TOOL-CALLING-TROUBLESHOOTING | Troubleshooting guide for AI tool-calling failures: parsing, timeouts, schema mismatches |
| Document | Summary |
|---|---|
| DAEMON-CONCURRENCY-PATTERN | Core concurrency pattern for daemons: async initialization, lifecycle management |
| DAEMON-CONCURRENCY-AUDIT | Audit of concurrency issues across all daemons: race conditions, deadlocks, fixes |
| DAEMON-RESPONSIBILITIES | Responsibility matrix for all daemons: what each owns, separation of concerns |
| DAEMON-BASE-CLASS-EXTRACTION | Extracting shared daemon behavior into BaseDaemon base class |
| DAEMON-LOGGING-STANDARDIZATION | Standardizing logging across all daemons: format, levels, output paths |
| CONCURRENT-DAEMON-ARCHITECTURE | Architecture for running daemons concurrently: startup ordering, dependency resolution |
| Document | Summary |
|---|---|
| ENTITY-ARCHITECTURE | Entity system design: BaseEntity inheritance, decorator-driven schema, prototype chain metadata |
| ENTITY-BASED-CONFIGURATION-SYSTEM | Using the entity system for configuration storage: typed settings as entities |
| ENTITY-EVOLUTION-PLAN | Evolution plan for entity system: migrations, versioning, backward compatibility |
| ENTITY-HYGIENE-SYSTEM | Automated entity hygiene: orphan detection, consistency checks, cleanup |
| ELEGANT-CRUD-ARCHITECTURE | Clean CRUD operations through the data daemon: generic typed operations |
| entity-adapter-architecture | Storage adapter abstraction: SQLite, JSON, vector DB behind a unified interface |
| RUST-ORM-ARCHITECTURE | Rust-side ORM design: rusqlite integration, type mapping, query building |
| RUST-STYLE-DEFAULTS-PLAN | Applying Rust-style default patterns to TypeScript entity initialization |
| Document | Summary |
|---|---|
| EVENT-COMMANDS-ARCHITECTURE | How Commands and Events work together: the two universal primitives |
| EVENT-STATE-ARCHITECTURE | Event-driven state management: state changes as events, derived state |
| EVENTS_UNIFICATION_PLAN | Plan to unify all event systems into one consistent Events API |
| UNIFIED_EVENTS_COMPLETE | Completion report for events unification: what changed, migration guide |
| CALLER-ADAPTIVE-OUTPUTS | Commands that adapt output format based on caller context (CLI vs API vs AI) |
| CLI-ARRAY-PARAMETERS | Handling array parameters in CLI: parsing, serialization, edge cases |
| DECORATOR-DRIVEN-SCHEMA | Schema generation from TypeScript decorators: command params, result types |
| Document | Summary |
|---|---|
| RUST-WORKER-IPC-PROTOCOL | IPC protocol between TypeScript and Rust: Unix sockets, JSON framing, error handling |
| RUST-WORKER-REGISTRATION-PATTERN | How Rust workers register with the TypeScript command system |
| RUST-WORKER-DUAL-PATH-PATTERN | Dual-path pattern: commands handled in Rust vs forwarded to TypeScript |
| RUST-WORKER-PATH-ANALYSIS | Analysis of command routing paths through the Rust worker layer |
| RUST-DATA-DAEMON-VISION | Vision for moving the data daemon to Rust: performance, SQLite native access |
| RUST-DATA-WORKER-ARCHITECTURE | Architecture for Rust-backed data operations: query execution, type mapping |
| UNIVERSAL-RUST-WORKER-PATTERN | Universal pattern for all Rust workers: lifecycle, IPC, error propagation |
| ARCHIVE-WORKER-DESIGN | Design for archive/compression worker in Rust: backup, export, snapshot |
| Document | Summary |
|---|---|
| GENERATOR-OOP-PHILOSOPHY | Core philosophy: generators ensure structural correctness at creation, OOP ensures behavioral correctness at runtime |
| GENERATOR-IMPROVEMENT-ARCHITECTURE | Architecture for improving the generator system: templates, validation, testing |
| GENERATOR-NEXT-STEPS | Immediate next steps for generator development |
| GENERATOR-ROADMAP | Long-term roadmap for the generation system |
| UNIFIED-GENERATION-SYSTEM | Unified generation: commands, daemons, widgets all from one generator pipeline |
| TDD-IN-TEMPLATES | Test-driven development baked into generator templates: tests generated alongside code |
| Document | Summary |
|---|---|
| LOGGING | Logging overview: philosophy, levels, output destinations |
| LOGGING-SYSTEM | Logging system architecture: daemon, transport, aggregation |
| LOGGING-MODULES | Per-module logging configuration: categories, verbosity, filtering |
| LOGGING-PATHS-DESIGN | Log file path design: directory structure, rotation, per-persona paths |
| LOGGER-DAEMON-VERIFICATION | Verification that the logger daemon correctly captures all log sources |
| MULTI-DIMENSIONAL-LOG-NAVIGATION | Navigating logs by time, persona, module, severity simultaneously |
| OBSERVABILITY-ARCHITECTURE | Full observability stack: logging, metrics, tracing, dashboards |
| Document | Summary |
|---|---|
| CODEBASE-RAG-DESIGN | RAG design for codebase understanding: chunking, embedding, retrieval |
| CODEBASE-RAG-IMPLEMENTATION | Implementation details for codebase RAG: file processing, index building |
| RAG-CONTEXT-BUDGET-SYSTEM | Context budget management: token allocation, priority ranking, truncation strategy |
| Document | Summary |
|---|---|
| CONTINUUM-STATE-ARCHITECTURE | Global system state management: initialization, lifecycle, shutdown |
| SYSTEM-CONFIG-ARCHITECTURE | Configuration system: sources, merging, validation, hot-reload |
| SYSTEM-DAEMON-ARCHITECTURE | System daemon design: the orchestrator that manages all other daemons |
| SYSTEM-PATHS-MIGRATION | Migration of hardcoded paths to centralized path constants |
| ARCHITECTURE_INCONSISTENCIES | Catalog of architectural inconsistencies found during audit |
| RUST-TS-INFERENCE-ARCHITECTURE | Architecture for Rust-TypeScript inference boundary: type generation, IPC typing |
| STORAGE-ADAPTER-ABSTRACTION | Storage adapter interface: abstracting SQLite/JSON/vector behind one API |
| Document | Summary |
|---|---|
| TDD-TRUST-MODEL | Trust model for testing: what tests prove, confidence levels, coverage strategy |
| ENVIRONMENT-AWARE-TESTING | Tests that adapt to environment: CI vs local, with/without GPU, mocked vs live |
| CRUD-EVENT-TEST-ARCHITECTURE | Testing architecture for CRUD operations and event emission: integration test patterns |
| Document | Summary |
|---|---|
| REAL-TIME-ARCHITECTURE | Real-time communication architecture: WebSocket, event streaming, latency |
| RECURSIVE-CONTEXT-ARCHITECTURE | Recursive context building: nested context assembly for deep conversation threads |
| Document | Summary |
|---|---|
| MULTI-DATABASE-HANDLES | Multi-database handle system: open/close/route to multiple SQLite databases |
| MULTI-DATABASE-IMPLEMENTATION-STATUS | Implementation status for multi-database: what ships, what is planned |
| MULTI-DATABASE-SECURITY | Security model for multi-database: isolation, access control, handle permissions |
| DATABASE-OPTIMIZATION-REPORT | Database performance analysis: query optimization, indexing, connection pooling |
| Document | Summary |
|---|---|
| GPU-MEMORY-ARCHITECTURE | GPU memory manager: RAII guards, subsystem budgets, pressure levels, hardware detection |
| RESOURCE-GOVERNANCE-ARCHITECTURE | Five-layer resource governance: from priority allocation to AI-driven sentinel control |
| SEMANTIC-SEARCH-ARCHITECTURE | Semantic search infrastructure: embedding generation, vector indexing, similarity queries |
| INDEX-MANAGEMENT-GUIDE | Guide for managing database and search indexes: creation, maintenance, monitoring |
| MODEL-DOWNLOAD-SYSTEM | Automated model download system: sources, caching, verification, retry |
| Document | Summary |
|---|---|
| JTAG_SYSTEM_ANALYSIS | Analysis of the JTAG debug/command system: architecture, capabilities, limitations |
| JTAG_CLIENT_UNIFICATION | Unifying JTAG client implementations: one client for CLI, browser, and tests |
| JTAG_COMMAND_ARCHITECTURE_REDESIGN | Redesign of command architecture: modular discovery, self-contained commands |
| COMMAND-ARCHITECTURE-AUDIT | Audit of command system: anti-patterns found, violations, remediation |
| COMMAND-VIOLATIONS-AUDIT | Specific violations of the modular command architecture and fixes |
| SHAREABLE-COMMAND-MODULES | Making command modules shareable across projects: packaging, dependencies |
| Document | Summary |
|---|---|
| PASSKEY-AUTHENTICATION-DESIGN | Passkey/WebAuthn authentication design: registration, verification, device management |
| Document | Summary |
|---|---|
| PATTERNS | Catalog of recurring patterns in the codebase: when to use each |
| DESIGN-PRINCIPLE-NATURAL-IDIOMS | Design principle: APIs should feel like natural language idioms |
| MODULAR-DEVELOPMENT-PHILOSOPHY | Philosophy of modular development: self-contained modules, dynamic discovery |
| ADAPTER-ARCHITECTURE | General adapter pattern: interface, factory, runtime selection |
| META-LANGUAGE-DESIGN | Meta-language for describing system behavior: DSL concepts, pipeline definitions |
| Document | Summary |
|---|---|
| ZERO-DOWNTIME-DEVELOPMENT | Zero-downtime development workflow: hot reload, live patching, graceful restart |
| UNIFIED-RUNTIME-MIGRATION | Migrating to a unified runtime: consolidating server, worker, and CLI entry points |
| UNIFIED_CLIENT_API | Unified client API: one interface for all command execution contexts |
| MCP-INTEGRATION | Model Context Protocol integration: connecting to MCP-compatible AI tooling |
| Document | Chapter | Relevance |
|---|---|---|
| SENTINEL-ARCHITECTURE | Sentinel | Pipeline engine that orchestrates long-running infrastructure tasks |
| SENTINEL-PIPELINE-ARCHITECTURE | Sentinel | Step types, execution model, and IPC for pipeline steps |
| GENOME-ARCHITECTURE | Genome | LoRA training infrastructure, adapter store, PEFT pipeline |
| TRAINING-SYSTEM-ARCHITECTURE | Genome | Training data pipelines that depend on data/ORM infrastructure |
| PERSONA-CONVERGENCE-ROADMAP | Personas | PersonaUser autonomous loop depends on daemons and command system |
| USER_DAEMON_ARCHITECTURE | Personas | User daemon that manages persona lifecycle via infrastructure primitives |
| VOICE-ARCHITECTURE | Live | Media workers using Rust worker IPC for audio/video processing |
| POSITRON-ARCHITECTURE | Positron | Widget system that consumes Events and executes Commands |
Commands.execute(name, params) → Response // Request/Response
Events.subscribe(name, handler) // Publish/Subscribe
Events.emit(name, data)
Everything is built on these. Local calls are direct. Remote calls go over WebSocket. Same API everywhere.