@wowok/agent-mcp 2.6.3 → 2.6.6

package/dist/examples/rental-ziroom-service-create.json

@@ -1,10 +1,10 @@
 {
   "title": "Create Service with 3-path Allocation (Ziroom Rental)",
-  "description": "Create a Service with machine, buy_guard, contact, and 3-path order_allocators (rent/refund/damage)",
+  "description": "Create a Service with machine, buy_guard, contact, and 3-path order_allocators (rent to operator / refund to customer signer / damage deduction to operator)",
   "tags": ["service", "allocation", "rental", "order_allocators", "guard"],
   "industry": "rental",
   "operation_type": "service",
-  "source": "ziroom testnet deployment 2026-07-29",
+  "source": "ziroom testnet deployment 2026-07-29 (repaired to current schema)",
   "verified": true,
   "network": "testnet",
   "call": {
@@ -14,21 +14,26 @@
       "object": {
         "name": "ziroom_service_v1",
         "tags": ["project:ziroom", "type:service"],
-        "replaceExistName": true
+        "replaceExistName": true,
+        "permission": "ziroom_permission_v1",
+        "type_parameter": "0x2::wow::WOW"
       },
-      "permission": "ziroom_permission_v1",
       "machine": "ziroom_machine_v1",
       "buy_guard": "ziroom_buy_guard_v1",
       "um": "ziroom_contact_v1",
-      "sales": [
-        {
-          "name": "ziroom_apartment_v1",
-          "price": 2000000000,
-          "stock": 1,
-          "suspension": false,
-          "wip_hash": ""
-        }
-      ],
+      "sales": {
+        "op": "add",
+        "sales": [
+          {
+            "name": "ziroom_apartment_v1",
+            "price": 2000000000,
+            "stock": 1,
+            "suspension": false,
+            "wip": "",
+            "wip_hash": ""
+          }
+        ]
+      },
       "order_allocators": {
         "description": "3-path allocation: rent to operator, refund to customer, damage deductions",
         "threshold": 1000000000,
@@ -37,7 +42,7 @@
             "guard": "ziroom_buy_guard_v1",
             "sharing": [
               {
-                "who": { "Entity": { "name_or_address": "0x36cd..." } },
+                "who": { "Entity": { "name_or_address": "ziroom_operator" } },
                 "sharing": 1000000000,
                 "mode": "Amount"
               }
@@ -57,7 +62,7 @@
             "guard": "ziroom_damage_guard_v1",
             "sharing": [
               {
-                "who": { "Entity": { "name_or_address": "0x36cd..." } },
+                "who": { "Entity": { "name_or_address": "ziroom_operator" } },
                 "sharing": 1000000000,
                 "mode": "Amount"
               }
@@ -73,8 +78,12 @@
     }
   },
   "notes": [
-    "order_allocators is PERMANENTLY IMMUTABLE after publish (service.move:503)",
-    "Signer recipient means the tx sender at alloc() time — customer must call alloc_by_guard themselves for refunds",
-    "Amount mode: fixed amount, not percentage. Use Rate mode (10000=100%) for proportional splits"
+    "order_allocators is PERMANENTLY IMMUTABLE after publish (service.move:503) — set it BEFORE publish=true.",
+    "Signer recipient means the tx sender at alloc() time — the customer must call alloc_by_guard THEMSELVES for refunds (if the operator calls it, the operator receives the funds).",
+    "Amount mode: fixed amount in smallest unit, not percentage. Use Rate mode (10000=100%) for proportional splits; Rate items must sum to exactly 10000 when no Surplus item exists.",
+    "sales is an op discriminated union: {op:'add'|'set', sales:[...]} or {op:'remove', sales_name:[...]} or {op:'clear'} — never a bare array.",
+    "permission and type_parameter live INSIDE 'object' (TypeNamedObjectWithPermissionSchema). wip/wip_hash empty strings skip verification (TESTING ONLY — production must use real WIP URLs).",
+    "machine must be PUBLISHED before binding here; buy_guard may use a LocalMark NAME to break the Guard↔Service circular dependency (Phase-1 create without publish, then publish in Phase 2).",
+    "Entity recipient shown as local mark name 'ziroom_operator' (desensitization repair 2026-07-30): the original deployment used the operator's raw 0x address; Entity resolves names via LocalMark to a FIXED static address, so the name form is equivalent and recommended."
   ]
 }

package/dist/examples/retail-adv-guard-customer-win-create.json

@@ -0,0 +1,80 @@
+{
+  "title": "Guard: Complete Multi-Condition Pattern (progress node + Signer==order.owner + order.service) — Customer-Win Allocator",
+  "description": "The 'complete pattern' allocation Guard: logic_and of (1) order at a customer-win node (Lost / Return Complete) via progress.current with convert_witness OrderProgress, (2) Level-2 dynamic identity binding Signer == query(order.owner), and (3) cross-service-theft prevention query(order.service) == this Service. Used as a Service order_allocators guard whose sharing.who is {Signer:'signer'} — the Signer binding is what makes Signer-recipient allocation safe (R-C3-06).",
+  "tags": ["guard", "allocation", "multi-condition", "logic_and", "level2-dynamic-binding", "retail"],
+  "industry": "retail",
+  "operation_type": "guard",
+  "source": "docs/examples/MyShop_Advanced — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "guard",
+    "data": {
+      "namedNew": {
+        "name": "service_customer_win_v2",
+        "tags": ["order", "customer-win", "level2-dynamic-binding"],
+        "replaceExistName": true
+      },
+      "description": "Verify order at customer win nodes (Lost, Return Complete) AND signer is the order owner AND order belongs to three_body_signature_service_v2. VERIFIER CONSTRAINT LEVEL 2 (dynamic identity binding): Signer bound to query('order.owner') — only the order's rightful owner can trigger the refund. Three-fold verification: (1) order at customer win node, (2) signer is order.owner (dynamic query, prevents fund theft), (3) order belongs to this service (prevents cross-service theft, R-C3-05).",
+      "table": [
+        { "identifier": 0, "b_submission": true, "value_type": "Address", "name": "order_id" },
+        { "identifier": 1, "b_submission": false, "value_type": "String", "value": "Lost" },
+        { "identifier": 2, "b_submission": false, "value_type": "String", "value": "Return Complete" },
+        { "identifier": 3, "b_submission": false, "value_type": "Address", "name": "service_address", "value": "three_body_signature_service_v2" }
+      ],
+      "root": {
+        "type": "logic_and",
+        "nodes": [
+          {
+            "type": "logic_or",
+            "nodes": [
+              {
+                "type": "logic_string_nocase_equal",
+                "nodes": [
+                  { "type": "query", "query": "progress.current", "object": { "identifier": 0, "convert_witness": "OrderProgress" }, "parameters": [] },
+                  { "type": "identifier", "identifier": 1 }
+                ]
+              },
+              {
+                "type": "logic_string_nocase_equal",
+                "nodes": [
+                  { "type": "query", "query": "progress.current", "object": { "identifier": 0, "convert_witness": "OrderProgress" }, "parameters": [] },
+                  { "type": "identifier", "identifier": 2 }
+                ]
+              }
+            ]
+          },
+          {
+            "type": "logic_equal",
+            "nodes": [
+              { "type": "query", "query": "order.owner", "object": { "identifier": 0 }, "parameters": [] },
+              { "type": "context", "context": "Signer" }
+            ]
+          },
+          {
+            "type": "logic_equal",
+            "nodes": [
+              { "type": "query", "query": "order.service", "object": { "identifier": 0 }, "parameters": [] },
+              { "type": "identifier", "identifier": 3 }
+            ]
+          }
+        ]
+      }
+    },
+    "env": {
+      "network": "testnet",
+      "no_cache": true
+    }
+  },
+  "notes": [
+    "COMPLETE PATTERN (BUG-01): root = logic_and of [node-set check via logic_or(logic_string_nocase_equal x2) on progress.current, Signer==order.owner, order.service==service]. All three conditions must pass; logic_and accepts 2-8 children (this uses 3).",
+    "Schema-verified: CallGuard_DataSchema (guard.ts) — creation uses namedNew (NOT 'object'); table items use GuardTableItemBaseSchema (common/index.ts) which REJECTS the output-only object_type field; root validated against GuardNodeSchema (query/index.ts) and must return Bool — logic_and is in the allowed root-type list.",
+    "Query names verified against knowledge/guard-templates.ts: progress.current (id 1253, String), order.owner (id 1562, Address), order.service (id 1563, Address). convert_witness 'OrderProgress' (id 100) is a valid WitnessTypeSchema string — the Order address submitted at runtime is converted to its Progress object before querying the current node.",
+    "Why the Signer binding matters: the paired allocator uses sharing.who = {Signer:'signer'} (funds go to the caller). Condition 2 binds the caller to query(order.owner), so only the customer who placed the order can receive the refund — without it anyone could steal 100% of the allocation (R-C3-06).",
+    "Shorthand variant (not used here): the logic_or of two logic_string_nocase_equal can collapse into one VecString constant + vec_contains_string_nocase — semantically equivalent per guard-examples-lint.spec.ts 'Semantic Equivalence' tests. Original form kept for clarity of the complete pattern.",
+    "Prerequisites: the Service 'three_body_signature_service_v2' must already exist (created unpublished) so the identifier-3 name resolves at transaction build time. Guard is IMMUTABLE after creation.",
+    "Desensitization: doc ran on mainnet with local-mark account myshop_merchant — network switched to testnet and account omitted (use your own default/local-mark account). Object names (service_customer_win_v2, three_body_signature_service_v2) are local marks, not real identities. No personal data or real 0x addresses present. replaceExistName:true kept from the doc's full-rerun convention — omit for one-off deployments.",
+    "Runtime use: bound as Service order_allocators[].guard; the customer triggers allocation.alloc_by_guard with submission of identifier 0 = their Order address (see the doc Part 4 'Customer Wins' example)."
+  ]
+}

package/dist/examples/retail-adv-guard-messenger-proof-create.json

@@ -0,0 +1,65 @@
+{
+  "title": "Guard: Strict-Mode Privacy Delivery via Messenger Chain Proof (Signer==proof.signer + proof.time>order.time + order.service)",
+  "description": "Machine forward Guard for privacy-preserving logistics: tracking numbers are exchanged via encrypted Messenger (off-chain); on-chain the verifier submits a Proof object address + the Order address. logic_and of (1) submitter accountability — context(Signer) == query(proof.signer), (2) freshness — query(proof.time) > query(order.time) via logic_as_u256_greater (prevents stale-proof replay), (3) project binding — query(order.service) == this Service (prevents cross-project bypass, R-C3-05).",
+  "tags": ["guard", "machine-forward", "messenger", "proof", "privacy", "multi-condition", "retail"],
+  "industry": "retail",
+  "operation_type": "guard",
+  "source": "docs/examples/MyShop_Advanced — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "guard",
+    "data": {
+      "namedNew": {
+        "name": "machine_messenger_proof_v2",
+        "replaceExistName": true
+      },
+      "description": "Strict-mode privacy delivery: verify Signer==proof.signer AND proof.time>order.time AND order.service==service (verifier submits Proof + Order object addresses)",
+      "table": [
+        { "identifier": 0, "b_submission": true, "value_type": "Address", "name": "proof_id" },
+        { "identifier": 1, "b_submission": true, "value_type": "Address", "name": "order_id" },
+        { "identifier": 2, "b_submission": false, "value_type": "Address", "name": "service_address", "value": "three_body_signature_service_v2" }
+      ],
+      "root": {
+        "type": "logic_and",
+        "nodes": [
+          {
+            "type": "logic_equal",
+            "nodes": [
+              { "type": "context", "context": "Signer" },
+              { "type": "query", "query": "proof.signer", "object": { "identifier": 0 }, "parameters": [] }
+            ]
+          },
+          {
+            "type": "logic_as_u256_greater",
+            "nodes": [
+              { "type": "query", "query": "proof.time", "object": { "identifier": 0 }, "parameters": [] },
+              { "type": "query", "query": "order.time", "object": { "identifier": 1 }, "parameters": [] }
+            ]
+          },
+          {
+            "type": "logic_equal",
+            "nodes": [
+              { "type": "query", "query": "order.service", "object": { "identifier": 1 }, "parameters": [] },
+              { "type": "identifier", "identifier": 2 }
+            ]
+          }
+        ]
+      }
+    },
+    "env": {
+      "network": "testnet",
+      "no_cache": true
+    }
+  },
+  "notes": [
+    "Strict-mode alternative to the broad 'Merkle Root length == 66' Guard (machine_merkle_root_v2). Broad mode trusts submitter honesty; strict mode enforces WHO submitted (谁得利谁举证 — whoever benefits bears the burden of proof) without verifying message content on-chain.",
+    "Schema-verified: CallGuard_DataSchema (guard.ts) — namedNew creation form; table items carry no object_type (output-only); root logic_and returns Bool (allowed root type). logic_as_u256_greater compares first node > all subsequent nodes, so proof.time is listed before order.time.",
+    "Query names verified against knowledge/guard-templates.ts (tpl that uses proof.signer/proof.time/order.time): proof.signer (Proof object, Address), proof.time (U64, clock-derived, always > 0), order.time (U64), order.service (Address). context enum is exactly 'Signer' | 'Clock' | 'Guard'.",
+    "Proof generation (provider side, off-chain SDK): messenger submitChainProof(env, peerAddress, description) — about_address = the customer, order id embedded in description; returns proofAddress which is later submitted as identifier 0.",
+    "Runtime submission contract for the Machine forward: TWO Address identifiers — identifier 0 = Proof object address, identifier 1 = the Order object address. The same Guard can be reused across all forwards needing delivery proof (shipping, lost, returns) — choose broad vs strict mode BEFORE publishing the Machine (Forward.guard is immutable).",
+    "Prerequisites: Service 'three_body_signature_service_v2' must exist (identifier 2 name resolves at build time). Guard is IMMUTABLE after creation.",
+    "Desensitization: doc ran on mainnet as local-mark account myshop_merchant — network switched to testnet, account omitted. Table names shortened to proof_id/order_id for the 64-BCS-char name limit; all object references are local marks, no real addresses or personal data. replaceExistName:true kept from the doc's full-rerun convention."
+  ]
+}

