@wowok/skills 2.2.2 → 2.2.4

package/wowok-collaborator/SKILL.md

@@ -32,7 +32,7 @@ The following content has been pushed down to the MCP knowledge layer and is app
 
 | Content | Access via (MCP action) | Applied Via |
 |---------|--------------------------|-------------|
-| Collaborator interest analysis (fund_flow / responsibility / leverage / stakes) | `project_operation` action='participation_radar' | role derivation → `collaborator-interest` |
+| 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 |
@@ -62,7 +62,7 @@ Two sub-kinds (derived on-chain, never asserted):
 
 ## What You Can Execute Now
 
-Run `project_operation` action='participation_radar' with your account + the order's Progress. It returns:
+Run `query_toolkit` query_type='participation_radar' with your account + the order's Progress. It returns:
 
 - `operable` — forwards YOU can execute right now (permission / named-operator path).
 - `waiting_on` — what the workflow waits on from other roles.

package/wowok-machine/SKILL.md

@@ -42,11 +42,11 @@ The following content has been pushed down to the MCP knowledge layer and is app
 
 | Content | Access via (MCP action) | Applied Via |
 |---------|--------------------------|-------------|
-| Node design rules (node type specs, forward guard patterns, topology limits) | auto-applied | `project_operation.create_project` (pass `project_industry`) + `project_operation.evaluate_project` |
-| Machine scene/template selection | auto-applied | `project_operation.create_project` (pass `project_industry`) |
-| Forward Guard design patterns | `schema_query` action='get_guard_design_patterns' | `project_operation.evaluate_project` |
-| Safety rules (immutability, confirmation) | `schema_query` action='get_safety_rules' | Pre-publish checks + `project_operation.evaluate_project` |
-| Publish gate (4-layer fail-closed: checklist → risk → user → environment) | auto-applied | `project_operation.evaluate_project` + pre-publish gate |
+| Node design rules (node type specs, forward guard patterns, topology limits) | auto-applied | Industry mode defaults (`industry_pack_operation` action='list_modes') + `goal_operation` action='aggregate_risks' |
+| Machine scene/template selection | auto-applied | Industry mode defaults (`industry_pack_operation` action='list_modes') |
+| Forward Guard design patterns | `schema_query` action='get_guard_design_patterns' | `goal_operation` action='aggregate_risks' |
+| Safety rules (immutability, confirmation) | `schema_query` action='get_safety_rules' | Pre-publish checks + `goal_operation` action='aggregate_risks' |
+| Publish gate (4-layer fail-closed: checklist → risk → user → environment) | auto-applied | `goal_operation` action='aggregate_risks' + pre-publish gate |
 
 This Skill keeps the **workflow conversation guidance**, **business flow design patterns**, and **machine lifecycle scripts**. The MCP layer handles node-design rule evaluation, scene/template selection, and risk aggregation.
 
@@ -74,7 +74,7 @@ This Skill keeps the **workflow conversation guidance**, **business flow design
 
 A Guard validates the Forward's execution condition. **Retained submissions**: when `retained_submission` is set on a Guard, submitted values are stored in Progress history, uniquely located by `(current_node, next_node, forward_name)`. Later nodes query these values from history.
 
-> **Guard construction**: Forward Guard design patterns (table design, computation trees, query instructions) now live in the MCP knowledge layer — query via `schema_query` action='get_guard_design_patterns', auto-applied via `project_operation.evaluate_project`. Query available Guard instructions via `wowok_buildin_info`.
+> **Guard construction**: Forward Guard design patterns (table design, computation trees, query instructions) now live in the MCP knowledge layer — query via `schema_query` action='get_guard_design_patterns', auto-applied via `goal_operation` action='aggregate_risks'. Query available Guard instructions via `wowok_buildin_info`.
 
 ### Threshold Mechanics
 
@@ -198,7 +198,7 @@ Decompose complex workflows into multiple Machines connected by Guard-based vali
 3. "Does any step depend on an external process completing first?"
 4. "Which party creates the sub-order, and which party verifies it?"
 
