@wowok/skills 2.0.2 → 2.1.0

package/wowok-order/SKILL.md

@@ -14,38 +14,24 @@ 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) | **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`.
+> **Role**: Customer (Buyer/Order Holder)
+> **Guides**: [wowok-provider](../wowok-provider/SKILL.md) · [wowok-arbitrator](../wowok-arbitrator/SKILL.md) · [wowok-machine](../wowok-machine/SKILL.md) · [wowok-messenger](../wowok-messenger/SKILL.md)
+> Guard patterns / safety rules / tool references live in the MCP knowledge layer — query via `schema_query` (`get_guard_design_patterns`, `get_safety_rules`, `get_tool_reference`).
 
 ---
 
 ## Core Concepts (Design Invariants Not in Schema)
 
-### Object Relationships
-
-Purchase creates three objects: **Order** (fund escrow, you are `builder`), **Progress** (Machine node tracker), **Allocation** (fund distribution engine). Only `builder` withdraws funds. Agents may operate but never access funds.
-
-### The No-Bypass Rule
-
-A forward with `namedOperator === ""` signals "user-operable". **However**: if that forward also binds a Guard, passport verification is mandatory and **cannot be bypassed**. `order.next` fails without validated passport. This is a protocol invariant.
-
-### Weight Accumulation
-
-Each forward contributes `weight` toward a node's `threshold`. `weight ≥ threshold` → one operation suffices. Multi-forward nodes may require cumulative multi-party contributions. Parse the `machineNode2file` JSON output; never query node-by-node.
-
-### Allocation Triggers
-
-Allocation evaluates when Progress reaches **any** configured node (not just exit nodes). The winning Allocator is the first whose Guard returns `true`. Rules are immutable after Service publish — both parties see identical conditions.
+- **Objects**: Purchase creates **Order** (fund escrow, you are `builder`), **Progress** (Machine node tracker), **Allocation** (fund distribution). Only `builder` withdraws; agents operate but never access funds.
+- **No-Bypass Rule**: A forward with `namedOperator === ""` is "user-operable", but if it also binds a Guard, passport verification is mandatory and cannot be bypassed (`order.next` fails without validated passport).
+- **Weight Accumulation**: Each forward contributes `weight` toward a node's `threshold`; `weight ≥ threshold` → one operation suffices. Parse `machineNode2file` JSON; never query node-by-node.
+- **Allocation Triggers**: Allocation evaluates when Progress reaches **any** configured node (not just exit nodes). Winning Allocator = first whose Guard returns `true`. Rules immutable after publish.
 
 ---
 
 ## Phase 1: Pre-Purchase Due Diligence (MANDATORY GATE)
 
-> **⛔ Complete E1-E11 in order. User must explicitly confirm every item.**
-> **⚠️ = explain risk, wait for decision. 🔴 = strongly advise against purchase.**
-
----
+> **⛔ Complete E1-E11 in order; user must confirm every item.** **⚠️** = explain risk, wait. **🔴** = strongly advise against.
 
 ### E1 — Service Basic Status
 
@@ -55,52 +41,35 @@ Query `query_toolkit` → `onchain_objects` for `<service_name_or_id>`. Save: `b
 - `bPaused === true` → 🔴 **ABORT**
 - OK → E2
 
----
-
 ### E2 — Product & WIP Verification
 
