@wowok/agent-mcp 2.6.0 → 2.6.3

package/dist/schemas/onchain_operations_service.schema.json

@@ -147,7 +147,7 @@
                             "number",
                             "string"
                           ],
-                          "description": "Balance type"
+                          "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                         }
                       },
                       "required": [
@@ -170,7 +170,7 @@
                       "additionalProperties": false
                     }
                   ],
-                  "description": "Actual payment amount"
+                  "description": "Actual payment amount. FORMAT: {balance: <amount_in_smallest_unit>} or {coin: <coin_object_id>}. The token type and precision are determined by the Service object's type_parameter (the generic type set when the Service was created). For WOW (9 decimals): {balance: 1000000000} = 1 WOW. For SUI (9 decimals): {balance: 1000000000} = 1 SUI."
                 },
                 "discount": {
                   "type": "string",
@@ -248,15 +248,15 @@
                 }
               },
               "additionalProperties": false,
-              "description": "Set the local name of the order object."
+              "description": "RECOMMENDED: Set a local name for the newly created Order object. Without this, the Order is only referenceable by its on-chain address. Example: {name: 'my_order_v1'} allows subsequent operations to use 'my_order_v1' instead of the address."
             },
             "namedNewAllocation": {
               "$ref": "#/definitions/data/properties/order_new/properties/namedNewOrder",
-              "description": "Set the local name of the order's Allocation object."
+              "description": "RECOMMENDED: Set a local name for the order's Allocation object. Without this, the Allocation is only referenceable by its address. Example: {name: 'my_allocation_v1'} allows alloc_by_guard to reference 'my_allocation_v1'."
             },
             "namedNewProgress": {
               "$ref": "#/definitions/data/properties/order_new/properties/namedNewOrder",
-              "description": "Set the local name of the order's Progress object."
+              "description": "RECOMMENDED: Set a local name for the order's Progress object. Without this, the Progress is only referenceable by its address. Example: {name: 'my_progress_v1'} allows progress operations to use 'my_progress_v1'."
             }
           },
           "required": [
@@ -311,11 +311,11 @@
                       },
                       "wip": {
                         "type": "string",
-                        "description": "HTTP URL of wip file"
+                        "description": "WIP file URL. EMPTY string \"\" skips verification (TESTING ONLY). Production MUST use a real HTTP URL pointing to a .wip file generated by the wip_file tool. Example: \"https://cdn.example.com/products/phone_v1.wip\""
                       },
                       "wip_hash": {
                         "type": "string",
-                        "description": "Hash of WIP. If EMPTY string, the hash within wip will be automatically used; else, the consistency of the hash within wip will be verified with the provided hash."
+                        "description": "WIP file hash (hex string). EMPTY string \"\" skips hash comparison (TESTING ONLY). Production: fill with the hash you saw when viewing the product, to prevent merchant replacing the WIP file before order."
                       }
                     },
                     "required": [
@@ -467,7 +467,7 @@
         },
         "arbitrations": {
           "$ref": "#/definitions/data/properties/repositories",
-          "description": "Service Arbitration object list."
+          "description": "Service Arbitration object list. FORMAT: same as repositories — use the `objects` field name inside the operation data. Example: {arbitrations: [{name: 'my_arb_1'}, {name: 'my_arb_2'}]}. Each item is a NameOrAddress (object ID or local mark name)."
         },
         "machine": {
           "anyOf": [
@@ -490,14 +490,16 @@
             "discount_type": {
               "anyOf": [
                 {
-                  "type": "number",
-                  "const": 0,
-                  "description": "Rate discount type"
+                  "type": "string",
+                  "enum": [
+                    "RATES",
+                    "FIXED"
+                  ]
                 },
                 {
-                  "type": "number",
-                  "const": 1,
-                  "description": "Fixed discount type"
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 1
                 }
               ],
               "description": "Discount type"
@@ -588,7 +590,7 @@
                 "threshold": {
                   "$ref": "#/definitions/data/properties/order_new/properties/buy/properties/total_pay/anyOf/0/properties/balance",
                   "default": 0,
-                  "description": "Threshold. If defined, fund allocation will be triggered when amount in Allocation object reaches this threshold."
+                  "description": "Minimum balance required for allocation to fire. When the Allocation object's balance < threshold, allocation aborts with EINSUFFICIENT_BALANCE=7. Also: when an Allocator has only Amount items (no Rate, no Surplus), the sum of Amount items must be >= threshold (EAMOUNT_BELOW_THRESHOLD=12). Set to 0 (default) to allow any balance."
                 },
                 "allocators": {
                   "type": "array",
@@ -597,7 +599,7 @@
                     "properties": {
                       "guard": {
                         "$ref": "#/definitions/data/properties/object/anyOf/0",
-                        "description": "Guard object ID. If Guard verification passes, fund allocation will start automatically."
+                        "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)."
                       },
                       "sharing": {
                         "type": "array",
@@ -633,7 +635,7 @@
                                     "Entity"
                                   ],
                                   "additionalProperties": false,
-                                  "description": "Determined ID"
+                                  "description": "Static address resolved via LocalMark. Format: {Entity: {name_or_address: 'mark_name'}} — NOTE: Entity is an OBJECT with name_or_address field, NOT a bare string."
                                 },
                                 {
                                   "type": "object",
@@ -647,26 +649,35 @@
                                     "Signer"
                                   ],
                                   "additionalProperties": false,
-                                  "description": "Current transaction signer ID"
+                                  "description": "Current transaction signer (tx_context::sender) at the time of the alloc() call. For refunds, the Order owner must call alloc_by_guard themselves to receive the funds."
                                 }
                               ],
-                              "description": "Recipient ID"
+                              "description": "Recipient of this allocation. Three forms — each resolves the address at a DIFFERENT time:\n• { GuardIdentifier: u8 } — DYNAMIC address resolved from Passport at alloc() time (contract calls passport::submission_get). Use 0 for Order owner in Service-integrated mode (Customer who created the Order). The identifier must match a Guard table entry with b_submission=true. If Passport has no matching submission, contract aborts with E_VERIFY_FAILED. Use when the recipient address is not known at config time and must be supplied via Guard submission data.\n• { Entity: { name_or_address: '...' } } — FIXED address resolved via LocalMark at SDK build time (passed to contract as a literal address). Use for known recipients (e.g., 'turo_host', or a Treasury object address). Use when the recipient is a stable, known address (e.g., operator receives rent, platform fee to treasury).\n• 'Signer' — the transaction sender at the time of the alloc() call (tx_context::sender). RESOLVED AT EXECUTION TIME, not at config time. For refunds: the customer (Order owner) must call alloc_by_guard THEMSELVES so that tx_context::sender resolves to THEIR address — if the operator calls alloc_by_guard, the operator becomes the recipient (Signer = operator), NOT the customer. Use when the recipient is whoever submits the allocation transaction (e.g., customer receives refund)."
                             },
                             "sharing": {
                               "type": [
                                 "number",
                                 "string"
                               ],
-                              "description": "Reward allocation value"
+                              "description": "Allocation value. SEMANTICS DEPEND ON `mode`:\n• mode='Amount': absolute amount in smallest unit (e.g., '750000000' for 0.75 WOW, '250000000' for 0.25 WOW). Allocated first; sum of Amount items cached as `fix`.\n• mode='Rate': basis-points rate, 10000 = 100% (e.g., '7500' for 75%, '2500' for 25%). When no Surplus in same Allocator, sum MUST == 10000; when Surplus present, sum MUST <= 10000.\n• mode='Surplus': IGNORED (contract forces to 0). Set to '0' for clarity. Receives remaining balance after Amount + Rate allocations."
                             },
                             "mode": {
-                              "type": "string",
-                              "enum": [
-                                "Amount",
-                                "Rate",
-                                "Surplus"
+                              "anyOf": [
+                                {
+                                  "type": "string",
+                                  "enum": [
+                                    "Amount",
+                                    "Rate",
+                                    "Surplus"
+                                  ]
+                                },
+                                {
+                                  "type": "integer",
+                                  "minimum": 0,
+                                  "maximum": 2
+                                }
                               ],
-                              "description": "Reward allocation mode"
+                              "description": "Allocation mode — determines how the `sharing` field is interpreted. Three modes can be used individually OR combined within a single Allocator; when combined, allocation order is strictly: Amount first, then Rate, then Surplus. Understanding these modes allows modeling almost any fund distribution pattern.\n• Amount (0): `sharing` is a FIXED amount in smallest unit (e.g., '750000000' = 0.75 WOW). Allocated FIRST; sum of all Amount items is cached as `fix` by the contract. Validation: when no Rate and no Surplus items exist, sum of Amount items must be >= allocators.threshold (EAMOUNT_BELOW_THRESHOLD=12); when `max` is set, sum of Amount items must be <= max (EAMOUNT_EXCEEDS_MAX=13).\n• Rate (1): `sharing` is a basis-points rate (10000 = 100%). Allocated AFTER Amount; formula: allocated = (sharing × total_rates) / 10000, where total_rates = balance - fix (or max - fix if `max` is set). Validation: when no Surplus items exist, sum of all Rate items must be EXACTLY 10000 (ERATE_NOT_10000=4); when Surplus items exist, sum of all Rate items must be <= 10000 (ERATE_EXCEEDS_10000=6).\n• Surplus (2): `sharing` is IGNORED (contract forces it to 0). Allocated LAST; receives the remaining balance after Amount + Rate allocations. Validation: MAX ONE Surplus item per Allocator (EMULTIPLE_SURPLUS=5). When Surplus exists, Rate sum constraint relaxes from == 10000 to <= 10000.\nALLOCATION ORDER (strict): Amount items (fixed, cached as fix) → Rate items (proportional to balance-fix) → Surplus item (remaining).\nRECOMMENDATION: Use Amount mode for known fixed amounts (clearer, no sum constraint). Use Rate mode for proportional splits (requires sum == 10000 unless Surplus present). Use Surplus to capture remainder (e.g., platform fee + host gets rest). Accepts string ('Amount'/'Rate'/'Surplus', recommended) or number (0/1/2)."
                             }
                           },
                           "required": [
@@ -675,13 +686,13 @@
                             "mode"
                           ],
                           "additionalProperties": false,
-                          "description": "Fund allocation item"
+                          "description": "Fund allocation item — one recipient's share of the Allocation balance. The `sharing` value's meaning depends on `mode` (see AllocationModeSchema). Multiple items in the same Allocator are evaluated together: Amount items first, Rate items second, Surplus last."
                         },
