Skip to content

Layering

Layering explains how SmrtHub splits concerns across runtime apps, services, libraries, and the Python core. The page stays high-level on purpose—each layer links to the canonical READMEs and component docs that contain implementation details.

Layer overview

Runtime applications

Desktop operators interact with the WinUI and WPF front-ends (ClipboardMonitor, HubWindow, TriggerManager). These binaries host UI, integrate with Windows, and surface automation controls. Their authoritative docs live in each component README plus the Runtime Apps guide.

Platform services

Long-running background services (SmrtHubSupervisor, MouseHookPipe) power automation across processes. They expose HTTP, pipe, or IPC surfaces while following the same configuration paths defined by the Operational Data Policy. Refer to the Platform Services index for per-service behavior.

Core libraries

Shared .NET libraries (Smrt.Core, Smrt.Config, Smrt.Logging, Smrt.UI, etc.) hold domain primitives, logging, configuration, and UI scaffolding. They are version-pinned centrally per the Central Package Policy. See the Core Libraries list for the full catalog.

Python core engine

SmrtApps/PythonApp hosts the detection, routing, and save pipeline. Modules under python_core (runtime, smrtdetect, smrtspace, flow_enhance, etc.) are documented in their README plus the auto-generated Python modules directory. C# components communicate with the engine exclusively through the HTTP/WS bridge defined there.

Shared policies and tooling

Build scripts, deployment rules, and cross-cutting requirements (logging parity, DPI, assets) are defined in README.Files/*.README.md. Those policies are the source of truth for any change that affects multiple layers. Start with the Architecture & Platform Policy and Documentation Policy when planning structural work.

Why the layers stay independent

  • Stability: a runtime app can update its UI without touching the Python pipeline, because contracts live in Smrt.Config and Smrt.Contracts.
  • Security: platform services isolate privileged operations, preventing UI apps from needing elevated permissions.
  • Deployability: shared libraries ship once and apply everywhere, keeping NuGet governance simple.
  • Observability: logging and support bundles pull from consistent sinks regardless of which layer emits the event.

Update this page only when a new layer is added or removed. Individual components should continue to evolve inside their READMEs and auto-generated docs without requiring edits here.