Declarative charts: provisioning that refuses more than it does

Every provisioning step in this course so far has been imperative: create this vault, then this agent, then this policy, one call at a time. 1claw apply takes a single file describing what you want, vaults, agents, policies, connectors, and reconciles reality toward it. If you have used Terraform or Kubernetes manifests, the shape is familiar. What is worth studying closely is not the YAML, it is the list of things apply is built to refuse.

1. 1

   See what a chart would change before it changes anything. This never writes.

   bash Copy

   1claw diff -f chart.yaml

2. 2

   Apply it. Names in the chart are the reconcile keys: a second apply finds what the first one made by name, not by position.

   bash Copy

   1claw apply -f chart.yaml

• It never deletes. A resource removed from the chart is left alone; there is no --prune. An apply that silently deletes is an apply nobody runs twice, and tearing down stays explicit and separate.
• It skips anything edited outside the chart, naming the field that differs, rather than overwriting it. Someone changed it for a reason, and a reconciler that erases that reason at three in the morning is worse than one that does nothing.
• It refuses guardrails outright. Transaction limits, host allowlists and approval policies are not chart fields; a reconciler that wrote them directly would be a way around the guardrail approval flow wearing a deployment tool's clothes.
• It does not skip your org's approval gates. Apply calls the same handlers the API routes call, so a resource that needs consensus queues an approval exactly as a dashboard click would, and the rest of the chart still applies around it.
• Unknown fields are errors, not warnings. A misspelled field that was silently dropped would report success while doing nothing you asked for, and the field's absence would be the only clue.

The drift detection needs a state file, .1claw/apply-state.json, which apply itself writes and reads. That file is what distinguishes "someone edited this since I last applied" from "this existed before I ever ran": a resource that predates your first apply is not drift, and treating it as such would make apply refuse to manage anything that already existed in your org.

This is the same rule fleet rollouts use for hand-edited agents, applied one layer up: a reconciler's job is to move reality toward the declared state, not to erase whatever a human did in between. The two features share that rule because it is the same failure mode either way, an automated tool overwriting a deliberate manual intervention because a file says otherwise.