-> **Guard construction**: Cross-Machine Guards use `convert_witness` with Progress query instructions. Design rules now live in the MCP knowledge layer — query via `schema_query` action='get_guard_design_patterns', applied via `project_operation.evaluate_project`. Query available Guard instructions via `wowok_buildin_info`.
+> **Guard construction**: Cross-Machine Guards use `convert_witness` with Progress query instructions. Design rules now live in the MCP knowledge layer — query via `schema_query` action='get_guard_design_patterns', applied via `goal_operation` action='aggregate_risks'. Query available Guard instructions via `wowok_buildin_info`.
 
 ### Dual-Signature Consensus
 
@@ -234,7 +234,7 @@ All stem from the same root: **every on-chain object has a publish/create freeze
 | `refunded` (terminal) | `refund_routing` (routing) → Allocator fires |
 | N/A (dispute) | `arbiter_rule` (routing) → Arbitration off-Machine (no Allocator) |
 
-A complete R-M1-11-compliant rental topology is auto-generated by `project_operation.create_project` with `project_industry='rental'`.
+A complete R-M1-11-compliant rental topology ships as the `rental` industry mode's default Machine shape — query `industry_pack_operation` action='list_modes' for the per-industry defaults.
 
 ### Pre-Publish Validation Checklist
 
@@ -245,7 +245,7 @@ Before `publish: true`, verify:
 - [ ] **Every node has outgoing Forwards** (except terminals): no dead-end nodes
 - [ ] **Every node has incoming Pair** (except entry): no orphaned nodes
 - [ ] **All thresholds independently achievable**: no dead branches (competing Pair always wins first)
-- [ ] **⚠ R-M1-11 Compliance** (CRITICAL for deposit/refund scenarios): NO terminal nodes named `deposit_refunded`, `deposit_deducted`, `refunded`, or any name implying Machine-internal refund/deduction. Refund/deduction MUST flow through an **Allocator** triggered by a routing node (e.g., `return_approved`, `damage_confirmed`, `arbiter_rule`). Violating this causes funds to lock in the Machine with no Allocator path. Auto-enforced by MCP pre-publish checks and `project_operation.evaluate_project`.
+- [ ] **⚠ R-M1-11 Compliance** (CRITICAL for deposit/refund scenarios): NO terminal nodes named `deposit_refunded`, `deposit_deducted`, `refunded`, or any name implying Machine-internal refund/deduction. Refund/deduction MUST flow through an **Allocator** triggered by a routing node (e.g., `return_approved`, `damage_confirmed`, `arbiter_rule`). Violating this causes funds to lock in the Machine with no Allocator path. Auto-enforced by MCP pre-publish checks and `goal_operation` action='aggregate_risks'.
 - [ ] All Guards exist on-chain and tested (use `gen_passport`)
 - [ ] `namedOperator` vs `permissionIndex` correct per Forward
 - [ ] Every Forward has at least one of `namedOperator` or `permissionIndex`

package/wowok-messenger/SKILL.md

@@ -72,7 +72,7 @@ The on-chain **Contact** object (`operation_type: "contact"`) is the bridge betw
 
 **When to create**: Before Service publish, when `customer_required` is set (Service.um must point to a Contact). Reuse an existing Contact if you serve multiple Services with the same support channel.
 
-**Lifecycle**: Contact is mutable (unlike Proof/Guard). `im_add`/`im_remove` require permission index 453 (CONTACT_IM). No events emitted on IM mutations — poll `ims[]` field. If Contact is bound to `Permission.um` via `permission_um_set`, clear that binding BEFORE deleting the Contact (else dangling pointer). Full field constraints: MCP `schema_query` action='get' name='contact'.
+**Lifecycle**: Contact is mutable (unlike Proof/Guard). IM mutations (`onchain_operations` contact with `ims: {op:'add'|'set'|'remove'|'clear', im:[...]}`) require permission index 453 (CONTACT_IM). No events emitted on IM mutations — poll `ims[]` field. If Contact is bound to `Permission.um`, clear that binding (permission op: `um: null`) BEFORE deleting the Contact (else dangling pointer). Full field constraints: MCP `schema_query` action='get' name='contact'.
 
 ---
 

