@wowok/agent-mcp 3.2.0 → 3.2.2

package/dist/schemas/onchain_operations.schema.json

@@ -83,7 +83,7 @@
                     },
                     "type_parameter": {
                       "default": "0x2::wow::WOW",
-                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                       "type": "string"
                     }
                   },
@@ -250,7 +250,7 @@
                   "additionalProperties": false
                 },
                 "namedNewOrder": {
-                  "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. PLACEMENT: this field MUST be inside data.order_new (it is an OrderNew field) — putting namedNewOrder at the data root fails schema validation with 'Unrecognized key'. MIGRATION TIP: for batch/migration order creation, always auto-generate readable names (e.g. '<source>_<service>_<seq>' like 'upwork_svc_v1_0001') — unnamed orders (head.name = null) are only address-referenceable, which breaks downstream queries, displays and audits (E-8).",
+                  "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. PLACEMENT: this field MUST be inside data.order_new (it is an OrderNew field) — putting namedNewOrder at the data root fails schema validation with 'Unrecognized key'. MIGRATION TIP: for batch/migration order creation, always auto-generate readable names (e.g. '<source>_<service>_<seq>' like 'my_shop_svc_v1_0001') — unnamed orders (head.name = null) are only address-referenceable, which breaks downstream queries, displays and audits (E-8).",
                   "type": "object",
                   "properties": {
                     "name": {
@@ -668,7 +668,7 @@
                     "suspension"
                   ],
                   "additionalProperties": false,
-                  "description": "Suspend or resume ONE product without removing it (keeps price/stock/WIP binding). The Amazon-style 'out of stock / listing inactive' state. Only the named product is touched; an unknown sale_name is silently ignored on-chain (verify with query_toolkit afterwards)."
+                  "description": "Suspend or resume ONE product without removing it (keeps price/stock/WIP binding). The retail-style 'out of stock / listing inactive' state. Only the named product is touched; an unknown sale_name is silently ignored on-chain (verify with query_toolkit afterwards)."
                 }
               ]
             },
