@wowok/skills 3.0.4 → 3.1.1

package/examples/MyShop/MyShop.md

@@ -1,2003 +0,0 @@
-# MyShop E-Commerce Example
-
-A complete e-commerce example demonstrating how to build an online store using WoWok protocol. This guide covers both merchant setup and customer order workflows.
-
----
-
-## ⚠️ Running Principle
-
-> **Run the example in full every time (repeatable).** This example uses `replaceExistName: true` on all object creations — each run generates new objects with new addresses. If you skip build steps, operations may silently act on orphaned objects from previous runs, producing incorrect results. Old objects' configurations do not reflect the current document version.
-
-- **Execution order**: Part 1 (Merchant Setup, Steps 1–8) → Part 2 (Customer Flow, Steps 1–9). Run all build steps in sequence before testing any customer flow. Do not skip steps — each depends on objects created by prior steps.
-- **Prerequisites**: `myshop_merchant` with sufficient WOW for gas and order operations. All on-chain operations require `env.confirmed: true`.
-
-> **💡 Call Format**: All WoWok operations go through a single unified `wowok` tool. The AI calls `wowok({ tool: "<sub-tool>", data: {<params>} })`. If parameters don't match the schema, the response includes the correct schema for self-correction. See [Response Format](../../docs/response-format.md) for details.
-
----
-
-## Core Requirements & Features
-
-| Requirement | Description | Implementation |
-|-------------|-------------|----------------|
-| **Product Listing** | Create and manage product/service listings | Service object with pricing, inventory, and WIP integration |
-| **Order Workflow** | Automated order processing from creation to completion | Machine with nodes: Order Confirmation → Shipping → In Transit → Completed |
-| **Permission Control** | Role-based access for merchant and customer operations | Permission object with custom indexes for merchant operations |
-| **Arbitration Support** | Dispute resolution mechanism | Arbitration object for handling order conflicts |
-| **WIP Verification** | Product authenticity verification via WIP files | WIP hash stored in Service for customer verification |
-| **Customer Communication** | Secure messaging between merchant and customer | Contact objects for pre-sales and after-sales support |
-
-### Key Design Decisions
-
-1. **Workflow-Driven Orders**: Order state transitions controlled by Machine workflow, ensuring predictable processing
-2. **Permission-Based Operations**: Merchant operations require specific permission indexes (1000-1002)
-3. **Customer Ownership**: Order owners can cancel orders and complete orders via `namedOperator: ""`
-4. **Modular Architecture**: Separate objects for Permission, Machine, Service, Arbitration, and Contact
-
----
-
-## Overview
-
-This example demonstrates a toy store e-commerce system with the following features:
-
-- **Merchant System**: Product listing, order management, workflow automation
-- **Customer Experience**: Browse products, place orders, track progress
-- **Trust & Security**: Arbitration for disputes, WIP for product verification
-- **Workflow Automation**: Machine-driven order processing from confirmation to delivery
-
----
-
-## Architecture
-
-### System Components
-
-```
-┌─────────────────────────────────────────────────────────────────────────────┐
-│                           MyShop E-Commerce System                          │
-├─────────────────────────────────────────────────────────────────────────────┤
-│                                                                             │
-│  ┌─────────────────────────┐    ┌─────────────────────────┐                │
-│  │    Merchant System      │    │    Customer System      │                │
-│  ├─────────────────────────┤    ├─────────────────────────┤                │
-│  │ • Permission (Access)   │    │ • Browse Products       │                │
-│  │ • Machine (Workflow)    │    │ • Create Order          │                │
-│  │ • Service (Products)    │◄──►│ • Send Private Info(*)  │                │
-│  │ • Allocation (Payment)  │    │ • Track Progress        │                │
-│  │ • Contact (Messaging)   │    │ • Order Complete        │                │
-│  └─────────────────────────┘    └─────────────────────────┘                │
-│                                                                             │
-│  Optional: Arbitration (Dispute Resolution)                                 │
-│                                                                             │
-└─────────────────────────────────────────────────────────────────────────────┘
-
-> **\*** Private information (shipping address, phone number) is sent via encrypted Messenger after order creation, not stored on-chain.
-
-### Order Workflow (Happy Path)
-
-```
-┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
-│    Order     │────►│   Shipping   │────►│  In Transit  │────►│   Completed  │
-│ Confirmation │     │              │     │              │     │              │
-└──────────────┘     └──────────────┘     └──────────────┘     └──────────────┘
-       │                                                            │
-       │                    ┌──────────────┐                        │
-       └───────────────────►│  Cancelled   │◄───────────────────────┘
-         (Cancel Order)     │(Final State) │    (Complete Order)
-                            └──────────────┘
-```
-
-**Normal Flow**: Order Confirmation → Shipping → In Transit → Completed  
-**Alternative**: Order Confirmation → Cancelled (if customer cancels before shipping)
-
----
-
-## Part 1: Merchant System Setup
-
-This section guides merchants through setting up their online store.
-
-### Prerequisites
-
-Before starting, ensure you have:
-- A WoWok account with mainnet WOW tokens (gas)
-- Access to the WoWok MCP server
-
-**Create merchant account:**
-
-**Prompt**: Create a new account named "myshop_merchant" for the store owner.
-
-```json
-{
-  "tool": "account_operation",
-  "data": {
-    "gen": {
-      "name": "myshop_merchant",
-      "replaceExistName": true
-    }
-  }
-}
-```
-
-**Get mainnet tokens:**
-
-**Prompt**: Transfer 1 WOW to account "myshop_merchant" from a funded account for gas fees.
-
-```json
-{
-  "tool": "account_operation",
-  "data": {
-    "transfer": {
-      "name_or_address_to": "myshop_merchant",
-      "amount": 1000000000,
-      "network": "mainnet"
-    }
-  }
-}
-```
-
----
-
-### Step 1: Create Permission Object
-
-First, create a Permission object to manage access control for your store operations.
-
-**Prompt**: Create a Permission object named "myshop_permission_v2" with tags ["ecommerce", "toys", "shop"] and description "Permission management for MyShop toy store".
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "permission",
-    "data": {
-      "object": {
-        "name": "myshop_permission_v2",
-        "tags": ["ecommerce", "toys", "shop"],
-        "onChain": false,
-        "replaceExistName": true
-      },
-      "description": "Permission management for MyShop toy store"
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
----
-
-### Step 2: Create Machine with Workflow Nodes
-
-Create a Machine to define the order processing workflow. This includes nodes for order confirmation, shipping, delivery, and completion. The Machine must be created with all nodes and published in a single operation — the protocol requires at least one node when publishing a Machine.
-
-> **Reference**: The complete node configuration is available in [`myshop_machine_nodes.json`](./myshop_machine_nodes.json). The JSON below mirrors that file's content wrapped in an on-chain operation.
-
-**Prompt**: Create a Machine named "myshop_machine_v2" with permission "myshop_permission_v2", including all workflow nodes (Order Confirmation, Shipping, In Transit, Completed, Cancelled), and publish it immediately.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "machine",
-    "data": {
-      "object": {
-        "name": "myshop_machine_v2",
-        "permission": "myshop_permission_v2",
-        "replaceExistName": true
-      },
-      "description": "Order processing workflow for MyShop toy store",
-      "node": {
-        "op": "add",
-        "nodes": [
-          {
-            "name": "Cancelled",
-            "pairs": [
-              {
-                "prev_node": "",
-                "threshold": 0,
-                "forwards": [
-                  {
-                    "name": "Cancel Order",
-                    "weight": 1,
-                    "namedOperator": ""
-                  }
-                ]
-              },
-              {
-                "prev_node": "Order Confirmation",
-                "threshold": 1,
-                "forwards": [
-                  {
-                    "name": "Cancel Order",
-                    "weight": 1,
-                    "namedOperator": ""
-                  }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "Completed",
-            "pairs": [
-              {
-                "prev_node": "In Transit",
-                "threshold": 1,
-                "forwards": [
-                  {
-                    "name": "Complete Order",
-                    "weight": 1,
-                    "namedOperator": ""
-                  }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "In Transit",
-            "pairs": [
-              {
-                "prev_node": "Shipping",
-                "threshold": 1,
-                "forwards": [
-                  {
-                    "name": "Confirm Delivery",
-                    "weight": 1,
-                    "permissionIndex": 1002
-                  }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "Order Confirmation",
-            "pairs": [
-              {
-                "prev_node": "",
-                "threshold": 0,
-                "forwards": [
-                  {
-                    "name": "Confirm Order",
-                    "weight": 1,
-                    "permissionIndex": 1000
-                  }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "Shipping",
-            "pairs": [
-              {
-                "prev_node": "Order Confirmation",
-                "threshold": 1,
-                "forwards": [
-                  {
-                    "name": "Ship Goods",
-                    "weight": 1,
-                    "permissionIndex": 1001
-                  }
-                ]
-              }
-            ]
-          }
-        ]
-      },
-      "publish": true
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: The Machine must be created with nodes and published in a single operation. Creating an empty Machine and then adding nodes/publishing separately will be rejected by the protocol's constraint checker. The "Cancelled" node has two pairs: one with `prev_node: ""` (cancel from initial state) and one with `prev_node: "Order Confirmation"` (cancel after order confirmation).
-
----
-
-### Step 3: Machine Workflow Design
-
-Before adding nodes, let's understand the order processing workflow:
-
-```
-┌─────────────────────────────────────────────────────────────────────────────────────┐
-│                         MyShop Order Processing Workflow                            │
-├─────────────────────────────────────────────────────────────────────────────────────┤
-│                                                                                     │
-│   ┌──────────────────┐                                                             │
-│   │  Order Created   │◄─────────────────────────────────────────────────────────┐  │
-│   │  (Initial State) │                                                              │  │
-│   └────────┬─────────┘                                                              │  │
-│            │                                                                        │  │
-│            ▼                                                                        │  │
-│   ┌──────────────────┐     ┌──────────────┐     ┌──────────────┐                   │  │
-│   │ Order Confirmation│────►│ Confirm Order│     │ Cancel Order │───────────────────┘  │
-│   │    (Node 1)      │     │  (Merchant)  │     │  (Customer)  │                      │
-│   │                  │     │  permission  │     │  (Order      │                      │
-│   └────────┬─────────┘     │  Index 1000  │     │   Owner)     │                      │
-│            │               └──────────────┘     └──────────────┘                      │
-│            │                      │                                                  │
-│            │                      ▼                                                  │
-│            │               ┌──────────────┐                                          │
-│            │               │   Threshold  │                                          │
-│            │               │     = 1      │                                          │
-│            │               └──────┬───────┘                                          │
-│            │                      │                                                  │
-│            ▼                      ▼                                                  │
-│   ┌──────────────────┐                                                             │
-│   │     Shipping     │◄─────────────────────────────────────────────────────────┐  │
-│   │    (Node 2)      │                                                             │  │
-│   │                  │     ┌──────────────┐                                       │  │
-│   └────────┬─────────┘────►│  Ship Goods  │                                       │  │
-│            │               │  (Merchant)  │                                       │  │
-│            │               │  permission  │                                       │  │
-│            │               │  Index 1001  │                                       │  │
-│            │               └──────────────┘                                       │  │
-│            │                      │                                               │  │
-│            │                      ▼                                               │  │
-│            │               ┌──────────────┐                                       │  │
-│            │               │   Threshold  │                                       │  │
-│            │               │     = 1      │                                       │  │
-│            │               └──────┬───────┘                                       │  │
-│            │                      │                                               │  │
-│            ▼                      ▼                                               │  │
-│   ┌──────────────────┐                                                             │
-│   │    In Transit    │◄─────────────────────────────────────────────────────────┐  │
-│   │    (Node 3)      │                                                             │  │
-│   │                  │     ┌──────────────┐                                       │  │
-│   └────────┬─────────┘────►│Confirm Delivery                                      │  │
-│            │               │  (Merchant)  │                                       │  │
-│            │               │  permission  │                                       │  │
-│            │               │  Index 1002  │                                       │  │
-│            │               └──────────────┘                                       │  │
-│            │                      │                                               │  │
-│            │                      ▼                                               │  │
-│            │               ┌──────────────┐                                       │  │
-│            │               │   Threshold  │                                       │  │
-│            │               │     = 1      │                                       │  │
-│            │               └──────┬───────┘                                       │  │
-│            │                      │                                               │  │
-│            ▼                      ▼                                               │  │
-│   ┌──────────────────┐                                                             │
-│   │    Completed     │◄─────────────────────────────────────────────────────────┐  │
-│   │    (Node 4)      │                                                             │  │
-│   │                  │     ┌──────────────┐                                       │  │
-│   └────────┬─────────┘────►│Complete Order│                                       │  │
-│            │               │  (Customer)  │                                       │  │
-│            │               │  (Order      │                                       │  │
-│            │               │   Owner)     │                                       │  │
-│            │               └──────────────┘                                       │  │
-│            │                      │                                               │  │
-│            │                      ▼                                               │  │
-│            │               ┌──────────────┐                                       │  │
-│            │               │  Cancelled   │                                       │  │
-│            │               │ (Final State)│                                       │  │
-│            │               └──────────────┘                                       │  │
-│            │                                                                       │  │
-│            └───────────────────────────────────────────────────────────────────────┘
-│                                                                                     │
-│   Legend:                                                                           │
-│   ───► = Forward transition (with threshold requirement)                            │
-│   ◄─── = Alternative path (cancellation)                                            │
-│                                                                                     │
-└─────────────────────────────────────────────────────────────────────────────────────┘
-```
-
-**Workflow Explanation:**
-
-| Node | Name | Description | Threshold | Forwards |
-|------|------|-------------|-----------|----------|
-| 1 | Order Confirmation | Initial state after order creation | 0 | Confirm Order (Merchant) |
-| 2 | Shipping | Merchant prepares and ships goods | 1 | Ship Goods (Merchant) |
-| 3 | In Transit | Goods are being delivered | 1 | Confirm Delivery (Merchant) |
-| 4 | Completed | Order successfully completed | 1 | Complete Order (Customer) |
-| 5 | Cancelled | Order cancelled by customer (from Order Confirmation) | 0 | Cancel Order (Customer) |
-
-**Permission Index Mapping:**
-- `1000` - Merchant confirms order
-- `1001` - Merchant ships goods
-- `1002` - Merchant confirms delivery
-
-**Order Permission:**
-- Use `namedOperator: ""` (empty string) to allow order owner and agents to operate through Order object
-- This is the recommended way to give order owners control over their orders
-
----
-
-### Step 4: Create Contact Object for Customer Service
-
-Create a Contact object to enable encrypted communication between customers and the store for after-sales support.
-
-#### 4.1 Enable Merchant Messenger
-
-**Prompt**: Enable messenger for the merchant account.
-
-```json
-{
-  "tool": "account_operation",
-  "data": {
-    "messenger": {
-      "enabled": true,
-      "name_or_account": "myshop_merchant"
-    }
-  }
-}
-```
-
-> **Note**: Enabling messenger now registers the account on the messenger server **immediately and synchronously** — each account registers itself (its own identity, its own keys). The result includes `registered: true` on success, or `registered: false` with `registerError` if the server is unreachable (the background refresh retries automatically every 60s). If the operation result shows `registered: false`, retry the enable operation before proceeding — otherwise the counterpart's first message will fail with "Recipient not registered".
-
-#### 4.2 Create After-Sales Contact Object
-
-**Prompt**: Create a Contact object named "myshop_aftersales_contact_v2" with permission "myshop_permission_v2" for after-sales support.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "contact",
-    "data": {
-      "object": {
-        "name": "myshop_aftersales_contact_v2",
-        "permission": "myshop_permission_v2",
-        "replaceExistName": true
-      },
-      "description": "MyShop after-sales support contact - we're here to help with orders, shipping, and returns",
-      "ims": {
-        "op": "add",
-        "im": [
-          {
-            "at": "myshop_merchant",
-            "description": "Primary after-sales support representative"
-          }
-        ]
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: The `at` field accepts an **account name** (not messenger name). It will be resolved to the account's address. Alternatively, use the full address directly.
-
----
-
-### Step 5: Create Service (Store) DRAFT
-
-> **⚠️ Order matters — Service DRAFT must be created BEFORE the Guards.** The Guards in Step 6 reference the Service by name (`myshop_service_v2` as an Address table value). The SDK resolves the name to the on-chain address AT Guard creation time. If the Service does not exist yet, Guard creation aborts with:
-> ```
-> Error: invalid parameter:BCS serialization failed: ... failed to resolve string: myshop_service_v2. Address may not exist in local accounts or marks.
-> ```
-> Create the Service as an unpublished DRAFT here so the name resolves, then bind machine/allocators/sales and publish it in Step 7.
-
-**Prompt**: Create an unpublished Service DRAFT named "myshop_service_v2" (no `publish` field — it stays a DRAFT so Guards can reference it and the mutable fields can still be configured).
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "service",
-    "data": {
-      "object": {
-        "name": "myshop_service_v2",
-        "type_parameter": "0x2::wow::WOW",
-        "permission": "myshop_permission_v2",
-        "tags": ["ecommerce", "toys", "store"],
-        "onChain": false,
-        "replaceExistName": true
-      },
-      "description": "MyShop - Top quality toys for children",
-      "location": "Online Store"
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: After publishing, `machine`, `order_allocators`, and `arbitrations` become **immutable**. Creating the draft first lets the Guards resolve the Service name while the Service is still configurable.
-
----
-
-### Step 6: Create Guards for Fund Allocation
-
-Before publishing the Service, create Guards that validate fund allocation conditions. These Guards ensure funds are only released when specific conditions are met. The Guards reference the Service DRAFT by name (`myshop_service_v2`), which now resolves to the draft's on-chain address (the address does NOT change when the draft is later published).
-
-> **Note**: Guard table item `name` must be ≤ 64 characters (`MAX_NAME_LENGTH`) and must NOT start with `0x`. Descriptive names with spaces/parentheses (e.g. `order_address (Order object submitted at runtime)`) exceed the limit and abort with `invalid parameter:table.name`. Use short identifiers like `order_address`.
-
-#### 6.1 Create Withdraw Guard (Merchant Withdrawal)
-
-Create a Guard that validates the order's Progress has reached the "Completed" node. This Guard uses `convert_witness: "OrderProgress"` (TypeOrderProgress) to query the Order's associated Progress object.
-
-**Prompt**: Create a Guard named "myshop_withdraw_guard_v2" that verifies the order is completed before allowing merchant withdrawal.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "guard",
-    "data": {
-      "namedNew": {
-        "name": "myshop_withdraw_guard_v2",
-        "tags": ["order", "completed", "withdraw", "signer-bound"],
-        "onChain": false,
-        "replaceExistName": true
-      },
-      "description": "Verify order progress is at Completed node for merchant withdrawal. RISK ELIMINATION: Three-fold verification - (1) order at Completed node, (2) signer is myshop_merchant (prevents fund theft), (3) order belongs to myshop_service_v2 (prevents cross-service theft).",
-      "table": [
-        {
-          "identifier": 0,
-          "b_submission": true,
-          "value_type": "Address",
-          "name": "order_address"
-        },
-        {
-          "identifier": 1,
-          "b_submission": false,
-          "value_type": "String",
-          "value": "Completed",
-          "name": "expected_node"
-        },
-        {
-          "identifier": 2,
-          "b_submission": false,
-          "value_type": "Address",
-          "value": "myshop_merchant",
-          "name": "merchant_address"
-        },
-        {
-          "identifier": 3,
-          "b_submission": false,
-          "value_type": "Address",
-          "value": "myshop_service_v2",
-          "name": "service_address"
-        }
-      ],
-      "root": {
-        "type": "logic_and",
-        "nodes": [
-          {
-            "type": "logic_equal",
-            "nodes": [
-              {
-                "type": "query",
-                "query": "progress.current",
-                "object": {
-                  "identifier": 0,
-                  "convert_witness": "OrderProgress"
-                },
-                "parameters": []
-              },
-              {
-                "type": "identifier",
-                "identifier": 1
-              }
-            ]
-          },
-          {
-            "type": "logic_equal",
-            "nodes": [
-              {
-                "type": "context",
-                "context": "Signer"
-              },
-              {
-                "type": "identifier",
-                "identifier": 2
-              }
-            ]
-          },
-          {
-            "type": "logic_equal",
-            "nodes": [
-              {
-                "type": "query",
-                "query": "order.service",
-                "object": {
-                  "identifier": 0
-                },
-                "parameters": []
-              },
-              {
-                "type": "identifier",
-                "identifier": 3
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-**Guard Explanation (Three-fold Verification):**
-- **Table Item 0**: Order address (submitted at runtime, typed as Order object)
-- **Table Item 1**: Constant string "Completed" (the target node name)
-- **Table Item 2**: Constant address `myshop_merchant` (authorized merchant)
-- **Table Item 3**: Constant address `myshop_service_v2` (this service's on-chain address)
-- **Condition 1 — Order Completed**: `logic_equal[query("progress.current", witness="OrderProgress"), identifier[1]]` — queries the submitted Order's Progress (via witness "OrderProgress") and verifies the current node is "Completed"
-- **Condition 2 — Signer is Merchant**: `logic_equal[context(Signer), identifier[2]]` — verifies the transaction caller is `myshop_merchant`, **preventing fund theft by unauthorized callers** (R-C3-01/R-C3-06)
-- **Condition 3 — Service Ownership**: `logic_equal[query("order.service"), identifier[3]]` — queries the submitted Order's `service` field and verifies it equals `myshop_service_v2`, **preventing cross-service theft** where someone submits another service's Completed order (R-C3-05)
-- **root**: `logic_and` of all three conditions — all must pass for allocation to proceed
-
-> **Risk Elimination (R-C3-06)**: The allocator uses `"who": {"Signer": "signer"}` (funds go to the caller). This is safe ONLY because Condition 2 binds the Signer to `myshop_merchant`. Without this binding, anyone could submit any Completed order and steal 100% of funds. The three-fold verification ensures only the authorized merchant can trigger withdrawal.
->
-> **Note**: The Guard `root` field directly specifies the GuardNode (e.g., `type: "logic_and"`), not wrapped in a `type: "node"` object.
-
-#### 6.2 Create Refund Guard (Customer Refund)
-
-Create a Guard for customer refunds when order is cancelled.
-
-**Prompt**: Create a Guard named "myshop_refund_guard_v2" for customer refund validation.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "guard",
-    "data": {
-      "namedNew": {
-        "name": "myshop_refund_guard_v2",
-        "tags": ["order", "cancelled", "refund", "signer-bound"],
-        "onChain": false,
-        "replaceExistName": true
-      },
-      "description": "Verify order progress is at Cancelled node for customer refund. RISK ELIMINATION: Three-fold verification - (1) order at Cancelled node, (2) signer is order.owner (dynamic query, prevents fund theft - only order owner can trigger their own refund), (3) order belongs to myshop_service_v2 (prevents cross-service theft).",
-      "table": [
-        {
-          "identifier": 0,
-          "b_submission": true,
-          "value_type": "Address",
-          "name": "order_address"
-        },
-        {
-          "identifier": 1,
-          "b_submission": false,
-          "value_type": "String",
-          "value": "Cancelled",
-          "name": "expected_node"
-        },
-        {
-          "identifier": 2,
-          "b_submission": false,
-          "value_type": "Address",
-          "value": "myshop_service_v2",
-          "name": "service_address"
-        }
-      ],
-      "root": {
-        "type": "logic_and",
-        "nodes": [
-          {
-            "type": "logic_equal",
-            "nodes": [
-              {
-                "type": "query",
-                "query": "progress.current",
-                "object": {
-                  "identifier": 0,
-                  "convert_witness": "OrderProgress"
-                },
-                "parameters": []
-              },
-              {
-                "type": "identifier",
-                "identifier": 1
-              }
-            ]
-          },
-          {
-            "type": "logic_equal",
-            "nodes": [
-              {
-                "type": "context",
-                "context": "Signer"
-              },
-              {
-                "type": "query",
-                "query": "order.owner",
-                "object": {
-                  "identifier": 0
-                },
-                "parameters": []
-              }
-            ]
-          },
-          {
-            "type": "logic_equal",
-            "nodes": [
-              {
-                "type": "query",
-                "query": "order.service",
-                "object": {
-                  "identifier": 0
-                },
-                "parameters": []
-              },
-              {
-                "type": "identifier",
-                "identifier": 2
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-**Guard Explanation (Three-fold Verification):**
-- **Table Item 0**: Order address (submitted at runtime, typed as Order object)
-- **Table Item 1**: Constant string "Cancelled" (the target node name)
-- **Table Item 2**: Constant address `myshop_service_v2` (this service's on-chain address)
-- **Condition 1 — Order Cancelled**: `logic_equal[query("progress.current", witness="OrderProgress"), identifier[1]]` — queries the submitted Order's Progress (via witness "OrderProgress") and verifies the current node is "Cancelled"
-- **Condition 2 — Signer is Order Owner**: `logic_equal[context(Signer), query("order.owner")]` — verifies the transaction caller is the Order's owner (dynamic query, not a fixed address), **preventing fund theft by unauthorized callers** (R-C3-01/R-C3-06). Only the customer who placed the order can trigger their own refund.
-- **Condition 3 — Service Ownership**: `logic_equal[query("order.service"), identifier[2]]` — queries the submitted Order's `service` field and verifies it equals `myshop_service_v2`, **preventing cross-service theft** (R-C3-05)
-- **root**: `logic_and` of all three conditions — all must pass for refund allocation to proceed
-
-> **Risk Elimination (R-C3-06)**: Unlike the withdraw Guard (which binds Signer to a fixed merchant address), the refund Guard binds Signer to `order.owner` via a **dynamic query** (query 1562). This is because refunds flow to the customer, and each order has a different customer. Only the order's rightful owner can trigger the refund — an attacker cannot submit another customer's Cancelled order.
->
-> **Refund Recipient Design**: The allocator uses `"who": {"GuardIdentifier": 0}` (funds go to the Order object's address, not the caller's wallet). This creates an escrow pattern: the refund is held at the Order object's address, and the customer subsequently claims it via a separate withdraw operation. This ensures traceability and audit trail.
-
----
-
-### Step 7: Publish Service (Store)
-
-Bind all previously created components (machine, Guards, products, after-sales contact) to the Service DRAFT created in Step 5, then publish it. The Service address stays the same as the DRAFT, so the Guards' `service_address` table values remain valid.
-
-> **Important**: Provide a complete configuration including machine, order_allocators with Guards, and products. The Service is published in a single transaction. After publish, `machine`, `order_allocators`, and `arbitrations` become immutable.
-
-#### 7.1 Understanding Order Allocators
-
-The `order_allocators` configuration defines how order payments are distributed:
-
-| Component | Description |
-|-----------|-------------|
-| **Guard** | Validates allocation conditions (e.g., order must be completed) |
-| **Sharing** | Defines who receives funds and how much |
-| **Mode** | "Rate" (percentage), "Amount" (fixed), or "Surplus" |
-| **Threshold** | Minimum amount to trigger allocation |
-
-**Recipient Types:**
-- `{ "Signer": "signer" }` - Transaction sender (caller). **⚠️ R-C3-06 Risk**: If the Guard does NOT bind the Signer to an authorized address, anyone who passes the Guard can steal 100% of funds. Safe ONLY when the Guard includes a `logic_equal[context(Signer), <authorized_address>]` check.
-- `{ "Entity": { "name_or_address": "..." } }` - Specific address or account name (safest — funds go to a fixed address regardless of caller)
-- `{ "GuardIdentifier": 0 }` - Address from Guard table (e.g., the submitted Order object's address)
-
-> **R-C3-06 Risk Elimination — Guard + Sharing Coupling**: The `order_allocators` scene couples Guard verification (WHO can trigger) with sharing recipient (WHERE funds go). This example uses two risk-elimination strategies:
-> - **Withdraw allocator** (`sharing.who = Signer`): Safe because `myshop_withdraw_guard_v2` binds `context(Signer)` to `myshop_merchant` (identifier 2). Only the merchant can pass the Guard, so funds correctly flow to the merchant.
-> - **Refund allocator** (`sharing.who = GuardIdentifier 0`): Funds go to the Order object's address (escrow), not to the caller. The Guard additionally binds `context(Signer)` to `order.owner` (dynamic query 1562), ensuring only the order's rightful owner can trigger the refund.
->
-> **Alternative approach**: Instead of Signer binding in the Guard, you can use `sharing.who = Entity` to send funds to a fixed Treasury or personal address. This is even more robust because funds are directed regardless of who passes the Guard. See the Insurance example for this pattern.
-
-> **Design Decision — Refund Recipient**: When using `{ "GuardIdentifier": 0 }` in the refund allocation, the refund is sent to the **Order object's on-chain address** (not the customer's wallet address). This is by design: the Order object acts as an escrow holding the refunded payment at its own address. The customer subsequently claims the refund from the Order object via a separate withdraw operation. This two-step design ensures the refund is traceable on-chain and tied to the specific order, providing better dispute resolution and audit trail.
-
-#### 7.2 Publish Service (bind machine + allocators + sales + um)
-
-**Prompt**: Publish the Service DRAFT "myshop_service_v2" (created in Step 5) by binding machine "myshop_machine_v2", order allocation using the Guards, after-sales contact, and toy products. Note `object` is now a STRING reference to the existing draft, and `publish: true` is set.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "service",
-    "data": {
-      "object": "myshop_service_v2",
-      "machine": "myshop_machine_v2",
-      "order_allocators": {
-        "description": "Order revenue allocation - merchant withdraw after completion",
-        "threshold": 0,
-        "allocators": [
-          {
-            "guard": "myshop_withdraw_guard_v2",
-            "sharing": [
-              {
-                "who": { "Signer": "signer" },
-                "sharing": 10000,
-                "mode": "Rate"
-              }
-            ]
-          },
-          {
-            "guard": "myshop_refund_guard_v2",
-            "sharing": [
-              {
-                "who": { "GuardIdentifier": 0 },
-                "sharing": 10000,
-                "mode": "Rate"
-              }
-            ]
-          }
-        ]
-      },
-      "sales": {
-        "op": "add",
-        "sales": [
-          {
-            "name": "Play Purse Set 35PCS",
-            "price": 50000000,
-            "stock": 100,
-            "suspension": false,
-            "wip": "https://raw.githubusercontent.com/wowok-ai/docs/main/wip-examples/three_body.wip",
-            "wip_hash": ""
-          },
-          {
-            "name": "Little Girls Purse with Accessories",
-            "price": 50000000,
-            "stock": 50,
-            "suspension": false,
-            "wip": "https://raw.githubusercontent.com/wowok-ai/docs/main/wip-examples/three_body.wip",
-            "wip_hash": ""
-          },
-          {
-            "name": "Tree House Building Set",
-            "price": 30000000,
-            "stock": 75,
-            "suspension": false,
-            "wip": "https://raw.githubusercontent.com/wowok-ai/docs/main/wip-examples/three_body.wip",
-            "wip_hash": ""
-          }
-        ]
-      },
-      "um": "myshop_aftersales_contact_v2",
-      "publish": true
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-**Important Notes:**
-- After publishing, `machine`, `order_allocators`, and `arbitrations` become **immutable**
-- Ensure your Guards and allocation logic are correct before publishing
-- The `sharing` value of `10000` represents 100% (rate mode uses 0-10000 scale)
-
----
-
-### Step 8: Update Product Pricing (Optional)
-
-To offer promotional pricing, update product prices using the `sales` operation with `op: "set"`:
-
-**Prompt**: Update the price of "Play Purse Set 35PCS" to 0.04 WOW for a promotion.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "service",
-    "data": {
-      "object": "myshop_service_v2",
-      "sales": {
-        "op": "set",
-        "sales": [
-          {
-            "name": "Play Purse Set 35PCS",
-            "price": 40000000,
-            "stock": 100,
-            "suspension": false,
-            "wip": "https://raw.githubusercontent.com/wowok-ai/docs/main/wip-examples/three_body.wip",
-            "wip_hash": ""
-          }
-        ]
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
----
-
-## Part 2: Customer Order Flow
-
-This section guides customers through browsing products, placing orders, and tracking progress.
-
-### Prerequisites
-
-Create a customer account:
-
-**Prompt**: Create a customer account named "myshop_customer".
-
-```json
-{
-  "tool": "account_operation",
-  "data": {
-    "gen": {
-      "name": "myshop_customer",
-      "replaceExistName": true
-    }
-  }
-}
-```
-
-**Get mainnet tokens:**
-
-**Prompt**: Transfer 1 WOW to account "myshop_customer" from a funded account for gas fees.
-
-```json
-{
-  "tool": "account_operation",
-  "data": {
-    "transfer": {
-      "name_or_address_to": "myshop_customer",
-      "amount": 1000000000,
-      "network": "mainnet"
-    }
-  }
-}
-```
-
-> **Note**: Ensure sufficient WOW balance for order payments plus gas fees. If needed, transfer additional tokens from a funded account.
-
----
-
-### Step 1: Query Service Products
-
-Customers can query the Service to see available products.
-
-**Prompt**: Query the Service "myshop_service_v2" to view available products and their details.
-
-```json
-{
-  "tool": "query_toolkit",
-  "data": {
-    "query_type": "onchain_objects",
-    "objects": ["myshop_service_v2"],
-    "no_cache": true
-  }
-}
-```
-
-> **AI Note**: Capture the `wip_hash` from the Service query result for each product. When the customer places an order, pass the captured `wip_hash` in `buy.items[].wip_hash`. **The `wip_hash` field cannot be an empty string** — it must match the hash stored in the Service. This is a dispute-prevention mechanism — the on-chain contract compares `item.wip_hash` against the Service's current `sale.wip_hash` to ensure the product hasn't been swapped between browse and purchase time.
-
----
-
-### Step 2: Create Order (Customer Purchase)
-
-Customer creates an order by purchasing products from the Service.
-
-**Prompt**: Create an order for customer "myshop_customer" to purchase "Play Purse Set 35PCS" from "myshop_service_v2" with payment of 0.05 WOW.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "service",
-    "data": {
-      "object": "myshop_service_v2",
-      "order_new": {
-        "buy": {
-          "items": [
-            {
-              "name": "Play Purse Set 35PCS",
-              "stock": 1,
-              "wip_hash": "<wip_hash captured from Step 1 query>"
-            }
-          ],
-          "total_pay": {
-            "balance": 50000000
-          }
-        },
-        "namedNewOrder": {
-          "name": "myshop_test_order",
-          "replaceExistName": true
-        },
-        "namedNewProgress": {
-          "name": "myshop_test_progress",
-          "replaceExistName": true
-        },
-        "namedNewAllocation": {
-          "name": "myshop_test_allocation",
-          "replaceExistName": true
-        }
-      }
-    },
-    "env": {
-      "account": "myshop_customer",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
----
-
-### Step 2.1: Send Shipping Address via Messenger (Privacy Protection)
-
-After creating the order, the customer sends their shipping address and contact information to the merchant's after-sales support team. This is done securely through the Messenger system to protect privacy - the information is never stored on-chain.
-
-```
-┌─────────────────────────────────────────────────────────────────────────────────────┐
-│                    Private Information Exchange via Messenger                       │
-├─────────────────────────────────────────────────────────────────────────────────────┤
-│                                                                                     │
-│   ┌──────────────────┐         End-to-End Encrypted          ┌──────────────────┐  │
-│   │                  │◄──────────────────────────────────────►│                  │  │
-│   │  myshop_customer │         Messenger Channel              │ myshop_merchant  │  │
-│   │  (Customer)      │         (Never on-chain)               │  (After-Sales    │  │
-│   │                  │                                        │   Support)      │  │
-│   └────────┬─────────┘                                        └────────┬─────────┘  │
-│            │                                                           │            │
-│            │ 1. Send shipping address                                  │            │
-│            │    - Full name                                            │            │
-│            │    - Phone number                                         │            │
-│            │    - Shipping address                                     │            │
-│            │    - Order reference ID                                   │            │
-│            │──────────────────────────────────────────────────────────►│            │
-│            │                                                           │            │
-│            │ 2. Receive confirmation                                   │            │
-│            │    - Address verified                                     │            │
-│            │    - Delivery ETA                                         │            │
-│            │    - Tracking number (when available)                     │            │
-│            │◄──────────────────────────────────────────────────────────│            │
-│            │                                                           │            │
-│   ┌────────▼─────────┐                                        ┌────────▼─────────┐  │
-│   │  Customer Info   │                                        │  Support System  │  │
-│   │  (Local Storage) │                                        │  (Local Storage) │  │
-│   └──────────────────┘                                        └──────────────────┘  │
-│                                                                                     │
-│   Privacy Guarantees:                                                               │
-│   - End-to-end encryption - Only customer and merchant can read                     │
-│   - No on-chain storage - Message content never touches blockchain                 │
-│   - Verifiable identity - Contact object confirms who you're talking to            │
-│                                                                                     │
-└─────────────────────────────────────────────────────────────────────────────────────┘
-```
-
-#### 2.1.1 Customer Enables Messenger
-
-**Prompt**: Enable messenger for customer account "myshop_customer" to send private messages.
-
-```json
-{
-  "tool": "account_operation",
-  "data": {
-    "messenger": {
-      "enabled": true,
-      "name_or_account": "myshop_customer"
-    }
-  }
-}
-```
-
-> **Note**: Same as merchant enable (Step 4.1): registration on the messenger server happens synchronously with the enable. Each party must enable messenger **in its own environment with its own account** — one side can never register the other.
-
-#### 2.1.2 Customer Sends Shipping Information
-
-**Prompt**: Customer "myshop_customer" sends shipping address and contact information to merchant "myshop_merchant" via encrypted messenger.
-
-```json
-{
-  "tool": "messenger_operation",
-  "data": {
-    "operation": "send_message",
-    "from": "myshop_customer",
-    "to": "myshop_merchant",
-    "content": "Order Shipping Information:\n\nOrder ID: 0xa6db...3d5\nProduct: Play Purse Set 35PCS\n\nRecipient: Zhang San\nPhone: 138-0000-0000\nAddress: Building 123, Unit 456, Room 789\n         Chaoyang District, Beijing\n         China, 100000\n\nPlease confirm receipt of this information."
-  }
-}
-```
-
-> **Note**: Replace the Order ID with your actual order object address from Step 2.
->
-> **Spam Protection**: The Messenger server allows only ONE message to a stranger (non-friend) before the recipient must reply. If the customer already sent an initial message to the merchant, the merchant must reply first before the customer can send additional messages. Once both parties have exchanged messages, they become "friends" and can send unlimited messages. If you encounter "Spam protection denied: You can only send one stranger message, wait for recipient to reply", have the merchant send a reply first.
-
-#### 2.1.3 Merchant Confirms Receipt
-
-**Prompt**: Merchant "myshop_merchant" views the message and sends confirmation to customer.
-
-```json
-{
-  "tool": "messenger_operation",
-  "data": {
-    "operation": "send_message",
-    "from": "myshop_merchant",
-    "to": "myshop_customer",
-    "content": "Dear Customer,\n\nWe have received your shipping information:\n- Order ID: 0xa6db...3d5 confirmed\n- Shipping address verified\n- Contact phone: 138-0000-0000\n\nYour order will be processed within 24 hours. We'll send you the tracking number once shipped.\n\nThank you for shopping with MyShop!"
-  }
-}
-```
-
-#### 2.1.4 View Conversation History
-
-**Prompt**: View the conversation between customer and merchant to confirm both messages were delivered.
-
-```json
-{
-  "tool": "messenger_operation",
-  "data": {
-    "operation": "watch_messages",
-    "filter": {
-      "peerAddress": "myshop_merchant",
-      "account": "myshop_customer"
-    }
-  }
-}
-```
-
----
-
-### Step 3: Query Order Status
-
-Customer can query the order status and progress.
-
-**Prompt**: Query the order "myshop_test_order" to check its current status and progress.
-
-```json
-{
-  "tool": "query_toolkit",
-  "data": {
-    "query_type": "onchain_objects",
-    "objects": ["myshop_test_order"],
-    "no_cache": true
-  }
-}
-```
-
----
-
-### Step 4: Query Progress Status
-
-Check the current workflow node of the order.
-
-**Prompt**: Query the Progress "myshop_test_progress" to see the current workflow node.
-
-```json
-{
-  "tool": "query_toolkit",
-  "data": {
-    "query_type": "onchain_objects",
-    "objects": ["myshop_test_progress"],
-    "no_cache": true
-  }
-}
-```
-
----
-
-### Step 5: Merchant Confirms Order
-
-Merchant advances the order from initial state to "Order Confirmation" node.
-
-> **Note**: Use `operation_type: "progress"` with `operate` to advance the workflow. The order is created with an empty initial node "", and the first step is to transition to "Order Confirmation" using "Confirm Order" forward.
-
-**Prompt**: Advance the order "myshop_test_order" progress from initial state to "Order Confirmation" using the "Confirm Order" forward.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "progress",
-    "data": {
-      "object": "myshop_test_progress",
-      "operate": {
-        "operation": {
-          "next_node_name": "Order Confirmation",
-          "forward": "Confirm Order"
-        },
-        "op": "next",
-        "message": "Order confirmed by merchant"
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
----
-
-### Step 6: Merchant Ships Order
-
-Merchant ships the order and advances from "Order Confirmation" to "Shipping".
-
-**Prompt**: Advance the order progress from "Order Confirmation" to "Shipping" using the "Ship Goods" forward.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "progress",
-    "data": {
-      "object": "myshop_test_progress",
-      "operate": {
-        "operation": {
-          "next_node_name": "Shipping",
-          "forward": "Ship Goods"
-        },
-        "op": "next",
-        "message": "Goods shipped via express delivery"
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
----
-
-### Step 7: Confirm Delivery
-
-Merchant or delivery service confirms the order has been delivered.
-
-**Prompt**: Advance the order progress from "Shipping" to "In Transit" using the "Confirm Delivery" forward.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "progress",
-    "data": {
-      "object": "myshop_test_progress",
-      "operate": {
-        "operation": {
-          "next_node_name": "In Transit",
-          "forward": "Confirm Delivery"
-        },
-        "op": "next",
-        "message": "Goods delivered successfully"
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
----
-
-### Step 8: Customer Completes Order
-
-Customer confirms receipt and completes the order.
-
-**Prompt**: Customer "myshop_customer" completes the order by advancing from "In Transit" to "Completed" node using "Complete Order" forward.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "progress",
-    "data": {
-      "object": "myshop_test_progress",
-      "operate": {
-        "operation": {
-          "next_node_name": "Completed",
-          "forward": "Complete Order"
-        },
-        "op": "next",
-        "message": "Order received and completed"
-      }
-    },
-    "env": {
-      "account": "myshop_customer",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
----
-
-### Step 9: Merchant Withdraws Funds
-
-After order completion, the merchant needs to:
-1. Activate the Allocation by verifying the Guard (order completion status)
-2. Withdraw funds from the Service
-
-#### 7.1 Activate Allocation (Guard Verification)
-
-First, activate the Allocation by submitting the Guard verification with the Order ID.
-
-> **Note**: The `alloc_by_guard` and `submission` fields require the actual Guard object address (0x...), not the local name. You can obtain the Guard address from the local mark list or by querying the Guard name.
-
-**Prompt**: Activate allocation "myshop_test_allocation" by verifying the withdraw guard with order "myshop_test_order".
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "allocation",
-    "data": {
-      "object": "myshop_test_allocation",
-      "alloc_by_guard": "0x5af9...1074"
-    },
-    "submission": {
-      "type": "submission",
-      "guard": [
-        {
-          "object": "0x5af9...1074",
-          "impack": true
-        }
-      ],
-      "submission": [
-        {
-          "guard": "0x5af9...1074",
-          "submission": [
-            {
-              "identifier": 0,
-              "b_submission": true,
-              "value_type": "Address",
-              "value": "0xa6db...3d5",
-              "name": "order_address"
-            }
-          ]
-        }
-      ]
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true,
-      "no_cache": true
-    }
-  }
-}
-```
-
-> **Note**: Replace the Guard address `0x5af9...1074` and Order address `0xa6db...3d5` with your actual object addresses. Use the full 64-character addresses in actual operations.
-
-#### 7.2 Withdraw Funds (Unwrap the Merchant's CoinWrapper)
-
-The allocator's recipient is `{"Signer": "signer"}`, so the Allocation pays out via a **CoinWrapper transferred directly to the merchant account** (an owned object of the merchant EOA) — NOT to the Service object. Therefore `owner_receive` on the Service cannot collect this payout. Instead, find the CoinWrapper received by the merchant account and unwrap it into spendable coins.
-
-**Step a**: Query the merchant account's received objects to find the payout CoinWrapper.
-
-**Prompt**: Query objects recently received by account "myshop_merchant" to find the allocation payout CoinWrapper.
-
-```json
-{
-  "tool": "query_toolkit",
-  "data": {
-    "query_type": "onchain_received",
-    "name_or_address": "myshop_merchant",
-    "type": "CoinWrapper",
-    "network": "mainnet"
-  }
-}
-```
-
-**Step b**: Unwrap the CoinWrapper into WOW coins in the merchant's wallet.
-
-**Prompt**: Merchant "myshop_merchant" unwraps the received CoinWrapper "0x1234...abcd" into WOW coins.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "payment",
-    "data": {
-      "object": "0x1234...abcd",
-      "receive": true,
-      "type_parameter": "0x2::wow::WOW"
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: Replace `0x1234...abcd` with the actual CoinWrapper object ID found in Step a (use the full 64-character address). The caller must be the CoinWrapper's owner — the allocation's `Signer` recipient (the merchant).
-
----
-
-## Alternative Flow: Order Cancellation
-
-### Customer Cancels Order
-
-Customer can cancel the order after the merchant confirms it. The "Cancel Order" forward transitions from "Order Confirmation" to "Cancelled". This requires the merchant to first confirm the order (advancing from the initial state "" to "Order Confirmation").
-
-**Step 1**: Merchant confirms the order (advances from "" to "Order Confirmation"):
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "progress",
-    "data": {
-      "object": "myshop_test_progress",
-      "operate": {
-        "operation": {
-          "next_node_name": "Order Confirmation",
-          "forward": "Confirm Order"
-        },
-        "op": "next",
-        "message": "Order confirmed by merchant"
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-**Step 2**: Customer cancels the order (advances from "Order Confirmation" to "Cancelled"):
-
-**Prompt**: Customer "myshop_customer" cancels the order after merchant confirmation.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "progress",
-    "data": {
-      "object": "myshop_test_progress",
-      "operate": {
-        "operation": {
-          "next_node_name": "Cancelled",
-          "forward": "Cancel Order"
-        },
-        "op": "next",
-        "message": "Order cancelled by customer"
-      }
-    },
-    "env": {
-      "account": "myshop_customer",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: Cancellation can only be done from the "Order Confirmation" state (after the merchant confirms the order, but before shipping). Once the order is shipped, cancellation is no longer possible through this forward.
-
-### Customer Refund After Cancellation
-
-After the order is cancelled, the customer can activate the refund allocation using the refund guard:
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "allocation",
-    "data": {
-      "object": "myshop_test_allocation",
-      "alloc_by_guard": "0x5792...5d2c"
-    },
-    "submission": {
-      "type": "submission",
-      "guard": [
-        {
-          "object": "0x5792...5d2c",
-          "impack": true
-        }
-      ],
-      "submission": [
-        {
-          "guard": "0x5792...5d2c",
-          "submission": [
-            {
-              "identifier": 0,
-              "b_submission": true,
-              "value_type": "Address",
-              "value": "0xa6db...3d5",
-              "name": "order_address"
-            }
-          ]
-        }
-      ]
-    },
-    "env": {
-      "account": "myshop_customer",
-      "network": "mainnet",
-      "confirmed": true,
-      "no_cache": true
-    }
-  }
-}
-```
-
-> **Note**: Replace the Guard address `0x5792...5d2c` and Order address `0xa6db...3d5` with your actual object addresses.
-
-The refund Allocation escrows the refunded funds to the Order address. Finally, the customer claims them from the Order:
-
-**Prompt**: Customer "myshop_customer" claims the refunded funds from order "myshop_test_order".
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "order",
-    "data": {
-      "object": "myshop_test_order",
-      "receive": "recently"
-    },
-    "env": {
-      "account": "myshop_customer",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: `receive: "recently"` unwraps all objects recently received by the Order (including the refund CoinWrapper) and transfers them to the order owner (the customer).
-
----
-
-## Alternative Flow: Dispute and Arbitration
-
-This flow handles order disputes through a formal arbitration process. The arbitration state machine has these statuses:
-- 0: Principal_confirming (after reset)
-- 1: Arbitrator_confirming (after dispute submitted)
-- 2: Voting (after materials confirmed)
-- 3: Arbitrated (after arbitration result provided)
-- 4: Objectionable (if principal objects)
-- 5: Finished (after compensation claimed)
-- 6: Withdrawn (30 days after arbitrated)
-
-### Step 1: Service Compensation Fund Setup
-
-The Service must have a compensation fund balance ≥ the arbitration indemnity amount. The merchant pre-funds this before any disputes.
-
-**Prompt**: Merchant adds 0.05 WOW to the Service compensation fund.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "service",
-    "data": {
-      "object": "myshop_service_v2",
-      "compensation_fund_add": {"balance": 50000000}
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-### Step 2: Create Independent Arbitration Permission
-
-The on-chain contract REQUIRES the Arbitration's Permission to be DIFFERENT from the Service's Permission — binding an Arbitration that shares the Service's Permission aborts the transaction with E_ARBITRATION_PERMISSION_CONFLICT (error 33). Create a dedicated Permission object for arbitration first.
-
-**Prompt**: Create a Permission object named "myshop_arbitration_permission" for dispute arbitration.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "permission",
-    "data": {
-      "object": {
-        "name": "myshop_arbitration_permission",
-        "tags": ["ecommerce", "dispute", "arbitration"],
-        "onChain": false,
-        "replaceExistName": true
-      },
-      "description": "Permission management for MyShop dispute arbitration"
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-### Step 3: Create Arbitration Object
-
-Create an Arbitration object for handling order disputes. It MUST use the independent arbitration Permission created in Step 2 (NOT the Service's "myshop_permission_v2").
-
-**Prompt**: Create an Arbitration object named "myshop_arbitration_v2" with permission "myshop_arbitration_permission" for dispute resolution.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "arbitration",
-    "data": {
-      "object": {
-        "name": "myshop_arbitration_v2",
-        "type_parameter": "0x2::wow::WOW",
-        "permission": "myshop_arbitration_permission",
-        "tags": ["ecommerce", "dispute", "toys"],
-        "onChain": false
-      },
-      "description": "Arbitration system for MyShop toy store disputes",
-      "location": "Online arbitration system",
-      "fee": 5000000
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: New Arbitration objects are created with `bPaused: true` by default. You must unpause it in the next step before submitting disputes.
-
-### Step 4: Unpause the Arbitration Object
-
-The merchant unpauses the Arbitration object to enable dispute submissions.
-
-**Prompt**: Merchant unpauses the Arbitration object "myshop_arbitration_v2".
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "arbitration",
-    "data": {
-      "object": "myshop_arbitration_v2",
-      "pause": false
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-### Step 5: Bind Arbitration to the Service
-
-Bind the Arbitration object to the Service so that orders on this Service can be disputed through it. Adding arbitrations is an L3 operation — it remains allowed even after the Service is published (only remove/clear requires pause + lock duration).
-
-**Prompt**: Merchant binds arbitration "myshop_arbitration_v2" to service "myshop_service_v2".
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "service",
-    "data": {
-      "object": "myshop_service_v2",
-      "arbitrations": {
-        "op": "add",
-        "objects": ["myshop_arbitration_v2"]
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-### Step 6: Create a Dispute Order
-
-Create a new order for testing the arbitration flow (if you don't have one already).
-
-**Prompt**: Customer "myshop_customer" creates a new order for "Tree House Building Set" for arbitration testing.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "service",
-    "data": {
-      "object": "myshop_service_v2",
-      "order_new": {
-        "buy": {
-          "items": [
-            {
-              "name": "Tree House Building Set",
-              "stock": 1,
-              "wip_hash": "<wip_hash captured from Step 1 query>"
-            }
-          ],
-          "total_pay": {"balance": 30000000}
-        },
-        "namedNewOrder": {"name": "myshop_arb_order", "replaceExistName": true},
-        "namedNewProgress": {"name": "myshop_arb_progress", "replaceExistName": true},
-        "namedNewAllocation": {"name": "myshop_arb_allocation", "replaceExistName": true}
-      }
-    },
-    "env": {
-      "account": "myshop_customer",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: The `wip_hash` must be obtained from the Service query result (Step 1 of Part 2). It cannot be omitted or set to an empty string — the on-chain contract validates it against the Service's current `sale.wip_hash`.
-
-### Step 7: Customer Submits Dispute
-
-The customer submits a dispute against the order, creating an Arb object.
-
-**Prompt**: Customer "myshop_customer" submits a dispute for order "myshop_arb_order" using arbitration "myshop_arbitration_v2".
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "arbitration",
-    "data": {
-      "object": "myshop_arbitration_v2",
-      "dispute": {
-        "order": "myshop_arb_order",
-        "description": "Product quality issue - the tree house set arrived damaged",
-        "proposition": ["Full refund to customer", "Partial refund 50%", "Replace with new product"],
-        "fee": {"balance": 5000000},
-        "namedArb": {"name": "myshop_arb_case", "replaceExistName": true}
-      }
-    },
-    "env": {
-      "account": "myshop_customer",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: The dispute fee (5000000 = 0.005 WOW) must be ≥ the Arbitration object's fee setting. The Arb object is created with status=1 (Arbitrator_confirming).
-
-### Step 8: Merchant Confirms Materials
-
-The merchant confirms the dispute materials are valid and sets the voting deadline.
-
-**Prompt**: Merchant "myshop_merchant" confirms the dispute materials for Arb "myshop_arb_case" with voting_deadline 0 (voting impossible — the arbitrator can provide the verdict immediately).
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "arbitration",
-    "data": {
-      "object": "myshop_arbitration_v2",
-      "confirm": {
-        "arb": "myshop_arb_case",
-        "voting_deadline": 0
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: `voting_deadline` accepts a Unix timestamp in **milliseconds**, `0`, or `null`. `0` (used here) sets the deadline in the past — voting is impossible, so the arbitrator can provide the verdict immediately. `null` means open-ended voting with no deadline — the verdict can also be provided at any time, but voting remains possible until then. To set a specific deadline, use a future Unix timestamp in milliseconds (e.g., `Date.now() + 86400000` for 24 hours).
-
-### Step 9: Merchant Provides Arbitration Result
-
-The merchant provides the final arbitration result with feedback and indemnity amount.
-
-**Prompt**: Merchant "myshop_merchant" provides arbitration result for Arb "myshop_arb_case" with 0.03 WOW indemnity.
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "arbitration",
-    "data": {
-      "object": "myshop_arbitration_v2",
-      "arbitration": {
-        "arb": "myshop_arb_case",
-        "feedback": "After investigation, the product quality issue is confirmed. Full refund to customer and return shipping cost covered by merchant.",
-        "indemnity": 30000000
-      }
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: The Arb status changes to 3 (Arbitrated). The indemnity amount must be ≤ the Service's compensation_fund balance.
-
-### Step 10: Customer Claims Compensation
-
-The customer claims the compensation from the Service's compensation fund.
-
-**Prompt**: Customer "myshop_customer" claims compensation for order "myshop_arb_order" from Arb "myshop_arb_case".
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "order",
-    "data": {
-      "object": "myshop_arb_order",
-      "arb_claim_compensation": {
-        "arb": "myshop_arb_case"
-      }
-    },
-    "env": {
-      "account": "myshop_customer",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-> **Note**: The customer receives the indemnity amount (0.03 WOW) from the Service's compensation fund. The Arb status changes to 5 (Finished). The Order's `claimed_by` field is updated with the Arb address.
-
-### Step 11: Query Arbitration Status
-
-Check the final status of the arbitration.
-
-**Prompt**: Query the Arb "myshop_arb_case" to verify the arbitration is finished.
-
-```json
-{
-  "tool": "query_toolkit",
-  "data": {
-    "query_type": "onchain_objects",
-    "objects": ["myshop_arb_case"],
-    "no_cache": true,
-    "network": "mainnet"
-  }
-}
-```
-
-The Arb should have `status: 5` (Finished) with `compensation_time` set.
-
----
-
-## Summary
-
-This MyShop e-commerce example demonstrates:
-
-1. **Merchant Setup**:
-   - Permission management for access control
-   - Machine workflow for order processing with visual flow diagram
-   - Contact objects for after-sales support
-   - Guard creation for fund allocation validation
-   - Service creation with products and pricing
-
-2. **Customer Flow**:
-   - Product browsing and selection
-   - Order creation with payment
-   - Private information exchange via Messenger (shipping address, phone number)
-   - Progress tracking through workflow nodes
-   - Order completion and payment release
-
-3. **Privacy & Security Features**:
-   - End-to-end encrypted messaging for sensitive information
-   - Contact-based identity verification
-   - No private data stored on-chain
-
-4. **Alternative Flows**:
-   - Order cancellation after confirmation (from "Order Confirmation" state)
-   - Customer refund after cancellation (via Guard-protected Allocation)
-   - Dispute submission and arbitration process (7-step state machine)
-   - Compensation claim from Service compensation fund
-
-All operations use the WoWok SDK patterns with JSON-based sub-tool calls, making it easy for AI agents to interact with the blockchain e-commerce system.
-
----
-
-## Workflow Advancement Notes
-
-When advancing order workflows, use `operation_type: "progress"` with the `operate` field for all workflow transitions:
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "progress",
-    "data": {
-      "object": "myshop_test_progress",
-      "operate": {
-        "operation": {
-          "next_node_name": "Target Node Name",
-          "forward": "Forward Name"
-        },
-        "op": "next",
-        "message": "Operation description"
-      }
-    },
-    "env": {
-      "account": "operator_account",
-      "network": "mainnet",
-      "confirmed": true
-    }
-  }
-}
-```
-
-The Progress object ID can be obtained from:
-- Order object's `progress` field
-- Named during order creation with `namedNewProgress`
-
-The operator account depends on the forward definition:
-- Forwards with `permissionIndex` require the merchant account (with appropriate permission)
-- Forwards with `namedOperator: ""` allow the order owner (customer) to operate
-
----
-
-## Object Reference Summary
-
-| Object Type | Name | Purpose |
-|-------------|------|---------|
-| Account | myshop_merchant | Store owner account |
-| Account | myshop_customer | Customer account |
-| Permission | myshop_permission_v2 | Access control management |
-| Permission | myshop_arbitration_permission | Arbitration access control (must differ from Service permission) |
-| Guard | myshop_withdraw_guard_v2 | Merchant withdrawal validation (order completed) |
-| Guard | myshop_refund_guard_v2 | Customer refund validation (order cancelled) |
-| Machine | myshop_machine_v2 | Order processing workflow |
-| Contact | myshop_aftersales_contact_v2 | After-sales support contact |
-| Service | myshop_service_v2 | Online store with products |
-| Arbitration | myshop_arbitration_v2 | Dispute resolution (optional) |
-| Order | myshop_test_order | Customer purchase order (dynamic) |
-| Progress | myshop_test_progress | Order workflow progress (dynamic) |
-| Allocation | myshop_test_allocation | Order fund allocation (dynamic) |
-
----
-
-## Next Steps
-
-- Extend the workflow with more nodes (e.g., "Return Goods", "Refund Processing")
-- Add more complex Guards for conditional transitions
-- Implement WIP files for product verification
-- Set up Repository for order data storage
-- Add WTS generation for messenger conversation records
-- Implement file sharing via Messenger (shipping labels, invoices)
-- Add blacklist/guardlist management for spam prevention
-- Create automated notification system for order status updates
-
----
-
-## Notes
-
-- All addresses shown in examples are truncated for readability (format: 0xabcd...efgh)
-- Use the full 64-character address in actual operations
-- Deploy and run on mainnet
-- Ensure sufficient WOW tokens for transaction fees