@wowok/skills 1.1.4 → 1.1.6

package/wowok-output/SKILL.md

@@ -137,6 +137,10 @@ When user asks about field meanings:
 | Skill | Purpose |
 |-------|---------|
 | [wowok-safety](../wowok-safety/SKILL.md) | Pre-operation safety checks |
+| [wowok-guard](../wowok-guard/SKILL.md) | Guard design & validation |
 | [wowok-tools](../wowok-tools/SKILL.md) | Tool selection patterns |
 | [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 |

package/wowok-provider/SKILL.md

@@ -21,435 +21,221 @@ when_to_use:
 
 # WoWok Service Provider Guide
 
-Build and operate commercial services on WoWok as a service provider.
-
-> **Role**: Service Provider (Merchant/Seller)  
-> **Prerequisites**: Understand CREATE vs MODIFY pattern — use `schema_query({ action: "get", name: "onchain_operations" })`  
-> **Customer Perspective**: See [wowok-order](../wowok-order/SKILL.md)  
-> **Arbitration**: See [wowok-arbitrator](../wowok-arbitrator/SKILL.md)  
-> **Machine Design**: See [wowok-machine](../wowok-machine/SKILL.md) for workflow details  
-> **Messenger**: See [wowok-messenger](../wowok-messenger/SKILL.md) for customer communication  
-> **Tools**: See [wowok-tools](../wowok-tools/SKILL.md)
-
----
-
-## Core Concepts
-
-### Dependency-First Construction
-
-Commercial services MUST be built in strict dependency order. An object cannot reference another that does not yet exist.
-
-**Build Sequence**:
-```
-Permission → Service (unpublished) → Machine (Nodes but unpublished) → Guards → Allocators → Reward/Arbitration → Publish Machine → Bind to Service → Publish Service
-```
-
-**Immutability Rules**:
-| Object | When Immutable | Impact |
-|--------|---------------|--------|
-| **Guard** | After creation | CREATE-only, cannot modify |
-| **Machine** | After `publish: true` | Nodes locked, workflow frozen |
-| **Service** | After `publish: true` | `machine` and `order_allocators` locked |
-
-### CREATE vs MODIFY Pattern
-
-The unified pattern across all operations:
-- **Object shape** (`{ name?, ... }`) = **CREATE** new object
-- **String value** (`"<name>"`) = **MODIFY** existing object
-
-**Schema Reference**: `schema_query({ action: "get", name: "onchain_operations" })`
-
-### Key Object Relationships
-
-```
-Service (merchant storefront)
-├── machine → Machine (workflow definition)
-├── order_allocators → Allocators (fund distribution rules)
-├── arbitrations → Arbitration[] (dispute resolution options)
-├── compensation_fund → Customer protection pool
-├── sales → SalesItem[] (products with WIP files)
-├── discount → Discount[] (coupons)
-├── rewards → Reward[] (order/user behavior incentives)
-└── um → Contact (customer service)
-
-Order (created per purchase)
-├── builder → Customer (order owner)
-├── progress → Progress (workflow state)
-└── allocation → Allocation (fund distribution engine)
-```
+> **Role**: Service Provider (Merchant/Seller)
+> **Related Skills**: [wowok-order](../wowok-order/SKILL.md) (customer), [wowok-machine](../wowok-machine/SKILL.md) (workflow), [wowok-guard](../wowok-guard/SKILL.md) (validation rules), [wowok-messenger](../wowok-messenger/SKILL.md) (communication), [wowok-safety](../wowok-safety/SKILL.md) (safety)
 
 ---
 
-## Phase 1: Service Design (Commercial Intent)
-
-Design your service offering before building. This phase defines what customers see and how orders flow.
-
-### 1.1 Product Promise (WIP Files)
-
-WIP (Witness Immutable Promise) files are **immutable product commitments** — your on-chain promise to customers.
-
-**Creating WIP Files**:
-
-**Tool**: `wip_file` with `type: "generate"` operation.
-
-**Schema Reference**: `schema_query({ action: "get", name: "wip_file" })`
+## ⚠️ PRE-FLIGHT: Required Items Checklist
 
-**Key Parameters**:
-- `options.markdown_text`: Product description in markdown format
-- `options.images`: Array of image sources for product visuals
-- `outputPath`: Output file path for generated WIP file
+**THIS SECTION IS MANDATORY.** Before ANY service creation or publication, the AI MUST collect explicit user confirmation for EVERY required item. **Do NOT skip, do NOT fabricate, do NOT proceed with missing items.**
 
-**Attaching to Service**:
+### The Golden Rule
 
-**Operation**: `onchain_operations` with `operation_type: "service"`.
-
-**Key Fields**:
-- `sales.op`: Operation type ("add", "set", "remove")
-- `sales.sales`: Array of sales items, each with:
-  - `name`: Product name
-  - `price`: Price in token units
-  - `stock`: Available quantity
-  - `wip`: URL to WIP file (your official site, GitHub, etc.)
-  - `wip_hash`: SHA256 hash of WIP file for verification (default: `""`, uses hash embedded in WIP file unless explicitly set for verification)
-
-**Why WIP Matters**:
-- **Immutable commitment**: Hashed and signed on-chain
-- **Arbitration evidence**: Disputes resolved against your WIP claims
-- **Customer trust**: Transparent specifications reduce uncertainty
-- **Legal protection**: Tamper-proof record of promises
-
-### 1.2 Service Workflow (Machine Design)
-
-Machine defines your **service process** — from order creation to completion. Design from a **commercial intent** perspective, not technical implementation.
-
-**Key Design Questions**:
-1. **Service stages**: What are the key milestones? (e.g., confirmed → processing → shipped → delivered)
-2. **Validation points**: Where do you need customer confirmation or external verification?
-3. **Branching paths**: What happens on success vs. failure? (e.g., on-time vs. late delivery)
-4. **Fund release triggers**: At which nodes and how to allocate order funds?
-
-**Integration with Allocators**:
-- Each terminal node should map to an allocator strategy
-- Guards determine which allocator executes
-- Design Machine and Allocators together for coherent fund flow
-
-> **Implementation**: See [wowok-machine](../wowok-machine/SKILL.md) for node definition syntax, Guard conditions, and Forward configurations.
-
-### 1.3 Fund Distribution Strategy (Allocators)
-
-Allocators define **who gets what** under different outcomes. Design these alongside your Machine workflow.
-
-**Allocator + Machine Integration**:
 ```
-"delivered" → "order_complete" (threshold: 1)
-└── Forward: "customer_signed" (weight: 1)
-└── Allocator: "completed" → 95% merchant, 5% platform
-
-"delivered" → "package_lost" (threshold: 2)
-├── Forward: "customer_reports_lost" (weight: 1)
-├── Forward: "merchant_confirms_lost" (weight: 1)
-└── Allocator: "package_lost" → 100% to order (buyer can withdraw)
+NEVER guess what the user sells, how their workflow operates, or how funds are distributed.
+These are BUSINESS decisions that ONLY the user can make.
 
-Note: Arbitration is an independent action that can be triggered at any time.
+User hasn't provided it → ASK.
+User provides incomplete info → ASK for clarification.
+User says "just make something up" → REFUSE and explain why each item matters.
 ```
 
-**Allocation Modes** (3 types, executed in order):
-1. **Amount**: Fixed allocation amount (U64) for each recipient
-2. **Rate**: Percentage in basis points (10000 = 100%, 500 = 5%)
-   - If no Surplus defined, sum of all Rates must equal 10000 (100%)
-3. **Surplus**: Receives remaining funds (maximum one per allocator)
+### Required Items
 
-**How Allocation Executes**:
-- When an allocator Guard returns `true`, funds are distributed immediately per that allocator's `sharing` rules. If multiple Guards may evaluate to `true`, query and compare their validation logic and `sharing` rules to determine the most favorable outcome for your interests.
+For each item, the user must provide one of: **"Reuse existing: `<name_or_id>`"** OR **"Create new: `<details>`"**
 
-**Query Guard Logic**: Use `query_toolkit` with `query_type: "onchain_objects"` to query Guard objects by ID or name. Retrieve detailed validation logic including required node conditions, evidence submissions, and permission checks.
+| # | Item | User Must Provide | Why Not Fabricate |
+|---|------|-------------------|--------------------|
+| **R1** | **Account** | Account name/address. Default `""` is fine. | Safe default exists |
+| **R2** | **Permission** | Existing Permission to reuse, OR name + type_parameter for new. **Reuse strongly recommended.** | Controls access to ALL your services |
+| **R3** | **Service** | Service name, type_parameter. What kind of service? | Your brand identity on-chain |
+| **R4** | **Machine** | Nodes, state transitions (pairs), forward paths. | IS your business process |
+| **R5** | **Guards** | For each Guard: validation logic, conditions. Reuse or define new. | Enforces your business rules |
+| **R6** | **Guard Bindings** | Which Guard validates which Machine forward? | Wrong binding = unauthorized access |
+| **R7** | **Allocators** | For each outcome: who gets what %/amount? (e.g. "success: 95% me, 5% platform") | IS your revenue model |
 
-**Schema Reference**: `schema_query({ action: "get", name: "onchain_operations_service" })` — look for `order_allocators` field
+**Conditionally Required:**
 
----
-
-## Phase 2: Trust Mechanisms (Customer Confidence)
-
-Configure mechanisms that assure customers they can trust your service.
-
-### 2.1 Compensation Fund (compensation_fund)
-
-A **dedicated pool** that pays customers if arbitration rules in their favor. Demonstrates your commitment to fair resolution.
-
-**Setting Up Compensation Fund**:
-
-**Operation**: `onchain_operations` with `operation_type: "service"`.
+| # | Item | Trigger | User Must Provide |
+|---|------|---------|-------------------|
+| **C1** | **Contact (um)** | If `customer_required` is set | Contact name/ID |
+| **C2** | **WIP Files** | Physical goods | Product description, images |
+| **C3** | **Sales Products** | Listing products | Name, price, stock, WIP per product |
 
-**Key Fields**:
-- `compensation_fund_add`: Add funds to compensation pool (BalanceType)
-- `setting_locked_time_add`: Lock duration in milliseconds (minimum 30 days = 2592000000ms)
+### Information Collection Protocol
 
-**Merchant Commitment (Constraint)**:
 ```
-Merchant withdrawal constraints from compensation_fund:
-1. Pause Service (stop accepting new orders)
-2. Wait compensation_lock_duration (≥30 days)
-3. Then can withdraw remaining funds via compensation_fund_receive
-
-This commitment ensures existing orders can still claim compensation during the lock period.
+STEP 0: Present checklist R1-R7 to user
+├── Each item: "Reuse or create new? Provide details."
+├── Track status: [pending] / [confirmed: reuse <id>] / [confirmed: create]
+├── If user indicates physical goods / customer_required → also confirm C1-C3
+└── ⛔ GATE: ALL R1-R7 must be [confirmed] before any on-chain action
+    └── NOT confirmed → STOP. Ask. Do NOT suggest creating service.
 ```
 
-**Customer-Facing Benefits**:
-- Display `compensation_fund` balance in service listing
-- Higher balance + longer lock = more confidence for high-value orders
-- Shows merchant has "skin in the game" for fair resolution
-- Customers can claim compensation via arbitration — see [wowok-order](../wowok-order/SKILL.md) for customer arbitration process
-
-### 2.2 Arbitration Configuration
-
-Configure which arbitration services can resolve disputes for your orders.
+### Anti-Fabrication Rules (HARD Constraints)
 
-**Operation**: `onchain_operations` with `operation_type: "service"`.
-
-**Key Fields**:
-- `arbitrations.op`: Operation type ("add", "set", "remove")
-- `arbitrations.list`: Array of Arbitration object IDs/names
-
-**Why Multiple Arbitrations**:
-- Customers evaluate on-chain data to choose the most trusted Arbitration from your approved list
-- Different arbitrations may specialize (e.g., product quality vs. service delivery)
+| Never... | Because... |
+|----------|------------|
+| Invent product names, prices, descriptions | You don't know what they sell |
+| Design workflow nodes without user input | You don't know their business process |
+| Decide fund splits | You don't know their revenue model |
+| Assume Guard logic | You don't know their security requirements |
+| Skip the checklist | Even if user seems to know what they want |
 
 ---
 
-## Phase 3: Build & Publish
-
-Execute the dependency-first build process.
-
-### 3.1 4-Phase Build Process
-
-```
-PHASE 1 — Foundation
-├── 1. Permission (CREATE)
-├── 2. Service (CREATE, unpublished) — define basic info
-└── 3. Machine (CREATE, unpublished) — define ALL nodes and transitions
-
-PHASE 2 — Trust Layer
-└── 4. Guards (CREATE) — schema_query({ action: "get", name: "onchain_operations_guard" }) — validate Reward claims, Allocator conditions, Machine node transitions, etc. Create all Guards needed for your workflow.
-
-PHASE 3 — Business Logic
-├── 5. Machine Node Guards (MODIFY Machine) — bind Guards to Machine node forwards for workflow validation at each operation
-├── 6. Allocators (MODIFY Service) — fund distribution rules
-├── 7. Rewards (CREATE/MODIFY Service) — optional incentive pools
-├── 8. Arbitrations (MODIFY Service) — dispute resolution options
-└── 9. Compensation Fund (MODIFY Service) — add funds
-
-PHASE 4 — Publication
-├── 10. Publish Machine — nodes become IMMUTABLE
-├── 11. Bind Machine to Service — MODIFY Service.machine
-└── 12. Publish Service — everything LOCKED
-```
-
-### 3.2 Pre-Build Discovery
-
-Query existing resources to avoid collisions:
-
-**Tools**:
-- `query_toolkit` with `query_type: "account_list"` — list account objects
-- `query_toolkit` with `query_type: "local_mark_list"` — list local marks
-- `query_toolkit` with `query_type: "onchain_objects"` — query specific objects
-
-### 3.3 Reuse Existing Templates
-
-Export from proven services instead of building from scratch:
-
-**Tools**:
-- `machineNode2file` — export Machine nodes to JSON file for editing
-- `guard2file` — export Guard rules to JSON file for editing
-
-**Schema References**:
-- `schema_query({ action: "get", name: "machineNode2file" })`
-- `schema_query({ action: "get", name: "guard2file" })`
+## Service Build Lifecycle
+
+Once R1-R7 confirmed, execute in strict order. All operations use R1 (Account) as `env.account`.
+
+```
+STEP 1: Foundation
+├── Permission — REUSE existing (strongly recommended)
+│     Tool: onchain_operations (permission) | Fields: name, type_parameter
+├── Service (unpublished) — CREATE new
+│     Tool: onchain_operations (service) | Fields: name, type_parameter, permission
+└── Machine (unpublished) — CREATE new or REUSE template
+      Tool: onchain_operations (machine) | Fields: nodes, pairs, forwards
+      Discovery: query_toolkit (account_list, local_mark_list, onchain_objects)
+      Template: machineNode2file (export existing for editing)
+
+STEP 2: Trust Layer
+└── Guards — CREATE new or REUSE existing
+      Tool: onchain_operations (guard) | Fields: logic, instructions
+      Template: guard2file (export existing for editing)
+      ⚠️ Design your Guard tables based on how the target object reads data:
+         - buy_guard → pass/fail only, no data extraction
+         - Allocator guard → pass/fail only
+         - Machine forward guard → if retained_submission is used, ensure b_submission:true entries match expected types
+         - Reward guard → pass/fail only
+      Full design reference: [wowok-guard](../wowok-guard/SKILL.md)
+
+STEP 3: Business Logic (MODIFY)
+├── Machine — bind Guards to forwards
+│     Tool: onchain_operations (machine)
+├── Service — set Allocators
+│     Tool: onchain_operations (service) | Fields: order_allocators
+├── Arbitrations (optional) — REUSE existing Arb services
+│     Tool: onchain_operations (service) | Fields: arbitrations.list
+├── Compensation Fund (optional): compensation_fund_add + setting_locked_time_add (min 30d)
+│     Tool: onchain_operations (service)
+└── Reward (optional) — incentive pools
+
+STEP 4: Publication
+├── Publish Machine → IMMUTABLE
+│     Tool: onchain_operations (machine) | publish: true
+├── Bind Machine to Service
+│     Tool: onchain_operations (service) | machine: "<machine_id>"
+└── Publish Service → machine/allocators LOCKED
+      Tool: onchain_operations (service) | publish: true
+
+      ⚠️ Pre-Publish Verification:
+      1. Re-check PRE-FLIGHT: all R1-R7 still confirmed?
+      2. guard2file export Guards → review
+      3. machineNode2file export Machine → review
+      4. Allocator splits match user's stated model?
+      5. Warn: publish = immutable. Proceed?
+
+STEP 5: Post-Publish (MODIFY Service — mutable after publish)
+├── description, location
+├── sales (products with WIP) — ⛔ user MUST provide: name, price, stock, WIP
+├── customer_required
+└── um — Contact (REUSE existing or CREATE new)
+      ⚠️ If customer_required is set → um MUST be set
+```
+
+### Object Reuse & Immutability
+
+| Object | Reuse Strategy | When Locked |
+|--------|---------------|-------------|
+| **Permission** | **Strongly recommended** — centralized control | Never |
+| Machine | Reuse via `machineNode2file` template | After publish |
+| Contact (um) | Reuse existing customer service Contact | Never |
+| Arbitration | Always reuse existing Arb services | — |
+| Guard | Reuse if logic matches | After creation |
+| Service | — | After publish: machine, order_allocators frozen |
 
 ---
 
-## Phase 4: Customer Attraction & Incentives
-
-Optional mechanisms to attract and retain customers.
-
-### 4.1 Discount Coupons
+## Key Concepts
 
-Issue promotional discounts to attract new customers or reward loyal ones (AI: query `schema_query` for `onchain_operations_service` to view `discount` field definitions).
-**Operation**: `onchain_operations` with `operation_type: "service"`.
+### Service Object Relationships
 
-### 4.2 Review & Reward Incentives
-
-Encourage post-order feedback and engagement.
-
-**Design Pattern — Review Incentive**:
-```
-Machine Workflow:
-"order_completed" → "like" (threshold: 1)
-└── Forward: "positive_feedback" (weight: 1)
-
-"order_completed" → "suggest" (threshold: 1)
-└── Forward: "negative_feedback" (weight: 1)
 ```
+Service (merchant storefront)
+├── machine → Machine (workflow)
+├── order_allocators → Fund distribution rules
+├── arbitrations → Dispute resolution (optional)
+├── compensation_fund → Customer protection (optional)
+├── sales → Products with WIP files
+├── rewards → Incentive pools (optional)
+└── um → Contact (customer service)
 
-**Creating Reward Pool**:
-
-**Operation**: `onchain_operations` with `operation_type: "reward"`.
-
-**Example Configuration**:
-
-Create 2 Guards that check if Progress reached "like" node, then bind to Reward with different amounts:
-
-```
-Guard 1: "reward_like_200k"
-└── Condition: progress.current_node == "like"
-
-Guard 2: "reward_suggest_100k"  
-└── Condition: progress.current_node == "suggest"
-
-Reward Configuration:
-├── Guard: "reward_like_200k"
-│   └── Amount: 200000
-│
-└── Guard: "reward_suggest_100k"
-    └── Amount: 100000
-```
-
-> **Note**: Reward is an optional advanced feature. See `schema_query({ action: "get", name: "onchain_operations_reward" })` for full configuration.
-
-### 4.3 Supply Chain Promises (Sub-Orders)
-
-Demonstrate quality by committing to purchase from trusted suppliers.
-
-**Use Case — Travel Service**:
-```
-Travel Service promises:
-"We only book 5-star hotels from trusted hotel groups"
-
-Machine Implementation:
-├── "Book Hotel" Node
-│   └── forward_to_order_create: {
-│       service: "trusted-hotel-group-service",
-│       // Creates sub-order on hotel service
-│   }
-│
-└── Guard: "hotel_booking_confirmed"
-    └── Validates sub-order created and confirmed
+Order (per purchase)
+├── builder → Customer
+├── progress → Workflow state
+└── allocation → Fund distribution engine
 ```
 
-**Benefits**:
-- **Transparency & Quality assurance**: Commits you to vetted suppliers
-- **Trust building**: "We use X brand" becomes verifiable on-chain
-
-**Prerequisites**:
-- Supplier Service must be published first
-- Your Machine references their Service ID
-
----
-
-## Phase 5: Order Fulfillment
-
-Handle active orders through workflow progression.
-
-### 5.1 Progress Operations
-
-Advance orders through your Machine workflow via the Progress object.
-
-**Key Principle**:
-| Object | Purpose | Operation Target |
-|--------|---------|------------------|
-| **Order** | Fund escrow, ownership | Read-only for workflow |
-| **Progress** | Workflow state, node execution | **Operate via this** |
-
-**Two-Phase Operation** (recommended):
+### Allocators + Machine Integration
 
-**Operation**: `onchain_operations` with `operation_type: "progress"`.
+Design together for coherent fund flow. **Allocation Modes** (execute in order):
+1. **Amount** — Fixed U64 per recipient
+2. **Rate** — Basis points (10000 = 100%)
+3. **Surplus** — Receives remainder (max 1)
 
-**Step 1: Lock permission** (Prevents race conditions):
-- `object`: Progress object ID (from Order.progress)
-- `operate.operation`: Target node operation (e.g., `{ Next: "shipped" }`)
-- `operate.hold`: `true` to lock permission
-
-**Step 2: Complete off-chain work, then submit**:
-- Same operation with `hold: false` to release lock and submit
-
-**Schema Reference**: `schema_query({ action: "get", name: "onchain_operations_progress" })`
-
-### 5.2 Voluntary Compensation
-
-Proactively compensate for service failures to maintain relationships.
-
-**Scenario — Late Delivery**:
-```
-Machine Design:
-├── "Shipping" Node
-│   ├── Forward: "On Time" (normal)
-│   └── Forward: "Late" (penalty trigger)
-│
-└── Guard "late_penalty"
-    ├── IF delivery_time > promised + grace_period
-    ├── THEN require Payment from merchant to Order
-    └── Validate: Payment ≥ configured_penalty
 ```
+Example: Delivery workflow
+"delivered" → "order_complete" (threshold: 1)
+└── Forward: "customer_signed"    → Allocator: 95% merchant, 5% platform
 
-**Payment Flow**:
-```
-Merchant or Participant Wallet
-    ├──→ Payment (penalty) ──→ Customer's Order
-    │                              └──→ Customer extracts via receive()
-    └──→ Guard validates before workflow continues
+"delivered" → "package_lost" (threshold: 2)
+├── Forward: "customer_reports_lost"
+├── Forward: "merchant_confirms_lost"
+└── Allocator: 100% to order (buyer withdraws)
 ```
 
-**Benefits**:
-- Retains customers through proactive accountability
-- Avoids escalation to arbitration
-- Differentiates your service with guarantees
-
-### 5.3 Customer Service
+### WIP Files (Witness Immutable Promise)
 
-Handle inquiries and issues via Messenger.
+Immutable product commitment for arbitration evidence.
 
-**Setup**:
 ```
-Service.um → Contact.object_id
-Contact.ims[] → Your customer service addresses
+Create:  wip_file → generate → markdown_text + images → outputPath
+Attach: onchain_operations (service) → sales.sales[{
+          name, price, stock, wip: "<URL>", wip_hash: "" (auto)
+        }]
 ```
 
-**Best Practices**:
-- Respond promptly to build trust
-- Document all agreements (generates WTS evidence)
-- Confirm understanding explicitly (ARK signature required for evidence)
-- Proactively communicate delays
+### Compensation Fund (Optional but Recommended)
 
-> **AI reminder**: When fulfilling an order, the AI should proactively check whether the Service's `customer_required` fields (phone, email, delivery address, etc.) have been provided by the customer. If any are missing, prompt the provider to request them from the customer via Messenger using `messenger_operation` with `send_message`.
-
-> **Full Guide**: See [wowok-messenger](../wowok-messenger/SKILL.md) for messaging, WTS generation, and evidence management.
+- Add: `compensation_fund_add` | Lock: `setting_locked_time_add` (min 30d = 2592000000ms)
+- **Withdraw**: Pause Service → Wait lock duration → `compensation_fund_receive`
 
 ---
 
-## Best Practices & Common Pitfalls
+## Order Fulfillment
 
-### Design Principles
+| Object | Purpose | Operation |
+|--------|---------|-----------|
+| Order | Fund escrow | Read-only |
+| **Progress** | Workflow state | **Operate this** — `hold: true` (lock) → work → `hold: false` (submit) |
 
-| Do | Don't |
-|----|-------|
-| Design Machine + Allocators together | Design workflow without considering fund flow |
-| Provide generous compensation_fund | Skip compensation fund for high-value services |
-| Use clear, verifiable Guard conditions | Create ambiguous validation logic |
-| Test on testnet first, then mainnet | Publish to mainnet without testing |
-| Document WIP thoroughly | Make vague product promises |
+**AI Reminder**: When fulfilling, check `customer_required` fields. Missing → prompt via Messenger.
 
 ---
 
 ## Quick Reference
 
-### Essential Schemas
-
-| Purpose | Schema Name |
-|---------|-------------|
-| Service operations | `onchain_operations_service` |
-| Machine operations | `onchain_operations_machine` |
-| Guard operations | `onchain_operations_guard` |
-| WIP file generation | `wip_file` |
-| Messenger operations | `messenger_operation` |
-| Query toolkit | `query_toolkit` |
-
-**Query Schema**: `schema_query({ action: "get", name: "<schema_name>" })`
+| Purpose | Schema |
+|---------|--------|
+| Service ops | `onchain_operations_service` |
+| Machine ops | `onchain_operations_machine` |
+| Guard ops | `onchain_operations_guard` |
+| Progress ops | `onchain_operations_progress` |
+| WIP generation | `wip_file` |
+| Messenger | `messenger_operation` |
+| Query | `query_toolkit` |
+
+**Export**: `machineNode2file`, `guard2file` | **Query Schema**: `schema_query({ action: "get", name: "<name>" })`