@wowok/agent-mcp 3.2.6 → 3.2.7

package/dist/knowledge/baselines/rules/plan.json

@@ -1,5 +1,5 @@
 {
-  "comment": "Plan-domain rules (L1 composition kernel). Facts are produced by composition/audit.ts planFacts() from a Plan AST. These six rules exist because each one names a verified mainnet failure class from wiki/test/10 (TRAILHAVEN): zero allocator rows passing silently, prose guard logic, dual-rail double-pay, path-dependent settlement windows, write-only enforcement, dropped guard/repository hosts.",
+  "comment": "Plan-domain rules (L1 composition kernel). Facts are produced by composition/audit.ts planFacts() from a Plan AST. Each rule names a verified failure class (TRAILHAVEN wiki/test/10, booking-85981 + amz-7f3a2c91 audits): zero allocator rows passing silently, prose guard logic, dual-rail double-pay, path-dependent settlement windows, write-only enforcement, dropped guard/repository hosts, missing task-binding slot declarations and GuardIdentifier slot mismatches that strand escrow permanently.",
   "facts": {
     "has_service": "Plan creates a service object",
     "has_machine": "Plan creates a machine object",
@@ -15,9 +15,19 @@
     "first_write_only_unenforced_field": "First write-only param set with no guard query covering it (WRITE-ONLY-01, A-1/A-10)",
     "first_orphan_guard": "First guard step id never referenced by any host binding (HOST-GRAPH-01, B-2)",
     "first_repo_query_without_repository": "First guard step id querying repository.* while the plan creates no repository (HOST-GRAPH-01, B-2)",
+    "first_edge_guard_missing_254": "First guard step id bound on a machine forward whose table declares no {identifier: 254, b_submission: true} row (TASKBIND-01, N-K20: progress::assert_task_binding aborts code 11)",
+    "first_alloc_slot_missing": "First allocator {GuardIdentifier:N} leg whose bound guard table lacks slot N as a declared Address submission row (TASKBIND-02, N-K21: alloc abort with funds stranded)",
     "pending_allocator_guard_count": "Unresolved guard designs bound to allocator rows (compile-time judgment surface; >0 downgrades FUND-EXIT-01 from critical to medium)",
     "first_pending_fund_guard": "First unresolved guard design bound to an allocator row or machine edge (UNRESOLVED-GUARD-01) — publishing now ships that path UNGUARDED",
-    "first_pending_buy_guard": "First unresolved guard design bound to the service buy path (UNRESOLVED-GUARD-01 warning tier)"
+    "first_pending_buy_guard": "First unresolved guard design bound to the service buy path (UNRESOLVED-GUARD-01 warning tier)",
+    "has_return_rail": "The machine declares a return rail node (name matches /return/i) — the structural refund promise (PROMISE-ARB, L-01')",
+    "return_rail_node": "First return-rail node name",
+    "has_arbitration_binding": "The plan wires an arbitration venue into the Service (configure method 'arbitrations' with a non-empty object list, or the service create carries non-empty arbitrations)",
+    "fund_topup_present": "The plan carries a compensation_fund_add step",
+    "fund_topup_amount": "Sum of parseable (integer smallest-unit) top-up balances; absent when unparseable",
+    "fund_ceiling_breach": "The top-up is below the award ceiling (MAX_INDEMNITY_MULTIPLE x highest SKU price) — judged ONLY when both sides parse (PLAN-K2)",
+    "fund_ceiling_basis": "Human-readable basis used for the ceiling judgment",
+    "fund_ceiling_unverifiable": "A fund top-up exists but the ceiling could not be judged here (price or amount unparseable) — the publish-patch KL-K2 rule re-checks at the 3x largest-order basis (PLAN-K2 fallback, stated explicitly)"
   },
   "rules": [
     {
@@ -81,6 +91,44 @@
         }
       ]
     },
+    {
+      "rule_id": "PROMISE-ARB",
+      "dimension": "fund_flow",
+      "trigger": "The machine declares a return rail — that IS the refund promise — but the plan binds no Arbitration into the Service. After settlement the in-escrow refund track is dead topology, so the only on-chain remedy for a post-settlement return is an independent Arbitration ruling paid from the compensation fund (etsy-ln L-01: a live shop promised returns with no venue bound).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "has_return_rail", "op": "truthy" }, { "field": "has_arbitration_binding", "op": "falsy" } ] },
+          "level": "critical",
+          "title": "Return-promising shop wires no Arbitration venue",
+          "description": "The machine's return rail ('${return_rail_node}') is a promise the chain cannot keep alone: once the settlement allocator drains the escrow, a post-settlement return can only be paid by an independent Arbitration ruling against the compensation fund. This plan binds no venue, so the promise is DECLARED but UNENFORCEABLE — the declared-but-not-enforced class. Blocking: the machine and guard freeze at publish; do not hand-build the wiring outside the plan (hand-built replicas silently drop the arbitration/fund steps).",
+          "mitigation": "Keep the arbitration create + service arbitration-binding steps in the plan (standard emission for arbitration_mode third_party). A shop that deliberately settles every dispute off-chain must remove the return rail instead of the venue — an unbacked promise is the one configuration the protocol cannot repair post-publish.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "PLAN-K2",
+      "dimension": "fund_flow",
+      "trigger": "Publish-front compensation-fund adequacy (KL-K2 family): an award is hard-capped at 3x the order amount at ruling time, so a fund below the ceiling turns a WON award into an unpayable one (the claim aborts and is NOT consumed). Preferred basis: 3x the highest SKU price on the plan's catalog; when no price is parseable the judgment is explicitly deferred to the publish-patch check (3x largest single order) instead of silently skipped.",
+      "cases": [
+        {
+          "when": { "field": "fund_ceiling_breach", "op": "truthy" },
+          "level": "critical",
+          "title": "Compensation fund tops up below the award ceiling (${fund_ceiling_basis})",
+          "description": "The plan tops the fund up to ${fund_topup_amount} (smallest units), but a ruling at the ceiling would abort the buyer's claim (E_COMPENSATION_NOT_MATCH) and the abort does NOT consume the claim — the buyer holds an unpayable win until a manual top-up, and the shop holds the reputational damage.",
+          "mitigation": "Raise the compensation_fund input to at least the ceiling (${fund_ceiling_basis}). Above the ceiling is optional (tolerance for CONCURRENT claims against the one per-Service pool); below it, a valid ruling cannot pay.",
+          "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "field": "fund_ceiling_unverifiable", "op": "truthy" },
+          "level": "medium",
+          "title": "Compensation-fund adequacy cannot be judged from the plan",
+          "description": "The plan carries a fund top-up, but the catalog price or the top-up amount is not machine-parseable here (display forms need token decimals the plan layer does not have), so the ceiling check is DEFERRED, not skipped: the publish patch re-runs it on the 3x largest-single-order basis and blocks publish when under.",
+          "mitigation": "Provide numeric smallest-unit sales prices and a numeric fund amount so the plan layer can verify the ceiling before materialization; otherwise expect the publish-patch check to judge it.",
+          "stakeholders": ["merchant"]
+        }
+      ]
+    },
     {
       "rule_id": "DUAL-RAIL-01",
       "dimension": "fund_flow",
@@ -134,6 +182,36 @@
         }
       ]
     },
