@wowok/agent-mcp 3.2.7 → 3.2.9

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 (185) hide show
  1. package/dist/chain-semantics/field-capability.js +1 -1
  2. package/dist/chain-semantics/fund-flow.js +1 -1
  3. package/dist/chain-semantics/guard-verbs.js +1 -1
  4. package/dist/chain-semantics/object-graph.js +1 -1
  5. package/dist/composition/audit.js +1 -1
  6. package/dist/composition/compile.js +1 -1
  7. package/dist/composition/inflight.d.ts +10 -0
  8. package/dist/composition/inflight.js +1 -1
  9. package/dist/extensions/business-modules.d.ts +1 -1
  10. package/dist/extensions/business-modules.js +1 -1
  11. package/dist/graph/onchain/edge-schema.js +1 -1
  12. package/dist/harness/index.d.ts +1 -0
  13. package/dist/harness/index.js +1 -1
  14. package/dist/harness/operation-id.d.ts +1 -0
  15. package/dist/harness/operation-id.js +1 -0
  16. package/dist/harness/recover.js +1 -1
  17. package/dist/index.js +1 -1
  18. package/dist/knowledge/arbitration-ledger.js +1 -1
  19. package/dist/knowledge/audit-rules.js +1 -1
  20. package/dist/knowledge/baselines/rules/guard.json +96 -1
  21. package/dist/knowledge/baselines/rules/plan.json +30 -7
  22. package/dist/knowledge/baselines/semantic-facts.js +1 -1
  23. package/dist/knowledge/builtin-templates.d.ts +1 -1
  24. package/dist/knowledge/builtin-templates.js +1 -1
  25. package/dist/knowledge/discount-threshold.d.ts +11 -0
  26. package/dist/knowledge/discount-threshold.js +1 -1
  27. package/dist/knowledge/fund-layer.js +1 -1
  28. package/dist/knowledge/getting-started.js +1 -1
  29. package/dist/knowledge/guard-design-patterns.d.ts +1 -1
  30. package/dist/knowledge/guard-design-patterns.js +1 -1
  31. package/dist/knowledge/guard-field-cognition.js +1 -1
  32. package/dist/knowledge/guard-ledger.js +1 -1
  33. package/dist/knowledge/guard-lint.js +1 -1
  34. package/dist/knowledge/guard-render.js +1 -1
  35. package/dist/knowledge/guard-risk.d.ts +1 -0
  36. package/dist/knowledge/guard-risk.js +1 -1
  37. package/dist/knowledge/guard-submission-brief.d.ts +6 -0
  38. package/dist/knowledge/guard-submission-brief.js +1 -1
  39. package/dist/knowledge/guard-templates.d.ts +2 -2
  40. package/dist/knowledge/guard-templates.js +1 -1
  41. package/dist/knowledge/index.js +1 -1
  42. package/dist/knowledge/industry-registry.js +1 -1
  43. package/dist/knowledge/jsonrpc-enum.js +1 -1
  44. package/dist/knowledge/order-ledger.js +1 -1
  45. package/dist/knowledge/reward-ledger.js +1 -1
  46. package/dist/knowledge/safety-rules.js +1 -1
  47. package/dist/knowledge/template-loader.js +1 -1
  48. package/dist/knowledge/template-registry.js +1 -1
  49. package/dist/knowledge/template-scanner.d.ts +2 -0
  50. package/dist/knowledge/template-scanner.js +1 -1
  51. package/dist/knowledge/tool-constraints.js +1 -1
  52. package/dist/knowledge/workflow-guidance.d.ts +7 -3
  53. package/dist/knowledge/workflow-guidance.js +1 -1
  54. package/dist/monitor/MonitorLoop.js +1 -1
  55. package/dist/participation/radar-core.d.ts +1 -1
  56. package/dist/playbooks/service-build/business-puzzle.js +1 -1
  57. package/dist/playbooks/service-build/machine-panorama.js +1 -1
  58. package/dist/playbooks/service-build/merchant-guide.d.ts +8 -0
  59. package/dist/playbooks/service-build/merchant-guide.js +1 -1
  60. package/dist/playbooks/service-build/object-panorama.d.ts +28 -1
  61. package/dist/playbooks/service-build/object-panorama.js +1 -1
  62. package/dist/playbooks/service-build/participation-radar.d.ts +2 -0
  63. package/dist/playbooks/service-build/participation-radar.js +1 -1
  64. package/dist/playbooks/service-build/relationship-profile.js +1 -1
  65. package/dist/playbooks/service-build/reverse-mapping-nk4.spec.js +1 -1
  66. package/dist/playbooks/service-build/reverse-mapping.js +1 -1
  67. package/dist/playbooks/service-build/service-panorama.js +1 -1
  68. package/dist/playbooks/service-build/service-quote.js +1 -1
  69. package/dist/playbooks/service-build/service-quote.spec.js +1 -1
  70. package/dist/review/index.js +1 -1
  71. package/dist/safety/confirm-gate.js +1 -1
  72. package/dist/safety/preview.d.ts +1 -0
  73. package/dist/safety/preview.js +1 -1
  74. package/dist/schema/benchmark-migration/index.d.ts +14 -0
  75. package/dist/schema/benchmark-migration/index.js +1 -1
  76. package/dist/schema/call/allocation.d.ts +1 -1
  77. package/dist/schema/call/arbitration.d.ts +4 -4
  78. package/dist/schema/call/arbitration.js +1 -1
  79. package/dist/schema/call/base.d.ts +13 -5
  80. package/dist/schema/call/base.js +1 -1
  81. package/dist/schema/call/bridge.d.ts +2 -0
  82. package/dist/schema/call/contact.d.ts +1 -1
  83. package/dist/schema/call/demand.d.ts +1 -1
  84. package/dist/schema/call/error-codes.d.ts +1 -1
  85. package/dist/schema/call/error-codes.js +1 -1
  86. package/dist/schema/call/guard.d.ts +3 -3
  87. package/dist/schema/call/guard.js +1 -1
  88. package/dist/schema/call/handler.js +1 -1
  89. package/dist/schema/call/machine.d.ts +1 -1
  90. package/dist/schema/call/machine.js +1 -1
  91. package/dist/schema/call/order.d.ts +1 -1
  92. package/dist/schema/call/order.js +1 -1
  93. package/dist/schema/call/permission.d.ts +1 -1
  94. package/dist/schema/call/personal.d.ts +4 -4
  95. package/dist/schema/call/progress.d.ts +1 -1
  96. package/dist/schema/call/progress.js +1 -1
  97. package/dist/schema/call/proof.js +1 -1
  98. package/dist/schema/call/repository.d.ts +5 -5
  99. package/dist/schema/call/repository.js +1 -1
  100. package/dist/schema/call/reward.d.ts +1 -1
  101. package/dist/schema/call/reward.js +1 -1
  102. package/dist/schema/call/semantic.js +1 -1
  103. package/dist/schema/call/service.d.ts +4 -1
  104. package/dist/schema/call/service.js +1 -1
  105. package/dist/schema/call/treasury.d.ts +1 -1
  106. package/dist/schema/common/index.d.ts +4 -4
  107. package/dist/schema/common/index.js +1 -1
  108. package/dist/schema/goal/index.d.ts +12 -0
  109. package/dist/schema/goal/planning.d.ts +18 -0
  110. package/dist/schema/goal/planning.js +1 -1
  111. package/dist/schema/local/index.d.ts +21 -0
  112. package/dist/schema/local/index.js +1 -1
  113. package/dist/schema/messenger/index.js +1 -1
  114. package/dist/schema/operations.d.ts +22 -21
  115. package/dist/schema/query/bi.d.ts +6 -6
  116. package/dist/schema/query/bi.js +1 -1
  117. package/dist/schema/query/index.d.ts +112 -54
  118. package/dist/schema/query/index.js +1 -1
  119. package/dist/schema/schema-query/index.d.ts +1 -0
  120. package/dist/schema/schema-query/index.js +1 -1
  121. package/dist/schema/schema-version.js +1 -1
  122. package/dist/schema/utils/permission-machine-check.d.ts +2 -0
  123. package/dist/schema/utils/permission-machine-check.js +1 -1
  124. package/dist/schema/workflow/index.d.ts +1 -1
  125. package/dist/schema-query-impl/index.js +1 -1
  126. package/dist/schemas/account_operation.output.json +2 -0
  127. package/dist/schemas/account_operation.schema.json +3 -3
  128. package/dist/schemas/benchmark_migration_operation.output.json +42 -0
  129. package/dist/schemas/benchmark_migration_operation.schema.json +13 -0
  130. package/dist/schemas/bridge_operation.output.json +2 -0
  131. package/dist/schemas/goal_operation.schema.json +26 -0
  132. package/dist/schemas/index.json +1 -1
  133. package/dist/schemas/local_cache_operation.output.json +2 -0
  134. package/dist/schemas/local_history_operation.output.json +2 -0
  135. package/dist/schemas/local_info_operation.output.json +2 -0
  136. package/dist/schemas/local_mark_operation.output.json +2 -0
  137. package/dist/schemas/messenger_operation.schema.json +4 -4
  138. package/dist/schemas/onchain_operations.output.json +7 -5
  139. package/dist/schemas/onchain_operations.schema.json +108 -92
  140. package/dist/schemas/onchain_operations_allocation.schema.json +5 -5
  141. package/dist/schemas/onchain_operations_arbitration.schema.json +10 -8
  142. package/dist/schemas/onchain_operations_contact.schema.json +6 -5
  143. package/dist/schemas/onchain_operations_demand.schema.json +6 -5
  144. package/dist/schemas/onchain_operations_gen_passport.schema.json +5 -5
  145. package/dist/schemas/onchain_operations_gen_proof.schema.json +1 -1
  146. package/dist/schemas/onchain_operations_guard.schema.json +4 -4
  147. package/dist/schemas/onchain_operations_machine.schema.json +7 -6
  148. package/dist/schemas/onchain_operations_order.schema.json +8 -7
  149. package/dist/schemas/onchain_operations_permission.schema.json +1 -0
  150. package/dist/schemas/onchain_operations_personal.schema.json +2 -2
  151. package/dist/schemas/onchain_operations_progress.schema.json +8 -7
  152. package/dist/schemas/onchain_operations_proof.schema.json +6 -6
  153. package/dist/schemas/onchain_operations_repository.schema.json +10 -9
  154. package/dist/schemas/onchain_operations_reward.schema.json +8 -7
  155. package/dist/schemas/onchain_operations_service.schema.json +16 -11
  156. package/dist/schemas/onchain_operations_treasury.schema.json +6 -5
  157. package/dist/schemas/onchain_table_data.output.json +7 -7
  158. package/dist/schemas/query_toolkit.output.json +31 -30
  159. package/dist/schemas/query_toolkit.schema.json +1 -1
  160. package/dist/schemas/schema_query.schema.json +4 -0
  161. package/dist/schemas/workflow_operation.schema.json +5 -5
  162. package/dist/schemas/wowok_buildin_info.output.json +140 -3
  163. package/dist/schemas/wowok_buildin_info.schema.json +2 -2
  164. package/dist/tools/handlers/benchmark-migration.d.ts +22 -1
  165. package/dist/tools/handlers/benchmark-migration.js +1 -1
  166. package/dist/tools/handlers/config.js +1 -1
  167. package/dist/tools/handlers/dispatch-expectations.d.ts +0 -1
  168. package/dist/tools/handlers/dispatch-expectations.js +1 -1
  169. package/dist/tools/handlers/local.js +1 -1
  170. package/dist/tools/handlers/onchain.js +1 -1
  171. package/dist/tools/handlers/query.d.ts +1 -0
  172. package/dist/tools/handlers/query.js +1 -1
  173. package/dist/tools/handlers/review-chain.js +1 -1
  174. package/dist/tools/handlers/schema-query.js +1 -1
  175. package/dist/tools/index.js +1 -1
  176. package/dist/tools/move-fn-index.gen.js +1 -1
  177. package/dist/tools/registry/files.js +1 -1
  178. package/dist/tools/registry/query.js +1 -1
  179. package/dist/tools/rules-hook.js +1 -1
  180. package/dist/tools/upgrade-check.d.ts +23 -0
  181. package/dist/tools/upgrade-check.js +1 -1
  182. package/dist/tools/wip-deploy-assist.d.ts +6 -0
  183. package/dist/tools/wip-deploy-assist.js +1 -1
  184. package/dist/tools/wrap.js +1 -1
  185. package/package.json +2 -2
