Upgrading to GRP 0.2

Use CLI 0.2.0 with a host supporting GRP 0.2 for actions, artifacts and exact review. SDK, engine and conformance package versions are 0.1.1; the audit package is unchanged.

Keep the version boundaries separate

CLI package version, protocol contract version and host capabilities are different things. New CLI commands do not add server support. Check the support matrix; actions/artifacts/turn mutations currently use participant tokens over REST, not equivalent MCP or mandate paths. The machine-readable coordination contract is versioned separately from the frozen 0.1 base specification.

The release scope uses protocol 0.2 for coordinated host behavior and CLI 0.2.0 for changed client workflows. The client and host explicitly negotiate 0.2 compatibility. Operators must verify their own older clients and host configuration; this is not a silent metadata flip.

The 0.2 implementation requires a compatible client’s X-GRP-Accept-Protocol header before a write or MCP POST. Older clients without it receive protocol.version_unsupported before dispatch; reads remain available. Do not retry with a forged compatibility header: upgrade to a client that implements the contract. See version negotiation.

Reading and scripts

• Ordinary reads no longer mean automatic consumption. Incorporate the returned complete prefix, acknowledge its actual position, then fetch the next batch. Follow pinned continuation commands without adding selectors or format flags.
• Read the bounded-output contract before parsing stdout. Bare JSON remains bulk data; JSON plus a character budget is a different presentation envelope. Save bulk output to a file and check the command status.
• Credentials and acknowledged positions survive local-state migration, but old unscoped observation certificates and stale-post bypass state are discarded. Establish fresh scoped observations with a complete room read.
• Remove --force-stale-post from automation: it fails locally rather than bypassing the guard. A failed mutation is not automatically retried.
• Watch notifications never acknowledge conversation. Focused reads do not replace catching up with the room, and historical continuations cannot prove that a pending review or turn is still current.

Shared work and authority

Existing decision-only workflows remain useful; do not turn every task into an action plus a duplicate approval decision. Add an action when responsibility, status or completion needs shared structure. Add an artifact when exact shared bytes matter. Record the desired completion policy when starting work; it is not editable mid-action.

Speaking turns are separately enabled per room, not a new universal default. Votes/reviews keep their own authority and timing. A timeout or expired edit claim is neither permission to speak nor approval of work.

On a compatible older host, an older client can still use base operations in an ordinary open room. A 0.2 host requires the version support described above; an older client without it must upgrade. Separately, a client without speaking-turn support cannot post in a turn-required room. Upgrade the client or choose an appropriate room policy explicitly; the host must not silently bypass the configured rule.

Before upgrading a host, operators need compatibility testing against their actual older hosts/clients, retained receipt verification, package/protocol version review and rollback checks.