@wowok/agent-mcp 2.5.2 → 2.5.3

package/dist/index.js

@@ -16,9 +16,37 @@ if (process.env.WOWOK_TELEMETRY === "false" || process.env.WOWOK_TELEMETRY === "
 }
 const SERVER_DESCRIPTION = `WoWok MCP Server - Making It Easy for AI Agents to Communicate, Collaborate, Trade, and Trust.
 
+## CRITICAL: Unified Single-Tool Architecture
+
+This server exposes exactly ONE MCP tool: \`wowok\`. All 17 sub-tools are dispatched internally by the \`wowok\` handler.
+
+### Call Format
+\`\`\`
+wowok({ tool: "<sub-tool-name>", data: {<sub-tool parameters>} })
+\`\`\`
+
+Accepted aliases (deprecated): \`tool_name\`/\`name\` for \`tool\`, \`args\`/\`params\` for \`data\`. Inline params (e.g. \`{ tool: "schema_query", action: "list" }\`) are also auto-wrapped into \`data\`.
+
+### Schema-Gated Execution (Self-Correcting)
+If your parameters don't match the sub-tool's schema, the response includes:
+- \`result.status = "schema_mismatch"\`
+- \`result.errors\` = specific validation errors
+- \`schema.input\` = the correct JSON schema for the sub-tool
+- \`schema.tool\` = which sub-tool this schema belongs to
+
+Read the schema, fix your params, and retry. CACHE the schema in your context for future calls to the SAME sub-tool — you should only need to see each sub-tool's schema once per conversation. No separate \`schema_query\` call is needed for parameter correction.
+
+### Unified Response Envelope
+\`\`\`
+{
+  "result": { "status": "success|error|schema_mismatch", "data": <sub-tool output>, "errors": [...] },
+  "schema": null | { "input": <JSON schema>, "tool": "<sub-tool-name>" }
+}
+\`\`\`
+
 ## CRITICAL: Schema Discovery Rule
 
-When the current context does not contain a tool's input/output schema, or when you are uncertain whether the schema you have is complete and up-to-date, you MUST query it first before calling the tool. Use schema_query for operational tool schemas or wowok_buildin_info for protocol constants and reference data. Never guess schema parameters, query instruction IDs, or type codes — always retrieve them from the live server.
+When the current context does not contain a sub-tool's input/output schema, or when you are uncertain whether the schema you have is complete and up-to-date, you MUST query it first before calling the sub-tool. Use \`wowok({ tool: "schema_query", data: { action: "get", name: "<sub-tool>" } })` + "`" + ` for operational sub-tool schemas or \`wowok({ tool: "wowok_buildin_info", data: { info: "..." } })\` for protocol constants and reference data. Never guess schema parameters, query instruction IDs, or type codes — always retrieve them from the live server.
 
 ## Token System Overview
 
@@ -64,10 +92,12 @@ Token amounts are HIGHLY SENSITIVE. Always:
 - Double-check large amount transactions
 - Never assume decimal places - use explicit token unit
 
-## Tool Selection Guide
+## Sub-tool Selection Guide
 
-| User Intent | Correct Tool | Wrong Tool (Avoid) |
-|------------|--------------|-------------------|
+All sub-tools are called via \`wowok({ tool: "<sub-tool>", data: {...} })\`. The table below helps pick the correct \`tool\` value.
+
+| User Intent | Correct Sub-tool | Wrong Sub-tool (Avoid) |
+|------------|------------------|------------------------|
 | Create service listing | onchain_operations (service) | query_toolkit |
 | Send coins to address | onchain_operations (payment) | account_operation |
 | Check my balance | query_toolkit (account_balance) | onchain_operations |
@@ -99,9 +129,13 @@ Token amounts are HIGHLY SENSITIVE. Always:
 | Send encrypted file via messenger | messenger_operation (send_file) | wip_file |
 | Generate Witness Timestamped Sequence (WTS) | messenger_operation (generate_wts) | wip_file |
 | Query protocol constants | wowok_buildin_info | query_toolkit |
-| Query tool schemas | schema_query | wowok_buildin_info |
+| Query sub-tool schemas | schema_query | wowok_buildin_info |
+| Cross-chain bridge (WOW<->EVM) | bridge_operation | onchain_operations |
+| Project deployment workflow | project_operation | onchain_operations |
+| Runtime service toggles | config_operation | — |
+| Service trust/risk assessment | trust_score | query_toolkit |
 
-## Local vs On-chain Operations
+## Sub-tool Categories
 
 ### LOCAL ONLY (Never touch blockchain):
 - account_operation
@@ -112,6 +146,7 @@ Token amounts are HIGHLY SENSITIVE. Always:
 - onchain_operations
 - messenger_operation (some operations)
 - wip_file (sign operation)
+- bridge_operation
 
 ### QUERY (Read-only):
 - query_toolkit
@@ -120,6 +155,11 @@ Token amounts are HIGHLY SENSITIVE. Always:
 - schema_query
 - guard2file
 - machineNode2file
+
+### WORKFLOW (Project-level):
+- project_operation
+- config_operation
+- trust_score
 `;
 const server = new McpServer(createServerConfig(packageJson, SERVER_DESCRIPTION), createCapabilitiesConfig());
 export { OnchainOperationsSchema, WipOperationsSchema, WatchQueryOperationsSchema, AccountOperationSchema, LocalMarkOperationSchema, LocalInfoOperationSchema, ProtocolInfoQuerySchema, CallOutputSchema, MessengerOperationInputSchema, MessengerOperationOutputSchema, };