@@ -925,7 +925,7 @@
                   "description": "Discount magnitude, meaning depends on discount_type. RATES (0): per-10000 off rate — 10 = 0.1% off, 1000 = 10% off, 10000 = 100% off; values above 10000 are rejected. FIXED (1): fixed deduction from the order total in the Service token's smallest units (e.g. 1000000000 = 1 WOW at 9 decimals)."
                 },
                 "benchmark": {
-                  "description": "Minimum order total (in the Service token's smallest units) for the discount to apply — the discount is applied only when the order total is GREATER THAN OR EQUAL TO this value. ⚠️ OMITTING this field means the discount NEVER applies: the coupon object is still consumed (destroyed) when used, but the order total is unchanged. To make a discount that always applies, pass 0. If the order total is below the discounted price the payment aborts — pay the list price; the excess is returned as a new Coin.",
+                  "description": "Minimum order total (in the Service token's smallest units) for the discount to apply — when set, the discount is applied only if the PRE-discount order total is GREATER THAN OR EQUAL TO this value. ✅ OMITTING this field (or passing null, or 0) means NO threshold — the discount applies UNCONDITIONALLY, and that is the common, correct case. This is the on-chain behaviour: benchmark_met = if (option::is_some(&discount.benchmark)) { total >= benchmark } else { true } (wow-framework sources/w/service.move:274-278, inside the discount-application step). ⚠️ SHARP EDGE when you DO set a threshold: a below-threshold order is NOT rejected — it completes at FULL price and the one-time coupon is still consumed and destroyed, so the buyer pays full price AND loses the coupon. Keep thresholds low enough that your typical basket clears them. If the order total is below the discounted price the payment aborts — pay the list price; the excess is returned as a new Coin.",
                   "anyOf": [
                     {
                       "type": "number"
@@ -1014,7 +1014,7 @@
               }
             },
             "order_allocators": {
-              "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 (on-chain check rejects after publish — 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 the Guard table submission at allocation time. BINDING SEMANTICS (contract-enforced, abort code 15): in a Service-created Allocation EVERY GuardIdentifier submission must equal the PAYING order — it is always 'the order', never a third party whose address is supplied at trigger time; use {who:{Entity:...}} for named parties. Canonical order pattern: the recipient slot is the single submitted Order (constrained by the Guard — service binding, qualifying node, signer==order.owner); funds land at that order object and are receivable only by its owner (object receipt = owner receipt). Safety is determined by constraint sufficiency — run the recipient constraint audit before publish. Fixed recipients should use {who:{Entity:...}}; unbound Signer recipients are a CRITICAL theft risk. MULTI-CALL ALLOCATION: an allocation can be executed 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.",
+              "description": "Order fund allocator. Max 100 allocators (MAX_ALLOCATOR_COUNT). ✅ EACH allocator has a guard, and EVERY allocator whose guard address matches the supplied guard RUNS — they are NOT mutually exclusive and NOT first-match-wins. One guard may legitimately authorize several distribution rules (different fix / rate / cap); each contributes its own Payment and consumes its own once-slot (keyed by the allocator index). Allocators are evaluated in vector order against the SHRINKING pool, so a later allocator only sees the balance left by the earlier ones — which is exactly how a waterfall (e.g. Amount fee + net Rate split) is built. On-chain truth: wow::allocation (allocation.move:366-368, `while` loop over all allocators, `if (guard address == alloc.guard)`). ⚠️ If you WANT mutual exclusion you must express it inside the Guard itself (make the conditions logically exclusive). Set to null to clear. ⚠️ PERMANENTLY IMMUTABLE after publish: order_allocators can ONLY be set BEFORE publish=true (on-chain check rejects after publish — 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 the Guard table submission at allocation time. BINDING SEMANTICS (contract-enforced, abort code 15): in a Service-created Allocation EVERY GuardIdentifier submission must equal the PAYING order — it is always 'the order', never a third party whose address is supplied at trigger time; use {who:{Entity:...}} for named parties. Canonical order pattern: the recipient slot is the single submitted Order (constrained by the Guard — service binding, qualifying node, signer==order.owner); funds land at that order object and are receivable only by its owner (object receipt = owner receipt). Safety is determined by constraint sufficiency — run the recipient constraint audit before publish. Fixed recipients should use {who:{Entity:...}}; unbound Signer recipients are a CRITICAL theft risk. MULTI-CALL ALLOCATION: an allocation can be executed 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.",
               "anyOf": [
                 {
                   "type": "object",
@@ -3256,7 +3256,7 @@
                   "properties": {
                     "json_or_markdown_file": {
                       "type": "string",
-                      "description": "Path to a JSON or Markdown file containing node array for COMPLETE REPLACEMENT of all nodes.\n\n**File Format Requirements:**\n- Must contain a JSON ARRAY of node objects: [{\"name\": \"...\", \"pairs\": [...]}, {...}]\n- NOT an operation object with \"op\" field (use NodeSchema for operations)\n- Supports JSON or Markdown (with ```json code blocks)\n\n**Node Structure:**\nEach node is a directed graph element representing workflow states and transitions:\n- name: Node identifier\n- role: (optional) business role tag for display layers — one of draft/active/delivered/final/cancelled. SESSION METADATA ONLY (not stored on-chain; echoed back as a NODE ROLES warning)\n- pairs: Array of {prior_node, forwards, threshold} defining connections\n- forwards: Operations available from this node\n- threshold: Required weight to advance\n\n**Behavior:**\n- COMPLETELY REPLACES all existing nodes (equivalent to \"set\" with bReplace=true)\n- Auto-detects format based on file content\n- If parsing fails, error includes line number and column information"
+                      "description": "Path to a JSON or Markdown file containing node array for COMPLETE REPLACEMENT of all nodes.\n\n**File Format Requirements:**\n- Must contain a JSON ARRAY of node objects: [{\"name\": \"...\", \"pairs\": [...]}, {...}]\n- NOT an operation object with \"op\" field (use NodeSchema for operations)\n- Supports JSON or Markdown (with ```json code blocks)\n\n**Node Structure:**\nEach node is a directed graph element representing a workflow STATE that an order\ncan rest in. Its Pairs are the INCOMING edges — this is the one convention the\nchain enforces, and getting it backwards silently builds a wrong graph:\n- name: Node identifier — the DESTINATION of every pair it owns\n- role: (optional) business role tag for display layers — one of draft/active/delivered/final/cancelled. SESSION METADATA ONLY (not stored on-chain; echoed back as a NODE ROLES warning)\n- pairs: Array of {prev_node, forwards, threshold} — edges ENTERING this node. The key is `prev_node`; `prior_node` is not recognized and is silently dropped.\n- forwards: Operations that advance INTO this node FROM its prev_node (NOT operations available from this node)\n- threshold: Weight required to migrate into this node along that pair\n\nDiagram `A --[Go]--> B` therefore lives in node **B**: {name:\"B\", pairs:[{prev_node:\"A\", forwards:[{name:\"Go\", weight:1}]}]}.\n\n**Forward names must determine the destination.** `next_node` is a CALLER argument\n(progress.move:540) and the chain resolves (current, next_node, forward) inside the\ndestination node (machine.move:275), so one forward name shared by two destinations\nfrom the same prev_node is legal and lets the caller pick the outcome — including\nwhether a refund Allocator ever fires. Give each destination its own forward name.\n\n**Behavior:**\n- COMPLETELY REPLACES all existing nodes (equivalent to \"set\" with bReplace=true)\n- Auto-detects format based on file content\n- If parsing fails, error includes line number and column information"
                     }
                   },
                   "required": [
@@ -3271,7 +3271,7 @@
               "type": "boolean"
             },
             "publish": {
-              "description": "Whether to publish the object. After the object is published, new Progress objects can be generated; and node settings will no longer be changeable. ⚠️ Before publishing, enumerate the graph STOP NODES (nodes with no outgoing Pair) plus every waiting state (review window, handover, open dispute) and verify each has a defined fund exit in the Service order_allocators — withdrawal (release) AND refund. Machine + Allocator are immutable after publish (IMMUT-001); an uncovered stop node strands funds permanently (rule R-M5-03, checklist pattern.fund_flow_stop_node_coverage).",
+              "description": "Whether to publish the object. After the object is published, new Progress objects can be generated; and node settings will no longer be changeable. ⚠️ PUBLISH IS A ONE-WAY DOOR AND THE CHAIN VALIDATES THE WHOLE GRAPH AT THAT MOMENT: machine::assert_publishable rejects a Machine that is empty, has no entry edge (no pair with prev_node:\"\"), has an entry pair with no forward, references a prev_node that is not a node of this Machine, carries a forward with neither namedOperator nor permissionIndex (a guard is NOT an identity), or has a pair whose threshold exceeds the sum of its forward weights (each forward counts at most once). These aborts (machine:17-22) fire BEFORE the publish lands, so the graph is still editable — but after it succeeds, nodes/forwards, Guard bindings and Service.machine are frozen forever, and a broken graph would only surface at the first transition with no repair path. Send the nodes in the SAME call as publish:true (bReplace:true or op:\"set\") so the complete graph is validated together. ⚠️ Before publishing, enumerate the graph STOP NODES (nodes with no outgoing Pair) plus every waiting state (review window, handover, open dispute) and verify each has a defined fund exit in the Service order_allocators — withdrawal (release) AND refund. Machine + Allocator are immutable after publish (IMMUT-001); an uncovered stop node strands funds permanently (rule R-M5-03, checklist pattern.fund_flow_stop_node_coverage).",
               "type": "boolean"
             },
             "owner_receive": {
@@ -6632,7 +6632,7 @@
                     },
                     "type_parameter": {
                       "default": "0x2::wow::WOW",
-                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                       "type": "string"
                     }
                   },
@@ -6769,8 +6769,8 @@
                   "description": "Arb CASE object — the single dispute case created by `dispute` (the object you may have named via `namedArb`). NOT the arbitrator registration object: that one goes in the ROOT `object` field, while every case-scoped operation (confirm / voting_deadline_change / vote / feedback / arbitration / reset / arb_withdraw) addresses the case through THIS field. Accepts the Arb's 0x address or its LocalMark name."
                 },
                 "voting_deadline": {
-                  "default": 0,
-                  "description": "Voting deadline as Unix timestamp in MILLISECONDS (ms). SEMANTICS OF SPECIAL VALUES: 0 (DEFAULT when omitted) = deadline already passed → voting is IMPOSSIBLE and the arbitrator may deliver the verdict immediately (direct-verdict flow); null = open-ended voting with no deadline (verdict allowed anytime); a future timestamp = normal voting window (recommended: now + at least 86400000 ms = 24 hours). COMMON MISTAKE: using seconds instead of milliseconds (multiply by 1000). Example: Date.now() + 259200000 for 3 days from now.",
+                  "default": null,
+                  "description": "Voting deadline as Unix timestamp in MILLISECONDS (ms). SEMANTICS OF SPECIAL VALUES: null (DEFAULT when omitted) = open-ended voting, no deadline; parties may vote at any time and the arbitrator may deliver the verdict immediately (arb.move skips the deadline assert when the Option is none) — this is the SAFE default; a future timestamp = normal bounded voting window (recommended: now + at least 86400000 ms = 24 hours); 0 = deadline already passed → voting is IMPOSSIBLE (every vote aborts E_VOTING_DEADLINE_PASSED) and only a direct verdict is possible. Only pass 0 deliberately when you truly want a no-vote verdict. COMMON MISTAKE: using seconds instead of milliseconds (multiply by 1000). Example: Date.now() + 259200000 for 3 days from now.",
                   "anyOf": [
                     {
                       "type": "integer",
@@ -8925,7 +8925,7 @@
                     },
                     "type_parameter": {
                       "default": "0x2::wow::WOW",
-                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                       "type": "string"
                     }
                   },
@@ -10430,7 +10430,7 @@
                     },
                     "type_parameter": {
                       "default": "0x2::wow::WOW",
-                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                       "type": "string"
                     }
                   },
@@ -11536,7 +11536,7 @@
                     },
                     "type_parameter": {
                       "default": "0x2::wow::WOW",
-                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                       "type": "string"
                     }
                   },