@@ -230,7 +230,7 @@
230
230
  "additionalProperties": false
231
231
  },
232
232
  "order_required_info": {
233
- "description": "Contact object ID or WTS Proof object, RECORDED on the Order as evidence that the order holder delivered the private information the Service declares in customer_required (e.g. phone/email/shipping_address). RECORD-ONLY, NOT ENFORCED: nothing on-chain reads this field — the purchase entry never requires it, and an order supplying none of the declared fields is still created. FLOW: the order holder sends the information to the Service's Contact (um) via end-to-end encrypted Messenger, then passes the Contact object ID or the generated WTS Proof here. To ENFORCE delivery on-chain, mount the pattern.required_info_evidence_gate Guard on the forward that hands over goods or funds, asserting order.required_info is some (presence-only — the recorded address value is never a guard condition; accepting the delivered information is the merchant's confirming forward).",
233
+ "description": "Contact object ID or WTS Proof object, RECORDED on the Order as evidence that the order holder delivered the private information the Service declares in customer_required (e.g. phone/email/shipping_address). RECORD-ONLY, NOT ENFORCED: nothing on-chain reads this field — the purchase entry never requires it, and an order supplying none of the declared fields is still created. FLOW: the order holder sends the information to the Service's Contact (um) via end-to-end encrypted Messenger, then passes the Contact object ID or the generated WTS Proof here. To ENFORCE delivery on-chain, mount the pattern.required_info_evidence_gate Guard on the forward that hands over goods or funds, asserting order.required_info is some (presence-only — the recorded address value is never a guard condition; accepting the delivered information is the merchant's confirming forward). ATTESTATION-ONLY: the recorded value is self-attested, has no on-chain readback, and MUST NOT be used as a gate condition. PER-ORDER BINDING: when the listing genuinely promises a per-order credential, use the dedicated controlled bind operation (order_required_info_bind) with a Proof whose about is THIS order and whose creator is the order holder — the chain verifies both at write time and rejects a mismatch without writing anything. The reuse model (one Contact Proof across orders) stays the default for this plain record field; pick per listing promise, not per habit.",
234
234
  "type": "string"
235
235
  },
