diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 6cc1450..508f88d 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -231,6 +231,17 @@ jobs:
           # Download and build libolm (pinned to v3.2.16 for reproducible builds)
           git clone --branch 3.2.16 --depth 1 https://gitlab.matrix.org/matrix-org/olm.git C:\olm
           cd C:\olm
+          
+          # Patch CMakeLists.txt to require CMake 3.5+ (for compatibility with modern CMake)
+          $originalContent = Get-Content CMakeLists.txt -Raw
+          $patchedContent = $originalContent -replace 'cmake_minimum_required\(VERSION [0-9]+\.[0-9]+(?:\.[0-9]+)?\)', 'cmake_minimum_required(VERSION 3.5)'
+          if ($patchedContent -ne $originalContent) {
+            Set-Content CMakeLists.txt $patchedContent
+            Write-Host "Successfully patched CMakeLists.txt to require CMake 3.5+"
+          } else {
+            Write-Host "Warning: CMakeLists.txt patch pattern not found, continuing anyway..."
+          }
+          
           cmake -S . -B build `
             -DCMAKE_INSTALL_PREFIX=C:\olm-install `
             -DCMAKE_BUILD_TYPE=Release `
@@ -353,7 +364,13 @@ jobs:
         run: |
           # Detect homebrew prefix (Apple Silicon uses /opt/homebrew, Intel uses /usr/local)
           HOMEBREW_PREFIX=$(brew --prefix)
-          echo "PKG_CONFIG_PATH=${HOMEBREW_PREFIX}/lib/pkgconfig:${PKG_CONFIG_PATH}" >> "$GITHUB_ENV"
+          
+          # Set environment variables for subsequent steps
+          {
+            echo "PKG_CONFIG_PATH=${HOMEBREW_PREFIX}/lib/pkgconfig:${PKG_CONFIG_PATH}"
+            echo "CFLAGS=-I${HOMEBREW_PREFIX}/include"
+            echo "LDFLAGS=-L${HOMEBREW_PREFIX}/lib"
+          } >> "$GITHUB_ENV"
       
       - name: Install dependencies
         run: |
diff --git a/AUDIT_SUMMARY.md b/AUDIT_SUMMARY.md
deleted file mode 100644
index b81939e..0000000
--- a/AUDIT_SUMMARY.md
+++ /dev/null
@@ -1,328 +0,0 @@
-# ChatrixCD Production Readiness Audit Summary
-
-**Date:** 2025-10-17  
-**Version Audited:** 2025.10.17.2.0.0  
-**Audit Status:** ✅ PRODUCTION READY
-
----
-
-## Executive Summary
-
-ChatrixCD has undergone a comprehensive production readiness audit covering code quality, documentation, testing, Matrix specification compliance, configuration, and security. The codebase demonstrates professional quality and is ready for production use and sharing with other users.
-
-**Overall Assessment: EXCELLENT** - All audited areas meet or exceed production standards.
-
----
-
-## Audit Scope
-
-The audit covered the following areas:
-
-1. **Code Quality** - Code cleanliness, PEP 8 compliance, debugging artifacts
-2. **Documentation** - Completeness, accuracy, consistency across platforms
-3. **Test Coverage** - Test quality, effectiveness, and coverage
-4. **Matrix Specification Compliance** - Protocol implementation correctness
-5. **Configuration & Build** - Packaging, dependencies, version management
-6. **Security** - Credential handling, logging, file permissions
-
----
-
-## Detailed Findings
-
-### 1. Code Quality ✅ EXCELLENT
-
-**Areas Reviewed:**
-- Debugging code and development artifacts
-- Code structure and organization  
-- PEP 8 compliance
-- Error handling patterns
-- Import management
-- Function complexity
-
-**Findings:**
-- ✅ No debugging code, breakpoints (`breakpoint()`), or pdb statements found
-- ✅ All `print()` statements are for legitimate user interaction (CLI/console mode)
-- ✅ No TODO/FIXME/XXX/HACK markers in production code
-- ✅ Clean code structure with clear separation of concerns
-- ✅ PEP 8 compliant with acceptable flexibility (lines up to 138 chars for readability)
-- ✅ All imports are used (static analysis false positives for local imports and type hints)
-- ✅ Function complexity is acceptable; longest function is `main()` at 127 lines (acceptable for entry point)
-- ✅ Comprehensive error handling with proper exception catching
-- ✅ No code smells or anti-patterns identified
-
-**Code Statistics:**
-- Total Python LOC: ~10,858 lines
-- Core modules: ~4,000 lines
-- Test code: ~4,300 lines
-- TUI code: ~2,000 lines
-
-### 2. Documentation ✅ EXCELLENT
-
-**Areas Reviewed:**
-- Repository documentation (root .md files)
-- GitHub Pages documentation (docs/ directory)
-- Issue templates and PR templates
-- Code comments and docstrings
-- Configuration examples
-
-**Findings:**
-- ✅ Two-tier documentation strategy properly implemented:
-  - **GitHub Pages (docs/)**: Concise, web-friendly versions with Jekyll formatting
-  - **Repository Root**: Comprehensive guides with full details
-- ✅ Cross-references added between both documentation tiers
-- ✅ All issue templates updated and accurate:
-  - Removed obsolete "Token" authentication option
-  - Updated Python version from 3.11 to 3.12
-  - Updated version placeholders to current format
-  - Fixed YAML references to JSON (project uses JSON/HJSON)
-- ✅ Configuration examples (config.json.example, aliases.json.example) are current
-- ✅ All docstrings follow Google/NumPy style
-- ✅ Code comments are appropriate and explain complex logic
-
-**Documentation Files:**
-- README.md (511 lines) - Comprehensive overview
-- INSTALL.md (484 lines) - Detailed installation guide
-- QUICKSTART.md (296 lines) - Quick start guide
-- ARCHITECTURE.md (680 lines) - Technical architecture
-- CONTRIBUTING.md (160 lines) - Contribution guidelines
-- SECURITY.md (170 lines) - Security policy
-- DEPLOYMENT.md (289 lines) - Deployment guide
-- SUPPORT.md (353 lines) - Support resources
-
-### 3. Test Coverage ✅ EXCELLENT
-
-**Areas Reviewed:**
-- Test structure and organization
-- Test effectiveness (can tests fail?)
-- Static/trivial tests
-- Coverage across modules
-
-**Findings:**
-- ✅ Comprehensive test suite with ~4,300 lines of test code
-- ✅ Well-structured tests with meaningful assertions
-- ✅ No trivial or always-passing tests (one intentional skip with valid reason)
-- ✅ Tests properly mock external dependencies (Matrix server, Semaphore API)
-- ✅ Good coverage across all modules:
-  - bot.py: 1,376 test lines
-  - commands.py: 578 test lines
-  - config.py: 570 test lines
-  - semaphore.py: 375 test lines
-  - verification: 658 test lines
-  - redactor.py: 219 test lines
-  - aliases.py: 137 test lines
-  - auth.py: 150 test lines
-  - tui.py: 265 test lines (lower coverage expected for UI)
-- ✅ Tests validate edge cases and error conditions
-- ✅ Async testing properly implemented with asyncio
-
-**Test Statistics:**
-- Total test files: 9
-- Test methods: 200+
-- Test frameworks: unittest (standard library)
-
-### 4. Matrix Specification Compliance ✅ EXCELLENT
-
-**Areas Reviewed:**
-- Authentication flows
-- E2E encryption implementation
-- Device verification
-- Client-Server API usage
-
-**Authentication - COMPLIANT:**
-- ✅ Uses standard `/_matrix/client/v3/login` endpoint
-- ✅ Supports `m.login.password` flow per spec
-- ✅ Supports `m.login.sso` and `m.login.token` flows per spec
-- ✅ Proper handling of identity providers
-- ✅ Token-based login completion follows spec
-- ✅ Session management with access token storage
-- ✅ Device ID and device name properly handled
-
-**E2E Encryption - COMPLIANT:**
-- ✅ Uses matrix-nio's Olm/Megolm implementation (spec-compliant)
-- ✅ Proper key upload using `/_matrix/client/v3/keys/upload`
-- ✅ Device key queries using `/_matrix/client/v3/keys/query`
-- ✅ One-time key claiming for Olm sessions
-- ✅ Megolm session management for room encryption
-- ✅ Automatic key rotation and upload when needed
-- ✅ Proper handling of encrypted events (MegolmEvent)
-
-**Device Verification - COMPLIANT:**
-- ✅ Implements SAS (Short Authentication String) verification per spec
-- ✅ Emoji comparison follows Matrix device verification spec
-- ✅ Proper key exchange and confirmation flows
-- ✅ Persistent device trust with proper store management
-- ✅ Support for multiple verification methods (emoji, QR code)
-- ✅ Verification callbacks properly implemented
-- ✅ Device trust state properly tracked
-
-**Matrix SDK:**
-- Uses matrix-nio >=0.24.0 with E2E encryption support
-- All Matrix operations use SDK methods (no custom protocol implementation)
-
-### 5. Configuration & Build ✅ EXCELLENT
-
-**Areas Reviewed:**
-- pyproject.toml configuration
-- setup.py configuration
-- requirements.txt dependencies
-- Version management
-
-**Findings:**
-- ✅ **FIXED**: pyproject.toml now includes all runtime dependencies:
-  - matrix-nio[e2e] >=0.24.0
-  - aiohttp >=3.9.0
-  - hjson >=3.1.0
-  - colorlog >=6.7.0
-  - textual >=0.47.0
-  - qrcode >=7.4.2
-- ✅ setup.py properly configured with console script entry point
-- ✅ Both pyproject.toml and setup.py present for compatibility
-- ✅ Version management using CalVer format: YYYY.MM.DD.patch.minor
-- ✅ Version stored in `chatrixcd/__init__.py` and dynamically loaded
-- ✅ All dependencies documented with purpose in requirements.txt
-- ✅ Python 3.12+ requirement properly specified
-- ✅ Package classifiers accurate and complete
-
-**Build Tools:**
-- setuptools >=61.0 with wheel
-- pip installable: `pip install -e .`
-- Console script: `chatrixcd`
-
-### 6. Security ✅ EXCELLENT
-
-**Areas Reviewed:**
-- Credential handling
-- Logging of sensitive data
-- File permissions
-- Error message safety
-- Hardcoded secrets
-
-**Findings:**
-- ✅ No hardcoded credentials in code
-- ✅ Configuration stored in external JSON files (not in code)
-- ✅ Session files protected with 0o600 permissions (owner read/write only)
-- ✅ Credentials never logged:
-  - Passwords: logged as "with password authentication" (not the actual value)
-  - Tokens: logged as "<provided>" or "<cancelled>"
-  - All credential values properly masked
-- ✅ Error messages don't leak sensitive information
-- ✅ Redaction support available for sensitive data in logs (`-R` flag)
-- ✅ Proper separation of configuration from code
-- ✅ Store path for encryption keys separate from config
-- ✅ No credentials in version control (.gitignore properly configured)
-
-**Security Features:**
-- Sensitive info redactor with patterns for:
-  - Room IDs and names
-  - User IDs
-  - IP addresses
-  - Access tokens
-  - API tokens
-  - Passwords
-- Redaction available via `-R` flag
-- Comprehensive .gitignore for sensitive files
-
----
-
-## Changes Made During Audit
-
-### Issue Templates (.github/ISSUE_TEMPLATE/)
-1. **bug_report.yml**
-   - Removed obsolete "Token" authentication option
-   - Updated Python version placeholder from 3.11.0 to 3.12.0
-   - Updated ChatrixCD version placeholder to 2025.10.17.2.0.0
-   - Added hint to run `chatrixcd --version` to check version
-
-2. **feature_request.yml**
-   - Fixed configuration examples from YAML to JSON format
-
-### Documentation (docs/)
-1. **README.md** - Enhanced with comprehensive structure and build guidelines
-2. **All docs/*.md files** - Added cross-references to comprehensive repository root docs:
-   - installation.md → INSTALL.md
-   - contributing.md → CONTRIBUTING.md
-   - security.md → SECURITY.md
-   - architecture.md → ARCHITECTURE.md
-   - quickstart.md → QUICKSTART.md
-   - deployment.md → DEPLOYMENT.md
-
-### Configuration & Build
-1. **pyproject.toml**
-   - Added all runtime dependencies (hjson, colorlog, textual, qrcode)
-   - Ensures proper packaging for PyPI distribution
-
----
-
-## Recommendations
-
-### For Immediate Action
-✅ **All completed** - No immediate actions required
-
-### For Future Enhancements (Optional)
-1. Consider adding GitHub Actions workflows for:
-   - Automated testing on PR
-   - Linting (flake8, black, mypy)
-   - Security scanning (bandit, safety)
-   
-2. Consider adding pre-commit hooks for:
-   - Code formatting
-   - Import sorting
-   - Type checking
-
-3. Consider adding more detailed metrics:
-   - Code coverage reporting (pytest-cov)
-   - Complexity analysis (radon)
-
-4. Consider creating a CHANGELOG.md maintenance workflow to ensure updates are consistently documented
-
----
-
-## Compliance Checklist
-
-- [x] No debugging code or development artifacts
-- [x] No hardcoded credentials or secrets
-- [x] Proper error handling throughout
-- [x] Comprehensive documentation
-- [x] Test coverage across all modules
-- [x] Matrix specification compliance
-- [x] Secure credential handling
-- [x] Proper file permissions
-- [x] PEP 8 compliant code
-- [x] All dependencies declared
-- [x] Proper versioning
-- [x] Issue templates current
-- [x] Security best practices followed
-
----
-
-## Conclusion
-
-**ChatrixCD is PRODUCTION READY for sharing with other users.**
-
-The codebase demonstrates:
-- ✅ Professional code quality
-- ✅ Comprehensive documentation
-- ✅ Robust test coverage
-- ✅ Matrix specification compliance
-- ✅ Security best practices
-- ✅ Proper packaging and configuration
-
-No critical issues were found during the audit. All identified minor issues have been resolved. The project is well-maintained, properly documented, and follows best practices for Python development and Matrix bot implementation.
-
----
-
-**Auditor Notes:**
-- Audit completed using static code analysis, manual review, and testing
-- All code paths reviewed for security and correctness
-- Documentation cross-checked for accuracy and completeness
-- Matrix specification references verified against spec.matrix.org
-- No external dependencies with known security vulnerabilities
-
-**Audit Artifacts:**
-- This document (AUDIT_SUMMARY.md)
-- Git commit history showing fixes applied during audit
-- Updated issue templates and documentation
-
----
-
-**End of Audit Report**
diff --git a/BRANDING.md b/BRANDING.md
deleted file mode 100644
index 8c30e2f..0000000
--- a/BRANDING.md
+++ /dev/null
@@ -1,209 +0,0 @@
-# ChatrixCD Branding Guide
-
-This document defines the visual identity and branding guidelines for the ChatrixCD project.
-
-## Brand Identity
-
-ChatrixCD is a Matrix bot that enables CI/CD automation through chat. Our branding reflects:
-- **Automation**: Represented by the bot/robot icon
-- **Communication**: Shown through the chat bubble design
-- **Technical Excellence**: Clean, modern aesthetics
-- **Approachability**: Friendly robot character
-
-## Logo
-
-### Primary Logo
-
-The ChatrixCD logo consists of:
-- **Icon**: A green robot head with a speech bubble, featuring an antenna
-- **Logotype**: "ChatrixCD" in white, modern sans-serif typeface
-
-**Usage**: The full logo (icon + text) should be used in most contexts.
-
-### Logo Variations
-
-1. **Full Logo (Horizontal)**: Icon on the left, text on the right - primary usage
-2. **Icon Only**: For small spaces, favicons, or when context is clear
-3. **Stacked Logo**: Icon on top, text below - for square/vertical layouts
-
-### Logo Files
-
-Logo files are located in the `assets/` directory:
-- `logo-horizontal.svg` - Full horizontal logo (default) - SVG format for scalability
-- `logo-icon.svg` - Icon only - SVG format
-- `logo-stacked.svg` - Stacked layout - SVG format
-- `logo-social.svg` - Social media preview (1200x630px) - SVG format
-- `favicon.svg` - Favicon for web pages - SVG format
-
-**Note**: All logos are provided in SVG format for perfect scalability and easy programmatic manipulation. PNG versions can be generated from SVG as needed for specific use cases.
-
-## Color Palette
-
-### Primary Colors
-
-- **ChatrixCD Green**: `#4A9B7F` (RGB: 74, 155, 127)
-  - Used for: Logo icon, primary buttons, accents, links
-  - Represents: Growth, automation, reliability
-
-- **White**: `#FFFFFF` (RGB: 255, 255, 255)
-  - Used for: Logo text, primary text on dark backgrounds
-  - Represents: Clarity, simplicity
-
-### Secondary Colors
-
-- **Dark Background**: `#2D3238` (RGB: 45, 50, 56)
-  - Used for: Backgrounds, containers, header areas
-  - Represents: Professionalism, focus
-
-- **Light Background**: `#F6F8FA` (RGB: 246, 248, 250)
-  - Used for: Light theme backgrounds, alternating sections
-  - Represents: Openness, accessibility
-
-### Accent Colors
-
-- **Success Green**: `#28A745` (RGB: 40, 167, 69)
-  - Used for: Success messages, completed tasks
-  
-- **Warning Yellow**: `#FFC107` (RGB: 255, 193, 7)
-  - Used for: Warnings, in-progress tasks
-
-- **Error Red**: `#DC3545` (RGB: 220, 53, 69)
-  - Used for: Errors, failed tasks
-
-- **Info Blue**: `#17A2B8` (RGB: 23, 162, 184)
-  - Used for: Information messages, tips
-
-## Typography
-
-### Primary Font
-
-- **Headings**: Sans-serif (system font stack)
-  - `-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif`
-  - Bold weights for emphasis
-
-- **Body Text**: Sans-serif (system font stack)
-  - Regular weight for readability
-  - Line height: 1.6 for optimal reading
-
-### Code Font
-
-- **Code Blocks**: Monospace (system font stack)
-  - `"SF Mono", Monaco, "Cascadia Code", "Roboto Mono", Consolas, "Courier New", monospace`
-
-## Logo Usage Guidelines
-
-### Do's ✅
-
-- Use the logo on a dark background for maximum contrast
-- Maintain adequate clear space around the logo (minimum 20% of logo height)
-- Scale the logo proportionally
-- Use the provided color values
-- Ensure the logo is clearly visible and readable
-
-### Don'ts ❌
-
-- Don't change the logo colors (except for approved variations)
-- Don't distort or skew the logo
-- Don't add effects (shadows, gradients, etc.) to the logo
-- Don't place the logo on busy backgrounds
-- Don't recreate or modify the logo artwork
-
-### Minimum Size
-
-- **Full Logo**: 200px width minimum
-- **Icon Only**: 32px × 32px minimum
-
-## Brand Voice
-
-When writing content for ChatrixCD:
-
-- **Clear**: Use simple, straightforward language
-- **Technical but Approachable**: Balance technical accuracy with accessibility
-- **Helpful**: Focus on solving user problems
-- **Professional**: Maintain a professional tone while being friendly
-
-## Application in Documentation
-
-### README Files
-
-- Include the full horizontal logo at the top
-- Use brand colors for section headers (with emoji icons)
-- Maintain consistent formatting
-
-### GitHub Pages
-
-- Logo in the site header/navigation
-- Use the dark color scheme with ChatrixCD Green accents
-- Consistent use of emoji icons for visual interest
-
-### Code Comments
-
-- Use clear, descriptive comments
-- Follow PEP 8 style guide
-- No branding needed in code comments
-
-## Social Media
-
-### GitHub Social Preview
-
-- Image size: 1200 × 630 pixels
-- Logo prominently displayed on dark background
-- Project tagline included
-
-### Profile Images
-
-- Use icon-only logo
-- Ensure visibility at small sizes (48 × 48 pixels)
-
-## Examples
-
-### Markdown Header with Branding
-
-```markdown
-<div align="center">
-  <img src="assets/logo-horizontal.png" alt="ChatrixCD Logo" width="400">
-  
-  # ChatrixCD
-  
-  **Matrix bot for CI/CD automation through chat**
-  
-  [![License: GPL v3](https://img.shields.io/badge/License-GPLv3-blue.svg)](https://www.gnu.org/licenses/gpl-3.0)
-  [![Python 3.12+](https://img.shields.io/badge/python-3.12+-blue.svg)](https://www.python.org/downloads/)
-</div>
-```
-
-### Badges
-
-Use shields.io badges with brand colors:
-- Color: `4A9B7F` (ChatrixCD Green)
-- Label color: `2D3238` (Dark Background)
-
-## Assets Checklist
-
-To fully implement the branding, add the following assets:
-
-- [ ] `assets/logo-horizontal.png` - Full horizontal logo (800 × 250px recommended)
-- [ ] `assets/logo-icon.png` - Icon only (512 × 512px)
-- [ ] `assets/logo-stacked.png` - Stacked layout (500 × 600px)
-- [ ] `assets/logo-social.png` - Social media preview (1200 × 630px)
-- [ ] `assets/favicon.ico` - Browser favicon (32 × 32px)
-- [ ] `docs/assets/logo-horizontal.png` - Copy for GitHub Pages
-- [ ] `docs/assets/logo-icon.png` - Copy for GitHub Pages
-
-## Brand Evolution
-
-This branding guide may be updated over time. Major changes will be:
-- Documented in CHANGELOG.md
-- Announced to contributors
-- Implemented gradually to avoid breaking existing usage
-
-## Questions?
-
-For questions about branding usage, please:
-- Open a discussion on GitHub
-- Reference this guide when proposing visual changes
-- Consult with maintainers for major branding decisions
-
----
-
-*ChatrixCD Branding Guide v1.0*
diff --git a/BUILD_FIX_SUMMARY.md b/BUILD_FIX_SUMMARY.md
deleted file mode 100644
index c0f3a71..0000000
--- a/BUILD_FIX_SUMMARY.md
+++ /dev/null
@@ -1,146 +0,0 @@
-# Build Workflow Fix Summary
-
-## Overview
-This document summarizes the fixes applied to the build workflow to successfully compile Windows (.exe) and macOS (.app) binaries, along with Linux binaries across multiple architectures.
-
-## Issues Fixed
-
-### 1. Nuitka Action Configuration Issue (All Platforms)
-**Problem:** The `include-data-dir` parameter was using multi-line YAML format which was being passed incorrectly to Nuitka.
-
-**Solution:** Changed to single-line format:
-```yaml
-include-data-dir: assets=assets
-```
-
-### 2. macOS Build Failure - Missing CMake
-**Problem:** python-olm requires CMake to build, but it wasn't available in the macOS runner.
-```
-CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
-  Compatibility with CMake < 3.5 has been removed from CMake.
-```
-
-**Solution:** Install CMake via homebrew:
-```yaml
-- name: Install build dependencies (macOS)
-  run: |
-    brew install libolm pkg-config cmake
-```
-
-### 3. Windows Build Failure - Missing olm.lib
-**Problem:** python-olm build failed looking for `olm.lib`, but CMake with `-DBUILD_SHARED_LIBS=OFF` creates `olm_static.lib`.
-```
-LINK : fatal error LNK1181: cannot open input file 'olm.lib'
-```
-
-**Solution:** 
-- Build libolm as static library with `-DBUILD_SHARED_LIBS=OFF`
-- Copy `olm_static.lib` to `olm.lib` for python-olm compatibility
-- Added debug output to troubleshoot library locations
-
-### 4. Linux ARM64 Build Failure - exec format error
-**Problem:** Docker container failed with "exec format error" when trying to run bash in ARM64 emulation.
-```
-exec /usr/bin/bash: exec format error
-```
-
-**Solution:**
-- Changed from `bash` to `sh` in Docker run command (more universally compatible)
-- Added Docker Buildx setup for better multi-platform support
-- Ensured QEMU platform is specified as `linux/arm64` (not just `arm64`)
-
-### 5. Linux i686 Build - Consistency Fix
-**Problem:** No error, but for consistency with ARM64 fix.
-
-**Solution:** Changed from `bash` to `sh` in Docker run command.
-
-## Files Modified
-
-### `.github/workflows/build.yml`
-All build configuration fixes were applied to this single file:
-
-1. **Lines ~130-135** (Linux x86_64): Fixed `include-data-dir` format
-2. **Lines ~76-82** (Linux all): Added Docker Buildx setup, fixed QEMU platform
-3. **Lines ~140-160** (Linux i686): Changed bash to sh
-4. **Lines ~165-180** (Linux ARM64): Changed bash to sh
-5. **Lines ~225-252** (Windows): Added static library build, library copy, debug output
-6. **Lines ~329-333** (macOS): Added cmake to brew install
-7. **Lines ~286-287** (Windows Nuitka): Fixed `include-data-dir` format
-8. **Lines ~378-379** (macOS Nuitka): Fixed `include-data-dir` format
-
-## Testing Required
-
-The workflow needs to be tested to verify all fixes work correctly. Since the workflow only triggers on:
-1. PR merge to main
-2. Manual workflow_dispatch
-
-To test before merging:
-
-### Option 1: Manual Workflow Dispatch
-1. Go to Actions tab in GitHub
-2. Select "Build and Release" workflow
-3. Click "Run workflow"
-4. Select branch: `copilot/build-windows-macos-binary`
-5. Choose version type: `patch`
-6. Click "Run workflow"
-
-### Option 2: Create a Pull Request
-Create a PR from `copilot/build-windows-macos-binary` to `main` (but don't merge yet) to trigger the workflow.
-
-## Expected Artifacts
-
-Upon successful build, the workflow should produce the following artifacts:
-
-1. **Linux Binaries:**
-   - `chatrixcd-linux-x86_64` (x86 64-bit)
-   - `chatrixcd-linux-i686` (x86 32-bit)
-   - `chatrixcd-linux-arm64` (ARM 64-bit)
-
-2. **Windows Binary:**
-   - `chatrixcd-windows-x86_64.exe` (64-bit executable)
-
-3. **macOS Binary:**
-   - `chatrixcd-macos-universal` (Universal binary)
-   - `ChatrixCD.app` (macOS application bundle)
-
-All artifacts should be available in the Actions run under "Artifacts" section with 90-day retention.
-
-## Verification Steps
-
-After workflow completes successfully:
-
-1. **Download all artifacts** from the workflow run
-2. **Verify file existence:**
-   - All 6 expected files/packages are present
-   - Files have reasonable sizes (not 0 bytes)
-3. **Test executability (optional):**
-   - Linux: `chmod +x chatrixcd-linux-x86_64 && ./chatrixcd-linux-x86_64 --version`
-   - Windows: Run `chatrixcd-windows-x86_64.exe` on a Windows machine
-   - macOS: Open `ChatrixCD.app` on a macOS machine
-
-## Remaining Considerations
-
-### Known Limitations
-1. **ARM64 build takes longer** due to QEMU emulation (~20-30 minutes)
-2. **Windows binary is large** due to bundled dependencies
-3. **macOS binary is Universal2** (supports both Intel and Apple Silicon)
-
-### Future Improvements
-1. Consider using pre-built wheels for python-olm if available
-2. Optimize build caching to speed up subsequent runs
-3. Add build artifact checksums for verification
-4. Consider code signing for Windows and macOS binaries
-
-## Commit History
-
-1. **Initial plan** - Analysis and planning
-2. **Fix Nuitka configuration and build issues for all platforms** - Core fixes for Nuitka Action and dependency issues
-3. **Fix remaining build issues: ARM64 emulation and Windows libolm library** - Final fixes for Docker and Windows static library
-
-## References
-
-- [Nuitka Action Documentation](https://github.com/Nuitka/Nuitka-Action)
-- [Docker QEMU Setup](https://github.com/docker/setup-qemu-action)
-- [Docker Buildx Setup](https://github.com/docker/setup-buildx-action)
-- [python-olm GitHub](https://github.com/poljar/python-olm)
-- [libolm GitHub](https://gitlab.matrix.org/matrix-org/olm)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 15f44f6..7f2fecf 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -21,11 +21,25 @@ and this project adheres to Semantic Calendar Versioning with format YYYY.MM.DD.
   - Added QEMU setup for ARM64 cross-compilation on Linux
   - Installed libolm build dependency via homebrew on macOS
   - Setup CMake and libolm build environment on Windows
+  - **Windows Build**: Patched libolm CMakeLists.txt to require CMake 3.5+ for compatibility
+  - **macOS Build**: Set CFLAGS and LDFLAGS to use homebrew libolm instead of building from source
   - Fixed compatibility issues with python-olm native extension builds
   - Enhanced Windows libolm build configuration with CMAKE_BUILD_TYPE and proper install paths
   - Added CMAKE_PREFIX_PATH and PATH environment variables for Windows python-olm builds
   - Fixed macOS PKG_CONFIG_PATH detection to support both Apple Silicon and Intel architectures
   - Re-added pull_request trigger to build workflow for automatic builds on PR merge
+- **Log Formatting**: Fixed `!cd log` command rendering issues
+  - Added `_ansi_to_html_for_pre()` function that strips ANSI codes and preserves newlines in `<pre>` tags
+  - Fixed log output to properly render with line breaks (newlines preserved in HTML `<pre>` tags)
+  - Logs now display correctly in Matrix clients without all content on one line
+  - ANSI color codes are stripped for better readability in Matrix clients
+- **Markdown Rendering**: Fixed markdown not being rendered in messages
+  - Added HTML conversion to log tailing messages
+  - Bold (`**text**`), italic (`*text*`), and code (`` `text` ``) now render properly
+- **User Mentions**: Fixed inconsistent username highlighting
+  - Updated `_get_display_name()` to return full Matrix IDs (@user:server.com)
+  - Enhanced `markdown_to_html()` to convert mentions to clickable HTML links
+  - Users are now properly highlighted when mentioned in messages
 
 ### Added
 - **Configuration Wizard**: Interactive configuration setup with `--init` flag
@@ -57,8 +71,19 @@ and this project adheres to Semantic Calendar Versioning with format YYYY.MM.DD.
   - `messages.json` auto-reloads every 5 seconds
   - Changes take effect without bot restart
   - Thread-safe implementation using asyncio tasks
+- **Test Coverage Improvements**: Added tests for new functionality
+  - Test for `_ansi_to_html_for_pre()` verifying newline preservation in `<pre>` tags
+  - Tests for markdown mention conversion to HTML links
+  - Test for `_get_display_name()` returning full Matrix IDs for proper mentions
+  - All new code paths now have corresponding unit tests
 
 ### Changed
+- **Documentation Cleanup**: Removed outdated and redundant documentation files
+  - Removed 11 old summary files (AUDIT_SUMMARY.md, BUILD_FIX_SUMMARY.md, etc.) from previous development iterations
+  - Removed overly detailed design documents (TUI_TURBO_VISION_DESIGN.md, TUI_MIGRATION_GUIDE.md, BUILD_WORKFLOW.md)
+  - Removed redundant architecture docs (CONCURRENT_ARCHITECTURE.md merged into ARCHITECTURE.md, BRANDING.md)
+  - Repository is now cleaner with focus on essential, user-facing documentation
+  - Over 4000 lines of documentation bloat removed
 - **Configuration Migration**: Migration system now suggests running `--init` after automatic migration to review new settings
 - **Username Display**: User display names now keep the `@` symbol for proper Matrix user identification
 - **Version Calculation System**: Complete refactoring for simplicity and robustness
diff --git a/CONCURRENT_ARCHITECTURE.md b/CONCURRENT_ARCHITECTURE.md
deleted file mode 100644
index 270622c..0000000
--- a/CONCURRENT_ARCHITECTURE.md
+++ /dev/null
@@ -1,252 +0,0 @@
-# ChatrixCD Concurrent Architecture
-
-## Overview
-
-ChatrixCD uses an **asynchronous architecture** based on Python's `asyncio` for optimal performance and resource utilization. This document explains the design decisions and how the bot achieves efficient concurrent execution.
-
-## Why Async Instead of Threading?
-
-While the term "threading" often implies OS-level threads, ChatrixCD uses `asyncio` for several important reasons:
-
-### 1. **I/O-Bound Workload**
-The bot's primary operations are I/O-bound:
-- Matrix server synchronization
-- Semaphore API requests
-- File system monitoring
-- TUI event handling
-
-For I/O-bound tasks, async/await provides **better performance** than threading because:
-- No thread context switching overhead
-- Efficient handling of thousands of concurrent connections
-- Lower memory footprint (no thread stacks)
-
-### 2. **Library Compatibility**
-Core dependencies are async-native:
-- **matrix-nio**: Async Matrix client library
-- **Textual**: Async TUI framework
-- **aiohttp**: Async HTTP client
-
-Using threads with these libraries would require complex synchronization and reduce performance.
-
-### 3. **Python's GIL**
-Python's Global Interpreter Lock (GIL) means:
-- Only one thread executes Python bytecode at a time
-- Threading doesn't provide true parallelism for CPU-bound tasks
-- For this bot's workload, async provides better concurrency
-
-### 4. **Simpler Concurrency Model**
-Async/await provides:
-- Explicit concurrency points (`await`)
-- No race conditions from shared mutable state
-- Easier to reason about and debug
-- No need for locks, semaphores, or other synchronization primitives
-
-## Concurrent Components
-
-The bot runs multiple concurrent tasks simultaneously:
-
-### 1. **Matrix Sync Loop**
-```python
-# In bot.py
-async def run(self):
-    # Starts the Matrix sync loop in the background
-    await self.client.sync_forever(timeout=30000, full_state=True)
-```
-
-This continuously polls the Matrix server for new events (messages, invitations, etc.) without blocking other operations.
-
-### 2. **TUI Event Loop**
-```python
-# In main.py
-async def run_tui_with_bot(bot, config, ...):
-    # TUI runs concurrently with the bot
-    await tui_app.run_async(mouse=mouse)
-```
-
-The TUI handles user input and displays updates independently of the Matrix sync.
-
-### 3. **Command Execution**
-```python
-# In commands.py
-async def handle_message(self, room, event):
-    # Commands execute asynchronously
-    await self.command_handler.handle_message(room, event)
-```
-
-Multiple commands can be processed concurrently without blocking.
-
-### 4. **File Watching**
-```python
-# In messages.py, aliases.py, config.py
-async def _auto_reload_loop(self):
-    while True:
-        await asyncio.sleep(5)  # Non-blocking sleep
-        if self.check_for_changes():
-            self.load_messages()
-```
-
-Configuration files are monitored in the background without blocking the main bot operations.
-
-### 5. **Task Monitoring**
-```python
-# In commands.py
-async def monitor_task(self, project_id, task_id, room_id, task_name):
-    while task_id in self.active_tasks:
-        await asyncio.sleep(10)  # Non-blocking
-        task = await self.semaphore.get_task_status(project_id, task_id)
-        # Send updates based on status changes
-```
-
-Multiple Semaphore tasks are monitored concurrently.
-
-## Concurrency in Action
-
-Here's how these components work together:
-
-```
-┌─────────────────────────────────────────┐
-│         AsyncIO Event Loop              │
-│                                         │
-│  ┌──────────────┐  ┌──────────────┐   │
-│  │ Matrix Sync  │  │  TUI Events  │   │
-│  │    Loop      │  │    Handler   │   │
-│  └──────┬───────┘  └──────┬───────┘   │
-│         │                  │           │
-│         ├──────────┬───────┤           │
-│         │          │       │           │
-│  ┌──────▼────┐ ┌──▼───┐ ┌─▼────────┐  │
-│  │  Command  │ │ File │ │   Task   │  │
-│  │  Handler  │ │Watch │ │ Monitor  │  │
-│  └───────────┘ └──────┘ └──────────┘  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-All components run concurrently on a **single thread**, sharing the asyncio event loop. This is efficient because:
-
-1. **No CPU Competition**: Components yield control while waiting for I/O
-2. **Cooperative Multitasking**: Explicit `await` points ensure fair scheduling
-3. **Resource Efficiency**: One thread handles everything with minimal overhead
-
-## Performance Characteristics
-
-### Async Advantages for This Bot:
-
-1. **Low Latency**: Responds to Matrix messages immediately, even while monitoring tasks
-2. **High Throughput**: Can handle multiple API requests simultaneously
-3. **Scalability**: Efficiently handles many rooms and concurrent commands
-4. **Resource Efficient**: Single thread, low memory footprint
-
-### When Threading Would Help:
-
-Threading would only improve performance if the bot had:
-- Heavy computational work (image processing, encryption, etc.)
-- CPU-bound operations that block the event loop
-- Need to bypass the GIL (e.g., with C extensions)
-
-**Current Status**: The bot has no CPU-bound operations that would benefit from threading.
-
-## File Watching Implementation
-
-The async file watching system provides hot-reload without blocking:
-
-```python
-# Non-blocking file monitoring
-async def _auto_reload_loop(self):
-    try:
-        while True:
-            await asyncio.sleep(5)  # Yields control to other tasks
-            
-            if self.check_for_changes():
-                logger.info(f"File modified, reloading...")
-                self.load_messages()  # Fast operation
-                
-    except asyncio.CancelledError:
-        logger.debug("Auto-reload task cancelled")
-```
-
-**Key Features**:
-- Checks every 5-10 seconds (configurable)
-- Non-blocking: uses `await asyncio.sleep()` instead of `time.sleep()`
-- Safe shutdown: handles cancellation gracefully
-- No race conditions: file operations are atomic
-
-## Testing Considerations
-
-Tests work with the async architecture:
-
-```python
-def setUp(self):
-    """Set up test fixtures."""
-    self.loop = asyncio.new_event_loop()
-    asyncio.set_event_loop(self.loop)
-
-def test_async_function(self):
-    """Test an async function."""
-    result = self.loop.run_until_complete(
-        self.handler.async_method()
-    )
-    self.assertEqual(result, expected)
-```
-
-**Note**: Auto-reload is **disabled** in tests to avoid event loop conflicts. The managers gracefully handle the absence of a running loop.
-
-## Future Enhancements
-
-While the current async architecture is optimal for the bot's needs, potential enhancements could include:
-
-### 1. **Process Pool for CPU-Intensive Tasks**
-If CPU-bound operations are added (e.g., log parsing, data processing):
-```python
-# Use ProcessPoolExecutor for true parallelism
-from concurrent.futures import ProcessPoolExecutor
-
-async def process_logs(logs):
-    loop = asyncio.get_event_loop()
-    with ProcessPoolExecutor() as pool:
-        result = await loop.run_in_executor(pool, cpu_intensive_function, logs)
-    return result
-```
-
-### 2. **Thread Pool for Blocking I/O**
-If synchronous blocking operations are needed:
-```python
-# Use ThreadPoolExecutor for blocking I/O
-from concurrent.futures import ThreadPoolExecutor
-
-async def blocking_operation():
-    loop = asyncio.get_event_loop()
-    with ThreadPoolExecutor() as pool:
-        result = await loop.run_in_executor(pool, blocking_function)
-    return result
-```
-
-### 3. **Rate Limiting**
-For API rate limiting:
-```python
-from asyncio import Semaphore
-
-# Limit concurrent API requests
-api_semaphore = Semaphore(10)
-
-async def api_call():
-    async with api_semaphore:
-        return await make_request()
-```
-
-## Conclusion
-
-ChatrixCD's async architecture provides:
-- ✅ **Concurrent execution** of multiple operations
-- ✅ **Efficient resource usage** (single thread, low overhead)
-- ✅ **Responsive UI** (TUI updates while bot runs)
-- ✅ **Hot-reload** (config changes without restart)
-- ✅ **Scalability** (handles many rooms/commands)
-- ✅ **Simplicity** (no locks, no race conditions)
-
-This architecture is **superior to threading** for the bot's I/O-bound workload and provides excellent performance characteristics for its use case.
-
-For more information:
-- [Python asyncio documentation](https://docs.python.org/3/library/asyncio.html)
-- [matrix-nio async API](https://matrix-nio.readthedocs.io/)
-- [Textual async framework](https://textual.textualize.io/)
diff --git a/DOCUMENTATION_UPDATE_SUMMARY.md b/DOCUMENTATION_UPDATE_SUMMARY.md
deleted file mode 100644
index 83b6c5f..0000000
--- a/DOCUMENTATION_UPDATE_SUMMARY.md
+++ /dev/null
@@ -1,152 +0,0 @@
-# Documentation Update Summary
-
-This document summarizes the documentation updates made to support pre-built binary downloads.
-
-## Overview
-
-All documentation has been updated to prioritize pre-built binaries as the **primary installation method**, with direct download links that automatically point to the latest stable release.
-
-## Files Updated
-
-### 1. README.md
-**Changes:**
-- Restructured "Installation" section to show pre-built binaries as "Option 1 (Recommended)"
-- Added direct download links for all platforms (Linux x86_64, i686, ARM64; Windows x86_64, ARM64; macOS Universal)
-- Added quick start commands for Linux/macOS/Windows
-- Source installation moved to "Option 2"
-
-### 2. INSTALL.md
-**Changes:**
-- Complete restructure with three installation methods:
-  - Method 1: Pre-built Binary (Recommended)
-  - Method 2: Install from Source
-  - Method 3: Docker Installation
-- Added download links and setup instructions for binaries
-- Added separate "Running the Bot" section with examples for binary and source
-- Updated configuration section to cover binary users
-
-### 3. QUICKSTART.md
-**Changes:**
-- Added "Option 1: Pre-built Binary (Fastest!)" with download commands
-- Source installation moved to "Option 2"
-- Updated "Running the Bot" section with binary and source examples
-- Added note about config.json location for binary users
-
-### 4. docs/index.md (GitHub Pages Homepage)
-**Changes:**
-- Added "Quick Install (Pre-built Binary)" section with download commands
-- Added comprehensive download links table for all platforms
-- Restructured to show binaries before source installation
-- Updated prerequisites to clarify binaries don't need Python
-
-### 5. docs/installation.md (GitHub Pages)
-**Changes:**
-- Restructured with three methods (Binary, Source, Docker)
-- Method 1 is now "Pre-built Binary (Recommended)"
-- Added complete download links and setup instructions
-- Updated navigation order
-
-### 6. docs/quickstart.md (GitHub Pages)
-**Changes:**
-- Added "Option 1: Pre-built Binary (Fastest!)"
-- Added platform-specific download examples
-- Updated running instructions for binaries
-
-### 7. DEPLOYMENT.md
-**Changes:**
-- Added "Pre-built Binary" to Quick Reference table
-- Added "For Quick Deployment (Pre-built Binary)" section
-- Updated Feature Comparison table to include binaries
-- Added "Use Pre-built Binary if" decision criteria
-- Updated detailed instructions links
-
-### 8. docs/BUILD_WORKFLOW.md
-**Changes:**
-- Added new section: "Documentation Updates After Release"
-- Explained that download links auto-update (no manual changes needed)
-- Added release checklist
-- Listed all files containing download links
-- Added testing instructions for download links
-- Explained pre-release vs production release link behavior
-
-## Download Link Format
-
-All documentation uses GitHub's automatic latest release URL pattern:
-
-```
-https://github.com/CJFWeatherhead/ChatrixCD/releases/latest/download/<artifact-name>
-```
-
-**Key benefit:** These links automatically redirect to the latest non-pre-release version. No manual updates needed when creating new releases!
-
-## Example Download Links
-
-- Linux x86_64: `https://github.com/CJFWeatherhead/ChatrixCD/releases/latest/download/chatrixcd-linux-x86_64`
-- Windows x86_64: `https://github.com/CJFWeatherhead/ChatrixCD/releases/latest/download/chatrixcd-windows-x86_64.exe`
-- macOS Universal: `https://github.com/CJFWeatherhead/ChatrixCD/releases/latest/download/chatrixcd-macos-universal`
-
-## Documentation Structure
-
-Before:
-```
-Installation
-├── Prerequisites (Python required)
-├── Install from Source
-└── Docker Installation
-```
-
-After:
-```
-Installation
-├── Option 1: Pre-built Binaries (Recommended) ← NEW PRIMARY METHOD
-│   ├── No Python required
-│   ├── Direct download links
-│   └── Quick start commands
-├── Option 2: Install from Source
-│   ├── Prerequisites (Python)
-│   └── Installation steps
-└── Option 3: Docker Installation
-```
-
-## User Experience Improvements
-
-1. **Faster onboarding**: Users can download and run immediately
-2. **Lower barrier to entry**: No Python installation needed
-3. **Clear platform selection**: Dedicated links for each architecture
-4. **Consistent messaging**: All documentation emphasizes binaries first
-5. **Easy updates**: Download links automatically point to latest release
-
-## Release Process
-
-When creating a new production release:
-
-1. Trigger build workflow (manual or on PR merge)
-2. Wait for builds to complete
-3. ✅ **Download links automatically update** - no documentation changes needed!
-4. Verify links work by testing them
-5. Announce release
-
-## Files Containing Auto-Updating Links
-
-These files contain download links that automatically resolve to the latest release:
-
-1. `README.md`
-2. `INSTALL.md`
-3. `QUICKSTART.md`
-4. `docs/index.md`
-5. `docs/installation.md`
-6. `docs/quickstart.md`
-7. `DEPLOYMENT.md`
-
-## Testing
-
-All existing tests pass:
-- 270 unit tests ✅
-- 15 workflow configuration tests ✅
-- Markdown files valid ✅
-
-## Commit
-
-Changes committed in: `df64c48`
-
-All updates are now live in the PR branch: `copilot/update-github-action-release-workflow`
diff --git a/ENCRYPTION_FIX_SUMMARY.md b/ENCRYPTION_FIX_SUMMARY.md
deleted file mode 100644
index 949cc99..0000000
--- a/ENCRYPTION_FIX_SUMMARY.md
+++ /dev/null
@@ -1,435 +0,0 @@
-# End-to-End Encryption Fix Summary
-
-## Problem Statement
-
-Despite PR #69 fixing device verification issues, several critical problems remained:
-
-1. **TUI showing "Unknown" for devices**: The TUI was still displaying "Unknown" for user IDs and device IDs in verification requests, even though the fix was applied to `verification.py`.
-
-2. **Decryption failures with no recovery**: When the bot received encrypted messages it couldn't decrypt, it would request room keys but often failed because:
-   - No Olm sessions were established with the sender's devices
-   - Device keys weren't queried proactively
-   - To-device messages weren't sent after key requests
-
-3. **Duplicate key request errors**: The bot would attempt to request the same room key multiple times, leading to "A key sharing request is already sent out for this session id" errors.
-
-4. **Poor encryption initialization**: When joining encrypted rooms, the bot didn't proactively establish Olm sessions with room members, leading to inability to decrypt messages.
-
-5. **No room key sharing after verification**: After successfully verifying a device, the bot didn't share room keys with the newly verified device.
-
-## Root Causes
-
-### Issue 1: TUI Device Info Extraction Not Fixed
-
-**Location**: `chatrixcd/tui.py`, `check_pending_verifications()` method (lines 1653-1654)
-
-**Problem**: While PR #69 fixed device info extraction in `verification.py`, the same fix was NOT applied to `tui.py`. The TUI was still trying to access `user_id` and `device_id` directly on Sas verification objects:
-
-```python
-user_id = getattr(verification, 'user_id', 'Unknown')
-device_id = getattr(verification, 'device_id', 'Unknown')
-```
-
-**Impact**: All verification requests in the TUI showed "Unknown" for both user and device, making it impossible to identify which device was trying to verify.
-
-### Issue 2: Passive Decryption Failure Handling
-
-**Location**: `chatrixcd/bot.py`, `megolm_event_callback()` method
-
-**Problem**: When receiving an encrypted message that couldn't be decrypted, the bot would:
-1. Log a warning
-2. Request the room key
-3. Do nothing else
-
-This passive approach failed because:
-- The sender's device keys might not be queried yet
-- No Olm session might exist with the sender's device (required for key sharing)
-- The to-device message for the key request might not be sent
-
-**Impact**: Messages remained undecryptable indefinitely, and the bot couldn't recover.
-
-### Issue 3: Session Tracking Too Broad
-
-**Location**: `chatrixcd/bot.py`, `requested_session_ids` tracking
-
-**Problem**: The bot tracked requested session IDs globally by session ID only, not by sender. This meant:
-- If the same session ID appeared from different senders (unlikely but possible), only one would be requested
-- The tracking was too coarse-grained
-
-**Impact**: Potential missed key requests in edge cases.
-
-### Issue 4: No Proactive Encryption Setup
-
-**Location**: `chatrixcd/bot.py`, sync handling
-
-**Problem**: The bot only queried device keys when `should_query_keys` was set by matrix-nio. It didn't:
-- Proactively query keys for all members of encrypted rooms
-- Establish Olm sessions when joining encrypted rooms
-- Claim one-time keys to enable encryption
-
-**Impact**: The bot couldn't decrypt messages in encrypted rooms because it had no Olm sessions with other users' devices.
-
-### Issue 5: No Room Key Sharing After Verification
-
-**Location**: `chatrixcd/verification.py`, `confirm_verification()` and `auto_verify_pending()`
-
-**Problem**: After successfully verifying a device, the bot would:
-1. Mark the device as verified
-2. Persist the trust
-3. Do nothing else
-
-The bot didn't share room keys with the newly verified device, meaning the verified device still couldn't decrypt messages in encrypted rooms.
-
-**Impact**: Verification was incomplete - even verified devices couldn't decrypt messages.
-
-## Solutions Implemented
-
-### Fix 1: TUI Device Info Extraction
-
-**File**: `chatrixcd/tui.py`
-**Method**: `check_pending_verifications()`
-
-**Changes**:
-```python
-# Import Sas at the top
-from nio.crypto import Sas
-
-# In check_pending_verifications():
-if isinstance(verification, Sas):
-    other_device = getattr(verification, 'other_olm_device', None)
-    if other_device:
-        user_id = getattr(other_device, 'user_id', 'Unknown')
-        device_id = getattr(other_device, 'id', 'Unknown')
-    else:
-        user_id = 'Unknown'
-        device_id = 'Unknown'
-else:
-    user_id = getattr(verification, 'user_id', 'Unknown')
-    device_id = getattr(verification, 'device_id', 'Unknown')
-```
-
-**Benefits**:
-- TUI now correctly displays user ID and device ID for verification requests
-- Consistent with the fix in PR #69 for `verification.py`
-- Users can identify which device is requesting verification
-
-### Fix 2: Active Decryption Failure Recovery
-
-**File**: `chatrixcd/bot.py`
-**Method**: `megolm_event_callback()`
-
-**Changes**:
-```python
-async def megolm_event_callback(self, room: MatrixRoom, event: MegolmEvent):
-    # ... (decryption check)
-    
-    # Message couldn't be decrypted - actively work to fix this
-    logger.warning(f"Unable to decrypt message... Taking steps to establish encryption...")
-    
-    # Step 1: Query device keys for the sender
-    await self.client.keys_query({event.sender})
-    
-    # Step 2: Claim one-time keys to establish Olm sessions
-    if event.sender in self.client.device_store.users:
-        sender_devices = self.client.device_store[event.sender]
-        devices_to_claim = {}
-        for device_id, device in sender_devices.items():
-            if not self.client.olm.session_store.get(device.curve25519):
-                devices_to_claim[event.sender] = [device_id]
-        
-        if devices_to_claim:
-            await self.client.keys_claim(devices_to_claim)
-    
-    # Step 3: Request the room key
-    await self.client.request_room_key(event)
-    
-    # Step 4: Send the to-device messages
-    await self.client.send_to_device_messages()
-```
-
-**Benefits**:
-- Proactively queries device keys for senders
-- Establishes Olm sessions before requesting room keys
-- Ensures to-device messages are actually sent
-- Provides automatic recovery from decryption failures
-
-### Fix 3: Per-Sender Session Tracking
-
-**File**: `chatrixcd/bot.py`
-**Method**: `megolm_event_callback()`
-
-**Changes**:
-```python
-# Track by sender:session_id instead of just session_id
-session_key = f"{event.sender}:{event.session_id}"
-if session_key in self.requested_session_ids:
-    logger.debug("Already requested key for this session from this sender")
-    return
-
-# After successful request:
-self.requested_session_ids.add(session_key)
-
-# On failure:
-self.requested_session_ids.discard(session_key)
-```
-
-**Benefits**:
-- More accurate tracking of key requests
-- Prevents duplicate requests for the same sender+session combination
-- Allows requesting the same session ID from different senders if needed
-
-### Fix 4: Proactive Encryption Setup
-
-**File**: `chatrixcd/bot.py`
-**Method**: `sync_callback()`
-
-**Changes**:
-```python
-async def sync_callback(self, response: SyncResponse):
-    # ... (existing key management)
-    
-    # Collect users from all encrypted rooms
-    users_to_query = set()
-    for room_id, room_info in response.rooms.join.items():
-        room = self.client.rooms.get(room_id)
-        if room and room.encrypted:
-            for user_id in room.users:
-                if user_id != self.client.user_id:
-                    users_to_query.add(user_id)
-    
-    if users_to_query:
-        # Query device keys for all users
-        await self.client.keys_query(user_set=users_to_query)
-        
-        # On first sync, also claim one-time keys
-        if not self._encryption_setup_done:
-            # Claim keys for devices we don't have sessions with
-            devices_to_claim = {}
-            for user_id in users_to_query:
-                if user_id in self.client.device_store.users:
-                    for device_id, device in self.client.device_store[user_id].items():
-                        if not self.client.olm.session_store.get(device.curve25519):
-                            devices_to_claim.setdefault(user_id, []).append(device_id)
-            
-            if devices_to_claim:
-                await self.client.keys_claim(devices_to_claim)
-            
-            self._encryption_setup_done = True
-```
-
-**Benefits**:
-- Proactively queries device keys for all users in encrypted rooms
-- Establishes Olm sessions with all devices after first sync
-- Ensures the bot is ready to decrypt messages immediately
-- Maintains sessions with periodic key queries
-
-### Fix 5: Room Key Sharing After Verification
-
-**File**: `chatrixcd/verification.py`
-**Methods**: `confirm_verification()`, `auto_verify_pending()`
-
-**Changes**:
-```python
-async def confirm_verification(self, sas: Sas) -> bool:
-    # ... (existing verification)
-    
-    # Mark device as verified
-    if sas.other_olm_device:
-        self.client.verify_device(sas.other_olm_device)
-        
-        # Share room keys with the newly verified device
-        await self._share_room_keys_with_device(sas.other_olm_device)
-
-async def _share_room_keys_with_device(self, device):
-    # Get all encrypted rooms shared with the user
-    shared_rooms = []
-    for room_id, room in self.client.rooms.items():
-        if room.encrypted and device.user_id in room.users:
-            shared_rooms.append(room_id)
-    
-    # Share keys for each room
-    for room_id in shared_rooms:
-        await self.client.share_group_session(
-            room_id,
-            users=[device.user_id],
-            ignore_unverified_devices=False
-        )
-    
-    # Send the to-device messages
-    await self.client.send_to_device_messages()
-```
-
-**Benefits**:
-- Verified devices can immediately decrypt messages in shared encrypted rooms
-- Automatic room key sharing after both manual and auto-verification
-- Ensures verification is complete and functional
-
-## Testing
-
-### Updated Tests
-
-**File**: `tests/test_bot.py`
-
-Updated two existing tests to match the new encryption handling behavior:
-
-1. **test_decryption_failure_prevents_duplicate_requests**: 
-   - Now expects `sender:session_id` format for tracking
-   - Mocks additional encryption methods (`keys_query`, `send_to_device_messages`)
-
-2. **test_decryption_failure_allows_different_sessions**:
-   - Now expects `sender:session_id` format for tracking
-   - Verifies that different sessions from the same sender are each requested once
-
-### Test Results
-
-All 234 tests pass, including:
-- 16 verification tests (6 original + 10 E2E from PR #69)
-- 2 updated decryption tests
-- All existing tests remain passing
-- No regressions introduced
-
-## Expected Behavior After Fix
-
-### For Encrypted Message Handling
-
-1. **Bot receives encrypted message it can't decrypt**
-2. Bot logs: "Unable to decrypt message... Taking steps to establish encryption..."
-3. Bot queries device keys for the sender
-4. Bot claims one-time keys to establish Olm sessions with sender's devices
-5. Bot requests the room key from sender
-6. Bot sends to-device messages to deliver the request
-7. **Sender's device receives the request and shares the key**
-8. **Bot can now decrypt future messages in that session**
-
-### For Encrypted Room Initialization
-
-1. **Bot starts and logs in**
-2. **Bot performs first sync**
-3. Bot identifies encrypted rooms and their members
-4. Bot logs: "Initial encryption setup: Found X encrypted room(s) with Y unique user(s)"
-5. Bot queries device keys for all users
-6. Bot claims one-time keys to establish Olm sessions
-7. Bot logs: "Successfully established Olm sessions with Z device(s)"
-8. **Bot is ready to decrypt messages from all room members**
-
-### For Device Verification
-
-1. **User initiates verification from Element (or another client)**
-2. **Bot receives verification request**
-3. **TUI displays**: "New verification request from @user:server (device: DEVICEID)"
-4. User accepts verification in TUI
-5. Bot confirms verification and marks device as verified
-6. **Bot shares room keys for all shared encrypted rooms with the verified device**
-7. Bot logs: "Sharing room keys for X encrypted room(s) with verified device"
-8. **Verified device can now decrypt messages in shared rooms**
-
-### For TUI Verification Requests
-
-1. **Verification request arrives**
-2. **TUI notification shows**: "New verification request from @user:server"
-3. **TUI Sessions menu shows**: "User: @user:server, Device: DEVICEID123"
-4. No more "Unknown" entries
-5. User can identify and verify the correct device
-
-## Breaking Changes
-
-None. All changes are backwards-compatible and improve existing functionality.
-
-## Migration Notes
-
-### For Users
-
-No configuration changes required. The improvements are automatic:
-- Existing verified devices remain verified
-- Encryption sessions are automatically established
-- Room keys are automatically shared after verification
-
-### For Developers
-
-If you have custom encryption handling:
-1. Note that `requested_session_ids` now uses `sender:session_id` format
-2. The `megolm_event_callback` now performs proactive encryption setup
-3. The `sync_callback` performs initial encryption setup on first sync
-4. Verification methods now share room keys automatically
-
-## Performance Impact
-
-The changes add some additional network operations:
-- Device key queries for senders of undecryptable messages (minimal, one-time per sender)
-- Initial one-time key claims after first sync (one-time per device)
-- Proactive device key queries during sync (minimal, cached by matrix-nio)
-- Room key sharing after verification (minimal, one-time per verification)
-
-These operations are necessary for proper end-to-end encryption and have negligible performance impact.
-
-## Security Considerations
-
-The changes improve security posture:
-- **Better key management**: Proactive key queries ensure up-to-date device information
-- **Proper session establishment**: One-time keys are claimed securely
-- **Room key sharing only for verified devices**: Keys are only shared after successful verification
-- **No trust-on-first-use compromises**: All existing security checks remain in place
-
-## Matrix Protocol Compliance
-
-All changes comply with the Matrix specification:
-- Device key queries follow the Matrix Key Distribution spec
-- One-time key claims follow the Olm protocol
-- Room key sharing follows the Megolm protocol
-- To-device messages are sent as required by the spec
-
-## Related Issues
-
-This fix addresses the issues described in the problem statement:
-- Fixes remaining "Unknown" device displays in TUI (same as PR #69 but for TUI)
-- Fixes verification timeout issues by properly establishing sessions
-- Fixes "Failed to request room key" errors with proactive session establishment
-- Fixes decryption failures with automatic recovery
-- Ensures verified devices can decrypt messages
-
-## Files Modified
-
-1. `chatrixcd/tui.py`: Fix device info extraction in `check_pending_verifications()`
-2. `chatrixcd/bot.py`: 
-   - Improve `megolm_event_callback()` with proactive encryption setup
-   - Enhance `sync_callback()` with initial encryption setup
-   - Add `_encryption_setup_done` tracking
-3. `chatrixcd/verification.py`:
-   - Add `_share_room_keys_with_device()` method
-   - Update `confirm_verification()` to share room keys
-   - Update `auto_verify_pending()` to share room keys
-4. `tests/test_bot.py`: Update tests to match new behavior
-5. `CHANGELOG.md`: Document all changes
-
-## Verification Steps
-
-To verify the fixes work:
-
-1. **Start ChatrixCD in TUI mode**
-2. **Join an encrypted room with other users**
-3. **Observe logs**: Should see "Initial encryption setup" messages
-4. **Send encrypted message from another client**
-5. **Bot should decrypt the message** without errors
-6. **Initiate verification from another client**
-7. **TUI should show**: "New verification request from @user:server (device: DEVICEID)"
-8. **Accept verification in TUI**
-9. **Other client should receive verification success**
-10. **Both devices can exchange encrypted messages**
-
-## Future Improvements
-
-While these fixes resolve the immediate issues, potential future enhancements include:
-
-1. **Retry logic for failed key claims**: Automatic retry with exponential backoff
-2. **Periodic session refresh**: Refresh Olm sessions periodically to prevent staleness
-3. **Better error messages**: More detailed error reporting for encryption failures
-4. **Metrics**: Track encryption success rates and session establishment times
-5. **Cross-signing support**: When matrix-nio adds support, implement cross-signing
-
-## References
-
-- [Matrix Specification - End-to-End Encryption](https://spec.matrix.org/latest/client-server-api/#end-to-end-encryption)
-- [Matrix Specification - Device Management](https://spec.matrix.org/latest/client-server-api/#device-management)
-- [matrix-nio Documentation](https://matrix-nio.readthedocs.io/)
-- [Olm Specification](https://gitlab.matrix.org/matrix-org/olm/-/blob/master/docs/olm.md)
-- [Megolm Specification](https://gitlab.matrix.org/matrix-org/olm/-/blob/master/docs/megolm.md)
diff --git a/FEATURE_SUMMARY.md b/FEATURE_SUMMARY.md
deleted file mode 100644
index a40836a..0000000
--- a/FEATURE_SUMMARY.md
+++ /dev/null
@@ -1,248 +0,0 @@
-# Feature Implementation Summary
-
-## Overview
-
-This document summarizes the implementation of new features for the ChatrixCD bot, including threaded responses, reaction-based confirmations, markdown parsing, and enhanced bot personality.
-
-## Implemented Features
-
-### 1. Threaded Responses (Matrix Spec v1.16)
-
-**Implementation:**
-- Updated `bot.py` `send_message()` method to accept `reply_to_event_id` parameter
-- Added threading relationship with `m.relates_to` field in message content
-- Follows Matrix spec for thread support with `rel_type: "m.thread"`
-- Uses `is_falling_back: true` and `m.in_reply_to` for client compatibility
-
-**Benefits:**
-- Keeps conversations organized in chat rooms
-- Easier to follow command responses in busy channels
-- Better context for users and admins
-
-**Code Changes:**
-- `chatrixcd/bot.py`: Lines 696-735 (updated `send_message` method)
-- `chatrixcd/commands.py`: All command methods now pass `reply_to_event_id`
-
-### 2. User Name Addressing
-
-**Implementation:**
-- Added `_get_display_name()` helper method to extract username from Matrix user ID
-- All bot responses now include personalized greeting (e.g., "username 👋")
-- Provides friendly, engaging interaction style
-
-**Benefits:**
-- More personal and engaging user experience
-- Users feel acknowledged and valued
-- Consistent with the bot's sassy personality
-
-**Code Changes:**
-- `chatrixcd/commands.py`: Lines 192-204 (new `_get_display_name` method)
-- All command methods updated to address users by name
-
-### 3. Reaction-Based Confirmations
-
-**Implementation:**
-- Added `reaction_callback()` in `bot.py` to handle Matrix reaction events
-- Added `handle_reaction()` in `commands.py` to process confirmation reactions
-- Tracks confirmation message IDs in `confirmation_message_ids` dictionary
-- Supports multiple reaction types:
-  - **Positive:** 👍, ✅, ✓, ☑, 🆗, yes, y
-  - **Negative:** 👎, ❌, ✖, ⛔, 🚫, no, n
-
-**Security:**
-- Only the user who initiated the command can use reactions
-- Other admins must reply with messages (not reactions)
-- Non-admins receive a polite brush-off message
-
-**Benefits:**
-- Faster confirmation workflow
-- More intuitive user interaction
-- Reduces typing for mobile users
-
-**Code Changes:**
-- `chatrixcd/bot.py`: Lines 697-735 (new `reaction_callback` method)
-- `chatrixcd/commands.py`: Lines 106-180 (new `handle_reaction` method)
-- Updated `run_task()` and `exit_bot()` to track message IDs
-
-### 4. Markdown Parsing with ¶ Paragraph Support
-
-**Implementation:**
-- Added `_format_description()` method to parse Semaphore descriptions
-- Converts ¶ symbol to double newlines (paragraph breaks)
-- Preserves other markdown formatting (bold, italic, links, etc.)
-- Applied to template descriptions and other Semaphore content
-
-**Benefits:**
-- Better formatting for long descriptions
-- Easier to read template documentation
-- Consistent with markdown standards
-
-**Code Changes:**
-- `chatrixcd/commands.py`: Lines 418-430 (new `_format_description` method)
-- Applied in `list_templates()` and `run_task()` methods
-
-### 5. Enhanced Bot Personality
-
-**Implementation:**
-- Added randomized response messages throughout
-- Increased emoji usage in all responses
-- Varied tone from helpful to sassy (but never rude)
-- User-friendly error messages with personality
-
-**Response Examples:**
-- "On it! Starting **Task Name**... 🚀"
-- "Here we go! Running **Task Name**... 🏃"
-- "Roger that! Executing **Task Name**... 🫡"
-- "Yes boss! Starting **Task Name**... 💪"
-
-**Benefits:**
-- More engaging and fun user experience
-- Reduces bot monotony
-- Builds user rapport and connection
-
-**Code Changes:**
-- `chatrixcd/commands.py`: Added randomized response arrays in multiple methods
-- Updated brush-off messages for non-admins
-- Enhanced timeout and confirmation messages
-
-### 6. Easter Egg Commands
-
-**Implementation:**
-Two undocumented commands for fun interactions:
-
-**`!cd pet`** - Positive reinforcement
-- Bot responds with appreciation messages
-- Random responses include various happy emoji
-- Examples:
-  - "Aww, thanks {user}! 🥰 *happy bot noises*"
-  - "You're the best! 😊 *purrs digitally*"
-  - "*wags virtual tail* Thanks {user}! 🐕💻"
-
-**`!cd scold`** - Negative feedback
-- Bot responds with apologetic messages
-- Random responses include various sad emoji
-- Examples:
-  - "Oh no, {user}! 😢 I'll try harder, I promise!"
-  - "Sorry {user}... 😔 What did I do wrong?"
-  - "*sad beep* {user}, I'll do better next time... 😞"
-
-**Benefits:**
-- Adds personality and humor
-- Encourages user engagement
-- Creates memorable bot interactions
-- Fun discovery for users
-
-**Code Changes:**
-- `chatrixcd/commands.py`: Lines 1091-1152 (new `handle_pet` and `handle_scold` methods)
-- Added to command router in `handle_message()`
-
-### 7. Updated Copilot Instructions
-
-**Implementation:**
-- Added bot personality section to `.github/copilot-instructions.md`
-- Documented sassy but friendly approach
-- Emphasized emoji usage and variety
-- Documented easter egg commands
-- Added threading and reaction guidelines
-
-**Benefits:**
-- Future contributors understand bot personality
-- Consistent tone in new features
-- Preservation of bot character
-
-## Testing
-
-### New Tests Added
-
-1. **`test_get_display_name()`** - Tests username extraction
-2. **`test_format_description_with_paragraph_symbol()`** - Tests ¶ parsing
-3. **`test_handle_pet_command()`** - Tests pet easter egg
-4. **`test_handle_scold_command()`** - Tests scold easter egg
-5. **`test_handle_message_with_threading()`** - Tests thread support
-6. **`test_handle_reaction_positive()`** - Tests thumbs up confirmation
-7. **`test_handle_reaction_negative()`** - Tests thumbs down cancellation
-8. **`test_handle_reaction_wrong_user()`** - Tests reaction security
-
-### Test Results
-
-All 49 tests pass successfully:
-- 45 existing tests (updated for new signatures)
-- 8 new tests for new features
-- No regressions in existing functionality
-
-## Compatibility
-
-### Matrix Specification
-- Follows Matrix spec v1.16 for threading
-- Uses `m.annotation` relationship type for reactions
-- Compatible with Element, Nheko, FluffyChat, and other Matrix clients
-
-### Dependencies
-No new dependencies required:
-- Uses existing `matrix-nio` SDK
-- Threading and reactions supported natively
-- No breaking changes to existing configurations
-
-## Documentation Updates
-
-### User-Facing
-- Help command now mentions reaction support
-- Tip added about using reactions for confirmations
-
-### Developer-Facing
-- Updated `.github/copilot-instructions.md` with personality guidelines
-- This `FEATURE_SUMMARY.md` document
-- Code comments explain threading and reaction logic
-
-## Future Enhancements
-
-Potential improvements for future versions:
-
-1. **Extended Reaction Support**
-   - Custom reaction configurations
-   - More emoji variations
-   - Reaction-based voting for admin decisions
-
-2. **Rich Markdown**
-   - Full markdown parser for Semaphore content
-   - Code block formatting
-   - Table support
-
-3. **Personality Profiles**
-   - Configurable bot personality levels
-   - Different tones (professional, casual, funny)
-   - Per-room personality settings
-
-4. **More Easter Eggs**
-   - Hidden achievements
-   - Status messages with personality
-   - Fun facts about CI/CD
-
-## Migration Guide
-
-### For Existing Installations
-
-No migration required! Changes are backward compatible:
-- All existing commands work as before
-- New features are opt-in (reactions are alternative, not replacement)
-- Configuration files unchanged
-
-### For Developers
-
-Update bot interaction code to:
-1. Pass `event.event_id` when calling command handlers
-2. Handle `reply_to_event_id` parameter in custom commands
-3. Follow personality guidelines for new features
-
-## Conclusion
-
-These features significantly enhance the ChatrixCD bot's user experience while maintaining compatibility and reliability. The bot is now more engaging, intuitive, and fun to use, while still providing powerful CI/CD automation capabilities.
-
-The implementation follows best practices with:
-- ✅ Comprehensive test coverage
-- ✅ Clear documentation
-- ✅ Backward compatibility
-- ✅ Security considerations
-- ✅ Matrix specification compliance
-
-All features are production-ready and tested!
diff --git a/IMPLEMENTATION_NOTES.md b/IMPLEMENTATION_NOTES.md
deleted file mode 100644
index 0dceb49..0000000
--- a/IMPLEMENTATION_NOTES.md
+++ /dev/null
@@ -1,293 +0,0 @@
-# Implementation Notes: Concurrent Architecture and Message Management
-
-## Summary
-
-This document describes the implementation of the concurrent architecture improvements and message management system for ChatrixCD.
-
-## Problem Statement
-
-The original issue requested:
-1. Application should be threaded to better leverage multicore systems
-2. Separate runners for listener, TUI, and handlers
-3. Extract response messages to `messages.json` for easier modification
-4. Unit tests should handle dynamic responses
-5. Auto-reload `config.json`, `aliases.json`, and `messages.json` when modified
-
-## Implementation Decisions
-
-### 1. Async vs Threading
-
-**Decision**: Use asyncio (async/await) instead of OS threads
-
-**Rationale**:
-- The bot's workload is primarily I/O-bound (Matrix sync, API calls)
-- Core dependencies (matrix-nio, Textual, aiohttp) are async-native
-- Python's GIL limits threading benefits for I/O-bound tasks
-- Async provides better performance and simpler concurrency model
-
-**Benefits**:
-- No race conditions from shared state
-- Lower memory footprint
-- Better performance for I/O operations
-- Explicit concurrency points (await)
-- Easier to debug and maintain
-
-### 2. Message Management System
-
-**Decision**: Create `MessageManager` class with hot-reload support
-
-**Implementation**:
-```python
-# chatrixcd/messages.py
-class MessageManager:
-    - Loads messages from messages.json
-    - Falls back to DEFAULT_MESSAGES if file missing
-    - Supports hot-reload via async file watching
-    - Thread-safe message access
-```
-
-**Features**:
-- 8 message categories (greetings, cancel, timeout, etc.)
-- Custom messages override defaults
-- Format strings with {name}, {user_name}, {task_name}
-- Random selection for variety
-- Graceful error handling
-
-### 3. Async File Watching
-
-**Decision**: Implement async file monitoring for all config files
-
-**Implementation**:
-```python
-async def _auto_reload_loop(self):
-    while True:
-        await asyncio.sleep(5)  # Non-blocking
-        if self.check_for_changes():
-            self.load_messages()
-```
-
-**Applied to**:
-- `messages.json` - Check every 5 seconds
-- `aliases.json` - Check every 5 seconds
-- `config.json` - Check every 10 seconds
-
-**Features**:
-- Non-blocking monitoring
-- Automatic reload on file modification
-- Graceful handling of missing files
-- Safe for unit tests (no loop required)
-
-### 4. Concurrent Components
-
-**Current Architecture**:
-```
-AsyncIO Event Loop (Single Thread)
-├── Matrix Sync Loop (async)
-├── TUI Event Handler (async)
-├── Command Execution (async)
-├── File Watchers (async)
-│   ├── messages.json watcher
-│   ├── aliases.json watcher
-│   └── config.json watcher
-└── Task Monitors (async)
-```
-
-**Concurrency Achieved**:
-- All components run concurrently
-- Non-blocking I/O operations
-- Cooperative multitasking
-- Efficient resource usage
-
-## Code Changes
-
-### New Files
-
-1. **chatrixcd/messages.py** (342 lines)
-   - MessageManager class
-   - DEFAULT_MESSAGES constant
-   - Async file watching
-
-2. **messages.json.example** (91 lines)
-   - Example message configuration
-   - All 8 message categories
-   - Format string examples
-
-3. **tests/test_messages.py** (126 lines)
-   - 8 comprehensive tests
-   - File loading tests
-   - Hot-reload tests
-   - Format string tests
-
-4. **CONCURRENT_ARCHITECTURE.md** (287 lines)
-   - Architecture explanation
-   - Async vs threading comparison
-   - Performance characteristics
-   - Future enhancements
-
-5. **docs/CUSTOMIZATION.md** (431 lines)
-   - User guide for customization
-   - Message categories explained
-   - Hot-reload usage
-   - Troubleshooting
-
-### Modified Files
-
-1. **chatrixcd/commands.py**
-   - Removed hardcoded message lists (50 lines removed)
-   - Added MessageManager integration
-   - All responses now use message_manager.get_random_message()
-
-2. **chatrixcd/aliases.py**
-   - Added auto_reload parameter
-   - Implemented check_for_changes()
-   - Added start_auto_reload() and stop_auto_reload()
-   - Async monitoring loop
-
-3. **chatrixcd/config.py**
-   - Added auto_reload parameter
-   - Implemented check_for_changes()
-   - Added start_auto_reload() and stop_auto_reload()
-   - Async monitoring loop
-
-4. **chatrixcd/bot.py**
-   - Start auto-reload in run() method
-   - Ensure watchers start when event loop available
-
-5. **CHANGELOG.md**
-   - Documented all new features
-   - Added message customization section
-   - Added async file watching section
-
-6. **.gitignore**
-   - Added messages.json (runtime file)
-   - Added demo_file_watching.py
-
-## Testing
-
-### Test Coverage
-
-**New Tests**: 8 tests in test_messages.py
-- File loading from disk
-- Default fallback behavior
-- Message formatting
-- Random selection
-- Category validation
-- File change detection
-- Custom message override
-
-**All Tests**: 279 tests total
-- 100% passing
-- No test failures
-- No regressions
-
-### Security
-
-**CodeQL Analysis**: 0 alerts
-- No security vulnerabilities introduced
-- Safe file handling
-- No injection risks
-
-## Performance Impact
-
-### Memory
-- **Minimal increase**: ~50KB for message cache
-- **Efficient**: Messages loaded once, reused
-
-### CPU
-- **Negligible**: File checks every 5-10 seconds
-- **Non-blocking**: Async monitoring
-- **Efficient**: Only reload on actual changes
-
-### Latency
-- **No impact**: Response time unchanged
-- **Concurrent**: Monitoring doesn't block operations
-
-## User Experience
-
-### Before
-- Messages hardcoded in Python
-- Restart required for changes
-- Difficult to customize personality
-- No separation of concerns
-
-### After
-- Messages in JSON file
-- Changes apply without restart
-- Easy personality customization
-- Clear separation of config/code
-
-## Migration Path
-
-### For Existing Users
-
-1. **No breaking changes**: Bot works without messages.json
-2. **Opt-in**: Copy messages.json.example to customize
-3. **Defaults preserved**: Original messages used as defaults
-4. **Backward compatible**: No config changes required
-
-### For New Users
-
-1. **Follow quickstart**: Standard setup process
-2. **Optional customization**: Use messages.json.example
-3. **Documentation**: CUSTOMIZATION.md guide
-
-## Known Limitations
-
-1. **Event loop required**: Auto-reload needs async context
-   - **Impact**: Tests must handle gracefully
-   - **Solution**: Graceful degradation if no loop
-
-2. **File system latency**: 5-10 second delay for changes
-   - **Impact**: Not instant reload
-   - **Solution**: Acceptable for config changes
-
-3. **Matrix auth settings**: Some config needs restart
-   - **Impact**: Homeserver/auth_type changes require restart
-   - **Solution**: Documented in user guide
-
-## Future Enhancements
-
-### Possible Additions
-
-1. **Web UI for customization**
-   - Edit messages through browser
-   - Live preview
-   - Validation
-
-2. **Message templates**
-   - Pre-built personality packs
-   - Community contributions
-   - Import/export
-
-3. **Dynamic intervals**
-   - Configurable check intervals
-   - Adaptive monitoring
-   - Performance tuning
-
-4. **Change notifications**
-   - Matrix notification on reload
-   - Admin alerts
-   - Change history
-
-## Conclusion
-
-The implementation successfully addresses all requirements from the issue:
-
-✅ **Concurrent execution** via async/await (superior to threading)
-✅ **Separate concurrent components** (Matrix, TUI, commands, watchers)
-✅ **Message externalization** via messages.json
-✅ **Dynamic responses** with hot-reload
-✅ **Auto-reload** for all config files
-✅ **Comprehensive testing** (279 tests, 100% passing)
-✅ **Security verified** (0 CodeQL alerts)
-✅ **Full documentation** (architecture, user guide, examples)
-
-The async architecture provides better performance and maintainability than threading would for this I/O-bound workload.
-
-## References
-
-- **CONCURRENT_ARCHITECTURE.md**: Technical architecture details
-- **docs/CUSTOMIZATION.md**: User customization guide
-- **CHANGELOG.md**: Complete change log
-- **messages.json.example**: Example configuration
-- **tests/test_messages.py**: Test suite
diff --git a/IMPLEMENTATION_SUMMARY.md b/IMPLEMENTATION_SUMMARY.md
deleted file mode 100644
index 1497338..0000000
--- a/IMPLEMENTATION_SUMMARY.md
+++ /dev/null
@@ -1,255 +0,0 @@
-# Build and Release Workflow Implementation Summary
-
-This document summarizes the implementation of the new Nuitka-based build and release workflow for ChatrixCD.
-
-## Changes Made
-
-### 1. Created New Build Workflow (`.github/workflows/build.yml`)
-
-Implemented a comprehensive GitHub Actions workflow that:
-
-- **Triggers**:
-  - Automatically on PR merges to `main` (creates pre-release with `-dev` suffix)
-  - Manually via `workflow_dispatch` (creates production or pre-release)
-
-- **Build Jobs**:
-  - `build-linux`: Builds for x86_64, i686, and ARM64
-    - x86_64: Native build with Nuitka-Action
-    - i686: Docker cross-compilation using `i386/python:3.12-slim`
-    - ARM64: Docker cross-compilation using `arm64v8/python:3.12-slim`
-  
-  - `build-windows`: Builds for x86_64 and ARM64
-    - Uses Nuitka-Action with Windows-specific metadata
-    - Includes icon and version information
-  
-  - `build-macos`: Builds universal binary
-    - Single binary supporting both x86_64 and ARM64
-    - Creates application bundle (ChatrixCD.app)
-
-- **Release Job**:
-  - Downloads all build artifacts
-  - Creates GitHub Release with all binaries
-  - Updates version files (for production releases)
-  - Updates CHANGELOG.md (for production releases)
-  - Creates git tags
-  - Handles pre-release vs production release logic
-
-### 2. Updated Test Workflow (`.github/workflows/test.yml`)
-
-Added validation job that:
-- Runs workflow configuration tests
-- Validates workflow YAML syntax with actionlint
-- Runs on all PRs to ensure build configuration is valid
-
-### 3. Created Icon Files
-
-Generated platform-specific icons from existing SVG logo:
-
-- **`assets/icon.ico`**: Windows executable icon (multi-resolution)
-- **`assets/icon.png`**: macOS/Linux icon (512x512 PNG)
-
-### 4. Created Comprehensive Test Suite (`tests/test_workflow.py`)
-
-Implemented 15 test cases covering:
-- Workflow file existence and validity
-- Required triggers (PR merge and manual)
-- Test job configuration
-- Platform build matrix (all required platforms)
-- Nuitka-Action usage
-- Version calculation logic
-- Release job configuration
-- Pre-release handling
-- Metadata inclusion
-- Asset bundling
-- Icon file validation
-
-### 5. Updated `.gitignore`
-
-Added Nuitka-specific build artifacts:
-```
-*.build/
-*.dist/
-*.onefile-build/
-chatrixcd-linux-*
-chatrixcd-windows-*
-chatrixcd-macos-*
-ChatrixCD.app/
-```
-
-### 6. Created Documentation
-
-**`docs/BUILD_WORKFLOW.md`**: Comprehensive documentation covering:
-- Overview of the build process
-- Workflow triggers (automatic and manual)
-- Version scheme (calendar + semantic versioning)
-- Build process for each platform
-- Build artifacts
-- Release process
-- Testing approach
-- Icons and metadata
-- Troubleshooting guide
-- Development guidelines
-
-### 7. Updated README.md
-
-Added sections for:
-- Pre-built binaries download information
-- Updated releases section with production vs pre-release distinction
-- Links to build workflow documentation
-
-### 8. Removed Old Workflow
-
-Deleted `.github/workflows/release.yml` as it's completely superseded by the new build workflow.
-
-## Key Features
-
-### Multi-Platform Support
-
-- **Linux**: x86_64, i686 (32-bit), ARM64
-- **Windows**: x86_64, ARM64
-- **macOS**: Universal (x86_64 + ARM64)
-
-### Pre-release vs Production
-
-- **Pre-releases** (automatic on PR merge):
-  - Version: `YYYY.MM.DD.MAJOR.MINOR.PATCH-dev`
-  - Marked as pre-release on GitHub
-  - No version file updates
-  - No CHANGELOG updates
-
-- **Production releases** (manual trigger):
-  - Version: `YYYY.MM.DD.MAJOR.MINOR.PATCH`
-  - Updates version in code
-  - Updates CHANGELOG.md
-  - Creates git tag
-  - Standard GitHub release
-
-### Build Metadata
-
-Windows builds include:
-- Company name: "ChatrixCD Contributors"
-- Product name: "ChatrixCD"
-- File description: "Matrix bot for CI/CD automation with Semaphore UI"
-- Copyright: "Copyright (c) 2024 ChatrixCD Contributors"
-- Version information
-- Application icon
-
-### Comprehensive Testing
-
-- Unit tests run before any builds
-- Workflow configuration validated on every PR
-- Icon files validated
-- All 270 existing tests pass
-- 15 new workflow-specific tests added
-
-## Technical Implementation Details
-
-### Cross-Compilation Strategy
-
-1. **Linux x86_64**: Native compilation on ubuntu-latest runner
-2. **Linux i686**: Docker-based cross-compilation
-   - Uses `i386/python:3.12-slim` base image
-   - Installs gcc, patchelf, ccache
-   - Runs Nuitka within container
-3. **Linux ARM64**: Docker-based cross-compilation
-   - Uses `arm64v8/python:3.12-slim` base image
-   - Emulated via Docker's ARM64 support
-4. **Windows x86_64**: Native compilation on windows-latest runner
-5. **Windows ARM64**: Native compilation with ARM64 target
-6. **macOS Universal**: Native compilation with `universal2` target
-
-### Nuitka Configuration
-
-All builds use:
-- `--onefile`: Single executable file
-- `--standalone`: No external dependencies
-- `--enable-plugin=anti-bloat`: Optimize size
-- `--include-data-dir=assets=assets`: Bundle assets
-- Platform-specific icons
-- Metadata (Windows)
-
-### Version Calculation
-
-Calendar versioning with semantic components:
-```
-YYYY.MM.DD.MAJOR.MINOR.PATCH[-dev]
-```
-
-Example flow:
-1. Latest tag: `2025.10.20.0.0.5`
-2. User triggers: `patch` release
-3. New version: `2025.10.21.0.0.6`
-
-Version increments never reset, ensuring uniqueness.
-
-### Asset Bundling
-
-All executables include:
-- `assets/` directory (logos, icons)
-- All Python modules compiled
-- All dependencies statically linked
-
-## Testing Results
-
-All tests pass successfully:
-
-```
-Ran 270 tests in 8.573s
-
-OK
-```
-
-This includes:
-- 255 existing tests (unchanged)
-- 15 new workflow tests
-- All icon validation tests
-- All workflow configuration tests
-
-## Files Changed
-
-1. **Created**:
-   - `.github/workflows/build.yml` (new build workflow)
-   - `tests/test_workflow.py` (workflow tests)
-   - `assets/icon.ico` (Windows icon)
-   - `assets/icon.png` (macOS/Linux icon)
-   - `docs/BUILD_WORKFLOW.md` (documentation)
-
-2. **Modified**:
-   - `.github/workflows/test.yml` (added workflow validation)
-   - `.gitignore` (added Nuitka artifacts)
-   - `README.md` (added pre-built binaries info)
-
-3. **Deleted**:
-   - `.github/workflows/release.yml` (replaced by build.yml)
-
-## Requirements Satisfied
-
-All requirements from the problem statement have been met:
-
-✅ Updated build and release workflow to use Nuitka-Action  
-✅ Created prebuilt artifacts for multiple platforms  
-✅ Linux: x86_64, i686, arm64  
-✅ Windows: x86_64, arm64  
-✅ macOS: universal (x86_64 + arm64)  
-✅ Part of PR acceptance workflow  
-✅ Automated artifacts on PR merge labeled as pre-release with `-dev` suffix  
-✅ Manual trigger for production releases  
-✅ Appropriate metadata included  
-✅ Icons added where relevant  
-✅ Comprehensive test suite created  
-
-## Next Steps
-
-1. Merge this PR to enable the new workflow
-2. Test automatic pre-release creation on next PR merge
-3. Test manual production release creation
-4. Monitor build times and artifact sizes
-5. Gather feedback on binary usability
-
-## Notes
-
-- Build times are approximately 15-25 minutes total (parallel builds)
-- Artifacts are retained for 90 days in GitHub Actions
-- All builds are reproducible and deterministic
-- No manual intervention required for pre-releases
-- Production releases require manual workflow trigger
diff --git a/TESTING_INSTRUCTIONS.md b/TESTING_INSTRUCTIONS.md
deleted file mode 100644
index 9432956..0000000
--- a/TESTING_INSTRUCTIONS.md
+++ /dev/null
@@ -1,142 +0,0 @@
-# Testing Instructions for Build Workflow Fixes
-
-## ⚠️ IMPORTANT: Action Required
-
-The build workflow fixes have been implemented and committed to the `copilot/build-windows-macos-binary` branch. **The workflow will automatically run when this PR is opened/updated**.
-
-The workflow triggers on:
-1. Pull requests to `main` (opens/updates) - **This is how to test before merge**
-2. Pull request merge to `main` (for actual release creation)
-3. Manual workflow dispatch (from default branch only)
-
-## How to Test
-
-### Option 1: Test via Pull Request (Recommended)
-
-The workflow is configured to run on pull requests to `main`. If a PR exists for this branch:
-
-1. Navigate to the Pull Request page
-2. The workflow should run automatically when the PR is opened/updated
-3. Check the "Checks" tab at the bottom of the PR to see the workflow status
-4. All 7 jobs should complete successfully
-
-**Note:** The workflow runs on the `pull_request` trigger when the PR is opened or updated, but it will only proceed to the "Create Release" step if the PR is actually merged.
-
-### Option 2: Manual Workflow Dispatch (From Main Branch)
-
-The manual workflow dispatch only works from branches where the workflow file exists. To test from the feature branch:
-
-1. First, ensure this PR is created (which you've already done)
-2. The workflow will automatically run on the PR
-3. Alternatively, you can merge the PR to `main` (after review) and then use workflow dispatch from `main` for future releases
-
-**Important:** GitHub Actions workflow dispatch only shows branches where the workflow file exists. Since this is a feature branch with workflow changes, the PR-based testing is the primary method.
-
-## What to Verify
-
-Once the workflow runs successfully, verify the following:
-
-### ✅ All Jobs Complete Successfully
-- [ ] Run Unit Tests
-- [ ] Build Linux x86_64
-- [ ] Build Linux i686
-- [ ] Build Linux arm64
-- [ ] Build Windows x86_64
-- [ ] Build macOS Universal
-- [ ] Create Release
-
-### ✅ Artifacts Are Generated
-Navigate to the workflow run and check the "Artifacts" section at the bottom. You should see:
-
-1. **chatrixcd-linux-x86_64** - Linux 64-bit binary
-2. **chatrixcd-linux-i686** - Linux 32-bit binary
-3. **chatrixcd-linux-arm64** - Linux ARM 64-bit binary
-4. **chatrixcd-windows-x86_64** - Windows .exe file
-5. **chatrixcd-macos-universal** - macOS binary and .app bundle
-
-### ✅ Download and Test Artifacts (Optional)
-
-1. Download each artifact from the workflow run
-2. Extract the zip files
-3. Verify file sizes are reasonable (not 0 bytes)
-4. Optionally test execution:
-
-**Linux:**
-```bash
-chmod +x chatrixcd-linux-x86_64
-./chatrixcd-linux-x86_64 --version
-```
-
-**Windows:**
-```cmd
-chatrixcd-windows-x86_64.exe --version
-```
-
-**macOS:**
-```bash
-./chatrixcd-macos-universal --version
-# or
-open ChatrixCD.app
-```
-
-## Expected Results
-
-### Build Times
-- **Linux x86_64:** ~5-10 minutes
-- **Linux i686:** ~20-25 minutes (Docker build)
-- **Linux arm64:** ~25-35 minutes (QEMU emulation)
-- **Windows:** ~8-12 minutes
-- **macOS:** ~8-12 minutes
-- **Total:** ~45-60 minutes for all builds
-
-### Known Working Configurations
-All builds should complete with:
-- Python 3.12
-- Nuitka latest (main branch)
-- matrix-nio[e2e] >= 0.24.0 with libolm
-
-## Troubleshooting
-
-### If Windows Build Fails
-Check the "Install libolm (Windows)" step logs for:
-- Successful cmake build
-- Presence of `olm_static.lib` in `C:\olm-install\lib`
-- Successful copy to `olm.lib`
-
-### If macOS Build Fails
-Check the "Install dependencies" step logs for:
-- Successful homebrew installation of libolm, pkg-config, and cmake
-- No CMake version compatibility errors
-
-### If ARM64 Build Fails
-Check for:
-- QEMU setup completed successfully
-- Docker Buildx setup completed
-- Image pull successful: `arm64v8/python:3.12-slim`
-- No "exec format error" in the build step
-
-## Changes Made
-
-See [BUILD_FIX_SUMMARY.md](BUILD_FIX_SUMMARY.md) for a complete list of all changes and fixes applied.
-
-## After Successful Test
-
-Once all builds complete successfully:
-
-1. ✅ Mark this PR as ready for review
-2. ✅ Request final review from maintainers
-3. ✅ Merge to `main` when approved
-
-## Questions?
-
-If the workflow fails or you encounter any issues:
-1. Check the workflow logs for specific error messages
-2. Compare against the known issues in BUILD_FIX_SUMMARY.md
-3. Review the specific job logs that failed
-4. Open an issue with the error details if needed
-
----
-
-**Prepared by:** GitHub Copilot Workspace Agent
-**Date:** October 24, 2024
-**Branch:** `copilot/build-windows-macos-binary`
diff --git a/TESTING_REVIEW.md b/TESTING_REVIEW.md
deleted file mode 100644
index cca3332..0000000
--- a/TESTING_REVIEW.md
+++ /dev/null
@@ -1,196 +0,0 @@
-# Testing and Matrix SDK Integration Review
-
-## Executive Summary
-
-This document summarizes the comprehensive code review of ChatrixCD's unit tests and Matrix SDK integration, conducted to assess test quality, coverage, and proper utilization of the Matrix SDK features.
-
-## Review Findings
-
-### Test Suite Quality Assessment
-
-#### Overall Metrics
-- **Total Tests**: 176 (increased from 167)
-- **Overall Coverage**: 56%
-- **All Tests Passing**: ✅ Yes
-
-#### Module-Specific Coverage
-| Module | Coverage | Status | Notes |
-|--------|----------|--------|-------|
-| `redactor.py` | 93% | ✅ Excellent | Privacy features well covered |
-| `commands.py` | 84% | ✅ Good | Command handler well tested |
-| `config.py` | 83% | ✅ Good | Comprehensive config and migration tests |
-| `semaphore.py` | 81% | ✅ Good | API client thoroughly tested |
-| `bot.py` | 80% | ✅ Good | Core bot functionality tested (improved from 75%) |
-| `auth.py` | 38% | ⚠️ Needs Work | OIDC flows require integration tests |
-| `main.py` | 33% | ⚠️ Needs Work | Entry point needs integration tests |
-| `tui.py` | 17% | ⚠️ Needs Work | TUI needs more comprehensive tests |
-
-### Issues Identified and Resolved
-
-#### 1. Trivial Tests (FIXED ✅)
-**Issue**: Two tests in `test_tui.py` used `self.assertTrue(True)` which always passes regardless of code changes.
-
-**Tests Fixed**:
-- `test_import_tui_module`: Now validates that imported classes are callable and have expected methods
-- `test_tui_screens_import`: Now validates all screen classes have required attributes
-
-**Impact**: Tests now provide actual validation and would catch import or structural issues.
-
-#### 2. Static Value Tests (REVIEWED ✅)
-**Finding**: Config tests check default values like `'CHATRIXCD'`, `'!cd'`, `'password'`.
-
-**Assessment**: These are **legitimate tests**. They:
-- Ensure default configuration values remain consistent
-- Would fail if defaults were accidentally changed
-- Document expected default behavior
-- Are necessary for configuration validation
-
-**Recommendation**: Keep these tests as-is.
-
-#### 3. Matrix SDK Integration (IMPROVED ✅)
-
-**New Tests Added**:
-
-**Bot Module** (6 new tests):
-1. `test_login_password_with_nio_response` - Uses actual `LoginResponse` object
-2. `test_login_handles_nio_error_response` - Tests error handling with `LoginError`
-3. `test_send_message_with_nio_error` - Tests error handling with `RoomSendError`
-4. `test_invite_callback_with_nio_join_response` - Uses `JoinResponse`
-5. `test_setup_encryption_with_nio_keys_upload_response` - Uses `KeysUploadResponse`
-6. `test_message_callback_with_nio_room_send_response` - Uses `RoomSendResponse`
-
-**Auth Module** (3 new tests):
-1. `test_token_storage` - Validates token storage behavior
-2. `test_password_auth_returns_none` - Validates delegation to matrix-nio
-3. `test_auth_type_determines_flow` - Validates auth type handling
-
-**Benefits**:
-- Tests now use actual nio Response types instead of just generic mocks
-- Better coverage of Matrix SDK error handling paths
-- More realistic test scenarios that mirror actual SDK behavior
-- Validates proper use of SDK response types
-
-### Matrix SDK Usage in Production Code
-
-#### Current State: EXCELLENT ✅
-
-The production code demonstrates **proper and effective use of Matrix SDK features**:
-
-1. **Response Type Checking**:
-   ```python
-   if isinstance(response, LoginResponse):
-       # Handle success
-   else:
-       # Handle error
-   ```
-   This is the recommended pattern for nio response handling.
-
-2. **Proper Use of SDK Features**:
-   - ✅ Event callbacks properly registered with `add_event_callback()`
-   - ✅ Response callbacks used with `add_response_callback()`
-   - ✅ Encryption support properly initialized with `load_store()`, `keys_upload()`, `keys_query()`
-   - ✅ Room key requests properly handled with `request_room_key()`
-   - ✅ Auto-join functionality using SDK's `join()` method
-   - ✅ Message sending using SDK's `room_send()` method
-
-3. **E2E Encryption Support**:
-   - ✅ Proper store initialization and management
-   - ✅ Key upload and query when needed
-   - ✅ Session management with duplicate request prevention
-   - ✅ Megolm event handling for encrypted messages
-   - ✅ Key verification callbacks implemented
-
-4. **Authentication Methods**:
-   - ✅ Password authentication delegated to SDK
-   - ✅ Token authentication properly implemented
-   - ✅ OIDC authentication with proper token management
-
-**Recommendation**: No changes needed to production code. The SDK is being used correctly and efficiently.
-
-### Test Coverage Gaps
-
-#### Auth Module (38% coverage)
-**Reason**: OIDC authentication flow requires actual HTTP requests and is difficult to unit test.
-
-**Recommendation**: 
-- Current unit tests adequately cover basic auth type logic
-- OIDC flow requires integration tests with mock OIDC server
-- Consider adding integration tests in future release
-- Document OIDC testing in TESTING.md
-
-#### Main Module (33% coverage)
-**Reason**: Entry point module handles application lifecycle and signal handling.
-
-**Recommendation**:
-- Requires integration tests with actual bot instance
-- Current CLI tests cover argument parsing
-- Application lifecycle best tested manually or with E2E tests
-- Not a priority for unit test coverage
-
-#### TUI Module (17% coverage)
-**Reason**: Terminal UI is highly interactive and difficult to unit test.
-
-**Current Coverage**:
-- ✅ Import tests validate module structure
-- ✅ Widget creation tests validate initialization
-- ✅ Screen creation tests validate basic functionality
-
-**Recommendation**:
-- Current level appropriate for TUI code
-- Interactive features require manual testing
-- Consider adding more screen interaction tests if bugs arise
-
-## Test Quality Improvements Summary
-
-### Before Review
-- 167 tests total
-- 2 trivial tests that always pass
-- Limited use of actual nio Response objects
-- 56% overall coverage
-- Bot module: 75% coverage
-
-### After Review
-- 176 tests total (+9 tests, +5.4%)
-- 0 trivial tests (all tests validate actual functionality)
-- Enhanced Matrix SDK integration with real Response objects
-- 50% coverage of chatrixcd modules specifically (excluding dependencies)
-- Bot module: 80% coverage (+5%)
-- All tests passing
-
-## Recommendations
-
-### Immediate (Completed ✅)
-- [x] Fix trivial tests in TUI module
-- [x] Add tests using actual nio Response objects
-- [x] Improve auth module test coverage
-- [x] Document findings
-
-### Short-term (Optional)
-- [ ] Add more edge case tests for encryption handling
-- [ ] Add tests for key verification workflow
-- [ ] Consider adding more TUI interaction tests
-
-### Long-term (Future Releases)
-- [ ] Set up integration test infrastructure
-- [ ] Add OIDC integration tests with mock server
-- [ ] Add E2E tests with test Matrix server
-- [ ] Implement performance and stress testing
-
-## Conclusion
-
-The ChatrixCD test suite is in **good overall condition**:
-
-1. ✅ **Test Quality**: High-quality tests that validate actual functionality
-2. ✅ **Matrix SDK Usage**: Proper and effective use of SDK features in production code
-3. ✅ **Coverage**: Adequate coverage for unit-testable code (56% overall, 75-93% for core modules)
-4. ✅ **No Breaking Changes**: All improvements made without modifying production code
-5. ✅ **Maintainability**: Clear test structure and good documentation
-
-**Key Takeaway**: The project demonstrates excellent engineering practices with proper SDK usage and solid test coverage. The identified gaps (OIDC, main, TUI) are expected for their respective code types and don't indicate quality issues.
-
----
-
-**Review Date**: 2025-10-12  
-**Reviewer**: GitHub Copilot  
-**Tests Reviewed**: 176 tests across 8 test files  
-**Production Code**: No changes required
diff --git a/TURBO_VISION_SUMMARY.md b/TURBO_VISION_SUMMARY.md
deleted file mode 100644
index 00f72d4..0000000
--- a/TURBO_VISION_SUMMARY.md
+++ /dev/null
@@ -1,328 +0,0 @@
-# ChatrixCD Turbo Vision TUI - Implementation Summary
-
-## Overview
-
-The ChatrixCD Text User Interface has been redesigned with a classic Turbo Vision aesthetic, featuring a menu bar, 3D windows with shadows, and a dynamic status bar - all while maintaining the ChatrixCD brand identity with the signature green (#4A9B7F) color scheme.
-
-## 🎯 Requirements Met
-
-All requirements from the original request have been implemented:
-
-✅ **Menu bar across the top** - Horizontal menu with File, Edit, Run, Help  
-✅ **Classic 3D aesthetic** - Box-drawing characters with drop shadows  
-✅ **Drop shadows** - Using `░` character for shadow effect  
-✅ **ChatrixCD brand colors** - #4A9B7F (green) and #2D3238 (dark gray)  
-✅ **Logical menu organization** - Grouped by functionality  
-✅ **Status bar at bottom** - Shows "Idle" or "Running X task(s)"  
-✅ **Windowed display** - All content appears in modal windows  
-
-### Menu Structure Implemented
-
-```
-File Menu:
-├── Status      (View bot status)
-├── Admins      (View admin users)
-├── Rooms       (View joined rooms)
-├── ─────────   (Separator)
-└── Exit        (Quit application)
-
-Edit Menu:
-├── Sessions    (Manage encryption sessions)
-└── Options     (Configuration - merged SET and SHOW)
-    ├── Edit Settings
-    ├── View Configuration
-    └── Manage Aliases
-
-Run Menu:
-└── Send        (Send messages to rooms - formerly "Say")
-
-Help Menu:
-├── Show Log    (View application logs)
-├── About       (Application information)
-└── Version     (Version and dependencies)
-```
-
-## 📁 Files Added/Modified
-
-### New Files
-1. **`chatrixcd/tui_turbo.py`** (871 lines)
-   - Complete Turbo Vision-style TUI implementation
-   - Includes: TurboMenuBar, TurboStatusBar, TurboWindow
-   - Menu screens: FileMenuScreen, EditMenuScreen, RunMenuScreen, HelpMenuScreen
-   - Dialog screens: StatusScreen, OptionsScreen, AboutScreen, VersionScreen
-
-2. **`docs/TUI_TURBO_VISION_DESIGN.md`** (500+ lines)
-   - Complete design documentation with ASCII art screenshots
-   - Shows all 8 screens: main, menus, and dialogs
-   - Color scheme and implementation details
-   - Keyboard shortcuts reference
-
-3. **`docs/TUI_MIGRATION_GUIDE.md`** (260+ lines)
-   - Migration guide from old to new TUI
-   - What changed, why, and how
-   - Backward compatibility notes
-   - Testing instructions
-
-### Modified Files
-1. **`chatrixcd/main.py`**
-   - Updated imports: `from chatrixcd.tui` → `from chatrixcd.tui_turbo`
-   - No functional changes, just using new TUI
-
-2. **`tests/test_tui.py`**
-   - Added tests for Turbo Vision components
-   - Tests for MenuBar, StatusBar, Window, Menus
-   - Tests for new screens and TUI creation
-
-## 🎨 Visual Design
-
-### Color Scheme
-- **Menu Bar**: #4A9B7F (ChatrixCD Green) with white text
-- **Status Bar**: #2D3238 (Dark Gray) with white text
-- **Window Borders**: #4A9B7F (ChatrixCD Green)
-- **Shadows**: Dark gray (`░` character)
-- **Primary Buttons**: #4A9B7F background with white text
-
-### Layout Structure
-```
-╔════════════════════════════════════════════╗
-║ File  Edit  Run  Help         ChatrixCD   ║ <- Menu Bar (green)
-╠════════════════════════════════════════════╣
-║                                            ║
-║    ╔═══════════════════════════╗          ║
-║    ║    Window Title           ║          ║
-║    ╠═══════════════════════════╣          ║
-║    ║                           ║░         ║ <- Window with shadow
-║    ║   Content area            ║░         ║
-║    ║                           ║░         ║
-║    ╚═══════════════════════════╝░         ║
-║      ░░░░░░░░░░░░░░░░░░░░░░░░░░           ║
-╠════════════════════════════════════════════╣
-║ Status: Idle / Running X task(s)          ║ <- Status Bar (dark gray)
-╚════════════════════════════════════════════╝
-```
-
-## 🎮 Keyboard Shortcuts
-
-### Menu Access
-- **F1** - Open File menu
-- **F2** - Open Edit menu
-- **F3** - Open Run menu
-- **F4** - Open Help menu
-
-### Navigation
-- **Escape** - Close current screen/menu
-- **Enter** - Confirm/OK (in dialogs)
-- **Ctrl+C** - Quit application
-
-### Mouse Support
-- Click on menu items to open dropdowns
-- Click on buttons to activate
-- Click outside menus to close
-
-## 📊 Dynamic Status Bar
-
-The status bar at the bottom provides real-time feedback:
-
-| State | Display |
-|-------|---------|
-| No tasks | `Idle` |
-| Tasks running | `Running 2 task(s)` |
-| Tasks queued | `3 task(s) (idle)` |
-| Bot initializing | `Bot not initialized` |
-
-Updates every 2 seconds automatically.
-
-## 🧪 Testing
-
-### Unit Tests Added
-```python
-# New test classes in tests/test_tui.py
-
-TestTUIImport.test_import_turbo_tui_module()
-TestShowConfigTUI.test_turbo_show_config_tui_import()
-TestTurboTUIComponents.test_turbo_menu_bar_creation()
-TestTurboTUIComponents.test_turbo_status_bar_creation()
-TestTurboTUIComponents.test_turbo_window_creation()
-TestTurboTUIComponents.test_menu_screen_creation()
-TestTurboTUIComponents.test_turbo_tui_creation()
-TestTurboTUIComponents.test_turbo_screens_creation()
-```
-
-All existing tests continue to pass ✅
-
-### Manual Testing Steps
-1. Install dependencies: `pip install -e .`
-2. Run the bot: `python -m chatrixcd.main`
-3. Navigate menus using F-keys or mouse
-4. Test all menu items and dialogs
-5. Verify status bar updates with task changes
-
-## 📸 Screenshots Available
-
-See **`docs/TUI_TURBO_VISION_DESIGN.md`** for complete visual documentation:
-
-1. **Main Screen** - Welcome screen with menu bar and status bar
-2. **File Menu** - Dropdown showing Status, Admins, Rooms, Exit
-3. **Edit Menu** - Dropdown showing Sessions, Options
-4. **Run Menu** - Dropdown showing Send
-5. **Help Menu** - Dropdown showing Show Log, About, Version
-6. **Status Window** - Bot status with metrics in 3D window
-7. **Options Window** - Unified configuration management (merged SET/SHOW)
-8. **About Window** - Application information and features
-
-All screenshots use ASCII art with proper box-drawing characters and shadows.
-
-## 🔄 Migration Notes
-
-### For Users
-- The new TUI is active by default when running `chatrixcd`
-- All functionality is preserved, just reorganized into menus
-- Use F-keys (F1-F4) or mouse to navigate
-- Status bar provides at-a-glance task information
-
-### For Developers
-- Original TUI (`chatrixcd/tui.py`) remains available
-- New TUI (`chatrixcd/tui_turbo.py`) is now default
-- Many components are reused from original TUI
-- Easy to switch back by changing imports in `main.py`
-
-### Breaking Changes
-**None** - All functionality is preserved, just reorganized:
-- SET + SHOW → Options (Edit menu)
-- Say → Send (Run menu)
-- New: About and Version (Help menu)
-
-## 🚀 Implementation Highlights
-
-### Component Reuse
-The new TUI intelligently reuses existing components:
-- `BotStatusWidget`, `ActiveTasksWidget`
-- `AdminsScreen`, `RoomsScreen`, `SessionsScreen`
-- `LogScreen`, `SetScreen`, `ShowScreen`
-- `MessageScreen`, `OIDCAuthScreen`
-
-### New Components
-Purpose-built for Turbo Vision aesthetic:
-- `TurboMenuBar` - Horizontal menu with hover effects
-- `TurboStatusBar` - Dynamic status display
-- `TurboWindow` - Reusable window container with shadows
-- Menu screens with proper dropdown positioning
-- Styled dialog screens with consistent appearance
-
-### CSS Magic
-Custom styling for Turbo Vision look:
-```css
-TurboMenuBar {
-    background: #4A9B7F;      /* ChatrixCD Green */
-    border-bottom: heavy white;
-}
-
-TurboStatusBar {
-    background: #2D3238;      /* Dark Gray */
-    dock: bottom;
-}
-
-TurboWindow {
-    border: heavy #4A9B7F;    /* ChatrixCD Green */
-}
-```
-
-## 📈 Code Statistics
-
-| Metric | Value |
-|--------|-------|
-| New TUI code | 871 lines |
-| Design documentation | 500+ lines |
-| Migration guide | 260+ lines |
-| New unit tests | 8 test methods |
-| Files added | 3 |
-| Files modified | 2 |
-| Test coverage | 100% for new components |
-
-## 🎓 Design Philosophy
-
-The Turbo Vision redesign follows these principles:
-
-1. **Classic Aesthetic** - Inspired by DOS-era Turbo Vision, Norton Commander, Midnight Commander
-2. **Brand Identity** - Maintains ChatrixCD's signature green color (#4A9B7F)
-3. **Logical Organization** - Menus grouped by function (File, Edit, Run, Help)
-4. **User Feedback** - Dynamic status bar provides real-time information
-5. **Consistency** - All windows and dialogs follow the same visual pattern
-6. **Accessibility** - F-keys for keyboard navigation, mouse support optional
-
-## 📚 Documentation Structure
-
-```
-docs/
-├── TUI_TURBO_VISION_DESIGN.md  <- Complete visual documentation
-├── TUI_MIGRATION_GUIDE.md      <- Migration from old to new TUI
-└── ARCHITECTURE.md             <- Updated with TUI architecture
-
-chatrixcd/
-├── tui.py                      <- Original TUI (still available)
-├── tui_turbo.py                <- New Turbo Vision TUI (active)
-└── main.py                     <- Updated to use tui_turbo
-
-tests/
-└── test_tui.py                 <- Tests for both TUIs
-```
-
-## ✅ Completion Checklist
-
-- [x] Menu bar with File, Edit, Run, Help
-- [x] 3D aesthetic with box-drawing characters
-- [x] Drop shadows on windows and menus
-- [x] ChatrixCD brand colors throughout
-- [x] Logical menu organization
-- [x] Status bar showing task status
-- [x] File menu: Status, Admins, Rooms, Exit
-- [x] Edit menu: Sessions, Options
-- [x] Run menu: Send (renamed from Say)
-- [x] Help menu: Show Log, About, Version
-- [x] Options merges SET and SHOW
-- [x] Windowed appearance
-- [x] Complete design documentation
-- [x] Migration guide
-- [x] Unit tests
-- [x] Screenshots (ASCII art)
-
-## 🎉 Ready for Review
-
-The implementation is **complete and ready for review**!
-
-### To Review:
-1. Check **`docs/TUI_TURBO_VISION_DESIGN.md`** for visual documentation
-2. Review **`chatrixcd/tui_turbo.py`** for implementation
-3. See **`docs/TUI_MIGRATION_GUIDE.md`** for what changed
-
-### To Test:
-```bash
-# Install dependencies
-pip install -e .
-
-# Run with new TUI
-python -m chatrixcd.main
-
-# Test menus with F1-F4
-# Test navigation with mouse
-# Verify status bar updates
-# Check all menu items work
-```
-
-### To Deploy:
-The new TUI is already integrated and active by default. Simply merge the PR!
-
-## 🙏 Acknowledgments
-
-This implementation was inspired by:
-- **Turbo Vision** by Borland (classic DOS TUI framework)
-- **tvision** by @magiblot (modern C++ implementation)
-- **tvision** by @tomer (Python implementation)
-
-While maintaining the unique **ChatrixCD brand identity** with its signature green color scheme.
-
----
-
-**Implementation by**: GitHub Copilot  
-**Review requested**: Please check screenshots and provide feedback  
-**Status**: ✅ Complete and ready for testing
diff --git a/VERIFICATION_FIX_SUMMARY.md b/VERIFICATION_FIX_SUMMARY.md
deleted file mode 100644
index 326b951..0000000
--- a/VERIFICATION_FIX_SUMMARY.md
+++ /dev/null
@@ -1,323 +0,0 @@
-# Device Verification Fix Summary
-
-## Problem Statement
-
-Device verification was failing with the following symptoms:
-
-1. **Timeout errors**: Verification always timed out with message:
-   ```
-   Verification timeout: Did not receive the other device's key.
-   Please ensure the other device has accepted the verification request.
-   ```
-
-2. **Unknown device information**: Pending verification requests showed:
-   ```
-   Request 1:
-     User: Unknown
-     Device: Unknown
-     Transaction: 0786a868-b42e-41...
-     Type: Sas
-   ```
-
-3. **No notifications on other client**: The device being verified with (e.g., Element) did not receive any notification or verification request.
-
-## Root Causes Identified
-
-### Issue 1: Incorrect Device Information Extraction
-
-**Location**: `chatrixcd/verification.py`, `get_pending_verifications()` method (lines 80-81)
-
-**Problem**: The code was trying to access `user_id` and `device_id` directly on the `Sas` verification object:
-```python
-'user_id': getattr(verification, 'user_id', 'Unknown'),
-'device_id': getattr(verification, 'device_id', 'Unknown'),
-```
-
-**Root Cause**: In matrix-nio's `Sas` class, the user ID and device ID are not direct attributes. Instead, they are properties of the `other_olm_device` attribute, which is an `OlmDevice` object. The `OlmDevice` class has:
-- `user_id`: The user ID of the other device
-- `id`: The device ID of the other device (note: it's `id`, not `device_id`)
-
-**Impact**: This caused all pending verification requests to display "Unknown" for both user and device, making it impossible to identify which device was trying to verify.
-
-### Issue 2: Missing To-Device Message Delivery
-
-**Location**: `chatrixcd/verification.py`, multiple methods
-
-**Problem**: After calling verification-related operations like:
-- `client.accept_key_verification()`
-- `client.start_key_verification()`
-
-The code was not calling `client.send_to_device_messages()` to actually send the messages to the other device.
-
-**Root Cause**: In matrix-nio, to-device messages (including verification messages) are queued internally and must be explicitly sent using `send_to_device_messages()`. Without this call, the messages never leave the client, and the other device never receives:
-- Verification start requests
-- Verification acceptance messages
-- Key exchange messages
-
-**Impact**: 
-- The other device never received verification requests when this bot initiated verification
-- The other device never received acceptance when this bot accepted an incoming verification
-- This caused the timeout because the key exchange could never complete
-
-## Solutions Implemented
-
-### Fix 1: Correct Device Information Extraction
-
-**File**: `chatrixcd/verification.py`
-**Method**: `get_pending_verifications()`
-
-**Changes**:
-```python
-# For Sas verifications, user_id and device_id are in other_olm_device
-if isinstance(verification, Sas):
-    other_device = getattr(verification, 'other_olm_device', None)
-    if other_device:
-        user_id = getattr(other_device, 'user_id', 'Unknown')
-        device_id = getattr(other_device, 'id', 'Unknown')
-    else:
-        user_id = 'Unknown'
-        device_id = 'Unknown'
-else:
-    user_id = getattr(verification, 'user_id', 'Unknown')
-    device_id = getattr(verification, 'device_id', 'Unknown')
-```
-
-**Benefits**:
-- Pending verification requests now correctly display the user ID and device ID
-- Users can identify which device is requesting verification
-- The TUI and logs show meaningful information instead of "Unknown"
-
-### Fix 2: Send To-Device Messages After Verification Operations
-
-**File**: `chatrixcd/verification.py`
-**Methods**: `start_verification()`, `accept_verification()`, `auto_verify_pending()`
-
-**Changes in `start_verification()`**:
-```python
-# Start key verification
-resp = await self.client.start_key_verification(device)
-
-if isinstance(resp, ToDeviceError):
-    logger.error(f"Failed to start verification: {resp.message}")
-    return None
-
-# Send the start message to the other device
-await self.client.send_to_device_messages()  # <-- ADDED
-
-# Wait for the verification to be set up
-await asyncio.sleep(1)
-```
-
-**Changes in `accept_verification()`**:
-```python
-if not sas.we_started_it and sas.state == SasState.created:
-    await self.client.accept_key_verification(sas.transaction_id)
-    # Send the accept message to the other device
-    await self.client.send_to_device_messages()  # <-- ADDED
-    await asyncio.sleep(0.5)
-    return True
-```
-
-**Changes in `auto_verify_pending()`**:
-```python
-# Accept the verification request
-await self.client.accept_key_verification(transaction_id)
-# Send the accept message to the other device
-await self.client.send_to_device_messages()  # <-- ADDED
-logger.info(f"Auto-accepted verification request {transaction_id}")
-```
-
-**Benefits**:
-- Verification start requests are now properly sent to the other device
-- Acceptance messages are delivered so the other device knows verification is proceeding
-- The key exchange can complete successfully
-- Verification no longer times out
-
-## Testing
-
-### New E2E Tests Added
-
-Created `tests/test_verification_e2e.py` with 10 comprehensive tests:
-
-1. **test_get_pending_verifications_with_sas**: Verifies correct extraction of user_id and device_id from Sas objects
-2. **test_accept_verification_sends_to_device_messages**: Ensures accept operations send messages
-3. **test_start_verification_sends_to_device_messages**: Ensures start operations send messages
-4. **test_full_verification_flow_mock**: Tests complete verification from start to emoji confirmation
-5. **test_auto_verify_pending_sends_messages**: Tests auto-verification in daemon mode
-6. **test_verification_with_wrong_emojis_rejection**: Tests rejection flow
-7. **test_verification_timeout_when_key_not_received**: Tests timeout behavior
-8. **test_get_pending_verifications_with_unknown_fallback**: Tests fallback to "Unknown" for invalid data
-9. **test_verify_device_interactive_success**: Tests interactive verification with user confirmation
-10. **test_verify_device_interactive_rejection**: Tests interactive verification with user rejection
-
-### Test Results
-
-All 225 tests pass, including:
-- 16 verification tests (6 original + 10 new E2E tests)
-- All existing tests remain passing
-- No regressions introduced
-
-## Expected Behavior After Fix
-
-### For Users Initiating Verification (Bot → Other Device)
-
-1. Bot calls `start_verification()` with a device
-2. Verification start message is sent to the other device
-3. Other device (e.g., Element) receives notification
-4. Other device accepts, sends response
-5. Bot receives key and displays emojis
-6. User confirms emojis match
-7. Verification completes successfully
-
-### For Users Accepting Verification (Other Device → Bot)
-
-1. Other device initiates verification with bot
-2. Bot receives verification request with correct user_id and device_id
-3. TUI shows: "New verification request from @user:server (device: DEVICEID)"
-4. User accepts through TUI
-5. Accept message is sent to other device
-6. Other device receives acceptance and shows emojis
-7. Both sides confirm emojis
-8. Verification completes successfully
-
-### For Auto-Verification (Daemon Mode)
-
-1. Other device initiates verification
-2. Bot automatically accepts
-3. Accept message is sent to other device
-4. Other device receives acceptance
-5. Bot automatically confirms emojis (trust without verification)
-6. Verification completes automatically
-
-## Matrix Protocol Compliance
-
-The fixes ensure proper compliance with the Matrix specification for device verification:
-
-1. **To-device message delivery**: All verification protocol messages are properly sent using the to-device messaging system
-2. **SAS verification flow**: The Short Authentication String (emoji) verification follows the correct state machine
-3. **Device information**: Proper extraction and display of device identity information
-4. **Timeout handling**: Appropriate timeout behavior when key exchange fails
-
-## Files Modified
-
-1. `chatrixcd/verification.py`: Core verification logic fixes
-   - `get_pending_verifications()`: Fix device info extraction
-   - `start_verification()`: Add send_to_device_messages()
-   - `accept_verification()`: Add send_to_device_messages()
-   - `auto_verify_pending()`: Add send_to_device_messages()
-
-2. `tests/test_verification_e2e.py`: New comprehensive E2E tests
-
-3. `CHANGELOG.md`: Documentation of changes
-
-## Migration Notes
-
-### For Existing Users
-
-No configuration changes required. The fixes are transparent and work with existing configurations.
-
-### For Developers
-
-If you have custom verification flows, ensure you:
-1. Call `send_to_device_messages()` after any to-device operation
-2. Extract device info from `Sas.other_olm_device` for Sas verifications
-3. Handle both `we_started_it=True` and `we_started_it=False` cases
-
-## Verification
-
-To verify the fix works:
-
-1. **Start ChatrixCD in TUI mode**
-2. **From Element (or another Matrix client)**:
-   - Go to Settings → Sessions
-   - Find the ChatrixCD bot session
-   - Click "Verify Session"
-3. **In ChatrixCD TUI**:
-   - Press `e` for Sessions menu
-   - Select "View Pending Verification Requests"
-   - You should see your user ID and device ID (not "Unknown")
-4. **Accept verification in ChatrixCD**
-5. **In Element**, you should see the verification proceed and emojis appear
-6. **Confirm emojis match on both sides**
-7. **Verification should complete successfully**
-
-## Related Documentation
-
-- [Matrix Specification - Device Verification](https://spec.matrix.org/latest/client-server-api/#device-verification)
-- [matrix-nio Documentation](https://matrix-nio.readthedocs.io/)
-- [ChatrixCD ARCHITECTURE.md](ARCHITECTURE.md)
-- [ChatrixCD TESTING.md](TESTING.md)
-
-## Future Improvements
-
-While this fix resolves the immediate issues, potential future enhancements include:
-
-1. **Retry logic**: Automatic retry of failed to-device message delivery
-2. **Better error messages**: More detailed error reporting for verification failures
-3. **QR code verification**: Support for QR code verification in addition to emoji
-4. ~~**Cross-signing**: Implement cross-signing for easier verification~~ *Note: matrix-nio does not currently provide cross-signing support. This would require implementation at a lower level than the library currently exposes.*
-5. ~~**Verification status persistence**: Remember verified devices across restarts~~ **✅ IMPLEMENTED** (see below)
-
-## Implemented Enhancements
-
-### Verification Status Persistence
-
-**Status**: ✅ Implemented
-
-Verified device status is now automatically persisted across bot restarts using matrix-nio's SqliteStore:
-
-- **Automatic Persistence**: When a device is successfully verified (via emoji or auto-verification), it is marked as verified in the encryption store
-- **Persistent Across Restarts**: The verified status is saved to disk and restored when the bot restarts
-- **New Methods**:
-  - `get_verified_devices()` - Returns a list of all verified devices with user IDs, device IDs, and trust states
-  - `is_device_verified(user_id, device_id)` - Checks if a specific device is verified
-- **Integration**: The verification manager now calls `client.verify_device()` after successful verification to persist the trust
-
-**Implementation Details**:
-
-1. After successful SAS emoji verification in `confirm_verification()`, the device is marked as verified:
-   ```python
-   if sas.other_olm_device:
-       self.client.verify_device(sas.other_olm_device)
-   ```
-
-2. In auto-verification mode in `auto_verify_pending()`, devices are similarly persisted:
-   ```python
-   if sas.other_olm_device:
-       self.client.verify_device(sas.other_olm_device)
-   ```
-
-3. The SqliteStore automatically saves this verification state to the database on disk
-
-**Testing**: Added 9 comprehensive tests in `test_verification_e2e.py`:
-- Test getting verified devices list
-- Test checking specific device verification status
-- Test that verification persistence works in confirm flow
-- Test that verification persistence works in auto-verify flow
-- Test filtering of own device from verified list
-- Test behavior with encryption disabled
-- Test behavior with non-existent devices
-
-**Benefits**:
-- Users don't need to re-verify devices after bot restarts
-- More seamless E2E encryption experience
-- Verified devices remain trusted between sessions
-- Reduces verification friction for regular users
-
-### Cross-Signing Support
-
-**Status**: ❌ Not Implemented
-
-Cross-signing requires master, self-signing, and user-signing keys that are not currently exposed by matrix-nio's API. The library would need to be extended to support:
-- Master signing key generation and storage
-- Self-signing key operations
-- User-signing key operations
-- Key signature verification
-- Trust chain validation
-
-This feature would require either:
-1. Waiting for matrix-nio to add cross-signing support
-2. Implementing custom cross-signing at a lower level using the underlying olm/vodozemac libraries
-3. Contributing cross-signing support to matrix-nio itself
-
-Given the complexity and the lack of library support, this enhancement is deferred for future consideration.
diff --git a/chatrixcd/commands.py b/chatrixcd/commands.py
index 281a2b5..cb97f42 100644
--- a/chatrixcd/commands.py
+++ b/chatrixcd/commands.py
@@ -101,6 +101,15 @@ def markdown_to_html(self, text: str) -> str:
         Returns:
             HTML formatted text
         """
+        # Convert Matrix user mentions (@username:server.com) to HTML links for proper highlighting
+        # This makes Matrix clients properly highlight the mentioned user
+        # Matrix spec allows: lowercase letters, digits, hyphens, dots, underscores, equals, and plus
+        text = re.sub(
+            r'(@[a-zA-Z0-9._=+-]+:[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})',
+            r'<a href="https://matrix.to/#/\1">\1</a>',
+            text
+        )
+        
         # Convert bold **text** to <strong>text</strong>
         text = re.sub(r'\*\*(.+?)\*\*', r'<strong>\1</strong>', text)
         # Convert italic *text* to <em>text</em>
@@ -118,17 +127,17 @@ def markdown_to_html(self, text: str) -> str:
     def _get_display_name(self, user_id: str) -> str:
         """Get a friendly display name for a user.
         
+        Returns the full Matrix ID for proper highlighting/mentions in messages.
+        The markdown_to_html function will convert it to a clickable mention link.
+        
         Args:
             user_id: User ID to get display name for
             
         Returns:
-            Display name with @ prefix (for greetings) or full user ID
+            Full Matrix user ID (e.g., @username:server.com) for proper mentions
         """
-        # Return username with @ prefix for consistency
-        # Extract username from Matrix user ID (@username:server.com)
-        if user_id.startswith('@'):
-            username = user_id.split(':')[0]  # Includes the @ symbol
-            return username
+        # Return the full Matrix ID for proper mentions
+        # The markdown_to_html function will convert it to an HTML link
         return user_id
     
     def _get_greeting(self, user_id: str) -> str:
@@ -1084,11 +1093,12 @@ async def get_logs(self, room_id: str, args: list, sender: str = None):
             }
             
             logger.info(f"Started log tailing for task {self.last_task_id} in room {room_id}")
+            message = (f"{user_name} 👋 - Started tailing logs for task **{self.last_task_id}** 📋\n"
+                      f"Use `{self.command_prefix} log off` to stop.")
             await self.bot.send_message(
                 room_id,
-                f"{user_name} 👋 - Started tailing logs for task **{self.last_task_id}** 📋\n"
-                f"Use `{self.command_prefix} log off` to stop."
-                
+                message,
+                self.markdown_to_html(message)
             )
             
             # Start the tailing task
@@ -1110,10 +1120,11 @@ async def get_logs(self, room_id: str, args: list, sender: str = None):
             del self.log_tailing_sessions[room_id]
             
             logger.info(f"Stopped log tailing for task {task_id} in room {room_id}")
+            message = f"{user_name} 👋 - Stopped tailing logs for task **{task_id}** 🛑"
             await self.bot.send_message(
                 room_id,
-                f"{user_name} 👋 - Stopped tailing logs for task **{task_id}** 🛑"
-                
+                message,
+                self.markdown_to_html(message)
             )
             return
         
@@ -1357,6 +1368,28 @@ def _ansi_to_html(self, text: str) -> str:
         
         return result
 
+    def _ansi_to_html_for_pre(self, text: str) -> str:
+        """Convert ANSI color codes to HTML for use in <pre> tags.
+        
+        This version does NOT replace newlines with <br> since <pre> tags
+        preserve newlines naturally. Uses a simplified conversion that strips
+        ANSI codes for readability rather than perfect HTML structure.
+        
+        Args:
+            text: Text with ANSI color codes
+            
+        Returns:
+            HTML formatted text (without <br> tags)
+        """
+        # For logs in <pre> tags, we prioritize readability over perfect formatting.
+        # Simply strip ANSI codes and preserve the text structure.
+        # Most logs are readable without color formatting in Matrix clients.
+        result = re.sub(r'\x1b\[[0-9;]*m', '', text)
+        
+        # Do NOT replace newlines - <pre> tags preserve them naturally
+        
+        return result
+
     def _format_task_logs(self, raw_logs: str) -> str:
         """Format raw task logs for better readability.
         
@@ -1405,10 +1438,10 @@ def _format_task_logs_html(self, raw_logs: str) -> str:
         # Remove excessive blank lines first
         logs = re.sub(r'\n{3,}', '\n\n', raw_logs)
         
-        # Convert ANSI codes to HTML
-        html_logs = self._ansi_to_html(logs)
+        # Convert ANSI codes to HTML (but keep newlines as-is for <pre> tag)
+        html_logs = self._ansi_to_html_for_pre(logs)
         
-        # Wrap in pre tag for monospace formatting
+        # Wrap in pre tag for monospace formatting (newlines are preserved in <pre>)
         return f'<pre>{html_logs}</pre>'
 
     async def ping_semaphore(self, room_id: str, sender: str = None):
diff --git a/docs/BUILD_WORKFLOW.md b/docs/BUILD_WORKFLOW.md
deleted file mode 100644
index d271894..0000000
--- a/docs/BUILD_WORKFLOW.md
+++ /dev/null
@@ -1,351 +0,0 @@
-# Build and Release Workflow
-
-This document describes the automated build and release workflow for ChatrixCD using Nuitka to create standalone executables.
-
-## Overview
-
-The build workflow (`build.yml`) uses [Nuitka-Action](https://github.com/Nuitka/Nuitka-Action) to compile ChatrixCD into standalone executables for multiple platforms:
-
-- **Linux**: x86_64, i686 (32-bit), ARM64
-- **Windows**: x86_64, ARM64
-- **macOS**: Universal binary (x86_64 + ARM64)
-
-## Workflow Triggers
-
-### Automatic Triggers (Pre-release)
-
-The workflow automatically runs when:
-- A pull request is **merged** into the `main` branch
-- Creates pre-release artifacts with `-dev` suffix
-- Example version: `2025.10.21.0.0.1-dev`
-
-### Manual Triggers (Production Release)
-
-The workflow can be manually triggered for production releases:
-1. Go to Actions → Build and Release → Run workflow
-2. Select version type: `patch`, `minor`, or `major`
-3. Choose whether to mark as pre-release
-4. Production releases do not have `-dev` suffix
-
-## Version Scheme
-
-ChatrixCD uses calendar versioning with semantic versioning:
-
-```
-YYYY.MM.DD.MAJOR.MINOR.PATCH[-dev]
-```
-
-- **YYYY.MM.DD**: Current date
-- **MAJOR.MINOR.PATCH**: Semantic version components
-- **-dev**: Optional suffix for pre-releases
-
-Example versions:
-- `2025.10.21.0.0.1` - Production release
-- `2025.10.21.0.0.1-dev` - Pre-release from PR merge
-
-## Build Process
-
-### Linux Builds
-
-- **x86_64**: Built natively using Nuitka-Action
-- **i686**: Cross-compiled using Docker with i386/python:3.12-slim
-- **ARM64**: Cross-compiled using Docker with arm64v8/python:3.12-slim
-
-Linux builds include:
-- Icon: `assets/icon.png`
-- Bundled assets directory
-- Standalone executable (statically linked)
-
-### Windows Builds
-
-- **x86_64**: Built natively using Nuitka-Action
-- **ARM64**: Built using Nuitka-Action with ARM64 target
-
-Windows builds include:
-- Icon: `assets/icon.ico`
-- File metadata (version, description, copyright)
-- Company name: "ChatrixCD Contributors"
-- Bundled assets directory
-- Standalone .exe file
-
-### macOS Builds
-
-- **Universal**: Single executable for both x86_64 and ARM64
-
-macOS builds include:
-- Icon: `assets/icon.png`
-- Application bundle: `ChatrixCD.app`
-- Universal binary supporting both architectures
-- Bundled assets directory
-
-## Build Artifacts
-
-All builds produce standalone executables with included assets:
-
-```
-chatrixcd-linux-x86_64
-chatrixcd-linux-i686
-chatrixcd-linux-arm64
-chatrixcd-windows-x86_64.exe
-chatrixcd-windows-arm64.exe
-chatrixcd-macos-universal
-ChatrixCD.app/ (macOS app bundle)
-```
-
-Artifacts are:
-- Uploaded to GitHub Actions (90-day retention)
-- Attached to GitHub Releases
-
-## Release Process
-
-### For PR Merges (Automated Pre-release)
-
-1. Unit tests run for all Python versions (3.12, 3.13, 3.14)
-2. Builds are created for all platforms
-3. Version is calculated with `-dev` suffix
-4. GitHub Release is created as **pre-release**
-5. Artifacts are attached to the release
-
-### For Manual Releases (Production)
-
-1. Developer triggers workflow manually
-2. Selects version type (patch/minor/major)
-3. Unit tests run
-4. Builds are created for all platforms
-5. Version files are updated (`__init__.py`, `setup.py`)
-6. `CHANGELOG.md` is updated
-7. Git tag is created
-8. GitHub Release is created
-9. Artifacts are attached to the release
-
-## Testing
-
-The workflow includes comprehensive testing:
-
-### Unit Tests
-
-All unit tests must pass before building:
-```bash
-python -m unittest discover -s tests -v
-```
-
-### Workflow Tests
-
-Workflow configuration is validated:
-```bash
-python -m unittest tests.test_workflow -v
-```
-
-Tests verify:
-- Workflow file syntax (YAML)
-- Required jobs and steps
-- Platform matrix configuration
-- Nuitka-Action usage
-- Metadata and icons
-- Pre-release handling
-
-### PR Checks
-
-On pull requests (before merge):
-- Unit tests run on Python 3.12, 3.13, 3.14
-- Workflow configuration tests run
-- Actionlint validates workflow syntax
-
-## Icons and Metadata
-
-### Icons
-
-- **icon.ico**: Windows executable icon (multi-resolution)
-- **icon.png**: macOS/Linux icon (512x512 PNG)
-- Source: `assets/logo-icon.svg` (converted to PNG/ICO)
-
-### Metadata (Windows)
-
-- **Company**: ChatrixCD Contributors
-- **Product**: ChatrixCD
-- **Description**: Matrix bot for CI/CD automation with Semaphore UI
-- **Copyright**: Copyright (c) 2024 ChatrixCD Contributors
-- **Version**: Matches release version
-
-## Troubleshooting
-
-### Build Failures
-
-If a platform build fails:
-1. Check the GitHub Actions logs for that specific job
-2. Look for Nuitka compilation errors
-3. Verify dependencies are correctly specified in `requirements.txt`
-4. Ensure assets directory structure is correct
-
-### Cross-compilation Issues
-
-For i686 and ARM64 Linux builds:
-- These use Docker for cross-compilation
-- Requires QEMU emulation (automatically set up)
-- May be slower than native builds
-- Check Docker logs for compilation errors
-
-### Version Conflicts
-
-If version tagging fails:
-- Check if the version already exists
-- Verify CHANGELOG.md format
-- Ensure git repository is clean
-
-## Development
-
-### Testing Workflow Locally
-
-You cannot run GitHub Actions locally, but you can:
-
-1. **Test workflow syntax**:
-   ```bash
-   actionlint .github/workflows/build.yml
-   ```
-
-2. **Test workflow configuration**:
-   ```bash
-   python -m unittest tests.test_workflow -v
-   ```
-
-3. **Test builds locally** (not recommended due to Nuitka complexity):
-   ```bash
-   pip install nuitka ordered-set
-   python -m nuitka --onefile --standalone chatrixcd/main.py
-   ```
-
-### Modifying the Workflow
-
-When modifying `build.yml`:
-1. Update the workflow file
-2. Run workflow tests to verify changes
-3. Run actionlint to check syntax
-4. Update this documentation if needed
-5. Test on a PR to verify changes work
-
-### Adding New Platforms
-
-To add a new platform:
-1. Add a new matrix entry in the appropriate job
-2. Configure Nuitka-Action parameters for that platform
-3. Update workflow tests to verify the new platform
-4. Update this documentation
-
-## Documentation Updates After Release
-
-When a new production release is created, the documentation contains direct download links that automatically point to the latest release. **These links require no manual updates** as they use GitHub's `/releases/latest/download/` URL pattern.
-
-### Download Link Format
-
-All documentation uses the following URL pattern:
-
-```
-https://github.com/CJFWeatherhead/ChatrixCD/releases/latest/download/<artifact-name>
-```
-
-Examples:
-- `https://github.com/CJFWeatherhead/ChatrixCD/releases/latest/download/chatrixcd-linux-x86_64`
-- `https://github.com/CJFWeatherhead/ChatrixCD/releases/latest/download/chatrixcd-windows-x86_64.exe`
-- `https://github.com/CJFWeatherhead/ChatrixCD/releases/latest/download/chatrixcd-macos-universal`
-
-GitHub automatically redirects these URLs to the latest non-pre-release version.
-
-### Files Containing Download Links
-
-The following files contain download links that are automatically updated by GitHub's URL resolution:
-
-1. **README.md** - Main repository documentation
-2. **INSTALL.md** - Installation guide
-3. **QUICKSTART.md** - Quick start guide
-4. **docs/index.md** - Documentation homepage
-5. **docs/installation.md** - Installation page (GitHub Pages)
-6. **docs/quickstart.md** - Quick start page (GitHub Pages)
-
-### Release Checklist
-
-When creating a new production release:
-
-- [ ] Trigger the build workflow manually (Actions → Build and Release)
-- [ ] Select version type (major/minor/patch)
-- [ ] Ensure "Mark as pre-release" is **unchecked**
-- [ ] Wait for build to complete (~15-25 minutes)
-- [ ] Verify all artifacts are attached to the release
-- [ ] **No documentation updates needed** - links auto-update!
-- [ ] Verify download links work by testing them
-- [ ] Announce release in appropriate channels
-
-### Testing Download Links
-
-After a release, verify the download links work:
-
-```bash
-# Test Linux x86_64 link
-curl -I https://github.com/CJFWeatherhead/ChatrixCD/releases/latest/download/chatrixcd-linux-x86_64
-
-# Should return HTTP 302 redirect to actual release URL
-# Followed by HTTP 200 OK
-```
-
-### Pre-release Notes
-
-Pre-releases (created automatically on PR merge):
-- Are marked as "pre-release" on GitHub
-- Have `-dev` suffix in version (e.g., `2025.10.21.0.0.1-dev`)
-- Are **NOT** included in `/releases/latest/` URLs
-- Are accessible via direct version URLs
-- Are intended for testing only
-
-### Manual Link Updates (If Needed)
-
-In the rare case that artifact names change, update the following pattern in all documentation files:
-
-**Old pattern:**
-```
-/releases/latest/download/chatrixcd-<platform>-<arch>
-```
-
-**Update in these files:**
-- README.md
-- INSTALL.md
-- QUICKSTART.md
-- docs/index.md
-- docs/installation.md
-- docs/quickstart.md
-
-**Search and replace example:**
-```bash
-# If renaming linux-x86_64 to linux-amd64
-find . -name "*.md" -exec sed -i 's/chatrixcd-linux-x86_64/chatrixcd-linux-amd64/g' {} \;
-```
-
-## Security Considerations
-
-### Credentials
-
-- GitHub Actions uses `GITHUB_TOKEN` for releases
-- No additional secrets required
-- Artifacts are publicly downloadable from releases
-
-### Build Environment
-
-- All builds run in isolated GitHub Actions runners
-- No persistent state between builds
-- Dependencies are installed fresh for each build
-
-## Performance
-
-Typical build times:
-- Linux x86_64: ~5-10 minutes
-- Linux i686 (Docker): ~10-15 minutes
-- Linux ARM64 (Docker): ~10-15 minutes
-- Windows x86_64: ~5-10 minutes
-- Windows ARM64: ~5-10 minutes
-- macOS Universal: ~10-15 minutes
-- Total workflow time: ~15-25 minutes (parallel builds)
-
-## References
-
-- [Nuitka-Action Documentation](https://github.com/Nuitka/Nuitka-Action)
-- [Nuitka Documentation](https://nuitka.net/doc/user-manual.html)
-- [GitHub Actions Documentation](https://docs.github.com/en/actions)
-- [ChatrixCD Architecture](ARCHITECTURE.md)
diff --git a/docs/TUI_MIGRATION_GUIDE.md b/docs/TUI_MIGRATION_GUIDE.md
deleted file mode 100644
index 97da000..0000000
--- a/docs/TUI_MIGRATION_GUIDE.md
+++ /dev/null
@@ -1,278 +0,0 @@
-# TUI Migration Guide: Classic to Turbo Vision
-
-This document explains the migration from the original ChatrixCD TUI to the new Turbo Vision-style interface.
-
-## Overview
-
-The new Turbo Vision-style TUI (`chatrixcd/tui_turbo.py`) provides a more classic, windowed interface inspired by the Turbo Vision framework, while maintaining all the functionality of the original TUI (`chatrixcd/tui.py`).
-
-## What Changed
-
-### 1. Menu Organization
-
-**Old TUI**: Button-based main menu with direct access to functions
-```
-Main Screen:
-- STATUS button
-- ADMINS button
-- ROOMS button
-- SESSIONS button
-- SAY button
-- LOG button
-- SET button
-- SHOW button
-- ALIASES button
-- QUIT button
-```
-
-**New TUI**: Menu bar with logical groupings
-```
-Menu Bar: File | Edit | Run | Help
-
-File Menu:
-- Status
-- Admins
-- Rooms
-- Exit
-
-Edit Menu:
-- Sessions
-- Options (merged SET + SHOW)
-
-Run Menu:
-- Send (renamed from Say)
-
-Help Menu:
-- Show Log
-- About
-- Version
-```
-
-### 2. Visual Style
-
-**Old TUI**:
-- Header widget at top
-- Footer widget at bottom
-- Button-based navigation
-- Simple styling
-
-**New TUI**:
-- Menu bar with F-key shortcuts (F1-F4)
-- 3D windowed appearance with shadows
-- Status bar showing task status
-- ChatrixCD brand colors (#4A9B7F green)
-- Drop-down menus
-- Modal dialogs with borders
-
-### 3. Key Bindings
-
-**Old TUI**:
-- `s` - Status
-- `a` - Admins
-- `r` - Rooms
-- `e` - Sessions
-- `m` - Say
-- `l` - Log
-- `t` - Set
-- `c` - Show Config
-- `x` - Aliases
-- `q` - Quit
-
-**New TUI**:
-- `F1` - File menu
-- `F2` - Edit menu
-- `F3` - Run menu
-- `F4` - Help menu
-- `Escape` - Close current screen/menu
-- `Ctrl+C` - Quit
-
-### 4. Merged Functionality
-
-The new TUI combines SET and SHOW into a single **Options** screen under the Edit menu:
-
-**Options Screen**:
-- Edit Settings (formerly SET)
-- View Configuration (formerly SHOW)
-- Manage Aliases
-
-This provides a more cohesive configuration management experience.
-
-### 5. Renamed Components
-
-- **Say** → **Send**: The message sending functionality is now called "Send" and is accessible via Run > Send
-- **SET/SHOW** → **Options**: Configuration viewing and editing are now unified under Edit > Options
-
-### 6. Status Bar
-
-The new TUI includes a dynamic status bar at the bottom that shows:
-- "Idle" - When no tasks are running
-- "Running X task(s)" - When tasks are active
-
-This provides at-a-glance information about bot activity.
-
-## Implementation Details
-
-### File Structure
-
-```
-chatrixcd/
-├── tui.py          # Original TUI (still available)
-├── tui_turbo.py    # New Turbo Vision TUI (active by default)
-└── main.py         # Updated to use tui_turbo by default
-```
-
-### Module Imports
-
-The new Turbo Vision TUI reuses many components from the original TUI:
-- `BotStatusWidget`
-- `ActiveTasksWidget`
-- `AdminsScreen`
-- `RoomsScreen`
-- `SessionsScreen`
-- `SayScreen`
-- `LogScreen`
-- `SetScreen`
-- `ShowScreen`
-- `MessageScreen`
-- `OIDCAuthScreen`
-
-New components specific to Turbo Vision style:
-- `TurboMenuBar` - Menu bar widget
-- `TurboStatusBar` - Status bar widget
-- `TurboWindow` - Window container with 3D borders and shadows
-- `FileMenuScreen`, `EditMenuScreen`, `RunMenuScreen`, `HelpMenuScreen` - Menu dropdowns
-- `StatusScreen` - Turbo-styled status display
-- `OptionsScreen` - Unified configuration management
-- `AboutScreen` - Application information
-- `VersionScreen` - Version and dependencies
-
-### Color Scheme
-
-The Turbo Vision TUI uses ChatrixCD brand colors:
-
-```python
-# Menu bar background
-background: #4A9B7F (ChatrixCD Green)
-
-# Status bar background
-background: #2D3238 (Dark Gray)
-
-# Window borders
-border: #4A9B7F (ChatrixCD Green)
-
-# Primary buttons
-background: #4A9B7F (ChatrixCD Green)
-color: white
-```
-
-### CSS Styling
-
-The new TUI includes custom CSS for the Turbo Vision aesthetic:
-
-```css
-TurboMenuBar {
-    height: 3;
-    width: 100%;
-    background: $primary;
-    color: white;
-    border-bottom: heavy white;
-}
-
-TurboStatusBar {
-    height: 1;
-    width: 100%;
-    background: $primary;
-    color: white;
-    dock: bottom;
-}
-
-TurboWindow {
-    width: 80%;
-    height: 80%;
-    border: heavy $primary;
-    background: $surface;
-}
-```
-
-## Testing
-
-### Unit Tests
-
-All existing TUI tests continue to pass. New tests have been added for Turbo Vision components:
-
-```python
-# tests/test_tui.py
-
-class TestTurboTUIComponents(unittest.TestCase):
-    """Test Turbo Vision TUI components."""
-    
-    def test_turbo_menu_bar_creation(self):
-        """Test creating a TurboMenuBar widget."""
-        ...
-    
-    def test_turbo_status_bar_creation(self):
-        """Test creating a TurboStatusBar widget."""
-        ...
-    
-    def test_turbo_window_creation(self):
-        """Test creating a TurboWindow container."""
-        ...
-```
-
-### Manual Testing
-
-To test the new TUI:
-
-```bash
-# Run the bot in TUI mode (default)
-python -m chatrixcd.main
-
-# Run in log-only mode (bypasses TUI)
-python -m chatrixcd.main -L
-```
-
-## Backward Compatibility
-
-The original TUI (`chatrixcd/tui.py`) remains available and can be restored by changing the imports in `chatrixcd/main.py`:
-
-```python
-# To use the original TUI:
-from chatrixcd.tui import run_tui, show_config_tui
-
-# To use the Turbo Vision TUI (current default):
-from chatrixcd.tui_turbo import run_tui, show_config_tui
-```
-
-## Migration Checklist
-
-If you're updating from the old TUI to the new Turbo Vision TUI:
-
-- [x] Menu items reorganized into File, Edit, Run, Help
-- [x] SET and SHOW merged into Options
-- [x] Say renamed to Send
-- [x] Added About and Version to Help menu
-- [x] Status bar shows task status
-- [x] 3D windowed appearance with shadows
-- [x] ChatrixCD brand colors applied
-- [x] F-key shortcuts for menu access
-- [x] All existing functionality preserved
-- [x] Tests updated to cover new components
-
-## Documentation
-
-See also:
-- [TUI_TURBO_VISION_DESIGN.md](TUI_TURBO_VISION_DESIGN.md) - Complete design documentation with screenshots
-- [QUICKSTART.md](../QUICKSTART.md) - Getting started guide
-- [ARCHITECTURE.md](../ARCHITECTURE.md) - Technical architecture
-
-## Questions or Issues
-
-If you encounter any issues with the new TUI or have questions about the migration:
-
-1. Check the [documentation](https://chatrixcd.cjfw.me/)
-2. Review the [TUI design document](TUI_TURBO_VISION_DESIGN.md)
-3. Open an issue on [GitHub](https://github.com/CJFWeatherhead/ChatrixCD/issues)
-
----
-
-*Last updated: 2025-10-21*
diff --git a/docs/TUI_TURBO_VISION_DESIGN.md b/docs/TUI_TURBO_VISION_DESIGN.md
deleted file mode 100644
index 86c91ce..0000000
--- a/docs/TUI_TURBO_VISION_DESIGN.md
+++ /dev/null
@@ -1,311 +0,0 @@
-# ChatrixCD Turbo Vision-Style TUI Design
-
-This document showcases the new Turbo Vision-inspired Text User Interface design for ChatrixCD.
-
-## Design Overview
-
-The new TUI features:
-
-- **Menu bar** at the top with File, Edit, Run, Help menus
-- **Classic 3D aesthetic** with box-drawing characters and drop shadows
-- **Status bar** at the bottom showing idle/running task status
-- **ChatrixCD brand colors** (#4A9B7F green for highlights and borders)
-- **Windowed appearance** with modal dialogs and shadows
-- **Logical menu organization** based on functionality
-
-## Color Scheme
-
-- **Menu bar background**: #4A9B7F (ChatrixCD Green)
-- **Status bar background**: #2D3238 (Dark Gray)
-- **Window borders**: #4A9B7F (ChatrixCD Green)
-- **Shadows**: Dark gray (░ character)
-- **Primary buttons**: #4A9B7F background with white text
-- **Regular text**: White on dark background
-
-## Screenshots
-
-### 1. Main Screen
-
-```
-╔════════════════════════════════════════════════════════════════════════════════╗
-║ File  Edit  Run  Help                                     ChatrixCD v1.0      ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║                                                                                ║
-║    ╔══════════════════════════════════════════════════════════════════╗      ║
-║    ║                   ChatrixCD - Matrix CI/CD Bot                   ║      ║
-║    ╠══════════════════════════════════════════════════════════════════╣      ║
-║    ║                                                                  ║░     ║
-║    ║  Welcome to ChatrixCD                                            ║░     ║
-║    ║                                                                  ║░     ║
-║    ║  Use the menu bar above to navigate:                            ║░     ║
-║    ║                                                                  ║░     ║
-║    ║  F1 - File Menu   F2 - Edit Menu   F3 - Run Menu   F4 - Help   ║░     ║
-║    ║                                                                  ║░     ║
-║    ║  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  ║░     ║
-║    ║                                                                  ║░     ║
-║    ║  Active Tasks                                                    ║░     ║
-║    ║                                                                  ║░     ║
-║    ║  No active tasks                                                 ║░     ║
-║    ║                                                                  ║░     ║
-║    ║                                                                  ║░     ║
-║    ║                                                                  ║░     ║
-║    ║                                                                  ║░     ║
-║    ║                                                                  ║░     ║
-║    ╚══════════════════════════════════════════════════════════════════╝░     ║
-║      ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░       ║
-║                                                                                ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║ Idle                                                                           ║
-╚════════════════════════════════════════════════════════════════════════════════╝
-```
-
-The main screen features:
-- Menu bar at top with File, Edit, Run, Help (highlighted in ChatrixCD green)
-- Central window with 3D appearance and drop shadow
-- Status bar at bottom showing current task status
-- Active tasks display area
-
-### 2. File Menu
-
-```
-╔════════════════════════════════════════════════════════════════════════════════╗
-║ File  Edit  Run  Help                                     ChatrixCD v1.0      ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║ ╔═══════════════╗                                                              ║
-║ ║ Status        ║                                                              ║
-║ ║ Admins        ║                                                              ║
-║ ║ Rooms         ║                                                              ║
-║ ║ ───────────── ║                                                              ║
-║ ║ Exit          ║                                                              ║
-║ ╚═══════════════╝░                                                             ║
-║   ░░░░░░░░░░░░░░░                                                              ║
-╚════════════════════════════════════════════════════════════════════════════════╝
-```
-
-File menu options:
-- **Status**: View bot status (Matrix connection, Semaphore status, uptime, metrics)
-- **Admins**: View list of admin users
-- **Rooms**: View list of joined Matrix rooms
-- **Exit**: Quit the application
-
-### 3. Edit Menu
-
-```
-╔════════════════════════════════════════════════════════════════════════════════╗
-║ File  Edit  Run  Help                                     ChatrixCD v1.0      ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║        ╔═══════════════╗                                                        ║
-║        ║ Sessions      ║                                                        ║
-║        ║ Options       ║                                                        ║
-║        ╚═══════════════╝░                                                       ║
-║          ░░░░░░░░░░░░░░░                                                        ║
-╚════════════════════════════════════════════════════════════════════════════════╝
-```
-
-Edit menu options:
-- **Sessions**: Manage encryption sessions, verify devices, view pending verifications
-- **Options**: Merged SET and SHOW functionality - edit settings, view configuration, manage aliases
-
-### 4. Run Menu
-
-```
-╔════════════════════════════════════════════════════════════════════════════════╗
-║ File  Edit  Run  Help                                     ChatrixCD v1.0      ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║               ╔═══════════════╗                                                 ║
-║               ║ Send          ║                                                 ║
-║               ╚═══════════════╝░                                                ║
-║                 ░░░░░░░░░░░░░░░                                                 ║
-╚════════════════════════════════════════════════════════════════════════════════╝
-```
-
-Run menu options:
-- **Send**: Send messages to Matrix rooms (formerly "Say")
-
-### 5. Help Menu
-
-```
-╔════════════════════════════════════════════════════════════════════════════════╗
-║ File  Edit  Run  Help                                     ChatrixCD v1.0      ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║                    ╔═══════════════╗                                            ║
-║                    ║ Show Log      ║                                            ║
-║                    ║ About         ║                                            ║
-║                    ║ Version       ║                                            ║
-║                    ╚═══════════════╝░                                           ║
-║                      ░░░░░░░░░░░░░░░                                            ║
-╚════════════════════════════════════════════════════════════════════════════════╝
-```
-
-Help menu options:
-- **Show Log**: View application logs
-- **About**: Show application information and features
-- **Version**: Display version information and dependencies
-
-### 6. Status Window
-
-```
-╔════════════════════════════════════════════════════════════════════════════════╗
-║ File  Edit  Run  Help                                     ChatrixCD v1.0      ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║                                                                                ║
-║         ╔═══════════════════════════════════════════════════════╗             ║
-║         ║                     Bot Status                        ║             ║
-║         ╠═══════════════════════════════════════════════════════╣             ║
-║         ║                                                       ║░            ║
-║         ║  Bot Status                                           ║░            ║
-║         ║                                                       ║░            ║
-║         ║  Matrix: Connected                                    ║░            ║
-║         ║  Semaphore: Connected                                 ║░            ║
-║         ║  Uptime: 2h 15m 30s                                   ║░            ║
-║         ║                                                       ║░            ║
-║         ║  Metrics                                              ║░            ║
-║         ║  Messages Processed: 42                               ║░            ║
-║         ║  Errors: 0                                            ║░            ║
-║         ║  Warnings: 1                                          ║░            ║
-║         ║                                                       ║░            ║
-║         ║               [ OK ]                                  ║░            ║
-║         ║                                                       ║░            ║
-║         ╚═══════════════════════════════════════════════════════╝░            ║
-║           ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░             ║
-║                                                                                ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║ Running 2 task(s)                                                              ║
-╚════════════════════════════════════════════════════════════════════════════════╝
-```
-
-Modal window example showing:
-- 3D window with border and shadow
-- Bot connection status
-- Runtime metrics
-- Primary action button in ChatrixCD green
-- Status bar updating to show running tasks
-
-### 7. Options Window (Edit > Options)
-
-```
-╔════════════════════════════════════════════════════════════════════════════════╗
-║ File  Edit  Run  Help                                     ChatrixCD v1.0      ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║                                                                                ║
-║         ╔═══════════════════════════════════════════════════════╗             ║
-║         ║                      Options                        ║             ║
-║         ╠═══════════════════════════════════════════════════════╣             ║
-║         ║                                                       ║░            ║
-║         ║  Configuration Options                               ║░            ║
-║         ║                                                       ║░            ║
-║         ║           [ Edit Settings ]                         ║░            ║
-║         ║                                                       ║░            ║
-║         ║           [ View Configuration ]                     ║░            ║
-║         ║                                                       ║░            ║
-║         ║           [ Manage Aliases ]                         ║░            ║
-║         ║                                                       ║░            ║
-║         ║                                                       ║░            ║
-║         ║                  [ Close ]                           ║░            ║
-║         ║                                                       ║░            ║
-║         ╚═══════════════════════════════════════════════════════╝░            ║
-║           ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░             ║
-║                                                                                ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║ Idle                                                                           ║
-╚════════════════════════════════════════════════════════════════════════════════╝
-```
-
-The Options screen merges the former SET and SHOW commands into one unified interface:
-- **Edit Settings**: Modify runtime configuration (formerly SET)
-- **View Configuration**: Display current configuration (formerly SHOW)
-- **Manage Aliases**: Add, edit, or remove command aliases
-
-### 8. About Window (Help > About)
-
-```
-╔════════════════════════════════════════════════════════════════════════════════╗
-║ File  Edit  Run  Help                                     ChatrixCD v1.0      ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║                                                                                ║
-║      ╔════════════════════════════════════════════════════════════╗          ║
-║      ║                   About ChatrixCD                       ║          ║
-║      ╠════════════════════════════════════════════════════════════╣          ║
-║      ║                                                            ║░         ║
-║      ║  ChatrixCD                                                 ║░         ║
-║      ║                                                            ║░         ║
-║      ║  Matrix bot for CI/CD automation through chat            ║░         ║
-║      ║                                                            ║░         ║
-║      ║  Features:                                                ║░         ║
-║      ║  • End-to-end encrypted Matrix rooms                     ║░         ║
-║      ║  • Native Matrix authentication (password and OIDC/SSO)  ║░         ║
-║      ║  • Interactive Text User Interface                       ║░         ║
-║      ║  • Semaphore UI integration                              ║░         ║
-║      ║  • Real-time task monitoring                             ║░         ║
-║      ║                                                            ║░         ║
-║      ║  License: GPL v3                                          ║░         ║
-║      ║  Repository: github.com/CJFWeatherhead/ChatrixCD          ║░         ║
-║      ║                                                            ║░         ║
-║      ║                        [ OK ]                           ║░         ║
-║      ║                                                            ║░         ║
-║      ╚════════════════════════════════════════════════════════════╝░         ║
-║        ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░          ║
-║                                                                                ║
-╠════════════════════════════════════════════════════════════════════════════════╣
-║ Idle                                                                           ║
-╚════════════════════════════════════════════════════════════════════════════════╝
-```
-
-The About window displays:
-- Application name and description
-- Key features list
-- License information
-- Repository link
-
-## Menu Structure
-
-### File Menu
-- Status - View bot status
-- Admins - View admin users
-- Rooms - View joined rooms
-- Exit - Quit application
-
-### Edit Menu
-- Sessions - Manage encryption sessions and device verification
-- Options - Configuration management (merged SET and SHOW)
-  - Edit Settings
-  - View Configuration
-  - Manage Aliases
-
-### Run Menu
-- Send - Send messages to rooms (formerly Say)
-
-### Help Menu
-- Show Log - View application logs
-- About - Application information
-- Version - Version and dependencies
-
-## Implementation Details
-
-The Turbo Vision-style TUI is implemented in `chatrixcd/tui_turbo.py` and features:
-
-1. **TurboMenuBar**: Custom menu bar widget with F-key shortcuts
-2. **TurboStatusBar**: Status bar showing idle/running task information
-3. **TurboWindow**: Reusable window container with 3D borders and shadows
-4. **Menu screens**: FileMenuScreen, EditMenuScreen, RunMenuScreen, HelpMenuScreen
-5. **Modal dialogs**: StatusScreen, OptionsScreen, AboutScreen, VersionScreen
-
-All screens reuse existing functionality from the original TUI while providing a more classic, windowed appearance inspired by Turbo Vision.
-
-## Keyboard Shortcuts
-
-- **F1**: Open File menu
-- **F2**: Open Edit menu
-- **F3**: Open Run menu
-- **F4**: Open Help menu
-- **Escape**: Close current screen/menu
-- **Ctrl+C**: Quit application
-
-## Status Bar States
-
-The status bar at the bottom dynamically updates to show:
-- **"Idle"**: No active tasks
-- **"Running X task(s)"**: Number of currently running tasks
-- **"X task(s) (idle)"**: Tasks tracked but not currently running
-
-This provides at-a-glance information about the bot's activity without needing to open additional screens.
diff --git a/tests/test_commands.py b/tests/test_commands.py
index 0e890ec..410ff90 100644
--- a/tests/test_commands.py
+++ b/tests/test_commands.py
@@ -581,15 +581,15 @@ def test_get_logs_truncation(self):
 
     def test_get_display_name(self):
         """Test getting display name from user ID."""
-        # Test with standard Matrix user ID - now keeps @ symbol
+        # Test with standard Matrix user ID - now returns full ID for proper mentions
         result = self.handler._get_display_name('@john:example.com')
-        self.assertEqual(result, '@john')
+        self.assertEqual(result, '@john:example.com')
         
         # Test with user ID containing @ symbol in username
         result = self.handler._get_display_name('@user@domain.com:server.com')
-        self.assertEqual(result, '@user@domain.com')
+        self.assertEqual(result, '@user@domain.com:server.com')
         
-        # Test with invalid user ID (no @ prefix)
+        # Test with invalid user ID (no @ prefix) - returns as-is
         result = self.handler._get_display_name('invalid')
         self.assertEqual(result, 'invalid')
     
@@ -788,5 +788,68 @@ def test_handle_reaction_wrong_user(self):
         self.assertIn('Only', call_args[1])
 
 
+    def test_ansi_to_html_for_pre(self):
+        """Test ANSI to HTML conversion for use in pre tags."""
+        # Test that ANSI codes are stripped for readability
+        text_with_color = "\x1b[31mRed text\x1b[0m"
+        result = self.handler._ansi_to_html_for_pre(text_with_color)
+        self.assertEqual(result, "Red text")
+        self.assertNotIn('\x1b', result)  # No ANSI codes
+        self.assertNotIn('<br>', result)  # Should NOT have br tags
+        
+        # Test bold ANSI codes are stripped
+        text_with_bold = "\x1b[1mBold text\x1b[0m"
+        result = self.handler._ansi_to_html_for_pre(text_with_bold)
+        self.assertEqual(result, "Bold text")
+        self.assertNotIn('\x1b', result)
+        
+        # Test that newlines are preserved (not replaced with <br>)
+        text_with_newlines = "Line 1\nLine 2\nLine 3"
+        result = self.handler._ansi_to_html_for_pre(text_with_newlines)
+        self.assertEqual(result, "Line 1\nLine 2\nLine 3")
+        self.assertNotIn('<br>', result)
+        
+        # Test mixed ANSI codes and text
+        text_mixed = "Normal \x1b[32mgreen\x1b[0m text"
+        result = self.handler._ansi_to_html_for_pre(text_mixed)
+        self.assertEqual(result, "Normal green text")
+
+    def test_markdown_to_html_with_mentions(self):
+        """Test markdown to HTML conversion with Matrix mentions."""
+        # Test Matrix user mention conversion
+        text = "Hello @user:example.com how are you?"
+        result = self.handler.markdown_to_html(text)
+        self.assertIn('<a href="https://matrix.to/#/@user:example.com">@user:example.com</a>', result)
+        
+        # Test bold with mentions
+        text = "Hello @user:example.com **bold text** here"
+        result = self.handler.markdown_to_html(text)
+        self.assertIn('<a href="https://matrix.to/#/@user:example.com">@user:example.com</a>', result)
+        self.assertIn('<strong>bold text</strong>', result)
+        
+        # Test multiple mentions
+        text = "@user1:example.com and @user2:example.org"
+        result = self.handler.markdown_to_html(text)
+        self.assertIn('<a href="https://matrix.to/#/@user1:example.com">@user1:example.com</a>', result)
+        self.assertIn('<a href="https://matrix.to/#/@user2:example.org">@user2:example.org</a>', result)
+        
+        # Test mention with special characters (underscore, plus, equals)
+        text = "@user_name+test=foo:matrix.example.org"
+        result = self.handler.markdown_to_html(text)
+        self.assertIn('<a href="https://matrix.to/#/@user_name+test=foo:matrix.example.org">@user_name+test=foo:matrix.example.org</a>', result)
+
+    def test_get_display_name_returns_full_id(self):
+        """Test that _get_display_name returns full Matrix ID for proper mentions."""
+        # Test with full Matrix ID
+        user_id = "@user:example.com"
+        result = self.handler._get_display_name(user_id)
+        self.assertEqual(result, "@user:example.com")
+        
+        # Test with another format
+        user_id = "@john.doe:matrix.org"
+        result = self.handler._get_display_name(user_id)
+        self.assertEqual(result, "@john.doe:matrix.org")
+
+
 if __name__ == '__main__':
     unittest.main()