@wowok/agent-mcp 3.2.6 → 3.2.9

package/dist/schemas/onchain_operations_service.schema.json

@@ -95,7 +95,7 @@
           "description": "Two ways to specify an object: (1) STRING - Reference an EXISTING object by name or ID; (2) OBJECT - CREATE a NEW object with full configuration including name, tags, description, token type for payments, and Permission-based access control. The object format is used when you need both token specification AND permission management."
         },
         "order_new": {
-          "description": "Create new order.",
+          "description": "Create new order. RETRY DISCIPLINE: the order creation is atomic on-chain but NOT in observability — a transport drop after submit leaves the commit state UNKNOWN, and a blind resubmit creates a second order with a second full escrow (live mainnet incident). On any failure/timeout, verify whether an order with this exact signature (service + buyer + items) already landed — via the in-flight marker in the failure envelope, the sender's recent on-chain objects, or onchain_events — and adopt it if present; resubmit only if confirmed absent.",
           "type": "object",
           "properties": {
             "buy": {
@@ -137,6 +137,7 @@
                   "description": "List of products or services to purchase"
                 },
                 "total_pay": {
+                  "description": "Actual payment amount. FORMAT: {balance: <amount_in_smallest_unit>} or {coin: <coin_object_id>}. The token type and precision are determined by the Service object's type_parameter (the generic type set when the Service was created). For WOW (9 decimals): {balance: 1000000000} = 1 WOW. OPTIONAL without a discount (M-K17): omit it and the handler derives the EXACT total Σ(sale price × quantity) from the Service's on-chain sales list and discloses the derived value — no transcription, no drift. REQUIRED when 'discount' is set (the discounted total depends on the coupon's live value: run query_toolkit query_type='service_quote' and pass total_pay.balance = the quoted final_total). An explicit value is always honored as-is. AMOUNT GATE (M-K11-a): a total that EXACTLY equals Σ published sale price × quantity (catalog-priced buy, in the Service's own payment coin — WOW or bridged USDT/USDC/ETH/BTC) bypasses the harness pre-sign amount gate; any other amount above the threshold is blocked until WOWOK_AMOUNT_THRESHOLD is raised after explicit user confirmation.",
                   "anyOf": [
                     {
                       "type": "object",
@@ -172,8 +173,7 @@
                       ],
                       "additionalProperties": false
                     }
-                  ],
-                  "description": "Actual payment amount. FORMAT: {balance: <amount_in_smallest_unit>} or {coin: <coin_object_id>}. The token type and precision are determined by the Service object's type_parameter (the generic type set when the Service was created). For WOW (9 decimals): {balance: 1000000000} = 1 WOW. "
+                  ]
                 },
                 "discount": {
                   "description": "Discount object ID or name",
@@ -189,8 +189,7 @@
                 }
               },
               "required": [
-                "items",
-                "total_pay"
+                "items"
               ],
               "additionalProperties": false
             },
