@wowok/agent-mcp 3.0.0 → 3.0.2

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

@@ -1,51 +0,0 @@
-{
-  "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

@@ -1,55 +0,0 @@
-{
-  "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

@@ -1,40 +0,0 @@
-{
-  "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

@@ -1,43 +0,0 @@
-{
-  "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

@@ -1,56 +0,0 @@
-{
-  "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

@@ -1,38 +0,0 @@
-{
-  "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."
-  ]
-}

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

@@ -1,35 +0,0 @@
-{
-  "title": "Create Reward Pool Object (MyShop Retail)",
-  "description": "Create an empty Reward object for MyShop service-quality rewards and compensation. The Reward is later referenced by claim Guards that prevent double-claiming, and funded via coin_add.",
-  "tags": ["reward", "claim", "retail"],
-  "industry": "retail",
-  "operation_type": "reward",
-  "source": "MyShop verified deployment walkthrough (docs/examples/MyShop_Advanced) — adapted to current schema",
-  "verified": true,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "reward",
-    "data": {
-      "object": {
-        "name": "myshop_reward_v2",
-        "type_parameter": "0x2::wow::WOW",
-        "permission": "myshop_perm_v2",
-        "replaceExistName": true
-      },
-      "description": "MyShop reward pool for wonderful service and compensation"
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true,
-      "confirmed": true
-    }
-  },
-  "notes": [
-    "Create the Reward EMPTY first (no coin_add, no guard_add): claim Guards are then built to reference this Reward object and use the query_reward_record_exists query instruction for double-claim protection — the Reward object must exist before the Guards that query it can be created.",
-    "Reward MAY share the Service's Permission (here myshop_perm_v2) for unified governance — service.move reward_add_imp has NO permission-conflict check. This is the opposite of Arbitration, which MUST use an independent Permission (E_ARBITRATION_PERMISSION_CONFLICT).",
-    "Adaptation: the doc omitted type_parameter — schema-valid because TokenTypeWithDefaultSchema defaults to '0x2::wow::WOW'; shown explicitly here for clarity.",
-    "Fund the pool later with coin_add; claimants trigger distribution by passing their claim Guard address in the 'claim' field. guard_add registers which Guards may claim from this Reward.",
-    "name/permission live INSIDE 'object' (TypeNamedObjectWithPermissionSchema). replaceExistName:true force-rebinds the local name if already taken — use deliberately."
-  ]
-}

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

@@ -1,38 +0,0 @@
-{
-  "title": "Create Retail Service DRAFT (MyShop E-Commerce)",
-  "description": "Step 3 of the 12-step deploy plan: create the MyShop retail Service object in DRAFT (unpublished) with only its identity — name, permission, payment token type, description, and location. Machine binding, sales (WIP), order_allocators, Contact (um), and publish are each separate later steps and are intentionally NOT bundled here.",
-  "tags": ["service", "retail", "ecommerce", "draft", "create", "12-step"],
-  "industry": "retail",
-  "operation_type": "service",
-  "source": "myshop deployment walkthrough (docs/examples/MyShop) — adapted to the 12-step plan + testnet (DRAFT only, schema-validated, not chain-verified)",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "service",
-    "data": {
-      "object": {
-        "name": "myshop_service_v2",
-        "type_parameter": "0x2::wow::WOW",
-        "permission": "myshop_permission_v2",
-        "tags": ["ecommerce", "toys", "store"],
-        "onChain": false,
-        "replaceExistName": true
-      },
-      "description": "MyShop - Top quality toys for children",
-      "location": "Online Store"
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "testnet",
-      "no_cache": true
-    }
-  },
-  "notes": [
-    "12-STEP PLAN alignment: this file is ONE step (Step 3 Service DRAFT). The full order is Account → Permission → Service DRAFT → Machine → Guard → Machine publish → Sales(WIP) → Treasury(optional) → order_allocators → Contact(um) → Arbitration → Service publish. Do NOT bundle machine/sales/order_allocators/um/publish into the create call.",
-    "object uses the OBJECT form of TypeNamedObjectWithPermissionSchema: name/permission/type_parameter go INSIDE object; description and location are top-level Service fields. No publish:true here — the Service stays unpublished until Step 12.",
-    "Physical-goods services SHOULD declare customer_required (e.g. name/phone/shipping_address) so the buyer's delivery info is captured. Per the SDK-enforced HARD LINKAGE, customer_required must be set TOGETHER with a Contact bound as um (the private info is delivered only through the Contact's end-to-end encrypted Messenger). Therefore customer_required is NOT set in this DRAFT — it is set together with um in the Contact step (see retail-myshop-contact-create.json, then bind um + customer_required in one update).",
-    "permission references the pre-created myshop_permission_v2 (Step 2); type_parameter '0x2::wow::WOW' sets the payment token (WOW, 9 decimals). onChain:false keeps the local name private (not published on-chain).",
-    "machine, order_allocators, and arbitrations become immutable after publish — set them in their own pre-publish steps, not here."
-  ]
-}

package/dist/examples/retail-myshop-service-customer-required.json

@@ -1,31 +0,0 @@
-{
-  "title": "Bind Contact (um) + customer_required Together (MyShop Retail)",
-  "description": "Contact step (12-step plan): set the Service's customer_required labels and bind its Contact (um) in ONE operation. The SDK enforces the HARD LINKAGE — customer_required without um is rejected, because the buyer's private information (name/phone/shipping_address) is delivered only through the Contact's end-to-end encrypted Messenger.",
-  "tags": ["service", "customer_required", "um", "contact", "messenger", "retail", "hard-linkage", "12-step"],
-  "industry": "retail",
-  "operation_type": "service",
-  "source": "adapted to the 12-step plan + SDK customer_required⟶um hard linkage (schema-validated, not chain-verified)",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "service",
-    "data": {
-      "object": "myshop_service_v2",
-      "customer_required": ["name", "phone", "shipping_address"],
-      "um": "myshop_aftersales_contact_v2"
-    },
-    "env": {
-      "account": "myshop_merchant",
-      "network": "testnet",
-      "no_cache": true
-    }
-  },
-  "notes": [
-    "HARD LINKAGE (SDK-enforced, service.ts checkCustomerRequiredNeedsUm): customer_required and um MUST be set together. The buyer's private info is delivered via end-to-end encrypted Messenger, which routes to the Contact bound as um — without um there is no channel and the SDK rejects the call with InvalidParam.",
-    "object is the STRING form (existing unpublished service); customer_required is an array of info labels (NotEmptyNameSchema); um is the Contact name/ID created in the Contact step (see retail-myshop-contact-create.json).",
-    "ORDER FLOW: after a customer places an order on this Service, they MUST send each customer_required field to this Contact's Messenger (messenger_operation → send_message) and obtain an explicit confirmation reply; the resulting Contact ID or WTS Proof can be recorded on the Order via OrderNewSchema.order_required_info.",
-    "customer_required and um remain MUTABLE after publish (L3 in the immutability matrix), but for physical goods set them BEFORE publish so customers get the right flow from day one.",
-    "The referenced Contact (myshop_aftersales_contact_v2) must exist and have an ims[] entry pointing at the merchant's Messenger account (account name, not messenger name)."
-  ]
-}

package/dist/examples/service-discount-issue.json

@@ -1,46 +0,0 @@
-{
-  "title": "Issue Discount Coupons to Customers (Service)",
-  "description": "Issue 100 transferable=false 10%-off RATES discount coupons named summer_2026_10pct for myshop_service_v2, targeted at a specific customer, valid until end of 2026.",
-  "tags": ["service", "discount", "coupon", "marketing", "retail"],
-  "industry": "retail",
-  "operation_type": "service",
-  "source": "constructed under T-09 authorization; grounded in DiscountSchema + DiscountTypeSchema + service.ts SDK — schema-validated, not chain-verified",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "service",
-    "data": {
-      "object": "myshop_service_v2",
-      "discount": {
-        "name": "summer_2026_10pct",
-        "discount_type": "RATES",
-        "discount_value": 1000,
-        "benchmark": 100000000,
-        "time_ms_start": 1782864000000,
-        "time_ms_end": 1798761599000,
-        "count": 100,
-        "recipient": {
-          "entities": [
-            { "name_or_address": "alice" }
-          ],
-          "check_all_founded": false
-        },
-        "transferable": false
-      }
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true,
-      "confirmed": true
-    }
-  },
-  "notes": [
-    "discount_type 'RATES' means discount_value is a RATIO in ten-thousandths: 1000 = 1000/10000 = 10% off. 'FIXED' (numeric 1) means discount_value is a fixed deduction in the token's smallest unit. String form ('RATES'/'FIXED') is recommended over numeric 0/1.",
-    "benchmark (optional): the discount only applies when the order amount EXCEEDS this value (smallest unit; 100000000 = 0.1 WOW). Omit for unconditional discounts.",
-    "time_ms_start/time_ms_end are Unix MILLISECONDS (not seconds). time_ms_end is REQUIRED; time_ms_start optional (starts immediately if omitted). 1782864000000 = 2026-07-01T00:00:00Z, 1798761599000 = 2026-12-31T15:59:59Z.",
-    "count = total usage count across all issued coupon objects; recipient.entities lists the receiving accounts (object form {name_or_address}); check_all_founded:false tolerates unresolved names instead of aborting.",
-    "transferable:false locks the coupon to the recipient (cannot be sold/gifted). Each issued coupon is a separate on-chain Discount object owned by the recipient; customers attach it at order time via order_new buy.discount (discount object ID or name).",
-    "Cleanup: issued discounts can be destroyed later via discount_destroy: ['<discount_object_id_or_name>']. Issuing discounts is an L3 operation on a live Service — no pause required."
-  ]
-}

