@wowok/agent-mcp 2.6.3 → 2.6.6

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

@@ -0,0 +1,35 @@
+{
+  "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/service-discount-issue.json

@@ -0,0 +1,46 @@
+{
+  "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/threebody-guard-create.json

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

@@ -0,0 +1,72 @@
+{
+  "title": "Create Signature-Approval Machine with Permission-Gated Forwards (ThreeBody Signature)",
+  "description": "Two-node signing workflow 'Book Delivered -> Signature Completed'. Each forward is gated by its own permissionIndex (1000/1001), so only accounts granted that index in the Permission object can advance that stage. Extendable to M-of-N multi-signature gates by adding weighted forwards and raising pair threshold.",
+  "tags": ["machine", "multisig", "signature", "approval-gate", "permissionIndex", "publish"],
+  "industry": "general",
+  "operation_type": "machine",
+  "source": "docs/examples/ThreeBody_Signature — 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
+                  }
+                ]
+              }
+            ]
+          }
+        ]
+      },
+      "publish": true
+    },
+    "env": {
+      "account": "signer_author",
+      "network": "testnet",
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "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 invariants satisfied: pair with prev_node='' has >=1 forward (FIX-002), and publish:true on a NEW machine requires an entry forward (FIX-02 refine) — '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).",
+    "publish: true IRREVERSIBLY locks nodes/pairs/forwards — env.confirmed: true required (ConfirmGate).",
+    "DESENSITIZED: doc account 'three_body_author' -> 'signer_author'; objects renamed to local marks 'threebody_machine' / 'threebody_permission'."
+  ]
+}

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

@@ -0,0 +1,38 @@
+{
+  "title": "Create Permission with Role Indexes for Signing Workflow (ThreeBody Signature)",
+  "description": "Permission object for a signature/approval service: grants the author account user-defined indexes 1000-1009 (1000 gates the 'Confirm Delivery' forward, 1001 gates the 'Complete Signature' forward, 1002-1009 reserved) plus built-in index 306 (SERVICE_MACHINE) for binding the Machine to the Service.",
+  "tags": ["permission", "multisig", "signature", "role-index", "approval-workflow"],
+  "industry": "general",
+  "operation_type": "permission",
+  "source": "docs/examples/ThreeBody_Signature — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "permission",
+    "data": {
+      "object": {
+        "name": "threebody_permission",
+        "replaceExistName": true
+      },
+      "description": "Permission for ThreeBody signature service (multi-role signing workflow)",
+      "table": {
+        "op": "add perm by entity",
+        "entity": { "name_or_address": "signer_author" },
+        "index": [1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 306]
+      }
+    },
+    "env": {
+      "account": "signer_author",
+      "network": "testnet",
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "Shape verified against CallPermission_DataSchema (schema/call/permission.ts): 'add perm by entity' = TablePermByEntitySchema {entity: AccountOrMark_AddressSchema, index: PermissionIndexTypeSchema[]} — entity-centric grant of MANY indexes to ONE account.",
+    "Index validity (PermissionIndexTypeSchema, schema/query/index.ts): user-defined indexes must be 1000-65535; 306 is built-in SERVICE_MACHINE (authorizes binding a Machine to a Service).",
+    "Multi-signer pattern: grant DIFFERENT forward indexes to DIFFERENT signer accounts (e.g. 'add perm by index' {index: 1000, entity: [signer_a, signer_b]}) so each Machine forward is gated to its own approver set; the creator is auto-admin and bypasses per-index checks, so these grants only bite for non-admin operators.",
+    "DESENSITIZED: doc account 'three_body_author' -> 'signer_author' (generic role name); object renamed to local-mark 'threebody_permission'.",
+    "replaceExistName: true triggers ConfirmGate — env.confirmed: true is required or the call blocks with pending_confirmation."
+  ]
+}

package/dist/examples/threebody-service-allocators.json

