@wowok/skills 3.2.0 → 3.2.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wowok/skills",
-  "version": "3.2.0",
+  "version": "3.2.2",
   "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-arbitrator/SKILL.md

@@ -2,237 +2,108 @@
 name: wowok-arbitrator
 description: "WoWok Arbitrator — build and operate on-chain arbitration services. Create Arbitration objects, configure voting rules (open or guard-based weighted), manage dispute cases through their full lifecycle, and earn fees from resolution. Core value: achieve trust consensus between merchants and users through transparent, fair, and efficient dispute resolution. Use when: User wants to create/configure an Arbitration service; User needs to handle dispute cases and voting processes; User wants to design voter eligibility and weight mechanisms; User mentions \"arbitration\", \"dispute\", \"voting\", \"arb\", \"judge\"."
 metadata:
-  version: "2.0.0"
+  version: "2.1.0"
   role: arbitrator
   related: "wowok-order, wowok-messenger"
 ---
 
 # WoWok Arbitrator Guide
 
-Build trust through fair dispute resolution. Arbitration services enable neutral third parties to resolve conflicts between customers and merchants, earning fees while establishing on-chain reputation.
-
-> **Related Skills**: [wowok-order](../wowok-order/SKILL.md) (customer disputes), [wowok-provider](../wowok-provider/SKILL.md) (service arbitration config), [wowok-machine](../wowok-machine/SKILL.md) (workflow analysis), [wowok-messenger](../wowok-messenger/SKILL.md) (evidence exchange)
-
----
-
-## MCP Knowledge Layer
-
-The following content has been pushed down to the MCP knowledge layer and is applied automatically — this Skill no longer duplicates it:
-
-| Content | Access via (MCP action) | Applied Via |
-|---------|--------------------------|-------------|
-| Guard design rules (structural layers, data source classification, voting_guard table design) | `schema_query` action='get_guard_design_patterns' | `goal_operation` action='aggregate_risks' |
-| Safety rules (confirmation levels, immutability, object reuse) | `schema_query` action='get_safety_rules' | Pre-publish checks + `goal_operation` action='aggregate_risks' |
-| Arbitration-specific risks | auto-applied | `goal_operation` action='aggregate_risks' |
-
-This Skill keeps the arbitration **conversation flow**, **evidence collection** scripts, and **dispute resolution** guidance — the MCP layer handles the rule evaluation.
-
----
-
-## Core Interaction Principles
-
-These four principles govern every arbitration build/handle step. They mirror the wowok-onboard model and are non-negotiable.
-
-1. **Review-first**: State (a) what the AI understood about the arbitration, (b) the dependency order to build, and (c) the interaction contract — before the first choice.
-2. **User-driven**: Every step is an explicit user decision; the AI provides a `recommend` but never auto-advances.
-3. **Reuse / Customize / Discover (choose one of three)**: For every component (Permission, Voting/Usage Guards, Contact), surface all three avenues — reuse an existing object, customize a new one, or discover from other projects / the system.
-4. **Default-config disclosure**: Disclose a new object's default config + important info + caveats BEFORE the user decides. No silent defaults.
-
----
-
-## ⚠️ PRE-FLIGHT: Required Items Checklist
-
-**THIS SECTION IS MANDATORY.** Before ANY arbitration service creation, the AI MUST collect explicit user confirmation for EVERY required item. **Do NOT skip, do NOT fabricate, do NOT proceed with missing items.**
-
-### The Golden Rule
-
-```
-NEVER guess the user's fee model, voting structure, or Guard design.
-These are BUSINESS and GOVERNANCE decisions that ONLY the user can make.
-
-User hasn't provided it → ASK.
-User provides incomplete info → ASK for clarification.
-User says "just make something up" → REFUSE and explain why each item matters.
-```
-
-### Required Items
-
-| # | Item | User Must Provide | Why Not Fabricate |
-|---|------|-------------------|--------------------|
-| **1** | **Account** | Which account to operate from. Default `""` is fine. | Safe default exists |
-| **2** | **Arbitration Name** | Service name. What kind of arbitration? | Your brand and reputation on-chain |
-| **3** | **Fee** | How much per case? (e.g. "10 WOW per dispute") | IS your revenue model — you cannot guess pricing |
-| **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 |
-| **5** | **Usage Guard** | Who can file disputes? Public or restricted? | Controls your case volume and quality |
-| **6** | **Contact (um)** | Messenger Contact name/ID for evidence exchange | Without this, customers cannot submit evidence — service is broken |
-
-### Information Collection Protocol
-
-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.
-
-All subsequent on-chain operations use Step 1 (Account) as `env.account`.
-
-### Anti-Fabrication Rules (HARD Constraints)
-
-| Never... | Because... |
-|----------|------------|
-| Invent a fee amount | You don't know their pricing strategy |
-| Assume usage_guard logic | You don't know their target audience |
-| Skip the checklist | Arbitration design decisions are on-chain and visible |
+> Build trust through fair dispute resolution — neutral third-party resolution of customer/merchant conflicts, paid per case.
+> **Tools**: `onchain_operations` operation_type=`arbitration` (service + most case ops); customer-side case ops live on operation_type=`order`.
+> **Related**: [wowok-order](../wowok-order/SKILL.md) · [wowok-provider](../wowok-provider/SKILL.md) · [wowok-messenger](../wowok-messenger/SKILL.md)
 
 ---
 
