@wowok/skills 1.1.11 → 1.1.13

package/wowok-order/SKILL.md

@@ -291,556 +291,160 @@ Schema: `onchain_operations_order`. Builder-only operations: `order.transfer_to`
 
 ---
 
-## 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`.
-
-### Phase Dependency
-
-```
-E1 (Service) ──→ E2 (Products/WIP)
-  │    │
-  │    ├──→ E8 (Contact)   ├──→ E7 (Compensation)
-  │    ├──→ E10 (Privacy)  └──→ E6 (Arbitrations)
-  │
-  └──→ E3 (Machine) ──→ E4 (Guards) ──→ E5 (Allocators)
-         │
-         └──→ E9 (Reputation)
-```
-
-> E3→E4→E5 is a strict chain. E6-E10 run in parallel after E1.
-
-### ⚠️ 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.
-
----
-
-## Dialogue Scripts (R1-R10)
-
-A guided 10-round dialogue for the customer journey — from initial intent to post-purchase operations. Each round has a specific AI Goal, Key Questions, Tool Calls, Success Criteria, Fallback, and Checkpoint. Checkpoints persist via `local_info_operation` so the journey can resume after interruption.
-
-### R1 — Intent Capture & Service Identification
-
-**AI Goal**: Understand what the user wants to buy and identify candidate Services on-chain. Establish the buyer role and surface options without committing to a purchase.
-
-**Key Questions**:
-- What are you trying to purchase (product, service, subscription, rental)?
-- Do you have a specific Service name or ID, or should I search?
-- What is your budget and preferred token?
-- Do you have a WoWok account set up? If not, hand off to [wowok-onboard](../wowok-onboard/SKILL.md).
-
-**Tool Calls**:
-1. `query_toolkit` → `onchain_objects` with name filter (if user provides a Service name).
-2. `query_toolkit` → `onchain_table_data` on the Service registry table (if user wants to browse by category/tags).
-3. `account_operation` → `get` to confirm the active account exists and has a balance.
-4. `local_info_operation` → create a session checkpoint `{ round: R1, intent, candidates[] }`.
-
-**Success Criteria**: User has identified at least one candidate Service. Account confirmed. Intent packet persisted.
-
-**Fallback**: No matching Service found → suggest broader search terms or hand off to [wowok-scenario](../wowok-scenario/SKILL.md) for industry-specific discovery. User has no account → hand off to [wowok-onboard](../wowok-onboard/SKILL.md).
+## Phase 3: Customer Intelligence (Optional Enhancement)
 
-**Checkpoint**: Persist `{ round: R1, service_candidates: [...], account, intent_summary }`. Mark R1 COMPLETE.
+> **When to use**: When `customer_intelligence` runtime service is enabled (default ON), the MCP server automatically populates `semantic.customer_advice` in order/query operations. This is a layer ON TOP of E1-E10 — never a replacement for due diligence.
 
-### R2 — E1-E2 Service Status & Product Verification
+### Information Puzzle (6 dimensions)
 
-**AI Goal**: Run the first two due-diligence checks (E1 service status, E2 product/WIP verification) on the candidate Service. Surface hard ABORT conditions before deeper analysis.
+E1-E10 captures static facts. The information puzzle assembles them into a dynamic, evolving picture that gets richer with every query:
 
-**Key Questions**:
-- Confirm we are evaluating `<service_name>` — correct?
-- Are you interested in a specific `sales[]` item, or all of them?
-- Have you reviewed the WIP file (product evidence)? If not, I will verify the hash.
+| Dimension | Source | Fragments |
+|-----------|--------|-----------|
+| Service basics | E1 query | publish/pause/price/sales/WIP |
+| Workflow structure | E3 machineNode2file | nodes/forwards/user-operable/refund path |
+| Fund safety | E5 + E7 | allocators/compensation/price anomaly |
+| Trust signals | E6 + E9 | arbitration/reviews/dispute rate |
+| Merchant behavior | onchain_events | completion rate/trend/refund rate |
+| Market context | batch query_toolkit | similar services/price distribution |
 
-**Tool Calls**:
-1. `query_toolkit` → `onchain_objects` for the Service. Capture `bPublished`, `bPaused`, `sales`, `machine`, `buy_guard`, `customer_required`, `arbitrations`, `compensation_fund`, `compensation_lock_duration`, `order_allocators`, `um`.
-2. For each non-suspended `sales[]` item with `wip_hash`: `wip_file` → `op: "verify"`, `wipFilePath: <wip_url>`, `hash_equal: <wip_hash>`.
-3. `local_info_operation` → update checkpoint with E1/E2 results.
+**Incremental collection**: Don't fetch all 6 every time. Browse = dim 1+6, Evaluate = +2/3/4, Preorder = +5, Monitoring = 2+5.
 
-**Success Criteria**: `bPublished === true` AND `bPaused === false` AND all WIP hashes verified. If any ABORT condition triggers, user has been informed and decided to stop or continue with risk acknowledgment.
+### Risk Scoring (4 dimensions, 100 points)
 
-**Fallback**: `bPublished === false` or `bPaused === true` → 🔴 ABORT, return to R1 for alternative candidates. WIP hash mismatch → 🔴 ABORT, warn user the seller altered claims post-publish. No WIP URL → ⚠️ continue but flag weaker evidence.
+E1-E10 produces ⚠️/🔴 flags. Risk scoring converts them to a quantitative score:
 
