@wowok/agent-mcp 2.6.1 → 2.6.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (125) hide show
  1. package/dist/customer/info-puzzle.d.ts +1 -1
  2. package/dist/customer/info-puzzle.js +4 -2
  3. package/dist/customer/risk-assessment.js +26 -4
  4. package/dist/customer/types.d.ts +2 -0
  5. package/dist/examples/guard-template-balance-check.json +38 -0
  6. package/dist/examples/guard-template-time-lock.json +39 -0
  7. package/dist/examples/machine-template-7node-rental.json +114 -0
  8. package/dist/examples/rental-ziroom-machine-create.json +137 -0
  9. package/dist/examples/rental-ziroom-permission-create.json +35 -0
  10. package/dist/examples/rental-ziroom-service-create.json +80 -0
  11. package/dist/examples/retail-myshop-service-create.json +88 -0
  12. package/dist/extensions/capability-manifest.js +24 -24
  13. package/dist/extensions/constraint-registry.js +18 -18
  14. package/dist/extensions/metric-registry.js +14 -14
  15. package/dist/extensions/mode-evaluator.js +16 -16
  16. package/dist/extensions/modes.js +131 -45
  17. package/dist/extensions/registry.d.ts +2 -0
  18. package/dist/extensions/registry.js +63 -30
  19. package/dist/extensions/types.d.ts +1 -0
  20. package/dist/index.js +50 -0
  21. package/dist/knowledge/deployment-scanner.js +1 -1
  22. package/dist/knowledge/fund-layer.d.ts +72 -0
  23. package/dist/knowledge/fund-layer.js +420 -0
  24. package/dist/knowledge/guard-render.d.ts +57 -0
  25. package/dist/knowledge/guard-render.js +700 -0
  26. package/dist/knowledge/guard-submission-prompt.d.ts +31 -0
  27. package/dist/knowledge/guard-submission-prompt.js +171 -0
  28. package/dist/knowledge/machine-ledger.js +1 -1
  29. package/dist/knowledge/machine-render.d.ts +41 -0
  30. package/dist/knowledge/machine-render.js +565 -0
  31. package/dist/knowledge/machine-templates.js +4 -4
  32. package/dist/knowledge/reward-confirm.js +2 -2
  33. package/dist/knowledge/reward-puzzle.js +1 -1
  34. package/dist/knowledge/reward-risk.js +9 -9
  35. package/dist/knowledge/reward-templates.js +2 -2
  36. package/dist/knowledge/service-confirm.d.ts +1 -1
  37. package/dist/knowledge/service-confirm.js +3 -3
  38. package/dist/knowledge/service-context.js +1 -1
  39. package/dist/knowledge/service-ledger.js +1 -1
  40. package/dist/knowledge/service-risk.d.ts +1 -1
  41. package/dist/knowledge/service-risk.js +3 -3
  42. package/dist/knowledge/service-templates.js +2 -2
  43. package/dist/knowledge/service-translation.d.ts +1 -1
  44. package/dist/knowledge/service-translation.js +7 -7
  45. package/dist/project/deployment-bridge.js +6 -5
  46. package/dist/project/deployment-doc.js +5 -5
  47. package/dist/project/edit-planner.d.ts +123 -0
  48. package/dist/project/edit-planner.js +1371 -0
  49. package/dist/project/evaluation.js +314 -14
  50. package/dist/project/graph-builder.js +6 -1
  51. package/dist/project/handlers.d.ts +99 -2
  52. package/dist/project/handlers.js +358 -16
  53. package/dist/project/stage-gate.js +4 -4
  54. package/dist/schema/call/allocation.js +2 -2
  55. package/dist/schema/call/arbitration.js +19 -6
  56. package/dist/schema/call/contact.js +2 -2
  57. package/dist/schema/call/demand.js +2 -2
  58. package/dist/schema/call/guard.js +1 -1
  59. package/dist/schema/call/machine.d.ts +1975 -777
  60. package/dist/schema/call/machine.js +50 -4
  61. package/dist/schema/call/order.js +3 -6
  62. package/dist/schema/call/permission.js +2 -2
  63. package/dist/schema/call/repository.js +2 -2
  64. package/dist/schema/call/reward.js +3 -3
  65. package/dist/schema/call/semantic.js +7 -1
  66. package/dist/schema/call/service.d.ts +180 -8
  67. package/dist/schema/call/service.js +82 -27
  68. package/dist/schema/call/treasury.js +3 -3
  69. package/dist/schema/common/index.d.ts +2 -0
  70. package/dist/schema/common/index.js +46 -10
  71. package/dist/schema/local/index.js +5 -1
  72. package/dist/schema/operations.d.ts +755 -176
  73. package/dist/schema/operations.js +43 -7
  74. package/dist/schema/project/index.d.ts +969 -6
  75. package/dist/schema/project/index.js +268 -4
  76. package/dist/schema/query/index.d.ts +217 -0
  77. package/dist/schema/query/index.js +63 -33
  78. package/dist/schema/schema-query/index.d.ts +53 -3
  79. package/dist/schema/schema-query/index.js +17 -2
  80. package/dist/schema/utils/node-parser.js +13 -0
  81. package/dist/schema/utils/object-type-utils.d.ts +12 -0
  82. package/dist/schema/utils/object-type-utils.js +35 -0
  83. package/dist/schema/utils/permission-machine-check.d.ts +49 -0
  84. package/dist/schema/utils/permission-machine-check.js +121 -0
  85. package/dist/schema/utils/skills-recommendation.d.ts +2 -0
  86. package/dist/schema/utils/skills-recommendation.js +76 -0
  87. package/dist/schema-query/index.d.ts +14 -1
  88. package/dist/schema-query/index.js +104 -2
  89. package/dist/schemas/account_operation.schema.json +1 -1
  90. package/dist/schemas/index.json +1 -1
  91. package/dist/schemas/onchain_events.output.json +1 -1
  92. package/dist/schemas/onchain_operations.output.json +2820 -0
  93. package/dist/schemas/onchain_operations.schema.json +115 -53
  94. package/dist/schemas/onchain_operations_allocation.schema.json +5 -5
  95. package/dist/schemas/onchain_operations_arbitration.schema.json +9 -7
  96. package/dist/schemas/onchain_operations_contact.schema.json +3 -3
  97. package/dist/schemas/onchain_operations_demand.schema.json +3 -3
  98. package/dist/schemas/onchain_operations_gen_passport.schema.json +2 -2
  99. package/dist/schemas/onchain_operations_guard.schema.json +1 -1
  100. package/dist/schemas/onchain_operations_machine.schema.json +4 -4
  101. package/dist/schemas/onchain_operations_order.schema.json +3 -3
  102. package/dist/schemas/onchain_operations_payment.schema.json +1 -1
  103. package/dist/schemas/onchain_operations_permission.schema.json +2 -2
  104. package/dist/schemas/onchain_operations_progress.schema.json +1 -1
  105. package/dist/schemas/onchain_operations_proof.schema.json +1 -1
  106. package/dist/schemas/onchain_operations_repository.schema.json +3 -3
  107. package/dist/schemas/onchain_operations_reward.schema.json +6 -6
  108. package/dist/schemas/onchain_operations_service.schema.json +77 -17
  109. package/dist/schemas/onchain_operations_treasury.schema.json +4 -4
  110. package/dist/schemas/onchain_table_data.output.json +1 -1
  111. package/dist/schemas/onchain_table_data.schema.json +10 -9
  112. package/dist/schemas/project_operation.output.json +1026 -7
  113. package/dist/schemas/project_operation.schema.json +46 -4
  114. package/dist/schemas/query_toolkit.output.json +15 -15
  115. package/dist/schemas/query_toolkit.schema.json +3 -3
  116. package/dist/schemas/schema_query.output.json +64 -1
  117. package/dist/schemas/schema_query.schema.json +3 -2
  118. package/dist/schemas/wowok_buildin_info.output.json +81 -8
  119. package/dist/schemas/wowok_buildin_info.schema.json +46 -2
  120. package/dist/tools/handlers/onchain.js +571 -6
  121. package/dist/tools/handlers/project.js +25 -2
  122. package/dist/tools/handlers/schema-query.js +24 -1
  123. package/dist/tools/index.d.ts +8 -0
  124. package/dist/tools/index.js +177 -6
  125. package/package.json +2 -2