-## Core Architecture
-
-### Two-Layer Design
-
-| Layer | Object | Purpose | Lifecycle |
-|-------|--------|---------|-----------|
-| **Service** | Arbitration | Rules, fees, voter configuration | Permanent |
-| **Case** | Arb | Individual dispute with state machine | Per dispute |
-
-**Separation of Powers**:
-- **Arbitrator controls**: Who can vote, voting weights, final verdict (`indemnity`)
-- **Customer controls**: Accept result or object, claim compensation timing
-
-Neither party can force outcome unilaterally — the design forces collaboration toward consensus.
-
-### Arb State Machine
-
-Customer dispute creates Arb directly at (1). State (0) entered only via `reset`.
+## What the MCP already handles
 
-| State | Available Operations | Next State |
-|-------|---------------------|------------|
-| **(0) Revision Pending** | Customer (via Order): `arb_confirm` | → (1) |
-| **(1) Arbitrator_confirming** | Arbitrator: `confirm` → (2), `reset` → (0), feedback | → (2) or (0) |
-| **(2) Voting** | Arbitrator: vote, set deadline, `arbitration` → (3), feedback | → (3) |
-| **(3) Arbitrated** | Customer (via Order): `arb_objection` → (4), `arb_claim_compensation` → (5) | → (4) or (5) |
-| **(4) Objectionable** | Arbitrator: `reset` → (0), feedback | → (0) |
-| **(5) Finished** | Arbitrator: `withdraw` → (6) | → (6) |
-| **(6) Withdrawn** | Terminal | — |
+- Guard design rules (voting-table design, `FixedValue`/`GuardIdentifier` weight sources, structural checks): `schema_query` action=`get_guard_design_patterns`; safety/confirmation: `get_safety_rules`; applied through `goal_operation` action=`aggregate_risks` and the publish/pre-call gates.
+- Move guidance and the arbitration schema (`onchain_operations_arbitration`) carry exact field constraints — read the call output, don't memorize this file.
 
-**Key Flows**:
-- **Standard**: (1) → confirm → (2) → arbitration → (3) → arb_claim_compensation → (5) → withdraw → (6)
-- **With Revision**: (1) → reset → (0) → arb_confirm → (1) → confirm → (2) → ...
-- **With Objection**: ... → (3) → arb_objection → (4) → reset → (0) → ...
+Keep the conversation flow, the governance questions, and the evidence discipline.
 
 ---
 
-## Phase 1: Build Your Service
-
-### Essential Configuration
-
-| Field | Purpose | Key Decision |
-|-------|---------|--------------|
-| `fee` | Revenue per case | Balance accessibility with sustainability |
-| `voting_guard` | Who votes, with what weight | Open (centralized) vs Guard-based (decentralized) |
-| `usage_guard` | Who can file disputes | Public vs invitation-only |
-| `um` | Contact for evidence exchange | Messenger addresses for WTS verification |
-
-**⚠️ Start paused** (`pause: true`). **Forgetting to unpause = all disputes silently rejected with no error.** Complete all configuration — fee, guards, um — before unpausing.
-
-**⚠️ Guard Immutability**: Once a Guard is created, its rules **cannot be modified**. If your `voting_guard` design is wrong, you must create a replacement Guard and reconfigure the Arbitration — wasteful but not fatal. Test with `gen_passport` before finalizing.
-
-**⚠️ Permission Isolation from Service** (CRITICAL for mainnet trust): The Arbitration's Permission object MUST be separate from the Service's Permission object. Sharing the same Permission — or having overlapping owner/admin addresses — breaks dispute fairness because the merchant can control arbitration operations (vote, confirm, execute rulings). For mainnet deployment, use a completely independent third-party Permission with a different owner and admin list. The evaluation engine deducts risk scores significantly for Permission overlap (-30 for same Permission, -20 for owner/admin overlap). Testnet may tolerate shared Permission for simplicity, but mainnet users should treat this as a critical trust factor.
-
-### Voting Modes
+## Interaction principles
 
-**Open** (`voting_guard: []`): arbitrator casts votes directly (weight = 1). **Guard-based** (`voting_guard: [{guard, vote_weight}, ...]`): voters authenticate via Passport + Guard; weight from `FixedValue(u32)` or `GuardIdentifier(u8)`; max 50 guards (tiered voting). Voting guard construction rules (table design, computation trees, `GuardIdentifier` requirements) are served by MCP `schema_query` action='get_guard_design_patterns'. Test with `gen_passport` before finalizing.
+1. **Review-first**: restate the arbitration design, the build dependency order, and the interaction contract before the first choice.
+2. **User-driven**: every governance/business parameter is an explicit user decision; recommend, never auto-advance.
+3. **Reuse / customize / discover** for Permission, Guards, Contact.
+4. **Default disclosure**: show defaults and consequences before deciding. Network: the runtime uses the USER'S CURRENT network (client UI selection) — omit `env.network`; set it only when the user explicitly names a different network (mainnet is a different trust posture).
 
 ---
 
