@wowok/agent-mcp 3.3.6 → 3.3.8

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": {
@@ -672,7 +672,7 @@
               ]
             },
             "restock": {
-              "description": "Refund restocking (permission 305 SERVICE_SALES). op:'flag' opts ONE live product into restock-on-refund; op:'order' puts the units a REFUNDED order purchased back on shelf. The order path is all-or-nothing: every purchased line must be flagged and still live before any unit moves (otherwise the chain aborts 46/32), so half a restock is impossible. The order path is once-per-order (replay aborts 49) and bound to THIS service (foreign order aborts 26). Do NOT fake a restock with stock_add when the order carries several lines — use op:'order' so quantities come from the order itself.",
+              "description": "Refund restocking (permission 305 SERVICE_SALES). op:'flag' opts ONE live product into restock-on-refund; op:'order' puts the units a REFUNDED order purchased back on shelf. The order path is all-or-nothing: every purchased line must be flagged and still live before any unit moves (otherwise the chain aborts 46/32), so half a restock is impossible. The order path is once-per-order (replay aborts 49) and bound to THIS service (foreign order aborts 26). Do NOT fake a restock with stock_add when the order carries several lines — use op:'order' so quantities come from the order itself. DISCLOSURE: restock reopens sales — if the machine (or its template) has no refund-terminal gate, orders inside their refund window may lose refund eligibility or create fund-accounting ambiguity once restocked units are resold; confirm the machine's refund rail remains reachable after restocking.",
               "oneOf": [
                 {
                   "type": "object",
@@ -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",
@@ -7305,7 +7305,7 @@
               "additionalProperties": false
             },
             "fees_transfer": {
-              "description": "Distribute the withdrawn arbitration fees. Moves the Arbitration's ENTIRE balance in ONE call — there is NO amount parameter. The balance leaves as a CoinWrapper owned by the target (allocation or treasury); for a treasury target, intake it with treasury receive: \"recently\" (permission 253) — see the 'to' field description.",
+              "description": "Distribute the withdrawn arbitration fees. SHAPE (exact — a malformed shape aborts on-chain with CommandArgumentError TypeMismatch, observed on testnet): 'to' is a SINGLE-KEY object with EXACTLY ONE of {allocation: '<Allocation object ID or registered name>'} or {treasury: '<Treasury object ID or registered name>'}. The value must reference an actual Allocation / Treasury OBJECT (its on-chain address or LocalMark name) — a plain wallet address, the Arb case, or the Arbitration registration object is NOT a valid target. payment_index is REQUIRED and must name an existing fee payment record in the Arb case's fees table (list the fees and their indices via onchain_operations type 'q' / onchain_table_data on the Arb case). Moves the Arbitration's ENTIRE balance pool in ONE call — there is NO amount parameter; the pool must be funded first with arb_withdraw. The balance leaves as a CoinWrapper owned by the target; for a treasury target, intake it with treasury receive: \"recently\" (permission 253) — see the 'to' field description.",
               "type": "object",
               "properties": {
                 "to": {
@@ -10973,7 +10973,7 @@
               ]
             },
             "guard_add": {
-              "description": "Add Guard to Reward object. IDIOMS (F08 — these differ from Service allocation, follow THIS shape here): recipient is ONE OF {GuardIdentifier: <u8>} | {Entity: {name_or_address: 'mark'}} | {Signer: 'signer'} (string const INSIDE the key, NOT a bare string) — BUT on the REWARD claim rail the recipient MUST equal the transaction sender (chain assert, abort 14), so {Signer: 'signer'} is the canonical form and {Entity} also passes (SDK replaces it with the claimant's account at claim time); a {GuardIdentifier} recipient resolves to the submitted Order and is STRUCTURALLY UNPAYABLE (every claim aborts 14) — the tool gate rejects it (crs-mn-261015 F-12). amount is {type: 'Fixed', value: '0.1WOW'} — value accepts a display string with token symbol ('0.1WOW') or a smallest-unit integer ('100000000'), NOT the plain balance string used by allocation `sharing`. FULL EXAMPLE: [{guard: '0xabc...', recipient: {Signer: 'signer'}, amount: {type: 'Fixed', value: '0.1WOW'}}].",
+              "description": "Add Guard to Reward object. IDIOMS (F08 — these differ from Service allocation, follow THIS shape here): recipient is ONE OF {GuardIdentifier: <u8>} | {Entity: {name_or_address: 'mark'}} | {Signer: 'signer'} (string const INSIDE the key, NOT a bare string) — BUT on the REWARD claim rail the recipient MUST equal the transaction sender (chain assert, abort 14), so {Signer: 'signer'} is the canonical form and {Entity} also passes (SDK replaces it with the claimant's account at claim time); a {GuardIdentifier} recipient resolves to the submitted Order and is STRUCTURALLY UNPAYABLE (every claim aborts 14) — the tool gate rejects it (crs-mn-261015 F-12). amount is {type: 'Fixed', value: '0.1WOW'} — value accepts a display string with token symbol ('0.1WOW') or a smallest-unit integer ('100000000'), NOT the plain balance string used by allocation `sharing`. FULL EXAMPLE: [{guard: '0xabc...', recipient: {Signer: 'signer'}, amount: {type: 'Fixed', value: '0.1WOW'}}]. OPTIONAL EVIDENCE BINDING (ksk9d2-tn-261026 F-01): an entry may carry evidence {repo, key, predicate} — a claim-time attestation pin that counts ONLY repository rows tied to THIS claim's own store_from value (the submitted order), so borrowed/foreign rows never satisfy the bounty; it requires store_from_id on the same guard (a missing pin aborts 16 at build time) and a claim whose order has no matching attestation row aborts 15.",
               "type": "array",
               "items": {
                 "type": "object",
@@ -11111,6 +11111,40 @@
                         "type": "null"
                       }
                     ]
+                  },
+                  "evidence": {
+                    "description": "ksk9d2-tn-261026 F-01 claim-time attestation pin (reward::evidence_bind). REQUIRES store_from_id on the SAME guard — the binding reads THE pinned store_from row, so the chain aborts 16 (E_EVIDENCE_NEEDS_STORE_FROM) at build time without it. At claim the chain counts repository rows under (repo, key) matching the predicate for the claim's OWN store_from value (the submitted order) via the native evidence_count and aborts 15 (E_EVIDENCE_NOT_OWNED) when none — a borrowed foreign row can never pay.",
+                    "type": "object",
+                    "properties": {
+                      "repo": {
+                        "type": "string",
+                        "description": "Repository object ID or name holding the attestation rows."
+                      },
+                      "key": {
+                        "type": "array",
+                        "items": {
+                          "type": "integer",
+                          "minimum": 0,
+                          "maximum": 255
+                        },
+                        "description": "Repository data key bytes (the policy name the rows live under, e.g. UTF-8 bytes of 'rating')."
+                      },
+                      "predicate": {
+                        "type": "array",
+                        "items": {
+                          "type": "integer",
+                          "minimum": 0,
+                          "maximum": 255
+                        },
+                        "description": "BCS-encoded RepositoryDataPredicateWire bytes — the same predicate blob the repository read channel uses."
+                      }
+                    },
+                    "required": [
+                      "repo",
+                      "key",
+                      "predicate"
+                    ],
+                    "additionalProperties": false
                   }
                 },
                 "required": [
@@ -12401,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": {
@@ -18063,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"
@@ -20777,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": {
@@ -27067,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": {

package/dist/schemas/onchain_operations_arbitration.schema.json

@@ -372,7 +372,7 @@
           "additionalProperties": false
         },
         "fees_transfer": {
-          "description": "Distribute the withdrawn arbitration fees. Moves the Arbitration's ENTIRE balance in ONE call — there is NO amount parameter. The balance leaves as a CoinWrapper owned by the target (allocation or treasury); for a treasury target, intake it with treasury receive: \"recently\" (permission 253) — see the 'to' field description.",
+          "description": "Distribute the withdrawn arbitration fees. SHAPE (exact — a malformed shape aborts on-chain with CommandArgumentError TypeMismatch, observed on testnet): 'to' is a SINGLE-KEY object with EXACTLY ONE of {allocation: '<Allocation object ID or registered name>'} or {treasury: '<Treasury object ID or registered name>'}. The value must reference an actual Allocation / Treasury OBJECT (its on-chain address or LocalMark name) — a plain wallet address, the Arb case, or the Arbitration registration object is NOT a valid target. payment_index is REQUIRED and must name an existing fee payment record in the Arb case's fees table (list the fees and their indices via onchain_operations type 'q' / onchain_table_data on the Arb case). Moves the Arbitration's ENTIRE balance pool in ONE call — there is NO amount parameter; the pool must be funded first with arb_withdraw. The balance leaves as a CoinWrapper owned by the target; for a treasury target, intake it with treasury receive: \"recently\" (permission 253) — see the 'to' field description.",
           "type": "object",
           "properties": {
             "to": {