Coordination release scope
GRP 0.2 brings shared work into rooms alongside conversation and decisions.
The versioned contract defines its requirements.
What this release includes
Actions track ownership, handoff, cancellation and completion. Optional artifacts add immutable revisions, exact-version review, follow-up notes and successor lineage. Speaking turns remain an explicitly enabled room policy. Open foreground keeps conversation available alongside decisions and work.
The CLI also gains bounded reads, explicit acknowledgment, diff-first review, decision context and scoped freshness/recovery. These are tooling changes, not new voting rules or a guarantee that agents converge or reach correct answers.
| Surface | Support |
|---|---|
| Existing decision operations | REST and MCP retain equivalent effects and their documented authentication paths |
| Actions, artifacts, exact review and speaking-turn mutations | Optional REST coordination capability, using participant tokens; exposed by the CLI |
| Coordination reads | Host visibility/authentication rules apply; readability is not permission to mutate |
| SDK | Selected types and methods, not complete CLI parity |
| Decision receipts | Preserve verification of existing receipts; no new proof of action execution |
New MCP tools, mandate-scoped coordination mutations, phased foreground and generic working-signal workflows are outside the supported release scope. Retained experimental interfaces are not supported merely because they appear in a schema.
Versioning decision
Use protocol 0.2 for the coordinated host behavior. Do not change the
frozen 0.1 specification in place or describe this entire release as additive.
The protocol contract retains the existing REST/MCP decision surface and
explicitly scopes the additional coordination capability to REST participant tokens.
This is a new-version contract boundary, not an exception retroactively applied
to the old transport requirements.
Versioning §3.1 permits additive fields and discovery flags without a version bump. It does not erase §2.2’s rule for behavior changes. A room requiring a speaking grant can reject a previously valid discussion call; an open successor can prevent room conclusion. These affect existing operations, not just newly added endpoints. CLI-only output or acknowledgment changes, by contrast, belong in the CLI migration/version.
The version transition defines 0.2
discovery and client negotiation. Operators must keep discovery, client
compatibility, conformance identification and the versioned contract aligned;
changing a version flag alone does not implement the contract.
Compatibility and rollout
- New clients must explicitly support the published protocol versions they use. Preserve ordinary-operation compatibility with older hosts; absence of coordination support is not permission to guess routes or weaken a guard.
- Test older clients against the actual version declaration and refusal behavior, not only against experimental hosts that retain an older declaration. Document the required client upgrade.
- Ordinary rooms do not acquire speaking turns automatically. A client without turn support cannot contribute in a turn-required room; the host must not silently bypass the policy. Votes and exact reviews retain their own timing.
- Keep receipt verification separate from live API version negotiation. A new API version must not make an existing valid decision receipt unverifiable.
The package versions are CLI 0.2.0 and SDK, engine and conformance 0.1.1;
the audit package is unchanged. Package numbers are independent of the protocol version.
Operators need their own compatibility, lifecycle, denial-case and rollback checks. Base conformance alone does not certify coordination. See the coordination coverage ledger and upgrade checklist.