-                        "description": "Fund allocation item list. Each item represents a recipient and their corresponding reward allocation value."
+                        "description": "Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate + Surplus) within the same Allocator. ALLOCATION ORDER: Amount items first (cached as fix) → Rate items (proportional to balance - fix) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); Amount sum must >= threshold (no Rate and no Surplus) and <= max (if max set)."
                       },
                       "fix": {
                         "$ref": "#/definitions/data/properties/order_new/properties/buy/properties/total_pay/anyOf/0/properties/balance",
-                        "description": "Fixed allocation amount. If specified, all recipients will receive the fixed allocation amount."
+                        "description": "OUTPUT-ONLY (query result). Cached sum of all Amount-mode `sharing` values in this Allocator. Computed by the contract during `allocator_add` — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for Rate allocation."
                       },
                       "max": {
                         "anyOf": [
@@ -692,7 +703,7 @@
                             "type": "null"
                           }
                         ],
-                        "description": "Maximum allocation amount. If specified, allocation amount cannot exceed maximum allocation amount."
+                        "description": "Maximum allocation cap (OPTIONAL — omit the field or set to null to disable the cap; do NOT set to 0 as that means a cap of zero). Passed through to the contract as Option<u64> via allocator_add(): when null/omitted the contract treats it as `none` (no cap); when set, the contract enforces it. Has THREE effects when set:\n1. Construction: sum of Amount items must be <= max (EAMOUNT_EXCEEDS_MAX=13)\n2. Rate execution: total_rates = max - fix (instead of balance - fix)\n3. Surplus execution: surplus_amount = max - alloced_amount (instead of balance - alloced_amount)\nUse when you want to cap total allocation regardless of Order balance (e.g., cap payout to declared amount). SDK pre-validates Amount sum <= max at build time to give actionable error messages before on-chain abort."
                       }
                     },
                     "required": [
@@ -700,9 +711,9 @@
                       "sharing"
                     ],
                     "additionalProperties": false,