236
236
  "transfer": {
@@ -742,7 +742,7 @@
742
742
  ]
743
743
  },
744
744
  "rewards": {
745
- "description": "Service Reward object list. May share the Service's Permission (no conflict check — intentional: rewards are the provider's own incentive tool; only Arbitration requires a different Permission for neutrality).",
745
+ "description": "Service Reward object list. May share the Service's Permission (no conflict check — intentional: rewards are the provider's own incentive tool; only Arbitration requires a different Permission for neutrality). ⚠️ OP SEMANTICS (SDK translation, etm-mn-261013 E-06): op:'set' executes as clear + add — and reward clear is TIME-LOCKED after publish (E_LOCKED_TIME_NOT_ENOUGH = abort 24: requires pause + setting_lock_duration elapsed, default 30 days). BEFORE publish op:'set' is fine; AFTER publish attach rewards with op:'add' ONLY (add has no lock).",
746
746
  "anyOf": [
747
747
  {
748
748
  "type": "object",
@@ -812,7 +812,7 @@
812
812
  ]
813
813
  },
814
814
  "arbitrations": {
815
- "description": "Service Arbitration object list. FORMAT: same as repositories — use the `objects` field name inside the operation data. Example: {arbitrations: {op: 'set', objects: [{name: 'my_arb_1'}, {name: 'my_arb_2'}]}}. NOTE: op:'add' is disabled on this surface (its success response can arrive unparseable and reads like a failure); ALWAYS pass the FULL list with op:'set'. Each item is a NameOrAddress (object ID or local mark name). ⚠️ PERMISSION RULE (contract-enforced): every Arbitration bound here MUST use a Permission object DIFFERENT from THIS Service's permission — binding an Arbitration that shares the Service's Permission aborts with E_ARBITRATION_PERMISSION_CONFLICT (error 33). Create a dedicated Permission for each Arbitration BEFORE binding. DESIGN RATIONALE (confirmed intentional): dispute resolution requires NEUTRALITY — an Arbitration controlled by the same Permission admins as the Service it judges would be a conflict of interest. ONLY Arbitration has this check: Reward and Treasury objects MAY share the Service's Permission (they are the provider's own tools).",
815
+ "description": "Service Arbitration object list. FORMAT: same as repositories — use the `objects` field name inside the operation data. Example: {arbitrations: {op: 'add', objects: [{name: 'my_arb_1'}]}}. Each item is a NameOrAddress (object ID or local mark name). ⚠️ OP SEMANTICS (SDK translation, etm-mn-261013 E-06 + crs P3-1): op:'add' appends and is the ONLY unlocked path after publish (add has no publish assert, service.move). op:'set' executes as clear + add and REPLACES the entire allowlist (pass EVERY Arbitration that must remain bound) — clear is TIME-LOCKED after publish (E_LOCKED_TIME_NOT_ENOUGH = abort 24: requires pause + setting_lock_duration elapsed, default 30 days), so use op:'set' BEFORE publish only. (The 2026-10-08 op:'add' disable was lifted: the unparseable-success-response SDK bug it responded to is fixed — safeTextJson + big-int conversion.) ⚠️ PERMISSION RULE (contract-enforced): every Arbitration bound here MUST use a Permission object DIFFERENT from THIS Service's permission — binding an Arbitration that shares the Service's Permission aborts with E_ARBITRATION_PERMISSION_CONFLICT (error 33). Create a dedicated Permission for each Arbitration BEFORE binding. DESIGN RATIONALE (confirmed intentional): dispute resolution requires NEUTRALITY — an Arbitration controlled by the same Permission admins as the Service it judges would be a conflict of interest. ONLY Arbitration has this check: Reward and Treasury objects MAY share the Service's Permission (they are the provider's own tools).",
816
816
  "anyOf": [
817
817
  {
818
818
  "type": "object",
@@ -935,9 +935,13 @@
935
935
  ]
936
936
  },
937
937
  "time_ms_start": {
938
- "description": "Discount start time (milliseconds)",
938
+ "description": "Discount start time (milliseconds). ⚠️ A FUTURE start mints a coupon that is listed as usable but CANNOT be spent until the window opens (every spend aborts E_DISCOUNT_TIME_INVALID / buy code 35). Legitimate for scheduled campaigns — the mint carries a loud warning; do not distribute the coupon to recipients before the window opens.",
939
939
  "type": "number"
940
940
  },
941
+ "allow_zero_total": {
942
+ "description": "FREE-TIER ESCAPE HATCH (BKN-P2): a coupon that would drive the final total to 0 (MINUS value >= the cheapest SKU price, or RATES value 10000) is BLOCKED at issuance by default. Set true ONLY to declare a deliberate zero-price product: the issuance then proceeds with a disclosure that zero-total orders carry an empty escrow and NEVER trigger reward/incentive rails. Omit (default false) for normal discounts.",
943
+ "type": "boolean"
944
+ },
941
945
  "time_ms_end": {
942
946
  "type": "number",
943
947
  "description": "Discount end time (milliseconds)"
@@ -978,7 +982,7 @@
978
982
  "check_all_founded"
979
983
  ],
980
984
  "additionalProperties": false,
981
- "description": "Discount recipient"
985
+ "description": "Discount recipient. OBJECT FORM REQUIRED (T9 az3-mn-261013): a bare string is REJECTED here — pass {entities: [{name_or_address: '<account_name_or_0x_address>'}]} (example: {entities: [{name_or_address: 'buyer1'}]}). Total coupons delivered = count × number of recipients."
982
986
  },
983
987
  "transferable": {
984
988
  "type": "boolean",
@@ -1015,7 +1019,7 @@
1015
1019
  "type": "string",
1016
1020
  "description": "Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."
1017
1021
  },
1018
- "description": "Coupon object IDs or local names to transfer. You MUST own these Discount objects. Each coupon must have been minted with transferable:true — otherwise the chain aborts with E_DISCOUNT_NOT_TRANSFERABLE (semantic code service:10). Coupons stay single-use; the transfer does not change that. Max 1000 coupons per call (SDK limit MAX_DISCOUNT_COUNT_ONCE)."
1022
+ "description": "Coupon object IDs or local names to transfer. You MUST own these Discount objects. Each coupon must have been minted with transferable:true — otherwise the chain aborts with E_DISCOUNT_NOT_TRANSFERABLE (semantic code service:10). Coupons stay single-use; the transfer does not change that. There is NO batch entry on-chain — each coupon is delivered by its own singleton call (fanned out automatically); prefer ONE coupon per transaction for coupon migrations (SDK cap MAX_DISCOUNT_COUNT_ONCE still applies)."
1019
1023
  },