@@ -17983,7 +17983,7 @@
                     },
                     "type_parameter": {
                       "default": "0x2::wow::WOW",
-                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                      "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                       "type": "string"
                     }
                   },

package/dist/schemas/onchain_operations_allocation.schema.json

@@ -38,7 +38,7 @@
                 },
                 "type_parameter": {
                   "default": "0x2::wow::WOW",
-                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                   "type": "string"
                 }
               },

package/dist/schemas/onchain_operations_arbitration.schema.json

@@ -81,7 +81,7 @@
                 },
                 "type_parameter": {
                   "default": "0x2::wow::WOW",
-                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                   "type": "string"
                 }
               },
@@ -218,8 +218,8 @@
               "description": "Arb CASE object — the single dispute case created by `dispute` (the object you may have named via `namedArb`). NOT the arbitrator registration object: that one goes in the ROOT `object` field, while every case-scoped operation (confirm / voting_deadline_change / vote / feedback / arbitration / reset / arb_withdraw) addresses the case through THIS field. Accepts the Arb's 0x address or its LocalMark name."
             },
             "voting_deadline": {
-              "default": 0,
-              "description": "Voting deadline as Unix timestamp in MILLISECONDS (ms). SEMANTICS OF SPECIAL VALUES: 0 (DEFAULT when omitted) = deadline already passed → voting is IMPOSSIBLE and the arbitrator may deliver the verdict immediately (direct-verdict flow); null = open-ended voting with no deadline (verdict allowed anytime); a future timestamp = normal voting window (recommended: now + at least 86400000 ms = 24 hours). COMMON MISTAKE: using seconds instead of milliseconds (multiply by 1000). Example: Date.now() + 259200000 for 3 days from now.",
+              "default": null,
+              "description": "Voting deadline as Unix timestamp in MILLISECONDS (ms). SEMANTICS OF SPECIAL VALUES: null (DEFAULT when omitted) = open-ended voting, no deadline; parties may vote at any time and the arbitrator may deliver the verdict immediately (arb.move skips the deadline assert when the Option is none) — this is the SAFE default; a future timestamp = normal bounded voting window (recommended: now + at least 86400000 ms = 24 hours); 0 = deadline already passed → voting is IMPOSSIBLE (every vote aborts E_VOTING_DEADLINE_PASSED) and only a direct verdict is possible. Only pass 0 deliberately when you truly want a no-vote verdict. COMMON MISTAKE: using seconds instead of milliseconds (multiply by 1000). Example: Date.now() + 259200000 for 3 days from now.",
               "anyOf": [
                 {
                   "type": "integer",

package/dist/schemas/onchain_operations_machine.schema.json

@@ -1053,7 +1053,7 @@
               "properties": {
                 "json_or_markdown_file": {
                   "type": "string",
-                  "description": "Path to a JSON or Markdown file containing node array for COMPLETE REPLACEMENT of all nodes.\n\n**File Format Requirements:**\n- Must contain a JSON ARRAY of node objects: [{\"name\": \"...\", \"pairs\": [...]}, {...}]\n- NOT an operation object with \"op\" field (use NodeSchema for operations)\n- Supports JSON or Markdown (with ```json code blocks)\n\n**Node Structure:**\nEach node is a directed graph element representing workflow states and transitions:\n- name: Node identifier\n- role: (optional) business role tag for display layers — one of draft/active/delivered/final/cancelled. SESSION METADATA ONLY (not stored on-chain; echoed back as a NODE ROLES warning)\n- pairs: Array of {prior_node, forwards, threshold} defining connections\n- forwards: Operations available from this node\n- threshold: Required weight to advance\n\n**Behavior:**\n- COMPLETELY REPLACES all existing nodes (equivalent to \"set\" with bReplace=true)\n- Auto-detects format based on file content\n- If parsing fails, error includes line number and column information"
+                  "description": "Path to a JSON or Markdown file containing node array for COMPLETE REPLACEMENT of all nodes.\n\n**File Format Requirements:**\n- Must contain a JSON ARRAY of node objects: [{\"name\": \"...\", \"pairs\": [...]}, {...}]\n- NOT an operation object with \"op\" field (use NodeSchema for operations)\n- Supports JSON or Markdown (with ```json code blocks)\n\n**Node Structure:**\nEach node is a directed graph element representing a workflow STATE that an order\ncan rest in. Its Pairs are the INCOMING edges — this is the one convention the\nchain enforces, and getting it backwards silently builds a wrong graph:\n- name: Node identifier — the DESTINATION of every pair it owns\n- role: (optional) business role tag for display layers — one of draft/active/delivered/final/cancelled. SESSION METADATA ONLY (not stored on-chain; echoed back as a NODE ROLES warning)\n- pairs: Array of {prev_node, forwards, threshold} — edges ENTERING this node. The key is `prev_node`; `prior_node` is not recognized and is silently dropped.\n- forwards: Operations that advance INTO this node FROM its prev_node (NOT operations available from this node)\n- threshold: Weight required to migrate into this node along that pair\n\nDiagram `A --[Go]--> B` therefore lives in node **B**: {name:\"B\", pairs:[{prev_node:\"A\", forwards:[{name:\"Go\", weight:1}]}]}.\n\n**Forward names must determine the destination.** `next_node` is a CALLER argument\n(progress.move:540) and the chain resolves (current, next_node, forward) inside the\ndestination node (machine.move:275), so one forward name shared by two destinations\nfrom the same prev_node is legal and lets the caller pick the outcome — including\nwhether a refund Allocator ever fires. Give each destination its own forward name.\n\n**Behavior:**\n- COMPLETELY REPLACES all existing nodes (equivalent to \"set\" with bReplace=true)\n- Auto-detects format based on file content\n- If parsing fails, error includes line number and column information"
                 }
               },
               "required": [
@@ -1068,7 +1068,7 @@
           "type": "boolean"
         },
         "publish": {
-          "description": "Whether to publish the object. After the object is published, new Progress objects can be generated; and node settings will no longer be changeable. ⚠️ Before publishing, enumerate the graph STOP NODES (nodes with no outgoing Pair) plus every waiting state (review window, handover, open dispute) and verify each has a defined fund exit in the Service order_allocators — withdrawal (release) AND refund. Machine + Allocator are immutable after publish (IMMUT-001); an uncovered stop node strands funds permanently (rule R-M5-03, checklist pattern.fund_flow_stop_node_coverage).",
+          "description": "Whether to publish the object. After the object is published, new Progress objects can be generated; and node settings will no longer be changeable. ⚠️ PUBLISH IS A ONE-WAY DOOR AND THE CHAIN VALIDATES THE WHOLE GRAPH AT THAT MOMENT: machine::assert_publishable rejects a Machine that is empty, has no entry edge (no pair with prev_node:\"\"), has an entry pair with no forward, references a prev_node that is not a node of this Machine, carries a forward with neither namedOperator nor permissionIndex (a guard is NOT an identity), or has a pair whose threshold exceeds the sum of its forward weights (each forward counts at most once). These aborts (machine:17-22) fire BEFORE the publish lands, so the graph is still editable — but after it succeeds, nodes/forwards, Guard bindings and Service.machine are frozen forever, and a broken graph would only surface at the first transition with no repair path. Send the nodes in the SAME call as publish:true (bReplace:true or op:\"set\") so the complete graph is validated together. ⚠️ Before publishing, enumerate the graph STOP NODES (nodes with no outgoing Pair) plus every waiting state (review window, handover, open dispute) and verify each has a defined fund exit in the Service order_allocators — withdrawal (release) AND refund. Machine + Allocator are immutable after publish (IMMUT-001); an uncovered stop node strands funds permanently (rule R-M5-03, checklist pattern.fund_flow_stop_node_coverage).",
           "type": "boolean"
         },
         "owner_receive": {

package/dist/schemas/onchain_operations_payment.schema.json

@@ -38,7 +38,7 @@
                 },
                 "type_parameter": {
                   "default": "0x2::wow::WOW",
-                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                   "type": "string"
                 }
               },

package/dist/schemas/onchain_operations_reward.schema.json

@@ -81,7 +81,7 @@
                 },
                 "type_parameter": {
                   "default": "0x2::wow::WOW",
-                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                   "type": "string"
                 }
               },