package/wowok-onboard/SKILL.md

@@ -37,13 +37,13 @@ The following content has been pushed down to the MCP knowledge layer and is app
 
 | Content | Access via (MCP action) | Applied Via |
 |---------|--------------------------|-------------|
-| Scenario mode defaults (per-industry Permission/Machine/Guard/Allocator) | `project_operation` action='list_modes' / 'create_project' | Auto-applied when `project_industry` is passed to `create_project` |
-| Safety rules (immutability, confirmation, object reuse) | `schema_query` action='get_safety_rules' | Pre-publish checks + `project_operation.evaluate_project` |
-| Guard / Machine / Arbitration / Treasury design rules | `schema_query` action='get_guard_design_patterns' | `project_operation.evaluate_project` |
+| Scenario mode defaults (per-industry Permission/Machine/Guard/Allocator) | `industry_pack_operation` action='list_modes' / 'recommend_industry' | Referenced when recording the Goal (`goal_operation` action='create') and when building each object |
+| Safety rules (immutability, confirmation, object reuse) | `schema_query` action='get_safety_rules' | Pre-publish checks + `goal_operation` action='aggregate_risks' |
+| Guard / Machine / Arbitration / Treasury design rules | `schema_query` action='get_guard_design_patterns' | `goal_operation` action='aggregate_risks' |
 | Common mistakes (field/unit/workflow pitfalls) | `wowok_buildin_info` action='common mistakes' | Tool calls (proactive warnings) |
-| Deployment checklist (publish readiness) | `project_operation` action='evaluate_project' | deployment-scanner D-01..D-20 |
+| Deployment checklist (publish readiness) | `goal_operation` action='aggregate_risks' (planned_objects / planned_operations) | deployment-scanner D-01..D-20 |
 
-This Skill keeps the **overall onboarding flow**, the **dependency-aware build order**, and the **user-driving interaction rhythm** (see below). Pass the user's industry to `create_project` (via `project_industry` parameter) and the MCP layer auto-fills the scenario defaults.
+This Skill keeps the **overall onboarding flow**, the **dependency-aware build order**, and the **user-driving interaction rhythm** (see below). The user's intent is recorded as a **Goal** (`goal_operation` action='create'); industry/scenario defaults come from `industry_pack_operation` action='recommend_industry' / 'list_modes', and the plan pipeline is `goal_operation` action='analyze_intent' — actual on-chain objects are created via `onchain_operations` in dependency order.
 
 ---
 
@@ -53,7 +53,7 @@ These four principles govern EVERY round. They are non-negotiable and replace th
 
 1. **Review-first**: Before the first user choice, the AI MUST output a review that states (a) its understanding of the user's task, (b) the dependency-chain overview, and (c) the interaction contract. Only AFTER this review is the first choice presented.
 2. **User-driven**: Every round is driven by an explicit user decision. The AI provides a `recommend` option but NEVER auto-advances. The user may pause at any important round to ask questions.
-3. **Reuse / Customize / Discover (三选一)**: For every component (Permission, Machine, Guard, Contact, Treasury, Arbitration, etc.), the AI MUST present three avenues — **reuse an existing object** (with its benefit), **customize a new object** (with its sub-task ability), or **discover an object** from other projects / the system. All three are mandatory to surface.
+3. **Reuse / Customize / Discover (choose one of three)**: For every component (Permission, Machine, Guard, Contact, Treasury, Arbitration, etc.), the AI MUST present three avenues — **reuse an existing object** (with its benefit), **customize a new object** (with its sub-task ability), or **discover an object** from other projects / the system. All three are mandatory to surface.
 4. **Default-config disclosure**: Before creating any new object, the AI MUST disclose the default configuration and important information (purpose, key settings, caveats), then let the user decide. No silent defaults.
 
 ---