-**Checkpoint**: Persist `{ round: R2, e1_status, e2_wip_results, abort_conditions: [...] }`. Mark R2 COMPLETE.
+| Dimension | Max | Key checks |
+|-----------|-----|------------|
+| Workflow | 35 | refund path / arbitration path / user-operable / dead ends |
+| Fund | 25 | compensation coverage / allocator fairness / price anomaly / lock duration |
+| Trust | 20 | arbitration independence / dispute rate / reputation / trust score |
+| Behavior | 20 | completion trend / response time / refund rate / arb loss rate / anomalies |
 
-### R3 — E3 Machine Workflow Analysis (CORE)
+**Levels**: 🟢 ≥85 low | 🟡 70-84 medium-low | 🟠 50-69 medium-high | 🔴 <50 high (advise against)
 
-**AI Goal**: Perform the most critical due-diligence step — analyze the Machine workflow to determine if the user can actually operate the order, reach refund paths, and access arbitration. This is the single most important round.
+### User Preference Matching (7 dimensions, 100 points)
 
-**Key Questions**:
-- Do you understand the workflow the seller has designed? I will explain it step-by-step.
-- Are there nodes you cannot reach yourself (require provider action)? Is that acceptable?
-- Is there a refund path? If not, are you comfortable with no fund recovery mechanism?
+When the user has 3+ historical orders, the system infers preferences and scores each Service:
 
-**Tool Calls**:
-1. `query_toolkit` → `onchain_objects` for the Machine (from E1 `machine` field). Confirm `bPublished === true` and `bPaused === false`.
-2. `machineNode2file` → export the complete Machine JSON. Parse locally — never node-by-node.
-3. Classify every forward per the E3 table: `namedOperator` × `guard` → user-operable / provider-only / guard-gated.
-4. Detect terminal nodes, refund paths (lead to 100%→Order Allocator), arbitration paths, user-blocked paths.
-5. `local_info_operation` → persist the full machine analysis (forward classification, paths, risk signals).
+| Dimension | Max | What it measures |
+|-----------|-----|------------------|
+| Price | 25 | budget fit or market avg comparison |
+| Time | 15 | cycle ≤ max_acceptable_cycle |
+| Region | 10 | preferred_region match |
+| Brand | 10 | min_order_history + merchant age |
+| Bargain | 15 | reward/discount presence |
+| Emotion | 10 | after_sales_expectation + transparency |
+| Risk | 15 | risk_score ≥ min_trust_score + arb/comp requirements |
 
-**Success Criteria**: User understands the workflow. All risk signals surfaced (no-refund, no-arb, user-blocked paths, guard-gated forwards). The combination "no refund + no arbitration" is flagged as 🔴 if present.
+**Score ≥ 75** = strong match. **< 50** = significant mismatch. The `matches`/`mismatches` arrays explain the score so you can present tradeoffs to the user.
 
-**Fallback**: No user-operable path from a critical node → 🔴 advise against purchase unless provider cooperation is guaranteed in writing via Messenger. No refund path → 🔴 strongly advise against. No arbitration path → 🔴 strongly advise against. User wants to negotiate workflow changes → hand off to [wowok-messenger](../wowok-messenger/SKILL.md) for pre-order negotiation.
+### Reminder System (6 stages, 4 priorities)
 
-**Checkpoint**: Persist `{ round: R3, machine_id, forward_classification, paths: {terminal, refund, arb, blocked}, risk_signals: [...] }`. Mark R3 COMPLETE.
+Reminders are populated in `semantic.customer_advice.reminders` based on the operation stage:
 
-### R4 — E4 Guards Analysis
+| Stage | When | Example reminders |
+|-------|------|-------------------|
+| browse | query_toolkit on Service | reviews summary / price anomaly / no arb / no comp |
+| evaluate | deeper analysis | checklist / high risk (required) / ambiguous guard (required) / no refund path |
+| preorder | order creation | payment confirm (required) / compensation insufficient / arb missing (required) |
+| in_progress | order monitoring | progress stalled / compensation drop / messenger unanswered |
+| complete | order done | review reminder / review window |
+| after_sale | post-purchase | arb window / refund received |
 
-**AI Goal**: Export and classify every Guard referenced by the Machine, allocators, and buy_guard. Identify any ambiguous Guards that the user must review manually — never speculate on Guard logic.
+**Priority order**: `required` (blocks purchase) > `recommended` (strong caution) > `info` (advisory) > `reminder` (timed nudge). Fatigue control: max 3 high-risk reminders per response.
 
-**Key Questions**:
-- Have you reviewed the exported Guard files? I will explain each one's purpose and conditions.
-- Are there Guards gating refund or user-operable forwards? These are the highest priority.
-- Do you meet the Guard conditions (e.g., token holdings, reputation thresholds)?
+### Game Strategy Quick Reference (8 scenarios)
 
-**Tool Calls**:
-1. Collect unique Guard IDs from E3 Machine JSON (`forward.guard.guard`), E1 `order_allocators`, E1 `buy_guard`. Deduplicate.
-2. `guard2file` → export each unique Guard as JSON.
-3. `wowok_buildin_info` → `info: "guard instructions"` for instruction reference.
-4. Classify each Guard: 🟢 Simple / 🟡 Complex / 🔴 Ambiguous.
-5. `local_info_operation` → persist Guard classifications and exported file paths.
+When the user faces a specific negotiation, refer to the strategy matrix:
 
