@wowok/agent-mcp 3.0.0 → 3.0.2

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

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

@@ -1,48 +0,0 @@
-{
-  "title": "Configure Order Allocators with Entity-Treasury Recipient (ThreeBody Signature)",
-  "description": "Pre-publish Service configuration step (12-step plan: order_allocators): 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).",
-  "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"
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "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).",
-    "HARD LINKAGE: if this Service also declares customer_required (private info the buyer must send), it MUST set customer_required TOGETHER with a Contact bound via `um` (same operation, in a pre-publish step) — the SDK rejects customer_required without um because the buyer's private info is delivered only through the Contact's end-to-end encrypted Messenger.",
-    "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

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

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

@@ -1,135 +0,0 @@
-{
-  "title": "Create Multi-Segment Travel Machine DRAFT with Forward Guards",
-  "description": "Step 4 of the 12-step deploy plan: create a 5-node Iceland travel workflow Machine in DRAFT (unpublished): (init) -> Buy Insurance -> SPA -> Ice Scooting -> Complete/Cancel. Three forwards are gated by Guards: weather oracle check (go_ice_scooting), time-lock (complete_trip), and always-pass cancel (cancel_trip). Publish is a separate later step (machine-publish.json).",
-  "tags": ["machine", "travel", "workflow", "forward-guard", "multi-node", "draft", "12-step"],
-  "industry": "travel",
-  "operation_type": "machine",
-  "source": "docs/examples/Travel — 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": "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": []
-                    }
-                  }
-                ]
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "env": {
-      "account": "travel_provider",
-      "network": "testnet",
-      "no_cache": true
-    }
-  },
-  "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.",
-    "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 omitted → DRAFT. The FIX-02 entry-forward refine (applied at publish time) is 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.",
-    "This is a DRAFT (no publish:true). Once published, nodes are irreversibly frozen and env.confirmed:true is required at publish time. 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 publish — 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

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

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

@@ -1,34 +0,0 @@
-{
-  "title": "Create Travel Service DRAFT (Iceland)",
-  "description": "Step 3 of the 12-step deploy plan: create the Iceland travel Service object in DRAFT (unpublished) with only its identity — name, permission, and description. Machine binding, sales (WIP), Arbitration binding, order_allocators (tiered waterfall), and publish are each separate later steps and are intentionally NOT bundled here.",
-  "tags": ["service", "travel", "draft", "create", "12-step"],
-  "industry": "travel",
-  "operation_type": "service",
-  "source": "docs/examples/Travel — 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": "travel_service",
-        "permission": "travel_permission",
-        "replaceExistName": true
-      },
-      "description": "Iceland travel service: Blue Lagoon SPA + Glacier Ice Scooting."
-    },
-    "env": {
-      "account": "travel_provider",
-      "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/arbitrations/order_allocators/publish into the create call.",
-    "object uses the OBJECT form of TypedPermissionObjectSchema (type_parameter omitted → WOW default '0x2::wow::WOW'); description is a top-level Service field. No publish:true here — the Service stays unpublished until Step 12.",
-    "machine and order_allocators are PERMANENTLY LOCKED once publish=true executes (service.move assert!(!bPublished)) — set them in their own pre-publish steps, not in this DRAFT.",
-    "arbitrations binding requires a Permission DIFFERENT from the Service's (E_ARBITRATION_PERMISSION_CONFLICT) — create a dedicated travel_arbitration Permission first, then bind the Arbitration in the Arbitration step (Step 11), not here.",
-    "Travel is a PHYSICAL/service scenario; if it declares customer_required, set it together with a Contact bound as um (hard linkage) in the Contact step."
-  ]
-}

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

@@ -1,34 +0,0 @@
-{
-  "title": "Create Treasury for Merchant Revenue (Travel)",
-  "description": "Create a Treasury (travel_treasury) holding WOW tokens to aggregate travel service merchant revenue, sharing the Service's permission for unified governance",
-  "tags": ["treasury", "fund", "travel", "revenue"],
-  "industry": "travel",
-  "operation_type": "treasury",
-  "source": "Travel verified deployment walkthrough (docs/examples/Travel) — adapted to current schema",
-  "verified": true,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "treasury",
-    "data": {
-      "object": {
-        "name": "travel_treasury",
-        "type_parameter": "0x2::wow::WOW",
-        "permission": "travel_permission",
-        "replaceExistName": true
-      },
-      "description": "Treasury for aggregating travel service merchant revenue. Uses the same Permission as the Service (travel_permission) for consistency — a single permission organization governs both fund collection and service operations."
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true,
-      "confirmed": true
-    }
-  },
-  "notes": [
-    "Treasury-First rule: merchant revenue flows to a Treasury object. The Treasury aggregates public funds in one fixed place, which makes Service allocator guards inherently safe — allocated funds always flow to the fixed treasury address, never to an arbitrary recipient, so guard logic cannot be abused to redirect money.",
-    "A Treasury MAY share the Service's Permission (travel_permission here) so one permission organization governs both fund collection and service operations. This is the opposite of Arbitration, which MUST NOT share the Service's Permission (arbitration needs independent governance to stay neutral between merchant and customer).",
-    "type_parameter determines the token type the Treasury holds and pays out (format {address}::{module}::{struct}). Use '0x2::wow::WOW' for WOW (the schema default, set explicitly here for clarity); it must match the Service's type_parameter so order payments can flow into this Treasury.",
-    "Doc payload validated against current CallTreasury_DataSchema with no drift: 'object' uses the OBJECT form of TypedPermissionObjectSchema (TypeNamedObjectWithPermissionSchema — name, type_parameter, permission, replaceExistName all valid); 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='travel_provider'."
-  ]
-}

