@wowok/agent-mcp 3.0.5 → 3.0.6

package/dist/schemas/onchain_operations_gen_proof.schema.json

@@ -86,13 +86,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_guard.schema.json

@@ -2389,13 +2389,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_machine.schema.json

@@ -427,7 +427,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": [
@@ -439,7 +439,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",
@@ -603,7 +603,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": [
@@ -615,7 +615,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",
@@ -886,7 +886,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": [
@@ -898,7 +898,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",
@@ -1204,13 +1204,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_order.schema.json

@@ -328,13 +328,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_payment.schema.json

@@ -121,7 +121,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"
@@ -220,13 +220,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_permission.schema.json

@@ -806,13 +806,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_personal.schema.json

@@ -921,13 +921,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_progress.schema.json

@@ -344,13 +344,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_proof.schema.json

@@ -130,13 +130,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_repository.schema.json

@@ -971,13 +971,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_reward.schema.json

@@ -548,13 +548,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_service.schema.json

@@ -861,7 +861,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",
@@ -990,7 +990,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.",
@@ -1120,7 +1120,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"
@@ -1423,13 +1423,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_treasury.schema.json

@@ -232,7 +232,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"
@@ -371,7 +371,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"
@@ -904,13 +904,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_table_data.output.json

@@ -7698,7 +7698,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": [
@@ -7710,7 +7710,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",
@@ -8498,7 +8498,7 @@
                                     "additionalProperties": false,
                                     "description": "Guard submission"
                                   },
-                                  "description": "Used to define submitted data after Guard verification"
+                                  "description": "Values persisted into the Progress history when this forward was accomplished. PROVENANCE: when the Machine forward lists retained_submission identifiers, the Guard is STILL fully verified first — the forward cannot complete without a passing Guard result. After verification, exactly the caller's submissions for the listed identifiers are copied here as Guard-verified facts (see MachineForwardGuardSchema)."
                                 },
                                 "msg": {
                                   "type": "string",
@@ -9113,7 +9113,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9140,7 +9140,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9167,7 +9167,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9194,7 +9194,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9228,7 +9228,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "context_depth": {
               "description": "BFS recursion depth for dependency expansion in assemble_context (default 0 = no expansion). When >0, the assembly recursively queries objects referenced by the center objects (permission, guard, machine, service, repositories, etc.) up to the given depth, using the same address-field extraction rules as extractAddressFields. Each level issues one batched query_objects call (≤50 IDs per batch). Cycles are detected and skipped via a visited set. Discovered dependencies are returned in `dependencies` (edge metadata) and `dependency_objects` (full object states). Recommended: 1–2 for most use cases; 3+ may pull large subgraphs (use context_include to constrain).",
@@ -9271,7 +9271,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "reverse_order_amount": {
               "description": "Escrowed order amount (smallest-unit string) for reverse_map — included in the report summary as the concrete escrow mention.",
@@ -9368,7 +9368,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9413,7 +9413,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9458,7 +9458,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "account": {
               "description": "Scope the aggregation to ONE account address (the client's current account). Omit to aggregate across ALL local accounts.",
@@ -9493,7 +9493,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "account": {
               "description": "Scope to ONE account address (the client's current account). Omit to merge across ALL local accounts.",
@@ -9569,7 +9569,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "intent": {
               "description": "SEMANTIC exploration strategy (G3) — what this topology call is trying to establish. Deterministically shapes the edge whitelist, per-family depth caps and budget: full_map=complete structural map; order_health=order lifecycle+completion+disputes; fund_flow=payments+allocation waterfall+guard-gated splits; workflow=Machine node graphs+transitions+progress; counterparty=who is on the other side (buyer/seller/agents/operators); reputation=votes+arbitration record+contacts; permission=permission groups+bindings+entity tables; supply_chain=multi-leg allocation/sub-order settlement; arbitration=dispute cases+voters; demand_match=demand presenters+guards+rewards. When omitted, defaults come from the persona system (role default intents < account persona preference), then industry templates; every applied layer is reported in result.strategy.trace.",