@wowok/agent-mcp 3.0.0 → 3.0.2

package/dist/examples/gen-passport-verify-guard.json

@@ -1,48 +0,0 @@
-{
-  "title": "Generate Passport from Guard Verification (KYC Credential)",
-  "description": "End-to-end gen_passport: verify a KYC-level Guard with runtime submission data and mint an immutable on-chain Passport credential for the signer.",
-  "tags": ["passport", "guard", "kyc", "credential", "gen_passport"],
-  "industry": "general",
-  "operation_type": "gen_passport",
-  "source": "constructed under T-09 authorization; grounded in CallGenPassport_InputSchema + SDK gen_passport — schema-validated, not chain-verified",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "gen_passport",
-    "guard": ["kyc_level_guard"],
-    "info": {
-      "type": "submission",
-      "guard": [
-        { "object": "kyc_level_guard", "impack": true }
-      ],
-      "submission": [
-        {
-          "guard": "kyc_level_guard",
-          "submission": [
-            {
-              "identifier": 0,
-              "b_submission": true,
-              "value_type": "U64",
-              "value": 1000,
-              "name": ""
-            }
-          ]
-        }
-      ]
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true,
-      "confirmed": true
-    }
-  },
-  "notes": [
-    "UNIQUE SHAPE: gen_passport has NO 'data' field — 'guard' is a TOP-LEVEL sibling of operation_type (string or string[] of Guard names/addresses). Do not wrap parameters inside a data object.",
-    "info is optional. When omitted, the SDK reuses submissions already recorded on the Guard (from a prior verification). Provide info when the Guard has b_submission=true table items whose values must be supplied at verification time — as here (identifier 0, a U64 KYC score).",
-    "info structure = SubmissionCallSchema: {type:'submission', guard:[{object, impack}], submission:[{guard, submission:[GuardTableItem...]}]}. impack:true means this Guard's result counts in the Passport's final AND result.",
-    "Each submission entry mirrors the Guard's table definition: identifier must match the table item being filled, value_type must match its declared type ('U64' string form accepted alongside numeric 6), and b_submission entries carry the runtime value.",
-    "The resulting Passport object records per-Guard results, the final AND result, signer, and timestamp (ObjectPassportSchema). It is the credential consumed by vote_with_voting_guard, alloc_by_guard, and buy flows that require Guard verification.",
-    "PREREQUISITE: 'kyc_level_guard' must already exist (created via operation_type:'guard') with a table item identifier:0, value_type U64, b_submission:true. Multiple Guards can be verified in one call by passing an array and one submission entry per Guard."
-  ]
-}

package/dist/examples/guard-template-balance-check.json

@@ -1,59 +0,0 @@
-{
-  "title": "Guard Template: Minimum Order Amount Validation",
-  "description": "Guard that passes only when the Order's paid amount meets a minimum threshold. Bind to an Allocator (fund release) or a Machine forward to gate high-value transitions.",
-  "tags": ["guard", "template", "balance", "amount", "validation"],
-  "industry": "general",
-  "operation_type": "guard",
-  "source": "template",
-  "verified": true,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "guard",
-    "data": {
-      "namedNew": {
-        "name": "balance_check_guard"
-      },
-      "description": "Passes when order.amount >= min_amount (table identifier 1).",
-      "table": [
-        {
-          "identifier": 0,
-          "b_submission": true,
-          "value_type": "Address",
-          "name": "order"
-        },
-        {
-          "identifier": 1,
-          "b_submission": false,
-          "value_type": "U64",
-          "value": "1000000000",
-          "name": "min_amount"
-        }
-      ],
-      "root": {
-        "type": "logic_as_u256_greater_or_equal",
-        "nodes": [
-          {
-            "type": "query",
-            "query": "order.amount",
-            "object": { "identifier": 0 }
-          },
-          {
-            "type": "identifier",
-            "identifier": 1
-          }
-        ]
-      }
-    },
-    "env": {
-      "network": "testnet"
-    }
-  },
-  "notes": [
-    "order.amount (id 1561) returns the TOTAL amount paid for the order (U64, smallest unit). Do NOT confuse with the order's residual escrow balance.",
-    "Root MUST return Bool — logic_as_u256_greater_or_equal compares the first node (query result) against all subsequent nodes (threshold from the table).",
-    "The threshold (identifier 1) is fixed at Guard creation (b_submission=false); the Order address is submitted per trigger (identifier 0, b_submission=true).",
-    "Amounts use the token's smallest unit: 1000000000 = 1 WOW (9 decimals).",
-    "Use for minimum payment validation, deposit threshold checks, or gating Allocator release on order value."
-  ]
-}

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