-From E1 `sales[]`. Skip `suspension === true` items.
-
-**WIP Verification** (mandatory when `wip_hash` non-empty):
+From E1 `sales[]`; skip `suspension === true`. Verify WIP (mandatory when `wip_hash` non-empty): `wip_file` → `type: "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)
+- `wip_hash` empty → no on-chain commitment (weaker evidence)
 - Verification fails → 🔴 **WIP tampered after publish**
 - No `wip` URL → ⚠️ No product evidence
-- Verified → E3
-
----
 
 ### E3 — Machine Workflow Analysis (CORE)
 
-**Step 1**: `query_toolkit` → `onchain_objects` for `<machine_id>`. Fail if `bPublished === false` or `bPaused === true`.
-
-**Step 1b (entry-node forward check)**: In the exported Machine JSON, verify the entry node (`prev_node: ""`) has ≥1 forward. If empty, Progress will be permanently stuck at `current=""` — flag as 🔴 BLOCKER. (New Machines are schema-blocked from this, but legacy Machines may still have it.)
+1. `query_toolkit` → `onchain_objects` for `<machine_id>`; fail if `bPublished === false` or `bPaused === true`.
+2. Entry-node check: entry node (`prev_node: ""`) must have ≥1 forward, else Progress stuck at `current=""` → 🔴 BLOCKER.
+3. `machineNode2file` → export full Machine JSON (parse locally; see [wowok-machine](../wowok-machine/SKILL.md)).
 
-**Step 2**: `machineNode2file` → export the complete Machine JSON. Contains all nodes and forwards — parse locally, never node-by-node. Machine structure: see [wowok-machine](../wowok-machine/SKILL.md).
-
-**Step 3: Classify every forward**:
+**Classify every forward**:
 
 | `namedOperator` | `guard` | User Can Execute? | Operation Path |
 |-----------------|---------|-------------------|----------------|
-| `Some("")` | `None` | ✅ Independently | **`order.progress`** (uses `order.has_op_permission`) |
-| `Some("")` | `Some({...})` | ⚠️ Need Guard passport — **no bypass** | **`order.progress`** + Passport |
-| `None` | Any | ❌ Provider/permission-holder only | `progress.operate` (provider path) |
-| `Some("<other>")` | Any | ❌ Named operator required | `progress.operate` (named operator path) |
-
-> **⚠ CRITICAL ROUTING RULE**: When `namedOperator=""` (empty string = OrderHolder), you MUST use `order.progress` (NOT `progress.operate`). Direct `progress::next` will abort with "Permission denied" (code 5) because the Progress-level permission check does not recognize the OrderHolder short-circuit. The empty-string `namedOperator` is set automatically by `service::buy` when an Order is created — the customer (order.builder) becomes the operator for the `""` namespace. In ALL other cases (non-empty `namedOperator` or `permissionIndex`-only), use `progress.operate` on the Progress object directly.
+| `Some("")` | `None` | ✅ Independently | `order.progress` |
+| `Some("")` | `Some({...})` | ⚠️ Guard passport (no bypass) | `order.progress` + Passport |
+| `None` | Any | ❌ Provider/permission-holder | `progress.operate` |
+| `Some("<other>")` | Any | ❌ Named operator | `progress.operate` |
 
-**Step 4: Detect paths**:
-- Terminal nodes (no outgoing forwards) → order ends
-- Refund paths → lead to 100%→Order Allocator (cross-check E5)
-- Arbitration paths → lead to arbitration nodes
-- User-blocked paths → all forwards require `namedOperator ≠ ""`
+> **⚠ ROUTING RULE**: `namedOperator=""` (OrderHolder) → use `order.progress` (NOT `progress.operate`); `progress::next` aborts "Permission denied" (code 5) because Progress-level checks don't recognize the OrderHolder short-circuit. The `""` operator is set by `service::buy` (customer = operator). All other cases (non-empty `namedOperator` or `permissionIndex`) → `progress.operate`.
 
-**Risk Rules**:
+**Detect paths**: terminal (no outgoing) → order ends; refund → 100%→Order Allocator (E5); arbitration → arb nodes; user-blocked → all forwards `namedOperator ≠ ""`.
 
-| Signal | Level |
-|--------|-------|
+| Risk Signal | Level |
+|-------------|-------|
 | No user-operable path from critical node | 🔴 Stuck unless provider acts |
 | No refund path | 🔴 No fund recovery |
 | No arbitration path | 🔴 No recourse |
@@ -109,35 +78,21 @@ Use `wip_file` → `type: "verify"`, `wipFilePath: "<wip_url>"`, `hash_equal: "<
 
 > **🔴 "No refund" + "No arbitration" → strongly advise against purchase.**
 
----
-
 ### E4 — Guards Analysis
 
-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.
-
-**Step 2**: `guard2file` → export each unique Guard as JSON. Skip duplicates (same address = same Guard).
-
-**Step 3**: `wowok_buildin_info` → `info: "guard instructions"` for instruction reference.
-
-**Step 4**: For each exported Guard file, classify:
+Guard structure/instructions: `schema_query` action='get_guard_design_patterns' + action='get_guard_templates'. Steps: (1) collect unique Guard IDs from E3 `forward.guard.guard` + E1 `order_allocators` + `buy_guard`, dedupe; (2) `guard2file` export each; (3) `wowok_buildin_info` → `info: "guard instructions"`; (4) classify:
 
 | Level | Criteria | Action |
 |-------|----------|--------|
 | 🟢 Simple | Clear purpose, few conditions | Explain |
 | 🟡 Complex | Multi-layer, intent clear | Explain step-by-step |
