Operate a mesh

The hard part — the operator bootstrapping loop, scaffolding, the first batch of pages — is behind you. Day-to-day operation is calmer than that, and it follows one rule: you don’t bootstrap again. Once the committed graph exists, you never start from scratch. You change an input and let GoToMesh reconcile the difference.

That reconcile is a short loop you’ll run again and again:

gtmesh pull demand --topic slack   # pull newer keyword data into the bag
gtmesh plan                      # see the diff (read-only — prints to stdout)
gtmesh apply                     # enact it (idempotent — safe to re-run)
gtmesh doctor                    # lint mesh health + get the recommended next action

gtmesh doctor is the health check for the loop — it surfaces structural smells (unresolved keywords, hub pollution, zero-demand landings, committed state gone stale vs config) and points at the file/knob to fix, ending with a recommended next action. Run it after apply, remediate what it flags, and re-plan. See the CLI reference.

The mental model is the same one from mental models: the committed graph is desired state. You edit what feeds it — a keyword pull, a config rule, a reference table — and apply makes reality match. Nothing happens until you apply, and apply only acts where there’s a real difference, so it’s always safe to run.

What you’ll find in this section:

• The refresh loop — the steady-state rhythm: re-pull cadence, why the keyword bag is frozen and timestamped, and why plan is free to re-run as often as you like.
• Lifecycle & reconcile — the heart of operations. Exactly what each kind of edit triggers (rewrite, redirect, a zero-rewrite manifest re-projection…), who acts on it (the writer, the engine, or you), and the deliberate human moves: promote/demote, seal, publish, recreate, amend.
• Editing a page — the decision front door for changing an existing page: input change vs. hand edit, writing vs. sealed, amend vs. recreate.
• Working memory — where the operator’s notes live: the rules file, the decision log, the daily journal, and the task plans — and why current state is derived rather than written down.
• Tuning — the practical “the plan says X is unresolved — which file do I edit?” guide, knob by knob.