-## Phase 2: Handle Cases
+## Pre-flight: business decisions (gate before any write)
 
-### Case Lifecycle
+Never invent a fee, a voting structure, or Guard logic — missing → ASK; "make something up" → REFUSE.
 
-| # | Step | State | Action |
-|---|------|-------|--------|
-| 1 | **Arrival** | (1) | Arb created via customer `dispute`. Fee locked, propositions recorded. |
-| 2 | **Review** ⚠️ | (1) | `confirm` (proceed) or `reset` (send back). **Insufficient → MUST reset.** |
-| 3 | **Voting** | (2) | Vote, set `voting_deadline` (≤ 3 days). Max 520 voters. |
-| 4 | **Finalize** ⛔ | (2)→(3) | `arbitration`: sets `feedback` + `indemnity`. **Irreversible** by arbitrator. |
-| 5 | **Resolution** | (3) | Customer: `arb_claim_compensation` → (5), or `arb_objection` → (4). |
-| 6 | **Objection** | (4) | Only `reset` → (0) for revision. |
-| 7 | **Withdraw** | (5)/(3)/(4) | Finished: **immediate**. Others: ⛔ **30-day mandatory wait**. |
+1. **Account** (`env.account`, default `""`).
+2. **Arbitration name + description/location** — the public brand.
+3. **Fee** per case (`fee`, smallest units) — revenue model; customer pays it when filing.
+4. **Voting Guards** — open (empty list, permission vote weight 1) or guard-based weighted list (≤50 Guards). Immutable once each Guard is created.
+5. **Usage Guard** (`usage_guard` or null) — who is allowed to file; null = anyone.
+6. **Contact `um`** — without it evidence exchange breaks.
 
-**Reset feedback channels**:
-
-| Channel | Use | Visibility |
-|---------|-----|------------|
-| **Messenger** (preferred) | Specific evidence, privacy-sensitive | Encrypted, off-chain |
-| **on-chain feedback** | General clarification, procedural | Public, permanent |
-
-**Best-move advice** (`evaluation_operation` → `arb_game`): pass `status` (7-state) + `perspective` (`customer`/`merchant`/`arbitrator`) to get ranked moves (optimal + payoff + risk). Read the result; the role decides and acts.
+⛔ All six confirmed before creating. Track pending/confirmed like the provider checklist.
 
 ---
 
-## Phase 3: Business Model
+## Architecture
 
-### Revenue Flow
+Two objects: **Arbitration** (the service: fee, voting/usage Guards, `um`, `bPaused`, `balance`, Permission — permanent) and **Arb** (one per case: state machine, propositions, votes, fee held in escrow, verdict).
 
-Customer pays fee → locked in `Arb.fee` per case → `arb_withdraw()` transfers to `Arbitration.balance` → distributed via Allocation (revenue sharing) or Treasury (controlled withdrawal).
+Separation of powers: the arbitrator sets process and verdict (`indemnity`); the CUSTOMER confirms filings, objects, and claims compensation. Neither side can finish a case unilaterally.
 
-### Compensation System
+### Arb state machine (codes are the on-chain names used by `arb_game` too)
 
-Arbitrator sets `indemnity` → Customer claims via `order.arb_claim_compensation` → Funds transfer from `service.compensation_fund` to Order.
+| # | State | Who moves, how |
+|---|---|---|
+| 0 | `Principal_confirming` | Customer via order `arb_confirm` ({arb, confirm, proposition?, description?}) → 1 |
+| 1 | `Arbitrator_confirming` | Arbitrator `confirm` → 2 · `reset` (with feedback) → 0 · `feedback` |
+| 2 | `Voting` | `vote` · `voting_deadline_change` · `arbitration` (verdict) → 3 · `feedback` |
+| 3 | `Arbitrated` | Customer: `arb_objection` → 4 · `arb_claim_compensation` → 5 |
+| 4 | `Objectionable` | Arbitrator `reset` → 0 (only exit) · `feedback` |
+| 5 | `Finished` | Terminal; fee withdrawable immediately |
+| 6 | `Withdrawn` | Terminal |
 
-> **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).
+`feedback` may be written in ANY non-terminal state (0–4) and emits a permanent public `FeedbackEvent`. Flows: standard 1→2→3→5→6; revision loops through 0; objection loops 3→4→0.
 
 ---
 
-## Integration
-
-### Evidence (Messenger)
-
-1. Customer queries Arbitration's `um` → gets Messenger addresses
-2. Customer sends WTS evidence files (encrypted, off-chain)
-3. Arbitrator verifies WTS authenticity (`verify_wts`)
-4. Only verified evidence considered valid
-
-Dispute initiators should pre-screen their collection via `evaluation_operation` action `evidence_review` (list mode): it partitions items into usable/manual/rejected and yields `proof_candidates` to reference in the dispute description (the human picks — nothing attaches automatically). When a party's evidence is thin, point them to it before voting.
-
-**⚠️ `um` must be configured before unpausing** — without it customers cannot submit evidence.
+## Build phase
 