-| 🔴 Ambiguous | Unclear logic or dependencies | **Warn. Never speculate. User must review file.** |
+| 🔴 Ambiguous | Unclear logic/dependencies | **Warn. Never speculate. User must review file.** |
 
 > **⛔ Never invent Guard logic. Prioritize Guards gating user-operable forwards and refund allocators.**
 
----
-
 ### E5 — Fund Allocation Rules
 
-From E1 `order_allocators.allocators[]`. For each Allocator: cross-reference Guard (E4) → trigger condition; map to Machine node (E3) → when it fires; present distribution outcome.
-
-**Risk Rules**:
+From E1 `order_allocators.allocators[]`: cross-ref Guard (E4) → trigger; map to Machine node (E3) → when fires; present outcome.
 
 | Check | Risk |
 |-------|------|
@@ -146,22 +101,16 @@ From E1 `order_allocators.allocators[]`. For each Allocator: cross-reference Gua
 | Triggers only on provider-only paths | ⚠️ Unilateral collection |
 | No allocators on user-operable paths | ⚠️ No financial control |
 
-> **Key safeguard**: 100%→Order Allocator on a user-operable forward.
-
----
+> **Safeguard**: 100%→Order Allocator on a user-operable forward.
 
 ### E6 — Arbitration Availability
 
-Batch query E1 `arbitrations[]` via `onchain_objects`. Arb process: [wowok-arbitrator](../wowok-arbitrator/SKILL.md).
-
-Also: `onchain_events` → `type: "ArbEvent"`, `limit: 20`, filter for these Arb IDs.
+Batch query E1 `arbitrations[]` via `onchain_objects` (process: [wowok-arbitrator](../wowok-arbitrator/SKILL.md)). Also `onchain_events` → `type: "ArbEvent"`, `limit: 20`, filter those Arb IDs.
 
 - `arbitrations[]` empty → 🔴 no recourse
 - Any Arb `bPaused === true` → 🔴 unavailable
 - High `fee` / closed `voting_guard` / no history → ⚠️
 
----
-
 ### E7 — Compensation Fund
 
 From E1: `compensation_fund`, `compensation_lock_duration`.
@@ -169,8 +118,6 @@ From E1: `compensation_fund`, `compensation_lock_duration`.
 - Balance < planned order amount → ⚠️ may not cover award
 - Lock near expiry → ⚠️ provider may withdraw
 
----
-
 ### E8 — Contact Channel
 
 Query `onchain_objects` for E1 `um` ID.
@@ -179,61 +126,48 @@ Query `onchain_objects` for E1 `um` ID.
 - `ims[]` empty → 🔴 **No Messenger**
 - Has active `ims[]` → E9
 
----
-
 ### E9 — Chain Reputation
 
-**Sentiment**: `query_toolkit` → `onchain_table_item_entity_linker` for provider address. Compute likes/dislikes ratio from `votes[]`.
-
-**Orders**: Batch query `votes[].address` via `onchain_objects` (50/batch, max 200). Filter Order-type objects where `service` matches. Aggregate dispute rate (`dispute ≠ []` / total) and repeat buyer ratio.
-
-- Dispute rate >10% → ⚠️
-
----
+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% → ⚠️.
 
-### E10 — Privacy Information Matching
+### E10 — Privacy Information Matching (LocalInfo reuse)
 
-From E1 `customer_required[]`. Check locally via `query_toolkit` → `local_info_list`. Match against local `name` fields.
+From E1 `customer_required[]` (e.g. `["name", "phone", "shipping_address"]`). Reuse locally-stored private info so the user never re-types it:
 