@@ -146,10 +146,10 @@
146
146
  "Signer"
147
147
  ],
148
148
  "additionalProperties": false,
149
- "description": "Current transaction signer ID"
149
+ "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."
150
150
  }
151
151
  ],
152
- "description": "Recipient of this allocation. Three forms:\n• { GuardIdentifier: u8 } — resolved from Passport at allocation time. 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.\n• { Entity: { name_or_address: '...' } } — static address resolved via LocalMark. Use for known recipients (e.g., 'turo_host', or a Treasury object address).\n• 'Signer' — the transaction sender (tx_context::sender). Use when the recipient is the current signer (e.g., self-refund scenarios)."
152
+ "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)."
153
153
  },
154
154
  "sharing": {
155
155
  "type": [
@@ -200,7 +200,7 @@
200
200
  "type": "null"
201
201
  }
202
202
  ],
203
- "description": "Maximum allocation cap (optional). Has THREE effects:\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)."
203
+ "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."
204
204
  }
205
205
  },
206
206
  "required": [
@@ -357,7 +357,7 @@
357
357
  "const": "recently"
358
358
  }
359
359
  ],
360
- "description": "Unwrap the CoinWrapper objects received by the Allocation object and deposit them into the pending allocation balance"
360
+ "description": "Unwrap the CoinWrapper objects received by the Allocation object and deposit them into the pending allocation 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."
361
361
  },
