@wowok/skills 3.1.1 → 3.2.0

package/wowok-messenger/SKILL.md

@@ -75,7 +75,7 @@ Two approaches, depending on need:
 - **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.
 - **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.
 
-**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).
+**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.
 
 **Design note**: By default, retrieving messages auto-marks them as viewed (`viewedAt` timestamp). Set `skipAutoMarkViewed: true` if you want to peek without marking read.
 

package/wowok-onboard/SKILL.md

@@ -23,12 +23,12 @@ The following content is pushed down to the MCP layer and applied automatically
 |---------|--------------------------|-------------|
 | 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) |
 | Cross-network build detection + mainnet migration checklist | `query_toolkit` query_type='migration_preflight' | Q2 (testnet vs mainnet) |
-| Testnet faucet / mainnet bridge / airdrop / payment-token guidance | `wowok_buildin_info` action='funding guidance' / 'mainnet bridge tokens' | Q2 + Q4 |
+| Testnet faucet / mainnet bridge / airdrop / payment-token guidance | `wowok_buildin_info` info='funding guidance' / 'mainnet bridge tokens' | Q2 + Q4 |
 | Third-party arbitrator discovery | `onchain_events` type='ArbitrationEvent' (dedupe by `object`) | Q8 (arbitration) |
 | Safety rules (immutability, confirmation, object reuse) | `schema_query` action='get_safety_rules' | pre-publish + `goal_operation` action='aggregate_risks' |
 | Guard / Machine / Arbitration / Treasury design rules | `schema_query` action='get_guard_design_patterns' | build + `aggregate_risks` |
-| Common mistakes (field/unit/workflow pitfalls) | `wowok_buildin_info` action='common mistakes' | tool calls (proactive warnings) |
-| Deployment checklist (publish readiness) | `goal_operation` action='aggregate_risks' | deployment-scanner D-01..D-20 |
+| Common mistakes (field/unit/workflow pitfalls) | `wowok_buildin_info` info='common mistakes' | tool calls (proactive warnings) |
+| Deployment checklist (publish readiness) | `goal_operation` action='aggregate_risks' (findings carry CRITICAL/WARN severity) + wowok-auditor pre-publish gates | before service/machine publish |
 | Multi-round memory (decisions / feedback / problems) | `goal_operation` (Goal) + TaskProcess streams | every confirmation / user objection |
 
 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
 ### Q1 — What do you sell, and to whom? (industry alignment)
 
 - **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.
-- **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".
+- **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".
 - **Output to user**: the recommended industry + "buyers in this industry mainly worry about: …", in plain language.
 
 ### Q2 — Practice on testnet first, or go straight to mainnet?
 
 - **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.
-- **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.
-- **Reassurance**: testnet is free; mainnet gas can be obtained via bridge/airdrop (`wowok_buildin_info` action='funding guidance').
+- **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.
+- **Reassurance**: testnet is free; mainnet gas can be obtained via bridge/airdrop (`wowok_buildin_info` info='funding guidance').
 
 ### Q3 — Where do you serve? (service area / location)
 
@@ -105,8 +105,8 @@ Ask these in order; stop at 8. Frame each in business terms. Every question maps
 
 ### Q4 — Which currency do you accept? (payment token)
 
-- **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.
-- **MCP**: `wowok_buildin_info` action='funding guidance' (testnet=WOW) + action='mainnet bridge tokens' (USDT/USDC/ETH/BTC/WOW type tags).
+- **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.
+- **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).
 
 ### Q5 — What are your products, prices, and descriptions? (sales + WIP)
 
@@ -153,16 +153,16 @@ Run `goal_operation` action='aggregate_risks' before publish; fix ALL CRITICAL f
 
 ## Industry Selection Guide
 
-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'.
+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'.
 
 ---
 
 ## Deployment Checklist
 
-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.
+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.
 
 ---
 
 ## Common Errors
 
-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.
+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

@@ -25,8 +25,8 @@ The planner sits between the user's intent and the Harness execution loop. It do
 
 - **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.
 - **Scenario-driven**: The Scenario Registry maps common intent patterns to pre-built ODG templates. A fallback `general` template absorbs unmatched intents.
