Summary

Expand the current docs/ARCHITECTURE.md (only 60 lines) into a comprehensive architecture document covering component interactions, data flow, threading model, and design decisions.

Parent Issue

Part of: [EPIC] docs: Address documentation gaps across all ecosystem systems (kcenon/common_system#325)

Background (Why)

The current ARCHITECTURE.md is too brief at only 60 lines, providing only a high-level overview. While docs/advanced/ARCHITECTURE_GUIDE.md exists with more detail, the main architecture document should be the definitive reference. The system has 80+ headers across 15 modules (core, collectors, exporters, alert, tracing, reliability, storage, interfaces, adapters, utils, plugins, config, optimization, factory, di) but the architecture document doesn't reflect this complexity.

Scope (What)

Expand docs/ARCHITECTURE.md to cover:

1. System Architecture Diagram

• Complete module dependency graph (15 modules)
• Data flow from collectors → core → exporters
• Event bus pub/sub topology
• Plugin system boundaries

2. Core Pipeline Architecture

• central_collector.h → thread_local_buffer.h → safe_event_dispatcher.h flow
• event_bus.h event routing and subscription model
• performance_monitor.h orchestration role
• result_types.h and error_codes.h error handling flow

3. Threading Model

• Thread-local buffer design (thread_local_buffer.h)
• Thread context management (context/thread_context.h)
• Lock-free queue usage (optimization/lockfree_queue.h)
• Safe event dispatcher thread safety guarantees

4. Plugin Architecture

• Plugin loading lifecycle (plugins/collector_plugin.h)
• Hardware plugin (plugins/hardware/hardware_plugin.h) — battery, power, temp, GPU
• Container plugin (plugins/container/container_plugin.h)
• CRTP collector base pattern (collectors/collector_base.h)

5. Storage Layer

• Backend abstraction (storage/storage_backends.h)
• Supported backends: Memory, File, SQLite, PostgreSQL, MySQL, S3, GCS, Azure
• Backend selection and configuration

6. Adapter & Interface Layer

• interfaces/monitoring_core.h — core abstraction
• interfaces/metric_collector_interface.h — collector contract
• interfaces/monitorable_interface.h — monitorable type contract
• Adapter pattern for cross-system integration

7. Design Decisions

• Why event bus for decoupled communication
• Why thread-local buffering for performance
• Why CRTP for collector base (zero-cost abstraction)
• Why plugin architecture for hardware/container collectors
• C++20 concepts usage (concepts/monitoring_concepts.h)

Acceptance Criteria

• Architecture diagram with all 15 modules
• Data flow diagram from collection to export
• Threading model fully explained
• Plugin architecture documented
• Storage layer architecture covered
• Design decisions documented with rationale
• Document exceeds 300 lines (currently 60)