362
362
  "alloc_by_guard": {
363
363
  "$ref": "#/definitions/data/anyOf/0/properties/allocators/properties/allocators/items/properties/sharing/items/properties/who/anyOf/1/properties/Entity/properties/name_or_address",
@@ -489,7 +489,7 @@
489
489
  },
490
490
  "b_submission": {
491
491
  "type": "boolean",
492
- "description": "Whether user submission is required for this data"
492
+ "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."
493
493
  },
494
494
  "value_type": {
495
495
  "anyOf": [
@@ -129,7 +129,7 @@
129
129
  "number",
130
130
  "string"
131
131
  ],
132
- "description": "A coin/balance amount in the smallest on-chain unit (u64). Accepts a JS number OR a numeric string. PRECISION RULE: for values exceeding 2^53 (e.g. token amounts with 18 decimals), ALWAYS pass a numeric STRING (e.g. \"1000000000000000000\") to preserve precision — JS numbers lose precision above 2^53. UNIT: this is the smallest unit, NOT the display unit. For SUI: 1 SUI = 10^9 MIST, so 10 SUI = 10000000000. For custom tokens: use the token's native smallest unit (decimals from coin metadata). Examples: 10000000000 (10 SUI), \"1000000000000000000\" (1 token with 18 decimals), 500 (500 units of a token with 0 decimals). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
132
+ "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."
133
133
  }
134
134
  },
135
135
  "required": [
@@ -152,7 +152,7 @@
152
152
  "additionalProperties": false
153
153
  }
154
154
  ],
155
- "description": "Dispute processing fee."
155
+ "description": "Dispute processing fee. FORMAT: {balance: <amount_in_smallest_unit>} — field name is 'balance' (NOT 'amount'). The token type and precision are determined by the Arbitration object's type_parameter (the generic type set when the Arbitration was created). For WOW (9 decimals): {balance: 50000000} = 0.05 WOW. For SUI (9 decimals): {balance: 50000000} = 0.05 SUI. For tokens with different decimals, adjust accordingly (e.g. USDC has 6 decimals, so {balance: 50000} = 0.05 USDC)."
156
156
  },
157
157
  "namedArb": {
158
158
  "type": "object",
@@ -171,7 +171,7 @@
171
171
  }
172
172
  },
173
173
  "additionalProperties": false,
174
- "description": "Name for the newly created arbitration object."
174
+ "description": "RECOMMENDED: Set a local name for the newly created Arb (arbitration case) object. Without this, the Arb is only referenceable by its on-chain address. Example: {name: 'my_dispute_v1'} allows subsequent vote/feedback operations to use 'my_dispute_v1'."
175
175
  }
176
176
  },
177
177
  "required": [
@@ -214,7 +214,8 @@
214
214
  {
215
215
  "type": "null"
216
216
  }
217
- ]
217
+ ],
218
+ "description": "Voting deadline as Unix timestamp in MILLISECONDS (ms). MUST be in the future (recommended: now + at least 86400000 ms = 24 hours). Set to null to remove the deadline. COMMON MISTAKE: using seconds instead of milliseconds (multiply by 1000). Example: Date.now() + 259200000 for 3 days from now."
218
219
  }
219
220
  },