@@ -0,0 +1,49 @@
+{
+  "title": "Configure Order Allocators with Entity-Treasury Recipient (ThreeBody Signature)",
+  "description": "Pre-publish Service configuration: 100% of completed-order funds route to the fixed Treasury object via an allocator Guard that verifies order.service == this service. Entity(treasury) recipient makes the fund flow caller-independent (no Signer binding needed). Also sets customer_required contact fields.",
+  "tags": ["service", "order_allocators", "treasury-first", "allocation", "guard", "signature"],
+  "industry": "general",
+  "operation_type": "service",
+  "source": "docs/examples/ThreeBody_Signature — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "service",
+    "data": {
+      "object": "threebody_signature_service",
+      "order_allocators": {
+        "description": "Signature service fund allocation - 100% to author Treasury",
+        "threshold": 0,
+        "allocators": [
+          {
+            "guard": "threebody_allocator_guard",
+            "sharing": [
+              {
+                "who": {
+                  "Entity": { "name_or_address": "threebody_treasury" }
+                },
+                "sharing": 10000,
+                "mode": "Rate"
+              }
+            ]
+          }
+        ]
+      },
+      "customer_required": ["phone", "email", "shipping_address"]
+    },
+    "env": {
+      "account": "signer_author",
+      "network": "testnet"
+    }
+  },
+  "notes": [
+    "Verified against CallService_DataSchema (schema/call/service.ts): order_allocators matches AllocatorsSchema (query/index.ts) {description, threshold, allocators[]}; sharing items match AllocationSharingSchema {who: RecipientSchema, sharing, mode}.",
+    "Recipient form: {Entity: {name_or_address: 'threebody_treasury'}} — Entity is an OBJECT with name_or_address, NOT a bare string (RecipientSchema). Funds flow to the fixed Treasury regardless of who triggers allocation (R-C3-06 safe); the referenced allocator Guard separately verifies order.service == this service (R-C3-05).",
+    "Rate mode: sharing 10000 = 100% (basis points); Rate items in one allocator must sum to 10000 when no Surplus item exists. threshold 0 allows allocation of any balance.",
+    "ORDER_ALLOCATORS IS PERMANENTLY IMMUTABLE AFTER PUBLISH (service.move:503) — this call must run BEFORE publish:true; the Service must also be unpublished when the machine field was bound earlier.",
+    "Prerequisite objects (created by separate calls, not shown): 'threebody_signature_service' (service, unpublished), 'threebody_allocator_guard' (guard: logic_equal[query order.service, identifier(service)]), 'threebody_treasury' (treasury sharing this service's permission).",
+    "customer_required entries validated against NotEmptyNameSchema (non-empty, <=64 bcs chars).",
+    "DESENSITIZED: doc account 'three_body_author' -> 'signer_author'; objects renamed to local marks ('threebody_signature_service', 'threebody_treasury', 'threebody_allocator_guard')."
+  ]
+}

package/dist/examples/travel-guard-time-lock.json

