@wowok/skills 3.1.1 → 3.1.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (12) hide show
  1. package/package.json +3 -2
  2. package/wowok-arbitrator/SKILL.md +10 -10
  3. package/wowok-auditor/SKILL.md +59 -72
  4. package/wowok-collaborator/SKILL.md +1 -1
  5. package/wowok-governance/SKILL.md +1 -1
  6. package/wowok-machine/SKILL.md +1 -1
  7. package/wowok-market/SKILL.md +2 -2
  8. package/wowok-messenger/SKILL.md +1 -1
  9. package/wowok-onboard/SKILL.md +11 -11
  10. package/wowok-planner/SKILL.md +4 -4
  11. package/wowok-provider/SKILL.md +11 -11
  12. package/wowok-supplier/SKILL.md +1 -1
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@wowok/skills",
3
- "version": "3.1.1",
3
+ "version": "3.1.2",
4
4
  "description": "WoWok AI Skills for Claude Code, Codex, Cursor, Windsurf, Trae, CodeBuddy, Qoder, Roo Code, 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)",
5
5
  "main": "dist/index.js",
6
6
  "types": "dist/index.d.ts",
@@ -33,7 +33,8 @@
33
33
  "postinstall": "node scripts/install.js",
34
34
  "audit:skills": "node scripts/validate-skills.mjs",
35
35
  "audit:length": "node scripts/check-skills-length.mjs",
36
- "check": "npm run build && npm run audit:skills && npm run audit:length"
36
+ "audit:drift": "node scripts/check-skill-mcp-drift.mjs",
37
+ "check": "npm run build && npm run audit:skills && npm run audit:length && npm run audit:drift"
37
38
  },
