@wowok/skills 3.2.0 → 3.2.1

package/wowok-output/SKILL.md

@@ -2,203 +2,94 @@
 name: wowok-output
 description: "WoWok output processing and display — post-processes all WoWok tool responses for human-readable presentation. Handles address resolution, name mapping, amount formatting, and data visualization. Use when: AI has received response from any WoWok MCP tool; Response contains addresses requiring name resolution; Response contains amounts requiring human-readable formatting; User queries on-chain data (events, objects, tables)."
 metadata:
-  version: "2.0.0"
+  version: "2.1.0"
   role: shared
   loading: always
 ---
 
-# Address Display Rules
+# WoWok Output Rules
 
-## Environment split (read first)
+Post-process every WoWok tool response before showing it: resolve addresses, format monetary fields from `_money_display`, render tables consistently.
 
-Address rendering differs by environment — pick the correct mode:
+# Addresses
+
+## Environment split (decide first)
 
 | 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)
-
-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:
-
-- **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. 7 hex chars or fewer → the whole string, uppercased
-5. Empty / missing → `--`
-
-**Examples**:
-| Full Address | SHORTID | Rule |
-|---|---|---|
-| `0xa1d421902a3e5f2e4da7590e8f243712b3b3479d1a07c48c2de543184fc97a33` | `A1D4-A33` | first 4 + `-` + last 3 |
-| `0x10ef0000000000000000000000000000000000000000000000000000000cda11` | `10EF-A11` | first 4 + `-` + last 3 |
-| `0x2` | `2` | ≤7 chars, as-is |
-
-## Resolution priority
+| **WoWok client** (rich chip renderer) | Full `0x`+64 hex in prose or inline code — the client converts it to a chip (name, DEFAULT badge, type icon, popup). Attach NO labels yourself | always |
+| **Other / plain-markdown clients** | Resolved **name only**, else **SHORTID**; empty-name default account tagged `(default)` | only when the user explicitly asks |
 
-**Query Tool**: `query_toolkit` with `query_type: "local_names"`
+Both environments:
+- **NEVER hand-truncate with `…`** (`0x00f6…a5839` is forbidden — not resolvable, not copyable). SHORTID is the only compact form.
+- The full address is always present in the tool result in context, so a name/SHORTID display loses nothing.
+- Named → name ONLY, never `name 10EF-A11` and never append an id.
 
-Returns: `{ account?: string, local_mark?: string, address: string }`
+Explicit user overrides: "show full/complete/copyable address" → complete address in inline code (plus name when known: **alice_wallet** `0xFULL…`). "use short/compact" → SHORTID. WoWok client always stays full (the chip owns display).
 
-- 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.
+## SHORTID (system rule, same as client `formatAddress`)
 
----
-
-## Name Display
+1. Strip `0x`; 2. first 4 + `-` + last 3 hex chars; 3. UPPERCASE; 4. ≤7 hex chars → whole string uppercased; 5. empty/missing → `--`.
+Special: the blueprint sentinel `draft:<name>` is not an on-chain address — render `Draft`.
 
-- Display the resolved name in full — the client does NOT truncate names.
+| Full | SHORTID |
+|---|---|
+| `0xa1d42190…184fc97a33` | `A1D4-A33` |
+| `0x10ef0000…000cda11` | `10EF-A11` |
+| `0x2` | `2` |
 
-# Amount Formatting Rules
+## Resolution
 
-## Primary Source: `_money_display`
+Batch-resolve with `query_toolkit` query_type=`local_names` → `{ account?, local_mark?, address }[]`. Prefer `local_mark` for objects, account name for user addresses. Unnamed → chip (WoWok client) or SHORTID + `(default)` for the empty-name on-chain default account elsewhere.
 
-The MCP fund layer now annotates all monetary query results with `_money_display` — a map of field paths to `ChainValueDisplay` objects containing `{raw, display, symbol, decimals, precision_known, text}`. **Use `_money_display` directly when present** — it is the authoritative formatted display, consistent with the MCP's own precision resolution.
+# Amounts
 
-- `precision_known === true` → `text` field already contains the complete formatted string: e.g. `"2.2 WOW (decimals: 9; raw: 2200000000)"`
-- `precision_known === false` → `text` contains the raw value with a retry hint; show as-is (the true raw value is authoritative)
+## Primary: `_money_display`
 