@@ -0,0 +1,69 @@
+{
+  "title": "Create Time-Lock Guard via Order-Witness Progress Query (Travel)",
+  "description": "Create a Guard that enforces a relative time-lock before order completion: passes only when the on-chain Clock exceeds the order's Progress current-node entry timestamp plus a fixed duration. The runtime submission is the ORDER id, transparently converted to its Progress via convert_witness='OrderProgress'.",
+  "tags": ["guard", "travel", "time-lock", "clock", "witness", "OrderProgress", "forward-guard"],
+  "industry": "travel",
+  "operation_type": "guard",
+  "source": "docs/examples/Travel — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "guard",
+    "data": {
+      "namedNew": {
+        "name": "travel_complete_guard",
+        "tags": ["travel", "time-lock", "complete"],
+        "replaceExistName": true
+      },
+      "description": "Time-lock guard for travel order completion. Requires current clock > progress.current_time + 1000ms.",
+      "table": [
+        {
+          "identifier": 0,
+          "b_submission": true,
+          "value_type": "Address",
+          "name": "Order ID (submitted at runtime)"
+        },
+        {
+          "identifier": 1,
+          "b_submission": false,
+          "value_type": "U64",
+          "value": 1000,
+          "name": "Time-lock duration in ms"
+        }
+      ],
+      "root": {
+        "type": "logic_as_u256_greater",
+        "nodes": [
+          {"type": "context", "context": "Clock"},
+          {
+            "type": "calc_number_add",
+            "nodes": [
+              {
+                "type": "query",
+                "query": "progress.current_time",
+                "object": {"identifier": 0, "convert_witness": "OrderProgress"},
+                "parameters": []
+              },
+              {"type": "identifier", "identifier": 1}
+            ]
+          }
+        ]
+      }
+    },
+    "env": {
+      "account": "travel_provider",
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "Order-witness time-lock pattern: the Guard table receives the ORDER id at runtime (identifier 0, b_submission:true), and the query node converts it to the order's associated Progress object via convert_witness='OrderProgress' (WitnessTypeSchema, id 100) before reading progress.current_time (query id 1272, returns U64 ms — the current-node entry timestamp). Root is logic_as_u256_greater[context Clock, calc_number_add[current_time, duration]] — i.e. now > entry_time + lock_duration. Root returns Bool via a logic_as_u256_* comparison, satisfying CallGuard_RootSchema.",
+    "Node-shape check (query/index.ts GuardNodeSchema, strict): context node {type:'context', context:'Clock'} — Clock returns the current on-chain timestamp (U64 ms); calc_number_add carries a 'nodes' array and returns U256; the query node carries query + object{identifier, convert_witness?} + optional parameters ([] here — progress.current_time takes no parameters). All field names verified against the discriminated union members.",
+    "Difference from the sibling library example guard-template-time-lock.json: the template submits the PROGRESS address directly and compares current_time >= an ABSOLUTE deadline stored in the table. This travel variant instead submits the ORDER id (witness conversion), uses a Clock context node, and enforces a RELATIVE duration (entry_time + delta) — use this form when the caller naturally holds the Order id and the lock is 'wait N ms after entering the node' rather than 'wait until date D'.",
+    "duration value 1000 (ms, 1 second) is TEST-ONLY so the example can complete immediately; production should use hours/days (e.g. 28800000 = 8h). The duration is static (b_submission:false) so it cannot be manipulated per-trigger.",
+    "Bound to the Machine's complete_trip forward (see sibling travel-machine-create example). Because Forward.guard verifies BEFORE the transition, current_time is still the entry timestamp of the CURRENT node (Ice Scooting) — exactly the intended anchor. Guards are immutable once created.",
+    "Desensitization: doc payload already uses generic local-mark names only (travel_provider, travel_complete_guard); no real personal data or raw 0x object addresses present — nothing replaced."
+  ]
+}

package/dist/examples/travel-guard-weather-oracle.json

