@wowok/agent-mcp 3.2.6 → 3.2.7

package/dist/schemas/onchain_events.output.json

@@ -3122,6 +3122,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": [

package/dist/schemas/onchain_operations.output.json

@@ -3592,6 +3592,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": [
@@ -5577,6 +5621,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": [
@@ -5685,6 +5773,7 @@
                 "wip_verification_failed",
                 "wip_storage_unavailable",
                 "submission_unknown",
+                "move_abort_unmapped",
                 "unknown"
               ]
             },
@@ -6973,6 +7062,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": [

package/dist/schemas/onchain_operations.schema.json

@@ -97,7 +97,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": {
@@ -139,6 +139,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",
@@ -174,8 +175,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",
@@ -191,8 +191,7 @@
                     }
                   },
                   "required": [
-                    "items",
-                    "total_pay"
+                    "items"
                   ],
                   "additionalProperties": false
                 },
@@ -925,7 +924,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"
@@ -1427,7 +1426,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",
@@ -1786,7 +1785,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"
             }
           },
@@ -2780,7 +2779,7 @@
                                 "description": "Node name. ⚠️ T1 LOSSY POINT (B-1): do NOT name a node 'refund'/'refunded'/'deposit_refunded'/'deposit_deducted'/'disputed'/'cancelled' to model fund return or dispute — funds MUST move through the Allocation waterfall (order_allocators), NOT through Machine terminal nodes (R-M1-11). A node named 'refund' is a semantic lie: reaching it does not move funds by itself. Model refund as a refund-to-Order Allocator slot (a { Signer } or Order-owner recipient), and model dispute as the bound Arbitration, not a Machine node."
                               },
                               "role": {
-                                "description": "OPTIONAL business role tag for display layers and template reuse (E-9). SESSION METADATA ONLY — the on-chain node struct carries name+pairs, so this is NOT stored on-chain; the MCP echoes it back as a NODE ROLES constraint warning and seed templates annotate it. Semantics: draft = pre-start cancellable, active = work in progress, delivered = work submitted awaiting acceptance, final = settlement endpoint (advancing here should trigger the Allocation fund release), cancelled = refund endpoint (advancing here should trigger the refund Allocator).",
+                                "description": "OPTIONAL business role tag for display layers and template reuse (E-9). SESSION METADATA ONLY — the on-chain node struct carries name+pairs, so this is NOT stored on-chain; the MCP echoes it back as a NODE ROLES constraint warning and seed templates annotate it. Semantics: draft = pre-start cancellable, active = work in progress, delivered = work submitted awaiting acceptance, final = settlement endpoint, cancelled = refund endpoint. ⚠️ Advancing to ANY node never moves funds by itself: settlement/refund requires an explicit allocation call (alloc by guard) AFTER the terminal node is reached. Nothing auto-settles on-chain — plan the settlement trigger (merchant, keeper, or buyer action) explicitly in the template.",
                                 "type": "string",
                                 "enum": [
                                   "draft",
@@ -2967,7 +2966,7 @@
                                 "description": "Node name. ⚠️ T1 LOSSY POINT (B-1): do NOT name a node 'refund'/'refunded'/'deposit_refunded'/'deposit_deducted'/'disputed'/'cancelled' to model fund return or dispute — funds MUST move through the Allocation waterfall (order_allocators), NOT through Machine terminal nodes (R-M1-11). A node named 'refund' is a semantic lie: reaching it does not move funds by itself. Model refund as a refund-to-Order Allocator slot (a { Signer } or Order-owner recipient), and model dispute as the bound Arbitration, not a Machine node."
                               },
                               "role": {
-                                "description": "OPTIONAL business role tag for display layers and template reuse (E-9). SESSION METADATA ONLY — the on-chain node struct carries name+pairs, so this is NOT stored on-chain; the MCP echoes it back as a NODE ROLES constraint warning and seed templates annotate it. Semantics: draft = pre-start cancellable, active = work in progress, delivered = work submitted awaiting acceptance, final = settlement endpoint (advancing here should trigger the Allocation fund release), cancelled = refund endpoint (advancing here should trigger the refund Allocator).",
+                                "description": "OPTIONAL business role tag for display layers and template reuse (E-9). SESSION METADATA ONLY — the on-chain node struct carries name+pairs, so this is NOT stored on-chain; the MCP echoes it back as a NODE ROLES constraint warning and seed templates annotate it. Semantics: draft = pre-start cancellable, active = work in progress, delivered = work submitted awaiting acceptance, final = settlement endpoint, cancelled = refund endpoint. ⚠️ Advancing to ANY node never moves funds by itself: settlement/refund requires an explicit allocation call (alloc by guard) AFTER the terminal node is reached. Nothing auto-settles on-chain — plan the settlement trigger (merchant, keeper, or buyer action) explicitly in the template.",
                                 "type": "string",
                                 "enum": [
                                   "draft",
@@ -4564,6 +4563,63 @@
                   "const": "recently"
                 }
               ]
+            },
+            "review": {
+              "description": "Structured review composite (REVIEW component): after this forward succeeds, write the structured reputation record into a Repository (+ optional reward claim), reusing this call's passport submission. Requires operate (the chain fires only after a successful forward).",
+              "type": "object",
+              "properties": {
+                "repository": {
+                  "type": "string",
+                  "description": "Repository object ID or name that stores the structured reputation record. Its matching policy key should use id_from=Signer (one record per buyer, rewrite = own-record overwrite) and accept a JSON payload {rating, tags?, orderRef?}. PREFERRED: the service's review repository EMITTED BY THE BUILD PLAN when review_mode was set (AR-1) — resolve it from the service's repositories list (service_panorama / onchain_objects, name suffix '_review') — never guess an address."
+                },
+                "key": {
+                  "description": "Data key (policy rule name) to write under. Default 'review'.",
+                  "type": "string"
+                },
+                "rating": {
+                  "type": "string",
+                  "enum": [
+                    "like",
+                    "dislike"
+                  ],
+                  "description": "Buyer rating. Ratings NEVER affect settlement (the settlement anchor is the delivered moment, not this review) — this is reputation only."
+                },
+                "tags": {
+                  "description": "Optional structured tags for statistics and market exposure (e.g. ['fast_delivery','good_quality']).",
+                  "type": "array",
+                  "items": {
+                    "type": "string"
+                  }
+                },
+                "reward_claim": {
+                  "description": "Optional reward claim chained after the repository write (fail-isolated: a failed claim never undoes the write or the forward).",
+                  "type": "object",
+                  "properties": {
+                    "reward": {
+                      "type": "string",
+                      "description": "Reward object ID or name to claim from. Resolve it from the service's rewards list (service_panorama / service_quote reward_terms) — never guess an address."
+                    },
+                    "guard": {
+                      "type": "string",
+                      "description": "Guard object that gates this claim. MUST be covered by this call's passport submission (one of the submission.guard entries, same address), otherwise the chain aborts."
+                    }
+                  },
+                  "required": [
+                    "reward",
+                    "guard"
+                  ],
+                  "additionalProperties": false
+                },
+                "write_guard": {
+                  "description": "Policy write guard for the repository write. DEFAULT: the first guard of this call's passport submission (the review-edge credential). Required when the matched Repository policy uses id_from=None with declared guards (the chain aborts with 22, E_POLICY_WRITE_GUARD_REQUIRED, otherwise). The guard MUST be covered by the passport submission.",
+                  "type": "string"
+                }
+              },
+              "required": [
+                "repository",
+                "rating"
+              ],
+              "additionalProperties": false
             }
           },
           "required": [
@@ -7091,7 +7147,8 @@
                 "indemnity": {
                   "type": "integer",
                   "minimum": 0,
-                  "maximum": 9007199254740991
+                  "maximum": 9007199254740991,
+                  "description": "Awarded compensation in integer smallest units (0 = a denial ruling that pays nothing). Hard-capped at 3x the disputed order amount on chain. Funded from the Service's merchant-prepaid compensation fund — an award larger than the fund balance aborts the later payout until the merchant tops up. A non-zero award consumes the order's one-shot compensation latch: refund rails gated on 'no award paid' can never fire afterwards, so pair them with a merchant-recovery rail at build time."
                 }
               },
               "required": [
@@ -8221,7 +8278,7 @@
                           "at"
                         ],
                         "additionalProperties": false,