-### Service Provider
+Create the Arbitration **paused** (`pause: true`), configure, then `pause: false` last. While paused, filing ABORTS with arbitration error `E_PAUSED` (4) — it is an on-chain error, not a silent reject, but the practical damage is the same: no cases can arrive. Verify unpaused before going live.
 
-Providers list approved Arbitrations in their Service. Customers choose from this list when disputes arise.
+- `fee`, `description`, `location` are settable by Permission.
+- `voting_guard: {op:'add'|'set'|'remove'|'clear', guards:[…]}`. Each entry is `{guard, vote_weight}`: fixed u32 weight, or a u8 Guard-table identifier whose submitted number becomes the voter's weight at vote time (`FixedValue` / `GuardIdentifier`). Open = empty list → plain Permission vote, weight 1. Test every Guard with standalone `gen_passport` before adding — Guards are immutable from creation; a flawed voting Guard can only be replaced (the list itself stays mutable while configured pre-service / as allowed).
+- `usage_guard`: a Guard address or null; when set, filing MUST pass it via Passport (`dispute_with_passport`), else plain `dispute` aborts `E_NEED_PASSPORT` (6).
+- `um`: a Contact; evidence flows through its Messenger addresses.
+- **Permission isolation (mainnet trust)**: the Arbitration's Permission MUST differ from every Service it's bound to — binding a shared one aborts `E_ARBITRATION_PERMISSION_CONFLICT` (33, enforced at Service bind). Separately, the buyer-side risk model scores same-Permission as **−6 points (critical)** and overlapping owner/admin as **−4 points (warning)** inside its 20-point trust dimension — even distinct objects with the same controllers fail the intent. Use a genuinely independent third-party Permission.
 
 ---
 
-## Design Principles
+## Handling a case
 
