@wowok/agent-mcp 3.3.2 → 3.3.3

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

@@ -318,20 +318,6 @@
       "dimension": "semantic",
       "trigger": "GuardIdentifier recipients combined with payment_info.for_object anchor state (Some = enforced, None = absent)",
       "cases": [
-        {
-          "when": { "all": [
-            { "field": "for_object_anchor_known", "op": "eq", "value": true },
-            { "field": "guard_identifier_recipient_present", "op": "eq", "value": true },
-            { "field": "for_object_anchor_set", "op": "eq", "value": true }
-          ] },
-          "level": "medium",
-          "title": "payment_info.for_object anchor is ENFORCED at allocation execution",
-          "description": "payment_info.for_object is set to ${for_object_anchor}. At allocation execution, every Recipient::GuardIdentifier submission must equal this address or the whole tx aborts with ERECIPIENT_NOT_FOR_OBJECT (15) — a wrong anchor or a guard whose passport submits a different address makes the allocation permanently fail (payment_info is immutable after create). Verify the anchor matches the intended recipient flow.",
-          "scenario": "Allocation created with a declared for_object binding and GuardIdentifier recipients",
-          "mitigation": "Before create: confirm for_object is the object the GuardIdentifier submissions will resolve to (the guard's passport must submit exactly this address for the recipient identifier). Entity/Signer sharing lines are unaffected by the anchor.",
-          "evidence": "for_object=${for_object_anchor}",
-          "stakeholders": ["owner", "recipient"]
-        },
         {
           "when": { "all": [
             { "field": "for_object_anchor_known", "op": "eq", "value": true },

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

@@ -4,7 +4,7 @@
     "kernel_fired": "Always true when the kernel analyzer reaches the emission site (the emission itself is the trigger)",
     "eoa": "The controller EOA address of the current finding",
     "only": "Identifier of the sole operator on the flagged Forward",
-    "r2_level": "high when the compensation fund is below the windowed order total; medium when merely below the 3x ceiling",
+    "r2_level": "high when the compensation fund is below the largest single windowed order amount; medium when merely below the 3x-per-largest-order ceiling",
     "r3_level": "medium when the EOA controls 5+ business-critical objects; low otherwise",
     "r7_slot_viability": "Aggregate reward claim-slot viability: viable when any entry is viable; blocked when every entry is provably bound; unverifiable otherwise",
     "r7_slot_audit": "Per-entry claim slot audit text (#index viability — reason)",
@@ -42,13 +42,13 @@
     {
       "rule_id": "R2",
       "dimension": "structural",
-      "trigger": "Compensation fund below the 3x ceiling of windowed order amounts",
+      "trigger": "Compensation fund below the 3x-per-order ceiling of the largest windowed order",
       "cases": [
         {
           "when": { "field": "kernel_fired", "op": "truthy" },
           "level": "fact:r2_level",
-          "title": "Payout exposure: compensation fund is below the 3x ceiling of windowed order amounts",
-          "description": "The statutory payout ceiling exceeds the funded balance; awarded indemnities can abort on-chain.",
+          "title": "Payout exposure: compensation fund cannot cover a maximum-multiple award on the largest windowed order",
+          "description": "A ruling at the statutory per-order cap exceeds the funded balance; the awarded indemnity claim aborts on-chain.",
           "exposure": {
             "loss_parties": [
               { "role": "buyer", "basis": "A favorable ruling pays from compensation_fund; when the fund is below the awarded indemnity the payout claim aborts on-chain and the buyer carries the uncovered portion — no other balance backs it." }

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

@@ -254,14 +254,14 @@
     {
       "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).",
+      "trigger": "An allocator {GuardIdentifier:N} leg names a slot the guard table never declares as a b_submission Address — allocation aborts before paying (N-K21, amz-7f3a2c91). A properly DECLARED slot is fine: on an order-anchored allocation the submission equals payment_info.for_object (the paying Order), which is the deliberate two-step refund shape (the CoinWrapper lands on the Order and order::owner_receive extracts it to order.owner).",
       "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.",
+          "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). The fix is to declare the slot, not to abandon the leg: a declared slot on an order-anchored allocation is payable and is how order refunds work.",
+          "mitigation": "Declare {identifier: N, b_submission: true, value_type: 'Address'} in the bound guard's table so the passport can carry the submitted address. For an order refund leg, identifier 0 carries the paying Order address; the guard should pin that submission to the context (order.owner or an agent may trigger) and the payout is extracted by order::owner_receive.",
           "stakeholders": ["merchant", "customer"]
         }
       ]
@@ -303,6 +303,36 @@
           "stakeholders": ["merchant", "customer"]
         }
       ]
+    },
+    {
+      "rule_id": "REPO-WRITE-ONCE-01",
+      "dimension": "composition",
+      "trigger": "A repository WRITE guard (bound via a repository policy write_guard ref) negates a 'repository.data has' probe in its root — the RETRACTED write-once idiom (bk15 K3b; ofn-mn-261012 F-02, mainnet A/B verified). The write guard is verified inside the same PTB as the write, BEFORE the row exists, so the negated probe evaluates against the pre-write state and always fails the write. The chain now has a native per-policy write-once (PolicyRule write_once, K3(a)): the WRITE PATH itself rejects overwriting an existing record — but it is declared on the policy, never expressible as a guard leg.",
+      "cases": [
+        {
+          "when": { "field": "first_repo_write_once_guard", "op": "present" },
+          "level": "high",
+          "title": "Repository write guard '${first_repo_write_once_guard}' carries an INEFFECTIVE write-once leg",
+          "description": "${repo_write_once_guard_count} write-bound guard(s) negate a 'repository.data has' probe. The leg can never do what it claims: at verification time the row does not exist yet (same-PTB pre-write evaluation), so the negation always aborts the write with E_VERIFY_FAILED — the evidence row it gates can never be written. Mainnet A/B: the identical guard minus the leg succeeded, and the author then overwrote their own review. A defence that cannot be enforced is worse than none.",
+          "mitigation": "Remove the negated has-leg from the write guard and declare write-once on the policy instead (policy write_once: true — the write path rejects overwriting an existing record with E_POLICY_WRITE_ONCE_CONFLICT). For order-bound rails use the task-binding slot (254) plus the order anchor instead; for one-write-per-guard-pool semantics use the ONCE slot (255, b_submission=true) — per guard-pool, not per order. Do NOT re-teach the negated probe: it is a guaranteed runtime abort on the write path.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "BUY-INFO-UNENFORCED-01",
+      "dimension": "composition",
+      "trigger": "A service declares customer_required but mounts no buy_guard (bk15 K11). The buy family on-chain never reads customer_required — the field alone enforces nothing at buy time. The chain has a buy-time enforcement primitive: buy_guard is evaluated inside the passport buy path, and non-passport buys reject outright when one is mounted.",
+      "cases": [
+        {
+          "when": { "field": "first_customer_required_unbacked", "op": "present" },
+          "level": "medium",
+          "title": "Service '${first_customer_required_unbacked}' declares customer_required with no buy_guard mounted",
+          "description": "${customer_required_unbacked_count} service(s) declare required customer information that nothing enforces at buy time: the on-chain buy entry points never read customer_required. Buyers who skip the info still complete the purchase, and fulfillment stalls later (post-buy collection, manual follow-up, or dispute).",
+          "mitigation": "Pick one deliberately: (a) mount a buy-spec guard (host service, key buy) whose submission legs carry the declared info, so the passport buy path enforces collection and non-passport buys reject; or (b) keep post-buy collection and disclose it honestly in the service description. Do not leave the declaration silently unenforced.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
     }
   ]
 }

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

@@ -45,7 +45,7 @@ export interface ArchetypeTemplate {
     affiliate_mode?: "none" | "commission";
     crowdfunding_mode?: "none" | "threshold" | "flexible";
 }
-export declare const BUILTIN_TEMPLATES_VERSION = 87;
+export declare const BUILTIN_TEMPLATES_VERSION = 102;
 export declare const BUILTIN_TEMPLATES: ArchetypeTemplate[];
 export declare const TEMPLATE_KEYWORDS: Record<string, string[]>;
 export declare const TEMPLATE_TAGS: Record<string, string[]>;