@wowok/agent-mcp 2.7.7 → 2.7.10

package/dist/schemas/onchain_operations_machine.schema.json

@@ -371,7 +371,7 @@
                                 },
                                 "threshold": {
                                   "default": 0,
-                                  "description": "Threshold to trigger node advancement. If total Forward weight is greater than or equal to threshold, node advancement is triggered.",
+                                  "description": "Threshold to trigger node advancement. If total Forward weight is greater than or equal to threshold, node advancement is triggered. ⚠️ SINGLE-OPERATOR LOCK: each forward contributes its weight AT MOST ONCE (locked by its first operator — progress.move session_accomplish_imp; re-execution by others aborts E_NOT_THE_HOLDER). The maximum achievable weight of this Pair is the sum of its DISTINCT forward weights — if that sum < threshold the transition can NEVER migrate. Multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1), never one forward reused by several people.",
                                   "anyOf": [
                                     {
                                       "type": "number"
@@ -424,7 +424,7 @@
                                             "type": "string"
                                           }
                                         ],
-                                        "description": "Forward weight"
+                                        "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.",
@@ -547,7 +547,7 @@
                                 },
                                 "threshold": {
                                   "default": 0,
-                                  "description": "Threshold to trigger node advancement. If total Forward weight is greater than or equal to threshold, node advancement is triggered.",
+                                  "description": "Threshold to trigger node advancement. If total Forward weight is greater than or equal to threshold, node advancement is triggered. ⚠️ SINGLE-OPERATOR LOCK: each forward contributes its weight AT MOST ONCE (locked by its first operator — progress.move session_accomplish_imp; re-execution by others aborts E_NOT_THE_HOLDER). The maximum achievable weight of this Pair is the sum of its DISTINCT forward weights — if that sum < threshold the transition can NEVER migrate. Multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1), never one forward reused by several people.",
                                   "anyOf": [
                                     {
                                       "type": "number"
@@ -600,7 +600,7 @@
                                             "type": "string"
                                           }
                                         ],
-                                        "description": "Forward weight"
+                                        "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.",
@@ -883,7 +883,7 @@
                                       "type": "string"
                                     }
                                   ],
-                                  "description": "Forward weight"
+                                  "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.",
@@ -1048,7 +1048,7 @@
           "type": "boolean"
         },
         "owner_receive": {
-          "description": "Unwrap CoinWrapper objects and other objects received by this Machine object and send them to the owner of its Permission object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::sui::SUI>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::sui::SUI', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
+          "description": "Unwrap CoinWrapper objects and other objects received by this Machine object and send them to the owner of its Permission object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::wow::WOW>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
           "anyOf": [
             {
               "type": "array",
@@ -1097,7 +1097,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -1121,7 +1121,7 @@
                             "type": "string"
                           }
                         ],
-                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                       },
                       "payment": {
                         "type": "string",
@@ -1210,12 +1210,16 @@
             "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. Use project_operation action='clone_project_to_network' to clone the project blueprint to the target network, then re-run onchain_operations with env.network=target_network to deploy."
+          "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.",
+          "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).",
           "type": "string"
         },
+        "no_auto_register": {
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "type": "boolean"
+        },
         "confirmed": {
           "description": "Phase 2 ConfirmGate: set to true to proceed after a 'pending_confirmation' result. The operation is NOT executed until you re-call with confirmed=true after user consent.",
           "type": "boolean"
@@ -1227,8 +1231,8 @@
             "type": "string"
           }
         },
