@wowok/skills 1.1.9 → 1.1.10

package/examples/MyShop/MyShop.md

@@ -2,8 +2,6 @@
 
 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.
 
-> 📋 **View Actual Execution Results**: See [MyShop_TestResults.md](MyShop_TestResults.md) for real testnet execution results with actual object addresses and transaction outputs.
-
 ---
 
 ## Core Requirements & Features
@@ -15,7 +13,6 @@ A complete e-commerce example demonstrating how to build an online store using W
 | **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 |
-| **Discount System** | Coupon and promotional code support | Discount object with time-limited offers |
 | **Customer Communication** | Secure messaging between merchant and customer | Contact objects for pre-sales and after-sales support |
 
 ### Key Design Decisions
@@ -54,8 +51,7 @@ This example demonstrates a toy store e-commerce system with the following featu
 │  │ • Machine (Workflow)    │    │ • Create Order          │                │
 │  │ • Service (Products)    │◄──►│ • Send Private Info(*)  │                │
 │  │ • Allocation (Payment)  │    │ • Track Progress        │                │
-│  │ • Discount (Coupons)    │    │ • Order Complete        │                │
-│  │ • Contact (Messaging)   │    │ • Receive Goods         │                │
+│  │ • Contact (Messaging)   │    │ • Order Complete        │                │
 │  └─────────────────────────┘    └─────────────────────────┘                │
 │                                                                             │
 │  Optional: Arbitration (Dispute Resolution)                                 │
@@ -73,13 +69,13 @@ This example demonstrates a toy store e-commerce system with the following featu
 └──────────────┘     └──────────────┘     └──────────────┘     └──────────────┘
        │                                                            │
        │                    ┌──────────────┐                        │
-       └───────────────────►│  Order End   │◄───────────────────────┘
+       └───────────────────►│  Cancelled   │◄───────────────────────┘
          (Cancel Order)     │(Final State) │    (Complete Order)
                             └──────────────┘
 ```
 
-**Normal Flow**: Order Confirmation → Shipping → In Transit → Completed → Order End  
-**Alternative**: Order Confirmation → Cancel Order → Order End (if cancelled)
+**Normal Flow**: Order Confirmation → Shipping → In Transit → Completed  
+**Alternative**: Order Confirmation → Cancelled (if customer cancels before shipping)
 
 ---
 
@@ -100,7 +96,8 @@ Before starting, ensure you have:
 ```json
 {
   "gen": {
-    "name": "myshop_merchant"
+    "name": "myshop_merchant",
+    "replaceExistName": true
   }
 }
 ```
@@ -133,7 +130,8 @@ First, create a Permission object to manage access control for your store operat
     "object": {
       "name": "myshop_permission_v2",
       "tags": ["ecommerce", "toys", "shop"],
-      "onChain": false
+      "onChain": false,
+      "replaceExistName": true
     },
     "description": "Permission management for MyShop toy store"
   },
@@ -158,7 +156,8 @@ Create a Machine to define the order processing workflow. This includes nodes fo
   "data": {
     "object": {
       "name": "myshop_machine_v2",
-      "permission": "myshop_permission_v2"
+      "permission": "myshop_permission_v2",
+      "replaceExistName": true
     },
     "description": "Order processing workflow for MyShop toy store"
   },
@@ -171,7 +170,7 @@ Create a Machine to define the order processing workflow. This includes nodes fo
 
 ---
 
-### Step 3.1: Machine Workflow Design
+### Step 3: Machine Workflow Design
 
 Before adding nodes, let's understand the order processing workflow:
 
@@ -246,10 +245,10 @@ Before adding nodes, let's understand the order processing workflow:
 │            │                      │                                               │  │
 │            │                      ▼                                               │  │
 │            │               ┌──────────────┐                                       │  │
-│            │               │   Order End  │                                       │  │
-│            │               │  (Final State)                                       │  │
+│            │               │  Cancelled   │                                       │  │
+│            │               │ (Final State)│                                       │  │
 │            │               └──────────────┘                                       │  │
-│            │                                                                       │
+│            │                                                                       │  │
 │            └───────────────────────────────────────────────────────────────────────┘
 │                                                                                     │
 │   Legend:                                                                           │
@@ -263,10 +262,11 @@ Before adding nodes, let's understand the order processing workflow:
 
 | Node | Name | Description | Threshold | Forwards |
 |------|------|-------------|-----------|----------|
-| 1 | Order Confirmation | Initial state after order creation | 0 | Confirm Order (Merchant), Cancel Order (Customer) |
+| 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
@@ -281,9 +281,9 @@ Before adding nodes, let's understand the order processing workflow:
 
 ### Step 4: Add Workflow Nodes
 
-Add the workflow nodes to the Machine for order processing.
+Add the workflow nodes to the Machine for order processing. The initial pair (prev_node: "") defines transitions from the empty starting state.
 
-**Prompt**: Add workflow nodes to "myshop_machine_v2" including Order Confirmation, Shipping, In Transit, and Completed nodes.
+**Prompt**: Add workflow nodes to "myshop_machine_v2" including Order Confirmation, Shipping, In Transit, Completed, and Cancelled nodes.
 
 ```json
 {
@@ -304,10 +304,16 @@ Add the workflow nodes to the Machine for order processing.
                   "name": "Confirm Order",
                   "permissionIndex": 1000,
                   "weight": 1
-                },
+                }
+              ]
+            },
+            {
+              "prev_node": "Order Confirmation",
+              "threshold": 1,
+              "forwards": [
                 {
-                  "name": "Cancel Order",
-                  "namedOperator": "",
+                  "name": "Ship Goods",
+                  "permissionIndex": 1001,
                   "weight": 1
                 }
               ]
@@ -361,6 +367,22 @@ Add the workflow nodes to the Machine for order processing.
               ]
             }
           ]