-> **⛔ Never send private info without explicit user confirmation per item.**
+1. `query_toolkit` → `query_type: "local_info_list"` to list stored private info (each `name` → `default` + optional `contents`).
+2. Match each `customer_required` name against a local `name` (case-insensitive):
+   - **Matched** → auto-fill the `default`; confirm "use this?" and offer any `contents` alternatives.
+   - **Missing** → ask the user for the value.
+3. **Save** any newly-provided value via `local_info_operation` → `add: { op: "add", data: [{ name, default }] }` (100% local, never on-chain).
 
-For matched: present value, ask "correct?" and "OK to send?". For missing: ask user to provide. Transmission: **Messenger only** (Phase 2), never on-chain.
-
----
+> **⛔ Never send private info without explicit user confirmation per item.** Transmission: **Messenger only** (Phase 2), never on-chain.
 
 ### 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>" } })`
+`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.
-
----
+- Compare candidates: `compare_with: ["<id2>", ...]` (1–9, same `depth: "preorder"`) → gains `comparison` block with per-metric bests, **NO overall ranking** (buyer decides).
+- Optional `preferences` / `user_metrics` reflect the buyer's priorities.
+- Fast pre-screen at E1: `depth: "evaluate"` (default); 🔴 `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; E11 `blocking_reminders` → resolve with user BEFORE proceeding.
-
-**Any ⚠️** → explain risk, wait for user decision. **All OK** → Phase 2.
+**Abort**: E1 `bPublished=false`/`bPaused=true`; E8 `um=null`; E3 no-refund + E6 no-arb → strongly advise ABORT; E4 ambiguous Guards → user must review; E11 `blocking_reminders` → resolve. **Any ⚠️** → explain + wait. **All OK** → Phase 2.
 
 ---
 
 ## Phase 2: Consensus Building
 
-Consensus foundation: immutable on-chain rules (Phase 1). Messenger: encrypted, self-verifiable supplement — clarifies, cannot override on-chain. Full operations: [wowok-messenger](../wowok-messenger/SKILL.md).
+Foundation = immutable on-chain rules (Phase 1). Messenger = encrypted, self-verifiable supplement (clarifies, cannot override on-chain). Full ops: [wowok-messenger](../wowok-messenger/SKILL.md).
 
 ### 2.1 Send Privacy Info
 
-Contact `ims[]` from E8. Send E10 info via `messenger_operation` → `send_message`. **Messenger only — never on-chain.** Get explicit user confirmation per item.
+Contact `ims[]` from E8. Send E10 info via `messenger_operation` → `send_message`. **Messenger only — never on-chain.** Explicit user confirmation per item. After sending, persist any newly-provided value via `local_info_operation` `add` (so future orders auto-fill).
 
 ### 2.2 Negotiate
 
-Clarify via Messenger: deliverables (E2 WIP), timeline (E3 nodes), refund/cancellation (E3/E5), privacy info received (E10). Evidence value requires recipient **explicit confirmation** (ARK signature). WTS evidence: [wowok-messenger](../wowok-messenger/SKILL.md).
+Clarify via Messenger: deliverables (E2 WIP), timeline (E3 nodes), refund/cancellation (E3/E5), privacy received (E10). Evidence value requires recipient **explicit confirmation** (ARK signature). WTS evidence: [wowok-messenger](../wowok-messenger/SKILL.md).
 
 ### 2.3 Consensus GATE
 
@@ -245,11 +179,7 @@ Clarify via Messenger: deliverables (E2 WIP), timeline (E3 nodes), refund/cancel
 
 ## Phase 3: Order Creation
 
-**Not in schema**:
-- Excess `buy.total_pay` auto-refunded. Agents cannot withdraw.
-- Discounts: query `onchain_received` (type `0x2::service::Discount`), filter by `service`, validate time/benchmark. Rate: `total_pay × (off / 10000)`. Fixed: `min(off, total_pay)`.
-
-Post-creation: notify via Messenger with order ID.
+Not in schema: excess `buy.total_pay` auto-refunded; agents cannot withdraw. Discounts: query `onchain_received` (type `0x2::service::Discount`), filter by `service`, validate time/benchmark; rate = `total_pay × (off / 10000)`; fixed = `min(off, total_pay)`. Post-creation: notify via Messenger with order ID.
 
 ---
 
@@ -257,142 +187,67 @@ Post-creation: notify via Messenger with order ID.
 
 ### Progress Advancement
 