-                        "description": "An instant messaging contact entry with address and optional description"
+                        "description": "An instant messaging contact entry (at + optional description). NO status field by design: on chain, Im.status is self-declared — each member sets its OWN status (your own via data.my_status; other members via their own contact-status update), and creating an entry always starts it with an empty status."
                       },
                       "description": "List of IM contacts to add"
                     }
@@ -8259,7 +8316,7 @@
                           "at"
                         ],
                         "additionalProperties": false,
-                        "description": "An instant messaging contact entry with address and optional description"
+                        "description": "An instant messaging contact entry (at + optional description). NO status field by design: on chain, Im.status is self-declared — each member sets its OWN status (your own via data.my_status; other members via their own contact-status update), and creating an entry always starts it with an empty status."
                       },
                       "description": "Complete list of IM contacts to set"
                     }
@@ -14191,7 +14248,7 @@
                                   "type": "string"
                                 }
                               ],
-                              "description": "When specified, the query retrieves data from the associated (witness) object instead of the queried object itself. This enables cross-object queries within Guard validation logic. Can be a numeric ID (100-108) or a string name (case-insensitive, with or without the 'Type' prefix). String format is recommended for readability.\n\nAvailable WitnessTypes:\n- OrderProgress / TypeOrderProgress (100): Query an Order's associated Progress object. Use case: Check if order has reached a specific workflow node (e.g., 'complete') before allowing reward claims.\n- OrderMachine / TypeOrderMachine (101): Query an Order's associated Machine (workflow definition). Use case: Verify the workflow structure or check node configurations.\n- OrderService / TypeOrderService (102): Query an Order's parent Service object. Use case: Validate the service offering details or check service-level configurations.\n- ProgressMachine / TypeProgressMachine (103): Query a Progress's associated Machine. Use case: Access workflow definition from a Progress context.\n- ArbOrder / TypeArbOrder (104): Query an Arb's associated Order. Use case: In arbitration voting guards, verify order details like payment amount or service ID.\n- ArbArbitration / TypeArbArbitration (105): Query an Arb's parent Arbitration service. Use case: Access arbitration configuration or fee settings from within an Arb case.\n- ArbProgress / TypeArbProgress (106): Query an Arb's associated Progress. Use case: Check order workflow state during arbitration validation.\n- ArbMachine / TypeArbMachine (107): Query an Arb's associated Machine. Use case: Access workflow definition for dispute context analysis.\n- ArbService / TypeArbService (108): Query an Arb's associated Service. Use case: Verify service terms or compensation fund status during arbitration.\n\nExample: To validate that an order has reached the 'complete' node, query the Order with convert_witness='OrderProgress' and check the Progress's current_node field."
+                              "description": "When specified, the query retrieves data from the associated (witness) object instead of the queried object itself. This enables cross-object queries within Guard validation logic. Can be a numeric ID (100-109) or a string name (case-insensitive, with or without the 'Type' prefix). String format is recommended for readability.\n\nAvailable WitnessTypes:\n- OrderProgress / TypeOrderProgress (100): Query an Order's associated Progress object. Use case: Check if order has reached a specific workflow node (e.g., 'complete') before allowing reward claims.\n- OrderMachine / TypeOrderMachine (101): Query an Order's associated Machine (workflow definition). Use case: Verify the workflow structure or check node configurations.\n- OrderService / TypeOrderService (102): Query an Order's parent Service object. Use case: Validate the service offering details or check service-level configurations.\n- ProgressMachine / TypeProgressMachine (103): Query a Progress's associated Machine. Use case: Access workflow definition from a Progress context.\n- ArbOrder / TypeArbOrder (104): Query an Arb's associated Order. Use case: In arbitration voting guards, verify order details like payment amount or service ID.\n- ArbArbitration / TypeArbArbitration (105): Query an Arb's parent Arbitration service. Use case: Access arbitration configuration or fee settings from within an Arb case.\n- ArbProgress / TypeArbProgress (106): Query an Arb's associated Progress. Use case: Check order workflow state during arbitration validation.\n- ArbMachine / TypeArbMachine (107): Query an Arb's associated Machine. Use case: Access workflow definition for dispute context analysis.\n- ArbService / TypeArbService (108): Query an Arb's associated Service. Use case: Verify service terms or compensation fund status during arbitration.\n- OrderAllocation / TypeOrderAllocation (109): Query an Order's escrow Allocation. Use case: Fund gates — combine with the allocation.balance query (1051) to require balance >= a threshold before a forward advances (e.g., renewal loops).\n\nExample: To validate that an order has reached the 'complete' node, query the Order with convert_witness='OrderProgress' and check the Progress's current_node field."
                             }
                           },
                           "required": [
@@ -18354,7 +18411,7 @@
                 "receive"
               ],
               "additionalProperties": false,