+        },
+        {
+          "name": "Cancelled",
+          "pairs": [
+            {
+              "prev_node": "Order Confirmation",
+              "threshold": 0,
+              "forwards": [
+                {
+                  "name": "Cancel Order",
+                  "namedOperator": "",
+                  "weight": 1
+                }
+              ]
+            }
+          ]
         }
       ]
     }
@@ -372,6 +394,8 @@ Add the workflow nodes to the Machine for order processing.
 }
 ```
 
+> **Note**: The "Cancel Order" forward is defined on the "Cancelled" node with `prev_node: "Order Confirmation"`. This means cancellation can only happen AFTER the merchant confirms the order (transitions from "Order Confirmation" to "Cancelled"). The "Cancelled" node is a terminal state with no further forwards.
+
 ---
 
 ### Step 5: Publish the Machine
@@ -393,13 +417,14 @@ Publish the Machine to make it available for creating orders.
   }
 }
 ```
+
 ---
 
-### Step 5.1: Create Contact Object for Customer Service
+### Step 6: Create Contact Object for Customer Service
 
 Create a Contact object to enable encrypted communication between customers and the store for after-sales support.
 
-#### 5.1.1 Enable Merchant Messenger
+#### 6.1 Enable Merchant Messenger
 
 **Prompt**: Enable messenger for the merchant account.
 
@@ -412,7 +437,7 @@ Create a Contact object to enable encrypted communication between customers and
 }
 ```
 
-#### 5.1.2 Create After-Sales Contact Object
+#### 6.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.
 
@@ -422,7 +447,8 @@ Create a Contact object to enable encrypted communication between customers and
   "data": {
     "object": {
       "name": "myshop_aftersales_contact_v2",
-      "permission": "myshop_permission_v2"
+      "permission": "myshop_permission_v2",
+      "replaceExistName": true
     },
     "description": "MyShop after-sales support contact - we're here to help with orders, shipping, and returns",
     "ims": {
@@ -442,17 +468,19 @@ Create a Contact object to enable encrypted communication between customers and
 }
 ```
 
+> **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 6: Create Allocation Guards
+### Step 7: Create Guards for Fund Allocation
 
-Before creating the Service, you need Guards for order fund allocation. These Guards validate when funds can be withdrawn by the merchant or refunded to customers.
+Before creating the Service, create Guards that validate fund allocation conditions. These Guards ensure funds are only released when specific conditions are met.
 
-#### 6.1 Create Merchant Withdraw Guard
+#### 7.1 Create Withdraw Guard (Merchant Withdrawal)
 
-This Guard checks if the order has reached "Completed" status before allowing the merchant to withdraw funds.
+Create a Guard that validates the order's Progress has reached the "Completed" node. This Guard uses `convert_witness: 100` (TypeOrderProgress) to query the Order's associated Progress object.
 
-**Prompt**: Create a Guard named "myshop_withdraw_guard_v2" that verifies the order is in "Completed" status.
+**Prompt**: Create a Guard named "myshop_withdraw_guard_v2" that verifies the order is completed before allowing merchant withdrawal.
 
 ```json
 {
@@ -460,15 +488,17 @@ This Guard checks if the order has reached "Completed" status before allowing th
   "data": {
     "namedNew": {
       "name": "myshop_withdraw_guard_v2",
-      "tags": ["ecommerce", "withdraw", "merchant"]
+      "tags": ["order", "completed", "withdraw"],
+      "onChain": false,
+      "replaceExistName": true
     },
-    "description": "Verify order is completed before merchant can withdraw funds. Submit order object ID.",
+    "description": "Verify order progress is at Completed node for merchant withdrawal",
     "table": [
       {
         "identifier": 0,
         "b_submission": true,
         "value_type": "Address",
-        "name": "order_id"
+        "name": "order_address"
       },
       {
         "identifier": 1,
@@ -479,25 +509,22 @@ This Guard checks if the order has reached "Completed" status before allowing th
       }
     ],
     "root": {
-      "type": "node",
-      "node": {
-        "type": "logic_equal",
-        "nodes": [
-          {
-            "type": "query",
-            "query": 1253,
-            "object": {
-              "identifier": 0,
-              "convert_witness": 100
-            },
-            "parameters": []
+      "type": "logic_equal",
+      "nodes": [
+        {
+          "type": "query",
+          "query": 1253,
+          "object": {
+            "identifier": 0,
+            "convert_witness": 100
           },
-          {
-            "type": "identifier",
-            "identifier": 1
-          }
-        ]
-      }
+          "parameters": []
+        },
+        {
+          "type": "identifier",
+          "identifier": 1
+        }
+      ]
     }
   },
   "env": {
@@ -507,16 +534,20 @@ This Guard checks if the order has reached "Completed" status before allowing th
 }
 ```
 