package/dist/examples/retail-adv-guard-reward-timeout-create.json

@@ -0,0 +1,92 @@
+{
+  "title": "Guard: Reward Claim with Time Condition + Double-Claim Protection (5-condition logic_and)",
+  "description": "Advanced reward-claim Guard for shipping-timeout compensation: logic_and of FIVE conditions — (1) order still at 'Shipping' node (progress.current via OrderProgress witness), (2) Signer == order.owner (only the customer can claim their own compensation), (3) order.service == this Service (anti cross-service theft), (4) elapsed time on current node >= 2 days via Clock - query(progress.current_time) >= 172800000, (5) logic_not(query_reward_record_exists) — the same order has not claimed before (double-claim protection keyed by store_from_id).",
+  "tags": ["guard", "reward", "claim", "double-claim-protection", "time-lock", "multi-condition", "retail"],
+  "industry": "retail",
+  "operation_type": "guard",
+  "source": "docs/examples/MyShop_Advanced — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "guard",
+    "data": {
+      "namedNew": {
+        "name": "reward_shipping_timeout_v2",
+        "replaceExistName": true
+      },
+      "description": "Verify order at Shipping node for timeout compensation: signer must be order owner, order belongs to this service, not claimed before, AND the order has been at the Shipping node for >= 2 days (Clock - progress.current_time >= 172800000 ms, progress submitted as Address identifier 4)",
+      "table": [
+        { "identifier": 0, "b_submission": true, "value_type": "Address", "name": "order_id" },
+        { "identifier": 1, "b_submission": false, "value_type": "String", "value": "Shipping" },
+        { "identifier": 2, "b_submission": false, "value_type": "Address", "value": "myshop_reward_v2", "name": "reward_object" },
+        { "identifier": 3, "b_submission": false, "value_type": "Address", "value": "three_body_signature_service_v2", "name": "service_address" },
+        { "identifier": 4, "b_submission": true, "value_type": "Address", "name": "progress_id" },
+        { "identifier": 5, "b_submission": false, "value_type": "U64", "value": "172800000", "name": "timeout_ms" }
+      ],
+      "root": {
+        "type": "logic_and",
+        "nodes": [
+          {
+            "type": "logic_string_nocase_equal",
+            "nodes": [
+              { "type": "query", "query": "progress.current", "object": { "identifier": 0, "convert_witness": "OrderProgress" }, "parameters": [] },
+              { "type": "identifier", "identifier": 1 }
+            ]
+          },
+          {
+            "type": "logic_equal",
+            "nodes": [
+              { "type": "query", "query": "order.owner", "object": { "identifier": 0 }, "parameters": [] },
+              { "type": "context", "context": "Signer" }
+            ]
+          },
+          {
+            "type": "logic_equal",
+            "nodes": [
+              { "type": "query", "query": "order.service", "object": { "identifier": 0 }, "parameters": [] },
+              { "type": "identifier", "identifier": 3 }
+            ]
+          },
+          {
+            "type": "logic_as_u256_greater_or_equal",
+            "nodes": [
+              {
+                "type": "calc_number_subtract",
+                "nodes": [
+                  { "type": "context", "context": "Clock" },
+                  { "type": "query", "query": "progress.current_time", "object": { "identifier": 4 }, "parameters": [] }
+                ]
+              },
+              { "type": "identifier", "identifier": 5 }
+            ]
+          },
+          {
+            "type": "logic_not",
+            "node": {
+              "type": "query_reward_record_exists",
+              "object": { "identifier": 2 },
+              "where": {
+                "storeFromId": { "identifier": 0 }
+              }
+            }
+          }
+        ]
+      }
+    },
+    "env": {
+      "network": "testnet",
+      "no_cache": true
+    }
+  },
+  "notes": [
+    "Most complex Guard in the MyShop_Advanced doc: 5-condition logic_and (schema allows 2-8 children) combining node check + Level-2 dynamic Signer binding + service binding + secure time-lock + one-claim-per-order record check.",
+    "Schema-verified: CallGuard_DataSchema (guard.ts) + GuardNodeSchema (query/index.ts). query_reward_record_exists node shape: {object:{identifier}, recipient?, where:{storeFromId:{identifier}}} — recipient omitted, so the transaction signer is matched; where.storeFromId points at identifier 0 (the order address) so one claim per ORDER, not per user.",
+    "SECURE TIME-LOCK PATTERN: the start time is NEVER a caller-submitted U64 (a submitter could pass 0 and bypass the lock). The Progress object is submitted at runtime (identifier 4, Address) and its current-node entry timestamp is read on-chain via query progress.current_time (id 1272); only the threshold (identifier 5, 172800000 ms = 2 days) is a creation-time constant.",
+    "Query names verified against knowledge/guard-templates.ts and guard-design-patterns.ts: progress.current (1253), order.owner (1562), order.service (1563), progress.current_time (1272). context enum: 'Clock' returns the on-chain timestamp (U64 ms).",
+    "Claim submission contract: claiming via reward.claim requires TWO submissions — identifier 0 = Order address AND identifier 4 = the order's Progress object address. The SDK auto-appends an internal VecU8 table entry (next free identifier) for the reward-record query parameters — only business identifiers 0-5 are defined here.",
+    "Prerequisites: Reward 'myshop_reward_v2' must exist EMPTY first (identifier 2 references it by name — circular-reference pattern: create Reward -> create this Guard -> reward.guard_add binds it with store_from_id: 0). Service must exist for identifier 3. Guard is IMMUTABLE after creation.",
+    "Desensitization: doc ran on mainnet as myshop_merchant — network switched to testnet, account omitted; all references are local marks; no personal data or real 0x addresses. replaceExistName:true kept from the doc's full-rerun convention.",
+    "Pair with: reward guard_add entry {guard: 'reward_shipping_timeout_v2', recipient: {Signer:'signer'}, amount: {type:'Fixed', value:'20000'}, store_from_id: 0} (see retail-adv-reward-guard-add example). Amount is a symbolic smallest-unit value (20000 = 0.00002 WOW at 9 decimals)."
+  ]
+}