@@ -229,7 +228,7 @@
               "additionalProperties": false
             },
             "order_required_info": {
-              "description": "Contact object ID or WTS Proof object, RECORDED on the Order as evidence that the order holder delivered the private information the Service declares in customer_required (e.g. phone/email/shipping_address). RECORD-ONLY, NOT ENFORCED: nothing on-chain reads this field — the purchase entry never requires it, and an order supplying none of the declared fields is still created. FLOW: the order holder sends the information to the Service's Contact (um) via end-to-end encrypted Messenger, then passes the Contact object ID or the generated WTS Proof here. To ENFORCE delivery on-chain, mount the pattern.required_info_evidence_gate Guard on the forward that hands over goods or funds, asserting order.required_info is some (presence-only — the recorded address value is never a guard condition; accepting the delivered information is the merchant's confirming forward).",
+              "description": "Contact object ID or WTS Proof object, RECORDED on the Order as evidence that the order holder delivered the private information the Service declares in customer_required (e.g. phone/email/shipping_address). RECORD-ONLY, NOT ENFORCED: nothing on-chain reads this field — the purchase entry never requires it, and an order supplying none of the declared fields is still created. FLOW: the order holder sends the information to the Service's Contact (um) via end-to-end encrypted Messenger, then passes the Contact object ID or the generated WTS Proof here. To ENFORCE delivery on-chain, mount the pattern.required_info_evidence_gate Guard on the forward that hands over goods or funds, asserting order.required_info is some (presence-only — the recorded address value is never a guard condition; accepting the delivered information is the merchant's confirming forward). ATTESTATION-ONLY: the recorded value is self-attested, has no on-chain readback, and MUST NOT be used as a gate condition. PER-ORDER BINDING: when the listing genuinely promises a per-order credential, use the dedicated controlled bind operation (order_required_info_bind) with a Proof whose about is THIS order and whose creator is the order holder — the chain verifies both at write time and rejects a mismatch without writing anything. The reuse model (one Contact Proof across orders) stays the default for this plain record field; pick per listing promise, not per habit.",
               "type": "string"
             },
             "transfer": {
@@ -741,7 +740,7 @@
           ]
         },
         "rewards": {
-          "description": "Service Reward object list. May share the Service's Permission (no conflict check — intentional: rewards are the provider's own incentive tool; only Arbitration requires a different Permission for neutrality).",
+          "description": "Service Reward object list. May share the Service's Permission (no conflict check — intentional: rewards are the provider's own incentive tool; only Arbitration requires a different Permission for neutrality). ⚠️ OP SEMANTICS (SDK translation, etm-mn-261013 E-06): op:'set' executes as clear + add — and reward clear is TIME-LOCKED after publish (E_LOCKED_TIME_NOT_ENOUGH = abort 24: requires pause + setting_lock_duration elapsed, default 30 days). BEFORE publish op:'set' is fine; AFTER publish attach rewards with op:'add' ONLY (add has no lock).",
           "anyOf": [
             {
               "type": "object",
@@ -811,7 +810,7 @@
           ]
         },
         "arbitrations": {
-          "description": "Service Arbitration object list. FORMAT: same as repositories — use the `objects` field name inside the operation data. Example: {arbitrations: {op: 'set', objects: [{name: 'my_arb_1'}, {name: 'my_arb_2'}]}}. NOTE: op:'add' is disabled on this surface (its success response can arrive unparseable and reads like a failure); ALWAYS pass the FULL list with op:'set'. Each item is a NameOrAddress (object ID or local mark name). ⚠️ PERMISSION RULE (contract-enforced): every Arbitration bound here MUST use a Permission object DIFFERENT from THIS Service's permission — binding an Arbitration that shares the Service's Permission aborts with E_ARBITRATION_PERMISSION_CONFLICT (error 33). Create a dedicated Permission for each Arbitration BEFORE binding. DESIGN RATIONALE (confirmed intentional): dispute resolution requires NEUTRALITY — an Arbitration controlled by the same Permission admins as the Service it judges would be a conflict of interest. ONLY Arbitration has this check: Reward and Treasury objects MAY share the Service's Permission (they are the provider's own tools).",
+          "description": "Service Arbitration object list. FORMAT: same as repositories — use the `objects` field name inside the operation data. Example: {arbitrations: {op: 'add', objects: [{name: 'my_arb_1'}]}}. Each item is a NameOrAddress (object ID or local mark name). ⚠️ OP SEMANTICS (SDK translation, etm-mn-261013 E-06 + crs P3-1): op:'add' appends and is the ONLY  unlocked path after publish (add has no publish assert, service.move). op:'set' executes as clear + add and REPLACES the entire allowlist (pass EVERY Arbitration that must remain bound) — clear is TIME-LOCKED after publish (E_LOCKED_TIME_NOT_ENOUGH = abort 24: requires pause + setting_lock_duration elapsed, default 30 days), so use op:'set' BEFORE publish only. (The 2026-10-08 op:'add' disable was lifted: the unparseable-success-response SDK bug it responded to is fixed — safeTextJson + big-int conversion.) ⚠️ PERMISSION RULE (contract-enforced): every Arbitration bound here MUST use a Permission object DIFFERENT from THIS Service's permission — binding an Arbitration that shares the Service's Permission aborts with E_ARBITRATION_PERMISSION_CONFLICT (error 33). Create a dedicated Permission for each Arbitration BEFORE binding. DESIGN RATIONALE (confirmed intentional): dispute resolution requires NEUTRALITY — an Arbitration controlled by the same Permission admins as the Service it judges would be a conflict of interest. ONLY Arbitration has this check: Reward and Treasury objects MAY share the Service's Permission (they are the provider's own tools).",
           "anyOf": [
             {
               "type": "object",
@@ -923,7 +922,7 @@
               "description": "Discount magnitude, meaning depends on discount_type. RATES (0): per-10000 off rate — 10 = 0.1% off, 1000 = 10% off, 10000 = 100% off; values above 10000 are rejected. FIXED (1): fixed deduction from the order total in the Service token's smallest units (e.g. 1000000000 = 1 WOW at 9 decimals)."
             },
             "benchmark": {
-              "description": "Minimum order total (in the Service token's smallest units) for the discount to apply — when set, the discount is applied only if the PRE-discount order total is GREATER THAN OR EQUAL TO this value. ✅ OMITTING this field (or passing null, or 0) means NO threshold — the discount applies UNCONDITIONALLY, and that is the common, correct case. This is the on-chain behaviour: benchmark_met = if (option::is_some(&discount.benchmark)) { total >= benchmark } else { true } (wow-framework sources/w/service.move:274-278, inside the discount-application step). ⚠️ SHARP EDGE when you DO set a threshold: a below-threshold order is NOT rejected — it completes at FULL price and the one-time coupon is still consumed and destroyed, so the buyer pays full price AND loses the coupon. Keep thresholds low enough that your typical basket clears them. If the order total is below the discounted price the payment aborts — pay the list price; the excess is returned as a new Coin.",
+              "description": "Minimum order total (in the Service token's smallest units) for the discount to apply — when set, the discount is applied only if the PRE-discount order total is GREATER THAN OR EQUAL TO this value. ✅ OMITTING this field (or passing null, or 0) means NO threshold — the discount applies UNCONDITIONALLY, and that is the common, correct case. This is the on-chain behaviour: benchmark_met = if (option::is_some(&discount.benchmark)) { total >= benchmark } else { true } (wow-framework sources/w/service.move:274-278, inside the discount-application step). ⚠️ SHARP EDGE when you DO set a threshold: an order below the threshold CANNOT use the coupon — attaching it at buy aborts (error 38: the transaction rolls back, nothing is paid, and the coupon is preserved); dropping it means the buyer pays FULL price and keeps the coupon for a future order. Keep thresholds low enough that your typical basket clears them. If the order total is below the discounted price the payment aborts — pay the list price; the excess is returned as a new Coin.",
               "anyOf": [
                 {
                   "type": "number"
@@ -934,9 +933,13 @@
               ]
             },
             "time_ms_start": {
-              "description": "Discount start time (milliseconds)",
+              "description": "Discount start time (milliseconds). ⚠️ A FUTURE start mints a coupon that is listed as usable but CANNOT be spent until the window opens (every spend aborts E_DISCOUNT_TIME_INVALID / buy code 35). Legitimate for scheduled campaigns — the mint carries a loud warning; do not distribute the coupon to recipients before the window opens.",
               "type": "number"
             },
+            "allow_zero_total": {
+              "description": "FREE-TIER ESCAPE HATCH (BKN-P2): a coupon that would drive the final total to 0 (MINUS value >= the cheapest SKU price, or RATES value 10000) is BLOCKED at issuance by default. Set true ONLY to declare a deliberate zero-price product: the issuance then proceeds with a disclosure that zero-total orders carry an empty escrow and NEVER trigger reward/incentive rails. Omit (default false) for normal discounts.",
+              "type": "boolean"
+            },
             "time_ms_end": {
               "type": "number",
               "description": "Discount end time (milliseconds)"
@@ -977,7 +980,7 @@
                 "check_all_founded"
               ],
               "additionalProperties": false,
-              "description": "Discount recipient"
+              "description": "Discount recipient. OBJECT FORM REQUIRED (T9 az3-mn-261013): a bare string is REJECTED here — pass {entities: [{name_or_address: '<account_name_or_0x_address>'}]} (example: {entities: [{name_or_address: 'buyer1'}]}). Total coupons delivered = count × number of recipients."
             },
             "transferable": {
               "type": "boolean",
@@ -1014,7 +1017,7 @@
                 "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)."
               },
-              "description": "Coupon object IDs or local names to transfer. You MUST own these Discount objects. Each coupon must have been minted with transferable:true — otherwise the chain aborts with E_DISCOUNT_NOT_TRANSFERABLE (semantic code service:10). Coupons stay single-use; the transfer does not change that. Max 1000 coupons per call (SDK limit MAX_DISCOUNT_COUNT_ONCE)."
+              "description": "Coupon object IDs or local names to transfer. You MUST own these Discount objects. Each coupon must have been minted with transferable:true — otherwise the chain aborts with E_DISCOUNT_NOT_TRANSFERABLE (semantic code service:10). Coupons stay single-use; the transfer does not change that. There is NO batch entry on-chain — each coupon is delivered by its own singleton call (fanned out automatically); prefer ONE coupon per transaction for coupon migrations (SDK cap MAX_DISCOUNT_COUNT_ONCE still applies)."
             },
             "recipient": {
               "type": "object",
@@ -1425,7 +1428,7 @@
           ]
         },
         "compensation_fund_add": {
-          "description": "Deposit funds into the Service compensation_fund. Used to pay indemnity when arbitration resolves in customer's favor. FORMAT: {balance: <amount_in_smallest_unit>} — the field name is 'balance' (NOT 'amount'). The token type and precision are determined by the Service object's type_parameter (the generic type set when the Service was created). For WOW (9 decimals): {balance: 1000000000} = 1 WOW. For tokens with different decimals, adjust accordingly (e.g. USDC has 6 decimals, so {balance: 1000000} = 1 USDC). REQUIRES: Permission index 315 (SERVICE_COMPENSATION_FUND_DEPOSIT) must be granted to the calling account first. COMMON MISTAKE: using {amount: ...} or {amount: ..., type: 'WOW'} — these will fail. The correct field is 'balance'.",
+          "description": "Deposit funds into the Service compensation_fund. Used to pay indemnity when arbitration resolves in customer's favor. FORMAT: {balance: <amount_in_smallest_unit>} — the field name is 'balance' (NOT 'amount'). The token type and precision are determined by the Service object's type_parameter (the generic type set when the Service was created). For WOW (9 decimals): {balance: 1000000000} = 1 WOW. For tokens with different decimals, adjust accordingly (e.g. USDC has 6 decimals, so {balance: 1000000} = 1 USDC). REQUIRES: Permission index 315 (SERVICE_COMPENSATION_FUND_DEPOSIT) for NON-ADMIN callers. The Permission owner and admin short-circuit every builtin index check (no grant needed); only non-admin callers must be granted 315 first. COMMON MISTAKE: using {amount: ...} or {amount: ..., type: 'WOW'} — these will fail. The correct field is 'balance'.",
           "anyOf": [
             {
               "type": "object",
@@ -1628,6 +1631,7 @@
           "description": "Unwrap CoinWrapper objects and other objects received by this Service object and send them to the owner of its Permission object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::wow::WOW>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
           "anyOf": [
             {
+              "minItems": 1,
               "type": "array",
               "items": {
                 "type": "object",
@@ -1784,7 +1788,7 @@
           "type": "boolean"
         },
         "publish": {
-          "description": "Whether to publish the Service. After publishing, customers can place orders. ⚠️ PRE-PUBLISH EVALUATION (mandatory, stop-node fund-exit coverage): service.allocators MUST cover EVERY stop node of the bound Machine — every node where an order can rest (terminal nodes AND waiting states: review windows, handovers, open disputes) needs BOTH a withdrawal (release) AND a refund allocation rule, and each mapping guard must be satisfiable in BOTH directions. An uncovered stop node strands escrowed funds permanently (order_allocators is L1-immutable). Review-gated release is a TIME VARIANT inside ONE exit guard ('reviewed OR unreviewed after T'), never parallel outgoing edges (race deadlock). See pattern.fund_flow_stop_node_coverage + rules R-M5-03 / R-M5-09. VERIFIED against Move source + SDK (4-level immutability matrix):\n  L1 — PERMANENTLY LOCKED after publish (assert!(!bPublished), no pause+lock exception):\n    • machine          (workflow template)\n    • order_allocators (fund distribution rules — full replacement locked; APPEND-ONLY additions remain possible via order_allocators_append, prefix/threshold frozen)\n  L2 — TIME-LOCKED after publish (unpublished-state check — requires pause + setting_lock_duration elapsed):\n    • arbitrations remove/clear (dispute resolution objects)\n    • rewards remove/clear       (reward objects)\n    • compensation_fund_withdraw (withdraw ALL funds)\n  L3 — REMAIN MUTABLE after publish (no SDK check, no Move check):\n    • arbitrations add, rewards add (no assert — can add after publish)\n    • buy_guard, sales, discount, description, location, pause, repositories,\n    • compensation_fund_add, setting_lock_duration_add, customer_required, um (Contact)\nThese 2 L1-LOCKED fields (machine/order_allocators) MUST be set BEFORE publish=true.\narbitrations/rewards can be ADDED after publish but remove/clear requires pause+lock.\n\n⚠️ COMPENSATION_FUND + ARBITRATION LINKAGE:\n  At publish time, if compensation_fund > 0, Arbitration MUST be bound:\n    if (balance::value(&self.compensation_fund) > 0) {\n        assert!(arbitration_count > 0, E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND);\n    }\n  The MCP handler enforces this as a HARD PRE-CHECK: if publish=true AND compensation_fund_add   is set in the same call AND arbitrations is empty, the call is REJECTED before submission.   If compensation_fund was deposited in a prior call, a SOFT WARNING is issued.\n\nSCHEMA-03 / P0-01 fix — DEPLOYMENT WORKFLOW (two-phase, avoids circular dependency):\n  Phase 1 — CREATE (no publish): object={name:'my-service', type_parameter, permission} + machine + order_allocators + arbitrations.\n    NOTE: buy_guard can use a LocalMark NAME (not address) to break the Guard→Service circular dependency.\n    The name is resolved to an address at transaction build time.\n  Phase 2 — PUBLISH: object='my-service' (string ref) + publish=true.\n    All L1-LOCKED fields must be set in Phase 1; Phase 2 only flips the publish flag.\n  Post-publish updates: buy_guard, sales, description, repositories (add), rewards (add), arbitrations (add), etc.",
+          "description": "Whether to publish the Service. After publishing, customers can place orders. ⚠️ PRE-PUBLISH EVALUATION (mandatory, stop-node fund-exit coverage): service.allocators MUST cover EVERY stop node of the bound Machine — every node where an order can rest (terminal nodes AND waiting states: review windows, handovers, open disputes) needs BOTH a withdrawal (release) AND a refund allocation rule, and each mapping guard must be satisfiable in BOTH directions. An uncovered stop node strands escrowed funds permanently (order_allocators is L1-immutable). Review-gated release is a TIME VARIANT inside ONE exit guard ('reviewed OR unreviewed after T'), never parallel outgoing edges (race deadlock). See pattern.fund_flow_stop_node_coverage + rules R-M5-03 / R-M5-09. VERIFIED against Move source + SDK (4-level immutability matrix):\n  L1 — PERMANENTLY LOCKED after publish (assert!(!bPublished), no pause+lock exception):\n    • machine          (workflow template)\n    • order_allocators (fund distribution rules — full replacement locked; APPEND-ONLY additions remain possible via order_allocators_append, prefix/threshold frozen)\n  L2 — TIME-LOCKED after publish (unpublished-state check — requires pause + setting_lock_duration elapsed):\n    • arbitrations remove/clear (dispute resolution objects)\n    • rewards remove/clear       (reward objects)\n    • compensation_fund_withdraw (withdraw ALL funds)\n    RATIONALE (deliberate design, NOT a defect): these three REVOKE buyer-facing guarantees that placed orders already rely on — the lock protects buyer expectations. Daily operations (sales add/remove, price, stock, description) are NEVER gated by this lock.\n  L3 — REMAIN MUTABLE after publish (no SDK check, no Move check):\n    • arbitrations add, rewards add (no assert — can add after publish)\n    • buy_guard, sales, discount, description, location, pause, repositories,\n    • compensation_fund_add, setting_lock_duration_add, customer_required, um (Contact)\nThese 2 L1-LOCKED fields (machine/order_allocators) MUST be set BEFORE publish=true.\narbitrations/rewards can be ADDED after publish but remove/clear requires pause+lock.\n\n⚠️ COMPENSATION_FUND + ARBITRATION LINKAGE:\n  At publish time, if compensation_fund > 0, Arbitration MUST be bound:\n    if (balance::value(&self.compensation_fund) > 0) {\n        assert!(arbitration_count > 0, E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND);\n    }\n  The MCP handler enforces this as a HARD PRE-CHECK: if publish=true AND compensation_fund_add   is set in the same call AND arbitrations is empty, the call is REJECTED before submission.   If compensation_fund was deposited in a prior call, a SOFT WARNING is issued.\n\nSCHEMA-03 / P0-01 fix — DEPLOYMENT WORKFLOW (two-phase, avoids circular dependency):\n  Phase 1 — CREATE (no publish): object={name:'my-service', type_parameter, permission} + machine + order_allocators + arbitrations.\n    NOTE: buy_guard can use a LocalMark NAME (not address) to break the Guard→Service circular dependency.\n    The name is resolved to an address at transaction build time.\n  Phase 2 — PUBLISH: object='my-service' (string ref) + publish=true.\n    All L1-LOCKED fields must be set in Phase 1; Phase 2 only flips the publish flag.\n  Post-publish updates: buy_guard, sales, description, repositories (add), rewards (add), arbitrations (add), etc.",
           "type": "boolean"
         }
       },
@@ -1939,6 +1943,7 @@
                       "description": "Whether this table item's value is submitted dynamically at Guard trigger time (alloc_by_guard call). \n\ntrue = value is submitted by the caller when triggering the Guard. Use for runtime-context-dependent values like order address, user address. The 'value' field is ignored when b_submission=true; the caller must provide it via submissions[]. \n\nfalse = value is static, set at Guard creation time. Use for values known when the Guard is created: expected node names, expected merchant address, expected service address. The 'value' field must be populated and will be stored on-chain permanently. \n\nRule of thumb: if the value is the SAME for all future Guard triggers, use false. If the value DIFFERS per trigger (e.g., which order to release funds for), use true."
                     },
                     "value_type": {
+                      "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
                       "anyOf": [
                         {
                           "type": "number",
@@ -2225,11 +2230,10 @@
                           "const": "vecvecu8",
                           "description": "vecvecu8"
                         }
-                      ],
-                      "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
+                      ]
                     },
                     "value": {
-                      "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
+                      "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
                       "anyOf": [
                         {
                           "type": "boolean"
@@ -2388,7 +2392,7 @@
                   "additionalProperties": false,
                   "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
                 },
-                "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
+                "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
               }
             },
             "required": [
@@ -2398,7 +2402,7 @@
             "additionalProperties": false,
             "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
           },
-          "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
+          "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
         }
       },
       "required": [

package/dist/schemas/onchain_operations_treasury.schema.json

@@ -751,6 +751,7 @@
           "description": "Unwrap CoinWrapper objects and other objects received by this Treasury object and send them to the owner of its Permission object.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received objects.\n  Use this for the common case: \"withdraw everything the object has received.\"\n  Example: receive: 'recently'\n• ReceivedNormal[] (array) — explicit list of received objects to unwrap.\n  Use this when you want to receive specific objects only (not all).\n  Example: receive: [{id: '0xobj1', type: '0x2::coin::Coin<0x2::wow::WOW>'}]\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a balance record from a specific Payment/payer.\n  Use this for precise balance targeting (advanced — usually after querying\n  the object's received history via query_received).\n  Example: receive: {token_type: '0x2::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.",
           "anyOf": [
             {
+              "minItems": 1,
               "type": "array",
               "items": {
                 "type": "object",
@@ -1029,6 +1030,7 @@
                       "description": "Whether this table item's value is submitted dynamically at Guard trigger time (alloc_by_guard call). \n\ntrue = value is submitted by the caller when triggering the Guard. Use for runtime-context-dependent values like order address, user address. The 'value' field is ignored when b_submission=true; the caller must provide it via submissions[]. \n\nfalse = value is static, set at Guard creation time. Use for values known when the Guard is created: expected node names, expected merchant address, expected service address. The 'value' field must be populated and will be stored on-chain permanently. \n\nRule of thumb: if the value is the SAME for all future Guard triggers, use false. If the value DIFFERS per trigger (e.g., which order to release funds for), use true."
                     },
                     "value_type": {
+                      "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.",
                       "anyOf": [
                         {
                           "type": "number",
@@ -1315,11 +1317,10 @@
                           "const": "vecvecu8",
                           "description": "vecvecu8"
                         }
-                      ],
-                      "description": "Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details."
+                      ]
                     },
                     "value": {
-                      "description": "The actual value data. Format depends on `value_type`:\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
+                      "description": "The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).",
                       "anyOf": [
                         {
                           "type": "boolean"
@@ -1478,7 +1479,7 @@
                   "additionalProperties": false,
                   "description": "Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"
                 },
-                "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}]"
+                "description": "User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."
               }
             },
             "required": [
@@ -1488,7 +1489,7 @@
             "additionalProperties": false,
             "description": "One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."
           },
-          "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
+          "description": "User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"
         }
       },
       "required": [

package/dist/schemas/onchain_table_data.output.json

@@ -653,7 +653,7 @@
                                       "description": "vecvecu8"
                                     }
                                   ],