-When user reaches a node, AI MUST cross-reference Phase 1:
+When user reaches a node, cross-reference Phase 1: (1) E3 user-operable forwards; (2) E4 Guard requirements; (3) E5 financial outcome. Present all three — never just the operation name.
 
-1. **E3 Machine JSON**: user-operable forwards from current node?
-2. **E4 Guard files**: Guard requirements? Can user satisfy?
-3. **E5 Allocation**: financial outcome of each path?
-
-Present all three dimensions. Never just the operation name.
-
-- `namedOperator === ""` + no Guard → `order.progress` directly
-- `namedOperator === ""` + Guard → passport required, no bypass
+- `namedOperator === ""` + no Guard → `order.progress`
+- `namedOperator === ""` + Guard → passport required (no bypass)
 - `namedOperator !== ""` → not user-operable
 
 ### Progress.current="" Diagnostic (stuck at initial state)
 
-If `query_toolkit` returns a Progress with `current: ""`:
-
-1. **Root cause**: Machine entry node (`prev_node: ""`) has empty `forwards[]` — Progress cannot advance.
-2. **Query Machine**: `query_toolkit` → `onchain_objects` for `progress.machine` → inspect `node.pairs` for `prev_node: ""`.
-3. **If forwards empty**: Machine must be republished with ≥1 forward on the entry node (nodes are immutable after publish — clone + add forward + new Machine + rebind to Service).
-4. **MCP auto-diagnostic**: `query_toolkit` now attaches `_diagnostic` with cause + 5-step fix guide when `current=""` is detected.
+Root cause: entry node (`prev_node: ""`) has empty `forwards[]`. Fix: clone Machine + add forward + republish + rebind (nodes immutable after publish). MCP `query_toolkit` attaches `_diagnostic` (cause + 5-step fix) when `current=""` is detected.
 
 ---
 
 ## Phase 5: 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`.
+Process: [wowok-arbitrator](../wowok-arbitrator/SKILL.md). Flow: `arbitration.dispute` → WTS evidence → Messenger → `order.arb_confirm` → voting → (`order.arb_objection`) → `order.arb_claim_compensation`.
 
-**Not in schema**: fee paid separately, not from Order. One compensation claim per Order. Source: `compensation_fund` (E7).
+Not in schema: fee paid separately (not from Order); one compensation claim per Order; source = `compensation_fund` (E7).
 
 ---
 
 ## Fund Management
 
-Builder-only operations: `order.transfer_to` (ownership), `order.receive` (withdraw — agents can execute, only builder receives).
+Builder-only: `order.transfer_to` (ownership), `order.receive` (withdraw). Agents may execute `receive`, but only the builder receives funds.
 
-### How to Withdraw Funds from Order (`order.receive`)
+### Withdraw via `order.receive`
 
-After Allocation distributes funds to Order (as `CoinWrapper` objects), the builder (Order owner) MUST call `order.receive` to unwrap and withdraw the funds. Without this step, funds stay locked in the Order as `CoinWrapper` objects.
+After Allocation distributes `CoinWrapper` objects to the Order, the builder MUST call `order.receive` to unwrap + withdraw; otherwise funds stay locked as `CoinWrapper`.
 
-> **P0-01 / P3-04 fix**: The `receive` field now uses `ReceivedObjectsOrRecentlySchema` (consistent with `owner_receive` on all other objects). Do NOT wrap in `{result: ...}` — pass directly.
-
-#### Step 1: Query received objects (optional but recommended)
-
-Before calling `order.receive`, query what the Order has received to verify there are funds to withdraw:
+- **Schema**: `receive` accepts `ReceivedObjectsOrRecentlySchema` (consistent with `owner_receive` on ALL objects). Pass directly — do NOT wrap in `{result: ...}` (that is `QueryReceivedResult`).
+- **Simplest form** — `"recently"` auto-receives all recently-received `CoinWrapper`:
 
 ```json
-{
-  "tool": "query_toolkit",
-  "query_type": "onchain_received",
-  "name_or_address": "<order_name_or_address>",
-  "type": "CoinWrapper"
-}
+{ "tool": "onchain_operations", "data": { "operation_type": "order", "data": { "object": "<order_id>", "receive": "recently" } }, "env": { "account": "<builder>", "network": "testnet", "confirmed": true } }
 ```
 