-**How it works:**
-- Uses `convert_witness: 100` (TypeOrderProgress) to access the order's Progress object
-- Query ID `1253` (`progress.current`) retrieves the current node name
-- Compares with "Completed" to verify order status
+**Guard Explanation:**
+- **Table Item 0**: Order address (submitted when activating allocation)
+- **Table Item 1**: Constant string "Completed" (the target node name)
+- **convert_witness: 100**: TypeOrderProgress - converts Order to its associated Progress
+- **Query "progress.current"**: Returns the current node name of the Progress
+- **logic_equal**: Verifies current node equals "Completed"
 
-#### 6.2 Create Customer Refund Guard
+> **Note**: The Guard `root` field directly specifies the GuardNode (e.g., `type: "logic_equal"`), not wrapped in a `type: "node"` object.
 
-For scenarios where customers need refunds before order completion.
+#### 7.2 Create Refund Guard (Customer Refund)
 
-**Prompt**: Create a Guard named "myshop_refund_guard_v2" for customer refund scenarios.
+Create a Guard for customer refunds when order is cancelled.
+
+**Prompt**: Create a Guard named "myshop_refund_guard_v2" for customer refund validation.
 
 ```json
 {
@@ -524,44 +555,43 @@ For scenarios where customers need refunds before order completion.
   "data": {
     "namedNew": {
       "name": "myshop_refund_guard_v2",
-      "tags": ["ecommerce", "refund", "customer"]
+      "tags": ["order", "cancelled", "refund"],
+      "onChain": false,
+      "replaceExistName": true
     },
-    "description": "Allow refund for orders not yet shipped. Submit order object ID.",
+    "description": "Verify order progress is at Cancelled node for customer refund",
     "table": [
       {
         "identifier": 0,
         "b_submission": true,
         "value_type": "Address",
-        "name": "order_id"
+        "name": "order_address"
       },
       {
         "identifier": 1,
         "b_submission": false,
         "value_type": "String",
-        "value": "Order Confirmation",
-        "name": "confirmation_node"
+        "value": "Cancelled",
+        "name": "cancelled_node"
       }
     ],
     "root": {
-      "type": "node",
-      "node": {
-        "type": "logic_equal",
-        "nodes": [
-          {
-            "type": "query",
-            "query": 1253,
-            "object": {
-              "identifier": 0,
-              "convert_witness": 100
-            },
-            "parameters": []
+      "type": "logic_equal",
+      "nodes": [
+        {
+          "type": "query",
+          "query": 1253,
+          "object": {
+            "identifier": 0,
+            "convert_witness": 100
           },
-          {
-            "type": "identifier",
-            "identifier": 1
-          }
-        ]
-      }
+          "parameters": []
+        },
+        {
+          "type": "identifier",
+          "identifier": 1
+        }
+      ]
     }
   },
   "env": {
@@ -570,15 +600,16 @@ For scenarios where customers need refunds before order completion.
   }
 }
 ```
+
 ---
 
-### Step 7: Create Service (Store)
+### Step 8: Create Service (Store)
 
 Create the Service object that represents your online store with products. This step binds all previously created components together.
 
-> **Important**: For Service creation, you need to provide a complete configuration including machine, order_allocators with Guards, and products. The Service will be created and published in a single transaction.
+> **Important**: For Service creation, provide a complete configuration including machine, order_allocators with Guards, and products. The Service will be created and published in a single transaction.
 
-#### 7.1 Understanding Order Allocators
+#### 8.1 Understanding Order Allocators
 
 The `order_allocators` configuration defines how order payments are distributed:
 
@@ -591,10 +622,12 @@ The `order_allocators` configuration defines how order payments are distributed:
 
 **Recipient Types:**
 - `{ "Signer": "signer" }` - Transaction sender (merchant)
-- `{ "Entity": { "address": "..." } }` - Specific address
+- `{ "Entity": { "name_or_address": "..." } }` - Specific address or account name
 - `{ "GuardIdentifier": 0 }` - Address from Guard table
 
-#### 7.2 Create and Publish Service
+> **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.
+
+#### 8.2 Create and Publish Service
 
 **Prompt**: Create and publish a Service named "myshop_service_v2" with machine "myshop_machine_v2", order allocation using Guards, after-sales contact, and toy products.
 
@@ -607,7 +640,8 @@ The `order_allocators` configuration defines how order payments are distributed:
       "type_parameter": "0x2::wow::WOW",
       "permission": "myshop_permission_v2",
       "tags": ["ecommerce", "toys", "store"],
-      "onChain": false
+      "onChain": false,
+      "replaceExistName": true
     },
     "description": "MyShop - Top quality toys for children",
     "location": "Online Store",
@@ -646,7 +680,7 @@ The `order_allocators` configuration defines how order payments are distributed:
           "price": 3000000000,
           "stock": 100,
           "suspension": false,
