@wowok/skills 1.3.4 → 2.0.1

package/wowok-safety/SKILL.md

@@ -1,275 +0,0 @@
----
-name: wowok-safety
-description: |
-  WoWok operational safety and best practices — ensures AI follows correct
-  conventions for security, transaction confirmation, object building workflow,
-  and common mistake prevention.
-
-  This skill is AUTOMATICALLY triggered before any on-chain operation.
-when_to_use:
-  - AI is about to execute an on-chain write operation
-  - AI is about to transfer funds or modify financial parameters
-  - AI is about to publish a Service or Machine
-  - AI is building multiple interdependent objects
-  - User mentions "confirm", "approve", "safe", "warning", "best practice"
-always: true
----
-
-# WoWok Safety & Best Practices
-
-## 1. Core Principles
-
-### 1.1 Object Reuse Principle (General Best Practice)
-
-**ALWAYS prefer reusing existing objects over creating new ones** — this enables centralized permission control and reduces management overhead.
-
-| Object Type | Reuse Strategy | Why |
-|-------------|----------------|-----|
-| **Permission** | **Strongly recommended** — ask user for existing Permission name/ID | Centralized permission control across all services |
-| Machine | Reuse if workflow fits | Save design time for similar processes |
-| Guards | Reuse if validation logic matches | Avoid redundant rules |
-| Contact | Reuse existing customer service Contact | Single point of management |
-| Arbitration | Always reuse existing Arbitration services | Customers choose from established arbiters |
-
-**How to Reuse**:
-- Ask user: *"Do you have an existing object you'd like to reuse? Provide the name or ID."*
-- Use string value `"<name_or_id>"` to reference existing objects
-- Use object shape `{ name?, ... }` only when creating new
-
-**CREATE vs MODIFY Pattern** (SDK-enforced, not Move-level):
-| Format | Meaning | Use When |
-|--------|---------|----------|
-| String `"<name>"` or `"<0x...>"` | **REUSE** existing | Object already exists |
-| Object `{ name?, ... }` | **CREATE** new | Need new object |
-
-The SDK resolves names to addresses via `GetObjectExisted()` — a string that fails resolution triggers a hard error. An object shape always creates.
-
-### 1.2 Security & Safety
-
-- **Hot Wallet Usage**: WoWok never exposes private keys. Treat it as a spending account for transfers, receipts, and commerce. Flag large transactions for explicit user confirmation.
-- **Amount-Sensitive Operations**: Any token transfer, payment, or reward distribution MUST be verbally confirmed with the user before execution. Use `Payment` objects for commercial transfers when possible (they offer Guard validation and purpose tracking).
-
-### 1.3 LOCAL vs ON-CHAIN
-
-| Type | Tools | Gas | Confirmation |
-|------|-------|-----|--------------|
-| **LOCAL ONLY** | `account_operation`, `local_mark_operation`, `local_info_operation` | None | Not needed |
-| **ON-CHAIN** | `onchain_operations`, `messenger_operation` (some ops), `wip_file` (sign) | Yes | Required |
-| **QUERY** | `query_toolkit`, `onchain_table_data`, `onchain_events`, `guard2file`, `machineNode2file` | Read-only | Not needed |
-| **ENCRYPTED** | `messenger_operation` (watch/send messages) | Local encryption | Not needed |
-
-### 1.4 Default Account
-
-Empty string `""` means the default account. Always use `""` when the user does not specify an account.
-
----
-
-## 2. Transaction Confirmation Protocol
-
-**Core rule**: NEVER execute an on-chain write without explicit user confirmation.
-
-### 2.1 Confirmation Template
-
-Present a preview table (Operation, Object, Network, Account) with a warning describing what will happen, then ask: "Proceed with execution?"
-
-### 2.2 Amount Verification
-
-- Always display amounts with token symbol (e.g., "10 WOW" not "10000000000").
-- Query token decimals first if unsure.
-
-**Tool**: `query_toolkit` with `query_type: "token_list"`.
-
-- **Amounts in operations are ALWAYS submitted as U64 integers**. If the user specifies "2 WOW", do NOT submit the string "2 WOW". Instead, calculate and submit `2000000000` (2 × 10^9, where 9 is WOW's decimals).
-- **Never assume token decimals**. If the token's decimals cannot be queried, HALT the amount submission and alert the user. Do not proceed with hardcoded or guessed precision.
-- Show both raw and human-readable amounts when clarifying with users.
-
-### 2.3 Publish Confirmation
-
-Before publishing a Service or Machine: (1) Export and review — use `guard2file` to export Guard definitions, `machineNode2file` to export Machine nodes; (2) Verify logic — confirm Guards and Machine nodes match user intent; (3) Warn about immutability — once published, many fields become locked. Present a publish confirmation warning listing what becomes immutable, then ask: "This action cannot be easily undone. Proceed?"
-
-#### 2.3.1 R-M1-11 Pre-Publish Hard Gate (Refund/Deduction Topology)
-
-For any Machine touching deposits, refunds, escrow, or deductions (rental, freelance milestone, dispute-aware e-commerce), the AI MUST verify R-M1-11 compliance before allowing publish:
-
-- **Hard blocker**: any node named `deposit_refunded`, `deposit_deducted`, `refunded`, or any name implying the Machine itself performs fund movement.
-- **Required pattern**: refund/deduction flows through an **Allocator** triggered by a routing node (e.g., `return_approved`, `damage_confirmed`). The Allocator watches `progress.current == <routing_node>` and executes fund movement.
-- **Dispute path**: `arbiter_rule` (routing) → Arbitration off-Machine — no Allocator; arbitration::dispute handles fund distribution.
-- **Verification**: review the `machineNode2file` export and grep node names against the forbidden list. If any match, BLOCK publish and alert the user.
-
-**Why critical**: A refund terminal node without a bound Allocator causes funds to lock permanently in the Order escrow — there is no primitive to move funds out. This was the root cause of P0-01 (Turo deployment: `deposit_refunded` node locked 0.25 WOW customer refunds). See [wowok-machine](../wowok-machine/SKILL.md) "R-M1-11 Anti-Pattern" and [wowok-scenario](../wowok-scenario/SKILL.md) "Rental Mode Template (R-M1-11 Compliant)".
-
----
-
-## 3. Common Mistakes to Avoid
-
-| Mistake | Why It Happens | Prevention |
-|---------|---------------|------------|
-| **Forgetting no_cache** | Cache lag in dependency chain | Set `env.no_cache: true` on all operations when building multiple objects |
-| **Missing permission indices** | Machine forwards reference non-existent indices | Verify Permission object has required indices before creating Machine |
-| **R-M1-11 violation** (refund terminal node) | Designing Machine with `deposit_refunded`/`deposit_deducted`/`refunded` nodes implying the Machine refunds — funds lock in escrow with no Allocator path (root cause of P0-01) | Use routing nodes (`return_approved`/`damage_confirmed`/`arbiter_rule`) + bound Allocators; grep `machineNode2file` output for forbidden names BEFORE publish |
-
----
-
-## 4. Naming Conventions
-
-When users request complex systems without naming, propose this scheme:
-
-```
-<projectPrefix>_<type>_<purpose>_<version>
-```
-
-| Part | Example | Purpose |
-|------|---------|---------|
-| Project prefix | `shopFunny_` | Prevents cross-project collisions |
-| Type prefix | `machine_`, `guard_`, `service_` | Clarifies object type |
-| Purpose suffix | `serviceWithdraw` | Describes function |
-| Version suffix | `_v2` | Enables iteration |
-
-- Always provide `tags` on object creation for filtering and management
-- Use short address form (`0x1234...def`); use names as primary identifiers
-
-### 4.1 `replaceExistName` Flag
-
-Controls name collision behavior. **DISCOURAGED** — prefer versioned names (`_v1`, `_v2`).
-
-| Value | Effect |
-|-------|--------|
-| `false` (default) | Throws error if name is in use — safe default |
-| `true` | Existing object/account with the same name is **suspended** (deactivated) to free the name |
-
-**Account-specific rules** (stricter than on-chain objects):
-- `replaceExistName: true` on the **default account** (`name=''` or omitted) is **FORBIDDEN** — throws error. The default account is unique and cannot be suspended by replacement; use `suspend()` explicitly if needed.
-- On non-default account names, `replaceExistName: true` **suspends** the old account (moves to Suspended tab, clears name + messenger). The old account can be reactivated via `resume(address, new_name)`.
-- This prevents the "orphan unnamed account" bug where old accounts leaked into the Active list without a name.
-
-**On-chain objects** (NamedObjectSchema): `replaceExistName: true` steals the name; the old object becomes unnamed (address-only reference). Prefer versioned names for production.
-
----
-
-## 5. Network & Token Defaults
-
-| Parameter | Default Value | Notes |
-|-----------|---------------|-------|
-| Network | `testnet` | Override via `env.network` |
-| Token | `0x2::wow::WOW` | 9 decimals (1 WOW = 1_000_000_000) |
-
-### 5.1 Multi-Token Support & Amount Formats
-
-- **Multi-Token**: All operations support custom `token_type`. ALWAYS query precision via `query_toolkit` with `query_type: "token_list"` first. Never assume decimals.
-- **Amount Formats**:
-  - With unit: `"2WOW"`, `"10.5USDT"` — auto-converted using token precision.
-  - Plain number: internal unit (e.g., `1000000000` = 1 WOW). Always clarify with users when displaying plain numbers.
-- **U64 integers**: Amounts in operations are ALWAYS submitted as U64 integers. If the user specifies "2 WOW", do NOT submit the string "2 WOW" — calculate and submit `2000000000` (2 × 10^9).
-- **Never assume token decimals**: If the token's decimals cannot be queried, HALT the amount submission and alert the user.
-
-### 5.2 Payment Objects for Commercial Transfers
-
-Use `Payment` objects for commercial transfers when possible — they offer Guard validation and purpose tracking beyond a simple `account_operation (transfer)`.
-
-### 5.3 Cross-Network Switching (testnet → mainnet)
-
-WoWok objects are network-specific — the same object name resolves to different addresses on testnet vs mainnet. The `local_mark` system manages this mapping automatically.
-
-**Prerequisites**:
-- testnet deployment verified (all objects created, order lifecycle tested)
-- Record all object names (query `local_mark_list` for the full list)
-- mainnet account has sufficient WOW balance (faucet is testnet-only; use `account_operation transfer` from a funded mainnet account)
-
-**Switching Steps**:
-1. Change `env.network` from `"testnet"` to `"mainnet"` in all MCP calls
-2. Re-create all objects on mainnet with `replaceExistName: true` (names stay the same, addresses change)
-3. Order matters — follow the dependency chain: Permission → Machine → Guards → Contact → Service → (Order/Progress/Allocation are created at purchase time)
-4. Verify each object creation succeeds and `local_mark` is updated
-5. Test the critical path: place a test order → advance Progress → verify Allocation
-
-**Key Mechanism**:
-```
-testnet:  local_mark["my_service"] = 0x867a...  (testnet address)
-mainnet:  local_mark["my_service"] = 0xdef0...  (mainnet address, auto-overwritten)
-```
-- All object references in Guard tables, Service bindings, and Machine forwards use NAMES (not addresses)
-- SDK's `GetObjectExisted()` resolves names to the current network's address at transaction build time
-- `replaceExistName: true` ensures the name mapping is overwritten for the new network
-
-**Important Notes**:
-- testnet objects remain on testnet (they don't disappear) — mainnet is a completely fresh deployment
-- Guard tables that reference other objects by NAME will auto-resolve to mainnet addresses
-- Service.order_allocators and Machine nodes are immutable after publish — verify design before mainnet publish
-- mainnet has no faucet — fund accounts via `account_operation` with `transfer` from an existing funded account
-
-### 5.4 Publish Pre-Check Checklist
-
-Before calling `publish: true` on a Service or Machine, verify:
-
-**Service Publish Checklist**:
-- [ ] `order_allocators` is set and design is verified (PERMANENTLY immutable after publish)
-- [ ] `machine` is bound and already published
-- [ ] `buy_guard` is bound (if purchase validation is needed)
-- [ ] `permission` is bound with all required indexes granted
-- [ ] If `compensation_fund > 0`: `arbitrations` MUST be bound (contract enforces: `E_ARBITRATION_NOT_SET_WITH_COMPENSATION_FUND`)
-- [ ] All Guard names in `order_allocators` resolve correctly
-- [ ] All sharing amounts and recipient types (Entity/Signer/GuardIdentifier) are intended
-- [ ] Use `dry_run: true` first to simulate the publish transaction
-
-**Machine Publish Checklist**:
-- [ ] All nodes have at least one forward (except terminal nodes)
-- [ ] Each forward has `namedOperator` or `permissionIndex` (or both = OR semantic)
-- [ ] `namedOperator: ""` means OrderHolder (customer), NOT "anyone"
-- [ ] All `permissionIndex` values are granted in the bound Permission object
-- [ ] Entry node has `prev_node: ""` and `threshold: 0`
-- [ ] Terminal nodes have empty `pairs: []`
-
----
-
-## 6. Query-First Pattern
-
-- **Query before mutate**: Always query current state before modifications.
-
-**Tool**: `query_toolkit` with appropriate filters.
-
-- **Pagination**: All on-chain list queries (events, tables, received) support `cursor`/`limit`. Loop for large datasets.
-- **Cache control**: Use `no_cache: true` for time-sensitive reads.
-
----
-
-## 7. Error Patterns
-
-| Error | Likely Cause |
-|-------|-------------|
-| Guard validation failure | After re-submitting with `submission`, Guard logic evaluated to false. Review Guard's rule tree via `guard2file` and submitted data values. |
-| File parsing failure | `machineNode2file` or `guard2file` output format error. Check file format and schema compliance. |
-| Cache stale reads | Sequential operations fail unexpectedly (e.g., "object not found" when just created). Retry with `env.no_cache: true`. |
-| Permission denied | Operating account lacks the required Permission index. Check the object's Permission configuration. |
-
----
-
-## 8. Testing & Validation Workflow
-
-1. **Design Phase**: Discover available permissions, Guard instructions, and value types via `wowok_buildin_info` (`info: "built-in permissions"` / `"guard instructions"` / `"value types"`).
-2. **Export & Review**: Before publishing, use `guard2file` and `machineNode2file` to export and review definitions.
-3. **Incremental Testing**: Build objects step-by-step, verifying each step.
-4. **Final Validation**: Test all Guard conditions and Machine transitions before publishing.
-5. **Publish**: Only after thorough testing, publish Service and Machine.
-
-### 8.1 Value Types — Built-in Type Annotation System
-
-Every data field in a Guard table or submission carries a `value_type` annotation. Value types matter when: defining Guard table columns, submitting data to Guards, reading `guard2file` exports, and designing query instructions. **String format is recommended** (`"U64"`, `"Address"`, `"VecString"`) for readability; numeric codes (0–18) are accepted but obscure. `Value` (19) is protocol-internal — never use in user-defined Guards. Available types are queried via `wowok_buildin_info` with `info: "value types"`.
-
----
-
-## 9. Incremental Object Building
-
-For complex objects with many fields (Service, Machine), use **incremental building** instead of creating everything in one call:
-
-- Each step can be verified before proceeding
-- Errors are isolated to specific fields
-- Easier to retry failed steps without re-executing successful ones
-- Better user feedback at each stage
-
----
-
-## Schema Reference
-
-**Related Skills**: [wowok-tools](../wowok-tools/SKILL.md) | [wowok-guard](../wowok-guard/SKILL.md) | [wowok-machine](../wowok-machine/SKILL.md) | [wowok-order](../wowok-order/SKILL.md) | [wowok-provider](../wowok-provider/SKILL.md) | [wowok-arbitrator](../wowok-arbitrator/SKILL.md) | [wowok-messenger](../wowok-messenger/SKILL.md)
-
----

package/wowok-scenario/SKILL.md

@@ -1,371 +0,0 @@
----
-name: wowok-scenario
-description: |
-  WoWok Industry Driving Modes — opinionated bundles of Permission, Machine,
-  Guard, and Allocator defaults per industry. Each mode is a "scene preset"
-  (like SUV driving modes: sand / road / water) that pre-fills best-practice
-  configuration so a new merchant can publish a working Service in 10 rounds.
-
-  Use when: user describes an industry ("I do freelance design", "I rent
-  cameras", "I run a course"), when wowok-onboard needs default parameters
-  for R3-R8, or when a merchant wants to switch from general configuration
-  to an industry-tuned preset.
-
-  Phase 1 covers freelance and rental modes in full detail. Education,
-  travel, and subscription modes are outlined for Phase 2/3.
-when_to_use:
-  - User mentions an industry (freelance, rental, education, travel, subscription)
-  - wowok-onboard R2 needs to load mode defaults
-  - User asks "what configuration works for my business"
-  - User wants to switch from general mode to an industry preset
-  - User wants to compose two modes (e.g., freelance + subscription)
----
-
-# WoWok Industry Driving Modes
-
-> **Related Skills**: [wowok-onboard](../wowok-onboard/SKILL.md) (uses mode defaults in R3-R8), [wowok-machine](../wowok-machine/SKILL.md) (Machine design authority), [wowok-guard](../wowok-guard/SKILL.md) (Guard design authority), [wowok-provider](../wowok-provider/SKILL.md) (Allocator operation), [wowok-safety](../wowok-safety/SKILL.md) (immutability rules)
-
----
-
-## Overview
-
-A **driving mode** is a curated bundle of: industry traits, default Permission indexes, default Machine node graph, default Guard templates, default Allocator strategy, a 10-round build script, an audit checklist, and a failure playbook. Modes are **presets, not constraints** — every underlying MCP operation remains available. Users can override any default or switch to `general` (free) mode at any time.
-
-### On-Chain Capacity Limits (Inline Reference)
-
-Mode defaults respect these on-chain constants. When a mode's suggested count exceeds a limit, the SDK will reject the operation.
-
-| Constant | Value | Scope |
-|----------|-------|-------|
-| `MAX_NODE_COUNT_SDK` | 100 | Max nodes per Machine (SDK limit; on-chain allows 200) |
-| `MAX_FORWARD_COUNT` | 20 | Max global forwards per Machine |
-| `MAX_FORWARD_ORDER_COUNT` | 20 | Max forwards per node pair |
-| `MAX_NODE_PAIR_COUNT` | 40 | Max pairs per node |
-| `USER_DEFINED_PERM_INDEX_START` | 1000 | Custom permission_index start (0-999 reserved for built-in) |
-| `MAX_PERM_FOR_ENTITY` | 1000 | Max permissions per Entity |
-| `MAX_ADMIN_COUNT` | 500 | Max admins per Permission object |
-| `MAX_AGENT_COUNT` | 10 | Max agents per Order |
-| `MAX_DISPUTE_COUNT` | 10 | Max concurrent disputes per Order |
-| `MAX_SHARING_COUNT` | 100 | Max sharing entries per allocator |
-| `MAX_VOTING_GUARD_COUNT` | 50 | Max voting guards per Arbitration |
-| `MAX_POLICY_COUNT` | 50 | Max policies per Repository |
-| `MAX_ID_COUNT_ONCE` | 100 | Max IDs per Repository operation |
-| `MAX_REWARD_COUNT` | 20 | Max rewards per Demand/Repository |
-| `MAX_CONTEXT_REPOSITORY_COUNT` | 30 | Max context repositories per Progress |
-| `MAX_NAMED_OPERATOR_COUNT` | 60 | Max named operators per Forward |
-| `MAX_NAMED_OPERATOR_ADDRESS_COUNT` | 80 | Max addresses per named operator |
-
-### What Driving Modes Solve
-
-The "object_type wall" — new users do not know which Machine topology, which Guards, which Allocator strategy fits their industry. Modes pre-answer these questions using best practices distilled from real usage (and refined by Loop Engineering over time).
-
-### Mode Catalog
-
-| Mode | Phase | Industry | Trust Pattern |
-|------|-------|----------|---------------|
-| `freelance` | 1 | Design / dev / consulting / writing | Milestone allocation, acceptance gate |
-| `rental` | 1 | Equipment / vehicle / property rental | Deposit escrow, return inspection |
-| `education` | 2 | Courses / training / tutoring | Periodic release per session, attendance Guard |
-| `travel` | 2 | Custom tours / multi-segment trips | Multi-tier allocation per segment |
-| `subscription` | 3 | SaaS / content membership / periodic service | Periodic charge, cancel Guard |
-| `general` | always | Anything not covered / hybrid | User-defined from scratch |
-
----
-
-## Mode Selection Logic
-
-The selection algorithm maps the user's business description to industry traits, then to a mode.
-
-### Trait Extraction
-
-Industry traits used for mode selection: `has_logistics` (physical goods to ship?), `communication_heavy` (lots of back-and-forth before delivery?), `pure_digital` (deliverable is a file/digital artifact?), `long_cycle` (multi-week or multi-month engagement?), `deposit_required` (collect refundable deposit?), `multi_tier_allocation` (pay multiple parties per segment?).
-
-### Selection Matrix
-
-| Trait Signature | Mode |
-|-----------------|------|
-| `pure_digital + communication_heavy + !deposit_required` | freelance |
-| `deposit_required + has_logistics + returnable` | rental |
-| `long_cycle + attendance + periodic_release` | education |
-| `multi_tier_allocation + segment_based + long_cycle` | travel |
-| `periodic_charge + cancel_anytime + pure_digital` | subscription |
-| none of the above / multiple conflicts | general |
-
-### Composition (Mode Stacking)
-
-Two modes can combine. Conflicts surface for user decision:
-
-| Combination | Use Case | Conflict Resolution |
-|-------------|----------|---------------------|
-| freelance + subscription | Retainer consulting (monthly + milestone) | Allocator: split into retainer (subscription) + milestone (freelance) |
-| rental + education | Equipment training rental | Machine: extend rental nodes with attendance gates |
-| travel + rental | Tour with equipment | Allocator: segment allocation + deposit escrow side-by-side |
-
-When two modes specify different Permission indexes for the same role, user decides which set to use.
-
----
-
-## Phase 1 Mode Details (Freelance & Rental)
-
-> **Mode defaults** (traits, machine_shape, guards, allocator, key_risk, build_notes) are provided by MCP `project_operation` action `create_project` — pass `project_industry` parameter and the MCP auto-fills scenario defaults from `knowledge/scenario-modes.ts`. The AI does NOT need to look up per-industry presets manually.
-
-### Quick Reference (mode summaries)
-
-| Mode | Machine Shape | Guards | Allocators | Key Risk |
-|------|---------------|--------|------------|----------|
-| `freelance` | 7 nodes (ordered→...→completed→{wonder\|no_wonder}) | 5 (buy/deliver/accept/withdraw/rating_window) | 2 (100% provider at completed / 0 at wonder-no_wonder) | Customer never accepts delivery |
-| `rental` | 10 nodes (reserved→...→completed→{wonder\|no_wonder}) | 5 (deposit/return/inspect/damage/rating_window) | 3 (rent at completed / refund-to-order via Allocator / damage deduct) | Owner claims damage without pre-rental WIP |
-
-> **Freelance entry-node forward (CRITICAL)**: the entry node (`prev_node: ""`, typically "Ordered") MUST have ≥1 forward (e.g. `{next_node:"Ordered", namedOperator:"", weight:1}`). Without it, Progress is permanently stuck at `current=""`. The 5-Guard default covers buy/deliver/accept/withdraw/rating_window; `penalty_guard` is OPTIONAL (add only if penalty deduction is needed — most freelance flows omit it).
-
-> **Dispute Independence**: `refunded`/`disputed`/`arb` MUST NOT appear as Machine nodes (R-M1-11 critical). Refunds flow through Allocator (100%→OrderHolder) or Arbitration (dispute → ruling → arb_withdraw), both off-Machine. Wonder/no_wonder are post-completion reputation terminals only.
-
-### Freelance Audit Checklist (pre-publish BLOCKERS)
-
-- `accept_guard` exists + `gen_passport` tested — BLOCKER (no acceptance = funds stuck)
-- 100% refund Allocator (sharing.who=OrderHolder) — BLOCKER (no refund path = dispute deadlock)
-- Machine MUST NOT contain `refunded`/`disputed`/`arb` nodes (R-M1-11 critical) — BLOCKER. Refund flows through Allocator or Arbitration, both off-Machine
-- `withdraw_guard` only triggers at `Progress.current=completed` — BLOCKER (prevents premature payout)
-- `deliver_guard` validates WIP hash — recommended
-- Optional: wonder/no_wonder terminals after `completed` for post-purchase rating (enables Reward wonder_praise template)
-
-### Freelance Failure Playbooks
-
-- Customer never accepts: `accept_guard` includes timeout auto-accept forward (threshold met by `namedOperator:""` after N days)
-- Wrong deliverable hash: `deliver_guard` enforces WIP match → re-generate WIP, re-submit via `progress.hold:false`
-- No arbiter assigned: bind Arbitration via `service.arbitrations` AND configure `Arbitration.voting_guard` (NOT Permission index 1500 — arbiters live in voting_guard, never in Permission)
-
-### Rental Audit Checklist (pre-publish BLOCKERS)
-
-- `deposit_guard` validates `Order.balance ≥ deposit_amount` — BLOCKER (renter runs off with item)
-- 100% refund Allocator (sharing.who=OrderHolder) — BLOCKER (no refund = deposit theft)
-- `damage_guard` requires pre+post WIP hash diff — BLOCKER (no evidence = arbitrary deduction)
-- Machine MUST NOT contain `deposit_refunded`/`deposit_deducted`/`refunded` nodes (R-M1-11 critical) — BLOCKER. Deposit refund/deduction flows through Allocator, not Machine terminals
-- Pre-rental WIP generated + hash stored — BLOCKER (can't prove damage without pre-hash)
-- Rental period timeout forward on `in_use` node — recommended
-
-### Rental Failure Playbooks
-
-- Renter never returns: timeout forward to `damage_confirmed`, `damage_deduct` Allocator fires (deduct deposit to host)
-- No pre-rental WIP: impossible post-publish — audit checklist blocks this at publish time
-- Owner refuses inspect: timeout forward auto-passes `inspect_guard`, `refund_guard` fires on `return_approved`, deposit returns to customer
-- Double-spend dispute: Machine topology ensures mutually exclusive forwards (first-Pair-wins), `escalate_arbiter` routes to Arbitration
-
-### Rental Mode Template (R-M1-11 Compliant)
-
-> **P3-03 fix**: The original Turo deployment used `deposit_refunded`/`deposit_deducted` as Machine nodes, which violates R-M1-11. This template replaces them with R-M1-11-compliant node names (`return_approved` / `damage_confirmed`). Deposit refund/deduction flows through Allocator triggered by these nodes, NOT through "refund terminal" nodes.
-
-#### Corrected 10-Node Machine Topology
-
-```
-reserved → paid_deposit → in_use → returned → inspected ─┬─→ return_approved → completed
-                                                            ├─→ damage_confirmed → completed
-                                                            └─→ arbiter_rule → completed
-
-completed → wonder | no_wonder (rating terminals, optional)
-```
-
-**Node inventory (10 nodes)**:
-
-| # | Node | Operator | Business meaning | Entry forward |
-|---|------|----------|------------------|---------------|
-| 1 | `reserved` | system | Renter selected item, pending payment | Order creation (auto) |
-| 2 | `paid_deposit` | customer | Paid rent + deposit | `pay_deposit_and_rent` (Customer, `namedOperator:""`) |
-| 3 | `in_use` | host | Item handed over, renter using | `pickup` (Host, `permissionIndex:1000`) |
-| 4 | `returned` | customer | Renter returned item | `trigger_return` (Customer, `namedOperator:""`) |
-| 5 | `inspected` | host | Host inspected condition | `inspect_item` (Host, `permissionIndex:1000`) |
-| 6 | `return_approved` | host | No damage — refund deposit | `approve_return` (Host, `permissionIndex:1000`) — **path 1** |
-| 7 | `damage_confirmed` | host | Damage confirmed — deduct deposit | `claim_damage` (Host, `permissionIndex:1000`) — **path 2** |
-| 8 | `arbiter_rule` | system | Escalated to arbitration | `escalate_arbiter` (Customer, `namedOperator:""`) — **path 3** |
-| 9 | `completed` | host | Trip finalized | `finalize` (Host, `permissionIndex:1000`) |
-| 10 | `wonder` / `no_wonder` | customer | Rating terminal (one of two) | `rate_good` / `rate_bad` (Customer, `namedOperator:""`) |
-
-**R-M1-11 compliance**: NO `deposit_refunded`, `deposit_deducted`, or `refunded` nodes. Deposit refund/deduction flows through Allocator triggered by `return_approved` / `damage_confirmed` nodes. `arbiter_rule` is allowed (it routes to Arbitration, not a refund terminal).
-
-#### 3 Mutually Exclusive Forwards from `inspected`
-
-| Forward | Next node | Operator | Trigger condition | Allocator fired |
-|---------|-----------|----------|-------------------|----------------|
-| `approve_return` | `return_approved` | Host (perm 1000) | No damage WIP diff | Allocator 1 (refund to customer) |
-| `claim_damage` | `damage_confirmed` | Host (perm 1000) | Damage WIP diff > 0 | Allocator 2 (deduct to host) |
-| `escalate_arbiter` | `arbiter_rule` | Customer (`namedOperator:""`) | Dispute | Arbitration (off-Machine) |
-
-Move contract guarantees first-Forward-wins: Progress can only advance from `inspected` to ONE of the three next nodes.
-
-#### 3 Allocator Templates (Amount mode recommended)
-
-> **Why Amount mode**: Rate mode requires sum == 10000 (hard constraint). Amount mode is clearer for fixed rent/deposit amounts. See [Allocation Mode Documentation](../../wiki/market/行业/租赁-Turo/06-Allocation模式说明-待审核.md) for details.
-
-**Allocator 0 — Rent payment (triggers on `completed`)**:
-```json
-{
-  "guard": "rent_completed_guard",
-  "sharing": [
-    { "who": { "Entity": { "name_or_address": "<host>" } }, "sharing": "750000000", "mode": "Amount" }
-  ]
-}
-```
-- Fires when `progress.current == "completed"` (via `rent_completed_guard`)
-- Pays 0.75 WOW rent to host
-
-**Allocator 1 — Deposit refund (triggers on `return_approved`)**:
-```json
-{
-  "guard": "refund_guard",
-  "sharing": [
-    { "who": { "GuardIdentifier": 0 }, "sharing": "250000000", "mode": "Amount" }
-  ]
-}
-```
-- Fires when `progress.current == "return_approved"` (via `refund_guard`)
-- Refunds 0.25 WOW deposit to customer (Order owner, via `GuardIdentifier:0`)
-
-**Allocator 2 — Damage deduction (triggers on `damage_confirmed`)**:
-```json
-{
-  "guard": "damage_guard",
-  "sharing": [
-    { "who": { "Entity": { "name_or_address": "<host>" } }, "sharing": "250000000", "mode": "Amount" }
-  ]
-}
-```
-- Fires when `progress.current == "damage_confirmed"` (via `damage_guard`)
-- Deducts 0.25 WOW deposit to host
-
-#### 5 Guard Templates
-
-| Guard | Type | Trigger condition | Purpose |
-|-------|------|-------------------|---------|
-| `deposit_guard` | Permission | `progress.current == "paid_deposit"` + signer is Customer | Verify customer paid rent + deposit |
-| `return_guard` | Permission | `progress.current == "returned"` + signer is Host | Verify item returned |
-| `inspect_guard` | Permission | `progress.current == "inspected"` + signer is Host | Verify inspection done |
-| `damage_guard` | WIP | Pre + post WIP hash diff > 0 | Verify damage evidence |
-| `rating_window_guard` | Permission | `progress.current == "completed"` + within N days | Rating window timer |
-
-#### Permission Index Design
-
-| Role | Permission Index | Operations |
-|------|------------------|------------|
-| Host | 1000 | pickup / inspect / approve_return / claim_damage / finalize |
-| Arbiter | 1500 | arbitration ruling (via `voting_guard`, NOT Permission index) |
-| Customer | (no index) | pay_deposit / trigger_return / escalate_arbiter (via `namedOperator:""`) |
-
-**Customer authorization**: uses `namedOperator: ""` (empty string = OrderHolder). Set automatically by `service::buy` when Order is created. No Permission index needed.
-
-#### Migration Guide (from R-M1-11 violating deployment)
-
-If you have an existing rental Machine with `deposit_refunded`/`deposit_deducted` nodes:
-
-1. **Clone the Machine** (nodes are immutable after publish)
-2. **Rename nodes**: `deposit_refunded` → `return_approved`; `deposit_deducted` → (remove, merge into `damage_confirmed`)
-3. **Rebind Allocators**: Allocator 1 trigger node `deposit_refunded` → `return_approved`; Allocator 2 trigger node `deposit_deducted` → `damage_confirmed`
-4. **Publish new Machine** and rebind to Service (requires Service to be in draft state; if already published, use `service.machine_rebind` with setting_lock_duration wait)
-
----
-
-## Education Mode (Phase 2 — Outline)
-
-**Traits**: communication_heavy, long_cycle, deposit_required (tuition pre-pay), not pure_digital.
-
-### Mode Outline
-
-- **Default Machine**: enroll → pay_tuition → session_1 → session_2 → ... → session_N → completed → {wonder | no_wonder}
-- **Default Guards**: `attendance_guard` (per session, student signs), `refund_guard` (institution approval OR arbiter)
-- **Default Allocator**: 1/N of tuition released per session attendance; unearned portion refundable on `refund_guard`
-- **Key trait**: `setting_locked_time` on Service prevents institution from changing rules mid-semester (regulatory compliance)
-- **GTM angle**: targets "tutoring institutions run away with prepaid tuition" pain point; policy-driven adoption
-
----
-
-## Travel Mode (Phase 2 — Outline)
-
-**Traits**: communication_heavy, long_cycle, deposit_required (deposit + final payment), multi_tier_allocation (agency → hotel → guide → driver).
-
-### Mode Outline
-
-- **Default Machine**: order → pay_deposit → pay_final → segment_D1 → segment_D2 → ... → return → completed → {wonder | no_wonder}
-- **Default Guards**: `segment_guard` (per-segment arrival WIP, e.g., hotel check-in), `refund_guard` (agency approval OR arbiter for trip interruption)
-- **Default Allocator**: multi-tier — deposit 20% to agency, final 80% to agency, then agency-side Allocation splits to hotel/guide/driver per segment
-- **Key trait**: multi-tier Allocation is WoWok's unique advantage over traditional travel platforms
-- **GTM angle**: targets "paid in full then service shrinks" pain point
-
-### Travel Mode Preset (Reference)
-
-> Concise preset for quick deployment. For full template, see Phase 2 expansion.
-
-**10-Node Machine Workflow**:
-```
-inquiry → booking → payment → confirmation → preparation → departure → in-progress → completion → review → refund
-```
-- `refund` is a routing node (Allocator-triggered), NOT a refund terminal — R-M1-11 compliant
-- Rating terminals (`wonder` / `no_wonder`) optional after `review`
-
-**4 Guards**:
-
-| Guard | Type | Trigger | Purpose |
-|-------|------|---------|---------|
-| `buy_guard` | Permission | Order creation | Validate customer eligibility + segment WIP |
-| `withdraw_guard` | Permission | `progress.current == "completion"` | Verify trip completed before host payout |
-| `refund_guard` | Permission | `progress.current == "refund"` | Verify trip interruption / agency approval |
-| `dispute_guard` | Permission | Arb escalation | Route to Arbitration (off-Machine) |
-
-**2 Allocators** (Rate mode, sum = 10000 each):
-
-| Allocator | Trigger Node | sharing[0] | sharing[1] |
-|-----------|--------------|------------|------------|
-| Withdraw | `completion` | Agency 80% (Entity) | Hotel/Guide/Driver 20% (Entity) |
-| Refund | `refund` | Customer 100% (GuardIdentifier:0 = Order owner) | — |
-
-**Required flags**: `require_compensation_fund = true` (protects customer prepayment if agency defaults)
-
----
-
-## Subscription Mode (Phase 3 — Outline)
-
-**Traits**: pure_digital, long_cycle, not deposit_required, not communication_heavy.
-
-### Mode Outline
-
-- **Default Machine**: subscribe → charge_period_1 → deliver_period_1 → charge_period_2 → ... → cancel / expire
-- **Default Guards**: `charge_guard` (user confirms each charge — no auto-renew trap), `cancel_guard` (user cancels anytime, takes effect next period), `deliver_guard` (creator WIP hash per period — prevents content abandonment)
-- **Default Allocator**: each charge → 100% to creator; unearned periods → refund to subscriber
-- **Key trait**: pure digital, native WoWok soil; directly attacks "auto-renew trap" and "platform takes 30%" pain points
-- **GTM angle**: independent creators (Indie Hackers, niche SaaS, paid newsletters)
-
----
-
-## Escape Hatch
-
-Any user can switch from a driving mode to `general` (free) mode at any time. This ditches all defaults and exposes raw MCP operations.
-
-### When to Use the Escape Hatch
-
-- User's business doesn't fit any Phase 1-3 mode
-- User wants a hybrid not supported by Mode Composition
-- Expert user wants full manual control
-- Industry-specific edge case (e.g., freelance with deposit requirement that's not rental)
-
-### How to Switch
-
-When user says "switch to general mode" or "configure manually": stop applying mode defaults to remaining rounds, surface the `IndustryModeSchema` shape as a blank template, let user provide Permission indexes/Machine nodes/Guards/Allocators manually. wowok-onboard R3-R8 still execute with empty defaults; wowok-machine / wowok-guard / wowok-provider become primary references.
-
-### Warning
-
-Switching to general mode mid-onboarding does NOT discard already-created objects. The Service draft, Permission, and Machine created under a previous mode remain on-chain. The user can:
-- Continue building on top of them (REUSE pattern)
-- Abandon them and start fresh (CREATE new objects)
-
-### Recommitting to a Mode
-
-User can switch back to a driving mode after using general mode:
-- wowok-onboard re-loads mode defaults for any unconfigured rounds
-- Already-configured objects are kept (REUSE); only missing pieces get mode defaults
-- Checkpoint is updated with the new mode
-
----
-
-## Tier Layering
-
-- **Novice**: Full driving mode — mode defaults fill all rounds, user only confirms
-- **Advanced**: Customize defaults — user overrides specific fields (e.g., Allocator split), audit checklist still runs
-- **Expert**: General mode — no defaults, raw MCP operations, wowok-machine/guard/provider become primary references