-**Success Criteria**: All Guards classified. Ambiguous Guards flagged for manual review. User has explicitly confirmed they understand Guards gating refund paths and user-operable forwards. User can satisfy all conditions OR has acknowledged which ones they cannot.
+| Scenario | Merchant tactic | User strategy |
+|----------|------------------|---------------|
+| Info asymmetry | Hides Machine details | Demand machineNode2file export + Messenger Q&A |
+| Fund safety | No/low compensation | Require 100% coverage + WTS agreement |
+| Refund dispute | No refund path | Demand 100%→Order Allocator + Messenger terms |
+| Arb fairness | Self-built arbitration | Verify arb owner via query_toolkit |
+| Pricing | Price >120% market avg | Reference market_context.avg_price + request discount/Reward |
+| Delivery SLA | No milestone nodes | Require milestone config + written timeline |
+| Quality | WIP hash unverified | Require WIP verify + sample/staged delivery |
+| After-sales | No Messenger | Require Messenger config + written after-sales terms |
 
-**Fallback**: 🔴 Ambiguous Guard → user MUST review the file directly. AI refuses to speculate. If user cannot meet a Guard condition gating a refund path → 🔴 advise against purchase. Guard logic seems to contradict seller's claims → flag discrepancy, hand off to [wowok-messenger](../wowok-messenger/SKILL.md) for clarification.
+**Red lines** (do not purchase): no arb + no refund path, OR compensation_ratio < 0.5.
 
-**Checkpoint**: Persist `{ round: R4, guards: [{id, level, gates_refund, user_can_satisfy}], ambiguous: [...] }`. Mark R4 COMPLETE.
+### Industry Personalization (6 industries)
 
-### R5 — E5 Fund Allocation Rules
+Each industry has specific risk checks and preference templates:
 
-**AI Goal**: Map out exactly where funds go under each possible order outcome. Verify a refund mechanism exists and identify any paths where the provider can unilaterally collect.
+| Industry | Cycle (days) | Response (h) | Arb | Comp | Risk appetite | Delivery |
+|----------|--------------|--------------|-----|------|---------------|----------|
+| freelance | 30 | 4 | ✓ | ✓ | balanced | normal |
+| rental | 7 | 8 | ✓ | ✓ | conservative | normal |
+| education | 90 | 24 | ✓ | ✓ | conservative | flexible |
+| travel | 14 | 2 | ✓ | ✓ | conservative | urgent |
+| subscription | 30 | 24 | – | – | aggressive | normal |
+| retail | 7 | 8 | ✓ | ✓ | balanced | normal |
 
-**Key Questions**:
-- Do you understand where your payment goes if the order completes successfully?
-- Is there a 100%→Order Allocator (refund mechanism)? If not, are you comfortable with no refund?
-- Are there allocators that fire only on provider-operated paths? That means unilateral collection.
+**Industry-specific risks**: freelance checks WIP verified + milestone nodes; rental checks compensation coverage + lock duration; travel checks urgent delivery + Messenger; subscription checks no-lockin + user-operable; etc.
 
-**Tool Calls**:
-1. From E1 `order_allocators.allocators[]`, cross-reference each Allocator's Guard (E4) → trigger condition.
-2. Map each Allocator to the Machine node (E3) where it fires.
-3. Present the distribution outcome for each path: who receives what percentage.
-4. `local_info_operation` → persist the allocation map.
+### Post-Purchase Support (4 phases)
 
-**Success Criteria**: User understands the financial outcome of every path. The key safeguard (100%→Order Allocator on a user-operable forward) is present OR user has acknowledged its absence. Surplus receiver and unilateral collection paths identified.
+When the order is in progress or completed, post-purchase support covers:
 
-**Fallback**: No 100%→Order Allocator → 🔴 no refund mechanism, strongly advise against. Surplus receiver = provider → ⚠️ explain remainder goes to provider. Allocators only on provider-only paths → ⚠️ explain unilateral collection risk.
+- **Refund tracking**: monitor refund Allocator triggers, check refunded vs order amount
+- **Quality issue**: WIP hash mismatch detection + evidence collection (≥3 items recommended)
+- **Merchant unreachable**: >3 days warning, >7 days arbitration advice (if available)
+- **Arbitration support**: evidence collection → application template → progress monitoring → result interpretation
 
-**Checkpoint**: Persist `{ round: R5, allocators: [{id, trigger_node, distribution, unilateral}], refund_mechanism: bool }`. Mark R5 COMPLETE.
+### Runtime Service Toggles
 
-### R6 — E6-E8 Arbitration, Compensation, Contact
+Use `config_operation` to toggle Phase 3 services at runtime:
 
-**AI Goal**: Verify the three recourse-related items in parallel: arbitration availability (E6), compensation fund adequacy (E7), and contact channel existence (E8). These determine whether the user has any recourse if something goes wrong.
+| Service | Default | What it controls |
+|---------|---------|------------------|
+| `customer_intelligence` | ON | Populates `semantic.customer_advice` (reminders + risk + preference match) |
+| `order_monitor` | OFF | Active order monitoring (Progress stall + compensation change + Messenger timeout) |
 