-**Expected response**: A `ReceivedBalance` object with `token_type`, `balance`, `received[]` array of `CoinWrapper` objects, and `_money_display` annotation (unit-converted values with decimals reminder). If empty, there is nothing to withdraw yet.
-
-#### Step 2: Call `order.receive` with `"recently"` (simplest form)
-
-Use the string `"recently"` to auto-receive all recently received `CoinWrapper` objects:
-
-```json
-{
-  "tool": "onchain_operations",
-  "data": {
-    "operation_type": "order",
-    "data": {
-      "object": "<order_name_or_address>",
-      "receive": "recently"
-    }
-  },
-  "env": {
-    "account": "<builder_account_name>",
-    "network": "testnet",
-    "confirmed": true
-  }
-}
-```
-
-**Expected result**:
-- Builder account receives the underlying token (e.g., WOW) — `CoinWrapper` is auto-unwrapped
-- Transaction digest returned
-- Order's received `CoinWrapper` objects are consumed
-
-#### Step 2 (alternatives)
+- **Precise form** — pass an explicit `[{id, type}]` array, or pass the `ReceivedBalance` from `query_toolkit` → `query_type: "onchain_received"` (type `CoinWrapper`) directly as `receive`.
+- **Result** — builder receives the underlying token (CoinWrapper auto-unwrapped); digest returned.
 
-For precise control, pass an explicit array of `{id, type}` objects, or pass the `ReceivedBalance` object from Step 1 query directly as `receive`. Both forms accept the same `env` block as the `"recently"` form above.
+**When to call**:
 
-#### Common Pitfalls
+| Trigger | Action |
+|---------|--------|
+| Allocation fires (refund on `return_approved`) | `order.receive` → withdraw to builder |
+| Arbitration awards compensation | `order.receive` → withdraw to builder |
+| Multi-stage allocation (partial refund + deduction) | `order.receive` `"recently"` (all at once) |
+| Order closed with no allocation | Do NOT call (nothing to withdraw) |
 
-- ❌ **Do NOT wrap in `{result: ...}`** — the `receive` field accepts `ReceivedObjectsOrRecently` directly, NOT `QueryReceivedResult` (`{result: [...]}`)
-- ❌ **Do NOT call `order.receive` if no funds received yet** — query first via Step 1
-- ✅ Only the **builder** (Order owner) can call `receive` — agents cannot withdraw funds (they can execute the call, but only builder receives)
-- ✅ `CoinWrapper` is auto-unwrapped to the underlying token (e.g., WOW)
-- ✅ The `receive` field is consistent with `owner_receive` on all other objects (arbitration/contact/demand/machine/permission/repository/reward/service/treasury)
-
-#### When to Call `order.receive`
-
-| Trigger | Why | Action |
-|---------|-----|--------|
-| Allocation fires (e.g., refund Allocator triggers on `return_approved`) | Order receives `CoinWrapper` with refund amount | Call `order.receive` to withdraw to builder account |
-| Arbitration awards compensation | Order receives `CoinWrapper` with award amount | Call `order.receive` to withdraw to builder account |
-| Multi-stage allocation (partial refund + partial deduction) | Order receives multiple `CoinWrapper` objects | Call `order.receive` with `"recently"` to receive all at once |
-| Order closed with no allocation | No `CoinWrapper` received | Do NOT call `order.receive` (nothing to withdraw) |
+**Pitfalls**: don't wrap in `{result:...}`; query first (don't call with no funds); only builder receives; CoinWrapper auto-unwraps to the underlying token.
 
 ---
 
-## Phase 3: Customer Intelligence (MCP-Handled)
-
-> **MCP auto-populates `semantic.customer_advice`** in order/query responses when `customer_intelligence` is ON (default). Read these fields from MCP output — do NOT recompute internally.
-
-**Key fields in `semantic.customer_advice`**:
-- `reminders[]`: stage-aware reminders with priority (`required` blocks purchase; `recommended` = strong caution; `info` = advisory; `reminder` = timed nudge)
-- `risk_score`: 0-100 (🟢≥85 low | 🟡70-84 | 🟠50-69 | 🔴<50 high — advise against purchase)
-- `preference_match`: 0-100 score with `matches`/`mismatches` arrays (≥75 strong match, <50 significant mismatch)
+## Phase 6: Customer Intelligence (MCP-Handled)
 
