Release v4.182.0

Summary

Command logic described in words can now be modeled as a typed, identified requirement that a renderer can stub and verify. You write it as a command whose handler is a pending implementation intent with optional hints, next to its produces.

Added

• A command can declare a pending handler implementation intent with ordered hints beside unconditional produces. The body owns only the event payload values. Which events, their order, destinations, tags, generated values, the response, authorization and validation stay declarative, and event-property mappings become non-normative hints, so required event properties may be left unmapped. See Commands. (#782)
• The executable semantic model version 23 carries a described command's handler requirement (handler { requirementId, resultVersion }), and the requirements sidecar reports it as a Pending CommandHandler requirement with its hints and provisional/ambiguous flags. Models without a described command keep their previous version and bytes, and consumers that do not admit version 23 refuse the model rather than dropping the described logic. (#782)
• Diagnostics PLAY0695 (a command is described but not implemented), PLAY0696 (a described command has no productions or only a response), PLAY0697 (conditional productions under a pending intent) and PLAY0698 (a pending intent next to another handler, in both compilers). (#782)
• Reference execution reports a specification that reaches a described command's body as Unsupported (ImplementationBody), naming the command and its requirement, directly and through reactions. Authorization and validation outcomes are evaluated as before. (#782)
• The MCP handler-intents and implementation-requirements views report pending requirements with their hints and flags, and whether each described command is admitted. (#782)

Changed

• A pending handler intent without produces now fails executable binding with PLAY0696 instead of PLAY0268. Its source stays valid. (#782)