Sync rhythm playbook

ROST meetings are for decisions. The system should compile the status work before humans meet.

Before Sync

Signal identifies measurables that are off target or stale. Friction ranks issues with evidence. Cascade shows goal movement and blocked work. Agent seats report completed work, handoffs, and escalations.

The Sync Brief should answer:

• What changed?
• Which seats are off track?
• Which issues need a decision?
• Which agent escalations are aging?
• Which goals lack current evidence?

On screen the brief reads in plain terms: Signal exceptions, goal progress, task review, ranked Friction, and agent activity. Where a section has no source data, it lists gaps to confirm — the missing inputs a human should know about before the meeting — rather than a blank section.

Before the first brief exists, the Sync pages are readiness views. They show the next scheduled compile and the source areas that will feed it: Signal, Cascade, Tasks, Friction, and Agents. Use those links to add the missing source data; there is no manual compile button until the system has an idempotent persisted operation to run.

The same readiness model appears around the meeting loop. Steward shows the governance loop even when no decision is waiting: which agent seats are stewarded, how many escalations are open, and recent raised/decided counts. Tasks explains when nothing is due and points to recently completed or agent-blocked work when it exists. The agent fleet shows configuration completeness per staffed agent seat — steward chain, lane/trigger/substrate, credentials, tools, model, dry run, and go-live — with links to the exact setup surface rather than a generic action button.

During Sync

Start with the exceptions, not a tour of every seat. Resolve the highest-value Friction first. Convert decisions into handoffs with owners and dates. Clarify Charters when ownership is ambiguous.

Operate Sync from CLI or MCP

• Compile prep: rost sync compile / sync.brief.compile / rost_compile_sync_brief (idempotent per period). Read it with rost sync brief --json / sync.brief.get / rost_get_sync_brief.
• Run the meeting: sync.run.start / rost_start_sync_run ensures a brief exists; rost sync complete / sync.run.complete / rost_complete_sync_run records that the meeting finished (idempotent).
• Turn agenda items into work: sync.item.assign / rost_assign_sync_follow_up creates a follow-up task from a Sync item with an owner seat.

When to stop for confirmation

sync.brief.compile, sync.brief.get, sync.run.start, sync.run.complete, and sync.item.assign are all none, so a tenant-admin seat runs the weekly rhythm directly without a per-action human gate. An agent can compile the brief and propose assignments ahead of the meeting; the human still owns the meeting and the decisions made in it, but ROST does not force a confirmation on these commands themselves.

After Sync

Decisions should be recorded as human decisions. Handoffs should attach to seats. Recurring ambiguity should become a Charter revision or a graph change.