-        "project": {
-          "description": "Project prefix to assign this object to (e.g. 'myshop'). When set: 1) the object is tagged with 'project:<prefix>' on-chain automatically via ProjectService, 2) the newly created object is auto-associated to the SQLite project for local management, evaluation, and graph tracking. The project MUST exist (create via project_operation action='create_project' first). Use project_operation to manage projects.",
+        "plan_approval": {
+          "description": "K3 24 PlanApproval: id of a goal whose plan was approved via goal_operation action='approve'. When set: 1) the ConfirmGate treats fail-open rules (standard/none levels) as pre-approved for operations under this goal's plan; 2) after successful CREATION operations, the created objects are auto-registered into the goal (GoalRecord.objects + its TaskProcess manifest — ACT station 'execution registers'). Fail-closed levels (irreversible/publish/amount) still require per-operation confirmation with env.confirmed=true.",
           "type": "string"
         },
         "client_schema_version": {
@@ -1250,7 +1254,7 @@
         "schema_strict_mode"
       ],
       "additionalProperties": false,
-      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used."
+      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used. NOTE: by default the SDK auto-registers the sender in the global Entity table when absent (first business transaction; the account receives an owned Resource object). Set no_auto_register=true only on explicit user request."
     },
     "submission": {
       "type": "object",

package/dist/schemas/onchain_operations_order.schema.json

@@ -169,7 +169,7 @@
           "additionalProperties": false
         },
         "receive": {
-          "description": "Unwrap CoinWrapper objects or other objects received by the order and transfer them to the order owner. Consistent with `owner_receive` on other objects (arbitration/contact/demand/machine/permission/repository/reward/service/treasury).\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::sui::SUI>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::sui::SUI', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
+          "description": "Unwrap CoinWrapper objects or other objects received by the order and transfer them to the order owner. Consistent with `owner_receive` on other objects (arbitration/contact/demand/machine/permission/repository/reward/service/treasury).\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::wow::WOW>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
           "anyOf": [
             {
               "type": "array",
@@ -218,7 +218,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -242,7 +242,7 @@
                             "type": "string"
                           }
                         ],
-                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                       },
                       "payment": {
                         "type": "string",
@@ -334,12 +334,16 @@
             "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. Use project_operation action='clone_project_to_network' to clone the project blueprint to the target network, then re-run onchain_operations with env.network=target_network to deploy."
+          "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.",
+          "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).",
           "type": "string"
         },
+        "no_auto_register": {
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "type": "boolean"
+        },
         "confirmed": {
           "description": "Phase 2 ConfirmGate: set to true to proceed after a 'pending_confirmation' result. The operation is NOT executed until you re-call with confirmed=true after user consent.",
           "type": "boolean"
@@ -351,8 +355,8 @@
             "type": "string"
           }
         },
-        "project": {
-          "description": "Project prefix to assign this object to (e.g. 'myshop'). When set: 1) the object is tagged with 'project:<prefix>' on-chain automatically via ProjectService, 2) the newly created object is auto-associated to the SQLite project for local management, evaluation, and graph tracking. The project MUST exist (create via project_operation action='create_project' first). Use project_operation to manage projects.",
+        "plan_approval": {
+          "description": "K3 24 PlanApproval: id of a goal whose plan was approved via goal_operation action='approve'. When set: 1) the ConfirmGate treats fail-open rules (standard/none levels) as pre-approved for operations under this goal's plan; 2) after successful CREATION operations, the created objects are auto-registered into the goal (GoalRecord.objects + its TaskProcess manifest — ACT station 'execution registers'). Fail-closed levels (irreversible/publish/amount) still require per-operation confirmation with env.confirmed=true.",
           "type": "string"
         },
         "client_schema_version": {
@@ -374,7 +378,7 @@
         "schema_strict_mode"
       ],
       "additionalProperties": false,
-      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used."
+      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used. NOTE: by default the SDK auto-registers the sender in the global Entity table when absent (first business transaction; the account receives an owned Resource object). Set no_auto_register=true only on explicit user request."
     },
     "submission": {
       "type": "object",

package/dist/schemas/onchain_operations_payment.schema.json

@@ -82,7 +82,7 @@
                                 "type": "string"
                               }
                             ],
-                            "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                            "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                           }
                         },
                         "required": [
@@ -226,12 +226,16 @@
             "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. Use project_operation action='clone_project_to_network' to clone the project blueprint to the target network, then re-run onchain_operations with env.network=target_network to deploy."
+          "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.",
+          "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).",
           "type": "string"
         },
+        "no_auto_register": {
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "type": "boolean"
+        },
         "confirmed": {
           "description": "Phase 2 ConfirmGate: set to true to proceed after a 'pending_confirmation' result. The operation is NOT executed until you re-call with confirmed=true after user consent.",
           "type": "boolean"
@@ -243,8 +247,8 @@
             "type": "string"
           }
         },