@@ -0,0 +1,70 @@
+{
+  "title": "Create Weather Oracle Guard via Repository Quote (Travel)",
+  "description": "Create a Guard that passes only when a weather record EXISTS for the submitted activity date: root query 'repository.data has' on the weather Repository with the runtime-submitted UTC-midnight timestamp converted via convert_number_address. Bound to the Machine's go_ice_scooting forward to gate weather-dependent activities.",
+  "tags": ["guard", "travel", "weather", "oracle", "repository", "query", "forward-guard"],
+  "industry": "travel",
+  "operation_type": "guard",
+  "source": "docs/examples/Travel — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "guard",
+    "data": {
+      "namedNew": {
+        "name": "weather_check_guard",
+        "tags": ["weather", "check", "travel"],
+        "replaceExistName": true
+      },
+      "description": "Weather check guard for ice scooting activity. Checks if weather data exists for the activity date.",
+      "table": [
+        {
+          "identifier": 0,
+          "b_submission": false,
+          "value_type": "Address",
+          "value": "weather_repo",
+          "name": "Weather Repository address"
+        },
+        {
+          "identifier": 1,
+          "b_submission": false,
+          "value_type": "String",
+          "value": "Condition",
+          "name": "Repository policy name"
+        },
+        {
+          "identifier": 2,
+          "b_submission": true,
+          "value_type": "U64",
+          "name": "Activity date timestamp (submitted at runtime)"
+        }
+      ],
+      "root": {
+        "type": "query",
+        "query": "repository.data has",
+        "object": {"identifier": 0},
+        "parameters": [
+          {"type": "identifier", "identifier": 1},
+          {
+            "type": "convert_number_address",
+            "node": {"type": "identifier", "identifier": 2}
+          }
+        ]
+      }
+    },
+    "env": {
+      "account": "travel_provider",
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "Weather-oracle-via-Repository pattern: an external data provider (weather_provider account) publishes timestamp-keyed records into a Repository policy ('Condition'); this Guard quotes that Repository at workflow-runtime to prove a record exists for the activity date before allowing the Ice Scooting forward. This is the canonical way to oracle off-chain data into a Machine transition without trusting the caller.",
+    "Query signature check (ts-sdk packages/wowok guard-ins.ts, id 1166 'repository.data has'): parameters [String policyName, Address dataId], returns Bool — so it is a valid ROOT node (call/guard.ts CallGuard_RootSchema refine allows 'query' roots only for Bool-returning queries). Parameter 2 must be Address type: the U64 timestamp is wrapped in convert_number_address (GuardNodeSchema {type:'convert_number_address', node}) to produce the data-id key the Repository uses.",
+    "Table check (common/index.ts GuardTableItemBaseSchema, strict — only identifier/b_submission/value_type/value/name): identifiers 0-1 are static (b_submission:false, value fixed at creation — note identifier 0 holds the Repository by local-mark NAME 'weather_repo', resolved to an address at build time; the repo name must be resolvable by THIS account, which is why the doc sets onChain:true on weather_repo for cross-account resolution). Identifier 2 is b_submission:true with NO value — supplied per-trigger via the top-level submission field when operating the Progress forward.",
+    "Timestamp alignment contract: Repository data is keyed by the exact numeric id written by the data provider; the activity_date submitted at Guard trigger time must EXACTLY equal that id (doc aligns both to UTC 00:00:00 via Math.floor(now/86400000)*86400000). A mismatch makes the query return false and the Guard fails. This Guard checks EXISTENCE only — it does not compare the weather value ('sunny' vs 'rainy'); value-based rejection would require the 'repository.data' query plus a comparison node.",
+    "Guards are IMMUTABLE once created — create before binding into the Machine forward (see sibling travel-machine-create example).",
+    "Desensitization: doc payload already uses generic local-mark names only (travel_provider, weather_repo, weather_check_guard); no real personal data or raw 0x object addresses present — nothing replaced."
+  ]
+}

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

