@wowok/skills 1.3.4 → 2.0.0

package/examples/Travel/Travel.md

@@ -1,6 +1,6 @@
 # Iceland Travel Service Example
 
-A complete example demonstrating how to create an Iceland travel service using WoWok protocol. This service integrates weather-dependent activities, insurance sub-orders, and multi-node workflow management.
+A complete example demonstrating how to create an Iceland travel service using WoWok protocol. This service integrates weather-dependent activities and multi-node workflow management. (Note: "Buy Insurance" is just the name of the first workflow node in this example — there is no real insurance sub-order mechanism.)
 
 ---
 
@@ -320,13 +320,46 @@ Create a Permission object to manage access control for the travel service. Add
 }
 ```
 
-> **Note**: Permission indices 1000-1009 are used for different workflow forwards. Index 306 is a reserved administrative permission. The travel_provider account is granted all these permissions.
+> **Note**: Permission indices 1000-1009 are used for different workflow forwards. Index 306 is the built-in `SERVICE_MACHINE` permission — it governs binding or changing a Service's Machine (`service::machine_set`), and is required in Step 5 when the Service binds `travel_machine`. The travel_provider account is granted all these permissions.
+
+---
+
+## Step 1.5: Create Arbitration Permission
+
+Create a dedicated Permission object for the Arbitration. No special permission indices are needed — the creator (`travel_provider`) automatically becomes the admin of the new Permission.
+
+> **Why a separate Permission?** When a Service binds an Arbitration, the contract asserts `arbitration.permission != service.permission` (error `E_ARBITRATION_PERMISSION_CONFLICT`). If the Arbitration shared the Service's permission, the Service owner would control dispute resolution, breaking fairness. The Arbitration must therefore use an independent Permission object.
+
+**Prompt**: Create a Permission object named "travel_arbitration_permission" for the arbitration.
+
+```json
+{
+  "tool": "onchain_operations",
+  "data": {
+    "operation_type": "permission",
+    "data": {
+      "object": {
+        "name": "travel_arbitration_permission",
+        "tags": ["travel", "arbitration"],
+        "replaceExistName": true
+      },
+      "description": "Independent permission for travel arbitration (must differ from the Service permission)"
+    },
+    "env": {
+      "account": "travel_provider",
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  }
+}
+```
 
 ---
 
 ## Step 2: Create Arbitration Object
 
-Create an Arbitration object for dispute resolution.
+Create an Arbitration object for dispute resolution. It uses the independent `travel_arbitration_permission` created in Step 1.5.
 
 **Prompt**: Create an Arbitration named "travel_arbitration".
 
@@ -338,7 +371,7 @@ Create an Arbitration object for dispute resolution.
     "data": {
       "object": {
         "name": "travel_arbitration",
-        "permission": "travel_permission",
+        "permission": "travel_arbitration_permission",
         "replaceExistName": true
       },
       "description": "Arbitration for Iceland travel service disputes"
@@ -1063,7 +1096,7 @@ Create a Machine to define the travel service workflow with all nodes and forwar
 | Complete | Ice Scooting | complete_trip | 1002 | travel_complete_guard |
 | Cancel | Ice Scooting | cancel_trip | 1003 | travel_cancel_guard |
 
-> **Note**: The `prev_node` field uses an empty string `""` to denote the entry point. Each node defines how to enter it from a previous node. The `threshold` field (required) specifies the minimum forward weight needed to trigger node advancement.
+> **Note**: The `prev_node` field uses an empty string `""` to denote the entry point. Each node defines how to enter it from a previous node. The `threshold` field (optional, defaults to `0`) specifies the minimum forward weight needed to trigger node advancement.
 
 ---
 
@@ -1114,7 +1147,6 @@ Configure the travel service (created unpublished in Step 2.5) with all bindings
         "allocators": [
           {
             "guard": "merchant_victory_guard",
-            "fix": "0",
             "sharing": [
               {
                 "who": {"Entity": {"name_or_address": "travel_treasury"}},
@@ -1125,7 +1157,6 @@ Configure the travel service (created unpublished in Step 2.5) with all bindings
           },
           {
             "guard": "no_ice_scooting_guard",
-            "fix": "0",
             "sharing": [
               {
                 "who": {"Entity": {"name_or_address": "travel_treasury"}},
@@ -1141,7 +1172,6 @@ Configure the travel service (created unpublished in Step 2.5) with all bindings
           },
           {
             "guard": "no_spa_guard",
-            "fix": "0",
             "sharing": [
               {
                 "who": {"Entity": {"name_or_address": "travel_treasury"}},
@@ -1281,7 +1311,8 @@ Move from initial node ("") to "Buy Insurance" node.
         "operation": {
           "next_node_name": "Buy Insurance",
           "forward": "buy_insurance"
-        }
+        },
+        "op": "next"
       }
     },
     "env": {
@@ -1310,7 +1341,8 @@ Move from "Buy Insurance" to "SPA" node.
         "operation": {
           "next_node_name": "SPA",
           "forward": "go_spa"
-        }
+        },
+        "op": "next"
       }
     },
     "env": {
@@ -1339,7 +1371,8 @@ Move from "SPA" to "Ice Scooting" node. This forward has a Guard (`weather_check
         "operation": {
           "next_node_name": "Ice Scooting",
           "forward": "go_ice_scooting"
-        }
+        },
+        "op": "next"
       }
     },
     "submission": {
@@ -1395,7 +1428,8 @@ Move from "Ice Scooting" to "Complete" node. This forward has a Guard (`travel_c
         "operation": {
           "next_node_name": "Complete",
           "forward": "complete_trip"
-        }
+        },
+        "op": "next"
       }
     },
     "submission": {
@@ -1430,7 +1464,7 @@ Move from "Ice Scooting" to "Complete" node. This forward has a Guard (`travel_c
 }
 ```
 
-> **Note**: Replace `<ORDER_OBJECT_ID>` with the actual Order object ID (e.g., `0x7cc9f2228e130c2f6b585bb9c4666fd4d03252d38048355678f46e31b682eb38`). You can query the Progress object to find the `task` field which contains the Order ID.
+> **Note**: Replace `<ORDER_OBJECT_ID>` with the actual Order object ID (a 64-hex-character string starting with `0x`). You can query the Progress object to find the `task` field which contains the Order ID.
 >
 > **Key**: The `submission` field is at the **top level** of the input (alongside `data` and `env`), NOT inside `data`. The `impack: true` means the Guard verification result affects the final outcome.
 
@@ -1451,7 +1485,8 @@ Move from "Ice Scooting" to "Complete" node. This forward has a Guard (`travel_c
         "operation": {
           "next_node_name": "Cancel",
           "forward": "cancel_trip"
-        }
+        },
+        "op": "next"
       }
     },
     "submission": {
@@ -1487,6 +1522,7 @@ Move from "Ice Scooting" to "Complete" node. This forward has a Guard (`travel_c
 | `data.object` | string | Progress object name/ID |
 | `data.operate.operation.next_node_name` | string | Target node name to move to |
 | `data.operate.operation.forward` | string | Forward name defined in Machine |
+| `data.operate.op` | string | **Required.** Operation type: `"next"` (advance the forward), `"hold"`, `"unhold"`, or `"adminUnhold"` |
 | `submission` | object | Guard verification data (top-level, required when forward has Guard) |
 | `env.no_cache` | boolean | Set to `true` to avoid stale cache issues |
 
@@ -1524,7 +1560,7 @@ The allocation Guard requires the Order ID as a submission (identifier: 0). Quer
 
 ### 8.2 Execute Allocation (Merchant Victory Path)
 
-When the Progress is "Complete", the `merchant_victory_guard` passes, and 100% of funds go to the Service object.
+When the Progress is "Complete", the `merchant_victory_guard` passes, and 100% of funds go to the Treasury (`travel_treasury`).
 
 **Prompt**: Execute fund allocation with the merchant_victory_guard, submitting the Order ID.
 
@@ -1577,7 +1613,7 @@ When the Progress is "Complete", the `merchant_victory_guard` passes, and 100% o
 
 For refund scenarios (Cancel or SPA), use the corresponding Guard. The same submission structure applies — the Order ID is submitted to identifier 0.
 
-**Cancel/Ice Scooting path** (80% Service, 20% Order):
+**Cancel/Ice Scooting path** (80% Treasury, 20% Order (escrow, claimable by the order owner)):
 
 ```json
 {
@@ -1601,7 +1637,7 @@ For refund scenarios (Cancel or SPA), use the corresponding Guard. The same subm
 }
 ```
 
-**SPA path** (5% Service, 95% Order):
+**SPA path** (5% Treasury, 95% Order (escrow, claimable by the order owner)):
 
 ```json
 {
@@ -1660,6 +1696,57 @@ After allocation, query the Allocation and Payment objects to verify the fund di
 
 > **Important**: `alloc_by_guard` accepts Guard names (e.g., `"merchant_victory_guard"`) or Guard object IDs. The Guard must exist in the Allocation's `allocators` list. Only the first Guard that passes (first-Guard-wins) triggers fund distribution.
 
+### 8.5 Claim Allocated Funds (Unwrap CoinWrapper)
+
+Allocation does not deposit spendable coins directly. `alloc_by_guard` distributes **CoinWrapper objects** to each recipient address — these must be claimed/unwrapped before the funds are spendable:
+
+- **Treasury share** (`Entity` → `travel_treasury`): the CoinWrapper is sent to the Treasury object address. The travel provider deposits it into the Treasury balance via the Treasury `receive` operation.
+- **Customer share** (`GuardIdentifier: 0` → the Order object address submitted at runtime, i.e. escrow): the CoinWrapper is sent to the Order object address. The order owner (Alice) claims it via the Order `receive` operation, which unwraps it and transfers the coins to her wallet.
+
+**Prompt**: Alice claims the customer share escrowed to the Order (refund paths only).
+
+```json
+{
+  "tool": "onchain_operations",
+  "data": {
+    "operation_type": "order",
+    "data": {
+      "object": "alice_travel_order",
+      "receive": "recently"
+    },
+    "env": {
+      "account": "alice",
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  }
+}
+```
+
+**Prompt**: The travel provider deposits the Treasury's share into the Treasury balance.
+
+```json
+{
+  "tool": "onchain_operations",
+  "data": {
+    "operation_type": "treasury",
+    "data": {
+      "object": "travel_treasury",
+      "receive": "recently"
+    },
+    "env": {
+      "account": "travel_provider",
+      "network": "testnet",
+      "no_cache": true,
+      "confirmed": true
+    }
+  }
+}
+```
+
+> **Note**: `"receive": "recently"` auto-queries and claims all recently received CoinWrapper objects. For the Order, `receive` unwraps them and transfers the coins to the order owner (Alice); for the Treasury, `receive` deposits the unwrapped coins into the Treasury's balance. In the merchant-victory path (100% to Treasury) only the Treasury claim is needed; the Order claim applies only to refund paths (8.3) where the customer has a share.
+
 ---
 
 ## Best Practices

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@wowok/skills",
-  "version": "1.3.4",
-  "description": "WoWok AI Skills for Claude and other AI assistants - Helping AI use WoWok MCP tools correctly",
+  "version": "2.0.0",
+  "description": "WoWok AI Skills for Claude and other AI assistants - Dialogue orchestration layer on top of the WoWok MCP server (rules/reference knowledge is served by MCP directly since v2.0.0)",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
   "bin": {
@@ -11,15 +11,11 @@
     "dist/",
     "wowok-provider/",
     "wowok-arbitrator/",
-    "wowok-guard/",
-    "wowok-tools/",
-    "wowok-safety/",
     "wowok-machine/",
     "wowok-order/",
     "wowok-messenger/",
     "wowok-output/",
     "wowok-onboard/",
-    "wowok-scenario/",
     "wowok-planner/",
     "wowok-auditor/",
     "examples/",

package/scripts/install.js

@@ -16,22 +16,47 @@ const path = require('path');
 const os = require('os');
 const { execSync } = require('child_process');
 
+/**
+ * Retained skills (post GLM5-31 sink refactor) — only these are installed.
+ * The 4 rule-reference skills (wowok-safety/tools/scenario/guard) were sunk
+ * into the MCP knowledge layer and are served by the MCP server directly:
+ *   - wowok-safety   → schema_query action='get_safety_rules'
+ *   - wowok-tools    → schema_query action='get_tool_reference'
+ *   - wowok-scenario → project_operation recommend_industry / create_project
+ *   - wowok-guard    → schema_query action='get_guard_design_patterns'
+ */
 const SKILL_DIRS = [
   'wowok-provider',
   'wowok-arbitrator',
   'wowok-order',
   'wowok-messenger',
-  'wowok-guard',
   'wowok-machine',
   'wowok-output',
-  'wowok-tools',
-  'wowok-safety',
   'wowok-onboard',
-  'wowok-scenario',
   'wowok-planner',
   'wowok-auditor',
 ];
 
+/**
+ * Deprecated skills removed in the GLM5-31 sink refactor. They are NEVER
+ * installed, but preuninstall/init still clean them up from legacy installs
+ * and warn the user where the content now lives.
+ */
+const LEGACY_SKILL_DIRS = [
+  'wowok-guard',
+  'wowok-tools',
+  'wowok-safety',
+  'wowok-scenario',
+];
+
+/** Where each deprecated skill's content now lives (migration message). */
+const SKILL_MIGRATION_MAP = {
+  'wowok-safety': "MCP schema_query action='get_safety_rules'",
+  'wowok-tools': "MCP schema_query action='get_tool_reference'",
+  'wowok-scenario': "MCP project_operation action='recommend_industry' / 'create_project'",
+  'wowok-guard': "MCP schema_query action='get_guard_design_patterns'",
+};
+
 const CLIENT_DIRS = {
   claude: path.join(os.homedir(), '.claude', 'skills'),
   cursor: path.join(os.homedir(), '.cursor', 'rules'),
@@ -172,7 +197,9 @@ function installSkills(targetDir, target) {
 function uninstallSkills(targetDir) {
   let count = 0;
 
-  for (const dir of SKILL_DIRS) {
+  // Remove both retained and legacy (deprecated) skills — legacy dirs may
+  // still exist from pre-refactor installs and must be cleaned up.
+  for (const dir of [...SKILL_DIRS, ...LEGACY_SKILL_DIRS]) {
     const dirPath = path.join(targetDir, dir);
     if (fs.existsSync(dirPath)) {
       removeDir(dirPath);
@@ -184,6 +211,23 @@ function uninstallSkills(targetDir) {
   return count;
 }
 
+/**
+ * Detect deprecated skills still present in a target dir and print a
+ * migration hint (GLM5-31 §3.2). Returns the list of legacy dirs found.
+ */
+function warnLegacySkills(targetDir) {
+  const found = LEGACY_SKILL_DIRS.filter((dir) => fs.existsSync(path.join(targetDir, dir)));
+  if (found.length > 0) {
+    console.warn(`[wowok-skills] ⚠ MIGRATION: deprecated skills detected in ${targetDir}:`);
+    for (const dir of found) {
+      console.warn(`[wowok-skills]   - ${dir} → content now served by ${SKILL_MIGRATION_MAP[dir]}`);
+    }
+    console.warn('[wowok-skills]   These skills are stale (MCP knowledge layer is the source of truth).');
+    console.warn('[wowok-skills]   Remove them with: wowok-skills uninit  (or delete the folders above)');
+  }
+  return found;
+}
+
 function getTargets() {
   const envTargets = process.env.WOWOK_SKILLS_TARGETS;
   if (!envTargets) {
@@ -206,6 +250,8 @@ function main() {
       console.log(`[wowok-skills] → ${dir}`);
       const count = installSkills(dir, target);
       total += count;
+      // GLM5-31 §3.2: warn about stale pre-refactor skills still present.
+      warnLegacySkills(dir);
     }
 
     console.log(`[wowok-skills] Done — ${total} skills installed across ${targets.length} client(s).`);
@@ -256,7 +302,7 @@ function main() {
 
 function countExisting(targetDir) {
   let count = 0;
-  for (const dir of SKILL_DIRS) {
+  for (const dir of [...SKILL_DIRS, ...LEGACY_SKILL_DIRS]) {
     if (fs.existsSync(path.join(targetDir, dir))) {
       count++;
     }

package/wowok-arbitrator/SKILL.md

@@ -30,7 +30,7 @@ The following content has been pushed down to the MCP knowledge layer and is app
 |---------|---------------------|-------------|
 | Guard design rules (structural layers, data source classification, voting_guard table design) | `knowledge/guard-design-patterns.ts` (`GUARD_DESIGN_PATTERNS`) | `project_operation.evaluate_project` (via `assessGuardRisks`) |
 | Safety rules (confirmation levels, immutability, object reuse) | `knowledge/safety-rules.ts` (`CONFIRMATION_RULES`) | Pre-publish checks + `project_operation.evaluate_project` |
-| Arbitration-specific risks | `knowledge/arb-risk.ts` (`assessArbitrationRisks`) | `project_operation.evaluate_project` |
+| Arbitration-specific risks | `knowledge/arbitration-risk.ts` (`assessArbitrationRisks`) | `project_operation.evaluate_project` |
 
 This Skill keeps the arbitration **conversation flow**, **evidence collection** scripts, and **dispute resolution** guidance — the MCP layer handles the rule evaluation.
 

package/wowok-machine/SKILL.md

@@ -234,7 +234,7 @@ All stem from the same root: **every on-chain object has a publish/create freeze
 | `refunded` (terminal) | `refund_routing` (routing) → Allocator fires |
 | N/A (dispute) | `arbiter_rule` (routing) → Arbitration off-Machine (no Allocator) |
 
-See [wowok-scenario](../wowok-scenario/SKILL.md) "Rental Mode Template (R-M1-11 Compliant)" for a complete 10-node rental topology.
+A complete R-M1-11-compliant rental topology is auto-generated by `project_operation.create_project` with `project_industry='rental'` (MCP `knowledge/scenario-modes.ts`).
 
 ### Pre-Publish Validation Checklist
 
@@ -245,7 +245,7 @@ Before `publish: true`, verify:
 - [ ] **Every node has outgoing Forwards** (except terminals): no dead-end nodes
 - [ ] **Every node has incoming Pair** (except entry): no orphaned nodes
 - [ ] **All thresholds independently achievable**: no dead branches (competing Pair always wins first)
-- [ ] **⚠ R-M1-11 Compliance** (CRITICAL for deposit/refund scenarios): NO terminal nodes named `deposit_refunded`, `deposit_deducted`, `refunded`, or any name implying Machine-internal refund/deduction. Refund/deduction MUST flow through an **Allocator** triggered by a routing node (e.g., `return_approved`, `damage_confirmed`, `arbiter_rule`). Violating this causes funds to lock in the Machine with no Allocator path. See [wowok-scenario](../wowok-scenario/SKILL.md) "Rental Mode Template (R-M1-11 Compliant)".
+- [ ] **⚠ R-M1-11 Compliance** (CRITICAL for deposit/refund scenarios): NO terminal nodes named `deposit_refunded`, `deposit_deducted`, `refunded`, or any name implying Machine-internal refund/deduction. Refund/deduction MUST flow through an **Allocator** triggered by a routing node (e.g., `return_approved`, `damage_confirmed`, `arbiter_rule`). Violating this causes funds to lock in the Machine with no Allocator path. Auto-enforced by MCP pre-publish checks and `project_operation.evaluate_project`.
 - [ ] All Guards exist on-chain and tested (use `gen_passport`)
 - [ ] `namedOperator` vs `permissionIndex` correct per Forward
 - [ ] Every Forward has at least one of `namedOperator` or `permissionIndex`

package/wowok-messenger/SKILL.md

@@ -25,8 +25,9 @@ always: false
 End-to-end encrypted messaging with tamper-proof audit trails.
 
 > **Role**: Any WoWok participant
-> All 16 operations with full parameter types and constraints are in the MCP schema (`messenger_operation`). This document focuses on **design decisions and strategy** not captured by the schema.
-> **Related Skills**: [wowok-guard](../wowok-guard/SKILL.md) (guard design), [wowok-arbitrator](../wowok-arbitrator/SKILL.md) (WTS evidence in disputes), [wowok-order](../wowok-order/SKILL.md) (customer perspective), [wowok-provider](../wowok-provider/SKILL.md) (service provider perspective), [wowok-safety](../wowok-safety/SKILL.md) (safety)
+> All 17 operations with full parameter types and constraints are in the MCP schema (`messenger_operation`). This document focuses on **design decisions and strategy** not captured by the schema.
+> **Related Skills**: [wowok-arbitrator](../wowok-arbitrator/SKILL.md) (WTS evidence in disputes), [wowok-order](../wowok-order/SKILL.md) (customer perspective), [wowok-provider](../wowok-provider/SKILL.md) (service provider perspective)
+> Guard design patterns and safety rules now live in the MCP knowledge layer — query via `schema_query` actions `get_guard_design_patterns` / `get_safety_rules`.
 
 ---
 
@@ -71,7 +72,7 @@ The on-chain **Contact** object (`operation_type: "contact"`) is the bridge betw
 
 **When to create**: Before Service publish, when `customer_required` is set (Service.um must point to a Contact). Reuse an existing Contact if you serve multiple Services with the same support channel.
 
-**Lifecycle**: Contact is mutable (unlike Proof/Guard). `im_add`/`im_remove` require permission index 453 (CONTACT_IM). No events emitted on IM mutations — poll `ims[]` field. If Contact is bound to `Permission.um` via `permission_um_set`, clear that binding BEFORE deleting the Contact (else dangling pointer). Full business guidance: [wowok-tools](../wowok-tools/SKILL.md) §"Contact (Service.um Bridge)".
+**Lifecycle**: Contact is mutable (unlike Proof/Guard). `im_add`/`im_remove` require permission index 453 (CONTACT_IM). No events emitted on IM mutations — poll `ims[]` field. If Contact is bound to `Permission.um` via `permission_um_set`, clear that binding BEFORE deleting the Contact (else dangling pointer). Full field constraints: MCP `schema_query` action='get' name='contact'.
 
 ---
 
@@ -85,6 +86,7 @@ Two approaches, depending on need:
 
 - **Quick glance** — `watch_conversations` with `unreadOnly: true` lists all conversations with unread messages, sorted by activity. Each conversation shows a preview of the last messages.
 - **Deep dive** — `watch_messages` with a specific `peerAddress` to view the full conversation with a particular counterparty. Supports keyword search, time-range filtering, direction filter, and status filter.
+- **Server sync** — `pull_messages` fetches the latest messages from the server into local storage (optional `limit` caps batch size). Use this first when the local view looks stale (e.g. after downtime or on a new device session), then read via `watch_conversations` / `watch_messages`.
 
 **Design note**: By default, retrieving messages auto-marks them as viewed (`viewedAt` timestamp). Set `skipAutoMarkViewed: true` if you want to peek without marking read.
 

package/wowok-onboard/SKILL.md

@@ -78,6 +78,8 @@ The onboarding flow is backed by the MCP SQLite-based project pipeline. Each ste
 | 3. Build Graph | After R8 | `build_graph` → object dependency graph from added objects | — |
 | 4. Evaluate | After graph built | `evaluate_project` (evaluation_type='risk') → risk assessment | CRITICAL risks block R9 |
 
+> **Async mode**: `build_graph` / `evaluate_project` accept `async_mode: true` for large projects — the call returns immediately with a `task_id`. Poll `query_task_status` with that `task_id` until `status: "completed"` before reading results / proceeding to the next step. Default is synchronous (`async_mode` omitted) — fine for the ≤10-object onboarding scale.
+
 ## R1-R10 Build Order
 
 | Round | Object | MCP Operation | Key Decision |
@@ -104,13 +106,13 @@ When the user describes their business (R2), match to one of the supported indus
 | `general` | `general` | Free-form / hybrid — no presets, full manual control |
 | `retail` | `general` (retail profile) | Physical goods sales with stock + WIP product listings |
 | `service` | `general` (service profile) | Intangible services (consulting, design) — milestone delivery |
-| `rental` | `rental` | Equipment / vehicle / property rental with deposit escrow + return inspection (R-M1-11 compliant — uses `return_approved`/`damage_confirmed`/`arbiter_rule` routing nodes, NO `deposit_refunded`/`deposit_deducted`/`refunded` terminal nodes; see [wowok-scenario](../wowok-scenario/SKILL.md) "Rental Mode Template") |
+| `rental` | `rental` | Equipment / vehicle / property rental with deposit escrow + return inspection (R-M1-11 compliant — uses `return_approved`/`damage_confirmed`/`arbiter_rule` routing nodes, NO `deposit_refunded`/`deposit_deducted`/`refunded` terminal nodes; topology auto-applied by `project_operation.create_project` with `project_industry='rental'` from MCP `knowledge/scenario-modes.ts`) |
 | `freelance` | `freelance` | Design / dev / consulting — milestone allocation + acceptance gate |
 | `education` | `education` | Courses / training / tutoring — periodic release per session attendance |
 | `travel` | `travel` | Custom tours / multi-segment trips — multi-tier allocation per segment |
 | `subscription` | `subscription` | SaaS / content membership / periodic service — periodic charge + cancel guard |
 
-> If unsure which fits, default to `general`. Users can switch modes mid-onboarding (see wowok-scenario "Escape Hatch"). For mode composition (e.g., freelance + subscription retainer), see [wowok-scenario](../wowok-scenario/SKILL.md).
+> If unsure which fits, call `project_operation` action='recommend_industry' with the user's business description — it returns top-3 industry matches with reference examples. To iterate a mode mid-onboarding, use action='derive_user_mode' / 'evolve_user_mode' (user mode registry in MCP).
 
 ---
 
@@ -138,9 +140,9 @@ Before declaring onboarding complete, verify ALL items. Each is a hard gate —
 | Error | Cause | Fix |
 |-------|-------|-----|
 | `dynamicFieldNotFound` | SDK cannot resolve a dynamic field reference | Set `env.account` (account not configured) — pass account in the tool call wrapper |
-| `Circular dependency` (Guard ↔ Service creation) | Guard needs Service address; Service needs Guard address | Use **LocalMark NAME** (not address) in Guard query table — see [wowok-guard](../wowok-guard/SKILL.md) "Circular Dependency Handling" |
+| `Circular dependency` (Guard ↔ Service creation) | Guard needs Service address; Service needs Guard address | Use **LocalMark NAME** (not address) in Guard query table — pattern documented in MCP `schema_query` action='get_guard_design_patterns' |
 | `order.balance invalid` | Used wrong field for order amount | Use `order.amount` (not `order.balance` — `balance` is residual escrow, `amount` is original payment) |
 | Allocator `rate sum != 10000` | Rate-mode Allocator sharing percentages don't sum to 100% | Ensure all `sharing[].sharing` values in Rate mode sum to exactly **10000** basis points (e.g., 80% = 8000) |
-| `IMPACK_GUARD_NOT_FOUND` (gen_passport) | Repository query with `quote_guard = Some(addr)` | `impack_list` is empty during verify phase — only `quote_guard = None` passes; see [wowok-guard](../wowok-guard/SKILL.md) |
+| `IMPACK_GUARD_NOT_FOUND` (gen_passport) | Repository query with `quote_guard = Some(addr)` | `impack_list` is empty during verify phase — only `quote_guard = None` passes; see MCP `schema_query` action='get_guard_design_patterns' |
 | `Permission denied` (Progress advance, abort code 5) | Wrong operation path for forward's `namedOperator` | Empty `namedOperator` → use `order.progress`; non-empty → use `progress.operate`; `permissionIndex` → use `progress.operate` |
-| Allocator never fires (refund stuck) — R-M1-11 violation | Machine has a node like `deposit_refunded` instead of routing node `return_approved`; or Allocator's `trigger_node` is missing/mispelled | Rename node to `return_approved` / `damage_confirmed`; bind Allocator to that node; see [wowok-scenario](../wowok-scenario/SKILL.md) "Rental Mode Template (R-M1-11 Compliant)" |
+| Allocator never fires (refund stuck) — R-M1-11 violation | Machine has a node like `deposit_refunded` instead of routing node `return_approved`; or Allocator's `trigger_node` is missing/mispelled | Rename node to `return_approved` / `damage_confirmed`; bind Allocator to that node; R-M1-11 is auto-enforced by MCP pre-publish checks and `project_operation.evaluate_project` |

package/wowok-order/SKILL.md

@@ -2,7 +2,7 @@
 name: wowok-order
 description: |
   WoWok Customer Guide — complete buyer order lifecycle: pre-purchase due diligence
-  (E1-E10), consensus building, order creation, progress advancement, and arbitration.
+  (E1-E11), consensus building, order creation, progress advancement, and arbitration.
 when_to_use:
   - User is a customer/buyer placing or managing orders
   - User wants to evaluate services before purchasing
@@ -15,7 +15,8 @@ when_to_use:
 # WoWok Customer Guide
 
 > **Role**: Customer (Buyer/Order Holder)  
-> **Provider Guide**: [wowok-provider](../wowok-provider/SKILL.md) | **Arbitration Guide**: [wowok-arbitrator](../wowok-arbitrator/SKILL.md) | **Guard Design**: [wowok-guard](../wowok-guard/SKILL.md) | **Machine**: [wowok-machine](../wowok-machine/SKILL.md) | **Messenger**: [wowok-messenger](../wowok-messenger/SKILL.md) | **Safety**: [wowok-safety](../wowok-safety/SKILL.md) | **Tools**: [wowok-tools](../wowok-tools/SKILL.md)
+> **Provider Guide**: [wowok-provider](../wowok-provider/SKILL.md) | **Arbitration Guide**: [wowok-arbitrator](../wowok-arbitrator/SKILL.md) | **Machine**: [wowok-machine](../wowok-machine/SKILL.md) | **Messenger**: [wowok-messenger](../wowok-messenger/SKILL.md)
+> Guard design patterns, safety rules, and tool references now live in the MCP knowledge layer — query via `schema_query` actions `get_guard_design_patterns`, `get_safety_rules`, `get_tool_reference`.
 
 ---
 
@@ -41,7 +42,7 @@ Allocation evaluates when Progress reaches **any** configured node (not just exi
 
 ## Phase 1: Pre-Purchase Due Diligence (MANDATORY GATE)
 
-> **⛔ Complete E1-E10 in order. User must explicitly confirm every item.**
+> **⛔ Complete E1-E11 in order. User must explicitly confirm every item.**
 > **⚠️ = explain risk, wait for decision. 🔴 = strongly advise against purchase.**
 
 ---
@@ -62,7 +63,7 @@ From E1 `sales[]`. Skip `suspension === true` items.
 
 **WIP Verification** (mandatory when `wip_hash` non-empty):
 
-Use `wip_file` → `op: "verify"`, `wipFilePath: "<wip_url>"`, `hash_equal: "<wip_hash>"`.
+Use `wip_file` → `type: "verify"`, `wipFilePath: "<wip_url>"`, `hash_equal: "<wip_hash>"`.
 
 - `wip_hash` empty → no on-chain commitment (auto-verified, weaker evidence)
 - Verification fails → 🔴 **WIP tampered after publish**
@@ -112,7 +113,7 @@ Use `wip_file` → `op: "verify"`, `wipFilePath: "<wip_url>"`, `hash_equal: "<wi
 
 ### E4 — Guards Analysis
 
-Guard structure and instruction reference: [wowok-guard](../wowok-guard/SKILL.md).
+Guard structure and instruction reference: MCP `schema_query` action='get_guard_design_patterns' (design patterns) and action='get_guard_templates' (ready-made templates).
 
 **Step 1**: Collect unique Guard IDs from E3 Machine JSON (`forward.guard.guard`), E1 `order_allocators`, E1 `buy_guard`. Deduplicate.
 
@@ -200,9 +201,23 @@ For matched: present value, ask "correct?" and "OK to send?". For missing: ask u
 
 ---
 
+### E11 — Trust Score Synthesis (Preorder Advice)
+
+Aggregate E1–E10 into a decision-grade assessment via `trust_score`:
+
+`wowok({ tool: "trust_score", data: { service: "<service_id>", depth: "preorder", order_amount: "<planned_amount>" } })`
+
+- Returns trust score + per-dimension risks + preorder advice (order confidence, game strategies, preference match, industry risks, `blocking_reminders`); non-empty `blocking_reminders` → ⛔ resolve with user BEFORE Phase 2.
+- Comparing multiple candidates → add `compare_with: ["<id2>", ...]` (1–9, same `depth: "preorder"`): output gains a `comparison` block with per-metric bests — **NO overall ranking**; present trade-offs, the buyer decides.
+- Optional `preferences` / `user_metrics` reflect the buyer's own priorities.
+
+> Fast pre-screen: at E1 you may call `depth: "evaluate"` (default) for a quick score; 🔴 `risk_score` (<50) → advise early abort, skip E2–E10.
+
+---
+
 ### Pre-Purchase GATE
 
-**Abort conditions**: E1 `bPublished=false`/`bPaused=true` → ABORT; E8 `um=null` → ABORT; E3 no-refund + E6 no-arb → strongly advise ABORT; E4 ambiguous Guards → user MUST manually review.
+**Abort conditions**: E1 `bPublished=false`/`bPaused=true` → ABORT; E8 `um=null` → ABORT; E3 no-refund + E6 no-arb → strongly advise ABORT; E4 ambiguous Guards → user MUST manually review; E11 `blocking_reminders` → resolve with user BEFORE proceeding.
 
 **Any ⚠️** → explain risk, wait for user decision. **All OK** → Phase 2.
 
@@ -369,7 +384,7 @@ For precise control, pass an explicit array of `{id, type}` objects, or pass the
 
 ### Phase Dependency
 
-E1 (Service) → E2 (Products/WIP), E8 (Contact), E10 (Privacy), E7 (Compensation), E6 (Arbitrations) run in parallel after E1. E3 (Machine) → E4 (Guards) → E5 (Allocators) is a strict chain. E9 (Reputation) follows E3.
+E1 (Service) → E2 (Products/WIP), E8 (Contact), E10 (Privacy), E7 (Compensation), E6 (Arbitrations) run in parallel after E1. E3 (Machine) → E4 (Guards) → E5 (Allocators) is a strict chain. E9 (Reputation) follows E3. E11 (Trust Score) runs LAST — it aggregates all prior findings.
 
 ### ⚠️ Critical Attention Items
 

package/wowok-output/SKILL.md

@@ -134,11 +134,11 @@ When user asks about field meanings:
 
 # Related Skills
 
-| Skill | Purpose |
+| Skill / MCP Knowledge | Purpose |
 |-------|---------|
-| [wowok-safety](../wowok-safety/SKILL.md) | Pre-operation safety checks |
-| [wowok-guard](../wowok-guard/SKILL.md) | Guard design & validation |
-| [wowok-tools](../wowok-tools/SKILL.md) | Tool selection patterns |
+| MCP `schema_query` action='get_safety_rules' | Pre-operation safety checks (sunk from wowok-safety) |
+| MCP `schema_query` action='get_guard_design_patterns' | Guard design & validation (sunk from wowok-guard) |
+| MCP `schema_query` action='get_tool_reference' | Tool selection patterns (sunk from wowok-tools) |
 | [wowok-order](../wowok-order/SKILL.md) | Order lifecycle (buyer) |
 | [wowok-provider](../wowok-provider/SKILL.md) | Service management (merchant) |
 | [wowok-arbitrator](../wowok-arbitrator/SKILL.md) | Dispute resolution |

package/wowok-planner/SKILL.md

@@ -26,7 +26,8 @@ when_to_use:
 Converts natural-language intent into an executable Object Dependency Graph (ODG) and phased execution plan. Deterministic-first: rules and scenario templates decide the shape; the LLM only clarifies ambiguity and translates free text into typed fields.
 
 > **Layer**: L3 Skill, primary planner for L4 Harness Plan Loop
-> **Related Skills**: [wowok-onboard](../wowok-onboard/SKILL.md) (guided execution), [wowok-scenario](../wowok-scenario/SKILL.md) (scenario templates), [wowok-tools](../wowok-tools/SKILL.md) (MCP reference), [wowok-machine](../wowok-machine/SKILL.md) (workflow design), [wowok-guard](../wowok-guard/SKILL.md) (Guard design), [wowok-safety](../wowok-safety/SKILL.md) (immutability rules), [wowok-provider](../wowok-provider/SKILL.md) (post-plan operations)
+> **Related Skills**: [wowok-onboard](../wowok-onboard/SKILL.md) (guided execution), [wowok-machine](../wowok-machine/SKILL.md) (workflow design), [wowok-provider](../wowok-provider/SKILL.md) (post-plan operations)
+> Industry modes, Guard design patterns, safety rules, and tool references now live in the MCP knowledge layer — query via `project_operation` (`recommend_industry` / `list_modes`) and `schema_query` (`get_guard_design_patterns` / `get_safety_rules` / `get_tool_reference`).
 
 ---
 

package/wowok-provider/SKILL.md

@@ -244,7 +244,7 @@ Order (per purchase, runtime-created)
 └── allocation → Allocation (optional, created at runtime; triggered via Progress.forward)
 
 Cross-object references:
-- Guard is referenced by 9 object types via diverse nested paths (see wowok-guard SKILL for full schema):
+- Guard is referenced by 9 object types via diverse nested paths (full schema via MCP `schema_query` action='get_guard_design_patterns'):
   - Service.buy_guard (top-level Option<address>)
   - Machine.forward.guard (per-node dynamic table; SDK does not expose — requires query_table)
   - Allocation.allocators[].guard (array element — graph-builder edge fieldName: allocator_guard)
@@ -314,7 +314,7 @@ Required submission: Order ID (matching the Guard's b_submission identifier)
 Immutable product commitment for arbitration evidence.
 
 ```
-Create:  wowok({ tool: "wip_file", data: { op: "generate", ... } }) → markdown_text + images → outputPath
+Create:  wowok({ tool: "wip_file", data: { type: "generate", ... } }) → markdown_text + images → outputPath
 Attach: wowok({ tool: "onchain_operations", data: { operation_type: "service", ... } }) → sales.sales[{
           name, price, stock, wip: "<URL>", wip_hash: "" (auto)
         }]
@@ -325,6 +325,16 @@ Attach: wowok({ tool: "onchain_operations", data: { operation_type: "service", .
 - Add: `compensation_fund_add` | Lock: `setting_lock_duration_add` (default 30 days = 2592000000ms, configurable via `setting_lock_duration_add`)
 - **Withdraw**: Pause Service → Wait lock duration → `compensation_fund_receive`
 
+### Payment Tokens & Stablecoin Bridging (Mainnet Only)
+
+WOW is the default settlement token. For stablecoin-denominated revenue (fiat-pegged pricing, large cross-period escrow), mainnet funds move via `bridge_operation`:
+
+- `query_supported_tokens` / `query_supported_evm_chains` — discover supported Bridge tokens (ETH/WETH/WBTC/USDC/USDT) and chains
+- `cross_chain_wow_to_evm` / `cross_chain_evm_to_wow` — WOW↔EVM transfer (mainnet env required; assets route through the auto-managed activeEvmAccount)
+- `query_transfer_status` / `query_transfer_list` — track transfers; `manage_evm_rpc` — handle EVM RPC rate limits (429)
+
+> Supported token addresses per network: `wowok_buildin_info` → 'mainnet bridge tokens'. Bridge is mainnet-only — testnet has no cross-chain path.
+
 ---
 
 ## Project Iteration: Fork vs In-Place