-**Key Questions**:
-- Are you comfortable with the arbitration fee and voting structure?
-- Is the compensation fund large enough to cover a potential award?
-- Does the seller have a reachable Messenger contact?
-
-**Tool Calls**:
-1. Batch query E1 `arbitrations[]` via `query_toolkit` → `onchain_objects`. Check `bPaused`, `fee`, `voting_guard`.
-2. `onchain_events` → `type: "ArbEvent"`, `limit: 20`, filter for these Arb IDs — check dispute history.
-3. From E1: check `compensation_fund` balance vs planned order amount. Check `compensation_lock_duration` expiry.
-4. `query_toolkit` → `onchain_objects` for E1 `um` ID. Check `ims[]` is non-empty.
-5. `local_info_operation` → persist E6/E7/E8 results.
-
-**Success Criteria**: At least one non-paused Arbitration service exists. Compensation fund balance ≥ planned order amount (or user acknowledged shortfall). Contact has active `ims[]`. If `um === null` or `ims[]` empty → 🔴 ABORT.
-
-**Fallback**: `arbitrations[]` empty → 🔴 no recourse, strongly advise against. Arb `bPaused === true` → 🔴 unavailable. Compensation fund insufficient → ⚠️ may not cover award. `um === null` → 🔴 ABORT (no contact channel). `ims[]` empty → 🔴 ABORT (no Messenger).
-
-**Checkpoint**: Persist `{ round: R6, e6_arb: [...], e7_comp_fund, e8_contact, abort_conditions: [...] }`. Mark R6 COMPLETE.
-
-### R7 — E9-E10 Reputation & Privacy Matching
-
-**AI Goal**: Complete the final two due-diligence items: chain reputation analysis (E9) and privacy information matching (E10). Surface quantitative warning signs and confirm the user consents to sharing required private info.
-
-**Key Questions**:
-- Are you comfortable with the seller's dispute rate and reputation?
-- The Service requires these private fields: `<list>`. Do you consent to send each one via Messenger?
-
-**Tool Calls**:
-1. `query_toolkit` → `onchain_table_item_entity_linker` for provider address. Compute likes/dislikes ratio.
-2. Batch query `votes[].address` via `query_toolkit` → `onchain_objects` (50/batch, max 200). Filter Order-type objects where `service` matches. Aggregate dispute rate.
-3. From E1 `customer_required[]`, check locally via `query_toolkit` → `local_info_list`. Match against local `name` fields.
-4. For each matched field: present value, ask "correct?" and "OK to send?". For missing: ask user to provide.
-5. `local_info_operation` → persist E9/E10 results and user consent per field.
-
-**Success Criteria**: Dispute rate ≤10% (or user acknowledged higher rate). User has explicitly consented per private field. All `customer_required` fields have values ready for Messenger transmission.
-
-**Fallback**: Dispute rate >10% → ⚠️ quantitative warning. User declines to send a required field → cannot proceed with purchase, return to R1. Missing field the user cannot provide → 🔴 ABORT.
-
-**Checkpoint**: Persist `{ round: R7, e9_dispute_rate, e10_consent: [{field, consented}], missing_fields: [...] }`. Mark R7 COMPLETE.
-
-### R8 — Pre-Purchase GATE Decision & Consensus Building
-
-**AI Goal**: Consolidate E1-E10 into the Pre-Purchase GATE decision. If all green, proceed to consensus building via Messenger. If any red, present the final risk summary and let the user decide.
-
-**Key Questions**:
-- Here is the consolidated GATE summary. Do you want to proceed?
-- Are you ready to send the required private info via Messenger and negotiate final terms?
-- Do you want to generate WTS evidence of our consensus conversation?
-
-**Tool Calls**:
-1. Render the Pre-Purchase GATE table from persisted checkpoints (R2-R7).
-2. If all OK: `messenger_operation` → `send_message` to the seller's Contact (`um` ims address). Send E10 info per user consent.
-3. Negotiate via Messenger: deliverables (E2 WIP), timeline (E3 nodes), refund/cancellation (E3/E5), privacy info received (E10).
-4. `messenger_operation` → `generate_wts` + `sign_wts` for the consensus conversation.
-5. `local_info_operation` → persist the GATE decision and consensus packet.
-
-**Success Criteria**: GATE decision made. If proceeding: E10 info sent and acknowledged by seller. WTS evidence generated. Seller confirmed deliverables and edge cases.
-
-**Fallback**: User decides not to proceed → archive the analysis, return to R1. Seller does not respond → wait, then consider alternative Services. Seller disputes on-chain rules → flag the discrepancy, on-chain rules are immutable and cannot be overridden by Messenger.
-
-**Checkpoint**: Persist `{ round: R8, gate_decision, consensus_wts_path, seller_ack: bool }`. Mark R8 COMPLETE.
-
-### R9 — Order Creation & First Progress
-
-**AI Goal**: Execute the order creation transaction and advance to the first user-operable node. Confirm the order is on-chain and the user understands the next operations.
-
-**Key Questions**:
-- Confirm the final amount and token. Any discounts available?
-- Ready to execute `service.buy`? This transfers funds into escrow.
-- After creation, which node are you at? Can you advance, or does the provider need to act first?
-
-**Tool Calls**:
-1. `query_toolkit` → `onchain_received` (type `0x2::service::Discount`), filter by `service`, validate time/benchmark.
-2. `schema_query` → `onchain_operations_service` to confirm the `buy` operation shape.
-3. `onchain_operations` → `service.buy` with `submission` (after user confirmation per [wowok-safety](../wowok-safety/SKILL.md)).
-4. `onchain_operations` → `order.progress` if the first node is user-operable (per E3 classification).
-5. `messenger_operation` → `send_message` to notify the seller with the order ID.
-6. `local_info_operation` → persist the order ID, current node, and next actions.
-
-**Success Criteria**: Order created on-chain. Order ID and Progress ID captured. User notified of current node and available forwards. Seller notified via Messenger.
-
-**Fallback**: `service.buy` fails → check `buy_guard` (E4) — passport may be required. Generate via `onchain_operations` → `gen_passport`. Excess `total_pay` auto-refunded — confirm with user. First node not user-operable → explain the provider must act, set expectation for wait time.
-
-**Checkpoint**: Persist `{ round: R9, order_id, progress_id, current_node, next_actions: [...] }`. Mark R9 COMPLETE.
-
-### R10 — Operations Handoff
-
-**AI Goal**: Hand off the user to daily order operations. Equip them with the progress advancement playbook, dispute escalation path, and fund management reference. The buyer journey transitions to ongoing operations.
-
-**Key Questions**:
-- Do you understand how to advance progress when you reach each node?
-- Do you know how to escalate to arbitration if the provider fails to deliver?
-- Do you know how to withdraw funds (only you, as `builder`, can do this)?
-
-**Tool Calls**:
-1. `local_info_operation` → write the handoff packet: order ID, progress ID, machine analysis (R3), allocation map (R5), guard requirements (R4), arbitration IDs (R6), contact (R8).
-2. Cross-reference E3 Machine JSON for the current node's user-operable forwards. Present all three dimensions: E3 (operability), E4 (Guard), E5 (financial outcome).
-3. Orient the user to Phase 4 (Order Operations) and Phase 5 (Arbitration) schemas.
-4. Recommend next Skills: [wowok-messenger](../wowok-messenger/SKILL.md) for ongoing communication, [wowok-arbitrator](../wowok-arbitrator/SKILL.md) if dispute arises, [wowok-output](../wowok-output/SKILL.md) for event display.
-
-**Success Criteria**: User has the handoff packet. User understands the daily ops loop (monitor Progress, advance nodes, trigger Allocation). User knows the dispute escalation path. User knows fund withdrawal is builder-only.
-
-**Fallback**: User wants to modify the order → clarify which fields are mutable (none — order terms are immutable after creation; only Progress advances). User wants to cancel → check E3/E5 for refund path; if none, funds are escrowed until Allocation fires. User wants to transfer ownership → `order.transfer_to` (builder-only).
-
-**Checkpoint**: Persist `{ round: R10, handoff_emitted: true, order_id, journey: complete }`. Mark buyer setup COMPLETE.
-
-**Handoff Packet** (emitted to [wowok-messenger](../wowok-messenger/SKILL.md) for ongoing communication, and to [wowok-arbitrator](../wowok-arbitrator/SKILL.md) for dispute readiness):
-- Order ID + Progress ID + Service ID
-- Machine analysis (forward classification, paths)
-- Guard requirements (which passport needed for which forward)
-- Allocation map (financial outcome per path)
-- Arbitration IDs + fee + voting structure
-- Contact (`um`) ID + Messenger address
-- WTS evidence path (from R8 consensus)
-- Recommended next Skill: wowok-messenger (daily communication), wowok-arbitrator (dispute), wowok-output (event display)
+Toggle example: `config_operation` → `action: "toggle"`, `service: "order_monitor"` to enable active monitoring when the user has active orders.
 
 ---
 
