@wowok/agent-mcp 2.6.3 → 2.6.6

package/dist/examples/arbitration-voting-guard-add.json

@@ -0,0 +1,38 @@
+{
+  "title": "Configure Weighted Voting Guard on Arbitration",
+  "description": "Add an eligibility Guard to the Arbitration's voting_guard list with a fixed vote weight, enabling guard-based weighted voting for dispute cases.",
+  "tags": ["arbitration", "voting_guard", "guard", "governance"],
+  "industry": "retail",
+  "operation_type": "arbitration",
+  "source": "constructed under T-09 authorization; grounded in VotingGuardActionSchema + VoteWeightSchema + arbitration.move voting_guard_fixed_add — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "arbitration",
+    "data": {
+      "object": "myshop_arbitration_v2",
+      "voting_guard": {
+        "op": "add",
+        "guards": [
+          {
+            "guard": "arbitrator_eligibility_guard",
+            "vote_weight": { "FixedValue": 1 }
+          }
+        ]
+      }
+    },
+    "env": {
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "Two voting modes exist (arbitration.move): OPEN voting (voting_guard list EMPTY — any permission-358 holder votes with weight 1 via vote_imp) and GUARD-WEIGHTED voting (list non-empty — only listed Guards can vote, via vote_with_voting_guard). This call switches the Arbitration to guard-weighted mode.",
+    "vote_weight variants (VoteWeightSchema): {FixedValue: n} gives every verified voter weight n (u32, max 65535 in schema); {GuardIdentifier: i} reads the weight dynamically from the voter's Passport submission value at Guard table index i (e.g. reputation-score-weighted voting).",
+    "The Guard itself ('arbitrator_eligibility_guard') must exist beforehand (operation_type:'guard') — e.g. a Guard checking the voter holds an arbitrator credential or stake.",
+    "op variants: 'add'/'set' take VotingGuard objects; 'remove' takes plain guard names/addresses; 'clear' empties the list (returning to open voting). Requires Arbitration permission index 354 (ARBITRATION_VOTING_GUARD).",
+    "Once ANY voting_guard is configured, plain vote (no guard) aborts with E_VOTING_GUARD_USED — every voter must verify through one of the listed Guards."
+  ]
+}

package/dist/examples/demand-present-service.json