package/dist/schemas/onchain_operations_service.schema.json

@@ -81,7 +81,7 @@
                 },
                 "type_parameter": {
                   "default": "0x2::wow::WOW",
-                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                   "type": "string"
                 }
               },
@@ -248,7 +248,7 @@
               "additionalProperties": false
             },
             "namedNewOrder": {
-              "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. PLACEMENT: this field MUST be inside data.order_new (it is an OrderNew field) — putting namedNewOrder at the data root fails schema validation with 'Unrecognized key'. MIGRATION TIP: for batch/migration order creation, always auto-generate readable names (e.g. '<source>_<service>_<seq>' like 'upwork_svc_v1_0001') — unnamed orders (head.name = null) are only address-referenceable, which breaks downstream queries, displays and audits (E-8).",
+              "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. PLACEMENT: this field MUST be inside data.order_new (it is an OrderNew field) — putting namedNewOrder at the data root fails schema validation with 'Unrecognized key'. MIGRATION TIP: for batch/migration order creation, always auto-generate readable names (e.g. '<source>_<service>_<seq>' like 'my_shop_svc_v1_0001') — unnamed orders (head.name = null) are only address-referenceable, which breaks downstream queries, displays and audits (E-8).",
               "type": "object",
               "properties": {
                 "name": {
@@ -666,7 +666,7 @@
                 "suspension"
               ],
               "additionalProperties": false,
-              "description": "Suspend or resume ONE product without removing it (keeps price/stock/WIP binding). The Amazon-style 'out of stock / listing inactive' state. Only the named product is touched; an unknown sale_name is silently ignored on-chain (verify with query_toolkit afterwards)."
+              "description": "Suspend or resume ONE product without removing it (keeps price/stock/WIP binding). The retail-style 'out of stock / listing inactive' state. Only the named product is touched; an unknown sale_name is silently ignored on-chain (verify with query_toolkit afterwards)."
             }
           ]
         },