-                    "description": "Fund allocator"
+                    "description": "Fund allocator — a complete allocation strategy triggered by a Guard. Contains a sharing[] array where items can mix Amount/Rate/Surplus modes. When the Guard passes, the contract allocates funds in strict order: Amount → Rate → Surplus."
                   },
-                  "description": "Fund allocator list. Each fund allocator represents a fund allocation strategy."
+                  "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)."
                 }
               },
               "required": [
@@ -710,13 +721,13 @@
                 "allocators"
               ],
               "additionalProperties": false,
-              "description": "Fund allocator list"
+              "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 → 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 Rate-mode sharing[] must independently sum to 10000 (or <= 10000 with Surplus)."
             },
             {
               "type": "null"
             }
           ],
-          "description": "Order fund allocator."
+          "description": "Order fund allocator. Max 100 allocators (MAX_ALLOCATOR_COUNT). Each allocator has a guard (first matching guard wins) and a sharing list. Set to null to clear. ⚠️ PERMANENTLY IMMUTABLE after publish: order_allocators can ONLY be set BEFORE publish=true (Move service.move:503: assert!(!self.bPublished, E_ALREADY_PUBLISHED)). After publish, the ONLY way to change allocation rules is to create a NEW Service object. There is NO pause+lock exception for order_allocators (unlike arbitrations/rewards which have time-lock removal). PRE-PUBLISH CHECKLIST: verify all guard names resolve, all sharing amounts are correct, threshold is set, and recipient types (Entity/Signer/GuardIdentifier) are intended before calling publish=true. GuardIdentifier sharing mode: {who: {GuardIdentifier: <u8>}, sharing: <rate>, mode: 'Rate'} — resolves recipient from Guard table submission at allocation time (e.g., refund to customer). MULTI-CALL ALLOCATION: Allocation.alloc() can be called MULTIPLE times (no consumed flag in contract). Use Amount mode (not Surplus) for recurring allocations — Surplus calls balance::withdraw_all which drains the balance. For monthly payment scenarios, create multiple Allocators with time-based Guards + Amount mode sharing items."
         },
         "buy_guard": {
           "anyOf": [
@@ -738,11 +749,71 @@
               "$ref": "#/definitions/data/properties/order_new/properties/buy/properties/total_pay/anyOf/1"
             }
           ],
