Skip to content

Architecture & Platform Overview

SmrtHub combines supervised .NET desktop services with a Python automation fabric. This page sketches the major layers, processes, and data flows so new engineers can form a mental model before diving into component-level docs.

Platform Goals

  • Hybrid runtime: .NET handles Windows-first UI, supervision, and packaging while Python delivers rapid automation features.
  • Deterministic operations: Every binary is supervised, every path is policy-driven, and every log follows the same schema.
  • Extensible surface: Components can be added without rewriting the host thanks to manifest-driven supervision and well-defined contracts.

High-Level Layout

graph TD
    subgraph Desktop Shell (Win32/WinUI3)
        HW[HubWindow]
        TM[TriggerManager]
        CM[ClipboardMonitor]
        SP[SmrtHubSupervisor]
    end

    subgraph Automation Plane (Python)
        PC[python_core]
        DET[smrtdetect]
        FLOW[flow_enhance]
        NET[net \n (Flask bridge + web listener)]
    end

    HW -->|Commands| SP
    TM -->|Triggers| SP
    CM -->|Clipboard Events| SP

    SP -->|Lifecycle| CAP
    SP -->|Lifecycle| DOCS

    SP <--> |IPC| PC
    PC -->|Heartbeat| SP
    NET -->|HTTP Bridge| HW
    DET -->|Signals| PC

Runtime Responsibilities

Layer Key Responsibilities Representative Projects
Supervisor Plane Process orchestration, restart policy, Support Bundle integration SmrtHubSupervisor, Smrt.SupportBundle
Experience Layer Tray/UI, hotkeys, clipboard automation, configuration UX HubWindow, TriggerManager, ClipboardMonitor, Smrt.UI
Automation Plane Python automation services, heartbeat, machine learning helpers python_core, smrtdetect, flow_enhance, net
Focused Services notifications, infrastructure libraries Smrt.Notifications
Shared Libraries Logging, configuration, security & contracts Smrt.Logging, Smrt.Config, Smrt.Security, Smrt.Contracts.Triggers

Process Lifecycle

  1. Supervisor boots – reads component manifest, ensures operational directories exist, initializes Smrt.Logging.
  2. Python fabric starts – supervisor launches the Python bridge; python_core activates heartbeat emitters and waits for orchestration commands.
  3. Runtime apps launch – clipboard, and automation services start according to manifest priorities.
  4. Health feedback loop – heartbeat pulses flow back to the supervisor; degraded state triggers restart policies defined in the manifest.
  5. Support bundle & logging – unified logging sinks allow the operator to export a support bundle with a single command.

Data & Configuration Flow

  • Operational Data: All config/state/logs follow the slugs defined in the Operational Data Policy.
  • SmrtSpace: Acts as the canonical store for captured artifacts; both extraction and automation services write into the same folder hierarchy.
  • Configuration APIs: C# components call into Smrt.Config while Python uses python_core.utils.config_path_resolver to ensure parity.
  • Logging: Every process initializes Smrt.Logging or python_core.utils.logger with the component slug so support bundles can join logs.

Extending SmrtHub

  1. Create a component README detailing the feature’s contract and dependencies.
  2. Add supervision metadata to the manifest with restart policy and health checks.
  3. Implement logging + config using the canonical libraries.
  4. Update navigation by tagging the new README so GenerateComponentDocs.ps1 mirrors it automatically.
  5. Add docstrings (C# XML or Python docstrings) so the API reference reflects the public surface.

Ready to explore individual Components Hub or jump into SmrtHub Policies.