@wowok/agent-mcp 3.3.7 → 3.3.9

package/dist/schemas/messenger_operation.schema.json

@@ -1884,6 +1884,72 @@
       ],
       "additionalProperties": false
     },
+    {
+      "type": "object",
+      "properties": {
+        "operation": {
+          "type": "string",
+          "const": "mark_conversation_read"
+        },
+        "account": {
+          "description": "Account - can be a string (name/address/mark name) or full object. If not specified, uses default account",
+          "anyOf": [
+            {
+              "description": "Account name, address (0x...), or mark name. When using string format, local marks are searched first. EXAMPLE: 'alice' - searches local marks first, then global; EXAMPLE: '0x2...' (64 hex chars) - uses address directly; EXAMPLE: '' - uses the default local account"
+            },
+            {
+              "type": "object",
+              "properties": {
+                "name_or_address": {
+                  "type": "string",
+                  "description": "Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."
+                },
+                "local_mark_first": {
+                  "description": "Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks",
+                  "type": "boolean"
+                }
+              },
+              "additionalProperties": false,
+              "description": "Account or address lookup object. Use this to specify which account to use for an operation. EXAMPLE: { name_or_address: 'testor2' } - looks up account by name; EXAMPLE: { name_or_address: '0x1234...' } - uses address directly; If name_or_address is empty string '', uses the default local account."
+            }
+          ]
+        },
+        "peerAddress": {
+          "anyOf": [
+            {
+              "description": "Account name, address (0x...), or mark name. When using string format, local marks are searched first. EXAMPLE: 'alice' - searches local marks first, then global; EXAMPLE: '0x2...' (64 hex chars) - uses address directly; EXAMPLE: '' - uses the default local account"
+            },
+            {
+              "type": "object",
+              "properties": {
+                "name_or_address": {
+                  "type": "string",
+                  "description": "Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."
+                },
+                "local_mark_first": {
+                  "description": "Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks",
+                  "type": "boolean"
+                }
+              },
+              "additionalProperties": false,
+              "description": "Account or address lookup object. Use this to specify which account to use for an operation. EXAMPLE: { name_or_address: 'testor2' } - looks up account by name; EXAMPLE: { name_or_address: '0x1234...' } - uses address directly; If name_or_address is empty string '', uses the default local account."
+            }
+          ],
+          "description": "Peer address or account name - can be a string (name/address) or full object"
+        },
+        "through_seq": {
+          "description": "Conversation sequence (leafIndex) to mark read THROUGH, inclusive. Ignored if lower than the current watermark (monotonic). Omit to use the highest RECEIVED seq retained locally. Values beyond the highest received seq are capped and reported (capped=true)",
+          "type": "integer",
+          "minimum": 0,
+          "maximum": 9007199254740991
+        }
+      },
+      "required": [
+        "operation",
+        "peerAddress"
+      ],
+      "additionalProperties": false
+    },
     {
       "type": "object",
       "properties": {
@@ -1915,7 +1981,7 @@
           ]
         },
         "limit": {
-          "description": "Maximum number of messages to pull from server per account",
+          "description": "Maximum number of messages to pull from server per account; in incremental mode (after set) this is the PAGE SIZE of returned messages",
           "type": "number"
         },
         "allAccounts": {
@@ -1954,6 +2020,35 @@
           "type": "number",
           "minimum": 1,
           "maximum": 20
+        },
+        "peerAddress": {
+          "description": "Conversation peer. REQUIRED in incremental mode (when `after` is set) — the cursor is conversation-scoped because the sequence (leafIndex) is per conversation",
+          "anyOf": [
+            {
+              "description": "Account name, address (0x...), or mark name. When using string format, local marks are searched first. EXAMPLE: 'alice' - searches local marks first, then global; EXAMPLE: '0x2...' (64 hex chars) - uses address directly; EXAMPLE: '' - uses the default local account"
+            },
+            {
+              "type": "object",
+              "properties": {
+                "name_or_address": {
+                  "type": "string",
+                  "description": "Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."
+                },
+                "local_mark_first": {
+                  "description": "Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks",
+                  "type": "boolean"
+                }
+              },
+              "additionalProperties": false,
+              "description": "Account or address lookup object. Use this to specify which account to use for an operation. EXAMPLE: { name_or_address: 'testor2' } - looks up account by name; EXAMPLE: { name_or_address: '0x1234...' } - uses address directly; If name_or_address is empty string '', uses the default local account."
+            }
+          ]
+        },
+        "after": {
+          "description": "Incremental cursor: return only messages of this conversation whose sequence (leafIndex) is strictly GREATER than this value, ascending, and return highest_seq/has_more plus gap detection. Omitting `after` keeps the legacy bare-array behavior. Do NOT advance this cursor on watch_messages — watch is a local query, not a consume",
+          "type": "integer",
+          "minimum": 0,
+          "maximum": 9007199254740991
         }
       },
       "required": [

package/dist/schemas/onchain_operations.output.json

@@ -5836,6 +5836,7 @@
                 "state_conflict",
                 "insufficient_balance",
                 "pool_shortage",
+                "allocation_empty",
                 "transaction_expired",
                 "stock_exhausted",
                 "sale_suspended",
@@ -5857,9 +5858,14 @@
                 "submission_unknown",
                 "move_abort_unmapped",
                 "missing_data",
+                "guard_data_missing",
                 "state_not_visible",
+                "unreachable_transition",
+                "forward_not_at_node",
                 "anchor_unavailable",
                 "delivery_unknown",
+                "capability_unavailable",
+                "transport_unavailable",
                 "unknown"
               ]
             },