-                                  "description": "User available value type (number or string, e.g., 6 or 'U64' or 'u64')"
+                                  "description": "User available value type (number, numeric string, or name — e.g., 6, '6', 'U64', 'u64')"
                                 },
                                 {
                                   "type": "number",
@@ -1642,7 +1642,7 @@
                                         "description": "vecvecu8"
                                       }
                                     ],
-                                    "description": "User available value type (number or string, e.g., 6 or 'U64' or 'u64')"
+                                    "description": "User available value type (number, numeric string, or name — e.g., 6, '6', 'U64', 'u64')"
                                   },
                                   {
                                     "type": "number",
@@ -2904,7 +2904,7 @@
                         "type": "null"
                       }
                     ],
-                    "description": "Buyer-recorded credential (order.required_info): the merchant's IM user address resolved from the Service's Contact (zero cost) or an on-chain WTS Proof object id (embeds the IM address + last-message timestamp); null when not submitted"
+                    "description": "Buyer-recorded credential (order.required_info): the merchant's IM user address resolved from the Service's Contact (zero cost) or an on-chain WTS Proof object id (embeds the IM address + last-message timestamp); null when not submitted. ATTESTATION-ONLY: the value is self-attested by the buyer, has no on-chain readback, and MUST NOT be used as a gate condition."
                   },
                   "progress_next": {
                     "anyOf": [
@@ -4259,7 +4259,7 @@
                                             "description": "vecvecu8"
                                           }
                                         ],