-          "wip": "",
+          "wip": "https://wowok.net/test/three_body.wip",
           "wip_hash": ""
         },
         {
@@ -654,7 +688,7 @@ The `order_allocators` configuration defines how order payments are distributed:
           "price": 5000000000,
           "stock": 50,
           "suspension": false,
-          "wip": "",
+          "wip": "https://wowok.net/test/three_body.wip",
           "wip_hash": ""
         },
         {
@@ -662,7 +696,7 @@ The `order_allocators` configuration defines how order payments are distributed:
           "price": 2000000000,
           "stock": 75,
           "suspension": false,
-          "wip": "",
+          "wip": "https://wowok.net/test/three_body.wip",
           "wip_hash": ""
         }
       ]
@@ -677,34 +711,36 @@ The `order_allocators` configuration defines how order payments are distributed:
 }
 ```
 
-⚠️ **Important Notes:**
+**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: Create Discount Coupons (Optional)
+### Step 9: Update Product Pricing (Optional)
 
-Create discount coupons for promotional campaigns.
+To offer promotional pricing, update product prices using the `sales` operation with `op: "set"`:
 
-**Prompt**: Create a 20% discount coupon named "HOLIDAY20" for holiday promotions, valid for 30 days, distributed to customers "alice" and "bob".
+**Prompt**: Update the price of "Play Purse Set 35PCS" to 2.4WOW for a promotion.
 
 ```json
 {
   "operation_type": "service",
   "data": {
     "object": "myshop_service_v2",
-    "discount": {
-      "name": "HOLIDAY20",
-      "discount_type": 0,
-      "discount_value": 2000,
-      "benchmark": 0,
-      "time_ms_start": 0,
-      "time_ms_end": 2592000000,
-      "count": 100,
-      "recipient": ["alice", "bob"],
-      "transferable": true
+    "sales": {
+      "op": "set",
+      "sales": [
+        {
+          "name": "Play Purse Set 35PCS",
+          "price": 2400000000,
+          "stock": 100,
+          "suspension": false,
+          "wip": "https://wowok.net/test/three_body.wip",
+          "wip_hash": ""
+        }
+      ]
     }
   },
   "env": {
@@ -729,12 +765,13 @@ Create a customer account:
 ```json
 {
   "gen": {
-    "name": "myshop_customer"
+    "name": "myshop_customer",
+    "replaceExistName": true
   }
 }
 ```
 
-**Get test tokens:**
+**Get test tokens** (request twice to ensure sufficient balance for order + gas fees):
 
 ```json
 {
@@ -745,6 +782,8 @@ Create a customer account:
 }
 ```
 
+> **Note**: The faucet provides 3 WOW per call. Since orders require payment plus gas fees, request faucet tokens twice to ensure sufficient balance.
+
 ---
 
 ### Step 1: Query Service Products
@@ -786,6 +825,15 @@ Customer creates an order by purchasing products from the Service.
         "total_pay": {
           "balance": 3000000000
         }
+      },
+      "namedNewOrder": {
+        "name": "myshop_test_order"
+      },
+      "namedNewProgress": {
+        "name": "myshop_test_progress"
+      },
+      "namedNewAllocation": {
+        "name": "myshop_test_allocation"
       }
     }
   },
@@ -800,7 +848,7 @@ Customer creates an order by purchasing products from the Service.
 
 ### Step 2.1: Send Shipping Address via Messenger (Privacy Protection)
 
-After creating the order, the customer needs to send their shipping address and contact information to the after-sales support team. This is done securely through the Messenger system to protect privacy - the information is never stored on-chain.
+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.
 
 ```
 ┌─────────────────────────────────────────────────────────────────────────────────────┐
@@ -809,9 +857,9 @@ After creating the order, the customer needs to send their shipping address and
 │                                                                                     │
 │   ┌──────────────────┐         End-to-End Encrypted          ┌──────────────────┐  │
 │   │                  │◄──────────────────────────────────────►│                  │  │
-│   │  myshop_customer │         Messenger Channel              │ myshop_aftersales│  │
-│   │  (Customer)      │         (Never on-chain)               │  (After-Sales)   │  │
-│   │                  │                                        │   Support Team   │  │
+│   │  myshop_customer │         Messenger Channel              │ myshop_merchant  │  │
+│   │  (Customer)      │         (Never on-chain)               │  (After-Sales    │  │
+│   │                  │                                        │   Support)      │  │
 │   └────────┬─────────┘                                        └────────┬─────────┘  │
 │            │                                                           │            │
 │            │ 1. Send shipping address                                  │            │
@@ -833,10 +881,9 @@ After creating the order, the customer needs to send their shipping address and
 │   └──────────────────┘                                        └──────────────────┘  │
 │                                                                                     │
 │   Privacy Guarantees:                                                               │
-│   ✅ End-to-end encryption - Only customer and support can read                     │
-│   ✅ No on-chain storage - Message content never touches blockchain                 │
-│   ✅ Verifiable identity - Contact object confirms who you're talking to            │
-│   ✅ WTS support - Can generate verifiable conversation records if needed           │
+│   - 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            │
 │                                                                                     │
 └─────────────────────────────────────────────────────────────────────────────────────┘
 ```
