@wowok/agent-mcp 3.0.5 → 3.0.6

package/dist/schemas/onchain_operations.schema.json

@@ -863,7 +863,7 @@
               }
             },
             "order_allocators": {
-              "description": "Order fund allocator. Max 100 allocators (MAX_ALLOCATOR_COUNT). Each allocator has a guard (first matching guard wins) and a sharing list. Set to null to clear. ⚠️ PERMANENTLY IMMUTABLE after publish: order_allocators can ONLY be set BEFORE publish=true (Move service.move:503: assert!(!self.bPublished, E_ALREADY_PUBLISHED)). After publish, the ONLY way to change allocation rules is to create a NEW Service object. There is NO pause+lock exception for order_allocators (unlike arbitrations/rewards which have time-lock removal). PRE-PUBLISH CHECKLIST: verify all guard names resolve, all sharing amounts are correct, threshold is set, and recipient types (Entity/Signer/GuardIdentifier) are intended before calling publish=true. GuardIdentifier sharing mode: {who: {GuardIdentifier: <u8>}, sharing: <rate>, mode: 'Rate'} — resolves recipient from Guard table submission at allocation time (e.g., refund to customer). MULTI-CALL ALLOCATION: Allocation.alloc() can be called MULTIPLE times (no consumed flag in contract). Use Amount mode (not Surplus) for recurring allocations — Surplus calls balance::withdraw_all which drains the balance. For monthly payment scenarios, create multiple Allocators with time-based Guards + Amount mode sharing items.",
+              "description": "Order fund allocator. Max 100 allocators (MAX_ALLOCATOR_COUNT). Each allocator has a guard (first matching guard wins) and a sharing list. Set to null to clear. ⚠️ PERMANENTLY IMMUTABLE after publish: order_allocators can ONLY be set BEFORE publish=true (Move service.move:503: assert!(!self.bPublished, E_ALREADY_PUBLISHED)). After publish, the ONLY way to change allocation rules is to create a NEW Service object. There is NO pause+lock exception for order_allocators (unlike arbitrations/rewards which have time-lock removal). PRE-PUBLISH CHECKLIST: verify all guard names resolve, all sharing amounts are correct, threshold is set, and recipient types (Entity/Signer/GuardIdentifier) are intended before calling publish=true. GuardIdentifier sharing mode: {who: {GuardIdentifier: <u8>}, sharing: <rate>, mode: 'Rate'} — resolves recipient from the Guard table submission at allocation time. Canonical order pattern: the recipient slot is the single submitted Order (constrained by the Guard — service binding, qualifying node, signer==order.owner); funds land at that order object and are receivable only by its owner (object receipt = owner receipt). Safety is determined by constraint sufficiency — run the recipient constraint audit before publish. Fixed recipients should use {who:{Entity:...}}; unbound Signer recipients are a CRITICAL theft risk. MULTI-CALL ALLOCATION: Allocation.alloc() can be called MULTIPLE times (no consumed flag in contract). Use Amount mode (not Surplus) for recurring allocations — Surplus calls balance::withdraw_all which drains the balance. For monthly payment scenarios, create multiple Allocators with time-based Guards + Amount mode sharing items.",
               "anyOf": [
                 {
                   "type": "object",
@@ -992,7 +992,7 @@
                               "additionalProperties": false,
                               "description": "Fund allocation item — one recipient's share of the Allocation balance. The `sharing` value's meaning depends on `mode` (see AllocationModeSchema). Multiple items in the same Allocator are evaluated together: Amount items first, Rate items second, Surplus last."
                             },
-                            "description": "Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate + Surplus) within the same Allocator. ALLOCATION ORDER: Amount items first (cached as fix) → Rate items (proportional to balance - fix) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); Amount sum must >= threshold (no Rate and no Surplus) and <= max (if max set)."
+                            "description": "Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate + Surplus) within the same Allocator. RECIPIENT SEMANTICS: the Guard constrains what each submission slot may be; a recipient's safety follows from the sufficiency of those constraints (run the recipient constraint audit). Canonical order pattern: recipient = the single submitted Order — funds land at that object and are receivable only by its owner. ALLOCATION ORDER: Amount items first (cached as fix) → Rate items (proportional to balance - fix) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); Amount sum must >= threshold (no Rate and no Surplus) and <= max (if max set)."
                           },
                           "fix": {
                             "description": "OUTPUT-ONLY (query result). Cached sum of all Amount-mode `sharing` values in this Allocator. Computed by the contract during `allocator_add` — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for Rate allocation.",
@@ -1122,7 +1122,7 @@
                   "type": "object",
                   "properties": {
                     "for_object": {
-                      "description": "Payment for a specific object ID",
+                      "description": "Object this distribution belongs to (e.g. the order for a per-order allocation, recorded at creation). Auditors can query it to see the distribution's business context.",
                       "anyOf": [
                         {
                           "type": "string"
@@ -1425,13 +1425,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -2443,7 +2443,7 @@
                                             "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it (progress.move session_accomplish_imp); a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
                                           },
                                           "guard": {
-                                            "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.",
+                                            "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.\nRETAINED_SUBMISSION: a non-empty retained_submission does NOT relax Guard verification — the forward's Guard is always validated first. The list only selects which of the caller's already-verified submissions are persisted into the Progress history (see the guard field above).",
                                             "anyOf": [
                                               {
                                                 "anyOf": [
@@ -2455,7 +2455,7 @@
                                                         "description": "Guard object name or address (string). Example: 'my_attendance_guard' or '0x1234...'"
                                                       },
                                                       "retained_submission": {
-                                                        "description": "Data submitted by user during Guard object verification",
+                                                        "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (passport::submissions_get) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
                                                         "anyOf": [
                                                           {
                                                             "type": "array",
@@ -2619,7 +2619,7 @@
                                             "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it (progress.move session_accomplish_imp); a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
                                           },
                                           "guard": {
-                                            "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.",
+                                            "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.\nRETAINED_SUBMISSION: a non-empty retained_submission does NOT relax Guard verification — the forward's Guard is always validated first. The list only selects which of the caller's already-verified submissions are persisted into the Progress history (see the guard field above).",
                                             "anyOf": [
                                               {
                                                 "anyOf": [
@@ -2631,7 +2631,7 @@
                                                         "description": "Guard object name or address (string). Example: 'my_attendance_guard' or '0x1234...'"
                                                       },
                                                       "retained_submission": {
-                                                        "description": "Data submitted by user during Guard object verification",
+                                                        "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (passport::submissions_get) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
                                                         "anyOf": [
                                                           {
                                                             "type": "array",
@@ -2902,7 +2902,7 @@
                                       "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it (progress.move session_accomplish_imp); a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
                                     },
                                     "guard": {
-                                      "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.",
+                                      "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.\nRETAINED_SUBMISSION: a non-empty retained_submission does NOT relax Guard verification — the forward's Guard is always validated first. The list only selects which of the caller's already-verified submissions are persisted into the Progress history (see the guard field above).",
                                       "anyOf": [
                                         {
                                           "anyOf": [
@@ -2914,7 +2914,7 @@
                                                   "description": "Guard object name or address (string). Example: 'my_attendance_guard' or '0x1234...'"
                                                 },
                                                 "retained_submission": {
-                                                  "description": "Data submitted by user during Guard object verification",
+                                                  "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (passport::submissions_get) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
                                                   "anyOf": [
                                                     {
                                                       "type": "array",
@@ -3220,13 +3220,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -4155,13 +4155,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -5717,13 +5717,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -7036,13 +7036,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -7990,13 +7990,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -8813,7 +8813,7 @@
                   "type": "object",
                   "properties": {
                     "for_object": {
-                      "description": "Payment for a specific object ID",
+                      "description": "Object this distribution belongs to (e.g. the order for a per-order allocation, recorded at creation). Auditors can query it to see the distribution's business context.",
                       "anyOf": [
                         {
                           "type": "string"
@@ -8952,7 +8952,7 @@
                   "type": "object",
                   "properties": {
                     "for_object": {
-                      "description": "Payment for a specific object ID",
+                      "description": "Object this distribution belongs to (e.g. the order for a per-order allocation, recorded at creation). Auditors can query it to see the distribution's business context.",
                       "anyOf": [
                         {
                           "type": "string"
@@ -9485,13 +9485,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -10624,13 +10624,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -11390,7 +11390,7 @@
                               "additionalProperties": false,
                               "description": "Fund allocation item — one recipient's share of the Allocation balance. The `sharing` value's meaning depends on `mode` (see AllocationModeSchema). Multiple items in the same Allocator are evaluated together: Amount items first, Rate items second, Surplus last."
                             },
-                            "description": "Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate + Surplus) within the same Allocator. ALLOCATION ORDER: Amount items first (cached as fix) → Rate items (proportional to balance - fix) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); Amount sum must >= threshold (no Rate and no Surplus) and <= max (if max set)."
+                            "description": "Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate + Surplus) within the same Allocator. RECIPIENT SEMANTICS: the Guard constrains what each submission slot may be; a recipient's safety follows from the sufficiency of those constraints (run the recipient constraint audit). Canonical order pattern: recipient = the single submitted Order — funds land at that object and are receivable only by its owner. ALLOCATION ORDER: Amount items first (cached as fix) → Rate items (proportional to balance - fix) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); Amount sum must >= threshold (no Rate and no Surplus) and <= max (if max set)."
                           },
                           "fix": {
                             "description": "OUTPUT-ONLY (query result). Cached sum of all Amount-mode `sharing` values in this Allocator. Computed by the contract during `allocator_add` — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for Rate allocation.",
@@ -11484,7 +11484,7 @@
                   "type": "object",
                   "properties": {
                     "for_object": {
-                      "description": "Payment for a specific object ID",
+                      "description": "Object this distribution belongs to (e.g. the order for a per-order allocation, recorded at creation). Auditors can query it to see the distribution's business context.",
                       "anyOf": [
                         {
                           "type": "string"
@@ -11629,7 +11629,7 @@
                   ]
                 },
                 "alloc_by_guard": {
-                  "description": "Verify the specified Guard and execute the corresponding fund allocation. POST-ALLOCATION CLAIM (required step): each recipient receives a CoinWrapper object (NOT spendable coins). Recipient address resolution (allocation.move): Entity recipients receive it at the Entity's address; Signer recipients receive it at the transaction sender's address; GuardIdentifier n recipients receive it at the ADDRESS SUBMITTED for identifier n in this call's submission (resolved via passport::submission_get) — conventionally the Order OBJECT address (escrow pattern), in which case the order owner claims it via operation_type='order' {object:'<order_id>', receive:'recently'}. Claim paths by holder: EOA wallet → operation_type='payment' RECEIVE mode {object:'<coinwrapper_id>', receive:true} (type_parameter optional, auto-derived from the CoinWrapper type); Order object → order receive; Treasury object → treasury receive. Find pending CoinWrappers via query_toolkit query_type='onchain_received'. Verify the distribution via the immutable Payment object created by this call (allocation.payment array).",
+                  "description": "Verify the specified Guard and execute the corresponding fund distribution. GENERIC SEMANTICS: an Allocation distributes whatever balance it holds — order funds, payroll, dividends, bounties. It defines no scenario-specific rule: eligibility (including issuer identity for standalone use, e.g. an org admin) and differentiation inputs are expressed as Guard constraints, all public and auditable. RECIPIENT RESOLUTION (allocation.move Recipient enum): Entity → fixed address; Signer → transaction sender; GuardIdentifier n → the address submitted for identifier n (passport::submission_get). ORDER PATTERN (canonical): the Guard table needs ONE submitted Order, constrained by the Guard (e.g. order.service == host service, progress at a qualifying node, signer == order.owner); that order submission IS the recipient slot. Whoever calls alloc, funds necessarily land at an Order OBJECT; delivered CoinWrappers are owned by the order and can be extracted only via order::owner_receive (&mut Order input, Sui ownership) — the coins then go to the order's current owner. Object receipt = owner receipt. POST-DISTRIBUTION CLAIM (required step): each recipient gets a CoinWrapper (not spendable coins) — EOA wallet → operation_type='payment' RECEIVE mode {object:'<coinwrapper_id>', receive:true}; Order object → operation_type='order' {object:'<order_id>', receive:'recently'}; Treasury object → treasury receive. Find pending CoinWrappers via query_toolkit query_type='onchain_received'; verify via the immutable Payment object (allocation.payment array). RISK: safety follows from the sufficiency of the Guard constraints, not the recipient form — analyze the recipient constraint audit before publish; structural residuals (unavoidable): permissionless alloc allows forced settlement timing, the submitted order is not bound to the settled allocation, and allocators/guards are immutable after publish.",
                   "type": "string"
                 }
               },
@@ -11662,13 +11662,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -13059,13 +13059,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -15515,13 +15515,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -16398,13 +16398,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -16586,7 +16586,7 @@
                   "type": "object",
                   "properties": {
                     "for_object": {
-                      "description": "Payment for a specific object ID",
+                      "description": "Object this distribution belongs to (e.g. the order for a per-order allocation, recorded at creation). Auditors can query it to see the distribution's business context.",
                       "anyOf": [
                         {
                           "type": "string"
@@ -16685,13 +16685,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -17265,13 +17265,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -18184,13 +18184,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -19342,13 +19342,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -19539,13 +19539,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",
@@ -20216,13 +20216,13 @@
               "type": "boolean"
             },
             "network": {
+              "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
               "type": "string",
               "enum": [
                 "localnet",
                 "testnet",
                 "mainnet"
-              ],
-              "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+              ]
             },
             "referrer": {
               "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",

package/dist/schemas/onchain_operations_allocation.schema.json

@@ -175,7 +175,7 @@
                           "additionalProperties": false,
                           "description": "Fund allocation item — one recipient's share of the Allocation balance. The `sharing` value's meaning depends on `mode` (see AllocationModeSchema). Multiple items in the same Allocator are evaluated together: Amount items first, Rate items second, Surplus last."
                         },
-                        "description": "Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate + Surplus) within the same Allocator. ALLOCATION ORDER: Amount items first (cached as fix) → Rate items (proportional to balance - fix) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); Amount sum must >= threshold (no Rate and no Surplus) and <= max (if max set)."
+                        "description": "Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate + Surplus) within the same Allocator. RECIPIENT SEMANTICS: the Guard constrains what each submission slot may be; a recipient's safety follows from the sufficiency of those constraints (run the recipient constraint audit). Canonical order pattern: recipient = the single submitted Order — funds land at that object and are receivable only by its owner. ALLOCATION ORDER: Amount items first (cached as fix) → Rate items (proportional to balance - fix) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); Amount sum must >= threshold (no Rate and no Surplus) and <= max (if max set)."
                       },
                       "fix": {
                         "description": "OUTPUT-ONLY (query result). Cached sum of all Amount-mode `sharing` values in this Allocator. Computed by the contract during `allocator_add` — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for Rate allocation.",
@@ -269,7 +269,7 @@
               "type": "object",
               "properties": {
                 "for_object": {
-                  "description": "Payment for a specific object ID",
+                  "description": "Object this distribution belongs to (e.g. the order for a per-order allocation, recorded at creation). Auditors can query it to see the distribution's business context.",
                   "anyOf": [
                     {
                       "type": "string"
@@ -414,7 +414,7 @@
               ]
             },
             "alloc_by_guard": {
-              "description": "Verify the specified Guard and execute the corresponding fund allocation. POST-ALLOCATION CLAIM (required step): each recipient receives a CoinWrapper object (NOT spendable coins). Recipient address resolution (allocation.move): Entity recipients receive it at the Entity's address; Signer recipients receive it at the transaction sender's address; GuardIdentifier n recipients receive it at the ADDRESS SUBMITTED for identifier n in this call's submission (resolved via passport::submission_get) — conventionally the Order OBJECT address (escrow pattern), in which case the order owner claims it via operation_type='order' {object:'<order_id>', receive:'recently'}. Claim paths by holder: EOA wallet → operation_type='payment' RECEIVE mode {object:'<coinwrapper_id>', receive:true} (type_parameter optional, auto-derived from the CoinWrapper type); Order object → order receive; Treasury object → treasury receive. Find pending CoinWrappers via query_toolkit query_type='onchain_received'. Verify the distribution via the immutable Payment object created by this call (allocation.payment array).",
+              "description": "Verify the specified Guard and execute the corresponding fund distribution. GENERIC SEMANTICS: an Allocation distributes whatever balance it holds — order funds, payroll, dividends, bounties. It defines no scenario-specific rule: eligibility (including issuer identity for standalone use, e.g. an org admin) and differentiation inputs are expressed as Guard constraints, all public and auditable. RECIPIENT RESOLUTION (allocation.move Recipient enum): Entity → fixed address; Signer → transaction sender; GuardIdentifier n → the address submitted for identifier n (passport::submission_get). ORDER PATTERN (canonical): the Guard table needs ONE submitted Order, constrained by the Guard (e.g. order.service == host service, progress at a qualifying node, signer == order.owner); that order submission IS the recipient slot. Whoever calls alloc, funds necessarily land at an Order OBJECT; delivered CoinWrappers are owned by the order and can be extracted only via order::owner_receive (&mut Order input, Sui ownership) — the coins then go to the order's current owner. Object receipt = owner receipt. POST-DISTRIBUTION CLAIM (required step): each recipient gets a CoinWrapper (not spendable coins) — EOA wallet → operation_type='payment' RECEIVE mode {object:'<coinwrapper_id>', receive:true}; Order object → operation_type='order' {object:'<order_id>', receive:'recently'}; Treasury object → treasury receive. Find pending CoinWrappers via query_toolkit query_type='onchain_received'; verify via the immutable Payment object (allocation.payment array). RISK: safety follows from the sufficiency of the Guard constraints, not the recipient form — analyze the recipient constraint audit before publish; structural residuals (unavoidable): permissionless alloc allows forced settlement timing, the submitted order is not bound to the settled allocation, and allocators/guards are immutable after publish.",
               "type": "string"
             }
           },
@@ -447,13 +447,13 @@
           "type": "boolean"
         },
         "network": {
+          "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
           "type": "string",
           "enum": [
             "localnet",
             "testnet",
             "mainnet"
-          ],
-          "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+          ]
         },
         "referrer": {
           "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",

package/dist/schemas/onchain_operations_arbitration.schema.json

@@ -728,13 +728,13 @@
           "type": "boolean"
         },
         "network": {
+          "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
           "type": "string",
           "enum": [
             "localnet",
             "testnet",
             "mainnet"
-          ],
-          "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+          ]
         },
         "referrer": {
           "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",

package/dist/schemas/onchain_operations_contact.schema.json

@@ -363,13 +363,13 @@
           "type": "boolean"
         },
         "network": {
+          "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
           "type": "string",
           "enum": [
             "localnet",
             "testnet",
             "mainnet"
-          ],
-          "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+          ]
         },
         "referrer": {
           "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",

package/dist/schemas/onchain_operations_demand.schema.json

@@ -513,13 +513,13 @@
           "type": "boolean"
         },
         "network": {
+          "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
           "type": "string",
           "enum": [
             "localnet",
             "testnet",
             "mainnet"
-          ],
-          "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+          ]
         },
         "referrer": {
           "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",

package/dist/schemas/onchain_operations_gen_passport.schema.json

@@ -567,13 +567,13 @@
           "type": "boolean"
         },
         "network": {
+          "description": "Omit in client/chat contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.",
           "type": "string",
           "enum": [
             "localnet",
             "testnet",
             "mainnet"
-          ],
-          "description": "Network entrypoint: Specifies which network the operation occurs on. FIX-010 cross-network note: LocalMark names are scoped per network (testnet marks are invisible on mainnet and vice versa). When migrating from testnet to mainnet, recreate all objects on mainnet and re-register LocalMark names with the SAME names to keep name-based references working across networks. Recreate all objects on the target network via onchain_operations with env.network=target_network, then re-register the LocalMark names."
+          ]
         },
         "referrer": {
           "description": "Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).",