Release v4.29.0

Policies written as code now bind to the executable semantic model instead of being rejected. This is the third implementation-attachment role from decision 0002, after reducer transitions and rule predicates; proposed decision record 0005 records the role and its composition rule. It also fixes two places where the language silently dropped an authorization condition.

Added

• A policy with a csharp body or a file binds as an opaque policy-predicate attachment with a stable requirement id and the capability pure (SemanticOpaquePolicyCondition). A model that has one is ESM v3, like models with reducer bodies or code validation; other models keep their bytes.
• SemanticExecutionCapability.Authorization, reported when authorization cannot be decided without running policy code.
• PLAY0440: a policy combines require with an inline code block or a file. A policy has one form or the other.
• PLAY0441: a policy has more than one require line. Combine the conditions with and/or in one require.
• Proposed decision record 0005: policy predicates as an implementation-attachment role, and authored-order composition.

Changed

• The reference evaluator does not run policy code. Authorization is evaluated left to right in authored order, as Stage renders it (&&/||) and Arc evaluates it (in declaration order, stopping at the first false): a portable operand that decides first still decides (Portable and Custom denies when Portable denies), but once policy code would run, the outcome is unsupported, never allowed or denied. The same order applies across module, feature and construct gates. A specification whose outcome depends on policy code never passes.
• The documented IsAdultCustomer example no longer reads the clock or throws on a malformed claim: it uses context.Occurred and DateTime.TryParse.

Fixed

• A command or query with two or more authorize lines kept only the last one, so every earlier gate was silently dropped. The lines now combine with AND in authored order, as module and feature gates already did and as the documentation states. Printing writes them as one authorize A and B line. This makes such commands and queries stricter.
• A policy with two require lines silently kept only the last condition. This is now PLAY0441.
• A policy combining require with code bound only the code and dropped the condition once policies with code were admitted; this is now PLAY0440 at parse time.