1020
1024
  "recipient": {
1021
1025
  "type": "object",
@@ -1629,6 +1633,7 @@
1629
1633
  "description": "Unwrap CoinWrapper objects and other objects received by this Service object and send them to the owner of its Permission object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n Use this for the common case: \"withdraw everything the object has received.\"\n Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n Use this when you want to receive specific objects only (not all).\n Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
1630
1634
  "anyOf": [
1631
1635
  {
1636
+ "minItems": 1,
1632
1637
  "type": "array",
1633
1638
  "items": {
1634
1639
  "type": "object",
@@ -1940,6 +1945,7 @@
1940
1945
  "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."
1941
1946
  },
1942
1947
  "value_type": {
1948
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
1943
1949
  "anyOf": [
1944
1950
  {
1945
1951
  "type": "number",
@@ -2226,11 +2232,10 @@
2226
2232
  "const": "vecvecu8",
2227
2233
  "description": "vecvecu8"
2228
2234
  }
2229
- ],
2230
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
2235
+ ]
2231
2236
  },
2232
2237
  "value": {
2233
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
2238
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
2234
2239
  "anyOf": [
2235
2240
  {
2236
2241
  "type": "boolean"
@@ -2389,7 +2394,7 @@
2389
2394
  "additionalProperties": false,
2390
2395
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
2391
2396
  },
2392
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
2397
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
2393
2398
  }
2394
2399
  },
2395
2400
  "required": [
@@ -2399,7 +2404,7 @@
2399
2404
  "additionalProperties": false,
2400
2405
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
2401
2406
  },
2402
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
2407
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
2403
2408
  }
2404
2409
  },
2405
2410
  "required": [
@@ -3480,7 +3485,7 @@
3480
3485
  ]
3481
3486
  },
3482
3487
  "pause": {
3483
- "description": "Whether to pause generating new Progress objects.",
3488
+ "description": "Whether to pause generating new Progress objects. Chain truth (machine.move:657, the progress-generation entry asserts !bPaused): the pause gates NEW order entry only — in-flight Progress keeps advancing and settling (yfd-ln F-13 misread this as a freeze switch; it never was one).",
3484
3489
  "type": "boolean"
3485
3490
  },
3486
3491
  "publish": {
@@ -3491,6 +3496,7 @@
3491
3496
  "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::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
3492
3497
  "anyOf": [
3493
3498
  {
3499
+ "minItems": 1,
3494
3500
  "type": "array",
3495
3501
  "items": {
3496
3502
  "type": "object",
@@ -3769,6 +3775,7 @@
3769
3775
  "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."
3770
3776
  },
3771
3777
  "value_type": {
3778
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
3772
3779
  "anyOf": [
3773
3780
  {
3774
3781
  "type": "number",
@@ -4055,11 +4062,10 @@
4055
4062
  "const": "vecvecu8",
4056
4063
  "description": "vecvecu8"
4057
4064
  }
4058
- ],
4059
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
4065
+ ]
4060
4066
  },
4061
4067
  "value": {
4062
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
4068
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
4063
4069
  "anyOf": [
4064
4070
  {
4065
4071
  "type": "boolean"
@@ -4218,7 +4224,7 @@
4218
4224
  "additionalProperties": false,
4219
4225
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
4220
4226
  },
4221
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
4227
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
4222
4228
  }
4223
4229
  },
4224
4230
  "required": [
@@ -4228,7 +4234,7 @@
4228
4234
  "additionalProperties": false,
4229
4235
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
4230
4236
  },
4231
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
4237
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
4232
4238
  }
4233
4239
  },
4234
4240
  "required": [
@@ -4436,7 +4442,7 @@
4436
4442
  ]
4437
4443
  },
4438
4444
  "message": {
4439
- "description": "Operation result message.",
4445
+ "description": "Message attached to the forward advance; recorded permanently in on-chain History. REVIEW-TYPE FORWARDS: de-facto REQUIRED here — the review text is this message (the reward claim guard does not read it, but a no-message Review forward has failed repeatedly on mainnet until the message was added). Always include message: '<review text>' when advancing a Review-named forward.",
4440
4446
  "type": "string"
4441
4447
  }
4442
4448
  },
@@ -4450,6 +4456,7 @@
4450
4456
  "description": "Unwrap CoinWrapper objects and other objects received by this Progress object and send them to the owner of the bound Machine's 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::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