-                                        "description": "User available value type (number or string, e.g., 6 or 'U64' or 'u64')"
+                                        "description": "User available value type (number, numeric string, or name — e.g., 6, '6', 'U64', 'u64')"
                                       },
                                       {
                                         "type": "number",
@@ -8297,7 +8297,7 @@
                                                     "description": "vecvecu8"
                                                   }
                                                 ],
-                                                "description": "User available value type (number or string, e.g., 6 or 'U64' or 'u64')"
+                                                "description": "User available value type (number, numeric string, or name — e.g., 6, '6', 'U64', 'u64')"
                                               },
                                               {
                                                 "type": "number",
@@ -9053,7 +9053,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9116,7 +9116,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9124,7 +9124,7 @@
             "service_address"
           ],
           "additionalProperties": false,
-          "description": "READ-ONLY pre-purchase quote of a Service (finding 3.6 — order_new total_pay pre-check): per-item unit price × quantity, the basket total that order_new.buy.total_pay.balance must exactly equal (the on-chain buy aborts on any drift), and the order_allocators fee-split preview (sharing rows of the FIRST allocator — the normal payout path; guards select per-case allocators such as refund/damage, so the live split depends on which guard passes). Mirrors the on-chain price×quantity semantics WITHOUT calling quote on-chain and NEVER submits a transaction. Amounts are payment-token smallest units plus a human display when the token precision resolves."
+          "description": "READ-ONLY pre-purchase quote of a Service (finding 3.6 — order_new total_pay pre-check): per-item unit price × quantity, the basket total that order_new.buy.total_pay.balance must exactly equal (the on-chain buy aborts on any drift), and the order_allocators fee-split preview (sharing rows of the FIRST allocator — the normal payout path; guards select per-case allocators such as refund/damage, so the live split depends on which guard passes). Also previews the reward terms of every Reward hung on the Service (pool balance, per-claim amount, claim window) so a buyer never budgets on an expired or unfunded reward. Mirrors the on-chain price×quantity semantics WITHOUT calling quote on-chain and NEVER submits a transaction. Amounts are payment-token smallest units plus a human display when the token precision resolves."
         },
         {
           "type": "object",
@@ -9144,7 +9144,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9179,14 +9179,14 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
             "query_type"
           ],
           "additionalProperties": false,
