@wowok/skills 1.2.2 → 1.2.4

package/wowok-onboard/APPENDIX.md

@@ -9,6 +9,20 @@
 
 Every round follows the same shape: state the goal, ask the key question(s), execute the MCP calls, verify success criteria, persist checkpoint, fall back on failure.
 
+> **Tool Call Convention**: All tool references in this document (e.g., `onchain_operations`, `query_toolkit`, `account_operation`) are sub-tools invoked via the single unified `wowok` tool. Translate every reference to `wowok({ tool: "<sub-tool-name>", data: {<params>} })`. See [wowok-tools](../wowok-tools/SKILL.md) for the full interface.
+
+## Project-Based Deployment Integration
+
+The onboarding flow is integrated with the MCP project-based 5-stage deployment pipeline. Each stage gates progression to the next, with `project_operation` action calls providing deterministic validation:
+
+- **Stage 1 (Project Naming)** → R1-R2 — establish `project` namespace and `version` for all subsequent calls
+- **Stage 2 (Business Puzzle)** → R2 calls `project_operation` → `action: "analyze_intent"` to obtain the Object Dependency Graph (ODG), missing field list (puzzles), and `next_step` guidance that drives R3-R8 field completion
+- **Stage 3 (Risk Calibration)** → after R8 checkpoint, calls `project_operation` → `action: "aggregate_risks"` to evaluate risk across all puzzles; CRITICAL risks block progression
+- **Stage 4 (Deployment Doc)** → once risks pass, calls `project_operation` → `action: "generate_deployment_doc"` to produce the deployment document; D-errors block progression to R9
+- **Stage 5 (Substep Trace)** → R9-R10 calls `project_operation` → `action: "trace_substeps"` to validate substep linkage integrity (D-10 check) before execution via `onchain_operations`
+
+All `project_operation` calls return a `can_proceed` boolean and a `next_action` hint. The onboarding AI MUST honor the gate semantics: stop on `can_proceed: false`, fix the reported issues, and only proceed when `can_proceed: true`.
+
 ### R1: Welcome + Account Setup
 
 **AI Goal**: Confirm the user is new (or resuming), establish the working account, fund it via faucet if empty.
@@ -28,7 +42,7 @@ Every round follows the same shape: state the goal, ask the key question(s), exe
 
 **Fallback**: Faucet fails → instruct user to wait 60s and retry, or fund via `transfer` from another account they own. Account name collision → append `_v1`, `_v2` per wowok-safety §1.1.
 
-**Checkpoint**: Persist `{ round: R1, account: <name>, balance: <n> }` via `local_info_operation`.
+**Checkpoint**: Persist `{ round: R1, account: <name>, balance: <n>, project: <project_name>, version: <version> }` via `local_info_operation`. The `project` and `version` fields establish the Stage 1 Project Naming namespace and MUST be carried forward in every subsequent `project_operation` call (Stage 2-5) and referenced in checkpoints R2-R10.
 
 ---
 
@@ -42,6 +56,7 @@ Every round follows the same shape: state the goal, ask the key question(s), exe
 - Will you need to ship physical goods?
 
 **Tool Calls**:
+0. `project_operation` → `action: "analyze_intent"` with `project`, `version`, `user_intent`, `industry` — 获取 ODG + 缺失字段清单 + 下一步建议。MCP 返回的 puzzles 和 next_step 指导后续 R3-R8 的字段补全。
 1. Internally classify the user's answers into `traits` (`has_logistics`, `communication_heavy`, `pure_digital`, `long_cycle`, `deposit_required`, `multi_tier_allocation`).
 2. Match to a mode via [wowok-scenario](../wowok-scenario/SKILL.md) §Mode Selection Logic:
    - freelance (Phase 1) — pure digital, no deposit, milestone allocation