@@ -110,7 +110,7 @@ Each round below lists: **Semantic meaning**, **Core elements to confirm**, **De
 - **Core elements to confirm**:
   - Account: **reuse an existing account** (name/address) or **create new** (default name).
   - Network: **testnet first** (recommended) or **mainnet directly**.
-  - Industry mode: pass to `create_project` as `project_industry` — see the Industry Selection Guide below.
+  - Industry mode: resolved via `industry_pack_operation` action='recommend_industry' — see the Industry Selection Guide below.
 - **Default config**: new account with a default name; testnet network; industry mode auto-fills scenario defaults (Machine shape, Guards, Allocator).
 - **Reuse / Customize / Discover**: Reuse an existing account (benefit: keeps objects under one identity) — or create new.
 - **Dependencies**: none (foundation).
@@ -145,7 +145,7 @@ Each round below lists: **Semantic meaning**, **Core elements to confirm**, **De
   - Business flow: node list + forward paths.
   - Permissions: per-forward `namedOperator` (`""`=OrderHolder / role name) or `permissionIndex`.
   - Acceptance: per-forward Guard (or inline) — what must be verified before the transition executes.
-- **Default config**: the industry mode's `machine_shape` + `guards` (query `project_operation` action='list_modes'). Disclose these defaults FIRST, then let the user accept or customize.
+- **Default config**: the industry mode's `machine_shape` + `guards` (query `industry_pack_operation` action='list_modes'). Disclose these defaults FIRST, then let the user accept or customize.
 - **Reuse / Customize / Discover**: Reuse an existing Machine template (`machineNode2file` export) or an existing Guard (`guard2file`). Customize: define your own nodes/forwards/guards. Discover: `machineNode2file` / `local_mark_list` for other projects' Machines/Guards.
 - **Dependencies**: Service draft (R3) + Permission (R2).
 - **R-M1-11 compliance**: Machine MUST use business-state nodes (e.g. `cancelled`, `returned`, `return_approved`), NOT dispute/refund terminal nodes (`refunded`, `deposit_refunded`, `disputed`, `arb`). Refund routes via Allocator; dispute routes via Arbitration.
@@ -214,7 +214,7 @@ Each round below lists: **Semantic meaning**, **Core elements to confirm**, **De
 - **Core elements to confirm** (each optional, each with default disclosure + reuse/customize/discover):
   - Reward (discounts/loyalty).
   - Supply-chain promises / Repository.
-  - Audit: `evaluate_project` (risk) — fix ALL CRITICAL findings.
+  - Audit: `goal_operation` action='aggregate_risks' — fix ALL CRITICAL findings.
 - **Default config**: none required — these are opt-in. The audit itself is mandatory.
 - **Reuse / Customize / Discover**: each optional component can be created or discovered.
 - **Dependencies**: R1–R9.
@@ -230,8 +230,8 @@ Each round below lists: **Semantic meaning**, **Core elements to confirm**, **De
 - **Core elements to confirm**:
   - **Test account**: which account places the order — default is the **service-creation account**, but the user may choose another account to simulate a buyer.
   - **Advance path**: at each node, the user chooses which next node to advance to.