package/dist/examples/subscription-contact-create.json

@@ -1,40 +0,0 @@
-{
-  "title": "Create Subscription Contact Object",
-  "description": "Create a named Contact object for a subscription service, with a Permission reference and an IM entry pointing at the support account",
-  "tags": ["contact", "messenger", "ims", "subscription"],
-  "industry": "subscription",
-  "operation_type": "contact",
-  "source": "Template-generated from K2 industry defaults (not chain-verified)",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "contact",
-    "data": {
-      "object": {
-        "name": "subscription_contact",
-        "permission": "subscription_permission",
-        "replaceExistName": true
-      },
-      "description": "Subscription support contact — manage your plan, pause, or cancel anytime",
-      "ims": {
-        "op": "add",
-        "im": [
-          {
-            "at": "subscription_support",
-            "description": "Primary support account"
-          }
-        ]
-      }
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true,
-      "confirmed": true
-    }
-  },
-  "notes": [
-    "Bind this Contact to the subscription Service via the service call's 'um' field.",
-    "Subscription billing should use charge_guard_signer (explicit user signature per period)."
-  ]
-}

package/dist/examples/threebody-guard-create.json

@@ -1,56 +0,0 @@
-{
-  "title": "Create Signer-Identity Buy Guard — Strict Single-Identity Binding (ThreeBody Signature)",
-  "description": "Guard that passes only when the transaction signer equals the fixed author address stored in the Guard table (logic_equal[context(Signer), identifier(0)]). Bound as Service buy_guard so only the author can purchase the signature service — Level 1 strict single-identity binding.",
-  "tags": ["guard", "buy_guard", "signer-identity", "signature", "allowlist"],
-  "industry": "general",
-  "operation_type": "guard",
-  "source": "docs/examples/ThreeBody_Signature — schema-validated, not chain-verified",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "guard",
-    "data": {
-      "namedNew": {
-        "name": "threebody_buy_guard",
-        "tags": ["signature", "buy-guard", "level1-strict"],
-        "replaceExistName": true
-      },
-      "description": "Verify buyer is the service author (signer_author). Only the author can purchase this signature service. LEVEL 1 strict single-identity binding: the author role is permanently tied to one address; if the address is lost/rotated, rebuild the Guard and re-bind Service.buy_guard.",
-      "table": [
-        {
-          "identifier": 0,
-          "b_submission": false,
-          "value_type": "Address",
-          "value": "signer_author",
-          "name": "Author address"
-        }
-      ],
-      "root": {
-        "type": "logic_equal",
-        "nodes": [
-          {
-            "type": "context",
-            "context": "Signer"
-          },
-          {
-            "type": "identifier",
-            "identifier": 0
-          }
-        ]
-      }
-    },
-    "env": {
-      "account": "signer_author",
-      "network": "testnet",
-      "confirmed": true
-    }
-  },
-  "notes": [
-    "Verified against CallGuard_DataSchema (schema/call/guard.ts): namedNew/description/table/root are the strict top-level fields; table items match GuardTableItemBaseSchema strict shape {identifier, b_submission, value_type, value, name} (common/index.ts) — value_type 'Address' string form accepted by ValueTypeUserSchema.",
-    "Root must return Bool: logic_equal is in the allowed root list (CallGuard_RootSchema refine). context node uses enum ['Signer'|'Clock'|'Guard'] (GuardNodeSchema, query/index.ts); identifier node references table identifier 0.",
-    "The Address table value uses a LOCAL-MARK account name ('signer_author'), resolved to an address at transaction build time — this also breaks the Guard<->Service circular dependency (bind by name, publish later).",
-    "Guard is IMMUTABLE once created: the whitelist cannot be tampered with, but a lost/rotated author address requires building a new Guard and re-binding buy_guard (documented lock-in trade-off, R-C4-04).",
-    "DESENSITIZED: doc account 'three_body_author' -> 'signer_author'; guard renamed to local mark 'threebody_buy_guard'."
-  ]
-}

