@wowok/skills 2.2.1 → 2.2.3

package/wowok-output/SKILL.md

@@ -19,25 +19,32 @@ always: true
 If user explicitly requests full/long addresses (e.g., "show full addresses", "do not abbreviate"),
 this skill's shortening rules are DISABLED — display complete 66-character addresses.
 
+## Client Rendering (authoritative)
+
+Inside the WoWok client, AI replies render every `0x…` address AUTOMATICALLY as
+the canonical address pill — local name (if any), system short id, auto-resolved
+object-type icon, and hover actions (copy / message / AI / on-chain query).
+Therefore: **write full `0x`-prefixed addresses in replies**; the client does the
+display formatting. The text rules below apply only to plain-text contexts
+where the client renderer is unavailable (CLI, raw logs).
+
 ## Short Address Format
 
-**MUST APPLY TO ALL ADDRESSES AND OBJECT IDs** (0x prefix + 64 hex chars = 66 chars total).
+**MUST APPLY TO ALL ADDRESSES AND OBJECT IDs** (0x prefix + up to 64 hex chars).
 
-Generate a short ID by the following rules:
-1. Remove `0x` prefix → get the hex string
-2. Take the first 5 characters (or fewer if the address is shorter)
+System-wide rule (identical to the client's `formatAddress`):
+1. Remove the `0x` prefix → hex string
+2. Keep the FIRST 4 and the LAST 3 hex chars, joined by `-`
 3. Convert to UPPERCASE
-4. **If all 5 characters are the same character** (e.g., `00000` → `AAAAA`), fall back to the last 5 characters, prefixed with `...`
-5. **If even the last 5 are all the same character** (extremely rare), find 5 consecutive characters near the middle that differ, wrapped with `...` on both sides
-6. **Display rule**: no parentheses by default; parentheses are only used when paired with a name (see Display Format Rules below)
+4. 7 hex chars or fewer → the whole string, uppercased
+5. Empty / missing → `--`
 
 **Examples**:
 | Full Address | Short ID | Rule |
 |---|---|---|
-| `0xa1d421902a3e5f2e4da7590e8f243712b3b3479d1a07c48c2de543184fc97a33` | `A1D42` | Normal: first 5 |
-| `0x00000123456789abcdef0123456789abcdef0123456789abcdef000000000000` | `...00000` | First 5 all same → last 5 |
-| `0x00000000000000000000000000000000000000000000000000000000000000000` | `...00000...` | Both ends all same → middle 5 |
-| `0x2` | `2` | Short address, take actual length |
+| `0xa1d421902a3e5f2e4da7590e8f243712b3b3479d1a07c48c2de543184fc97a33` | `A1D4-A33` | first 4 + `-` + last 3 |
+| `0x10ef0000000000000000000000000000000000000000000000000000000cda11` | `10EF-A11` | first 4 + `-` + last 3 |
+| `0x2` | `2` | ≤7 chars, as-is |
 
 ## Resolution Priority & Display Format
 
@@ -45,22 +52,22 @@ Generate a short ID by the following rules:
 
 Returns: `{ account?: string, local_mark?: string, address: string }`
 
-### Display Format Rules (STRICT)
+### Display Format Rules (STRICT — mirrors the client's `displayLabelOf`)
 
 | Condition | Display Format | Example |
 |-----------|----------------|---------|
-| **Both account AND local_mark exist** | `{account_name} \| {local_mark_name}({ID})` | `alice \| my_mark(A1D42)` |
-| **Only account exists** | `{account_name}({ID})` | `alice_wallet(A1D42)` |
-| **Only local_mark exists** | `{local_mark_name}({ID})` | `my_service(A1D42)` |
-| **Neither exists** | `{ID}` | `A1D42` |
+| **Named** (account or local_mark resolved) | `{name}` only — NEVER append the short id | `alice_wallet` |
+| **Unnamed** | `{SHORTID}` | `10EF-A11` |
+
+- A named object shows ONLY its name — no parentheses, no short id after it.
+- When both an account name and a local_mark exist, prefer the local_mark
+  (object names) for objects and the account name for user addresses.
 
 ---
 
-## Name Length Limit
+## Name Display
 
-- **Maximum display length**: 20 characters
-- **Overflow handling**: Truncate to 17 chars + `...`
-- **Example**: `three_body_signature_service_v2` → `three_body_sig...`
+- Display the resolved name in full — the client does NOT truncate names.
 
 # Amount Formatting Rules
 
@@ -100,10 +107,11 @@ Supported query types with `_money_display`:
 ```
 | # | Time | Sender | Service | Amount | Order |
 |---|------|--------|---------|--------|-------|
-| 1 | {time} | {name}(ABCDE) | {name}(ABCDE) | {amount} | ABCDE |
+| 1 | {time} | {name-or-SHORTID} | {name-or-SHORTID} | {amount} | SHORTID |
 ```
 
-**Note**: `{name}` follows Display Format Rules above (account | local_mark). If no name, show only the short ID (no parentheses).
+**Note**: `{name-or-SHORTID}` follows Display Format Rules above — name ONLY when
+resolved, otherwise the short id (no parentheses in either case).
 
 ## Event Type Fields
 
@@ -126,7 +134,7 @@ When user asks about field meanings:
 - **Sender**: Account that initiated the transaction
 - **Service**: Service object being ordered/interacted with
 - **Order Object**: Unique on-chain identifier for this order
-- **Short Address (ABCDE)**: Shortened ID for quick visual identification — see Short Address Format rules (first 5 chars; fallback to last 5 or middle 5 if all same)
+- **Short Address**: System-wide shortened id for quick visual identification — first 4 + `-` + last 3 hex chars, uppercase (see Short Address Format rules)
 
 ## Amounts
 - **Raw**: Actual U64 integer stored on-chain

package/wowok-planner/SKILL.md

@@ -27,7 +27,7 @@ Converts natural-language intent into an executable Object Dependency Graph (ODG
 
 > **Layer**: L3 Skill, primary planner for L4 Harness Plan Loop
 > **Related Skills**: [wowok-onboard](../wowok-onboard/SKILL.md) (guided execution), [wowok-machine](../wowok-machine/SKILL.md) (workflow design), [wowok-provider](../wowok-provider/SKILL.md) (post-plan operations)
-> Industry modes, Guard design patterns, safety rules, and tool references now live in the MCP knowledge layer — query via `project_operation` (`recommend_industry` / `list_modes`) and `schema_query` (`get_guard_design_patterns` / `get_safety_rules` / `get_tool_reference`).
+> Industry modes, Guard design patterns, safety rules, and tool references now live in the MCP knowledge layer — query via `industry_pack_operation` (`recommend_industry` / `list_modes`) and `schema_query` (`get_guard_design_patterns` / `get_safety_rules` / `get_tool_reference`).
 
 ---
 
@@ -96,7 +96,7 @@ The ODG (Object Dependency Graph) is the single output artifact, persisted via `
 }
 ```
 
-Each object has: `id`, `type`, `status` (planned/created/published), `reversible` (true/false), `dependencies` (other object IDs), `user_decisions` (typed fields). Phases gate progression — `risk_check` calls `evaluate_project` (evaluation_type='risk'), `final_audit` runs the pre-publish audit checklist (see wowok-auditor).
+Each object has: `id`, `type`, `status` (planned/created/published), `reversible` (true/false), `dependencies` (other object IDs), `user_decisions` (typed fields). Phases gate progression — `risk_check` calls `goal_operation` action='aggregate_risks' (with planned objects/operations), `final_audit` runs the pre-publish audit checklist (see wowok-auditor).
 
 **Dependency-chain ordering rules (authoritative, verified from Move/SDK):**
 1. **Service DRAFT is created BEFORE Machine** — Guards reference the Service by LocalMark NAME, so the Service skeleton must exist first to break the Guard↔Service circular dependency.

package/wowok-provider/SKILL.md

@@ -28,17 +28,17 @@ when_to_use:
 
 ## MCP Knowledge Layer
 
-The following rule tables have been pushed down to the MCP knowledge layer and are automatically applied during project operations. You do NOT need to manually check these — the MCP server enforces them.
+The following rule tables have been pushed down to the MCP knowledge layer and are automatically applied during on-chain operations. You do NOT need to manually check these — the MCP server enforces them.
 
 | Rule Category | Access via (MCP action) | Applied By |
 |---------------|--------------------------|------------|
-| Safety rules (confirmation, immutability, object reuse) | `schema_query` action='get_safety_rules' | `evaluate_project` + `onchain_operations` pre-publish |
-| Guard design patterns | `schema_query` action='get_guard_design_patterns' | `evaluate_project` (guard risk assessment) |
-| Machine topology rules | auto-applied | `evaluate_project` (machine risk assessment) |
-| Scenario mode defaults | `project_operation` action='list_modes' | `create_project` (pass `project_industry` parameter) |
+| Safety rules (confirmation, immutability, object reuse) | `schema_query` action='get_safety_rules' | `goal_operation` action='aggregate_risks' + `onchain_operations` pre-publish |
+| Guard design patterns | `schema_query` action='get_guard_design_patterns' | `goal_operation` action='aggregate_risks' (guard risk assessment) |
+| Machine topology rules | auto-applied | `goal_operation` action='aggregate_risks' (machine risk assessment) |
+| Scenario mode defaults | `industry_pack_operation` action='list_modes' / 'recommend_industry' | Referenced when recording the Goal and building the Service |
 | Tool reference (gas, faucet, wrappers) | `schema_query` action='get_tool_reference' | All tool calls automatically |
 
-**How to use**: Call `project_operation` with `action: "evaluate_project"` (evaluation_type='risk') after completing your puzzle — the MCP server will automatically apply all relevant safety rules and return risk findings.
+**How to use**: Call `goal_operation` with `action: "aggregate_risks"` after completing your puzzle (pass your planned objects/operations) — the MCP server will automatically apply all relevant safety rules and return risk findings.
 
 ---
 
@@ -124,13 +124,13 @@ Once R1-R7 confirmed, execute in strict order. Sub-tools are invoked via `wowok(
 
 **STEP 7 — Trust (Arbitration + compensation_fund)**: REUSE third-party Arbitration (MUST NOT share Service's Permission — E_ARBITRATION_PERMISSION_CONFLICT 33; don't create your own). `compensation_fund_add` (internal Balance<T>, not Treasury); fund>0 requires non-empty arbitrations (E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND 25); withdraw needs bPaused + lock elapsed.
 
-**STEP 8 — Publication**: pre-publish verify — (1) machineNode2file, (2) guard2file, (3) evaluate_project risk → fix CRITICAL, (4) permission indexes granted, (5) arb permission isolation, (6) contact ims+enabled → `onchain_operations` service `publish: true` (L1-LOCKED: machine/order_allocators/arbitrations).
+**STEP 8 — Publication**: pre-publish verify — (1) machineNode2file, (2) guard2file, (3) `goal_operation` aggregate_risks → fix CRITICAL, (4) permission indexes granted, (5) arb permission isolation, (6) contact ims+enabled → `onchain_operations` service `publish: true` (L1-LOCKED: machine/order_allocators/arbitrations).
 
 **STEP 9 — Post-publish + Test Order**: mutable fields (description/location/sales/customer_required/rewards add/repositories add). Test order: `order_new` (requires bPublished, else E_NOT_PUBLISHED) → disclose next nodes → advance (order.progress / progress.operate) → alloc_by_guard → verify distribution. User chooses test account (default: service-creation account).
 
 ### Post-Publish Mutability (SDK-LOCKED vs mutable)
 
-Served by MCP `schema_query` action='get_safety_rules' (immutability-after-publish). Summary: `buy_guard` / `sales` / `description` / `repositories` / `rewards` are mutable; `machine` / `order_allocators` / `arbitrations` are SDK-LOCKED (fork required to change).
+Served by MCP `schema_query` action='get_safety_rules' (immutability-after-publish). Summary: `buy_guard` / `sales` / `description` / `repositories` / `rewards` are mutable; `machine` / `order_allocators` / `arbitrations` are SDK-LOCKED (a new Service version is required to change them).
 
 ---
 
@@ -138,7 +138,7 @@ Served by MCP `schema_query` action='get_safety_rules' (immutability-after-publi
 
 ### Service Object Relationships
 
-> **Boundary conditions**: Service/Machine are IMMUTABLE after publish; Payment is FROZEN at creation; Order/Progress/Arbitration operations are irreversible. Use `get_project_detail` to check whether a project has published objects.
+> **Boundary conditions**: Service/Machine are IMMUTABLE after publish; Payment is FROZEN at creation; Order/Progress/Arbitration operations are irreversible. Use `query_toolkit` query_type='service_panorama' to check whether a Service has published objects.
 
 ```
 Service → permission, machine (immutable), order_allocators (immutable),
@@ -199,28 +199,28 @@ WOW is the default settlement token. For stablecoin-denominated revenue (fiat-pe
 
 ---
 
-## Project Iteration: Fork vs In-Place
+## Service Iteration: New Version vs In-Place
 
-When a merchant wants to modify an existing service (change workflow, add allocators, update guards), the AI must determine whether to modify the current version (in-place) or fork a new version.
+When a merchant wants to modify an existing service (change workflow, add allocators, update guards), the AI must determine whether to modify in place or build a new version.
 
 ### Decision Rule
 
 | Scenario | Strategy | MCP Action |
 |----------|----------|------------|
-| Service NOT yet published | **In-place** — modify the current version directly | `onchain_operations` (modify) |
-| Service IS published | **Fork** — create a new version, preserve original as read-only | `project_operation` → `create_version` (with `fork_from_version`) |
+| Service NOT yet published | **In-place** — modify the current draft directly | `onchain_operations` (modify) |
+| Service IS published | **New version** — build v2 objects and publish as a separate Service; v1 keeps running | `onchain_operations` (create + publish) |
 
-### Fork Workflow
+### New-Version Workflow
 
-When the service is already published and the user wants structural changes, use MCP `project_operation` action `create_version` (with `fork_from_version` parameter; original v1 stays read-only; no on-chain objects copied since they're immutable). Then work on v2 reusing v1 on-chain objects by address and creating new objects only for changed parts. Publish v2 when ready — v1 continues running uninterrupted.
+Published objects are IMMUTABLE on-chain — there is no in-place structural change and no version-fork tool. When the service is already published and the user wants structural changes, build the new version's objects with `onchain_operations`: reuse v1 objects by address where unchanged (Permission, Guards, Treasury, Contact…) and create new objects only for the changed parts (e.g. a new Machine). Then publish v2 as its own Service — v1 continues running uninterrupted as a separate, still-live Service.
 
-Before forking, verify necessity via `get_project_detail` → `has_published_object=true` confirms fork is required (published objects are immutable).
+Before building v2, verify necessity via `query_toolkit` query_type='service_panorama' — a published Service confirms a new version is required (published objects are immutable).
 
-### When to Recommend Forking
+### When to Recommend a New Version
 
-- User says "I want to change my workflow" → check if published → recommend fork
-- User says "I want to add a new product line" → if same Machine can handle it, in-place modify Service.sales; if needs new Machine, fork
-- User says "I want to change fund distribution" → if Service not published, in-place; if published, fork (allocators are frozen after publish)
+- User says "I want to change my workflow" → check if published → recommend a new version
+- User says "I want to add a new product line" → if same Machine can handle it, in-place modify Service.sales; if it needs a new Machine, a new version
+- User says "I want to change fund distribution" → if Service not published, in-place; if published, a new version (allocators are frozen after publish)
 
 ---
 

package/wowok-supplier/SKILL.md

@@ -32,9 +32,9 @@ The following content has been pushed down to the MCP knowledge layer and is app
 | Content | Access via (MCP action) | Applied Via |
 |---------|--------------------------|-------------|
 | Demand semantics (open vs guarded, present paths) | `schema_query` action='get' (demand object schema, or on-demand knowledge) | `onchain_operations` demand |
-| Supplier interest analysis (fund_flow / responsibility / leverage / stakes) | `project_operation` action='participation_radar' | role derivation → `supplier-interest` |
+| Supplier interest analysis (fund_flow / responsibility / leverage / stakes) | `query_toolkit` query_type='participation_radar' | role derivation → `supplier-interest` |
 | Demand/service matching | `evaluation_operation` action='demand_match' | read-only ranking |
-| Safety rules (immutability, object reuse, confirmation) | `schema_query` action='get_safety_rules' | `evaluate_project` + pre-publish |
+| Safety rules (immutability, object reuse, confirmation) | `schema_query` action='get_safety_rules' | `goal_operation` action='aggregate_risks' + pre-publish |
 
 This Skill keeps the supplier **conversation flow** — discover → present → fulfill → collect. The MCP layer handles rules, matching, and own-interest surfacing.
 
@@ -114,7 +114,7 @@ If the upstream merchant stalls or withholds, escalate in order:
 
 ## Own-Interest Surfacing
 
-Run `project_operation` action='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 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.
 
 ---