-        "project": {
-          "description": "Project prefix to assign this object to (e.g. 'myshop'). When set: 1) the object is tagged with 'project:<prefix>' on-chain automatically via ProjectService, 2) the newly created object is auto-associated to the SQLite project for local management, evaluation, and graph tracking. The project MUST exist (create via project_operation action='create_project' first). Use project_operation to manage projects.",
+        "plan_approval": {
+          "description": "K3 24 PlanApproval: id of a goal whose plan was approved via goal_operation action='approve'. When set: 1) the ConfirmGate treats fail-open rules (standard/none levels) as pre-approved for operations under this goal's plan; 2) after successful CREATION operations, the created objects are auto-registered into the goal (GoalRecord.objects + its TaskProcess manifest — ACT station 'execution registers'). Fail-closed levels (irreversible/publish/amount) still require per-operation confirmation with env.confirmed=true.",
           "type": "string"
         },
         "client_schema_version": {
@@ -266,7 +270,7 @@
         "schema_strict_mode"
       ],
       "additionalProperties": false,
-      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used."
+      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used. NOTE: by default the SDK auto-registers the sender in the global Entity table when absent (first business transaction; the account receives an owned Resource object). Set no_auto_register=true only on explicit user request."
     }
   },
   "required": [

package/dist/schemas/onchain_operations_permission.schema.json

@@ -653,7 +653,7 @@
           "additionalProperties": false
         },
         "owner_receive": {
-          "description": "Unwrap CoinWrapper objects and other objects received by this Permission object and send them to the builder(owner).\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::sui::SUI>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::sui::SUI', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
+          "description": "Unwrap CoinWrapper objects and other objects received by this Permission object and send them to the builder(owner).\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::wow::WOW>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
           "anyOf": [
             {
               "type": "array",
@@ -702,7 +702,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -726,7 +726,7 @@
                             "type": "string"
                           }
                         ],
-                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                       },
                       "payment": {
                         "type": "string",
@@ -812,12 +812,16 @@
             "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. Use project_operation action='clone_project_to_network' to clone the project blueprint to the target network, then re-run onchain_operations with env.network=target_network to deploy."
+          "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.",
+          "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).",
           "type": "string"
         },
+        "no_auto_register": {
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "type": "boolean"
+        },
         "confirmed": {
           "description": "Phase 2 ConfirmGate: set to true to proceed after a 'pending_confirmation' result. The operation is NOT executed until you re-call with confirmed=true after user consent.",
           "type": "boolean"
@@ -829,8 +833,8 @@
             "type": "string"
           }
         },
-        "project": {
-          "description": "Project prefix to assign this object to (e.g. 'myshop'). When set: 1) the object is tagged with 'project:<prefix>' on-chain automatically via ProjectService, 2) the newly created object is auto-associated to the SQLite project for local management, evaluation, and graph tracking. The project MUST exist (create via project_operation action='create_project' first). Use project_operation to manage projects.",
+        "plan_approval": {
+          "description": "K3 24 PlanApproval: id of a goal whose plan was approved via goal_operation action='approve'. When set: 1) the ConfirmGate treats fail-open rules (standard/none levels) as pre-approved for operations under this goal's plan; 2) after successful CREATION operations, the created objects are auto-registered into the goal (GoalRecord.objects + its TaskProcess manifest — ACT station 'execution registers'). Fail-closed levels (irreversible/publish/amount) still require per-operation confirmation with env.confirmed=true.",
           "type": "string"
         },
         "client_schema_version": {
@@ -852,7 +856,7 @@
         "schema_strict_mode"
       ],
       "additionalProperties": false,
-      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used."
+      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used. NOTE: by default the SDK auto-registers the sender in the global Entity table when absent (first business transaction; the account receives an owned Resource object). Set no_auto_register=true only on explicit user request."
     }
   },
   "required": [

package/dist/schemas/onchain_operations_personal.schema.json

@@ -787,6 +787,44 @@
               "additionalProperties": false,
               "description": "PUBLIC REPUTATION VOTE: Dislike an address (0x...) or LocalMark name. Goes through registrar::dislike — toggles off if already disliked, auto-flips an existing like, and increments the target's PUBLIC aggregate dislike count. Same manual-tag caveat as 'like'."
             },