@@ -73,7 +88,7 @@ Every round follows the same shape: state the goal, ask the key question(s), exe
 1. `onchain_operations` → `operation_type: "service"` with:
    - `data.name`, `data.type_parameter`, `data.description`
    - `data.permission` left empty for now (Permission comes in R4) OR pass a Permission object shape that auto-creates (wowok-safety §1.1 — SDK auto-creates a Permission if object shape passed)
-   - `publish: false` (mandatory — Service stays draft)
+   - `publish: false` (mandatory — **DRAFT** creation, Service stays draft until R10 publish; this is a deliberate two-phase pattern: draft in R3-R8 allows iterative MODIFY, then irreversible publish in R10)
    - `env.account` = R1 account
 2. (Optional, physical goods) `wip_file` → `generate` to produce WIP file URL + hash for product metadata
 3. `local_mark_operation` → tag the new Service with a friendly name (e.g., `freelance_logo_v1`)
@@ -204,6 +219,18 @@ Every round follows the same shape: state the goal, ask the key question(s), exe
 
 **Checkpoint**: Persist `{ round: R8, allocators: [{name, id, trigger_guard}], refund_path_covered: true }`.
 
+**Stage 3 Gate: Risk Calibration**
+After R8 checkpoint, call `project_operation` → `action: "aggregate_risks"` with `project`, `version`, `puzzles` (from R2's analyze_intent).
+- If `can_proceed: false` (CRITICAL risks) → fix risks before proceeding
+- If `can_proceed: true` → proceed to Stage 4
+- The `next_action` field tells you the next step
+
+**Stage 4 Gate: Deployment Document**
+After risks pass, call `project_operation` → `action: "generate_deployment_doc"` with `project`, `version`, `business_intent`, `objects`, `edges`, `steps`, `risk_status`, `risk_critical_count`, `risk_high_count`.
+- If `can_proceed: false` (D-errors) → fix doc errors
+- If `can_proceed: true` → proceed to R9 (deployment execution)
+- The `next_action` field tells you the next step
+
 ---
 
 ### R9: Test Order (Dry Run)
@@ -215,6 +242,9 @@ Every round follows the same shape: state the goal, ask the key question(s), exe
 - Confirm test parameters: test amount, test deliverable hash.
 
 **Tool Calls**:
+0. `project_operation` → `action: "trace_substeps"` with `project`, `version`, `network`, `substeps` (from Stage 4 deployment doc) — 验证子步骤衔接完整性 (D-10 check).
+   - If `can_proceed: false` → fix substep issues
+   - If `can_proceed: true` → execute substeps via onchain_operations
 1. `account_operation` → `gen` (second account, the "buyer")
 2. `account_operation` → `faucet` for the buyer
 3. `onchain_operations` → `operation_type: "order"` CREATE — buyer places order on the Service draft
@@ -244,9 +274,9 @@ Every round follows the same shape: state the goal, ask the key question(s), exe
    - `machineNode2file` → export Machine, verify topology
    - `guard2file` → export all Guards, verify logic
    - `query_toolkit` → `onchain_objects` → re-check Permission, Service, Machine, Progress, Guards, Allocation all exist and are correctly bound
-2. `onchain_operations` → `operation_type: "machine"` with `publish: true` — Machine locked
+2. **Publish Machine FIRST** — `onchain_operations` → `operation_type: "machine"` with `publish: true` (PUBLISH, irreversible). Machine locked. This MUST happen before Service publish because the Service depends on a published Machine.
 3. `onchain_operations` → `operation_type: "service"` MODIFY to bind `data.machine = "<published_machine_id>"`
-4. `onchain_operations` → `operation_type: "service"` with `publish: true` — Service locked
+4. **Publish Service SECOND** — `onchain_operations` → `operation_type: "service"` with `publish: true` (PUBLISH, irreversible). Service locked. Order is mandatory: **Machine first, then Service** (Service depends on Machine).
 5. (Optional) `onchain_operations` → `operation_type: "service"` MODIFY to add `compensation_fund_add` and `setting_locked_time_add`
 6. Post-publish verification:
    - `query_toolkit` → `onchain_objects` (Service) → confirm `bPublished: true`, `machine` field is locked, `order_allocators` is locked

package/wowok-order/SKILL.md

@@ -245,7 +245,7 @@ Clarify via Messenger: deliverables (E2 WIP), timeline (E3 nodes), refund/cancel
 
 ## Phase 3: Order Creation
 
-Schema: `schema_query({ action: "get", name: "onchain_operations_service" })`. Safety: [wowok-safety](../wowok-safety/SKILL.md).
+Schema: `wowok({ tool: "schema_query", data: { action: "get", name: "onchain_operations_service" } })`. Safety: [wowok-safety](../wowok-safety/SKILL.md).
 
 **Not in schema**:
 - Excess `buy.total_pay` auto-refunded. Agents cannot withdraw.
@@ -257,7 +257,7 @@ Post-creation: notify via Messenger with order ID.
 
 ## Phase 4: Order Operations
 
-Schema: `schema_query({ action: "get", name: "onchain_operations_order" })`.
+Schema: `wowok({ tool: "schema_query", data: { action: "get", name: "onchain_operations_order" } })`.
 
 ### Progress Advancement
 
@@ -277,7 +277,7 @@ Present all three dimensions. Never just the operation name.
 
 ## Phase 5: Arbitration
 
-Schema: `schema_query({ action: "get", name: "onchain_operations_arbitration" })`. Process: [wowok-arbitrator](../wowok-arbitrator/SKILL.md).
+Schema: `wowok({ tool: "schema_query", data: { action: "get", name: "onchain_operations_arbitration" } })`. Process: [wowok-arbitrator](../wowok-arbitrator/SKILL.md).
 
 Flow: `arbitration.dispute` → WTS evidence → Messenger → `order.arb_confirm` → voting → (`order.arb_objection`) → `order.arb_claim_compensation`.
 
@@ -410,7 +410,7 @@ Toggle example: `config_operation` → `action: "toggle"`, `service: "order_moni
 
 ## Quick Reference
 
-Schemas: `schema_query({ action: "get", name: "<name>" })` for `onchain_operations_service`, `onchain_operations_order`, `onchain_operations_arbitration`, `messenger_operation`, `query_toolkit`, `onchain_table_data`, `wip_file`.
+Schemas: `wowok({ tool: "schema_query", data: { action: "get", name: "<name>" } })` for `onchain_operations_service`, `onchain_operations_order`, `onchain_operations_arbitration`, `messenger_operation`, `query_toolkit`, `onchain_table_data`, `wip_file`.
 
 ### Phase Dependency
 

package/wowok-planner/APPENDIX.md

@@ -9,6 +9,20 @@
 
 Each round follows: state the goal, ask the minimum questions needed, gather inputs (LLM translation only when free text is ambiguous), update the ODG in memory, persist checkpoint, advance.
 
+> **Tool Call Convention**: All tool references in this document (e.g., `project_operation`, `onchain_operations`) are sub-tools invoked via the single unified `wowok` tool. Translate every reference to `wowok({ tool: "<sub-tool-name>", data: {<params>} })`. See [wowok-tools](../wowok-tools/SKILL.md) for the full interface.
+
+## Project-Based Deployment Integration
+
+The planner flow integrates with the MCP project-based deployment pipeline (5 stages). Each stage maps to specific R rounds:
+
+- **Stage 1 (Project Naming)** → R1 — establish the `project` and `version` identifiers used by all subsequent `project_operation` calls.
+- **Stage 2 (Business Puzzle)** → R1 — call `project_operation` → `action: "analyze_intent"` to replace internal Scenario Registry matching; the MCP side performs Scenario Registry matching + ODG skeleton generation + puzzle initialization in one call.
+- **Stage 3 (Risk Calibration)** → R9 — call `project_operation` → `action: "aggregate_risks"` to perform L1/L2/L3 risk assessment on the assembled puzzles.
+- **Stage 4 (Deployment Doc)** → after R9 — call `project_operation` → `action: "generate_deployment_doc"` to produce the markdown deployment doc with D-01..D-18 scanner checks.
+- **Stage 5 (Substep Trace)** → R10 — call `project_operation` → `action: "trace_substeps"` to verify substep continuity before handoff to the Harness.
+
+All `project_operation` calls use the unified `project` + `version` keys established in R1. The `next_action` field returned by each call drives the stage transition.
+
 ### R1: Intent Capture
 
 **AI Goal**: Capture the user's natural-language intent and classify it against the Scenario Registry.
@@ -20,7 +34,7 @@ Each round follows: state the goal, ask the minimum questions needed, gather inp
 
 **Tool Calls**:
 1. `query_toolkit` → `local_names` — check for any prior planning checkpoint to offer a resume path.
-2. (Internal) Match intent against the Scenario Registry §Intent Keywords. If two candidates score equally, ask one disambiguating question (LLM-translated to a typed choice).
+2. `project_operation` → `action: "analyze_intent"` with `project`, `version`, `user_intent`, `industry` (if known) — MCP 内部完成 Scenario Registry 匹配 + ODG 生成 + puzzle 初始化. Returns `puzzles`, `next_step`, `next_action`. If `next_action: "aggregate_risks"` indicates puzzles are complete, you can proceed directly to Stage 3.
 3. If no candidate matches → select `general` scenario (no failure — the fallback is intentional).
 
 **Success Criteria**: A `scenario` field is set on the ODG (one of `freelance`, `rental`, `digital_goods`, `travel_package`, `general`). The scenario's ODG template is loaded as the working skeleton.
@@ -193,6 +207,9 @@ Each round follows: state the goal, ask the minimum questions needed, gather inp
 - Confirm the fund-risk paths (deposit escrow, refund Allocator)?
 
 **Tool Calls**:
+0. `project_operation` → `action: "aggregate_risks"` with `project`, `version`, `puzzles` (from R1's analyze_intent) — MCP 内部完成 L1/L2/L3 风险评估. Returns `findings`, `can_proceed`, `next_action`.
+   - If `can_proceed: false` (CRITICAL risks) → record in ODG risk_assessment, block execution
+   - If `can_proceed: true` → proceed to Stage 4
 1. (Internal) Compute `reversible` per object (see §Reversibility Matrix).
 2. (Internal) Estimate `estimated_time` per phase from scenario template defaults (Tier 1 ≈ 10 min, Tier 2 ≈ 30 min, Tier 3 ≈ 60 min, excluding human response time).
 3. (Internal) List every object whose creation or publish is irreversible; require explicit per-item acknowledgment.
@@ -203,6 +220,12 @@ Each round follows: state the goal, ask the minimum questions needed, gather inp
 
 **Checkpoint**: Persist `{ round: R9, risk_assessment, acknowledgments: [...] }`.
 
+**Stage 4 Gate: Deployment Document**
+After risks pass, call `project_operation` → `action: "generate_deployment_doc"` with `project`, `version`, `business_intent`, `objects`, `edges`, `steps`, `risk_status`, `risk_critical_count`, `risk_high_count`.
+- Returns markdown deployment doc + D-01..D-18 scanner checks
+- If `can_proceed: false` (D-errors) → fix doc errors
+- If `can_proceed: true` → proceed to R10
+
 ---
 
 ### R10: Execution Handoff
@@ -214,6 +237,9 @@ Each round follows: state the goal, ask the minimum questions needed, gather inp
 - Which execution delegate should run the phases? (default: wowok-onboard for a fresh build; wowok-provider for extensions)
 
 **Tool Calls**:
+0. `project_operation` → `action: "trace_substeps"` with `project`, `version`, `network`, `substeps` (from Stage 4 deployment doc) — 验证子步骤衔接完整性.
+   - If `can_proceed: false` → fix substep issues before handoff
+   - If `can_proceed: true` → handoff to Harness/wowok-onboard for execution
 1. (Internal) Emit the Harness handoff packet (see §Handoff Protocol).
 2. `local_info_operation` → persist the final ODG under a stable `task_id` key so the Harness can read it.
 3. (Internal) Register per-phase verification hooks: after each phase, the Harness must re-query on-chain state and reconcile with the ODG before advancing.

package/wowok-provider/APPENDIX.md

@@ -9,6 +9,18 @@
 
 A 10-round dialogue for the merchant operations journey: from "I want to set up a service" through "published, live, and accepting orders". This dialogue assumes the merchant has an account (per [wowok-onboard](../wowok-onboard/SKILL.md) R1) and may have a partial configuration. Each round maps to one R-item in the §PRE-FLIGHT checklist or one STEP in the §Service Build Lifecycle. The §Anti-Fabrication Rules are non-negotiable throughout — the AI never invents products, prices, workflow, or fund splits.
 
+> **Tool Call Convention**: All tool references in this document (e.g., `onchain_operations`, `query_toolkit`, `messenger_operation`) are sub-tools invoked via the single unified `wowok` tool. Translate every reference to `wowok({ tool: "<sub-tool-name>", data: {<params>} })`. See [wowok-tools](../wowok-tools/SKILL.md) for the full interface.
+
+## Project-Based Deployment Integration
+
+The provider flow integrates with the MCP project-based deployment pipeline (5 stages). The relevant stages for the operations journey are:
+
+- **Stage 3 (Risk Calibration)** → R5 — call `project_operation` → `action: "aggregate_risks"` to replace the manual pre-publish audit checklist with an MCP-driven risk assessment.
+- **Stage 4 (Deployment Doc)** → after R5 — call `project_operation` → `action: "generate_deployment_doc"` to produce the markdown deployment doc with D-01..D-18 scanner checks before publish.
+- **Stage 5 (Substep Trace)** → R6 — call `project_operation` → `action: "trace_substeps"` to verify publish substep continuity before the irreversible publish sequence.
+
+All `project_operation` calls use the unified `project` + `version` keys from the prior planning phase (wowok-planner R1). The `next_action` field returned by each call drives the stage transition.
+
 ### R1: PRE-FLIGHT Checklist Presentation
 
 **AI Goal**: Present the R1-R7 checklist (plus conditional C1-C3) and collect the user's intent for each item: REUSE existing, CREATE new, or PENDING. Do NOT proceed to any on-chain action until all items are confirmed.
@@ -103,6 +115,10 @@ A 10-round dialogue for the merchant operations journey: from "I want to set up
 - Confirm: Allocator splits match your stated revenue model?
 
 **Tool Calls**:
+0. `project_operation` → `action: "aggregate_risks"` with `project`, `version`, `puzzles` (from prior planning) — MCP 内部完成风险评估, replacing the manual audit checklist.
+   - If `can_proceed: false` (CRITICAL risks) → block publish, fix risks
+   - If `can_proceed: true` → proceed to deployment doc generation
+   - The `next_action` field guides the next step
 1. `guard2file` → export all Guards, present for review.
 2. `machineNode2file` → export the Machine, present for review.
 3. `query_toolkit` → `onchain_objects` for the Service — re-check `machine`, `order_allocators`, `buy_guard`, `permission` all bound correctly.
@@ -114,6 +130,12 @@ A 10-round dialogue for the merchant operations journey: from "I want to set up
 
 **Checkpoint**: Persist `{ round: R5, audit_pass: true, user_confirmed: true, guard_exports: [...], machine_export: <path> }`.
 
+**Stage 4 Gate: Deployment Document**
+After audit passes, call `project_operation` → `action: "generate_deployment_doc"` with `project`, `version`, `business_intent`, `objects`, `edges`, `steps`, `risk_status`, `risk_critical_count`, `risk_high_count`.
+- Returns markdown deployment doc + D-01..D-18 scanner checks
+- If `can_proceed: false` (D-errors) → fix doc errors before publish
+- If `can_proceed: true` → proceed to R6 (Publish)
+
 ### R6: Publish (Machine First, Then Service)
 
 **AI Goal**: Execute STEP 4: publish the Machine (irreversible), bind it to the Service, then publish the Service (irreversible). Both `machine`/`order_allocators` fields become immutable on Service publish.
@@ -123,12 +145,20 @@ A 10-round dialogue for the merchant operations journey: from "I want to set up
 - Confirm the operating account has sufficient gas.
 
 **Tool Calls**:
+0. `project_operation` → `action: "trace_substeps"` with `project`, `version`, `network` (testnet first), `substeps` (from Stage 4 deployment doc) — 验证发布子步骤衔接完整性.
+   - If `can_proceed: false` → fix substep issues before publish
+   - If `can_proceed: true` → proceed with publish sequence (Machine first, then Service)
 1. `onchain_operations` → `operation_type: "machine"` with `publish: true` — Machine locked.
 2. `onchain_operations` → `operation_type: "service"` MODIFY to bind `data.machine = "<published_machine_id>"`.
 3. `onchain_operations` → `operation_type: "service"` with `publish: true` — Service `machine` and `order_allocators` locked.
 4. Post-publish verification: `query_toolkit` → `onchain_objects` for the Service — confirm `bPublished: true`, `machine` field locked, `order_allocators` locked.
 5. `onchain_events` → confirm Publish event fired.
 
+**Publish Order (Irreversibility Notes)**:
+- Machine publish is irreversible (immutable) — nodes, forwards, guards, thresholds all become immutable.
+- Service publish is irreversible (immutable) — `machine` and `order_allocators` fields become locked.
+- **Order**: publish Machine FIRST, then publish Service. Service publish requires the Machine to be published; binding `data.machine` to an unpublished Machine will revert.
+
 **Success Criteria**: Both Machine and Service `bPublished: true`. Service `machine` and `order_allocators` fields are immutable. Publish event recorded.
 
 **Fallback**: Pre-publish audit fails → return to R5 and fix; do NOT publish. Publish transaction fails (gas) → re-faucet, retry. Service publish fails with "machine not published" → confirm Machine publish succeeded first (use `env.no_cache: true`). Post-publish immutability check fails (rare) → escalate; protocol-level invariant violated.
@@ -292,7 +322,7 @@ Should I add a Compensation Fund?
 
 ```
 Merchant daily check-in:
-├── New orders? ──→ query_toolkit.onchain_events (NewOrderEvent) → fulfill per Machine workflow
+├── New orders? ──→ `wowok({ tool: "query_toolkit", data: { query_type: "onchain_events", ... } })` (NewOrderEvent) → fulfill per Machine workflow
 ├── Orders stuck at a node? ──→ query Progress → check Forward operators / Guard submissions → advance or contact customer
 ├── Customer messages? ──→ messenger_operation.watch_conversations (unreadOnly: true) → respond
 ├── Funds to claim? ──→ allocation.alloc_by_guard (anyone can trigger; verify fund flow)

package/wowok-provider/SKILL.md

@@ -91,20 +91,22 @@ STEP 0: Present checklist R1-R7 to user
 Once R1-R7 confirmed, execute in strict order. All operations use R1 (Account) as `env.account`.
 
 ```
+All Tool: references below are sub-tools invoked via wowok({ tool: "<name>", data: { operation_type: "<type>", ... } })
+
 STEP 1: Foundation
 ├── Permission — REUSE existing (strongly recommended)
-│     Tool: onchain_operations (permission) | Fields: name, type_parameter
+│     Tool: "onchain_operations" (permission) | Fields: name, type_parameter
 ├── Service (unpublished) — CREATE new
-│     Tool: onchain_operations (service) | Fields: name, type_parameter, permission
+│     Tool: "onchain_operations" (service) | Fields: name, type_parameter, permission
 └── Machine (unpublished) — CREATE new or REUSE template
-      Tool: onchain_operations (machine) | Fields: nodes, pairs, forwards
-      Discovery: query_toolkit (account_list, local_mark_list, onchain_objects)
-      Template: machineNode2file (export existing for editing)
+      Tool: "onchain_operations" (machine) | Fields: nodes, pairs, forwards
+      Discovery: "query_toolkit" (account_list, local_mark_list, onchain_objects)
+      Template: "machineNode2file" (export existing for editing)
 
 STEP 2: Trust Layer
 └── Guards — CREATE new or REUSE existing
-      Tool: onchain_operations (guard) | Fields: logic, instructions
-      Template: guard2file (export existing for editing)
+      Tool: "onchain_operations" (guard) | Fields: logic, instructions
+      Template: "guard2file" (export existing for editing)
       ⚠️ Design your Guard tables based on how the target object reads data:
          - buy_guard → pass/fail only, no data extraction
          - Allocator guard → pass/fail only
@@ -114,22 +116,22 @@ STEP 2: Trust Layer
 
 STEP 3: Business Logic (MODIFY)
 ├── Machine — bind Guards to forwards
-│     Tool: onchain_operations (machine)
+│     Tool: "onchain_operations" (machine)
 ├── Service — set Allocators
-│     Tool: onchain_operations (service) | Fields: order_allocators
+│     Tool: "onchain_operations" (service) | Fields: order_allocators
 ├── Arbitrations (optional) — REUSE existing Arb services
-│     Tool: onchain_operations (service) | Fields: arbitrations.list
+│     Tool: "onchain_operations" (service) | Fields: arbitrations.list
 ├── Compensation Fund (optional): compensation_fund_add + setting_locked_time_add (default 30 days, configurable)
-│     Tool: onchain_operations (service)
+│     Tool: "onchain_operations" (service)
 └── Reward (optional) — incentive pools
 
 STEP 4: Publication
 ├── Publish Machine → IMMUTABLE
-│     Tool: onchain_operations (machine) | publish: true
+│     Tool: "onchain_operations" (machine) | publish: true
 ├── Bind Machine to Service
-│     Tool: onchain_operations (service) | machine: "<machine_id>"
+│     Tool: "onchain_operations" (service) | machine: "<machine_id>"
 └── Publish Service → machine/allocators LOCKED
-      Tool: onchain_operations (service) | publish: true
+      Tool: "onchain_operations" (service) | publish: true
 
       ⚠️ Pre-Publish Verification:
       1. Re-check PRE-FLIGHT: all R1-R7 still confirmed?
@@ -233,7 +235,7 @@ Each `sharing[].who` field determines where funds go. Choose the correct type ba
 After the Progress reaches a terminal state, the fund allocation is NOT automatic — it must be triggered explicitly. **Anyone can call this operation**; the caller does not need to be the merchant or customer. The Guard verification determines which allocator's rules apply.
 
 ```
-Tool: onchain_operations (allocation)
+Tool: wowok({ tool: "onchain_operations", data: { operation_type: "allocation", ... } })
 Operation: alloc_by_guard
 Required submission: Order ID (matching the Guard's b_submission identifier)
 ```
@@ -249,8 +251,8 @@ Required submission: Order ID (matching the Guard's b_submission identifier)
 Immutable product commitment for arbitration evidence.
 
 ```
-Create:  wip_file → generate → markdown_text + images → outputPath
-Attach: onchain_operations (service) → sales.sales[{
+Create:  wowok({ tool: "wip_file", data: { op: "generate", ... } }) → markdown_text + images → outputPath
+Attach: wowok({ tool: "onchain_operations", data: { operation_type: "service", ... } }) → sales.sales[{
           name, price, stock, wip: "<URL>", wip_hash: "" (auto)
         }]
 ```
@@ -285,7 +287,7 @@ Attach: onchain_operations (service) → sales.sales[{
 | Messenger | `messenger_operation` |
 | Query | `query_toolkit` |
 
-**Export**: `machineNode2file`, `guard2file` | **Query Schema**: `schema_query({ action: "get", name: "<name>" })`
+**Export**: `machineNode2file`, `guard2file` | **Query Schema**: `wowok({ tool: "schema_query", data: { action: "get", name: "<name>" } })`
 
 ---
 

package/wowok-safety/APPENDIX.md

@@ -9,6 +9,8 @@
 
 A guided 10-round dialogue for the safety verification journey — runs before ANY on-chain write operation. Each round has a specific AI Goal, Key Questions, Tool Calls, Success Criteria, Fallback, and Checkpoint. Checkpoints persist via `local_info_operation` so the verification can resume after interruption.
 
+> **Tool Call Convention**: All tool references in this document are sub-tools invoked via the single unified `wowok` tool. Translate every reference to `wowok({ tool: "<sub-tool-name>", data: {<params>} })`. See [wowok-tools](../wowok-tools/SKILL.md) for the full interface.
+
 > **Trigger**: This dialogue is automatically invoked when the user requests an on-chain write operation (transfer, publish, create, modify, etc.). It is the safety gate that all writes must pass through.
 
 ### R1 — Operation Intent Capture
@@ -309,24 +311,26 @@ What level of confirmation does this operation need?
 ### D3: LOCAL vs ON-CHAIN vs QUERY
 
 ```
+All sub-tools below are accessed via: wowok({ tool: "<sub-tool-name>", data: {<params>} })
+
 Classifying the operation:
 ├── LOCAL ONLY (no gas, no confirmation)
-│   ├── account_operation (gen, get, faucet, messenger, etc.)
-│   ├── local_mark_operation
-│   └── local_info_operation
+│   ├── tool: "account_operation" (gen, get, faucet, messenger, etc.)
+│   ├── tool: "local_mark_operation"
+│   └── tool: "local_info_operation"
 ├── ON-CHAIN (gas required, confirmation required)
-│   ├── onchain_operations (all 16 operation_types)
-│   ├── messenger_operation (some ops — sign, proof_message)
-│   └── wip_file (sign)
+│   ├── tool: "onchain_operations" (all 16 operation_types)
+│   ├── tool: "messenger_operation" (some ops — sign, proof_message)
+│   └── tool: "wip_file" (sign)
 ├── QUERY (read-only, no gas, no confirmation)
-│   ├── query_toolkit
-│   ├── onchain_table_data
-│   ├── onchain_events
-│   ├── guard2file
-│   ├── machineNode2file
-│   └── wowok_buildin_info
+│   ├── tool: "query_toolkit"
+│   ├── tool: "onchain_table_data"
+│   ├── tool: "onchain_events"
+│   ├── tool: "guard2file"
+│   ├── tool: "machineNode2file"
+│   └── tool: "wowok_buildin_info"
 └── ENCRYPTED (local encryption, no gas)
-    └── messenger_operation (watch/send messages — local ops)
+    └── tool: "messenger_operation" (watch/send messages — local ops)
 ```
 
 ### D4: Publish Readiness Check

package/wowok-safety/SKILL.md

@@ -262,7 +262,7 @@ For complex objects with many fields (Service, Machine), use **incremental build
 | Guard instructions | `wowok_buildin_info` with `info: "guard instructions"` |
 | Value types | `wowok_buildin_info` with `info: "value types"` |
 
-**Query Schema**: `schema_query({ action: "get", name: "<schema_name>" })`
+**Query Schema**: `wowok({ tool: "schema_query", data: { action: "get", name: "<schema_name>" } })`
 
 **Related Skills**: [wowok-tools](../wowok-tools/SKILL.md) | [wowok-guard](../wowok-guard/SKILL.md) | [wowok-machine](../wowok-machine/SKILL.md) | [wowok-order](../wowok-order/SKILL.md) | [wowok-provider](../wowok-provider/SKILL.md) | [wowok-arbitrator](../wowok-arbitrator/SKILL.md) | [wowok-messenger](../wowok-messenger/SKILL.md)