@wowok/agent-mcp 3.3.9 → 3.4.1

package/dist/schemas/onchain_operations_allocation.schema.json

@@ -74,7 +74,7 @@
                     "properties": {
                       "guard": {
                         "type": "string",
-                        "description": "Guard object ID or name. A distribution call submits ONE guard; EVERY Allocator bound to that guard fires — in vector order, each against the balance left by the previous (allocation.move:366-368: the loop matches the submitted guard address, it does NOT evaluate guards competitively). NOT first-match-wins: Allocators with different guards are alternative distribution paths selected by the caller's choice of guard (e.g., a refund guard vs a damage guard), and mutual exclusion must be expressed inside the Guard conditions themselves, never assumed from ordering."
+                        "description": "Guard object ID or name. A distribution call submits ONE guard; EVERY Allocator bound to that guard fires — in vector order, each against the balance left by the previous (the distribution loop matches the submitted guard address, it does NOT evaluate guards competitively). NOT first-match-wins: Allocators with different guards are alternative distribution paths selected by the caller's choice of guard (e.g., a refund guard vs a damage guard), and mutual exclusion must be expressed inside the Guard conditions themselves, never assumed from ordering."
                       },
                       "sharing": {
                         "type": "array",
@@ -90,7 +90,7 @@
                                       "type": "integer",
                                       "minimum": 0,
                                       "maximum": 255,
-                                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
                                     }
                                   },
                                   "required": [
@@ -103,26 +103,34 @@
                                   "type": "object",
                                   "properties": {
                                     "Entity": {
-                                      "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)."
+                                      "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"
                                         },
-                                        "local_mark_first": {
-                                          "description": "Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks",
-                                          "type": "boolean"
+                                        {
+                                          "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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                                         }
-                                      },
-                                      "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": [
                                     "Entity"
                                   ],
                                   "additionalProperties": false,
-                                  "description": "Static address resolved via LocalMark. Format: {Entity: {name_or_address: 'mark_name'}} — NOTE: Entity is an OBJECT with name_or_address field, NOT a bare string."
+                                  "description": "Static address resolved via LocalMark. Format: {Entity: 'mark_name'} (string shorthand) or {Entity: {name_or_address: 'mark_name'}} (full object).F-RQ-11 (rq2 promotion): string shorthand accepted — the FIX-005 transform resolves local marks first."
                                 },
                                 {
                                   "type": "object",
@@ -698,7 +706,7 @@
                       "items": {
                         "type": "string"
                       },
-                      "description": "EXPLICIT candidate object IDs (vector<address>) to scan. Duplicates are deduped; max 100 candidates; an EMPTY list matches no records (scalar 0) — there is no 'all objects' wildcard."
+                      "description": "EXPLICIT candidate object IDs (vector<address>) to scan. Duplicates are deduped; max 100 candidates; an EMPTY list matches no records (scalar 0) — there is no 'all objects' wildcard. S12-③ witness boundary (v139): the 100-cap applies to THIS guard-table vector; the guard's inline WITNESS is separately capped at 4096 BCS bytes total (passport MAX_SUBMISSION_SIZE — a 100-address roster fits), so keep roster-style attestation here in the vector and reserve the witness for per-call attestation."
                     }
                   },
                   "required": [
@@ -729,6 +737,13 @@
       ],
       "description": "On-chain Allocation operations. USAGE: (1) CREATE NEW: Use CallAllocation_CreateSchema by setting 'object' with OBJECT format {name, type_parameter, ...}. (2) OPERATE EXISTING: Use CallAllocation_OperateSchema by setting 'object' with STRING format (object ID or name). The 'object' field is CRITICAL and REQUIRED in both cases. "
     },
