@wowok/skills 2.2.1 → 2.2.3

package/examples/ThreeBody_Signature/ThreeBody_Signature.md

@@ -18,7 +18,7 @@ This example sets `env.confirmed: true` on irreversible operations (e.g., `publi
 1. **Phase 1 — Preview**: Call the tool **without** `env.confirmed`. The server returns `{ status: "pending_confirmation", confirmation_text: "..." }` containing the full operation summary, risk assessment, and irreversible-action warnings.
 2. **Phase 2 — Confirm**: Review `confirmation_text` with the user. Only after explicit user approval, call the tool again **with** `env.confirmed: true` to actually execute the on-chain transaction.
 
-> Skipping Phase 1 means the user never sees the risk summary before gas is spent. Always preview first, then confirm. This is especially critical for the two `publish: true` steps in this doc: the Machine publish (**Step 3**), which irreversibly locks the workflow definition (`nodes`/`pairs`/`forwards`), and the Service publish (**Step 10**), which irreversibly locks the `machine` and `order_allocators` fields.
+> Skipping Phase 1 means the user never sees the risk summary before gas is spent. Always preview first, then confirm. This is especially critical for the two `publish: true` steps in this doc: the Machine publish (**Step 3**), which irreversibly locks the workflow definition (`nodes`/`pairs`/`forwards`), and the Service publish (**Step 11**), which irreversibly locks the `machine` and `order_allocators` fields.
 
 > **💡 Call Format**: All WoWok operations go through a single unified `wowok` tool. The AI calls `wowok({ tool: "<sub-tool>", data: {<params>} })`. If parameters don't match the schema, the response includes the correct schema for self-correction. See [Response Format](../../docs/response-format.md) for details.
 >
@@ -719,7 +719,70 @@ Create a Treasury object to aggregate signature service revenue (public funds fo
 
 ---
 
-## Step 8: Create Allocator Guard
+## Step 8: Create Contact Object (Customer-Service Channel)
+
+Create a Contact object to serve as the Service's encrypted customer-service channel. **Whenever `customer_required` is set (e.g. phone/email/shipping address), a Contact MUST be bound via the `um` field** — the customer's private information is delivered exclusively through end-to-end encrypted Messenger, which routes messages to the Contact bound as `um`. Without `um`, there is no channel to receive the customer's privacy-sensitive input and the SDK blocks the call with an invalid parameter error. The Contact uses the same Permission as the Service (`three_body_permission`) for unified governance.
+
+**Request**:
+```json
+{
+  "tool": "onchain_operations",
+  "data": {
+    "operation_type": "contact",
+    "data": {
+      "object": {
+        "name": "three_body_contact",
+        "permission": "three_body_permission",
+        "replaceExistName": true
+      },
+      "description": "Contact for Three-Body signature service customer info — end-to-end encrypted Messenger channel for delivery of phone/email/shipping_address collected via customer_required."
+    },
+    "env": {
+      "account": "three_body_author",
+      "network": "testnet",
+      "confirmed": true
+    }
+  }
+}
+```
+
+> **Why a Contact is required with customer_required (SDK-enforced hard linkage)**:
+> - `customer_required` tells the order flow which private-info labels to collect from the buyer (phone, email, shipping_address, etc.)
+> - Those labels are delivered to the merchant ONLY through the end-to-end encrypted Messenger protocol
+> - Messenger routes messages to the Service's bound Contact object (the `um` field)
+> - Without `um`, the collected private information would be silently dropped — there is no other delivery path
+> - The SDK's `checkCustomerRequiredNeedsUm()` validator in `service.ts` (L1226) runs on EVERY service operation that touches `customer_required` AND on `publish: true`, so the constraint cannot be bypassed by splitting into two calls
+
+> **Important**: `env.confirmed: true` is required because `replaceExistName: true` triggers a confirmation prompt.
+
+**Expected Result**:
+```json
+{
+  "result": {
+    "status": "success",
+    "data": {
+      "result": {
+        "type": "transaction",
+        "objectChanges": [
+          {
+            "type": "Contact",
+            "type_raw": "0x2::contact::Contact",
+            "object": "0x...",
+            "version": "...",
+            "owner": {"Shared": {"initial_shared_version": "..."}},
+            "change": "created"
+          }
+        ]
+      }
+    }
+  },
+  "schema": null
+}
+```
+
+---
+
+## Step 9: Create Allocator Guard
 
 Create a dedicated Guard for the order allocator that verifies the order belongs to this service. This is a **Level 3 scene-combined** Guard: no Signer binding is needed because the allocator uses `sharing.who=Entity(three_body_treasury)` — funds always flow to the fixed Treasury regardless of who triggers the allocation.
 
@@ -819,9 +882,9 @@ order.service == three_body_signature_service
 
 ---
 
-## Step 9: Configure Order Allocators
+## Step 10: Configure Order Allocators
 
-Set up fund allocation: 100% to the author's Treasury upon order completion.
+Set up fund allocation: 100% to the author's Treasury upon order completion. Also bind the Contact (Step 8) as `um` to enable the `customer_required` private-info delivery channel — the SDK blocks `customer_required` without a matching `um` (see Step 8 for the rationale).
 
 **Request**:
 ```json
@@ -849,7 +912,8 @@ Set up fund allocation: 100% to the author's Treasury upon order completion.
           }
         ]
       },