4451
4457
  "anyOf": [
4452
4458
  {
4459
+ "minItems": 1,
4453
4460
  "type": "array",
4454
4461
  "items": {
4455
4462
  "type": "object",
@@ -4570,7 +4577,7 @@
4570
4577
  "properties": {
4571
4578
  "repository": {
4572
4579
  "type": "string",
4573
- "description": "Repository object ID or name that stores the structured reputation record. Its matching policy key should use id_from=Signer (one record per buyer, rewrite = own-record overwrite) and accept a JSON payload {rating, tags?, orderRef?}. PREFERRED: the service's review repository EMITTED BY THE BUILD PLAN when review_mode was set (AR-1) — resolve it from the service's repositories list (service_panorama / onchain_objects, name suffix '_review') — never guess an address."
4580
+ "description": "Repository object ID or name that stores the structured reputation record. The matching policy key must accept a JSON payload {rating, tags?, orderRef?}. id_from options (C30): Signer = one record per BUYER (rewrite = own-record overwrite); None + a write_guard with id_from_submission = one record per bound OBJECT/ORDER (the row id is the raw bound Order address — the verified once-per-order review shape); Clock = append-only log. PREFERRED: the service's review repository EMITTED BY THE BUILD PLAN when review_mode was set (AR-1) — resolve it from the service's repositories list (service_panorama / onchain_objects, name suffix '_review') — never guess an address."
4574
4581
  },
4575
4582
  "key": {
4576
4583
  "description": "Data key (policy rule name) to write under. Default 'review'.",
@@ -4773,6 +4780,7 @@
4773
4780
  "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."
4774
4781
  },
4775
4782
  "value_type": {
4783
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
4776
4784
  "anyOf": [
4777
4785
  {
4778
4786
  "type": "number",
@@ -5059,11 +5067,10 @@
5059
5067
  "const": "vecvecu8",
5060
5068
  "description": "vecvecu8"
5061
5069
  }
5062
- ],
5063
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
5070
+ ]
5064
5071
  },
5065
5072
  "value": {
5066
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
5073
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
5067
5074
  "anyOf": [
5068
5075
  {
5069
5076
  "type": "boolean"
@@ -5222,7 +5229,7 @@
5222
5229
  "additionalProperties": false,
5223
5230
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
5224
5231
  },
5225
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
5232
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
5226
5233
  }
5227
5234
  },
5228
5235
  "required": [
@@ -5232,7 +5239,7 @@
5232
5239
  "additionalProperties": false,
5233
5240
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
5234
5241
  },
5235
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
5242
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
5236
5243
  }
5237
5244
  },
5238
5245
  "required": [
@@ -5340,7 +5347,7 @@
5340
5347
  "description": "Description string (max 4000 bcs characters)"
5341
5348
  },
5342
5349
  "policies": {
5343
- "description": "Write and read permission rules governing the data records of this Repository.",
5350
+ "description": "Write and read permission rules governing the data records of this Repository. NOTE the PLURAL field name here — the Permission object's equivalent field is singular 'policy' (set/add/remove ops); do not carry one spelling to the other.",
5344
5351
  "oneOf": [
5345
5352
  {
5346
5353
  "type": "object",
@@ -5457,6 +5464,7 @@
5457
5464
  "description": "Source of data ID when writing data. If None, user must specify the ID separately; if Clock, data ID is current timestamp; if Signer, data ID is user ID."
5458
5465
  },
5459
5466
  "value_type": {
5467
+ "description": "Type of data value when writing data. Note: 19 (Value) is an internal dynamic type for guard expressions and is NOT accepted here.",
5460
5468
  "anyOf": [
5461
5469
  {
5462
5470
  "type": "number",
@@ -5743,8 +5751,7 @@
5743
5751
  "const": "vecvecu8",
5744
5752
  "description": "vecvecu8"
5745
5753
  }
5746
- ],
5747
- "description": "Type of data value when writing data. Note: 19 (Value) is an internal dynamic type for guard expressions and is NOT accepted here."
5754
+ ]
5748
5755
  }
5749
5756
  },
5750
5757
  "required": [
@@ -6067,6 +6074,7 @@
6067
6074
  "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::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
6068
6075
  "anyOf": [
6069
6076
  {
6077
+ "minItems": 1,
6070
6078
  "type": "array",
6071
6079
  "items": {
6072
6080
  "type": "object",
@@ -6345,6 +6353,7 @@
6345
6353
  "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."
6346
6354
  },
6347
6355
  "value_type": {
6356
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
6348
6357
  "anyOf": [
6349
6358
  {
6350
6359
  "type": "number",
@@ -6631,11 +6640,10 @@
6631
6640
  "const": "vecvecu8",
6632
6641
  "description": "vecvecu8"
6633
6642
  }
6634
- ],
6635
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
6643
+ ]
6636
6644
  },
6637
6645
  "value": {
6638
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
6646
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
6639
6647
  "anyOf": [
6640
6648
  {
6641
6649
  "type": "boolean"
@@ -6794,7 +6802,7 @@
6794
6802
  "additionalProperties": false,
6795
6803
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
6796
6804
  },
6797
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
6805
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
6798
6806
  }
6799
6807
  },
6800
6808
  "required": [
@@ -6804,7 +6812,7 @@
6804
6812
  "additionalProperties": false,
6805
6813
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
6806
6814
  },
6807
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
6815
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
6808
6816
  }
6809
6817
  },
6810
6818
  "required": [
@@ -6924,8 +6932,8 @@
6924
6932
  "description": "Order ID or name."
6925
6933
  },
6926
6934
  "description": {
6927
- "description": "Dispute description.",
6928
- "type": "string"
6935
+ "type": "string",
6936
+ "description": "Dispute description. REQUIRED and NON-EMPTY on-chain (the dispute call aborts when it is empty; max 4000 bytes). State what the dispute is about — it is permanent on-chain case context."
6929
6937
  },
6930
6938
  "proposition": {
6931
6939
  "type": "array",
@@ -7002,6 +7010,7 @@
7002
7010
  },
7003
7011
  "required": [
7004
7012
  "order",
7013
+ "description",
7005
7014
  "proposition",
7006
7015
  "fee"
7007
7016
  ],
@@ -7103,7 +7112,7 @@
7103
7112
  "description": "Proposition INDICES (0-based, u8) the voter agrees with — e.g. [0] votes for the first proposition. Re-voting REPLACES the voter's previous vote (old weight removed, new applied). Out-of-range index aborts with E_PROPOSITION_NOT_FOUND."
7104
7113
  },
7105
7114
  "voting_guard": {
7106
- "description": "Voting Guard for WEIGHTED voting. DECISION RULE (contract-enforced):\n(A) Arbitration HAS a non-empty voting_guard list → plain vote is REJECTED on-chain with E_VOTING_GUARD_USED (abort 2). You MUST provide this field set to ONE guard from the Arbitration's voting_guard list, and fill its submission: when the guard's vote_weight is {GuardIdentifier: pos}, the number you submit at that table position IS the vote weight; when it is {FixedValue: v}, no submission is needed (weight is fixed). The SDK then routes the call through the Guard-weighted vote path via a Passport. Omitting this field on such an Arbitration now fails fast pre-call with the list of valid guards.\n(B) Arbitration has NO voting_guard → omit this field; the SDK uses plain vote (weight 1, permission-gated), or the passport-gated vote path when other guards require it.\nBOTH (B) paths still assert ARBITRATION_VOTE=358 on-chain (the SDK now pre-checks 358 and fails fast with 'Missing permissions 358'). An empty voting_guard means EQUAL WEIGHT (1 person 1 vote), NOT permissionless — there is no permission-free vote entry. For genuinely open voting, configure a public voting_guard (op=\"set\") and vote via path (A): the weighted passport path authorizes by the guard and does NOT require 358.\nThe Guard (when provided) MUST be in the Arbitration's voting_guard list — an unlisted guard aborts with E_VOTING_GUARD_NOT_FOUND.",
7115
+ "description": "Voting Guard for WEIGHTED voting. DECISION RULE (contract-enforced):\n(A) Arbitration HAS a non-empty voting_guard list → plain vote is REJECTED on-chain with E_VOTING_GUARD_USED (abort 2). You MUST provide this field set to ONE guard from the Arbitration's voting_guard list, and fill its submission: when the guard's vote_weight is {GuardIdentifier: pos}, the number you submit at that table position IS the vote weight; when it is {FixedValue: v}, no submission is needed (weight is fixed). The SDK then routes the call through the Guard-weighted vote path via a Passport. Omitting this field on such an Arbitration now fails fast pre-call with the list of valid guards.\n(B) Arbitration has NO voting_guard → omit this field; the SDK uses plain vote (weight 1, permission-gated), or the passport-gated vote path when other guards require it.\nBOTH (B) paths still assert ARBITRATION_VOTE=358 on-chain (the SDK now pre-checks 358 and fails fast with 'Missing permissions 358'). An empty voting_guard means EQUAL WEIGHT (1 person 1 vote), NOT permissionless — there is no permission-free vote entry. For genuinely open voting, configure a public voting_guard (op=\"set\") and vote via path (A): the weighted passport path authorizes by the guard and does NOT require 358.\nThe Guard (when provided) MUST be in the Arbitration's voting_guard list — an unlisted guard aborts with E_VOTING_GUARD_NOT_FOUND. WEIGHTED REVOTE RESIDUE (az3-mn-261013, arb.move:315-320 source comment): under weighted voting a re-vote is NOT clean — re-voting with a LARGER weight than the previous one aborts on underflow (re-vote DoS surface); re-voting with a SMALLER weight succeeds but leaves phantom votes behind. Treat the first weighted vote as final when possible.",
7107
7116
  "type": "string"
7108
7117
  }
