@wowok/skills 2.0.1 → 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`, and `received[]` array of `CoinWrapper` objects. 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-output/SKILL.md

@@ -21,13 +21,23 @@ this skill's shortening rules are DISABLED — display complete 66-character add
 
 ## Short Address Format
 
-**MUST APPLY TO ALL ADDRESSES** (0x prefix + 64 hex chars = 66 chars total):
-1. Remove `0x` prefix
-2. Take first 5 characters
-3. Convert to UPPERCASE
-4. Wrap in parentheses `()`
+**MUST APPLY TO ALL ADDRESSES AND OBJECT IDs** (0x prefix + 64 hex chars = 66 chars total).
 
-**Example**: `0xa1d421902a3e5f2e4da7590e8f243712b3b3479d1a07c48c2de543184fc97a33` → `(A1D42)`
+Generate a short ID by the following rules:
+1. Remove `0x` prefix → get the hex string
+2. Take the first 5 characters (or fewer if the address is shorter)
+3. Convert to UPPERCASE
+4. **If all 5 characters are the same character** (e.g., `00000` → `AAAAA`), fall back to the last 5 characters, prefixed with `...`
+5. **If even the last 5 are all the same character** (extremely rare), find 5 consecutive characters near the middle that differ, wrapped with `...` on both sides
+6. **Display rule**: no parentheses by default; parentheses are only used when paired with a name (see Display Format Rules below)
+
+**Examples**:
+| Full Address | Short ID | Rule |
+|---|---|---|
+| `0xa1d421902a3e5f2e4da7590e8f243712b3b3479d1a07c48c2de543184fc97a33` | `A1D42` | Normal: first 5 |
+| `0x00000123456789abcdef0123456789abcdef0123456789abcdef000000000000` | `...00000` | First 5 all same → last 5 |
+| `0x00000000000000000000000000000000000000000000000000000000000000000` | `...00000...` | Both ends all same → middle 5 |
+| `0x2` | `2` | Short address, take actual length |
 
 ## Resolution Priority & Display Format
 
@@ -39,10 +49,10 @@ Returns: `{ account?: string, local_mark?: string, address: string }`
 
 | Condition | Display Format | Example |
 |-----------|----------------|---------|
-| **Both account AND local_mark exist** | `{account_name} \| {local_mark_name} (ABCDE)` | `alice \| my_mark (A1D42)` |
-| **Only account exists** | `{account_name} (ABCDE)` | `alice_wallet (A1D42)` |
-| **Only local_mark exists** | `{local_mark_name} (ABCDE)` | `my_service (A1D42)` |
-| **Neither exists** | `(ABCDE)` | `(A1D42)` |
+| **Both account AND local_mark exist** | `{account_name} \| {local_mark_name}({ID})` | `alice \| my_mark(A1D42)` |
+| **Only account exists** | `{account_name}({ID})` | `alice_wallet(A1D42)` |
+| **Only local_mark exists** | `{local_mark_name}({ID})` | `my_service(A1D42)` |
+| **Neither exists** | `{ID}` | `A1D42` |
 
 ---
 
@@ -54,24 +64,32 @@ Returns: `{ account?: string, local_mark?: string, address: string }`
 
 # Amount Formatting Rules
 
-## Conservative Principle
+## Primary Source: `_money_display`
+
+The MCP fund layer now annotates all monetary query results with `_money_display` — a map of field paths to `ChainValueDisplay` objects containing `{raw, display, symbol, decimals, precision_known, text}`. **Use `_money_display` directly when present** — it is the authoritative formatted display, consistent with the MCP's own precision resolution.
+
+- `precision_known === true` → `text` field already contains the complete formatted string: e.g. `"2.2 WOW (decimals: 9; raw: 2200000000)"`
+- `precision_known === false` → `text` contains the raw value with a retry hint; show as-is (the true raw value is authoritative)
+
+Supported query types with `_money_display`:
+- `account_balance` — balance and coin amounts
+- `onchain_objects` — Treasury, Service, Order, Allocation, Payment, Reward, Arb, Discount monetary fields
+- `onchain_table_item_treasury_history` / `onchain_table_item_reward_record` — table entry amounts
+- `onchain_received` — CoinWrapper balances
+- `onchain_transaction` — balance_changes (each change has its own `coin_type`)
+- `onchain_events` — NewOrderEvent.amount (via the order's Service generic token type)
+
+## Fallback (when `_money_display` is absent)
 
 **When in doubt, display raw value.**
 
 | Condition | Display | Example |
 |-----------|---------|---------|
 | Token info UNAVAILABLE | Raw amount | `500000000` |
-| Token info AVAILABLE | Converted + symbol + precision | `0.5 WOW (9P)` |
-
-## Conversion Requirements
-
-ONLY convert when ALL conditions met:
-1. Token type explicitly identified
-2. Successfully queried via `query_toolkit` with `query_type: "token_list"`
-3. Metadata contains valid `decimals` and `symbol`
+| Token info AVAILABLE | Converted + symbol + precision | `2.2 WOW (decimals: 9; raw: 2200000000)` |
 
 **Formula**: `converted = raw / (10 ^ decimals)`  
-**Format**: `{amount} {symbol} ({decimals}P)`
+**Format**: `{amount} {symbol} (decimals: {N}; raw: {raw})`
 
 ---
 
@@ -82,10 +100,10 @@ ONLY convert when ALL conditions met:
 ```
 | # | Time | Sender | Service | Amount | Order |
 |---|------|--------|---------|--------|-------|
-| 1 | {time} | {name} (ABCDE) | {name} (ABCDE) | {amount} | (ABCDE) |
+| 1 | {time} | {name}(ABCDE) | {name}(ABCDE) | {amount} | ABCDE |
 ```
 
-**Note**: `{name}` follows Display Format Rules above (account | local_mark). If no name, show only `(ABCDE)`.
+**Note**: `{name}` follows Display Format Rules above (account | local_mark). If no name, show only the short ID (no parentheses).
 
 ## Event Type Fields
 
@@ -108,12 +126,13 @@ When user asks about field meanings:
 - **Sender**: Account that initiated the transaction
 - **Service**: Service object being ordered/interacted with
 - **Order Object**: Unique on-chain identifier for this order
-- **Short Address (ABCDE)**: First 5 chars for quick visual identification
+- **Short Address (ABCDE)**: Shortened ID for quick visual identification — see Short Address Format rules (first 5 chars; fallback to last 5 or middle 5 if all same)
 
 ## Amounts
 - **Raw**: Actual U64 integer stored on-chain
 - **Converted**: Human-readable after applying decimals
-- **Precision (XP)**: Number of decimal places
+- **Precision (N decimals)**: Number of decimal places
+- **`_money_display`**: MCP-annotated display map (see Amount Formatting Rules above)
 
 ## Time
 - **Timestamp**: Unix milliseconds since epoch
@@ -125,9 +144,10 @@ When user asks about field meanings:
 
 - [ ] Extract unique addresses from response
 - [ ] Query `local_names` for resolution
-- [ ] Query `token_list` for amount formatting
+- [ ] Check for `_money_display` annotations in query results (primary amount source)
+- [ ] If `_money_display` absent, query `token_list` for manual amount formatting
 - [ ] Apply address format rules
-- [ ] Apply amount format rules (conservative)
+- [ ] Apply amount format rules (use `_money_display` first; fallback to conservative)
 - [ ] Render final output
 
 ---