-- **Plan-before-write**: The full ODG is confirmed at R8 before any publish-bound object is created. Reversibility is tracked per object.
-- **Checkpointed**: The ODG is persisted after every round via `local_info_operation` so the Harness can resume on interruption.
+- **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".)
+- **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.
 
 ### What This Skill Does
 
@@ -40,7 +40,7 @@ The planner sits between the user's intent and the Harness execution loop. It do
 
 - User says "I want to build / set up / start / plan X"
 - L4 Harness opens a new Plan Loop cycle
-- User resumes an interrupted plan (read ODG checkpoint first)
+- User resumes an interrupted plan (read the Goal state and the workspace ODG file first)
 - Do NOT invoke for: live order operations, dispute resolution, or post-publish tuning — those go to wowok-provider / wowok-arbitrator.
 
 ### Output Contract
@@ -51,7 +51,7 @@ A confirmed ODG JSON document (see §ODG Data Structure) with: scenario tag, com
 
 ## ODG Data Structure
 
-The ODG (Object Dependency Graph) is the single output artifact, persisted via `local_info_operation` and consumed by the Harness:
+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:
 
 ```json
 {

package/wowok-provider/SKILL.md

@@ -55,13 +55,13 @@ For each item, the user must provide one of: **"Reuse existing: `<name_or_id>`"*
 
 | # | Item | User Must Provide | Why Not Fabricate |
 |---|------|-------------------|--------------------|
-| **R1** | **Account** | Account name/address. Default `""` is fine. | Safe default exists |
-| **R2** | **Permission** | Existing Permission to reuse, OR name + type_parameter for new. **Reuse strongly recommended.** | Controls access to ALL your services |
-| **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 |
-| **R4** | **Machine** | Nodes, state transitions (pairs), forward paths. | IS your business process |
-| **R5** | **Guards** | For each Guard: validation logic, conditions. Reuse or define new. | Enforces your business rules |
-| **R6** | **Guard Bindings** | Which Guard validates which Machine forward? | Wrong binding = unauthorized access |
-| **R7** | **Allocators** | For each outcome: who gets what %/amount? (e.g. "success: 95% me, 5% platform") | IS your revenue model |
+| **1** | **Account** | Account name/address. Default `""` is fine. | Safe default exists |
+| **2** | **Permission** | Existing Permission to reuse, OR name + type_parameter for new. **Reuse strongly recommended.** | Controls access to ALL your services |
+| **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 |
+| **4** | **Machine** | Nodes, state transitions (pairs), forward paths. | IS your business process |
+| **5** | **Guards** | For each Guard: validation logic, conditions. Reuse or define new. | Enforces your business rules |
+| **6** | **Guard Bindings** | Which Guard validates which Machine forward? | Wrong binding = unauthorized access |
+| **7** | **Allocators** | For each outcome: who gets what %/amount? (e.g. "success: 95% me, 5% platform") | IS your revenue model |
 
 **Conditionally Required:**
 
@@ -74,11 +74,11 @@ For each item, the user must provide one of: **"Reuse existing: `<name_or_id>`"*
 ### Information Collection Protocol
 
 ```
-STEP 0: Present checklist R1-R7 to user
+STEP 0: Present checklist Steps 1-7 to user
 ├── Each item: "Reuse or create new? Provide details."
 ├── Track status: [pending] / [confirmed: reuse <id>] / [confirmed: create]
 ├── If user indicates physical goods / customer_required → also confirm C1-C3
-└── ⛔ GATE: ALL R1-R7 must be [confirmed] before any on-chain action
+└── ⛔ GATE: ALL Steps 1-7 must be [confirmed] before any on-chain action
     └── NOT confirmed → STOP. Ask. Do NOT suggest creating service.
 ```
 
@@ -96,7 +96,7 @@ STEP 0: Present checklist R1-R7 to user
 
 ## Service Build Lifecycle
 
-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`.
+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`.
 
 **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`.
 
@@ -135,7 +135,7 @@ Service → permission, machine (immutable), order_allocators (immutable),
 Order (runtime) → builder, service snapshot, machine, progress, dispute (Arb[]), allocation
 ```
 
-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.
+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.
 
 ### Allocators + Machine Integration
 

package/wowok-supplier/SKILL.md

@@ -110,7 +110,7 @@ If the upstream merchant stalls or withholds, escalate in order:
 
 ## Own-Interest Surfacing
 
-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.
+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.
 
 ---