+    "idempotency_key": {
+      "type": "string",
+      "minLength": 8,
+      "maxLength": 128,
+      "pattern": "^[A-Za-z0-9._:-]+$",
+      "description": "F-RQ-13A (prescription ⑨): idempotency key for this business attempt. REPLAY GUARD: if a previous call with the SAME key is still open (dispatched but outcome unresolved, or already committed), this call is HELD — you get a structured state_conflict envelope with the prior attempt's verification data instead of a second on-chain submission (the ghost-order guard: two live mainnet orders, two escrows). Lifecycle: a deterministic failure (nothing submitted / provably reverted) clears the key — fix the cause and retry with the SAME key; an unknown-outcome failure (submission may have landed) keeps the key HELD — verify on-chain state first (result.submission_verification tells you where to look), and only retry with a NEW key once the outcome is resolved. Keep one key per business attempt (e.g. 'ord-20261030-042-buy'); do not reuse across attempts."
+    },
     "env": {
       "type": "object",
       "properties": {
@@ -749,7 +764,7 @@
           "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.",
+          "description": "Omit in chat-client 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",
@@ -867,7 +882,7 @@
                       "type": "integer",
                       "minimum": 0,
                       "maximum": 255,
-                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
                     },
                     "b_submission": {
                       "type": "boolean",
@@ -1184,7 +1199,7 @@
                                 }
                               },
                               "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 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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                             },
                             {
                               "type": "string"
@@ -1209,6 +1224,7 @@
                               "type": "object",
                               "properties": {
                                 "entities": {
+                                  "minItems": 1,
                                   "type": "array",
                                   "items": {
                                     "type": "object",
@@ -1223,7 +1239,7 @@
                                       }
                                     },
                                     "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 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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                                   }
                                 },
                                 "check_all_founded": {

package/dist/schemas/onchain_operations_arbitration.schema.json

@@ -150,7 +150,7 @@
                   "additionalProperties": false
                 }
               ],