@@ -0,0 +1,33 @@
+{
+  "title": "Present Service to a Demand (Recommendation)",
+  "description": "Recommend myshop_service_v2 to an open Demand object with a recommendation letter, entering the Demand's presenter list for reward eligibility.",
+  "tags": ["demand", "present", "recommendation", "service"],
+  "industry": "retail",
+  "operation_type": "demand",
+  "source": "constructed under T-09 authorization; grounded in DemandPresentSchema + demand.ts SDK — schema-validated, not chain-verified",
+  "verified": false,
+  "network": "testnet",
+  "call": {
+    "tool": "onchain_operations",
+    "operation_type": "demand",
+    "data": {
+      "object": "toy_repair_demand_v1",
+      "present": {
+        "recommend": "Our toy repair service matches this demand: 7-day turnaround, WOW escrow payment, independent arbitration coverage.",
+        "service": "myshop_service_v2"
+      }
+    },
+    "env": {
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  },
+  "notes": [
+    "present makes the CALLER a Presenter on the Demand: the recommendation letter (recommend, REQUIRED) plus an optional service reference. Presenters become eligible to claim the Demand's reward pool when the demander accepts their recommendation.",
+    "If the Demand has guards configured (ServiceGuard list), the presented Service is verified against them — a Guard may filter which Services qualify (e.g. must have arbitration bound, must be in a category). Use by_guard to select which configured Guard to verify through when several are present.",
+    "service is optional but recommended — a bare recommendation without a Service reference gives the demander nothing to inspect.",
+    "Follow-up flow: the demander reviews presenters (query_table on DemandPresenter), buys the presented Service, and may leave feedback (FeedbackInfo: acceptance_score 0-255 + feedback text) which updates the presenter's on-chain reputation.",
+    "PREREQUISITE: 'toy_repair_demand_v1' exists (created via operation_type:'demand' with object {name, permission, rewards...}) and 'myshop_service_v2' is a published Service."
+  ]
+}

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

@@ -0,0 +1,48 @@
+{
+  "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,31 +1,48 @@
 {
-  "title": "Guard Template: Balance Check Validation",
-  "description": "Guard that validates order balance >= threshold",
-  "tags": ["guard", "template", "balance", "validation"],
+  "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": {
-      "object": {
+      "namedNew": {
         "name": "balance_check_guard"
       },
-      "root": {
-        "type": "logic_greater_equal",
-        "left": {
-          "type": "query",
-          "name": "balance",
-          "parameters": [],
-          "objectType": "Order"
+      "description": "Passes when order.amount >= min_amount (table identifier 1).",
+      "table": [
+        {
+          "identifier": 0,
+          "b_submission": true,
+          "value_type": "Address",
+          "name": "order"
         },
-        "right": {
-          "type": "identifier",
+        {
+          "identifier": 1,
+          "b_submission": false,
           "value_type": "U64",
-          "index": 0
+          "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": {
@@ -33,6 +50,10 @@
     }
   },
   "notes": [
-    "Use for minimum payment validation, deposit threshold checks"
+    "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,32 +1,49 @@
 {
   "title": "Guard Template: Time-Lock Validation",
-  "description": "Guard that validates a time-based condition (e.g., rental period elapsed)",
+  "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": {
-      "object": {
+      "namedNew": {
         "name": "time_lock_guard",
         "tags": ["template", "time-lock"]
       },
-      "root": {
-        "type": "logic_equal",
-        "left": {
-          "type": "query",
-          "name": "time_now",
-          "parameters": [],
-          "objectType": "Order"
+      "description": "Passes when progress.current_time >= release_after_ms (table identifier 1).",
+      "table": [
+        {
+          "identifier": 0,
+          "b_submission": true,
+          "value_type": "Address",
+          "name": "progress"
         },
-        "right": {
-          "type": "identifier",
+        {
+          "identifier": 1,
+          "b_submission": false,
           "value_type": "U64",
-          "index": 0
+          "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": {
@@ -34,6 +51,10 @@
     }
   },
   "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

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

@@ -0,0 +1,96 @@
+{
+  "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-publish.json

@@ -0,0 +1,75 @@
+{
+  "title": "Create and Publish Insurance Claim Machine (Start -> Complete)",
+  "description": "Create a two-node insurance claim workflow Machine and publish it in a single transaction: 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.",
+  "tags": ["machine", "insurance", "claim", "workflow", "publish"],
+  "industry": "insurance",
+  "operation_type": "machine",
+  "source": "docs/examples/Insurance — 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"
+                    }
+                  }
+                ]
+              }
+            ]
+          }
+        ]
+      },
+      "publish": true
+    },
+    "env": {
+      "account": "insurance_provider_v1",
+      "network": "testnet"
+    }
+  },
+  "notes": [
+    "Insurance-claim Machine pattern: a minimal two-node Start -> Complete workflow where the completion forward is gated by a time-lock Guard. Demonstrates create-with-nodes + publish in ONE transaction (nodes become immutable after 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=true on NEW machine creation triggers the FIX-02 entry-forward refine — 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 this call — 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-publish.json

@@ -0,0 +1,56 @@
+{
+  "title": "Add Entity-Sharing Order Allocators and Publish Insurance Service",
+  "description": "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 — then publish the Service in the same transaction.",
+  "tags": ["service", "insurance", "order_allocators", "entity-sharing", "publish"],
+  "industry": "insurance",
+  "operation_type": "service",
+  "source": "docs/examples/Insurance — 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"
+              }
+            ]
+          }
+        ]
+      },
+      "publish": true
+    },
+    "env": {
+      "account": "insurance_provider_v1",
+      "network": "testnet"
+    }
+  },
+  "notes": [
+    "Fund-safety pattern the library previously lacked: 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 or a forged Order submitted, funds still flow to the fixed Entity — the caller cannot redirect them. NEVER use {Signer: 'signer'} for merchant collection (funds would go to whoever triggers allocation).",
+    "first-match-wins: the TWO allocators illustrate the 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 — hence two Guards with identical logic in the doc (see sibling insurance-guard-withdraw-allocation example).",
+    "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.",
+    "IMMUTABILITY (L1-locked): order_allocators can ONLY be set before publish=true (service.move E_ALREADY_PUBLISHED); after publish it is permanently frozen — this call sets allocators and publishes in one transaction, which is the standard finalize step.",
+    "PREREQUISITES: insurance_service_v1 created UNPUBLISHED with machine + sales (so its name resolves in the Guards' static tables); both withdraw Guards and insurance_treasury_v1 created; Machine published. This is Step 7 of the Insurance doc flow.",
+    "Desensitization: doc payload already uses generic local-mark names only (insurance_service_v1, insurance_treasury_v1, insurance_provider_v1, insurance_withdraw_guard_*_v1); no real personal data present, nothing replaced."
+  ]
+}