package/dist/examples/retail-adv-reward-guard-add.json

@@ -0,0 +1,51 @@
+{
+  "title": "Reward: Bind Claim Guards with store_from_id (double-claim protection) — Wonderful / Lost / Shipping-Timeout",
+  "description": "Attach three claim Guards to an existing Reward pool in one call. Each entry pairs a Guard with a Fixed amount, recipient {Signer:'signer'}, and store_from_id: 0 — the value at Guard-table identifier 0 (the order address) is recorded per claim, enabling query_reward_record_exists-based double-claim protection. This is the bind step of the circular-reference pattern: (1) create empty Reward, (2) create Guards referencing the Reward by name, (3) guard_add binds them.",
+  "tags": ["reward", "guard_add", "claim", "double-claim-protection", "circular-reference", "retail"],
+  "industry": "retail",
+  "operation_type": "reward",
+  "source": "docs/examples/MyShop_Advanced — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "reward",
+    "data": {
+      "object": "myshop_reward_v2",
+      "guard_add": [
+        {
+          "guard": "reward_wonderful_v2",
+          "recipient": { "Signer": "signer" },
+          "amount": { "type": "Fixed", "value": "10000" },
+          "store_from_id": 0
+        },
+        {
+          "guard": "reward_lost_v2",
+          "recipient": { "Signer": "signer" },
+          "amount": { "type": "Fixed", "value": "20000" },
+          "store_from_id": 0
+        },
+        {
+          "guard": "reward_shipping_timeout_v2",
+          "recipient": { "Signer": "signer" },
+          "amount": { "type": "Fixed", "value": "20000" },
+          "store_from_id": 0
+        }
+      ]
+    },
+    "env": {
+      "network": "testnet",
+      "no_cache": true
+    }
+  },
+  "notes": [
+    "Schema-verified against CallReward_DataSchema (call/reward.ts, strict): 'object' as STRING = operate on existing Reward (object form would CREATE). guard_add items validated against RewardGuardSchema (query/index.ts): {guard: NameOrAddress, recipient: RecipientSchema, amount: AmountSchema, expiration_time?, store_from_id?}.",
+    "recipient {Signer:'signer'} matches RecipientSchema's z.object({Signer: z.literal('signer')}) branch — the literal string 'signer' is required. Safe here because each claim Guard binds Signer == query(order.owner) (Level-2 dynamic binding), so funds always reach the order's rightful owner.",
+    "amount {type:'Fixed', value} — AmountSchema discriminated union ('Fixed' | 'GuardU64Identifier'). Values converted from the doc's numbers to STRINGS per smallest-unit convention (BalanceTypeSchema accepts both; string preserves precision). 10000/20000 are SYMBOLIC test values (0.00001/0.00002 WOW at 9 decimals) — far below gas; production should use e.g. '20000000000' (20 WOW) or display format '20WOW'.",
+    "store_from_id: 0 means the Guard-table identifier-0 value (the submitted order address) is stored with each claim record — the claim Guards' query_reward_record_exists(where.storeFromId={identifier:0}) then rejects repeat claims for the same order. GuardIdentifierSchema range 0-255.",
+    "Prerequisites (circular-reference order, DOC): (1) Reward 'myshop_reward_v2' created EMPTY; (2) the three Guards created (they reference the Reward by name in their tables); (3) THIS guard_add call binds them. Afterwards fund the pool via coin_add — claims fail on insufficient balance.",
+    "Optional lock: set guard_expiration_time (ms, or null to remove) to freeze the Guard list — after that point no new Guards/fund rules can be added.",
+    "Desensitization: doc ran on mainnet as myshop_merchant — network switched to testnet, account omitted; all object references are local marks; no personal data or real 0x addresses.",
+    "Claim flow after binding: customer calls reward.claim = '<guard_name>' with a submission carrying the Guard's b_submission identifiers (order address, plus progress address for the timeout guard)."
+  ]
+}