package/dist/schemas/onchain_operations.schema.json

@@ -178,7 +178,7 @@
                       ]
                     },
                     "discount": {
-                      "description": "Discount object ID or name",
+                      "description": "Discount object ID or name. ⚠️ COUPON OWNERSHIP RULE (KB-02, disclose BEFORE checkout): a coupon held by another address cannot be applied to your order — only the coupon's current holder can redeem it, and the buy is signed by the buyer, so have the owner transfer the coupon to the buyer first (call service discount_send), then attach it here. Attaching the coupon BURNS it (every coupon is single-use), and any later refund settles the POST-coupon amount only (the escrowed discounted total) — the coupon's face value is never restored.",
                       "type": "string"
                     },
                     "payment_remark": {
@@ -943,7 +943,7 @@
               ]
             },
             "discount": {
-              "description": "Issue discount.",
+              "description": "Issue discount (mint coupons bound to this Service). ⚠️ ISSUANCE PRESCRIPTION (KB-02): issuing = MINT then TRANSFER. This field mints the coupon objects under THIS account — its `recipient` field delivers them directly when you know the recipients; for pre-minted campaign coupons held for later handout, the handout itself is discount_send (mint first, transfer to the recipient at distribution time). COUPON SEMANTICS to disclose: HOLDING IS THE CREDENTIAL — the coupon belongs to whoever HOLDS it, only the holder's own signature can spend it, and sharing the coupon's object ID confers nothing; ONE COUPON, ONE BURN — every coupon is single-use and is destroyed on first spend; REFUNDS SETTLE THE POST-COUPON AMOUNT — refund rails pay back the escrowed discounted total only, a cancelled order never restores the coupon's face value. A coupon held by another address cannot be applied to a buyer's order — the owner must discount_send it to the buyer first.",
               "type": "object",
               "properties": {
                 "name": {
@@ -988,7 +988,7 @@
                   "type": "number"
                 },
                 "allow_zero_total": {
-                  "description": "DISCLOSURE-ONLY FLAG — it has NO on-chain effect (F-BS-74: the on-chain Discount struct has no such field; a coupon minted with it is byte-identical to one without, and zero-total BUYS are refused by the chain's zero-total gate regardless — order_new_zero_total_dead_order client-side, abort 42 on-chain). Setting true only downgrades the MCP issuance BLOCK for a coupon that zeroes the cheapest SKU into a warning. There is NO free-product escape hatch today: price a deliberate free tier at 1 smallest unit (or deliver it outside the sales rails). Omit (default) for normal discounts.",
+                  "description": "NO EFFECT — DO NOT SET (BSX-F07: the former escape hatch is removed). This flag has no on-chain field (the on-chain Discount struct never carried it; a coupon minted with it is byte-identical to one without), and it NO LONGER downgrades the MCP issuance block for a coupon that zeroes the cheapest SKU — the block is unconditional: a zeroing coupon can only dead-end at the buyer's checkout (order_new_zero_total_dead_order client-side, abort 42 on-chain). For a deliberate free tier: price the SKU at 1 smallest unit (never 0 — a zero-priced sale is permanently unbuyable) or deliver it outside the sales rails (e.g. a Demand with Signature fulfillment). Omit this field.",
                   "type": "boolean"
                 },
                 "time_ms_end": {
@@ -1058,7 +1058,7 @@
               }
             },
             "discount_send": {
-              "description": "Transfer ALREADY-MINTED coupons you own to another address, instead of destroying them (discount_destroy) or minting new ones (discount). This is a pure ownership handover: the on-chain entry points are public funs with NO Service permission requirement — the only preconditions are that the sender owns each coupon and each was minted transferable:true. Typical use: hand out pre-minted campaign coupons, or move coupons between your own accounts.",
+              "description": "Transfer ALREADY-MINTED coupons you own to another address, instead of destroying them (discount_destroy) or minting new ones (discount). This is a pure ownership handover: the on-chain entry points are public funs with NO Service permission requirement — the only preconditions are that the sender owns each coupon and each was minted transferable:true. Typical use: hand out pre-minted campaign coupons, or move coupons between your own accounts. KB-02 COUPON SEMANTICS: this transfer is the second half of coupon ISSUANCE (mint via `discount`, then transfer here at distribution time). HOLDING IS THE CREDENTIAL: the coupon belongs to whoever HOLDS it — only the holder's own signature can spend it, and sharing the object ID confers nothing. ONE COUPON, ONE BURN: each coupon stays single-use and is destroyed on first spend — transfer does not reset that. REFUNDS SETTLE THE POST-COUPON AMOUNT: refund rails pay the escrowed discounted total only, never the coupon's face value. Until you transfer a gifted coupon, the recipient CANNOT use it on their own orders — a coupon held by another address cannot be applied to their buy.",
               "type": "object",
               "properties": {
                 "discounts": {
@@ -1469,7 +1469,7 @@
               "additionalProperties": false
             },
             "buy_guard": {
-              "description": "Buy guard object ID or name.",
+              "description": "Buy guard object ID or name (null CLEARS the mount). RUNTIME SWITCH (permission 307 SERVICE_BUY_GUARD — the guard OBJECT is immutable but its MOUNT on the Service is mutable at any time). ROUND-ROTATION DUTY (拍板② dm-mtw-261027): for daily/group rounds whose cutoff is an absolute timestamp, the precise batch boundary is THIS mount, not the time guard — at the cutoff instant the keeper cron SETS the buy_guard (new entrants refused at BUY time) and CLEARs/re-arms it when the next round opens; the on-chain Clock >= cutoff comparison stays the settlement/advance authority. Disclose the publisher's time source the cron fires on. Full Machine reuse across rounds (advance gate re-reading a repository cutoff row) is filed for a protocol window.",
               "anyOf": [
                 {
                   "type": "string",
@@ -12435,8 +12435,17 @@
                   "description": "Verify the specified Guard and execute the corresponding fund distribution. GENERIC SEMANTICS: an Allocation distributes whatever balance it holds — order funds, payroll, dividends, bounties. It defines no scenario-specific rule: eligibility (including issuer identity for standalone use, e.g. an org admin) and differentiation inputs are expressed as Guard constraints, all public and auditable. RECIPIENT RESOLUTION (Recipient enum): Entity → fixed address; Signer → transaction sender; GuardIdentifier n → the address submitted for identifier n (resolved from the passport's submission record). ORDER PATTERN (canonical): the Guard table needs ONE submitted Order, constrained by the Guard (e.g. order.service == host service, progress at a qualifying node, signer == order.owner); that order submission IS the recipient slot. Whoever triggers the distribution, funds necessarily land at an Order OBJECT; delivered CoinWrappers are owned by the order and can be extracted only by the Order object itself (Wow ownership) — the coins then go to the order's current owner. Object receipt = owner receipt. POST-DISTRIBUTION CLAIM (required step): each recipient gets a CoinWrapper (not spendable coins) — EOA wallet → operation_type='payment' RECEIVE mode {object:'<coinwrapper_id>', receive:true}; Order object → operation_type='order' {object:'<order_id>', receive:'recently'}; Treasury object → treasury receive. Find pending CoinWrappers via query_toolkit query_type='onchain_received'; verify via the immutable Payment object (allocation.payment array). RISK: safety follows from the sufficiency of the Guard constraints, not the recipient form — analyze the recipient constraint audit before publish; structural residuals (unavoidable): permissionless alloc allows forced settlement timing, the submitted order is not bound to the settled allocation, and allocators/guards are immutable after publish.",
                   "type": "string"
                 },
+                "alloc_batch": {
+                  "description": "Q8-F01 AGGREGATE RELEASE — sweep SEVERAL pools in ONE transaction (allocation::alloc_batch). Provide the COMPLETE pool list INCLUDING 'object': the anchor Allocation addressed by this operation must appear in the list, and the SDK refuses a list that omits it. REQUIRES alloc_by_guard — that one Guard defines the release and is applied to every pool. WHY THIS EXISTS: a crowdfunding settlement holds each backer's escrow in its own Allocation under the SAME release/refund Guard; with single-pool calls a keeper needs N ordered transactions, and any keeper that stops at the first failure strands the remaining pools while the release reports done. ALL-OR-NOTHING: one pool aborting reverts the whole batch. PRE-FILTER drained pools before building the call — a zero-balance pool aborts the ENTIRE batch with EZERO_DISTRIBUTION (14) and nothing is released; an empty candidate set means there is genuinely nothing to release (an empty list is refused with EEMPTY_POOL_BATCH 26 instead of a fake success). EVERY pool must carry an allocator BOUND to alloc_by_guard: an unbound pool completes the sweep having distributed NOTHING, so the SDK verifies membership pool-by-pool and REFUSES the call before any gas is spent. Each recipient still receives a CoinWrapper and claims it through the normal POST-DISTRIBUTION CLAIM step — batching changes the release atomicity, not the claim path.",
+                  "minItems": 1,
+                  "type": "array",
+                  "items": {
+                    "type": "string",
+                    "description": "Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."
+                  }
+                },
                 "acknowledge_dual_payout": {
-                  "description": "A-1 (amz9-ln-261023) explicit opt-in for a KNOWN double payout: when a submitted order already received arbitration compensation (order.claimed_by set) and this call would ALSO release its escrow (refund track), the call is REFUSED unless this flag is true. The two payout tracks are independent by design — the chain will not net or stop the second payout (the escrow receive path has no claimed_by gate), BUT a rail paired on order.claimed_by (refund none / recover some) may guard-reject the second payout on-chain; that rejection is the designed mutual exclusion, and the escrow exits via the paired rail. Buyer NET view: total received = compensation + escrow refund. Leave unset for normal refunds of un-awarded orders.",
+                  "description": "A-1 (amz9-ln-261023; keeper posture 拍板⑧ dm-mtw-261027) explicit opt-in for a KNOWN double payout: when a submitted order already received arbitration compensation (order.claimed_by set) and this call would ALSO release its escrow (refund track), the call is REFUSED unless this flag is true. The two payout tracks are independent by design — the chain will not net or stop the second payout (the escrow receive path has no claimed_by gate), BUT a rail paired on order.claimed_by (refund none / recover some) may guard-reject the second payout on-chain; that rejection is the designed mutual exclusion, and the escrow exits via the paired rail. Buyer NET view: total received = compensation + escrow refund. Leave unset for normal refunds of un-awarded orders. AUTOMATION RULE: this flag is the HUMAN operator's netting decision — an automated keeper that receives dual_payout_unconfirmed must STOP retrying and escalate (never set the flag itself); a retry loop wastes gas and a silent stop strands the payout. D-1 (ksr 5R-08): the flag is additionally honored ONLY when the executing store carries a human-recorded preauthorization (config_operation store_dual_payout_set {account, confirm:true}, then store_dual_payout_get shows preauthorized=true); without it the gate answers dual_payout_preauthorization_required — record the standing decision first, then re-send.",
                   "type": "boolean"
                 },
                 "formula_spec_set": {
@@ -18097,6 +18106,165 @@
                       ],
                       "additionalProperties": false,
                       "description": "Returns VecString. Lists ALL policy key names of the Repository (max 50). Use vec_length to bound per-key composite queries or vec_contains_string to assert a key exists."
+                    },
+                    {
+                      "type": "object",
+                      "properties": {
+                        "type": {
+                          "type": "string",
+                          "const": "query_order_named_operator_member"
+                        },
+                        "object": {
+                          "type": "object",
+                          "properties": {
+                            "identifier": {
+                              "type": "integer",
+                              "minimum": 0,
+                              "maximum": 255,
+                              "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                            }
+                          },
+                          "required": [
+                            "identifier"
+                          ],
+                          "additionalProperties": false,
+                          "description": "Reference to the Order object in the Guard table (must be Address type)."
+                        }
+                      },
+                      "required": [
+                        "type",
+                        "object"
+                      ],
+                      "additionalProperties": false,
+                      "description": "Returns Bool. Whether the transaction signer is on the order's named-operator roster (DM-P1 rider-roster exclusive admission): reads the namedOperator roster of the order's Progress and checks tx-signer membership. Parameterless — the signer comes from the transaction context. Gated by protocol v138 (feature flag enable_order_named_operator_member); on a chain without the flag the guard evaluation aborts. Typical use: AND it into the forward-edge guard on courier handover edges (e.g. PickupOrder/DeliverOrder) so only roster members can advance — the on-chain namedOperator rail alone only AUTHORIZES, it never DENIES (R-19)."
+                    },
+                    {
+                      "type": "object",
+                      "properties": {
+                        "type": {
+                          "type": "string",
+                          "const": "query_repository_data_has"
+                        },
+                        "object": {
+                          "type": "object",
+                          "properties": {
+                            "identifier": {
+                              "type": "integer",
+                              "minimum": 0,
+                              "maximum": 255,
+                              "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                            }
+                          },
+                          "required": [
+                            "identifier"
+                          ],
+                          "additionalProperties": false,
+                          "description": "Reference to the Repository object in the Guard table (must be Address type)."
+                        },
+                        "id": {
+                          "type": "object",
+                          "properties": {
+                            "identifier": {
+                              "type": "integer",
+                              "minimum": 0,
+                              "maximum": 255,
+                              "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                            }
+                          },
+                          "required": [
+                            "identifier"
+                          ],
+                          "additionalProperties": false,
+                          "description": "Reference to the row's principal address (Address type table entry) — the row id the data was written under."
+                        },
+                        "key": {
+                          "type": "string",
+                          "minLength": 1,
+                          "description": "Row name — the policy key string of the data row to probe."
+                        }
+                      },
+                      "required": [
+                        "type",
+                        "object",
+                        "id",
+                        "key"
+                      ],
+                      "additionalProperties": false,
+                      "description": "Returns Bool. Whether the Repository holds a data row for (key, id) — single-row exact read by (key, id), the primitive for per-value mutual-consent attestation (e.g. a settlement keeper asserting the buyer acceptance row exists before executing a refund allocator). NOT protocol-gated (legacy query, works on every chain version)."
+                    },
+                    {
+                      "type": "object",
+                      "properties": {
+                        "type": {
+                          "type": "string",
+                          "const": "query_repository_data"
+                        },
+                        "object": {
+                          "type": "object",
+                          "properties": {
+                            "identifier": {
+                              "type": "integer",
+                              "minimum": 0,
+                              "maximum": 255,
+                              "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                            }
+                          },
+                          "required": [
+                            "identifier"
+                          ],
+                          "additionalProperties": false,
+                          "description": "Reference to the Repository object in the Guard table (must be Address type)."
+                        },
+                        "id": {
+                          "type": "object",
+                          "properties": {
+                            "identifier": {
+                              "type": "integer",
+                              "minimum": 0,
+                              "maximum": 255,
+                              "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                            }
+                          },
+                          "required": [
+                            "identifier"
+                          ],
+                          "additionalProperties": false,
+                          "description": "Reference to the row's principal address (Address type table entry) — the row id the data was written under."
+                        },
+                        "key": {
+                          "type": "string",
+                          "minLength": 1,
+                          "description": "Row name — the policy key string of the data row to read."
+                        },
+                        "conditions": {
+                          "description": "Optional equality conditions compared against the read row bytes; when non-empty the node emits ONE on-chain logic_equal over the read plus all conditions and returns Bool instead of VecU8.",
+                          "type": "array",
+                          "items": {
+                            "type": "object",
+                            "properties": {
+                              "identifier": {
+                                "type": "integer",
+                                "minimum": 0,
+                                "maximum": 255,
+                                "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                              }
+                            },
+                            "required": [
+                              "identifier"
+                            ],
+                            "additionalProperties": false,
+                            "description": "Reference to a VecU8-type table entry whose value must equal the read row — a b_submission slot (the submitted acceptance value) is the typical leg."
+                          }
+                        }
+                      },
+                      "required": [
+                        "type",
+                        "object",
+                        "id",
+                        "key"
+                      ],
+                      "additionalProperties": false,
+                      "description": "Returns VecU8 (the row bytes [type_byte, ...bcs_payload]) — single-row exact read by (key, id), the primitive for per-value mutual-consent attestation. With conditions, returns Bool: the kernel-enforced 'stored value == submitted value' check (b_submission condition entries make the comparison read the passport submission slot) — this turns a self-attested policy write into kernel-verified mutual consent. NOT protocol-gated (legacy query). Absent row: empty blob under the v136 sentinel flag (never equals a non-empty acceptance value — fail-closed), guard abort on older chains."
                     }
                   ],
                   "$ref": "#/definitions/__schema2"
@@ -20811,7 +20979,7 @@
               "additionalProperties": false
             },
             "acknowledge_dual_payout": {
-              "description": "Explicit opt-in for a KNOWN double payout on the compensation-claim direction: when this order's escrow is already FULLY released (allocation balance 0 of a positive order amount) and this call claims the arbitration compensation on top, the call is REFUSED unless this flag is true. The escrow track and the compensation track are independent by design — the chain will not stop the second payout, so the operator must state the netting decision deliberately. Leave unset for claims on orders whose escrow is intact or partially released.",
+              "description": "Explicit opt-in for a KNOWN double payout on the compensation-claim direction (keeper posture 拍板⑧ dm-mtw-261027): when this order's escrow is already FULLY released (allocation balance 0 of a positive order amount) and this call claims the arbitration compensation on top, the call is REFUSED unless this flag is true. The escrow track and the compensation track are independent by design — the chain will not stop the second payout, so the operator must state the netting decision deliberately. Leave unset for claims on orders whose escrow is intact or partially released. AUTOMATION RULE: this flag is the HUMAN operator's netting decision — an automated keeper that receives dual_payout_unconfirmed must STOP retrying and escalate (never set the flag itself). D-1 (ksr 5R-08): the flag is additionally honored ONLY when the executing store carries a human-recorded preauthorization (config_operation store_dual_payout_set {account, confirm:true}, then store_dual_payout_get shows preauthorized=true); without it the gate answers dual_payout_preauthorization_required — record the standing decision first, then re-send.",
               "type": "boolean"
             },
             "arb_case_conclude": {
@@ -27101,6 +27269,165 @@
           ],
           "additionalProperties": false,
           "description": "Returns VecString. Lists ALL policy key names of the Repository (max 50). Use vec_length to bound per-key composite queries or vec_contains_string to assert a key exists."
+        },
+        {
+          "type": "object",
+          "properties": {
+            "type": {
+              "type": "string",
+              "const": "query_order_named_operator_member"
+            },
+            "object": {
+              "type": "object",
+              "properties": {
+                "identifier": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 255,
+                  "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                }
+              },
+              "required": [
+                "identifier"
+              ],
+              "additionalProperties": false,
+              "description": "Reference to the Order object in the Guard table (must be Address type)."
+            }
+          },
+          "required": [
+            "type",
+            "object"
+          ],
+          "additionalProperties": false,
+          "description": "Returns Bool. Whether the transaction signer is on the order's named-operator roster (DM-P1 rider-roster exclusive admission): reads the namedOperator roster of the order's Progress and checks tx-signer membership. Parameterless — the signer comes from the transaction context. Gated by protocol v138 (feature flag enable_order_named_operator_member); on a chain without the flag the guard evaluation aborts. Typical use: AND it into the forward-edge guard on courier handover edges (e.g. PickupOrder/DeliverOrder) so only roster members can advance — the on-chain namedOperator rail alone only AUTHORIZES, it never DENIES (R-19)."
+        },
+        {
+          "type": "object",
+          "properties": {
+            "type": {
+              "type": "string",
+              "const": "query_repository_data_has"
+            },
+            "object": {
+              "type": "object",
+              "properties": {
+                "identifier": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 255,
+                  "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                }
+              },
+              "required": [
+                "identifier"
+              ],
+              "additionalProperties": false,
+              "description": "Reference to the Repository object in the Guard table (must be Address type)."
+            },
+            "id": {
+              "type": "object",
+              "properties": {
+                "identifier": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 255,
+                  "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                }
+              },
+              "required": [
+                "identifier"
+              ],
+              "additionalProperties": false,
+              "description": "Reference to the row's principal address (Address type table entry) — the row id the data was written under."
+            },
+            "key": {
+              "type": "string",
+              "minLength": 1,
+              "description": "Row name — the policy key string of the data row to probe."
+            }
+          },
+          "required": [
+            "type",
+            "object",
+            "id",
+            "key"
+          ],
+          "additionalProperties": false,
+          "description": "Returns Bool. Whether the Repository holds a data row for (key, id) — single-row exact read by (key, id), the primitive for per-value mutual-consent attestation (e.g. a settlement keeper asserting the buyer acceptance row exists before executing a refund allocator). NOT protocol-gated (legacy query, works on every chain version)."
+        },
+        {
+          "type": "object",
+          "properties": {
+            "type": {
+              "type": "string",
+              "const": "query_repository_data"
+            },
+            "object": {
+              "type": "object",
+              "properties": {
+                "identifier": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 255,
+                  "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                }
+              },
+              "required": [
+                "identifier"
+              ],
+              "additionalProperties": false,
+              "description": "Reference to the Repository object in the Guard table (must be Address type)."
+            },
+            "id": {
+              "type": "object",
+              "properties": {
+                "identifier": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 255,
+                  "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                }
+              },
+              "required": [
+                "identifier"
+              ],
+              "additionalProperties": false,
+              "description": "Reference to the row's principal address (Address type table entry) — the row id the data was written under."
+            },
+            "key": {
+              "type": "string",
+              "minLength": 1,
+              "description": "Row name — the policy key string of the data row to read."
+            },
+            "conditions": {
+              "description": "Optional equality conditions compared against the read row bytes; when non-empty the node emits ONE on-chain logic_equal over the read plus all conditions and returns Bool instead of VecU8.",
+              "type": "array",
+              "items": {
+                "type": "object",
+                "properties": {
+                  "identifier": {
+                    "type": "integer",
+                    "minimum": 0,
+                    "maximum": 255,
+                    "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                  }
+                },
+                "required": [
+                  "identifier"
+                ],
+                "additionalProperties": false,
+                "description": "Reference to a VecU8-type table entry whose value must equal the read row — a b_submission slot (the submitted acceptance value) is the typical leg."
+              }
+            }
+          },
+          "required": [
+            "type",
+            "object",
+            "id",
+            "key"
+          ],
+          "additionalProperties": false,
+          "description": "Returns VecU8 (the row bytes [type_byte, ...bcs_payload]) — single-row exact read by (key, id), the primitive for per-value mutual-consent attestation. With conditions, returns Bool: the kernel-enforced 'stored value == submitted value' check (b_submission condition entries make the comparison read the passport submission slot) — this turns a self-attested policy write into kernel-verified mutual consent. NOT protocol-gated (legacy query). Absent row: empty blob under the v136 sentinel flag (never equals a non-empty acceptance value — fail-closed), guard abort on older chains."
         }
       ]
     }

package/dist/schemas/onchain_operations_allocation.schema.json

@@ -423,8 +423,17 @@
               "description": "Verify the specified Guard and execute the corresponding fund distribution. GENERIC SEMANTICS: an Allocation distributes whatever balance it holds — order funds, payroll, dividends, bounties. It defines no scenario-specific rule: eligibility (including issuer identity for standalone use, e.g. an org admin) and differentiation inputs are expressed as Guard constraints, all public and auditable. RECIPIENT RESOLUTION (Recipient enum): Entity → fixed address; Signer → transaction sender; GuardIdentifier n → the address submitted for identifier n (resolved from the passport's submission record). ORDER PATTERN (canonical): the Guard table needs ONE submitted Order, constrained by the Guard (e.g. order.service == host service, progress at a qualifying node, signer == order.owner); that order submission IS the recipient slot. Whoever triggers the distribution, funds necessarily land at an Order OBJECT; delivered CoinWrappers are owned by the order and can be extracted only by the Order object itself (Wow ownership) — the coins then go to the order's current owner. Object receipt = owner receipt. POST-DISTRIBUTION CLAIM (required step): each recipient gets a CoinWrapper (not spendable coins) — EOA wallet → operation_type='payment' RECEIVE mode {object:'<coinwrapper_id>', receive:true}; Order object → operation_type='order' {object:'<order_id>', receive:'recently'}; Treasury object → treasury receive. Find pending CoinWrappers via query_toolkit query_type='onchain_received'; verify via the immutable Payment object (allocation.payment array). RISK: safety follows from the sufficiency of the Guard constraints, not the recipient form — analyze the recipient constraint audit before publish; structural residuals (unavoidable): permissionless alloc allows forced settlement timing, the submitted order is not bound to the settled allocation, and allocators/guards are immutable after publish.",
               "type": "string"
             },
+            "alloc_batch": {
+              "description": "Q8-F01 AGGREGATE RELEASE — sweep SEVERAL pools in ONE transaction (allocation::alloc_batch). Provide the COMPLETE pool list INCLUDING 'object': the anchor Allocation addressed by this operation must appear in the list, and the SDK refuses a list that omits it. REQUIRES alloc_by_guard — that one Guard defines the release and is applied to every pool. WHY THIS EXISTS: a crowdfunding settlement holds each backer's escrow in its own Allocation under the SAME release/refund Guard; with single-pool calls a keeper needs N ordered transactions, and any keeper that stops at the first failure strands the remaining pools while the release reports done. ALL-OR-NOTHING: one pool aborting reverts the whole batch. PRE-FILTER drained pools before building the call — a zero-balance pool aborts the ENTIRE batch with EZERO_DISTRIBUTION (14) and nothing is released; an empty candidate set means there is genuinely nothing to release (an empty list is refused with EEMPTY_POOL_BATCH 26 instead of a fake success). EVERY pool must carry an allocator BOUND to alloc_by_guard: an unbound pool completes the sweep having distributed NOTHING, so the SDK verifies membership pool-by-pool and REFUSES the call before any gas is spent. Each recipient still receives a CoinWrapper and claims it through the normal POST-DISTRIBUTION CLAIM step — batching changes the release atomicity, not the claim path.",
+              "minItems": 1,
+              "type": "array",
+              "items": {
+                "type": "string",
+                "description": "Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."
+              }
+            },
             "acknowledge_dual_payout": {
-              "description": "A-1 (amz9-ln-261023) explicit opt-in for a KNOWN double payout: when a submitted order already received arbitration compensation (order.claimed_by set) and this call would ALSO release its escrow (refund track), the call is REFUSED unless this flag is true. The two payout tracks are independent by design — the chain will not net or stop the second payout (the escrow receive path has no claimed_by gate), BUT a rail paired on order.claimed_by (refund none / recover some) may guard-reject the second payout on-chain; that rejection is the designed mutual exclusion, and the escrow exits via the paired rail. Buyer NET view: total received = compensation + escrow refund. Leave unset for normal refunds of un-awarded orders.",
+              "description": "A-1 (amz9-ln-261023; keeper posture 拍板⑧ dm-mtw-261027) explicit opt-in for a KNOWN double payout: when a submitted order already received arbitration compensation (order.claimed_by set) and this call would ALSO release its escrow (refund track), the call is REFUSED unless this flag is true. The two payout tracks are independent by design — the chain will not net or stop the second payout (the escrow receive path has no claimed_by gate), BUT a rail paired on order.claimed_by (refund none / recover some) may guard-reject the second payout on-chain; that rejection is the designed mutual exclusion, and the escrow exits via the paired rail. Buyer NET view: total received = compensation + escrow refund. Leave unset for normal refunds of un-awarded orders. AUTOMATION RULE: this flag is the HUMAN operator's netting decision — an automated keeper that receives dual_payout_unconfirmed must STOP retrying and escalate (never set the flag itself); a retry loop wastes gas and a silent stop strands the payout. D-1 (ksr 5R-08): the flag is additionally honored ONLY when the executing store carries a human-recorded preauthorization (config_operation store_dual_payout_set {account, confirm:true}, then store_dual_payout_get shows preauthorized=true); without it the gate answers dual_payout_preauthorization_required — record the standing decision first, then re-send.",
               "type": "boolean"
             },
             "formula_spec_set": {