@@ -848,47 +895,51 @@ After creating the order, the customer needs to send their shipping address and
 ```json
 {
   "messenger": {
-    "m": "customer_messenger"
-  },
-  "name_or_account": "myshop_customer"
+    "m": "customer_messenger",
+    "name_or_account": "myshop_customer"
+  }
 }
 ```
 
 #### 2.1.2 Customer Sends Shipping Information
 
-**Prompt**: Customer "myshop_customer" sends shipping address and contact information to after-sales support "myshop_aftersales" via encrypted messenger.
+**Prompt**: Customer "myshop_customer" sends shipping address and contact information to merchant "myshop_merchant" via encrypted messenger.
 
 ```json
 {
   "operation": "send_message",
   "from": "myshop_customer",
-  "to": "myshop_aftersales",
-  "content": "Order Shipping Information:\n\nOrder ID: 0x5678...9abc\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."
+  "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."
 }
 ```
 
-#### 2.1.3 After-Sales Support Receives and Confirms
+> **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.
 
-**Prompt**: After-sales support "myshop_aftersales" views the message and sends confirmation to customer.
+#### 2.1.3 Merchant Confirms Receipt
+
+**Prompt**: Merchant "myshop_merchant" views the message and sends confirmation to customer.
 
 ```json
 {
   "operation": "send_message",
-  "from": "myshop_aftersales",
+  "from": "myshop_merchant",
   "to": "myshop_customer",
-  "content": "Dear Customer,\n\nWe have received your shipping information:\n✅ Order ID: 0x5678...9abc 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!"
+  "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 after-sales support to confirm both messages were delivered.
+**Prompt**: View the conversation between customer and merchant to confirm both messages were delivered.
 
 ```json
 {
   "operation": "watch_messages",
   "filter": {
-    "peerAddress": "myshop_aftersales",
+    "peerAddress": "myshop_merchant",
     "account": "myshop_customer"
   }
 }
@@ -900,12 +951,13 @@ After creating the order, the customer needs to send their shipping address and
 
 Customer can query the order status and progress.
 
-**Prompt**: Query the order "0x5678...9abc" to check its current status and progress.
+**Prompt**: Query the order "myshop_test_order" to check its current status and progress.
 
 ```json
 {
   "query_type": "onchain_objects",
-  "objects": ["0x5678...9abc"]
+  "objects": ["myshop_test_order"],
+  "no_cache": true
 }
 ```
 
@@ -915,32 +967,34 @@ Customer can query the order status and progress.
 
 Check the current workflow node of the order.
 
-**Prompt**: Query the Progress "0x1234...5678" to see the current workflow node.
+**Prompt**: Query the Progress "myshop_test_progress" to see the current workflow node.
 
 ```json
 {
   "query_type": "onchain_objects",
-  "objects": ["0x1234...5678"]
+  "objects": ["myshop_test_progress"],
+  "no_cache": true
 }
 ```
+
 ---
 
 ### Step 5: Merchant Confirms Order
 
-Merchant advances the order from "Order Confirmation" to "Shipping".
+Merchant advances the order from initial state to "Order Confirmation" node.
 
-> **Note**: The merchant (order owner) can use `operation_type: "order"` with `progress` to advance the workflow. Non-owners must use `operation_type: "progress"` with `operate`.
+> **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 "0x5678...9abc" progress from "Order Confirmation" to "Shipping" using the "Confirm Order" forward.
+**Prompt**: Advance the order "myshop_test_order" progress from initial state to "Order Confirmation" using the "Confirm Order" forward.
 
 ```json
 {
-  "operation_type": "order",
+  "operation_type": "progress",
   "data": {
-    "object": "0x5678...9abc",
-    "progress": {
+    "object": "myshop_test_progress",
+    "operate": {
       "operation": {
-        "next_node_name": "Shipping",
+        "next_node_name": "Order Confirmation",
         "forward": "Confirm Order"
       },
       "hold": false,
@@ -953,22 +1007,23 @@ Merchant advances the order from "Order Confirmation" to "Shipping".
   }
 }
 ```
+
 ---
 
 ### Step 6: Merchant Ships Order
 
-Merchant ships the order and advances to "In Transit".
+Merchant ships the order and advances from "Order Confirmation" to "Shipping".
 
-**Prompt**: Advance the order "0x5678...9abc" progress from "Shipping" to "In Transit" using the "Ship Goods" forward.
+**Prompt**: Advance the order progress from "Order Confirmation" to "Shipping" using the "Ship Goods" forward.
 
 ```json
 {
-  "operation_type": "order",
+  "operation_type": "progress",
   "data": {
-    "object": "0x5678...9abc",
-    "progress": {
+    "object": "myshop_test_progress",
+    "operate": {
       "operation": {
-        "next_node_name": "In Transit",
+        "next_node_name": "Shipping",
         "forward": "Ship Goods"
       },
       "hold": false,
@@ -981,22 +1036,23 @@ Merchant ships the order and advances to "In Transit".
   }
 }
 ```
+
 ---
 
 ### Step 7: Confirm Delivery
 
 Merchant or delivery service confirms the order has been delivered.
 