package/dist/examples/threebody-machine-create.json

@@ -1,71 +0,0 @@
-{
-  "title": "Create Signature-Approval Machine DRAFT (ThreeBody Signature)",
-  "description": "Step 4 of the 12-step deploy plan: create the two-node signing workflow 'Book Delivered -> Signature Completed' in DRAFT (unpublished). Each forward is gated by its own permissionIndex (1000/1001), so only accounts granted that index in the Permission object can advance that stage. Publish is a separate later step (machine-publish.json) — do NOT bundle publish here.",
-  "tags": ["machine", "multisig", "signature", "approval-gate", "permissionIndex", "draft", "12-step"],
-  "industry": "general",
-  "operation_type": "machine",
-  "source": "docs/examples/ThreeBody_Signature — adapted to the 12-step plan (DRAFT only, schema-validated, not chain-verified)",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "machine",
-    "data": {
-      "object": {
-        "name": "threebody_machine",
-        "permission": "threebody_permission",
-        "replaceExistName": true
-      },
-      "description": "Signature service workflow: Book Delivered -> Signature Completed",
-      "node": {
-        "op": "add",
-        "nodes": [
-          {
-            "name": "Book Delivered",
-            "pairs": [
-              {
-                "prev_node": "",
-                "threshold": 0,
-                "forwards": [
-                  {
-                    "name": "Confirm Delivery",
-                    "permissionIndex": 1000,
-                    "weight": 1
-                  }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "Signature Completed",
-            "pairs": [
-              {
-                "prev_node": "Book Delivered",
-                "threshold": 1,
-                "forwards": [
-                  {
-                    "name": "Complete Signature",
-                    "permissionIndex": 1001,
-                    "weight": 1
-                  }
-                ]
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "env": {
-      "account": "signer_author",
-      "network": "testnet"
-    }
-  },
-  "notes": [
-    "12-STEP PLAN alignment: this is ONE step (Step 4 Machine DRAFT). Do NOT bundle publish:true here — publish is Step 6 (see machine-publish.json). The 12-step order is Service DRAFT → Machine (nodes/forwards) → Guard → bind Guards → Machine publish.",
-    "Shapes verified against MachineNodeSchema / MachineNodePairSchema / MachineForwardSchema (schema/query/index.ts) + CallMachine_DataSchema (schema/call/machine.ts). Forwards use camelCase permissionIndex (namedOperator is the alternative); the schema-level one-of refine requires namedOperator OR permissionIndex on every forward.",
-    "Entry-forward invariant satisfied: pair with prev_node='' has >=1 forward (FIX-002). The FIX-02 publish-time entry-forward refine will also pass when this DRAFT is later published — 'Confirm Delivery' covers both.",
-    "Threshold semantics: pair 1 threshold 0 is exempt (single-forward pair — one signature advances). Pair 2 threshold 1 equals the summed weight of its single forward. MULTI-SIG EXTENSION: add more forwards {permissionIndex or namedOperator, weight} to the pair and set threshold > 1 — the node only advances once accumulated signature weight >= threshold (e.g. 2-of-3 approvers).",
-    "This is a DRAFT (no publish:true). Once published, nodes/pairs/forwards become irreversibly locked and env.confirmed:true is required at publish time.",
-    "DESENSITIZED: doc account 'three_body_author' -> 'signer_author'; objects renamed to local marks 'threebody_machine' / 'threebody_permission'."
-  ]
-}