@wowok/skills 3.2.3 → 3.2.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wowok/skills",
-  "version": "3.2.3",
+  "version": "3.2.5",
   "description": "WoWok AI Skills for Claude Code, Codex, Gemini CLI, Qwen Code, Grok Build, OpenCode, Google Antigravity, Cursor, Devin Desktop (formerly Windsurf), Trae, CodeBuddy, WorkBuddy, Qoder, Cline, Kilo Code and GitHub Copilot - dialogue orchestration layer on top of the WoWok MCP server (rules/reference knowledge is served by MCP directly since v2.0.0)",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/wowok-auditor/SKILL.md

@@ -2,7 +2,7 @@
 name: wowok-auditor
 description: "WoWok pre-publish auditor — the static-analysis Skill that verifies Guard completeness, Machine soundness, fund-flow safety, permission consistency, and publish readiness BEFORE any irreversible publish operation (Service publish, Machine publish, Allocator binding freeze). This Skill is the orchestration guide for the L4 Harness Verify Loop. It does not mutate objects. It triggers the MCP risk engine, gathers evidence, and presents a pass/warn/fail report plus a publish decision. Use when: User is about to publish a Service, Machine, or lock an Allocator set; User asks to \"audit\", \"verify\", \"review\", \"check before publish\"; L4 Harness Verify Loop is invoked before an irreversible operation; User mentions \"fund flow\", \"refund path\", \"allocation sum\", \"guard completeness\"; User mentions \"machine cycle\", \"unreachable state\", \"permission index conflict\"; User wants a pre-publish go/no-go decision; A publish operation failed and root-cause analysis is needed."
 metadata:
-  version: "2.1.1"
+  version: "2.2.0"
   role: shared
   related: "wowok-planner, wowok-provider, wowok-machine"
 ---
@@ -37,10 +37,11 @@ This Skill keeps only **when to run the audit, how to call it, and how to read t
 
 Run an audit immediately before any irreversible operation:
 