@@ -0,0 +1,136 @@
+{
+  "title": "Create and Publish Multi-Segment Travel Machine with Forward Guards",
+  "description": "Create a 5-node Iceland travel workflow Machine (entry -> Buy Insurance -> SPA -> Ice Scooting -> Complete/Cancel) and publish it in one transaction. Three forwards are gated by Guards: weather oracle check (go_ice_scooting), time-lock (complete_trip), and always-pass cancel (cancel_trip). Each forward uses a distinct permissionIndex.",
+  "tags": ["machine", "travel", "workflow", "forward-guard", "publish", "multi-node"],
+  "industry": "travel",
+  "operation_type": "machine",
+  "source": "docs/examples/Travel — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "machine",
+    "data": {
+      "object": {
+        "name": "travel_machine",
+        "permission": "travel_permission",
+        "replaceExistName": true
+      },
+      "description": "Iceland travel service workflow: (init) -> Buy Insurance -> SPA -> Ice Scooting -> Complete/Cancel",
+      "node": {
+        "op": "add",
+        "bReplace": true,
+        "nodes": [
+          {
+            "name": "Buy Insurance",
+            "pairs": [
+              {
+                "prev_node": "",
+                "threshold": 1,
+                "forwards": [
+                  {
+                    "name": "buy_insurance",
+                    "weight": 1,
+                    "permissionIndex": 1000
+                  }
+                ]
+              }
+            ]
+          },
+          {
+            "name": "SPA",
+            "pairs": [
+              {
+                "prev_node": "Buy Insurance",
+                "threshold": 1,
+                "forwards": [
+                  {
+                    "name": "go_spa",
+                    "weight": 1,
+                    "permissionIndex": 1001
+                  }
+                ]
+              }
+            ]
+          },
+          {
+            "name": "Ice Scooting",
+            "pairs": [
+              {
+                "prev_node": "SPA",
+                "threshold": 1,
+                "forwards": [
+                  {
+                    "name": "go_ice_scooting",
+                    "weight": 1,
+                    "permissionIndex": 1004,
+                    "guard": {
+                      "guard": "weather_check_guard",
+                      "retained_submission": []
+                    }
+                  }
+                ]
+              }
+            ]
+          },
+          {
+            "name": "Complete",
+            "pairs": [
+              {
+                "prev_node": "Ice Scooting",
+                "threshold": 1,
+                "forwards": [
+                  {
+                    "name": "complete_trip",
+                    "weight": 1,
+                    "permissionIndex": 1002,
+                    "guard": {
+                      "guard": "travel_complete_guard",
+                      "retained_submission": []
+                    }
+                  }
+                ]
+              }
+            ]
+          },
+          {
+            "name": "Cancel",
+            "pairs": [
+              {
+                "prev_node": "Ice Scooting",
+                "threshold": 1,
+                "forwards": [
+                  {
+                    "name": "cancel_trip",
+                    "weight": 1,
+                    "permissionIndex": 1003,
+                    "guard": {
+                      "guard": "travel_cancel_guard",
+                      "retained_submission": []
+                    }
+                  }
+                ]
+              }
+            ]
+          }
+        ]
+      },
+      "publish": true
+    },
+    "env": {
+      "account": "travel_provider",
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "Multi-segment workflow pattern: 5 nodes form a linear chain with a terminal fork — Ice Scooting has TWO outgoing paths (complete_trip -> Complete, cancel_trip -> Cancel), each guarded differently. Demonstrates per-forward Guard binding (Forward.guard) combined with per-forward permissionIndex, the canonical way to put conditional gates on workflow transitions.",
+    "Schema check (call/machine.ts CallMachine_DataSchema, strict): 'object' uses the OBJECT form of WithPermissionObjectSchema (NamedObjectWithPermissionSchema — name, permission, replaceExistName); node uses NodeSchema op='add' with bReplace:true + nodes array; publish=true on NEW machine creation triggers the FIX-02 entry-forward refine — satisfied because the 'Buy Insurance' pair has prev_node='' with a non-empty forwards list (FIX-002).",
+    "Pair/forward semantics (query/index.ts MachineNodePairSchema): 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. Field is 'prev_node' (NOT 'prior_node' — that name only appears in the separate 'add forward'/'remove forward' ops). threshold is per-pair; weight sums across the pair's forwards must reach threshold to advance.",
+    "Forward check (query/index.ts MachineForwardSchema, strict — only name/namedOperator/permissionIndex/weight/guard allowed): every forward provides permissionIndex (1000-1004), satisfying the one-of namedOperator/permissionIndex refine (namedOperator:'' is the order-owner wildcard alternative). Guarded forwards use the OBJECT guard form {guard: '<name>', retained_submission: []} (MachineForwardGuardSchema); a plain string shorthand 'guard': '<name>' is also accepted via preprocess when no retained_submission is needed.",
+    "Guard evaluation order: Forward.guard verifies BEFORE the transition executes, so a forward Guard querying THIS progress's progress.current sees the SOURCE node, not the target. Here weather_check_guard queries an external Repository (safe) and travel_complete_guard queries time-lock data (safe); neither checks progress.current == target, which would always fail.",
+    "publish:true is IRREVERSIBLE and freezes the node set — nodes cannot be changed after publish, and only published Machines can bind to a Service (service.machine). Guards referenced by name (weather_check_guard, travel_complete_guard, travel_cancel_guard) and the Permission (travel_permission, with indexes 1000-1004 granted to the operator) must exist BEFORE this call — see the sibling travel-guard-weather-oracle / travel-guard-time-lock examples and Travel doc Steps 1/3.",
+    "Desensitization: doc payload already uses generic local-mark names only (travel_provider, travel_machine, travel_permission, guard names); no real personal data, phone numbers, or raw 0x object addresses present — nothing replaced."
+  ]
+}