package/dist/examples/retail-myshop-allocation-activate.json

@@ -0,0 +1,55 @@
+{
+  "title": "Activate Allocation via Guard Verification (MyShop Retail)",
+  "description": "Activate a pending MyShop Allocation by verifying the withdraw Guard with alloc_by_guard, passing the Order address as a runtime submission. On Guard pass, funds are distributed per the allocator's sharing rules.",
+  "tags": ["allocation", "alloc_by_guard", "submission", "withdraw", "retail"],
+  "industry": "retail",
+  "operation_type": "allocation",
+  "source": "MyShop verified deployment walkthrough (docs/examples/MyShop) — adapted to current schema",
+  "verified": true,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "allocation",
+    "data": {
+      "object": "myshop_test_allocation",
+      "alloc_by_guard": "myshop_withdraw_guard"
+    },
+    "submission": {
+      "type": "submission",
+      "guard": [
+        {
+          "object": "myshop_withdraw_guard",
+          "impack": true
+        }
+      ],
+      "submission": [
+        {
+          "guard": "myshop_withdraw_guard",
+          "submission": [
+            {
+              "identifier": 0,
+              "b_submission": true,
+              "value_type": "Address",
+              "value": "myshop_order_v1",
+              "name": "order_address"
+            }
+          ]
+        }
+      ]
+    },
+    "env": {
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "alloc_by_guard and the submission guard entries accept the Guard's LOCAL MARK NAME — the SDK resolves non-address values via LocalMark.get_address (allocation.ts L122-136), so names and 0x addresses both work. This example uses names (desensitization repair 2026-07-30: the original walkthrough recorded truncated real addresses, which are neither valid schema IDs nor reproducible).",
+    "submission sits at the request ROOT level — sibling of data/env (mirrored here as call.submission), NOT inside data.data. Shape (SubmissionCallSchema): {type:'submission', guard:[{object, impack}], submission:[{guard, submission:[GuardTableItem...]}]}, one submission entry per Guard in the guard array.",
+    "impack flag (per schema): whether this Guard's verification result participates in the final logic. true = the Guard must PASS for the allocation to execute; false = the Guard is still checked but does not block the operation.",
+    "b_submission:true table items are runtime values supplied by the caller at Guard trigger time (e.g. the order address to release funds for) — the static 'value' stored in the Guard definition is ignored and the value here is used instead.",
+    "After activation distributes funds per the allocator sharing rules, the merchant withdraws Service-side receipts via: {operation_type:'service', data:{object:'myshop_service_v2', owner_receive:'recently'}} (MyShop step 7.2).",
+    "object as a STRING targets an EXISTING Allocation (CallAllocation_OperateSchema). Allocation objects are normally created automatically by order payments through the Service's order_allocators config, then activated per allocator Guard.",
+    "Adaptations from doc: network changed mainnet->testnet; payload otherwise matches current schema (no drift found)."
+  ]
+}