package/dist/examples/treasury-deposit.json

@@ -1,37 +0,0 @@
-{
-  "title": "Deposit Revenue into Treasury",
-  "description": "Deposit 1 WOW of service revenue into travel_treasury via Permission, recording the payment with a remark and naming the generated Payment object.",
-  "tags": ["treasury", "deposit", "fund", "travel"],
-  "industry": "travel",
-  "operation_type": "treasury",
-  "source": "constructed under T-09 authorization; grounded in DepositSchema + treasury.ts SDK — schema-validated, not chain-verified",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "treasury",
-    "data": {
-      "object": "travel_treasury",
-      "deposit": {
-        "coin": { "balance": 1000000000 },
-        "payment_info": {
-          "remark": "Service revenue settlement 2026-07",
-          "index": 0
-        },
-        "namedNewPayment": { "name": "travel_deposit_payment_v1" }
-      }
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true,
-      "confirmed": true
-    }
-  },
-  "notes": [
-    "coin uses CoinParam: {balance: <amount>} pulls that amount from the signer's wallet (1000000000 = 1 WOW, 9 decimals); alternatively {coin: '<coin_object_id_or_name>'} deposits a specific Coin object.",
-    "Two deposit paths: via PERMISSION (default, as here — caller must hold the Treasury's deposit operation permission) or via EXTERNAL GUARD (set by_external_deposit_guard to a Guard name/address; the amount may then be bounded by the Guard table value at the identifier configured in external_deposit_guard).",
-    "payment_info (PaymentInfoSchema): remark + index are REQUIRED; index is the payment-record sequence number used later by fees_transfer-style operations to reference this payment. for_object/for_guard are optional scenario bindings (see payment-scenario-bound example).",
-    "namedNewPayment names the Payment object auto-generated by the deposit — recommended so the fund flow is auditable by name in later queries.",
-    "Token type is fixed by the Treasury's type_parameter (0x2::wow::WOW here); the deposited coin must match."
-  ]
-}

package/dist/examples/treasury-withdraw.json

@@ -1,38 +0,0 @@
-{
-  "title": "Withdraw Fixed Amount from Treasury",
-  "description": "Withdraw 0.5 WOW from travel_treasury to the provider account via Permission (fixed-amount path), recording the payout as a named Payment.",
-  "tags": ["treasury", "withdraw", "payout", "travel"],
-  "industry": "travel",
-  "operation_type": "treasury",
-  "source": "constructed under T-09 authorization; grounded in WithdrawSchema + treasury.ts SDK — schema-validated, not chain-verified",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "treasury",
-    "data": {
-      "object": "travel_treasury",
-      "withdraw": {
-        "amount": { "fixed": 500000000 },
-        "recipient": { "name_or_address": "travel_provider" },
-        "payment_info": {
-          "remark": "Monthly provider payout 2026-07",
-          "index": 1
-        },
-        "namedNewPayment": { "name": "travel_withdraw_payment_v1" }
-      }
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true,
-      "confirmed": true
-    }
-  },
-  "notes": [
-    "amount is a UNION: {fixed: <amount>} = fixed withdrawal via PERMISSION only (500000000 = 0.5 WOW); {by_external_withdraw_guard: '<guard>'} = Guard-verified withdrawal where the amount comes from the Guard table value at the identifier configured in external_withdraw_guard. The two paths are mutually exclusive.",
-    "recipient is AccountOrMark_Address OBJECT form {name_or_address: 'travel_provider'} — resolves the local account/mark to an address. A bare string is NOT accepted here (unlike NameOrAddress fields); wrap it in the object.",
-    "payment_info.remark and payment_info.index are REQUIRED (PaymentInfoSchema). Keep index unique per payment for clean audit trails.",
-    "namedNewPayment names the Payment object generated by the withdrawal for later audit reference.",
-    "The Treasury must hold sufficient balance of its type_parameter token; withdrawal via Permission requires the caller to hold the Treasury's withdraw operation permission."
-  ]
-}

package/dist/harness/plan.d.ts

@@ -1,33 +0,0 @@
-import type { ODG, ScenarioTemplate } from "./types.js";
-import type { SemanticObjectGraph } from "../playbooks/service-build/semantic-graph.js";
-export declare const SCENARIO_REGISTRY: ScenarioTemplate[];
-export interface IntentClassification {
-    scenario: string;
-    matched_keywords: string[];
-    confidence: number;
-    fallback: boolean;
-}
-export declare function classifyIntent(userInput: string): IntentClassification;
-export declare function generateODG(userInput: string, taskId?: string): ODG;
-export declare function generateODGFromSemanticGraph(graph: SemanticObjectGraph, taskId?: string): ODG;
-export interface DecisionPoint {
-    round: string;
-    question: string;
-    options: string[];
-    default?: string;
-}
-export declare function identifyDecisionPoints(odg: ODG): DecisionPoint[];
-export declare function detectCycles(odg: ODG): string[] | null;
-export interface MigrationDecision {
-    round: string;
-    question: string;
-    options: string[];
-    default?: string;
-    note?: string;
-}
-export interface MigrationDecisionOptions {
-    from_network?: "testnet";
-    to_network?: "mainnet";
-    current_payment_token?: string;
-}
-export declare function identifyMigrationDecisions(options?: MigrationDecisionOptions): MigrationDecision[];