+            {
+              "type": "object",
+              "properties": {
+                "op": {
+                  "type": "string",
+                  "const": "favor"
+                },
+                "address": {
+                  "anyOf": [
+                    {
+                      "description": "Account name, address (0x...), or mark name. When using string format, local marks are searched first. EXAMPLE: 'alice' - searches local marks first, then global; EXAMPLE: '0x2...' (64 hex chars) - uses address directly; EXAMPLE: '' - uses the default local account"
+                    },
+                    {
+                      "type": "object",
+                      "properties": {
+                        "name_or_address": {
+                          "type": "string",
+                          "description": "Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."
+                        },
+                        "local_mark_first": {
+                          "description": "Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks",
+                          "type": "boolean"
+                        }
+                      },
+                      "additionalProperties": false,
+                      "description": "Account or address lookup object. Use this to specify which account to use for an operation. EXAMPLE: { name_or_address: 'testor2' } - looks up account by name; EXAMPLE: { name_or_address: '0x1234...' } - uses address directly; If name_or_address is empty string '', uses the default local account."
+                    }
+                  ],
+                  "description": "Account or address lookup. Can be a simple string (recommended for AI) or full object with explicit local_mark_first control. String form auto-converts to { name_or_address: <string>, local_mark_first: true }."
+                }
+              },
+              "required": [
+                "op",
+                "address"
+              ],
+              "additionalProperties": false,
+              "description": "PUBLIC REPUTATION VOTE: Favor (bookmark/star) an address (0x...) or LocalMark name. Goes through registrar::favor — toggles off if already favored, and increments the target's PUBLIC aggregate favor count (independent of like/dislike; queryable via query personal). Use for 'save this service/provider' style endorsements."
+            },
             {
               "type": "object",
               "properties": {
@@ -889,12 +927,16 @@
             "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. Use project_operation action='clone_project_to_network' to clone the project blueprint to the target network, then re-run onchain_operations with env.network=target_network to deploy."
+          "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.",
+          "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).",
           "type": "string"
         },
+        "no_auto_register": {
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "type": "boolean"
+        },
         "confirmed": {
           "description": "Phase 2 ConfirmGate: set to true to proceed after a 'pending_confirmation' result. The operation is NOT executed until you re-call with confirmed=true after user consent.",
           "type": "boolean"
@@ -906,8 +948,8 @@
             "type": "string"
           }
         },
-        "project": {
-          "description": "Project prefix to assign this object to (e.g. 'myshop'). When set: 1) the object is tagged with 'project:<prefix>' on-chain automatically via ProjectService, 2) the newly created object is auto-associated to the SQLite project for local management, evaluation, and graph tracking. The project MUST exist (create via project_operation action='create_project' first). Use project_operation to manage projects.",
+        "plan_approval": {
+          "description": "K3 24 PlanApproval: id of a goal whose plan was approved via goal_operation action='approve'. When set: 1) the ConfirmGate treats fail-open rules (standard/none levels) as pre-approved for operations under this goal's plan; 2) after successful CREATION operations, the created objects are auto-registered into the goal (GoalRecord.objects + its TaskProcess manifest — ACT station 'execution registers'). Fail-closed levels (irreversible/publish/amount) still require per-operation confirmation with env.confirmed=true.",
           "type": "string"
         },
         "client_schema_version": {
@@ -929,7 +971,7 @@
         "schema_strict_mode"
       ],
       "additionalProperties": false,
-      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used."
+      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used. NOTE: by default the SDK auto-registers the sender in the global Entity table when absent (first business transaction; the account receives an owned Resource object). Set no_auto_register=true only on explicit user request."
     }
   },
   "required": [

package/dist/schemas/onchain_operations_progress.schema.json

@@ -200,7 +200,7 @@
           "additionalProperties": false
         },
         "owner_receive": {
-          "description": "Unwrap CoinWrapper objects and other objects received by this Progress object and send them to the owner of the bound Machine's Permission object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::sui::SUI>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::sui::SUI', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
+          "description": "Unwrap CoinWrapper objects and other objects received by this Progress object and send them to the owner of the bound Machine's Permission object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::wow::WOW>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
           "anyOf": [
             {
               "type": "array",
@@ -249,7 +249,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -273,7 +273,7 @@
                             "type": "string"
                           }
                         ],
-                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05SUI\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is (loses precision above 2^53). PRECISION RULE: for values exceeding 2^53, ALWAYS use format (1) or (2) — JS numbers lose precision. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer. If multiple tokens share a symbol (ambiguity), specify the full type string in type_parameter. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                       },
                       "payment": {
                         "type": "string",
@@ -350,12 +350,16 @@
             "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. Use project_operation action='clone_project_to_network' to clone the project blueprint to the target network, then re-run onchain_operations with env.network=target_network to deploy."
+          "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.",
+          "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).",
           "type": "string"
         },
