cloudfall 0.5.0__tar.gz → 0.6.0__tar.gz

{cloudfall-0.5.0 → cloudfall-0.6.0}/ARCHITECTURE.md

@@ -1,6 +1,6 @@
 # Architecture
 
-Cloudfall is the operator's record for a small fleet run by an AI agent.
+Cloudfall is the operator's record for self-hosted servers run by an AI agent.
 The agent decides, Ansible executes, and Cloudfall sits between them: it
 declares what the agent may do, checks every result, and keeps the evidence
 behind every decision. Ansible is the hand, the agent is the brain,
@@ -15,7 +15,8 @@ Debian servers without Kubernetes (see the [fleet goals](docs/fleet-goals.md)),
 on a config the team already owns. This document describes the durable
 design; [`ROADMAP.md`](ROADMAP.md) is the authoritative source for what is
 implemented today, and the [brownfield design](docs/brownfield-design.md)
-describes the proposed next step, none of which is built.
+describes the next step, whose operations catalog, gate and record are
+built while safe edits and autonomy from the record are not.
 
 Every layer keeps the same invariants: no action without declared config, no
 status without evidence, no compliance without audit, no decision without a
@@ -32,7 +33,7 @@ Human / AI agent ──runs───► CLI / MCP / Python API ──► Gate
 
 The config is a store, not a pipeline stage: humans and agents edit it
 directly, the CLI validates and reads it, and the engine converges servers
-to it. The agent operates through a stable CLI, the `cloudfall-mcp` server
+to it. The agent operates through a stable CLI, the `cloudfall mcp serve` server
 and a Python API instead of inventing shell commands or discovering
 infrastructure over SSH. Every mutating operation goes through the engine's
 explicit playbook contracts, waits behind a gate the agent does not control