-          "description": "Compensation fund. Used to claim compensation based on the arbitration result of the Arb object when resolving order disputes."
+          "description": "Deposit funds into the Service compensation_fund. Used to pay indemnity when arbitration resolves in customer's favor. FORMAT: {balance: <amount_in_smallest_unit>} — the field name is 'balance' (NOT 'amount'). The token type and precision are determined by the Service object's type_parameter (the generic type set when the Service was created). For WOW (9 decimals): {balance: 1000000000} = 1 WOW. For SUI (9 decimals): {balance: 1000000000} = 1 SUI. For tokens with different decimals, adjust accordingly (e.g. USDC has 6 decimals, so {balance: 1000000} = 1 USDC). REQUIRES: Permission index 315 (SERVICE_COMPENSATION_FUND_DEPOSIT) must be granted to the calling account first. COMMON MISTAKE: using {amount: ...} or {amount: ..., type: 'WOW'} — these will fail. The correct field is 'balance'."
+        },
+        "compensation_fund_withdraw": {
+          "type": "object",
+          "properties": {
+            "receipt": {
+              "type": "object",
+              "properties": {
+                "name_or_address": {
+                  "$ref": "#/definitions/data/properties/order_new/properties/agents/properties/entities/items/properties/name_or_address"
+                },
+                "local_mark_first": {
+                  "$ref": "#/definitions/data/properties/order_new/properties/agents/properties/entities/items/properties/local_mark_first"
+                }
+              },
+              "additionalProperties": false,
+              "description": "Receipt address that will receive the withdrawn funds (as a new Payment object)"
+            },
+            "payment_info": {
+              "type": "object",
+              "properties": {
+                "for_object": {
+                  "type": [
+                    "string",
+                    "null"
+                  ],
+                  "description": "Payment for a specific object ID"
+                },
+                "for_guard": {
+                  "type": [
+                    "string",
+                    "null"
+                  ],
+                  "description": "Payment to satisfy verification of a Guard object"
+                },
+                "remark": {
+                  "type": "string",
+                  "description": "Payment record remark"
+                },
+                "index": {
+                  "type": [
+                    "number",
+                    "string"
+                  ],
+                  "description": "Payment record index"
+                }
+              },
+              "required": [
+                "remark",
+                "index"
+              ],
+              "additionalProperties": false,
+              "description": "Payment info for the new Payment object created to hold the withdrawn funds"
+            }
+          },
+          "required": [
+            "receipt",
+            "payment_info"
+          ],
+          "additionalProperties": false,
+          "description": "Withdraw ALL funds from the compensation_fund to a new Payment object owned by `receipt`. Move layer: service::compensation_fund_withdraw (service.move L383-390). REQUIRES: Service must be paused AND setting_lock_duration must have elapsed since pause (assert_not_published at L384-385). Withdraws the ENTIRE compensation_fund balance via balance::withdraw_all. DIFFERENT from compensation_claim (order-side, for arbitration-winning users, no pause+lock required)."
         },