-- **Fairness**: Separated powers (neither side can force outcome), revision cycles (`reset`), customer objection rights, transparent on-chain rules, 30-day withdrawal protection.
-- **Efficiency**: Clear state machine, weighted voting to reduce spam, deadline enforcement, fee incentive for timely resolution.
-- **Trust**: ⚠️ Feedback is permanently public — be reasoned and professional. Apply consistent standards. Monitor Messenger, verify WTS promptly.
+1. **Arrival**: customer files via `arbitration` `dispute: {order, description?, proposition[], fee:{balance}, namedArb?}` (≤20 propositions; fee locked in the Arb; excess fee is refunded). Arb appears at state 1.
+2. **Review (1)**: `confirm: {arb, voting_deadline}` — proceed, or `reset` with feedback when the filing is insufficient (don't escalate thin cases).
+   - `voting_deadline` is ms: **0 (default) = already-passed → direct verdict, voting impossible**; **null = open-ended**; a future timestamp = voting window (recommend ≥24h; ~3 days is a convention, NOT a chain limit).
+3. **Voting (2)**: `vote: {arb, votes:[indices…], voting_guard?}` — 0-based proposition indices; re-voting REPLACES the prior vote; ≤520 voters. With a deadline set, `arbitration` cannot run until it has passed (`E_VOTING_DEADLINE_NOT_PASSED`).
+4. **Verdict (2→3)**: `arbitration: {arb, feedback, indemnity}` — irreversible for the arbitrator; only customer objection/claim follows. **Indemnity is capped at 3× the order amount** (`MAX_INDEMNITY_MULTIPLE`, abort 9) and is paid from the SERVICE's `compensation_fund`, never from arbitrator funds.
+5. **Customer branch (3)**: claim → 5, or object with `arb_objection` → 4 → your `reset` sends it to 0 for revision.
+6. **Fee withdrawal**: `arb_withdraw: {arb}` — immediate at Finished; from Arbitrated/Objectionable only after 30 days past indemnity time (`WITHDRAW_DURATION_TIME`, abort 8). Then move the balance onward with `fees_transfer: {to:{allocation|{treasury}}, payment_remark, payment_index}`.
 
----
-
-## Quick Reference
-
-### Critical Constraints
-
-- Max 20 propositions per case
-- Max 520 voters per case
-- Max 50 voting guards per Arbitration
-- ⛔ 30-day withdrawal wait for non-finished cases (mandatory, cannot bypass)
-- ⛔ Guard is **immutable after creation** — test before finalizing
-- ⛔ `arbitration` verdict is **irreversible** by arbitrator — only customer can object
-- ⛔ `feedback` is **permanently public on-chain** — use Messenger for privacy-sensitive communication
+**Move advice**: `evaluation_operation` action=`arb_game` with `status` (one of the 7 state names) and `perspective: customer|merchant|arbitrator` returns ranked moves/payoffs/risk — read-only; the role decides.
 
 ---
 
-## Best Practices
-
-1. **Configure before unpause**: Fee, contact, voting rules ready first. ⚠️ Unpause is the last step.
-2. **Reset proactively**: Unclear case? Send back immediately with clear feedback (Messenger preferred for privacy).
-3. **Verify all evidence**: Use `verify_wts` before evaluating — unverified evidence is not evidence.
-4. **Write detailed feedback**: Your on-chain reputation is permanent. Be professional, reasoned, and fair.
-5. **Set fair indemnity**: Proportional to order value and dispute nature.
-6. **Test guards first**: Use `gen_passport` to verify voting_guard logic before deployment.
-7. **Set reasonable deadlines**: Suggest ≤ 3 days for voting — balances efficiency with thoroughness.
+## Evidence & reputation
 
-### Common Pitfalls
+- Customer reads the Arbitration's `um`, sends WTS evidence off-chain via encrypted Messenger; arbitrator runs `messenger_operation` `verify_wts` before considering anything — unverified evidence is not evidence.
+- Tell initiators to pre-sort with `evaluation_operation` action=`evidence_review` (list mode): usable/manual/rejected partition + `proof_candidates` for the dispute description; the human selects — nothing auto-attaches.
+- On-chain `feedback` is permanent and public: reasoned, professional, consistent. Use Messenger for anything private.
 
-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.
+## Hard constraints (quick reference)
 
----
+- Propositions ≤20 · voters ≤520 · voting Guards ≤50 · indemnity ≤3× order amount.
+- Paused ⇒ filing aborts (4); verdict needs deadline passed when one is set (7); non-finished withdrawal waits 30d (8).
+- Guards immutable from creation — `gen_passport` first. Verdict irreversible for the arbitrator. Feedback permanent/public.

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.0"
+  version: "2.1.1"
   role: shared
   related: "wowok-planner, wowok-provider, wowok-machine"
 ---
@@ -39,7 +39,7 @@ 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. **Allocator-set freeze** (`order_allocators` bind) — fund-flow paths lock with the Service.
+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.
 
 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.
@@ -83,7 +83,7 @@ Presentation rules:
 
 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.
 2. **Blast-radius first**: order findings by irreversibility — a post-publish Guard logic bug is permanent; an untested Guard or missing backup is recoverable.
-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.
+3. Group by the five coverage aspects — **Guard completeness, Machine soundness, fund-flow safety, permission consistency, publish readiness** (map each finding via its returned `object_type` and `risk_rule_id`), and state explicitly which objects were in scope. Quote the finding text the engine returns; never maintain a local rule list.
 
 ---
 

package/wowok-collaborator/SKILL.md

@@ -2,7 +2,7 @@
 name: wowok-collaborator
 description: "WoWok Collaborator — the canonical skill for process collaborators who execute workflow forwards on behalf of a merchant: internal staff (permission entities) and external operators (named operators). Covers permission-index and named-operator routing, guard-gated evidence submission, and reputation protection. The collaborator carries PROCESS responsibility (no direct settlement stake) — the goal is to keep the workflow flowing and avoid stall blame. For the merchant who owns the Service, see wowok-provider. For the supplier who presents to Demands, see wowok-supplier. Use when: User is an operator/employee executing workflow steps (permission index); User is an external named operator advancing a Machine forward; User wants to submit guard evidence (proof/repository) for a forward; User mentions \"collaborator\", \"operator\", \"permission index\", \"named operator\", \"execute forward\"."
 metadata:
-  version: "2.0.0"
+  version: "2.1.0"
   role: collaborator
   related: "wowok-provider, wowok-machine, wowok-messenger"
 ---
@@ -11,88 +11,48 @@ metadata:
 
 > **Role**: Collaborator (internal permission entity OR external named operator)
 > **Related Skills**: [wowok-provider](../wowok-provider/SKILL.md) (merchant), [wowok-machine](../wowok-machine/SKILL.md) (workflow), [wowok-messenger](../wowok-messenger/SKILL.md) (evidence exchange)
+> Mechanics — routing, permission indexes, guard field lists, thresholds — are emitted by the MCP per query. Read them from the output; do not hand-maintain them here. Guard patterns: `schema_query` (`get_guard_design_patterns`, `get_safety_rules`).
 
----
-
-## MCP Knowledge Layer
-
-The following content has been pushed down to the MCP knowledge layer and is applied automatically — this Skill does NOT duplicate it:
-
-| Content | Access via (MCP action) | Applied Via |
-|---------|--------------------------|-------------|
-| Collaborator interest analysis (fund_flow / responsibility / leverage / stakes) | `query_toolkit` query_type='participation_radar' | role derivation → `collaborator-interest` |
-| Progress routing rule (namedOperator vs permissionIndex) | `schema_query` action='get_safety_rules' | `onchain_operations` progress/order |
-| Guard design + submission patterns | `schema_query` action='get_guard_design_patterns' | guard-gated forwards |
-| Node game (threshold cooperation) | `evaluation_operation` action='node_game' | multi-role forward evaluation |
+## What is pushed down (do not duplicate)
 
-This Skill keeps the collaborator **conversation flow** — what you can execute now, what evidence to submit, and how to stay in scope.
-
----
+| Capability | Where it surfaces |
+|---|---|
+| What you can execute now, and how | `query_toolkit` `participation_radar` — `operable[]` with per-forward `execution_path`, `permission_index` / `named_operator`, `guard`, and **`recommended_call`** |
+| Concrete execution route | each operable forward's **`recommended_call`** (`tool` + `path` + `reason`) — the single source of truth; never hand-route from operator names |
+| Interest analysis | radar `interest_analysis` (fund_flow / responsibility / leverage / stakes), derived as `collaborator-interest` |
+| Guard design & safety rules | `schema_query` `get_guard_design_patterns` / `get_safety_rules` |
+| Threshold cooperation (multi-contributor forwards) | `evaluation_operation` action `node_game` |
 
 ## Role: process responsibility, not settlement
 
-The collaborator has **no direct settlement stake**. Your compensation is typically outside the on-chain order (salary/contract) unless the allocation explicitly routes a slot to you. Your stake is **reputation** — the stall/dispute metrics are public and read by future counterparties.
-
-Two sub-kinds (derived on-chain, never asserted):
-- **permission entity** (internal staff): granted a `permissionIndex` in the Service's Permission.
-- **named operator** (external): resolved via Progress.namedOperator → LocalMark.
-
----
-
-## Core Interaction Principles
-
-1. **Review-first**: State what you understand + what you can execute + the interaction contract before acting.
-2. **User-driven**: the AI surfaces options; you decide; never auto-advance.
-3. **Stay in scope**: only execute forwards your permission/named-operator grants — out-of-scope action creates semantic responsibility without authority.
-4. **Default-config disclosure**: disclose defaults + caveats before acting.
-
----
-
-## What You Can Execute Now
-
-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:
+- You typically have **no direct settlement stake** (compensation is salary/contract off-chain, unless an Allocation slot explicitly routes to you).
+- Your real stake is **reputation**: stall and dispute metrics are public and read by future counterparties.
+- Sub-kind is **derived on-chain, never asserted**: `permission_entity` (granted a permission index in the Service's Permission) or `named_operator` (Progress.namedOperator → LocalMark). The radar tells you which.
 
-- `operable` — forwards YOU can execute right now (permission / named-operator path).
-- `waiting_on` — what the workflow waits on from other roles.
-- `collaborator_kind` — internal vs external.
-- `interest_analysis` → `collaborator-interest` (fund_flow / responsibility / leverage / stakes).
+## Working procedure
 
-Present it neutrally; the collaborator decides.
-
----
+1. **Review-first**: state what you understood, what the account can execute, and the interaction contract before acting.
+2. **Read the radar**: `query_toolkit` `participation_radar` with `radar_account` and `radar_targets: [{ progress, order? }]` (1–20 targets). Present `operable` neutrally; if `branch_choice` is present, the user picks the branch — never auto-advance.
+3. **Execute per `recommended_call`**: call exactly the tool/path the forward gives (the reason text carries the failure code you would hit on the wrong path). No `recommended_call` → that forward is not executable by this account; say so instead of trying.
+4. **Stay in scope**: only execute forwards the account's permission/named-operator grants. Out-of-scope action creates semantic responsibility without authority.
 
-## Routing
+## Guard-gated forwards
 
-- Empty `namedOperator` (`""`) → `order.progress` (the order holder, NOT you).
-- Non-empty role name → `progress.operate` with the named operator.
-- `permissionIndex` → `progress.operate` with your granted index.
-
-Wrong path → "Permission denied" (abort code 5). The MCP safety rules carry the authoritative classification.
-
----
-
-## Guard-gated Forwards
-
-A forward with a guard requires a `b_submission` (retained submission) before execution. Prepare your evidence (Repository/proof) in advance:
-
-1. Upload evidence (Repository/proof data).
-2. Execute the forward (two-phase: call → submission prompt → re-call with submission).
-3. Advance the workflow.
-
-Uploading evidence BEFORE executing reduces dispute probability and pre-builds the merchant's arbitration defense — your diligence is visible on-chain.
-
----
+- The forward's `guard` field (and `workflow_operation` `list`/`task` → `options[].guard_submissions`) tells you exactly which `b_submission` fields must be supplied (name, value type, object type).
+- Prepare evidence (Repository / Proof) **before** executing; exchange it via Messenger when it comes from another party.
+- Execute once, with the `submission` values attached to the same call. Pre-uploading evidence reduces dispute probability and builds the merchant's arbitration defense — your diligence is visible on-chain.
 
-## Design Principles
+## Principles
 
-- **Momentum**: advance when you can; the stall is publicly visible.
-- **Scope discipline**: never interfere outside your permission/named-operator scope.
-- **Evidence first**: guard-gated forwards are only as strong as the submission behind them.
-- **Neutrality**: the AI surfaces trade-offs, never chooses the branch for you.
+- **Momentum**: advance when you can; a stall is publicly visible.
+- **Scope discipline**: never interfere outside your granted forwards.
+- **Evidence first**: a guarded forward is only as strong as its submission.
+- **Neutrality**: surface trade-offs and options; the role decides, you do not.
+- **Defaults disclosed**: disclose defaults and caveats before acting.
 
-## Quick Reference
+## Quick reference
 
-- You carry no settlement stake — your currency is reputation.
-- `permissionIndex` → `progress.operate`; `namedOperator` role name → `progress.operate`.
-- Guard-gated forward needs `b_submission` evidence before execution.
-- Threshold cooperation (`node_game`) surfaces multi-role forward needs when a pair's threshold > 1.
+- No settlement stake — your currency is reputation.
+- Route via `operable[].recommended_call`; do not infer the tool from the operator kind yourself.
+- Guarded forward: read `guard_submissions`, collect the values, submit with the execute call.
+- `node_game` surfaces the cooperation picture when a pair's threshold needs multiple distinct contributors.

package/wowok-governance/SKILL.md

@@ -2,7 +2,7 @@
 name: wowok-governance
 description: "WoWok Governance — the canonical skill for on-chain permission, data, and financial governance: the account that OWNS the objects keeps them healthy after setup. Covers Permission lifecycle (indexes, role assignment, entity table, admin transfer), Treasury/Allocation fund stewardship (deposit/withdraw, history audit, unclaimed payments), and Personal data boundaries (public identity, profile records). Governance is a continuous loop — inventory, decide, execute, audit — not a one-time setup. For building services, see wowok-provider. For market operations, see wowok-market. Use when: User wants to manage who can operate their objects (permission indexes, entity table); User wants to deposit/withdraw treasury funds or audit fund history; User has unclaimed payments or wants to check claimable balances; User wants to update their public on-chain profile or personal data; User mentions \"permission\", \"treasury\", \"governance\", \"manage assets\", \"audit funds\"."
 metadata:
-  version: "1.0.0"
+  version: "1.1.0"
   role: shared
   related: "wowok-provider, wowok-market, wowok-messenger"
 ---
@@ -11,85 +11,46 @@ metadata:
 
 > **Role**: Object owner/admin — the account that carries administrative responsibility for Permission, Treasury, and Personal objects
 > **Related Skills**: [wowok-provider](../wowok-provider/SKILL.md) (service build), [wowok-market](../wowok-market/SKILL.md) (market ops), [wowok-messenger](../wowok-messenger/SKILL.md) (contact)
+> Exact op shapes, field lists and enums live in the tool schemas — read `schema_query` `get` with `onchain_operations` (see the `permission` / `treasury` / `personal` `operation_type` branches) before mutating. Safety rules: `get_safety_rules`.
 
----
-
-## MCP Knowledge Layer
-
-The following content has been pushed down to the MCP knowledge layer and is applied automatically — this Skill does NOT duplicate it:
-
-| Content | Access via (MCP action) | Applied Via |
-|---------|--------------------------|-------------|
-| Permission safety rules (owner/admin/entity hierarchy) | `schema_query` action='get_safety_rules' | `onchain_operations` permission |
-| Treasury/Permission/Personal object schema | `schema_query` action='get' name='treasury'/'permission'/'personal' | governance operations |
-| Unclaimed-payment detection | `keeper_operation` (payment_unclaimed scan) | monitor loop |
-| Fund-flow event meanings (TreasuryEvent / AllocationEvent / RewardClaimEvent / RewardFundEvent) | event semantic registry | audit & monitor |
-
-This Skill keeps the governance **conversation flow** — what to inventory, what to decide, what to execute, and how to audit.
-
----
-
-## Governance Is a Loop, Not a Setup
-
-Inventory → Decide → Execute → Audit. Governance objects are LIVE: a permission change takes effect on the next call, a withdraw is irreversible, a personal profile record is permanently public. Every change deserves an audit pass after execution.
-
----
-
-## Domain 1: Permission Governance
+## Governance is a loop, not a setup
 
-A Permission object defines WHO can perform WHICH operations on your business objects (Service / Machine / Treasury …).
+Inventory → decide → execute → **audit (re-query the post-state every time)**. These objects are live: a grant change applies on the next call, a withdraw is irreversible, a profile record is permanently public.
 
-- **Indexes**: role indexes are numeric IDs (custom indexes start at 1000 — built-ins are reserved). Naming one for readability is a `remark {op:'set', index, remark}` write, not a "create index" call.
-- **Grants** (`table` field): assign with `add perm by index` (one index → many entities) or `add perm by entity` (one entity → many indexes); `set` variants REPLACE the existing list. `admin {op:'add'|'remove'|'set'}` controls admins; entity-level hygiene uses `del`/`swap`/`replace`/`copy`. A mis-assigned grant takes effect immediately. Exact op shapes: `schema_query` action='get' name='permission'.
-- **Entity table**: review-first — read the current Permission via `query_toolkit` query_type='onchain_objects' before mutating.
-- **Audit**: `query_toolkit` query_type='onchain_table_item_permission_perm' checks what a specific address may do; query_type='address_profile' shows an address's permission memberships across all objects.
+## Domain 1 — Permission governance
 
-Rules of thumb:
-- One Permission per business object family; reuse named indexes, don't proliferate unnamed ones.
-- Removing an entity is immediate — the next operation by that address fails with "Permission denied" (abort code 5).
-- Admin transfer is a high-trust operation: the new admin controls the whole table.
+- **Inventory before mutating**: read the Permission via `query_toolkit` `onchain_objects`; audit one address with `onchain_table_item_permission_perm`; see every membership an address holds across objects with `address_profile` (batch form `address_profiles`, up to 50).
+- **Index naming is not an "index creation"**: custom permission indexes are the numeric IDs 1000–65535 (built-ins reserved below); a readable name is just a `remark` write (`set` / `remove` / `clear`).
+- **Choose the op family by shape** (`permission_operation`, exact params in schema):
+  - one index → many entities: `add|set|remove perm by index`;
+  - one entity → many indexes: `add|set|remove perm by entity`;
+  - `set` REPLACES the whole list — warn before using; prefer `add`/`remove`;
+  - entity hygiene: `swap` / `replace` / `copy` / `del`;
+  - admins: `admin` `add|remove|set` — high-trust: a new admin controls the whole table.
+- A removed entity's next call fails with permission#5 "Permission denied". Prefer one Permission per business-object family; reuse named indexes.
 
----
-
-## Domain 2: Financial Governance
-
-Fund stewardship across Treasury / Allocation / Reward / Payment.
-
-- **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.
-- **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.
-- **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).
-- **Reward pools**: RewardFundEvent in / RewardClaimEvent out; a dry pool blocks claims — watch balances before announcing campaigns.
-
----
+## Domain 2 — Financial governance
 
-## Domain 3: Data Governance
+- **Treasury**: deposit joins coins in (Payment receipt minted); withdraw splits balance out — irreversible, and an `external_guard` on the Treasury must authorize it. Audit every flow with `query_toolkit` `onchain_table_item_treasury_history` (op `0` Withdraw / `1` Deposit / `2` Receive; amount + guard + timestamp).
+- **Allocation**: modes Amount (fixed) / Rate (basis points, 10000 = 100%; pure-Rate must sum to 10000) / Surplus (remainder drain, ≤1 per Allocator). Review allocator guards periodically — a stale guard blocks legitimate distributions.
+- **Unclaimed payments**: recipients own frozen CoinWrappers until unwrapped. The keeper owns this reminder surface: `keeper_operation` `scan` then `tasks` with `detector: "payment_unclaimed"`; nudge recipients via Messenger. `NewPaymentEvent` is deliberately NOT push-suggestion-bridged, to avoid duplicate reminders.
+- **Reward pools**: funds in (RewardFundEvent) / claims out (RewardClaimEvent); a dry pool blocks claims — watch balances before announcing campaigns.
 
-- **Personal profile** (`personal` operations): your public on-chain identity. Everything here is PERMANENTLY PUBLIC — never anchor private data. Review-first: show the current record before every mutation.
-- **Entity info**: description/info updates re-emit NewEntityEvent — counterparties' cached profiles refresh; keep descriptions accurate.
-- **Repository data**: contribution/usage policies are designed at Repository level (see wowok-provider); governance audits consumption through the event stream.
+## Domain 3 — Data governance
 
----
-
-## Monitor Loop
-
-Governance goals close the loop through three channels:
-
-- **Push**: fund-flow events (TreasuryEvent / AllocationEvent / RewardClaimEvent / RewardFundEvent) become goal-bound suggestions via SuggestionBridge.
-- **Pull**: keeper scans (payment_unclaimed, balance thresholds) repeat reminders until resolved.
-- **Audit**: after every governance write, re-query the object and confirm the post-state matches the intent.
-
----
+- **Personal profile is permanently public** — never anchor private data; show the current record before every mutation.
+- **Profile/contact description updates emit NO on-chain event** (`NewEntityEvent` fires only on entity registration). Counterparties see updates on their next object read — there is no push; tell the user this instead of promising a refresh.
+- Repository contribution/usage policy belongs to [wowok-provider](../wowok-provider/SKILL.md); governance audits consumption via the event stream.
 
-## Core Interaction Principles
+## Loop channels
 
-1. **Review-first**: always show current state + the exact delta before executing.
-2. **User-driven**: surface options, never auto-execute — withdraw and admin transfer are irreversible.
-3. **Disclose irreversibility**: say it explicitly for withdraw, admin transfer, and any personal-data write.
-4. **Audit after**: every governance write ends with a re-query confirmation.
+- **Push**: fund-flow events (Treasury / Allocation / RewardFund / RewardClaim) become goal-bound suggestions through the monitor SuggestionBridge.
+- **Pull**: keeper scans (`payment_unclaimed`, `progress_actionable`) repeat reminders until resolved; standing `auto_execute` exists only for claim-to-self.
+- **Audit**: after every governance write, re-query and confirm the post-state matches intent.
 
-## Quick Reference
+## Interaction rules
 
-- Permission: index remarks → grants (`add perm by index`/`by entity`) → audit via permission_perm + address_profile.
-- Treasury: deposit/withdraw + history audit; external_guard gates withdrawals.
-- Unclaimed payments: keeper scan owns reminders; recipients unwrap CoinWrappers.
-- Personal data: permanently public — review before every write.
+1. **Review-first**: current state + exact delta before executing.
+2. **User-driven**: never auto-execute — withdraw and admin changes are irreversible.
+3. **Disclose irreversibility** for withdraw, admin transfer, and any personal-data write.
+4. **Audit after**: end every governance write with a re-query confirmation.