-1. **Service publish** — machine bound + published, allocators locked, arbitration/compensation invariants, buy_guard, contact, permission indices.
-2. **Machine publish** — nodes/pairs/forwards become immutable afterward.
-3. **Service fund-template lock** — `order_allocators` (the order distribution template and its trigger guards) is a Service create/update FIELD that becomes permanently immutable at `publish=true`; there is no separate bind op.
-4. **Post-failure root-cause analysis** — a publish/assert failed (e.g. `E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND`, `E_ARBITRATION_PERMISSION_CONFLICT`); re-run to identify every remaining blocker, not just the one that aborted.
+1. **Template adoption (earliest gate)** — before a build plan is even generated from an industry archetype template: `benchmark_migration_operation` action=`template_scan` runs the pre-deploy risk scan (same rule surface as the on-chain analyze, plus the template scanner's static trust-mechanism checks). `passed: false` (any CRITICAL finding) blocks `template_generate` / `migration_apply` at the MCP level — report the red flags and stop; do not proceed to object planning.
+2. **Service publish** — machine bound + published, allocators locked, arbitration/compensation invariants, buy_guard, contact, permission indices.
+3. **Machine publish** — nodes/pairs/forwards become immutable afterward.
+4. **Service fund-template lock** — `order_allocators` (the order distribution template and its trigger guards) is a Service create/update FIELD that becomes permanently immutable at `publish=true`; there is no separate bind op.
+5. **Post-failure root-cause analysis** — a publish/assert failed (e.g. `E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND`, `E_ARBITRATION_PERMISSION_CONFLICT`); re-run to identify every remaining blocker, not just the one that aborted.
 
 Scope adapts to blast radius: a single Service with no Machine skips machine checks automatically; a stack with cross-Machine supply chains runs the full chain. The engine derives applicable checks from the objects — do not hand-pick rules.
 

package/wowok-onboard/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: wowok-onboard
-description: "WoWok First-Touch Onboarding — guides a NEW user from a vague first prompt to their first published Service: a Review opening, then AT MOST 8 mandatory business questions (never technical field prompts), then a dependency-aware auto-build (reuse / customize / discover). Every decision (industry, network, location, token, pricing, workflow, fund distribution, arbitration) is framed as who-wins-what and why. Produces Permission + Service + Machine + Progress + Guards + Allocation + Contact + Arbitration, verified by a test order. Not for existing merchants tuning operations — use wowok-provider. Use when: User is new to WoWok and wants to set up a service; User says \"open a shop\", \"create a service\", \"start selling\", \"onboard\"; User has no published Service yet; User asks \"what's next\" after account creation; User resumes an interrupted onboarding."
+description: "WoWok First-Touch Onboarding — guides a NEW user from a vague first prompt to their first published Service: a Review opening, then AT MOST 8 mandatory business questions (never technical field prompts), then a dependency-aware auto-build (reuse / customize / discover). Every decision (industry, network, location, token, pricing, workflow, fund distribution, arbitration) is framed as who-wins-what and why. Produces Permission + Service + Machine + Progress + Guards + Allocation + Contact + Arbitration, verified by a test order. Not for existing merchants tuning operations — use wowok-provider. Use when: User is new to WoWok and wants to set up a service; User says \"open a shop\", \"create a service\", \"start selling\", \"onboard\"; User wants to build from an industry template or migrate an existing store (\"migrate my shop\"); User has no published Service yet; User asks \"what's next\" after account creation; User resumes an interrupted onboarding."
 metadata:
-  version: "2.1.0"
+  version: "2.2.1"
   role: shared
   related: "wowok-provider, wowok-machine"
 ---
@@ -27,9 +27,19 @@ Take a new merchant from zero to first published Service via a **Review opening
 | Safety + Guard/Machine/Arbitration design rules | `schema_query` `get_safety_rules` / `get_guard_design_patterns` |
 | Publish readiness (CRITICAL/WARN findings) | `goal_operation` action=`aggregate_risks` |
 | Multi-round memory (decisions/feedback) | `goal_operation` (Goal + TaskProcess streams) |
+| Industry archetype templates + pre-deploy risk scan + competitor migration | `benchmark_migration_operation` (`template_list` / `template_get` / `template_scan` / `template_generate` / `migration_import` / `migration_review` / `migration_apply`) |
 
 ---
 
+## Template & migration fast paths
+
+Two entry points skip the 8-question discovery (the MCP owns the shape; this skill keeps the confirmation rhythm):
+
+1. **Template build** — the user wants to build "like the `<industry>` leader/challenger model": `template_list` (optional industry filter) → `template_get` → `template_scan` (pre-deploy risk scan; CRITICAL blocks) → `template_generate` (creation plan via the merchant-guide pipeline; never executes on-chain). Templates are editable MD files (`.wowok/industry/<industry>/templates/<variant>.md` — the client industry drawer tree); the template's `user_inputs` are the ONLY questions left to ask — business-framed — then continue with the normal auto-build.
+2. **Competitor migration** — the user hands over an existing store URL/description: `migration_import` (`description` required; `url` is provenance only) → `migration_review` (surface mapped / unmapped / manual_review + WoWok advantages + role assessment for user confirmation) → `migration_apply` (scan-first; creation plan only; testnet unless the user explicitly confirms mainnet). Every `manual_review` entry is an explicit user decision — never resolve it silently.
+
+Both paths merge back into the dependency chain below at "auto-build & finish".
+
 ## Non-negotiable interaction rules
 
 1. **Business-first**: every question is "what this means for you and your customer", never a technical field prompt. Translate defaults into consequences; offer them as recommendations.

package/wowok-order/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wowok-order
-description: "WoWok Buyer Guide — TWO lifecycles in one skill: 1. PROSPECT (prospect due diligence, pre-purchase): E1-E11 due diligence + consensus building + trust-score synthesis, ending in a buy/no-buy decision. 2. CUSTOMER (in-order fulfillment, post-order): order creation, progress advancement, fund management, and arbitration. For suppliers presenting to Demands, see wowok-supplier. For process operators executing workflow forwards, see wowok-collaborator. Use when: User is a potential buyer evaluating a service BEFORE purchasing (prospect); User is a customer/buyer placing or managing orders (customer); User wants to evaluate services, WIP, guards, allocations, arbitration; User needs to communicate with sellers via Messenger; User asks about order progress, payments, or refunds; User wants to file disputes or arbitration claims; User mentions \"buy\", \"order\", \"purchase\", \"refund\", \"dispute\", \"arbitration\", \"due diligence\"."
+description: "WoWok Buyer Guide — TWO lifecycles in one skill: 1. PROSPECT (prospect due diligence, pre-purchase): E1-E11 due diligence + consensus building + graph-evaluation synthesis, ending in a buy/no-buy decision. 2. CUSTOMER (in-order fulfillment, post-order): order creation, progress advancement, fund management, and arbitration. For suppliers presenting to Demands, see wowok-supplier. For process operators executing workflow forwards, see wowok-collaborator. Use when: User is a potential buyer evaluating a service BEFORE purchasing (prospect); User is a customer/buyer placing or managing orders (customer); User wants to evaluate services, WIP, guards, allocations, arbitration; User needs to communicate with sellers via Messenger; User asks about order progress, payments, or refunds; User wants to file disputes or arbitration claims; User mentions \"buy\", \"order\", \"purchase\", \"refund\", \"dispute\", \"arbitration\", \"due diligence\"."
 metadata:
   version: "2.1.0"
   role: customer
@@ -22,7 +22,7 @@ metadata:
 | **Prospect** | You have NOT ordered yet | Phase 1 (E1–E11) + Phase 2 | buy / no-buy decision |
 | **Customer** | You are the Order `builder` | Phase 3–6 + Fund Management | funds withdrawn / dispute resolved |
 
-Prospect analysis is computed by MCP `trust_score` (`depth: "preorder"`) + `evaluation_operation`; this skill only keeps the dialogue flow and the user-facing gates. The customer lifecycle is on-chain (Order/Progress/Allocation/Arb).
+Prospect analysis is computed by MCP `query_toolkit` (`query_type: "onchain_topology"`, the graph evaluation) + `evaluation_operation`; this skill only keeps the dialogue flow and the user-facing gates. The customer lifecycle is on-chain (Order/Progress/Allocation/Arb).
 
 ## Ground Rules (apply to every phase)
 
@@ -43,7 +43,7 @@ Prospect analysis is computed by MCP `trust_score` (`depth: "preorder"`) + `eval
 `query_toolkit` → `onchain_objects` for the service; save `bPublished`, `bPaused`, `sales`, `machine`, `buy_guard`, `customer_required`, `arbitrations`, `compensation_fund`, `compensation_lock_duration`, `order_allocators`, `um`.
 - `bPublished === false` or `bPaused === true` → 🔴 ABORT.
 
-Fast pre-screen: `trust_score` with default `depth: "evaluate"`; 🔴 `risk_score < 50` → offer early abort, skip E2–E10.
+Fast pre-screen: `query_toolkit` `{ query_type: "onchain_topology", focus: "<service_id>" }`; 🔴 `evaluation.risk.total < 50` → offer early abort, skip E2–E10.
 
 ### E2 — Product / WIP
 From E1 `sales[]`, skip `suspension === true`. When `wip_hash` is non-empty it is a buy-side MUST: verify with `wip_file` `{type:"verify", wipFilePath, hash_equal}` before purchase.
@@ -83,9 +83,9 @@ From E1: `compensation_fund`, `compensation_lock_duration`. Balance below planne
 `onchain_objects` for E1 `um`: `um === null` → 🔴 ABORT; `ims[]` empty → 🔴 no Messenger; active IMs → proceed.
 
 ### E9 — Chain reputation
-The aggregate view is already computed inside `trust_score` (reviews dimension) and `query_toolkit relationship_profile` (derived relationships) — present those rather than hand-aggregating.
+The aggregate view is already computed inside the `onchain_topology` graph evaluation (trust dimension) and `query_toolkit relationship_profile` (derived relationships) — present those rather than hand-aggregating.
 Only when raw evidence is needed (all reads batched, ≤50/batch): `onchain_table_data` `onchain_table_item_entity_linker` (provider address → `votes[]` {who, like, dislike, favor}) + `onchain_table_data` `onchain_table_item_object_linker_tx` (Service address → recent binding Orders, FIFO 0xaaf window — lossy) → dispute rate / repeat-buyer ratio; >10% dispute → ⚠️.
-Presenter history (merchant active on Demands): aggregate `onchain_events` `DemandFeedbackEvent` filtered by the merchant's Service, or `onchain_table_data` `onchain_table_item_demand_presenter` per Demand (row carries `acceptance_score`, null = unrated); pass as `presenter_history` to `evaluation_operation` (`service_risk` / `demand_match`). Omit when no presenter activity (neutral without history).
+Presenter history (merchant active on Demands): aggregate `onchain_events` `DemandFeedbackEvent` filtered by the merchant's Service, or `onchain_table_data` `onchain_table_item_demand_presenter` per Demand (row carries `acceptance_score`, null = unrated); pass as `presenter_history` to `evaluation_operation` (`demand_match`). Omit when no presenter activity (neutral without history).
 
 ### E10 — Privacy matching (LocalInfo)
 From E1 `customer_required[]` (e.g. name/phone/shipping_address):
@@ -94,11 +94,11 @@ From E1 `customer_required[]` (e.g. name/phone/shipping_address):
 3. Persist new values with `local_info_operation` `add` (100% local, never on-chain).
 > ⛔ Never transmit any private item without explicit per-item confirmation. Transmission is Messenger only (Phase 2).
 
-### E11 — Trust-score synthesis
-`trust_score` `{ service, depth: "preorder", order_amount }` → score + per-dimension risks + preorder advice (confidence, game strategies, preference match, industry risks, `blocking_reminders`). Non-empty `blocking_reminders` → ⛔ resolve with the user before Phase 2. Compare candidates with `compare_with` (1–9, same depth): a `comparison` block with per-metric bests, **no overall ranking**.
+### E11 — Graph evaluation synthesis
+`query_toolkit` `{ query_type: "onchain_topology", focus: "<service_id>" }` → `evaluation` = `trust` + `risk` (each a 0-100 `total` with `level`/`breakdown`/`red_flags`/`blocked`), `completeness`, `coverage` slots, and `unverified` rules (data gaps are never scored as low). ⛔ `evaluation.risk.blocked` (critical red flags) → resolve with the user before Phase 2. Compare candidates by running the same query per service: present per-metric bests, **no overall ranking**.
 
 ### Pre-purchase gate
-🔴 Abort: E1 unpublished/paused · E8 `um=null` · E3 no-refund + E6 no-arb · E4 ambiguous Guards (user review) · E11 unresolved `blocking_reminders`. Every ⚠️ = explain and wait. All clear → Phase 2.
+🔴 Abort: E1 unpublished/paused · E8 `um=null` · E3 no-refund + E6 no-arb · E4 ambiguous Guards (user review) · E11 `evaluation.risk.blocked` unresolved. Every ⚠️ = explain and wait. All clear → Phase 2.
 
 **Dependency**: E1 first; E2/E8/E10/E7/E6 parallel after E1; E3→E4→E5 strict chain; E9 follows E3; E11 last (aggregates everything).
 
@@ -167,4 +167,4 @@ When `customer_intelligence` is ON (default), order/query responses carry `seman
 - Red lines: no arb + no refund path, OR `compensation_ratio < 0.5`. Post-purchase: monitor refund triggers, WIP hash mismatch, merchant unreachable (>3d warn → >7d arb), evidence ≥3 items.
 - Runtime toggle: `config_operation` `action:"toggle" service:"order_monitor"` (default OFF; enable when active orders exist).
 
-Plug-in `evaluation_operation` (read-only; read results, don't recompute): `service_risk` (4-dimension risk, inject `requirements`/`overrides`), `demand_match` / `service_match` (rank vs capability vector), `capability_gap`, `compose_service`, `node_game` / `arb_game` (best-move + payoff; pair with `query_toolkit participation_radar` output). The role decides and acts.
+Plug-in `evaluation_operation` (read-only; read results, don't recompute): `demand_match` / `service_match` (rank vs capability vector), `capability_gap`, `compose_service`, `node_game` / `arb_game` (best-move + payoff; pair with `query_toolkit participation_radar` output). The role decides and acts.

package/wowok-output/SKILL.md

@@ -22,6 +22,7 @@ Post-process every WoWok tool response before showing it: resolve addresses, for
 
 Both environments:
 - **NEVER hand-truncate with `…`** (`0x00f6…a5839` is forbidden — not resolvable, not copyable). SHORTID is the only compact form.
+- **Copy addresses VERBATIM from the tool result — never retype from memory.** A silently dropped/duplicated hex char (observed failure: 64→62 hex, the address still LOOKS complete) makes the value unresolvable and pointing at nothing. Self-check before emitting: every address you write is `0x` + exactly 64 hex chars.
 - The full address is always present in the tool result in context, so a name/SHORTID display loses nothing.
 - Named → name ONLY, never `name 10EF-A11` and never append an id.
 - **Hash ≠ address** (first-byte discipline): only 32-byte hex whose first byte is `0x00` (user), `0x10`–`0x24` (typed objects) or `0xf1` (regular objects) can exist on-chain. Merkle roots, plaintext/file hashes and other digests have a random first byte — they are NOT addresses: never name-resolve or SHORTID them as if they were. ALWAYS emit hashes as `` `hash:0x…` `` (inline code, literal `hash:` prefix, no space) — NEVER bare hex: the client renders the marked form as raw text (no chip, no icon) and copy strips the marker back to the bare hex.

package/wowok-planner/SKILL.md

@@ -2,7 +2,7 @@
 name: wowok-planner
 description: "WoWok Planning Skill — the planning component of the L4 Harness Plan Loop. Converts natural-language intent into an executable Object Dependency Graph (ODG) plus a phased plan. Deterministic-first: rule tables and scenario templates drive planning; the LLM only clarifies intent. Produces an ODG consumed by the Harness execution loop, with checkpoints between phases. Not for direct execution — hand off to wowok-onboard or wowok-provider once the ODG is confirmed. Use when: User describes a new service intent and needs a build plan; the Harness opens a Plan Loop cycle; User asks \"what do I need to create to support X\"; User wants to reuse existing objects for a new service; User asks for a dependency graph or execution phases; User resumes an interrupted planning session."
 metadata:
-  version: "2.1.0"
+  version: "2.2.0"
   role: shared
   related: "wowok-onboard, wowok-auditor, wowok-provider"
 ---
@@ -20,9 +20,10 @@ Converts natural-language intent into an executable, dependency-ordered build pl
 Do not invent a plan format or gate names — the MCP owns the artifacts:
 
 1. **Industry** (optional first): `industry_pack_operation` `recommend_industry` with the intent text; confirm one of the returned modes (`list_modes` to see all; `derive_user_mode` to fork a custom one).
-2. **Guided wizard (default for merchants)**: `merchant_guide` — a stateless 10-step wizard (intent → industry → roles → deliverables → payment → trust → blueprint → score preview → harness checks → **creation_plan**). Pass the opaque `guide_state` back UNCHANGED each turn with the user's `guide_confirm`. Step 10 returns a topological `creation_plan` (order / object_type / depends_on / operation_hint) computed from the semantic graph — that order IS the plan.
-3. **Object-level pipeline (advanced / harness)**: `analyze_intent` (C1: parsed intent, per-object puzzle snapshots, missing dimensions, `recommended_creation_order`) → `aggregate_risks` (C2: blocking RISK status — pass the puzzles through UNCHANGED) → `trace_substeps` (C3: substep DAG + coherence verdict). Omit `puzzles` and pass `intent` to run C1→C2 in one call.
-4. **Materialize after GO**: create objects in `creation_plan` order via `onchain_operations` (that belongs to wowok-onboard / wowok-provider), then pass the pre-publish gate (wowok-auditor).
+2. **Template / migration fast path** (when the intent matches a known archetype or an existing store): `benchmark_migration_operation` — `template_list` / `template_get` / `template_scan` (pre-deploy risk scan; CRITICAL blocks) / `template_generate`, or `migration_import` → `migration_review` → `migration_apply` for a competitor store. Both return a merchant-guide `creation_plan` (scan-first; never executes on-chain; testnet unless the user explicitly confirms mainnet) — that plan IS the ODG, so skip steps 3-4 below unless the user wants a custom shape.
+3. **Guided wizard (default for merchants)**: `merchant_guide` — a stateless 10-step wizard (intent → industry → roles → deliverables → payment → trust → blueprint → score preview → harness checks → **creation_plan**). Pass the opaque `guide_state` back UNCHANGED each turn with the user's `guide_confirm`. Step 10 returns a topological `creation_plan` (order / object_type / depends_on / operation_hint) computed from the semantic graph — that order IS the plan.
+4. **Object-level pipeline (advanced / harness)**: `analyze_intent` (C1: parsed intent, per-object puzzle snapshots, missing dimensions, `recommended_creation_order`) → `aggregate_risks` (C2: blocking RISK status — pass the puzzles through UNCHANGED) → `trace_substeps` (C3: substep DAG + coherence verdict). Omit `puzzles` and pass `intent` to run C1→C2 in one call.
+5. **Materialize after GO**: create objects in `creation_plan` order via `onchain_operations` (that belongs to wowok-onboard / wowok-provider), then pass the pre-publish gate (wowok-auditor).
 
 ## Checkpoints & resumability
 

package/wowok-provider/SKILL.md

@@ -2,7 +2,7 @@
 name: wowok-provider
 description: "WoWok Service Provider — the canonical skill for service providers (merchants, sellers) to build, operate, and manage commercial services on WoWok. Covers service design (WIP products, Machine workflows, Allocator strategies), trust mechanisms (compensation funds, arbitration), customer attraction (discounts, rewards, supply chain promises), and order fulfillment. For customers placing orders, see wowok-order. For arbitrators, see wowok-arbitrator. Use when: User is a service provider/merchant/seller on WoWok; User wants to create a commercial service/marketplace; User wants to design workflow (Machine) for order processing; User wants to set up fund distribution strategies (Allocators); User wants to configure trust mechanisms (compensation, arbitration); User wants to handle order fulfillment and customer service; User mentions \"create service\", \"merchant\", \"seller\", \"provider\", \"workflow design\", \"compensation\", \"arbitration\"."
 metadata:
-  version: "2.1.0"
+  version: "2.2.1"
   role: provider
   related: "wowok-machine, wowok-messenger"
 ---
@@ -20,6 +20,7 @@ Do not re-derive these — the server applies them and returns findings/prompts:
 
 - **Pre-publish risk audit**: `goal_operation` action=`aggregate_risks` over your planned objects (safety rules, guard design, machine topology). Knowledge access: `schema_query` actions `get_safety_rules`, `get_guard_design_patterns`, `get_tool_reference`.
 - **Guided build pipeline** (optional, recommended for non-trivial services): `industry_pack_operation` (recommend_industry / list_modes / derive_user_mode) and `goal_operation` action=`merchant_guide` (stateless 10-step wizard; the final step emits a topologically ordered `creation_plan`). This skill's lifecycle below is the manual path to the same result.
+- **Industry archetype templates + one-click competitor migration**: `benchmark_migration_operation` — `template_list` / `template_get` / `template_scan` (pre-deploy risk scan; CRITICAL blocks) / `template_generate`, and `migration_import` → `migration_review` → `migration_apply` for migrating an existing store (URL/description → MigrationLog → scan-first creation plan; testnet unless the user explicitly confirms mainnet). Templates are editable MD files (`.wowok/industry/<industry>/templates/<variant>.md` — the client industry drawer tree) whose `user_inputs` are the business questions to confirm — the fast path that feeds the same lifecycle below.
 - **WIP network-deployment gate**, publish-time L1/L2 lock checks, and the compensation-fund-requires-arbitration pre-check are hard-enforced inside `onchain_operations`.
 - **Execution routing for live orders** comes from `query_toolkit` query_type=`participation_radar` → `operable[].recommended_call`. Never hand-pick `order.progress` vs `progress.operate`.
 

package/wowok-supplier/SKILL.md

@@ -2,7 +2,7 @@
 name: wowok-supplier
 description: "WoWok Supplier — the canonical skill for suppliers (sub-order providers) who present their service to a Demand and fulfill the resulting sub-order. Covers demand discovery, service presentation (open or passport-gated), sub-order fulfillment via Progress, and settlement collection. The supplier is a PEER role with a two-sided position: deliver (to get paid) + collect (from the upstream merchant). For the merchant who owns the main Service, see wowok-provider. For the process operators executing the workflow, see wowok-collaborator. Use when: User wants to present their service to a Demand (open RFP or gated call); User is a sub-order provider / supplier fulfilling part of a transaction; User wants to collect settlement from an upstream merchant; User mentions \"supplier\", \"sub-order\", \"demand\", \"present service\", \"RFP\", \"fulfill sub-order\"."
 metadata:
-  version: "2.1.0"
+  version: "2.2.0"
   role: supplier
   related: "wowok-provider, wowok-machine, wowok-messenger"
 ---
@@ -19,7 +19,7 @@ metadata:
 Do not re-derive any of this — consume the tool output:
 
 - **Discovery → present-path bridge**: `evaluation_operation` action=`demand_present` enumerates Demands, matches THIS service, and returns each match with a `next` block — `operation` (`demand.present_service` vs `demand.present_service_with_passport`), `preconditions` checklist, and rationale. Read-only; the write still needs user consent.
-- **Ad-hoc ranking**: `demand_match` (one Demand vs candidate Services), `service_match` (one Service vs candidate Demands), `service_risk`. All accept an optional `presenter_history` (see reputation below).
+- **Ad-hoc ranking**: `demand_match` (one Demand vs candidate Services) and `service_match` (one Service vs candidate Demands). Both accept an optional `presenter_history` (see reputation below).
 - **Execution routing**: `query_toolkit` query_type=`participation_radar` returns `operable[].recommended_call` (tool/path/reason) for every forward the account can execute. Never hand-pick `order.progress` vs `progress.operate` yourself — no `recommended_call` means the forward is not yours to execute.
 - **Own-interest analysis**: the radar derives role `supplier` and attaches `supplier-interest` (fund_flow / responsibility / leverage / stakes). Present it neutrally; the supplier decides.
 
@@ -48,6 +48,8 @@ Payment is a two-hop waterfall: main order escrow → allocation → your sub-or
 
 ## Pre-flight: before presenting
 
+**Role check first**: a user arriving with "migrate my existing store / build like the `<industry>` challenger model" may be a supplier, not a merchant. `benchmark_migration_operation` `migration_import` returns a `role_assessment` (recommended role + rationale + alternatives) — when it recommends `supplier`, hand the build over to this skill's flow instead of the merchant lifecycle, and say so explicitly.
+
 Confirm with the user; never fabricate or auto-present:
 
 | # | Item | Notes |