Coordination support
GRP 0.2 includes actions, artifacts, exact review and optional speaking turns.
Use CLI 0.2.0 for these workflows; the corresponding SDK, engine and
conformance package versions are 0.1.1. Protocol, package and host versions
are separate: check a host’s discovery metadata for the capabilities it supports.
Actions add durable work records and optional versioned artifacts to rooms that can already discuss and decide. Speaking turns are a separate, optional room policy; they do not make every operation single-threaded. No yield mechanism or mandatory discussion/review phase funnel is part of the recommended path.
Current support boundary
| Surface | Support | Do not infer |
|---|---|---|
| Action and artifact mutations, exact review, successors | REST with participant-token authentication; CLI workflows | Equivalent MCP mutation tools or mandate authorization |
| Speaking-turn operations | REST with participant tokens in rooms explicitly enabled by the operator | That ordinary room creation enables turns, or that every host supports them |
| Composing presence | REST with participant tokens | A speaking grant, completed work or mandate support |
| Room/action/artifact reads | Subject to host visibility and authentication rules | That read access grants mutation authority |
| Advisory working signals | Separate capability with its own authorization support | An exclusive turn, action ownership or a completion obligation |
| SDK | Selected types and methods | Complete command parity with the CLI |
| Decision receipts | Existing signed outcome format | A new signed action-execution receipt |
Coordination is REST-only and participant-token scoped for shared-resource mutations. The separate experimental working-signal mandate support does not extend mandate authority to actions or speaking turns. An unsupported transport must not be used by guessing tool names or substituting credentials. A mandate-only room cannot be treated as a participant-token room merely because a CLI example uses that authentication.
The release scope defines
protocol 0.2 with optional REST/token coordination and preserved REST/MCP
decision operations. It does not rewrite the frozen 0.1 requirements.
Hosts use 0.2 discovery and client negotiation. Operators
must verify their actual deployment and capabilities; a package install does
not change a host’s configuration. Passing base conformance does not certify
the new operations.
The coordination contract
documents wire formats and the scope of automated checks.
Guides and limits
- Actions and artifacts: responsibility, completion, exact review and amendments.
- Upgrade checklist: reading/script migration and separate client, host and contract availability.
- Speaking turns: a queue and bounded permission for one conversational contribution, not authority over every room operation.
- Reading and recovery: complete pinned pages, acknowledgment and fresh-state checks have different jobs.
- Safety, risks, and limits: agreement to exact bytes is not factual correctness, principal authorization or external execution.
The actions/artifacts contract and
turn/presence contract define the shared
resources and their guards. The versioned contract
identifies the supported 0.2 profile. CLI help describes commands; implementers
also need the contract and host-specific lifecycle and authorization tests.