+    {
+      "rule_id": "TASKBIND-01",
+      "dimension": "fund_flow",
+      "trigger": "A guard bound on a machine forward declares no {identifier: 254, b_submission: true} row — progress::assert_task_binding aborts code 11 on every guarded forward of an order-driven Progress, and Guard tables are frozen at creation (N-K20, booking-85981 + amz-7f3a2c91).",
+      "cases": [
+        {
+          "when": { "field": "first_edge_guard_missing_254", "op": "present" },
+          "level": "critical",
+          "title": "Forward guard '${first_edge_guard_missing_254}' lacks the protocol task-binding slot (254)",
+          "description": "Every guarded forward of a machine running on an order Progress requires the passport to carry a slot-254 (task binding) submission; the guard table declares none, so the forward aborts with code 11 on first traversal. Guard tables and machines freeze at publish — shipping now strands the path permanently, and no builder can patch the table afterwards.",
+          "mitigation": "Declare {identifier: 254, b_submission: true, value_type: 'Address'} in guard '${first_edge_guard_missing_254}' (protocol slot 254; the order address is written by order creation). The compile kernel auto-injects this row when the guard is edge-bound — a finding here means the guard is bound in a way the kernel could not see.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "TASKBIND-02",
+      "dimension": "fund_flow",
+      "trigger": "An allocator {GuardIdentifier:N} leg names a slot the guard table never declares as a b_submission Address — allocation asserts the passport submission == payment_info.for_object and aborts (code 15) with funds already escrowed (N-K21, amz-7f3a2c91: 0.98991 WOW stranded).",
+      "cases": [
+        {
+          "when": { "field": "first_alloc_slot_missing", "op": "present" },
+          "level": "critical",
+          "title": "Allocator leg ${first_alloc_slot_missing} is undeclared",
+          "description": "The allocator row pays a recipient keyed by this guard slot, but the guard table has no b_submission Address declaration for it. At allocation time the passport lacks the slot, the assert fails, and the distribution aborts — escrowed funds stay stranded because the guard froze at publish and cannot gain the declaration later. A static Address slot in the same position passes the declaration window but fails the same assertion (N-11).",
+          "mitigation": "Declare slot N in the guard table as {identifier: N, b_submission: true, value_type: 'Address', object_type: 'Order'} so the passing order address is captured; the allocator then pays against payment_info.for_object.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
     {
       "rule_id": "HOST-GRAPH-01",
       "dimension": "composition",

package/dist/knowledge/builtin-templates.d.ts

@@ -1,5 +1,6 @@
 import type { Industry } from "../customer/index.js";
 import type { ModeMachineNode, ModeGuardRef, ModeAllocatorStrategy } from "./scenario-modes.js";
+export type TemplateArbitrationMode = "none" | "merchant_pick" | "mutual_pick" | "third_party";
 export interface ArchetypeTemplate {
     id: string;
     industry: Industry;
@@ -19,11 +20,25 @@ export interface ArchetypeTemplate {
     user_inputs: string[];
     key_risk: string;
     build_notes: string[];
+    evidence_refs?: string[];
     payment_model?: "milestone" | "subscription" | "escrow";
-    arbitration_mode?: "none" | "merchant_pick" | "mutual_pick" | "third_party";
+    arbitration_mode?: TemplateArbitrationMode;
     time_anchors?: Record<string, string>;
+    conditional_guards?: Array<{
+        guard_key: string;
+        param: string;
+        values: string[];
+        emit_value: string;
+        question: string;
+    }>;
+    reward_claim_policy?: {
+        kind: "once" | "periodic" | "capped";
+        min_claim_interval_ms?: number;
+        max_total_per_recipient?: string;
+    };
+    review_mode?: "none" | "review" | "review_reward";
 }
-export declare const BUILTIN_TEMPLATES_VERSION = 38;
+export declare const BUILTIN_TEMPLATES_VERSION = 51;
 export declare const BUILTIN_TEMPLATES: ArchetypeTemplate[];
 export declare const TEMPLATE_KEYWORDS: Record<string, string[]>;
 export declare function getBuiltinTemplate(id: string): ArchetypeTemplate | undefined;