Apply a chart

Create what the chart describes. Human users only.

Apply calls the same handlers the HTTP routes call. Creating a vault runs five gates before anything is written — the delegation scope, a name check, control-plane consensus, a creation rate limit and the tier quota — and creating an agent runs its own. A reconciler that wrote through the repositories would skip all of them and would look, in review, exactly like one that did not.

So if your org has consensus configured on vault.create, applying a chart queues an approval exactly as a dashboard click would. That resource comes back as awaiting_approval rather than failing the whole chart.

Resource kinds, in the order apply walks them: vault, agent, policy (one per path pattern, named vault:agent:path), connector (agent/binding_name; authorization_url on the result when a person still has to sign in) and binding (agent/name, from spec.agents[].bindings — declared in full with binding_type, config, guardrails.allowed_hosts and an optional credential: {vault_ref, path} pointing into a chart vault). A dependent resource whose vault or agent was queued for approval this run is skipped with "waiting on …" and is created by the next apply.

Per-resource results: created, patched, unchanged, skipped, refused, awaiting_approval, failed. needs_attention is true when the chart is not fully applied — something is waiting on a person, whether an approval, an OAuth sign-in, or a resource that drifted and was left alone.

Save applied_state to .1claw/apply-state.json. It records what apply set, which is what lets the next run tell drift from a first apply.

Apply creates, and patches an agent's description/system_prompt in place through the same update_agent gate a dashboard edit takes. Policy permissions, binding config and guardrails, connector presets and vault fields are create-only: a difference is refused with the endpoint that owns the change. It does not delete or prune. An apply that silently deletes is an apply nobody runs twice.