220
221
  "required": [
@@ -234,7 +235,8 @@
234
235
  "type": [
235
236
  "number",
236
237
  "null"
237
- ]
238
+ ],
239
+ "description": "New voting deadline as Unix timestamp in MILLISECONDS (ms). MUST be in the future (recommended: now + at least 86400000 ms = 24 hours). Set to null to remove the deadline. COMMON MISTAKE: using seconds instead of milliseconds (multiply by 1000). Example: Date.now() + 259200000 for 3 days from now."
238
240
  }
239
241
  },
240
242
  "required": [
@@ -599,7 +601,7 @@
599
601
  "const": "recently"
600
602
  }
601
603
  ],
602
- "description": "Unwrap CoinWrapper objects and other objects received by this object and send them to the owner of its Permission object."
604
+ "description": "Unwrap CoinWrapper objects and other objects received by this Arbitration 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."
603
605
  },
604
606
  "um": {
605
607
  "anyOf": [
@@ -735,7 +737,7 @@
735
737
  },
736
738
  "b_submission": {
737
739
  "type": "boolean",
738
- "description": "Whether user submission is required for this data"
740
+ "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."
739
741
  },
740
742
  "value_type": {
741
743
  "anyOf": [
@@ -250,7 +250,7 @@
250
250
  "number",
251
251
  "string"
252
252
  ],
253
- "description": "A coin/balance amount in the smallest on-chain unit (u64). Accepts a JS number OR a numeric string. PRECISION RULE: for values exceeding 2^53 (e.g. token amounts with 18 decimals), ALWAYS pass a numeric STRING (e.g. \"1000000000000000000\") to preserve precision — JS numbers lose precision above 2^53. UNIT: this is the smallest unit, NOT the display unit. For SUI: 1 SUI = 10^9 MIST, so 10 SUI = 10000000000. For custom tokens: use the token's native smallest unit (decimals from coin metadata). Examples: 10000000000 (10 SUI), \"1000000000000000000\" (1 token with 18 decimals), 500 (500 units of a token with 0 decimals). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
253
+ "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."
254
254
  },
255
255
  "token_type": {
256
256
  "type": "string",
@@ -297,7 +297,7 @@
297
297
  "const": "recently"
298
298
  }
299
299
  ],
300
- "description": "Receive objects sent to this contact object and unwrap them to the permission owner"
300
+ "description": "Receive objects sent to this Contact object and unwrap them to the permission owner.\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."
301
301
  }
302
302
  },
303
303
  "required": [
@@ -422,7 +422,7 @@
422
422
  },
423
423
  "b_submission": {
424
424
  "type": "boolean",
425
- "description": "Whether user submission is required for this data"
425
+ "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."
426
426
  },
427
427
  "value_type": {
428
428
  "anyOf": [
@@ -370,7 +370,7 @@
370
370
  "number",
371
371
  "string"
372
372
  ],
373
- "description": "A coin/balance amount in the smallest on-chain unit (u64). Accepts a JS number OR a numeric string. PRECISION RULE: for values exceeding 2^53 (e.g. token amounts with 18 decimals), ALWAYS pass a numeric STRING (e.g. \"1000000000000000000\") to preserve precision — JS numbers lose precision above 2^53. UNIT: this is the smallest unit, NOT the display unit. For SUI: 1 SUI = 10^9 MIST, so 10 SUI = 10000000000. For custom tokens: use the token's native smallest unit (decimals from coin metadata). Examples: 10000000000 (10 SUI), \"1000000000000000000\" (1 token with 18 decimals), 500 (500 units of a token with 0 decimals). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
373
+ "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."
374
374
  },
375
375
  "token_type": {
376
376
  "type": "string",
@@ -417,7 +417,7 @@
417
417
  "const": "recently"
418
418
  }
419
419
  ],
420
- "description": "Unwrap CoinWrapper objects and other objects received by this object and send them to the owner of its Permission object."
420
+ "description": "Unwrap CoinWrapper objects and other objects received by this Demand 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."
421
421
  },