-        "setting_locked_time_add": {
+        "setting_lock_duration_add": {
           "type": "number",
-          "description": "Additional lock duration (milliseconds) to extend the 'setting_lock_duration'. Initial value is 30 days, can only be increased, not decreased. Affects: rewards, arbitrations, and compensation_fund_receive."
+          "description": "Additional lock duration to ADD to 'setting_lock_duration' (Move field name). UNIT: milliseconds (ms). Example: 2592000000 = 30 days, 7776000000 = 90 days, 86400000 = 1 day. DEFAULT: 2592000000 (30 days, DEFAULT_LOCK_DURATION). This is the initial value when a Service is created. Behavior: additive (safe_add) — only increases, never decreases. Move entry: service::setting_lock_duration_add / setting_lock_duration_add_with_passport. Can be called BEFORE or AFTER publish (no publish check). Affects the waiting time required by: compensation_fund_withdraw, arbitrations remove/clear, rewards remove/clear (all require pause + setting_lock_duration elapsed since pause)."
         },
         "compensation_fund_receive": {
           "anyOf": [
@@ -797,7 +868,7 @@
               "const": "recently"
             }
           ],
-          "description": "Receive order compensation funds."
+          "description": "Receive order compensation funds from this Service object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received balance.\n  Use this for the common case: \"deposit all recently received coins into pending balance.\"\n  Example: receive: 'recently'\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a specific balance record from a Payment/payer.\n  Use this when targeting a specific received balance (advanced).\n  Example: receive: {token_type: '0x2::sui::SUI', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly."
         },
         "owner_receive": {
           "anyOf": [
@@ -836,7 +907,7 @@
               "const": "recently"
             }
           ],