7109
7118
  },
@@ -7397,6 +7406,7 @@
7397
7406
  "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::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
7398
7407
  "anyOf": [
7399
7408
  {
7409
+ "minItems": 1,
7400
7410
  "type": "array",
7401
7411
  "items": {
7402
7412
  "type": "object",
@@ -7675,6 +7685,7 @@
7675
7685
  "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."
7676
7686
  },
7677
7687
  "value_type": {
7688
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
7678
7689
  "anyOf": [
7679
7690
  {
7680
7691
  "type": "number",
@@ -7961,11 +7972,10 @@
7961
7972
  "const": "vecvecu8",
7962
7973
  "description": "vecvecu8"
7963
7974
  }
7964
- ],
7965
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
7975
+ ]
7966
7976
  },
7967
7977
  "value": {
7968
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
7978
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
7969
7979
  "anyOf": [
7970
7980
  {
7971
7981
  "type": "boolean"
@@ -8124,7 +8134,7 @@
8124
8134
  "additionalProperties": false,
8125
8135
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
8126
8136
  },
8127
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
8137
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
8128
8138
  }
8129
8139
  },
8130
8140
  "required": [
@@ -8134,7 +8144,7 @@
8134
8144
  "additionalProperties": false,
8135
8145
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
8136
8146
  },
8137
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
8147
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
8138
8148
  }
8139
8149
  },
8140
8150
  "required": [
@@ -8373,6 +8383,7 @@
8373
8383
  "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::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
8374
8384
  "anyOf": [
8375
8385
  {
8386
+ "minItems": 1,
8376
8387
  "type": "array",
8377
8388
  "items": {
8378
8389
  "type": "object",
@@ -8639,6 +8650,7 @@
8639
8650
  "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."
8640
8651
  },
8641
8652
  "value_type": {
8653
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
8642
8654
  "anyOf": [
8643
8655
  {
8644
8656
  "type": "number",
@@ -8925,11 +8937,10 @@
8925
8937
  "const": "vecvecu8",
8926
8938
  "description": "vecvecu8"
8927
8939
  }
8928
- ],
8929
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
8940
+ ]
8930
8941
  },
8931
8942
  "value": {
8932
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
8943
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
8933
8944
  "anyOf": [
8934
8945
  {
8935
8946
  "type": "boolean"
@@ -9088,7 +9099,7 @@
9088
9099
  "additionalProperties": false,
9089
9100
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
9090
9101
  },
9091
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
9102
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
9092
9103
  }
9093
9104
  },
9094
9105
  "required": [
@@ -9098,7 +9109,7 @@
9098
9109
  "additionalProperties": false,
9099
9110
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
9100
9111
  },
9101
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
9112
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
9102
9113
  }
9103
9114
  },
9104
9115
  "required": [
@@ -9866,6 +9877,7 @@
9866
9877
  "description": "Unwrap CoinWrapper objects and other objects received by this Treasury object and send them to the owner of its Permission object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n Use this for the common case: \"withdraw everything the object has received.\"\n Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n Use this when you want to receive specific objects only (not all).\n Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
9867
9878
  "anyOf": [
9868
9879
  {
9880
+ "minItems": 1,
9869
9881
  "type": "array",
9870
9882
  "items": {
9871
9883
  "type": "object",
@@ -10144,6 +10156,7 @@
10144
10156
  "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."
10145
10157
  },
10146
10158
  "value_type": {
10159
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
10147
10160
  "anyOf": [
10148
10161
  {
10149
10162
  "type": "number",
@@ -10430,11 +10443,10 @@
10430
10443
  "const": "vecvecu8",
10431
10444
  "description": "vecvecu8"
10432
10445
  }
10433
- ],
10434
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
10446
+ ]
10435
10447
  },
10436
10448
  "value": {
10437
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
10449
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
10438
10450
  "anyOf": [
10439
10451
  {
10440
10452
  "type": "boolean"
@@ -10593,7 +10605,7 @@
10593
10605
  "additionalProperties": false,
10594
10606
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
10595
10607
  },
10596
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
10608
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
10597
10609
  }
10598
10610
  },
10599
10611
  "required": [
@@ -10603,7 +10615,7 @@
10603
10615
  "additionalProperties": false,
10604
10616
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
10605
10617
  },
10606
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
10618
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
10607
10619
  }
10608
10620
  },
10609
10621
  "required": [
@@ -10845,7 +10857,7 @@
10845
10857
  ]
10846
10858
  },
