@wowok/agent-mcp 3.2.4 → 3.2.7

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

@@ -448,6 +448,87 @@
           }
         }
       ]
+    },
+    {
+      "rule_id": "AC5",
+      "dimension": "integrity",
+      "trigger": "Freshly-registered accounts casting registrar votes in a burst (voter-side, V-PROF)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "fact:ac_signal_level",
+          "title": "Vote-noise suspicion: freshly-registered accounts are casting votes in a burst",
+          "description": "New accounts voting in volume read as an organized reputation push, not organic discovery.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "system", "basis": "Account-level vote aggregates absorb coordinated pushes, distorting the discovery signals every participant ranks on." },
+              { "role": "buyer", "basis": "Buyers reading like/favor counts as social proof are shown a manufactured signal." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "A burst of fresh-account votes inflates the account-level reputation of the targets the push favors.",
+                "viability": "viable",
+                "gate": "Registrar votes cost only gas and carry no order binding — the gate is detection and de-weighting, not the chain."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "AC6",
+      "dimension": "integrity",
+      "trigger": "Mutual votes between address pairs (voter-side, V-PROF)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "fact:ac_signal_level",
+          "title": "Vote-ring suspicion: mutual votes between address pairs",
+          "description": "Symmetric voting pairs are the cheapest way to manufacture mutual account-level reputation.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "system", "basis": "Ring votes correlate accounts that read as independent reputations, polluting pairwise trust statistics." },
+              { "role": "buyer", "basis": "Rings inflate the accounts buyers compare against, skewing discovery." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Each ring member gains a like-backed reputation at pure gas cost — the reciprocity is the whole scheme.",
+                "viability": "viable",
+                "gate": "No on-chain primitive binds a vote to an order; only correlation analysis reveals the ring."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "AC7",
+      "dimension": "integrity",
+      "trigger": "One target's votes dominated by low-credibility accounts (voter-side, V-PROF)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "fact:ac_signal_level",
+          "title": "Vote-noise suspicion: an address's votes are dominated by low-credibility accounts",
+          "description": "The account-level aggregate may be noise rather than signal; rank by the order-backed layer instead.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "system", "basis": "A flooded vote ring makes the target's account-level reputation meaningless as a ranking input." },
+              { "role": "buyer", "basis": "Buyers trusting the flooded account's like count are misled at decision time." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Flooding a target (a competitor or one's own account) with fresh/zero-history votes rewrites its social proof at gas cost.",
+                "viability": "viable",
+                "gate": "The vote ring has no order gate — the flood is undetectable on-chain, only by voter-credibility re-projection."
+              }
+            ]
+          }
+        }
+      ]
     }
   ]
 }

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

@@ -52,7 +52,7 @@
     "rc3_03_no_type_count": "KERNEL — submitted Address entries missing the object_type annotation.",
     "rc3_03_evidence": "KERNEL — final evidence listing the missing-object_type or annotated entries.",
     "rc3_05_applies": "KERNEL — a project-relevant object (Order/Progress/Arb) is submitted in an affected scene without a project-binding query (1563/1560/1250/1402/1401) in the root.",
-    "rc3_05_critical": "KERNEL — the scene belongs to the critical set (machine_forward_guard / service_order_allocators_guard).",
+    "rc3_05_critical": "KERNEL — the scene belongs to the critical set. Since protocol v148 (assert_task_binding live) the set is machine_forward_guard only: the forward-stage replay past acceptance gates is not closed by the chain, while allocator scenes carry the v148 chain backstop and grade info.",
     "rc3_05_unbound_csv": "KERNEL — unbound project-relevant submission entries rendered '#id(Order|Progress|Arb|inferred …)', comma joined.",
     "rc3_05_scene_label": "KERNEL — scene label for the evidence ('unknown scene (conservative flag)' when absent).",
     "rc3_06_applies": "KERNEL — allocators scene, Guard without Signer binding, and sharing is not provably Entity/GuardIdentifier-only.",
@@ -112,7 +112,7 @@
           "title": "arb.status==5 gate is transient: fee withdrawal permanently kills the refund edge",
           "description": "arb.status is a U8 lifecycle state. After a ruling the case sits at 5 (Finished), but a legitimate arb_withdraw by the arbitrator advances it to 6 (Withdrawn) — the gate silently flips false and never returns. Guard AND Machine are immutable after publish (IMMUT-001), so any forward gated on ==5 dies permanently and strands its funds (verified on testnet, booking o10: 1.5 WOW locked with no on-chain exit).",
           "scenario": "Arbitration refund forward gated on arb.status==5: the arbitrator withdraws the case fee before the refund executes — the forward aborts forever",