38
39
  "keywords": [
39
40
  "wowok",
package/wowok-arbitrator/SKILL.md CHANGED
@@ -59,18 +59,18 @@ User says "just make something up" → REFUSE and explain why each item matters.
59
59
 
60
60
  | # | Item | User Must Provide | Why Not Fabricate |
61
61
  |---|------|-------------------|--------------------|
62
- | **R1** | **Account** | Which account to operate from. Default `""` is fine. | Safe default exists |
63
- | **R2** | **Arbitration Name** | Service name. What kind of arbitration? | Your brand and reputation on-chain |
64
- | **R3** | **Fee** | How much per case? (e.g. "10 WOW per dispute") | IS your revenue model — you cannot guess pricing |
65
- | **R4** | **Voting Guard(s)** | Who votes and with what weight? Open voting (centralized) or Guard-based (decentralized)? | ⛔ Guards are **immutable after creation** — wrong design = create replacement Guard |
66
- | **R5** | **Usage Guard** | Who can file disputes? Public or restricted? | Controls your case volume and quality |
67
- | **R6** | **Contact (um)** | Messenger Contact name/ID for evidence exchange | Without this, customers cannot submit evidence — service is broken |
62
+ | **1** | **Account** | Which account to operate from. Default `""` is fine. | Safe default exists |
63
+ | **2** | **Arbitration Name** | Service name. What kind of arbitration? | Your brand and reputation on-chain |
64
+ | **3** | **Fee** | How much per case? (e.g. "10 WOW per dispute") | IS your revenue model — you cannot guess pricing |
65
+ | **4** | **Voting Guard(s)** | Who votes and with what weight? Open voting (centralized) or Guard-based (decentralized)? | ⛔ Guards are **immutable after creation** — wrong design = create replacement Guard |
66
+ | **5** | **Usage Guard** | Who can file disputes? Public or restricted? | Controls your case volume and quality |
67
+ | **6** | **Contact (um)** | Messenger Contact name/ID for evidence exchange | Without this, customers cannot submit evidence — service is broken |
68
68
 
69
69
  ### Information Collection Protocol
70
70
 
71
- Present checklist R1-R6 to user. Each item: "Reuse or create new? Provide details." Track status: [pending] / [confirmed: reuse <id>] / [confirmed: create]. ⛔ GATE: ALL R1-R6 must be [confirmed] before any on-chain action — NOT confirmed → STOP. Ask. Do NOT suggest creating arbitration.
71
+ Present checklist Steps 1-6 to user. Each item: "Reuse or create new? Provide details." Track status: [pending] / [confirmed: reuse <id>] / [confirmed: create]. ⛔ GATE: ALL Steps 1-6 must be [confirmed] before any on-chain action — NOT confirmed → STOP. Ask. Do NOT suggest creating arbitration.
72
72
 
73
- All subsequent on-chain operations use R1 (Account) as `env.account`.
73
+ All subsequent on-chain operations use Step 1 (Account) as `env.account`.
74
74
 
75
75
  ### Anti-Fabrication Rules (HARD Constraints)
76
76
 
@@ -176,7 +176,7 @@ Customer pays fee → locked in `Arb.fee` per case → `arb_withdraw()` transfer
176
176
 
177
177
  Arbitrator sets `indemnity` → Customer claims via `order.arb_claim_compensation` → Funds transfer from `service.compensation_fund` to Order.
178
178
 
179
- > **Note**: The compensation payout comes from the **provider's** compensation_fund, not the arbitrator's funds. Customers should assess the provider's fund balance before purchase — this is covered in [wowok-order](../wowok-order/SKILL.md) Phase 1.1.
179
+ > **Note**: The compensation payout comes from the **provider's** compensation_fund, not the arbitrator's funds. Customers should assess the provider's fund balance before purchase — this is covered in [wowok-order](../wowok-order/SKILL.md) E7 (Compensation Fund).
180
180
 
181
181
  ---
182
182
 
@@ -233,6 +233,6 @@ Providers list approved Arbitrations in their Service. Customers choose from thi
233
233
 
234
234
  ### Common Pitfalls
235
235
 
236
- Served by `wowok_buildin_info` action='common mistakes' + MCP `schema_query` action='get_safety_rules'. Key ones: paused Arbitration rejects disputes silently (verify `pause: false`); wrong Guard design is immutable (test with `gen_passport` first); non-finished withdrawal has a 30-day lock; always `verify_wts` before ruling.
236
+ Served by `wowok_buildin_info` info='common mistakes' + MCP `schema_query` action='get_safety_rules'. Key ones: paused Arbitration rejects disputes silently (verify `pause: false`); wrong Guard design is immutable (test with `gen_passport` first); non-finished withdrawal has a 30-day lock; always `verify_wts` before ruling.
237
237
 
238
238
  ---
package/wowok-auditor/SKILL.md CHANGED
@@ -1,105 +1,92 @@
1
1
  ---
2
2
  name: wowok-auditor
3
- 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 knowledge base for the L4 Harness Verify Loop. It does not mutate objects. It queries, exports, and rules — emitting a pass/warn/fail audit 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."
3
+ 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."
4
4
  metadata:
5
- version: "2.0.0"
5
+ version: "2.1.0"
6
6
  role: shared
7
7
  related: "wowok-planner, wowok-provider, wowok-machine"
8
8
  ---
9
9
 
10
10
  # WoWok Pre-Publish Auditor
11
11
 
12
- Static-analysis rules that gate every irreversible publish. The auditor never
13
- writes on-chain; it queries (`query_toolkit`, `onchain_events`), exports
14
- (`guard2file`, `machineNode2file`), evaluates rule tables, and emits a
15
- pass / warn / fail report. A FAIL blocks the publish in R10.
12
+ Read-only orchestration for the gate that precedes every irreversible publish.
13
+ The auditor never writes on-chain; it triggers the MCP risk engine, gathers
14
+ evidence, and presents a go / no-go decision. (R10 in MCP dialogue rounds is
15
+ the canonical **verify** round — a FAIL blocks publish there.)
16
16
 
17
- > **Role**: Auditor (read-only). The pre-write safety gate now lives in the MCP knowledge layer (`schema_query` action='get_safety_rules'), applied on every write; this auditor runs only on publish.
18
- > **Layer**: L3 Skill, knowledge base for L4 Verify Loop.
17
+ > **Role**: Auditor (read-only). Pre-write safety rules live in the MCP knowledge layer (`schema_query` action='get_safety_rules') and are applied on every write; this auditor drives the comprehensive pre-publish aggregation.
18
+ > **Layer**: L3 Skill, orchestration guide for the L4 Verify Loop.
19
19
  > **Related Skills**: [wowok-machine](../wowok-machine/SKILL.md) (Machine design), [wowok-onboard](../wowok-onboard/SKILL.md) (publish flow).
20
20
 
21
21
  ---
22
22
 
23
- ## MCP Knowledge Layer
23
+ ## What Lives Where (single source of truth)
24
24
 
25
- The following content has been pushed down to the MCP knowledge layer and is applied automatically — this Skill no longer duplicates it:
25
+ The machine-executable rules are NOT duplicated in this Skill — they evolve in MCP and this file would drift:
26
26
 
27
- | Content | Access via (MCP action) | Applied Via |
28
- |---------|--------------------------|-------------|
29
- | Safety rules (confirmation levels, immutability rules, object reuse rules) | `schema_query` action='get_safety_rules' | Pre-publish checks + `goal_operation` action='aggregate_risks' |
30
- | Machine-executable audit rules | auto-applied (not queryable) | `goal_operation` action='aggregate_risks' |
31
- | Guard completeness / Machine soundness / fund-flow risks | auto-applied (not queryable) | `goal_operation` action='aggregate_risks' |
27
+ | Content | Source (MCP) |
28
+ |---------|--------------|
29
+ | Safety rules (confirmation levels, immutability, object reuse) | `schema_query` action='get_safety_rules' |
30
+ | Guard completeness, Machine soundness, fund-flow safety, permission consistency, publish readiness | `goal_operation` action='aggregate_risks' (auto-applied) |
32
31
 
33
- This Skill keeps the **audit flow**, the **4 audit dimensions** (Guard completeness, Machine soundness, fund flow, publish readiness), and the **checklist structure** as the human-readable knowledge base for the L4 Harness Verify Loop. The MCP layer runs the machine-executable rule evaluation.
32
+ This Skill keeps only **when to run the audit, how to call it, and how to read the verdict**.
34
33
 
35
34
  ---
36
35
 
37
- ## Core Principles
36
+ ## When to Run
38
37
 
39
- 1. **Read-only**: The auditor never calls `onchain_operations` with `submission`. It only queries and exports. Mutations belong to the Skill being audited.
40
- 2. **Rule-driven**: Every check is a row in a rule table (GUARD_COMPLETENESS_RULES, MACHINE_SOUNDNESS_RULES, FUND_FLOW_RULES, PUBLISH_READINESS_RULES). Adding a check = adding a row, not editing control flow.
41
- 3. **FAIL blocks, WARN asks**: A FAIL verdict blocks R10 publish until fixed. A WARN verdict proceeds after explicit user acknowledgement. PASS is silent.
42
- 4. **Blast-radius first**: Before reporting, classify each issue by irreversibility — a Guard logic bug post-publish is permanent; an untested Guard is recoverable.
43
- 5. **Semantic-aware**: Use the `semantic` field returned by recent operations (`semantic.created`, `semantic.modified`, `semantic.released`, `semantic.events`) to cross-check that the intended roles were actually created/modified/released.
44
- 6. **Tiered**: A Tier-1 audit (single Service + single Guard) skips Machine soundness if no Machine is bound. Tier-3 runs every rule including cross-Machine dependency chains.
38
+ Run an audit immediately before any irreversible operation:
39
+
40
+ 1. **Service publish** — machine bound + published, allocators locked, arbitration/compensation invariants, buy_guard, contact, permission indices.
41
+ 2. **Machine publish** — nodes/pairs/forwards become immutable afterward.
42
+ 3. **Allocator-set freeze** (`order_allocators` bind) — fund-flow paths lock with the Service.
43
+ 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.
44
+
45
+ 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.
45
46
 
46
47
  ---
47
48
 
48
- ## Audit Rule Tables
49
+ ## How to Run
49
50
 
50
- ### GUARD_COMPLETENESS_RULES
51
+ ```
52
+ goal_operation action='aggregate_risks'
53
+ intent=<business intent text> # or pass 'puzzles' through from analyze_intent
54
+ planned_objects=[{object_type,is_new,name?}]
55
+ planned_operations=[{object_type,trigger:'create'|'publish',name?}]
56
+ severity_threshold='HIGH' # default HIGH
57
+ user_confirmed_high_risks=[...] # IDs acknowledged in a prior round
58
+ ```
51
59
 
52
- | Operation Type | Fund Flow? | Guard Required? | Audit Action |
53
- |---|---|---|---|
54
- | payment (negative amount) | Yes | Yes | FAIL if no Guard bound |
55
- | treasury deposit | Yes | Recommended | WARN if no Guard |
56
- | allocation execute | Yes | Yes | FAIL if no Guard |
57
- | service publish | No | No | PASS |
58
- | machine publish | No | No | PASS |
59
- | order create | Yes (escrow) | Yes | FAIL if no Guard on refund path |
60
- | progress forward (no fund) | No | Optional | PASS (skip) |
61
- | progress forward (fund release) | Yes | Yes | FAIL if no Guard on forward |
62
- | reward claim | Yes | Yes | FAIL if no Guard |
63
- | repository write | No | Recommended | WARN if no Guard |
60
+ Evidence-gathering (all read-only, done BEFORE presenting the verdict):
64
61
 
65
- ### MACHINE_SOUNDNESS_RULES
62
+ - `guard2file` / `machineNode2file` — export immutable backups of what is about to be published.
63
+ - `query_toolkit` (`onchain_objects`, table items) — verify current on-chain state (`bPublished`, balances, bound objects).
64
+ - `onchain_events` — confirm the state transitions claimed by recent operations.
65
+ - Use the `semantic` field of recent operation results (`semantic.created` / `.modified` / `.released` / `.events`) to cross-check that intended roles/objects were actually produced.
66
66
 
67
- | Check | Pass Condition | Fail Action |
68
- |---|---|---|
69
- | Acyclicity | No cycles in state graph | FAIL: cycle detected |
70
- | Single entry | Exactly one node with no inbound Pair | FAIL: multiple/zero entries |
71
- | Terminal reachability | All terminals reachable from entry | FAIL: unreachable terminal |
72
- | No dead-end non-terminals | Every non-terminal node has an outgoing Forward | FAIL: dead-end node |
73
- | No orphan non-entries | Every non-entry node has an incoming Pair | FAIL: orphaned node |
74
- | Forward permissions | Each forward has `permissionIndex` ≥ 1000 OR `namedOperator` set (or both) | WARN: missing permission; FAIL if neither |
75
- | Guard bindings | Each forward with fund flow has a Guard bound | FAIL: unguarded fund flow |
76
- | Threshold achievability | Each Pair's threshold is reachable by its Forwards' weights | WARN: dead branch (competing Pair always wins) |
77
-
78
- ### FUND_FLOW_RULES
79
-
80
- | Check | Pass Condition | Fail Action |
81
- |---|---|---|
82
- | Refund path exists | Every payment path has a corresponding refund path | FAIL: no refund path |
83
- | Allocation sum | Each Allocator's `sharing` array sums to 10000 (100%) | FAIL: allocation doesn't sum to 100% |
84
- | Treasury balance | Treasury has sufficient balance for pending allocations | WARN: low balance |
85
- | Gas coin separation | Gas coins (WOW) are not mixed with business tokens in allocations | WARN: gas coin in allocation |
86
- | Recipient type | Refund path uses `Entity`/`Signer` for known parties, `GuardIdentifier` for dynamic | WARN: ambiguous recipient |
87
- | Escrow symmetry | Order escrow amount equals sum of all Allocation paths from that order | FAIL: escrow mismatch |
67
+ Never call `onchain_operations` with `submission` from this role — fixes belong to the Skill being audited.
68
+
69
+ ---
88
70
 
89
- ### PUBLISH_READINESS_RULES
71
+ ## How to Read the Verdict
90
72
 
91
- | Check | Pass Condition | Fail Action |
73
+ `aggregate_risks` returns a blocking **status** plus per-finding severity (CRITICAL / HIGH / MEDIUM / LOW / INFO):
74
+
75
+ | Status | Meaning | Auditor action |
92
76
  |---|---|---|
93
- | Service unpublished | `bPublished === false` | PASS: ready to publish |
94
- | Machine published | Machine is published (if bound to Service) | FAIL: publish Machine first |
95
- | Guards tested | All Guards have a passing `gen_passport` test on record | WARN: untested Guard |
96
- | Permission configured | Permission object exists with correct indices for every Forward | FAIL: no Permission |
97
- | Allocators configured | `order_allocators` non-empty and each Allocator audited | FAIL: no Allocators |
98
- | User confirmation | User has explicitly confirmed publish intent | FAIL: no confirmation |
99
- | Compensation fund present | `compensation_fund` funded (recommended for trust) | WARN: empty fund |
100
- | Compensation fund invariant | If `compensation_fund > 0` then `arbitrations` MUST be non-empty (per service.move:494-496 `assert!(vector::length(&self.arbitrations) > 0, E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND)`) | FAIL: funded but no Arbitration bound |
101
- | order_allocators immutability | `order_allocators` set BEFORE publish (service.move:503 `assert!(!self.bPublished)`) — cannot be modified post-publish | FAIL: attempt to modify after publish |
102
- | machine immutability | `machine` bound BEFORE publish (service.move:633 `assert!(!self.bPublished)`) — cannot be modified post-publish | FAIL: attempt to modify after publish |
103
- | Backup export | `machineNode2file` + `guard2file` backups persisted | WARN: no backup |
77
+ | `RISK_PASSED` | No risk at/above threshold | Go — present the go decision |
78
+ | `RISK_BLOCKED` | CRITICAL present, or unacknowledged risk ≥ threshold (default HIGH) | No-go — list every blocker with its object + fix; do not publish |
79
+ | `RISK_PENDING_CONFIRM` | Only acknowledged-able HIGH risks remain | Explain each HIGH risk in business terms; proceed only after explicit user confirmation, then re-run with the risk IDs in `user_confirmed_high_risks` |
80
+ | `RISK_CANCELLED` | The risk session was cancelled | Treat as no-go until re-audited |
81
+
82
+ Presentation rules:
83
+
84
+ 1. **FAIL blocks, WARN asks, PASS is silent.** CRITICAL/blocked findings are hard stops fixed by the owning Skill; MEDIUM/LOW are surfaced as advisories.
85
+ 2. **Blast-radius first**: order findings by irreversibility — a post-publish Guard logic bug is permanent; an untested Guard or missing backup is recoverable.
86
+ 3. Report grouped by the four coverage dimensions — **Guard completeness, Machine soundness, fund flow, publish readiness** — and state explicitly which objects were in scope. The individual checks inside each dimension are whatever MCP currently evaluates; quote the finding text returned, never a local rule list.
104
87
 
105
88
  ---
89
+
90
+ ## Audit Report Contract
91
+
92
+ The user-facing report contains: scope (objects/operations audited), findings grouped by dimension with severity, the blocking status, required fixes vs acknowledged risks, and a final one-line decision: **GO / NO-GO / CONFIRM-THEN-GO**. It contains no transaction itself — the audited Skill performs the mutation after GO.
package/wowok-collaborator/SKILL.md CHANGED
@@ -50,7 +50,7 @@ Two sub-kinds (derived on-chain, never asserted):
50
50
 
51
51
  ## What You Can Execute Now
52
52
 
53
- Run `query_toolkit` query_type='participation_radar' with your account + the order's Progress. It returns:
53
+ Run `query_toolkit` query_type='participation_radar' with `radar_account` (your account) and `radar_targets: [{ progress: <the order's Progress object>, order: <the Order, optional but recommended> }]` (1–20 targets). It returns:
54
54
 
55
55
  - `operable` — forwards YOU can execute right now (permission / named-operator path).
56
56
  - `waiting_on` — what the workflow waits on from other roles.
package/wowok-governance/SKILL.md CHANGED
@@ -56,7 +56,7 @@ Rules of thumb:
56
56
  Fund stewardship across Treasury / Allocation / Reward / Payment.
57
57
 
58
58
  - **Treasury**: deposit joins coins in (a Payment receipt is minted); withdraw splits balance out — irreversible, and when an `external_guard` is set the guard must validate first. `query_toolkit` query_type='onchain_table_item_treasury_history' audits every flow (op 0 Withdraw / 1 Deposit / 2 Receive) with amount + guard + timestamp.
59
- - **Allocation**: runs distribute pool funds per sharing mode (Amount / Rate ‰ / Surplus). Review allocator guards periodically — a stale guard blocks legitimate distributions.
59
+ - **Allocation**: runs distribute pool funds per sharing mode (Amount / Rate in bps — base 10000 = 100% / Surplus). Review allocator guards periodically — a stale guard blocks legitimate distributions.
60
60
  - **Unclaimed payments**: recipients hold frozen CoinWrappers until they unwrap. The keeper `payment_unclaimed` scan owns this reminder surface — run `keeper_operation` to list claimable payments and nudge recipients via Messenger. NewPaymentEvent is deliberately NOT push-bridged, to avoid duplicate reminders (P2-4 channel split).
61
61
  - **Reward pools**: RewardFundEvent in / RewardClaimEvent out; a dry pool blocks claims — watch balances before announcing campaigns.
62
62
 
package/wowok-machine/SKILL.md CHANGED
@@ -41,7 +41,7 @@ This Skill keeps the **workflow conversation guidance**, **business flow design
41
41
 
42
42
  ## Machine Architecture
43
43
 
44
- **Machine** → **Nodes** → **Pairs** (`prev_node` ["" = entry, multiple allowed], `threshold` [required total forward weight to advance]) → **Forwards** (`name`, `weight`, `permissionIndex` | `namedOperator` [who can execute], `guard` [optional condition]).
44
+ **Machine** → **Nodes** → **Pairs** (`prev_node` ["" = the single entry pair — pair keys are unique on chain (`E_DUPLICATE_NODE_PREV`); its `forwards` vector may carry multiple forwards to different first nodes], `threshold` [required total forward weight to advance]) → **Forwards** (`name`, `weight`, `permissionIndex` | `namedOperator` [who can execute], `guard` [optional condition]).
45
45
 
46
46
  > All field types, limits, and valid values are in the MCP schema (`onchain_operations_machine`). This document focuses on design decisions **not captured** by the schema.
47
47
 
package/wowok-market/SKILL.md CHANGED
@@ -56,7 +56,7 @@ This Skill keeps the **market conversation flow** — discover → compare → t
56
56
  ## Phase 2: Compare & Trust
57
57
 
58
58
  - **Compare**: the `match_discover` result already surfaces per-service scores + reasons. Surface the top-N side-by-side; highlight differences, never force a single pick.
59
- - **Arbitrator trust**: `evaluation_operation` action=`arbitration_score` with the Arbitration `object` (history auto-fetched via `query_arbs`). Returns `trust` + `fairness` + `combined`. Use it when a merchant chooses which Arbitration to bind, or a customer judges a Service's arbitration guarantee.
59
+ - **Arbitrator trust**: `evaluation_operation` action=`arbitration_score` with the Arbitration `object` — the Arb case history is auto-fetched on-chain when omitted (pass `context_network` for the right network). Returns `trust` + `fairness` + `combined`. Use it when a merchant chooses which Arbitration to bind, or a customer judges a Service's arbitration guarantee.
60
60
 
61
61
  ---
62
62
 
@@ -71,7 +71,7 @@ This Skill keeps the **market conversation flow** — discover → compare → t
71
71
 
72
72
  - **Metrics**: `evaluation_operation` action=`market_metrics` → active services / open demands / disputes / supply-demand ratio.
73
73
  - **Anti-cheat**: `evaluation_operation` action=`anti_cheat` with a Service's orders/reviews/object-stack → returns negative-factor signals (fake order / fake review / shell merchant).
74
- - **Operations**: `evaluation_operation` action=`market_operations` with `op` = `journey_funnel` / `referral_attribution` / `customer_relationship`.
74
+ - **Operations**: `evaluation_operation` action=`market_operations` with `op` = `journey_funnel` / `referral_attribution` / `customer_relationship` / `dynamic_pricing`.
75
75
 
76
76
  ---
77
77
 
package/wowok-messenger/SKILL.md CHANGED
@@ -75,7 +75,7 @@ Two approaches, depending on need:
75
75
  - **Deep dive** — `watch_messages` with a specific `peerAddress` to view the full conversation with a particular counterparty. Supports keyword search, time-range filtering, direction filter, and status filter.
76
76
  - **Server sync** — `pull_messages` fetches the latest messages from the server into local storage (optional `limit` caps batch size). Use this first when the local view looks stale (e.g. after downtime or on a new device session), then read via `watch_conversations` / `watch_messages`. Pass `allAccounts: true` (or `accounts: [...]`, optional `concurrency`, default 5) to fan out across every messenger-enabled account in one call — the result is one entry per account `{account, pulled, messages, error?}` with per-account failure isolation.
77
77
 
78
- **Read boundary for attachments**: Attachment messages (those with `zipMetadata`) never expose their base64 payload in `watch_messages` / `watch_conversations` / `pull_messages` / `search_messages` output — `plaintext` is omitted and a byte-free `attachment` descriptor is attached instead (`kind`: image/video/audio/voice/file/wts/wip, `fileName`, `mimeType`, `size`, optional `caption`/`durationMs`/`width`/`height`). This prevents multi-megabyte base64 blobs from flooding every read. Bytes are fetched on demand only (see Save Attachments below).
78
+ **Read boundary for attachments**: Attachment messages (those with `zipMetadata`) never expose their base64 payload in `watch_messages` / `watch_conversations` / `pull_messages` output — `plaintext` is omitted and a byte-free `attachment` descriptor is attached instead (`kind`: image/video/audio/voice/file/wts/wip, `fileName`, `mimeType`, `size`, optional `caption`/`durationMs`/`width`/`height`). This prevents multi-megabyte base64 blobs from flooding every read. Bytes are fetched on demand only (see Save Attachments below). Keyword search is a `watch_messages` filter (`keyword`, plus `direction` / `status` / `startTime`-`endTime` filters) — there is no separate search operation.
79
79
 
80
80
  **Design note**: By default, retrieving messages auto-marks them as viewed (`viewedAt` timestamp). Set `skipAutoMarkViewed: true` if you want to peek without marking read.
81
81
 
package/wowok-onboard/SKILL.md CHANGED
@@ -23,12 +23,12 @@ The following content is pushed down to the MCP layer and applied automatically
23
23
  |---------|--------------------------|-------------|
24
24
  | Industry modes + expert description guidance | `industry_pack_operation` action='list_modes' / 'recommend_industry' (each mode now returns `location_sensitivity`, `trust_selling_points`, `build_notes`) | Q1 (industry) + Q5 (description optimization) |
25
25
  | Cross-network build detection + mainnet migration checklist | `query_toolkit` query_type='migration_preflight' | Q2 (testnet vs mainnet) |
26
- | Testnet faucet / mainnet bridge / airdrop / payment-token guidance | `wowok_buildin_info` action='funding guidance' / 'mainnet bridge tokens' | Q2 + Q4 |
26
+ | Testnet faucet / mainnet bridge / airdrop / payment-token guidance | `wowok_buildin_info` info='funding guidance' / 'mainnet bridge tokens' | Q2 + Q4 |
27
27
  | Third-party arbitrator discovery | `onchain_events` type='ArbitrationEvent' (dedupe by `object`) | Q8 (arbitration) |
28
28
  | Safety rules (immutability, confirmation, object reuse) | `schema_query` action='get_safety_rules' | pre-publish + `goal_operation` action='aggregate_risks' |
29
29
  | Guard / Machine / Arbitration / Treasury design rules | `schema_query` action='get_guard_design_patterns' | build + `aggregate_risks` |
30
- | Common mistakes (field/unit/workflow pitfalls) | `wowok_buildin_info` action='common mistakes' | tool calls (proactive warnings) |
31
- | Deployment checklist (publish readiness) | `goal_operation` action='aggregate_risks' | deployment-scanner D-01..D-20 |
30
+ | Common mistakes (field/unit/workflow pitfalls) | `wowok_buildin_info` info='common mistakes' | tool calls (proactive warnings) |
31
+ | Deployment checklist (publish readiness) | `goal_operation` action='aggregate_risks' (findings carry CRITICAL/WARN severity) + wowok-auditor pre-publish gates | before service/machine publish |
32
32
  | Multi-round memory (decisions / feedback / problems) | `goal_operation` (Goal) + TaskProcess streams | every confirmation / user objection |
33
33
 
34
34
  This Skill keeps the **business dialogue flow**, the **≤8-question gate**, and the **dependency-aware build order**. The user's intent is recorded as a Goal (`goal_operation` action='create'); actual on-chain objects are created via `onchain_operations` in dependency order.
@@ -89,14 +89,14 @@ Ask these in order; stop at 8. Frame each in business terms. Every question maps
89
89
  ### Q1 — What do you sell, and to whom? (industry alignment)
90
90
 
91
91
  - **Business meaning**: Your business type determines the trust mechanism (how a buyer feels safe paying you), the workflow (how an order progresses), and the money split. It is the single most consequential choice.
92
- - **MCP**: `industry_pack_operation` action='recommend_industry' (business description → top-3 modes) or action='list_modes'. Each mode returns `location_sensitivity`, `trust_selling_points`, and `build_notes` — surface these as "here is what buyers in your industry worry about, and what a trustworthy shop emphasizes".
92
+ - **MCP**: `industry_pack_operation` action='recommend_industry' with `intent`=<business description text> (→ top-3 modes), or action='list_modes'. Each mode returns `location_sensitivity`, `trust_selling_points`, and `build_notes` — surface these as "here is what buyers in your industry worry about, and what a trustworthy shop emphasizes".
93
93
  - **Output to user**: the recommended industry + "buyers in this industry mainly worry about: …", in plain language.
94
94
 
95
95
  ### Q2 — Practice on testnet first, or go straight to mainnet?
96
96
 
97
97
  - **Business meaning**: Testnet is a free sandbox (faucet, zero money at risk) for you to try everything; mainnet is real money and needs gas. Strongly recommend testnet first.
98
- - **Existing-build detection (migration)**: call `query_toolkit` query_type='migration_preflight' (account + source=testnet + target=mainnet). If the account already built on testnet, switch to the **mainnet customization guide** — re-confirm payment token / location / arbitration (the checklist is returned by the same query), rather than re-asking everything.
99
- - **Reassurance**: testnet is free; mainnet gas can be obtained via bridge/airdrop (`wowok_buildin_info` action='funding guidance').
98
+ - **Existing-build detection (migration)**: call `query_toolkit` query_type='migration_preflight' with `account` (required); `source_network` / `target_network` are optional and default to testnet → mainnet (the resolved direction is echoed back in the result). If the account already built on testnet, switch to the **mainnet customization guide** — re-confirm payment token / location / arbitration (the checklist is returned by the same query), rather than re-asking everything.
99
+ - **Reassurance**: testnet is free; mainnet gas can be obtained via bridge/airdrop (`wowok_buildin_info` info='funding guidance').
100
100
 
101
101
  ### Q3 — Where do you serve? (service area / location)
102
102
 
@@ -105,8 +105,8 @@ Ask these in order; stop at 8. Frame each in business terms. Every question maps
105
105
 
106
106
  ### Q4 — Which currency do you accept? (payment token)
107
107
 
108
- - **Business meaning**: On testnet everything settles in WOW (free). On mainnet you may accept stablecoins (USDT/USDC) to reduce price-volatility disputes, or ETH/BTC/WOW. This is the "should I change the payment token when going live" decision.
109
- - **MCP**: `wowok_buildin_info` action='funding guidance' (testnet=WOW) + action='mainnet bridge tokens' (USDT/USDC/ETH/BTC/WOW type tags).
108
+ - **Business meaning**: On testnet everything settles in WOW (free). On mainnet you may accept stablecoins (USDT/USDC) to reduce price-volatility disputes, or ETH/WBTC; WOW itself is the gas token. This is the "should I change the payment token when going live" decision.
109
+ - **MCP**: `wowok_buildin_info` info='funding guidance' (testnet=WOW) + info='mainnet bridge tokens' (the authoritative bridge-token set with each `wowTypeTag` is served by MCP — quote that list, do not hardcode it here).
110
110
 
111
111
  ### Q5 — What are your products, prices, and descriptions? (sales + WIP)
112
112
 
@@ -153,16 +153,16 @@ Run `goal_operation` action='aggregate_risks' before publish; fix ALL CRITICAL f
153
153
 
154
154
  ## Industry Selection Guide
155
155
 
156
- Call `industry_pack_operation` action='list_modes' (8 builtin modes: `freelance` / `rental` / `education` / `travel` / `subscription` / `retail` / `retail_d2c` / `general`). If unsure, call action='recommend_industry' with the business description. Each mode now returns `location_sensitivity`, `trust_selling_points`, and `build_notes` — use these for Q3 (location) and Q5 (description optimization). Mid-onboarding iteration: action='derive_user_mode' / 'evolve_user_mode'.
156
+ Call `industry_pack_operation` action='list_modes' (8 builtin modes: `freelance` / `rental` / `education` / `travel` / `subscription` / `retail` / `retail_d2c` / `general`). If unsure, call action='recommend_industry' with `intent` set to the business description text. Each mode now returns `location_sensitivity`, `trust_selling_points`, and `build_notes` — use these for Q3 (location) and Q5 (description optimization). Mid-onboarding iteration: action='derive_user_mode' / 'evolve_user_mode'.
157
157
 
158
158
  ---
159
159
 
160
160
  ## Deployment Checklist
161
161
 
162
- Before declaring onboarding complete, run `goal_operation` action='aggregate_risks' — MCP auto-checks machine binding, order_allocators, buy_guard, arbitration isolation, R-M1-11 compliance, and publish readiness (D-01..D-20). Fix ALL CRITICAL findings, then verify remaining hard gates via `query_toolkit` (onchain_objects). The authoritative checklist is served by MCP — do not re-derive it here.
162
+ Before declaring onboarding complete, run `goal_operation` action='aggregate_risks' — MCP auto-checks machine binding, order_allocators, buy_guard, arbitration isolation, R-M1-11 compliance, and the rest of publish readiness, returning findings with CRITICAL/WARN severity. Fix ALL CRITICAL findings, then verify remaining hard gates via `query_toolkit` (onchain_objects). The authoritative checklist is served by MCP — do not re-derive it here.
163
163
 
164
164
  ---
165
165
 
166
166
  ## Common Errors
167
167
 
168
- Known field-name / unit / workflow pitfalls are served by `wowok_buildin_info` action='common mistakes' (filter by `operation` or `category`). Error-code guidance (`E_ARBITRATION_PERMISSION_CONFLICT` 33, `E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND` 25, R-M1-11 refund routing) appears above plus MCP `schema_query` action='get_safety_rules' / 'get_guard_design_patterns'. Consult those instead of a duplicated table.
168
+ Known field-name / unit / workflow pitfalls are served by `wowok_buildin_info` info='common mistakes' (filter by `operation` or `category`). Error-code guidance (`E_ARBITRATION_PERMISSION_CONFLICT` 33, `E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND` 25, R-M1-11 refund routing) appears above plus MCP `schema_query` action='get_safety_rules' / 'get_guard_design_patterns'. Consult those instead of a duplicated table.
package/wowok-planner/SKILL.md CHANGED
@@ -25,8 +25,8 @@ The planner sits between the user's intent and the Harness execution loop. It do
25
25
 
26
26
  - **Deterministic-first**: Rule tables and scenario templates produce the ODG skeleton. The LLM is invoked only for (a) intent clarification when keywords are ambiguous, and (b) translating free-text answers into typed fields.
27
27
  - **Scenario-driven**: The Scenario Registry maps common intent patterns to pre-built ODG templates. A fallback `general` template absorbs unmatched intents.
28
- - **Plan-before-write**: The full ODG is confirmed at R8 before any publish-bound object is created. Reversibility is tracked per object.
29
- - **Checkpointed**: The ODG is persisted after every round via `local_info_operation` so the Harness can resume on interruption.
28
+ - **Plan-before-write**: The full ODG is confirmed through the phase review gates (`user_confirm` / `risk_check` / `final_audit`) before any publish-bound object is created. Reversibility is tracked per object. (Note: the R1–R10 rounds in MCP schemas are the Guard-authoring dialogue rounds — R1=intent, R2=table, R3=tree, R4=rely, R5=binding, R6=review, R7=CREATE, R8=test, R9=bind, R10=verify — not ODG plan phases; label local build checklists "Step n", never "Rn".)
29
+ - **Checkpointed**: Round state is anchored in a Goal (`goal_operation` create/approve/advance; the Harness TaskProcess stream persists every round), and the human-readable ODG JSON is written to the local workspace via `workspace_operation` so the Harness can resume on interruption. Do NOT use `local_info_operation` for this — that store is private customer-required info, not planning state.
30
30
 
31
31
  ### What This Skill Does
32
32
 
@@ -40,7 +40,7 @@ The planner sits between the user's intent and the Harness execution loop. It do
40
40
 
41
41
  - User says "I want to build / set up / start / plan X"
42
42
  - L4 Harness opens a new Plan Loop cycle
43
- - User resumes an interrupted plan (read ODG checkpoint first)
43
+ - User resumes an interrupted plan (read the Goal state and the workspace ODG file first)
44
44
  - Do NOT invoke for: live order operations, dispute resolution, or post-publish tuning — those go to wowok-provider / wowok-arbitrator.
45
45
 
46
46
  ### Output Contract
@@ -51,7 +51,7 @@ A confirmed ODG JSON document (see §ODG Data Structure) with: scenario tag, com
51
51
 
52
52
  ## ODG Data Structure
53
53
 
54
- The ODG (Object Dependency Graph) is the single output artifact, persisted via `local_info_operation` and consumed by the Harness:
54
+ The ODG (Object Dependency Graph) is the single output artifact. Round state lives in the Goal / TaskProcess stream (`goal_operation`) and the ODG JSON itself is written to the local workspace via `workspace_operation`; the Harness consumes it phase-by-phase:
55
55
 
56
56
  ```json
57
57
  {
package/wowok-provider/SKILL.md CHANGED
@@ -55,13 +55,13 @@ For each item, the user must provide one of: **"Reuse existing: `<name_or_id>`"*
55
55
 
56
56
  | # | Item | User Must Provide | Why Not Fabricate |
57
57
  |---|------|-------------------|--------------------|
58
- | **R1** | **Account** | Account name/address. Default `""` is fine. | Safe default exists |
59
- | **R2** | **Permission** | Existing Permission to reuse, OR name + type_parameter for new. **Reuse strongly recommended.** | Controls access to ALL your services |
60
- | **R3** | **Service (DRAFT)** | Service name, type_parameter. Create the draft FIRST (unpublished) so Guards can reference it by LocalMark NAME. | Your brand identity on-chain; breaks Guard↔Service cycle |
61
- | **R4** | **Machine** | Nodes, state transitions (pairs), forward paths. | IS your business process |
62
- | **R5** | **Guards** | For each Guard: validation logic, conditions. Reuse or define new. | Enforces your business rules |
63
- | **R6** | **Guard Bindings** | Which Guard validates which Machine forward? | Wrong binding = unauthorized access |
64
- | **R7** | **Allocators** | For each outcome: who gets what %/amount? (e.g. "success: 95% me, 5% platform") | IS your revenue model |
58
+ | **1** | **Account** | Account name/address. Default `""` is fine. | Safe default exists |
59
+ | **2** | **Permission** | Existing Permission to reuse, OR name + type_parameter for new. **Reuse strongly recommended.** | Controls access to ALL your services |
60
+ | **3** | **Service (DRAFT)** | Service name, type_parameter. Create the draft FIRST (unpublished) so Guards can reference it by LocalMark NAME. | Your brand identity on-chain; breaks Guard↔Service cycle |
61
+ | **4** | **Machine** | Nodes, state transitions (pairs), forward paths. | IS your business process |
62
+ | **5** | **Guards** | For each Guard: validation logic, conditions. Reuse or define new. | Enforces your business rules |
63
+ | **6** | **Guard Bindings** | Which Guard validates which Machine forward? | Wrong binding = unauthorized access |
64
+ | **7** | **Allocators** | For each outcome: who gets what %/amount? (e.g. "success: 95% me, 5% platform") | IS your revenue model |
65
65
 
66
66
  **Conditionally Required:**
67
67
 
@@ -74,11 +74,11 @@ For each item, the user must provide one of: **"Reuse existing: `<name_or_id>`"*
74
74
  ### Information Collection Protocol
75
75
 
76
76
  ```
77
- STEP 0: Present checklist R1-R7 to user
77
+ STEP 0: Present checklist Steps 1-7 to user
78
78
  ├── Each item: "Reuse or create new? Provide details."
79
79
  ├── Track status: [pending] / [confirmed: reuse <id>] / [confirmed: create]
80
80
  ├── If user indicates physical goods / customer_required → also confirm C1-C3
81
- └── ⛔ GATE: ALL R1-R7 must be [confirmed] before any on-chain action
81
+ └── ⛔ GATE: ALL Steps 1-7 must be [confirmed] before any on-chain action
82
82
  └── NOT confirmed → STOP. Ask. Do NOT suggest creating service.
83
83
  ```
84
84
 
@@ -96,7 +96,7 @@ STEP 0: Present checklist R1-R7 to user
96
96
 
97
97
  ## Service Build Lifecycle
98
98
 
99
- Once R1-R7 confirmed, execute in strict order. Sub-tools are invoked via `wowok({ tool: "<name>", data: { operation_type: "<type>", ... } })`; all use R1 (Account) as `env.account`.
99
+ Once Steps 1-7 confirmed, execute in strict order. Sub-tools are invoked via `wowok({ tool: "<name>", data: { operation_type: "<type>", ... } })`; all use Step 1 (Account) as `env.account`.
100
100
 
101
101
  **STEP 1 — Foundation**: Account (`account_operation` gen) → Permission (`onchain_operations` permission) → Service DRAFT (`onchain_operations` service, `publish: false` — Guards reference it by LocalMark NAME) → Machine unpublished (`onchain_operations` machine: nodes/pairs/forwards). Discovery `query_toolkit` (account_list/local_mark_list/onchain_objects); template `machineNode2file`.
102
102
 
@@ -135,7 +135,7 @@ Service → permission, machine (immutable), order_allocators (immutable),
135
135
  Order (runtime) → builder, service snapshot, machine, progress, dispute (Arb[]), allocation
136
136
  ```
137
137
 
138
- Cross-object references (which 9 object types hold a Guard and which 4 hold a Machine) are served by MCP `schema_query` action='get_guard_design_patterns'. Permission is the central hub — 11 objects hold BuiltinPermissionIndex.
138
+ Cross-object references — which object types host a Guard, which host a Machine, and which objects carry a `BuiltinPermissionIndex` — are served by MCP `schema_query` action='get_guard_design_patterns' (do not hardcode the counts; the object set evolves). Permission is the central access-control hub.
139
139
 
140
140
  ### Allocators + Machine Integration
141
141
 
package/wowok-supplier/SKILL.md CHANGED
@@ -110,7 +110,7 @@ If the upstream merchant stalls or withholds, escalate in order:
110
110
 
111
111
  ## Own-Interest Surfacing
112
112
 
113
- Run `query_toolkit` query_type='participation_radar' with your account + sub-order progress. The MCP derives your role (supplier) and attaches `supplier-interest` (fund_flow / responsibility / leverage / stakes). Present it as neutral information — the supplier decides.
113
+ Run `query_toolkit` query_type='participation_radar' with `radar_account` (your account) and `radar_targets: [{ progress: <sub-order Progress>, order: <sub-order, optional but recommended> }]`. The MCP derives your role (supplier) and attaches `supplier-interest` (fund_flow / responsibility / leverage / stakes). Present it as neutral information — the supplier decides.
114
114
 
115
115
  ---
116
116