-          "description": "ONE-CALL detail-page panorama for Progress / Demand / Order / Arb / Repository / Proof objects (client panorama family): discriminated `object_type` + head (name/tags/description) + the object's own typed fields + type-specific extras (Demand presenters from the GLOBAL tx table, Progress session/forwards, Arb votes & propositions, Repository policies, Proof anchored root + WTS cross-check). Read-only."
+          "description": "ONE-CALL detail-page panorama for Progress / Demand / Order / Allocation / Arb / Repository / Proof objects (client panorama family): discriminated `object_type` + head (name/tags/description) + the object's own typed fields + type-specific extras (Demand presenters from the GLOBAL tx table, Progress session/forwards, Order fund state, Allocation pool balance + per-rail resolved recipients + Payment children, Arb votes & propositions, Repository policies, Proof anchored root + WTS cross-check). Read-only."
         },
         {
           "type": "object",
@@ -9206,7 +9206,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9240,7 +9240,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "context_depth": {
               "description": "BFS recursion depth for dependency expansion in assemble_context (default 0 = no expansion). When >0, the assembly recursively queries objects referenced by the center objects (permission, guard, machine, service, repositories, etc.) up to the given depth, using the same address-field extraction rules as extractAddressFields. Each level issues one batched query_objects call (≤50 IDs per batch). Cycles are detected and skipped via a visited set. Discovered dependencies are returned in `dependencies` (edge metadata) and `dependency_objects` (full object states). Recommended: 1–2 for most use cases; 3+ may pull large subgraphs (use context_include to constrain).",
@@ -9283,7 +9283,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "reverse_order_amount": {
               "description": "Escrowed order amount (smallest-unit string) for reverse_map — included in the report summary as the concrete escrow mention.",
@@ -9334,6 +9334,30 @@
               "description": "Attach order-monitor alerts (progress stall / compensation fund / review & arbitration windows) to each per-order result. Default true.",
               "type": "boolean"
             },
+            "radar_review_summary": {
+              "description": "Merchant-side review coverage summary (REVIEW-COMPONENT-PLAN batch 4): completed orders vs orders with a structured review record. Review rows live in a caller-named Repository — gather both counts via onchain_table_data (repository rows under the 'review' key, id_from=Signer → one row per buyer) and pass them in; the radar derives the merchant-side review-rate hint (high missing rate with a reward attached → reward lapsed or window too short). Omit when no review repository is bound.",
+              "type": "object",
+              "properties": {
+                "orders_completed": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 9007199254740991
+                },
+                "reviews_written": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 9007199254740991
+                },
+                "reward_bound": {
+                  "type": "boolean"
+                }
+              },
+              "required": [
+                "orders_completed",
+                "reviews_written"
+              ],
+              "additionalProperties": false
+            },
             "radar_monitor_thresholds": {
               "description": "Optional per-call overrides for order-monitor alert thresholds (only used when radar_include_alerts is on). All fields optional; omitted fields keep defaults. Units: hours/days as marked per field.",
               "type": "object",
@@ -9380,7 +9404,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9425,7 +9449,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9470,7 +9494,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "account": {
               "description": "Scope the aggregation to ONE account address (the client's current account). Omit to aggregate across ALL local accounts.",
@@ -9505,7 +9529,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "account": {
               "description": "Scope to ONE account address (the client's current account). Omit to merge across ALL local accounts.",
@@ -9581,7 +9605,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query — equivalent to the `network` parameter (prefer `network`). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query — THIS field is `context_network` (the query tools accept no separate `network` key). Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "intent": {
               "description": "SEMANTIC exploration strategy (G3) — what this topology call is trying to establish. Deterministically shapes the edge whitelist, per-family depth caps and budget: full_map=complete structural map; order_health=order lifecycle+completion+disputes; fund_flow=payments+allocation waterfall+guard-gated splits; workflow=Machine node graphs+transitions+progress; counterparty=who is on the other side (buyer/seller/agents/operators); reputation=votes+arbitration record+contacts; permission=permission groups+bindings+entity tables; supply_chain=multi-leg allocation/sub-order settlement; arbitration=dispute cases+voters; demand_match=demand presenters+guards+rewards. When omitted, defaults come from the persona system (role default intents < account persona preference), then industry templates; every applied layer is reported in result.strategy.trace.",
@@ -11038,6 +11062,50 @@
             "current_node"
           ],
           "additionalProperties": false
+        },
+        "review_steps": {
+          "description": "Composite review submission report: the structured-reputation repository write (+ optional reward claim) chained after a successful progress forward via the data.review block, each reusing the forward's passport submission. Fail-isolated — a failed step never rolled back the forward. Relay failed steps to the user with the retry path (dedicated repository/reward tools).",
+          "type": "array",
+          "items": {
+            "type": "object",
+            "properties": {
+              "step": {
+                "type": "string",
+                "enum": [
+                  "repository_write",
+                  "reward_claim"
+                ],
+                "description": "Which chained review step this report describes. repository_write = structured reputation record (rating/tags) into the caller-named Repository; reward_claim = incentive claim on the caller-named Reward."
+              },
+              "status": {
+                "type": "string",
+                "enum": [
+                  "success",
+                  "failed"
+                ],
+                "description": "Step outcome. Steps are fail-isolated: a failed step never affects the forward or the other step (on-chain has no rollback)."
+              },
+              "detail": {
+                "type": "string",
+                "description": "On success: what was written/claimed (payload summary). On failure: what the step attempted."
+              },
+              "digest": {
+                "description": "Transaction digest when the step succeeded.",
+                "type": "string"
+              },
+              "error": {
+                "description": "Error message when the step failed. Retry via the dedicated repository/reward tools with the same submission values.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "step",
+              "status",
+              "detail"
+            ],
+            "additionalProperties": false,
+            "description": "One fail-isolated chained step of the progress composite review submission (REVIEW component, data.review block)."
+          }
         }
       },
       "required": [
@@ -11348,7 +11416,7 @@
                       "description": "vecvecu8"
                     }
                   ],
-                  "description": "User available value type (number or string, e.g., 6 or 'U64' or 'u64')"
+                  "description": "User available value type (number, numeric string, or name — e.g., 6, '6', 'U64', 'u64')"
                 },
                 {
                   "type": "number",