package/dist/examples/retail-myshop-arbitration-create.json

@@ -0,0 +1,40 @@
+{
+  "title": "Create Arbitration with Independent Permission (MyShop Retail)",
+  "description": "Create an Arbitration object for MyShop retail order dispute resolution, using an independent Permission (myshop_arbitration_permission) separate from the Service's permission, with dispute fee, description, and location.",
+  "tags": ["arbitration", "dispute", "retail", "permission"],
+  "industry": "retail",
+  "operation_type": "arbitration",
+  "source": "MyShop verified deployment walkthrough (docs/examples/MyShop) — adapted to current schema",
+  "verified": true,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "arbitration",
+    "data": {
+      "object": {
+        "name": "myshop_arbitration_v2",
+        "type_parameter": "0x2::wow::WOW",
+        "permission": "myshop_arbitration_permission",
+        "tags": ["ecommerce", "dispute", "toys"],
+        "onChain": false,
+        "replaceExistName": true
+      },
+      "description": "Arbitration system for MyShop toy store disputes",
+      "location": "Online arbitration system",
+      "fee": 5000000
+    },
+    "env": {
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "CRITICAL FIX vs original doc: the walkthrough used permission 'myshop_permission_v2' — the SAME permission as the Service. This is now blocked at the contract layer: service.move arbitration_add_imp asserts arbitration.permission != service.permission and aborts with E_ARBITRATION_PERMISSION_CONFLICT (code 33), because a Service owner controlling its own Arbitration breaks dispute fairness. An Arbitration MUST use an independent Permission (here 'myshop_arbitration_permission').",
+    "New Arbitration objects are created PAUSED (bPaused=true) and cannot accept disputes until unpaused. Follow-up call after creation: {operation_type:'arbitration', data:{object:'myshop_arbitration_v2', pause:false}} (object as STRING references the existing object).",
+    "fee is in the SMALLEST unit of the type_parameter token: 5000000 = 0.005 WOW (WOW has 9 decimals). BalanceTypeSchema also accepts numeric strings for values above 2^53.",
+    "name/type_parameter/permission live INSIDE 'object' (TypeNamedObjectWithPermissionSchema), not at the data root. permission may reference an existing Permission by name/address (as here) or create a new one inline.",
+    "onChain:false keeps the local mark private (not published on-chain); replaceExistName:true force-rebinds the name if already taken — use deliberately, it unbinds the name from its previous object.",
+    "Adaptations from doc: permission renamed to an independent Permission (contract fix above), network changed mainnet->testnet, replaceExistName added for re-runnability."
+  ]
+}