422
422
  "um": {
423
423
  "anyOf": [
@@ -553,7 +553,7 @@
553
553
  },
554
554
  "b_submission": {
555
555
  "type": "boolean",
556
- "description": "Whether user submission is required for this data"
556
+ "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."
557
557
  },
558
558
  "value_type": {
559
559
  "anyOf": [
@@ -76,7 +76,7 @@
76
76
  },
77
77
  "b_submission": {
78
78
  "type": "boolean",
79
- "description": "Whether user submission is required for this data"
79
+ "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."
80
80
  },
81
81
  "value_type": {
82
82
  "anyOf": [
@@ -675,7 +675,7 @@
675
675
  },
676
676
  "b_submission": {
677
677
  "type": "boolean",
678
- "description": "Whether user submission is required for this data"
678
+ "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."
679
679
  },
680
680
  "value_type": {
681
681
  "anyOf": [
@@ -10,7 +10,7 @@
10
10
  },
11
11
  "data": {
12
12
  "type": "object",
13
- "description": "On-chain Guard creation. IMPORTANT: All defined data (include all submitted data) must be defined in the 'table' field. USAGE: Set 'namedNew' field with {name, tags?, onChain?} to name the new Guard. The Guard is immutable once created. Define the validation logic in 'root' field. When root.type='file', the file can contain all Guard fields, and any fields defined in the schema will OVERRIDE the file content.",
13
+ "description": "On-chain Guard creation. IMPORTANT: All defined data (include all submitted data) must be defined in the 'table' field. USAGE: Set 'namedNew' field with {name, tags?, onChain?} to name the new Guard (you may also use 'object' as an alias for 'namedNew' — the MCP preprocess will convert it automatically). The Guard is immutable once created. Define the validation logic in 'root' field. When root.type='file', the file can contain all Guard fields, and any fields defined in the schema will OVERRIDE the file content.",
14
14
  "properties": {
15
15
  "namedNew": {
16
16
  "$ref": "#/definitions/guard_namedNew",
@@ -397,7 +397,7 @@
397
397
  "additionalProperties": false,
398
398
  "description": "Forward in Machine object"
399
399
  },
400
- "description": "Forward list — operations to ENTER THIS NODE from prev_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. 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."
400
+ "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."
401
401
  }
402
402
  },
403
403
  "required": [
@@ -746,7 +746,7 @@
746
746
  "number",
747
747
  "string"
748
748
  ],
749
- "description": "A coin/balance amount in the smallest on-chain unit (u64). Accepts a JS number OR a numeric string. PRECISION RULE: for values exceeding 2^53 (e.g. token amounts with 18 decimals), ALWAYS pass a numeric STRING (e.g. \"1000000000000000000\") to preserve precision — JS numbers lose precision above 2^53. UNIT: this is the smallest unit, NOT the display unit. For SUI: 1 SUI = 10^9 MIST, so 10 SUI = 10000000000. For custom tokens: use the token's native smallest unit (decimals from coin metadata). Examples: 10000000000 (10 SUI), \"1000000000000000000\" (1 token with 18 decimals), 500 (500 units of a token with 0 decimals). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
749
+ "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."
750
750
  },
751
751
  "token_type": {
752
752
  "type": "string",
@@ -793,7 +793,7 @@
793
793
  "const": "recently"
794
794
  }
795
795
  ],
796
- "description": "Unwrap CoinWrapper objects and other objects received by this object and send them to the owner of its Permission object."
796
+ "description": "Unwrap CoinWrapper objects and other objects received by this Machine 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."
797
797
  },
798
798
  "um": {
799
799
  "anyOf": [
@@ -929,7 +929,7 @@
929
929
  },
930
930
  "b_submission": {
931
931
  "type": "boolean",
932
- "description": "Whether user submission is required for this data"
932
+ "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."
933
933
  },
934
934
  "value_type": {
935
935
  "anyOf": [
@@ -220,7 +220,7 @@
220
220
  "number",
221
221
  "string"
222
222
  ],
223
- "description": "A coin/balance amount in the smallest on-chain unit (u64). Accepts a JS number OR a numeric string. PRECISION RULE: for values exceeding 2^53 (e.g. token amounts with 18 decimals), ALWAYS pass a numeric STRING (e.g. \"1000000000000000000\") to preserve precision — JS numbers lose precision above 2^53. UNIT: this is the smallest unit, NOT the display unit. For SUI: 1 SUI = 10^9 MIST, so 10 SUI = 10000000000. For custom tokens: use the token's native smallest unit (decimals from coin metadata). Examples: 10000000000 (10 SUI), \"1000000000000000000\" (1 token with 18 decimals), 500 (500 units of a token with 0 decimals). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
223
+ "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."
224
224
  },
225
225
  "token_type": {
226
226
  "type": "string",
@@ -267,7 +267,7 @@
267
267
  "const": "recently"
268
268
  }
269
269
  ],
270
- "description": "Unwrap CoinWrapper objects or other objects received by the order and transfer them to the order owner. ACCEPTED FORMATS (consistent with `owner_receive` on other objects — see arbitration/contact/demand/machine/permission/repository/reward/service/treasury):\n• 'recently' (string) — auto-query and receive all recently received objects\n• ReceivedNormal[] (array) — explicit list of received objects: [{id, type, content_raw?}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) — received balance record\nDO NOT wrap in {result: ...} — pass directly (NOT {result: [...]})"
270
+ "description": "Unwrap CoinWrapper objects or other objects received by the order and transfer them to the order owner. Consistent with `owner_receive` on other objects (arbitration/contact/demand/machine/permission/repository/reward/service/treasury).\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."
271
271
  },
