Outcome
Specify client requests and authoritative results/deltas for movement, targeting, item/container/equipment operations, apply/use, interaction, trade, and reusable semantic actions.
Scope and normative requirements
- Use stable action/request/transaction IDs, revisions, idempotency, preconditions, typed targets, quantities, source context, pending/accepted/rejected/committed/cancelled outcomes, and localized diagnostic codes.
- Define inventory/container/equipment snapshots and revisioned transactions with stable item/template identity, quantities, slots, visibility, identification, rarity, charge, comparison, and explicit semantic metadata.
- Represent interaction catalogs/options and selected actions structurally; client cannot submit an arbitrary server handler name.
- Separate protocol model from internal Go domain structs and Rust UI/session types.
- Bound action rates, targets/shapes, lists/pages, nesting, text/metadata, transaction changes, and stale history.
Acceptance criteria
- Go/Rust fixtures cover every state transition, empty/full/boundary collections, stale/duplicate/replayed requests, partial message, unknown enum/field, and rejected atomic transaction.
- Item ownership never appears partially moved/equipped across a committed protocol transaction.
- UI can implement quantity, quickslot, filters, comparisons, and accessible cues without parsing prose or inferring mechanics.
- Adding a semantic action requires schema/spec/authorization owner and compatibility review.
- Movement/action authority and prediction/presentation boundaries are normative.
Dependencies and parallelization
Depends on common types #3 and transport #2. Server/client item/action services build in parallel against fixtures.
Licensing and scope boundary
Protocol schemas, specifications, fixtures, and generators are MIT. Verified original past work by an approved MIT provenance grantor may be migrated under the recorded provenance grant. Compiled content artifacts are specified by content-toolkit; this repository owns network contracts only.
Outcome
Specify client requests and authoritative results/deltas for movement, targeting, item/container/equipment operations, apply/use, interaction, trade, and reusable semantic actions.
Scope and normative requirements
Acceptance criteria
Dependencies and parallelization
Depends on common types #3 and transport #2. Server/client item/action services build in parallel against fixtures.
Licensing and scope boundary
Protocol schemas, specifications, fixtures, and generators are MIT. Verified original past work by an approved MIT provenance grantor may be migrated under the recorded provenance grant. Compiled content artifacts are specified by content-toolkit; this repository owns network contracts only.