Plan & apply

plan and apply are the core loop. They behave exactly like terraform plan and terraform apply: one reads and previews, the other reconciles reality to match desired state — idempotently.

What it is

gtmesh plan recomputes desired state from your inputs and diffs it against the committed registry. It is read-only and free: it prints the diff to stdout and writes a derived, git-ignored .gtmesh/plan.json, but it changes nothing and spends no API credits.
gtmesh apply makes the registry (and the page files) match what plan showed. It is idempotent — it only acts where there is a real difference, so running it twice in a row does nothing the second time. Terraform-style, it previews the intended actions and prompts Proceed? [y/N] before writing.

You never need plan between a change and an apply — apply computes the same diff itself. plan is the optional preview; apply is the one that writes.

Why it matters

The diff is registry-to-registry: GoToMesh compares the hashes stored in the registry against freshly computed desired state, never by re-reading your rendered pages. That is what makes the loop deterministic (a frozen input always yields the same plan) and auditable (the diff is a reviewable Git change). Because apply is idempotent, an automated nightly or weekly run is harmless when nothing changed.

How it works

plan emits one action per identity — exactly one decision per page that could exist. The action depends on what you changed and whether the row is built or unbuilt:

Action	When	Who acts
`noop`	Nothing changed	—
`catalogue`	A new identity, not yet promoted	Engine
`create`	A new identity, already promoted	Engine (scaffolds the page)
`recompute`	An unbuilt row’s inputs changed	Engine
`rewrite`	A built page’s body inputs changed	The writer (the one LLM step)
`restamp`	A built page’s render projection changed (reason `relink` for a moved edge)	Engine
`redirect`	A slug changed	Human-gated
`prune`	An identity’s input vanished	Human-gated

This drives the two loops. The cheap catalogue loop — extract → plan → apply — keeps the map of everything that could exist in sync, and is safe to schedule. The deliberate production loop — promote → apply → write → seal → publish — decides which catalogued pages to actually build. promote is the gate between them.

Key files & flags

Thing	What it is
`gtmesh plan`	Read-only diff; writes `.gtmesh/plan.json`
`gtmesh plan --json`	Machine-readable plan output
`gtmesh apply`	Preview, confirm, then enact
`gtmesh apply --yes`	Skip the prompt (CI / non-interactive shells)
`gtmesh apply --prune`	Also remove carried-forward rows + bundles (destructive)
`registry/pages.csv`	The committed state the diff is computed against

plan — the read-only diff command
apply — the only writer
Lifecycle & reconcile — what every edit triggers, and who acts on it