-**Red lines** (do not purchase): no arb + no refund path, OR compensation_ratio < 0.5.
+> **MCP auto-populates `semantic.customer_advice`** in order/query responses when `customer_intelligence` is ON (default). Read from MCP output — do NOT recompute.
 
-**Post-purchase**: monitor refund Allocator triggers, WIP hash mismatch, merchant unreachable (>3d warning, >7d arb advice), evidence collection (≥3 items).
+Key fields: `reminders[]` (`required` blocks purchase; `recommended` = strong caution; `info` = advisory; `reminder` = timed nudge); `risk_score` 0-100 (🟢≥85 | 🟡70-84 | 🟠50-69 | 🔴<50 advise against); `preference_match` 0-100 with `matches`/`mismatches` (≥75 strong, <50 mismatch).
 
-**Runtime toggle**: `config_operation` → `action: "toggle"`, `service: "order_monitor"` (default OFF) to enable active Progress stall + compensation change + Messenger timeout monitoring.
+**Red lines** (do not purchase): no arb + no refund path, OR `compensation_ratio < 0.5`. **Post-purchase**: monitor refund Allocator triggers, WIP hash mismatch, merchant unreachable (>3d warning, >7d arb), evidence collection (≥3 items). **Runtime toggle**: `config_operation` → `action: "toggle"`, `service: "order_monitor"` (default OFF).
 
 ---
 
 ### 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. E11 (Trust Score) runs LAST — it aggregates all prior findings.
-
-### ⚠️ Critical Attention Items
-
-1. **E4 Ambiguous Guards** — blind spot. User must review file directly. AI must not speculate.
-2. **E3 no-refund + E6 no-arb** — no mechanism to recover funds. Single most important decision factor.
-3. **E3 Forward with Guard** — "user-operable" is misleading if Guard blocks you. Verify requirements.
-4. **E2 WIP hash mismatch** — seller altered claims post-publish. Red flag regardless of other factors.
-5. **E9 High dispute rate** — >10% quantitative warning independent of structural analysis.
-6. **Phase 3 customer_advice** — when `customer_intelligence` is ON, read `semantic.customer_advice` first in every order/query response. The `reminders` array is pre-sorted by priority; `required` items block purchase.
-
----
+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 — aggregates all prior findings.

package/wowok-planner/SKILL.md

