@wowok/agent-mcp 3.0.0 → 3.0.2

package/dist/examples/machine-template-7node-rental.json

@@ -1,119 +0,0 @@
-{
-  "title": "Machine Template: 7-Node Rental Workflow (Simplified, R-M1-11 Compliant)",
-  "description": "Simplified rental workflow without damage/arbitration paths. Refund flows through an Allocator triggered by the return_approved routing node — never through a Machine terminal node.",
-  "tags": ["machine", "template", "rental", "simplified", "r-m1-11"],
-  "industry": "rental",
-  "operation_type": "machine",
-  "source": "template",
-  "verified": true,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "machine",
-    "data": {
-      "object": {
-        "name": "rental_machine_simple"
-      },
-      "node": {
-        "op": "add",
-        "bReplace": true,
-        "nodes": [
-          {
-            "name": "reserved",
-            "pairs": [
-              {
-                "prev_node": "",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Pay", "weight": 1, "namedOperator": "" }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "paid",
-            "pairs": [
-              {
-                "prev_node": "reserved",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Confirm Payment", "weight": 1, "permissionIndex": 1000 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "in_use",
-            "pairs": [
-              {
-                "prev_node": "paid",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Deliver Item", "weight": 1, "permissionIndex": 1000 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "returned",
-            "pairs": [
-              {
-                "prev_node": "in_use",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Return Item", "weight": 1, "namedOperator": "" }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "inspected",
-            "pairs": [
-              {
-                "prev_node": "returned",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Inspect", "weight": 1, "permissionIndex": 1001 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "return_approved",
-            "pairs": [
-              {
-                "prev_node": "inspected",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Approve Return", "weight": 1, "permissionIndex": 1002 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "completed",
-            "pairs": [
-              {
-                "prev_node": "return_approved",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Complete", "weight": 1, "permissionIndex": 1000 }
-                ]
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "env": {
-      "network": "testnet"
-    }
-  },
-  "notes": [
-    "R-M1-11: 'return_approved' is a ROUTING node — the actual refund MUST be executed by an Allocator (bound via Service.order_allocators) whose Guard checks progress.current == 'return_approved'. A node named 'refunded' implies the Machine itself moves funds, which Machines cannot do; funds would lock in the Order escrow.",
-    "Forwards describe INCOMING transitions: the forward in a node's pair (prev_node='X') is the action that advances Progress FROM X INTO this node.",
-    "The entry node (prev_node='') MUST have at least one forward — schema-enforced (FIX-002).",
-    "namedOperator='' means OrderHolder (customer). permissionIndex references Permission table entries (1000=operator, 1001=inspector, 1002=finance).",
-    "Simplified version — no damage or arbitration paths. Use for short-term rentals without damage risk."
-  ]
-}

package/dist/examples/payment-scenario-bound.json

@@ -1,45 +0,0 @@
-{
-  "title": "Create Scenario-Bound Payment (for_object + for_guard)",
-  "description": "Create a Payment of 0.05 WOW to alice whose payment_info binds it to a Demand object and a KYC Guard, making the fund flow auditable against a business scenario.",
-  "tags": ["payment", "scenario", "for_object", "for_guard", "audit"],
-  "industry": "general",
-  "operation_type": "payment",
-  "source": "constructed under T-09 authorization; grounded in CallPayment_CreateSchema + PaymentInfoSchema — schema-validated, not chain-verified",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "payment",
-    "data": {
-      "object": {
-        "name": "kyc_bounty_payment_v1",
-        "type_parameter": "0x2::wow::WOW"
-      },
-      "revenue": [
-        {
-          "recipient": { "name_or_address": "alice" },
-          "amount": { "balance": 50000000 }
-        }
-      ],
-      "info": {
-        "for_object": "toy_repair_demand_v1",
-        "for_guard": "kyc_level_guard",
-        "remark": "Bounty payout for completed KYC verification demand",
-        "index": 0
-      }
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true,
-      "confirmed": true
-    }
-  },
-  "notes": [
-    "SCENARIO BINDING: info.for_object ties the Payment to a business object (here the Demand it settles); info.for_guard ties it to the Guard whose verification justified the payout (here the KYC Guard). Both are optional but together make the payment self-describing on-chain — auditors can trace WHY the money moved.",
-    "Payment is IMMUTABLE once created: it can only be created, never modified. revenue[] is the full recipient/amount split in one shot (single recipient here; multiple entries split the total).",
-    "amount uses CoinParam {balance: <smallest unit>} — 50000000 = 0.05 WOW (9 decimals). recipient is AccountOrMark_Address OBJECT form {name_or_address}.",
-    "info.remark and info.index are REQUIRED (PaymentInfoSchema); index numbers the payment record for later reference by fees_transfer-style operations.",
-    "The OTHER payment mode (not shown): {object: '<coinwrapper_id>', receive: true, type_parameter: '0x2::wow::WOW'} unwraps a CoinWrapper received from an Allocation split into spendable coins — see CallPayment_ReceiveSchema and the allocation-activate example for the full flow.",
-    "type_parameter goes INSIDE 'object' (TypeNamedObjectSchema) and must match the coin being paid."
-  ]
-}

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

@@ -1,148 +0,0 @@
-{
-  "title": "Create 9-Node Machine for Rental Lifecycle (Ziroom, R-M1-11 Compliant)",
-  "description": "9-node workflow: reserved → paid_deposit → in_use → returned → inspected, then three competing routing branches: return_approved (refund Allocator fires) / damage_confirmed (deduction Allocator fires) / arbiter_rule (off-Machine arbitration). completed follows return_approved.",
-  "tags": ["machine", "rental", "workflow", "nodes", "permission_index", "r-m1-11"],
-  "industry": "rental",
-  "operation_type": "machine",
-  "source": "ziroom testnet deployment 2026-07-29 (repaired to current schema + R-M1-11)",
-  "verified": true,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "machine",
-    "data": {
-      "object": {
-        "name": "ziroom_machine_v1",
-        "tags": ["rental", "machine"],
-        "replaceExistName": true,
-        "permission": "ziroom_permission_v1"
-      },
-      "node": {
-        "op": "add",
-        "bReplace": true,
-        "nodes": [
-          {
-            "name": "reserved",
-            "pairs": [
-              {
-                "prev_node": "",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Reserve", "weight": 1, "namedOperator": "" }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "paid_deposit",
-            "pairs": [
-              {
-                "prev_node": "reserved",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Pay Deposit", "weight": 1, "namedOperator": "" }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "in_use",
-            "pairs": [
-              {
-                "prev_node": "paid_deposit",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Handover", "weight": 1, "permissionIndex": 1000 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "returned",
-            "pairs": [
-              {
-                "prev_node": "in_use",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Return Keys", "weight": 1, "namedOperator": "" }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "inspected",
-            "pairs": [
-              {
-                "prev_node": "returned",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Inspect", "weight": 1, "permissionIndex": 1001 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "return_approved",
-            "pairs": [
-              {
-                "prev_node": "inspected",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Approve Refund", "weight": 1, "permissionIndex": 1002 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "damage_confirmed",
-            "pairs": [
-              {
-                "prev_node": "inspected",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Confirm Damage", "weight": 1, "permissionIndex": 1001 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "arbiter_rule",
-            "pairs": [
-              {
-                "prev_node": "inspected",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Escalate Arbitration", "weight": 1, "permissionIndex": 1500 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "completed",
-            "pairs": [
-              {
-                "prev_node": "return_approved",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Complete", "weight": 1, "permissionIndex": 1000 }
-                ]
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true
-    }
-  },
-  "notes": [
-    "R-M1-11: return_approved / damage_confirmed / arbiter_rule are ROUTING nodes. Fund movement (deposit refund / deduction) MUST be executed by Allocators (Service.order_allocators) whose Guards check progress.current == <routing node>. Never name nodes 'deposit_refunded'/'deposit_deducted'/'refunded' — Machines have no fund movement primitive; misnamed nodes leave funds locked in the Order escrow.",
-    "The three branches from 'inspected' are competing pairs (each threshold=1): the first forward executed wins and the other branches are abandoned for this session.",
-    "Forwards describe INCOMING transitions: a forward in a node's pair (prev_node='X') advances Progress FROM X INTO this node.",
-    "permission lives INSIDE 'object' (NamedObjectWithPermissionSchema) — it references existing Permission 'ziroom_permission_v1' by LocalMark name.",
-    "namedOperator='' means OrderHolder (customer), NOT 'anyone'. permissionIndex maps to Permission table entries (1000=operator, 1001=inspector, 1002=finance, 1500=arbiter).",
-    "Machine nodes are immutable after publish — create a new Machine to change the workflow."
-  ]
-}

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

@@ -1,41 +0,0 @@
-{
-  "title": "Create Permission with Role-Based Indexes (Ziroom Rental)",
-  "description": "Single Permission with indexes: 1000=operator, 1001=inspector, 1002=finance, 1500=arbiter",
-  "tags": ["permission", "rental", "role", "index"],
-  "industry": "rental",
-  "operation_type": "permission",
-  "source": "ziroom testnet deployment 2026-07-29 (repaired to current schema)",
-  "verified": true,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "permission",
-    "data": {
-      "object": {
-        "name": "ziroom_permission_v1",
-        "tags": ["project:ziroom", "type:permission"],
-        "replaceExistName": true
-      },
-      "table": {
-        "op": "add perm by index",
-        "index": 1000,
-        "entity": {
-          "entities": [
-            { "name_or_address": "ziroom_operator" }
-          ],
-          "check_all_founded": false
-        }
-      }
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true
-    }
-  },
-  "notes": [
-    "Custom indexes range 1000-65535 (0-999 are protocol-reserved)",
-    "Single Permission recommended for centralized control across all objects",
-    "Use 'add perm by index' to grant one permission to many entities",
-    "entity is ManyAccountOrMark_AddressSchema OBJECT form {entities: [{name_or_address}], check_all_founded?} — NOT a bare array (schema drift repair 2026-07-30: the 2026-07-29 deployment used the legacy array form; current schema requires the object wrapper). Recipient shown as the operator's local mark name; the original deployment used raw 0x addresses (desensitized)."
-  ]
-}

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

@@ -1,36 +0,0 @@
-{
-  "title": "Create Rental Service DRAFT (Ziroom)",
-  "description": "Step 3 of the 12-step deploy plan: create the Ziroom rental Service object in DRAFT (unpublished) with only its identity — name, permission, payment token type, description, and location. Machine binding, buy_guard, sales (WIP), order_allocators, Contact (um), and publish are each separate later steps and are intentionally NOT bundled here.",
-  "tags": ["service", "rental", "draft", "create", "12-step"],
-  "industry": "rental",
-  "operation_type": "service",
-  "source": "ziroom testnet deployment 2026-07-29 — adapted to the 12-step plan (DRAFT only, schema-validated, not chain-verified)",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "service",
-    "data": {
-      "object": {
-        "name": "ziroom_service_v1",
-        "tags": ["project:ziroom", "type:service"],
-        "replaceExistName": true,
-        "permission": "ziroom_permission_v1",
-        "type_parameter": "0x2::wow::WOW"
-      },
-      "description": "Ziroom apartment rental service",
-      "location": "Beijing"
-    },
-    "env": {
-      "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/buy_guard/um/sales/order_allocators 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.",
-    "Rental is a PHYSICAL-goods scenario and SHOULD declare customer_required (name/phone/shipping_address/id_number for deposit-backed rental). Per the SDK-enforced HARD LINKAGE, customer_required must be set TOGETHER with a Contact bound as um — the buyer's 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 (create the Contact, then bind um + customer_required in one update).",
-    "permission references the pre-created ziroom_permission_v1 (Step 2); type_parameter '0x2::wow::WOW' sets the payment token (WOW, 9 decimals).",
-    "machine, order_allocators, and arbitrations become immutable after publish — set them in their own pre-publish steps, not here."
-  ]
-}

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

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

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

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