zenops 0.20.0

Declarative system configuration management for shell config and dotfiles.
# Getting started

`zenops` keeps your shell config and dotfiles in sync with a single TOML
file at `~/.config/zenops/config.toml`. Declare the shell, environment
variables, aliases, and dotfile placements you want; run `zenops apply`
to bring the machine into agreement; run `zenops status` to see what
would change without touching anything. Most people keep that config in
git and reach for it whenever they bring up a new machine.

## Install

```sh
cargo install zenops
```

zenops is built and tested on macOS, Ubuntu, Fedora, and Arch. It still
runs on other systems, doing what it can on a host it doesn't recognise,
so an unfamiliar distro is a degraded host and never a reason to refuse
to start.

## Initialise a config

If you already keep your dotfiles in a zenops-shaped repo, the fastest
path is to clone and apply in one go:

```sh
zenops init git@github.com:you/dotfiles.git --apply
```

That clones into `~/.config/zenops/`, validates the `config.toml`, and
chains into `zenops apply`.

Starting from scratch instead? Run `zenops init` with no URL — it
prompts for shell, name, and email, then writes a minimal `config.toml`
and makes the initial commit so you have somewhere to grow the config
from. The full set of sections and fields is in the
[configuration reference](./reference/config.md).

A minimal config looks like this:

```toml
[user]
name = "Ada Lovelace"
email = "ada@example.com"

[shell]
type = "bash"

[shell.environment]
EDITOR = "hx"

[shell.alias]
ll = "ls -la"
```

## The apply loop

```sh
zenops status         # see what would change
zenops apply          # make the system match the config
zenops doctor         # diagnose the environment
zenops pkg            # list configured packages and their detect state
```

`status` is read-only. `apply` prompts per change by default — you
confirm each new file, each symlink swap, and each diff hunk of every
updated file before it happens. Pass `--yes` once you trust the config
and want unattended runs.

Both commands speak structured output: add `-o json` to get NDJSON
events suitable for piping into another tool.

## What this site documents

- The [configuration reference]./reference/config.md — every section,
  every field, every enum variant, generated from the schema that ships
  with each release.
- The [command-line interface]./reference/cli.md — every subcommand and
  flag, generated from the clap definitions.

The same site is served by `zenops docs` (embedded in the binary, works
offline) and is published to GitHub Pages at <https://bjorn-ove.github.io/zenops/>.