package/dist/examples/retail-myshop-contact-create.json

@@ -0,0 +1,43 @@
+{
+  "title": "Create After-Sales Contact Object (MyShop Retail)",
+  "description": "Create a named Contact object with a Permission reference and an initial IM entry pointing at the merchant's after-sales support account",
+  "tags": ["contact", "messenger", "ims", "retail"],
+  "industry": "retail",
+  "operation_type": "contact",
+  "source": "MyShop verified deployment walkthrough (docs/examples/MyShop) — adapted to current schema",
+  "verified": true,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "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": {
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "ims.im[].at accepts an ACCOUNT NAME (resolved to the account's address at transaction build time) or a full 0x address directly — 'myshop_merchant' here is an account name, not a messenger name.",
+    "ims is an op discriminated union, never a bare array: {op:'add', im:[{at, description?}...]} / {op:'set', im:[...]} replaces the whole list / {op:'remove', im:[...]} takes plain names-or-addresses (NOT {at, description} entries) / {op:'clear'} empties the list.",
+    "'object' uses the OBJECT creation form {name, permission, replaceExistName} — 'name' goes INSIDE 'object', and 'permission' references the pre-created myshop_permission_v2 (or inline-create a new Permission, or omit for an auto-created unnamed one). To operate an existing Contact, pass a string name/ID instead.",
+    "Bind this Contact to a Service via the service call's 'um' field so customers can reach after-sales support; Messenger communication itself is end-to-end encrypted and never stored on-chain.",
+    "Adapted from the doc's mainnet env to testnet + no_cache; env.account omitted because Contact creation is not bound to a specific signer — any account can create it."
+  ]
+}