-- **Per-node disclosure (before each advance)**: the MCP injects `semantic.workflow_guidance` (on query_toolkit Progress results: `_workflow_guidance` / `_workflow_guidance_text`) listing **ALL** reachable next nodes with their operator (`namedOperator=""` → order holder / `permissionIndex` → role / named operator), forward, weight, guard, business meaning, and a K3-framed recommendation (gains/risks/consistency). Relay this full list to the user (who can act, with which permission/account), then let the user choose — **AI 推荐、人决策** (K3 P3).
-- **After each advance**: relay `semantic.workflow_receipt` — which account did what, whether the node migrated; if it did NOT migrate and threshold > 0, report threshold / accumulated weight / remaining / who must act next (K3 G4 阈值配合).
+- **Per-node disclosure (before each advance)**: the MCP injects `semantic.workflow_guidance` (on query_toolkit Progress results: `_workflow_guidance` / `_workflow_guidance_text`) listing **ALL** reachable next nodes with their operator (`namedOperator=""` → order holder / `permissionIndex` → role / named operator), forward, weight, guard, business meaning, and a K3-framed recommendation (gains/risks/consistency). Relay this full list to the user (who can act, with which permission/account), then let the user choose — **AI recommends, human decides** (K3 P3).
+- **After each advance**: relay `semantic.workflow_receipt` — which account did what, whether the node migrated; if it did NOT migrate and threshold > 0, report threshold / accumulated weight / remaining / who must act next (K3 G4 threshold coordination).
 - **Default config**: test account = service-creation account.
 - **Reuse / Customize / Discover**: n/a (verification).
 - **Dependencies**: Service published (R11) — `order_new` requires `bPublished=true`.
@@ -241,13 +241,13 @@ Each round below lists: **Semantic meaning**, **Core elements to confirm**, **De
 
 ## Industry Selection Guide
 
-When the user describes their business (R1), query the authoritative industry list via `project_operation` action='list_modes' — 8 entries: `freelance` / `rental` / `education` / `travel` / `subscription` / `retail` / `retail_d2c` / `general`. If unsure which fits, call `project_operation` action='recommend_industry' with the business description. Pass the chosen `project_industry` to `create_project` — MCP auto-fills the scenario defaults (Machine shape, Guards, Allocator). Mid-onboarding iteration: `derive_user_mode` / `evolve_user_mode`.
+When the user describes their business (R1), query the authoritative industry list via `industry_pack_operation` action='list_modes' — 8 entries: `freelance` / `rental` / `education` / `travel` / `subscription` / `retail` / `retail_d2c` / `general`. If unsure which fits, call `industry_pack_operation` action='recommend_industry' with the business description. Reference the chosen mode when recording the Goal (`goal_operation` action='create') and when building the Service — its defaults (Machine shape, Guards, Allocator) inform each round's config disclosure. Mid-onboarding iteration: `industry_pack_operation` action='derive_user_mode' / 'evolve_user_mode'.
 
 ---
 
 ## Deployment Checklist
 
-Before declaring onboarding complete, run `project_operation` action='evaluate_project' (risk) — MCP auto-checks machine binding, order_allocators, buy_guard, arbitration isolation, R-M1-11 compliance, and publish readiness (deployment-scanner D-01..D-20). Fix ALL CRITICAL findings, then verify the 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 publish readiness (deployment-scanner D-01..D-20) against your planned objects/operations. Fix ALL CRITICAL findings, then verify the remaining hard gates via `query_toolkit` (onchain_objects). The authoritative checklist is served by MCP — do not re-derive it here.
 
 ---
 

package/wowok-order/SKILL.md

@@ -3,9 +3,9 @@ name: wowok-order
 description: |
   WoWok Buyer Guide — TWO lifecycles in one skill:
 
-  1. PROSPECT (潜在用户尽调, pre-purchase): E1-E11 due diligence + consensus
+  1. PROSPECT (prospect due diligence, pre-purchase): E1-E11 due diligence + consensus
      building + trust-score synthesis, ending in a buy/no-buy decision.
-  2. CUSTOMER (已下单履约, post-order): order creation, progress advancement,
+  2. CUSTOMER (in-order fulfillment, post-order): order creation, progress advancement,
      fund management, and arbitration.
 
   For suppliers presenting to Demands, see wowok-supplier. For process
@@ -32,8 +32,8 @@ when_to_use:
 
 | Lifecycle | Role | Phases | Ends with |
 |-----------|------|--------|-----------|