272
272
  "transfer_to": {
273
273
  "$ref": "#/definitions/data/properties/agent/properties/entities/items",
@@ -396,7 +396,7 @@
396
396
  },
397
397
  "b_submission": {
398
398
  "type": "boolean",
399
- "description": "Whether user submission is required for this data"
399
+ "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."
400
400
  },
401
401
  "value_type": {
402
402
  "anyOf": [
@@ -88,7 +88,7 @@
88
88
  "number",
89
89
  "string"
90
90
  ],
91
- "description": "A coin/balance amount in the smallest on-chain unit (u64). Accepts a JS number OR a numeric string. PRECISION RULE: for values exceeding 2^53 (e.g. token amounts with 18 decimals), ALWAYS pass a numeric STRING (e.g. \"1000000000000000000\") to preserve precision — JS numbers lose precision above 2^53. UNIT: this is the smallest unit, NOT the display unit. For SUI: 1 SUI = 10^9 MIST, so 10 SUI = 10000000000. For custom tokens: use the token's native smallest unit (decimals from coin metadata). Examples: 10000000000 (10 SUI), \"1000000000000000000\" (1 token with 18 decimals), 500 (500 units of a token with 0 decimals). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
91
+ "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."
92
92
  }
93
93
  },
94
94
  "required": [
@@ -473,7 +473,7 @@
473
473
  "number",
474
474
  "string"
475
475
  ],
476
- "description": "A coin/balance amount in the smallest on-chain unit (u64). Accepts a JS number OR a numeric string. PRECISION RULE: for values exceeding 2^53 (e.g. token amounts with 18 decimals), ALWAYS pass a numeric STRING (e.g. \"1000000000000000000\") to preserve precision — JS numbers lose precision above 2^53. UNIT: this is the smallest unit, NOT the display unit. For SUI: 1 SUI = 10^9 MIST, so 10 SUI = 10000000000. For custom tokens: use the token's native smallest unit (decimals from coin metadata). Examples: 10000000000 (10 SUI), \"1000000000000000000\" (1 token with 18 decimals), 500 (500 units of a token with 0 decimals). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
476
+ "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."
477
477
  },
478
478
  "token_type": {
479
479
  "type": "string",
@@ -520,7 +520,7 @@
520
520
  "const": "recently"
521
521
  }
522
522
  ],
523
- "description": "Unwrap CoinWrapper objects and other objects received by this object and send them to the builder(owner)."
523
+ "description": "Unwrap CoinWrapper objects and other objects received by this Permission object and send them to the builder(owner).\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."
524
524
  },