-**Prompt**: Advance the order "0x5678...9abc" progress from "In Transit" to "Completed" using the "Confirm Delivery" forward.
+**Prompt**: Advance the order progress from "Shipping" to "In Transit" using the "Confirm Delivery" forward.
 
 ```json
 {
-  "operation_type": "order",
+  "operation_type": "progress",
   "data": {
-    "object": "0x5678...9abc",
-    "progress": {
+    "object": "myshop_test_progress",
+    "operate": {
       "operation": {
-        "next_node_name": "Completed",
+        "next_node_name": "In Transit",
         "forward": "Confirm Delivery"
       },
       "hold": false,
@@ -1009,21 +1065,20 @@ Merchant or delivery service confirms the order has been delivered.
   }
 }
 ```
+
 ---
 
 ### Step 8: Customer Completes Order
 
 Customer confirms receipt and completes the order.
 
-> **Important**: Non-order owners (like the customer in this case) must use `operation_type: "progress"` to advance the workflow. Only the order owner (merchant) can use `operation_type: "order"` with progress operations.
-
-**Prompt**: Customer "myshop_customer" completes the order "0x5678...9abc" by advancing from "Completed" node using "Complete Order" forward.
+**Prompt**: Customer "myshop_customer" completes the order by advancing from "In Transit" to "Completed" node using "Complete Order" forward.
 
 ```json
 {
   "operation_type": "progress",
   "data": {
-    "object": "0x1234...5678",
+    "object": "myshop_test_progress",
     "operate": {
       "operation": {
         "next_node_name": "Completed",
@@ -1039,6 +1094,7 @@ Customer confirms receipt and completes the order.
   }
 }
 ```
+
 ---
 
 ### Step 9: Merchant Withdraws Funds
@@ -1051,34 +1107,35 @@ After order completion, the merchant needs to:
 
 First, activate the Allocation by submitting the Guard verification with the Order ID.
 
-> **Note**: You can get the Allocation object ID from the Order object's `allocation` field, or by naming it during order creation with `namedNewAllocation`.
+> **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 "0xdef0...1234" by verifying the withdraw guard with order "0x5678...9abc".
+**Prompt**: Activate allocation "myshop_test_allocation" by verifying the withdraw guard with order "myshop_test_order".
 
 ```json
 {
   "operation_type": "allocation",
   "data": {
-    "object": "0x248f01d944de8f6712ec06f9b4c54f93fe4132e5323488b2d24c83d7487069de",
-    "alloc_by_guard": "myshop_withdraw_guard_v2"
+    "object": "myshop_test_allocation",
+    "alloc_by_guard": "0x5af9...1074"
   },
   "submission": {
     "type": "submission",
     "guard": [
       {
-        "object": "myshop_withdraw_guard_v2",
+        "object": "0x5af9...1074",
         "impack": true
       }
     ],
     "submission": [
       {
-        "guard": "myshop_withdraw_guard_v2",
+        "guard": "0x5af9...1074",
         "submission": [
           {
             "identifier": 0,
             "b_submission": true,
             "value_type": "Address",
-            "value": "0x497ea4f7a5bb098802c23deedd8ed7122d6b501979394ce111aa66432d2ba0ca"
+            "value": "0xa6db...3d5",
+            "name": "order_address"
           }
         ]
       }
@@ -1092,6 +1149,8 @@ First, activate the Allocation by submitting the Guard verification with the Ord
 }
 ```
 
+> **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.
+
 #### 9.2 Withdraw Funds from Service
 
 After the Allocation is activated, withdraw the funds from the Service.