@@ -923,7 +923,7 @@
               "description": "Discount magnitude, meaning depends on discount_type. RATES (0): per-10000 off rate — 10 = 0.1% off, 1000 = 10% off, 10000 = 100% off; values above 10000 are rejected. FIXED (1): fixed deduction from the order total in the Service token's smallest units (e.g. 1000000000 = 1 WOW at 9 decimals)."
             },
             "benchmark": {
-              "description": "Minimum order total (in the Service token's smallest units) for the discount to apply — the discount is applied only when the order total is GREATER THAN OR EQUAL TO this value. ⚠️ OMITTING this field means the discount NEVER applies: the coupon object is still consumed (destroyed) when used, but the order total is unchanged. To make a discount that always applies, pass 0. If the order total is below the discounted price the payment aborts — pay the list price; the excess is returned as a new Coin.",
+              "description": "Minimum order total (in the Service token's smallest units) for the discount to apply — when set, the discount is applied only if the PRE-discount order total is GREATER THAN OR EQUAL TO this value. ✅ OMITTING this field (or passing null, or 0) means NO threshold — the discount applies UNCONDITIONALLY, and that is the common, correct case. This is the on-chain behaviour: benchmark_met = if (option::is_some(&discount.benchmark)) { total >= benchmark } else { true } (wow-framework sources/w/service.move:274-278, inside the discount-application step). ⚠️ SHARP EDGE when you DO set a threshold: a below-threshold order is NOT rejected — it completes at FULL price and the one-time coupon is still consumed and destroyed, so the buyer pays full price AND loses the coupon. Keep thresholds low enough that your typical basket clears them. If the order total is below the discounted price the payment aborts — pay the list price; the excess is returned as a new Coin.",
               "anyOf": [
                 {
                   "type": "number"
@@ -1012,7 +1012,7 @@
           }
         },
         "order_allocators": {
-          "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 (on-chain check rejects after publish — 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 the Guard table submission at allocation time. BINDING SEMANTICS (contract-enforced, abort code 15): in a Service-created Allocation EVERY GuardIdentifier submission must equal the PAYING order — it is always 'the order', never a third party whose address is supplied at trigger time; use {who:{Entity:...}} for named parties. Canonical order pattern: the recipient slot is the single submitted Order (constrained by the Guard — service binding, qualifying node, signer==order.owner); funds land at that order object and are receivable only by its owner (object receipt = owner receipt). Safety is determined by constraint sufficiency — run the recipient constraint audit before publish. Fixed recipients should use {who:{Entity:...}}; unbound Signer recipients are a CRITICAL theft risk. MULTI-CALL ALLOCATION: an allocation can be executed 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.",
+          "description": "Order fund allocator. Max 100 allocators (MAX_ALLOCATOR_COUNT). ✅ EACH allocator has a guard, and EVERY allocator whose guard address matches the supplied guard RUNS — they are NOT mutually exclusive and NOT first-match-wins. One guard may legitimately authorize several distribution rules (different fix / rate / cap); each contributes its own Payment and consumes its own once-slot (keyed by the allocator index). Allocators are evaluated in vector order against the SHRINKING pool, so a later allocator only sees the balance left by the earlier ones — which is exactly how a waterfall (e.g. Amount fee + net Rate split) is built. On-chain truth: wow::allocation (allocation.move:366-368, `while` loop over all allocators, `if (guard address == alloc.guard)`). ⚠️ If you WANT mutual exclusion you must express it inside the Guard itself (make the conditions logically exclusive). Set to null to clear. ⚠️ PERMANENTLY IMMUTABLE after publish: order_allocators can ONLY be set BEFORE publish=true (on-chain check rejects after publish — 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 the Guard table submission at allocation time. BINDING SEMANTICS (contract-enforced, abort code 15): in a Service-created Allocation EVERY GuardIdentifier submission must equal the PAYING order — it is always 'the order', never a third party whose address is supplied at trigger time; use {who:{Entity:...}} for named parties. Canonical order pattern: the recipient slot is the single submitted Order (constrained by the Guard — service binding, qualifying node, signer==order.owner); funds land at that order object and are receivable only by its owner (object receipt = owner receipt). Safety is determined by constraint sufficiency — run the recipient constraint audit before publish. Fixed recipients should use {who:{Entity:...}}; unbound Signer recipients are a CRITICAL theft risk. MULTI-CALL ALLOCATION: an allocation can be executed 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.",
           "anyOf": [
             {
               "type": "object",

package/dist/schemas/onchain_operations_treasury.schema.json

@@ -81,7 +81,7 @@
                 },
                 "type_parameter": {
                   "default": "0x2::wow::WOW",
-                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. '0x2::wow::WOW' (WOW, the default), '0x...::usdt::USDT' (USDT), '0x...::eth::ETH' (ETH). Defines which token this object accepts for payments. To discover all available tokens and their type tags, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here.",
+                  "description": "Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.",
                   "type": "string"
                 }
               },

package/dist/schemas/onchain_table_data.output.json

@@ -9098,6 +9098,17 @@
                 "additionalProperties": false
               }
             },