525
525
  "um": {
526
526
  "anyOf": [
@@ -323,7 +323,7 @@
323
323
  },
324
324
  "b_submission": {
325
325
  "type": "boolean",
326
- "description": "Whether user submission is required for this data"
326
+ "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."
327
327
  },
328
328
  "value_type": {
329
329
  "anyOf": [
@@ -241,7 +241,7 @@
241
241
  },
242
242
  "b_submission": {
243
243
  "type": "boolean",
244
- "description": "Whether user submission is required for this data"
244
+ "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."
245
245
  },
246
246
  "value_type": {
247
247
  "anyOf": [
@@ -961,7 +961,7 @@
961
961
  "number",
962
962
  "string"
963
963
  ],
964
- "description": "A coin/balance amount in the smallest on-chain unit (u64). Accepts a JS number OR a numeric string. PRECISION RULE: for values exceeding 2^53 (e.g. token amounts with 18 decimals), ALWAYS pass a numeric STRING (e.g. \"1000000000000000000\") to preserve precision — JS numbers lose precision above 2^53. UNIT: this is the smallest unit, NOT the display unit. For SUI: 1 SUI = 10^9 MIST, so 10 SUI = 10000000000. For custom tokens: use the token's native smallest unit (decimals from coin metadata). Examples: 10000000000 (10 SUI), \"1000000000000000000\" (1 token with 18 decimals), 500 (500 units of a token with 0 decimals). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
964
+ "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."
965
965
  },
966
966
  "token_type": {
967
967
  "type": "string",
@@ -1008,7 +1008,7 @@
1008
1008
  "const": "recently"
1009
1009
  }
1010
1010
  ],
1011
- "description": "Unwrap CoinWrapper objects and other objects received by this object and send them to the owner of its Permission object."
1011
+ "description": "Unwrap CoinWrapper objects and other objects received by this Repository 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."
1012
1012
  },
1013
1013
  "um": {
1014
1014
  "anyOf": [
@@ -1144,7 +1144,7 @@
1144
1144
  },
1145
1145
  "b_submission": {
1146
1146
  "type": "boolean",
1147
- "description": "Whether user submission is required for this data"
1147
+ "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."
1148
1148
  },
1149
1149
  "value_type": {
1150
1150
  "anyOf": [
@@ -119,7 +119,7 @@
119
119
  "number",
120
120
  "string"
121
121
  ],
122
- "description": "A coin/balance amount in the smallest on-chain unit (u64). Accepts a JS number OR a numeric string. PRECISION RULE: for values exceeding 2^53 (e.g. token amounts with 18 decimals), ALWAYS pass a numeric STRING (e.g. \"1000000000000000000\") to preserve precision — JS numbers lose precision above 2^53. UNIT: this is the smallest unit, NOT the display unit. For SUI: 1 SUI = 10^9 MIST, so 10 SUI = 10000000000. For custom tokens: use the token's native smallest unit (decimals from coin metadata). Examples: 10000000000 (10 SUI), \"1000000000000000000\" (1 token with 18 decimals), 500 (500 units of a token with 0 decimals). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
122
+ "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."
123
123
  }
124
124
  },
125
125
  "required": [
@@ -197,7 +197,7 @@
197
197
  "const": "recently"
198
198
  }
199
199
  ],
200
- "description": "Unwrap CoinWrapper objects received by Reward object and store them in pending balance."
200
+ "description": "Unwrap CoinWrapper objects received by Reward object and store them in pending 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."
201
201
  },
202
202
  "guard_add": {
203
203
  "type": "array",
@@ -263,10 +263,10 @@
263
263
  "Signer"
264
264
  ],
265
265
  "additionalProperties": false,
266
- "description": "Current transaction signer ID"
266
+ "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."
267
267
  }
268
268
  ],
269
- "description": "Recipient ID. Three forms:\n - {GuardIdentifier: u8} — resolved from Passport at allocation time\n - {Entity: {name_or_address: 'mark_name'}} — static address via LocalMark (recommended)\n - {Signer: 'signer'} — transaction sender (e.g. self-refund)"
269
+ "description": "Recipient ID. Three forms:\n - {GuardIdentifier: u8} — DYNAMIC address resolved from Passport at alloc() time\n - {Entity: {name_or_address: 'mark_name'}} — FIXED static address via LocalMark (recommended)\n - {Signer: 'signer'} — transaction sender at alloc() time (e.g. self-refund; customer must call alloc_by_guard themselves)"
270
270
  },
271
271
  "amount": {
272
272
  "anyOf": [
@@ -388,7 +388,7 @@
388
388
  "const": "recently"
389
389
  }
390
390
  ],
391
- "description": "Unwrap CoinWrapper objects and other objects received by this object and send them to the owner of its Permission object."
391
+ "description": "Unwrap CoinWrapper objects and other objects received by this Reward 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."
392
392
  },
393
393
  "um": {
394
394
  "anyOf": [
@@ -524,7 +524,7 @@
524
524
  },
525
525
  "b_submission": {
526
526
  "type": "boolean",
527
- "description": "Whether user submission is required for this data"
527
+ "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."
528
528
  },
529
529
  "value_type": {
530
530
  "anyOf": [