10847
10859
  "guard_add": {
10848
- "description": "Add Guard to Reward object.",
10860
+ "description": "Add Guard to Reward object. IDIOMS (F08 — these differ from Service allocation, follow THIS shape here): recipient is ONE OF {GuardIdentifier: <u8>} | {Entity: {name_or_address: 'mark'}} | {Signer: 'signer'} (string const INSIDE the key, NOT a bare string); amount is {type: 'Fixed', value: '0.1WOW'} — value accepts a display string with token symbol ('0.1WOW') or a smallest-unit integer ('100000000'), NOT the plain balance string used by allocation `sharing`. FULL EXAMPLE: [{guard: '0xabc...', recipient: {Signer: 'signer'}, amount: {type: 'Fixed', value: '0.1WOW'}}].",
10849
10861
  "type": "array",
10850
10862
  "items": {
10851
10863
  "type": "object",
@@ -11015,6 +11027,7 @@
11015
11027
  "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::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
11016
11028
  "anyOf": [
11017
11029
  {
11030
+ "minItems": 1,
11018
11031
  "type": "array",
11019
11032
  "items": {
11020
11033
  "type": "object",
@@ -11146,7 +11159,7 @@
11146
11159
  "object"
11147
11160
  ],
11148
11161
  "additionalProperties": false,
11149
- "description": "On-chain Reward operations. USAGE: (1) CREATE NEW: Set 'object' field with OBJECT format {name, type_parameter, permission, ...} to create a Reward. NOTE: 'name' goes INSIDE 'object', NOT at the data root level.'permission' can be a new Permission object or reference an existing one - check 'object' field description for details. (2) OPERATE EXISTING: Set 'object' field with STRING format (object ID or name). The 'object' field is CRITICAL and REQUIRED in both cases. STRING for existing, OBJECT for new creation."
11162
+ "description": "On-chain Reward operations. USAGE: (1) CREATE NEW: Set 'object' field with OBJECT format {name, type_parameter, permission, ...} to create a Reward. NOTE: 'name' goes INSIDE 'object', NOT at the data root level.'permission' can be a new Permission object or reference an existing one - check 'object' field description for details. (2) OPERATE EXISTING: Set 'object' field with STRING format (object ID or name). The 'object' field is CRITICAL and REQUIRED in both cases. STRING for existing, OBJECT for new creation. NAME RESOLUTION SCOPE (T8 az3-mn-261013): a LocalMark name resolves ONLY within the SIGNING account's own local mark store — when the Reward was named by a DIFFERENT account (e.g. the merchant's mark) and you operate it from another account, the name lookup fails with 'not found locally'; pass the on-chain 0x object ID instead (resolve it once via workspace/onchain_objects and reuse the id)."
11150
11163
  },
11151
11164
  "env": {
11152
11165
  "type": "object",
@@ -11293,6 +11306,7 @@
11293
11306
  "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."
11294
11307
  },
11295
11308
  "value_type": {
11309
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
11296
11310
  "anyOf": [
11297
11311
  {
11298
11312
  "type": "number",
@@ -11579,11 +11593,10 @@
11579
11593
  "const": "vecvecu8",
11580
11594
  "description": "vecvecu8"
11581
11595
  }
11582
- ],
11583
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
11596
+ ]
11584
11597
  },
11585
11598
  "value": {
11586
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
11599
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
11587
11600
  "anyOf": [
11588
11601
  {
11589
11602
  "type": "boolean"
@@ -11742,7 +11755,7 @@
11742
11755
  "additionalProperties": false,
11743
11756
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
11744
11757
  },
11745
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
11758
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
11746
11759
  }
11747
11760
  },
11748
11761
  "required": [
@@ -11752,7 +11765,7 @@
11752
11765
  "additionalProperties": false,
11753
11766
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
11754
11767
  },
11755
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
11768
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
11756
11769
  }
11757
11770
  },
11758
11771
  "required": [
@@ -12346,6 +12359,7 @@
12346
12359
  "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."
12347
12360
  },
12348
12361
  "value_type": {
12362
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
12349
12363
  "anyOf": [
12350
12364
  {
12351
12365
  "type": "number",
@@ -12632,11 +12646,10 @@
12632
12646
  "const": "vecvecu8",
12633
12647
  "description": "vecvecu8"
12634
12648
  }
12635
- ],
12636
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
12649
+ ]
12637
12650
  },
12638
12651
  "value": {
12639
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
12652
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
12640
12653
  "anyOf": [
12641
12654
  {
12642
12655
  "type": "boolean"
@@ -12795,7 +12808,7 @@
12795
12808
  "additionalProperties": false,
12796
12809
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
12797
12810
  },
12798
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
12811
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
12799
12812
  }
12800
12813
  },
12801
12814
  "required": [
@@ -12805,7 +12818,7 @@
12805
12818
  "additionalProperties": false,
12806
12819
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
12807
12820
  },
12808
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
12821
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
12809
12822
  }
12810
12823
  },
12811
12824
  "required": [
@@ -13486,6 +13499,7 @@
13486
13499
  "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::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
13487
13500
  "anyOf": [
13488
13501
  {
13502
+ "minItems": 1,
13489
13503
  "type": "array",
13490
13504
  "items": {
13491
13505
  "type": "object",
@@ -13770,6 +13784,7 @@
13770
13784
  "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."
13771
13785
  },
13772
13786
  "value_type": {
13787
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
13773
13788
  "anyOf": [
13774
13789
  {
13775
13790
  "type": "number",
@@ -14056,11 +14071,10 @@
14056
14071
  "const": "vecvecu8",
14057
14072
  "description": "vecvecu8"
14058
14073
  }
14059
- ],
14060
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
14074
+ ]
14061
14075
  },
14062
14076
  "value": {
14063
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
14077
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
14064
14078
  "anyOf": [
14065
14079
  {
14066
14080
  "type": "boolean"
@@ -17104,7 +17118,7 @@
17104
17118
  },
17105
17119
  "file_path": {
17106
17120
  "type": "string",
17107
- "description": "Path to JSON or Markdown file containing Guard definition. File can define: namedNew, description, table, root, rely."
17121
+ "description": "ABSOLUTE path to JSON or Markdown file containing Guard definition. Field name is `file_path` (NOT `file`). File can define: namedNew, description, table, root, rely."
17108
17122
  },
17109
17123
  "format": {
17110
17124
  "default": "json",
@@ -17676,7 +17690,7 @@
17676
17690
  "description": "vecvecu8"
17677
17691
  }
17678
17692
  ],
17679
- "description": "User available value type (number or string, e.g., 6 or 'U64' or 'u64')"
17693
+ "description": "User available value type (number, numeric string, or name — e.g., 6, '6', 'U64', 'u64')"
17680
17694
  },
17681
17695
  {
17682
17696
  "type": "number",
@@ -18871,6 +18885,7 @@
18871
18885
  "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::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
18872
18886
  "anyOf": [
18873
18887
  {
18888
+ "minItems": 1,
18874
18889
  "type": "array",
18875
18890
  "items": {
18876
18891
  "type": "object",
@@ -19149,6 +19164,7 @@
19149
19164
  "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."
19150
19165
  },
19151
19166
  "value_type": {
19167
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
19152
19168
  "anyOf": [
19153
19169
  {
19154
19170
  "type": "number",
@@ -19435,11 +19451,10 @@
19435
19451
  "const": "vecvecu8",
19436
19452
  "description": "vecvecu8"
19437
19453
  }
19438
- ],
19439
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
19454
+ ]
19440
19455
  },
19441
19456
  "value": {
19442
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
19457
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
19443
19458
  "anyOf": [
19444
19459
  {
19445
19460
  "type": "boolean"
@@ -19598,7 +19613,7 @@
19598
19613
  "additionalProperties": false,
19599
19614
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
19600
19615
  },
19601
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
19616
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
19602
19617
  }
19603
19618
  },
19604
19619
  "required": [
@@ -19608,7 +19623,7 @@
19608
19623
  "additionalProperties": false,
19609
19624
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
19610
19625
  },
19611
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
19626
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
19612
19627
  }
19613
19628
  },
19614
19629
  "required": [
@@ -19676,7 +19691,7 @@
19676
19691
  "additionalProperties": false
19677
19692
  },
19678
19693
  "required_info": {
19679
- "description": "Credential recorded on the order: the merchant's IM user address resolved from the Service's Contact (zero cost) or a WTS Proof object id (on-chain delivery proof embedding that IM address and timestamp; costs gas). The information itself is delivered via Wowok Messenger.",
19694
+ "description": "Credential recorded on the order: the merchant's IM user address resolved from the Service's Contact (zero cost) or a WTS Proof object id (on-chain delivery proof embedding that IM address and timestamp; costs gas). The information itself is delivered via Wowok Messenger. WRITE PERMISSION: OWNER-ONLY — only the order owner (the buyer) can set or clear this field; any other signer (including the merchant/service owner) aborts on-chain (MoveAbort 1, 'Not the owner'). The merchant's role is to READ it and to receive the info over Messenger. ATTESTATION SEMANTICS: the recorded VALUE is self-attested and has no on-chain readback — never trust the value itself as a gate condition. A PRESENCE gate IS legitimate on-chain (query order.required_info is some — see pattern.required_info_evidence_gate): it proves the buyer recorded a credential before handover, without asserting what the credential says.",
19680
19695
  "anyOf": [
19681
19696
  {
19682
19697
  "type": "string",
@@ -19722,7 +19737,7 @@
19722
19737
  ]
19723
19738
  },
19724
19739
  "message": {
19725
- "description": "Operation result message.",
19740
+ "description": "Message attached to the forward advance; recorded permanently in on-chain History. REVIEW-TYPE FORWARDS: de-facto REQUIRED here — the review text is this message (the reward claim guard does not read it, but a no-message Review forward has failed repeatedly on mainnet until the message was added). Always include message: '<review text>' when advancing a Review-named forward.",
19726
19741
  "type": "string"
19727
19742
  }
19728
19743
  },
@@ -19799,6 +19814,7 @@
19799
19814
  "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::wow::WOW>'}]\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::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
19800
19815
  "anyOf": [
19801
19816
  {
19817
+ "minItems": 1,
19802
19818
  "type": "array",
19803
19819
  "items": {
19804
19820
  "type": "object",
@@ -20212,6 +20228,7 @@
20212
20228
  "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."
20213
20229
  },
20214
20230
  "value_type": {
20231
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
20215
20232
  "anyOf": [
20216
20233
  {
20217
20234
  "type": "number",
@@ -20498,11 +20515,10 @@
20498
20515
  "const": "vecvecu8",
20499
20516
  "description": "vecvecu8"
20500
20517
  }
20501
- ],
20502
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
20518
+ ]
20503
20519
  },
20504
20520
  "value": {
20505
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
20521
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
20506
20522
  "anyOf": [
20507
20523
  {
20508
20524
  "type": "boolean"
@@ -20661,7 +20677,7 @@
20661
20677
  "additionalProperties": false,
20662
20678
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
20663
20679
  },
20664
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
20680
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
20665
20681
  }
20666
20682
  },
20667
20683
  "required": [
@@ -20671,7 +20687,7 @@
20671
20687
  "additionalProperties": false,
20672
20688
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
20673
20689
  },
20674
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
20690
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
20675
20691
  }
20676
20692
  },
20677
20693
  "required": [
@@ -20768,6 +20784,7 @@
20768
20784
  "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."
20769
20785
  },
20770
20786
  "value_type": {
20787
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
20771
20788
  "anyOf": [
20772
20789
  {
20773
20790
  "type": "number",
@@ -21054,11 +21071,10 @@
21054
21071
  "const": "vecvecu8",
21055
21072
  "description": "vecvecu8"
21056
21073
  }
21057
- ],
21058
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
21074
+ ]
21059
21075
  },