-              "description": "Receive mode: unwrap a CoinWrapper to the caller's wallet. Use after Allocation's alloc_by_guard creates a Payment with your address as a revenue recipient. The CoinWrapper holds your share — call this to convert it to actual coins in your wallet. Provide 'object' to unwrap a specific CoinWrapper, or OMIT it to auto-unwrap every CoinWrapper owned by the caller. AUTO-CLAIM: when the allocation SIGNER and the recipient are the SAME account, the share is credited directly during settlement and NO CoinWrapper is created — a 'no CoinWrapper found' result in that case means the funds already arrived (verify via account_balance), it is NOT a failure."
+              "description": "Receive mode: unwrap a CoinWrapper to the caller's wallet. Use after Allocation's alloc_by_guard creates a Payment with your address as a revenue recipient. The CoinWrapper holds your share — call this to convert it to actual coins in your wallet. Provide 'object' to unwrap a specific CoinWrapper, or OMIT it to auto-unwrap every CoinWrapper owned by the caller. CHAIN TRUTH: allocation settlement ALWAYS creates one CoinWrapper per recipient row on-chain — there is NO chain-level auto-claim, even when the signer IS the recipient (ptrn-ln-261010 C-04). After an alloc where you are a recipient, expect a CoinWrapper under your address and claim it here; a 'no CoinWrapper found' result means the funds were already claimed (verify via account_balance) or your share is held by another object (Order/Entity) and must be claimed through that object's own receive entry."
             }
           ],
           "description": "On-chain Payment operations. TWO modes:\n(1) CREATE: Set 'object' with {name, type_parameter, ...}, 'revenue', and 'info' to create a new Payment.\n(2) RECEIVE: Set {receive: true} to unwrap CoinWrappers to your wallet. Provide 'object' (<coinwrapper_id_or_name>) to unwrap a specific one, or OMIT it to auto-unwrap every CoinWrapper owned by the caller. type_parameter optional — auto-derived from the CoinWrapper's type."