-      "customer_required": ["phone", "email", "shipping_address"]
+      "customer_required": ["phone", "email", "shipping_address"],
+      "um": "three_body_contact"
     },
     "env": {
       "account": "three_body_author",
@@ -860,9 +924,10 @@ Set up fund allocation: 100% to the author's Treasury upon order completion.
 ```
 
 > **⚠️ Risk Elimination — Why this configuration is safe**:
-> - **R-C3-05 (Cross-service theft)**: Eliminated by `three_body_allocator_guard` (Step 8), which verifies `order.service == three_body_signature_service` before allocation proceeds.
+> - **R-C3-05 (Cross-service theft)**: Eliminated by `three_body_allocator_guard` (Step 9), which verifies `order.service == three_body_signature_service` before allocation proceeds.
 > - **R-C3-06 (Fund theft via Signer)**: Eliminated by `sharing.who = {"Entity": {"name_or_address": "three_body_treasury"}}` — funds always flow to the fixed Treasury address regardless of who triggers the allocation. An attacker cannot redirect funds to themselves even if they somehow bypass the Guard.
 > - **Previous unsafe pattern (DO NOT USE)**: The original design used `guard: "three_body_buy_guard"` (no `order.service` check) with `sharing.who = {"Signer": "signer"}` — this allowed anyone to trigger allocation of any order's funds to themselves.
+> - **SDK-enforced constraint (customer_required ⟶ um)**: `"customer_required"` is set alongside `"um": "three_body_contact"` in the SAME call. The SDK validator `checkCustomerRequiredNeedsUm()` in `service.ts` L1226 also runs on publish (L314), so splitting into two calls (e.g. `customer_required` now, `um` later) would still fail at publish time — they are both required before the Service goes live.
 
 **Expected Result**:
 ```json
@@ -891,7 +956,7 @@ Set up fund allocation: 100% to the author's Treasury upon order completion.
 
 ---
 
-## Step 10: Add Sales and Publish Service
+## Step 11: Add Sales and Publish Service
 
 Add sales items and publish the service to make it available for orders.
 
@@ -956,7 +1021,7 @@ Add sales items and publish the service to make it available for orders.
 
 ---
 
-## Step 11: Unpause Service
+## Step 12: Unpause Service
 
 Unpause the service to allow order creation.
 
@@ -1005,7 +1070,7 @@ Unpause the service to allow order creation.
 
 ---
 
-## Step 12: Verify Service Configuration
+## Step 13: Verify Service Configuration
 
 Query the service to verify all configurations.
 
@@ -1080,7 +1145,7 @@ Query the service to verify all configurations.
                 ]
               },
               "rewards": [],
-              "um": null,
+              "um": "0x...",
               "permission": "0x...",
               "cache_expire": 1234567890,
               "query_name": "three_body_signature_service"
@@ -1095,9 +1160,10 @@ Query the service to verify all configurations.
 ```
 
 > **Field Reference**:
-> - **`buy_guard`**, **`machine`**, **`permission`**: Return **on-chain object IDs** (not names). The on-chain data stores raw object IDs; resolving them back to local mark names requires a separate reverse lookup that is not performed by `onchain_objects` queries.
+> - **`buy_guard`**, **`machine`**, **`permission`**, **`um`**: Return **on-chain object IDs** (not names). The on-chain data stores raw object IDs; resolving them back to local mark names requires a separate reverse lookup that is not performed by `onchain_objects` queries.
 > - **`query_name`**: The original name string passed in the query request (here, `"three_body_signature_service"`). This is automatically populated by the SDK from the input `objects` array, so you can identify which queried name corresponds to which returned object.
-> - **`order_allocators.allocators[].guard`**: Returns the on-chain object ID of `three_body_allocator_guard` (created in Step 8). This Guard verifies `order.service == three_body_signature_service` (R-C3-05 protection).
+> - **`um`**: The on-chain object ID of `three_body_contact` (created in Step 8). The SDK validator `checkCustomerRequiredNeedsUm()` requires this whenever `customer_required` is non-empty — without a Contact the Service has no encrypted channel to receive customer private info.
+> - **`order_allocators.allocators[].guard`**: Returns the on-chain object ID of `three_body_allocator_guard` (created in Step 9). This Guard verifies `order.service == three_body_signature_service` (R-C3-05 protection).
 > - **`order_allocators.allocators[].sharing[].who`**: `{"Entity": "0x..."}` indicates funds flow to the fixed Treasury object (`three_body_treasury` from Step 7). The address is the Treasury's on-chain object ID. This eliminates R-C3-06 (fund theft via Signer) because the recipient is fixed regardless of caller.
 > - **`order_allocators.allocators[].sharing[].mode`**: `1` is the numeric enum for `Rate` mode (input accepts the string `"Rate"`, output returns the numeric `1`).
 > - **`order_allocators.allocators[].fix`** and **`max`**: Additional fields returned on-chain (default `"0"` and `null` respectively) that are not part of the input schema but are present in the on-chain data structure.
@@ -1154,7 +1220,7 @@ The author (`three_body_author`) should be able to purchase the service.
 }
 ```
 