@@ -75,20 +75,35 @@ The ODG (Object Dependency Graph) is the single output artifact, persisted via `
   "status": "confirmed",
   "account": "merchant_v1",
   "objects": [
-    { "id": "obj_permission", "type": "permission", "status": "planned", "reversible": true, "dependencies": [], "user_decisions": { "reuse": false, "indexes": { "provider": 1000 } } },
-    { "id": "obj_service", "type": "service", "status": "planned", "reversible": true, "dependencies": ["obj_permission"], "user_decisions": { "name": "...", "publish": "deferred" } },
-    { "id": "obj_machine", "type": "machine", "status": "planned", "reversible": false, "dependencies": ["obj_permission"], "user_decisions": { "nodes": [...], "forwards": [...], "publish": "deferred" } },
-    { "id": "obj_arbitration", "type": "arbitration", "status": "planned", "reversible": true, "dependencies": [], "user_decisions": { "voting_guard_count": 3, "fee_balance": "1000 WOW", "note": "arbiters live in voting_guard, NOT Permission index 1500" } }
+    { "id": "obj_account", "type": "account", "status": "created", "reversible": true, "dependencies": [], "user_decisions": { "reuse": false, "network": "testnet" } },
+    { "id": "obj_permission", "type": "permission", "status": "planned", "reversible": true, "dependencies": ["obj_account"], "user_decisions": { "reuse": false, "indexes": { "provider": 1000 } } },
+    { "id": "obj_service", "type": "service", "status": "planned", "reversible": true, "dependencies": ["obj_permission"], "user_decisions": { "name": "...", "publish": "deferred", "note": "DRAFT first — Guards reference it by LocalMark NAME to break the Guard↔Service cycle" } },
+    { "id": "obj_machine", "type": "machine", "status": "planned", "reversible": false, "dependencies": ["obj_service", "obj_permission"], "user_decisions": { "nodes": [...], "forwards": [...], "publish": "deferred" } },
+    { "id": "obj_guard_*", "type": "guard", "status": "planned", "reversible": false, "dependencies": ["obj_machine", "obj_service"], "user_decisions": { "logic": "...", "note": "references machine node names + service name via LocalMark NAME" } },
+    { "id": "obj_treasury", "type": "treasury", "status": "planned", "reversible": true, "dependencies": ["obj_permission"], "user_decisions": { "reuse": false, "note": "optional fund pool for organizations; referenced by order_allocators as Entity recipient" } },
+    { "id": "obj_contact", "type": "contact", "status": "planned", "reversible": true, "dependencies": ["obj_permission", "obj_account"], "user_decisions": { "reuse": false, "messenger": true, "anti_spam": "open", "note": "Service.um → Contact → ims[]; messenger enabled + anti-spam configured" } },
+    { "id": "obj_arbitration", "type": "arbitration", "status": "planned", "reversible": true, "dependencies": ["obj_permission"], "user_decisions": { "reuse": true, "note": "REUSE third-party; permission MUST differ from Service (E_ARBITRATION_PERMISSION_CONFLICT); compensation_fund > 0 requires non-empty arbitrations" } }
   ],
   "phases": [
-    { "phase": 1, "objects": ["obj_permission"], "gate": "user_confirm" },
-    { "phase": 2, "objects": ["obj_service", "obj_machine", "obj_arbitration"], "gate": "risk_check" },
-    { "phase": 3, "objects": ["obj_guard_*"], "gate": "passport_test" },
-    { "phase": 4, "objects": ["obj_allocator_*"], "gate": "allocation_audit" },
-    { "phase": 5, "objects": ["publish"], "gate": "final_audit" }
+    { "phase": 1, "objects": ["obj_account", "obj_permission"], "gate": "user_confirm" },
+    { "phase": 2, "objects": ["obj_service"], "gate": "user_confirm", "note": "Service DRAFT created BEFORE Machine so Guards can reference it by name" },
+    { "phase": 3, "objects": ["obj_machine", "obj_guard_*"], "gate": "risk_check", "note": "Machine + Guards designed together; guards bound to forwards before publish" },
+    { "phase": 4, "objects": ["publish_machine", "obj_treasury", "obj_allocator_*"], "gate": "allocation_audit", "note": "Machine published; Treasury (optional) created before order_allocators references it" },
+    { "phase": 5, "objects": ["obj_contact", "obj_arbitration"], "gate": "user_confirm", "note": "Contact + third-party Arbitration configured BEFORE publish; arbitration.permission != service.permission" },
+    { "phase": 6, "objects": ["publish_service"], "gate": "final_audit" }
   ],
   "risk_assessment": { "critical": [], "warnings": [], "irreversible_count": 1 }
 }
 ```
 
 Each object has: `id`, `type`, `status` (planned/created/published), `reversible` (true/false), `dependencies` (other object IDs), `user_decisions` (typed fields). Phases gate progression — `risk_check` calls `evaluate_project` (evaluation_type='risk'), `final_audit` runs the pre-publish audit checklist (see wowok-auditor).
+
+**Dependency-chain ordering rules (authoritative, verified from Move/SDK):**
+1. **Service DRAFT is created BEFORE Machine** — Guards reference the Service by LocalMark NAME, so the Service skeleton must exist first to break the Guard↔Service circular dependency.
+2. **Machine + Guards are designed together** (one phase) — a forward's Guard depends on the Machine's node names; the Allocator's Guard depends on both Machine and Service.
+3. **Machine publishes before Service binds it** — `service.machine` must reference a *published* Machine.
+4. **`order_allocators` is L1-locked** — set it before `service.publish`; personal merchants route to Permission owner, organizations route to a Treasury (`Entity` recipient).
+5. **Contact (customer service)** is configured before Service publish — `Service.um → Contact → ims[]`, with the local account enabled as messenger and anti-spam set.
+6. **Arbitration is third-party and before publish** — `arbitration.permission != service.permission` (`E_ARBITRATION_PERMISSION_CONFLICT`); `compensation_fund > 0` requires non-empty `arbitrations` (`E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND`).
+
+These rules are the single source of truth for the dependency chain; the phase list above is their concrete serialization. Hand-off to `wowok-onboard` (Review opening + 12 rounds) follows this same chain.