+        "no_auto_register": {
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "type": "boolean"
+        },
         "confirmed": {
           "description": "Phase 2 ConfirmGate: set to true to proceed after a 'pending_confirmation' result. The operation is NOT executed until you re-call with confirmed=true after user consent.",
           "type": "boolean"
@@ -367,8 +371,8 @@
             "type": "string"
           }
         },
-        "project": {
-          "description": "Project prefix to assign this object to (e.g. 'myshop'). When set: 1) the object is tagged with 'project:<prefix>' on-chain automatically via ProjectService, 2) the newly created object is auto-associated to the SQLite project for local management, evaluation, and graph tracking. The project MUST exist (create via project_operation action='create_project' first). Use project_operation to manage projects.",
+        "plan_approval": {
+          "description": "K3 24 PlanApproval: id of a goal whose plan was approved via goal_operation action='approve'. When set: 1) the ConfirmGate treats fail-open rules (standard/none levels) as pre-approved for operations under this goal's plan; 2) after successful CREATION operations, the created objects are auto-registered into the goal (GoalRecord.objects + its TaskProcess manifest — ACT station 'execution registers'). Fail-closed levels (irreversible/publish/amount) still require per-operation confirmation with env.confirmed=true.",
           "type": "string"
         },
         "client_schema_version": {
@@ -390,7 +394,7 @@
         "schema_strict_mode"
       ],
       "additionalProperties": false,
-      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used."
+      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used. NOTE: by default the SDK auto-registers the sender in the global Entity table when absent (first business transaction; the account receives an owned Resource object). Set no_auto_register=true only on explicit user request."
     },
     "submission": {
       "type": "object",

package/dist/schemas/onchain_operations_proof.schema.json

@@ -136,12 +136,16 @@
             "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. Use project_operation action='clone_project_to_network' to clone the project blueprint to the target network, then re-run onchain_operations with env.network=target_network to deploy."
+          "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.",
+          "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).",
           "type": "string"
         },
+        "no_auto_register": {
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "type": "boolean"
+        },
         "confirmed": {
           "description": "Phase 2 ConfirmGate: set to true to proceed after a 'pending_confirmation' result. The operation is NOT executed until you re-call with confirmed=true after user consent.",
           "type": "boolean"
@@ -153,8 +157,8 @@
             "type": "string"
           }
         },
-        "project": {
-          "description": "Project prefix to assign this object to (e.g. 'myshop'). When set: 1) the object is tagged with 'project:<prefix>' on-chain automatically via ProjectService, 2) the newly created object is auto-associated to the SQLite project for local management, evaluation, and graph tracking. The project MUST exist (create via project_operation action='create_project' first). Use project_operation to manage projects.",
+        "plan_approval": {
+          "description": "K3 24 PlanApproval: id of a goal whose plan was approved via goal_operation action='approve'. When set: 1) the ConfirmGate treats fail-open rules (standard/none levels) as pre-approved for operations under this goal's plan; 2) after successful CREATION operations, the created objects are auto-registered into the goal (GoalRecord.objects + its TaskProcess manifest — ACT station 'execution registers'). Fail-closed levels (irreversible/publish/amount) still require per-operation confirmation with env.confirmed=true.",
           "type": "string"
         },
         "client_schema_version": {
@@ -176,7 +180,7 @@
         "schema_strict_mode"
       ],
       "additionalProperties": false,
-      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used."
+      "description": "IMPORTANT: Execution environment includes: account for signing operations, network selection ([object Object]), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used. NOTE: by default the SDK auto-registers the sender in the global Entity table when absent (first business transaction; the account receives an owned Resource object). Set no_auto_register=true only on explicit user request."
     },
     "submission": {
       "type": "object",