21060
21076
  "value": {
21061
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
21077
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
21062
21078
  "anyOf": [
21063
21079
  {
21064
21080
  "type": "boolean"
@@ -21217,7 +21233,7 @@
21217
21233
  "additionalProperties": false,
21218
21234
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
21219
21235
  },
21220
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
21236
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
21221
21237
  }
21222
21238
  },
21223
21239
  "required": [
@@ -21227,7 +21243,7 @@
21227
21243
  "additionalProperties": false,
21228
21244
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
21229
21245
  },
21230
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
21246
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
21231
21247
  }
21232
21248
  },
21233
21249
  "required": [
@@ -21420,7 +21436,7 @@
21420
21436
  ]
21421
21437
  },
21422
21438
  "about_address": {
21423
- "description": "About address. Accepts null/undefined (→ Move Option::none). When provided, must be a raw 0x-prefixed address (NOT a name). e.g. address of the entity being proved.",
21439
+ "description": "About binding (K3 contract): ONLY the counterparty ACCOUNT address (address first byte = account type) or a Proof object address (first byte = Proof type) — a messenger contact record. NEVER a business object (Progress/Order/Arb) and never a guard decision condition. Accepts null/undefined (→ Move Option::none). When provided, must be a raw 0x-prefixed address (NOT a name). e.g. the peer account being proved with.",
21424
21440
  "anyOf": [
21425
21441
  {
21426
21442
  "type": "string",
@@ -21587,6 +21603,7 @@
21587
21603
  "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."
21588
21604
  },
21589
21605
  "value_type": {
21606
+ "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
21590
21607
  "anyOf": [
21591
21608
  {
21592
21609
  "type": "number",
@@ -21873,11 +21890,10 @@
21873
21890
  "const": "vecvecu8",
21874
21891
  "description": "vecvecu8"
21875
21892
  }
21876
- ],
21877
- "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
21893
+ ]
21878
21894
  },
21879
21895
  "value": {
21880
- "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
21896
+ "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
21881
21897
  "anyOf": [
21882
21898
  {
21883
21899
  "type": "boolean"
@@ -22036,7 +22052,7 @@
22036
22052
  "additionalProperties": false,
22037
22053
  "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
22038
22054
  },
22039
- "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
22055
+ "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
22040
22056
  }
22041
22057
  },
22042
22058
  "required": [
@@ -22046,7 +22062,7 @@
22046
22062
  "additionalProperties": false,
22047
22063
  "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
22048
22064
  },
22049
- "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
22065
+ "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
22050
22066
  }
22051
22067
  },
22052
22068
  "required": [
@@ -22118,7 +22134,7 @@
22118
22134
  ]
22119
22135
  },
22120
22136
  "about_address": {
22121
- "description": "About address. Accepts null/undefined (→ Move Option::none). When provided, must be a raw 0x-prefixed address (NOT a name).",
22137
+ "description": "About binding (K3 contract): ONLY the counterparty ACCOUNT address (address first byte = account type) or a Proof object address (first byte = Proof type) — a messenger contact record. NEVER a business object (Progress/Order/Arb) and never a guard decision condition. Accepts null/undefined (→ Move Option::none). When provided, must be a raw 0x-prefixed address (NOT a name).",
22122
22138
  "anyOf": [
22123
22139
  {
22124
22140
  "type": "string",
@@ -22646,7 +22662,7 @@
22646
22662
  "description": "vecvecu8"
22647
22663
  }
22648
22664
  ],
22649
- "description": "User available value type (number or string, e.g., 6 or 'U64' or 'u64')"
22665
+ "description": "User available value type (number, numeric string, or name — e.g., 6, '6', 'U64', 'u64')"
22650
22666
  },
22651
22667
  {
22652
22668
  "type": "number",