@@ -1,60 +0,0 @@
-{
-  "title": "Guard Template: Time-Lock Validation",
-  "description": "Guard that passes only after the Progress object's current-node entry timestamp reaches a deadline (e.g., rental period elapsed, escrow release timing). Bind to a Machine forward or an Allocator to gate time-locked transitions.",
-  "tags": ["guard", "template", "time-lock", "validation"],
-  "industry": "general",
-  "operation_type": "guard",
-  "source": "template",
-  "verified": true,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "guard",
-    "data": {
-      "namedNew": {
-        "name": "time_lock_guard",
-        "tags": ["template", "time-lock"]
-      },
-      "description": "Passes when progress.current_time >= release_after_ms (table identifier 1).",
-      "table": [
-        {
-          "identifier": 0,
-          "b_submission": true,
-          "value_type": "Address",
-          "name": "progress"
-        },
-        {
-          "identifier": 1,
-          "b_submission": false,
-          "value_type": "U64",
-          "value": "1735689600000",
-          "name": "release_after_ms"
-        }
-      ],
-      "root": {
-        "type": "logic_as_u256_greater_or_equal",
-        "nodes": [
-          {
-            "type": "query",
-            "query": "progress.current_time",
-            "object": { "identifier": 0 }
-          },
-          {
-            "type": "identifier",
-            "identifier": 1
-          }
-        ]
-      }
-    },
-    "env": {
-      "network": "testnet"
-    }
-  },
-  "notes": [
-    "Root MUST return Bool: comparison/logic nodes (logic_*, logic_as_u256_*) qualify; a bare query returning U64 does NOT.",
-    "Comparison nodes carry a 'nodes' array (first node compared against all subsequent). Query nodes carry 'query' (instruction id or name) + 'object' (Guard-table identifier of the queried object). Identifier nodes carry 'identifier' (Guard-table index).",
-    "progress.current_time (id 1272) returns the current-node entry timestamp in milliseconds (U64) — compare against a deadline stored in the table (identifier 1, b_submission=false so it is fixed at creation).",
-    "The Progress address is submitted at trigger time (identifier 0, b_submission=true) — the caller supplies it via submissions[].",
-    "Use for rental period expiry, escrow release timing, etc."
-  ]
-}

package/dist/examples/insurance-guard-claim-timelock.json

@@ -1,75 +0,0 @@
-{
-  "title": "Create Time-Lock Claim Completion Guard (Insurance)",
-  "description": "Create a Guard that enforces a time-lock on insurance claim completion: the on-chain clock must be later than the order Progress's current-node entry time plus a lock duration. The submitted Order ID is converted to its Progress via convert_witness=\"OrderProgress\" to query progress.current_time.",
-  "tags": ["guard", "insurance", "time-lock", "claim", "convert_witness"],
-  "industry": "insurance",
-  "operation_type": "guard",
-  "source": "docs/examples/Insurance — schema-validated, not chain-verified",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "guard",
-    "data": {
-      "namedNew": {
-        "name": "insurance_complete_guard_v1",
-        "tags": ["insurance", "time-lock", "complete"],
-        "replaceExistName": true
-      },
-      "description": "Time-lock guard for insurance claim completion. Requires current clock > progress.current_time + 10000ms (10 seconds for TESTING; in production set to a reasonable duration like 8 hours). Progress is accessed via Order with convert_witness=\"OrderProgress\" (100).",
-      "table": [
-        {
-          "identifier": 0,
-          "b_submission": true,
-          "value_type": "Address",
-          "name": "Order ID (submitted at runtime)"
-        },
-        {
-          "identifier": 1,
-          "b_submission": false,
-          "value_type": "U64",
-          "value": 10000
-        }
-      ],
-      "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": "insurance_provider_v1",
-      "network": "testnet"
-    }
-  },
-  "notes": [
-    "Unique pattern vs the existing guard-template-time-lock.json: that template queries progress.current_time on a Progress submitted DIRECTLY; this insurance Guard submits the ORDER and uses convert_witness='OrderProgress' (WitnessType 100) to hop from Order to its associated Progress before querying — the canonical claim-eligibility pattern when only the Order ID is available at trigger time.",
-    "Schema check (call/guard.ts CallGuard_DataSchema + query/index.ts GuardNodeSchema): root type 'logic_as_u256_greater' is in the Bool-returning allowed list; 'context' node uses context enum 'Clock'; 'calc_number_add' wraps the U64 query + identifier so the comparison operands are numeric; query node carries object {identifier, convert_witness} and optional parameters [] (may be omitted for parameter-less queries).",
-    "convert_witness 'OrderProgress' validated against WitnessTypeSchema (query/index.ts L736-746): string name form, 'Type' prefix optional, case-insensitive.",
-    "Table validated against GuardTableItemBaseSchema (common/index.ts L365-399): identifier 0 is b_submission=true (runtime-submitted Order address, 'value' omitted); identifier 1 is b_submission=false with value_type 'U64' and numeric value 10000. No 'object_type' field (output-only, rejected on input).",
-    "10000 ms (10 s) is a TESTING lock duration; production should use e.g. 8 hours (28800000 ms).",
-    "Desensitization: doc payload already uses generic local-mark names (insurance_provider_v1, insurance_complete_guard_v1) and contains no real personal names/phones/addresses; nothing further to replace."
-  ]
-}