@@ -22693,7 +22750,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "When specified, the query retrieves data from the associated (witness) object instead of the queried object itself. This enables cross-object queries within Guard validation logic. Can be a numeric ID (100-108) or a string name (case-insensitive, with or without the 'Type' prefix). String format is recommended for readability.\n\nAvailable WitnessTypes:\n- OrderProgress / TypeOrderProgress (100): Query an Order's associated Progress object. Use case: Check if order has reached a specific workflow node (e.g., 'complete') before allowing reward claims.\n- OrderMachine / TypeOrderMachine (101): Query an Order's associated Machine (workflow definition). Use case: Verify the workflow structure or check node configurations.\n- OrderService / TypeOrderService (102): Query an Order's parent Service object. Use case: Validate the service offering details or check service-level configurations.\n- ProgressMachine / TypeProgressMachine (103): Query a Progress's associated Machine. Use case: Access workflow definition from a Progress context.\n- ArbOrder / TypeArbOrder (104): Query an Arb's associated Order. Use case: In arbitration voting guards, verify order details like payment amount or service ID.\n- ArbArbitration / TypeArbArbitration (105): Query an Arb's parent Arbitration service. Use case: Access arbitration configuration or fee settings from within an Arb case.\n- ArbProgress / TypeArbProgress (106): Query an Arb's associated Progress. Use case: Check order workflow state during arbitration validation.\n- ArbMachine / TypeArbMachine (107): Query an Arb's associated Machine. Use case: Access workflow definition for dispute context analysis.\n- ArbService / TypeArbService (108): Query an Arb's associated Service. Use case: Verify service terms or compensation fund status during arbitration.\n\nExample: To validate that an order has reached the 'complete' node, query the Order with convert_witness='OrderProgress' and check the Progress's current_node field."
+                  "description": "When specified, the query retrieves data from the associated (witness) object instead of the queried object itself. This enables cross-object queries within Guard validation logic. Can be a numeric ID (100-109) or a string name (case-insensitive, with or without the 'Type' prefix). String format is recommended for readability.\n\nAvailable WitnessTypes:\n- OrderProgress / TypeOrderProgress (100): Query an Order's associated Progress object. Use case: Check if order has reached a specific workflow node (e.g., 'complete') before allowing reward claims.\n- OrderMachine / TypeOrderMachine (101): Query an Order's associated Machine (workflow definition). Use case: Verify the workflow structure or check node configurations.\n- OrderService / TypeOrderService (102): Query an Order's parent Service object. Use case: Validate the service offering details or check service-level configurations.\n- ProgressMachine / TypeProgressMachine (103): Query a Progress's associated Machine. Use case: Access workflow definition from a Progress context.\n- ArbOrder / TypeArbOrder (104): Query an Arb's associated Order. Use case: In arbitration voting guards, verify order details like payment amount or service ID.\n- ArbArbitration / TypeArbArbitration (105): Query an Arb's parent Arbitration service. Use case: Access arbitration configuration or fee settings from within an Arb case.\n- ArbProgress / TypeArbProgress (106): Query an Arb's associated Progress. Use case: Check order workflow state during arbitration validation.\n- ArbMachine / TypeArbMachine (107): Query an Arb's associated Machine. Use case: Access workflow definition for dispute context analysis.\n- ArbService / TypeArbService (108): Query an Arb's associated Service. Use case: Verify service terms or compensation fund status during arbitration.\n- OrderAllocation / TypeOrderAllocation (109): Query an Order's escrow Allocation. Use case: Fund gates — combine with the allocation.balance query (1051) to require balance >= a threshold before a forward advances (e.g., renewal loops).\n\nExample: To validate that an order has reached the 'complete' node, query the Order with convert_witness='OrderProgress' and check the Progress's current_node field."
                 }
               },
               "required": [

package/dist/schemas/onchain_operations_arbitration.schema.json

@@ -326,7 +326,8 @@
             "indemnity": {
               "type": "integer",
               "minimum": 0,
-              "maximum": 9007199254740991
+              "maximum": 9007199254740991,
+              "description": "Awarded compensation in integer smallest units (0 = a denial ruling that pays nothing). Hard-capped at 3x the disputed order amount on chain. Funded from the Service's merchant-prepaid compensation fund — an award larger than the fund balance aborts the later payout until the merchant tops up. A non-zero award consumes the order's one-shot compensation latch: refund rails gated on 'no award paid' can never fire afterwards, so pair them with a merchant-recovery rail at build time."
             }
           },
           "required": [

package/dist/schemas/onchain_operations_contact.schema.json

@@ -127,7 +127,7 @@
                       "at"
                     ],
                     "additionalProperties": false,