-| **Prospect** (潜在用户尽调) | You have NOT ordered yet | Phase 1 (E1-E11) + Phase 2 | buy / no-buy decision |
-| **Customer** (已下单履约) | You are the Order `builder` | Phase 3-6 + Fund Management | funds withdrawn / dispute resolved |
+| **Prospect** (prospect due diligence) | You have NOT ordered yet | Phase 1 (E1-E11) + Phase 2 | buy / no-buy decision |
+| **Customer** (in-order fulfillment) | You are the Order `builder` | Phase 3-6 + Fund Management | funds withdrawn / dispute resolved |
 
 The prospect lifecycle is served primarily by MCP `trust_score` (`depth: "preorder"`) and the plug-in `evaluation_operation` — this skill keeps the dialogue flow. The customer lifecycle is on-chain (Order/Progress/Allocation/Arb).
 

package/wowok-output/SKILL.md

@@ -14,53 +14,89 @@ always: true
 
 # Address Display Rules
 
-## Override Condition
+## Environment split (read first)
 
-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.
+Address rendering differs by environment — pick the correct mode:
 
-## Short Address Format
+| Environment | Default display | Full address |
+|---|---|---|
+| **WoWok client** (rich renderer available) | Full address — the client converts it into an address chip (name, DEFAULT badge, type icon, popup) | Always |
+| **Other AI clients** (plain MCP clients, markdown only) | Name when resolved, otherwise SHORTID; DEFAULT marker on the default account | ONLY when the user explicitly asks |
+
+Rules that hold in BOTH environments:
+- **NEVER truncate with `…`** (e.g. `0x00f6…a5839` is FORBIDDEN). It is neither a valid full address nor a valid SHORTID — it cannot be resolved, copied, or acted on. The only compact form allowed is the SHORTID transform defined below.
+- The full 66-character address is ALWAYS present in the tool results injected into your context — nothing is lost when you display a name/SHORTID; you can produce the full address on request.
+
+## Inside the WoWok client (rich rendering — authoritative)
+
+The client renders EVERY complete `0x`-prefixed address in your reply
+automatically as the canonical address chip — local name, DEFAULT badge,
+first-byte object-type icon, and hover popup (Explorer / Analyze / AI / copy).
+
+Therefore:
+- Write the full address in prose OR in inline code — both become chips.
+- Do NOT attach names, labels, short ids, or parentheses to an address (no `(default)`, no `Name 0x<full-address>`); the client resolves and renders name/type/DEFAULT state itself.
+
+## Other AI clients (generic MCP clients — plain markdown, no custom renderer)
 
-**MUST APPLY TO ALL ADDRESSES AND OBJECT IDs** (0x prefix + 64 hex chars = 66 chars total).
+External clients render standard markdown only (no popup, no chips). Default to
+a CONCISE display — full 66-char addresses are noisy and are not shown unless
+asked:
 
