Overview
Monolex uses multiple SQLite databases to manage different aspects of terminal operations, project tracking, and file monitoring. Each database has a single, focused purpose following the SMPC principle.Architecture Layers
The databases are organized into three conceptual layers based on their role and update frequency.Database Summaries
session.db - Session State
Terminal session persistence, heartbeat tracking, and crash recovery.Schema Details
Schema Details
Tables:
terminal_heartbeats- Live terminal state monitoringterminals- Terminal metadata and settingsterminal_sessions- Scrollback data for recoveryterminal_group_log- Multi-tab group tracking
| Function | Trigger | Purpose |
|---|---|---|
session_db_save_terminal | Tab open | Register new terminal |
session_db_heartbeat | Every 10s | Update alive status |
session_db_end_terminal | Tab close | Mark as ended |
cleanup_dead_terminals | App start | Clear stale entries |
onit.db - Project Management
Project definitions, folder mappings, context documents, and daily statistics.Schema Details
Schema Details
Tables:
monolex_projects- Project metadata and statusmonolex_project_folders- Project-folder mappingscontext_docs- Global and project-scoped context filesdaily_stats- Aggregated daily activity metricsterminal_name_history- Terminal rename audit trail
niia-watcher.db - File Monitoring
File system event capture from the Rust watcher daemon.Schema Details
Schema Details
Tables:
file_events- File change events with metadatawatch_paths- Directories being monitoredworker_status- Daemon health and statisticsdaily_stats- Daily event counts by typeuser_exclusions- Custom ignore patterns
| Type | Description |
|---|---|
Create | New file or directory created |
Change | File content modified |
Unlink | File or directory deleted |
Rename | File renamed (includes old_path) |
atomic-term.db - Terminal Activity
PTY output parsing results and activity logs.Schema Details
Schema Details
Tables:
parsed_activities- Detected tool operations from PTY outputfile_map- Fallback cache for path resolution
target field from PTY output often contains truncated paths. The system correlates with niia-watcher.db to resolve full paths:
work-wiki-diff.db - Diff History
Git diff tracking for time-travel debugging and AI attribution.Schema Details
Schema Details
Tables:
file_diffs- Individual file diff recordssettings- Retention and size limitsai_sessions- AI agent work sessions (v2)commit_work_mapping- Links diffs to commits (v2)
| Query | Purpose |
|---|---|
| Time-travel | ”What did file.rs look like 2 hours ago?” |
| AI attribution | ”How much code did Claude write today?” |
| Pre-commit review | ”What changes will this commit include?” |
| Commit archaeology | ”What work led to commit xyz?” |
- Default: 30 days
- Max file size: 1MB (larger files store metadata only)
- Uncommitted work preserved regardless of age
file-paths.db - Path Index
Path normalization and usage frequency tracking.Data Flow Overview
Write Patterns
| Database | Write Frequency | Pattern | Optimization |
|---|---|---|---|
session.db | Low | Single row updates | Standard |
onit.db | Medium | Batch inserts | WAL mode |
niia-watcher.db | High (bursts) | Direct write | WAL + no IPC |
atomic-term.db | High | DBWriter thread | WAL + dedicated thread |
work-wiki-diff.db | Per save | Deduplication | Content hash check |
file-paths.db | Low | Insert/update | Standard |
DBWriter Thread Pattern (atomic-term.db)
Cross-Database Relationships
SMPC/OFAC Principles
SMPC Applied
- Each database has ONE clear purpose
- No complex JOIN queries across DBs
- WAL mode for concurrent access
- Simple key-value patterns where possible
OFAC Applied
- Time-based event correlation
- Graceful degradation on DB unavailability
- file-paths.db normalizes chaos
- session.db enables crash recovery