-          "description": "Unwrap CoinWrapper objects and other objects received by this object and send them to the owner of its Permission object."
+          "description": "Unwrap CoinWrapper objects and other objects received by this Service object and send them to the owner of its Permission object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::sui::SUI>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::sui::SUI', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly."
         },
         "um": {
           "anyOf": [
@@ -855,7 +926,7 @@
         },
         "publish": {
           "type": "boolean",
-          "description": "Whether to publish the Service. After publishing, customers can place orders; at the same time, service commitments such as machine, order_allocators, arbitrations, etc. will be immutable."
+          "description": "Whether to publish the Service. After publishing, customers can place orders. VERIFIED against Move source service.move + SDK service.ts (4-level immutability matrix):\n  L1 — PERMANENTLY LOCKED after publish (assert!(!bPublished), no pause+lock exception):\n    • machine          (service.move L633/L653 — workflow template)\n    • order_allocators (service.move L503 — fund distribution rules)\n  L2 — TIME-LOCKED after publish (assert_not_published — requires pause + setting_lock_duration elapsed):\n    • arbitrations remove/clear (service.move L433/L445 — dispute resolution objects)\n    • rewards remove/clear       (service.move L402/L414 — reward objects)\n    • compensation_fund_withdraw (service.move L384-385 — withdraw ALL funds)\n  L3 — REMAIN MUTABLE after publish (no SDK check, no Move check):\n    • arbitrations add, rewards add (no assert — can add after publish)\n    • buy_guard, sales, discount, description, location, pause, repositories,\n    • compensation_fund_add, setting_lock_duration_add, customer_required, um (Contact)\nThese 2 L1-LOCKED fields (machine/order_allocators) MUST be set BEFORE publish=true.\narbitrations/rewards can be ADDED after publish but remove/clear requires pause+lock.\n\n⚠️ COMPENSATION_FUND + ARBITRATION LINKAGE (service.move:494-499):\n  At publish time, if compensation_fund > 0, Arbitration MUST be bound:\n    if (balance::value(&self.compensation_fund) > 0) {\n        assert!(arbitration_count > 0, E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND);\n    }\n  The MCP handler enforces this as a HARD PRE-CHECK: if publish=true AND compensation_fund_add   is set in the same call AND arbitrations is empty, the call is REJECTED before submission.   If compensation_fund was deposited in a prior call, a SOFT WARNING is issued.\n\nSCHEMA-03 / P0-01 fix — DEPLOYMENT WORKFLOW (two-phase, avoids circular dependency):\n  Phase 1 — CREATE (no publish): object={name:'my-service', type_parameter, permission} + machine + order_allocators + arbitrations.\n    NOTE: buy_guard can use a LocalMark NAME (not address) to break the Guard→Service circular dependency.\n    The name is resolved to an address at transaction build time.\n  Phase 2 — PUBLISH: object='my-service' (string ref) + publish=true.\n    All L1-LOCKED fields must be set in Phase 1; Phase 2 only flips the publish flag.\n  Post-publish updates: buy_guard, sales, description, repositories (add), rewards (add), arbitrations (add), etc."
         }
       },
       "required": [
@@ -890,7 +961,7 @@
             "testnet",
             "mainnet"
           ],
-          "description": "Network entrypoint: Specifies which network the operation occurs on"
+          "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Use project_operation action='clone_project_to_network' to clone the project blueprint to the target network, then re-run onchain_operations with env.network=target_network to deploy."
         },
         "referrer": {
           "$ref": "#/definitions/env/properties/account",
@@ -980,7 +1051,7 @@
                     },
                     "b_submission": {
                       "type": "boolean",
-                      "description": "Whether user submission is required for this data"
+                      "description": "Whether this table item's value is submitted dynamically at Guard trigger time (alloc_by_guard call). \n\ntrue = value is submitted by the caller when triggering the Guard. Use for runtime-context-dependent values like order address, user address. The 'value' field is ignored when b_submission=true; the caller must provide it via submissions[]. \n\nfalse = value is static, set at Guard creation time. Use for values known when the Guard is created: expected node names, expected merchant address, expected service address. The 'value' field must be populated and will be stored on-chain permanently. \n\nRule of thumb: if the value is the SAME for all future Guard triggers, use false. If the value DIFFERS per trigger (e.g., which order to release funds for), use true."
                     },
                     "value_type": {
                       "anyOf": [
@@ -1270,7 +1341,7 @@
                           "description": "vecvecu8"
                         }
                       ],
-                      "description": "Type of the value"
+                      "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
                     },
                     "value": {
                       "anyOf": [
@@ -1363,12 +1434,12 @@
                           }
                         }
                       ],
-                      "description": "The actual value data"
+                      "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission)."
                     },
                     "name": {
                       "type": "string",
                       "default": "",
-                      "description": "Name or description of this data"
+                      "description": "Data name identifier. MAX 64 BCS characters (Chinese chars count as 3-4 BCS bytes each). Use short identifiers like 'order_id', 'delivery_node'. Put longer descriptions in the Guard's 'description' field, NOT here."
                     },
                     "object_type": {
                       "type": "string",
@@ -1406,7 +1477,7 @@
                         "TableItem_AddressMark",
                         "TableItem_EntityRegistrar"
                       ],