-                    "description": "An instant messaging contact entry with address and optional description"
+                    "description": "An instant messaging contact entry (at + optional description). NO status field by design: on chain, Im.status is self-declared — each member sets its OWN status (your own via data.my_status; other members via their own contact-status update), and creating an entry always starts it with an empty status."
                   },
                   "description": "List of IM contacts to add"
                 }
@@ -165,7 +165,7 @@
                       "at"
                     ],
                     "additionalProperties": false,
-                    "description": "An instant messaging contact entry with address and optional description"
+                    "description": "An instant messaging contact entry (at + optional description). NO status field by design: on chain, Im.status is self-declared — each member sets its OWN status (your own via data.my_status; other members via their own contact-status update), and creating an entry always starts it with an empty status."
                   },
                   "description": "Complete list of IM contacts to set"
                 }

package/dist/schemas/onchain_operations_guard.schema.json

@@ -537,7 +537,7 @@
                               "type": "string"
                             }
                           ],
-                          "description": "When specified, the query retrieves data from the associated (witness) object instead of the queried object itself. This enables cross-object queries within Guard validation logic. Can be a numeric ID (100-108) or a string name (case-insensitive, with or without the 'Type' prefix). String format is recommended for readability.\n\nAvailable WitnessTypes:\n- OrderProgress / TypeOrderProgress (100): Query an Order's associated Progress object. Use case: Check if order has reached a specific workflow node (e.g., 'complete') before allowing reward claims.\n- OrderMachine / TypeOrderMachine (101): Query an Order's associated Machine (workflow definition). Use case: Verify the workflow structure or check node configurations.\n- OrderService / TypeOrderService (102): Query an Order's parent Service object. Use case: Validate the service offering details or check service-level configurations.\n- ProgressMachine / TypeProgressMachine (103): Query a Progress's associated Machine. Use case: Access workflow definition from a Progress context.\n- ArbOrder / TypeArbOrder (104): Query an Arb's associated Order. Use case: In arbitration voting guards, verify order details like payment amount or service ID.\n- ArbArbitration / TypeArbArbitration (105): Query an Arb's parent Arbitration service. Use case: Access arbitration configuration or fee settings from within an Arb case.\n- ArbProgress / TypeArbProgress (106): Query an Arb's associated Progress. Use case: Check order workflow state during arbitration validation.\n- ArbMachine / TypeArbMachine (107): Query an Arb's associated Machine. Use case: Access workflow definition for dispute context analysis.\n- ArbService / TypeArbService (108): Query an Arb's associated Service. Use case: Verify service terms or compensation fund status during arbitration.\n\nExample: To validate that an order has reached the 'complete' node, query the Order with convert_witness='OrderProgress' and check the Progress's current_node field."
+                          "description": "When specified, the query retrieves data from the associated (witness) object instead of the queried object itself. This enables cross-object queries within Guard validation logic. Can be a numeric ID (100-109) or a string name (case-insensitive, with or without the 'Type' prefix). String format is recommended for readability.\n\nAvailable WitnessTypes:\n- OrderProgress / TypeOrderProgress (100): Query an Order's associated Progress object. Use case: Check if order has reached a specific workflow node (e.g., 'complete') before allowing reward claims.\n- OrderMachine / TypeOrderMachine (101): Query an Order's associated Machine (workflow definition). Use case: Verify the workflow structure or check node configurations.\n- OrderService / TypeOrderService (102): Query an Order's parent Service object. Use case: Validate the service offering details or check service-level configurations.\n- ProgressMachine / TypeProgressMachine (103): Query a Progress's associated Machine. Use case: Access workflow definition from a Progress context.\n- ArbOrder / TypeArbOrder (104): Query an Arb's associated Order. Use case: In arbitration voting guards, verify order details like payment amount or service ID.\n- ArbArbitration / TypeArbArbitration (105): Query an Arb's parent Arbitration service. Use case: Access arbitration configuration or fee settings from within an Arb case.\n- ArbProgress / TypeArbProgress (106): Query an Arb's associated Progress. Use case: Check order workflow state during arbitration validation.\n- ArbMachine / TypeArbMachine (107): Query an Arb's associated Machine. Use case: Access workflow definition for dispute context analysis.\n- ArbService / TypeArbService (108): Query an Arb's associated Service. Use case: Verify service terms or compensation fund status during arbitration.\n- OrderAllocation / TypeOrderAllocation (109): Query an Order's escrow Allocation. Use case: Fund gates — combine with the allocation.balance query (1051) to require balance >= a threshold before a forward advances (e.g., renewal loops).\n\nExample: To validate that an order has reached the 'complete' node, query the Order with convert_witness='OrderProgress' and check the Progress's current_node field."
                         }
                       },
                       "required": [
@@ -3684,7 +3684,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "When specified, the query retrieves data from the associated (witness) object instead of the queried object itself. This enables cross-object queries within Guard validation logic. Can be a numeric ID (100-108) or a string name (case-insensitive, with or without the 'Type' prefix). String format is recommended for readability.\n\nAvailable WitnessTypes:\n- OrderProgress / TypeOrderProgress (100): Query an Order's associated Progress object. Use case: Check if order has reached a specific workflow node (e.g., 'complete') before allowing reward claims.\n- OrderMachine / TypeOrderMachine (101): Query an Order's associated Machine (workflow definition). Use case: Verify the workflow structure or check node configurations.\n- OrderService / TypeOrderService (102): Query an Order's parent Service object. Use case: Validate the service offering details or check service-level configurations.\n- ProgressMachine / TypeProgressMachine (103): Query a Progress's associated Machine. Use case: Access workflow definition from a Progress context.\n- ArbOrder / TypeArbOrder (104): Query an Arb's associated Order. Use case: In arbitration voting guards, verify order details like payment amount or service ID.\n- ArbArbitration / TypeArbArbitration (105): Query an Arb's parent Arbitration service. Use case: Access arbitration configuration or fee settings from within an Arb case.\n- ArbProgress / TypeArbProgress (106): Query an Arb's associated Progress. Use case: Check order workflow state during arbitration validation.\n- ArbMachine / TypeArbMachine (107): Query an Arb's associated Machine. Use case: Access workflow definition for dispute context analysis.\n- ArbService / TypeArbService (108): Query an Arb's associated Service. Use case: Verify service terms or compensation fund status during arbitration.\n\nExample: To validate that an order has reached the 'complete' node, query the Order with convert_witness='OrderProgress' and check the Progress's current_node field."
+                  "description": "When specified, the query retrieves data from the associated (witness) object instead of the queried object itself. This enables cross-object queries within Guard validation logic. Can be a numeric ID (100-109) or a string name (case-insensitive, with or without the 'Type' prefix). String format is recommended for readability.\n\nAvailable WitnessTypes:\n- OrderProgress / TypeOrderProgress (100): Query an Order's associated Progress object. Use case: Check if order has reached a specific workflow node (e.g., 'complete') before allowing reward claims.\n- OrderMachine / TypeOrderMachine (101): Query an Order's associated Machine (workflow definition). Use case: Verify the workflow structure or check node configurations.\n- OrderService / TypeOrderService (102): Query an Order's parent Service object. Use case: Validate the service offering details or check service-level configurations.\n- ProgressMachine / TypeProgressMachine (103): Query a Progress's associated Machine. Use case: Access workflow definition from a Progress context.\n- ArbOrder / TypeArbOrder (104): Query an Arb's associated Order. Use case: In arbitration voting guards, verify order details like payment amount or service ID.\n- ArbArbitration / TypeArbArbitration (105): Query an Arb's parent Arbitration service. Use case: Access arbitration configuration or fee settings from within an Arb case.\n- ArbProgress / TypeArbProgress (106): Query an Arb's associated Progress. Use case: Check order workflow state during arbitration validation.\n- ArbMachine / TypeArbMachine (107): Query an Arb's associated Machine. Use case: Access workflow definition for dispute context analysis.\n- ArbService / TypeArbService (108): Query an Arb's associated Service. Use case: Verify service terms or compensation fund status during arbitration.\n- OrderAllocation / TypeOrderAllocation (109): Query an Order's escrow Allocation. Use case: Fund gates — combine with the allocation.balance query (1051) to require balance >= a threshold before a forward advances (e.g., renewal loops).\n\nExample: To validate that an order has reached the 'complete' node, query the Order with convert_witness='OrderProgress' and check the Progress's current_node field."
                 }
               },
               "required": [

package/dist/schemas/onchain_operations_machine.schema.json

@@ -363,7 +363,7 @@
                             "description": "Node name. ⚠️ T1 LOSSY POINT (B-1): do NOT name a node 'refund'/'refunded'/'deposit_refunded'/'deposit_deducted'/'disputed'/'cancelled' to model fund return or dispute — funds MUST move through the Allocation waterfall (order_allocators), NOT through Machine terminal nodes (R-M1-11). A node named 'refund' is a semantic lie: reaching it does not move funds by itself. Model refund as a refund-to-Order Allocator slot (a { Signer } or Order-owner recipient), and model dispute as the bound Arbitration, not a Machine node."
                           },
                           "role": {
-                            "description": "OPTIONAL business role tag for display layers and template reuse (E-9). SESSION METADATA ONLY — the on-chain node struct carries name+pairs, so this is NOT stored on-chain; the MCP echoes it back as a NODE ROLES constraint warning and seed templates annotate it. Semantics: draft = pre-start cancellable, active = work in progress, delivered = work submitted awaiting acceptance, final = settlement endpoint (advancing here should trigger the Allocation fund release), cancelled = refund endpoint (advancing here should trigger the refund Allocator).",
+                            "description": "OPTIONAL business role tag for display layers and template reuse (E-9). SESSION METADATA ONLY — the on-chain node struct carries name+pairs, so this is NOT stored on-chain; the MCP echoes it back as a NODE ROLES constraint warning and seed templates annotate it. Semantics: draft = pre-start cancellable, active = work in progress, delivered = work submitted awaiting acceptance, final = settlement endpoint, cancelled = refund endpoint. ⚠️ Advancing to ANY node never moves funds by itself: settlement/refund requires an explicit allocation call (alloc by guard) AFTER the terminal node is reached. Nothing auto-settles on-chain — plan the settlement trigger (merchant, keeper, or buyer action) explicitly in the template.",
                             "type": "string",
                             "enum": [
                               "draft",
@@ -550,7 +550,7 @@
                             "description": "Node name. ⚠️ T1 LOSSY POINT (B-1): do NOT name a node 'refund'/'refunded'/'deposit_refunded'/'deposit_deducted'/'disputed'/'cancelled' to model fund return or dispute — funds MUST move through the Allocation waterfall (order_allocators), NOT through Machine terminal nodes (R-M1-11). A node named 'refund' is a semantic lie: reaching it does not move funds by itself. Model refund as a refund-to-Order Allocator slot (a { Signer } or Order-owner recipient), and model dispute as the bound Arbitration, not a Machine node."
                           },
                           "role": {
-                            "description": "OPTIONAL business role tag for display layers and template reuse (E-9). SESSION METADATA ONLY — the on-chain node struct carries name+pairs, so this is NOT stored on-chain; the MCP echoes it back as a NODE ROLES constraint warning and seed templates annotate it. Semantics: draft = pre-start cancellable, active = work in progress, delivered = work submitted awaiting acceptance, final = settlement endpoint (advancing here should trigger the Allocation fund release), cancelled = refund endpoint (advancing here should trigger the refund Allocator).",
+                            "description": "OPTIONAL business role tag for display layers and template reuse (E-9). SESSION METADATA ONLY — the on-chain node struct carries name+pairs, so this is NOT stored on-chain; the MCP echoes it back as a NODE ROLES constraint warning and seed templates annotate it. Semantics: draft = pre-start cancellable, active = work in progress, delivered = work submitted awaiting acceptance, final = settlement endpoint, cancelled = refund endpoint. ⚠️ Advancing to ANY node never moves funds by itself: settlement/refund requires an explicit allocation call (alloc by guard) AFTER the terminal node is reached. Nothing auto-settles on-chain — plan the settlement trigger (merchant, keeper, or buyer action) explicitly in the template.",
                             "type": "string",
                             "enum": [
                               "draft",

package/dist/schemas/onchain_operations_payment.schema.json

@@ -195,7 +195,7 @@
             "receive"
           ],
           "additionalProperties": false,
-          "description": "Receive mode: unwrap a CoinWrapper to the caller's wallet. Use after Allocation's alloc_by_guard creates a Payment with your address as a revenue recipient. The CoinWrapper holds your share — call this to convert it to actual coins in your wallet. Provide 'object' to unwrap a specific CoinWrapper, or OMIT it to auto-unwrap every CoinWrapper owned by the caller. AUTO-CLAIM: when the allocation SIGNER and the recipient are the SAME account, the share is credited directly during settlement and NO CoinWrapper is created — a 'no CoinWrapper found' result in that case means the funds already arrived (verify via account_balance), it is NOT a failure."
+          "description": "Receive mode: unwrap a CoinWrapper to the caller's wallet. Use after Allocation's alloc_by_guard creates a Payment with your address as a revenue recipient. The CoinWrapper holds your share — call this to convert it to actual coins in your wallet. Provide 'object' to unwrap a specific CoinWrapper, or OMIT it to auto-unwrap every CoinWrapper owned by the caller. CHAIN TRUTH: allocation settlement ALWAYS creates one CoinWrapper per recipient row on-chain — there is NO chain-level auto-claim, even when the signer IS the recipient (ptrn-ln-261010 C-04). After an alloc where you are a recipient, expect a CoinWrapper under your address and claim it here; a 'no CoinWrapper found' result means the funds were already claimed (verify via account_balance) or your share is held by another object (Order/Entity) and must be claimed through that object's own receive entry."
         }
       ],
       "description": "On-chain Payment operations. TWO modes:\n(1) CREATE: Set 'object' with {name, type_parameter, ...}, 'revenue', and 'info' to create a new Payment.\n(2) RECEIVE: Set {receive: true} to unwrap CoinWrappers to your wallet. Provide 'object' (<coinwrapper_id_or_name>) to unwrap a specific one, or OMIT it to auto-unwrap every CoinWrapper owned by the caller. type_parameter optional — auto-derived from the CoinWrapper's type."