@@ -1111,26 +1170,50 @@ After the Allocation is activated, withdraw the funds from the Service.
   }
 }
 ```
+
 ---
 
 ## Alternative Flow: Order Cancellation
 
 ### Customer Cancels Order
 
-Customer can cancel the order before it's confirmed.
+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").
 
-> **Note**: Customer (non-order owner) uses `operation_type: "progress"` to cancel the order.
-
-**Prompt**: Customer "myshop_customer" cancels the order "0x5678...9abc" before merchant confirmation.
+**Step 1**: Merchant confirms the order (advances from "" to "Order Confirmation"):
 
 ```json
 {
   "operation_type": "progress",
   "data": {
-    "object": "0x1234...5678",
+    "object": "myshop_test_progress",
     "operate": {
       "operation": {
         "next_node_name": "Order Confirmation",
+        "forward": "Confirm Order"
+      },
+      "hold": false,
+      "message": "Order confirmed by merchant"
+    }
+  },
+  "env": {
+    "account": "myshop_merchant",
+    "network": "testnet"
+  }
+}
+```
+
+**Step 2**: Customer cancels the order (advances from "Order Confirmation" to "Cancelled"):
+
+**Prompt**: Customer "myshop_customer" cancels the order after merchant confirmation.
+
+```json
+{
+  "operation_type": "progress",
+  "data": {
+    "object": "myshop_test_progress",
+    "operate": {
+      "operation": {
+        "next_node_name": "Cancelled",
         "forward": "Cancel Order"
       },
       "hold": false,
@@ -1143,13 +1226,89 @@ Customer can cancel the order before it's confirmed.
   }
 }
 ```
+
+> **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
+{
+  "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": "testnet",
+    "no_cache": true
+  }
+}
+```
+
+> **Note**: Replace the Guard address `0x5792...5d2c` and Order address `0xa6db...3d5` with your actual object addresses.
+
 ---
 
 ## Alternative Flow: Dispute and Arbitration
 
-### Step 1: Create Arbitration Object
+This flow handles order disputes through a formal arbitration process. The arbitration state machine has these statuses:
+- 0: Principal_confirming (initial)
+- 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 3 WOW to the Service compensation fund.
+
+```json
+{
+  "operation_type": "service",
+  "data": {
+    "object": "myshop_service_v2",
+    "compensation_fund_add": {"balance": 3000000000}
+  },
+  "env": {
+    "account": "myshop_merchant",
+    "network": "testnet"
+  }
+}
+```
+
+### Step 2: Create Arbitration Object
 
-First, create an Arbitration object for handling order disputes.
+Create an Arbitration object for handling order disputes.
 
 **Prompt**: Create an Arbitration object named "myshop_arbitration_v2" with permission "myshop_permission_v2" for dispute resolution.
 
@@ -1175,22 +1334,155 @@ First, create an Arbitration object for handling order disputes.
 }
 ```
 
-### Step 2: Customer Submits Arbitration
+> **Note**: New Arbitration objects are created with `bPaused: true` by default. You must unpause it in the next step before submitting disputes.
+
+### Step 3: Unpause the Arbitration Object
+
+The merchant unpauses the Arbitration object to enable dispute submissions.
+
+**Prompt**: Merchant unpauses the Arbitration object "myshop_arbitration_v2".
+
+```json
+{
+  "operation_type": "arbitration",
+  "data": {
+    "object": "myshop_arbitration_v2",
+    "pause": false
+  },
+  "env": {
+    "account": "myshop_merchant",
+    "network": "testnet"
+  }
+}
+```
+
+### Step 4: 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
+{
+  "operation_type": "service",
+  "data": {
+    "object": "myshop_service_v2",
+    "order_new": {
+      "buy": {
+        "items": [
+          {
+            "name": "Tree House Building Set",
+            "stock": 1
+          }
+        ],
+        "total_pay": {"balance": 2000000000}
+      },
+      "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": "testnet"
+  }
+}
+```
+
+> **Note**: The WIP hash is auto-computed by the SDK from the Service's WIP URL configuration.
+
+### Step 5: 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
+{
+  "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": 100000000},
+      "namedArb": {"name": "myshop_arb_case", "replaceExistName": true}
+    }
+  },
+  "env": {
+    "account": "myshop_customer",
+    "network": "testnet"
+  }
+}
+```
+
+> **Note**: The dispute fee (100000000 = 0.1 WOW) must be ≥ the Arbitration object's fee setting. The Arb object is created with status=1 (Arbitrator_confirming).
+
+### Step 6: 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 no voting deadline (0 = no deadline).
+
+```json
+{
+  "operation_type": "arbitration",
+  "data": {
+    "object": "myshop_arbitration_v2",
+    "confirm": {
+      "arb": "myshop_arb_case",
+      "voting_deadline": 0
+    }
+  },
+  "env": {
+    "account": "myshop_merchant",
+    "network": "testnet"
+  }
+}
+```
+
+> **Note**: Use `0` for `voting_deadline` to indicate no deadline (immediate arbitration). The MCP tool does not accept `null` for this field. To set a specific deadline, use a Unix timestamp in milliseconds.
+
+### Step 7: 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 2 WOW indemnity.
+
+```json
+{
+  "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": 2000000000
+    }
+  },
+  "env": {
+    "account": "myshop_merchant",
+    "network": "testnet"
+  }
+}
+```
+
+> **Note**: The Arb status changes to 3 (Arbitrated). The indemnity amount must be ≤ the Service's compensation_fund balance.
+
+### Step 8: Customer Claims Compensation
 
-If there's a dispute, customer can submit arbitration.
+The customer claims the compensation from the Service's compensation fund.
 
-**Prompt**: Customer "myshop_customer" submits arbitration for order "0x5678...9abc" using arbitration "myshop_arbitration".
+**Prompt**: Customer "myshop_customer" claims compensation for order "myshop_arb_order" from Arb "myshop_arb_case".
 
 ```json
 {
   "operation_type": "order",
   "data": {
-    "object": "0x5678...9abc",
-    "arb_confirm": {
-      "arb": "myshop_arbitration",
-      "confirm": true,
-      "description": "Product not as described - requesting refund",
-      "proposition": ["Full refund", "Return shipping cost coverage"]
+    "object": "myshop_arb_order",
+    "arb_claim_compensation": {
+      "arb": "myshop_arb_case"
     }
   },
   "env": {
@@ -1200,19 +1492,25 @@ If there's a dispute, customer can submit arbitration.
 }
 ```
 
-### Step 3: Query Arbitration Status
+> **Note**: The customer receives the indemnity amount (2 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 9: Query Arbitration Status
 
-Check the status of the arbitration.
+Check the final status of the arbitration.
 
-**Prompt**: Query the arbitration "0xbeef...cafe" to check its status.
+**Prompt**: Query the Arb "myshop_arb_case" to verify the arbitration is finished.
 
 ```json
 {
   "query_type": "onchain_objects",
-  "objects": ["0xbeef...cafe"]
+  "objects": ["myshop_arb_case"],
+  "no_cache": true,
+  "network": "testnet"
 }
 ```
 
+The Arb should have `status: 5` (Finished) with `compensation_time` set.
+
 ---
 
 ## Summary
@@ -1222,15 +1520,14 @@ 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 pre-sales and after-sales support
+   - Contact objects for after-sales support
+   - Guard creation for fund allocation validation
    - Service creation with products and pricing
-   - Arbitration setup for dispute resolution
-   - Discount coupon creation for promotions
 
 2. **Customer Flow**:
    - Product browsing and selection
    - Order creation with payment
-   - **Private information exchange via Messenger** (shipping address, phone number)
+   - Private information exchange via Messenger (shipping address, phone number)
    - Progress tracking through workflow nodes
    - Order completion and payment release
 
@@ -1238,90 +1535,68 @@ This MyShop e-commerce example demonstrates:
    - End-to-end encrypted messaging for sensitive information
    - Contact-based identity verification
    - No private data stored on-chain
-   - WTS support for verifiable conversation records
 
 4. **Alternative Flows**:
-   - Order cancellation before confirmation
-   - Dispute submission and arbitration process
+   - 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 new WoWok SDK patterns with JSON-based tool calls, making it easy for AI agents to interact with the blockchain e-commerce system.
+All operations use the WoWok SDK patterns with JSON-based tool calls, making it easy for AI agents to interact with the blockchain e-commerce system.
 
 ---
 
-## Important: Order vs Progress Operations
-
-When advancing order workflows, it's crucial to use the correct operation type based on who is performing the action:
-
-### Order Owner (Merchant)
-
-The order owner can use `operation_type: "order"` with the `progress` field:
-
-```json
-{
-  "operation_type": "order",
-  "data": {
-    "object": "0x5678...9abc",
-    "progress": {
-      "operation": {
-        "next_node_name": "Shipping",
-        "forward": "Confirm Order"
-      },
-      "hold": false,
-      "message": "Order confirmed"
-    }
-  }
-}
-```
-
-### Non-Owner (Customer, Agents)
+## Workflow Advancement Notes
 
-Non-owners must use `operation_type: "progress"` with the `operate` field:
+When advancing order workflows, use `operation_type: "progress"` with the `operate` field for all workflow transitions:
 
 ```json
 {
   "operation_type": "progress",
   "data": {
-    "object": "0x1234...5678",
+    "object": "myshop_test_progress",
     "operate": {
       "operation": {
-        "next_node_name": "Completed",
-        "forward": "Complete Order"
+        "next_node_name": "Target Node Name",
+        "forward": "Forward Name"
       },
       "hold": false,
-      "message": "Order completed"
+      "message": "Operation description"
     }
+  },
+  "env": {
+    "account": "operator_account",
+    "network": "testnet"
   }
 }
 ```
 
-> **Key Difference**: 
-> - `order` operation: Uses `progress` field, only for order owners
-> - `progress` operation: Uses `operate` field, for anyone with permission to advance the workflow
-
 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 | Example Address | Purpose |
-|-------------|------|-----------------|---------|
-| Account | myshop_merchant | 0x73e1...708a | Store owner account |
-| Account | myshop_customer | 0x6e95...d94d | Customer account |
-| Permission | myshop_permission_v2 | 0x0e01...9862 | Access control management |
-| Guard | myshop_withdraw_guard_v2 | 0x7fe6...91ea | Merchant withdrawal validation (order completed) |
-| Guard | myshop_refund_guard_v2 | 0x6147...bda4 | Customer refund validation (order not shipped) |
-| Machine | myshop_machine_v2 | 0x923b...6aac | Order processing workflow |
-| Contact | myshop_aftersales_contact_v2 | 0x855a...f53b | After-sales support contact |
-| Service | myshop_service_v2 | 0xc02e...9755 | Online store with products |
-| Arbitration | myshop_arbitration_v2 | (to be created) | Dispute resolution |
-| Discount | HOLIDAY20 | (to be created) | Promotional coupon |
-| Order | (dynamic) | 0x497e...a0ca | Customer purchase order |
-| Progress | (dynamic) | 0xf7ec...472f | Order workflow progress |
-| Allocation | (dynamic) | 0x248f...69de | Order fund allocation |
-| Arb | (dynamic) | (dynamic) | Arbitration case |
+| Object Type | Name | Purpose |
+|-------------|------|---------|
+| Account | myshop_merchant | Store owner account |
+| Account | myshop_customer | Customer account |
+| Permission | myshop_permission_v2 | Access control management |
+| 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) |
 
 ---
 
@@ -1330,7 +1605,6 @@ The Progress object ID can be obtained from:
 - 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
-- Create multiple discount campaigns
 - Set up Repository for order data storage
 - Add WTS generation for messenger conversation records
 - Implement file sharing via Messenger (shipping labels, invoices)
@@ -1345,9 +1619,3 @@ The Progress object ID can be obtained from:
 - Use the full 64-character address in actual operations
 - Test on testnet before deploying to mainnet
 - Ensure sufficient WOW tokens for transaction fees
-
----
-
-## Actual Test Results
-
-For actual execution results with real object addresses and transaction outputs from testnet, see [MyShop_TestResults.md](MyShop_TestResults.md).