-                      "description": "Object type when value_type is Address and represents a specific object"
+                      "description": "OUTPUT-ONLY (query side): Object type when value_type is Address and represents a specific object. Auto-derived by the system — DO NOT set this field at Guard creation."
                     }
                   },
                   "required": [
@@ -1415,7 +1486,7 @@
                     "value_type"
                   ],
                   "additionalProperties": false,
-                  "description": "Guard table item"
+                  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
                 },
                 "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
               }
@@ -1427,7 +1498,7 @@
             "additionalProperties": false,
             "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
           },
-          "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission."
+          "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
         }
       },
       "required": [

package/dist/schemas/onchain_operations_treasury.schema.json

@@ -115,7 +115,7 @@
                     "number",
                     "string"
                   ],
-                  "description": "Balance type"
+                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -162,7 +162,7 @@
               "const": "recently"
             }
           ],
-          "description": "Receive CoinWrapper objects received by the object and deposit them into its balance."
+          "description": "Receive CoinWrapper objects received by this Treasury object and deposit them into its balance.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received balance.\n  Use this for the common case: \"deposit all recently received coins into pending balance.\"\n  Example: receive: 'recently'\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a specific balance record from a Payment/payer.\n  Use this when targeting a specific received balance (advanced).\n  Example: receive: {token_type: '0x2::sui::SUI', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly."
         },
         "deposit": {
           "type": "object",
@@ -588,7 +588,7 @@
               "const": "recently"
             }
           ],
-          "description": "Unwrap CoinWrapper objects and other objects received by this object and send them to the owner of its Permission object."
+          "description": "Unwrap CoinWrapper objects and other objects received by this Treasury object and send them to the owner of its Permission object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::sui::SUI>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::sui::SUI', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly."
         },
         "um": {
           "anyOf": [
@@ -634,7 +634,7 @@
             "testnet",
             "mainnet"
           ],
-          "description": "Network entrypoint: Specifies which network the operation occurs on"
+          "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Use project_operation action='clone_project_to_network' to clone the project blueprint to the target network, then re-run onchain_operations with env.network=target_network to deploy."
         },
         "referrer": {
           "$ref": "#/definitions/env/properties/account",
@@ -724,7 +724,7 @@
                     },
                     "b_submission": {
                       "type": "boolean",
-                      "description": "Whether user submission is required for this data"
+                      "description": "Whether this table item's value is submitted dynamically at Guard trigger time (alloc_by_guard call). \n\ntrue = value is submitted by the caller when triggering the Guard. Use for runtime-context-dependent values like order address, user address. The 'value' field is ignored when b_submission=true; the caller must provide it via submissions[]. \n\nfalse = value is static, set at Guard creation time. Use for values known when the Guard is created: expected node names, expected merchant address, expected service address. The 'value' field must be populated and will be stored on-chain permanently. \n\nRule of thumb: if the value is the SAME for all future Guard triggers, use false. If the value DIFFERS per trigger (e.g., which order to release funds for), use true."
                     },
                     "value_type": {
                       "anyOf": [
@@ -1014,7 +1014,7 @@
                           "description": "vecvecu8"
                         }
                       ],
-                      "description": "Type of the value"
+                      "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
                     },
                     "value": {
                       "anyOf": [
@@ -1107,12 +1107,12 @@
                           }
                         }
                       ],
-                      "description": "The actual value data"
+                      "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission)."
                     },
                     "name": {
                       "type": "string",
                       "default": "",
-                      "description": "Name or description of this data"
+                      "description": "Data name identifier. MAX 64 BCS characters (Chinese chars count as 3-4 BCS bytes each). Use short identifiers like 'order_id', 'delivery_node'. Put longer descriptions in the Guard's 'description' field, NOT here."
                     },
                     "object_type": {
                       "type": "string",
@@ -1150,7 +1150,7 @@
                         "TableItem_AddressMark",
                         "TableItem_EntityRegistrar"
                       ],
-                      "description": "Object type when value_type is Address and represents a specific object"
+                      "description": "OUTPUT-ONLY (query side): Object type when value_type is Address and represents a specific object. Auto-derived by the system — DO NOT set this field at Guard creation."
                     }
                   },
                   "required": [
@@ -1159,7 +1159,7 @@
                     "value_type"
                   ],
                   "additionalProperties": false,