-              "description": "Dispute processing fee. FORMAT: {balance: <amount_in_smallest_unit>} — field name is 'balance' (NOT 'amount'). The token type and precision are determined by the Arbitration object's type_parameter (the generic type set when the Arbitration was created). For WOW (9 decimals): {balance: 50000000} = 0.05 WOW. For tokens with different decimals, adjust accordingly (e.g. USDC has 6 decimals, so {balance: 50000} = 0.05 USDC). docs#45: the fee does NOT return to the filer on a win — it stays in the Arbitration object and is withdrawable by the arbitrator."
+              "description": "Coin attached to the dispute filing. FORMAT: {balance: <amount_in_smallest_unit>} — field name is 'balance' (NOT 'amount'). The token type and precision are determined by the Arbitration object's type_parameter (the generic type set when the Arbitration was created). For WOW (9 decimals): {balance: 50000000} = 0.05 WOW. CHAIN MECHANISM (S14-F②, on dispute filing): the case escrows the ARBITRATION VENUE's configured fee (self.fee), NOT this amount — any residue above the venue fee is REFUNDED to the filer in the SAME transaction. If the venue fee is 0, the entire attached coin refunds and the case escrows nothing (the created Arb's fee reads '0'). To charge a real per-case fee, the VENUE must set it first: {operation_type:'arbitration', data:{object:'<venue>', fee:<amount>}} (arbitrator permission 357); filing then requires balance >= that fee (E_FEE_NOT_ENOUGH). ATTACHING MORE THAN THE VENUE FEE IS A NO-OP for the case — the excess comes straight back."
             },
             "namedArb": {
               "description": "RECOMMENDED: Set a local name for the newly created Arb (arbitration case) object. Without this, the Arb is only referenceable by its on-chain address. Example: {name: 'my_dispute_v1'} allows subsequent vote/feedback operations to use 'my_dispute_v1'.",
@@ -220,7 +220,7 @@
             },
             "voting_deadline": {
               "default": null,
-              "description": "Voting deadline as Unix timestamp in MILLISECONDS (ms). SEMANTICS OF SPECIAL VALUES: null (DEFAULT when omitted) = open-ended voting, no deadline; parties may vote at any time and the arbitrator may deliver the verdict after casting at least one ballot (arb.move skips the deadline assert when the Option is none) — this is the SAFE default; a future timestamp = normal bounded voting window (recommended: now + at least 86400000 ms = 24 hours); 0 = deadline already passed → the case PERMANENTLY DEADLOCKS (kl-real-261016 F-01, chain-verified): every vote aborts E_VOTING_DEADLINE_PASSED, so no ballot can ever exist, the verdict then aborts E_NO_VOTE_CAST (a verdict requires >= 1 cast ballot), and reset aborts as well. NEVER pass 0. Direct verdict = null + cast one ballot first, then deliver the verdict. COMMON MISTAKE: using seconds instead of milliseconds (multiply by 1000). Example: Date.now() + 259200000 for 3 days from now.",
+              "description": "Voting deadline as Unix timestamp in MILLISECONDS (ms). SEMANTICS OF SPECIAL VALUES: null (DEFAULT when omitted) = open-ended voting, no deadline; parties may vote at any time and the arbitrator may deliver the verdict after casting at least one ballot (the on-chain arbitration skips the deadline assert when the Option is none) — this is the SAFE default; a future timestamp = normal bounded voting window (recommended: now + at least 86400000 ms = 24 hours); 0 = deadline already passed → the case PERMANENTLY DEADLOCKS (kl-real-261016 F-01, chain-verified): every vote aborts E_VOTING_DEADLINE_PASSED, so no ballot can ever exist, the verdict then aborts E_NO_VOTE_CAST (a verdict requires >= 1 cast ballot), and reset aborts as well. NEVER pass 0. Direct verdict = null + cast one ballot first, then deliver the verdict. COMMON MISTAKE: using seconds instead of milliseconds (multiply by 1000). Example: Date.now() + 259200000 for 3 days from now.",
               "anyOf": [
                 {
                   "type": "integer",
@@ -283,7 +283,7 @@
               "description": "Proposition INDICES (0-based, u8) the voter agrees with — e.g. [0] votes for the first proposition. Re-voting REPLACES the voter's previous vote (old weight removed, new applied). Out-of-range index aborts with E_PROPOSITION_NOT_FOUND."
             },
             "voting_guard": {
-              "description": "Voting Guard for WEIGHTED voting. DECISION RULE (contract-enforced):\n(A) Arbitration HAS a non-empty voting_guard list → plain vote is REJECTED on-chain with E_VOTING_GUARD_USED (abort 2). You MUST provide this field set to ONE guard from the Arbitration's voting_guard list, and fill its submission: when the guard's vote_weight is {GuardIdentifier: pos}, the number you submit at that table position IS the vote weight; when it is {FixedValue: v}, no submission is needed (weight is fixed). The SDK then routes the call through the Guard-weighted vote path via a Passport. Omitting this field on such an Arbitration now fails fast pre-call with the list of valid guards.\n(B) Arbitration has NO voting_guard → omit this field; the SDK uses plain vote (weight 1, permission-gated), or the passport-gated vote path when other guards require it.\nBOTH (B) paths still assert ARBITRATION_VOTE=358 on-chain (the SDK now pre-checks 358 and fails fast with 'Missing permissions 358'). An empty voting_guard means EQUAL WEIGHT (1 person 1 vote), NOT permissionless — there is no permission-free vote entry. For genuinely open voting, configure a public voting_guard (op=\"set\") and vote via path (A): the weighted passport path authorizes by the guard and does NOT require 358.\nThe Guard (when provided) MUST be in the Arbitration's voting_guard list — an unlisted guard aborts with E_VOTING_GUARD_NOT_FOUND. WEIGHTED REVOTE RESIDUE (az3-mn-261013, arb.move:315-320 source comment): under weighted voting a re-vote is NOT clean — re-voting with a LARGER weight than the previous one aborts on underflow (re-vote DoS surface); re-voting with a SMALLER weight succeeds but leaves phantom votes behind. Treat the first weighted vote as final when possible.",
+              "description": "Voting Guard for WEIGHTED voting. DECISION RULE (contract-enforced):\n(A) Arbitration HAS a non-empty voting_guard list → plain vote is REJECTED on-chain with E_VOTING_GUARD_USED (abort 2). You MUST provide this field set to ONE guard from the Arbitration's voting_guard list, and fill its submission: when the guard's vote_weight is {GuardIdentifier: pos}, the number you submit at that table position IS the vote weight; when it is {FixedValue: v}, no submission is needed (weight is fixed). The SDK then routes the call through the Guard-weighted vote path via a Passport. Omitting this field on such an Arbitration now fails fast pre-call with the list of valid guards.\n(B) Arbitration has NO voting_guard → omit this field; the SDK uses plain vote (weight 1, permission-gated), or the passport-gated vote path when other guards require it.\nBOTH (B) paths still assert ARBITRATION_VOTE=358 on-chain (the SDK now pre-checks 358 and fails fast with 'Missing permissions 358'). An empty voting_guard means EQUAL WEIGHT (1 person 1 vote), NOT permissionless — there is no permission-free vote entry. For genuinely open voting, configure a public voting_guard (op=\"set\") and vote via path (A): the weighted passport path authorizes by the guard and does NOT require 358.\nThe Guard (when provided) MUST be in the Arbitration's voting_guard list — an unlisted guard aborts with E_VOTING_GUARD_NOT_FOUND. WEIGHTED REVOTE RESIDUE (az3-mn-261013): under weighted voting a re-vote is NOT clean — re-voting with a LARGER weight than the previous one aborts on underflow (re-vote DoS surface); re-voting with a SMALLER weight succeeds but leaves phantom votes behind. Treat the first weighted vote as final when possible.",
               "type": "string"
             }
           },
@@ -493,7 +493,7 @@
                                 "type": "integer",
                                 "minimum": 0,
                                 "maximum": 255,
-                                "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                                "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
                               }
                             },
                             "required": [
@@ -715,6 +715,13 @@
       "additionalProperties": false,
       "description": "On-chain Arbitration operations. TWO OBJECT KINDS — do not confuse them (§5.9): the ROOT 'object' field is the Arbitration (arbitrator REGISTRATION) object; the Arb (single CASE) created by 'dispute' is addressed via each case operation's 'arb' field. USAGE: (1) CREATE NEW: Set 'object' field with OBJECT format {name, type_parameter, permission, ...} to create an Arbitration. NOTE:'name' goes INSIDE 'object', NOT at the data root level. 'permission' can be a new Permission object or reference an existing one - check 'object' field description for details. ⚠️ PERMISSION RULE (contract-enforced): the Arbitration's permission MUST be DIFFERENT from the permission of any Service it will be bound to — binding an Arbitration that SHARES the Service's Permission aborts with E_ARBITRATION_PERMISSION_CONFLICT (error 33). Always create a DEDICATED Permission object for each Arbitration. (2) OPERATE EXISTING: Set 'object' field with STRING format (object ID or name). The 'object' field is CRITICAL and REQUIRED in both cases. STRING for existing, OBJECT for new creation."
     },