-Supported query types with `_money_display`:
-- `account_balance` — balance and coin amounts
-- `onchain_objects` — Treasury, Service, Order, Allocation, Payment, Reward, Arb, Discount monetary fields
-- `onchain_table_item_treasury_history` / `onchain_table_item_reward_record` — table entry amounts
-- `onchain_received` — CoinWrapper balances
-- `onchain_transaction` — balance_changes (each change has its own `coin_type`)
-- `onchain_events` — NewOrderEvent.amount (via the order's Service generic token type)
+Monetary query results carry `_money_display`: a map of field paths → `{raw, display, symbol?, decimals?, token_type, precision_known, text}`. Use it directly — it is the authoritative precision-resolved display.
 
-## Fallback (when `_money_display` is absent)
+- `precision_known: true` → show `text` as-is, e.g. `2.2 WOW (decimals: 9; raw: 2200000000)`.
+- `precision_known: false` → `display === raw`, no conversion happened; show the raw value (optionally retry token resolution via `token_list`).
 
-**When in doubt, display raw value.**
+Annotated query types: `account_balance`; `onchain_objects` (Treasury/Service/Order/Allocation/Payment/Reward/Arb/Discount monetary fields); `onchain_table_item_treasury_history`, `onchain_table_item_reward_record`; `onchain_received` (CoinWrapper); `onchain_transaction` (balance_changes, each with its own `coin_type`, signed); `onchain_events` (`NewOrderEvent.amount`, resolved via the order's Service token type).
 
-| Condition | Display | Example |
-|-----------|---------|---------|
-| Token info UNAVAILABLE | Raw amount | `500000000` |
-| Token info AVAILABLE | Converted + symbol + precision | `2.2 WOW (decimals: 9; raw: 2200000000)` |
+## Fallback (no annotation)
 
-**Formula**: `converted = raw / (10 ^ decimals)`  
-**Format**: `{amount} {symbol} (decimals: {N}; raw: {raw})`
+When in doubt, raw. Token info unavailable → raw integer (`500000000`). Available → `raw / 10^decimals`, formatted `{amount} {symbol} (decimals: {N}; raw: {raw})`.
 
----
+# Events
 
-# Event Display Format
+Table template: `| # | Time | Sender | Service | Amount | Order |` — address cells follow the environment split.
 
-## Table Format
+Key fields of the common built-in events (authoritative list + triggers live in the MCP Event Semantics Registry):
 
-```
-| # | Time | Sender | Service | Amount | Order |
-|---|------|--------|---------|--------|-------|
-| 1 | {time} | {addr-cell} | {addr-cell} | {amount} | {addr-cell} |
-```
-
-**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
-
-| Event Type | Key Fields |
-|------------|------------|
-| `NewOrderEvent` | sender, service, amount, object |
-| `ProgressEvent` | order, operator, machine |
-| `ArbEvent` | arbitration, voter, order, service |
-| `DemandPresentEvent` | demand, presenter, service |
-| `DemandFeedbackEvent` | demand, feedbacker |
-| `NewEntityEvent` | entity |
-
----
+| Event | Key fields |
+|---|---|
+| `NewOrderEvent` | sender (base), object (Order), service, amount, allocation, progress |
+| `ProgressEvent` | object (Progress), machine, task (usually the Order), node, forward, hold |
+| `ArbEvent` | object (Arb case), arbitration, order, status, indemnity_amount, compensation_time |
+| `VoteEvent` | object (Arb), voter, agrees, weight |
+| `FeedbackEvent` | object (Arb), feedback |
+| `ArbitrationEvent` | object (service), location, description, fee, voting_guard_count |
+| `DemandPresentEvent` | object (Demand), service (Option), recommend |
+| `DemandFeedbackEvent` | object (Demand), service (Option), feedback, acceptance_score (0–100, Option) |
+| `DemandChangedEvent` | object (Demand), location, description, rewards |
+| `NewEntityEvent` | resource, referrer (Option) |
+| `ServiceEvent` / `AllocationEvent` / `TreasuryEvent` / `NewPaymentEvent` / `RewardClaimEvent` / `RewardFundEvent` | resolve via the registry rather than guessing field names |
 
-# Field Explanations
+# Field glossary
 
-When user asks about field meanings:
+- **Raw**: on-chain u64 in smallest units. **Converted**: after dividing by 10^decimals. **Decimals**: token precision.
+- **Time**: Unix **milliseconds**; render in the user's local time.
+- **Sender**: transaction initiator; **Service**: the ordered object; **Order object** (`object` field on `NewOrderEvent`): the order's unique id.
+- **SHORTID**: compact display (first4-`-`-last3 uppercase); never `…` truncation.
 
-## Addresses
-- **Sender**: Account that initiated the transaction
-- **Service**: Service object being ordered/interacted with
-- **Order Object**: Unique on-chain identifier for this order
-- **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 `…`.
+# Checklist
 
-## Amounts
-- **Raw**: Actual U64 integer stored on-chain
-- **Converted**: Human-readable after applying decimals
-- **Precision (N decimals)**: Number of decimal places
-- **`_money_display`**: MCP-annotated display map (see Amount Formatting Rules above)
+1. Collect unique addresses → one `local_names` batch.
+2. Read `_money_display` first; only fall back to `token_list` + manual conversion when absent.
+3. Apply the environment split (WoWok client: full addresses; others: name/SHORTID/`(default)`).
+4. Keep event field names exact per the table above.
+5. Render (tables: name/SHORTID cells unless full was requested).
 
-## Time
-- **Timestamp**: Unix milliseconds since epoch
-- **Human-readable**: Converted local time
-
----
-
-# Implementation Checklist
-
-- [ ] Extract unique addresses from response
-- [ ] 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
-- [ ] 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
-
----
-
-# Related Skills
-
-| Skill / MCP Knowledge | Purpose |
-|-------|---------|
-| MCP `schema_query` action='get_safety_rules' | Pre-operation safety checks (sunk from wowok-safety) |
-| MCP `schema_query` action='get_guard_design_patterns' | Guard design & validation (sunk from wowok-guard) |
-| MCP `schema_query` action='get_tool_reference' | Tool selection patterns (sunk from wowok-tools) |
-| [wowok-order](../wowok-order/SKILL.md) | Order lifecycle (buyer) |
-| [wowok-provider](../wowok-provider/SKILL.md) | Service management (merchant) |
-| [wowok-arbitrator](../wowok-arbitrator/SKILL.md) | Dispute resolution |
-| [wowok-machine](../wowok-machine/SKILL.md) | Workflow design |
-| [wowok-messenger](../wowok-messenger/SKILL.md) | Encrypted communication |
-
----
+> Design patterns and tool selection stay in the MCP knowledge layer: `schema_query` `get_safety_rules` / `get_guard_design_patterns` / `get_tool_reference`.

package/wowok-planner/SKILL.md

@@ -2,94 +2,46 @@
 name: wowok-planner
 description: "WoWok Planning Skill — the planning component of the L4 Harness Plan Loop. Converts natural-language intent into an executable Object Dependency Graph (ODG) plus a phased plan. Deterministic-first: rule tables and scenario templates drive planning; the LLM only clarifies intent. Produces an ODG consumed by the Harness execution loop, with checkpoints between phases. Not for direct execution — hand off to wowok-onboard or wowok-provider once the ODG is confirmed. Use when: User describes a new service intent and needs a build plan; the Harness opens a Plan Loop cycle; User asks \"what do I need to create to support X\"; User wants to reuse existing objects for a new service; User asks for a dependency graph or execution phases; User resumes an interrupted planning session."
 metadata:
-  version: "2.0.0"
+  version: "2.1.0"
   role: shared
   related: "wowok-onboard, wowok-auditor, wowok-provider"
 ---
 
 # WoWok Planning Skill
 
-Converts natural-language intent into an executable Object Dependency Graph (ODG) and phased execution plan. Deterministic-first: rules and scenario templates decide the shape; the LLM only clarifies ambiguity and translates free text into typed fields.
+Converts natural-language intent into an executable, dependency-ordered build plan. Deterministic-first: the MCP pipeline decides the shape; you only clarify ambiguity and translate free-text answers into typed fields. You NEVER execute chain transactions — the plan is materialized later via `onchain_operations`.
 
-> **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 `industry_pack_operation` (`recommend_industry` / `list_modes`) and `schema_query` (`get_guard_design_patterns` / `get_safety_rules` / `get_tool_reference`).
+> **Layer**: L3 Skill, planner for the L4 Harness Plan Loop
+> **Related**: [wowok-onboard](../wowok-onboard/SKILL.md) (guided execution), [wowok-auditor](../wowok-auditor/SKILL.md) (pre-publish gate), [wowok-machine](../wowok-machine/SKILL.md), [wowok-provider](../wowok-provider/SKILL.md)
+> Industry modes / Guard patterns / safety rules are MCP knowledge: `industry_pack_operation` (`recommend_industry` / `list_modes` / `derive_user_mode`) and `schema_query` (`get_guard_design_patterns` / `get_safety_rules` / `get_tool_reference`).
 
----
-
-## Overview
-
-The planner sits between the user's intent and the Harness execution loop. It does NOT execute MCP transactions directly — it produces an ODG document that the Harness consumes phase-by-phase. This separation enforces review-before-write: every irreversible action is visible in the plan before any transaction is signed.
-
-### Design Philosophy
-
-- **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 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.
+## The planning pipeline (all under `goal_operation`)
 
-### What This Skill Does
+Do not invent a plan format or gate names — the MCP owns the artifacts:
 
-- Classifies user intent against the Scenario Registry
-- Queries existing on-chain objects to decide reuse vs create per object
-- Emits an ODG with typed objects, dependencies, phases, and reversibility flags
-- Flags irreversible actions and fund-risk paths before handoff
-- Hands off to the Harness with a checkpoint plan and per-phase verification hooks
+1. **Industry** (optional first): `industry_pack_operation` `recommend_industry` with the intent text; confirm one of the returned modes (`list_modes` to see all; `derive_user_mode` to fork a custom one).
+2. **Guided wizard (default for merchants)**: `merchant_guide` — a stateless 10-step wizard (intent → industry → roles → deliverables → payment → trust → blueprint → score preview → harness checks → **creation_plan**). Pass the opaque `guide_state` back UNCHANGED each turn with the user's `guide_confirm`. Step 10 returns a topological `creation_plan` (order / object_type / depends_on / operation_hint) computed from the semantic graph — that order IS the plan.
+3. **Object-level pipeline (advanced / harness)**: `analyze_intent` (C1: parsed intent, per-object puzzle snapshots, missing dimensions, `recommended_creation_order`) → `aggregate_risks` (C2: blocking RISK status — pass the puzzles through UNCHANGED) → `trace_substeps` (C3: substep DAG + coherence verdict). Omit `puzzles` and pass `intent` to run C1→C2 in one call.
+4. **Materialize after GO**: create objects in `creation_plan` order via `onchain_operations` (that belongs to wowok-onboard / wowok-provider), then pass the pre-publish gate (wowok-auditor).
 
-### When to Invoke
-
-- 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 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
-
-A confirmed ODG JSON document (see §ODG Data Structure) with: scenario tag, complete object list with dependencies and reversibility, ordered phases, risk assessment, and a Harness handoff packet including checkpoint keys.
-
----
+## Checkpoints & resumability
 
-## ODG Data Structure
+- Round state lives in a Goal: `goal_operation` `create` → `approve` / `advance` (plus `bind` / `pause` / `complete` / `abandon` as the lifecycle requires). Never fake completion outside the Goal.
+- Persist human-readable plan artifacts with `workspace_operation` (`write` / `read` / `list`) so an interrupted session can resume. Do NOT use `local_info_operation` — that store is private customer-required info, not planning state.
+- On resume: read the Goal state and the workspace artifact first, then continue from the furthest confirmed step.
 
-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:
+## Invariants the plan must always satisfy
 
-```json
-{
-  "task_id": "task_20260714_001",
-  "scenario": "freelance",
-  "version": 1,
-  "status": "confirmed",
-  "account": "merchant_v1",
-  "objects": [
-    { "id": "obj_account", "type": "account", "status": "created", "reversible": true, "dependencies": [], "user_decisions": { "reuse": false, "network": "testnet" } },
-    { "id": "obj_permission", "type": "permission", "status": "planned", "reversible": true, "dependencies": ["obj_account"], "user_decisions": { "reuse": false, "indexes": { "provider": 1000 } } },
-    { "id": "obj_service", "type": "service", "status": "planned", "reversible": true, "dependencies": ["obj_permission"], "user_decisions": { "name": "...", "publish": "deferred", "note": "DRAFT first — Guards reference it by LocalMark NAME to break the Guard↔Service cycle" } },
-    { "id": "obj_machine", "type": "machine", "status": "planned", "reversible": false, "dependencies": ["obj_service", "obj_permission"], "user_decisions": { "nodes": [...], "forwards": [...], "publish": "deferred" } },
-    { "id": "obj_guard_*", "type": "guard", "status": "planned", "reversible": false, "dependencies": ["obj_machine", "obj_service"], "user_decisions": { "logic": "...", "note": "references machine node names + service name via LocalMark NAME" } },
-    { "id": "obj_treasury", "type": "treasury", "status": "planned", "reversible": true, "dependencies": ["obj_permission"], "user_decisions": { "reuse": false, "note": "optional fund pool for organizations; referenced by order_allocators as Entity recipient" } },
-    { "id": "obj_contact", "type": "contact", "status": "planned", "reversible": true, "dependencies": ["obj_permission", "obj_account"], "user_decisions": { "reuse": false, "messenger": true, "anti_spam": "open", "note": "Service.um → Contact → ims[]; messenger enabled + anti-spam configured" } },
-    { "id": "obj_arbitration", "type": "arbitration", "status": "planned", "reversible": true, "dependencies": ["obj_permission"], "user_decisions": { "reuse": true, "note": "REUSE third-party; permission MUST differ from Service (E_ARBITRATION_PERMISSION_CONFLICT); compensation_fund > 0 requires non-empty arbitrations" } }
-  ],
-  "phases": [
-    { "phase": 1, "objects": ["obj_account", "obj_permission"], "gate": "user_confirm" },
-    { "phase": 2, "objects": ["obj_service"], "gate": "user_confirm", "note": "Service DRAFT created BEFORE Machine so Guards can reference it by name" },
-    { "phase": 3, "objects": ["obj_machine", "obj_guard_*"], "gate": "risk_check", "note": "Machine + Guards designed together; guards bound to forwards before publish" },
-    { "phase": 4, "objects": ["publish_machine", "obj_treasury", "obj_allocator_*"], "gate": "allocation_audit", "note": "Machine published; Treasury (optional) created before order_allocators references it" },
-    { "phase": 5, "objects": ["obj_contact", "obj_arbitration"], "gate": "user_confirm", "note": "Contact + third-party Arbitration configured BEFORE publish; arbitration.permission != service.permission" },
-    { "phase": 6, "objects": ["publish_service"], "gate": "final_audit" }
-  ],
-  "risk_assessment": { "critical": [], "warnings": [], "irreversible_count": 1 }
-}
-```
+These are chain-enforced (the risk engine and auditor verify them — your plan must not fight them):
 
-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).
+1. **Machine published and bound before Service publish** — `service.machine` needs a published Machine; the binding is immutable afterward.
+2. **`order_allocators` set before `publish=true`** — permanently L1-locked at publish (no pause exception); personal merchants route to the Permission owner, organizations typically to a Treasury `Entity` recipient.
+3. **Arbitration permission ≠ Service permission** (`E_ARBITRATION_PERMISSION_CONFLICT`); a positive compensation fund requires non-empty arbitrations (`E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND`).
+4. **Contact configured before Service publish** — `Service.um → Contact → ims[]`, with the messenger account enabled and anti-spam set.
+5. Drafts may reference each other by LocalMark name while still unbound; respect the machine-derived `creation_plan` order when an edge is `required`.
 
-**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.
-2. **Machine + Guards are designed together** (one phase) — a forward's Guard depends on the Machine's node names; the Allocator's Guard depends on both Machine and Service.
-3. **Machine publishes before Service binds it** — `service.machine` must reference a *published* Machine.
-4. **`order_allocators` is L1-locked** — set it before `service.publish`; personal merchants route to Permission owner, organizations route to a Treasury (`Entity` recipient).
-5. **Contact (customer service)** is configured before Service publish — `Service.um → Contact → ims[]`, with the local account enabled as messenger and anti-spam set.
-6. **Arbitration is third-party and before publish** — `arbitration.permission != service.permission` (`E_ARBITRATION_PERMISSION_CONFLICT`); `compensation_fund > 0` requires non-empty `arbitrations` (`E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND`).
+## Boundaries
 
-These rules are the single source of truth for the dependency chain; the phase list above is their concrete serialization. Hand-off to `wowok-onboard` (Review opening + at most 8 business questions) follows this same chain.
+- Invoke on: "I want to build / set up / plan X", a new Plan Loop cycle, or resuming an interrupted plan.
+- Do NOT invoke for live order ops, disputes, or post-publish tuning → wowok-provider / wowok-arbitrator.
+- Naming note: the **R1–R10** rounds in MCP schemas are the Guard-authoring dialogue rounds (R1=intent … R10=verify), NOT plan phases. Label your own checklists "Step n", never "Rn".