@wowok/agent-mcp 3.2.2 → 3.2.4

package/dist/schemas/onchain_operations_allocation.schema.json

@@ -74,7 +74,7 @@
                     "properties": {
                       "guard": {
                         "type": "string",
-                        "description": "Guard object ID or name. If Guard verification passes (via Passport), fund allocation for THIS Allocator fires. Each Allocator in an Allocators list can have a different Guard — the first Allocator whose Guard returns true wins. This enables mutually exclusive allocation paths (e.g., refund Guard on 'return_approved' node vs damage Guard on 'damage_confirmed' node)."
+                        "description": "Guard object ID or name. A distribution call submits ONE guard; EVERY Allocator bound to that guard fires — in vector order, each against the balance left by the previous (allocation.move:366-368: the loop matches the submitted guard address, it does NOT evaluate guards competitively). NOT first-match-wins: Allocators with different guards are alternative distribution paths selected by the caller's choice of guard (e.g., a refund guard vs a damage guard), and mutual exclusion must be expressed inside the Guard conditions themselves, never assumed from ordering."
                       },
                       "sharing": {
                         "type": "array",
@@ -90,7 +90,7 @@
                                       "type": "integer",
                                       "minimum": 0,
                                       "maximum": 255,
-                                      "description": "Identifier (0-255) for data lookup in Guard table."
+                                      "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)."
                                     }
                                   },
                                   "required": [
@@ -216,7 +216,7 @@
                     "additionalProperties": false,
                     "description": "Fund allocator — a complete allocation strategy triggered by a Guard. Contains a sharing[] array where items can mix Amount/Rate/RateGross/Surplus modes. When the Guard passes, the contract allocates funds in strict order: Amount → Rate/RateGross → Surplus."
                   },
-                  "description": "Fund allocator list. Each allocator is evaluated in order; the FIRST allocator whose Guard passes wins. This enables mutually exclusive allocation paths (e.g., 3 allocators for 3 forward paths: refund / damage-deduct / arbitrate)."
+                  "description": "Fund allocator list. NOT first-match-wins: a distribution call submits ONE guard and EVERY allocator bound to that guard fires, in vector order, each against the shrinking pool left by the previous (this is how a waterfall like Amount fee + net Rate split is built). Alternative paths (e.g., refund / damage-deduct / arbitrate) are expressed as allocators bound to DIFFERENT guards; the caller's submitted guard selects the path."
                 }
               },
               "required": [
@@ -225,7 +225,7 @@
                 "allocators"
               ],
               "additionalProperties": false,
-              "description": "Fund allocator list — the top-level allocation configuration attached to an Order. Contains a threshold and a list of Allocators. When funds arrive at the Order, the first Allocator whose Guard passes executes its sharing[] in strict order: Amount → Rate/RateGross → Surplus. MULTI-TIER ALLOCATION (DOC-04): Each Order binds ONE Allocators template (set on Service.order_allocators before publish). For multi-tier distribution (e.g., customer→agency→suppliers), use a two-phase approach: (1) Tier-1 Allocators on the customer's Order (allocates to agency + refund fund); (2) Tier-2 Allocators on a NEW Order created by the agency (allocates agency's received funds to suppliers). Each tier's NET Rate-mode sharing[] must independently sum to 10000 (or <= 10000 with Surplus); RateGross-mode sharing[] must sum to <= 10000."
+              "description": "Fund allocator list — the top-level allocation configuration attached to an Order. Contains a threshold and a list of Allocators. A distribution call submits ONE guard; every Allocator bound to that guard executes its sharing[] in strict order (Amount → Rate/RateGross → Surplus) against the shrinking pool. MULTI-TIER ALLOCATION (DOC-04): Each Order binds ONE Allocators template (set on Service.order_allocators before publish). For multi-tier distribution (e.g., customer→agency→suppliers), use a two-phase approach: (1) Tier-1 Allocators on the customer's Order (allocates to agency + refund fund); (2) Tier-2 Allocators on a NEW Order created by the agency (allocates agency's received funds to suppliers). Each tier's NET Rate-mode sharing[] must independently sum to 10000 (or <= 10000 with Surplus); RateGross-mode sharing[] must sum to <= 10000."
             },
             "coin": {
               "anyOf": [
@@ -570,7 +570,7 @@
                       "type": "integer",
                       "minimum": 0,
                       "maximum": 255,
-                      "description": "Identifier (0-255) for data lookup in Guard table."
+                      "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)."
                     },
                     "b_submission": {
                       "type": "boolean",

package/dist/schemas/onchain_operations_arbitration.schema.json

@@ -95,7 +95,7 @@
           "description": "Two ways to specify an object: (1) STRING - Reference an EXISTING object by name or ID; (2) OBJECT - CREATE a NEW object with full configuration including name, tags, description, token type for payments, and Permission-based access control. The object format is used when you need both token specification AND permission management."
         },
         "dispute": {
-          "description": "Create a new Arb object for the order; the case lands directly in state 1 (Arbitrator_confirming) — the customer does not confirm at filing time.",
+          "description": "Create a new Arb object for the order; the case lands directly in state 1 (Arbitrator_confirming) — the customer does not confirm at filing time. FILING IS SERVICE-BOUND: the SDK resolves the order's Service and files through its Service-side dispute entry points, which enforce the merchant's arbitrator allowlist, the service-arbitration neutrality rule and the order binding before the case is minted (venues gated by a usage_guard require the passport path, verified in the same transaction). Direct calls to the removed arbitration-side dispute entries abort with arbitration:10",
           "type": "object",
           "properties": {
             "order": {
@@ -491,7 +491,7 @@
                                 "type": "integer",
                                 "minimum": 0,
                                 "maximum": 255,
-                                "description": "Identifier (0-255) for data lookup in Guard table."
+                                "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)."
                               }
                             },
                             "required": [
@@ -846,7 +846,7 @@
                       "type": "integer",
                       "minimum": 0,
                       "maximum": 255,
-                      "description": "Identifier (0-255) for data lookup in Guard table."
+                      "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)."
                     },
                     "b_submission": {
                       "type": "boolean",

package/dist/schemas/onchain_operations_contact.schema.json

@@ -481,7 +481,7 @@
                       "type": "integer",
                       "minimum": 0,
                       "maximum": 255,
-                      "description": "Identifier (0-255) for data lookup in Guard table."
+                      "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)."
                     },
                     "b_submission": {
                       "type": "boolean",

package/dist/schemas/onchain_operations_demand.schema.json

@@ -250,7 +250,7 @@
                             "type": "integer",
                             "minimum": 0,
                             "maximum": 255,
-                            "description": "Identifier (0-255) for data lookup in Guard table."
+                            "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)."
                           },
                           {
                             "type": "null"
@@ -296,7 +296,7 @@
                             "type": "integer",
                             "minimum": 0,
                             "maximum": 255,
-                            "description": "Identifier (0-255) for data lookup in Guard table."
+                            "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)."
                           },
                           {
                             "type": "null"
@@ -631,7 +631,7 @@
                       "type": "integer",
                       "minimum": 0,
                       "maximum": 255,
-                      "description": "Identifier (0-255) for data lookup in Guard table."
+                      "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)."
                     },
                     "b_submission": {
                       "type": "boolean",

package/dist/schemas/onchain_operations_gen_passport.schema.json

@@ -73,7 +73,7 @@
                       "type": "integer",
                       "minimum": 0,
                       "maximum": 255,
-                      "description": "Identifier (0-255) for data lookup in Guard table."
+                      "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)."
                     },
                     "b_submission": {
                       "type": "boolean",