package/dist/examples/insurance-guard-withdraw-allocation.json

@@ -1,96 +0,0 @@
-{
-  "title": "Create Withdraw Guard for Order Allocation (Insurance, Project-Bound)",
-  "description": "Create a withdraw Guard for merchant fund collection after an insurance order completes. The Guard requires the submitted Order to be at the 'Complete' node (via convert_witness OrderProgress) AND to belong to this specific Service (project binding, preventing cross-service order theft). Bind it to a Service order_allocators entry.",
-  "tags": ["guard", "insurance", "withdraw", "allocation", "project-binding"],
-  "industry": "insurance",
-  "operation_type": "guard",
-  "source": "docs/examples/Insurance — schema-validated, not chain-verified",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "guard",
-    "data": {
-      "namedNew": {
-        "name": "insurance_withdraw_guard_treasury_v1",
-        "tags": ["insurance", "withdraw", "treasury"],
-        "replaceExistName": true
-      },
-      "description": "Allow fund allocation to Treasury after order is completed. RISK ELIMINATION: order must be at Complete node AND belong to insurance_service_v1 (prevents cross-service theft). Funds flow to fixed Treasury Entity (safe — no Signer binding needed).",
-      "table": [
-        {
-          "identifier": 0,
-          "b_submission": true,
-          "value_type": "Address",
-          "name": "order_id (Order object submitted at runtime)"
-        },
-        {
-          "identifier": 1,
-          "b_submission": false,
-          "value_type": "String",
-          "value": "Complete",
-          "name": "Expected Complete node name (case-sensitive)"
-        },
-        {
-          "identifier": 2,
-          "b_submission": false,
-          "value_type": "Address",
-          "value": "insurance_service_v1",
-          "name": "Expected service address (prevents cross-service fund theft)"
-        }
-      ],
-      "root": {
-        "type": "logic_and",
-        "nodes": [
-          {
-            "type": "logic_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.service",
-                "object": {
-                  "identifier": 0
-                },
-                "parameters": []
-              },
-              {
-                "type": "identifier",
-                "identifier": 2
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "env": {
-      "account": "insurance_provider_v1",
-      "network": "testnet"
-    }
-  },
-  "notes": [
-    "Withdraw-guard pattern the library previously lacked: logic_and of (1) workflow-state check — progress.current == 'Complete' via Order + convert_witness='OrderProgress' — and (2) project binding — order.service == insurance_service_v1 — so a completed Order from ANOTHER Service cannot be submitted to trigger this Service's allocation.",
-    "CIRCULAR-REFERENCE WORKFLOW (DOC-01): the Guard's static table stores the Service as a LocalMark NAME ('insurance_service_v1', identifier 2, value_type Address). The name must resolve at transaction build time, so create the Service FIRST (unpublished), then this Guard, then update the Service with order_allocators + publish. GuardTableItemBaseSchema explicitly allows a LocalMark name as an Address value (resolved at evaluation/build time).",
-    "Schema check (call/guard.ts + query/index.ts GuardNodeSchema): root 'logic_and' has exactly 2 children (min 2 enforced); both children are Bool-returning 'logic_equal' nodes; query nodes use parameter-less queries progress.current / order.service with optional parameters [].",
-    "Doc creates TWO such Guards (treasury + personal collection) with identical logic but different names/descriptions, because allocators require unique Guard addresses. Only the Treasury variant is extracted here; to use the personal-collection approach, duplicate with namedNew.name 'insurance_withdraw_guard_personal_v1' and adjust tags/description.",
-    "The node name comparison is CASE-SENSITIVE ('Complete' != 'complete') — the table value must exactly match the Machine node name.",
-    "Desensitization: doc payload already uses generic local-mark names only (insurance_provider_v1, insurance_service_v1, insurance_withdraw_guard_treasury_v1); no real personal data present, nothing replaced."
-  ]
-}

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

@@ -1,75 +0,0 @@
-{
-  "title": "Create Insurance Claim Machine DRAFT (Start -> Complete)",
-  "description": "Step 4 of the 12-step deploy plan: create the two-node insurance claim workflow Machine in DRAFT (unpublished): entry forward 'start_claim' into Start (permissionIndex 1000), and 'complete_claim' from Start into Complete (permissionIndex 1001) gated by the time-lock Guard insurance_complete_guard_v1. Publish is a separate later step (machine-publish.json).",
-  "tags": ["machine", "insurance", "claim", "workflow", "draft", "12-step"],
-  "industry": "insurance",
-  "operation_type": "machine",
-  "source": "docs/examples/Insurance — 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": "insurance_machine_v1",
-        "permission": "insurance_permission_v1",
-        "replaceExistName": true
-      },
-      "description": "Insurance claim processing workflow: Start -> Complete (with time-lock guard)",
-      "node": {
-        "op": "add",
-        "nodes": [
-          {
-            "name": "Start",
-            "pairs": [
-              {
-                "prev_node": "",
-                "threshold": 0,
-                "forwards": [
-                  {
-                    "name": "start_claim",
-                    "permissionIndex": 1000,
-                    "weight": 1
-                  }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "Complete",
-            "pairs": [
-              {
-                "prev_node": "Start",
-                "threshold": 1,
-                "forwards": [
-                  {
-                    "name": "complete_claim",
-                    "permissionIndex": 1001,
-                    "weight": 1,
-                    "guard": {
-                      "guard": "insurance_complete_guard_v1"
-                    }
-                  }
-                ]
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "env": {
-      "account": "insurance_provider_v1",
-      "network": "testnet"
-    }
-  },
-  "notes": [
-    "12-STEP PLAN alignment: this is ONE step (Step 4 Machine DRAFT). Do NOT bundle publish:true here — publish is Step 6 (see machine-publish.json). The 12-step order is Service DRAFT → Machine (nodes/forwards) → Guard → bind Guards → Machine publish.",
-    "Insurance-claim Machine pattern: a minimal two-node Start -> Complete workflow where the completion forward is gated by a time-lock Guard. This creates the Machine in DRAFT (nodes remain editable until publish).",
-    "Schema check (call/machine.ts CallMachine_DataSchema): 'object' uses the OBJECT form of WithPermissionObjectSchema (NamedObjectWithPermissionSchema — name, permission, replaceExistName); node uses NodeSchema op='add' with nodes array; publish omitted → DRAFT. The FIX-02 entry-forward refine (applied at publish time) is satisfied because the Start pair has prev_node='' with at least one forward (FIX-002 also requires the initial pair to have a non-empty forwards list).",
-    "Forward check (query/index.ts MachineForwardSchema): every forward provides permissionIndex (1000/1001) satisfying the one-of namedOperator/permissionIndex rule; the Complete forward uses the OBJECT guard form {guard: 'insurance_complete_guard_v1'} (MachineForwardGuardSchema; a plain string shorthand is also accepted via preprocess).",
-    "The referenced Guard (insurance_complete_guard_v1) and Permission (insurance_permission_v1, with indexes 1000/1001 granted to the operator) must exist before publish — see the sibling insurance-guard-claim-timelock example and the Insurance doc Steps 1/3.",
-    "PREREQUISITE for advancing claims: the Permission must grant index 1000 (start_claim) and 1001 (complete_claim) to the operating account, otherwise progress advancement aborts with MoveAbort code 7.",
-    "Desensitization: doc payload already uses generic local-mark names only (insurance_provider_v1, insurance_machine_v1, insurance_permission_v1); no real personal data present, nothing replaced."
-  ]
-}

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

@@ -1,55 +0,0 @@
-{
-  "title": "Configure Order Allocators (Insurance, Entity-Sharing)",
-  "description": "Pre-publish Service configuration step (12-step plan: order_allocators). Update the unpublished insurance Service with two alternative order_allocators (Treasury collection and personal collection, first-match-wins) whose sharing recipients are FIXED Entity addresses — the fund-theft-safe pattern. Publish is a SEPARATE later step (Step 12) and is intentionally NOT bundled here.",
-  "tags": ["service", "insurance", "order_allocators", "entity-sharing", "12-step"],
-  "industry": "insurance",
-  "operation_type": "service",
-  "source": "docs/examples/Insurance — adapted to the 12-step plan (allocators only, schema-validated, not chain-verified)",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "service",
-    "data": {
-      "object": "insurance_service_v1",
-      "order_allocators": {
-        "description": "Insurance order revenue allocation — 2 alternative merchant collection approaches (first-match-wins means only the first passing allocator executes)",
-        "threshold": 0,
-        "allocators": [
-          {
-            "guard": "insurance_withdraw_guard_treasury_v1",
-            "sharing": [
-              {
-                "who": { "Entity": { "name_or_address": "insurance_treasury_v1" } },
-                "sharing": 10000,
-                "mode": "Rate"
-              }
-            ]
-          },
-          {
-            "guard": "insurance_withdraw_guard_personal_v1",
-            "sharing": [
-              {
-                "who": { "Entity": { "name_or_address": "insurance_provider_v1" } },
-                "sharing": 10000,
-                "mode": "Rate"
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "env": {
-      "account": "insurance_provider_v1",
-      "network": "testnet"
-    }
-  },
-  "notes": [
-    "12-STEP PLAN alignment: this file is ONE step (Step 9 order_allocators). Do NOT bundle publish:true here — publish is Step 12. order_allocators is PERMANENTLY IMMUTABLE after publish (service.move E_ALREADY_PUBLISHED), so it MUST be set in this pre-publish step.",
-    "Fund-safety pattern: who = {Entity: {name_or_address: ...}} pins the recipient to a FIXED address (Treasury object or provider account) resolved via LocalMark at build time. Even if the withdraw Guard were bypassed, funds still flow to the fixed Entity — the caller cannot redirect them. NEVER use {Signer: 'signer'} for merchant collection.",
-    "first-match-wins: the TWO allocators illustrate 2 alternative collection designs (Treasury vs personal); only the FIRST allocator whose Guard passes executes. In production pick ONE and delete the other. Each allocator's Guard must be a UNIQUE Guard object.",
-    "Schema check (call/service.ts CallService_DataSchema + query/index.ts AllocatorsSchema/AllocatorSchema/AllocationSharingSchema/RecipientSchema): object is the STRING form (existing service); order_allocators = {description, threshold, allocators[]} with per-allocator {guard: NameOrAddress, sharing: [{who: {Entity: {name_or_address}}, sharing, mode}]}; mode 'Rate' with a single sharing of 10000 satisfies the Rate-sum == 10000 (basis points, 100%) rule with no Surplus item; threshold 0 allows any balance.",
-    "PREREQUISITES (created by separate calls, not shown): insurance_service_v1 (unpublished, with machine + sales), both withdraw Guards, and insurance_treasury_v1; Machine published. If this Service declares customer_required, it must also bind a Contact via um (hard linkage) — see the Contact step.",
-    "Desensitization: generic local-mark names only (insurance_service_v1, insurance_treasury_v1, insurance_provider_v1, insurance_withdraw_guard_*_v1); no real personal data present."
-  ]
-}

package/dist/examples/machine-multisig-threshold.json

@@ -1,87 +0,0 @@
-{
-  "title": "Machine Template: 2-of-3 Multi-Sig Approval Workflow (threshold > 1)",
-  "description": "Four-node workflow where the 'approved' node requires cumulative weight 2 from three distinct approver forwards (permissionIndex 1001/1002/1003, weight 1 each) — the on-chain multi-signature approval pattern.",
-  "tags": ["machine", "template", "multisig", "threshold", "approval", "governance"],
-  "industry": "general",
-  "operation_type": "machine",
-  "source": "constructed under T-09 authorization; grounded in MachineNodePairSchema threshold + MachineForwardSchema weight — schema-validated, not chain-verified",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "machine",
-    "data": {
-      "object": {
-        "name": "multisig_approval_machine"
-      },
-      "node": {
-        "op": "add",
-        "bReplace": true,
-        "nodes": [
-          {
-            "name": "submitted",
-            "pairs": [
-              {
-                "prev_node": "",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Submit", "weight": 1, "namedOperator": "" }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "under_review",
-            "pairs": [
-              {
-                "prev_node": "submitted",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Start Review", "weight": 1, "permissionIndex": 1000 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "approved",
-            "pairs": [
-              {
-                "prev_node": "under_review",
-                "threshold": 2,
-                "forwards": [
-                  { "name": "Approve Alice", "weight": 1, "permissionIndex": 1001 },
-                  { "name": "Approve Bob", "weight": 1, "permissionIndex": 1002 },
-                  { "name": "Approve Carol", "weight": 1, "permissionIndex": 1003 }
-                ]
-              }
-            ]
-          },
-          {
-            "name": "completed",
-            "pairs": [
-              {
-                "prev_node": "approved",
-                "threshold": 1,
-                "forwards": [
-                  { "name": "Finalize", "weight": 1, "permissionIndex": 1000 }
-                ]
-              }
-            ]
-          }
-        ]
-      }
-    },
-    "env": {
-      "network": "testnet"
-    }
-  },
-  "notes": [
-    "MULTI-SIG MECHANICS: pair threshold=2 means Progress advances from 'under_review' to 'approved' only when the CUMULATIVE weight of completed DISTINCT forwards on that pair reaches 2. Each of the three approver forwards contributes weight 1, so any 2 of the 3 approvers must act — a 2-of-3 signature scheme.",
-    "Each approver calls progress operate with their OWN forward name (e.g. 'Approve Alice'). The same forward cannot be double-counted; distinct forwards by the same operator would still count separately, so map each forward to a distinct permissionIndex (1001/1002/1003 = three approver roles in the Permission table).",
-    "⚠️ SINGLE-OPERATOR LOCK (E_NOT_THE_HOLDER): each forward is locked by the FIRST operator that accomplishes it — a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER, and the weight is counted only ONCE. This is exactly why a threshold-N transition needs N DISTINCT forwards (here 2-of-3): each of the three approver forwards can be executed by exactly one person. Do NOT try to have several people 'all execute Approve Alice' — it will abort for everyone after the first.",
-    "threshold semantics (MachineNodePairSchema): 'If total Forward weight is greater than or equal to threshold, node advancement is triggered.' Weighted variants are possible — e.g. give a senior approver weight 2 so they can approve alone (threshold 2 met by one forward).",
-    "Entry-node rule: 'submitted' has prev_node='' with at least one forward (schema-enforced FIX-002). namedOperator='' = order owner; permissionIndex references Permission table entries.",
-    "Compare with machine-template-7node-rental.json where every pair uses threshold 1 (single-signature sequential flow).",
-    "This Machine is a TEMPLATE object: bind it to a Service and each order gets a Progress instance whose multi-sig approvals are tracked per order."
-  ]
-}

package/dist/examples/machine-publish.json

@@ -1,30 +0,0 @@
-{
-  "title": "Publish a Machine (Freeze Workflow)",
-  "description": "Step 6 of the 12-step deploy plan: publish an existing DRAFT Machine to make its nodes/forwards immutable. This is a single-concept operation — create the Machine in DRAFT first (see *-machine-create.json), then bind Guards to forwards, then publish. Replace 'my_machine' with your Machine's name.",
-  "tags": ["machine", "publish", "freeze", "immutable", "12-step"],
-  "industry": "general",
-  "operation_type": "machine",
-  "source": "12-step deploy plan (Step 6 Machine publish) — schema-validated, not chain-verified",
-  "verified": false,
-  "network": "testnet",
-  "call": {
-    "tool": "onchain_operations",
-    "operation_type": "machine",
-    "data": {
-      "object": "my_machine",
-      "publish": true
-    },
-    "env": {
-      "account": "service_provider",
-      "network": "testnet",
-      "confirmed": true
-    }
-  },
-  "notes": [
-    "12-STEP PLAN alignment: this is ONE step (Step 6 Machine publish). Create the Machine in DRAFT first (Step 4), then create/bind Guards to forwards (Step 5), THEN publish here. Publishing is IRREVERSIBLE — nodes/pairs/forwards become permanently frozen.",
-    "object is the STRING form (existing DRAFT Machine name/ID). publish:true is the only data field needed — node/progress_new/description are NOT re-specified.",
-    "env.confirmed:true is REQUIRED (ConfirmGate) because publish is irreversible.",
-    "FIX-02: publish:true validates that the on-chain nodes contain at least one entry forward (prev_node=''), else the Machine would be stuck at Progress current=''.",
-    "Only a PUBLISHED Machine can be bound to a Service (service.machine asserts bPublished). Publish the Machine BEFORE the Service's machine-binding step."
-  ]
-}