package/dist/knowledge/guard-design-patterns.js

@@ -93,7 +93,110 @@ export const GUARD_DESIGN_PATTERNS = [
         notes: [
             "Repository address declared as table constant",
             "Timestamp keys may need convert_number_address",
-            "quote_guard = Some(addr) always fails in verify phase (impack_list empty) — use quote_guard = None",
+            "quote_guard context: fails in gen_passport (impack_list empty), works in on-chain business operations (see R-X1-10)",
+        ],
+    },
+    {
+        id: "pattern.repository_quote_guard_subscription",
+        business_requirement: "Repository data access requires payment proof (subscription revenue model)",
+        data_source: "SubmittedObject",
+        host: "repository_write",
+        verifier_level: "level3_scene_combined",
+        logic_summary: "Repository policy sets quote_guard (is_depended: immutable + rep=true). " +
+            "When a Guard queries this Repository's data (query 1167), check_repository_quote_guard verifies " +
+            "the quote_guard is in impack_list. The quote_guard itself verifies a submitted Payment " +
+            "(payment.info.for matches Repository, payment.amount meets subscription price). " +
+            "User submits Payment via Passport → quote_guard verified → added to impack_list → query 1167 passes.",
+        key_queries: ["repository.data", "payment.info.for", "payment.amount"],
+        mitigated_risks: ["R-X1-10"],
+        applicable_industries: ["subscription", "travel", "rental", "education"],
+        notes: [
+            "VERIFIED: passport.rs#L545-612 (check_repository_quote_guard), passport.rs#L758-769 (trigger at query_id==1167)",
+            "Repository.owner_receive<T> accepts Payment as subscription revenue (repository.move#L714-717)",
+            "quote_guard must be is_depended: immutable=true, relies empty, rep=true (guard.move#L133-135)",
+            "VERIFIER-EVIDENCE DESIGN: user submits valid Payment, quote_guard verifies Payment fields — no affiliation needed",
+            "gen_passport context: quote_guard fails (impack_list empty) — only use for on-chain business operations",
+            "Business model: data provider publishes weather/market/oracle data to Repository, " +
+                "users pay subscription to access data in their Machine flows",
+        ],
+    },
+    {
+        id: "pattern.supply_chain_suborder_verification",
+        business_requirement: "Sub-service purchase requires ownership of main service order (supply chain milestone unlock)",
+        data_source: "SubmittedObject",
+        host: "service_buy_guard",
+        verifier_level: "level2_identity_set",
+        logic_summary: "Sub-service buy_guard verifies submitted main Order: " +
+            "logic_and[logic_equal[query(order.owner), context(Signer)], logic_equal[query(order.service), identifier[N](main_service_address)]]. " +
+            "User submits main Order via Passport (b_submission=true), buy_guard verifies ownership + service match.",
+        key_queries: ["order.owner", "order.service"],
+        mitigated_risks: ["R-C3-05"],
+        applicable_industries: ["travel", "rental", "education", "freelance"],
+        notes: [
+            "VERIFIER-EVIDENCE DESIGN: user submits main Order as evidence, buy_guard verifies order.owner==Signer AND order.service==main_service",
+            "Each milestone = one sub-order with its own Service + buy_guard referencing the main order",
+            "Main flow can branch to different sub-services based on Machine node progression",
+            "No parent_order field needed — relationship verified via buy_guard querying submitted Order fields",
+            "Enables supply chain composition: main service → multiple sub-services with conditional access",
+        ],
+    },
+    {
+        id: "pattern.payment_exception_compensation",
+        business_requirement: "Exception branch triggers compensation Payment (e.g., delivery delay > 30min auto-compensates customer)",
+        data_source: "SubmittedObject",
+        host: "machine_forward",
+        verifier_level: "level3_scene_combined",
+        logic_summary: "Exception forward guard verifies 4-dimensional anti-reuse binding: logic_and[" +
+            "logic_equal[query(payment.info.for), identifier[N](order_address)], " +
+            "logic_equal[query(payment.info.guard), identifier[N](this_guard_address)], " +
+            "logic_as_u256_ge[query(payment.amount), identifier[N](compensation_amount)], " +
+            "logic_as_u256_equal[query(payment.info.index), query(progress.history count)], " +
+            "logic_string_nocase_equal[query(payment.info.remark), query(progress.current)]]. " +
+            "Treasury withdraws to customer with PaymentInfo(for_object=order, for_guard=this, index=history_count_at_creation, remark=node_name). " +
+            "Customer submits Payment via Passport; guard verifies index matches current unique step (progress.history count, U64, monotonically increasing — unique even in cycles) AND remark matches current node name (progress.current, String — may repeat across cycles but bound to this step by index).",
+        key_queries: [
+            "payment.info.for",
+            "payment.info.guard",
+            "payment.info.index",
+            "payment.info.remark",
+            "payment.amount",
+            "progress.history count",
+            "progress.current",
+        ],
+        mitigated_risks: [],
+        applicable_industries: ["rental", "travel", "general", "freelance"],
+        notes: [
+            "VERIFIED: payment.move#L66-71 (PaymentInfo: for_object, for_guard, remark, index), payment.move#L82-86 (payment_info_with_guard)",
+            "VERIFIED: treasury.move#L249-264 (withdraw creates Payment via payment::new_singleton + from_object_set)",
+            "Payment is freeze_object (immutable, payment.move#L160) — cannot be modified after creation",
+            "VERIFIED INDEX QUERY: progress.history count (id 1273, U64) — guard-ins.ts#L1228-1237. From progress.move L440-441 (session_accomplish pushes a new History entry) + L475/L482 (parent_table_vec::length returns current session id). This count is the unique monotonically increasing step index — even in cycles, each entry has a different count.",
+            "VERIFIED NODE NAME QUERY: progress.current (id 1253, String) — guard-ins.ts#L1025-1032. Returns the current node name. A node CAN be entered multiple times in cycles, so node name alone is NOT unique — it MUST be paired with progress.history count for uniqueness.",
+            "DESIGN INTENT (USER): to validate index (U64 type), use progress.history count (unique, non-repeating); to validate node name (may repeat in cycles), store it in PaymentInfo.remark and do string comparison with progress.current.",
+            "ANTI-REUSE 4-DIMENSIONAL BINDING: for_object (Order) + for_guard (Guard) + index (unique step via progress.history count) + remark (node name via progress.current). Same Payment cannot be reused in other contexts — at least one field will mismatch.",
+            "VERIFIER-EVIDENCE DESIGN: customer submits Payment, guard verifies binding fields match current context",
+            "Enables user-friendly exception handling: delay → auto-compensation → friendly branch flow",
+            "No affiliation registration needed — guard only verifies submitted Payment's field accuracy",
+        ],
+    },
+    {
+        id: "pattern.verifier_evidence_philosophy",
+        business_requirement: "Guard design philosophy: verifier provides evidence, guard verifies logic + data accuracy (NOT data discovery)",
+        data_source: "SubmittedObject",
+        host: "gen_passport",
+        verifier_level: "none",
+        logic_summary: "Guard is a PURE VERIFICATION engine. Participants submit evidence (Payment, Order, Proof, etc.) " +
+            "via Passport submissions (b_submission=true). Guard verifies: (1) logic completeness, (2) data usage accuracy. " +
+            "Guard does NOT discover/fetch objects via affiliation. Affiliation is for object lifecycle bookkeeping, " +
+            "NOT for guard data discovery.",
+        key_queries: [],
+        mitigated_risks: ["R-C3-05", "R-C3-06"],
+        notes: [
+            "CORE PRINCIPLE: Guard only validates submitted evidence — it never fetches data on its own",
+            "For Payment verification: user submits valid Payment → guard checks for_object/for_guard/index match",
+            "For multi-order verification: verifier submits Order data → guard checks service/owner relationships",
+            "For Repository access: user submits Payment → quote_guard verifies → impack_list updated → data query passes",
+            "Type 3 (SubmittedObject) data source class embodies this philosophy — b_submission=true entries",
+            "This pattern is foundational for all guard designs — always prefer verifier-evidence over complex object discovery",
         ],
     },
     {

package/dist/knowledge/guard-ledger.js

@@ -215,9 +215,9 @@ export const GUARD_SCENES = [
         fail_result: "Passport generation fails; the user did not pass validation",
         submission_source: "Passport applicant (signer + credentials)",
         special_constraints: [
-            "impack_list is always empty during the verify phase (only filled after result_for_permission)",
-            "Therefore quote_guard (query 1167) always fails in the gen_passport flow (IMPACK_GUARD_NOT_FOUND)",
-            "Only Repository queries with quote_guard==None can pass in gen_passport",
+            "quote_guard is a RIGID verification requirement when querying Repository data (query 1167)",
+            "Two-phase: passport generation scans guard + prepares quote_guard, passport verification re-checks + verifies",
+            "If quote_guard==None: Repository data is freely queryable (no access control)",
             "Guard can be created standalone (not bound to a specific Host Object)",
             "Guard can be depended on by other Guards via rely (requires rep=true)",
             "The Passport generated by gen_passport can be used as submission data for subsequent operations",

package/dist/knowledge/guard-lint.js

@@ -132,12 +132,12 @@ function checkSemanticErrors(json) {
             if (hasQuoteGuard) {
                 diagnostics.push({
                     code: "LE-06",
-                    message: "gen_passport scene uses quote_guard (will always fail)",
-                    severity: "error",
+                    message: "repository.data query with quote_guard: rigid verification requirement — ensure Passport includes quote_guard verification with necessary submissions (e.g., Payment proof)",
+                    severity: "info",
                     source: "lint",
                     location: { path: "/root" },
                     fix: {
-                        description: "Remove quote_guard authentication, or switch to a query method that does not depend on impack_list",
+                        description: "Ensure the quote_guard is verified: user submits Payment via Passport, quote_guard verifies Payment fields, repository data query passes",
                         auto_fixable: false,
                     },
                 });

package/dist/knowledge/guard-risk.js

@@ -1461,7 +1461,7 @@ const RISK_RULES = [
     {
         id: "R-X1-10",
         data_source_class: "cross_type",
-        trigger: "Guard uses repository.data query (query 1167) and the Repository has quote_guard set",
+        trigger: "Guard uses repository.data query (query 1167) and the Repository has quote_guard set — rigid verification requirement",
         check: (ctx) => {
             const str = rootStr(ctx);
             if (!(str.includes("repository") && str.includes('"query"')))
@@ -1469,22 +1469,30 @@ const RISK_RULES = [
             return {
                 id: "R-X1-10",
                 data_source_class: "cross_type",
-                level: "medium",
+                level: "low",
                 category: "impack_risk",
-                title: "repository.data query's quote_guard is invalid in the verify phase (impack_list is empty)",
-                description: "Guard queries repository.data (query 1167). According to passport.move#L289 and passport.rs implementation, " +
-                    "the impack_list is always empty in the verify phase (only filled after result_for_permission).\n" +
-                    "Therefore in check_repository_quote_guard (inside query 1167), " +
-                    "if the Repository policy's quote_guard is Some(addr), " +
-                    "since addr is not in the empty list, it will always report IMPACK_GUARD_NOT_FOUND.\n" +
-                    "Only when quote_guard==None can query 1167 pass.\n" +
-                    "This means: querying Repository data with a quote_guard in the Guard will always fail.",
+                title: "repository.data quote_guard is a RIGID verification requirement (data subscription access control)",
+                description: "When a Guard queries repository.data (query 1167), if the Repository policy has quote_guard set (Some(addr)), " +
+                    "then the quote_guard MUST be verified. This is a RIGID requirement — not context-dependent.\n\n" +
+                    "TWO-PHASE VERIFICATION MECHANISM (VERIFIED: passport.rs#L756-769, passport.rs#L545-612):\n" +
+                    "  Phase 1 — Passport generation (scan guard): The system scans the Guard to identify that it queries repository data. " +
+                    "If the Repository has a quote_guard, the system prepares the quote_guard for verification (adds it to the required " +
+                    "verification set, populating impack_list).\n" +
+                    "  Phase 2 — Passport verification: The system re-checks (a) is the quote_guard prepared/in impack_list? " +
+                    "(b) rigidly verify the quote_guard (e.g., verify Payment proof for subscription).\n\n" +
+                    "SEMANTIC INTENT: Any Guard that uses a Repository's data MUST satisfy that Repository's quote_guard. " +
+                    "This is the intended access control mechanism for data subscription — e.g., accessing weather data " +
+                    "requires payment proof verified by the quote_guard.\n\n" +
+                    "DESIGN PHILOSOPHY: On-chain data is consumed by guard verifiers. The quote_guard gates Repository data access, " +
+                    "enabling subscription revenue models. The Guard only verifies logic + data accuracy (verifier-evidence design).",
                 affected_stakeholders: ["customer", "provider"],
-                scenario: "quote_guard invalidation: impack_list is empty in the verify phase, causing the 1167 query to always fail",
-                mitigation: "1) Confirm the queried Repository's quote_guard is None;" +
-                    "2) If quote authentication is needed, modify the verify loop in the Move layer to maintain impack_list;" +
-                    "3) Document this limitation clearly: Repositories with quote_guard cannot be queried in the Guard;" +
-                    "4) Consider using other data sources instead of Repository.data query",
+                scenario: "quote_guard rigid verification: any guard querying repository data must satisfy the repository's quote_guard (e.g., payment requirement)",
+                mitigation: "1) This is an INTENDED capability, not a limitation — quote_guard enables data subscription access control;\n" +
+                    "2) When designing a Guard that queries Repository data with quote_guard: ensure the Passport includes " +
+                    "the quote_guard verification with necessary submissions (e.g., Payment proof);\n" +
+                    "3) Pattern: Repository with quote_guard for data subscription — quote_guard verifies Payment (for_object, for_guard, index), " +
+                    "user submits Payment via Passport, quote_guard verified in both phases, repository data query passes;\n" +
+                    "4) If quote_guard==None: no access control — Repository data is freely queryable",
             };
         },
     },

package/dist/knowledge/guard-templates.js

@@ -426,7 +426,7 @@ export const GUARD_TEMPLATES = [
         applicable_industries: ["ecommerce", "education", "travel", "subscription"],
         relevant_risks: ["R-C1-03", "R-X1-01", "R-X1-10"],
         creation_notes: [
-            "Repository queries require quote_guard==None (otherwise impack_list is empty, causing IMPACK_GUARD_NOT_FOUND)",
+            "Repository with quote_guard: rigid verification — any guard querying this Repository's data MUST satisfy the quote_guard (see R-X1-10, pattern.repository_quote_guard_subscription)",
             "repository.data query returns U64 (record count), compared with identifier[1] (value 0)",
             "Reward guard is iterable; duplicate-claim protection requires rebuilding the Guard to update the Repository address",
         ],
@@ -561,13 +561,185 @@ export const GUARD_TEMPLATES = [
         relevant_risks: ["R-C1-01", "R-X1-10", "R-X1-13"],
         creation_notes: [
             "gen_passport is a standalone Guard; it does not bind a Host Object (host_object: Standalone)",
-            "impack_list is always empty during the verify phase; quote_guard queries will always fail",
+            "quote_guard is a rigid requirement: if the Guard queries Repository data with quote_guard set, the quote_guard must be verified (see R-X1-10)",
             "The Guard can be depended on by other Guards via rely (requires rep=true)",
             "The generated Passport can be used as submission data for subsequent operations",
         ],
         example_use_case: "After the user passes identity verification, a Passport is generated; this Passport is then submitted as an identity credential in subsequent service purchases.",
         verifier_constraint_level: "level1_strict",
     },
+    {
+        id: "tpl_repository_quote_guard_subscription",
+        scene_id: "repository_write",
+        name: "Repository data subscription with payment verification",
+        description: "Repository quote_guard requires payment proof for data access. When any Guard queries this Repository's data (query 1167), the quote_guard is rigidly verified. Enables data subscription revenue model (e.g., weather data, market oracle data).",
+        recommended_patterns: ["P03", "P07"],
+        parameters: [
+            { name: "repository_address", type: "address", description: "Repository object address", required: true },
+            { name: "subscription_price", type: "number", description: "Subscription payment amount required for data access", required: true },
+            { name: "payment_for_object", type: "address", description: "Payment for_object (Repository address)", required: true },
+        ],
+        example_table: [
+            { identifier: 0, b_submission: false, value_type: "Address", value: "${repository_address}", name: "Repository address" },
+            { identifier: 1, b_submission: false, value_type: "U256", value: "${subscription_price}", name: "Subscription price" },
+            { identifier: 2, b_submission: true, value_type: "Address", name: "Submitted Payment (for_object verification)" },
+            { identifier: 3, b_submission: true, value_type: "U256", name: "Submitted Payment amount" },
+        ],
+        example_root: {
+            type: "logic_and",
+            nodes: [
+                {
+                    type: "logic_equal",
+                    nodes: [
+                        { type: "query", query: "payment.info.for", object: { identifier: 2 } },
+                        { type: "identifier", identifier: 0 },
+                    ],
+                },
+                {
+                    type: "logic_as_u256_ge",
+                    nodes: [
+                        { type: "query", query: "payment.amount", object: { identifier: 2 } },
+                        { type: "identifier", identifier: 1 },
+                    ],
+                },
+            ],
+        },
+        applicable_industries: ["subscription", "travel", "rental", "education"],
+        relevant_risks: ["R-X1-10"],
+        creation_notes: [
+            "VERIFIER-EVIDENCE DESIGN: user submits valid Payment via Passport (b_submission=true), quote_guard verifies Payment fields",
+            "quote_guard must be is_depended: immutable=true, relies empty, rep=true (guard.move#L133-135)",
+            "Repository.owner_receive<T> accepts Payment as subscription revenue (repository.move#L714-717)",
+            "Rigid verification: any guard querying this Repository's data MUST satisfy the quote_guard",
+            "Two-phase: passport generation scans + prepares, passport verification re-checks + verifies",
+            "VERIFIED QUERY NAMES: payment.info.for (id 1107, Address), payment.amount (id 1100, U256)",
+        ],
+        example_use_case: "Weather data provider publishes daily temperature data to Repository. Insurance Machine queries weather data; user must pay subscription (Payment) to access data in their insurance claim flow.",
+        verifier_constraint_level: "level3_scene_combined",
+    },
+    {
+        id: "tpl_buy_guard_order_holder",
+        scene_id: "service_buy_guard",
+        name: "Supply chain sub-order purchase verification",
+        description: "Sub-service buy_guard verifies the user owns a main service order. Enables supply chain milestone unlock: each milestone = one sub-order, sub-service only purchasable by users who bought the main service.",
+        recommended_patterns: ["P03", "P04"],
+        parameters: [
+            { name: "main_service_address", type: "address", description: "Main Service object address", required: true },
+            { name: "main_order_address", type: "address", description: "Submitted main Order address (b_submission=true)", required: false,
+                constraint: "If using P16 circular reference, use service name instead of address" },
+        ],
+        example_table: [
+            { identifier: 0, b_submission: false, value_type: "Address", value: "${main_service_address}", name: "Main service address" },
+            { identifier: 1, b_submission: true, value_type: "Address", name: "Submitted main Order (ownership verification)" },
+        ],
+        example_root: {
+            type: "logic_and",
+            nodes: [
+                {
+                    type: "logic_equal",
+                    nodes: [
+                        { type: "query", query: "order.owner", object: { identifier: 1 } },
+                        { type: "context", context: "Signer" },
+                    ],
+                },
+                {
+                    type: "logic_equal",
+                    nodes: [
+                        { type: "query", query: "order.service", object: { identifier: 1 } },
+                        { type: "identifier", identifier: 0 },
+                    ],
+                },
+            ],
+        },
+        applicable_industries: ["travel", "rental", "education", "freelance"],
+        relevant_risks: ["R-C3-05"],
+        creation_notes: [
+            "VERIFIER-EVIDENCE DESIGN: user submits main Order as evidence (b_submission=true), buy_guard verifies ownership + service match",
+            "No parent_order field needed — relationship verified via buy_guard querying submitted Order fields",
+            "Each milestone = one sub-order with its own Service + buy_guard",
+            "Main flow can branch to different sub-services based on Machine node progression",
+            "VERIFIED QUERY NAMES: order.owner (id 1202, Address), order.service (id 1203, Address)",
+        ],
+        example_use_case: "Travel package: main service = tour booking. Sub-services = hotel, guide, transfer — each with buy_guard verifying the user purchased the main tour order.",
+        verifier_constraint_level: "level2_identity_set",
+    },
+    {
+        id: "tpl_payment_exception_compensation",
+        scene_id: "machine_forward_guard",
+        name: "Exception branch compensation Payment",
+        description: "Machine forward guard for exception handling: verifies a compensation Payment bound to specific order + guard + unique progress step (history count) + node name. Enables user-friendly exception branches (e.g., delivery delay > 30min triggers auto-compensation).",
+        recommended_patterns: ["P03", "P07", "P09"],
+        parameters: [
+            { name: "order_address", type: "address", description: "Order object address (Payment for_object target)", required: true },
+            { name: "this_guard_address", type: "address", description: "This guard's own address (Payment for_guard target)", required: true },
+            { name: "compensation_amount", type: "number", description: "Minimum compensation amount", required: true },
+            { name: "expected_node_name", type: "string", description: "Expected node name (stored in PaymentInfo.remark, compared with progress.current)", required: true },
+        ],
+        example_table: [
+            { identifier: 0, b_submission: false, value_type: "Address", value: "${order_address}", name: "Order address" },
+            { identifier: 1, b_submission: false, value_type: "Address", value: "${this_guard_address}", name: "This guard address" },
+            { identifier: 2, b_submission: false, value_type: "U256", value: "${compensation_amount}", name: "Compensation amount" },
+            { identifier: 3, b_submission: false, value_type: "String", value: "${expected_node_name}", name: "Expected node name (for remark comparison)" },
+            { identifier: 4, b_submission: true, value_type: "Address", name: "Submitted Payment (compensation proof)" },
+        ],
+        example_root: {
+            type: "logic_and",
+            nodes: [
+                {
+                    type: "logic_equal",
+                    nodes: [
+                        { type: "query", query: "payment.info.for", object: { identifier: 4 } },
+                        { type: "identifier", identifier: 0 },
+                    ],
+                },
+                {
+                    type: "logic_equal",
+                    nodes: [
+                        { type: "query", query: "payment.info.guard", object: { identifier: 4 } },
+                        { type: "identifier", identifier: 1 },
+                    ],
+                },
+                {
+                    type: "logic_as_u256_ge",
+                    nodes: [
+                        { type: "query", query: "payment.amount", object: { identifier: 4 } },
+                        { type: "identifier", identifier: 2 },
+                    ],
+                },
+                {
+                    type: "logic_as_u256_equal",
+                    nodes: [
+                        { type: "query", query: "payment.info.index", object: { identifier: 4 } },
+                        { type: "query", query: "progress.history count" },
+                    ],
+                },
+                {
+                    type: "logic_string_nocase_equal",
+                    nodes: [
+                        { type: "query", query: "payment.info.remark", object: { identifier: 4 } },
+                        { type: "query", query: "progress.current" },
+                    ],
+                },
+            ],
+        },
+        applicable_industries: ["rental", "travel", "ecommerce", "freelance"],
+        relevant_risks: [],
+        creation_notes: [
+            "VERIFIED: payment.move#L66-71 (PaymentInfo: for_object, for_guard, remark, index), payment.move#L82-86 (payment_info_with_guard)",
+            "VERIFIED: treasury.move#L249-264 (withdraw creates Payment via payment::new_singleton + from_object_set)",
+            "VERIFIED QUERY NAMES: payment.info.for (id 1107, Address), payment.info.guard (id 1109, Address), payment.info.index (id 1111, U64), payment.info.remark (id 1110, String), payment.amount (id 1100, U64; logic_as_u256_ge casts U64→U256 for comparison)",
+            "VERIFIED INDEX: progress.history count (id 1273, U64) = unique monotonically increasing step index (progress.move L440-441, L475, L482). Even in cycles, each entry has a different count.",
+            "VERIFIED NODE NAME: progress.current (id 1253, String) = current node name. A node can be entered multiple times in cycles, but the history count is unique each time.",
+            "DESIGN: payment.info.index stores the step index set by Treasury at creation time; progress.history count provides the current unique step. Comparing them ensures the Payment was created for THIS specific progress step.",
+            "DESIGN: payment.info.remark stores the node name; progress.current provides the current node name. Comparing them provides semantic verification of which node triggered the compensation.",
+            "ANTI-REUSE: 4-dimensional binding: for_object (Order) + for_guard (Guard) + index (unique step) + remark (node name). Same Payment cannot be reused in other contexts.",
+            "Payment is freeze_object (immutable) — cannot be modified after creation",
+            "VERIFIER-EVIDENCE DESIGN: customer submits Payment, guard verifies binding fields match current context",
+            "Treasury withdraws compensation with PaymentInfo(for_object=order, for_guard=this, index=history_count_at_creation, remark=node_name)",
+        ],
+        example_use_case: "Food delivery: if delivery delayed > 30min at node 'delayed' (history count=5), restaurant Treasury auto-compensates $5 to customer with PaymentInfo(for_object=order, for_guard=this, index=5, remark='delayed'). Customer submits Payment via Passport, guard verifies index matches current history count AND remark matches current node name.",
+        verifier_constraint_level: "level3_scene_combined",
+    },
 ];
 export function getTemplatesByScene(sceneId) {
     return GUARD_TEMPLATES.filter((t) => t.scene_id === sceneId);

package/dist/knowledge/guard-translation.js

@@ -448,9 +448,9 @@ export const SEMANTIC_TO_SCHEMA_RULES = [
             tree_structure: "logic_and(query(1167: repository.data, object: { identifier: 0 }, parameters: [...]), [data validation condition])",
         },
         constraints: [
-            "The quote_guard authentication of query 1167 always has empty impack_list during the verify phase",
-            "Repository queries with quote_guard fail with IMPACK_GUARD_NOT_FOUND in the gen_passport flow",
-            "Only passes when quote_guard==None",
+            "quote_guard is a RIGID verification requirement: any guard querying Repository data with quote_guard must satisfy it",
+            "Two-phase: passport generation scans/prepares quote_guard, passport verification re-checks + verifies (see R-X1-10)",
+            "If quote_guard==None: no access control — Repository data is freely queryable",
             "rep semantics: repository.data query does not depend on runtime submission, so rep=true",
         ],
         example: {

package/dist/knowledge/index.d.ts

@@ -208,6 +208,9 @@ export { BRIDGE_RISK_RULES, BRIDGE_RISK_VERSION, checkBridgeRisks, getBridgeRisk
 export { TOOLS_REFERENCE, getToolReference, searchToolReference, getToolSequence, type ToolReferenceEntry, };
 export { SCENARIO_MODES, SCENARIO_MODES_VERSION, MODE_COMPOSITIONS, matchScenarioMode, inferScenarioTraits, getScenarioMode, listScenarioModes, getShippedModes, getModeCompositions, type IndustryModeName, type ScenarioTraits, type ModeAllocatorStrategy, type ModeGuardRef, type ModeMachineNode, type ScenarioMode, type ModeComposition, };
 export { GUARD_DESIGN_PATTERNS, GUARD_DESIGN_PATTERNS_VERSION, VERIFIER_LEVEL_GUIDANCE, getGuardDesignPattern, searchGuardDesignPatterns, getPatternsByHost, getPatternsByIndustry, getPatternsByDataSourceClass, getVerifierLevelGuidance, suggestPatternForRequirement, type GuardDataSourceClass, type VerifierConstraintLevel, type GuardHostObject, type GuardDesignPattern, type VerifierLevelGuidance, };
+import { type OverrideConfig } from "./overrides-loader.js";
+export declare function getKnowledgeOverrides(): OverrideConfig;
+export declare function refreshKnowledgeOverrides(): OverrideConfig;
 export declare function getKnowledgeBase(): {
     version: {
         glossary: number;

package/dist/knowledge/index.js

@@ -208,6 +208,15 @@ export { BRIDGE_RISK_RULES, BRIDGE_RISK_VERSION, checkBridgeRisks, getBridgeRisk
 export { TOOLS_REFERENCE, getToolReference, searchToolReference, getToolSequence, };
 export { SCENARIO_MODES, SCENARIO_MODES_VERSION, MODE_COMPOSITIONS, matchScenarioMode, inferScenarioTraits, getScenarioMode, listScenarioModes, getShippedModes, getModeCompositions, };
 export { GUARD_DESIGN_PATTERNS, GUARD_DESIGN_PATTERNS_VERSION, VERIFIER_LEVEL_GUIDANCE, getGuardDesignPattern, searchGuardDesignPatterns, getPatternsByHost, getPatternsByIndustry, getPatternsByDataSourceClass, getVerifierLevelGuidance, suggestPatternForRequirement, };
+import { loadOverrides as loadOverridesFromDisk } from "./overrides-loader.js";
+let KNOWLEDGE_OVERRIDES = loadOverridesFromDisk();
+export function getKnowledgeOverrides() {
+    return KNOWLEDGE_OVERRIDES;
+}
+export function refreshKnowledgeOverrides() {
+    KNOWLEDGE_OVERRIDES = loadOverridesFromDisk(true);
+    return KNOWLEDGE_OVERRIDES;
+}
 export function getKnowledgeBase() {
     return {
         version: {

package/dist/knowledge/machine-context.d.ts

@@ -8,7 +8,7 @@ import { type ChecklistResult } from "./machine-confirm.js";
 import { type GuardScene } from "./guard-ledger.js";
 export declare const MACHINE_CONTEXT_VERSION = "1.0.0";
 export interface VerificationNote {
-    topic: "bReplace" | "um" | "consensus_repositories" | "namedOperator_assignment" | "cross_machine_dependency";
+    topic: "bReplace" | "um" | "consensus_repositories" | "namedOperator_assignment" | "cross_machine_dependency" | "first_node_semantics_service_bound";
     judgment: "YES" | "PARTIAL" | "NO";
     verified_semantic: string;
     code_reference: string;

package/dist/knowledge/machine-context.js

@@ -52,6 +52,23 @@ export const MACHINE_VERIFICATION_NOTES = [
         code_reference: "progress.move (progress::new, assert_published) + guard.move (convert_witness)",
         affected_modes: ["cross_machine", "pre_publish_check"],
     },
+    {
+        topic: "first_node_semantics_service_bound",
+        judgment: "YES",
+        verified_semantic: "For Service-bound Machines, the entry node (prev_node='' target) represents a " +
+            "POST-PAYMENT state, because Service.buy() performs quote + buy (payment) + " +
+            "order_allocation + order_progress ATOMICALLY in a single transaction. The Machine " +
+            "must NOT include separate 'Order', 'Pay', 'Reserve', or 'Subscribe' nodes — those " +
+            "actions are handled by the Service layer before the Progress (Machine instance) " +
+            "is created. All nodes after entry represent ORDER PROCESSING stages (fulfillment, " +
+            "delivery, confirmation, review, refund), NOT payment actions. Correct entry node " +
+            "examples: 'Paid', 'DepositPaid', 'Active'. Incorrect: 'OrderCreated', 'Reserved', " +
+            "'Subscribed'. See machine-ledger.ts first_node_semantics field per scene and " +
+            "machine-templates.ts example_nodes/example_pairs for the canonical structure.",
+        code_reference: "ts-sdk\\packages\\wowok\\src\\w\\call\\service.ts (buy: quote -> buy -> order_allocation -> order_progress) " +
+            "+ machine-ledger.ts (first_node_semantics field) + machine-templates.ts (example_nodes)",
+        affected_modes: ["initial_design", "mid_design_review", "pre_publish_check"],
+    },
 ];
 export function getMachineKnowledgeSnapshot() {
     const verifiedYes = MACHINE_VERIFICATION_NOTES.filter((n) => n.judgment === "YES").length;
@@ -632,7 +649,11 @@ function buildPromptHints(ctx) {
             hints.push("Start by confirming the matched scene and selecting a template.");
             if (ctx.matched_scene) {
                 hints.push(`Scene "${ctx.matched_scene.name}" recommends patterns: ${ctx.matched_scene.recommended_patterns.join(", ")}.`);
+                if (ctx.matched_scene.first_node_semantics) {
+                    hints.push(`First-node semantics: ${ctx.matched_scene.first_node_semantics}`);
+                }
             }
+            hints.push("⚠ First node convention: For Service-bound Machines, the entry node (prev_node='' target) MUST represent a POST-PAYMENT state (e.g. 'Paid', 'DepositPaid'). Do NOT add 'Order'/'Pay'/'Reserve'/'Subscribe' nodes — Service.buy() handles payment atomically before Progress is created.");
             if (ctx.suggested_templates.length > 0) {
                 hints.push(`Top template suggestion: ${ctx.suggested_templates[0].id} (${ctx.suggested_templates[0].name}).`);
             }

package/dist/knowledge/machine-ledger.d.ts

@@ -19,6 +19,7 @@ export interface MachineScene {
     guard_requirements: GuardRequirement[];
     allocation_integration: string;
     special_constraints: string[];
+    first_node_semantics: string;
     mutable_after_publish: boolean;
     m_rounds_focus: string[];
 }