+    "idempotency_key": {
+      "type": "string",
+      "minLength": 8,
+      "maxLength": 128,
+      "pattern": "^[A-Za-z0-9._:-]+$",
+      "description": "F-RQ-13A (prescription ⑨): idempotency key for this business attempt. REPLAY GUARD: if a previous call with the SAME key is still open (dispatched but outcome unresolved, or already committed), this call is HELD — you get a structured state_conflict envelope with the prior attempt's verification data instead of a second on-chain submission (the ghost-order guard: two live mainnet orders, two escrows). Lifecycle: a deterministic failure (nothing submitted / provably reverted) clears the key — fix the cause and retry with the SAME key; an unknown-outcome failure (submission may have landed) keeps the key HELD — verify on-chain state first (result.submission_verification tells you where to look), and only retry with a NEW key once the outcome is resolved. Keep one key per business attempt (e.g. 'ord-20261030-042-buy'); do not reuse across attempts."
+    },
     "env": {
       "type": "object",
       "properties": {
@@ -735,7 +742,7 @@
           "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.",
+          "description": "Omit in chat-client 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",
@@ -853,7 +860,7 @@
                       "type": "integer",
                       "minimum": 0,
                       "maximum": 255,
-                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
                     },
                     "b_submission": {
                       "type": "boolean",
@@ -1170,7 +1177,7 @@
                                 }
                               },
                               "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 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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                             },
                             {
                               "type": "string"
@@ -1195,6 +1202,7 @@
                               "type": "object",
                               "properties": {
                                 "entities": {
+                                  "minItems": 1,
                                   "type": "array",
                                   "items": {
                                     "type": "object",
@@ -1209,7 +1217,7 @@
                                       }
                                     },
                                     "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 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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                                   }
                                 },
                                 "check_all_founded": {

package/dist/schemas/onchain_operations_contact.schema.json

@@ -348,6 +348,13 @@
       "additionalProperties": false,
       "description": "On-chain Contact operations. USAGE: (1) CREATE NEW: Set 'object' field with OBJECT format {name, permission, ...} to create a Contact. NOTE: 'name' goes INSIDE 'object', NOT at the data root level. 'permission' can be a new Permission object or reference an existing one - check 'object' field description for details. (2) OPERATE EXISTING: Set 'object' field with STRING format (object ID or name). The 'object' field is CRITICAL and REQUIRED in both cases. STRING for existing, OBJECT for new creation."
     },
+    "idempotency_key": {
+      "type": "string",
+      "minLength": 8,
+      "maxLength": 128,
+      "pattern": "^[A-Za-z0-9._:-]+$",
+      "description": "F-RQ-13A (prescription ⑨): idempotency key for this business attempt. REPLAY GUARD: if a previous call with the SAME key is still open (dispatched but outcome unresolved, or already committed), this call is HELD — you get a structured state_conflict envelope with the prior attempt's verification data instead of a second on-chain submission (the ghost-order guard: two live mainnet orders, two escrows). Lifecycle: a deterministic failure (nothing submitted / provably reverted) clears the key — fix the cause and retry with the SAME key; an unknown-outcome failure (submission may have landed) keeps the key HELD — verify on-chain state first (result.submission_verification tells you where to look), and only retry with a NEW key once the outcome is resolved. Keep one key per business attempt (e.g. 'ord-20261030-042-buy'); do not reuse across attempts."
+    },
     "env": {
       "type": "object",
       "properties": {
@@ -368,7 +375,7 @@
           "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.",
+          "description": "Omit in chat-client 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",
@@ -486,7 +493,7 @@
                       "type": "integer",
                       "minimum": 0,
                       "maximum": 255,
-                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
                     },
                     "b_submission": {
                       "type": "boolean",
@@ -803,7 +810,7 @@
                                 }
                               },
                               "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 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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                             },
                             {
                               "type": "string"
@@ -828,6 +835,7 @@
                               "type": "object",
                               "properties": {
                                 "entities": {
+                                  "minItems": 1,
                                   "type": "array",
                                   "items": {
                                     "type": "object",
@@ -842,7 +850,7 @@
                                       }
                                     },
                                     "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 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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                                   }
                                 },
                                 "check_all_founded": {

package/dist/schemas/onchain_operations_demand.schema.json

@@ -92,7 +92,7 @@
           "properties": {
             "recommend": {
               "type": "string",
-              "description": "Recommendation for the demand"
+              "description": "Recommendation for the demand. F-RQ-17 convention (structured quote lines): include machine-readable `key: value` lines so buyers can compare presents WITHOUT prose extraction — `quote: <amount> <token>` (e.g. \"quote: 5.8 WOW\"), `terms: <key conditions>` (cancellation/refund/deviations), `timing: <start/duration/deadline>`, `contact: <um or channel>`. One line per key, prose allowed around them. Parsers (panorama presenters, matching) read these lines first; missing lines force lossy extraction."
             },
             "by_guard": {
               "description": "Guard ID or name, used to select which Guard's verification to pass through",
@@ -193,18 +193,26 @@
             "type": "object",
             "properties": {
               "who": {
-                "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)."
+                "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"
                   },
-                  "local_mark_first": {
-                    "description": "Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks",
-                    "type": "boolean"
+                  {
+                    "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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                   }
-                },
-                "additionalProperties": false,
+                ],
                 "description": "Account address or mark name, used to identify providing feedback to this user"
               },
               "acceptance_score": {
@@ -250,7 +258,7 @@
                             "type": "integer",
                             "minimum": 0,
                             "maximum": 255,
-                            "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                            "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
                           },
                           {
                             "type": "null"
@@ -296,7 +304,7 @@
                             "type": "integer",
                             "minimum": 0,
                             "maximum": 255,
-                            "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                            "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
                           },
                           {
                             "type": "null"
@@ -498,6 +506,13 @@
       "additionalProperties": false,
       "description": "On-chain Demand operations. USAGE: (1) CREATE NEW: Set 'object' field with OBJECT format {name, permission, ...} to create a Demand. NOTE: 'name' goes INSIDE 'object', NOT at the data root level. 'permission' can be a new Permission object or reference an existing one - check 'object' field description for details. (2) OPERATE EXISTING: Set 'object' field with STRING format (object ID or name). The 'object' field is CRITICAL and REQUIRED in both cases. STRING for existing, OBJECT for new creation."
     },
+    "idempotency_key": {
+      "type": "string",
+      "minLength": 8,
+      "maxLength": 128,
+      "pattern": "^[A-Za-z0-9._:-]+$",
+      "description": "F-RQ-13A (prescription ⑨): idempotency key for this business attempt. REPLAY GUARD: if a previous call with the SAME key is still open (dispatched but outcome unresolved, or already committed), this call is HELD — you get a structured state_conflict envelope with the prior attempt's verification data instead of a second on-chain submission (the ghost-order guard: two live mainnet orders, two escrows). Lifecycle: a deterministic failure (nothing submitted / provably reverted) clears the key — fix the cause and retry with the SAME key; an unknown-outcome failure (submission may have landed) keeps the key HELD — verify on-chain state first (result.submission_verification tells you where to look), and only retry with a NEW key once the outcome is resolved. Keep one key per business attempt (e.g. 'ord-20261030-042-buy'); do not reuse across attempts."
+    },
     "env": {
       "type": "object",
       "properties": {
@@ -518,7 +533,7 @@
           "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.",
+          "description": "Omit in chat-client 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",
@@ -636,7 +651,7 @@
                       "type": "integer",
                       "minimum": 0,
                       "maximum": 255,
-                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
                     },
                     "b_submission": {
                       "type": "boolean",
@@ -953,7 +968,7 @@
                                 }
                               },
                               "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 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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                             },
                             {
                               "type": "string"
@@ -978,6 +993,7 @@
                               "type": "object",
                               "properties": {
                                 "entities": {
+                                  "minItems": 1,
                                   "type": "array",
                                   "items": {
                                     "type": "object",
@@ -992,7 +1008,7 @@
                                       }
                                     },
                                     "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 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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                                   }
                                 },
                                 "check_all_founded": {

package/dist/schemas/onchain_operations_gen_passport.schema.json

@@ -73,7 +73,7 @@
                       "type": "integer",
                       "minimum": 0,
                       "maximum": 255,
-                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                      "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
                     },
                     "b_submission": {
                       "type": "boolean",
@@ -390,7 +390,7 @@
                                 }
                               },
                               "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 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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                             },
                             {
                               "type": "string"
@@ -415,6 +415,7 @@
                               "type": "object",
                               "properties": {
                                 "entities": {
+                                  "minItems": 1,
                                   "type": "array",
                                   "items": {
                                     "type": "object",
@@ -429,7 +430,7 @@
                                       }
                                     },
                                     "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 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. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."
                                   }
                                 },
                                 "check_all_founded": {
@@ -549,6 +550,13 @@
       ],
       "additionalProperties": false
     },
+    "idempotency_key": {
+      "type": "string",
+      "minLength": 8,
+      "maxLength": 128,
+      "pattern": "^[A-Za-z0-9._:-]+$",
+      "description": "F-RQ-13A (prescription ⑨): idempotency key for this business attempt. REPLAY GUARD: if a previous call with the SAME key is still open (dispatched but outcome unresolved, or already committed), this call is HELD — you get a structured state_conflict envelope with the prior attempt's verification data instead of a second on-chain submission (the ghost-order guard: two live mainnet orders, two escrows). Lifecycle: a deterministic failure (nothing submitted / provably reverted) clears the key — fix the cause and retry with the SAME key; an unknown-outcome failure (submission may have landed) keeps the key HELD — verify on-chain state first (result.submission_verification tells you where to look), and only retry with a NEW key once the outcome is resolved. Keep one key per business attempt (e.g. 'ord-20261030-042-buy'); do not reuse across attempts."
+    },
     "env": {
       "type": "object",
       "properties": {
@@ -569,7 +577,7 @@
           "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.",
+          "description": "Omit in chat-client 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",

package/dist/schemas/onchain_operations_gen_proof.schema.json

@@ -86,7 +86,7 @@
           "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.",
+          "description": "Omit in chat-client 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",