+            "discount": {
+              "description": "C-10: Discount (coupon) object address or LocalMark name to price the basket WITH. Without it the quote is always the UNDISCOUNTED total, so a discounted buyer cannot compute the exact total_pay that order_new requires (it must equal the order total precisely — any drift aborts with E_COIN_NOT_ENOUGH). RATES subtracts total*off/10000; MINUS/FIXED subtracts min(total, off), mirroring the on-chain rule with integer floor division. Read-only: quoting does NOT consume the coupon.",
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
             "context_network": {
               "type": "string",
               "enum": [
@@ -9157,6 +9168,10 @@
               "description": "DEPRECATED alias of object_address (accepted for call compatibility; must be a plain address or LocalMark NAME string, not an object). Prefer object_address. Example: {\"query_type\": \"object_panorama\", \"object_address\": \"0xabc...\"}.",
               "type": "string"
             },
+            "wts_file_path": {
+              "description": "Proof objects only: local path to the .wts evidence packet to cross-check against this anchor. Returns wts_anchor_check — whether the packet's message roots match the frozen root, whether the server key matches, and whether the Proof predates the packet (a frozen Proof is what makes WTS content non-re-fabricable after the fact).",
+              "type": "string"
+            },
             "context_network": {
               "type": "string",
               "enum": [
@@ -9171,7 +9186,7 @@
             "query_type"
           ],
           "additionalProperties": false,
-          "description": "ONE-CALL detail-page panorama for Progress / Demand / Order / Arb / Repository objects (client panorama family): discriminated `object_type` + head (name/tags/description) + the object's own typed fields + type-specific extras (Demand presenters from the GLOBAL tx table, Progress session/forwards, Arb votes & propositions, Repository policies). Read-only."
+          "description": "ONE-CALL detail-page panorama for Progress / Demand / Order / Arb / Repository / Proof objects (client panorama family): discriminated `object_type` + head (name/tags/description) + the object's own typed fields + type-specific extras (Demand presenters from the GLOBAL tx table, Progress session/forwards, Arb votes & propositions, Repository policies, Proof anchored root + WTS cross-check). Read-only."
         },
         {
           "type": "object",