package/dist/examples/travel-repository-create.json

@@ -0,0 +1,47 @@
+{
+  "title": "Create Data Repository with Write Policy (Travel)",
+  "description": "Create an on-chain Repository (weather_repo) with a 'Condition' policy defining write rules (write_guard, id_from, value_type) for travel weather data shared across accounts",
+  "tags": ["repository", "policies", "write_guard", "travel", "data"],
+  "industry": "travel",
+  "operation_type": "repository",
+  "source": "Travel verified deployment walkthrough (docs/examples/Travel) — adapted to current schema",
+  "verified": true,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "repository",
+    "data": {
+      "object": {
+        "name": "weather_repo",
+        "permission": "weather_permission",
+        "replaceExistName": true,
+        "onChain": true
+      },
+      "description": "Weather data repository for Iceland travel activities",
+      "policies": {
+        "op": "add",
+        "policy": [
+          {
+            "name": "Condition",
+            "description": "Weather condition policy for activity dates",
+            "write_guard": [],
+            "id_from": "None",
+            "value_type": "String"
+          }
+        ]
+      }
+    },
+    "env": {
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "onChain:true is REQUIRED here for cross-account name resolution: weather_repo is created by the weather_provider account, but its name is later referenced in a Guard table by the travel_provider account. Without onChain:true the name is stored LOCALLY ONLY on the creator's device (private) and cannot be resolved by any other account; with onChain:true the name is published on-chain and becomes publicly visible/resolvable.",
+    "write_guard semantics: the schema is z.array(PolicyWriteGuardSchema) with no minimum length, so an EMPTY array is valid and means NO Guard verification is required to write data under this policy — writes are gated only by the Repository's Permission. Non-empty entries must be PolicyWriteGuard OBJECTS {guard, id_from_submission?, data_from_submission?}, never bare guard-name strings.",
+    "id_from 'None' means the writer MUST specify the data ID explicitly on every write (IdFromSchema accepts 0/1/2 or 'None'/'Clock'/'Signer', case-insensitive). 'Clock' makes the data ID the current on-chain timestamp; 'Signer' makes it the writer's address.",
+    "policies is an op discriminated union: {op:'add'|'set', policy:[PolicyRule...]} | {op:'remove', policy:[name strings...]} | {op:'clear'} — never a bare array. PolicyRule requires name, description, write_guard, id_from, value_type (quote_guard is optional; value_type 'String' is a valid ValueTypeSchema literal).",
+    "Doc payload validated against current CallRepository_DataSchema with no drift; only restructured from the raw MCP envelope (data.operation_type/data.data) into the example-library call shape. The verified walkthrough executed this call with env.account='weather_provider' (a different account than travel_provider, which is exactly why onChain:true matters)."
+  ]
+}