-## Decision Trees
-
-### D1: Purchase Decision (Post-E1-E10 GATE)
-
-```
-After E1-E10 due diligence:
-├── Any 🔴 ABORT condition?
-│   ├── YES → STOP. Do not purchase.
-│   │        (bPublished=false, bPaused=true, um=null, ims empty,
-│   │         WIP hash mismatch, no-refund + no-arb)
-│   └── NO → continue
-├── Any ⚠️ WARNING condition?
-│   ├── YES → Present risk, wait for explicit user decision
-│   │        (high dispute rate, insufficient comp fund,
-│   │         ambiguous guard, unilateral collection path)
-│   │   ├── User accepts risk → PROCEED (document acknowledgment)
-│   │   └── User declines → STOP. Return to R1.
-│   └── NO → continue
-├── All E1-E10 OK?
-│   ├── YES → PROCEED to Consensus Building (R8)
-│   └── NO → Identify which items incomplete, return to relevant R round
-└── Final check: User has explicitly consented to send all
-    customer_required fields via Messenger?
-    ├── YES → Execute `service.buy`
-    └── NO → Return to R7 for consent collection
-```
-
-### D2: Progress Advancement Path Selection
-
-```
-User has reached a node in the Machine workflow:
-├── Query E3 Machine JSON for current node's forwards
-├── For each outgoing forward:
-│   ├── namedOperator === "" AND no Guard?
-│   │   └── User-operable → `order.progress` directly
-│   ├── namedOperator === "" AND Guard present?
-│   │   ├── User can satisfy Guard (has passport)?
-│   │   │   ├── YES → `order.progress` with passport
-│   │   │   └── NO → Generate passport via `gen_passport`
-│   │   │       ├── Passport generated → `order.progress`
-│   │   │       └── Guard rejects → Stuck. Escalate to Messenger
-│   │   └── (No-bypass rule: passport is mandatory)
-│   ├── namedOperator !== ""?
-│   │   └── Provider-only → Wait for provider action
-│   │       ├── Provider acts → Node advances
-│   │       └── Provider stalls → Consider dispute (D3)
-│   └── No outgoing forwards (terminal)?
-│       └── Order complete. Check Allocation outcome.
-└── Multiple user-operable forwards?
-    ├── Present all three dimensions (E3 operability, E4 Guard, E5 finance)
-    └── Let user choose which path to take
-```
-
-### D3: Dispute Escalation Path
-
-```
-Order is stuck or provider failed to deliver:
-├── Is there a user-operable forward to a refund path? (E3/E5)
-│   ├── YES → Advance to refund node. Allocation fires. Funds returned.
-│   └── NO → continue
-├── Is there an arbitration path in the Machine? (E3)
-│   ├── YES → Follow Machine arbitration path (may need provider action)
-│   └── NO → File dispute directly via `arbitration.dispute` (E6)
-├── Filing dispute:
-│   ├── Generate WTS evidence (`generate_wts` + `sign_wts`)
-│   ├── Send WTS to arbitrator via Messenger
-│   ├── Execute `order.arb_confirm`
-│   ├── Voting occurs (Arb state machine)
-│   ├── Result at state (3) Arbitrated:
-│   │   ├── Accept → `order.arb_claim_compensation` → (5)
-│   │   └── Object → `order.arb_objection` → (4) → reset → (0) → retry
-│   └── One compensation claim per Order (source: compensation_fund)
-└── No arbitration available? (E6 empty)
-    ├── No refund + no arb → Funds escrowed indefinitely
-    └── Escalate to WoWok community / off-chain recourse
-```
-
-### D4: Refund vs Arbitration Decision
+## Quick Reference
 
