gtmesh apply

Previews the plan, prompts to confirm, then executes it — the one command that writes the registry and scaffolds page bundles.

gtmesh apply                 # show the actions, prompt to confirm, then enact
gtmesh apply --yes           # skip the prompt (scripts/CI)

What it does

apply is Terraform-style: it prints the intended actions (the same diff as plan) and prompts Proceed? [y/N] before writing. It is idempotent — it only acts when there’s a difference, so it’s always safe to re-run.

What it does depends on each row’s status. On the first run, catalogued rows are recorded in the registry with no page files created. Once you promote rows to an actionable status, the next apply scaffolds each as a bundle folder — content/<slug>/index.yaml holding the schema skeleton plus an engine-owned _brief — and flips the status to writing. So the rule of thumb is: promote rows first, then apply builds them.

Arguments & flags

Reads & writes

• Reads: the same inputs as plan — config, reference tables, seeds, the frozen data bag, and the registry.
• Writes: rows into registry/pages.csv; on promoted rows, scaffolds content/<slug>/index.yaml bundles and flips status to writing. With --prune, removes carried-forward rows and their bundles. On a slug change it moves the bundle and appends a hop to registry/redirects.csv.
• Committed: yes — commit the registry change after each apply.

Examples

gtmesh apply                 # first run: catalogue every row (no page files yet)
gtmesh promote --section glossary
gtmesh apply                 # now scaffolds the promoted rows → writing
gtmesh apply --yes           # non-interactive (CI)
gtmesh apply --prune         # remove rows whose inputs vanished, plus their bundles

Related

• Platform: Plan & apply, Page Registry
• Guide: Walkthrough, Lifecycle & reconcile
• CLI: gtmesh plan, gtmesh promote / demote