-          "mitigation": "Gate on the withdraw-stable ruling signal instead: arb.indemnity some == true (Bool — set by the ruling, never cleared by arb_withdraw; cleared by reset, which correctly re-gates). Template: tpl_forward_arb_ruling_won. Time-bounded variant: arb.indemnity.time (U64 ruling timestamp).",
+          "mitigation": "Gate on the stable ruling signal instead: arb.indemnity some == true (Bool — set by the ruling; arb_withdraw sweeps only the fee balance and never touches it, so a fee withdrawal cannot clear it; cleared by reset, which correctly re-gates). Template: tpl_forward_arb_ruling_won. Time-bounded variant: arb.indemnity.time (U64 ruling timestamp). Merchant-favor dismissal edges: tpl_forward_arb_ruling_dismissed (arb.indemnity.amount == 0 — fail-closed on the None field).",
           "evidence": "Root queries arb.status; table pins a constant numeric value of 5 (Finished).",
           "stakeholders": ["provider", "customer"]
         }
@@ -472,24 +472,24 @@
         },
         {
           "when": { "all": [{ "field": "rc3_05_applies", "op": "eq", "value": true }, { "field": "rc3_05_critical", "op": "eq", "value": false }] },
-          "level": "high",
-          "title": "Submitted Order/Progress/Arb is NOT verified to belong to the current project (cross-project bypass — CRITICAL trust-boundary gap)",
+          "level": "info",
+          "title": "Submitted Order/Progress/Arb is NOT verified to belong to the current project — advisory: the chain now rejects cross-order submissions at the Progress layer (protocol v148, N-1 assert_task_binding); keep the project binding as defense-in-depth",
           "description": "Guard accepts runtime-submitted Order/Progress/Arb object(s) [${rc3_05_unbound_csv}] but the root does NOT verify the submitted object belongs to the current project (no query of order.service/order.machine/progress.machine/arb.service compared to a project constant).\n\nTRUST-BOUNDARY GAP (verified via Move source):\n  - The Passport submission is built by the CALLER, not auto-injected by the runtime\n  - the guard verification receives ONLY the caller-provided submission bytes — it never sees the Progress/Order actually being forwarded\n  - the passport-driven forward performs NO linkage check between the passport submission and the Progress under advancement\n  - Even the order forward's E_ORDER_NOT_MATCH only checks the separate `order:&Order` parameter, NOT the order_id embedded in the passport submission\n\nEXPLOIT (scene=${rc3_05_scene_label}):\n  1. Attacker holds Order Y from project B (where progress.current_time is old enough to pass the time-lock)\n  2. Attacker calls forward on Order X's Progress (project A, freshly entered the node)\n  3. Attacker submits Order Y's ID in the passport (lying about which order is being forwarded)\n  4. Guard's witness=100 reads Order Y's Progress -> time-lock passes (Order Y is old)\n  5. forward actually executes on Order X's Progress -> TIME-LOCK BYPASSED\n\nThis is distinct from R-C3-01 (Signer binding — WHO can submit) and R-C3-03 (type matching — WHAT type is submitted). R-C3-05 addresses WHETHER the submitted object belongs to the current project — a third orthogonal axis of submission trust. Even with R-C3-01 satisfied (authorized Signer) and R-C3-03 satisfied (correct type), the Signer can still submit an unrelated project's object.",
           "scenario": "Cross-project bypass: authorized signer submits an unrelated project's order/progress/arb to bypass time-lock, status, or allocation conditions",
           "mitigation": "Add a project-binding check to the root (wrap existing root in logic_and):\n  - For submitted Order: add logic_equal[query(1563: order.service), identifier[N](project_service_address)] — RECOMMENDED (service is the canonical project anchor)\n  - For submitted Order: add logic_equal[query(1560: order.machine), identifier[N](project_machine_address)] — alternative (machine anchor)\n  - For submitted Progress: add logic_equal[query(1250: progress.machine), identifier[N](project_machine_address)]\n  - For submitted Arb: add logic_equal[query(1402: arb.service), identifier[N](project_service_address)]\n  - Use witness=102 (TypeOrderService) on the submitted Order to derive the Service, then compare to the project service constant\n\nIntentional cross-project exception: if the Guard is DESIGNED to accept cross-project submissions (rare), document this explicitly in the description and add a binding_hint annotation 'cross_project_intentional:true' to suppress this rule.",
-          "evidence": "Unbound submitted project-relevant entries: ${rc3_05_unbound_csv}. Scene: ${rc3_05_scene_label}. Missing project-binding queries: none of [1563(order.service), 1560(order.machine), 1250(progress.machine), 1402(arb.service)] present in root.",
+          "evidence": "Unbound submitted project-relevant entries: ${rc3_05_unbound_csv}. Scene: ${rc3_05_scene_label}. Missing project-binding queries: none of [1563(order.service), 1560(order.machine), 1250(progress.machine), 1402(arb.service)] present in root. Chain backstop (protocol v148): progress.move assert_task_binding requires the passport's identifier-254 submission to equal Progress.task on every guard-gated forward of a task-bound Progress — cross-order replay aborts with 11 (binding required) / 12 (binding mismatch).",
           "stakeholders": ["customer", "provider", "arbitrator"],
           "exposure": {
             "loss_parties": [
-              { "role": "merchant", "basis": "Time-lock, status and allocation conditions stop protecting the project — funds can be released before the merchant's obligations are met." },
-              { "role": "buyer", "basis": "The buyer's order protections (time-locks, status gates) can be bypassed with a foreign project's object." }
+              { "role": "merchant", "basis": "Historical (pre-v148): time-lock, status and allocation conditions stopped protecting the project — funds could be released before the merchant's obligations were met. Since protocol v148 the chain rejects cross-order evidence at the Progress layer, so this loss path no longer materializes." },
+              { "role": "buyer", "basis": "Historical (pre-v148): the buyer's order protections (time-locks, status gates) could be bypassed with a foreign project's object. Since protocol v148 the task binding closes that path; the missing project queries remain a defense-in-depth gap only." }
             ],
             "gain_paths": [
               {
                 "role": "neutral",
                 "path": "The caller submits an unrelated project's order/progress id in the passport while forwarding the real Progress; the Guard witness reads the foreign object and passes.",
-                "viability": "viable",
-                "gate": "The runtime never links the passport submission to the Progress under advancement — the bypass executes exactly as described in the exploit."
+                "viability": "blocked",
+                "gate": "protocol v148 assert_task_binding runs on every guard-gated forward of a task-bound Progress and aborts when the identifier-254 submission does not equal Progress.task — the forged-evidence forward is rejected by the chain after guard verification, before the node can advance."
               }
             ]
           }

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

@@ -22,7 +22,7 @@
     "first_missing_guard_forward_name": "First-offender — name of the first Forward referencing a Guard outside the published set (absent when none).",
     "first_missing_guard_guard": "That Forward's Guard address.",
     "first_retained_no_guard_forward_name": "First-offender — name of the first Forward carrying retained_submission without any Guard (absent when none).",
-    "first_noperm_forward_name": "First-offender — name of the first Forward with NONE of namedOperator, permissionIndex, or Guard (absent when none). A Guard-only forward IS executable: the verified Guard replaces both identity pre-checks through the Passport path.",
+    "first_noperm_forward_name": "First-offender — name of the first Forward with NONE of namedOperator, permissionIndex, or Guard (absent when none). Note: since N-8-B a Guard-only forward is rejected by the chain at CONSTRUCTION (forward_with_guard aborts E_FORWARD_NO_IDENTITY 21) and re-checked at publish — both constructors require namedOperator or permissionIndex on EVERY forward; treat Guard as a post-verification addition, never the sole binding.",
     "first_noperm_prev": "That Forward's Pair prev_node.",
     "first_noperm_next": "That Forward's Pair next_node.",
     "first_both_forward_name": "First-offender — name of the first Forward with BOTH namedOperator and permissionIndex set (absent when none).",
@@ -202,7 +202,7 @@
     {
       "rule_id": "R-M1-11",
       "dimension": "structural",
-      "trigger": "Two-tier node-name match, identical to the template-scanner / mode-actions / audit-rules enforcement regex /(^|_)(disputed?|arbitration|arb)(_|$)|^(refund|refunded|deposit_refunded|deposit_deducted|cancel|cancelled)$/i — dispute family matches any underscore segment (a dispute never lives inside the Machine); fund terminals match EXACT names only. Business states that ROUTE allocator refunds ('closed_cancel', 'cancel_requested', 'refund_requested', 'return_approved', 'returned') do NOT match. — catalog stub: the retired check was not implemented",
+      "trigger": "Two-tier node-name match, single-sourced in knowledge/audit-rules.ts (ANTI_PATTERN_NODE_REGEX = DISPUTE_FAMILY_NODE_REGEX | FUND_TERMINAL_NODE_REGEX): /(^|_)(disputed?|arbitration|arb)(_|$)|^(refund|refunded|deposit_refunded|deposit_deducted|cancel|cancelled)$/i — dispute family matches any underscore segment (a dispute never lives inside the Machine); fund terminals match EXACT names only. Business states that ROUTE allocator refunds ('closed_cancel', 'cancel_requested', 'refund_requested', 'return_approved', 'returned') do NOT match. The template scanner's R-M1-11 adds one guard-anchored exemption: a fund-terminal node whose refund-track allocator row binds (guard_key) a guard that names that state downgrades to a LOW finding — the wrap publish gate (auditMachineNodes) stays strict. — catalog stub: the retired check was not implemented",
       "cases": [
         {
           "when": { "field": "always_true", "op": "eq", "value": false },
@@ -387,14 +387,14 @@
     {
       "rule_id": "R-M3-01",
       "dimension": "permission",
-      "trigger": "Check each forward has at least one executor binding: namedOperator, permissionIndex, or Guard (Guard-only is valid — verified via Passport)",
+      "trigger": "Check each forward has at least one executor binding: namedOperator, permissionIndex, or Guard (the chain rejects a Guard-only forward at construction and again at publish with E_FORWARD_NO_IDENTITY — Guard is a post-verification addition, never the sole binding)",
       "cases": [
         {
           "when": { "field": "first_noperm_forward_name", "op": "present" },
           "level": "critical",
           "title": "Forward without permission",
           "description": "Forward has no executor binding at all — neither namedOperator, permissionIndex, nor Guard. Cannot be executed (the plain forward constructor aborts E_PERMISSION_NOT_DEFINED).",
-          "mitigation": "Set namedOperator='' for OrderHolder, set permissionIndex, or bind a Guard (a Guard-only forward is executable through the Passport path — the verified Guard replaces both identity pre-checks).",
+          "mitigation": "Set namedOperator='' for OrderHolder, or set permissionIndex. Binding a Guard alone is rejected (E_FORWARD_NO_IDENTITY aborts in both constructors and again at publish): a Guard is a post-verification addition on top of an identity field, never a replacement.",
           "evidence": "Forward \"${first_noperm_forward_name}\" in Pair (${first_noperm_prev} -> ${first_noperm_next}) has no executor binding.",
           "exposure": {
             "loss_parties": [
@@ -472,7 +472,7 @@
           "level": "medium",
           "title": "Permission game imbalance",
           "description": "One party has excessive permission, can unilaterally advance workflow. Game theory imbalance.",
-          "mitigation": "Use dual-signature (threshold=2) or multi-signature mechanism to balance power."
+          "mitigation": "Use dual-signature (threshold=2 with two DISTINCT operator-bound forwards, each weight 1) or a multi-signature mechanism to balance power. Note: threshold=2 alone does not guarantee two different people — one forward of weight 2 passes alone, and permission admins hold every index."
         }
       ]
     },

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

@@ -236,7 +236,7 @@
           "when": { "field": "operation", "op": "eq", "value": "arb_claim_compensation" },
           "level": "high",
           "title": "arb_claim_compensation is IRREVERSIBLE (claimed_by one-time set)",
-          "description": "Setting claimed_by is permanent. After this call: (1) claimed_by cannot be reset, (2) NO new disputes can be filed (E_ORDER_ALREADY_CLAIMED), (3) all unresolved disputes become unactionable, (4) the order seals itself — the owner receive entries abort, so any escrow balance still on the order becomes unclaimable. If first compensation is insufficient, buyer has no recourse.",
+          "description": "Setting claimed_by is permanent. After this call: (1) claimed_by cannot be reset, (2) NO new disputes can be filed (E_ORDER_ALREADY_CLAIMED), (3) all unresolved disputes become unactionable, (4) NO on-chain seal follows — the owner receive entries are deliberately ungated (order.move:213-234), so escrow still on the order remains claimable; enforce any refund-vs-claim exclusion by gating the refund allocator on order.claimed_by some==false. If first compensation is insufficient, buyer has no recourse.",
           "scenario": "Buyer claims partial compensation, then discovers additional damages",
           "mitigation": "BEFORE claiming: (1) enumerate ALL disputes, (2) ensure proposition covers all damages, (3) confirm Arb ruling is final. Add explicit user confirmation (C-O-08).",
           "evidence": "operation=arb_claim_compensation, current_claimed_by=${claimed_by_display}",

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,12 +20,27 @@ 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 = 33;
+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;
 export declare function listBuiltinTemplates(): ArchetypeTemplate[];
+export declare function validateBuiltinTemplateCatalog(entries?: ArchetypeTemplate[]): void;