-```
-User wants to exit the order:
-├── Why does the user want to exit?
-│   ├── Provider agreed to cancel
-│   │   ├── Refund path exists (E3/E5)? → Advance to refund node. Done.
-│   │   └── No refund path → Negotiate via Messenger, may need arbitration
-│   ├── Provider stalled / non-responsive
-│   │   ├── Refund path user-operable? → Advance to refund node. Done.
-│   │   ├── Refund path provider-operable? → Provider must act. Escalate.
-│   │   └── No refund path → Must use arbitration (D3)
-│   ├── Quality dispute (deliverable doesn't match WIP)
-│   │   ├── Document discrepancy (Messenger evidence)
-│   │   └── File arbitration dispute (D3)
-│   └── Changed mind (no fault)
-│       ├── Refund path exists? → Try to advance. Provider may block.
-│       └── No refund path → No recourse. Funds escrowed.
-└── Key: Always check E3 Machine JSON + E5 Allocation map first.
-```
+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`.
 
-### D5: Information Sharing Decision
+### Phase Dependency
 
 ```
-Service has customer_required[] fields (E10):
-├── For each required field:
-│   ├── Is it already in local_info? (query local_info_list)
-│   │   ├── YES → Present value, ask user "correct?" and "OK to send?"
-│   │   │   ├── Correct + consent → Queue for Messenger send
-│   │   │   ├── Correct + decline → Cannot purchase. ABORT.
-│   │   │   └── Incorrect → Ask user to provide new value
-│   │   └── NO → Ask user to provide value
-│   │       ├── User provides → Queue for Messenger send
-│   │       └── User declines → Cannot purchase. ABORT.
-│   └── After all fields resolved:
-│       ├── Send via Messenger ONLY (never on-chain)
-│       ├── Get explicit confirmation per item
-│       └── Generate WTS evidence of the exchange
-└── Transmission medium:
-    ├── Messenger send_message (text fields)
-    └── Messenger send_file (large documents, WIP, ZIP)
+E1 (Service) ──→ E2 (Products/WIP)
+  │    │
+  │    ├──→ E8 (Contact)   ├──→ E7 (Compensation)
+  │    ├──→ E10 (Privacy)  └──→ E6 (Arbitrations)
+  │
+  └──→ E3 (Machine) ──→ E4 (Guards) ──→ E5 (Allocators)
+         │
+         └──→ E9 (Reputation)
 ```
 
----
-
-## Failure Playbooks
-
-### F1: Service Not Found / Not Published
-
-**Trigger**: User provides a Service name or ID, but `query_toolkit` → `onchain_objects` returns empty OR `bPublished === false`.
-
-**Diagnosis**:
-- Empty result: name typo, wrong network, or Service never created.
-- `bPublished === false`: Service exists but seller hasn't published it yet. Cannot be purchased.
-- `bPaused === true`: Service is temporarily suspended by seller.
-
-**Recovery**:
-1. Confirm the name/ID with the user. Check for typos.
-2. Verify `env.network` matches the Service's chain (testnet vs mainnet).
-3. If `bPublished === false`: inform user the Service is not yet live. Suggest contacting the seller via Messenger if Contact exists.
-4. If `bPaused === true`: inform user the Service is suspended. Check `onchain_events` for recent pause events to understand why.
-5. Return to R1 for alternative candidates.
-
-**Prevention**: Always confirm the Service name/ID with the user before starting due diligence. Verify `env.network` at R1.
-
-### F2: Ambiguous Guard Blocks Purchase
-
-**Trigger**: During E4, a Guard export (`guard2file`) produces logic the AI cannot confidently classify as 🟢 Simple or 🟡 Complex — it falls into 🔴 Ambiguous.
-
-**Diagnosis**:
-- Guard uses complex `rely` composition with cross-object references.
-- Guard logic depends on dynamic on-chain state that's hard to evaluate offline.
-- Guard instructions reference obscure or undocumented operations.
-- The Guard gates a critical path (refund, user-operable forward).
-
-**Recovery**:
-1. **Never speculate.** Present the raw Guard file to the user.
-2. Explain which parts are clear and which are ambiguous.
-3. Identify the specific instructions or rely chains that are unclear.
-4. Query `wowok_buildin_info` → `info: "guard instructions"` for reference.
-5. If user can review and confirm understanding → proceed with documented acknowledgment.
-6. If user cannot understand → recommend declining purchase. The risk of an unforeseen Guard failure during refund is too high.
-7. If user wants to negotiate with seller → hand off to [wowok-messenger](../wowok-messenger/SKILL.md) to request clarification or Guard modification (seller would need to create a new Guard — immutable after creation).
-
-**Prevention**: At R4, always prioritize Guards gating refund paths and user-operable forwards. If any such Guard is ambiguous, treat as a hard stop until resolved.
-
-### F3: Order Stuck (No User-Operable Forward)
-
-**Trigger**: User has created an order (R9 complete) but cannot advance Progress because all forwards from the current node have `namedOperator !== ""` (provider-only) or require a Guard the user cannot satisfy.
-
-**Diagnosis**:
-- This was likely identified at E3 (R3) but the user proceeded anyway, expecting provider cooperation.
-- Provider is now non-responsive or refusing to act.
-- The node has no refund path — funds are escrowed.
-
-**Recovery**:
-1. Re-confirm the forward classification from the persisted R3 checkpoint.
-2. Check if any forward was misclassified (e.g., Guard condition the user can now satisfy).
-3. If a Guard-gated forward exists and user can generate a passport → try `gen_passport` then `order.progress`.
-4. If truly no user-operable path:
-   - Contact provider via Messenger. Document the stall.
-   - If arbitration path exists in Machine (E3) → advance via that path (may require provider action — same problem).
-   - File dispute directly via `arbitration.dispute` (E6). WTS evidence of the stall strengthens the case.
-5. If no arbitration available → funds are escrowed indefinitely. This is the worst-case scenario flagged at E3.
-
-**Prevention**: At R3 (E3), the combination "no user-operable path from critical node" should be 🔴. Never proceed without explicit user acknowledgment AND a Messenger-negotiated commitment from the provider to act within a timeframe.
-
-### F4: Refund Path Blocked
-
-**Trigger**: User wants to exit the order, but the refund path (100%→Order Allocator) either doesn't exist (E5) or is gated by a Guard the user cannot satisfy (E4).
-
-**Diagnosis**:
-- E5 showed no 100%→Order Allocator → no refund mechanism was designed.
-- Refund path exists but Guard requires conditions the user doesn't meet (e.g., provider-issued passport).
-- Refund path is provider-operated (`namedOperator !== ""`) and provider refuses to advance.
-
-**Recovery**:
-1. Confirm from R5 checkpoint whether any refund mechanism exists.
-2. If refund path exists but Guard blocks:
-   - Try `gen_passport` — if Guard is self-satisfiable (e.g., token holding), this works.
-   - If Guard requires provider action → provider is blocking refund. Document via Messenger.
-3. If no refund mechanism:
-   - File arbitration dispute (D3). The absence of a refund path strengthens the case if the provider also failed to deliver.
-   - WTS evidence of provider non-delivery is critical.
-4. If arbitration also unavailable (E6 empty) → funds are escrowed indefinitely. This is the 🔴 no-refund + no-arb scenario flagged at E3.
-
-**Prevention**: At R3/R5, "no refund + no arb" is a hard 🔴. Never proceed without explicit user acknowledgment of the worst-case outcome.
-
-### F5: Arbitration Rejected / Unavailable
-
-**Trigger**: User files a dispute via `arbitration.dispute`, but the Arbitration service is paused, the fee is prohibitive, or the voting structure is closed.
-
-**Diagnosis**:
-- E6 showed `bPaused === true` → Arbitration service is suspended.
-- `fee` is higher than the disputed amount → not economically viable.
-- `voting_guard` is closed (specific voters only) and may be biased toward the provider.
-
-**Recovery**:
-1. Re-check E6 — are there other Arbitration services in `arbitrations[]`? Batch query them.
-2. If all are paused or prohibitively expensive → inform user. No on-chain recourse.
-3. If voting structure seems biased → document via WTS, consider off-chain escalation.
-4. If user already paid the dispute fee and Arb is paused → fee may be lost. Check `onchain_events` for Arb state.
-5. If Arb is active but voting is slow → check deadline settings. Arbitrator sets voting deadline.
-
-**Prevention**: At R6 (E6), verify at least one non-paused Arbitration service with a reasonable fee BEFORE purchase. If all are paused or expensive, flag as ⚠️ or 🔴.
-
-### F6: WIP Hash Mismatch Discovered Post-Purchase
-
-**Trigger**: User verified WIP hash at E2 (R2) and it matched. After purchase, the seller altered the WIP file and the hash no longer matches.
-
-**Diagnosis**:
-- Seller updated the WIP file post-publish without updating the on-chain hash.
-- Or: seller published a different WIP than what was verified (rare, but possible if verification was skipped).
-- The on-chain `wip_hash` is immutable after Service publish — any change to the WIP file is detectable.
+> E3→E4→E5 is a strict chain. E6-E10 run in parallel after E1.
 
-**Recovery**:
-1. Re-run `wip_file` → `op: "verify"` with the current WIP file and the on-chain `wip_hash`.
-2. If verification fails → the seller has altered the product evidence. This is a red flag for arbitration.
-3. Generate WTS evidence of:
-   - The original verification result (if logged).
-   - The current WIP file and hash mismatch.
-4. File arbitration dispute (D3). WIP hash mismatch is strong evidence of seller bad faith.
-5. If the order is still in progress → try to advance to a refund path (D4) before the provider collects.
+### ⚠️ Critical Attention Items
 
-**Prevention**: Always verify WIP hash at E2 (R2) and re-verify immediately before purchase at R8/R9. Log the verification result in the checkpoint for future evidence.
+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.
 
 ---
 
-## Tier Layering
-
-### Novice — Guided E1-E10 Walkthrough
-
-**Profile**: First-time buyer. Unfamiliar with WoWok concepts. Needs step-by-step guidance through due diligence.
-
-**AI Behavior**:
-- Execute E1-E10 in strict order. Explain each step's purpose before running it.
-- Use simple language. Avoid jargon. Translate Machine forwards into plain-English workflow descriptions.
-- Render the Pre-Purchase GATE table visually at R8.
-- Confirm every decision explicitly. Default to conservative (any ⚠️ → ask user to acknowledge).
-- For Guards: only present 🟢 Simple and 🟡 Complex. For 🔴 Ambiguous, recommend declining purchase.
-- For Messenger: guide through `send_message` step-by-step. Do not assume familiarity.
-- For order creation: show the confirmation template from [wowok-safety](../wowok-safety/SKILL.md). Wait for explicit "yes" before `service.buy`.
-
-**Typical Journey**: R1 (browse) → R2-R7 (guided E1-E10) → R8 (GATE decision) → R9 (first order) → R10 (handoff with clear next steps).
-
-### Advanced — Direct Phase Execution with Custom Evaluation
-
-**Profile**: Experienced buyer. Understands WoWok concepts. Wants to run due diligence efficiently with custom risk thresholds.
-
-**AI Behavior**:
-- Execute E1-E10 but allow the user to skip items they've pre-evaluated.
-- Present Machine JSON analysis concisely — forward classification table, no step-by-step explanation.
-- For Guards: present all three levels (🟢🟡🔴). For 🔴 Ambiguous, export the file and let the user review independently.
-- Allow custom risk thresholds (e.g., "I'm OK with 15% dispute rate" or "I don't need arbitration for orders under 10 WOW").
-- For Messenger: assume familiarity. Only intervene for WTS evidence generation.
-- For order creation: show the operation, confirm, execute. Minimal hand-holding.
-- Support batch evaluation: if the user provides multiple Service candidates, run E1-E10 on all and present a comparison table.
-
-**Typical Journey**: R1 (direct Service ID) → R2-R7 (batch E1-E10 with custom thresholds) → R8 (GATE decision with comparison) → R9 (order creation) → R10 (handoff to operations).
-
-### Expert — Multi-Service Portfolio & Risk Modeling
-
-**Profile**: Power user. Manages multiple orders across Services. Wants portfolio-level risk analysis and custom workflows.
-
-**AI Behavior**:
-- Support portfolio queries: "Show me all my active orders and their current node states."
-- Cross-Service comparison: normalize E1-E10 results into a risk score. Rank candidates.
-- Custom Guard analysis: for 🔴 Ambiguous Guards, attempt partial evaluation using `wowok_buildin_info` and `onchain_table_data` to resolve dynamic dependencies.
-- Machine path optimization: for multi-forward nodes, compute the optimal path based on user's Guard satisfaction and financial outcome (E5).
-- Arbitration strategy: evaluate multiple Arbitration services (E6) and recommend the best one based on fee, voting structure, and historical dispute resolution speed (from `onchain_events`).
-- WTS evidence pipeline: automate `generate_wts` + `sign_wts` for all Messenger conversations related to an order. Maintain an evidence library.
-- Discount hunting: proactively query `onchain_received` for active discounts before order creation.
-- Fund management: track escrowed funds across all orders. Alert when compensation funds are near lock expiry.
+## Appendices (Progressive Disclosure)
 
-**Typical Journey**: R1 (portfolio query) → R2-R7 (automated E1-E10 with risk scoring) → R8 (comparison table + recommendation) → R9 (batch order creation with discounts) → R10 (portfolio dashboard handoff).
+> The following sections have been extracted to [APPENDIX.md](./APPENDIX.md) for on-demand loading:
+> - Dialogue Scripts (R1-R10) — guided conversation scripts
+> - Decision Trees — branching logic reference
+> - Failure Playbooks — recovery scenarios
+> - Tier Layering — expertise-tier based guidance
+> - Phase 3 Integration — information puzzle + risk scoring + preference matching + game strategy + post-purchase playbook
+>
+> Load APPENDIX.md when the user needs guided dialogue, recovery help, or tier-specific guidance.