Working across many sites

The person says: “Add Events to the main menu on all ten venue sites. If it looks wrong, take it back.”

One batch reaches every site; each call on each site is its own call and its own ledger row, and the batch itself is metered as operations times sites (the fan-out). Held in change sets, the change is reversible site by site.

The loop

1. Empress:whoami — the sites, and whether “all” means every site in the workspace.
2. Empress:changeset_create — with sites (slugs, or “all”) and the person’s sentence as title: one set per site, returned by slug.
3. Empress:site_call — the batch: sites, calls (each {tool, args}), and changeset as the map of slug to that site’s set. Read the per-site sentences; a site that refused says why.
4. Empress:changeset_promote — once the person agreed, with changesets as the same map of slug to set and confirm: true: every set goes live in one call, each on its own; one that stops is named and never stops the others.
5. Empress:version_revert — when the person says take it back: each site’s set, to as the promote’s next names it, confirm: true.
6. Empress:site_status — without site: every site at once.

Judgment

• Read before writing everywhere. Empress:content_query with sites: "all" finds what each site has today; a menu that differs per site is not “the same menu”.
• Count the cost first. A batch is calls times sites operations; say the number to the person when it is large.
• Partial success is normal. Promote the sites that worked, report the rest with their sentences, and fix those separately.
• Live writes outside a set have no undo. Use the sets for anything the person may want back.