-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)
+- **Named** (account name or local_mark resolved via `local_names` / tool
+  results): show the NAME ONLY, e.g. `alice_wallet`. Never append an id.
+- **Unnamed**: show the SHORTID (format below), e.g. `10EF-A11`.
+- **Default account** (the on-chain default account, which has an empty name):
+  mark it as `(default)`, e.g. `(default) 10EF-A11`.
+- In tables: name or SHORTID in the cell; the full address is omitted by default.
+- **Full address on request**: when the user explicitly asks to see full /
+  detailed / complete addresses ("show the full address", "give me the complete
+  address", "copyable address"), output the COMPLETE `0x` + 64 hex chars
+  wrapped in inline code so it is one-click copyable in any markdown client.
+  When a name is known, put name + full address together:
+  **alice_wallet** `0xFULLADDRESS`.
+
+## User override
+
+- Other clients, "show full / long / complete addresses" → output the full inline-code address for that reply.
+- Other clients, "use short / compact" → SHORTID (already the default for unnamed addresses).
+- WoWok client: always full addresses regardless — the chip renderer handles display.
+
+## SHORTID format
+
+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 |
+| Full Address | SHORTID | 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
+## Resolution priority
 
 **Query Tool**: `query_toolkit` with `query_type: "local_names"`
 
 Returns: `{ account?: string, local_mark?: string, address: string }`
 
-### Display Format Rules (STRICT)
-
-| 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): display the name ONLY (WoWok client
+  renders the name chip itself; other clients show the name).
+- Unnamed: WoWok client → full address (chip); other clients → SHORTID.
+- The account with an empty name that is the on-chain default → other clients
+  tag it `(default)`; the WoWok client adds its DEFAULT badge automatically.
+- When both an account name and a local_mark exist, prefer 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 +136,12 @@ Supported query types with `_money_display`:
 ```
 | # | Time | Sender | Service | Amount | Order |
 |---|------|--------|---------|--------|-------|
-| 1 | {time} | {name}(ABCDE) | {name}(ABCDE) | {amount} | ABCDE |
+| 1 | {time} | {addr-cell} | {addr-cell} | {amount} | {addr-cell} |
 ```
 
-**Note**: `{name}` follows Display Format Rules above (account | local_mark). If no name, show only the short ID (no parentheses).
+**Address cells follow the environment split above**:
+- WoWok client → the cell contains the full address (rendered as an address chip automatically).
+- Other clients → the cell contains the resolved name or the SHORTID (default account tagged `(default)`); full addresses only when the user explicitly asked for them.
 
 ## Event Type Fields
 
@@ -126,7 +164,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 (SHORTID)**: Compact display form (first 4 + `-` + last 3 hex chars, uppercase). Default for unnamed addresses in other AI clients; the WoWok client applies it automatically inside its address chips. Never hand-truncate with `…`.
 
 ## Amounts
 - **Raw**: Actual U64 integer stored on-chain
@@ -146,7 +184,10 @@ When user asks about field meanings:
 - [ ] Query `local_names` for resolution
 - [ ] Check for `_money_display` annotations in query results (primary amount source)
 - [ ] If `_money_display` absent, query `token_list` for manual amount formatting
-- [ ] Apply address format rules
+- [ ] Address display: WoWok client → full `0x`+64 hex addresses (auto chips);
+      other clients → resolved name, or SHORTID for unnamed / `(default)` for the
+      default account; full inline-code address only when the user asks
+- [ ] Never hand-truncate addresses with `…` — SHORTID is the only compact form
 - [ ] Apply amount format rules (use `_money_display` first; fallback to conservative)
 - [ ] Render final output
 

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.
 
 ---
 
@@ -48,7 +48,7 @@ These four principles govern every service build/modify step. They mirror the wo
 
 1. **Review-first**: State (a) what the AI understood about the service, (b) the dependency order to build/modify, 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. The user may pause at any important step.
-3. **Reuse / Customize / Discover (三选一)**: For every component (Permission, Machine, Guard, Treasury, Contact, Arbitration, etc.), surface all three avenues — reuse an existing object (benefit), customize a new one (sub-task ability), or discover from other projects / the system.
+3. **Reuse / Customize / Discover (choose one of three)**: For every component (Permission, Machine, Guard, Treasury, Contact, Arbitration, etc.), surface all three avenues — reuse an existing object (benefit), customize a new one (sub-task ability), 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.
 
 ---
@@ -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.
 
@@ -55,7 +55,7 @@ Your payment is a two-hop waterfall: main order escrow → allocation → your s
 
 1. **Review-first**: State (a) what the AI understood, (b) the decision order, 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 (三选一)**: For every component (service, passport, guard), surface reuse / customize / discover.
+3. **Reuse / Customize / Discover (choose one of three)**: For every component (service, passport, guard), surface reuse / customize / discover.
 4. **Default-config disclosure**: Disclose defaults + caveats BEFORE the user decides.
 
 ---
@@ -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.
 
 ---