-> **Amount Format**: `"888WOW"` is the display format — the Fund Processing Layer converts it to `888000000000` smallest units (WOW has 9 decimals) before submission. The raw integer `888000000000` is equally valid. The order pays exactly the sale price set in Step 10.
+> **Amount Format**: `"888WOW"` is the display format — the Fund Processing Layer converts it to `888000000000` smallest units (WOW has 9 decimals) before submission. The raw integer `888000000000` is equally valid. The order pays exactly the sale price set in Step 11.
 
 **Expected Result**:
 ```json
@@ -1435,7 +1501,7 @@ The author completes the signature.
 
 ### Fund Allocation: Release the 888 WOW Payment to the Treasury
 
-Once the Progress reaches the final node (`Signature Completed`), the order is fulfilled and the 888 WOW payment held by `three_body_allocation` can be distributed. The Service's `order_allocators` (Step 9) routes 100% to `three_body_treasury` when `three_body_allocator_guard` (Step 8) verifies `order.service == three_body_signature_service`.
+Once the Progress reaches the final node (`Signature Completed`), the order is fulfilled and the 888 WOW payment held by `three_body_allocation` can be distributed. The Service's `order_allocators` (Step 10) routes 100% to `three_body_treasury` when `three_body_allocator_guard` (Step 9) verifies `order.service == three_body_signature_service`.
 
 #### (a) Trigger the Allocation (`alloc_by_guard`)
 
@@ -1690,6 +1756,7 @@ This example demonstrates:
 | Machine | three_body_machine |
 | Service | three_body_signature_service |
 | Treasury | three_body_treasury |
+| Contact (um) | three_body_contact (required for customer_required — SDK-enforced customer_required ⟶ um linkage) |
 | Allocator Guard | three_body_allocator_guard (Level 3 scene-combined, R-C3-05/R-C3-06 safe) |
 | Order | three_body_order |
 | Allocation | three_body_allocation |
@@ -1739,7 +1806,8 @@ Each node transition requires the author's confirmation, ensuring accountability
    - Service (unpublished)
    - Guards (Buy Guard for purchase control; Allocator Guard needs Service address for `order.service` verification)
    - Treasury (uses same Permission as Service for unified governance)
-   - Configure Service (add machine, buy_guard, order_allocators with allocator guard + Entity(Treasury))
+   - Contact (um) — REQUIRED before setting customer_required (SDK-enforced: customer_required ⟶ um hard linkage; validator also re-runs at publish time)
+   - Configure Service (add machine, buy_guard, order_allocators with allocator guard + Entity(Treasury); set customer_required **together with** um in the same or prior call)
    - Publish Service (LAST - once published, many changes are blocked)
 
 3. **Treasury-First Fund Flow**: Always route merchant revenue through a Treasury object using `sharing.who = {"Entity": {"name_or_address": "treasury_name"}}` instead of `{"Signer": "signer"}`. This eliminates R-C3-06 (critical fund theft via Signer) because funds flow to a fixed recipient regardless of who triggers the allocation. Combined with an allocator Guard that verifies `order.service == this_service` (R-C3-05 protection), the fund allocation becomes inherently safe.
@@ -1751,8 +1819,13 @@ Each node transition requires the author's confirmation, ensuring accountability
 
 5. **Use `no_cache: true` for Sequential Operations**: When performing multiple operations on the same object in sequence (especially Progress workflow advancement), always set `no_cache: true` in the `env` to ensure the SDK reads the latest on-chain state.
 
-6. **Query Toolkit is Your Best Friend**: Use queries constantly to verify objects exist, check configurations, debug issues, and confirm state changes.
+6. **customer_required ⟶ um (Contact) Hard Linkage (SDK-enforced)**: Whenever you set `customer_required` (e.g. `["phone", "email", "shipping_address"]`), you MUST also bind a Contact object via `um` in the SAME or a prior Service call. The SDK's `checkCustomerRequiredNeedsUm()` validator in `ts-sdk/packages/wowok/src/w/call/service.ts` (L1226) runs at TWO points:
+   - When `customer_required` is present in the current operation `data` (immediate block, L307)
+   - When `publish: true` is set (re-verifies against the accumulated Service state, L314)
+   This means splitting the two calls (set `customer_required` first, add `um` later) is NOT safe — the publish-time re-check would still block. Always create the Contact first, then set both `customer_required` and `um` together.
+
+7. **Query Toolkit is Your Best Friend**: Use queries constantly to verify objects exist, check configurations, debug issues, and confirm state changes.
 
-7. **Object IDs vs Names in Responses**: On-chain query responses return **object IDs** (e.g., `0x8202...`) for cross-object references like `buy_guard`, `machine`, `permission`. The `query_name` field in the response echoes back the original query input name. To resolve object IDs back to local mark names, use `query_toolkit` with `query_type: "local_names"`.
+8. **Object IDs vs Names in Responses**: On-chain query responses return **object IDs** (e.g., `0x8202...`) for cross-object references like `buy_guard`, `machine`, `permission`, `um`. The `query_name` field in the response echoes back the original query input name. To resolve object IDs back to local mark names, use `query_toolkit` with `query_type: "local_names"`.
 
-8. **Information Injection in Transaction Responses**: Mutation/creation operations return ALL objects affected by the transaction (including side effects like `TableItem_EntityLinker` and `TableItem_ProgressHistory`), not just the primary target. This is a deliberate design for transparency. The return order reflects the transaction's execution order.
+9. **Information Injection in Transaction Responses**: Mutation/creation operations return ALL objects affected by the transaction (including side effects like `TableItem_EntityLinker` and `TableItem_ProgressHistory`), not just the primary target. This is a deliberate design for transparency. The return order reflects the transaction's execution order.

package/examples/Travel/Travel.md

@@ -225,7 +225,7 @@ Day 5: 1783900800000 (2026-07-13T00:00:00.000Z)
           {
             "name": "Condition",
             "description": "Weather condition policy for activity dates",
-            "write_guard": [],
+            "write_guard": [{ "guard": "weather_write_guard" }],
             "id_from": "None",
             "value_type": "String"
           }
@@ -243,6 +243,8 @@ Day 5: 1783900800000 (2026-07-13T00:00:00.000Z)
 ```
 
 > **Note**: `onChain: true` is required here because `weather_repo` is created by the `weather_provider` account, but its name will be referenced in the Guard table (Step 3.1) by the `travel_provider` account. Without `onChain: true`, the name is stored locally only on `weather_provider`'s device and cannot be resolved by `travel_provider`. When `onChain: true` is set, the name is published on-chain and becomes publicly visible, allowing cross-account name resolution.