-                  "description": "Guard table item"
+                  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
                 },
                 "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
               }
@@ -1171,7 +1171,7 @@
             "additionalProperties": false,
             "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
           },
-          "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission."
+          "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
         }
       },
       "required": [

package/dist/schemas/onchain_table_data.output.json

@@ -1582,7 +1582,7 @@
                             "properties": {
                               "prev_node": {
                                 "type": "string",
-                                "description": "Previous node name"
+                                "description": "Previous node name. Empty string '' means initial entry node (the first node in the workflow)."
                               },
                               "threshold": {
                                 "type": [
@@ -1642,38 +1642,46 @@
                                     "guard": {
                                       "anyOf": [
                                         {
-                                          "type": "object",
-                                          "properties": {
-                                            "guard": {
-                                              "type": "string",
-                                              "description": "Guard object ID"
-                                            },
-                                            "retained_submission": {
-                                              "anyOf": [
-                                                {
-                                                  "type": "array",
-                                                  "items": {
-                                                    "$ref": "#/definitions/onchain_table_data/properties/result/anyOf/8/properties/result/anyOf/0/properties/value/items/properties/threshold"
-                                                  }
+                                          "anyOf": [
+                                            {
+                                              "type": "object",
+                                              "properties": {
+                                                "guard": {
+                                                  "type": "string",
+                                                  "description": "Guard object name or address (string). Example: 'my_attendance_guard' or '0x1234...'"
                                                 },
-                                                {
-                                                  "type": "null"
+                                                "retained_submission": {
+                                                  "anyOf": [
+                                                    {
+                                                      "type": "array",
+                                                      "items": {
+                                                        "$ref": "#/definitions/onchain_table_data/properties/result/anyOf/8/properties/result/anyOf/0/properties/value/items/properties/threshold"
+                                                      }
+                                                    },
+                                                    {
+                                                      "type": "null"
+                                                    }
+                                                  ],
+                                                  "description": "Data submitted by user during Guard object verification"
                                                 }
+                                              },
+                                              "required": [
+                                                "guard"
                                               ],
-                                              "description": "Data submitted by user during Guard object verification"
+                                              "additionalProperties": false,
+                                              "description": "OBJECT form: {guard: '<guard_name_or_address>', retained_submission?: number[]}. Use this form when you need to pass retained_submission data alongside the Guard reference."
+                                            },
+                                            {
+                                              "type": "string",
+                                              "description": "STRING form (shorthand): the Guard object's name or address as a plain string. Auto-wrapped to {guard: <string>} at runtime. Use this when you only need to reference a Guard without retained_submission."
                                             }
-                                          },
-                                          "required": [
-                                            "guard"
-                                          ],
-                                          "additionalProperties": false,
-                                          "description": "Record of Guard object in MachineForwardGuard object"
+                                          ]
                                         },
                                         {
                                           "type": "null"
                                         }
                                       ],
-                                      "description": "Guard object ID, if defined, Guard verification must also pass to complete Forward (e.g., completed promised supply chain sub-order)."
+                                      "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes)."
                                     }
                                   },
                                   "required": [
@@ -1683,7 +1691,7 @@
                                   "additionalProperties": false,
                                   "description": "Forward in Machine object"
                                 },
-                                "description": "Forward list"
+                                "description": "Forward list — operations to ENTER THIS NODE from prev_node. SEMANTIC CLARIFICATION: forwards describe INCOMING transitions (how to ARRIVE at this node), NOT outgoing transitions. Think of each forward as an 'entry door' to this node. Example: pair {prev_node:'A', forwards:[{name:'Go'}]} means 'use Go to advance FROM A TO THIS NODE'. For initial node (prev_node=''), forwards are operations to enter this node from the start state. DIAGRAM: A --[Go]--> B means the pair belongs to node B (destination), with prev_node='A'. WARNING: forwards belong to the DESTINATION node's pair, NOT the source node. Placing a forward on the wrong pair will cause Progress to get stuck."
                               }
                             },
                             "required": [