package/dist/examples/retail-myshop-order-create.json

@@ -0,0 +1,56 @@
+{
+  "title": "Create Order with Named Order/Progress/Allocation (MyShop Retail)",
+  "description": "Customer purchases a product from a published Service via order_new: buy.items + total_pay, while simultaneously naming the newly created Order, Progress, and Allocation objects so later steps can reference them by name",
+  "tags": ["order", "order_new", "retail", "buy", "named_objects"],
+  "industry": "retail",
+  "operation_type": "service",
+  "source": "MyShop verified deployment walkthrough (docs/examples/MyShop) — adapted to current schema",
+  "verified": true,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "service",
+    "data": {
+      "object": "myshop_service_v2",
+      "order_new": {
+        "buy": {
+          "items": [
+            {
+              "name": "Play Purse Set 35PCS",
+              "stock": 1,
+              "wip_hash": "03c18561efa8faf4d75480eb1f732c4a46ffde95599e92eca06167785fc07a5b"
+            }
+          ],
+          "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": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "A single order_new call creates THREE objects at once — Order, Progress, and Allocation — and namedNewOrder / namedNewProgress / namedNewAllocation name all three in the same call, so subsequent steps (progress operate, alloc_by_guard) can reference them by name instead of raw on-chain addresses. All three are optional but strongly RECOMMENDED.",
+    "buy.items[].wip_hash is a dispute-prevention mechanism: the on-chain contract compares it against the Service's current sale.wip_hash to ensure the product WIP file was not swapped between browse time and purchase time. Capture it from the Service query result right before ordering. Empty string \"\" only verifies WIP file integrity without comparing to a specific hash — NOT recommended for real purchases.",
+    "total_pay.balance is denominated in the SMALLEST unit of the Service's type_parameter token — WOW has 9 decimals, so 50000000 = 0.05 WOW. Alternative format: {coin: '<coin_object_id_or_name>'} to pay with a specific Coin object.",
+    "'object' is a STRING here (reference to an existing, published Service), not the object-creation form. order_new is an optional field of the service call, alongside sales / order_allocators / buy_guard / etc.",
+    "env.account is the customer and is CRITICAL here: the signer pays total_pay and becomes the Order owner. Adapted from the doc's mainnet env to testnet + no_cache per example conventions."
+  ]
+}

package/dist/examples/retail-myshop-progress-operate.json

@@ -0,0 +1,38 @@
+{
+  "title": "Advance Order Progress via Forward (MyShop Retail)",
+  "description": "Merchant advances an order's Progress from the empty initial node to the 'Order Confirmation' node using the 'Confirm Order' forward — the canonical progress operate shape",
+  "tags": ["progress", "operate", "forward", "retail", "workflow"],
+  "industry": "retail",
+  "operation_type": "progress",
+  "source": "MyShop verified deployment walkthrough (docs/examples/MyShop) — adapted to current schema",
+  "verified": true,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "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": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "Orders are created sitting at the EMPTY initial node \"\" — the first operate call transitions from \"\" to the first real workflow node, so next_node_name names the TARGET node, not the current one.",
+    "next_node_name + forward must TOGETHER match a Pair (prior_node → next_node) defined in the Service's published Machine, with 'forward' naming the specific forward on that pair. A mismatched node or forward name fails on-chain; the launcher's permission/guard for that forward is also enforced by the Machine.",
+    "SCHEMA ADAPTATION (schema wins): the walkthrough used the legacy form {hold: false}; the current canonical schema uses the op enum — hold:false maps to op:'next' (the MCP layer still auto-migrates hold:boolean via preprocess, but new code should use op directly). op semantics: 'next' = advance/accomplish the forward; 'hold' = set hold to BLOCK the forward; 'unhold' = self-release your own hold (no 224 permission needed); 'adminUnhold' = force-release a hold via permission 224 (PROGRESS_UNHOLD).",
+    "This is the canonical progress operate shape: {object, operate: {operation: {next_node_name, forward}, op, message?}} — 'object' is the Progress object name/address (here the namedNewProgress name from order creation).",
+    "env.account is the merchant and is CRITICAL here: launching the 'Confirm Order' forward requires the merchant-side permission configured on the Machine node. Adapted from the doc's mainnet env to testnet + no_cache per example conventions."
+  ]
+}