# Code Map CCM is a declarative configuration management engine written in Go. A manifest or a command names resources and the desired state for each; the engine drives every resource to that state and reports what changed. This code map is a deep-dive into how the Go code is built, for contributors and for anyone who wants to understand the machine behind the manifests. {{% notice style="note" title="Snapshot" %}} Generated 2026-07-10 against commit `d1b8674` on branch `main`. The working tree was clean at capture time. Commits after this one may make parts of this map stale. {{% /notice %}} ## The mental model CCM has one core and many faces. The core is a small loop: a `Manager` holds the run's facts, data, and session; a `Resource` decides whether the system already matches the desired state; a `Provider` makes the platform-specific change when it does not. Every entry point drives that same loop. The CLI applies one resource. The apply engine walks a manifest of many. The background agent applies manifests on a timer. A piped wire API applies a resource sent as JSON. The logic underneath is identical, so behavior does not drift between how a resource is invoked. Providers are selected at run time. A resource type declares a capability interface, and each provider registers a factory that reports whether it can manage the resource on this host. The registry picks the best match from the gathered facts, so the same manifest runs `apt` on Debian and `dnf` on RHEL with no change to the resource.

One core loop, many faces. Every entry point drives the same manager, resource, and provider machinery.

## Explore {{% children description="true" %}} {{% notice style="tip" title="Next" %}} Start with the [Architecture]({{% relref "architecture" %}}) page for the package layering and the contracts every subsystem programs against. {{% /notice %}}