+>
+> The `write_guard` in the "Condition" policy points to `weather_write_guard` (created above). Because `id_from: "None"` lets the writer choose data ids, the contract mandates a Guard to authorize writes. `data_add` in Step 0.4 needs no Guard submission — the Guard is always-true with no submission fields.
 
 ### 0.4 Add Weather Data
 
@@ -1117,11 +1119,7 @@ Configure the travel service (created unpublished in Step 2.5) with all bindings
   "data": {
     "operation_type": "service",
     "data": {
-      "object": {
-        "name": "travel_service",
-        "permission": "travel_permission",
-        "replaceExistName": true
-      },
+      "object": "travel_service",
       "description": "Iceland travel service: Blue Lagoon SPA + Glacier Ice Scooting.",
       "machine": "travel_machine",
       "sales": {
@@ -1200,6 +1198,8 @@ Configure the travel service (created unpublished in Step 2.5) with all bindings
 }
 ```
 
+> **Note**: `object` uses a plain string reference (`"travel_service"`) so this call **configures the draft Service created in Step 2.5**. Passing a full object definition block (`{name, permission, replaceExistName}`) here would create a brand-new Service object instead — orders and allocator Guard bindings pointing at the old draft would then fail validation.
+
 **order_allocators Field Reference**:
 
 | Field | Type | Description |
@@ -1542,21 +1542,17 @@ The allocation Guard requires the Order ID as a submission (identifier: 0). Quer
 
 ```json
 {
-  "tool": "onchain_operations",
+  "tool": "query_toolkit",
   "data": {
-    "operation_type": "progress",
-    "data": {
-      "object": "alice_travel_progress"
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true
-    }
+    "query_type": "onchain_objects",
+    "objects": ["alice_travel_progress"],
+    "network": "testnet",
+    "no_cache": true
   }
 }
 ```
 
-> **Note**: The response includes a `task` field containing the Order object ID. Copy this value for the allocation submission.
+> **Note**: Use `query_toolkit` (not `onchain_operations`) for read-only lookups — queries consume no gas and never mutate state. The response includes a `task` field containing the Order object ID. Copy this value for the allocation submission.
 
 ### 8.2 Execute Allocation (Merchant Victory Path)
 
@@ -1669,16 +1665,12 @@ After allocation, query the Allocation and Payment objects to verify the fund di
 
 ```json
 {
-  "tool": "onchain_operations",
+  "tool": "query_toolkit",
   "data": {
-    "operation_type": "allocation",
-    "data": {
-      "object": "alice_travel_allocation"
-    },
-    "env": {
-      "network": "testnet",
-      "no_cache": true
-    }
+    "query_type": "onchain_objects",
+    "objects": ["alice_travel_allocation"],
+    "network": "testnet",
+    "no_cache": true
   }
 }
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wowok/skills",
-  "version": "2.2.1",
+  "version": "2.2.3",
   "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",

package/scripts/install.js

@@ -25,7 +25,7 @@ const { execSync } = require('child_process');
  * 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-scenario → industry_pack_operation recommend_industry / list_modes
  *   - wowok-guard    → schema_query action='get_guard_design_patterns'
  */
 const SKILL_DIRS = [
@@ -59,7 +59,7 @@ const LEGACY_SKILL_DIRS = [
 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-scenario': "MCP industry_pack_operation action='recommend_industry' / 'list_modes'",
   'wowok-guard': "MCP schema_query action='get_guard_design_patterns'",
 };
 

package/wowok-arbitrator/SKILL.md

@@ -28,9 +28,9 @@ The following content has been pushed down to the MCP knowledge layer and is app
 
 | Content | Access via (MCP action) | Applied Via |
 |---------|--------------------------|-------------|
-| Guard design rules (structural layers, data source classification, voting_guard table design) | `schema_query` action='get_guard_design_patterns' | `project_operation.evaluate_project` |
-| Safety rules (confirmation levels, immutability, object reuse) | `schema_query` action='get_safety_rules' | Pre-publish checks + `project_operation.evaluate_project` |
-| Arbitration-specific risks | auto-applied | `project_operation.evaluate_project` |
+| Guard design rules (structural layers, data source classification, voting_guard table design) | `schema_query` action='get_guard_design_patterns' | `goal_operation` action='aggregate_risks' |
+| Safety rules (confirmation levels, immutability, object reuse) | `schema_query` action='get_safety_rules' | Pre-publish checks + `goal_operation` action='aggregate_risks' |
+| Arbitration-specific risks | auto-applied | `goal_operation` action='aggregate_risks' |
 
 This Skill keeps the arbitration **conversation flow**, **evidence collection** scripts, and **dispute resolution** guidance — the MCP layer handles the rule evaluation.
 

package/wowok-auditor/SKILL.md

@@ -38,9 +38,9 @@ The following content has been pushed down to the MCP knowledge layer and is app
 
 | Content | Access via (MCP action) | Applied Via |
 |---------|--------------------------|-------------|
-| Safety rules (confirmation levels, immutability rules, object reuse rules) | `schema_query` action='get_safety_rules' | Pre-publish checks + `project_operation.evaluate_project` |
-| Machine-executable audit rules | auto-applied (not queryable) | `project_operation.evaluate_project` |
-| Guard completeness / Machine soundness / fund-flow risks | auto-applied (not queryable) | `project_operation.evaluate_project` |
+| Safety rules (confirmation levels, immutability rules, object reuse rules) | `schema_query` action='get_safety_rules' | Pre-publish checks + `goal_operation` action='aggregate_risks' |
+| Machine-executable audit rules | auto-applied (not queryable) | `goal_operation` action='aggregate_risks' |
+| Guard completeness / Machine soundness / fund-flow risks | auto-applied (not queryable) | `goal_operation` action='aggregate_risks' |
 
 This Skill keeps the **audit flow**, the **4 audit dimensions** (Guard completeness, Machine soundness, fund flow, publish readiness), and the **checklist structure** as the human-readable knowledge base for the L4 Harness Verify Loop. The MCP layer runs the machine-executable rule evaluation.
 

package/wowok-collaborator/SKILL.md

@@ -32,7 +32,7 @@ The following content has been pushed down to the MCP knowledge layer and is app
 
 | Content | Access via (MCP action) | Applied Via |
 |---------|--------------------------|-------------|
-| Collaborator interest analysis (fund_flow / responsibility / leverage / stakes) | `project_operation` action='participation_radar' | role derivation → `collaborator-interest` |
+| Collaborator interest analysis (fund_flow / responsibility / leverage / stakes) | `query_toolkit` query_type='participation_radar' | role derivation → `collaborator-interest` |
 | Progress routing rule (namedOperator vs permissionIndex) | `schema_query` action='get_safety_rules' | `onchain_operations` progress/order |
 | Guard design + submission patterns | `schema_query` action='get_guard_design_patterns' | guard-gated forwards |
 | Node game (threshold cooperation) | `evaluation_operation` action='node_game' | multi-role forward evaluation |
@@ -62,7 +62,7 @@ Two sub-kinds (derived on-chain, never asserted):
 
 ## What You Can Execute Now
 
-Run `project_operation` action='participation_radar' with your account + the order's Progress. It returns:
+Run `query_toolkit` query_type='participation_radar' with your account + the order's Progress. It returns:
 
 - `operable` — forwards YOU can execute right now (permission / named-operator path).
 - `waiting_on` — what the workflow waits on from other roles.

package/wowok-machine/SKILL.md

@@ -42,11 +42,11 @@ The following content has been pushed down to the MCP knowledge layer and is app
 
 | Content | Access via (MCP action) | Applied Via |
 |---------|--------------------------|-------------|
-| Node design rules (node type specs, forward guard patterns, topology limits) | auto-applied | `project_operation.create_project` (pass `project_industry`) + `project_operation.evaluate_project` |
-| Machine scene/template selection | auto-applied | `project_operation.create_project` (pass `project_industry`) |
-| Forward Guard design patterns | `schema_query` action='get_guard_design_patterns' | `project_operation.evaluate_project` |
-| Safety rules (immutability, confirmation) | `schema_query` action='get_safety_rules' | Pre-publish checks + `project_operation.evaluate_project` |
-| Publish gate (4-layer fail-closed: checklist → risk → user → environment) | auto-applied | `project_operation.evaluate_project` + pre-publish gate |
+| Node design rules (node type specs, forward guard patterns, topology limits) | auto-applied | Industry mode defaults (`industry_pack_operation` action='list_modes') + `goal_operation` action='aggregate_risks' |
+| Machine scene/template selection | auto-applied | Industry mode defaults (`industry_pack_operation` action='list_modes') |
+| Forward Guard design patterns | `schema_query` action='get_guard_design_patterns' | `goal_operation` action='aggregate_risks' |
+| Safety rules (immutability, confirmation) | `schema_query` action='get_safety_rules' | Pre-publish checks + `goal_operation` action='aggregate_risks' |
+| Publish gate (4-layer fail-closed: checklist → risk → user → environment) | auto-applied | `goal_operation` action='aggregate_risks' + pre-publish gate |
 
 This Skill keeps the **workflow conversation guidance**, **business flow design patterns**, and **machine lifecycle scripts**. The MCP layer handles node-design rule evaluation, scene/template selection, and risk aggregation.
 
@@ -74,7 +74,7 @@ This Skill keeps the **workflow conversation guidance**, **business flow design
 
 A Guard validates the Forward's execution condition. **Retained submissions**: when `retained_submission` is set on a Guard, submitted values are stored in Progress history, uniquely located by `(current_node, next_node, forward_name)`. Later nodes query these values from history.
 
-> **Guard construction**: Forward Guard design patterns (table design, computation trees, query instructions) now live in the MCP knowledge layer — query via `schema_query` action='get_guard_design_patterns', auto-applied via `project_operation.evaluate_project`. Query available Guard instructions via `wowok_buildin_info`.
+> **Guard construction**: Forward Guard design patterns (table design, computation trees, query instructions) now live in the MCP knowledge layer — query via `schema_query` action='get_guard_design_patterns', auto-applied via `goal_operation` action='aggregate_risks'. Query available Guard instructions via `wowok_buildin_info`.
 
 ### Threshold Mechanics
 
@@ -198,7 +198,7 @@ Decompose complex workflows into multiple Machines connected by Guard-based vali
 3. "Does any step depend on an external process completing first?"
 4. "Which party creates the sub-order, and which party verifies it?"
 
-> **Guard construction**: Cross-Machine Guards use `convert_witness` with Progress query instructions. Design rules now live in the MCP knowledge layer — query via `schema_query` action='get_guard_design_patterns', applied via `project_operation.evaluate_project`. Query available Guard instructions via `wowok_buildin_info`.
+> **Guard construction**: Cross-Machine Guards use `convert_witness` with Progress query instructions. Design rules now live in the MCP knowledge layer — query via `schema_query` action='get_guard_design_patterns', applied via `goal_operation` action='aggregate_risks'. Query available Guard instructions via `wowok_buildin_info`.
 
 ### Dual-Signature Consensus
 
@@ -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) |
 
-A complete R-M1-11-compliant rental topology is auto-generated by `project_operation.create_project` with `project_industry='rental'`.
+A complete R-M1-11-compliant rental topology ships as the `rental` industry mode's default Machine shape — query `industry_pack_operation` action='list_modes' for the per-industry defaults.
 
 ### 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. Auto-enforced by MCP pre-publish checks and `project_operation.evaluate_project`.
+- [ ] **⚠ 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 `goal_operation` action='aggregate_risks'.
 - [ ] 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

@@ -72,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 field constraints: MCP `schema_query` action='get' name='contact'.
+**Lifecycle**: Contact is mutable (unlike Proof/Guard). IM mutations (`onchain_operations` contact with `ims: {op:'add'|'set'|'remove'|'clear', im:[...]}`) require permission index 453 (CONTACT_IM). No events emitted on IM mutations — poll `ims[]` field. If Contact is bound to `Permission.um`, clear that binding (permission op: `um: null`) BEFORE deleting the Contact (else dangling pointer). Full field constraints: MCP `schema_query` action='get' name='contact'.
 
 ---
 

package/wowok-onboard/SKILL.md

@@ -37,13 +37,13 @@ The following content has been pushed down to the MCP knowledge layer and is app
 
 | Content | Access via (MCP action) | Applied Via |
 |---------|--------------------------|-------------|
-| Scenario mode defaults (per-industry Permission/Machine/Guard/Allocator) | `project_operation` action='list_modes' / 'create_project' | Auto-applied when `project_industry` is passed to `create_project` |
-| Safety rules (immutability, confirmation, object reuse) | `schema_query` action='get_safety_rules' | Pre-publish checks + `project_operation.evaluate_project` |
-| Guard / Machine / Arbitration / Treasury design rules | `schema_query` action='get_guard_design_patterns' | `project_operation.evaluate_project` |
+| Scenario mode defaults (per-industry Permission/Machine/Guard/Allocator) | `industry_pack_operation` action='list_modes' / 'recommend_industry' | Referenced when recording the Goal (`goal_operation` action='create') and when building each object |
+| Safety rules (immutability, confirmation, object reuse) | `schema_query` action='get_safety_rules' | Pre-publish checks + `goal_operation` action='aggregate_risks' |
+| Guard / Machine / Arbitration / Treasury design rules | `schema_query` action='get_guard_design_patterns' | `goal_operation` action='aggregate_risks' |
 | Common mistakes (field/unit/workflow pitfalls) | `wowok_buildin_info` action='common mistakes' | Tool calls (proactive warnings) |
-| Deployment checklist (publish readiness) | `project_operation` action='evaluate_project' | deployment-scanner D-01..D-20 |
+| Deployment checklist (publish readiness) | `goal_operation` action='aggregate_risks' (planned_objects / planned_operations) | deployment-scanner D-01..D-20 |
 
-This Skill keeps the **overall onboarding flow**, the **dependency-aware build order**, and the **user-driving interaction rhythm** (see below). Pass the user's industry to `create_project` (via `project_industry` parameter) and the MCP layer auto-fills the scenario defaults.
+This Skill keeps the **overall onboarding flow**, the **dependency-aware build order**, and the **user-driving interaction rhythm** (see below). The user's intent is recorded as a **Goal** (`goal_operation` action='create'); industry/scenario defaults come from `industry_pack_operation` action='recommend_industry' / 'list_modes', and the plan pipeline is `goal_operation` action='analyze_intent' — actual on-chain objects are created via `onchain_operations` in dependency order.
 
 ---
 
@@ -110,7 +110,7 @@ Each round below lists: **Semantic meaning**, **Core elements to confirm**, **De
 - **Core elements to confirm**:
   - Account: **reuse an existing account** (name/address) or **create new** (default name).
   - Network: **testnet first** (recommended) or **mainnet directly**.
-  - Industry mode: pass to `create_project` as `project_industry` — see the Industry Selection Guide below.
+  - Industry mode: resolved via `industry_pack_operation` action='recommend_industry' — see the Industry Selection Guide below.
 - **Default config**: new account with a default name; testnet network; industry mode auto-fills scenario defaults (Machine shape, Guards, Allocator).
 - **Reuse / Customize / Discover**: Reuse an existing account (benefit: keeps objects under one identity) — or create new.
 - **Dependencies**: none (foundation).
@@ -145,7 +145,7 @@ Each round below lists: **Semantic meaning**, **Core elements to confirm**, **De
   - Business flow: node list + forward paths.
   - Permissions: per-forward `namedOperator` (`""`=OrderHolder / role name) or `permissionIndex`.
   - Acceptance: per-forward Guard (or inline) — what must be verified before the transition executes.
-- **Default config**: the industry mode's `machine_shape` + `guards` (query `project_operation` action='list_modes'). Disclose these defaults FIRST, then let the user accept or customize.
+- **Default config**: the industry mode's `machine_shape` + `guards` (query `industry_pack_operation` action='list_modes'). Disclose these defaults FIRST, then let the user accept or customize.
 - **Reuse / Customize / Discover**: Reuse an existing Machine template (`machineNode2file` export) or an existing Guard (`guard2file`). Customize: define your own nodes/forwards/guards. Discover: `machineNode2file` / `local_mark_list` for other projects' Machines/Guards.
 - **Dependencies**: Service draft (R3) + Permission (R2).
 - **R-M1-11 compliance**: Machine MUST use business-state nodes (e.g. `cancelled`, `returned`, `return_approved`), NOT dispute/refund terminal nodes (`refunded`, `deposit_refunded`, `disputed`, `arb`). Refund routes via Allocator; dispute routes via Arbitration.
@@ -214,7 +214,7 @@ Each round below lists: **Semantic meaning**, **Core elements to confirm**, **De
 - **Core elements to confirm** (each optional, each with default disclosure + reuse/customize/discover):
   - Reward (discounts/loyalty).
   - Supply-chain promises / Repository.
-  - Audit: `evaluate_project` (risk) — fix ALL CRITICAL findings.
+  - Audit: `goal_operation` action='aggregate_risks' — fix ALL CRITICAL findings.
 - **Default config**: none required — these are opt-in. The audit itself is mandatory.
 - **Reuse / Customize / Discover**: each optional component can be created or discovered.
 - **Dependencies**: R1–R9.
@@ -241,13 +241,13 @@ Each round below lists: **Semantic meaning**, **Core elements to confirm**, **De
 
 ## Industry Selection Guide
 
-When the user describes their business (R1), query the authoritative industry list via `project_operation` action='list_modes' — 8 entries: `freelance` / `rental` / `education` / `travel` / `subscription` / `retail` / `retail_d2c` / `general`. If unsure which fits, call `project_operation` action='recommend_industry' with the business description. Pass the chosen `project_industry` to `create_project` — MCP auto-fills the scenario defaults (Machine shape, Guards, Allocator). Mid-onboarding iteration: `derive_user_mode` / `evolve_user_mode`.
+When the user describes their business (R1), query the authoritative industry list via `industry_pack_operation` action='list_modes' — 8 entries: `freelance` / `rental` / `education` / `travel` / `subscription` / `retail` / `retail_d2c` / `general`. If unsure which fits, call `industry_pack_operation` action='recommend_industry' with the business description. Reference the chosen mode when recording the Goal (`goal_operation` action='create') and when building the Service — its defaults (Machine shape, Guards, Allocator) inform each round's config disclosure. Mid-onboarding iteration: `industry_pack_operation` action='derive_user_mode' / 'evolve_user_mode'.
 
 ---
 
 ## Deployment Checklist
 
-Before declaring onboarding complete, run `project_operation` action='evaluate_project' (risk) — MCP auto-checks machine binding, order_allocators, buy_guard, arbitration isolation, R-M1-11 compliance, and publish readiness (deployment-scanner D-01..D-20). Fix ALL CRITICAL findings, then verify the remaining hard gates via `query_toolkit` (onchain_objects). The authoritative checklist is served by MCP — do not re-derive it here.
+Before declaring onboarding complete, run `goal_operation` action='aggregate_risks' — MCP auto-checks machine binding, order_allocators, buy_guard, arbitration isolation, R-M1-11 compliance, and publish readiness (deployment-scanner D-01..D-20) against your planned objects/operations. Fix ALL CRITICAL findings, then verify the remaining hard gates via `query_toolkit` (onchain_objects). The authoritative checklist is served by MCP — do not re-derive it here.
 
 ---
 

package/wowok-order/SKILL.md

@@ -147,7 +147,7 @@ Query `onchain_objects` for E1 `um` ID.
 
 ### E9 — Chain Reputation
 
-Sentiment: `query_toolkit` → `onchain_table_item_entity_linker` for provider; compute likes/dislikes from `votes[]`. Orders: batch query `votes[].address` via `onchain_objects` (50/batch, max 200), filter `service` match; aggregate dispute rate (`dispute ≠ []` / total) + repeat-buyer ratio. Dispute rate >10% → ⚠️.
+Sentiment: `query_toolkit` → `onchain_table_item_entity_linker` for the provider address; compute likes/dislikes/favor from `votes[]` (each vote: `{ who, like, dislike, favor, time }`). Orders: `query_toolkit` → `onchain_table_item_object_linker_tx` with the Service address → `items[].who` = recent Orders binding to it (tx reverse index 0xaaf, FIFO window); batch query those via `onchain_objects` (50/batch, max 200); aggregate dispute rate (`dispute ≠ []` / total) + repeat-buyer ratio. Dispute rate >10% → ⚠️.
 
 ### E10 — Privacy Information Matching (LocalInfo reuse)